Übersicht über Azure Sphere-Anwendungen

Azure Sphere-Geräte können zwei Arten von Anwendungen ausführen:

  • Allgemeine Anwendungen werden containerisiert unter dem Azure Sphere-Betriebssystem ausgeführt
  • Echtzeitfähige Anwendungen (RTApps) werden auf Bare-Metal oder mit einem Echtzeitbetriebssystem (Real-Time Operating System, RTOS) auf den Echtzeitkernen ausgeführt.

Für jedes Azure Sphere-Gerät ist eine allgemeine Anwendung erforderlich. RTApps sind optional.

Allgemeine Anwendungen

Jedes Azure Sphere-Gerät verfügt über eine allgemeine Anwendung, die unter dem Azure Sphere-Betriebssystem ausgeführt wird und die Anwendungsbibliotheken verwenden kann. Eine allgemeine Anwendung kann:

  • Konfigurieren und Interagieren mit Azure Sphere-Peripheriegeräten, z. B. GPIO-Pins (General-Purpose Input/Output), Universelle asynchrone Empfänger/Sender (UARTs) und andere Schnittstellen

  • Kommunizieren mit RTApps

  • Kommunizieren mit dem Internet und cloudbasierten Diensten

  • Broker-Vertrauensstellungen mit anderen Geräten und Diensten über zertifikatbasierte 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 und eine Reihe von Anwendungsbibliotheken (Applibs), die für das Azure Sphere-Betriebssystem spezifisch sind. Die Bibliotheken und Funktionen, die für allgemeine Anwendungen verfügbar sind, sind eingeschränkt, um sicherzustellen, dass die Plattform sicher bleibt und einfach aktualisiert werden kann. Anwendungen können nur auf die Von Microsoft bereitgestellten Bibliotheken und Laufzeitdienste zugreifen. Neben anderen Einschränkungen sind weder direkter Datei-E/A-Zugriff noch Shellzugriff verfügbar. Die Entwicklungsumgebung beschreibt den BASIS-API-Satz und führt die Azure Sphere-Anwendungsbibliotheken ein, die gerätespezifische Features unterstützen.

Es wird erwartet, dass allgemeine Anwendungen kontinuierlich ausgeführt werden und automatisch neu gestartet werden, wenn sie beendet werden oder fehlschlagen.

Erstellen einer allgemeinen Anwendung bietet weitere Informationen zu Features.

Echtzeitfähige Anwendungen

Ein Azure Sphere-Gerät kann zusätzlich zu seiner allgemeinen Anwendung auch über eine oder mehrere Echtzeitanwendungen verfügen. Eine RTApp kann:

  • Konfigurieren und Interagieren mit Peripheriegeräten, die in die Azure Sphere-MCU integriert sind, z. B. GPIO-Pins und UARTs
  • Kommunikation mit allgemeinen Anwendungen

RTApps können entweder auf Bare-Metal oder mit einem Echtzeitbetriebssystem (Real-Time Operating System, RTOS) ausgeführt werden. Das Azure Sphere-Beispielrepository auf GitHub enthält ein Bare-Metal-HelloWorld-Beispiel sowie ein Beispiel, das die Kommunikation zwischen Kernen zwischen high-level und RTApps veranschaulicht. Das Azure-Beispielrepository auf GitHub enthält ein Beispiel, das zeigt, wie Azure Sphere mit Azure RTOS verwendet wird.

Weitere Treiber und Beispiele für RTApps, die auf die M4-Echtzeitkerne auf dem MT3620-Chip abzielen, sind auf GitHub von Den Azure Sphere-Partnern MediaTek und Codethink verfügbar.

Jede RTApp wird isoliert auf einem bestimmten E/A-Kern ausgeführt und kann nur mit einer allgemeinen Anwendung kommunizieren. Das Internet, die Azure Sphere-Applibs oder andere Features des Azure Sphere-Betriebssystems können nicht verwendet werden.

Erstellen einer Echtzeitanwendung bietet weitere Informationen zu den Features und dem Entwicklungsprozess für RTApps.

Features, die für alle Anwendungen gemeinsam sind

Trotz der erheblichen Unterschiede zwischen allgemeinen Apps und RTApps haben alle Azure Sphere-Anwendungen einige Gemeinsamkeiten. Sie können beide Arten von Anwendungen mithilfe von Visual Studio oder Visual Studio Code oder durch Aufrufen von CMake und Ninja mithilfe der CLI entwickeln, erstellen und debuggen.

Darüber hinaus gelten die folgenden Sicherheitsfeatures sowohl für allgemeine Als auch für RTApps:

Anwendungsfunktionen

Unabhängig davon, wo sie ausgeführt wird, muss jede Azure Sphere-Anwendung die externen Dienste und Schnittstellen angeben, die sie benötigt, z. B. ihre E/A- und Netzwerkanforderungen, um eine nicht autorisierte oder unerwartete Verwendung zu verhindern.

Anwendungsfunktionen sind die Ressourcen, die eine Anwendung benötigt. Zu den Anwendungsfunktionen gehören unter anderem die von der Anwendung genutzten Peripheriegeräte, die Internethosts, mit denen eine allgemeine Anwendung eine Verbindung herstellt, und die Berechtigung zum Ändern der Netzwerkkonfiguration. Jede Anwendung muss über ein Anwendungsmanifest verfügen, das diese Ressourcen identifiziert.

Gerätefunktionen

Eine Gerätefunktion ermöglicht eine gerätespezifische Aktivität. Gerätefunktionen werden vom Azure Sphere-Sicherheitsdienst gewährt. Standardmäßig verfügen Azure Sphere-Chips über keine Gerätefunktionen. Es gibt zwei Standard Arten von Gerätefunktionen: die AppDevelopment-Gerätefunktion und die FieldServicing-Gerätefunktion.

Die AppDevelopment-Gerätefunktion ändert den Typ der Signatur, dem das Gerät vertraut. Standardmäßig vertrauen Azure Sphere-Geräte produktionssignierten Imagepaketen, aber keine MIT SDK signierten Imagepaketen. Daher können Sie kein mit dem SDK signiertes Imagepaket auf ein Azure Sphere-Gerät querladen, das nicht über diese Funktion verfügt. Wenn die AppDevelopment-Funktion vorhanden ist, vertraut das Gerät jedoch sdksignierten Imagepaketen. Darüber hinaus können Sie eine Anwendung starten, beenden, debuggen oder vom Gerät entfernen. Zusammenfassend muss die Anwendungsentwicklungsfunktion auf dem Gerät vorhanden sein, bevor Folgendes möglich ist:

  • Querladen eines Imagepakets, das von Visual Studio oder dem Befehl azsphere image-package erstellt wurde.
  • Starten, Beenden, Debuggen oder Entfernen eines Imagepakets vom Azure Sphere-Gerät, unabhängig davon, wie das Imagepaket signiert ist.

Der Befehl az sphere device enable-development erstellt und wendet die AppDevelopment-Funktion an und verhindert, dass das Gerät Cloudanwendungsupdates empfängt.

Die fieldServicing-Funktion ermöglicht die Kommunikation zwischen Geräten, die sich im DeviceComplete-Fertigungszustand befinden. Mit dieser Funktion können Sie in der Produktion signierte Images querladen, aber nicht löschen. Sie können Anwendungen starten und beenden, aber nicht debuggen. Sie können auch routinemäßige Wartungsaufgaben ausführen, z. B. das Konfigurieren von WLAN. Es ist für den kurzfristigen Gebrauch während einer Wartungssitzung vorgesehen, in einem begrenzten Zeitraum, in dem der Zugriff auf das Gerät pro Vorgang gewährt wird.

Signierungs- und Bereitstellungsanforderungen

Alle Imagepakete, die auf einem Azure Sphere-Gerät bereitgestellt werden, müssen signiert werden. Das Azure Sphere SDK und der Befehl az sphere image-package sign image packages for testing by using an SDK signing key .The Azure Sphere SDK and the az sphere image-package command sign image packages for testing by using an SDK signing key. Azure Sphere-Geräte vertrauen diesem Schlüssel nur, wenn die AppDevelopment-Gerätefunktion ebenfalls vorhanden ist.

Die Produktion des Azure Sphere-Sicherheitsdiensts signiert Imagepakete, wenn Sie sie in die Cloud hochladen. In der Produktion signierte Imagepakete können 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 und tests als auch für die Wartung von Geräten vor Ort verwendet werden kann. Für das Querladen für die Softwareentwicklung und -tests ist die AppDevelopment-Gerätefunktion erforderlich. Das Querladen für die Feldwartung erfordert die FieldServicing-Gerätefunktion und produktionssignierte Imagepakete. Sowohl Visual Studio als auch Visual Studio Code laden Anwendungen während der Entwicklung und beim Debuggen quer. Sie können auch manuell über die Azure CLI querladen.

  • Cloudupdate, das nur vom Azure Sphere-Sicherheitsdienst ausgeführt werden kann. Verwenden Sie die Azure CLI, um Cloudbereitstellungen zu erstellen und zu verwalten.

Partneranwendungen

Anwendungen, die zusammenarbeiten, können als Partneranwendungen betrachtet und dann separat quergeladen werden. Wenn Sie eine Anwendung querladen, die über einen Partner verfügt, verbleibt die Partneranwendung auf dem Azure Sphere-Gerät, wenn sie bereits bereitgestellt wurde. Jede Anwendung deklariert eine Liste ihrer Partner in ihrer Projektkonfiguration.

Um Partner zur CMake-Projektkonfiguration hinzuzufügen, geben Sie die Komponenten-ID der Partner-App im Feld partnerComponentsdes Konfigurationsabschnitts der Datei launch.vs.json oder der Datei .vscode/launch.json 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 Allgemeinen Apps-Paaren oder RTApps-Paaren.