Vue d’ensemble des applications Azure Sphere

Les appareils Azure Sphere peuvent exécuter deux types d'applications :

• Les applications générales s'exécutent dans un conteneur du système d'exploitation Azure Sphere
• Les applications en temps réel s'exécutent en mode « bare metal » (nu) ou avec un système d'exploitation en temps réel (RTOS) sur les cœurs en temps réel

Une application générale est requise sur chaque appareil Azure Sphere. Les applications en temps réel sont facultatives.

Applications générales

Chaque appareil Azure Sphere dispose d’une application de haut niveau, qui s’exécute sur le système d’exploitation Azure Sphere et peut utiliser les bibliothèques d’applications. Une application générale peut :

• Configurer et interagir avec des périphériques Azure Sphere tels que les broches GPIO (General-Purpose Input/Output), les émetteurs/récepteurs asynchrones universels (UART) et d’autres interfaces

• Communiquer avec RTApps

• Communiquer avec Internet et les services cloud

• Négocier des relations d’approbation avec d’autres appareils et services grâce à l’authentification basée sur les certificats

Une application générale s'exécute dans un conteneur en mode utilisateur Monde normal, comme décrit dans Qu'est-ce qu'Azure Sphere ?. Le conteneur d'applications prend en charge un sous-ensemble de l'environnement POSIX et un ensemble de bibliothèques d'applications spécifiques au système d'exploitation Azure Sphere. Les bibliothèques et les fonctions disponibles pour les applications générales sont limitées pour assurer la sécurité de la plateforme et faciliter sa mise à jour. Seuls les services d'exécution et les bibliothèques fournis par Microsoft sont accessibles aux applications. Ni les entrées/sorties de fichier directes ni l'accès à l'interpréteur de commandes ne sont disponibles, entre autres contraintes. L’environnement de développement décrit l’ensemble d’API de base et présente les bibliothèques d’applications Azure Sphere qui prennent en charge les fonctionnalités spécifiques aux appareils.

Les applications générales sont supposées s'exécuter en continu et sont automatiquement redémarrées en cas d'arrêt ou d'échec.

Créer une application de haut niveau fournit plus d’informations sur les fonctionnalités.

Applications en temps réel

En plus de son application générale, un appareil Azure Sphere peut également disposer d'une ou plusieurs applications en temps réel. Une application en temps réel peut :

• configurer et interagir avec des périphériques intégrés au microcontrôleur Azure Sphere, comme les broches GPIO et les UART ;
• communiquer avec les applications générales.

Les applications en temps réel peuvent être exécutées en mode « bare metal » ou avec un système d'exploitation en temps réel (RTOS). Le dépôt d’exemples Azure Sphere sur GitHub comprend un exemple HelloWorld complet ainsi qu’un exemple qui montre la communication inter-cœurs entre les applications de haut niveau et les applications temps réel. Le dépôt d’exemples Azure sur GitHub contient un exemple qui montre comment utiliser Azure Sphere avec Azure RTOS.

Des pilotes et des exemples supplémentaires pour RATpps qui ciblent les cœurs temps réel M4 sur la puce MT3620 sont disponibles sur GitHub ; ils proviennent des partenaires Azure Sphere MediaTek et Codethink.

Chaque application en temps réel s'exécute de manière isolée sur un cœur d'E/S particulier et ne peut communiquer qu'avec une application générale ; elle ne peut pas utiliser Internet, les bibliothèques d'applications Azure Sphere ou d'autres fonctionnalités du système d'exploitation Azure Sphere.

Créer une application compatible en temps réel fournit plus d’informations sur les fonctionnalités et le processus de développement pour RTApps.

Fonctionnalités communes à toutes les applications

Il existe des différences significatives entre les applications en temps réel et les applications générales, mais toutes les applications Azure Sphere ont néanmoins des points communs. Vous pouvez développer, générer et déboguer les deux types d’applications en utilisant Visual Studio ou Visual Studio Code, ou en appelant CMake et Ninja dans la CLI.

En outre, les fonctionnalités de sécurité suivantes s'appliquent à la fois aux applications générales et aux applications en temps réel :

• Fonctionnalités d’application
• Fonctionnalités de l’appareil
• Exigences en matière de signature et de déploiement

Fonctionnalités d’application

Quel que soit son emplacement, chaque application Azure Sphere doit spécifier les services et interfaces externes dont elle a besoin (par exemple, ses exigences d'E/S et réseau) pour empêcher toute utilisation non autorisée ou inattendue.

Les fonctionnalités d’application sont les ressources qui sont nécessaires à une application. Les fonctionnalités d'application incluent notamment les périphériques que l'application utilise, les hôtes Internet auxquels une application générale se connecte et l'autorisation de modifier la configuration réseau. Chaque application doit avoir un manifeste d’application qui identifie ces ressources.

Fonctionnalités de l’appareil

Une fonctionnalité d'appareil permet une activité spécifique à l'appareil. Les fonctionnalités d’appareil sont accordées par le service de sécurité Azure Sphere. Par défaut, les processeurs Azure Sphere n’ont aucune fonctionnalité d’appareil. Il existe deux principaux types de fonctionnalités d’appareil : la fonctionnalité d’appareil appDevelopment et la fonctionnalité d’appareil fieldServicing .

La fonctionnalité d’appareil appDevelopment change le type de signature que l’appareil approuve. Par défaut, les appareils Azure Sphere approuvent les packages d’images signés pour la production, mais n’approuvent pas les packages d’images signés pour le SDK. Par conséquent, vous ne pouvez pas charger indépendamment un package d’images signé pour le SDK sur un appareil Azure Sphere qui ne dispose pas de cette fonctionnalité. Toutefois, lorsque la fonctionnalité appDevelopment est présente, l’appareil approuve les packages d’images signés pour le SDK. En outre, elle vous permet de démarrer, d'arrêter, de déboguer ou de supprimer une application de l'appareil. En résumé, la fonctionnalité de développement d’application doit être présente sur l’appareil avant de :

• Effectuez un chargement indépendant d’un package d’images qui a été généré par Visual Studio ou par la commande azsphere image-package.
• Démarrer, arrêter, déboguer ou supprimer un package d’images de l’appareil Azure Sphere, quelle que soit la façon dont le package d’images a été signé

La commande azsphere device azsphere device enable-development crée et applique la fonctionnalité appDevelopment et empêche l’appareil de recevoir des mises à jour d’application cloud.

La fonctionnalité fieldServicing autorise les communications appareil-ordinateur sur les appareils qui sont à l’état de fabrication DeviceComplete. Avec cette fonctionnalité, vous pouvez charger des images signées en production, mais pas les supprimer. Vous pouvez démarrer et arrêter des applications, mais pas les déboguer. Vous pouvez également effectuer des tâches de maintenance courantes telles que la configuration du Wi-Fi. Il est destiné à une utilisation à court terme pendant une session de maintenance, période limitée pendant laquelle l’accès à l’appareil est accordé par opération.

Exigences en matière de signature et de déploiement

Tous les packages d’images qui sont déployés sur un appareil Azure Sphere doivent être signés. Azure Sphere SDK et la commande azsphere image package signent les packages d’images à des fins de test à l’aide d’une clé de signature de SDK. Les appareils Azure Sphere n’approuvent cette clé que si la fonctionnalité d’appareil appDevelopment est également présente.

Le Service de sécurité Azure Sphere signe les packages d’images pour la production quand vous les chargez vers le cloud. Les packages d’images signés pour la production peuvent faire l’objet d’un chargement indépendant à partir du cloud.

Pour empêcher l'installation de logiciels non autorisés, les applications ne peuvent être chargées sur un appareil Azure Sphere que de deux manières :

• Chargement indépendant, qui peut être utilisé à la fois pour le développement et le test de logiciels et pour la maintenance sur le terrain des appareils. Le chargement indépendant pour le développement et le test de logiciels nécessite la fonctionnalité d’appareil appDevelopment. Le chargement indépendant pour la maintenance des champs nécessite la fonctionnalité d’appareil fieldServicing et les packages d’images signés en production. Visual Studio et Visual Studio Code chargent des applications pendant le développement et le débogage ; vous pouvez également charger manuellement à l’aide de l’interface CLI Azure Sphere.

• La Mise à jour cloud, qui peut être effectuée seulement par le service de sécurité Azure Sphere. Utilisez l’interface CLI Azure Sphere pour créer et gérer des déploiements cloud.

Applications partenaires

Les applications qui fonctionnent ensemble peuvent être considérées comme des applications partenaires, et une version test distincte de celles-ci peut être chargée. Lorsque vous chargez une version test d'une application qui a un partenaire, l'application partenaire reste sur l'appareil Azure Sphere si elle a déjà été déployée. Chaque application déclare la liste de ses partenaires dans la configuration de son projet.

Pour ajouter des partenaires à la configuration de projet CMake, spécifiez l’ID de composant de l’application partenaire dans le champ partnerComponents de la section configurations du fichier launch.vs.json ou .vscode/launch.json :

"partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]

Les applications de haut niveau et les applications RTApps qui communiquent entre elles doivent être identifiées en tant que partenaires. Azure Sphere ne prend pas en charge la communication entre les paires d’applications de haut niveau ou les paires d’applications RTApps.