Компоненты для облачных обновлений программного обеспечения в IoT

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

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

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

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

Подключение устройства

Существуют различные варианты подключения устройства к облачному сервису. С точки зрения архитектуры необходимо решить, должны ли устройства подключаться напрямую . в службу обновления программного обеспечения или косвенно через уровень подключения устройств (например, Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub и т. д.), который сам может быть службой решения IoT. Я сам очень верю в прямой подход, и мой продукт Bosch IoT Rollouts действительно поддерживает и то, и другое. Я объясню почему ниже.

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

Это интересный подход по двум причинам: во-первых, он значительно упрощает поддержание стабильности API канала обновления программного обеспечения, если вам не нужно беспокоиться обо всех бизнес-требованиях другого канала . Мы не должны забывать, что в IoT есть сценарии, в которых подключенные устройства могут работать в течение длительного времени без контакта с серверной частью. В некоторых случаях могут пройти годы, особенно между производством и первоначальным подключением. Поддерживать стабильность транспортного уровня в течение этого времени легко, но, конечно, это не относится к бизнес-уровню. Это особенно верно в отношении Интернета вещей, где многие облачные решения все еще находятся на ранних стадиях зрелости.

Во-вторых, наличие отдельного канала также позволяет разделить бизнес и обновлять функции на самом устройстве . Вы действительно хотите рискнуть потенциально сломанным стеком, особенно в сложном стеке (например, на шлюзе IoT), чтобы устранить проблему? И можно ли гарантировать, что он всегда сможет это сделать? Представьте себе сценарий, в котором у вас есть среда выполнения OSGi на вашем шлюзе с одним пакетом, который вызывает исключения нехватки памяти, и ваш клиент обновления программного обеспечения работает в той же среде выполнения. Результат может быть очень сложно предсказать.

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

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

Это дает большое преимущество упрощенной архитектуры подключения. Это также позволяет использовать стандарты протокола управления устройствами общего назначения (например, LWM2M, OMA-DM, TR-069), которые обычно включают обновления программного обеспечения только как часть своих стандартов. Кроме того, он позволяет использовать проприетарные протоколы, которые определяются самим устройством (производителем).

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

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

Второе решение об обновлении программного обеспечения в Интернете вещей в облаке связано с протоколом. Должен ли я использовать стандартный протокол управления устройствами или разработать собственный? Многие решения IoT в наши дни отдают предпочтение MQTT с настраиваемым протоколом поверх. Кроме того, многие из представленных на рынке уровней подключения к Интернету вещей также предлагают собственный протокол поверх HTTP, MQTT или AMQP.

Я лично считаю, что некоторые из стандартов имеют ценность и должны, по крайней мере, приниматься во внимание. OMA-DM v2 выглядит многообещающим, и у нас также есть некоторый опыт работы с LWM2M. Как всегда, стандарты предлагают хорошую основу, но обычно имеют ряд ограничений; особенно на ранних стадиях проекта Интернета вещей, это может добавить много сложностей. Однако хороший стандарт, охватывающий обновления программного обеспечения, позволит решению IoT иметь обновления программного обеспечения как функцию без необходимости писать даже одну строку кода, если и устройство, и служба обновления программного обеспечения поддерживают его в готовом виде.

И последнее, но не менее важное:есть вопрос об аутентификации устройства. Это, конечно, общий вопрос для любого решения IoT. Но особенно для пути прямой интеграции необходимо сделать выбор, можно ли использовать один и тот же механизм аутентификации для обновлений программного обеспечения и канала решения IoT. Я обычно выступаю за использование того же механизма. На самом деле это легко реализовать с помощью асимметричной аутентификации (например, сертификата X.509). Bosch IoT Rollouts поддерживает это для своего API прямой интеграции устройств, а также для большинства уровней подключения, обычно используемых в IoT. Если асимметричный вариант не подходит (что часто бывает с ограниченными встроенными устройствами), я бы порекомендовал использовать центральное (симметричное) хранилище ключей, которое может использоваться разными каналами.

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