Übersicht über Azure Sphere-Anwendungen
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.
Azure Sphere-Geräte können zwei Arten von Anwendungen ausführen:
- Allgemeine Anwendungen werden in Containern unter dem Azure Sphere-Betriebssystem ausgeführt.
- Echtzeitanwendungen (RTApps) werden auf einem Bare-Metal-System oder mit einem Echtzeit-Betriebssystem (Real-Time Operating System, RTOS) auf den Echtzeitkernen ausgeführt.
Eine allgemeine Anwendung ist für jedes Azure Sphere-Gerät erforderlich. RTApps sind optional.
Allgemeine Anwendungen
Jedes Azure Sphere-Gerät verfügt über eine allgemeine Anwendung, die auf dem Azure Sphere-Betriebssystem ausgeführt wird und die Anwendungsbibliotheken verwenden kann. Eine allgemeine Anwendung kann Folgendes:
Konfigurieren von und Interagieren mit Azure Sphere-Peripheriegeräten, z. B. Stecker für die Allzweckeingabe/-ausgabe (General-Purpose Input/Output, GPIO), Universal-Asynchronous-Receiver-Transmitter-Schaltungen (UARTs) sowie andere Schnittstellen
Kommunizieren mit RTApps
Kommunizieren mit den internet- und cloudbasierten Diensten
Aushandeln von Vertrauensstellungen zu anderen Geräten und Diensten mithilfe der zertifikatbasierten Authentifizierung
Eine allgemeine Anwendung wird in einem Container im Normal World-Benutzermodus ausgeführt, wie unter Was ist Azure Sphere? beschrieben. Der Anwendungscontainer unterstützt eine Teilmenge der POSIX-Umgebung sowie einen Satz spezifischer Anwendungsbibliotheken (Applibs) für das Azure Sphere-Betriebssystem. Die für allgemeine Anwendungen verfügbaren Bibliotheken und Funktionen sind eingeschränkt, um sicherzustellen, dass die Plattform sicher bleibt und problemlos aktualisiert werden kann. Anwendungen können nur auf die von Microsoft bereitstellten Bibliotheken und Laufzeitdienste zugreifen. Direkte Datei-E/A und Shellzugriff sind nicht verfügbar (neben anderen Einschränkungen). Die Entwicklungsumgebung beschreibt den Basis-API-Satz und führt die Azure Sphere-Anwendungsbibliotheken ein, die gerätespezifische Features unterstützen.
Von allgemeinen Anwendungen wird erwartet, dass sie ohne Unterbrechung ausgeführt und automatisch neu gestartet werden, wenn sie beendet wurden oder ausfallen.
Erstellen Sie eine allgemeine Anwendung , die weitere Informationen zu Features bereitstellt.
Echtzeitanwendungen
Ein Azure Sphere-Gerät kann neben seiner allgemeinen Anwendung auch über Echtzeitanwendungen verfügen. Eine RTApp kann Folgendes:
- Die in die Azure Sphere-MPU integrierten Peripheriegeräte (etwa GPIO-Pins und UARTs) konfigurieren und mit ihnen interagieren
- Mit allgemeinen Anwendungen kommunizieren
RTApps können entweder auf einem Bare-Metal-System oder mit einem Echtzeitbetriebssystem (Real-Time Operating System, RTOS) ausgeführt werden. Das GitHub-Repository mit den Azure Sphere-Beispielen enthält ein Bare-Metal-Beispiel vom Typ „HelloWorld“ sowie ein Beispiel zur Veranschaulichung der kernübergreifenden Kommunikation zwischen allgemeinen Anwendungen und Echtzeitanwendungen (RTApps). Das Repository mit Azure-Beispielen auf GitHub enthält ein Beispiel, das die Verwendung von Azure Sphere mit Azure RTOS demonstriert.
Zusätzliche Treiber und Beispiele für RTApps für M4-Echtzeitkerne des MT3620-Chips werden auf GitHub von den Azure Sphere-Partnern MediaTek und Codethink bereitgestellt.
Jede RTApp wird isoliert auf einem bestimmten E/A-Kern ausgeführt und kann nur mit einer allgemeinen Anwendung kommunizieren. Sie kann weder das Internet noch die Azure Sphere-Applibs oder andere Features des Azure Sphere-Betriebssystems verwenden.
Erstellen Sie eine Echtzeit-fähige Anwendung bietet weitere Informationen zu den Features und Entwicklungsprozessen für RTApps.
Features, über die alle Anwendungen verfügen
Ungeachtet der beträchtlichen Unterschiede zwischen allgemeinen Apps und RTApps haben alle Azure Sphere-Anwendungen auch einige Dinge gemeinsam. Sie können beide Arten von Anwendungen mithilfe von Visual Studio oder Visual Studio Code oder durch Aufrufen von CMake und Ninja mithilfe der Befehlszeilenschnittstelle entwickeln, erstellen und debuggen.
Darüber hinaus stehen folgende Sicherheitsfunktionen sowohl für allgemeine Anwendungen als auch für RTApps zur Verfügung:
Anwendungsfunktionen
Jede Azure Sphere-Anwendung muss unabhängig von ihrem Ausführungsort die externen Dienste und Schnittstellen angeben, die sie benötigt (etwa ihre E/A- und Netzwerkanforderungen), um eine unbefugte oder unerwartete Nutzung zu verhindern.
Anwendungsfunktionen sind die Ressourcen, die eine Anwendung benötigt. Zu den Anwendungsfunktionen gehören unter anderem die von der Anwendung verwendeten Peripheriegeräte, die Internethosts, mit denen eine allgemeine Anwendung eine Verbindung herstellt, sowie Berechtigung zum Ändern der Netzwerkkonfiguration. Jede Anwendung muss über ein Anwendungsmanifest verfügen, das diese Ressourcen identifiziert.
Gerätefunktionen
Eine Gerätefunktion ermöglicht das Ausführen einer gerätespezifischen Aktivität. Gerätefunktionen werden vom Azure Sphere Security Service gewährt. Standardmäßig weisen die Azure Sphere-Chips keine Gerätefunktionen auf. Es gibt zwei Haupttypen von Gerätefunktionen: die AppDevelopment-Gerätefunktion und die FieldServicing-Gerätefunktion .
Die appDevelopment-Gerätefunktion ändert den Typ der Signatur, der das Gerät vertraut. Standardmäßig vertrauen Azure Sphere-Geräte für die Produktion signierten Paketen, jedoch keinen SDK-signierten Paketen. Daher können Sie ein SDK-signiertes Imagepaket nicht auf einem Azure Sphere Gerät querladen, das nicht über diese Funktion verfügt. Wenn die appDevelopment-Funktion vorhanden ist, vertraut das Gerät jedoch SDK-signierten Imagepaketen. Dadurch können Sie zudem eine Anwendung starten, beenden, debuggen oder vom Gerät zu entfernen. Zusammenfassend lässt sich sagen, dass die Anwendungsentwicklungsfunktion auf dem Gerät vorhanden sein muss, bevor Sie die folgenden Aufgaben ausführen können:
- Querladen eines Imagepakets, das mit Visual Studio oder mit dem Befehl azsphere image-package erstellt wurde.
- Starten, Beenden, Debuggen oder Entfernen eines Imagepakets aus dem Azure Sphere-Gerät, und zwar unabhängig davon, wie das Paket signiert wurde.
Der Befehl azsphere device enable-development erstellt die appDevelopment-Funktion und wendet sie an, und er verhindert, dass das Gerät Cloudanwendungsupdates empfängt.
Die FieldServicing-Funktion ermöglicht die Geräte-zu-Computer-Kommunikation auf Geräten, die sich im Fertigungszustand "DeviceComplete" befinden. Mit dieser Funktion können Sie produktionssignierte Bilder querladen, aber nicht löschen. Sie können Anwendungen starten und beenden, aber nicht debuggen. Sie können auch Routinewartungsaufgaben ausführen, z. B. das Konfigurieren von WLAN. Es ist für die kurzfristige Verwendung während einer Wartungssitzung vorgesehen, eine begrenzte Zeit, in der der Zugriff auf das Gerät pro Betrieb gewährt wird.
Signatur- und Bereitstellungsanforderungen
Alle Imagepakete, die auf einem Azure Sphere-Gerät bereitgestellt werden, müssen signiert werden. Das Azure Sphere SDK und der Befehl azsphere image package signieren Imagepakete zum Testen mithilfe eines SDK-Signaturschlüssels. Azure Sphere Geräte vertrauen diesem Schlüssel nur dann, wenn auch die appDevelopment-Gerätefunktion vorhanden ist.
Der Azure Sphere-Sicherheitsdienst signiert Imagepakete für die Produktion, wenn Sie sie in die Cloud hochladen. Für die Produktion signierte Pakete können OTA (Over-the-Air) quergeladen oder aus der Cloud geladen werden.
Um die Installation von nicht autorisierter Software zu verhindern, können Anwendungen auf einem Azure Sphere-Gerät nur auf zwei Arten geladen werden:
Querladen, das sowohl für die Softwareentwicklung als auch für tests und für die Feldwartung von Geräten verwendet werden kann. Das Querladen für die Softwareentwicklung und -tests erfordert die AppDevelopment-Gerätefunktion. Das Querladen für die Feldwartung erfordert die FieldServicing-Gerätefunktion und produktionssignierte Imagepakete. Sowohl Visual Studio als auch Visual Studio Code querladen Anwendungen während der Entwicklung und beim Debuggen; Sie können das Querladen auch manuell mithilfe der Azure Sphere CLI ausführen.
Cloudupdate, das nur vom Azure Sphere-Sicherheitsdienst durchgeführt werden kann. Verwenden Sie azure Sphere CLI, um Cloudbereitstellungen zu erstellen und zu verwalten.
Partneranwendungen
Anwendungen, die zusammenarbeiten, können als Partneranwendungen betrachtet und anschließend separat quergeladen werden. Wenn Sie eine Anwendung querladen, die über einen Partner verfügt, bleibt die Partneranwendung auf dem Azure Sphere-Gerät, wenn sie bereits bereitgestellt wurde. Jede Anwendung deklariert in ihrer Projektkonfiguration eine Liste mit den zugehörigen Partnern.
Geben Sie zum Hinzufügen von Partnern zur CMake-Projektkonfiguration die Komponenten-ID der Partner-App in der Datei „ launch.vs.json“ oder „.vscode/launch.json“ im Feld partnerComponents des Abschnitts configurations an.
"partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]
Allgemeine Apps und RTApps, die miteinander kommunizieren, müssen als Partner identifiziert werden. Azure Sphere unterstützt keine Kommunikation zwischen Paaren von High-Level-Apps oder -Paaren von RTApps.