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

Статья №1: Как построить открытую АСУТП. Рождение идеи открытых систем: почему мир движется в этом направлении.

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

В них мы рассказали о выборе инструмента для создания открытой АСУ ТП и принципах работы приложения с использованием стандарта IEC 61499.

В данной статье рассмотрим архитектуру программного программируемого логического контроллера (ПЛК), а также самостоятельную сборку среды исполнения из исходников и запуск её из готовых сборок. Самостоятельную сборку опишем на примере российского одноплатного компьютера Repka-pi, имеющего архитектуру aarch64.

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

Архитектура

Наш программный ПЛК мы создаём, взяв за основу продукт Eclipse 4diac-forte, внося в него необходимые изменения и дорабатывая его до наших требований. На данный момент мы добавили следующую функциональность: 

  • функциональные блоки (ФБ) и классы для IO подсистемы для работы с Modbus RTU Master;

  • функциональные блоки и классы для IO подсистемы для работы с адаптером протоколов Modbus RTU Slave;

  • функциональные блоки и классы для IO подсистемы для работы с адаптером протоколов Modbus TCP Master;

  • функциональные блоки и классы для IO подсистемы для работы с адаптером протоколов Modbus TCP Slave;

  • библиотек для работы с CAPI;

  • сетевой слой для работы с адаптером протоколов для MQTT;

  • функциональные блоки и классы для IO подсистемы для работы с адаптером протоколов OPC UA Client;

  • OPC UA сервер.

Укрупнённая схема взаимодействия среды разработки и среды исполнения приведена на рисунке 1.

Рис. 1. Схема взаимодействия среды разработки и среды исполнения
Рис. 1. Схема взаимодействия среды разработки и среды исполнения

Как мы видим, среда исполнения состоит из набора сервисов, каждый из которых выполняет свою задачу:

  • ядро исполнения, основанное на forte, занимается исполнением кода пользовательских программ;

  • плагины протоколов реализуют работу протоколов связи;

  • шина данных связывает ядро исполнения с плагинами протоколов, позволяя при этом добавлять другие плагины, которые будут использовать данные из этой шины. Библиотека адаптера шины CAPI использует в основании протокол eCAL.

В настоящий момент мы тестируем работу программного ПЛК с использованием разделяемой памяти (shared memory), но также eCAL позволяет работать и через UDP и TCP, что даёт нам возможность выделить каждый сервис в отдельный контейнер и связать их через CAPI.

Каждый из адаптеров протоколов включает в себя следующие компоненты:

  • функциональный блок (используется IDE) с корректным набором соединений, соответствующих программному описанию блока;

  • программное описание функционального блока, который обеспечивает получение данных от IDE и функционирование forte, включает: события управления блоком, события на выходе блока, входные статусы, параметры и данные, выходные статусы и данные;

  • контроллер адаптера, который определяет функционирование блока и обеспечивает связь с плагином протокола;

  • плагин, который непосредственно работает с требуемым протоколом, обеспечивает приём и отправку на шину данных, обмен с контроллером в forte.

Взаимодействие компонентов можно представить следующей схемой (рис.2):

Рис. 2. Схема взаимодействия компонентов
Рис. 2. Схема взаимодействия компонентов

Конфигурационный файл plugins_cfg.xml содержит перечень плагинов, которые должны быть запущены при старте forte:

<CAPI>
  <Timeout>5000</Timeout>
  <Plugins>
    <Plugin Id="MBUS" Mode="protobuf"><Command>./MBUSPlugin</Command></Plugin>
    <Plugin Id="MSLAVE" Mode="protobuf"><Command>./MSLAVEPlugin</Command></Plugin>
    <Plugin Id="mqtt" Mode="protobuf"><Command>./MQTTPlugin</Command></Plugin>
    <Plugin Id="OPCUAC" Mode="protobuf"><Command>./plugin_opcua</Command></Plugin>
  </Plugins>
</CAPI>

Для взаимодействия среды исполнения с полевыми протоколами предполагается использовать выделенные программы адаптеров полевых протоколов.
Плагины протоколов взаимодействуют со средой исполнения через интерфейс CAPI.
Реализуются следующие полевые протоколы:

  • протокол Modbus RTU мастера (MBUSPlugin);

  • протокол Modbus TCP мастера (MBUSPlugin);

  • протокол Modbus RTU slave (MBUSPlugin);

  • протокол Modbus TCP slave (MBUSPlugin);

  • протокол MQTT (MQTTPlugin);

  • протокол OPCUA client (plugin_opcua);

  • протокол шины ПЛК-вендора (сейчас в работе).

Для работы с протоколами Modbus RTU мастера и Modbus TCP мастера в 4daic предназначены блоки MBUS в среде MSLAVE базирующиеся на CAPI плагинах.

Блоки MBUS и MSLAVE предназначены для работы forte в качестве мастера или ведомого устройства на Modbus TCP/RTU шине.

Реализация данных блоков представлена обобщёнными GEN_MBUS и GEN_MSLAVE функциональными блоками, что предполагает возможность динамического переопределения количества и типов IO-блоков типа Ix/Qx. Несколько идентичных функциональных блоков работают с собственной копией контроллера, но с одним общим плагином (рис.3):

Рис. 3. Работа с плагином
Рис. 3. Работа с плагином

Демонстрация работы среды исполнения

Давайте удостоверимся, что выбранная архитектура соответствует заложенным принципам, и убедимся, что среда исполнения справляется с поставленными задачами. Для этого используем разработанный нами пример приложения чуть посложнее, чем набивший всем оскомину пример «Hello World!». Приложение будет отправлять MQTT брокеру значение с инкрементного счётчика и считывать с MQTT брокера назад для сравнения. При достижении счётчиком значения «20» отдавать переменную на брокер и забирать обратно для сбрасывания счётчика.

Данный протокол выбрали для того, чтобы показать работу плагина с шиной данных без сложной предварительной подготовки. В качестве mqtt брокера был использован сервис «синий трактор», готовая инфраструктура для автоматизации обработки данных. В примере мы получим и отправим данные, имитируя обмен данными между оборудованием по mqtt протоколу. 

Для проверки нам понадобятся:

Запуск среды исполнения 

Предусмотрено два варианта запуска среды исполнения:

  • первый, сложный — собрать самим среду исполнения из исходников, этот вариант опишу ниже, в пункте «Сборка среды исполнения из исходных кодов»;  

  • второй — использовать уже готовые сборки под архитектуры x86-64, arm и aarch64. 

Скачиваем готовую сборку с исполняемыми файлами под архитектуры x86-64, arm или aarch64 тут. Распаковываем и запускаем среду исполнения из терминала командой:

./forte -ac plugins_cfg.xml

После того, как запустили среду исполнения посмотрим, как работает наше приложение.  

Для этого открываем проект в среде разработки. Загружаем приложение на устройство, а затем мониторим его в онлайн-режиме, для этого нажимаем кнопку в верхнем меню с пиктограммой «жука».

Выполняется отправка приложения в среду исполнения и переход в режим онлайн-отладки (рис. 4).

Удостоверяемся в том, что приложение исполняется и данные поступают (если нет подсветки на входах, можно нажать на ФБ правой кнопкой мыши и из выпадающего меню выбрать «Toggle watch»).

Рис.4 Выполнение приложения онлайн
Рис.4 Выполнение приложения онлайн

В итоге видим, как наше приложение выполняется в среде исполнения: данные по плагин протоколу mqtt успешно переданы и записаны.

Подробная инструкция о том, как работать с проектом в среде разработки, размещена в  репозитории проекта.

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

Сборка среды исполнения из исходных кодов

Скачать исходные коды среды исполнения для самостоятельной сборки из исходников можно здесь.

Процесс сборки выглядит следующим образом:

Шаг 1.

Копируем на repka-pi архив репозитория исходных кодов для самостоятельной сборки и распаковываем его.

Шаг 2.

Устанавливаем инструменты для сборки. Для этого вызываем терминал и в командной строке пишем (предварительно sudo должен быть установлен):

sudo apt-get install build-essential git cmake g++

Далее устанавливаем необходимые библиотеки:

sudo apt-get install libpaho-mqtt-dev libmodbus-dev libhdf5-dev libyaml-cpp-dev libpugixml-dev rapidjson-dev libxml2-dev 
sudo apt-get install nlohmann-json3-dev libssl-dev

Запускаем скрипт для компиляции дополнительных библиотек. Скрипт расположен в директории, в которую был распакован архив репозитория:

./prepare_libs.sh

После того, как всё собралось, запускаем скрипт setup_flogic.sh:

./setup_flogic.sh

Шаг 3.

Переходим в директорию bin/posix и вводим команду make:

cd bin/posix
make

Ждём завершения компиляции.

В результате собранные файлы должны находиться в следующих директориях:

   bin/posix/src/forte   
   bin/posix/plugins/MBUSPlugin   
   bin/posix/plugins/MQTTPlugin   
   bin/posix/plugins/MSLAVEPlugin   
   bin/posix/plugins/plugin_opcua

Для удобства все файлы можно собрать в одной директории. Например, testrun.

Шаг 4.

Скачиваем и размещаем в этой же директории (testrun) файлы ecal.ini и plugins_cfg.xml. Затем указываем путь к дополнительным библиотекам в LD_LIBRARY_PATH, выполнив эти команды в терминале (путь должен быть указан для вашей папки 4diac-forte):

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/4diac-forte/fl_ext_libs/lib/ecal_build/lib 
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/4diac-forte/fl_ext_libs/lib/open62541_build/lib

Шаг 5. 

Запускаем среду исполнения командой:

./forte -ac plugins_cfg.xml

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

Шаг 6.

Для удобства запуска Forte, собранного из исполняемых исходников, можно сделать скрипт, который выполнит указанные команды и запустит среду исполнения. Назовем скрипт runf.sh, внутри скрипта запишем следующие команды:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/4diac-forte/fl_ext_libs/lib/ecal_build/lib 
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/4diac-forte/fl_ext_libs/lib/open62541_build/lib
./forte -ac plugins_cfg.xml

Шаг 7.

После создания скрипта среда исполнения запускается командой:

./runf.sh

Ссылки на наши продукты, доступные для скачивания, собрали ниже.

Ссылки для скачивания

Среда разработки (IDE). Исходники с вносимыми изменениями в IDE будем выкладывать по мере готовности.

Готовая сборка среды исполнения под архитектуры x86-64, arm или aarch64.

Исходные коды среды исполнения для самостоятельной сборки.

Также мы опубликовали в репозитории исходный код и конструкторскую документацию на плату Profibus master на базе микроконтроллера MIK32 Амур. Скачать исходный код можно здесь.

P.S. 

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

  • разработчиков,

  • вендоров,

  • интеграторов,

  • преподавателей и студентов вузов

для написания своих библиотек и компонентов, используемых при решении практических задач.

Пишите на почту open.soft.plc@severstal.com 

В следующих публикациях в серии статей по разработке открытого программного ПЛК мы рассмотрим такие темы: разработку и использование ФБ-устройств ввода/вывода (на примере модулей ввода/вывода Modbus TCP); подключение плагинов проприетарных шин и ещё много интересного. 

to be continued..

Комментарии (2)


  1. DanilaX
    01.08.2025 05:54

    Подскажите к вашему виртуальному плк можно будет подключать периферию профибас? И какую Ос вы будете использовать для реализации реалтайма. Будет ли возможность применение вашего программного плк для прокатного стана ?


    1. Ivan_80 Автор
      01.08.2025 05:54

      1) Мы начали реализацию протокола ProfiBUS начав с реализации на АМУР-32, конвертировав его в Modbus RTU. На ЦИПР наш программный ПЛК управлял двумя слейвами ProfiBUS через коммуникационный процессор на чипе АМУР-32 ссылка на прототип коммуникационного процессора. В дальнейшем мы планируем уйти от Modbus RTU на другой интерфейс и протоколы, чтобы уменьшить цикл опроса.

      2) Сейчас в рамках открытой АСУ ТП (ОАСУ ТП) создается техническая рабочая группа (ТРГ) по общесистемному программному обеспечению, в которую войдут разработчики ОС и ОСРВ, поэтому я думаю у нас будет выбор какие ОС под какие задачи выбрать. Сейчас тестируем на ОС с патчем реального времени и изучаем возможность использования Нейтрино (QNX).

      3) В мире уже есть станы, реализованные на программном ПЛК (например: Siemens, IBA), так что в теории это возможно. Для управления быстрыми процессами, такими как прокатка, необходимо иметь высокоскоростную полевую шину и модули ввода/вывода. В рамках ОАСУ ТП создана ТРГ по шине и полевому протоколу.