Архитектура НППА
Задача НППА — сформировать открытую экосистему, в которой оборудование и программное обеспечение разных производителей работают совместно без проприетарных шлюзов и вендорных ограничений. Чтобы это стало возможным, платформа строится вокруг единой архитектурной идеи: декуплинг аппаратного обеспечения от прикладного программного обеспечения.
Именно это разделение — «железо» отдельно, логика управления отдельно — позволяет переносить алгоритмы между платформами, заменять контроллер одного производителя контроллером другого без переписывания кода и собирать систему из компонентов независимых разработчиков как из конструктора.
Прототип НППА в виде физически реализованной системы — Распределённый стенд
Три домена НППА
Для структурирования задач и компонентов НППА использует доменную модель. Домен — это самостоятельная область деятельности со своими процессами, продуктами и стандартами. Три домена охватывают полный жизненный цикл системы автоматизации: непосредственное управление технологическим процессом, управление жизненным циклом самих систем автоматизации и публикацию проверенных решений для участников рынка.
Первый домен — основной с точки зрения технологии производства. Именно для него разработана ключевая архитектурная конструкция НППА — открытая распределённая система управления (ОРСУ), которой посвящены все последующие разделы этой страницы. Второй и третий домены обеспечивают инструментарий для разработчиков и механизм доверия для заказчиков — подробнее о них в разделе Витрина доверенных решений.
Домен 1. Автоматизация технологических процессов
Уровни IACS-0 и IACS-1/2
Охватывает оперативное управление производством в реальном времени. Включает компоненты, непосредственно взаимодействующие с технологическим процессом — от полевых приборов до диспетчерского уровня.
Процессы
- Контроль и управление технологическим процессом
- Мониторинг, диспетчерское управление и автоматизированное управление
- Эксплуатация систем автоматизации технологических процессов
Продукты и компоненты
- Узлы распределённого управления (УРУ) и виртуальные УРУ (вУРУ)
- Информационно-управляющие платформы (ИУП)
- SCADA/HMI — системы диспетчерского управления
- Системы противоаварийной защиты (СПАЗ/ПАЗ)
Ключевые стандарты
- ГОСТ Р МЭК 62541 (OPC UA) — стандарт обмена данными
- ГОСТ Р МЭК 61131-3 — языки программирования ПЛК
- IEC 61499 — распределённые функциональные блоки
- IEC 62264 / ISA-95 — интеграция с ERP/MES
- IEEE 1588 / PTP — синхронизация времени
Домен 2. Управление жизненным циклом систем автоматизации
Проектирование, разработка, внедрение, модернизация
Определяет процессы сквозного проектирования, программирования, тестирования и развёртывания конфигураций. Обеспечивает воспроизводимость и контролируемость изменений в системе на протяжении всего жизненного цикла.
Процессы
- Проектирование и разработка систем АСУ ТП
- Внедрение и модернизация
- Управление конфигурацией и версионирование
Продукты и компоненты
- Инженерные среды разработки (IDE)
- Службы управления конфигурацией (СУК)
- DevOps-конвейеры для АСУ ТП (CI/CD, тестирование, развёртывание)
- Сервисы ИБ для разработки открытой АСУ ТП
Ключевые стандарты
- AutomationML — описание топологии и параметров оборудования
- YAML/JSON — схемы конфигурационных файлов
- IEC 61499 — распределённые системы управления
Домен 3. Витрина решений открытой АСУ ТП
Доверенная экосистема для участников рынка
Обеспечивает доверенную среду для разработчиков, системных интеграторов и заказчиков. Включает инструменты верификации совместимости решений с требованиями НППА и механизмы их публикации и распространения.
Процессы
- Внесение решений в доверенный репозиторий
- Верификация совместимости с требованиями НППА
- Доступ к решениям и их использование
Продукты и компоненты
- Портал каталога решений (Витрина)
- Доверенный репозиторий программного обеспечения
- Средства сертификации решений
- Полигоны тестирования совместимости
Ключевые стандарты
- Стандарты сертификации совместимости
- ISA/IEC 62443 — кибербезопасность промышленных систем
- Безопасность данных и контроль версий
Взаимодействие между доменами
Три домена не существуют изолированно — между ними выстроены чёткие потоки взаимодействия в зависимости от роли участника.
Вендор решений загружает свои программные компоненты в домен «Витрина решений», где они проходят верификацию. Заказчик и интегратор получают доступ к уже проверенным решениям из того же домена и могут быть уверены в их совместимости с НППА. Интегратор АСУ ТП работает в домене «Управление жизненным циклом»: проектирует, разрабатывает и внедряет системы, используя доверенный репозиторий из домена «Витрина». Готовая система в итоге попадает в домен «Автоматизация технологических процессов», где ею управляет служба эксплуатации, а обслуживает сервисная служба.
| Участник | Домен | Действие |
|---|---|---|
| Вендор решений для ОАСУ ТП | Витрина решений | Внесение решений |
| Заказчик, интегратор | Витрина решений | Доступ к решениям |
| Интегратор АСУ ТП | Управление жизненным циклом | Проектирование, разработка |
| Служба эксплуатации | Автоматизация технологических процессов | Эксплуатация |
| Сервисная служба АСУ ТП | Автоматизация технологических процессов | Обслуживание |
Связи между доменами:
- Витрина решений → Управление жизненным циклом: доступ к доверенному репозиторию.
- Управление жизненным циклом → Автоматизация технологических процессов: доступ к системам АСУ ТП.
Схема взаимодействия между доменами НППА — РГ ОАСУ ТП
Открытая распределённая система управления (ОРСУ)
НППА разрабатывается прежде всего как распределённая система управления (РСУ). Классические РСУ (DCS) существуют в промышленности десятилетиями, но строятся по закрытому принципу: все компоненты — от контроллеров до инженерных сред — производятся и интегрируются одним вендором. Замена любого элемента фактически означает замену всей системы.
ОРСУ решает эту проблему через открытую архитектуру: компоненты разных производителей взаимодействуют через стандартизированные интерфейсы, а прикладное ПО отделено от аппаратной платформы.
Архитектура ОРСУ строится на пяти взаимосвязанных принципах. Каждый из них решает конкретную проблему, возникающую при попытке собрать систему из компонентов разных производителей. Вместе они образуют целостную систему требований, при соблюдении которых гарантируется совместимость компонентов.
| Принцип | Описание |
|---|---|
| Взаимозаменяемость (Interchangeability) | Возможность аппаратной или программной замены компонента одного производителя эквивалентным компонентом другого производителя без изменения остальной части системы и без потери функциональности. |
| Интероперабельность (Interoperability) | Способность двух или более систем безопасно обмениваться информацией на семантическом уровне и совместно использовать полученные данные без написания специализированных шлюзов и драйверов. |
| Портируемость / Переносимость (Portability) | Возможность беспрепятственного переноса прикладного программного обеспечения (алгоритмов управления) с одной аппаратной платформы на другую. |
| Модульность (Modularity) | Логическое и физическое разделение системы на независимые, слабосвязанные блоки с жёстко специфицированными интерфейсами взаимодействия. |
| Оркестрируемость и управляемость (Orchestration & Manageability) | Возможность сквозного централизованного мониторинга, конфигурирования, развёртывания и обновления всех аппаратных и виртуальных ресурсов системы в реальном времени. |
FILO-модель: как достигается декуплинг
Ключевым инструментом реализации декуплинга является вертикальная декомпозиция программного обеспечения каждого вычислительного узла на четыре строго разделённых слоя. Аббревиатура FILO образована первыми буквами названий этих слоёв (сверху вниз): Functional, Implementation (Execution), Local services, Operating system.
Каждый слой знает только о том, что находится непосредственно под ним, и взаимодействует с ним через стандартизированный интерфейс. Прикладной алгоритм уровня F не «знает», под какой операционной системой он работает и на каком «железе» запущена эта ОС. Именно эта изоляция обеспечивает переносимость: перенести алгоритм с одного контроллера на другой — значит запустить тот же код F в другой среде исполнения I на другой ОС O, не меняя ни строчки логики.
| Слой | Название | Описание |
|---|---|---|
| F | Functional — Прикладной уровень | Прикладные алгоритмы управления технологическим процессом, написанные на технологических языках программирования (IEC 61131-3, IEC 61499). Полностью аппаратно-независим — перемещается между платформами без изменений. |
| I | Execution — Среда исполнения | Программный слой Runtime. Исполняет прикладной код уровня F, обеспечивает трансляцию абстрактных команд в системные вызовы. Примеры: ISaGRAF, MasterPLC, среды исполнения IEC 61499 (FORTE). |
| L | Local Services — Локальные системные сервисы | Системное ПО, специфичное для конкретной аппаратной платформы. Включает драйверы модулей ввода-вывода, локальные СУБД реального времени, встроенные серверные компоненты OPC UA, службы самодиагностики. |
| O | Operating System — Операционная система | Для УРУ — операционные системы реального времени (RT-Linux, Astra Linux с пулом РВ, QNX). Для ИУП — ОС общего назначения (Astra Linux, РЕД ОС). |
Вычислительные узлы: УРУ и ИУП
ОРСУ физически строится из двух классов вычислительных узлов, которые отражают два принципиально разных режима работы в промышленных системах: реальное время на уровне управления процессом и ИТ-инфраструктура для вычислительно-ёмких сервисов верхнего уровня.
Узлы распределённого управления (УРУ) работают в жёстком реальном времени и имеют прямой доступ к полевому оборудованию. Информационно-управляющие платформы (ИУП) — это серверная инфраструктура, на которой разворачиваются виртуализированные сервисы: виртуальные УРУ (вУРУ), SCADA, Historian, СУК. Разделение позволяет масштабировать каждую часть независимо и выбирать для неё подходящее оборудование.
Узел распределённого управления (УРУ / DCN)
Основной физический или виртуальный компонент ОРСУ. Выпускается в четырёх специализированных вариантах.
| Код | Тип | Описание |
|---|---|---|
| УП-Л | Узел управления — Логический | Полнофункциональный контроллер. Содержит среду исполнения (уровень I) и выполняет пользовательский алгоритм управления (уровень F). |
| УП-Д | Узел управления — Датчик/Актуатор | «Умный» полевой прибор с алгоритмом, зашитым на этапе производства. Не требует внешней инженерной среды для перепрограммирования. |
| УП-Ш | Узел управления — Шлюз | Предназначен для интеграции унаследованных (legacy) систем. Транслирует данные из проприетарных полевых протоколов (Modbus, Profibus, HART) в адресное пространство ФОС. |
| УП-П | Узел управления — Процессорный модуль | Аппаратный модуль без встроенных каналов ввода-вывода. Ориентирован на ресурсоёмкие вычисления или координацию подчинённых модулей ввода-вывода по внутренней шине. |
Виртуальный УРУ (вУРУ) — программный контейнер на ИУП, эмулирующий функции УП-Л.
Информационно-управляющая платформа (ИУП / ACP)
Высокопроизводительный программно-аппаратный комплекс (серверная группа или промышленный ЦОД). Обеспечивает функционирование виртуализированных сервисов автоматизации.
- Аппаратный слой: серверы стандартной архитектуры (x86, Эльбрус, ARM), дисковые массивы, резервированные коммутаторы.
- Программный слой: платформы виртуализации и контейнеризации (KVM, LXC, Docker/Kubernetes) с балансировкой нагрузки, High Availability и изоляцией сред.
- Развёртываемые сервисы: вУРУ, SCADA-серверы, системы архивирования (Historian), СУК, инженерные среды.
Стандартизированные интерфейсы (И1–И6)
Если FILO-модель описывает, как устроено ПО внутри одного узла, то шесть стандартизированных интерфейсов описывают, как узлы взаимодействуют между собой и с внешними системами. Именно жёсткая спецификация этих точек взаимодействия — главное условие взаимозаменяемости компонентов разных производителей. Производитель, реализовавший все необходимые интерфейсы согласно спецификации, получает гарантированную совместимость со всей экосистемой ОРСУ без дополнительной интеграционной работы.
| Код | Интерфейс | Описание |
|---|---|---|
| И1 | Физический интерфейс сети | Стандартизированный разъём и параметры подключения к среде передачи данных (Ethernet IEEE 802.3, Fast/Gigabit Ethernet). Применяется на уровне сетевых интерфейсов УРУ и коммуникационного оборудования. |
| И2 | Интерфейс ФОС | Программный интерфейс обмена технологическими переменными реального времени по протоколам OPC UA Pub/Sub (циклическая передача) и OPC UA Client/Server (транзакционный обмен, аларм). |
| И3 | Интерфейс загрузки конфигурации | Протокол и формат передачи конфигурационных файлов и исполняемого кода уровня F из Службы управления конфигурацией (СУК) в память УРУ/вУРУ. |
| И4 | Интерфейс администрирования ОС | Канал ИТ-администрирования для мониторинга состояния операционной системы уровня O: логи, загрузка CPU, диагностика ОЗУ, обновление прошивки ОС. |
| И5 | Интерфейс локальной наладки | Физический выделенный порт на УРУ (USB, RS-485 или RJ-45) для первоначального конфигурирования «в поле» — задание IP-адреса, базовых сетевых настроек в обход основной сети ФОС. |
| И6 | Интерфейс импорта/экспорта прикладного ПО | Унифицированный формат обмена схемами алгоритмов (уровень F) между инженерными средами разработки и Службой управления конфигурацией на базе XML-структур (AutomationML). |
Место ОРСУ в иерархии IACS
Архитектура ОРСУ сопоставляется со стандартной моделью производственных уровней (ГОСТ Р МЭК 62264-1), определяя типы обрабатываемой информации и временные интервалы.
| Уровень | Функция | Информация | Временной масштаб | Стек технологий |
|---|---|---|---|---|
| IACS-4 | Бизнес-управление (ERP, BI, CRM) | Корпоративная отчётность, финансовые показатели, заказы | Дни, месяцы, кварталы | Облачные технологии, СУБД общего назначения |
| IACS-3 | Управление операциями (MES, PLM, СУУТП) | Расчёт материальных балансов, рецептуры, параметры качества партий, оптимизация процессов | Часы, смены, сутки | Базовый ИТ-стек, серверы БД, аналитическое ПО |
| IACS-2 | Диспетчерское управление (SCADA/HMI, Historian) | Состояние цеха, алармы, тренды, технологические сводки | Минуты, секунды | Стек ИУП, распределённые SCADA, клиент-серверный OPC UA |
| IACS-1 | Базовое управление (УП-Л, вУРУ, регуляторы) | Контуры регулирования, блокировки, состояние агрегатов | Миллисекунды (цикл 1–100 мс) | Промышленный стек F-I-L-O, ОСРВ, IEC 61499/61131-3 |
| IACS-0 | Физический процесс (полевые приборы, КИП, УП-Д) | Значения давления, температуры (PV), управляющие воздействия (MV) | Микросекунды, миллисекунды | Датчики, исполнительные механизмы, полевые шины, TSN |
Инфраструктурные сервисы: ФОС, СУК, IDE
Помимо вычислительных узлов, ОРСУ включает три общесистемных сервиса. Они не управляют технологическим процессом напрямую, но без них система не может функционировать как единое целое: ФОС обеспечивает связность узлов, СУК — загрузку и обновление логики управления, IDE — инструментарий для разработчика. Вместе эти три сервиса закрывают полный цикл: разработка → загрузка → эксплуатация.
Служба управления конфигурацией (СУК)
Критически важный компонент, оркестрирующий всю систему. Собирает файлы прикладных программ уровня F из инженерных сред, привязывает логические переменные к физическим адресам ввода-вывода конкретных УРУ/вУРУ, формирует конфигурационные пакеты и осуществляет их централизованную загрузку через интерфейс И3.
Инженерная среда разработки (IDE)
Программный комплекс проектирования логики управления, независимый от вендора контроллера. Разработчик создаёт проект, используя стандартизированные библиотеки функциональных блоков, и экспортирует результат в открытом формате (XML/AutomationML) через интерфейс И6.
Фреймворк обеспечения связности (ФОС)
Единая коммуникационная среда, организующая взаимодействие всех компонентов ОРСУ. Базируется на OPC UA (ГОСТ Р МЭК 62541): Client/Server для транзакционного обмена и Pub/Sub для быстрой циклической передачи данных реального времени. Встроенная служба обнаружения (LDS-ME/GDS) обеспечивает принцип Plug and Play — новое устройство при подключении автоматически регистрируется и становится доступным для интеграции.
ФОС реализует принцип Plug and Play на уровне ПО: новый узел, появившись в сети, автоматически регистрируется через службу обнаружения LDS и становится доступным для СУК — без ручной настройки. СУК, в свою очередь, выступает как единый оркестратор конфигурации: она знает топологию всей системы и доставляет нужный код на нужный узел, контролируя версионность и согласованность. IDE замыкает цикл разработки — инженер пишет алгоритм один раз в стандартизированной среде и не задумывается о том, на каком «железе» он будет исполняться.
Сетевые механизмы реального времени
Промышленные системы управления предъявляют к сети требования, принципиально отличающиеся от офисных или ЦОД-сетей. Задержка в несколько миллисекунд, незаметная при просмотре веб-страниц, может привести к некорректному срабатыванию защиты или потере синхронизации между узлами. ОРСУ использует два механизма, которые делают стандартный Ethernet промышленно пригодным.
IEEE 1588 / PTP (Precision Time Protocol)
Обеспечивает субмикросекундную точность синхронизации времени на всех физических устройствах (УРУ, модули ввода-вывода) по сети ФОС. Необходим для точной фиксации последовательности событий (SOE — Sequence of Events) при авариях.
TSN (Time-Sensitive Networking)
Набор стандартов IEEE 802.1, гарантирующий доставку приоритетных пакетов управления в Ethernet-сетях без коллизий и с детерминированной задержкой за счёт временного разделения трафика (Time-Aware Shaper). Применяется на уровне сетевых интерфейсов И1.
TSN и PTP в совокупности решают две разные проблемы: TSN гарантирует, что пакет управления будет доставлен в нужный момент (детерминизм доставки), а PTP гарантирует, что все узлы системы согласованно понимают, что именно является «нужным моментом» (единое время). Без обоих механизмов реализовать распределённую систему управления с жёсткими требованиями реального времени на стандартном Ethernet невозможно.
Информационная безопасность в архитектуре НППА
Информационная безопасность в НППА не является отдельным контуром, надстроенным над системой. Это встроенное архитектурное свойство, заложенное на уровне принципов, интерфейсов и компонентов. Такой подход называется Secure by design: требования ИБ определяются на этапе проектирования каждого компонента, а не добавляются постфактум.
- Уровень протоколов. Базовый протокол ФОС — OPC UA — имеет встроенные механизмы безопасности: аутентификация сессий, шифрование канала, подпись сообщений. Это не опция, а обязательная часть стандарта IEC 62541.
- Уровень сети. Защита периметра и каналов связи: PT NGFW обеспечивает сегментацию технологической сети, ViPNet — защищённые VPN-каналы с ГОСТ-шифрованием между распределёнными площадками. Встраиваемые СКЗИ реализуют аппаратный корень доверия.
- Уровень мониторинга. PT ISIM осуществляет непрерывный мониторинг технологической сети: инвентаризация узлов, глубокий анализ трафика промышленных протоколов, обнаружение вторжений и управление инцидентами.
- Уровень компонентов. Требование Secure by design распространяется на каждый компонент, претендующий на включение в экосистему НППА. На распределённом стенде это проверяется практически: ИБ-компоненты демонстрируются наравне с функциональными на каждом релизе стенда.
- Нормативная база. Архитектура ИБ НППА выстраивается в соответствии с серией стандартов ISA/IEC 62443 (кибербезопасность промышленных систем) и требованиями ЗОКИИ (Приказ ФСТЭК №239, ПП РФ №1912). Детали нормативной базы — в описании релиза Q4-2025 на странице Релизы распределённого стенда.
- Витрина решений. Конвейер верификации в Витрине доверенных решений включает обязательные SAST и DAST-проверки: ни одно решение не попадает в доверенный репозиторий без прохождения автоматизированного анализа безопасности.
Разработкой требований ИБ для компонентов НППА занимается ТРГ по информационной безопасности — см. Технические рабочие группы. Подробнее об ИБ-стеке на распределённом стенде — на странице Распределённый стенд.
