Partage via

Vue d’ensemble des applications Azure Sphere

  • Article

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

  • Les applications de haut niveau s’exécutent en conteneur sur le système d’exploitation Azure Sphere
  • Les applications compatibles temps réel (RTApps) s’exécutent sur un système d’exploitation en temps réel ou avec un système d’exploitation en temps réel (RTOS) sur les cœurs en temps réel

Une application de haut niveau est requise pour chaque appareil Azure Sphere . Les rtapps sont facultatives.

Applications de haut niveau

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 de haut niveau peut :

  • Configurer et interagir avec des périphériques Azure Sphere, tels que les broches d’entrée/sortie à usage général (GPIO), les récepteurs/émetteurs asynchrones universels (UART) et d’autres interfaces

  • Communiquer avec les applications en temps réel

  • Communiquer avec Internet et les services cloud

  • Relations d’approbation broker avec d’autres appareils et services via l’authentification basée sur les certificats

Une application de haut niveau s’exécute dans un conteneur en mode utilisateur Normal World, comme décrit dans Qu’est-ce qu’Azure Sphere ?. Le conteneur d’application prend en charge un sous-ensemble de l’environnement POSIX et un ensemble de bibliothèques d’applications (bibliothèques d’applications) spécifiques au système d’exploitation Azure Sphere. Les bibliothèques et fonctions disponibles pour les applications de haut niveau sont limitées pour garantir que la plateforme reste sécurisée et peut être facilement mise à jour. Les applications peuvent accéder uniquement aux bibliothèques et aux services d’exécution que Microsoft fournit ; ni les E/S 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 de l’appareil.

Les applications de haut niveau sont censées s’exécuter en continu et sont automatiquement redémarrées si elles s’arrêtent ou échouent.

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

Applications prenant en charge le temps réel

Un appareil Azure Sphere peut également avoir une ou plusieurs applications en temps réel en plus de son application de haut niveau. Une application en temps réel peut :

  • Configurer et interagir avec des périphériques intégrés au MCU Azure Sphere, tels que les broches GPIO et les UART
  • Communiquer avec des applications de haut niveau

Les applications en temps réel peuvent s’exécuter sur un système d’exploitation nu ou avec un système d’exploitation en temps réel (RTOS). Le référentiel d’exemples Azure Sphere sur GitHub comprend un exemple HelloWorld complet, ainsi qu’un exemple qui illustre la communication intercœurs entre les applications de haut niveau et les applications en temps réel. Le référentiel Exemples Azure sur GitHub contient un exemple qui montre comment utiliser Azure Sphere avec Azure RTOS.

Des pilotes et des exemples supplémentaires pour les applications en temps réel qui ciblent les cœurs en temps réel M4 sur la puce MT3620 sont disponibles sur GitHub auprès des partenaires Azure Sphere MediaTek et Codethink.

Chaque application en temps réel s’exécute isolément sur un cœur d’E/S particulier et ne peut communiquer qu’avec une application de haut niveau ; il 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 les applications en temps réel.

Fonctionnalités communes à toutes les applications

Malgré les différences significatives entre les applications de haut niveau et les applications en temps réel, toutes les applications Azure Sphere ont certains points en commun. Vous pouvez développer, générer et déboguer les deux types d’applications à l’aide de Visual Studio ou Visual Studio Code, ou en appelant CMake et Ninja à l’aide de l’interface CLI.

En outre, les fonctionnalités de sécurité suivantes s’appliquent aux applications de haut niveau et aux applications en temps réel :

Fonctionnalités de l’application

Quel que soit l’endroit où elle s’exécute, chaque application Azure Sphere doit spécifier les services et interfaces externes dont elle a besoin( par exemple, ses exigences en matière d’E/S et de réseau) pour empêcher toute utilisation non autorisée ou inattendue.

Les fonctionnalités d’application sont les ressources dont une application a besoin. Les fonctionnalités de l’application incluent les périphériques que l’application utilise, les hôtes Internet auxquels une application de haut niveau se connecte et l’autorisation de modifier la configuration réseau, entre autres. Chaque application doit avoir un manifeste d’application qui identifie ces ressources.

Fonctionnalités de l’appareil

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

La fonctionnalité d’appareil appDevelopment modifie le type de signature approuvé par l’appareil. Par défaut, les appareils Azure Sphere approuvent les packages d’images signés en production, mais ne font pas confiance aux packages d’images signés par le SDK. Par conséquent, vous ne pouvez pas charger une version test d’un package d’image signé par le SDK sur un appareil Azure Sphere qui n’a pas cette fonctionnalité. Toutefois, lorsque la fonctionnalité appDevelopment est présente, l’appareil approuve les packages d’images signés par le SDK. En outre, il 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’applications doit être présente sur l’appareil pour que vous puissiez :

  • Charger une version test d’un package d’images qui a été créé par Visual Studio ou la commande azsphere image-package .
  • Démarrez, arrêtez, déboguez ou supprimez un package d’images de l’appareil Azure Sphere, quelle que soit la façon dont le package d’images est signé.

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

La fonctionnalité fieldServicing autorise les communications appareil-à-ordinateur sur les appareils qui sont dans l’état de fabrication DeviceComplete. Avec cette fonctionnalité, vous pouvez charger une version test 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 de routine, 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.

Conditions requises pour la signature et le déploiement

Tous les packages d’images déployés sur un appareil Azure Sphere doivent être signés. Le Kit de développement logiciel (SDK) Azure Sphere et la commande az sphere image-package sign sign image packages for testing by using an SDK signing key. Les appareils Azure Sphere approuvent cette clé uniquement si la fonctionnalité d’appareil appDevelopment est également présente.

Le service de sécurité Azure Sphere signe des packages d’images lorsque vous les chargez dans le cloud. Les packages d’images signés en production peuvent être chargés de manière indépendante ou à partir du cloud.

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

  • 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 de version test pour la maintenance sur le terrain nécessite la fonctionnalité d’appareil fieldServicing et des packages d’images signés en production. Visual Studio et Visual Studio Code chargent une version test des applications pendant le développement et le débogage ; vous pouvez également charger une version test manuellement à l’aide d’Azure CLI.

  • Mise à jour cloud, qui peut être effectuée uniquement par le service de sécurité Azure Sphere. Utilisez Azure CLI 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 , puis peuvent être chargées séparément. Lorsque vous chargez 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 une liste de ses partenaires dans sa configuration de projet.

Pour ajouter des partenaires à la configuration du 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 en temps réel qui communiquent entre elles doivent être identifiées en tant que partenaires. Azure Sphere ne prend pas en charge la communication entre des paires d’applications de haut niveau ou des paires d’applications en temps réel.