Edge-контроллеры в АСУ ТП

Недавно наткнулись на интересную публикацию, посвященную месту и роли Edge технологий в мире АСУ ТП.

Классическая схема «АСУ ТП - OPC - MES» не справляется с потоком данных от современных датчиков и требованиями цифровых сервисов вроде ML-аналитики или предиктивного обслуживания. Решение - поднять вычислительные мощности ближе к источнику данных.

Edge-контроллер выполняет первичную обработку сырых данных локально. Может работать на российской Linux-основе, транслирует промышленные протоколы в OPC UA и MQTT. При этом три принципа определяют выбор компонентов: функциональная совместимость и независимость от вендора, переносимость и защищенность на всем жизненном цикле. Архитектурно Edge-контроллер занимает слой L2 - между классическими ПЛК/КИПиА (L1) и корпоративными MES/SCADA/AI (L3).

Эффект двойной: снижение стоимости и сроков внедрения, плюс ускорение t2m цифровых сервисов.

Полностью разделяем эту точку зрения. Делитесь в комментариях, что думаете?

Что нового в OpenFB? Публикуем наше недавнее демо видео

OpenFB - это среда исполнения с открытым исходным кодом для функциональных блоков IEC 61499. Он обеспечивает работу распределенных систем управления на Linux, Windows и встраиваемом оборудовании, имеет встроенную поддержку Python.

Недавно мы реализовали стандартную библиотеку для OpenFB. В видео мы демонстрируем возможности OpenFB:
• функциональные блоки можно разделять на несколько секций для повторного использования сложной логики управления
• вывод в консоль для отладки для упрощения поиска и устранение неполадок, а также мониторинга выполнения функциональных блоков в процессе разработки и тестирования

Репозиторий проекта: https://goo.su/yWzW7s

Что нового рассказали на ARC Leadership Forum?

Продолжаем рассказывать о событиях индустрии. В феврале этого года состоялся ARC Leadership Forum, на котором были предствлены кейсы по OPA (Open Process Automation).

Прошлым летом в Индии стартовал амбициозный проект внедрения OPA-совместимой системы, запуск которой запланирован на 2027 год. В основе лежат два ключевых стандарта: IEC 61499 для управляющих сред выполнения с открытой архитектурой и IEC 61131 для контроллеров. Библиотеки готовых функций, структурированные коммуникации между устройствами и системами создают экосистему, которую удобно сравнить с магазином приложений: переносимость и многократное использование компонентов дают гибкость без необходимости в чрезмерно усложненной инфраструктуре. Об этом расскажем в следующих постах.

Пока что детали проекта не раскрываются, но будем держать руку на пульсе.

Одно можно сказать точно: отказ от привязки к конкретному вендору означает реальную конкуренцию по цене и качеству. Вот только несколько вопросов остаются незакрытыми - нужны ли новые стандарты функциональной безопасности для "сборных" систем? Как открытые системы будут взаимодействовать с унаследованным оборудованием, на практике?

Давайте обсудим в комментариях.

Shell: кейс по созданию экосистемы открытых стандартов

На конференции ARC Leadership Forum также выступил Jacco Opmeer, главный инженер по автоматизации из Shell и бывший со-председатель OPAF. Он поделился подробностями касаемо архитектуры открытой автоматизации, которую энергетический гигант активно внедряет в своих производствах.

Спикер представил многоуровневую архитектуру, где каждый слой отвечает за конкретную функцию интеграции. На вершине - облако (L3), работающее через открытые протоколы OPC UA с профилями PA DIM и MDIS. Уровень L2 объединяет базовую систему управления процессом (BPCS), систему мониторинга электросети (EN MCS) и стандарт IEC 61850 для энергетики. Связующим звеном между уровнями выступает OPC UA FX - расширение протокола для полевых устройств. Фундамент всей архитектуры - Advanced Physical Layer (APL) Ethernet, обеспечивающий физическое соединение, и стандарт безопасности IEC 62443.

Мы видим, что промышленные гиганты активно внедряют открытые стандарты, а что делать более мелким предприятиям? Пока что вопрос остается открытым.

Вебинар “Анатомия загрузки ARM: От BootROM до U-Boot на примере Orange Pi 5”

Напоминаем, что уже завтра, в 11.00, состоится наш новый вебинар, посвященный загрузке ARM.

Успейте зарегистрироваться по ссылке: https://rtsoft.timepad.ru/event/3892769/

Начинаем уже через 1 час!

Регистрируйтесь на наш вебинар - ссылка на трансляцию придет сразу же: https://rtsoft.timepad.ru/event/3892769/

Ура! Всем спасибо за ожидание. Публикуем первую часть прошедшего вебинара Анатомия загрузки ARM 💀 Приятного просмотра, уважаемые.

Как правильно заинтересовать детей технологиями? Возможностью стать космонавтом астронавтом.

CircuitMess выпустила NASA Artemis Watch 2.0 - умные часы на базе ESP32-S3, которые одновременно являются и гаджетом, и образовательным инструментом.

Юный инженер может потыкать микроконтроллер с датчиками и периферией. Ну и попробовать программирование через scratch-подобное IDE CircuitBlocks и даже на C/C++ или MicroPython.

Стоимость гаджета - около $129. Годно , или игрушка на один вечер?

P.S на алике в два - три раза дешевле, но для тайконавтов , т.е с нюансами.

Доброй пятницы, уважаемые.

На будущей неделе горячо рекомендуем найти время и посмотреть - послушать профессиональные вебинары от собратьев по профессии:

Вебинар: Getting Started with Embedded Linux Security
15 апреля 2026 | 1 час | Бесплатно
На вебинаре обещают научить харденингу (мы не знаем подходящего термина на русском, если знаете - скажите в комментах) embedded-устройств на Linux : от безопасной компиляции до верификации загрузки. Рассматриваются как программные методы (sandbox, SELinux, hardening ядра), так и аппаратные механизмы (TrustZone, HSM) на примере AMD Versal. В итоге — практический чек-лист мер для соответствия современным стандартам безопасности.

Вебинар: Architecture-driven Development for Embedded Systems
16 апреля 2026 | 30 минут | Бесплатно
Вебинар посвящён подходу, при котором модель системы становится центральным артефактом разработки, а не просто документацией. Вы узнаете, как с помощью формального моделирования и генерации кода создавать надёжные встраиваемые системы быстрее и с меньшим количеством ошибок. Так обещают, во всяком случае.

Все на английском, правда 🤷‍♂️

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

Существует такая точка зрения, изложенная в статье «Зачем embedded-разработчикам переходить на современный C++» (осторожно, English).

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

Согласны?

Здравствуйте, уважаемые, разработчики встраиваемых систем и промышленного ПО.

Буквально сегодня сформулировали кредо по разработке 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. Это даёт базу для долгосрочной поддержки, прохождения аудитов и сертификации без ручного вмешательства.

Что скажете, согласны с нашей парадигмой?