Карлсон, который живет до Сrash'a | IoT, АСУТП, Linux, AI

CiA 302-3 и "последняя миля" доставки обновления на умные промышленные устройства по CANopen. Всем, кто умные устройства использует с прошивками через CANOPen и хочет интегрироваться с оркестратором типа Hawkbit (или аналогом, о котором мы чуть спустя поведаем вам, уважаемые инженеры промышленных систем), рекомендуем присмотреться к CiA 302-3 Firmware Update Process.

Это часть семейства спецификаций CAN in Automation, описывающая детализированный, детерминированный и безопасный механизм обновления прошивок для устройств поверх CAN/CANopen-шин. То есть это не «залить файл как-нибудь». Это именно регламентированный firmware update process. Почему этот стандарт стал референсом для промышленных шлюзов? В промышленной среде обновление устройства — это не бытовая операция. Ошибка может привести не просто к неработающему гаджету, а к остановке линии, потере управления приводом, нарушению технологического процесса или необходимости физического доступа к оборудованию. Поэтому обновление должно отвечать на несколько критичных вопросов: Как понять, что устройство готово к обновлению? Нельзя начать процесс в неподходящем состоянии Как передать firmware по ограниченной шине? CANopen не является «широким IP-каналом» Как контролировать этапы обновления? Нужна диагностика и управляемость Что делать при ошибке? Промышленная система должна оставаться предсказуемой Как подтвердить результат? Нужны аудит и воспроизводимость Как связать обновление с верхнеуровневой системой? Нужна интеграция с оркестратором вроде Hawkbit У CiA 302-3 есть ответы на все эти вопросы. Машина состояний, а не просто файл в сеть CiA 302-3 описывает строгий жизненный цикл обновления: Idle → Preparing → Downloading → Verifying → Activating → Rollback/Success. Каждый шаг валидируется, а переходы синхронизированы с реальным состоянием контроллера, а не с таймаутами на сервере. Сегментированная передача через SDO Прошивка не летит «одним куском». Она разбивается на блоки, каждый из которых подтверждается получателем. При обрыве связи шлюз запоминает последний успешный сегмент и возобновляет передачу без перезапуска процесса. Никаких «полупрошитых» узлов. Сквозная криптографическая верификация Стандарт предусматривает проверку контрольных сумм и цифровых подписей на уровне устройства. Если хеш не совпадает или подпись не валидна, контроллер не перейдёт в фазу Activating, а шлюз немедленно сообщит об этом оркестратору. Гарантированный fallback При потере питания, аппаратной ошибке или нарушении детерминизма шины CiA 302-3 предписывает контроллеру вернуться к предыдущей рабочей прошивке. Это не «костыль», а встроенная фаза стандарта. Совместимость с существующими топологиями Шлюз, реализующий CiA 302-3, работает поверх штатных CANopen-объектных словарей и SDO-механизмов. Не нужно менять кабельную инфраструктуру или перепрошивать legacy-устройства — достаточно обновить прошивку шлюза и привести его в соответствие со спецификацией. Переносимость на другие полевые шины CiA 302 прекрасно сосуществует с Ethernet полем: Canopen-over-EtherCAT, ETHERNET Powerlink, EtherNet/IP используются для реализации CiA спецификаций наравне с CAN и RS485.

❗️Вебинар по 4diac и ForgeLogic стартует через 20 минут❗️ Регистрируйтесь и заходите, пожалуйста, уважаемые: https://rtsoft.timepad.ru/event/3978763/

ЦПР РТСофт приглашает всех желающих принять участие в новом бесплатном вебинаре "OpenSource инструменты разработки для IEC 61499. ForgeLogic и 4diac, cходства и различия", который состоится 20 мая 2026 года в 16.00. На вебинаре вы узнаете о двух ведущих open-source проектах в области распределенных систем управления и промышленных контроллеров (IEC 61499): Eclipse 4diac — признанный отраслевой мейнстрим, и ForgeLogic — российский open-source проект, решающий ключевую задачу импортозамещения в промышленной автоматизации. Вы увидите, что их объединяет: общая событийно-ориентированная модель, поддержка распределённых архитектур и базовая совместимость на уровне функциональных блоков (FB). А также — чем они принципиально различаются: от IDE до среды исполнения. Успейте зарегистрироваться по ссылке: https://rtsoft.timepad.ru/event/3978763/

🌌 Важное сообщение 🌌 ЦПР РТСофт приглашает всех желающих принять участие в новом бесплатном вебинаре OpenSource инструменты разработки для IEC 61499. ForgeLogic и 4diac, cходства и различия 20 мая 2026 года в 16.00 На вебинаре вы узнаете о двух ведущих open-source проектах в области распределенных систем управления и промышленных контроллеров (IEC 61499): Eclipse 4diac — признанный отраслевой мейнстрим, и ForgeLogic — российский open-source проект, решающий ключевую задачу импортозамещения в промышленной автоматизации. Вы увидите, что их объединяет: общая событийно-ориентированная модель, поддержка распределённых архитектур и базовая совместимость на уровне функциональных блоков (FB). А также — чем они принципиально различаются: от IDE до среды исполнения. Успейте зарегистрироваться по 👉 ССЫЛКЕ 👈

Доброй пятницы, уважаемые инженеры промышленных систем. Майкл Оберленер, видный член коммунити, через 2 недели выдаст программное выступление о том, как Eclipse 4diac 3.1 помогает инженерам сопровождать и развивать системы на базе IEC 61499 благодаря улучшенному управлению библиотеками, поддержке рефакторинга и более безопасным процессам обновления. Регистрируйтесь, пожалуйста.

HawkBit меняет правила игры. ч.2 Продолжаем лонгрид, уважаемые разработчики встраиваемых и промышленных систем HawkBit работает поверх HTTP REST, MQTT, CoAP (а вы в курсе, что этот протокол может гарантированно передавать файлы по SMS? 😃 ), AMQP или через шлюзы, транслирующие обновления в проводные промышленные сети. Но главное — это не просто «сервер для загрузки файлов». Это архитектура доставки, которая берет на себя контроль над процессом. Репозиторий устройств и ПО — единый реестр всего парка оборудования и всех версий прошивок с полной историей и метаданными. Гибкие сценарии развертывания (rollouts) Обновления распределяются по группам устройств с возможностью поэтапного rollout, паузы, приоритизации по критичности и автоматического отката. Не нужно «лить» прошивку на весь парк одновременно: сначала тестовая группа, потом пилотный участок, затем массовое применение. Работа в тандеме с инфраструктурным QoS и резервированием HawkBit не заменяет сетевую инженерию, а строит поверх неё логику доставки. Инженер может построить схему с QoS и резервированием: основной канал — проводной, резервный — через другой физический маршрут, и всё это прозрачно для Hawkbit. Полный аудит и интеграция с SIEM Кто, когда, какую версию и на какое устройство отправил? Была ли подтверждена установка? Успешно ли прошёл post-update check? HawkBit хранит детальный журнал всех операций, что критично для соответствия требованиям регуляторов (ФСТЭК, ГОСТ Р МЭК 62443) и упрощает расследование инцидентов. Автоматизация fallback Если после обновления устройство не прошло встроенную самодиагностику или не вернулось в рабочий режим за заданный таймаут, HawkBit позволит сделать возврат к предыдущей стабильной версии. Экосистема интеграций — клиенты для embedded Linux (SWUpdate, RAUC), Zephyr RTOS, LoRaWAN-серверов. На базе Hawkbit построены и коммерческие решения (они есть у нас!). Почему это актуально для КИИ и промавтоматизации В контексте требований к критической информационной инфраструктуре Hawkbit закрывает несколько болевых точек: Изоляция от публичных сетей. Поскольку платформа self-hosted и транспортно-независима, её можно развернуть целиком внутри контура безопасности предприятия — без единого пакета, уходящего в интернет. Контролируемая доставка. Ни одно обновление не «прилетает само»: оператор определяет группы устройств, расписание, условия отката. Это принципиально отличается от consumer-модели, где обновление приходит ночью без спроса. Итак, выводы! Граница между «умным цехом» и «критической инфраструктурой» стирается. Промышленные контроллеры становятся сложнее, парки устройств растут, а требования к доступности и безопасности ужесточаются. Отказ от OTA в таких условиях означает ручные выезды, простои, человеческий фактор и невозможность быстро закрыть уязвимость. Eclipse Hawkbit — это не «ещё одна OTA-платформа для умных лампочек». Это зрелый, проверенный индустрией инструмент, который берёт лучшее из концепции OTA — централизацию, автоматизацию, масштабируемость. HawkBit не отрицает риски беспроводных каналов. Он обходит их архитектурно. Он не заменяет инженеров связи, а даёт им инструмент, который превращает хаотичную «прошивку по воздуху» в управляемый, воспроизводимый и аудируемый процесс жизненного цикла устройств. Будущее — не в отказе от OTA, а в его «взрослении». И HawkBit показывает, как это сделать без компромиссов между скоростью обновления и устойчивостью системы. Осилили лонгрид? Делитесь впечатлениями в комментариях!🐧

HawkBit меняет правила игры. ч.1 Здравствуйте, уважаемые разработчики встраиваемых и промышленных систем 🐧 Раз зашел предыдущий пост про Mender, то и этот вам понравиться может. Слово OTA (Over-The-Air) сегодня знают даже те, кто далёк от инженерии. Смартфон получил новую ОС, автомобиль «по воздуху» обновил автопилот, умная колонка заговорила на ещё одном языке. Всё это работает быстро, незаметно и, казалось бы, надёжно. Но перенесите эту логику в цех, на подстанцию или в систему управления технологическим процессом (АСУ ТП) — и уверенность сменяется холодным потом. В промавтоматизации и КИИ, где контроллер управляет химическим реактором, а PLC координирует работу турбины, беспроводной канал — это не удобство, а потенциальная точка отказа и поверхность атаки. Представьте: по Wi-Fi или LTE летит прошивка, алгоритм или конфигурация контроллера, управляющего аварийным сбросом давления или блокировкой приводов. Потеря пакетов, джиттер, радиоэлектронное подавление, MITM-атака или просто сбой базовой станции — и вместо «улучшения функционала» вы получаете остановку линии, порчу сырья или, в худшем сценарии, техногенную аварию. Поэтому в КИИ классический OTA часто считают «игрушкой для потребительских гаджетов», никто не решится добровольно открывать дверь, которую регуляторы и здравый смысл требуют держать запертой на три замка. Но что, если сохранить философию OTA — централизованное, версионированное, управляемое обновление парка устройств — но отвязать её от рискованного транспортного уровня? Что если оставить канал связи на выбор ИТ-команде, а логику управления, безопасность, предсказуемость и контроль возьмет на себя архитектура системы? Именно эту задачу решает Eclipse HawkBit — open-source платформа управления обновлениями IoT- и промышленного оборудования, которая доказывает: OTA может быть не только удобным, но и безопасным, отказоустойчивым и промышленно-надёжным. HawkBit: OTA, который не верит «на слово» эфиру Суть OTA — не в антенне, а в оркестрации: централизованное хранилище прошивок, контроль версий, поэтапный раскат на парк устройств, мониторинг статусов, откат при сбое. Всё это можно реализовать поверх любого транспортного уровня — будь то Ethernet, оптоволокно или полевая шина. Именно на этом принципе построен Eclipse Hawkbit — и в апреле 2026 года проект достиг знаковой отметки: релиз 1.0. За плечами проекта — 84 контрибьютора, почти 4 000 коммитов и 20 промежуточных релизов. Подробнее про одуванчики в следующем посте.

Нам важно, чтобы вы узнали об этом первыми 🌌 Команда ЦПР РТСофт выпустила openFB 1.1.0 Что в новом релизе: совместимость с 4diac 3.0, публикация входов и выходов функциональных блоков по OPC UA, а также добавлена расширенная библиотека функциональных блоков, совместимая с 4diac 3.0 и ForgeLogic (разделы convert, events, iec61131, utils и другие.) Расширенная библиотека функциональных блоков позволяет запускать программы 4diac в среде исполнения openFb! Полный список блоков тут. Дополнительно: проведен рефакторинг структуры проекта, улучшено логирование, обновлены зависимости и исправлена работа OPC UA во встроенном сервере. Подробнее: https://github.com/rtsoft-sdc/openFB/ Уважаемые разработчики промышленного ПО, приглашаем вас пробовать, задавать вопросы и делиться впечатлениями. Обратную связь от вас невозможно переоценить!

Mender: когда нужен не просто обновлятор, а платформа управления жизенным циклом устройств Если RAUC — это вполне себе «инженерный» способ обновлять embedded Linux на устройстве, то Mender — это уже целая OTA/IoT платформа. Тут речь не только про то, как записать новую версию системы, но и про то, как управлять обновлениями на парке устройств, следить за состоянием, планировать кампании обновлений и не утонуть в ручной операционке. Если очень грубо: RAUC отвечает за установку и переключение образов на устройстве; Mender закрывает весь жизненный цикл обновления, включая сервер, кампании и управление устройствами.

Что такое Mender Mender — это решение для OTA обновлений, которое включает клиентскую и серверную части. И Mender изначально проектировался как система для массового развёртывания обновлений. Атомарные обновления и откат Как и положено нормальному OTA-решению, Mender поддерживает безопасные обновления и rollback-сценарии. Если новая версия не проходит проверку или устройство не возвращается в рабочее состояние, можно откатиться. Управление флотом устройств Вот здесь Mender особенно силён. Он помогает не просто «залить новую версию», а делать это поэтапно: - по группам устройств; - по кампаниям; - с контролем статуса; - с видимостью того, что реально происходит в поле. Интеграция в CI/CD Mender довольно естественно встраивается в современные процессы доставки. Если у вас релизы собираются автоматически, то и обновления можно автоматизировать до довольно зрелого уровня. Коммерческая поддержка и зрелая документация Не у всех есть желание собирать всю инфраструктуру OTA только на диком опенсурсе. Когда продукт уже живёт в поле, коммерческая поддержка и нормальная документация стоят своих денег (евро, в данном случае).

Короче, Mender — это вариант, когда задача уже вышла за рамки «обновить образ на девайсе» и превратилась в управление жизненным циклом устройств, а так же требуется экономить время и силы уважаемых инженеров встраиваемого ПО Но есть нюанс: это норвежский vendor lock продукт. Интересно, существуют ли российские аналоги? Делитесь в комментариях вашими догадками☕️

Доброй пятницы, уважаемые архитекторы встраиваемых и промышленных систем. Hitex и PROTOS опубликовали видеозапись прошедшего вебинара про Архитектурно-ориентированную разработку встраиваемых систем Это про модельно-ориентированный язык ROOM. Интересное демо показывают - создание структурной модели контроллера светофора, отладка и масштабирование на 20 объектов. Про ROOM любопытно вдвойне послушать и почитать (с английскими субтитрами), так как лектор херр Шютц (Thomas Schütz), CEO PROTOS'a 🐧

RAUC: рабочий обновлятор устройства и ничего лишнего Чуть выше мы утверждали, что в embedded-разработке обновление прошивки — это часть базовой надёжности продукта. Именно поэтому вокруг OTA-update management вырос целый зоопарк решений, и RAUC здесь занимает очень понятное место.

Что такое RAUC RAUC (Robust Auto-Update Controller) - это open-source фреймворк для безопасной установки обновлений на Linux-based embedded-системах. Важно! RAUC — это прежде всего клиентская часть: он отвечает за проверку, установку и переключение версий на самом устройстве. Сервер, кампании обновлений, управление флотом и аналитика обычно строятся отдельно. Что умеет RAUC RAUC любят за то, что он не перегружен лишним функционалом, но закрывает ключевые вещи, которые нужны в реальном embedded-проекте. Атомарное обновление Главная идея RAUC — обновление должно либо пройти полностью, либо не затронуть рабочую систему. Это особенно важно для устройств, которые нельзя просто перезагрузить «и посмотреть, что будет». A/B-схемы Самый частый сценарий — две слота: один активный, второй резервный. Новая версия сначала ставится в неактивный слот, а потом система переключается на него. Если после перезагрузки что-то идёт не так, можно вернуться назад. Проверка подписи и целостности RAUC работает с подписанными образами, и это критично. Поддержка криптографической валидации и аппаратного хранения ключей делает его пригодным для вполне серьёзных "промышленных" сценариев. Гибкость интеграции RAUC достаточно спокойно живёт в разных архитектурах: - разные схемы разделов; - разные файловые системы; - разные bootloader-ы; - разные варианты хранения корневой системы.

Короче, RAUC особенно хорошо подходит, если у вас: Встраиваемая система с ОС на Linux Нужен фреймворк для обновления именно самого устройства Есть собственный серверный бэкэнд системы, с которым можно интегрироваться Есть команда готовая разбираться с интеграцией :) А в следующем посте приведем пример известного OTA-update комбайна (это когда вы хотите одну красивую кнопку в браузере "Обновить все"). Если есть предположения, как он называется - пишите в комментариях!

Ручные обновления embedded-систем - это тупик 👩‍💻 Пока устройство выпущено в количестве одного-двух, трех десятков, кажется, что легче обновлять систему “по старинке”: залить файл по SSH, заменить бинарник через rsync, прогнать скрипт после перезагрузки, а если что-то пойдёт не так — поправить вручную силами уважаемых инженеров встраиваемого ПО (Приветствуем!). Знакомо? Безусловно. Но как только таких устройств становится много, такой подход начинает разваливаться: плохо масштабируется, плохо контролируется и слишком легко приводит к поломанным устройствам, уже находящимся в эксплуатации.

Типичные проблемы: Оборвалась связь в середине передачи, питание пропало во время записи, образ оказался повреждён, а старая версия уже частично затёрта. Что теперь? "Кирпич" вместо устройства, и ущерб репутации! Ещё хуже то, что такие схемы почти всегда слабо защищены. В них часто нет нормальной проверки подписи, контроля целостности и доверенной загрузки. Это значит, что обновление может быть не только нестабильным, но и небезопасным. Аппарат с кофе, или инфокиоск в ТЦ еще перенесет. А вот для промышленных, медицинских и автомобильных систем это уже серьёзная архитектурная ошибка. Есть и операционная сторона проблемы. Ручные сценарии плохо повторяются, зависят от конкретного инженера, трудно документируются и почти не интегрируются в нормальный CI/CD-процесс. Поддерживать разные аппаратные ревизии, разные загрузчики, разные разметки памяти и разные сценарии отката становится всё сложнее. То, что выглядело как быстрый путь, довольно быстро превращается в долгий и дорогой техдолг.

Поэтому обновление embedded-систем давно перестало быть второстепенной задачей. Это часть самой архитектуры продукта, продумывается она на стадии дизайна. Если механизм обновления не атомарный, не проверяет целостность и не умеет безопасно откатываться, он не подходит для масштабируемого устройства в реальном мире. Много букв, но мы так хотим подвести к RAUC и альтернативам, и в каких случаях лучше выбрать готовый фреймворк, а не писать свой механизм с нуля. Делитесь вашими мыслями и опытом в комментариях, уважаемые ☕️

Желаем хорошего вечера всем разработчикам промышленного программного обеспечения. А между прочим, при выборе open-source движка для реализации OPC UA сервера на промышленном контроллере сейчас доступно несколько вполне зрелых вариантов, вот наиболее выгодные (не все, конечно):

open62541 (C, MPL 2.0) Зрелая и широко применяемая реализация для встраиваемых и промышленных систем. Ключевые преимущества: - Чистый C (C99) — минимальные зависимости, лёгкая кросс-компиляция под ARM, MIPS и другие архитектуры контроллеров. - Малый footprint — ядро занимает десятки килобайт RAM, что критично для ресурсоограниченных платформ. - Полнота стека — поддержка серверной и клиентской части, PubSub, Discovery, Security (Basic256Sha256, Aes128Sha256RsaOaep), исторических данных. - Сертифицируемость — проект ориентирован на прохождение OPC Foundation Compliance Test, ряд коммерческих продуктов на его базе уже сертифицирован. - Активное сообщество — регулярные релизы, подробная документация, широкая база примеров. - Работает bare-metal, под RTOS (FreeRTOS, Zephyr, VxWorks, QNX), Linux, Windows. OPC Foundation UA-.NETStandard (C#, GPL 2.0 / коммерческая) Эталонная реализация от OPC Foundation на платформе .NET, ВАЖНО: с недавних пор лицензия не GPL 2.0 / коммерческая, а MIT. И не стоит сразу возмущаться по поводу .NET/Java runtime, они уже пригодны для embedded, с известными ограничениями - Максимальная полнота спецификации «из коробки», эталон совместимости. - Плохо подходит для промышленных контроллеров с ограниченными ресурсами: типичные целевые платформы — серверы, шлюзы, десктопы. Eclipse Milo (Java, EPL 2.0) Качественная реализация на Java, поддерживаемая Eclipse Foundation: - Хорошо подходит для edge (промПК), но Java можно окультурить для работы и на малоресурсных контроллерах. - Latency и предсказуемость работы GC делают его рискованным выбором для жёстких требований реального времени. Отдельно: клиентская часть Если задача ограничивается реализацией OPC UA клиента на встроенной платформе, стоит обратить внимание на Systerel S2OPC (C, Apache 2.0): - Проект изначально разрабатывался с упором на формальную верификацию и безопасность — критично для safety-/security-ориентированных систем (ядерная энергетика, железнодорожный транспорт). - Компактная кодовая база, детерминированное поведение, отсутствие динамической аллокации в критических путях. - Минимальный набор зависимостей, портируемость на RTOS. - Лицензия Apache 2.0 — максимально дружественна к коммерческому использованию. S2OPC может уступать open62541 по полноте серверных функций и размеру сообщества, но для встроенного клиента он весьма привлекательный.

Рекомендация Для реализации OPC UA сервера на промышленном контроллере рекомендуется open62541. Это единственный из рассмотренных вариантов, который сочетает малый ресурсный footprint, написан на чистом C, активно развивается и имеет подтверждённый опыт промышленного применения. ЦПР РТСофт имеет хороший опыт использования расширенной функциональности этой платформы для создания OPC UA серверов высокой производительности edge уровня (с поддержкой хранилища исторических данных и горячего резервирования). Ну а если цель - программный ПЛК, то стоит сразу иметь в виду, что OPC UA сервер и клиент уже поставляется в открытом (opensource!) ForgeLogic Runtime от компании Северсталь как референс-реализация ОАСУТП, а также OPC UA сервер (python 3 реализация) встроен в наш продукт с открытым исходным кодом - OpenFB.

Добрый вечер, уважаемые разработчики промышленных систем👩‍💻 Сложная тема, о которой настало время побеседовать: виртуализация в ОС промышленного контроллера: зачем и когда это необходимо?

Суть проблемы Современный промышленный контроллер способен совмещать на одной аппаратной платформе задачи принципиально разной природы: - Управление в реальном времени — циклы регулирования, обработка сигналов, safety-логика с жёсткими дедлайнами (микро- и миллисекунды). - Коммуникационный стек — OPC UA, MQTT, HTTP/REST, обновления конфигурации, диагностический интерфейс. - Прикладная логика верхнего уровня — HMI-панели, визуализация, edge-аналитика, логирование. Попытка разместить всё это в рамках одной ОС создаёт конфликт: RTOS не приспособлена для выполнения интерфейсных задач общего назначения, а Linux не способна гарантировать детерминизм жёсткого реального времени (да-да, есть нюансы). Что даёт виртуализация Изоляция доменов с разными требованиями Гипервизор (как правило, Type-1 — bare-metal) позволяет запустить на одном процессоре несколько изолированных гостевых ОС. Типичная конфигурация: - Домен реального времени — RTOS (VxWorks, QNX, Zephyr, FreeRTOS) или bare-metal приложение, которому гипервизор гарантирует выделенные ядра, прямой доступ к периферии и предсказуемое планирование. - Домен общего назначения — Linux с полноценным сетевым стеком, OPC UA сервером, средствами удалённого обслуживания. Каждый домен работает так, будто владеет аппаратурой единолично, при этом сбой или перезагрузка Linux-домена не затрагивает контур реального времени. Повышение функциональной безопасности - Сертификация по IEC 61508 / ISO 13849 требует доказательства того, что несертифицированное ПО не влияет на safety-функции. Гипервизор выступает границей разделения (freedom from interference), упрощая аргументацию безопасности. - Уменьшается объём кода, подлежащего сертификации: сертифицируется только RTOS-домен и сам гипервизор, а не вся система целиком. Информационная безопасность - Атака на Linux-домен (через сеть, USB, обновления) не даёт прямого доступа к контуру управления. - Гипервизор контролирует межвиртуальные каналы связи, сводя поверхность атаки к минимуму. - Это упрощает выполнение требований IEC 62443 к зонированию и сегментации. Консолидация оборудования Вместо двух–трёх отдельных плат (контроллер + коммуникационный модуль + HMI-процессор) можно использовать один многоядерный SoC. Это снижает стоимость BOM, габариты, энергопотребление и количество точек отказа. Когда виртуализация избыточна Виртуализация не является универсальным решением и привносит собственную сложность: - Простые контроллеры с единственной задачей реального времени и минимальной коммуникацией вполне обходятся одной RTOS. - Ресурсоограниченные платформы (одноядерные MCU, малый объём RAM) физически не способны нести overhead гипервизора. - Latency межвиртуального взаимодействия — обмен данными между доменами проходит через разделяемую память или virtio и добавляет единицы–десятки микросекунд, что может быть критично для сверхбыстрых контуров. - Гипервизор сам становится дополнительным компонентом, требующим квалификации, обновлений и, при необходимости, сертификации.

Наш вывод: Виртуализация на промышленном контроллере — инженерный инструмент разделения ответственности. Она становится необходимой в тот момент, когда на одной аппаратной платформе требуется гарантированно совместить детерминизм реального времени, развитую коммуникацию и требования safety/security — без взаимного влияния этих доменов друг на друга. В более простых сценариях её внедрение следует оценивать по критерию «сложность внедрения vs. реальный выигрыш». Примеры зрелых решений смотрите в комментах. И свои не забывайте добавлять 👩‍💻

Здравствуйте, уважаемые разработчики встраиваемого и промышленного ПО. О красоте и удобстве пост. Web-интерфейс в ПЛК ☕️ Идея заманчива: открыл браузер, зашёл на контроллер, настроил. Без среды разработки, без кабелей, без специального ПО. Вот , как на прикрепленном фото - мы такие поднимаем для наших клиентов. Инженеры-наладчики скажут спасибо. Но вот реальность.

Защита web-интерфейса на ПЛК — это если не ад, то чистилище. TLS-сертификаты, аутентификация, управление сессиями, защита от CSRF/XSS, обновления безопасности... Всё это нужно делать правильно, регулярно и на платформе с ограниченными ресурсами. А если web торчит в промышленную сеть — вы только что подарили потенциальному злоумышленнику парадный вход. IEC 62443 требует сегментации и контроля доступа. На практике — каждый открытый порт на контроллере это точка атаки и бесконечная головная боль для служб ИБ предприятия. А обслуживание? Сертификат истёк — web недоступен. Забыли пароль — нужен сброс. Обнаружена уязвимость в embedded web-сервере — нужно обновлять firmware на всех контроллерах в поле. Для парка из сотен устройств это кошмар. 💡 Компромисс: USB-to-Ethernet А что если web-интерфейс есть, но доступен только через выделенный USB-Ethernet-device на корпусе контроллера? Физический доступ = авторизация. Подключиться можно только стоя у шкафа с отвёрткой и ноутбуком. Никакого доступа из сети. Можно упростить защиту. Link-local адрес, самоподписанный сертификат, базовая аутентификация — для изолированного point-to-point соединения этого достаточно. Нулевая поверхность атаки из промсети. Интерфейс не маршрутизируется, не виден сканерам, не нуждается в firewall-правилах. Удобство сохраняется. Наладчик подключил кабель, открыл браузер — работает. Отключил — порт спит. По сути, это цифровой аналог сервисного разъёма на передней панели. Просто, понятно, безопасно.

Вывод: web-интерфейс в ПЛК — нужная вещь, но пускать его в сеть — плохая идея. Выделенный USB-Ethernet порт даёт удобство конфигурации без рисков и без боли с PKI/IAM на каждом контроллере в поле. Есть и другие мнения, идеи, решения, готовы сформулировать? P.S. Полюбопытствуйте на содержание окна с версиями прошивки ( в комментарии). Это про A/B обновления контроллеров, о которых мы обещали порассуждать в скором времени.

Вы еще на работе? Хотим поделиться ссылкой на интереснейшее мероприятие на будущей неделе. Programming Hardware Two Ways: CircuitPython и Verilog 30 апреля 2026 Обещают продемонстрировать практический взгляд на выбор между программной и аппаратной логикой во встроенных системах: высокоуровневый код (CircuitPython на плате Microchip) для быстрого прототипирования и аппаратную логику (Verilog на CLB/MiniFPGA) для задач с жёсткими требованиями к времени и детерминизму. И еще обещают, что участники увидят демо с пайкой (свинцовой , или нет - не уточняют).😃 Всем уважаемым инженерам промышленных и встраиваемых систем желаем отличной пятницы и хороших выходных.

Здравствуйте, уважаемые, разработчики встраиваемых систем и промышленного ПО. Буквально сегодня сформулировали кредо по разработке Yocto BSP для промышленных контроллеров (ПР, ПЛК, ...) — это "создание детерминированной, сертифицируемой и долгосрочно поддерживаемой платформы".

Сейчас попробуем расписать ключевые шаги и особенности этого процесса. Основные шаги 1. Создание BSP-слоя: структура meta-<plc>/conf/machine/, conf/layer.conf, описание SoC, памяти, интерфейсов и загрузчика. 2. Настройка ядра точно вне этого небольшого поста, для железа с архитектурой ARM и RISC-V все гораздо сложнее, чем выбор штатного linux-yocto или кастомного upstream, тут искусство кернальщика (если хотите поговорить об этом дополнительно - пишите "+" в комментах). Отметим только применение PREEMPT_RT, отключение неиспользуемых драйверов, в первую очередь графики и т.п.. 3. Bootloader и secure chain: U-Boot с поддержкой verified boot, FIT-образов. Опять же вне этого сообщения оставим вопросы аппаратного корня доверия и восстановления при сбоях питания и критических ошибках прошивок. 4. Валидация: bitbake core-image-minimal → кастомный образ → запуск на реальном железе или QEMU, проверка загрузки, сети, RTC, storage. Набор пакетов Для ПЛК применяется принцип «минимальный детерминированный базис + промышленный стек», хотя строго говоря промышленного стека не существует пока, есть carrier grade, но это телеком больше. • Базовые: systemd (или busybox/sysvinit для legacy), dropbear/openssh с hardened-конфигом, chrony, logrotate, iproute2, util-linux. Добавим к этому еще syslog-ng, наверное, как минимум для интеграции с SIEM • Промышленные: mosquitto, open62541 (OPC UA), libmodbus, socat, net-snmp, rt-tests, python3 + runtime-библиотеки (если используется скриптовая логика). • Аппаратные/безопасность: tpm2-tools, cryptsetup, watchdog, irqbalance (отключается для RT), procps. Все пакеты жёстко фиксируются в IMAGE_INSTALL и PACKAGECONFIG. Лишнее отсекается через DISTRO_FEATURES, IMAGE_FEATURES += "read-only-rootfs", EXTRA_IMAGE_FEATURES не включаются без необходимости. Версии зависимостей привязываются к слою, репозитории кэшируются для воспроизводимости. Автоматическая сборка Промышленный BSP живёт в CI/CD. Стандартный стек: kas или crops для изоляции Docker-среды, GitLab CI / Jenkins для оркестрации. Пайплайн включает: • bitbake -k с параллельной сборкой нескольких машин/профилей. • oe-selftest и ptest для проверки рецептов. • Генерацию артефактов (u-boot, kernel, rootfs, sdcard/wic) с хешированием. • HIL-тесты через LAVA/Robot Framework: прошивка, проверка загрузки, пинг, опрос GPIO/Fieldbus, стресс-тест watchdog. Каждый коммит фиксируется в реестре, образы подписываются, метаданные версионируются. Откат к предыдущему билду занимает минуты. Проверка на уязвимости Безопасность в Yocto встроена, но требует явной активации: • INHERIT += "cve-check" сканирует рецепты на этапе парсинга и сборки, генерируя отчёт cve.log. • BB_SIGNATURE_HANDLER = "OEBasicHash" гарантирует, что изменение версии или патча пересоберёт пакет и сбросит хеш. • Пост-билд анализ: syft/grype или scancode-toolkit поверх готового rootfs, генерация SBOM (SPDX/CycloneDX) для аудита и соответствия IEC 62443. • CVE_CHECK_WHITELIST используется только для ложных срабатываний; критические/высокие CVE блокируют пайплайн (FAIL_ON_CVE = "1"). • Дополнительно: INHERIT += "sign-package", IMAGE_CLASSES += "image-buildinfo", строгий контроль лицензий (INHERIT += "license"), автоматическое обновление баз CVE в ночном режиме.

Итог Успешный Yocto BSP для промышленного ПЛК строится на трёх китах: фиксированный минимальный набор пакетов, полностью автоматизированный воспроизводимый пайплайн и непрерывный контроль уязвимостей с генерацией SBOM. Это даёт базу для долгосрочной поддержки, прохождения аудитов и сертификации без ручного вмешательства. Что скажете, согласны с нашей парадигмой?

Здравствуйте, уважаемые разработчики встраиваемых и промышленных систем. Существует такая точка зрения, изложенная в статье «Зачем embedded-разработчикам переходить на современный C++» (осторожно, English). Суть такая: агитируют перестать цепляться за "устаревший C". Он полон ловушек — переполнения буферов, ошибки с указателями, трудно читаемый код в больших проектах. Современный C++ решает это без потери скорости: абстракции "бесплатны" (zero-cost), RAII автоматически чистит память, умные указатели спасают от висячих ссылок (ох уж эти dangling pointer'ы). Согласны?

А вот и Третья часть блокбастера Анатомия загрузки АРМ Продолжаем разбор процесса загрузки ARM-устройств на примере платы Orange Pi 5 с процессором Rockchip RK3588. Рассматриваем последовательность инициализации, структуру и назначение FIT-образа, практические шаги по сборке U-Boot из исходников, работу с бинарными файлами, разметку SD-карты с учётом смещений и сигнатур, а также базовые приёмы отладки при сбоях загрузки. YouTube ссылка Желаем приятного просмотра и замечательного понедельника вам, уважаемые инженеры встраиваемых и промышленных систем ☕️