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

Предыдущий пост про шлюз между Hawkbit и полевой шиной был вовсе не теоретизированием, а вполне себе нашей практикой. Мы такой разработали и внедрили на нашем RITMS UP2DATE (сделан на базе Hawkbit, полюбопытствуйте).

Шлюз выполняет промышленную трансляцию: принимает артефакт, проверяет политику, выбирает устройство, запускает процесс обновления по CiA 302-3 и возвращает результат наверх.

Он должен понимать:
- какие устройства доступны в промышленной сети;
- какие версии firmware им подходят;
- можно ли сейчас начинать обновление;
- как передавать данные в соответствии с ограничениями шины;
- как обрабатывать таймауты и сбои;
- как сопоставить статусы CANopen-процесса со статусами в RITMS UP2DATE;
- как обеспечить журналирование и повторяемость операции.

Именно поэтому шлюз становится полноценным участником жизненного цикла устройства.

RITMS UP2DATE выступает мозгом: формирует артефакты, управляет поэтапным rollout, отслеживает статусы устройств, ведёт детальный аудит и триггерит откаты.

Шлюз на базе CiA 302-3 — это руки и голос: транслирует команды в проводной контур, соблюдая промышленные требования к задержкам, пропускной способности и отказоустойчивости.

На верхнем уровне инженер формирует кампанию в RITMS UP2DATE:
- выбрать группу устройств;
- назначить нужную версию firmware;
- задать окно обновления;
- определить правила запуска;
- включить сбор статусов и аудит.

Дальше шлюз получает задание и начинает работать в своем домене:
1. Проверяет доступность CANopen-узлов.
2. Сопоставляет устройство с целевой firmware.
3. Переводит задание в процесс CiA 302-3.
4. Передает данные в промышленную сеть.
5. Контролирует этапы обновления.
6. Фиксирует ошибки, таймауты и подтверждения.
7. Возвращает результат в RITMS UP2DATE.

В итоге инженер видит не абстрактное «что-то отправили в сеть», а понятный статус жизненного цикла:
- обновление назначено;
- доставка начата;
- устройство обновляется;
- обновление завершено;
- требуется повтор;
- ошибка на конкретном этапе;
- устройство недоступно;
- версия подтверждена.

Самая сильная сторона такой архитектуры — правильное разделение ответственности.

RITMS UP2DATE отвечает за управление:
- политики;
- версии;
- кампании;
- аудит;
- группы устройств;
- статусы;
- интеграцию с ИТ-процессами.

Сетевая и промышленная инфраструктура отвечает за доставку:
- QoS;
- резервирование;
- маршрутизацию;
- сегментацию;
- доступность каналов;
- защиту периметра.

Шлюз CiA 302-3 отвечает за трансляцию в промышленную сеть:
- выполнение firmware update process;
- взаимодействие с CANopen-узлами;
- контроль этапов;
- обработку ошибок;
- возврат статусов наверх.

Такой подход не заставляет один инструмент делать всё. Вместо этого каждый слой делает то, для чего он предназначен.

Готовы ли ваши шлюзы "говорить" на языке промышленных стандартов, а не только проприетарных команд? Делитесь кейсами внедрения, задавайте вопросы по интеграции QoS и резервирования☕️

16:00 🌌 ВЕБИНАР УЖЕ СЕГОДНЯ !!! 🌌 16:00

Наш новый вебинар: OpenFB — Синергия классической автоматизации, IIoT и ИИ

Среда, 27 мая, 16:00

До сих пор интеграция мощных алгоритмов машинного обучения в реальное производство была сложной и дорогой задачей. Но, времена меняются.

Центр программных разработок РТСофт представляет своё видение того, как это можно сделать открыто, гибко и эффективно с помощью новой платформы OpenFB (открытая среда исполнения на базе стандарта IEC 61499 для Python).

📌Мы приглашаем вас на наш вебинар, где мы расскажем, как новая российская open-source платформа меняет привычный подход к автоматизации.

Регистрируйтесь по ссылке: https://rtsoft.timepad.ru/event/3993203/

🌌THIS IS THE LAST CALL 🌌

🌌Уже через час 🌌

Наш новый вебинар: OpenFB — Синергия классической автоматизации, IIoT и ИИ
Среда, 27 мая, 16:00

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

Уважаемые разработчики промышленного ПО, инженеры по автоматизации, специалисты, работающие со стандартом IEC 61499 и открытыми инструментами промышленного IoT, вашему вниманию предлагаем видеозапись прошедшего давеча вебинара

🐧«Поддержка крупных приложений управления с помощью Eclipse 4diac IDE»🐧

🔍 О чём рассказывают в видео:
- Управление библиотеками функциональных блоков: версионирование, зависимости, повторное использование кода.
- Рефакторинг приложений: переименование, изменение структур данных, безопасное обновление без нарушения работы системы.
- Интеграция с репозиториями (GitLab/GitHub) и автоматизация сборки/развёртывания через CI/CD-пайплайны.
- Отладка и тестирование функциональных блоков прямо в IDE.
- Компиляция проектов в C++ для запуска на устройстве 4diac FORTE (runtime-среда).

Практическая демонстрация:
- Создание и экспорт библиотеки блоков.
- Публикация в реестре пакетов.
- Импорт и использование библиотеки в другом проекте.
- Обновление версии библиотеки и обработка изменений в зависимых проектах.

А вот еще и презентация. Читайте на здоровье 🐧

Всем, кто еще не знаком с 4diac 3.0 (и не только) будет крайне интересно (много переработок было сделано по сравнению с вер.2хх). Обратим лишь особенное внимание, что релиз вер.3.2.х анонсируют уже на июнь!

Ждем ☕️

Уважаемые разработчики промышленного ПО! 

Публикуем первую часть нашего вебинара, посвященного обзору-анализу Eclipse 4diac и ForgeLogic.

Ссылка на YouTube
Ссылка на VK Видео

Внутри: Индустрия 4.0 и IEC 61499. История 4diac и ForgeLogic, обзор архитектуры, IDE и набора функций. Сходства и различия. Виды функциональных блоков. Смотрим, просвещаемся. И напоминаем, что:

16-17 июня 2026 г. мы проводим двухдневный профессиональный тренинг по Eclipse 4diac и ForgeLogic.
 
Подавайте заявку на участие тренинге на сайте, либо по электронной почте  rt.practic@dev.rtsoft.ru ☕️

АСУ ТП больше не остров, или Кибербезопасность в современной промавтоматизации 🤨

Мы решили поделиться июньскими тезисами с уважаемыми разработчиками промышленных систем.

Раньше промышленные сети (OT) были изолированы, и эта «воздушная прослойка» считалась надежной защитой. Но сейчас АСУ ТП все больше интегрируются в корпоративные сети, и, как предупреждает CISA, даже хакеры с базовыми навыками способны парализовать производство.

Данный пост касается исключительно информационной безопасности (Cybersecurity), важно не путать Security Level (SL) из IEC 62443 (уровни защиты от кибератак) и Safety Integrity Level (SIL) из стандартов функциональной безопасности (IEC 61508/61511). SIL отвечает за то, чтобы система не нанесла физического вреда людям или экологии при аппаратном сбое. Мы же говорим о защите данных и команд.

Как строить информационную защиту сегодня? Индустрия приходит к синергии двух подходов: IEC 62443 задает архитектурный каркас: делит сеть на зоны, определяет роли и задает базовые требования. Zero Trust («никому не доверяй, всегда проверяй») обеспечивает микросегментацию, строгую аутентификацию и непрерывный мониторинг трафика между этими зонами, не давая злоумышленнику перемещаться по сети (Lateral Movement).

Важное замечание по стандартам: IEC 62443 (в индустрии часто встречается опечатка «61443») хоть и используется как фундамент для открытых архитектур вроде O-PAS, но ограничиваться только им нельзя. Более современные идеи, сформулированные в стандартах NIST (и детально описанные в модели зрелости CISA ZTMM v2), тоже должны быть внедрены в производственную автоматизацию. Главная задача — адаптировать их с учетом жесткой специфики OT: приоритета бесперебойной доступности (High Availability) и обилия уязвимого legacy-оборудования.

Где почитать про NIST и ZT на русском? Если хотите глубоко разобраться в 5 столпах Zero Trust от CISA (Identity, Devices, Networks, Apps, Data) и посмотреть, как это применяют в IT индустрии, рекомендуем потрясающий русскоязычный ресурс: Zero Trust Book, где разобраны архитектуры NIST и даны практические лабораторные работы.

Однако применение стандартных ИТ-подходов к безопасности в ОТ-средах может быть неэффективным и даже опасным, поэтому на сцену выходит «Zero Trust Overlays» для OT, которые учитывают это и разработаны:

CISA (Cybersecurity and Infrastructure Security Agency) — через Zero Trust Maturity Model v2.0
DoD/DoW (Department of Defense/War) — через документ «Zero Trust for Operational Technology Activities and Outcomes»
NIST — на базе SP 800-207 (Zero Trust Architecture) и SP 800-82 Rev. 3 (Guide to OT Security)

Немного времени спустя в заметке про Zero Trust Overlays для OT расскажем, как реализовать синергию стандартов O-PAS и CISA/NIST для АСУТП.

Недавно на нашей площадке прошёл вебинар по OTA обновлениям, вызвавший инженерный ажиотаж: мы получили много вопросов, критики и слов поддержки. Любая обратная связь от вас - бесценна 😃

Вебинар получился большим и содержательным, содержит как анализ ОТА обновлений в целом, так и детали работы с RAUC, поэтому публикация тянет на целый сериал 🍿
 
Итак, Серия 1. Анализ OTA обновлений
Содержание: краткий обзор принципов удаленного обновления встроенных устройств и популярных систем обновления - Mender, Rauc, SWUpdate, OSTree. Критерии выбора для вашего устройства.

😊 YouTube ссылка
💙 VK ссылка

Приятного просмотра, уважаемые разработчики встраиваемых систем 🐧

Здравствуйте, хорошей пятницы желаем вам ☕️

Чуть ранее мы обещали рассказать, что такое «Zero Trust Overlays» для OT. Коротко - это специализированные наборы требований, активностей и результатов, которые адаптируют общие принципы архитектуры нулевого доверия (Zero Trust Architecture, ZTA) к уникальным условиям операционных технологий (OT) и промышленных систем управления (ICS).

⁉️Окей, а как это связано с реальным миром⁉️спросите вы, уважаемые разработчики промышленного ПО.

Связь с IEC 62443 и другими стандартами
OT Zero Trust Overlays не заменяют, а дополняют отраслевые стандарты. Грубо говоря интеграция фреймворков выглядит так:

IEC 62443 (Zones & Conduits)
↓
Zero Trust (Micro-segmentation + Continuous Verification)
↓
NIST RMF / DoD RMF (Risk Management)
↓
CISA ZTMM (Maturity Assessment & Roadmap)

IEC 62443-3-3: Требования к системной безопасности → реализуются через политики доступа Zero Trust
IEC 62443-4-2: Требования к компонентам → обеспечиваются через Root of Trust и защищённую загрузку
NIST SP 800-82 Rev. 3: Руководство по безопасности ОТ → предоставляет контекст для адаптации принципов ZTA

Ключевые отличия OT от IT, влияющие на Zero Trust
В первую очередь, это Приоритет целей и потребностей, если для IT предприятия это обычно конфиденциальность и целостность информации, то для Operational Technology (OT) это доступность и безопасность процессов, Риски для IT - это утечка данных, компрометация сервисов, а в ОТ - Физический ущерб, угроза жизни, остановка критической инфраструктуры

Оборудование в ОТ кардинально отличается от IT: в корпоративной сети оно стандартизированное, часто обновляемое, а в технологических процессах применяются легаси-системы, специализированные контроллеры (ПЛК), все оборудование предполагает долгосрочный жизненный цикл.

Протоколы информационного обмена - еще одно ключевое отличие: в Enterprise IT это стандартные TCP/IP (как правило HTTPS), а в ОТ это целый букет полевых протоколов, часто без встроенной аутентификации/шифрования.

Процедуры Обслуживания в Enterprise IT производятся ИТ-персоналом и как правило это автоматизированные обновления, в ОТ же Инженеры-технологи применяют строго поинструкции ручные процедуры, критически важны ограниченные окна обслуживания.

Уровни зрелости OT Zero Trust Overlays (Maturity Stages)
Традиционный (устаревший): Ручная настройка, статические политики, разрозненные решения. Пример для ОТ: Учёт пользователей в электронных таблицах, пароли без MFA

Начальный: базовая интеграция между столпами (см. Пять основных столпов (Pillars) Zero Trust): Внедрение MFA для операторов (MFA интегрирована с авторизованным сервисом учётных данных), инвентаризация активов (Создание инвентаря пользователей ОТ-среды, включая привилегированные и сервисные учётные записи)

Расширенный: Автоматизированные политики, централизованная видимость, кросс-платформенная координация. Пример для ОТ: Динамический доступ на основе ролей, SIEM для ОТ-событий

Оптимальный: Полная автоматизация, адаптивные политики в реальном времени, само-отчётные активы. Пример для ОТ: Непрерывная аутентификация (ОТ-решение PAM охватывает все критические сценарии использования), автоматическое реагирование на аномалии без вмешательства человека

Для остальных столпов (Устройств и Сетей), также как и для акторов применяются такие же принципы:

Полный учёт всех ОТ-активов с периодической верификацией,
Все неавторизованные подключения заблокированы технически или процедурно.
ОТ-среды соответствуют утверждённым стандартам, патчинг выполняется с тестированием рисков.
Микросегментация реализована для всех потоков данных в ОТ-среде.
Критический трафик защищён, ключи управляются централизованно.

Казалось бы, что еще по этой теме можно было бы сказать? Тем не менее, мы добавим в следующем лонгриде про то, как OT Overlays соотносятся с NIST SP 800-207 и 7 принципами Zero Trust.

Mender опубликовал отчёт о состоянии промышленного IoT в 2026 году. Там — кошмар 😱

60% производителей признают, что их инфраструктура управления устройствами не выдержит нагрузки в течение трёх лет. 71% рынка до сих пор работает на самописных или ручных решениях. Продукты усложняются: 90% OEM собирают устройства из нескольких компонентов с разными ОС и железом. Среднее время разработки — уже 54 месяца, и растёт. Плюс головная боль — регуляторика (в ЕС, напоминаем, есть Cyber Resilience Act; у нас, понятно, свои приколюхи есть).

Короче: амбиций много, инфраструктура не успевает, выбирайте профессиональные платформы RITMS UP2DATE, например ☕️

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

Публикуем вторую часть нашего вебинара, посвященного обзору-анализу Eclipse 4diac и ForgeLogic.

Внутри: Особенности подсистемы ввода-вывода 4diac и ForgeLogic, плагины ввода-вывода, , коммуникационные протоколы, поддержка MODBUS RTU, MQTT, OPC UA, интеграция с оркестратором и логгирование, работа с платами ввода-вывода.

😊Ссылка на YouTube
💙Ссылка на VK Видео

Напоминаем, что 16-17 июня 2026 г. мы проводим двухдневный профессиональный тренинг по Eclipse 4diac и ForgeLogic.
 
Подавайте заявку на участие тренинге на сайте, либо по электронной почте  rt.practic@dev.rtsoft.ru ☕️

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

NIST SP 800-207 определяет 7 фундаментальных принципов ZTA. OT-оверлеи адаптируют их следующим образом:

1. Все ресурсы считаются ресурсами: ПЛК, датчики, исполнительные механизмы — это «ресурсы», требующие защиты, даже если они не поддерживают стандартные протоколы безопасности

2. Вся коммуникация защищается: Шифрование применяется выборочно: приоритет — критическим каналам управления; для легаси-протоколов — компенсационные меры (физическая изоляция, шлюзы)

3. Доступ предоставляется посессионно: Для ОТ: сессионный доступ + процедурные подтверждения (например, физическое присутствие оператора для критических команд)

4. Доступ определяется динамической политикой: Политики учитывают не только идентичность, но и состояние процесса (например, запрет изменений во время аварийного режима)

5. Мониторинг целостности активов: Пассивный мониторинг трафика ОТ-протоколов + поведенческий анализ (UEBA) для выявления аномалий в работе оборудования

6. Динамическая аутентификация и авторизация: Многоуровневая аутентификация: цифровая + физическая (биометрия, proximity-карты) для критических действий

7. Сбор информации для улучшения безопасности: Агрегация логов из ОТ и ИТ в единый SIEM, но с фильтрацией по критичности для предотвращения «шума»

Отметим основные проблемы безопасности:

Легаси-оборудование не поддерживает современные протоколы аутентификации/шифрования
Требования к доступности ограничивают возможность перезагрузки или обновления
Специализированные протоколы (Modbus, DNP3) не имеют встроенных механизмов безопасности
Ну и барьеры между ИТ- и ОТ-командами (разные приоритеты, терминология, процессы)

Что можно сделать, или практический чек-лист по улучшениям:

✔️Оцените текущее состояние по модели CISA ZTMM (5 столпов × 4 уровня зрелости)
✔️Инвентаризируйте активы: пользователи, NPE, приложения, данные в ОТ-среде
✔️Определите критические процессы: какие системы требуют наивысшей доступности?
✔️Сегментируйте сеть: выделите зоны по функциям и уровням риска (Purdue Model L0-L5)
✔️Усильте аутентификацию: внедрите MFA для удалённого доступа и привилегированных учётных записей
✔️Настройте мониторинг: агрегируйте логи ОТ-протоколов в SIEM с правилами детектирования аномалий
✔️Разработайте процедуры: компенсирующие меры для систем, не поддерживающих технические контроли
✔️Тестируйте в изолированной среде: любые изменения в ОТ должны проходить валидацию перед внедрением

Пользуйтесь, пожалуйста 👍

Добрый вечер, уважаемые разработчики встраиваемых систем ☕️

Краткий обзор принципов удаленного обновления встроенных устройств и популярных систем обновления - Mender, Rauc, SWUpdate, OSTree вы увидели в первой серии нашего блокбастер-вебинара по OTA обновлениям. А теперь начинаем глубже разбираться c RAUC.

Серия 2. Общие принципы работы RAUC
Встраивание в U-Boot, конфигурационные файлы RAUC на устройстве.
😊 YouTube ссылка
💙 VK ссылка

Приятного просмотра, и... напоминаем, что совсем скоро у нас пройдет очередной суперкурс Создание встраиваемых систем на основе Embedded Linux.

Записывайтесь, пожалуйста 🐧