Лучший нейминг, который я видел, за всю мою практику

Чуть больше полугода я пытаюсь выработать для себя архитектурный подход для написания ППО. Почитать об первые заметки можно тут:
Первая
Вторая
Третья
Что я хочу для себя: четкие разделенные логические слои ППО; изменения не должны затрагивать внутреннюю логику ФБ; быстрый процесс масштабирования и изменений.
И так, пару неделек назад, впервые за долгое время поехал я на объект, так сказать пописать код в боевых условиях, да посмотреть как это будет работать. А раз есть целый объект и боевые задачи, то почему бы не применить свои идеи по факту и посмотреть что будет…
Итог: получилось ужасно, а в какие-то моменты больно.
Да, у меня были четки логические слои, вот тут сигналы, тут управление оборудованием, там логика работы оборудования, а здесь совсем чуть-чуть безопасность. Изменения в одном месте затрагивали внутреннюю логику лишь одного функционального блока.
А вот быстрый процесс масштабирования и изменений не происходил, так как получилось слишком много специальных структур и перед вызовом ФБ приходилось писать огромное количество бойлерплейта, который просто перекидывал значения из поля одной структуры, в поле другой структуру. Казалось бы, что можно было бы просто скормить нужные структуры в ФБ, но тогда получалась высокая связанность…
Исходя из эксперимента - подход построения архитектуры требует переосмысления)
У вас что было интересного?
#АСУТП #ППО #ПЛК #Архитектруа
"Я вам че - Автоматизатор?!"

Приветствую, давно не виделись.
Май месяц был загруженным в рабочем плане, так что сил оставалось только добраться до дома и иногда поиграть в Forza.
Будем нагонять, что там было интересного в сфере отечественной пром автоматизации. Был мною пропущен ЦИПР, какое-то мероприятие по автоматизации в Питере, но зато я разобрался как готовить код для ЧПУ станка и научился правильно делать однослойные платы, путем выжигания всего лишнего на оптоволоконном лазере.
Как у вас делишки? Что нового и интересного?

Распределённый ПЛК без шкафов автоматики
Первый на моей памяти внятный кейс использования 4diac и стандарта IEC61499.
Хорошо показывает базовые основы, чтобы можно было хоть к чему-то подступиться, но есть конечно ряд моментов, к которым бы я прицепился, но в целом очень толково.
FUXA SCADA - не рекомендую ставить на текущий день, уж очень капризная к своим зависимостям.
#PLC #4diac #IEC61499
"Я вам че - Автоматизатор?!"

Industrial Network Scanner: как мы написали на Go инструмент аудита безопасности ICS/SCADA-сетей
В целом, в сфере АСУТП очень туго с инструментариями. Различные Modbus сканнеры - это уже просто рутина, которые пишутся или ручками, или нейроночками за часик другой для конкретной задачки. Но вот универсального комбайна я не наблюдал.
На моей памяти это первый опенсорсный сканер для брешей в безопасности, но как минимум его можно будет использовать для карты регистров Modbus. Если у кого-то будет возможность, то тестаните у себя)
"Я вам че - Автоматизатор?!"

Ооо очень жизненная ситуация.

Так, опять субботнее вечернее чтиво.
Продолжаю изучать вопросы связанные с #IEC61499 и если честно, то проще найти различные научные монографии, чем сам стандарт со всеми его частями на просторах интернета, так что складываю свое представление исключительно по научным и публицистическим работам.
IEC61499 «Открытый стандарт распределенных систем управления и автоматизации» сильно отличается от #IEC61131, который, на данный момент, является прочным фундаментом всей промышленной автоматизации.
То, что ломает привычное мироустройство по пунктам:

1. Событийная модель выполнения ППО
Для полноценного понимания необходима уверенная база в конечных автоматах, машины состояний, которые представлены тут как ECC, у каждого функционального блока. Если вы не ковырялись для себя, то по мимо новых функциональных блоков, каждый функциональный блок может иметь несколько алгоритмов, работа алгоритмов функционального блока определяется ECC, что представляет из себя машину состояний. Еще, если я все правильно понял, там можно связывать данные и события, чтобы использовать только нужное в данный момент.
Цикличность выполнения ППО теперь тоже является событием, т.е. мы вводим специальный ФБ, который генерирует нам событие каждый период, а это значит, что логика работы алгоритмов в цикличных блоках будет отличаться, от работы алгоритмов в чисто событийных блоках.

2. Переосмысление ФБ, как сущности
Когда я провожу собеседования, то ожидаю услышать, что функциональный блок - это единица организации программы, которая содержит логику, а также сохраняет свое внутреннее состояние между циклическими вызовами, так как в отличие от функции обладает экземпляром, который хранит все данные в памяти ПЛК.
В моем понимании IEC61499 теперь ФБ - это основная единица построения распределенной системы.
Можно сказать, что мы и сейчас строим распределенные системы, ведь у нас же есть РСУ, но я еще не видел, чтобы мы могли программу разделить на составные ФБ и отдать каждый ФБ в свой ПЛК, который бы занимался обработкой этого ФБ исходя из событий в системе.(Тема РСУ в целом очень интересная, недавно у нас был разговор с КОТЭ в АСУ ТП, ваши варианты можете накидать в комментарии)

3. Библиотеки и повторное использование
Это самое интересное, опять такие, если я ничего не напутал, то в стандарте четко прописана взаимозаменяемость железа в отрыве от ППО, ставь что хочешь, если вы соответствуете стандарту, то все будет супер и система должна сразу подхватить все без танцев с бубнами, что в целом позволяет использовать одни и те же решения на разном железе, но этот момент надо доизучить.
Пока на рынке не так уж много готовых коммерческих решений, если вы производите такое и готовы дать наборчик на тесты, то отпишитесь в личные сообщения каналов) Ну а я в свою очередь начну еще один виток углубленного изучения, начиная с конечных автоматов и событийной модели.

#АСУТП
"Я вам че - Автоматизатор?!"

Siemens «сломал» игру: почему их новый ИИ-агент навсегда изменит программирование ПЛК в TIA Portal.
Обзорная статья по поверхности когда для своего закрытого решения требуется закрытое решение.

В отличие от универсальных инструментов вроде ChatGPT, Claude или Copilot, Eigen Engineering Agent работает не в изолированном чате, а внутри реальной инженерной среды Totally Integrated. Automation (TIA Portal). Это решает главную проблему автоматизаторов — отсутствие у ИИ понимания контекста, архитектуры и взаимосвязей внутри конкретного проекта.

Разумеется, ведь дочтуп у исходникам проекта нельзя просто получить. Как минимум тебе нужен TIA Openness.

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

А он так уже давно не выглядит. Агенты умеют декомпозировать и проверять, да и тесты гонять и много чего еще.

Eigen Engineering Agent уже прошел масштабное пилотное тестирование в более чем 100 компаниях из 19 стран мира. Результаты реального применения показывают впечатляющие метрики:
Скорость выполнения ИИ-процессов возрастает в 2–5 раз по сравнению с ручным выполнением аналогичных задач.
Качество и точность генерируемых решений увеличиваются на 80%.
Общая эффективность инженерной разработки (engineering efficiency) повышается на 50%.

Скрипты пишут код быстрее человека пальцами, нам это еще TAS в спидранах показал.
Качество и точность увеличились, но мне было бы интересно через какой размер контекста начинаются галлюцинации, а они точно есть.
Ну и мое любимое - это общая эффективность. Я бы сказал, что до 50% на типовых задачах, которые специалист умеет уже решать и тестировать.

"Я вам че - Автоматизатор?!"
#АСУТП #ПНР #mem

OpenSource инструменты разработки для IEC 61499. ForgeLogic и 4diac, cходства и различия. Часть 1.
OpenSource инструменты разработки для IEC 61499. ForgeLogic и 4diac, cходства и различия. Часть 2
Снова вечер субботы. Решил я глянуть два этих видео.
Отличный обзор того, как ПО было адаптировано, какие завезли фичи. С точки зрения разработки инструмента - супер видео.
Немного раскрыли внутрянку работы рантайма и как проекты запускаются. Ответили мне почему в 4diac надо пересобирать среду исполнения если добавили свой ФБ.
Кратко рассказали за основные типы ФБ. Когда нибудь я захочу их повторить, но пока буду ссылаться на эти видосики.
Также есть обзор основных фб для коммуникации, ввода/вывода.
Обозначены основные проблемы при работе с IEC61499.
В целом найдите часик времени за чаем, чтобы ознакомиться, я также ещё раз пересмотрю.
Там ещё у меня было пару моментов, с которых я подгорел, но это уже из серии "докопался до орфографии".
Теперь от меня пару направлений для размышлений. Первым делом, чтобы освоиться с событиями попробуйте посмотреть в сторону паттернов Observer и State. Там же еще можно пройтись по машинам состояний, которые нас полностью погрузять в ECC. Затем очень хорошо пойдёт освежить или узнать такую прекрасную вещь как реактивное программирование. Ну и на десерт event-loop.
Тут мне надо написать, что приму в дар, чтобы сломать, ваш ПЛК, который поддерживает IEC61499, ну или накачу на одноплатник, если потребуется.
"Я вам че - Автоматизатор?"
#IEC61499 #АСУТП