Tâches d’usine

La fabrication d’appareils connectés qui incorporent du matériel Azure Sphere implique les tâches d’usine suivantes pour préparer les appareils à l’expédition :

• Connexion de chaque puce Azure Sphere à un PC d’usine
• Obtention des détails de l’appareil et leur enregistrement pour une utilisation ultérieure
• Mise à jour du système d’exploitation Azure Sphere, si nécessaire
• Mettez à jour le magasin de clés approuvé, si nécessaire
• Chargement de logiciels sur l’appareil
• Exécution de tests fonctionnels pour vérifier l’opération correcte du produit
• Exécution de tests et d’étalonnage de fréquence radio (RF)
• Vérification de la communication Wi-Fi
• Configuration de l’appareil pour Ethernet
• Finalisation de l’appareil Azure Sphere pour l’expédition

Vous devez d’abord connecter la puce au PC, obtenir les détails de l’appareil en second et finaliser l’appareil en dernier, mais vous pouvez effectuer les autres tâches dans n’importe quel ordre qui convient à votre environnement de fabrication.

Connecter chaque puce Azure Sphere à un PC d’usine

Pendant la fabrication, vous devez connecter chaque puce Azure Sphere à un PC de niveau usine. Si vous souhaitez connecter simultanément plusieurs appareils Azure Sphere à un seul PC, consultez Équipement pour les tâches d’usine dans les tâches de préparation de la fabrication.

La plupart des tâches au niveau de l’usine impliquent la commande d’appareil azsphere. Lorsque vous avez plusieurs appareils attachés au PC, vous devez spécifier l’appareil sur lequel appliquer la commande azsphere device en incluant le --device paramètre défini sur l’adresse IP de l’appareil ou le chemin de connexion de l’appareil. La commande échoue si le --device paramètre est omis et que plusieurs appareils sont attachés. Pour obtenir l’adresse IP ou le chemin de connexion, consultez Obtenir les détails de l’appareil.

Obtenir les détails de l’appareil

Vous devez enregistrer l’ID d’appareil de chaque puce Azure Sphere que votre entreprise intègre dans des produits fabriqués. Vous aurez besoin de l’ID d’appareil pour les tâches de configuration cloud.

Si vous avez plusieurs appareils attachés au PC d’usine, vous devez également enregistrer l’adresse IP ou le chemin de connexion des appareils attachés pour une utilisation ultérieure dans les tâches au niveau de l’usine. Comme expliqué dans Connecter chaque puce Azure Sphere, adresse IP ou chemin de connexion est requis pour spécifier l’appareil cible lorsqu’il existe plusieurs appareils attachés.

Pour obtenir l’ID d’appareil, l’adresse IP et le chemin de connexion des appareils attachés, utilisez la commande azsphere device list-attached. Les descriptions suivantes fournissent des détails essentiels sur l’ID d’appareil, l’adresse IP et le chemin de connexion.

• ID d’appareil : le fabricant de silicium crée l’ID d’appareil, le stocke sur la puce et l’inscrit auprès de Microsoft. Cette inscription d’appareil permet de s’assurer que Microsoft a connaissance de toutes les puces Azure Sphere et que seules les puces légitimes peuvent être utilisées dans des appareils connectés.

• Adresse IP : l’adresse IP est affectée lorsqu’une interface d’appareil basée sur FTDI est attachée au PC ; il n’indique pas qu’un appareil réactif est présent. L’adresse IP est conservée tant que l’interface d’appareil FTDI est attachée au PC, même si un autre appareil Azure Sphere est branché sur l’interface. Cependant, après un redémarrage du PC, il est possible que l’adresse IP change. La première interface d’appareil FTDI à attacher est affectée à l’adresse 192.168.35.2. Une adresse IP est affectée à chaque appareil, même s’il ne répond pas, ce qui vous permet d’utiliser l’adresse IP pour identifier un appareil nécessitant une récupération.

• Chemin de connexion : le chemin de connexion est un ID d’emplacement FTDI qui identifie la connexion USB. L’ID d’emplacement persiste pendant que l’interface d’appareil FTDI est attachée au même port USB sur le même hub USB, puis au même port sur le PC. Il est donc conservé après un redémarrage. Cependant, des modifications apportées au câblage entre le PC et l’appareil peuvent aboutir à des changements du chemin de connexion. Comme l’adresse IP, il ne change pas même si un autre appareil Azure Sphere est branché sur l’interface FTDI.

Mettre à jour le système d’exploitation Azure Sphere

Chaque puce Azure Sphere est chargée avec le système d’exploitation Azure Sphere au moment de sa livraison par le fabricant de silicium. En fonction de la version du système d’exploitation Azure Sphere présente sur les puces disponibles auprès de votre fournisseur, et en fonction des exigences de version du système d’exploitation de votre application, vous devrez peut-être mettre à jour le système d’exploitation Azure Sphere lors de la fabrication de l’appareil connecté. Vous pouvez mettre à jour le système d’exploitation en installant des images de récupération spécifiques, qui doivent déjà être présentes sur votre PC. Consultez Préparer une mise à jour du système d’exploitation dans les tâches de préparation de fabrication. Les exemples de fabrication incluent un exemple de script qui effectue une récupération multi-appareil parallèle.

Vous pouvez mettre à jour le système d’exploitation sur l’appareil Azure Sphere en émettant la commande azsphere device recover . Utilisez le --images paramètre pour installer des images de récupération spécifiques :

azsphere device recover --images <path-to-images> [--device <IP-address or connection-path>]

Mettre à jour le magasin de clés approuvé

En tant que prérequis pour le chargement de logiciels sur votre appareil, vous devrez peut-être mettre à jour le magasin de clés approuvé sur l’appareil. Cela est nécessaire uniquement si le système d’exploitation sur l’appareil est plus ancien que votre logiciel, et uniquement si la clé de signature d’image Azure Sphere utilisée par AS3 a été mise à jour entre le système d’exploitation en cours de publication et votre logiciel signé en production. Pour éviter cette étape et réduire le temps de fabrication, envisagez de mettre à jour la version du système d’exploitation que vous utilisez pendant la fabrication.

Vous pouvez facilement déterminer si la mise à jour du magasin de clés approuvé est requise en tentant de charger votre logiciel en suivant les instructions de la section suivante. Si le chargement réussit, vous n’avez pas besoin de mettre à jour le magasin de clés approuvé. Si le chargement échoue avec le message commençant par Internal device error: Image not trusted by device un magasin de clés approuvé obsolète, c’est la cause.

Pour mettre à jour le magasin de clés approuvé, vous devez avoir acquis le fichier de magasin de clés approuvé à jour. Ensuite, dans le cadre de vos scripts de fabrication, utilisez la commande azsphere device sideload deploy pour charger le magasin de clés approuvé mis à jour avant le chargement du logiciel d’application, en remplaçant <path-to-trusted-keystore.bin> par le chemin d’accès au fichier de magasin de clés approuvé :

azsphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]

azsphere device sideload deploy --imagepackage <path-to-trusted-keystore.bin> [--deviceip <IP-address> | --devicelocation <connection-path>]

Charger des logiciels d’appareil

Tous les logiciels que vous chargez, qu’il s’agisse d’une image de configuration de carte, d’une application de test ou d’une application de production, doivent être signés en production. Si vous chargez une application temporaire pour le test, vous devez la supprimer une fois le test terminé.

Toutes les images signées en production dont vous avez besoin pendant le processus d’usine doivent être enregistrées sur votre PC d’usine avant de commencer le processus, comme décrit dans Obtenir les images signées en production dans les tâches de préparation de la fabrication.

Lors de la fabrication, les appareils Azure Sphere ne doivent pas nécessiter de fonctionnalités d’appareil spéciales, comme la fonctionnalité appdevelopment, qui active le débogage. L’acquisition de fonctionnalités pour des appareils spécifiques réduit la sécurité de l’appareil et nécessite une connectivité Internet, ce qui n’est généralement pas souhaitable en usine.

Pour charger des logiciels sur un appareil dans la fabrique ou pour supprimer des logiciels temporaires d’un appareil une fois le test terminé, utilisez la commande azsphere device sideload comme suit :

• Utilisez azsphere device sideload deploy pour charger une image, en remplaçant <file-path> par le nom et le chemin d’accès à votre fichier image signé en production :

  • Interface DE ligne de commande Azure Sphere
  • Azure Sphere classic CLI

  azsphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
  

• Utilisez azsphere device sideload delete pour supprimer une image temporaire, en <component-id> remplaçant par l’ID de composant de l’image à supprimer :

  • Interface DE ligne de commande Azure Sphere
  • Azure Sphere classic CLI

  azsphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
  

Exécuter les tests fonctionnels

Les tests fonctionnels sont nécessaires pour vérifier que le produit fonctionne correctement. Exécutez les applications que vous avez développées pour les tests fonctionnels dans le cadre des tâches de préparation de fabrication. Consultez Développer des applications pour les tests fonctionnels.

Si vos tests fonctionnels nécessitent une communication avec la puce testée, connectez les UARTs périphériques MT3620 (ISU0, ISU1, ISU2 ou ISU3) à votre PC d’usine ou à votre équipement de test externe via un circuit approprié de votre propre conception.

Effectuer des tests et des étalonnages de fréquence radio (RF)

Les puces Azure Sphere peuvent utiliser le Wi-Fi pour recevoir des mises à jour logicielles et communiquer avec Internet. Si votre produit utilise le Wi-Fi et qu’il intègre une conception à puce ou un module qui n’est pas certifié RF, vous devez effectuer des tests RF et l’étalonnage pour chaque appareil. L’équipement et les outils nécessaires à cette tâche sont décrits dans Équipement et logiciel pour les tests rf et l’étalonnage dans les tâches de préparation de fabrication.

Le package RF Tools inclut des utilitaires et une bibliothèque d’API C à utiliser pendant les tests. Vous pouvez utiliser la bibliothèque d’API C pour programmer des paramètres RF spécifiques au produit dans les fusibles électroniques. Par exemple, les fusibles électroniques sont programmés pour configurer l’antenne et la fréquence, pour régler les appareils pour des performances optimales et pour activer les canaux Wi-Fi. La rubrique Outils de test RF explique comment utiliser les outils RF.

Programmer des e-fusibles pour activer les canaux Wi-Fi

Le système d’exploitation Azure Sphere sélectionne les canaux Wi-Fi en fonction du code de région qui est programmé dans les fusibles e-fusibles MT3620 aux adresses de décalage 0x36 et 0x37. Pour plus d’informations sur les fusibles électroniques sur le MT3620, consultez le document Mediatek des directives de contenu de fusion E-fuse MT3620.

Le code de région est un code ASCII à deux lettres. Le système d’exploitation Azure Sphere utilise le paramètre de code de région dans les fusibles électroniques pour rechercher la région dans la base de données réglementaire sans fil Linux, puis sélectionne les canaux autorisés pour cette région. Si aucun code de région n’est programmé dans les fusibles électroniques, auquel cas les e-fuses restent définis sur 0x00 0x00 ou si les caractères « 00 » sont programmés, le système d’exploitation est défini par défaut sur un ensemble conservateur de canaux généralement autorisés dans toutes les régions. Les canaux autorisés pour la région « 00 » sont spécifiés dans la base de données réglementaire sans fil Linux.

Le paramètre de code de région dans les fusibles électroniques n’a pas besoin de correspondre au pays où l’appareil sera utilisé. Les fabricants peuvent choisir n’importe quel code de région qui correspond à un ensemble autorisé de canaux pour la région d’opération. Les différentes régions et pays adoptent souvent des réglementations similaires ou identiques, ce qui peut permettre l’utilisation interchangeable des codes régionaux.

Exemple : pour indiquer au système d’exploitation Azure Sphere de sélectionner les canaux Wi-Fi pour la région « DE » (Allemagne), programmez 0x44=D et 0x45=E dans les fusibles électroniques aux adresses 0x36 et 0x37. Les canaux autorisés pour l’Allemagne, extraits de la base de données réglementaire sans fil Linux, sont indiqués ci-dessous. La plupart des pays de l’Union européenne (UE) autorisent le même ensemble de canaux.

country DE: DFS-ETSI
        (2400 - 2483.5 @ 40), (100 mW)
        (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
        (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
        (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
        # short range devices (ETSI EN 300 440-1)
        (5725 - 5875 @ 80), (25 mW)
        # 60 GHz band channels 1-4 (ETSI EN 302 567)
        (57000 - 66000 @ 2160), (40)

Vérifier la configuration RF

Utilisez RfSettingsTool pour vérifier que les options de configuration radio telles que la puissance de transmission cible, le code de région et l’adresse MAC (Wi-Fi Media Access Control) ont été correctement définies. La documentation de l’outil de paramètres RF fournit plus d’informations sur l’utilisation de cet outil.

Vérifier la communication Wi-Fi

Envisagez de vous connecter à un point d’accès Wi-Fi pour vérifier que votre application de produit est en mesure de communiquer via le Wi-Fi. Assurez-vous que la connexion Wi-Fi n’a pas d’accès à Internet, car une mise à jour sur internet peut se produire si la puce se connecte à un point d’accès internet.

Pour connecter un appareil à un point d’accès Wi-Fi, suivez les instructions de l’onglet Démarrage rapide (cli). Si plusieurs appareils sont connectés au PC, vous devez inclure le --device paramètre dans la commande azsphere device wifi show-status et la commande azsphere device wifi add. Pour plus d’informations sur l’utilisation de la commande d’appareil azsphere avec plusieurs appareils attachés, consultez Connecter chaque puce Azure Sphere à un PC de niveau usine.

Après les tests Wi-Fi, vous devez supprimer tous les points d’accès Wi-Fi utilisés pour les tests de la puce afin qu’ils ne soient pas visibles par les clients. La récupération d’appareil supprime toutes les données de configuration Wi-Fi de la puce.

Configurer l’appareil pour Ethernet

Un appareil Azure Sphere peut communiquer via Ethernet. L’appareil nécessite une carte Ethernet externe et une image de configuration de carte pour la communication via Ethernet.

Pour configurer un appareil Azure Sphere pour Ethernet, connectez un adaptateur Ethernet à l’appareil Azure Sphere, comme décrit dans La connexion des adaptateurs Ethernet.

Deux appareils Ethernet sont pris en charge par le système d’exploitation Azure Sphere.

1. Microchip ENC28J60. Il s’agit d’un adaptateur 10Base-T (10 mops). Il peut être câblé avec un indicateur LED à vitesse demi-duplex ou sans indicateur LED à vitesse duplex totale. Les devkits vus sont câblés pour une opération semi-duplex.
2. Wiznet W5500. Il s’agit d’un adaptateur 100Base-TX (100mpb). Il prend en charge une pile TCP/IP intégrée et des modes pass-through de carte réseau, mais Azure Sphere prend uniquement en charge la carte réseau directe lors de l’utilisation de W5500 pour la connectivité Internet. En raison des limitations de bande passante de bus, la vitesse complète de 100 Mbits/s peut ne pas être réalisable par l’appareil MT3620.

L’interface Ethernet est activée automatiquement une fois la configuration de carte chargée, comme décrit dans Charger le logiciel de l’appareil, et l’appareil est redémarré. Par défaut, toutes les interfaces utilisent des adresses IP dynamiques.

Finaliser l’appareil Azure Sphere

La finalisation permet de s’assurer que l’appareil Azure Sphere est dans un état sécurisé et qu’il est prêt à être expédié aux clients. Vous devez finaliser l’appareil avant de l’expédier. La finalisation implique les opérations suivantes :

• Exécution de contrôles afin de s’assurer que les applications de production et les logiciels système corrects sont installés, et que les outils RF sont désactivés

• Définition de l’état de fabrication de l’appareil pour verrouiller la configuration RF et les outils d’étalonnage et empêcher les violations de la sécurité.

Exécuter des vérifications prêtes à l’expédition

Il est important d’exécuter des vérifications prêtes à l’expédition avant d’expédier un produit incluant un appareil Azure Sphere. Différentes vérifications doivent être effectuées pour différents états de fabrication. Les vérifications prêtes à l’expédition garantissent les éléments suivants :

• L’état de fabrication de l’appareil est correctement défini pour cette étape de fabrication.
• Le système d’exploitation Azure Sphere sur l’appareil est valide et la version attendue. Cela ne peut être vérifié que pour les appareils qui ne sont pas encore dans l’état DeviceComplete.
• Les images fournies par l’utilisateur sur l’appareil correspondent à la liste des images attendues. Cela ne peut être vérifié que pour les appareils qui ne sont pas encore dans l’état DeviceComplete.
• Aucun réseau Wi-Fi inattendu n’est configuré sur l’appareil. Cela ne peut être vérifié que pour les appareils qui ne sont pas encore dans l’état DeviceComplete.
• L’appareil ne contient aucun certificat de fonctionnalité spéciale. Pour les appareils MT3620, cela ne peut être vérifié que sur les appareils qui ne sont pas dans l’état Vide.

Différentes vérifications sont nécessaires à différentes étapes de fabrication, car l’état de fabrication de l’appareil détermine les fonctionnalités de l’appareil.

Les vérifications que vous exécutez dépendent également de la conception d’un module ou d’un appareil connecté. Par exemple, en tant que fabricant de modules, vous pouvez choisir de laisser la puce dans l’état de fabrication Vide afin que le client du module puisse effectuer des tests radio et une configuration supplémentaires.

Utiliser device_ready.py pour effectuer des vérifications

Le package d’exemples de fabrication comprend un outil appelé device_ready.py, qui effectue les vérifications ci-dessus, selon les besoins de chaque état de fabrication. Il doit être exécuté pour chacun des états de fabrication pertinents pour votre appareil.

Le tableau suivant répertorie les paramètres que prend le script device_ready.py :

L’exemple suivant est un exemple d’exécution de l’outil device_ready.py avec les arguments suivants :

• --os 22.07
• --os_components_json_file mt3620an.json
• --expected_mfg_state Module1Complete

device_ready.py --os 22.07 --os_components_json_file mt3620an.json --expected_mfg_state Module1Complete
Checking device is in manufacturing state Module1Complete...
PASS: Device manufacturing state is Module1Complete
Checking capabilities...
PASS: No capabilities on device
Checking OS version...
PASS: OS '22.07' is an expected version
Checking installed images...
PASS: Installed images matches expected images
Checking wifi networks...
PASS: Device has no wifi networks configured
------------------
PASS

Définir l’état de fabrication de l’appareil

Les opérations de fabrication sensibles telles que le réglage des fonctionnalités radio en mode test et la définition de la configuration Wi-Fi des eFUSE ne doivent pas être accessibles aux utilisateurs finaux des appareils qui contiennent une puce Azure Sphere. L’état de fabrication de l’appareil Azure Sphere limite l’accès à ces opérations sensibles.

Les trois états de fabrication sont les suivants :

• Blank. L’état vide ne limite pas les opérations de fabrication sur une puce. Les puces dans l’état Vide peuvent entrer en mode de test RF et leurs e-fusibles peuvent être programmés. Lorsque les puces sont livrées à partir de l’usine de silicium, elles sont dans l’état de fabrication vide .

• Module1Complete. L’état de fabrication Module1Complete est conçu pour limiter les ajustements que les utilisateurs peuvent apporter aux paramètres de configuration radio, tels que les niveaux de puissance de transmission maximal et les fréquences autorisées. Les commandes RF peuvent être utilisées jusqu’à ce que Module1Complete soit défini. La restriction de l’accès des utilisateurs finaux à ces paramètres peut être nécessaire pour satisfaire aux stratégies réglementaires sur le matériel radio. Ce paramètre affecte principalement les fabricants qui doivent tester et étalonner les paramètres de fonctionnement radio.

  Microsoft vous recommande de définir cet état de fabrication après avoir effectué les tests radio et l’étalonnage ; les commandes RF ne peuvent pas être utilisées une fois cet état défini. L’état Module1Complete protège l’appareil contre les modifications susceptibles de perturber le bon fonctionnement de la radio et d’autres appareils sans fil à proximité.

• DeviceComplete. L’état de fabrication DeviceComplete permet aux fabricants de produits finis de sécuriser les appareils déployés dans le champ par rapport aux modifications. Une fois qu’un appareil est placé dans l’état DeviceComplete , un fichier de capacité spécifique à l’appareil doit être utilisé chaque fois que vous effectuez des tâches de chargement et de configuration de logiciels. La fonctionnalité fieldservicing vous permet de charger des images signées en production, mais pas de les supprimer. La fonctionnalité de développement d’application permet à la fois le chargement indépendant et la suppression d’images.

  Ne définissez pas DeviceComplete pour les appareils ou modules non terminés (modules Wi-Fi, cartes de développement, etc.) qui peuvent être utilisés dans le cadre d’un système plus grand ; cet état limite les activités de fabrication telles que les tests de ligne de production, l’installation logicielle et la configuration. De nombreuses commandes CLI ne sont pas disponibles après la définition de DeviceComplete . Par conséquent, certaines vérifications prêtes à l’expédition doivent être exécutées avant que cet état ne soit défini. Les commandes restreintes peuvent être réactivées à l’aide d’une fonctionnalité d’appareil telle que la fonctionnalité fieldservicing, mais uniquement pour les appareils que vous avez revendiqués, et par conséquent, cela n’est pas approprié pour une utilisation dans un environnement de niveau usine, car il nécessite une connectivité cloud.

Le tableau suivant récapitule les fonctionnalités d’appareil présentes pour chaque état de fabrication.

Une fois la fabrication terminée, utilisez la commande azsphere device manufacturing-state update pour définir l’état DeviceComplete :

azsphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]

azsphere device manufacturing-state update --state <desired-state> [--deviceip <IP-address> | --devicelocation <connection-path>]