ОТА-обновления встроенных устройств: архитектура, риски и практические решения

Одно из главных преимуществ ОТА-обновлений заключается в их скорости и экономичности. Если парк устройств обновляется вручную, специалист должен посетить каждый объект. Если речь о сотнях и тысячах устройств, такое обслуживание может занимать месяцы. При этом компания должна оплачивать работу инженера и организацию поездки. Если обновление требуется для устранения критической ошибки, которая привела к простою оборудования конечного пользователя, то из-за задержек потребитель также несет убытки. Обновление по воздуху позволяет установить новые версии ПО как на все устройства производителя разом, так и только на часть парка – например, на тестовую группу, – не выходя из офиса.

При этом ОТА-инфраструктура может фиксировать все шаги обновления: обновление предложено, скачано, проверено, установлено, запущено, подтверждено устройством или отменено механизмом восстановления. Из уравнения также устраняется человеческий фактор: при самостоятельном обновлении клиент может скачать не ту версию или неправильно установить высланный файл.

Сегодня ОТА играет роль основного канала массового обновления устройств, однако ручной способ может быть предпочтительнее, если:

• устройство находится в закрытом контуре и не подключено к внешним сетям;
• парк устройств очень мал, а обновления выходят редко;
• при перезапуске устройства рядом должен находиться квалифицированный специалист;
• после обновления прибор требует физической донастройки или калибровки.

Удаленное обновление прошивки может упростить обслуживание и поддержку разрабатываемого устройства, но следует заранее заложить OTA в архитектуру продукта. Если вам нужна помощь с проектированием такой системы, расскажите о проекте – мы поможем подобрать подходящую архитектуру и реализовать ее.

Процесс обновления по воздуху в наиболее полном варианте, включающем как обязательные, так и дополнительные этапы, выглядит так:

1. Публикация новой версии ПО
Разработчик собирает новую версию ПО, тестирует ее и публикует на сервере. Наряду с бинарным файлом прошивки также публикуются:

• Manifest-файл, который содержит метаданные и правила установки обновления.
• Криптографический хеш – идентификатор фиксированной длины, вычисляемый из файла прошивки. С его помощью можно определить, повредился ли файл во время скачивания и записи на флеш-память.
• Цифровая подпись, которая подтверждает, что обновление или manifest были одобрены разработчиком (владельцем закрытого ключа).

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

3. Проверка manifest-файла
Устройство проверяет manifest, чтобы понять:

• подходит ли обновление для его модели;
• допустима ли версия;
• хватает ли места и питания;
• не запрещено ли обновление политикой;
• подлинна ли подпись метаданных.

4. Скачивание образа прошивки
Если все в порядке, устройство скачивает пакет обновления. Это может быть полный образ новой прошивки или патч, который заменяет только те файлы, в которые разработчик внес изменения. Файл обычно загружается порциями (чанками), и в случае потери соединения устройство может возобновить загрузку.

5. Проверка целостности и подлинности
Устройство вычисляет хеш-сумму скачанного образа и сравнивает ее с хеш-суммой, указанной в manifest, чтобы проверить целостность файла. Также проверяется цифровая подпись прошивки, чтобы убедиться, что файл выпущен авторизованным разработчиком. Если не удается подтвердить, что файл выпущен доверенным разработчиком или что при скачивании часть данных не была утеряна, обновление не устанавливается.

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

7. Отчет на сервер
Если все в порядке, устройство отправляет на сервер отчет о том, что новая версия установлена и работает штатно.

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

Основные инженерные вызовы можно свести к следующим:

• нестабильная связь; 
• безопасность; 
• операционное управление релизами;
• откат изменений.

При обновлении по воздуху устройство может выйти из зоны покрытия сети или потерять соединение при переключении точки доступа Wi-Fi. Также владелец может иметь дорогой и лимитированный интернет-трафик. Поэтому загрузку файлов обновления обычно делят на порции (чанки) с возможностью возобновлять прерванную загрузку и скачивать файлы повторно.

Безопасное OTA строится на трех уровнях:

• Файл обновления подписывается цифровой подписью. Перед установкой нового образа прошивки устройство проверяет подпись. Если подпись неверна, образ не устанавливается. Одна из частых ошибок здесь – жестко закодировать (захардкодить) открытый ключ в устройстве, не предусмотрев механизма обновления открытого ключа.
• Канал передачи данных с сервера на устройство должен быть защищен. Обычно применяется протокол TLS 1.3, хотя допустимо использовать и TLS 1.2.
• Защита от атак понижения версии (downgrade-атак). Старая версия встроенного ПО может быть подлинной, но содержать уязвимость, которую устранили в новой версии. В этом случае политика обновлений должна запрещать откат к уязвимой старой версии.

Безопасность OTA не сводится только к шифрованию канала. Необходимо продумать пользовательские сценарии, управление ключами, их ротацию. Если эти вопросы актуальны для вашего устройства, расскажите о своем проекте, и наши специалисты помогут спроектировать безопасный механизм обновления встроенного ПО.

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

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

Недостаточно просто собрать образ новой прошивки на компьютере разработчика и положить его на сервер. Обновляемость все чаще рассматривается как часть полного жизненного цикла продукта, вплоть до послепродажной поддержки. И здесь важна предсказуемая схема версионирования, единая генерация бинарного файла, manifest-файла и др., автоматическое вычисление хешей и т.д. А это требует дисциплинированного конвейера развертывания.

При этом даже тщательно протестированный код может содержать дефект, который не проявился на тестовом стенде: редкая ревизия платы, особая конфигурация клиента, конфликты при миграции настроек. Поэтому обновлять сразу весь флот устройств может оказаться неудачной затеей.

После обновления лабораторных устройств стоит обновить небольшой “пилотный” парк приборов и затем постепенно расширять охват. При этом нужно следить за метриками и в случае проблем немедленно остановить процесс или откатить устройства на предыдущую версию.

Во время OTA-обновления у устройства может отключиться питание, закончиться заряд аккумулятора, зависнуть приложение, оборваться запись во флеш-память или сама новая версия может не запуститься. Если обновление прерывается на любом из этапов, система должна сохранять возможность откатиться к предыдущей версии ПО.

Поэтому надежная система ОТА-обновлений обычно подразумевает следующее:

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

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

Это самый простой вариант установки обновления, применяемый, когда на устройстве ограниченный объем памяти. В классической схеме, часто применяемой на микроконтроллерах, память разделена на области под неизменяемый загрузчик, собственно прошивку и пользовательские данные.

При обновлении новая версия прошивки сразу устанавливается в соответствующую область по мере скачивания – постепенно переписывая старый образ. Если питание отключится до завершения процесса, устройство “закирпичится”. В этом фундаментальный недостаток этой схемы. Однако, поскольку загрузчик при обновлении не стирается, устройство можно “оживить”, запустив процесс заново.

Более продвинутый вариант однослотовой схемы предполагает выделение в памяти отдельной области, куда сначала скачивается пакет обновления и откуда затем файл устанавливается в область прошивки.

Такой вариант позволяет запустить старую версию встроенного ПО, если что-то пошло не так во время скачивания пакета обновления – но только пока не началась запись новой версии прошивки на устройство.

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

Процесс обновления можно сделать устойчивее. Перед началом обновления устанавливается специальный флаг, указывающий на то, что процесс не завершен – update_in_progress = 1. После успешной записи нового образа он заменяется на update_in_progress = 0. Если процесс прерывается, то при запуске устройства загрузчик “видит”, что процесс не был завершен, и автоматически начинает запись образа заново.

В такой схеме в памяти устройства выделены две области для полноценных прошивок, из которых работает только одна. При обновлении новая версия перезаписывает неиспользуемую копию – например, в области B. При отключении питания загрузчик запускает старую версию из области А. По окончании записи и проверок меняется конфигурация загрузки: теперь загрузчик по умолчанию запускает прошивку из области B.

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

В этом случае загрузчик предпримет несколько попыток запустить новую версию прошивки и в случае неудачи, для распознавания которой применяется счетчик, вернется к предыдущей версии ПО.

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

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

В рамках одного из проектов наша команда спроектировала систему для удаленного управления оборудованием. Решение включает в себя контроллер, который управляет исполнительными механизмами, базовую станцию (хаб), с которой оператор передает команды на контроллер, и мобильное приложение. Так как заказчик предполагал использовать систему в зонах, где интернет недоступен, мы реализовали передачу команд и телеметрии между хабом и контроллерами по радиоканалу.

Разработанная для данного решения система обновления прошивки контроллеров значительно отличается от классической ОТА-архитектуры.

Нет привычного ОТА-сервера

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

Передача данных поверх Modbus RTU

В основе системы лежит собственный загрузчик и протокол передачи прошивки поверх Modbus RTU. Modbus работает через UART, подключенный к радиомодулю. Ограничения Modbus, в свою очередь, определяют всю механику обновлений.

• Классический Modbus RTU ограничивает размер PDU примерно 253 байтами. Поэтому прошивка передается не как HTTP-файл или поток байтов, а страницами размером до 4КБ. Каждая страница представляет последовательность отдельных Modbus-транзакций записи регистров. Контроллер собирает из переданных значений кусок прошивки, а при получении специальной команды записывает накопленные данные в буфер.
• Роль manifest-файла фактически выполняет заголовок DFU-образа. Один файл содержит и метаданные, и сам образ, поэтому отдельный manifest-файл не требуется. Это также упрощает процесс.
• Из-за ограничений бюджета команде пришлось отказаться от внедрения двухслотовой схемы. Если обновление не удалось, предыдущую версию автоматически восстановить нельзя. Устройство переходит в аварийный режим и ожидает новых команд по Modbus.
• Один и тот же обработчик update-регистров используется и в основном приложении, и в загрузчике. Поэтому устройство может скачивать обновления как во время нормальной работы, так и при неработающей прошивке, что повышает надежность механизма восстановления. Если прошивка оказалась нерабочей, загрузчик запрашивает новую прошивку по Modbus. Без этого единственным способом восстановления был бы физический доступ.

Такой подход хорошо иллюстрирует, что OTA не обязательно означает стандартную клиент-серверную схему обновлений. В данном случае OTA – это прежде всего способ доставить новый бинарный образ по радиоканалу и надежно записать его во флеш-память.

В другом проекте команда должна была реализовать ОТА-обновления устройств внутри Bluetooth mesh-сети.

Решение представляет собой систему для отслеживания местоположения активов и персонала в шахтах. Оно состоит из шлюза, который крепится на объекте или на поясе шахтера, и BLE-маячков, которые служат для определения координат шлюза. Данные передаются по mesh-сети, образуемой ретрансляторами.

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

Прошивка передается с сервера на шлюз, к которому подключена mesh-сеть, и распространяется по сети лавинообразно – от верхнего узла к нижнему. Процесс продолжается, пока файлы обновления не загрузятся на каждый ретранслятор. Только когда не остается нижестоящих узлов, устройства на самом нижнем ярусе запускают самообновление.

По завершении процесса узел отключается, и только тогда обновляется вышестоящее устройство. Таким образом, файл обновления распространяется по сети сверху вниз, но обновление распространяется снизу вверх. Это гарантирует, что все ретрансляторы получат обновление и сеть не развалится.

Если новая версия прошивки по какой-то причине не запускается, то узел откатывается к старой версии ПО. Однако после переподключения к сети, он “видит”, что у вышестоящего устройства более поздняя версия прошивки, и снова пытается обновиться. Получается бесконечный цикл. Чтобы такого не происходило, в этом случае верхний узел запрограммирован также откатиться к старой версии ПО. В результате от сети отключаются два узла, но в противном случае трафик в сети вырос бы до недопустимых объемов.

Если ретранслятор подключается к сети уже в процессе распространения новой версии прошивки, он игнорирует обновление. Когда верхний узел обновляется и перезапускается, нижестоящий (пропустивший обновление) заново подключается к сети, “видит” новую версию ПО у верхнего узла и запрашивает файл.