"Я вам че - Автоматизатор?"

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

На случай важных переговоров
"Я вам че - Автоматизатор?!"

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% на типовых задачах, которые специалист умеет уже решать и тестировать.

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

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

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

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

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

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

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

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

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

ИИ внедряют, а отказы не уходят. Почему — в новом номере

Диагностика есть. Аналитика есть. Цифровизация идёт полным ходом. Но значительная часть отказов на производстве по-прежнему связана с человеческим фактором, данные остаются разрозненными, а AI-проекты буксуют из-за незрелой инфраструктуры.

Выходит в свет новый номер журнала СТА 2/2026 — о том, почему технологии без архитектуры не работают:

- Человеческий фактор vs. автоматизация: системные подходы к оценке и управлению эффективностью персонала — не «мягкий» HR, а инженерная необходимость
- Сигналы и изоляция: классические задачи передачи данных, от которых до сих пор зависит стабильность всей системы
- Данные как производственный актив: почему разрозненность моделей и данных — главный тормоз для внедрения ИИ
- Edge-вычисления, модульные архитектуры, роботизация нового поколения: что уже работает в задачах мониторинга и управления в реальном времени

Читайте. Проверяйте на своих задачах. Применяйте.

Электронная версия СТА 2-2026 на портале СЭТА

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

Продолжаю историю о том, как происходит разработка ПЛК. Закончили тестировать защиту RS485. Очень интересно получилось, что когда модуль в режиме приема, то может выдерживать спокойно до +18 вольт на линии, а вот если он начал передавать, то сразу в зависимости от напряжения на шине могут выйти из строя либо токоограничивающие резисторы, но если не повезет то сама микросхема RS485.
Модуль защиты получился немного активным и если на линии есть от +18 и выше, то отрубает модуль на передачу. Затестировали до 115200 бод\с проходит на ура.
Нашли еще одну багулину в сетевом коде из-за которой бывали ситуации, что сетевое соединение отваливалось, пока не перезагрузить ПЛК.
Начал миграцию с YAPLC в VSCode. Научили работать с многофайловым проектом, теперь все исходники являются текстовыми файлами с расширением .st, далее цепочка прежняя формируем из всех файлов огромную портянку, кормим ее транслятору, получаем С-код, билдим, линкуем и можем заливать.
Сейчас стабильный вариант - это сборка проекта в YAPLC, а потом сторонней утилитой происходит загрузка прошивки, когда все это перенес в VSCode - стало легче.
Ну и самое удобное что я получил в конечно итоге - LSP серевер языка ST, который имеет небольшой анализатор, подсказывающий ошибки в коде и также функцию автодополнения.
#devlog@wtfcontrolsengineer
#плк@wtfcontrolsengineer

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

Утро начинается с поиска интересной нормативки. И так, что же я узнал за сегодня:
1)ГОСТ Р ИСО 9241-303 — 2013 «Эргономика взаимодействия человек-система. Требования к электронным видеодисплеям»
2)ГОСТ ISO 3861-4 — 2013 «Графические символы. Сигнальные цвета и знаки безопасности»
3)ГОСТ Р ИСО 9241-210 — 2016 «Эргономика взаимодействия человек-система. Человеко-ориентированное проектирование интерактивных систем»
Уже начальная точка, что ознакомится и взять что-то к себе на вооружение для отрисовки HMI и SCADA.
#АСУТП #ГОСТ #HMI
🔗"Я вам че - Автоматизатор?!"

Пока я немного закапываюсь в операционной деятельности своего отдела, принес вам немного почитать интересного.
«О! Айтишники! Вы же полезными стали. А можете нам конвертер сфотографировать?»
Интересный пост о той самой сказочной IT/OT конвергенции. Тут вам и шины данных со всего завода и техническое зрение и мат модели с аналитикой. И главное все к месту.
Иногда после такого чтива хочется вернутся в эксплуатацию, но у нас тут свои интересные планы.
#АСУТП #OT #IT
🔗"Я вам че - Автоматизатор?!"