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

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

Если коротко, я работаю над собственным аналогом комплекса - Codesys. Программная экосистема для разработки ПЛК на разном железе, под названием 3o|||sheet (читать как “Зошит”). Состоит из трех уровней: Среда разработки IDE (LD/FBD/ текстовые), собственного компилятора, и собственная среда выполнения на стороне железа.

В прошлом посте, сравнивал свой ПЛК с китайскими клонами на базе Mitsubishi FX3 При одинаковом чипе (stm32f103) мой инженерный образец был в три раза медленнее Mitsubishi.

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

Внутри рантайма в микроконтроллере. Было:

Изменил на:

Производительность нашего ПЛК  на “ровном месте” увеличилась больше чем на 30%.
Сейчас картина выглядит так по работе с релейной логикой (LD)- Указано время выполнения базовых LD инструкций в микросекундах (меньше - лучше):

Наш ПЛК на базе собственного 3o|||sheet все еще уступает Mitsubishi FX3 (с китайским клоном и идентичного микроконтроллера stm32f103), но уже не в три раза, как в прошлый раз, а примерно в два раза. Поле для оптимизации у меня еще широкое (та самая работа с декодированием инструкций- маски, сдвиги, и прочее, я молчу уже об оптимизации - конкретно  выполнение виртуальных инструкций). Пока я создаю инженерные образцы ПЛК (а не коммерческие) где тестируется в основном- стабильность, а не скорость, хотя периодически бывает интересно что можно выжать по скорости.

Но возможно достичь аналогичного результата клона Mitsubishi FX3 может и не удастся, учитывая универсальность моей архитектуры 3o|||sheet и деревянного ( бюджетного конечно)  от Mitsubishi. Но если я оптимизирую производительность до уровня 10-20% разницы с Mitsubishi, буду считать - прекрасным результатом, и вот почему.

Превосходство моей архитектуры:

Mitsubishi FX3 - деревянный и не гибкий, напоминающий Allen Bradley SLC 500). У них “табличная память”. Жестко выделенные области - битовые переменные, целочисленные переменные, таймеры  и т.д Адресация, чтение/запись идет быстро - никакого декодирования . В моей архитектуре 3o|||sheet - единое адресное пространство, и любые типы переменных могут располагаться в перемешку, в любой последовательности, с адресным пространством 4 гигабайта:

То есть, делить адресное пространство можно - как угодно. Создавать или нет внутри Диспетчер задач или Операционную систему.

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

Но не только я так думаю. Бюджетный современный  Allen Bradley может уже исполняться из ST языка ( в отличии от старых бюджетных SLC 500), и что произошло? Новый бюджетный как видим выполняет релейную логику в 2.5  микросекунды на команду,  против 1.2 микросекунды у старых SLC 500 ))) данные я прочитал в документации SLC 500. То есть современный ПЛК Allen Bradley стал медленнее в два раза в сравнении с старым Allen Bradley))

Давайте продемонстрирую возможности своего компилятора 3o|||sheet  и системы воспроизведения в железе, о том что значит - гибкость системы.

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

Я не буду демонстрировать LD или ST  (это у всех ПЛК +- тоже самое, ведь стандарт же), интересней это выглядит внутри микроконтроллера:

В данном видео примере выводятся строки: чем глубже функция, тем длиннее строка для наглядности

Main ------| переход

func1 ------------| переход

func2 ------------------| переход

func3 ---------------------| переход

func4 ------------------------| переход

func5 ---------------------------| Самая глубокая функция

func5 ---------------------------| возврат

func4 ------------------------| возврат

func3 ---------------------| возврат

func2 ------------------| возврат

func1 ------------| возврат

Main ------| Завершение Main. -> Начало Main.

Глубокие переходы между функциями ( функция внутри вызывает другую функцию, а та следующую и т.д), или рекурсии - на всю память. Единое адресное пространство - чем больше программа - тем меньше данных, и наоборот. Никакой жесткости типа -  “память программ 256 кб, память данных 128 кб” и прочее. Никаких жестких списков  “целочисленных переменных 256 страниц, булевых 256 страниц, таймеров 64” и т.д. Как в архитектурах типа FX3. Гибкая архитектура подразумевает  - есть целое виртуальное ОЗУ - а там распределяйте сколько чего нужно в каких пропорциях -  сами.

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

Разработка своего компилятора - трудный путь, но зато потом все вознаграждается тем что ты вплотную сравниваешься с брендами по функциональности: Вытесняющая многозадачность, обновление кода на лету + свои идеи по безопасности , создавая на слабом железе "микро "виртуалки", где одна может выполнять рискованный код (взаимодействовать с внешними системами) и может слететь, а другая - исполняет критический код, никогда не слетит.

Ну и на последок,

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

Никак не доедет отладочная плата на RISC V для теста, кому интересно - присоединяйтесь, периодически буду публиковать ход разработки проекта.

Пишите на почту:

zoshytlogic@gmail.com

Лично мое мнение. Компания разработчик ПЛК (или 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