Test del successo degli aggiornamenti Over the Air [chiuso]

10

Qual è la migliore pratica per garantire che un dispositivo IoT sia stato aggiornato correttamente?

Cosa è necessario fare per testare gli aggiornamenti OTA e autenticare i dispositivi? Facendo un ulteriore passo avanti, come è possibile monitorare / gestire le versioni del software (aggiornamenti) di una flotta di dispositivi IoT?

testing authentication over-the-air-updates

— Noam Hacker
fonte

1

Questo è troppo ampio, come l'altra tua domanda. E dipenderà molto dal tipo di dispositivo e dalla modalità di distribuzione.

— Gilles 'SO- smetti di essere malvagio' il

1

Quando dici "flotta", intendi una flotta di veicoli? In tal caso, presumo la comunicazione tramite SMS (crittografato) o HTTPS su GPRS o satellite di eventi, usando qualcosa come un modem SkyWave. se puoi modificare la tua domanda per chiarire, sono sicuro che verrà riaperta.

— Mawg dice di ripristinare Monica il

10

Ho un software (Windows Server - un po 'diverso da "cose" ma il principale è lo stesso) che chiama ogni 24 ore - restituisce vari metadati su se stesso:

nome cliente (o ID univoco)
versione software
data / ora della chiamata / richiesta
tipo di prodotto / ID

Il servizio Web analizza i dati e inserisce (o aggiorna se il cliente ha una riga esistente) una riga in un database.

In questo modo i nuovi clienti vengono aggiunti automaticamente al DB, i clienti esistenti ottengono il loro timestamp "ultimo accesso" aggiornato e abbiamo sempre la loro versione più recente del software. Posso eseguire query DB che mi dicono quali clienti sono nelle versioni precedenti e / o quali clienti non hanno chiamato per un po '.

Di recente abbiamo anche implementato un aggiornamento automatico (pensa all'aggiornamento OTA) e poiché questo è un processo critico, abbiamo implementato telemetria specifica per questo - che registra:

Versione corrente.
Versione da aggiornare.
Chi / quando autorizzato (se è richiesta l'accettazione del cliente).
Timestamp e codici di stato per ciascuno dei passaggi principali.

Questo ci consente di determinare se alcuni aspetti dell'aggiornamento automatico non riescono e in molti casi ci consente di chiamare il cliente spesso prima ancora che notino che qualcosa non va.

La grande differenza con "cose" è che in genere è limitato dalla memoria, quindi per fare un aggiornamento OTA xxx Kbdel firmware è necessario xxx Kb * 2disporre della memoria disponibile (firmware esistente + memoria sufficiente per memorizzare il nuovo firmware prima di iniziare l'aggiornamento del firmware effettivo)

— KennetRunner
fonte

1

grazie per la condivisione. L'uso della memoria è un punto importante da sottolineare. Come si procede per l'autorizzazione e l'accettazione da parte del cliente, quando applicabile? È richiesta una password per accettare un aggiornamento?

— Noam Hacker,

2

È un caso d'uso diverso (perché è Windows Server), ma abbiamo un'interfaccia utente che visualizza un avviso quando viene scaricato l'aggiornamento OTA: l'avviso chiede al cliente se desidera aggiornare (e include collegamenti per le note di rilascio ecc.). Su un thingdispositivo probabilmente farei lampeggiare un LED o qualcosa per avvisare l'utente (supponendo che tu voglia "consentire" l'aggiornamento) e poi fargli "premere a lungo" un pulsante per avviarlo ...

— KennetRunner

5

Ad esempio, è possibile effettuare una richiesta ogni X settimane / giorni / ore ... a un server con il numero di versione corrente del software. Dopo sarai in grado di utilizzare l'analisi per vedere la percentuale e il numero correnti di dispositivi aggiornati.

— WayToDoor
fonte

1

Questo account per i dispositivi che sono stati murati o non sono riusciti a completare un aggiornamento (forse bloccato in un riavvio, download, ciclo di crash?)

— Sean Houlihane

1

In un certo senso, sì. Se hai 100 dispositivi il giorno 1, invii l'aggiornamento il giorno 2 e il giorno 3 hai solo 25 dispositivi

— sull'analisi

1

Interessante. c'è un modo per differenziare i tipi di guasti?

— Noam Hacker,

1

dividere l'aggiornamento giù in passi discreti (ad esempio aggiungere nuovi valori di configurazione , gps riavvio , Set ID dispositivo , firmware sovrascrittura , ecc) con ciascuno che ha un inizio .. chiamata send 'casa' e completato con lo status di xx casa chiamata inviata. In questo modo puoi dire (approssimativamente) dove è fallito e (si spera) quale fosse il codice di stato.

— KennetRunner,

4

Si tratta di una politica di sincronizzazione intelligente

È necessaria una politica di sincronizzazione intelligente che funzioni in combinazione con l'approccio di roll-out dell'aggiornamento. Il momento più ovvio in cui il dispositivo IoT deve sincronizzare la sua versione è direttamente dopo l'aggiornamento . Il resto della pianificazione della sincronizzazione dipende fortemente dal tipo di dispositivo.

È sempre attivo e connesso tramite connessione cablata in cui una singola sincronizzazione non costa (molto) ha senso sincronizzarsi abbastanza periodicamente per mantenere aggiornati i dati sul dispositivo.

Se il dispositivo si trova da qualche parte ogni volta è costoso perché si utilizzano costose connessioni satellitari, la pianificazione della sincronizzazione deve adattarsi a tale circostanza.

Verifica della sincronizzazione

In un dispositivo sufficientemente avanzato (leggere una fascia di prezzo o un'area operativa che lo giustifica) ogni dispositivo potrebbe essere dotato di un certificato client che consente un controllo di autenticità della sincronizzazione.

Ad ogni modo, con i dispositivi del cliente finale avrai sempre i dispositivi che cadono dal radar a causa di batterie scariche, del dispositivo fuori uso o semplicemente del cliente che cambia la sua password wireless e non informa il dispositivo IoT. Questi potrebbero non dover fare nulla con il tuo aggiornamento, anche se cadono insieme in termini di tempistica.

— Helmar
fonte

Non credo che ciò dia una soluzione alla domanda del PO.

— WayToDoor,

@WayToDoor il mio primo paragrafo consiglia di sincronizzare direttamente dopo l'aggiornamento. Ciò fornisce le informazioni se la nuova versione è stata raggiunta correttamente. Eventuali contromisure se ciò non è avvenuto sono troppo ampie (e non richieste). Il resto della mia risposta riguarda il monitoraggio delle versioni sul campo. Quale domanda mi mancava?

— Helmar