Читали свежую статью в Automaion World Industrial IoT Security: Designing OTA Updates That Recover From Failure? Если коротко (не рекламируя конкретного вендора), то там вот о чем:
Основная проблема
Каждый инженер, создающий промышленные Linux-устройства, сталкивается с вопросом: как обновлять оборудование, установленное в шкафах, на заводских цехах или удалённых объектах, без длительного простоя, выезда на место или риска превратить устройство в "кирпич"?
Промышленные устройства отличаются от разработческих плат: они труднодоступны, работают через ненадёжные сети и должны функционировать непрерывно годами. Неудачное обновление, внезапное отключение питания или приложение, не запускающееся после перезагрузки, могут превратить плановый релиз ПО в вызов сервисной службы.
Ключевая стратегия: A/B обновления
Фундаментальная идея надёжных OTA-обновлений проста: не заменяйте работающую операционную систему на месте. Вместо этого поддерживайте две загрузочные системы (A и B).
Как это работает:
Пока система A работает, обновление устанавливается в B
Устройство перезагружается и пытается запустить B
Если B успешно стартует и проходит проверки здоровья — она становится активной
Если не получается — устройство возвращается к A
Это избегает одного из самых больших рисков обновлений на месте: отключение питания может оставить систему неработоспособной. При A/B-обновлениях предыдущая система остаётся доступной во время установки новой.
Аппаратная избыточность имеет значение
Статья подчёркивает важное различие:
- Два раздела на одном диске — программная избыточность
- Два физически независимых накопителя — дополнительный уровень устойчивости
Приводится пример с dual-SD конфигурацией, где две полные системы находятся на двух независимых SD-картах. Микроконтроллер управляет маршрутизацией хранилища и может переключаться между ними. Это означает, что концепция A/B не ограничивается двумя разделами на одном устройстве хранения — каждая сторона может находиться на отдельном физическом носителе, оставляя систему восстановления доступной даже при отказе одного устройства.
Что происходит при сбое обновления?
Сценарий восстановления с dual-SD конфигурацией:
Обновление записывается на неактивную SD-карту
Вооружается механизм отката на основе watchdog
Система перезагружается с переключением карт
Обновлённая система загружается
Если она сообщает о здоровой работе — остаётся активной
Если многократно сбоит — система переключается обратно на предыдущую SD-карту
Важный момент про watchdog: Успешная загрузка Linux не обязательно означает, что продукт работает. В производственных системах heartbeat watchdog должен отражать здоровье приложения, а не просто доказывать, что userspace запущен.
Безопасность и прослеживаемость
Криптографические подписи: Откат защищает от плохого обновления, но не от несанкционированного. Производственные пакеты обновлений должны быть криптографически подписаны, устанавливая цепочку доверия между процессом релиза и развёрнутым устройством.
SBOM (Software Bill of Materials): Конвейер обновлений должен обеспечивать видимость того, что содержит каждый релиз. SBOM записывает программные компоненты и зависимости, включённые в релиз. При обнаружении уязвимости это помогает идентифицировать затронутые продукты и версии.
Всё логично. Для рекламного хука. Но возникает вопрос: а что если устройство подключено к системе управления не по стандартной IP-сети, а по промышленной шине CANopen? Там нет ни SSH, ни apt upgrade, ни двух SD-карт — только ограниченный по пропускной способности канал и специфические протоколы обмена.
Рассматриваем эту ситуацию в статье нашего блога — про "последнюю милю" доставки прошивки до контроллера по CANopen через стандарт CiA 302-3.
Ключевые моменты, которые мы разбираем:
- Передача прошивки через Segmented/Block SDO с подтверждением каждого блока
- Возможность продолжить обновление после временной потери связи
- Автоматический rollback при сбоях питания или ошибках проверки целостности
- Криптографические подписи и контроль целостности образа
- Интеграция с платформой оркестрации RITMS UP2DATE на базе Eclipse HawkBit
Ну и показываем, как промышленный шлюз становится исполнителем команд оркестратора, реализуя требования CiA 302-3 и возвращая результаты обратно в систему управления. В результате инженер работает не с низкоуровневыми CANopen-сообщениями, а с понятным жизненным циклом обновления устройства.
Читайте статью тут: https://outsource.rtsoft.ru/blog/ota-last-mile
Будем рады вашим реакциям и комментариям 🐧