Informationen zu Over-the-Air-Updates

Wichtig

Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.

Updates sind ein wichtiger Bestandteil des Azure Sphere-Sicherheitsmodells, da sie das Eigentum der erneuerbaren Sicherheit verkörpern. Sicherstellen, dass Updates regelmäßig durchgeführt werden, hilft Ihnen, Ihre Geräte mit 7-Eigenschaften kompatibel zu halten. Azure Sphere-Geräte suchen nach Updates, wenn sie sich nach dem Einschalten oder nach dem Drücken der Zurücksetzungstaste zum ersten Mal mit dem Internet verbinden. Danach erfolgen Prüfungen in regelmäßigen Abständen (derzeit 20 Stunden).

Es gibt drei Arten von Updates: erforderliche Updates, Betriebssystemupdates und Bereitstellungsupdates. Voraussetzungsupdates werden verwendet, um sicherzustellen, dass die Komponenten, auf denen sich der Updateprozess selbst stützt – derzeit der Vertrauenswürdige Schlüsselspeicher (Trusted Key Store, TKS) und der Zertifikatspeicher – auf dem neuesten Stand sind. Die TKS wird verwendet, um die herunterzuladenden und installierten Bilder zu authentifizieren, während der Zertifikatspeicher Internetverbindungen überprüft. Ein Betriebssystemupdate zielt auf die von Microsoft bereitgestellte Software auf dem Gerät ab, einschließlich des normalen Betriebssystems, in dem Ihre Anwendungen ausgeführt werden, aber auch Firmware auf niedrigerer Ebene wie das Pluton-Subsystem und den Sicherheitsmonitor. Bereitstellungsupdates richten sich an Ihre eigene Software – Ihre high-level- und Echtzeit-fähigen Anwendungen und Boardkonfigurationsimages (falls vorhanden). Voraussetzungen und Betriebssystemupdates werden von Azure Sphere verwaltet; Anwendungsupdates werden von Azure Sphere basierend auf Bereitstellungen koordiniert, die von Ihrer Organisation erstellt wurden.

Damit jedes Gerät erforderliche Updates oder Betriebssystemupdates empfängt:

• Sie müssen mit dem Internet verbunden sein.
• Netzwerkanforderungen müssen entsprechend konfiguriert werden.

Damit jedes Gerät seine Anwendungs- und Boardkonfigurationsimages aktualisieren kann:

• Sie darf nicht über die Anwendungsentwicklungsfunktion verfügen.
• Sie muss von einem Mandanten beansprucht werden.
• Sie muss zu einer Gerätegruppe gehören.
• Die Gerätegruppe, zu der sie gehört, muss von einer Bereitstellung adressiert werden.
• Die Bereitstellung muss Anwendungsimages (und optional ein Boardkonfigurationsimage) enthalten, das von oder im Auftrag Ihrer Organisation erstellt wurde.
• Die Gerätegruppe muss über die UpdateAll-Updaterichtlinie verfügen. Mit dem Befehl azsphere device-group update können Sie Anwendungsupdates für eine bestimmte Gerätegruppe deaktivieren.

Für alle Geräte in einer bestimmten Gerätegruppe werden Bereitstellungen, die auf diese Gerätegruppe abzielen, als Wahrheitsquelle für die Imageerstellung dieser Geräte betrachtet. Alle Bilder auf dem Gerät, die in der Bereitstellung nicht vorhanden sind, werden vom Gerät entfernt. Die einzige Ausnahme, ab Azure Sphere OS 21.04, besteht darin, dass Boardkonfigurationsimages nicht entfernt werden, es sei denn, sie werden durch ein neues Boardkonfigurationsimage ersetzt.

Die Überprüfung des Geräteupdates erfolgt in drei Phasen, die den drei Arten von Updates entsprechen:

• In der ersten Phase erhält Azure Sphere ein Manifest mit den aktuellen Versionen des TKS und Zertifikatspeichers. Wenn die TKS und der Zertifikatspeicher auf dem Gerät aktuell sind, wird das Update mit der zweiten Phase fortgesetzt. Andernfalls werden die aktuellen Images heruntergeladen und installiert.
• In der zweiten Phase erhält Azure Sphere ein Manifest mit den aktuellen Versionen der verschiedenen Betriebssystemkomponentenimages. Wenn alle Bilder auf dem Gerät veraltet sind, werden die aktuellen Bilder zusammen mit Rollbackimages heruntergeladen, die verwendet werden können, um das Gerät auf einen bekannten guten Zustand zurückzurufen, wenn der Updatevorgang fehlschlägt. Das Betriebssystem und rollbackimages werden heruntergeladen und in einem Stagingbereich auf dem Gerät gespeichert, dann werden die Betriebssystemimages installiert und das Gerät neu gestartet.
• In der dritten Phase sucht Azure Sphere nach Bereitstellungsupdates, wenn die Gerätegruppe sie akzeptiert. Wie beim Betriebssystemupdate werden auch Rollbackimages für die Anwendungen nach Bedarf bereitgestellt. Anwendungs- und Rollbackimages werden heruntergeladen und im Stagingbereich gespeichert, dann werden die Anwendungsimages installiert.

Updaterollback

Jeder Teil des Aktualisierungsprozesses enthält eine Rollbackoption. Im erforderlichen Update ist das Rollbackimage einfach eine Sicherung des Zustands vor dem Update. Wenn das Update fehlschlägt, wird der Zustand vor dem Update wiederhergestellt.

Rollback auf jeder Ebene erzwingt das Rollback auf allen höheren Ebenen: Wenn ein Firmwareimage nicht gestartet werden kann, werden sowohl die Firmware- als auch die Anwendungspartitionen zurückgesetzt.

Für das Betriebssystemupdate kann entweder ein Signaturüberprüfungsfehler oder Laufzeitprobleme ein Rollback auslösen. Bei einem Fehler bei der Signaturüberprüfung wird versucht, das Bild zu korrigieren; Wenn dies fehlschlägt, wird ein vollständiger Rollback ausgelöst. In einem vollständigen Rollback werden die mehrstufigen Rollbackimages sowohl für das Betriebssystem als auch für Anwendungen installiert.

Betriebssystemupdates und Bereitstellungen verfügen über unabhängige Veröffentlichungszyklen, sodass mehrere Bereitstellungen zwischen Betriebssystemupdates möglich sind. In diesem Fall ist es wichtig zu beachten, dass die Rollbackziele für die Bereitstellung nicht die neueste Bereitstellung, sondern die Bereitstellung zum Zeitpunkt des letzten Betriebssystemupdates sind. Dadurch wird sichergestellt, dass das Betriebssystem und die Anwendung im Rollbackzustand zusammenarbeiten.

Unterbrochene Updates

Wenn ein Update unterbrochen wird, z. B. durch einen Stromausfall oder verlust der Konnektivität, gibt es vier mögliche Szenarien für jeden Updatetyp:

• Wenn ein vollständiger Satz von Images erfolgreich heruntergeladen und bereitgestellt, aber noch nicht installiert wurde, wird die Installation abgeschlossen, wenn die Stromversorgung wiederhergestellt wird.
• Wenn einige, aber nicht alle Bilder heruntergeladen und bereitgestellt wurden, lädt das Update weiterhin fehlende Images herunter, und fahren Sie dann mit der Installation fort.
• Wenn ein Update während der Installation nach Abschluss des Downloads unterbrochen wird, wird die Installation beim Start neu gestartet.
• Wenn kein Image vollständig heruntergeladen wurde, beginnt der Updatevorgang neu, wenn der Strom wiederhergestellt wird, da nichts zur Installation bereit ist.

Updates in Power-Down-Szenarien

Azure Sphere unterstützt Szenarien mit geringer Leistung, mit denen Geräte für längere Zeiträume heruntergefahren werden können, um die Akkulaufzeit zu sparen. In solchen Szenarien ist es wichtig, dass das Gerät regelmäßig nach Updates suchen darf. Die Power Down-Beispielanwendung veranschaulicht, wie Sie den Stromverbrauch ordnungsgemäß reduzieren und gleichzeitig sicherstellen, dass das Gerät regelmäßig wach bleibt, um nach Betriebssystem- und App-Updates zu suchen.

Verzögerte Updates

Um zu verhindern, dass wichtige Vorgänge durch Updates unterbrochen werden, können anwendungen auf hoher Ebene verzögerte Updates integrieren. Mit diesem Feature kann die Anwendung ihre kritischen Aufgaben ausführen und sich dann auf das Herunterfahren vorbereiten, damit das Update fortgesetzt werden kann. Im Beispiel "DeferredUpdate" wird veranschaulicht, wie ein solches verzögertes Update implementiert wird.