Тестирование успеха обновлений по воздуху [закрыто]

10

Какова оптимальная практика для успешного обновления устройства IoT?

Что нужно сделать, чтобы протестировать OTA-обновления и аутентифицировать устройства? Делая еще один шаг вперед, как вы можете контролировать / управлять версиями программного обеспечения (обновлениями) парка устройств IoT?

testing authentication over-the-air-updates Ноам Хакер
источник
1
Это слишком широко, как ваш другой вопрос. И это будет во многом зависеть от типа устройства и способа развертывания.
Жиль "ТАК ... перестать быть злым"
1
Когда вы говорите «автопарк», вы имеете в виду автопарк? Если это так, я предполагаю связь по (зашифрованному) SMS или HTTPS через GPRS или спутник событий, используя что-то вроде модема SkyWave. если вы можете отредактировать свой вопрос, чтобы уточнить, я уверен, что он будет вновь открыт.
Mawg говорит восстановить Monica

Ответы:

10

У меня есть программное обеспечение (Windows Server - немного отличающееся от «вещей», но основной принцип тот же), которое вызывает каждые 24 часа - оно отправляет обратно различные метаданные о себе:

  • имя клиента (или уникальный идентификатор)
  • версия программного обеспечения
  • отметка времени звонка / запроса
  • тип продукта / идентификатор

Веб-служба анализирует данные и вставляет (или обновляет, если у клиента есть существующая строка) строку в базе данных.

Таким образом, новый клиент автоматически добавляется в БД, существующие клиенты обновляют свою «последнюю увиденную» метку времени, и у нас всегда есть их последняя версия программного обеспечения. Я могу выполнять запросы к БД, которые сообщают мне, какие клиенты используют более старые версии и / или какие клиенты не обращались в течение некоторого времени.

Мы также недавно внедрили автоматическое обновление (например, обновление OTA), и потому что это очень важный процесс, мы внедрили для этого специальную телеметрию, которая записывает:

  • Текущая версия.
  • Версия для обновления.
  • Кто / когда это разрешил (если требуется согласие клиента).
  • Отметки времени и коды состояния для каждого из основных этапов.

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

Большая разница с «вещами» заключается в том, что вы, как правило, ограничены в памяти, поэтому для OTA-обновления xxx Kbпрошивки вам необходима xxx Kb * 2доступная память (существующая прошивка + достаточно памяти для хранения новой прошивки перед началом фактического обновления прошивки)

KennetRunner
источник
1
Спасибо, что поделился. Использование памяти является важным моментом, чтобы сделать. Как вы относитесь к авторизации и принятию клиента, когда это применимо? Требуется ли пароль для принятия обновления?
Ноам Хакер
2
Это другой вариант использования (потому что это Windows Server), но у нас есть пользовательский интерфейс, который выдает предупреждение при загрузке OTA-обновления - предупреждение спрашивает пользователя, хотят ли они обновить (и включает ссылки на заметки о выпуске и т. Д.). thingВозможно, на моем компьютере будет мигать светодиод или что-то, предупреждающее пользователя (при условии, что вы хотите, чтобы пользователь «разрешил» обновление), а затем
попросил
5

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

WayToDoor
источник
1
Это относится к устройствам, которые были заблокированы, или не смогли завершить обновление (возможно, застряли в цикле перезагрузки, загрузки, сбоя?)
Шон Хоулихейн
1
В некотором смысле, да. Если у вас есть 100 устройств в
первый
1
Это интересно. Есть ли способ различать типы сбоев?
Ноам Хакер
1
разбить обновление на отдельные этапы (например, добавить новые значения конфигурации , перезагрузить gps , установить идентификатор устройства , перезаписать прошивку и т. д.), каждый из которых имеет начальный .. вызов отправить «домой» и завершен со статусом хх вызов отправлен домой. Таким образом, вы можете сказать (примерно), где произошел сбой, и (надеюсь), каков был код состояния.
KennetRunner
4

Все дело в умной политике синхронизации

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

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

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

Проверка синхронизации

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

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

Хельмар
источник
Я не думаю, что это даст решение вопроса ОП.
WayToDoor
@WayToDoor мой первый абзац советует синхронизировать сразу после обновления. Это дает информацию, если новая версия была успешно достигнута. Возможные контрмеры, если этого не произошло, слишком широки (и не запрашиваются). Остальная часть моего ответа посвящена мониторингу версий на местах. Какой вопрос я пропустил?
Helmar