Серия «Моими разработками, соревнуюсь с Брендами в АСУ ТП»

Лично мое мнение. Компания разработчик ПЛК (или SCADA )без разработки своего компилятора это - разработчик "начального уровня". В таком случае , невозможно  делать действительно передовые технологии, контролировать весь процесс, или  иметь доступ к мельчайшему поведению программ.

Тут я расскажу, как я делал компилятор, и что выделял в первую очередь  работе.

Среда исполнения и компилятор создавался для работы с MCU с 8 килобайт ОЗУ и до 4ГБ.

То есть, чтоб критически слабые системы, имели функциональность топовых ПЛК (горячая замена кода на лету, вытесняющая виртуальная многозадачность, и другое). Другими способами этого добиться, кроме как создавать свой компилятор - нет.

Я не использовал LLVM  но использовал правила лексера/парсера библиотеки ANTLR. Сосредоточившись на архитектуре и алгоритмах компилятора касающиеся выполнения программы, а не обработки текстовых символов.

Сделать примитивный компилятор и машину - просто. Множество статей написано про это в интернете. Но что б я выделил в полноценном компиляторе, то есть, который может построить программу любого уровня сложности? В данном случае речь идет не о компиляции в нативный код как после СИ, а в байткод который выполняется рантаймом.

Настоящий компилятор и виртуальная машина.

Я бы выделил  два ключевых момента которые нужно реализовать для полноценного  компилятора:

Менеджер адресации данных.

Я б назвал это самым важным в работе. Любая программа работает с данными.

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

Возьмем простой пример:

По сути это готовая LD  математическая инструкция. Вполне можно сделать ПЛК на базе микроконтроллера с ОЗУ даже 2кб для небольшого количества LD  инструкицй.

Но, что если пользователь захочет поддержку в ПЛК языка ST или LD  и создавать собственные  функциональные блоки, а не только стандартные?

Тут не обойтись без поддержки пользовательских данных и структур:

У нас есть сложный тип структуры внутри которого - другие структуры, внутри которых и структуры и массивы и т.д

Теперь, при встрече строки

Компилятор должен посчитать размер всех данных внутри переменной sandwikMB670 типа Equipment , и выделить под это память. А если в программе встретится строка:

Компилятор должен все просчитать и подставить вместо имени переменной, верный адрес после компиляции:

Менеджер адресации и данных должен переварить любой тип данных из "бесконечных" вложений внутри:

А самое главное, алгоритм просчета и управления адресами, должен быть надежным и лаконичным как X^2 , который предсказуемо выдаст те данные которые ожидаешь, и не промахнется ни на байт в сторону среди миллиарда других байт. Только для работы с типами, переменными и их адресами, я завел совершенно отдельный парсер ANTLR и создал библиотеку для этой конкретной задачи независимо от компилятора в целом.

Вторая составляющая компилятора:

На изображении - скрин, результат трансляции моей средой 3o|||sheet программ LD / ST в промежуточный виртуальный ассемблер для своей виртуальной машины. ВМ не знает что такое - потоки, функции и прочее, она просто поочередно выполняет все команды. Задача компилятора превратить метки (например BinaryOperaty \ MathOperaty etc...) в адреса переходов. Одни метки - играют роль отдельных потоков, другие метки играют роль - функций программы. Метки которые играют роль независимых задач/ потоков - обрабатывает виртуальная моя ОС 3o|||sheet которая , которая сохраняет адреса, в свой системный массив указателей задач, а при сообщении от физического таймера - прерывает задачу, и достает следующую.

В завершение компилятор переводит объекты инструкций, к бинарному виду типа:

В которых уже закодированы - тип инструкции, номера регистров , разные флаги и даже константы. Интерпретируются эти потоки байт - виртуальной машиной (а не физическим CPU/MCU ).

В итоге

Решив две эти задачи по управлению адресации данных, и менеджер инструкций, (ну и конечно рантайм который это воспроизводит на стороне железа) я создал собственный компилятор который может:

1. Создавать сложные типы данных

2. Утрамбовывать в памяти без пробелов

3. Надежно с ними работать.

4. Создавать сложные алгоритмы и поведения программы (рекурсии, многоуровневые переходы между функциями, передачи/возврата данных между ними

5. Реализовав управление контекстом, соответственно - создавать вытесняющую многозадачность , многопоточность, с полной масштабируемостью в многоядерных микроконтроллерах или CPU.

И при этом, легко и безопасно можно менять отдельные участки кода программы на лету.

И даже устанавливать (добавлять) в ПЛК - новые задачи, к уже работающим задачам/программ не останавливая ПЛК физически, как это в операционных системах Windows:

установил приложение, и оно сразу работает, или удалил его (но не злоупотреблять этим конечно, все таки это система для АСУ ТП с детерминированным, строгим по времени исполнением программ. Сборщиков мусора и фоновых задач по фрагментации памяти - нет).

А этого (менять код на лету, или устанавливать новые задачи без перепрошивки) не могут нативные ОС типа FreeRTOS. Так же можно обновлять ОС виртуального уровня - "по воздуху", и менять физические свойства ПЛК, например - включить дополнительный физический аналоговый IO - "по платной подписке" :D , это конечно шутка, но виртуальный уровень полностью может менять - физический если надо, управляя регистрами процессора и периферией.

Конечно, компилятор это еще и анализ самого кода и прочее (оптимизации) , но что касается ПЛК тут можно проще к этому относиться. Я реализовал только - удаление "мертвого кода"( да и то не по умолчанию), и предупреждения об неиспользуемых переменных и ошибках с типами. Чтоб не вышло как в старых версиях ПЛК от Siemense, когда компилятор дооптимизировался до такого что данные читал/записывал неинаисаои места( те самые "промахи" менеджера адресации данных).

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

Не могу сказать на какую аудиторию больше ориентируюсь в данных постах, но скорее всего это будет интересно - разработчикам электронщикам, и предпринимателям в сфере АСУ ТП которые разрабатывают ПЛК и разное программно-аппаратное (они часто пишут). Как показывает практика - меньше всего это понятно АСУ-ТПшникам, что не удивительно так как посты больше о разработке ПЛК как прибора и предпринимательстве, а не о применении ПЛК.

Что у меня за проект такой, пост тут: Своими разработками соревнуюсь с брендами в АСУ ТП. Превзойти Codesys

Если коротко, то это аналог Codesys, в несколько скромном виде.

Среда разработки (LD FBD + текстовые типа ST), свой компилятор, и среда выполнения на CPU.

Потенциальному производителю ПЛК осталось разработать железо и скомпилировать среду выполнения под свой CPU/MCU. Один производитель уже разрабатывает железо под своим лейблом, и через полгода мы увидим что вышло.

Хотя со мной связывались так же из  - станкостроительного предприятия, на предмет можно ли все это внедрять в станки. Можно.

Тестовое железо:

Методика тестирования:

Запускаем  программу на LD из 184 блоков.

Замеряем осциллографом реакцию  вывода , и считаем время отработки одной инструкции/блока.

Почему LD а не ST:

Очень часто спрашивают. LD - хорошо документирован. Производители ПЛК часто прямо в документации пишут время выполнения базовых LD  инструкций, и я могу прямо сравнить “свой” ПЛК с брендом по скорости программ.

Результат тестирования в сравнении с брендами:

Хотя пост не о китайском МК, но интересен для сравнения результат моей машины на CH32V307 RISC V.

Еще несколько лет назад, когда я начал переносить на микроконтроллеры свой рантайм, я замерял тестовую скорость базовых LD  операций, они так и были - 1 микросекунда. Потому у меня было некоторое удивление от STM32F407 (и вообще от всей линейки STM ARM) который был медленнее в два с половиной раза.

В данный момент, могу это объяснить так: у RISC V  в два раза больше регистров ядра (16 в ARM против 32 RISC V), это значит что переходы между функциями  RISC V может делать быстрее, так как меньше приходится использовать память, а промежуточные результаты хранить непосредственно в регистрах ядра CPU.

Хотя тут еще предстоит более тщательно разобраться, напишу отдельный пост о тестировании RISC V так как по одному такому МК я сотрудничаю с предприятием. Но скорее всего в данной задаче (по крайней мере моя виртуальная машина) и вправду на RISC V в два раза быстрее чем на ARM.

В прошлом посте где я тестировал свой комплекс на STM32F103 Своими разработками, соревнуюсь с Mitsubishi в АСУ ТП. STM32F103 как ПЛК lo  , упоминал китайские дешевые ПЛК под среду Mitsubishi .Мне скинули китайскую документацию как сделать ПЛК под среду и компилятор от Mitsubishi. В общих чертах почитал, Оказывается, у меня такая же архитектура что и у Mitsubishi. Но я не делал оптимизацию под ARM и мой ПЛК оказался существенно медленнее. Хотя если брать не китайские и разные любительские ПЛК на Mitsubishi, а оригинальные, то тут Mitsubishi равных нет, они делают свои CPU и  аппаратно реализовывают декодирование инструкций и выполнения программ. Мне такой скорости добиться можно наверное если только перенесу виртуальную машину на FPGA, где базовая операция длится - наносекунды.

Что можно выжать из STM32F407  в качестве CPU  ПЛК:

ОЗУ  больше сотни килобайт, и флэш под мегабайт, соответственно можно писать полноценные большие программы на LD  и ST.

Если брать LD то за цикл 1 миллисекунды такой ПЛК отработает чуть больше 400 базовых LD инструкций. Из опыта знаю, ветка горного конвейера, обходилась примерно в 300 LD.

Пид регулятор такого ПЛК успеет отработать за 150 микросекунд вместе с фильтрацией .

Или за 2 миллисекунды еще + 200 LD математических.

(*/+-) на STM32f407 с моим рантаймом - 4.4 микросекунды, на математику. У Siemens S7 1200(CPU 1214C) этот показатель 2.3 микросекудны, а PID регулятор 150-300 микросекунд ( с временем на сетевой обмен). Таким образом, ПЛК на STM32F407 будет уступать S7 1200 не сильно много (я тестировал без учета сети).

Если брать особенность чисто моей архитектуры, то все МК которые имеют ОЗУ больше 16 Кб могут запускать в себе - множественные исполнители:

Код, с операционкой(моей виртуальной имею ввиду операционкой, которую писал), и все что потенциально может вызвать фатальную ошибку и вылет ПЛК - может запустить отдельно, а критический код (безопасность какая) - тоже отдельно. То от чего обычный ПЛК - вылетит, у нас просто заглохнет один исполнитель, в то время как другие продолжат работать.

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

Виртуальная машина по очереди выполняет instruction  каждой ОЗУ(в каждом массиве), и если где то произошла критическая ошибка (повреждение данных, или еще что) просто один исполнитель будет выключен. Как видите , хоть полностью удали данные массива который играет роль ОЗУ это не затронет другие исполнители, и тем более не затронет физический ПЛК.

Тут я ничего принципиально - нового не придумал. Точно так как в операционной системе Windows/Linux/Android - если вылетело какое то приложение, ни ПК ни смартфон от этого не перегружаются и не вылетают.

Но моя заслуга в том что я написал полноценный компилятор, поддерживающий вытесняющую многозадачность, сложную адресацию, и другие сложные , и все это может работать уже на МК с ОЗУ в 16 Кб. Система работает в режиме реального времени, с детерминированным исполнением инструкций, по системному таймеру. В отличии от операционных систем типа Linux/Windows где ОС может приостановить вашу программу, для каких то своих дел.

Следующие тесты буду проводить уже на RISC V микроконтроллерах, и больше буду уделять внимание как это выглядит и работает - физически.

Кому интересно - присоединяйтесь, или пишите на почту

zoshytlogic@gmail.com

3o|||sheet : комплекс для разработки промышленных контроллеров (виртуальных, или физических).Состоит из трех независимых частей:

1)Среда разработки. 2) Компилятор. 3) Среда выполнения на железе:

3o|||sheet IDE : Легкая кроссплатформенная среда разработки, может открываться даже на одноплатных ПК. Задача среды - транслировать языки программирования  (любые) в набор текстовых инструкций  для 3o|||sheet компилятора. А также, Устанавливать виртуальный  RTOS (собственной разработки) если пользователь распараллеливает программу на независимые задачи. В данный момент поддерживается LD, FBD и текстовый редактор для языков типа ST

3o|||sheet - компилятор

3o|||sheet - компилятор собственной разработки: независимое кроссплатформенное приложение. Самая интеллектуальная часть. Писать программы можно и без 3o|||sheet IDE,  Взяв  любой текстовый  редактор, например  Visual Code.

“Родным” кодом компилятора есть собственный стиль, гибрид синтаксиса ассемблера (инструкции) и языка СИ (данные) , сделано с целью - максимально простой трансляции других высокоуровневых языков на платформу. Какая бы ни была среда разработки  (LD FBD ST) своя или сторонняя, среда должна транслировать в наш код .3osheet.

Несмотря на то что данные / переменные в системе виртуальные - физический их размер такой же как у языка СИ или Ассемблера. По переменным - никакой избыточности нет. В отличии от lua, Java , MicroPython , где переменная типа bool - весит больше 20 байт . Тут все оптимизировано для экстремально слабого железа. Вся ответственность типизации и работы с массивами лежит на компиляторе.

3o|||sheet Runtime

3o|||sheet Runtime: регистровая виртуальная машина работающая на стороне железа. Написана на СИ. Не использует низкоуровневый код под конкретную архитектуру, и быстро компилируется на любое железо ARM, RISC V,  x86, разница только в настройке периферии, которую также инициализировать можно из виртуального уровня.

Указанные требования - только  для запуска виртуальной машины.

Для пользовательских программ нужно  + память  программ ( к ОЗУ и Flash). С примерным расчетом 8-12 байт на каждую базовую инструкцию если мы говорим о LD языке. И 60-100 байт на каждый таймер / счетчик.

Если говорим о пользовательских LD/FBD то каждая атомарная инструкция входящая в него (ADD, SUB , инкременты  разные, переходы по веткам ) -  4 байта.

3o|||sheet Runtime - это полноценная машина. Содержит все нужные типы инструкций в том числе по работе с виртуальным стеком / контекстом задач. Что позволяет исполнять любые программы (глубокие переходы между функциями, рекурсии, многопоточность/многоядерность ). Разрабатывалась специально под АСУ ТП и строгие временные рамки исполнения задач.

Преимущества перед мировыми брендами

Это первая система виртуализации для железа с критически малыми ресурсами . У мировых производителей есть ПЛК с вытесняющей многозадачностью (не на железе с 8кБ ОЗУ). У нас  первый возможный ПЛК,  который может работать в нескольких  режимах одновременно ( в отличии от брендов где только что то одно). И в целом кардинально новое.

На базе микроконтроллера с 16 килобайт ОЗУ можно запустить несколько исполнителей, разделяя на критичность процессов.

Представьте что вы АСУ ТП шник, и меньше всего хотите остановить какой то процесс из-за простоя. Вы можете создать несколько изолированных исполнителей разделяя  по критичности:

Первая VM0 это - общие задачи + RTOS. Хотя  зависшая задача не повлияет на другие задачи так как периферийный таймер все равно переключит, но критическая ошибка кода - может положить систему/машину.

Обычный ПЛК от критической ошибки бы - лег. Тут ляжет только один из исполнителей.

Сюда мы можем установить HMI , не критическую связь, иной код с возможными рисками.

VM1 VM2 Критический код, безопасность (максимально простые процессы, не используя стек или глубокие переходы) - выполняем отдельными независимыми исполнителями.

На физическом уровне, в CPU -  у каждого исполнителя своя область памяти (свой массив байт) что бы там не произошло - вылетит только один,

другие продолжат работать.

Физический CPU так же  в полной  безопасности, для него - каждая машина это просто  какой то массив байт, в котором данные и программа не его, и чтобы там не случилось - хоть полное их удаление - это проблемы того кто этот массив использует ,а не проблемы физического  CPU.

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

Множественные исполнители программ.

Выполняться  код может в безопасном режиме. Например один исполнитель без доступа к физическим процессам - исполняет код, второй проверяет не слетела ли машина после этого , и самое главное - проверяет хэш исполнения на наличия “тихих ошибок” которые просто могут быть не замечены компилятором и даже средой выполнения ( не будет исключения, но данные могут быть ошибочны - вместе с ложным  срабатыванием впоследствии физическим выводом).

Третий исполнитель (полная копия первой, но с доступом к физическим процессам) убедившись что код и данные безопасны - выполнит и повлияет уже на физические производственные процессы. Кроме того, такой подход позволяет создавать полностью идентичные процессы в одном ПЛК. Подключать к ним например разные дубликаты физических датчиков для подстраховки на случай физической неисправности одного из них.

Жесткая изоляция: Сбой в VM1 (например, из-за некорректных данных с Датчика 1) никак не повлияет на выполнение VM2.

В классическом ПЛК с одной общей памятью сбойная программа могла бы повредить общие данные и "положить" весь контроллер.

Arbiter - сверяет данные, перезапускает слетевшего исполнителя, другое.

Подобные механизмы были раньше только в системах на Linux, а не на микроконтроллерах с 8-16 кб ОЗУ в формате ПЛК. Но Linux -  не система реального времени, и вообще темный лес для безопасности критических систем.

Виртуализация  выполнения проигрывает по скорости в 2-4 раза в сравнении с нативным кодом. А  создание нативных платформ для ПЛК - гораздо легче  путь,  так как свои LD ST  программы можно транслировать в СИ и компилировать например СИ-шным компилятором,  не заморачиваться о деталях реализации самому (как это делают открытые проекты типа Beremiz  и разные отечественные разработчики ПЛК).

Но виртуализация дает обширные возможности по безопасности и контролю, изменению программ на лету не останавливая производственные процессы, и при этом полностью соответствовать - строгим временным интервалам.

Первое тестирование и сравнение с брендом: Своими разработками, соревнуюсь с брендами в АСУ ТП. Аналог Allen Bradley? STM32G030 против Micro810

Дальше буду тестировать свою разработку на разном железе и сравнивать с мировыми брендами. То что на быстрых CPU результаты будут хорошие итак понятно, но целенаправленно буду тестировать в основном "слабые" микроконтроллеры, для демонстрации уровня оптимизации и максимальные возможности которые можно эффективно выжать из слабого железа чего не предлагают мировые бренды в АСУ ТП.

Этот пост - обновленная справка по проекту, ссылаться на него буду в дальнейшем в тестах, как информация о проекте

Интересно мнение специалистов по АСУ ТП. Будет ли полезна функция графического оформления пользователем LD/FBD блоков внутри лестничных диаграмм? Добавил полноценный редактор рисования блоков, переменных , а так же их анимация. Например к фигуре : текст, линия, полигон... -идет привязка к переменной и ее визуальное изменение в зависимости от значения (появляется\исчезает, меняет цвет, вертится, перемещается и т.п).

Но если с анимацией - все понятно, с этим и SCADA может разобраться по морганиям и перемещениям. То будет ли полезным рисовать LD блоки для удобного чтения схем? Насколько знаю Siemens и Codesys не предлагают такого, у них все элементы/ функциональные блоки в LD одинаковы на вид и размерам (ваш опыт, как это читается если программа состоит из тысяч таких LD). Добавил возможность полностью создавать свои LD любого вида, любого размера, задавать его поведение кодом, и внедрять в цепи LD.

Кто не знает о чем проект, тут первый пост: https://pikabu.ru/story/svoimi_razrabotkami_c_nulya_reshil_tyagatsya_s_rockwell_automation_i_siemens_v_asu_tp_13203787?utm_source=linkshare&utm_medium=sharing

Готовлю мега-тестирование. STM32F407 (ARM) vs CH32v307( RISC V) vs ESP32 в выполнении LD программ для АСУ ТП (скорость выполнения инструкций в разных режимах) на разработаной IDE. А так же сравню с ПЛК брендов - Rockwell и Siemens.

Кто не читал прошлую статью о моем проекте: Своими разработками c нуля, решил тягаться с Rockwell Automation и Siemens в АСУ ТП

Многие встречали разные проекты под мкрокоетроллеры: мигание светодиодов, домашние сервера, умные дома и прочее.

Но как себя эти МК поведут если захотите стать предпринимателем, и на их (да и на любых других МК) базе создавать Промышленные контроллеры с топовой функциональностью? Замена кода отдельных задач в режиме реального времени без пепезагрузки ПЛК, и прочее, теперь с моей IDE все этр будет реально на обычных дешевых МК

Если интересно подписывайтесь.