ИНКА.ФРЕЙМВОРК

Промышленная платформа для создания, масштабирования и сопровождения бизнес-приложений, объединяющая Ядро ИНКА, стандарты разработки и единую шину данных.

Ядро ИНКА и стандарты разработки

Единая шина данных и базовые сервисы

Инструментарий для независимого развития

Назначение платформы

ИНКА.ФРЕЙМВОРК состоит из Ядра ИНКА и Стандартов ИНКА и формирует промышленный инструментарий разработки: единые правила проектирования, базовые сервисы, шину данных и средства администрирования функциональных модулей. Ядро ИНКА является технологической основой платформы ИНКА для создания, масштабирования и сопровождения бизнес-приложений.

ИНКА.ФРЕЙМВОРК предназначен для разработки и эксплуатации бизнес-приложений, работающих под управлением платформы ИНКА. Ядро ИНКА обеспечивает взаимодействие между функциональными модулями, управляет данными, бизнес-процессами, графическими интерфейсами, пользователями и правами доступа. Стандарты ИНКА задают единые правила и методологию на всех этапах: от проектирования и аналитики до внедрения и сопровождения.

В совокупности Ядро ИНКА и Стандарты ИНКА позволяют создавать приложения любой сложности и функциональности: от отдельных отраслевых модулей до масштабируемых цифровых контуров предприятия. Платформа дает командам единый подход к аналитике, разработке, тестированию, внедрению и дальнейшему развитию решений.

Решаемые задачи

Создание и масштабирование бизнес-приложений на единой платформе.
Сокращение сроков внедрения за счет готового инструментария разработки.
Поддержка модульного подхода к построению информационных систем.
Организация единой точки обмена данными между модулями и внешними системами.
Управление сущностями, данными, связями и событиями функциональных модулей.
Управление бизнес-процессами, шаблонами процессов и правилами.
Разработка и настройка пользовательских интерфейсов через UI-конструктор.
Администрирование, активация, обновление и версионирование функциональных модулей.
Управление пользователями, ролями, группами и объектами доступа.
Настройка авторизации через внешние системы и корпоративные провайдеры.
Поддержка уведомлений, печатных форм, отчетов и шаблонов документов.
Сбор логов, метрик, мониторинг и самодиагностика сервисов.
Управление лицензиями ядра и функциональных модулей.
Поддержка стандартов разработки, обучения и создания центров компетенций.

Разработка бизнес-приложений

Стандарты ИНКА описывают полный путь разработки: проектирование и аналитику, разработку, опытно-промышленную эксплуатацию, эксплуатацию и развитие. В них входят единые принципы ведения проекта, подготовки аналитики, back-end и front-end разработки, тестирования, настройки бизнес-процессов и сопровождения решений.

Функциональный модуль в архитектуре ИНКА представляет собой бизнес-приложение, построенное по продуктовому принципу и покрывающее конкретные бизнес-требования. Модуль может включать внешние API, функции, тестовые функции, события, собственные пользовательские интерфейсы, шаблоны форм, настройки стандартных представлений, бизнес-процессы, связи сущностей, базу данных, настройки модуля, health check и зависимости от событий или сущностей других модулей.

Архитектура и технологическая основа

Ядро ИНКА построено на микросервисной архитектуре и объединяет собственные сервисы платформы с промышленными open-source решениями. Архитектура поддерживает гибкость, масштабируемость, отказоустойчивость, событийно-сущностную модель и единую шину данных.

Технологическая основа включает кросс-платформенность, Docker, Kubernetes, диспетчеризацию на базе Dapr, OData как альтернативу прямой работе с SQL, ORM-слой для независимости от базы данных, REST API для независимости от языка программирования, мониторинг LGTM и шаблон функционального модуля. Базовый стек разработки: .NET Core и Angular.

Принципы разработки

Принципы ИНКА нужны, чтобы проект быстрее переходил от архитектуры платформы к прикладным сценариям предприятия.

скорость и простота разработки;
кастомизация под запрос заказчика;
единый интерфейс;
быстрая интеграция со сторонними системами.

Платформа проектируется так, чтобы новые производственные сервисы не начинались с повторной сборки базового технологического контура.

Модульность, единый интерфейс и интеграционные возможности помогают адаптировать решение под процессы заказчика и подключать его к существующей ИТ-инфраструктуре.

Ядро и базовые сервисы

Ядро ИНКА является основой модульной архитектуры платформы. Функциональные модули подключаются к ядру как самостоятельные бизнес-приложения, которые решают конкретные задачи предприятия и используют общие сервисы платформы.

Такой подход позволяет подбирать только необходимые модули, не перегружать инфраструктуру избыточным функционалом и развивать систему поэтапно. Новые модули могут создаваться на базе готовых шаблонов, low-code/no-code инструментов и стандартов разработки ИНКА.

Ядро включает управление сущностями, подсистему уведомлений, диспетчеризацию, лицензирование, управление модулями, мониторинг и логирование, BPMN-движок, UI-конструктор, портал ядра, подсистему печати, управление пользователями и самотестирование.

Поддерживаются экспорт и импорт настроек, работа с манифестами модулей, настройка связей сущностей, маппинг полей, события модулей, вычисляемые поля, сохраненные запросы и карта связей. Для работы с данными используются инструменты OData: фильтрация, сортировка, выбор полей и расширение навигационными и внешними сущностями.

Для пользовательских интерфейсов предусмотрен конструктор форм с low-code настройкой взаимодействия с функционалом модулей. Можно создавать полноэкранные и модальные формы, формы с навигацией и без нее, настраивать лейауты, меню, логотипы и области интерфейса, использовать типовые элементы и расширять логику JavaScript-скриптами и кастомными компонентами.

Администрирование, безопасность и контроль

Ядро ИНКА обеспечивает централизованное администрирование модулей, портала, пользователей, ролей, групп и объектов доступа. Поддерживаются внешние провайдеры авторизации, Active Directory, LDAP, OAuth 2.0, OpenID, SAML и двухфакторная аутентификация.

Встроенные средства мониторинга, логирования и самодиагностики позволяют контролировать состояние сервисов ядра и функциональных модулей. Подсистема лицензирования управляет лицензиями ядра и модулей, поддерживает онлайн- и офлайн-лицензии, ограничения доступа при истечении лицензии и передачу параметров лицензии в модуль.

Интеграции и единая шина данных

Ядро ИНКА обеспечивает работу событийной модели платформы и взаимодействие функциональных модулей через единую шину данных. Это позволяет организовать согласованный обмен информацией между модулями ИНКА и внешними системами предприятия: ERP, MES, АСУ ТП, АСУП, системами энергоучета, экологии и другими цифровыми решениями.

Единая шина данных помогает сделать платформу общей точкой обмена информацией и использовать данные в разных приложениях без дублирования и несогласованных интеграций.

Центр компетенций и независимое развитие

На базе платформы ИНКА заказчик может создать собственный центр компетенций разработки бизнес-приложений. Команда получает доступ к базе знаний, стандартам разработки, обучающим курсам и шаблонам для быстрого старта.

Это позволяет развивать функциональные модули собственными силами, совместно с партнером или на базе готовых продуктов ИНКА. Расширение функциональности возможно как через low-code/no-code инструменты, так и через полноценную разработку с использованием инструментария платформы.

Создание центра компетенций обеспечивает независимость в разработке и масштабировании бизнес-приложений любой сложности и функциональности.

Политика перехода между версиями продуктов ИНКА

Правила планирования, обновления, приемки и отката.

Статус: проект внутреннего нормативного документа. Область: ядро ИНКА, функциональные модули и инфраструктурные компоненты. Актуальность источников: docs.inka.ru, состояние на 20.07.2026.

Главное правило. Переход разрешается только для документированной целевой версии, после проверки совместимости, резервного копирования и успешной репетиции на непроизводственной среде. Для ядра переход выполняется последовательно по соседним версиям.

1. Назначение и область действия

Политика устанавливает единый порядок обновления, понижения версии и смены продуктовой ветки. Она применяется к ядру ИНКА, функциональным модулям, конфигурациям и связанным инфраструктурным сервисам в средах разработки, тестирования, приемки и промышленной эксплуатации.

Политика обязательна для владельца продукта, администратора платформы, разработки и эксплуатации, команды продукта, тестирования и ответственного за приемку. Описание изменений целевой версии имеет приоритет над общими положениями политики.

2. Базовые принципы

Версия и артефакт едины. Используется формат X.Y.Z; версии продукта, манифеста, задач и поставочных артефактов согласованы.
Совместимость подтверждается. Изменения контрактов, событий, функций и сущностей требуют повышения версии и проверки влияния на интеграции.
Переход воспроизводим. Фиксируются исходная и целевая версии, состав поставки, конфигурация, миграции, план проверки и возврата.
Данные защищены. До изменений создаются и проверяются резервные копии БД, файловых хранилищ и конфигураций.
Ядро обновляется по шагам. Нельзя пропускать промежуточные версии ядра, если описание изменений версии не подтверждает кумулятивный переход.
Промышленная среда - только по утвержденной процедуре. Экспериментальный скрипт обновления ядра не используется как готовый промышленный регламент без адаптации, ревью и испытаний.

3. Классы переходов

Исправление внутри ветки: изменение Z, стандартный риск; требуются описание изменений версии, проверка совместимости, резервная копия и приемочные проверки.
Переход на следующую версию: соседняя версия ядра или продукта, повышенный риск; требуются репетиция, миграции, окно работ и контроль точки возврата.
Пропуск нескольких версий: два и более шага, высокий риск; для ядра обязателен последовательный переход, для ФМ допустим только при прямом указании в документации.
Смена ветки продукта: например, НСИ 1.x на 2.x или 2.0 на 2.1, высокий риск; нужен отдельный план миграции данных, интеграций, форм и пользовательских расширений.
Понижение версии: целевая версия ниже текущей, критический риск; допустимо только на подтвержденную резервную копию, возможна потеря данных после точки копирования.

4. Условия допуска к переходу

Работы запускаются только при одновременном выполнении условий:

зафиксированы продукт, исходная и целевая версии, версия ядра, окружение и состав поставки;
целевая комбинация есть в актуальной матрице совместимости либо подтверждена владельцем продукта или технической поддержкой;
изучены описания изменений промежуточных версий, специальные инструкции и обязательные действия после обновления;
подготовлены артефакты с неизменяемыми тегами, проверены контрольные суммы и доступ к реестру образов;
оценены миграции БД, изменения API, событий, сущностей, форм, конфигураций и интеграций;
созданы и проверены резервные копии БД, MinIO/файлов, конфигураций, секретов и манифестов;
переход отрепетирован на среде, максимально близкой к промышленной, с протоколом успешной проверки;
согласованы окно работ, лица, принимающие решение о запуске или отказе от запуска, допустимый простой, точка возврата и коммуникации;
готовы лицензии, ресурсы, доступы и мониторинг для целевой версии.

Запрет. Установщик ядра применяется только на чистом стенде; он не используется для обновления или отката существующей установки.

5. Порядок выполнения перехода

Инвентаризация: снять фактические версии ядра, ФМ, инфраструктуры, конфигураций и схем БД; зафиксировать CORE_VERSION и состав образов.
Проектирование маршрута: построить последовательность версий; для ядра включить каждый соседний шаг, для ФМ проверить манифест и описание изменений каждой целевой версии.
Оценка совместимости: сопоставить минимальную версию ядра, требования инфраструктуры и специальные действия; недокументированные сочетания считать неподтвержденными.
Репетиция: восстановить копию данных на тестовом стенде, выполнить полный маршрут, проверить миграции, формы, права, интеграции, события и производительность.
Подготовка возврата: проверить восстановление резервных копий и определить предельное время решения об откате.
Выполнение: остановить ФМ и ядро в согласованном порядке, создать финальные копии, выполнить переход, применить миграции и специальные действия из описания изменений версии.
Техническая проверка: проверить контейнеры, работоспособность сервисов, логи, очереди, БД, авторизацию, регистрацию манифестов и пользовательские формы.
Приемка: пройти согласованные сценарии и зафиксировать объект, версии, среду, поставку, результат и замечания.
Закрытие: обновить эксплуатационную документацию и матрицу совместимости, сохранить протокол и ссылки на резервные копии по правилам хранения.

6. Последовательность компонентов

при необходимости подготовить и обновить инфраструктуру при остановленном ядре, включая обязательные миграции инфраструктурных БД;
последовательно обновить ядро до версии, удовлетворяющей требованиям всех целевых ФМ;
обновить ФМ и зарегистрировать или обновить их манифесты;
выполнить специальные действия из описания изменений версии, например регенерацию форм НСИ 2.1.3;
запустить комплексные проверки межмодульных сценариев.

Если описание изменений конкретной версии задаёт иной порядок, применяется этот специальный порядок. Инфраструктура обновляется при остановленном ядре и после резервного копирования сервисов.

7. Условия отката и понижения версии

Откат инициируется при невыполнении критерия допуска к запуску, превышении допустимого простоя, необратимой ошибке миграции или нарушении целостности либо доступности данных. Понижение выполняется только к версии с проверенной резервной копией совместимого состояния данных и конфигурации.

После миграций недостаточно заменить образы: восстанавливаются данные, файлы и конфигурации из согласованной точки возврата. Владелец бизнеса заранее подтверждает допустимость потери изменений после точки резервного копирования. После отката выполняются технические и бизнес-проверки, а инцидент и фактическая точка восстановления фиксируются в протоколе.

Критический риск. Восстановление резервной копии при понижении версии возвращает систему к моменту ее создания; накопленные после этой точки данные могут быть утрачены.

8. Критерии успешности и приемка

фактические версии соответствуют утвержденной целевой комбинации;
сервисы и ФМ запущены, проверки работоспособности успешны, критические ошибки в логах отсутствуют;
миграции завершены, целостность данных подтверждена, контрольные выборки совпадают;
авторизация, роли, формы, ключевые функции, события и интеграции работают по согласованным сценариям;
производительность находится в согласованных пределах;
протокол содержит продукт, его версию, версию ядра, среду, состав поставки, сценарии и решение о приемке.

Результат перехода: «принято», «принято с некритичными замечаниями» или «не принято/выполнен откат». Критичность замечаний определяется критериями проекта.

9. Управление исключениями и поддержка

Если сочетание версий отсутствует в документации, содержит противоречия или предполагает пропуск миграций, переход блокируется до письменного решения владельца продукта либо технической поддержки. Заявка содержит продукт и версию, среду, шаги воспроизведения или сценарий, ожидаемый и фактический результат, логи и перечень выполненных проверок.

Исключение должно иметь срок действия, владельца риска, компенсирующие меры и план возврата к поддерживаемой комбинации.

10. Ответственность

Владелец продукта: утверждает целевую версию, приоритет описания изменений версии, критерии приемки и исключения.
Архитектор или технический лидер: подтверждает маршрут, совместимость контрактов и влияние на интеграции.
Разработка и эксплуатация: отвечает за резервное копирование, переход, наблюдаемость и технический откат.
Команда продукта: поставляет артефакты, миграции, специальные действия и исправляет дефекты.
Тестирование/приемка: выполняет репетицию, регресс, бизнес-сценарии и фиксирует решение.

Приложение А. Контрольный лист допуска к запуску

маршрут версий согласован, пропусков промежуточных версий ядра нет;
минимальная версия ядра соответствует целевым ФМ;
описания изменений и специальные инструкции изучены;
репетиция завершена успешно и задокументирована;
резервные копии созданы, их читаемость и восстановление проверены;
окно, владельцы решения и время точки возврата подтверждены;
мониторинг, логи, проверка работоспособности и критерии приемки готовы;
план отката выполним в доступное окно, риск потери данных принят.

Документация и информация о платформе

Включен в Единый реестр российского программного обеспечения под наименованием «Индустриальная Кибернетическая Платформа 4.0»: запись Минцифры России от 23.01.2023 № 16301.
Свидетельство о государственной регистрации программы для ЭВМ
Техническое описание ИНКА 4.0
Назначение и функционал ИНКА.Ядро 1.6
Презентация ИНКА 4.0

Вопросы о внедрении и применении

Чем платформа отличается от функционального модуля?

ИНКА.ФРЕЙМВОРК предоставляет ядро, стандарты разработки, базовые сервисы и единую шину данных. Функциональные модули решают прикладные задачи, например ведение НСИ и оперативный производственный учёт.

Можно ли развивать собственные производственные приложения?

Платформа предназначена для создания, масштабирования и сопровождения бизнес-приложений. Архитектура конкретного решения, состав модулей и распределение ответственности определяются требованиями предприятия.

Где изучить документацию и примеры?

Регистрационные документы и материалы платформы доступны на этой странице. В каталоге продуктов приведены функциональные модули, а в разделе кейсов — опубликованные примеры реализации решений.

См. также: продукты ИНКА и кейсы внедрения. Обсудить задачи предприятия.