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 pour l’expédition :

• Connexion de chaque puce Azure Sphere à un PC d’usine
• Obtention des détails de l’appareil et enregistrement de ceux-ci pour une utilisation ultérieure
• Mise à jour du système d’exploitation Azure Sphere, si nécessaire
• Mettre à jour le magasin de clés approuvé, si nécessaire
• Chargement de logiciels sur l’appareil
• Exécution de tests fonctionnels pour vérifier le bon fonctionnement du produit
• Exécution de tests et d’étalonnage de la 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 ensuite et finaliser l’appareil en dernier, mais vous pouvez effectuer les autres tâches dans n’importe quel ordre adapté à 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 d’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 fabrication.

La plupart des tâches d’usine impliquent la commande az sphere device . Lorsque vous avez plusieurs appareils connectés au PC, vous devez spécifier l’appareil sur lequel appliquer la commande az sphere 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 si 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 incorpore dans les produits fabriqués. Vous aurez besoin de l’ID d’appareil pour les tâches de configuration cloud.

Si vous avez plusieurs appareils connecté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 d’usine. Comme expliqué dans Connecter chaque puce, adresse IP ou chemin de connexion Azure Sphere est nécessaire 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 az sphere device list-attached . Les descriptions suivantes fournissent des détails essentiels sur l’ID de l’appareil, l’adresse IP et le chemin de connexion.

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

• Adresse IP : l’adresse IP est attribuée lorsqu’une interface d’appareil FTDI est attachée au PC. elle n’indique pas qu’un appareil réactif est présent. L’adresse IP est conservée pendant que l’interface d’appareil FTDI est attachée au PC, même si un autre appareil Azure Sphere est branché à l’interface. Toutefois, après le redémarrage d’un PC, l’adresse IP peut changer. La première interface d’appareil ftDI à attacher se voit attribuer l’adresse 192.168.35.2. Une adresse IP est attribuée à chaque appareil, même s’il ne répond pas, de sorte que vous pouvez utiliser l’adresse IP pour identifier un appareil qui nécessite 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 est conservé lorsque l’interface de l’appareil FTDI est attachée au même port USB sur le même hub USB et, à son tour, au même port sur le PC. Par conséquent, il persiste lors du redémarrage. Toutefois, toute modification du câblage entre le PC et l’appareil peut entraîner des modifications du chemin de connexion. Comme l’adresse IP, elle ne change pas même si un autre appareil Azure Sphere est branché à 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 lorsqu’elle est expédiée par le fabricant de silicium. Selon la version du système d’exploitation Azure Sphere sur les puces disponibles auprès de votre fournisseur et selon les exigences de version du système d’exploitation de votre application, vous devrez peut-être mettre à jour le système d’exploitation Azure Sphere pendant 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 en parallèle.

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

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

Mettre à jour le magasin de clés approuvé

Comme condition préalable au chargement du logiciel 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 antérieur à votre logiciel, et uniquement si la clé de signature d’image Azure Sphere utilisée par AS3 a été mise à jour entre la publication du système d’exploitation et la signature de votre logiciel 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 nécessaire en essayant de charger votre logiciel conformément aux 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 en 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 az sphere device sideload deploy pour charger le magasin de clés approuvé mis à jour avant de charger le logiciel d’application, en <path-to-trusted-keystore.bin> remplaçant par le chemin d’accès au fichier de magasin de clés approuvé :

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

Charger le logiciel de l’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 à des fins de 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 des images signées en production dans les tâches de préparation de fabrication.

Pendant la fabrication, les appareils Azure Sphere ne doivent pas nécessiter de fonctionnalités d’appareil spéciales, telles que la fonctionnalité de développement d’application, qui permet le débogage. L’acquisition de fonctionnalités pour des appareils individuels réduit la sécurité des appareils et nécessite une connectivité Internet, ce qui n’est généralement pas souhaitable en usine.

Pour charger des logiciels sur un appareil en usine ou supprimer des logiciels temporaires d’un appareil une fois le test terminé, utilisez la commande az sphere device sideload comme suit :

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

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

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

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

Exécuter des tests fonctionnels

Des 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 UART périphériques MT3620 (ISU0, ISU1, ISU2 ou ISU3) à votre PC d’usine ou à l’équipement de test externe via des circuits appropriés de votre propre conception.

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

Les puces Azure Sphere peuvent utiliser Wi-Fi pour recevoir des mises à jour logicielles et communiquer avec Internet. Si votre produit utilise 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 logiciels pour les tests rf et l’étalonnage dans les tâches de préparation de fabrication.

Le package RF Tools comprend 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 des 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 Wi-Fi canaux. La rubrique Outils de test RF décrit comment utiliser les outils RF.

Programmer des fusibles électroniques pour activer les canaux Wi-Fi

Le système d’exploitation Azure Sphere sélectionne Wi-Fi canaux en fonction du code de région qui est programmé dans les e-fusibles MT3620 aux adresses offset 0x36 et 0x37. Pour plus d’informations sur les fusibles électroniques sur le MT3620, consultez le document Mediatek sur les directives relatives au contenu e-fusible 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 e-fusibles, auquel cas les e-fusibles restent définis sur 0x00 0x00, ou si les caractères « 00 » sont programmés, le système d’exploitation utilise par défaut 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 mappé à 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, qui peuvent permettre l’utilisation indifférem des codes régionaux.

Exemple: Pour indiquer au système d’exploitation Azure Sphere de sélectionner Wi-Fi canaux 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 présenté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 l’alimentation de transmission cible, le code de région et Wi-Fi'adresse MAC (Media Access Control) ont été correctement définies. La documentation de l’outil paramètres RF fournit plus d’informations sur l’utilisation de cet outil.

Vérifier Wi-Fi communication

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. Vérifiez que la connexion Wi-Fi n’a pas accès à Internet, car une mise à jour ota 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 du guide de démarrage rapide (onglet CLI). Si plusieurs appareils sont connectés au PC, vous devez inclure le --device paramètre dans la commande az sphere device wifi show-status et la commande az sphere device wifi add. Pour plus d’informations sur l’utilisation de la commande az sphere device avec plusieurs appareils attachés, consultez Connecter chaque puce Azure Sphere à un PC d’usine.

Après Wi-Fi test, vous devez supprimer tous les points d’accès Wi-Fi utilisés pour le test 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 une carte Ethernet à l’appareil Azure Sphere, comme décrit dans Connexion d’adaptateurs Ethernet.

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

1. Micropuce ENC28J60. Il s’agit d’un adaptateur 10Base-T (10mbps). Il peut être câblé avec un indicateur LED à la vitesse semi-duplex, ou sans indicateur LED à la vitesse du duplex intégral. Les devkits seeed sont câblés pour une opération semi-duplex.
2. Wiznet W5500. Il s’agit d’un adaptateur 100Base-TX (100mpbs). Il prend en charge une pile TCP/IP intégrée et des modes pass-through de carte réseau, mais Azure Sphere ne prend en charge que la carte réseau directe lors de l’utilisation du W5500 pour la connectivité Internet. En raison des limitations de bande passante du 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 que la configuration de la carte est chargée, comme décrit dans Charger le logiciel de l’appareil et que l’appareil est redémarré. Toutes les interfaces utilisent des adresses IP dynamiques par défaut.

Finaliser l’appareil Azure Sphere

La finalisation garantit que l’appareil Azure Sphere est dans un état sécurisé et prêt à être expédié aux clients. Vous devez finaliser l’appareil avant de l’expédier. La finalisation implique :

• Exécution de vérifications prêtes à l’expédition pour s’assurer que le logiciel système et l’application de production appropriés sont installés et que les outils RF sont désactivés.

• Définition de l’état de fabrication de l’appareil pour verrouiller les outils de configuration et d’étalonnage RF et empêcher les violations de 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 qui inclut 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 à 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 à 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 à l’état DeviceComplete.
• L’appareil ne contient aucun certificat de capacité spéciale. Pour les appareils MT3620, cela peut être vérifié uniquement sur les appareils qui ne sont pas à l’état Vide.

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

Les vérifications que vous exécutez varient également selon que vous concevez un module ou 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 supplémentaires et une configuration.

Utiliser device_ready.py pour effectuer des vérifications

Le package Manufacturing Samples inclut 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 le script device_ready.py accepte :

Voici 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 placement de la radio en mode test et la définition de Wi-Fi de fusibles électroniques de configuration, ne doivent pas être accessibles aux utilisateurs finaux d’appareils qui contiennent une puce Azure Sphere. L’état de fabrication de l’appareil Azure Sphere restreint l’accès à ces opérations sensibles.

Les trois états de fabrication sont les suivants :

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

• Module1Complétion. L’état de fabrication module1Complete est conçu pour limiter les ajustements que les utilisateurs peuvent effectuer aux paramètres de configuration radio, tels que les niveaux de puissance de transmission maximale 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 de l’utilisateur final à ces paramètres peut être nécessaire pour satisfaire aux stratégies réglementaires relatives au 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 une fois les tests radio et l’étalonnage terminés ; Les commandes RF ne peuvent pas être utilisées une fois qu’elles sont définies. L’état Module1Complete protège l’appareil contre les modifications susceptibles de perturber le bon fonctionnement de la radio et d’autres périphériques sans fil situés à proximité.

• DeviceComplete. L’état de fabrication DeviceComplete permet aux fabricants de produits finis de sécuriser les appareils déployés sur le terrain contre les 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 une version test 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 inachevé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 en ligne de production, l’installation de logiciels 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 à être livrées 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. Par conséquent, cela n’est pas approprié pour une utilisation dans un environnement d’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 az sphere device manufacturing-state update pour définir l’état DeviceComplete :

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