Меня зовут Вадим Подольный и я технический директор Лаборатории Технологий Автоматизации. Это компания софтварный вендор, которую мы создали для разработки нашей платформы в 2020-м году. Также я являюсь руководителем комитета промышленной автоматизации Ассоциации Разработчиков Программных Продуктов (АРПП) «Отечественный софт», в состав которого входят такие же вендоры.
Я хотел бы рассказать о нашей разработке Платформе "Лацерта", которая является как бы и SCADA но и немного больше. В заголовке указано, что это первая часть, следовательно будут еще подробности. В рамках этой части я хотел бы обосновать идею данной разработки и вообще зачем нужно было стартовать новую, достаточно сложную разработку, и дать краткий обзор для дальнейшего развития темы. Ведь на рынке много всяких SCADA и MES систем, как открытых так и проприетарных, как отечественных так и иностранных, которые не сложно "достать" даже в современных условиях.
Нас мотивировало 3 ключевых идеи.
- Сделать современную отказоустойчивую платформу, способную выдерживать большие нагрузки. На современных технологиях, избавиться от всяких атавизмов.
- Сделать лучше других, даже лучше западных вендоров с огромной референтностью и ресурсными возможностями. И даже немного изменить саму концепцию автоматизации.
- Сделать пользовательский опыт лучше. Упростить разработку проектов автоматизации. Повысить скорость разработки. Снизить порог входа разработчика.
Предпосылки
В современных проектах АСУ ТП все привыкли программировать контроллеры (программно-логические, ПЛК), которые, в свою очередь, считаются центром отказоустойчивости. Такие ПЛК включают резервирование каналов связи, резервируемые вычислительные модули, и даже резервируемые каналы взаимодействия с модулями ввода-вывода (IO). Такой контроллер, как правило работает автономной или подключен к агрегационному шлюзу или сразу к серверу SCADA. В большинстве случаев, контроллер может работать автономно а SCADA необходима для сбора и анализа данных, возможно для подачи определенных команд. На большинстве объектов есть локальные пульты управления, которые позволяют обойтись, в случае необходимости, без SCADA.
Таким образом, считается что если SCADA "отвалится", ничего критического и не произойдет. Системы противоаварийной защиты (ПАЗ) так и работают, без SCADA а логика задается на ПЛК.
Возьмем АСУ ТП посложнее, где логика технологического процесса зависит от непрерывного надежного взаимодействия множества контроллеров. Такая логика может быть реализована с помощью, например распределенных систем управления (РСУ, DCS). РСУ, как правило обеспечивают высокую доступность, низкую задержку, гарантированную высокую производительность, и состоят из совокупности устройство одного вендора. И да, стоят как "чугунный мост". Объединение в одной АСУ ТП РСУ нескольких вендоров, так еще задача. А зависимость от ограниченного числа вендоров приводит к импортозамещению (доля шутки). Контроллеры, которые могут участвовать в РСУ, не только дорогие, но и сложные. Такие контроллеры требуют еще и сложного конфигурационного софта.
Сложность контроллеров, в том числе РСУ, основана на концепциях 50-ти летней давности. Тогда, когда многих из нас еще не было в проекте, линии связи были, так сказать ненадежные, со всеми задачами управления необходимо было справиться максимально локально. Мощность вычислительных узлов не позволяло агрегировать сложную логику, и она подвергалась децентрализации.
На дворе третье десятилетие 21 века. Современные технологии связи запредельно превосходны, на любой карман. Бери хоть 100GbE (а 1GbE вообще ничего не стоит), оптику, WiFi, 5G, используй для надежности все вместе. Доступ к любому конечному узлу можно организовать весьма эффективно, с резервированием, технологическим разнообразием и весьма недорого, даже в самых критических системах. Даже простейший встраиваемый процессор может обладает впечатляющей мощностью, достаточной для обработки любой сложной логики промышленной автоматизации.
Таким образом появились технологии интернета вещей (IoT), индустриального IoT (IIoT), где достаточно простое устройство взаимодействует с облаком и логика задается в облаке. Конечно, IIoT – это не про низколатентные высокопроизводительные системы, это игрушки для умного дома, не подходящие под серьезные проекты (хотя что только не встречается).
Возвращаясь к сложным ПЛК в современных условиях. Очень хочется вынести логику из ПЛК на обычные северы. А главное, что с помощью современных технологий – "можется". Конечно, всегда будет вопрос, что можно вынести на сервер, а что необходимо оставить на узле контроллера (рис. 1).
Рис. 01. Логика размещенная на ПЛК VS на серверах
В примере, на рис. 01, совокупность ПЛК обслуживают исполнительные механизмы. ПЛК сопряжены с серверами. ПЛК резервированы, каналы связи резервированы. Таким образом предполагается, что надежность системы будет необходимо высокой. Необходима большая надежность, пожалуйста (рис. 02). Может отказать хоть половина всего оборудования, что крайне маловероятно (рис. 03).
Рис. 02. Распределенная логика, дополнительные резервные устройства, каналы
Рис. 03. Распределенная логика, множественные отказы оборудования
Для управления такой архитектурой требуется эффективная среда управления. Таковой является наша платформа.
Обратите внимание, что во всех трех примерах серверы объедененны изолированным, резервируемым интерконнектом. Данный интерконнект предназначен для обслуживания синхронизации корневых (root) узлов. Под корневыми узлами следует понимать узлы, с общей распределенной вычислительной средой. Такая среда по сути является некоторой формой реализации РСУ, которая обеспечивают всю "магию".
Устройство корневого узла
Корневой узел представляет собой совокупность сервисов, реализующих следующий функционал (рис. 04):
- Сервис СУБД реального времени. Обеспечивает хранение данных реального времени (переменные, модели, объекты, события) и кэш.
- Сервис метаданных. Обслуживает данные, которые нет необходимости обрабатывтаь в режиме РВ.
- Сервис архива. Обслуживает архивные данные в формате временных рядов.
- Логические сервисы. Обслуживает узловую логику, реализует событийно-управляемую архитектуру, и обработку проектных сценариев (алгоритмов).
- Сервис обслуживания драйверов. Обслуживания экземпляров драйверов.
- Сервисы драйверов. Реализация определенного протокола, например сейчас доступны OPC UA, MQTT, Modbus, BACnet, IEC 60870, IEC 61850, Profinet (S7comm), SNMP, Zabbix и др.
- Сервис API (REST, WebSocket). Обслуживание API сервисов. UI (HMI) доступен по WS, некоторые сервисы взаимодействуют с узлом по REST API.
Рис. 04. Архитектура сервисов корневого узла
Интерконнект и синхронизация узлов
В проекте может быть множество таких узлов, десятки, если необходимо то сотни. Интерконнект объединяет такие узлы и обеспечивает их синхронизацию. Поддержка актуальности узловых данных осуществляется путем синхронизации узловых кэшей. В Платформе реализована поддержка гарантии когерентности узловых кэшей, что позволяет узлам РСУ работать в режиме Active-Active.
На приличном оборудования синхронизация работает с эффективностью до нескольких десятков млн. изменений в сек на всю систему. Доступна асинхронная репликация для передачи данных за пределы АСУ ТП в различные внешние ситуационные, кризисные центры и прочие информационные системы с более высокой задержкой.
Клиенты и прочие узлы могут поддерживать соединения с несколькими корневыми узлами, что обеспечивает мгновенное переключение на другой доступный корневой узел. При таком переключение не теряются данные и не снижается задержки. При определенной логики, проектные алгоритмы можно задать так, чтобы при переключении корневых узлов, алгоритм продолжал свое выполнение на другом узле с места завершения на отказавшем узле.
Структура данных платформы: модели и объекты
Структура данных платформы устроена достаточно просто. Основным элементом являются модели. Это абстрактный составной элемент, который состоит из простейших моделей (Boolean, Integer, Float, String, Directory и др., рис. 05).
Рис. 05. Абстрактные модели
Модель может быть сколь угодно сложной. С помощью вложенных подмоделей можно структурировать сколь угодно сложный объект автоматизации. Например, можно описать объекты отдельного оборудования или логическую структуру сложной мнемосхемы (рис. 06).
Рис. 06. Модель клапана
Из примера видно, что к абстрактной модели может быть привязан набор визуальных элементов, который будет отражен на мнемосхеме.
Объект описывает реальное оборудование или сущность на основе абстрактной модели. При изменении структуры модели, все связанные объекты подвергнутся каскадному резонансу изменению. Это полезно, когда к вам приехало десяток новых насосов и у них слегка изменилось число параметров, то не придется не только менять каждый по отдельности объект но и на всех мнемосхемах элемент меняется (рис. 07).
Рис. 07. Объекты и параметры
Переменные объекта могут быть привязаны к разным платформенным сервисам (рис. 08).
Рис. 08. Привязка переменных объекта
Переменная объекта может быть привязана к переменным драйвера (рис. 09).
Рис. 09. Привязка драйвера
Переменная объекта может быть привязана к сервису имитатора (рис. 10). Доступны различные функции имитации, синусоида, пила, меандр и др. Крайне удобно для отладки проектов и для диагностики каналов.
Рис. 10. Привязка имитатора
Переменная объекта может быть привязана к сервису калькулятора (рис. 11).
Рис. 11. Привязка калькулятора
Событийная модель
Платформа обладает мощным аппаратом, основанным на событийно-ориентированной архитектуре. Событие может наступить по условию, заданному в калькуляторе. Например, событие может возникнуть при достижении значение переменной заданной уставки (рис. 11). Событийная переменная всегда имеет булевый тип, таким образом может быть определен статус активности события (EDA, рис. 12).
Рис. 12. Статусы событий
Все классы событий могут быть заданы в специальном редакторе (рис. 13). Классы событий могу иметь значения приоритета, которое важно при оперативном реагировании. Также класс события может включать фактор необходимости квитирования (будет "орать" сигнализация, пока оператор не подтвердит, что увидел).
Рис. 13. Классы событий
Все события выводятся в специальный интерфейс представления событий и тревог (рис. 14). В целевом проекте визуальное представления событий может быть сделано по требованию заказчика.
Рис. 14. Тревоги, события
Пользовательский интерфейс: UI, HMI
Важнейшая тема для оперативного и диспетчерского управления является визуализации данных и работе с элементами управления.
Настоящей проблемой абсолютно всех SCАDA в том, что в них встроены убогие векторные редакторы. Ни один разработчик SCADA не сделать векторный редактор лучше Figma, Pixco, CorelDraw, Adobe Illustrator, Inkscape и др. Встроенный редактор – это хорошо для того, чтобы что-нибудь "подшаманить". Большинство мнемосхем в доступных системах это "колхоз", хоть и выполняющий свой функционал.
В современных системах можно использовать всю мощь доступных на рынке векторных редакторов. Идея UI Лацерты, чтобы любой разработчик начального уровня с рынка мог разработать и запрограммировать мнемосхему. Мы предлагаем новаторский подход. Разработчик может использовать любой редактор для отрисовки мнемосхем и их типовых элементов.
Для Лацерты мнемосхема – это микроприложение, интерфейс которого рисуется в векторе, а программируется уже средствами платформы (рис. 15)
Рис. 15. Внешний векторный редактор
С некоторыми редакторами Лацерта сопрягается и умеет синхронизировать содержимое проектов. Такая опция обеспечивает не только удобство сопряжения мощности внешнего редактора но и обеспечивает возможность коллаборативной работы.
Мнемосхемы состоят из компонентов (рис. 16, те самые с рис. 05, 06).
Рис. 16. Визуальные компоненты мнемосхем
Каждый компонент может быть привязан к абстрактными моделям (рис. 17)
Рис. 17. Настройка компонента
Компоненты программируются средствами Платформами, с помощью встроенного языка TypeScript (рис. 18)
Рис. 18. Программирование компонента
Таким образом, разработкой мнемосхем может заниматься даже обычный web-разработчик или разработчик мобильных приложений, при наличии технического задания. Хватай с рынка любого и дай кодить мнемосхемы.
Сами мнемосхемы могут быть сколь угодно сложными (рис. 19, 20, 21).
Рис. 19. Мнемосхема – Турбина
Рис. 20. Мнемосхема – ЦОД
Рис. 21. Показометры
Лацерта содержит инструменты анализа данных, такие как тренды различного типа (рис. 22), табличные формы вывода. Доступен экспорт данных в табличном формате.
Рис. 22. Тренды
Сопряжения
Разработчики получили огромный опыт в сопряжении Платформы Лацерта с различными внешними системами (рис. 23).
Рис. 23. Платформенные сопряжения
Заключение
Лацерта развилась в весьма мощную платформу автоматизации. С помощью Лацерты можно решать широкий класс задач промышленной автоматизации и диспетчеризации.
Мне кажется нам удалось сделать что-то качественно новое. И немного сместить акцент в принципах разработки таких систем.
Если спросите, удалось ли нам сделать что-то лучше. Конечно я отвечу, что да. Для каждого разработчика, его "детище" всегда самое лучшее. Поэтому судите строго как можете, все равно не сможете строже, чем заказчик за деньги =)
PS. Если кому интересно, видео с демонстрашкой доступно тут.
PPS.
О многих архитектурных и решениях принципах, применяющих в разработке Платформ Лацерта можно прочитать в моей книге "Архитектура Высоконагруженных Систем"