Как построить открытую АСУТП. IEC 61499 — основа открытой автоматизации будущего

Добрый день! Меня зовут Татьяна Пчельникова, и я — владелец продукта в ИТ-команде «Северстали», занимающейся разработкой компонентов для открытой АСУТП. В марте этого года мы начали выпуск статей, посвящённых нашей разработке компонентов открытой АСУТП, с первой статьёй этого цикла можно ознакомиться здесь: Как построить открытую АСУТП. Рождение идеи открытых систем: почему мир движется в этом направлении / Хабр. Мы внимательно прочитали все комментарии к прошлой статье и хотим отметить, что тема вызвала большой интерес и горячие споры, а значит, направление — актуальное, и  мы продолжим цикл публикаций. 

Чтобы не было разночтений, давайте дадим определение открытой АСУТП. Открытая АСУТП — это система, построенная на принципах модульности, совместимости и взаимозаменяемости компонентов. Она позволяет гибко использовать элементы от разных производителей, являясь независимой от конкретного поставщика, и обеспечивает простую интеграцию с другими системами посредством реализации международных стандартных протоколов и интерфейсов. Эти характеристики позволяют открытой АСУТП масштабироваться как горизонтально, так и вертикально, что делает её перспективной для промышленного применения. «Северсталь» делает два компонента: открытый программный ПЛК (среду исполнения) и открытую среду разработки. Открытая SCADA, интересующая комментирующих, тоже разрабатывается, но другими участниками, входящими в рабочую группу открытой АСУТП.  

В данной статье мы поделимся информацией о том, что содержит управляющая программа для открытого программного ПЛК, базирующаяся на стандарте IEC 61499, и как она обрабатывается в среде исполнения. 

1. Функциональные блоки (ФБ)

Итак, начнём с фундамента, с функциональных блоков (ФБ), которые в стандарте 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 

Работа с ресурсами и ФБ включает выполнение следующих операций:

• получение списка ФБ;

• создание ресурса;

• Для ресурса. Создание ФБ;

• Для ресурса. Задание значения входа ФБ;

• Для ресурса. Создание связи;

• Для ресурса. Запуск ресурса.

 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..