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

Знаете ли вы сколько неудобства есть в программных продуктах, потому что исторически сложилось? Исходя из современных правил рынка мы не можем долго разрабатывать продукт, полностью его продумывать и описывать разные граничные условия, коих может быть огромное множество, но даже если их все поработать, то есть огромный шанс, что получится не то... Гибкие методологии как раз и появились для того, чтобы дать короткую петлю обратной связи. Спринт ->релиз ->обратная связь. И все по кругу. Но тут требуется изначально продумывать гибкий и масштабируемый фундамент. Что тоже не всегда возможно. А когда мы получаем обратную связь, то нам, исправляя недочёты и вводя новый функционал, надо ещё позаботиться об обратной совместимости. Вряд ли бы вам понравилось, что при обновлении ПЛК необходимо переписать весь проект, а то он больше не работает. Для того, чтобы можно было исправить основные недочёты в фундаменте используют обычно мажорные версии или новые линейки оборудования. Так что если у вас возникнет вопрос, а почему тут так неудобно, то скорее всего-это исторически сложившаяся ситуация, которая держит обратную совместимость, возникшая по причине того, что не было достаточно времени или денег.

Опять принес в субботу немного интересного: https://www.ironplc.com/ Опенсорс, МЭК тулчейн вместе с игровой площадкой сделанный на Rust

Автоматизация больше не терпит компромиссов Что сегодня определяет эффективность промышленного предприятия? Предиктивная диагностика, надёжное электропитание, кибербезопасность, отечественные платформы автоматизации или искусственный интеллект? Ответ гораздо сложнее. В новом номере журнала СТА №3/2026 собраны материалы о технологиях, которые уже работают на российских предприятиях: предиктивной диагностике, отказоустойчивой инфраструктуре, российских средствах автоматизации, промышленном Ethernet, защищённых вычислительных платформах и практической защите АСУ ТП. Это не обзор трендов, а инженерный опыт и решения, которые можно применять уже сегодня. Читайте свежий номер СТА 3-2026 на портале СЭТА

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

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

"Я вам че - Автоматизатор?!" #АСУТП #ПНР #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. Если у кого-то будет возможность, то тестаните у себя) "Я вам че - Автоматизатор?!"