Testando o sucesso das atualizações Over the Air [fechado]

10

Qual é a melhor prática para garantir que um dispositivo IoT tenha sido atualizado com sucesso?

O que você precisa fazer para testar as atualizações do OTA e autenticar dispositivos? Indo um passo adiante, como você pode monitorar / gerenciar as versões de software (atualizações) de uma frota de dispositivos IoT?

testing authentication over-the-air-updates Noam Hacker
fonte
11
Isso é muito amplo, como sua outra pergunta. E isso dependerá muito do tipo de dispositivo e modo de implantação.
Gilles 'SO- stop be evil'
11
Quando você diz "frota", você quer dizer uma frota de veículos? Nesse caso, presumo a comunicação por SMS (criptografado) ou HTTPS por GPRS ou satélite de eventos, usando algo como um modem SkyWave. se você puder editar sua pergunta para esclarecer, tenho certeza de que ela será reaberta.
Mawg diz que restabelece Monica

Respostas:

10

Eu tenho um software (Windows Server - um pouco diferente de 'coisas', mas o principal é o mesmo) que liga a cada 24 horas - ele envia vários metadados sobre si:

  • nome do cliente (ou ID exclusivo)
  • versão do software
  • registro de data e hora da chamada / solicitação
  • tipo / ID do produto

O serviço da Web analisa os dados e insere (ou atualiza se o cliente tiver uma linha existente) uma linha em um banco de dados.

Dessa forma, novos clientes são adicionados automaticamente ao banco de dados, os clientes existentes atualizam o carimbo de data / hora da última vez que visualizamos e sempre temos a versão mais recente do software. Posso executar consultas de banco de dados que me informam quais clientes estão em versões mais antigas e / ou quais clientes não ligaram por um tempo.

Também implementamos uma atualização automática (pense na atualização OTA) recentemente e, por ser um processo crítico, implementamos telemetria específica para isso - que registra:

  • Versão Atual.
  • Versão a ser atualizada para.
  • Quem / quando autorizou (se a aceitação do cliente for necessária).
  • Carimbos de data e hora e códigos de status para cada uma das principais etapas.

Isso nos permite determinar se certos aspectos da atualização automática estão falhando e, em muitos casos, permite ligar para o cliente com frequência antes mesmo de perceber que algo está errado.

A grande diferença com 'coisas' é que você normalmente tem memória limitada; portanto, para fazer uma atualização OTA xxx Kbdo firmware, você precisa xxx Kb * 2de memória disponível (firmware existente + memória suficiente para armazenar o novo firmware antes de iniciar a atualização real do firmware)

KennetRunner
fonte
11
obrigado por compartilhar. O uso da memória é um ponto importante a ser destacado. Como você autoriza e aceita o cliente, quando aplicável? Você precisa de uma senha para aceitar uma atualização?
Noam Hacker
2
É um caso de uso diferente (porque é o Windows Server), mas temos uma interface do usuário que exibe um alerta quando a atualização do OTA é baixada - o alerta pergunta ao cliente se ele deseja atualizar (e inclui links para notas de versão etc.). Em um, thingeu provavelmente piscaria um LED ou algo assim para alertar o usuário (supondo que você desejasse que o usuário 'permitisse' a atualização) e, em seguida, pressionasse um botão para iniciá-lo ...
KennetRunner
5

Você pode, por exemplo, fazer uma solicitação a cada X semanas / dias / horas ... para um servidor com o número da versão atual do software. Depois, você poderá usar o analytics para ver a porcentagem e o número atuais de dispositivos atualizados.

WayToDoor
fonte
11
Será que isso conta para dispositivos que tenham sido emparedada, ou não conseguiram completar uma atualização (talvez preso em uma reinicialização, download, ciclo acidente?)
Sean Houlihane
11
De certa forma, sim. Se você tem 100 dispositivos no dia 1, você empurra atualização no dia 2 e dia 3 você tem apenas 25 dispositivos em análise, isso significa que algo de ruim aconteceu
WayToDoor
11
isso é interessante. existe uma maneira de diferenciar entre tipos de falhas?
Noam Hacker
11
dividir a atualização em etapas discretas (por exemplo, adicionar novos valores de configuração , gps de reinicialização , definir ID do dispositivo , firmware de substituição , etc) com cada um tendo um começando .. chamada Enviar 'home' e concluída com o status xx casa chamada enviado. Dessa forma, você pode dizer (aproximadamente) onde ela falhou e (espero) qual era o código de status.
KennetRunner
4

É uma política de sincronização inteligente

Você precisa de uma política de sincronização inteligente que funcione em conjunto com a abordagem de implementação da atualização. O momento mais óbvio em que o dispositivo IoT deve sincronizar sua versão é diretamente após a atualização . O restante do cronograma de sincronização é altamente dependente do tipo de dispositivo.

Está sempre ligado e conectado via conexão a cabo, onde uma única sincronização não custa (muito), faz sentido sincronizar periodicamente para manter seus dados atualizados sobre o dispositivo.

Se o dispositivo estiver em algum lugar onde tudo é caro, porque você está usando conexões via satélite caras, a programação de sincronização deve acomodar essa circunstância.

Verificação da sincronização

Em um dispositivo suficientemente avançado (leia uma faixa de preço ou área de operação que o justifique), cada dispositivo pode ser equipado com um certificado de cliente que permita uma verificação de autenticidade da sincronização.

De qualquer forma, com dispositivos do cliente final, você sempre terá os dispositivos caídos do radar devido a pilhas esgotadas, o dispositivo ficando fora de uso ou simplesmente o cliente alterando sua senha sem fio e não informando o dispositivo IoT. Talvez eles não precisem fazer nada com a sua atualização, mesmo que caiam juntos no tempo.

Helmar
fonte
Eu não acho que isso dê uma solução para a questão do OP.
WayToDoor
@WayToDoor meu primeiro parágrafo aconselha a sincronização direta após a atualização. Isso fornece as informações se a nova versão foi alcançada com sucesso. As possíveis medidas contrárias, se esse não for o caso, são muito amplas (e não solicitadas). O restante da minha resposta trata do monitoramento das versões em campo. Qual pergunta eu perdi?
Helmar