Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les phases de développement d’une solution IoT peuvent s’étendre sur plusieurs semaines ou mois, en raison de réalités de production telles que le temps de fabrication, l’expédition, le processus douanier, etc. En outre, ils peuvent s’étendre sur plusieurs rôles en fonction des différentes entités impliquées. Cet article examine plus en détail les différents rôles et opérations liés à chaque phase, puis illustre le flux dans un diagramme de séquence.
L’approvisionnement place également des exigences sur le fabricant de l’appareil, propres à l’activation du mécanisme d’attestation. Les opérations de fabrication peuvent également se produire indépendamment du minutage des phases de provisionnement automatique, en particulier dans les cas où de nouveaux appareils sont achetés après l’établissement de l’autoprovisionnement.
Une série de guides de démarrage rapide est fournie dans la table des matières à gauche, pour vous aider à comprendre l’autoprovisionnement à travers l'expérience pratique. Pour faciliter/simplifier le processus d’apprentissage, le logiciel est utilisé pour simuler un appareil physique pour l'inscription et l'enregistrement. Certains démarrages rapides vous obligent à effectuer des opérations pour plusieurs rôles, y compris les opérations pour les rôles inexistants, en raison de la nature simulée des démarrages rapides.
| Role | Opération | Descriptif |
|---|---|---|
| Fabricant | Encoder l’URL d’identité et d’inscription | En fonction du mécanisme d’attestation utilisé, le fabricant est responsable de l’encodage des informations d’identité de l’appareil et de l’URL d’inscription du service Device Provisioning. Guides de démarrage rapide : étant donné que l’appareil est simulé, il n’existe aucun rôle de fabricant. Consultez le rôle Développeur pour plus d’informations sur la façon dont vous obtenez ces informations, qui sont utilisées pour coder un exemple d’application d’inscription. |
| Fournir une identité d’appareil | En tant qu’origine des informations d’identité de l’appareil, le fabricant est chargé de le communiquer à l’opérateur (ou à un agent désigné) ou de l’inscrire directement au service Device Provisioning via des API. Démarrages rapides : l’appareil étant simulé, il n’existe aucun rôle Fabricant. Consultez le rôle Opérateur pour plus d’informations sur la façon dont vous obtenez l’identité de l’appareil, qui est utilisée pour inscrire un appareil simulé dans votre instance de service Device Provisioning. |
|
| Operator | Configurer le provisionnement automatique | Cette opération correspond à la première phase de l’autoprovisionnement. Démarrages rapides : Vous effectuez le rôle Opérateur, en configurant le service Device Provisioning et les instances IoT Hub dans votre abonnement Azure. |
| Inscrire l’identité de l’appareil | Cette opération correspond à la deuxième phase de l’autoprovisionnement. Démarrages rapides : vous jouez le rôle d'opérateur, en inscrivant votre appareil simulé dans votre instance de service d'approvisionnement de périphériques. La méthode d’attestation simulée dans le guide de démarrage rapide (TPM ou X.509) détermine l’identité de l’appareil. Consultez le rôle Développeur pour les détails de l'attestation. |
|
| Service d'approvisionnement de dispositifs IoT Hub |
<toutes les opérations> | Pour une implémentation de production avec des appareils physiques et des démarrages rapides avec des appareils simulés, ces rôles sont remplis via les services IoT que vous configurez dans votre abonnement Azure. Les rôles/opérations fonctionnent exactement de la même façon, comme les services IoT sont indifférents à l’approvisionnement d’appareils physiques par rapport à des appareils simulés. |
| Developer | Générer/déployer un logiciel d’inscription | Cette opération correspond à la troisième phase de l’autoprovisionnement. Le développeur est responsable de la création et du déploiement du logiciel d’inscription sur l’appareil, à l’aide du Kit de développement logiciel (SDK) approprié. Démarrages rapides : l’exemple d’application d’inscription que vous générez simule un appareil réel, pour votre plateforme/langage de choix, qui s’exécute sur votre station de travail (au lieu de le déployer sur un appareil physique). L’application d’inscription effectue les mêmes opérations que celles déployées sur un appareil physique. Vous spécifiez la méthode d’attestation (certificat TPM ou X.509), ainsi que l’URL d’inscription et l'« étendue d’ID » de votre instance de service Device Provisioning. La logique d’attestation du Kit de développement logiciel (SDK) au moment de l’exécution détermine l’identité de l’appareil, en fonction de la méthode que vous spécifiez :
|
| Device | Démarrage et inscription | Cette opération correspond à la troisième phase de l’approvisionnement automatique, remplie par le logiciel d’inscription d’appareil créé par le développeur. Pour plus d’informations, consultez le rôle Développeur. Lors du premier démarrage :
|
Le diagramme suivant récapitule les rôles et le séquencement des opérations lors de l’autoprovisionnement de l’appareil :
Note
Si vous le souhaitez, le fabricant peut également effectuer l’opération « Inscrire l’identité de l’appareil » à l’aide des API du service Device Provisioning (au lieu de l’opérateur). Pour une discussion détaillée de cette mise en séquence et des informations supplémentaires, consultez la vidéo sur l’inscription d’appareils sans intervention avec Azure IoT (à partir du marqueur 41:00).
Rôles et comptes Azure
La façon dont chaque rôle est mappé à un compte Azure dépend du scénario et il existe quelques scénarios qui peuvent être impliqués. Les modèles courants suivants doivent aider à fournir une compréhension générale de la façon dont les rôles sont mappés à un compte Azure.
Le fabricant de puce fournit des services de sécurité
Dans ce scénario, le fabricant gère la sécurité pour les clients de niveau un. Ce scénario peut être préférable pour ces clients de niveau un, car ils n’ont pas besoin de gérer la sécurité détaillée.
Le fabricant introduit la sécurité dans les modules de sécurité matériels (HSM). Cette sécurité peut inclure le fabricant qui obtient des clés, des certificats, etc. auprès de clients potentiels qui ont déjà des instances DPS et des groupes d’inscription configurés. Le fabricant peut également générer ces informations de sécurité pour ses clients.
Dans ce scénario, il peut y avoir deux comptes Azure impliqués :
Compte n°1 : Probablement partagés entre les rôles d’opérateur et de développeur à un certain degré. Cette partie peut acheter les puces HSM auprès du fabricant. Ces puces électroniques sont pointées vers les instances DPS associées au compte #1. Avec les inscriptions DPS, cette partie peut louer des appareils à plusieurs clients de niveau deux en reconfigurant les paramètres d’inscription des appareils dans DPS. Cette partie peut également avoir des hubs IoT alloués pour les systèmes back-end de l’utilisateur final à interagir avec afin d’accéder aux données de télémétrie des appareils, etc. Dans ce dernier cas, un deuxième compte peut ne pas être nécessaire.
Compte n°2 : Les utilisateurs finaux, les clients de niveau 2 peuvent avoir leurs propres hubs IoT. Le partenaire lié au compte n°1 redirige simplement les appareils loués vers le concentrateur approprié de ce compte. Cette configuration nécessite la liaison de DPS et d’IoT Hubs entre des comptes Azure, qui peuvent être effectués avec des modèles Azure Resource Manager.
OEM tout-en-un
Le fabricant pourrait être un « OEM tout-en-un » où un seul compte de fabricant serait nécessaire. Le fabricant gère la sécurité et l’approvisionnement de bout en bout.
Le fabricant peut fournir une application basée sur le cloud aux clients qui achètent des appareils. Cette application interface avec le hub IoT alloué par le fabricant.
Les distributeurs automatiques ou les machines à café automatisées représentent des exemples dans ce contexte.
Étapes suivantes
Vous trouverez peut-être utile de marquer cet article comme point de référence, à mesure que vous parcourez les démarrages rapides de provisionnement automatique correspondants.
Commencez par suivre un guide de démarrage rapide « Configurer le provisionnement automatique » qui convient le mieux à vos préférences d’outil de gestion, ce qui vous guide tout au long de la phase « Configuration du service » :
- Configurer le provisionnement automatique à l’aide d’Azure CLI
- Configurer le provisionnement automatique à l’aide du portail Azure
- Configurer le provisionnement automatique à l’aide d’un modèle Azure Resource Manager (ARM)
Ensuite, poursuivez avec un guide de démarrage rapide « Provisionner un appareil » qui convient à votre mécanisme d’attestation de l’appareil et à votre préférence de langage pour le SDK/service de provisionnement d'appareils. Dans ce guide de démarrage rapide, vous allez parcourir les phases « Inscription des appareils » et « Inscription et configuration de l’appareil » :
| Mécanisme d’attestation d’appareil | Démarrage rapide |
|---|---|
| Clé symétrique | Créer un appareil à clé symétrique simulé |
| X.509 certificate | Provisionner un appareil X.509 simulé |
| Module de plateforme sécurisée simulée (TPM) | Provisionner un appareil TPM simulé |