Как построить открытую АСУТП. Как мы собрали стенд из компонентов открытой АСУТП

21–22 октября в Нижнем Новгороде состоялся II Всероссийский форум «Промышленная автоматизация: переход на открытую АСУТП». Мероприятие, организованное в рамках программы Минпромторга РФ «Код индустрии» при поддержке рабочей группы по открытой АСУТП (РГ ОАСУТП), было нацелено на обмен опытом и поиск решений для ключевых проблем. Однако обсуждение проблем и обмен опытом — это лишь небольшая часть того, что происходило на форуме.

Перед РГ ОАСУТП была поставлена задача демонстрации на форуме новых разработанных технологических решений. Поэтому уже в конце августа 2025 года РГ приняла решение: на форуме в Нижнем Новгороде представить действующий многокомпонентный стенд. В качестве демонстрационного объекта выбрали типовую котельную — наглядный и понятный пример. Главный вызов был не в логике, а в интеграции компонентов. На одном стенде должны были «подружиться» компоненты от разных вендоров. К концу сентября участники рабочей группы ОАСУТП продумали архитектуру: несколько независимых систем (котельная, насосная, телемеханика) и единая система диспетчеризации, связанные через технологическую шину данных на OPC UA.

Меня зовут Пчельникова Татьяна, я владелец продукта в ИТ-команде «Северстали». Я расскажу, как мы с рабочей группой собрали межвендорный стенд и продемонстрировали совместную работу готовых компонентов открытой АСУТП на реальном объекте.

Архитектура стенда — это классическая пирамида, но с современной начинкой

Уровень 1. Локальные системы управления:

• система управления котельной: автоматизация тепловых процессов (регулирование температуры, давления, расхода топлива);
• система управления насосной станцией: управление насосами, контроль давления и уровня жидкости, сбор данных с расходомеров и датчиков через HART и Ethernet APL;
• система телемеханики (на примере нефтедобывающей скважины): удалённый мониторинг и управление с использованием OPC UA.

Уровень 2. Единая система диспетчеризации.

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

Компоненты от «Северстали» на общем стенде

Компоненты ОАСУТП: среда исполнения и среда разработки работали в системе управления котельной, параллельно с программируемым логическим контроллером других вендоров. Структура этой системы представлена ниже:

На стенде был использован полный набор инструментов открытой АСУТП:

• EDGE-устройства: для локальной обработки данных и снижения нагрузки на центральные системы;
• удалённый ввод-вывод (Remote I/O) обеспечивает гибкое расширение и децентрализацию системы;
• программные ПЛК (Soft PLC) заменяют аппаратные ПЛК и обеспечивают переносимость конфигураций между платформами;
• SCADA-системы: решения от различных производителей, демонстрирующие интероперабельность;
• программные шлюзы-конвертеры: для интеграции классических систем и поддержки протоколов (Modbus TCP, Profibus, HART, IEC 61850);
• технологическая шина данных (ФОС) — единый поток данных между всеми уровнями системы на основе OPC UA;
• СМИД (система мониторинга и сбора диагностической информации) обеспечивает сквозной контроль всего тракта передачи данных — от датчика до диспетчерского уровня, собирая как технологические, так и диагностические данные со всех устройств АСУТП (контроллеров, модулей ввода/вывода, сетевого оборудования, ИБП и др.), а также отслеживает превышение уставок и формирует аварийные сообщения;
• полевая шина Ethernet APL — современная двухпроводная промышленная сеть с питанием по линии связи, поддерживающая OPC UA и предназначенная для подключения «умных» датчиков и исполнительных устройств непосредственно к открытой АСУТП;
• серверная платформа — отечественная серверная инфраструктура, обеспечивающая надёжное размещение виртуальных узлов управления, сервисов безопасности, мониторинга и оркестрации в рамках ИУП.Перечень компонентов, развёрнутых на серверной платформе:

• Виртуальные машины:
  • MGMT,
  • Оркестратор,
  • СМИД,
  • OPC UA Client,
  • ВУРУ Web-server SCADA «HMI Котельная»,
  • ВУРУ Web-server SCADA «HMI Насосная»,
  • ВУРУ Web-server SCADA «HMI Телемеханика»,
  • ВУРУ Web-server SCADA «HMI Компрессор»,
  • ВУРУ Прог.ПЛК1 Вендора №1 «Насосная»,
  • ВУРУ Прог.ПЛК2 Северсталь «Насосная»,
  • Шлюз,
  • OPC UA Server,
  • EDGE-парсер,
  • OPC UA Client.

План «А»: Развертываем всё на виртуальных машинах

План был такой: развернуть всю логику управления на виртуальных машинах (ВМ), а в поле оставить лишь модули ввода-вывода и сеть. И изначально мы пошли по этому пути при создании управляющей программы для котельной:

1. Создали функциональные блоки управления котлом на стандартном ST (IEC 61131-3), используя проверенные библиотеки.
2. Полностью отладили программу в виртуальной среде.
3. Собрали установочный DEB-пакет для целевой ВМ.
4. Провели все интеграционные тесты удалённо, на виртуальном стенде. Всё работало идеально. Казалось, план сработал.

Все остальные участники рабочей группы также разрабатывали свои компоненты, используя виртуальные машины.

Преимущества такого подхода:

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

Поворотный момент: «надо что-то, что можно потрогать»

Ближе к событию стало ясно: посетителям выставки важно видеть не просто серверные стойки, а осязаемые контроллеры. Нужен был физический ПЛК, на котором крутится наша логика. Решение было принято буквально на ходу.

У нас уже была отлаженная программа и отработанная технология упаковки. Мы оперативно собрали DEB-пакет под архитектуру аппаратной платформы выбранного вендора и передали его коллегам для установки. Результат превзошёл ожидания: партнёры самостоятельно установили пакет, наш runtime-модуль автоматически стартовал и начал публиковать технологические переменные в OPC UA-сервер. Мы выдохнули: ключевой компонент заработал на «неродном» железе без нашего физического присутствия.

Мы расширили линейку представленных аппаратных платформ своим прототипом. Весь процесс повторился:

1. Собрали DEB-пакет под его архитектуру.
2. Передали пакет партнёру на выставке.

Фактический деплой нашего ПО — от распаковки до работы — уложился в одну команду и занял меньше минуты. Вся установка осуществлялась одной простой командой: sudo dpkg -i flogic.deb

Главный «хак»: IEC 61131-3 внутри IEC 61499

Наши функциональные блоки, написанные на классическом ST, мы создали в среде разработки, поддерживающей стандарт IEC 61499. IEC 61499 — это стандарт для распределённых систем. И наша программа, созданная в парадигме 61131-3, прекрасно «зациклилась» и заработала в среде исполнения.

Что это дало? Мы не переписывали код. Мы дали старой, проверенной логике билет в будущее — в мир гибких, распределённых и независимых от железа систем. Что это значит на практике? Если у вас есть гигантская кодовая база на ST, которую вы боитесь трогать, выдыхайте. Её не нужно выкидывать или переписывать с нуля.

Была и ещё одна практическая задача при создании программы управления котельной: разработка функционального блока регулирования.

При создании функциональных блоков для регуляторов (ПИД, двухпозиционных и т.д.) критически важно точное знание времени — интервала между вызовами (Δt).

В парадигме IEC 61499 эту задачу обычно решают через событийные модели, например, используя блок E_CYCLE для генерации периодических событий, которые и несут в себе информацию о времени. Это было бы чистое, «академическое» решение.

Но у нас был выбран стандарт проектирования 61131-3, и блок E_CYCLE мы не использовали для получения значений времени. К счастью, наша среда исполнения имеет следующую возможность: функциональные блоки можно писать не только на ST, но и встраивать функции, написанные на C++.

Мы воспользовались этим как инженерным лайфхаком:

• написали функцию на С++, которая обращается к системным часам в операционной системе, используя CLOCK_MONOTONIC (для измерения монотонно возрастающего времени с произвольной начальной точки, обычно с момента загрузки системы);
• инкапсулировали эту функцию в логику функционального блока регулятора. Подробно как это делать можно прочитать в нашей статье тут.

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

Также мы реализовали библиотеку модулей управления (регуляторов), содержащихся в библиотеке OSCAT, и вспомогательные ФБ для этой библиотеки (в целом, около 40 ФБ). Эти ФБ и функция обращения ко времени будут доступны в следующем релизе среды разработки и среды исполнения.

Что мы вынесли для себя:

1. Установочный пакет — это суперсила. DEB-пакет (или RPM, или любой другой) — это не просто удобно. Это — индустриальный стандарт будущего, который радикально снижает порог вхождения и исключает человеческую ошибку при развёртывании. «Собрал один раз — установил, где угодно».
2. Виртуализация — это полигон. Она позволяет отладить 90% интеграции удалённо, параллельно и без стресса. Физический монтаж превращается в финальный, предсказуемый штрих.
3. Архитектурная ясность побеждает. Когда есть единый протокол для интеграции (у нас это OPC UA), а логика абстрагирована от железа, можно менять аппаратные платформы буквально на лету. Выбор носителя становится не судьбоносным решением, а тактическим вопросом.

Итог: история нашего стенда — не про революцию, а про эволюцию и прагматизм. Мы взяли проверенные временем технологии (ST, OSCAT), упаковали их в современные контейнеры (виртуализация, пакеты), соединили через открытый стандарт (OPC UA) и получили результат, который работает здесь и сейчас. И это, пожалуй, самый убедительный аргумент в пользу открытости АСУТП.

P.S.

Напоминаем, что открытый программный программируемый логический контроллер (ОП ПЛК) имеет открытый исходный код, и мы приглашаем к совместной работе в этом проекте:

• разработчиков,
• вендоров,
• интеграторов,
• преподавателей и студентов вузов,

для написания своих библиотек и компонентов, используемых при решении практических задач. Пишите на почту open.soft.plc@severstal.com

Подробнее прочитать про наши продукты и скачать дистрибутивы можно здесь.

Информация по межотраслевой рабочей группе открытой АСУТП — здесь.

to be continued…

Источник: https://habr.com/ru/companies/severstal/articles/977248

🔗 Как построить открытую АСУТП. Как мы собрали стенд из компонентов открытой АСУТП