Добрый день! Меня зовут Татьяна Пчельникова, и я — владелец продукта в ИТ-команде «Северстали», занимающейся разработкой компонентов для открытой АСУТП. В марте этого года мы начали выпуск статей, посвящённых нашей разработке компонентов открытой АСУТП, с первой статьёй этого цикла можно ознакомиться здесь: Как построить открытую АСУТП. Рождение идеи открытых систем: почему мир движется в этом направлении / Хабр. Мы внимательно прочитали все комментарии к прошлой статье и хотим отметить, что тема вызвала большой интерес и горячие споры, а значит, направление — актуальное, и мы продолжим цикл публикаций.
Чтобы не было разночтений, давайте дадим определение открытой АСУТП. Открытая АСУТП — это система, построенная на принципах модульности, совместимости и взаимозаменяемости компонентов. Она позволяет гибко использовать элементы от разных производителей, являясь независимой от конкретного поставщика, и обеспечивает простую интеграцию с другими системами посредством реализации международных стандартных протоколов и интерфейсов. Эти характеристики позволяют открытой АСУТП масштабироваться как горизонтально, так и вертикально, что делает её перспективной для промышленного применения. «Северсталь» делает два компонента: открытый программный ПЛК (среду исполнения) и открытую среду разработки. Открытая SCADA, интересующая комментирующих, тоже разрабатывается, но другими участниками, входящими в рабочую группу открытой АСУТП.
В данной статье мы поделимся информацией о том, что содержит управляющая программа для открытого программного ПЛК, базирующаяся на стандарте IEC 61499, и как она обрабатывается в среде исполнения.
Функциональные блоки (ФБ)
Итак, начнём с фундамента, с функциональных блоков (ФБ), которые в стандарте IEC 61499 имеют следующий вид:
Функциональные блоки делятся на три основных типа:
Базовые функциональные блоки (BFB – Basic Function Block)
Используют диаграмму управления выполнением (ECC – Execution Control Chart), аналогичную конечному автомату (UML-диаграмме состояний). Каждое состояние может содержать действия, связанные с алгоритмами и событиями.
Особенности:
управляются событиями (например, входное событие REQ запускает обработку данных), что отличается от стандарта IEC 61131-3, где исполнение ФБ осуществляется постоянно в цикле опроса;
выходные события (например, CNF) сигнализируют о завершении вычислений;
алгоритмы могут быть реализованы на языках, совместимых с IEC 61131-3 (например, ST, FBD).
Составные функциональные блоки (CFB – Composite Function Block)
Создаются как сети из других ФБ (BFB, SIFB или даже CFB), соединённых через события и данные.
Особенности:
не имеют собственной логики — поведение определяется внутренней структурой подключенных блоков;
позволяют инкапсулировать сложную логику в модули для повторного использования;
не поддерживают распределение между устройствами (в отличие от подприложений).
Интерфейсные сервисные блоки (SIFB – Service Interface Function Block):
Скрывают реализацию, предоставляя только описание поведения через сервисные последовательности (например, для взаимодействия с аппаратурой или внешними системами).
Особенности:
используются для коммуникации (например, Modbus, OPC UA), управления устройствами или доступа к операционной системе;
не имеют ECC — их логика описывается на уровне сервисов (например, «отправить запрос → получить ответ»);
примеры: блоки для публикации/подписки (PUB/SUB), клиент-серверного взаимодействия.
Интерфейс ФБ описывается в файле с расширением *.fbt и содержит:
название типа ФБ;
перечень входов событий и данных;
перечень выходов событий и данных.
Дополнительно в *.fbt файле могут содержаться: спецификация конечного автомата ФБ (ECC), код методов ФБ на языке ST, декларации внутренних переменных и начальных значения входов данных и внутренних переменных. Если выполнять требования стандарта IEC 61499, то любой ФБ, разработанный пользователем в открытой среде разработки, может быть перенесён в другую открытую среду разработки и исполнен без потери функций.
Существуют различные модели выполнения ФБ:
непрерывный многопотоковый ресурс (NPMTR-модель);
прерываемый многопотоковый ресурс (PMTR-модель).
4daic forte реализует PMTR-модель. После завершения обработки события ФБ текущее входное событие удаляется и порождается выходное событие. Событие, порождаемое ФБ, помещается в конец очереди событий ресурса. Каждое событие содержит ссылку на ФБ, который должен его обрабатывать. Ресурс извлекает из головы очереди событий новое событие и начинает выполнение связанного с ним ФБ. В результате порядок обработки ФБ напоминает волну обработки.
Среда исполнения 4diac forte содержит скомпилированные реализации блоков стандартной библиотеки в виде кода С++ классов (каждому типу ФБ соответствует С++ класс). Среда исполнения при старте может загрузить программу для исполнения из загрузочного файла. Загрузочный файл содержит команды конфигурирования для:
создания ресурсов;
создания ФБ;
создания связей данных;
создания связей событий;
задания начальных значений входов данных.
2. Библиотека
ФБ, как стандартные, так и пользовательские, могут быть добавлены в библиотеку. В стандарте IEC61499 и среде 4diac, библиотека представляет собой коллекцию ФБ, которые можно использовать для разработки распределенных систем управления. Эти блоки инкапсулируют определенные функции и могут быть легко интегрированы в приложения для создания сложных систем управления. В библиотеке могут быть различные блоки, которые обеспечивают широкий спектр возможностей, от работы с файлами до решения задач технического зрения. Библиотека позволяет повторно использовать ФБ в различных приложениях, что упрощает разработку и поддержку систем управления. ФБ, входящие в библиотеку, могут храниться в репозиториях и могут импортироваться и экспортироваться в текстовом синтаксисе или в синтаксисе XML, определенном в IEC 61499-2. Такие объекты имеют атрибуты поставщика (vendor, programmer и т.д.) и версии (номер версии, дата и т.д.), которые помогают в управлении, в дополнение к имени в качестве ключевого атрибута. Стандарт IEC 61499 дает возможность создавать пользовательские ФБ, которые могут включать в себя уже существующие в библиотеке ФБ.
Как стандартные так и вновь созданные ФБ поддерживают:
экспорт в С++ код, включение его в проект FORTE и собственную/специализированную «сборку» версии FORTE.
динамическую загрузку ФБ в виде Lua кода. Динамическая загрузка в виде Lua кода не требует экспорта и выполняется на этапе развертывания приложения. При этом, инструкция по созданию ФБ, передаваемая от 4diac IDE в FORTE, содержит Lua скрипт, сгенерированный для этого ФБ. Увидеть содержимое скрипта можно выполнив экспорт блока в виде Lua кода.
В 4diac IDE библиотека содержит ФБ для выполнения базовых операций и обеспечивает реализацию следующих возможностей:
преобразования типов;
обработки событий;
предоставления функций аналогичных IEC 61131 (арифметические операции, триггеры, битовые операции, строковые операции, операции сравнения, преобразования типа, счетчики, математические операции, операции выбора, операции с таймерами);
поддержки работы с платами локального ввода-вывода;
поддержки работы с промышленными шинами;
поддержки реконфигурирования;
работы с событиями реального времени;
использования утилит ввода-вывода.
3. Приложение
Далее, из ФБ собирается приложение. Приложение — это программно-функциональная единица, состоящая из ФБ (Applicatioin — software functional unit that is specific to the solution of a problem in industrial-process measurement and control) и предназначенная для решения задач измерения и управления промышленными процессами. Приложение может быть распределено по ресурсам и взаимодействовать с другими приложениями, что является основным отличием стандарта IEC 61499 от IEC 61131 и позволяет реализовывать распределенное приложение в АСУТП. В стандарте IEC 61131 приложение выполняется только на одном ресурсе.
Например, приложение может состоять из одного или нескольких контуров управления, в которых выборка входных данных выполняется в одном ресурсе (устройстве), обработка управления выполняется — в другом, а преобразование выходных данных — в третьем.
4. Ресурс
Сразу внесем ясность, что такое ресурс. В контексте стандарта IEC61499 и среды 4diac, ресурс (Resource) определяется как функциональная единица, имеющая независимое управление своей работой. Она обеспечивает различные сервисы для приложений, включая планирование и выполнение алгоритмов. Ресурсы могут быть частью устройств и обеспечивают выполнение ФБ, которые являются основными элементами распределенных систем управления.
В реализации 4diac forte ресурс содержит один поток обработки и независимую очередь событий. Поток обработки событий реализуется в классе CEventChainExecutionThread. При старте системы устройство по команде START запускает все содержащиеся в нем ресурсы.
Последовательность вызова методов при команде START в 4diac forte показана на рисунке ниже:
5. Управляющая программа
Для создания управляющей программы в 4diac IDE создаётся проект, который включает в себя одно или несколько приложений (application в терминах IEC 61499), информацию об устройствах (вычислительных узлах, на которых может быть развернута программа и сетевых соединениях между ними), и о стандартных и новых (например, созданных пользователем) ФБ, которые используются в приложении.
В IEC 61131-3 так сделать не получится, т.к. управляющая программа работает на одном ПЛК (ресурсе). Поэтому и был разработан новый стандарт, который позволит строить распределенные приложения.
Управляющая программа (проект) в 4diac IDE сохраняется в виде файла с расширением *.sys. Файл проекта записывает в xml-формате следующую информацию:
спецификацию графа ФБ (перечень используемых ФБ, связи данных и событий между ними);
спецификацию устройств;
информацию о назначении ФБ на устройства.
К сожалению, формат не совместим с PLCOpenXML, и это нам нужно будет изменить.
Среда разработки 4diac IDE взаимодействует со средой исполнения forte через запрос-ответ по протоколу на основе tcp с сообщениями, оформленными в при помощи XML. Инициатором запросов является IDE.
Протокол позволяет выполнять следующие операции:
загрузка и запуск приложения (работа с ресурсами и ФБ);
отладка приложения (чтение значений входов и выходов ФБ, запись («форсирование») входов и выходов ФБ и событий).
Обобщенный формат команд:
0x50 [Длина имени ресурса 2 байта ][Имя ресурса] 0x50 [XML length 2 байта] < Тело команды />
Допустимые значения поля Action: CREATE, DELETE, START, STOP, READ, WRITE, KILL, QUERY, RESET.
Обобщенный формат ответа в случае успешного выполнения команды:
0x50 [Длина тела XML сообщения - 2 байта]
Обобщенный формат ответа в случае неуспешного выполнения команды
0x50 [XML length 2 байта]
Таблица перечня основных команд, используемых в 4diac
cmd | object | result |
START | APPLICATION | Запуск приложения. |
STOP | APPLICATION | Остановка приложения. |
KILL | APPLICATION | Принудительное завершение приложения. |
QUERY | APPLICATION | Проверка состояния приложения. |
CREATE | RESOURCE | Создание ресурса в устройстве. |
DELETE | RESOURCE | Удаление ресурса. |
START | RESOURCE | Запуск ресурса. |
STOP | RESOURCE | Остановка ресурса. |
READ | VARIABLE | Чтение значения переменной. |
WRITE | VARIABLE | Запись значения в переменную. |
CREATE_CONNECTION | CONNECTION | Создание соединения между блоками. |
DELETE_CONNECTION | CONNECTION | Удаление соединения. |
UPLOAD | TYPE_LIBRARY | Загрузка библиотеки типов. |
DOWNLOAD | DEVICE | Загрузка конфигурации на устройство. |
Работа с ресурсами и ФБ включает выполнение следующих операций:
получение списка ФБ;
создание ресурса;
Для ресурса. Создание ФБ;
Для ресурса. Задание значения входа ФБ;
Для ресурса. Создание связи;
Для ресурса. Запуск ресурса.
6. Загрузка приложения в среду исполнения
После того, как создана управляющая программа, она загружается в среду исполнения в определенной последовательности.
Как видно из таблицы доступных команд и из диаграммы последовательности, передача проекта, по сути — это передача команд. IEC 61499 и 4diac IDE, в частности, поддерживают добавление в уже исполняемую программу нового экземпляра ФБ, связей и запуска его исполнения, что даёт возможность дополнять программу новыми ФБ (доступными в среде исполнения) без остановки уже выполняемого алгоритма и его рестарта.
7. Отладка
И, конечно, далее идет всеми любимый процесс отладки. Среда разработки 4diac IDE позволяет для отладочных целей выполнять просмотр значений входов и выходов ФБ, просмотр числа сгенерированных событий, изменение значений входов и выходов данных, генерацию событий. Для реализации этой функциональности в процессе отладки могут выполняться следующие операции:
декларация наблюдаемых переменных (входов и выходов ФБ) для просмотра (CREATE);
запрос на чтение (READ) значений наблюдаемых переменных (входов и выходов ФБ) для просмотра;
запрос на изменение значения переменной.
Стандарт IEC 61499 определяет модель выполнения распределённой системы управления в терминах взаимодействующих ФБ, которые не сильно отличаются от привычных многим ФБ в IEC 61131. Основное отличие заключается в наличие входов и выходов для событий. Алгоритм, выполняемый ФБ, может быть разработан на FBD, ST, а также на C++.
8. Что мы уже доработали и включили в первый релиз
Для взаимодействия среды исполнения forte с полевыми протоколами была реализована шина данных и добавлены новые функциональные блоки в библиотеку 4diacIDE. Для взаимодействия плагинов протоколов через шину данных со средой исполнения нами был добавлен интерфейс CAPI (C Application Programming Interface), используя который в дальнейшем можно добавлять новые протоколы или получать данные полевых протоколов для обработки. В первом релизе мы разработали плагины для следующих полевых протоколов, которые работают независимо от ядра исполнения:
протокол Modbus RTU мастера (MBUSPlugin),
протокол Modbus TCP мастера (MBUSPlugin),
протокол Modbus RTU slave (MBUSPlugin),
протокол Modbus TCP slave (MBUSPlugin),
протокол MQTT (MQTTPlugin).
Рассмотрим наши доработки на примере ФБ, реализующего опрос устройств по протоколу Modbus:
Инициализация происходит по приходу события MAP. В момент прихода события MAP вход QI должен быть установлен в true. Для реконфигурирования количества подключаемых элементов достаточно переименовать элемент MBUS, и редактором типа элемента добавить нужное количество IO входов. Название блока должно иметь вид MBUS_n comment, например, MBUS8_rtu, где n - максимальное количество входов-выходов. Для работы в поле PARAM необходимо задать параметры Modbus RTU или Modbus TCP соединения в JSON формате. Пример строки PARAM для работы с Modbus RTU:
'{"id":1, "device":"/dev/ttyS0", "baud":9600, "bps":"8N1","update":"500ms"}'
Ранее для того, чтобы в 4diacIDE реализовать такой же опрос, необходимо было предварительно скачать, скомпилировать библиотеку libmodbus на целевом устройстве, а затем, используя стандартный функциональный блок CLIENT, правильно задать параметры работ блока. Также нужно скомпилировать черeз cmake и сам Forte, указав путь к скомпилированной библиотеке libmodbus. Сам ФБ в этой библиотеке выглядит вот так:
А в поле ID требуется задать параметры работы ФБ в следующем виде:
modbus[protocol:port:baudrate:parity:databits:stopbits:flow:(slaveId):pollFrequency:readAddresses:sendAddresses(:responseTimeout:byteTimeout)]
modbus[rtu:/dev/ttyS0:19200:N:8:1::1:2000:i6142,i6132,i6137:h64025..64028,h63995..63998]
Как видно, ФБ создан из уже существующего стандартного блока, выделенного типа ФБ для Modbus нет. Задание адреса не очевидно для конкретного устройства, также еще стоит проблема маппинга переменных и задания нужного типа переменной.
Подобные упрощения для пользователя были сделаны и для передачи значения переменной в OPC UA сервер, об этом тоже расскажем, но чуть позже.
Итог
Гибкость, переносимость и расширяемость — ключевые преимущества открытого подхода на IEC 61499.
Открытый программный ПЛК и среда разработки на базе IEC 61499 поддерживают:
распределение кода между устройствами — буквально в два клика,
переносимость проектов между разными средами,
динамическое обновление — добавление функциональных блоков «на лету».
Наши доработки:
поддержка новых протоколов через CAPI (включая сторонние плагины),
упрощение разработки пользовательских прикладных программ для опроса полевых шин.
P.s. В следующих публикациях в серии статей по разработке открытого программного ПЛК будут рассмотрены такие темы: архитектура программного ПЛК; разработка и использование ФБ устройств ввода/вывода (на примере модулей ввода/вывода Овен); подключение плагинов проприетарных шин (на примере шины МЗТА); подключение коммуникационного протокола (на примере Modbus или OPC UA) и еще много интересного.
Наше решение будет иметь открытый исходный код и мы приглашаем разработчиков и вендоров к совместной работе над развитием программного ПЛК (open.soft.plc@severstal.com).
to be continued..
