Créez un pool d'appareils IDT gratuitement RTOS - Gratuit RTOS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Créez un pool d'appareils IDT gratuitement RTOS

Les appareils à tester sont organisés dans des groupes. Chaque groupe d'appareils se compose d'un ou de plusieurs appareils identiques. Vous pouvez configurer Free IDT RTOS pour tester un seul appareil ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for Free RTOS peut tester en parallèle des appareils répondant aux mêmes spécifications. Il utilise une méthode séquentielle pour exécuter un groupe de tests différents pour chaque appareil d'un groupe.

Le device.json fichier possède un tableau à son niveau supérieur. Chaque attribut du tableau correspond à un nouveau pool de périphériques. Chaque pool de périphériques possède un attribut de tableau d'appareils, dans lequel plusieurs appareils sont déclarés. Dans le modèle, il existe un pool de périphériques et un seul appareil dans ce pool de périphériques. Vous pouvez ajouter un ou plusieurs appareils à un groupe d'appareils en modifiant la section devices du modèle device.json dans le dossier configs.

Note

Tous les appareils d'un même pool doivent avoir les mêmes spécifications techniques etSKU. Pour activer les compilations parallèles du code source pour différents groupes de test, IDT for Free RTOS copie le code source dans un dossier de résultats situé dans le dossier RTOS extrait IDT for Free. Vous devez référencer le chemin du code source dans votre commande de build ou de flash à l'aide de la testdata.sourcePath variable. IDTfor Free RTOS remplace cette variable par un chemin temporaire du code source copié. Pour de plus amples informations, veuillez consulter IDTpour les RTOS variables libres.

Voici un exemple de device.json fichier qui a été utilisé pour créer un pool de périphériques avec plusieurs appareils.

[ { "id": "pool-id", "sku": "sku", "features": [ { "name": "Wifi", "value": "Yes | No" }, { "name": "Cellular", "value": "Yes | No" }, { "name": "BLE", "value": "Yes | No" }, { "name": "PKCS11", "value": "RSA | ECC | Both" }, { "name": "OTA", "value": "Yes | No", "configs": [ { "name": "OTADataPlaneProtocol", "value": "MQTT | HTTP | None" } ] }, { "name": "KeyProvisioning", "value": "Onboard | Import | Both | No" } ], "devices": [ { "id": "device-id", "connectivity": { "protocol": "uart", "serialPort": "/dev/tty*" }, "secureElementConfig" : { "publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key", "publiDeviceCertificateArn": "arn:partition:iot:region:account-id:resourcetype:resource:qualifier", "secureElementSerialNumber": "secure-element-serialNo-value", "preProvisioned" : "Yes | No", "pkcs11JITPCodeVerifyRootCertSupport": "Yes | No" }, "identifiers": [ { "name": "serialNo", "value": "serialNo-value" } ] } ] } ]

Les attributs suivants sont utilisés dans le fichier device.json :

id

Un ID alphanumérique défini par l'utilisateur qui identifie de façon unique un groupe d'appareils. Les appareils appartenant à un groupe doivent être du même type. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail.

sku

Une valeur alphanumérique qui identifie de façon unique la carte que vous testez. Le SKU est utilisé pour suivre les tableaux qualifiés.

Note

Si vous souhaitez répertorier votre carte dans le catalogue des appareils AWS partenaires, le tableau que SKU vous spécifiez ici doit correspondre à celui SKU que vous avez utilisé lors du processus de mise en vente.

features

Tableau contenant les fonctionnalités prises en charge par l'appareil. AWS IoT Device Tester utilise ces informations pour sélectionner les tests de qualification à exécuter.

Les valeurs prises en charge sont :

Wifi

Indique si la carte contient des fonctionnalités Wi-Fi.

Cellular

Indique si votre carte est dotée de fonctionnalités cellulaires.

PKCS11

Indique l'algorithme de chiffrement de clé publique que la carte prend en charge. PKCS11est requis pour la qualification. Les valeurs prises en charge sont ECCRSA, etBoth. Bothindique que le tableau prend en charge les deux ECC etRSA.

KeyProvisioning

Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte.

Les valeurs valides sont ImportOnboard, Both etNo. OnboardBoth, ou l'approvisionnement No des clés est requis pour la qualification. Importà elle seule, n'est pas une option valide pour la qualification.

  • À utiliser Import uniquement si votre forum autorise l'importation de clés privées. ImportLa sélection n'est pas une configuration valide pour la qualification et ne doit être utilisée qu'à des fins de test, en particulier pour les cas de PKCS11 test. Onboard, Both ou No est requis pour la qualification.

  • À utiliser Onboard si votre carte prend en charge les clés privées intégrées (par exemple, si votre appareil possède un élément sécurisé ou si vous préférez générer votre propre paire de clés et votre propre certificat). Veillez à ajouter un élément secureElementConfig dans chacune des sections de l'appareil et indiquez le chemin absolu vers le fichier de clé publique dans le champ publicKeyAsciiHexFilePath.

  • À utiliser Both si votre tableau prend en charge à la fois l'importation de clés privées et la génération de clés intégrée pour le provisionnement des clés.

  • À utiliser No si votre tableau ne prend pas en charge l'approvisionnement en clés. Non'est une option valide que lorsque votre appareil est également préapprovisionné.

OTA

Indique si votre tableau prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'OtaDataPlaneProtocolattribut indique le protocole de OTA plan de données pris en charge par le périphérique. OTAavec l'un HTTP ou l'autre protocole du MQTT plan de données est requis pour la qualification. Pour ignorer l'exécution OTA des tests pendant les tests, définissez la OTA fonctionnalité sur No et l'OtaDataPlaneProtocolattribut surNone. Il ne s'agira pas d'une course de qualification.

BLE

Indique si votre carte est compatible avec le Bluetooth Low Energy (BLE).

devices.id

Un identificateur unique défini par l'utilisateur pour l'appareil testé.

devices.connectivity.serialPort

Le port série de l'ordinateur hôte utilisé pour se connecter aux appareils testés.

devices.secureElementConfig.PublicKeyAsciiHexFilePath

Obligatoire si votre planche PublicDeviceCertificateArn est fournie NOT pre-provisioned ou non. Comme Onboard il s'agit d'un type obligatoire de fourniture de clés, ce champ est actuellement obligatoire pour le groupe de FullTransportInterface TLS test. Si votre appareil l'estpre-provisioned, PublicKeyAsciiHexFilePath il est facultatif et n'a pas besoin d'être inclus.

Le bloc suivant est un chemin absolu vers le fichier contenant la clé publique en octets hexadécimaux extraite de la clé Onboard privée.

3059 3013 0607 2a86 48ce 3d02 0106 082a 8648 ce3d 0301 0703 4200 04cd 6569 ceb8 1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac 6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0 41b7 345c e746 1046 228e 5a5f d787 d571 dcb2 4e8d 75b3 2586 e2cc 0c

Si votre clé publique est au format .der, vous pouvez l'encoder directement en hexadécimal pour générer le fichier hexadécimal.

Pour générer le fichier hexadécimal à partir d'une clé publique .der, entrez la commande suivante : xxd

xxd -p pubkey.der > outFile

Si votre clé publique est au format .pem, vous pouvez extraire les en-têtes et pieds de page codés en base64 et les décoder au format binaire. Ensuite, vous codez la chaîne binaire en hexadécimal pour générer le fichier hexadécimal.

Pour générer un fichier hexadécimal pour une clé publique .pem, procédez comme suit :

  1. Exécutez la base64 commande suivante pour supprimer l'en-tête et le pied de page base64 de la clé publique. La clé décodée, nomméebase64key, est ensuite sortie dans le fichier pubkey.der :

    base64 —decode base64key > pubkey.der
  2. Exécutez la xxd commande suivante pour convertir pubkey.der au format hexadécimal. La clé obtenue est enregistrée sous outFile

    xxd -p pubkey.der > outFile
devices.secureElementConfig.PublicDeviceCertificateArn

Le certificat ARN de votre élément sécurisé qui est téléchargé sur AWS IoT Core. Pour plus d'informations sur le téléchargement de votre certificat vers AWS IoT Core, consultez la section Certificats client X.509 dans le guide du AWS IoT développeur.

devices.secureElementConfig.SecureElementSerialNumber

(Facultatif) Numéro de série de l'élément sécurisé. Le numéro de série est éventuellement utilisé pour créer des certificats d'appareil pour le provisionnement des JITR clés.

devices.secureElementConfig.preProvisioned

(Facultatif) Réglez sur « Oui » si l'appareil possède un élément sécurisé préconfiguré avec des informations d'identification verrouillées, qui ne peut pas importer, créer ou détruire des objets. Si cet attribut est défini sur Oui, vous devez fournir les étiquettes pkcs11 correspondantes.

devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport

(Facultatif) Définissez cette option sur Oui si l'PKCS11implémentation principale de l'appareil prend en charge le stockage pourJITP. Cela permettra le JITP codeverify test lors du test du noyau PKCS 11 et nécessite la fourniture des étiquettes de clé de vérification du code, de certificat et de certificat racine PKCS 11. JITP

identifiers

(Facultatif) Un tableau de paires nom-valeur arbitraires. Vous pouvez utiliser ces valeurs dans les commandes de création et flash décrites dans la section suivante.