Componentes para atualizações de software baseado em nuvem na IoT

Atualizar software (componentes) em dispositivos de borda restrita, bem como em controladores e gateways mais poderosos é um requisito comum na maioria dos cenários de IoT.

Ter recursos de atualização de software garante uma IoT segura ao dar aos projetos IoT uma chance de lutar contra a caixa de Pandora, eles abriram no momento em que seus dispositivos foram conectados . A partir desse momento, os dispositivos estão na vanguarda das ameaças à segurança de TI, que, historicamente, muitos desenvolvedores de software embarcado nunca tiveram que enfrentar. Hoje em dia, distribuir, digamos, um dispositivo conectado à web com Linux sem que nenhuma atualização de segurança tenha sido aplicada durante sua vida útil é semelhante a um suicídio.

Um argumento mais charmoso para atualizações de software é que elas permitem o desenvolvimento ágil de hardware e componentes relacionados a hardware. Conceitos como produto mínimo viável podem ser aplicados aos dispositivos, pois nem todos os recursos precisam estar prontos no momento da fabricação. As mudanças no lado da nuvem da solução IoT também podem ser aplicadas aos dispositivos em tempo de execução.

Às vezes, a atualização de software é um modelo de negócio por si só, pois os dispositivos são muito mais atraentes para o cliente se forem atualizáveis. Em outras palavras, os consumidores sabem que não apenas obtêm um conjunto fixo de recursos, mas também podem esperar se beneficiar de futuras atualizações de produtos. Além disso, novos fluxos de receita podem surgir da monetização potencial de extensões de recursos (por exemplo, aplicativos ) sem a necessidade de projetar, fabricar e enviar um novo dispositivo (revisão).

Conectividade do dispositivo

Existem várias opções para conectar um dispositivo a um serviço em nuvem. De uma perspectiva arquitetônica, deve-se decidir se os dispositivos devem se conectar diretamente para o serviço de atualização de software ou indiretamente por meio de uma camada de conectividade do dispositivo (por exemplo, Hub IoT Bosch, IoT AWS, IBM Watson IoT, Hub IoT Azure, etc.), que por si só também poderia ser um serviço de solução IoT. Eu mesmo acredito muito na abordagem direta, e meu produto Bosch IoT Rollouts na verdade oferece suporte a ambos. Vou explicar o porquê abaixo.

Então, vamos começar:a conectividade direta permitirá que as soluções de IoT tenham uma separação de interesses, tendo canais distintos para atualizações de software, além de seu próprio canal que as soluções de IoT usam para fluxos de eventos e comandos do dispositivo.

Esta é uma abordagem interessante por dois motivos: primeiro, torna muito mais fácil manter estável a API do canal de atualização de software se você não precisa se preocupar com todos os requisitos de negócios do outro canal . Não devemos esquecer que existem cenários na IoT em que os dispositivos conectados podem permanecer por longos períodos sem contato com o back-end. Em alguns casos, pode levar anos, especialmente entre a fabricação e a conectividade inicial. Manter uma camada de transporte estável por esse período é fácil, mas certamente não é o caso da camada de negócios. Isso é especialmente verdadeiro na IoT, onde muitas soluções de nuvem ainda estão nas fases iniciais de maturidade.

Em segundo lugar, ter um canal separado também permite que você separe os negócios e atualize a funcionalidade no próprio dispositivo . Especialmente em uma pilha complexa (por exemplo, em um gateway IoT), você realmente quer arriscar uma pilha potencialmente quebrada tendo que se atualizar para corrigir o problema? E pode-se garantir que sempre será capaz de fazer isso? Imagine um cenário onde você tem um tempo de execução OSGi em seu gateway com um pacote que causa exceções de falta de memória e seu cliente de atualização de software é executado no mesmo tempo de execução. Pode ser muito difícil prever o resultado.

No entanto, a separação tem um preço:dois canais geralmente significam maior esforço de implementação no lado do dispositivo e, em alguns cenários, também pode aumentar o consumo de seu orçamento de tráfego ou a vida útil da bateria.

A segunda opção é combinar os casos de uso em um único canal. Chamamos isso de indireto integração com o serviço de atualização de software, já que a camada de conectividade em nuvem está realmente conectada ao dispositivo e tem que separar a solução do tráfego de atualização na nuvem.

Isso tem o grande benefício de uma arquitetura de conectividade simplificada. Também permite o aproveitamento de padrões de protocolo de gerenciamento de dispositivos de uso geral (por exemplo, LWM2M, OMA-DM, TR-069), que geralmente incluem atualizações de software apenas como uma subseção de seus padrões. Além disso, permite o uso de protocolos proprietários que são definidos pelo próprio dispositivo (fabricante).

No final do dia, o engenheiro de solução de IoT tem uma escolha a fazer:separação de interesses x simplicidade. Com nossos implementos de IoT da Bosch, decidimos oferecer suporte a ambas as opções e temos clientes que usam ambas. A conectividade direta acabou sendo muito mais fácil de manter para a solução IoT, enquanto a conectividade indireta adiciona muita complexidade à arquitetura geral.

No entanto, a maioria dos engenheiros de IoT inclui problemas de atualização de software em seu processo de design muito tarde no projeto, já que na maioria dos casos isso não faz parte da função principal do negócio e, quando chegam lá, não querem fazer mais alterações para sua arquitetura. Como resultado, a maioria das soluções usa a abordagem indireta, potencialmente sofrendo as consequências após o go-live.

A segunda decisão para atualizações de software baseadas em nuvem na IoT está relacionada ao protocolo. Devo escolher um protocolo de gerenciamento de dispositivo padrão ou projetar um personalizado? Muitas soluções de IoT atualmente favorecem o MQTT com um protocolo customizado no topo. Além disso, muitas das camadas de conectividade IoT no mercado também oferecem um protocolo proprietário além de HTTP, MQTT ou AMQP.

Pessoalmente, acredito que alguns dos padrões têm valor e devem pelo menos ser considerados. OMA-DM v2 parece promissor e também temos alguma experiência com o LWM2M. Como sempre, os padrões oferecem uma boa estrutura, mas geralmente vêm com um conjunto de restrições; especialmente nos estágios iniciais de um projeto de IoT, isso pode adicionar muita complexidade. No entanto, um bom padrão que cobre as atualizações de software permitirá que a solução IoT tenha atualizações de software como uma função sem a necessidade de escrever nem mesmo uma linha de código, se tanto o dispositivo quanto o serviço de atualização de software suportarem prontamente.

Por último, mas não menos importante, há a questão da autenticação do dispositivo. Esta é, obviamente, uma questão geral para todas as soluções de IoT. Mas, especialmente para o caminho de integração direta, a escolha deve ser feita se o mesmo mecanismo de autenticação pode ser usado para atualizações de software e o canal de solução IoT. Normalmente defendo o uso do mesmo mecanismo. Na verdade, isso é fácil de implementar com autenticação assimétrica (por exemplo, certificado X.509). O Bosch IoT Rollouts suporta isso para sua API Direct Device Integration, bem como para a maioria das camadas de conectividade normalmente usadas na IoT. Se assimétrico não for uma opção (o que geralmente é o caso com dispositivos incorporados restritos), eu recomendaria ir para um armazenamento de chave central (simétrico) que pode ser usado por diferentes canais.

Como apontado acima, há escolhas que devem ser feitas e perguntas a serem respondidas. Infelizmente, a IoT ainda não está em um estado em que encontramos uma arquitetura que se encaixa pelo menos na maioria dos cenários. A boa notícia, no entanto, é que existem opções e funcionam.