Condividi tramite


Informazioni sugli aggiornamenti over-the-air

Importante

Questa è la documentazione di Azure Sphere (legacy). Azure Sphere (legacy) viene ritirato il 27 settembre 2027 e gli utenti devono eseguire la migrazione ad Azure Sphere (integrato) entro questo periodo. Usare il selettore di versione posizionato sopra il sommario per visualizzare la documentazione di Azure Sphere (integrata).

Gli aggiornamenti sono una parte importante del modello di sicurezza di Azure Sphere, poiché incorporano la proprietà della sicurezza rinnovabile. Assicurarsi che gli aggiornamenti vengano completati regolarmente consente di mantenere conformi i dispositivi a 7 proprietà . I dispositivi Azure Sphere controllano la disponibilità di aggiornamenti quando si connettono per la prima volta a Internet dopo l'accensione o dopo la pressione del pulsante Reimposta. Successivamente, i controlli vengono eseguiti a intervalli regolari (attualmente 20 ore).

Esistono tre tipi di aggiornamenti: aggiornamenti dei prerequisiti, aggiornamenti del sistema operativo e aggiornamenti della distribuzione. Gli aggiornamenti dei prerequisiti vengono usati per garantire che i componenti su cui si basa il processo di aggiornamento stesso, attualmente l'archivio chiavi attendibile e l'archivio certificati, siano aggiornati. Il servizio TKS viene usato per autenticare le immagini da scaricare e installare, mentre l'archivio certificati convalida le connessioni Internet. Un aggiornamento del sistema operativo è destinato al software fornito da Microsoft nel dispositivo, incluso il sistema operativo normale in cui vengono eseguite le applicazioni, ma anche firmware di livello inferiore, ad esempio il sottosistema Pluton e Il Monitoraggio della sicurezza. Gli aggiornamenti della distribuzione hanno come destinazione il proprio software, ovvero le applicazioni con funzionalità generali e in tempo reale e le immagini di configurazione della scheda (se presenti). I prerequisiti e gli aggiornamenti del sistema operativo vengono gestiti da Azure Sphere; gli aggiornamenti delle applicazioni sono coordinati da Azure Sphere in base alle distribuzioni create dall'organizzazione.

Per consentire a qualsiasi dispositivo di ricevere i prerequisiti o gli aggiornamenti del sistema operativo:

  • Deve essere connesso a Internet.
  • I requisiti di rete devono essere configurati in modo appropriato.

Per consentire a qualsiasi dispositivo di aggiornare le immagini di configurazione dell'applicazione e della scheda:

  • Non deve avere la funzionalità di sviluppo dell'applicazione.
  • Deve essere richiesto da un tenant.
  • Deve appartenere a un gruppo di dispositivi.
  • Il gruppo di dispositivi a cui appartiene deve essere destinato a una distribuzione.
  • La distribuzione deve contenere immagini dell'applicazione (e, facoltativamente, un'immagine di configurazione della scheda) creata da o per conto dell'organizzazione.
  • Il gruppo di dispositivi deve avere i criteri di aggiornamento UpdateAll. È possibile disabilitare gli aggiornamenti dell'applicazione per un gruppo di dispositivi specifico usando il comando azsphere device-group update.

Per tutti i dispositivi in un determinato gruppo di dispositivi, le distribuzioni destinate a tale gruppo di dispositivi sono considerate l'origine della verità per la creazione di immagini di tali dispositivi. Tutte le immagini nel dispositivo che non esistono nella distribuzione verranno rimosse dal dispositivo. L'unica eccezione, a partire dal sistema operativo Azure Sphere 21.04, è che le immagini di configurazione della scheda non vengono rimosse a meno che non vengano sostituite con una nuova immagine di configurazione della scheda.

Il controllo degli aggiornamenti del dispositivo viene eseguito in tre fasi corrispondenti ai tre tipi di aggiornamenti:

  • Nella prima fase, Azure Sphere ottiene un manifesto che elenca le versioni correnti del servizio Azure Kubernetes e dell'archivio certificati. Se il servizio Azure Kubernetes e l'archivio certificati nel dispositivo sono aggiornati, l'aggiornamento continua con la seconda fase. In caso contrario, le immagini correnti vengono scaricate e installate.
  • Nella seconda fase, Azure Sphere ottiene un manifesto che elenca le versioni correnti delle varie immagini del componente del sistema operativo. Se le immagini nel dispositivo non sono aggiornate, le immagini correnti vengono scaricate insieme alle immagini di rollback che possono essere usate per eseguire il rollback del dispositivo a uno stato valido noto se il processo di aggiornamento ha esito negativo. Le immagini del sistema operativo e del rollback vengono scaricate e archiviate in un'area di gestione temporanea nel dispositivo, quindi le immagini del sistema operativo vengono installate e il dispositivo viene riavviato.
  • Nella terza fase, Azure Sphere verifica la disponibilità di aggiornamenti della distribuzione se il gruppo di dispositivi li accetta. Come per l'aggiornamento del sistema operativo, anche le immagini di rollback per le applicazioni vengono gestite automaticamente in base alle esigenze. Le immagini di applicazione e rollback vengono scaricate e archiviate nell'area di gestione temporanea, quindi vengono installate le immagini dell'applicazione.

Aggiornamento del rollback

Ogni parte del processo di aggiornamento include un'opzione di rollback. Nell'aggiornamento dei prerequisiti, l'immagine di rollback è semplicemente un backup dello stato di pre-aggiornamento. Se l'aggiornamento non riesce, viene ripristinato lo stato di pre-aggiornamento.

Il rollback a qualsiasi livello forza il rollback a tutti i livelli superiori: se un'immagine del firmware non viene avviata, viene eseguito il rollback delle partizioni del firmware e dell'applicazione.

Per l'aggiornamento del sistema operativo, un errore di verifica della firma o problemi di runtime può attivare un rollback. In caso di errore di verifica della firma, viene effettuato un tentativo di correggere l'immagine; in caso di errore, viene attivato un rollback completo. In un rollback completo, le immagini di rollback a fasi vengono installate sia per il sistema operativo che per le applicazioni.

Gli aggiornamenti e le distribuzioni del sistema operativo hanno cicli di rilascio indipendenti, quindi è possibile che si verifichino più distribuzioni tra gli aggiornamenti del sistema operativo. In questo caso, è importante notare che le destinazioni di rollback per la distribuzione non sono la distribuzione più recente, ma piuttosto la distribuzione al momento dell'ultimo aggiornamento del sistema operativo. In questo modo, il sistema operativo e l'applicazione interagiscono nello stato di rollback.

Aggiornamenti interrotti

Se un aggiornamento viene interrotto, ad esempio da un'interruzione dell'alimentazione o dalla perdita di connettività, esistono quattro possibili scenari per ogni tipo di aggiornamento:

  • Se un set completo di immagini è stato scaricato correttamente e sottoposto a staging ma non ancora installato, l'installazione verrà completata al ripristino dell'alimentazione.
  • Se alcune immagini ma non tutte le immagini sono state scaricate e gestite in staging, l'aggiornamento continuerà a scaricare le immagini mancanti e quindi procedere all'installazione.
  • Se un aggiornamento viene interrotto durante l'installazione al termine del download, l'installazione verrà riavviata all'avvio.
  • Se non è stata scaricata completamente un'immagine, il processo di aggiornamento inizierà di nuovo quando viene ripristinata l'alimentazione, perché non sarà disponibile alcun elemento pronto per l'installazione.

Aggiornamenti negli scenari di risparmio di energia

Azure Sphere supporta scenari a basso consumo che consentono di spegnere i dispositivi per periodi prolungati per risparmiare durata della batteria. In questi scenari, è importante che il dispositivo possa controllare periodicamente la disponibilità di aggiornamenti. L'applicazione di esempio Power Down illustra come ridurre correttamente il consumo di energia, garantendo comunque che il dispositivo rimanga attivo periodicamente per verificare la presenza di aggiornamenti del sistema operativo e dell'app.

Aggiornamenti posticipati

Per evitare che le attività critiche vengano interrotte dagli aggiornamenti, le applicazioni di alto livello possono incorporare l'aggiornamento posticipato. Questa funzionalità consente all'applicazione di completare le attività critiche e quindi preparare l'arresto per consentire l'esecuzione dell'aggiornamento. L'esempio DeferredUpdate illustra come implementare tale aggiornamento posticipato.