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. # IDT avec suite de qualification FreeRTOS 2.0 (FRQ 2.0) La suite de qualification FreeRTOS 2.0 est une version mise à jour de la suite de qualification FreeRTOS. Nous recommandons aux développeurs d'utiliser FRQ 2.0 car il contient des scénarios de test pertinents pour qualifier les appareils qui exécutent les bibliothèques FreeRTOS Long Term Support (LTS). IDT pour FreeRTOS vérifie le port de FreeRTOS sur votre microcontrôleur et s'il communique efficacement avec. AWS IoT Plus précisément, il vérifie les interfaces de la couche de portage avec les bibliothèques FreeRTOS et si les référentiels de test FreeRTOS sont correctement implémentés. Il effectue également end-to-end des tests avec AWS IoT Core. [Les tests exécutés par IDT pour FreeRTOS sont définis dans le référentiel FreeRTOS. GitHub](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) IDT pour FreeRTOS exécute des tests sous forme d'applications intégrées qu'il fait clignoter sur le microcontrôleur testé. Les images binaires de l'application incluent FreeRTOS, les interfaces FreeRTOS portées et les pilotes de périphériques embarqués. Le but des tests est de vérifier que les interfaces FreeRTOS portées fonctionnent correctement au-dessus des pilotes de votre appareil. IDT for FreeRTOS génère des rapports de test que vous pouvez soumettre AWS IoT pour que votre matériel soit répertorié dans le AWS catalogue des appareils partenaires. Pour de plus amples informations, veuillez consulter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/). IDT pour FreeRTOS s'exécute sur un ordinateur hôte (Windows, macOS ou Linux) connecté à l'appareil testé. IDT configure et orchestre les cas de test et agrège les résultats. Il fournit également une interface de ligne de commande pour gérer l'exécution des tests. Afin de tester votre appareil, IDT for FreeRTOS crée des ressources telles que des AWS IoT objets, des groupes FreeRTOS, des fonctions Lambda. Pour créer ces ressources, IDT pour FreeRTOS utilise les informations d'identification configurées dans AWS le pour effectuer des appels d'API en `config.json` votre nom. Ces ressources sont allouées à différents moments d'un test. Lorsque vous exécutez IDT pour FreeRTOS sur votre ordinateur hôte, il exécute les étapes suivantes : 1. Chargement et validation des informations d'identification et de la configuration de votre appareil. 1. Tests sélectionnés avec les ressources locales et les ressources cloud requises. 1. Élimination des ressources locales et des ressources cloud. 1. Génération de rapports de tests indiquant si votre carte a réussi les tests obligatoires pour la qualification. # Configurez les prérequis de qualification LTS Cette section décrit les prérequis pour tester les microcontrôleurs avec. AWS IoT Device Tester ## Préparez-vous à la qualification FreeRTOS **Note** AWS IoT Device Tester for FreeRTOS recommande vivement d'utiliser le dernier correctif de la dernière version de FreeRTOS-LTS. IDT pour FRQ 2.0 est une qualification pour FreeRTOS. *Avant de lancer IDT FRQ 2.0 pour la qualification, vous devez terminer la qualification de [votre plateau dans le guide de qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html) FreeRTOS.* Pour porter des bibliothèques, les tester et les configurer`manifest.yml`, consultez la section Portage des bibliothèques [FreeRTOS dans le Guide de portage de *FreeRTOS*](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting.html). FRQ 2.0 contient un processus de qualification différent. Consultez [les derniers changements en matière de qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/latest-changes.html) dans le guide de *qualification FreeRTOS pour plus de détails*. Le référentiel [FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) doit être présent pour qu'IDT puisse fonctionner. Consultez le [fichier README.md](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/README.md) pour savoir comment cloner et porter ce dépôt vers votre projet source. FreeRTOS-Libraries-Integration-Testsdoit inclure le contenu `manifest.yml` situé à la racine de votre projet, pour que IDT puisse fonctionner. **Note** IDT dépend de l'implémentation de`UNITY_OUTPUT_CHAR`. Les journaux des résultats des tests et les journaux des appareils ne doivent pas être entrelacés. Voir [la section Implémentation des macros de journalisation des bibliothèques](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) dans le Guide de *portage de FreeRTOS* pour plus de détails. ## Télécharger IDT pour FreeRTOS Chaque version de FreeRTOS possède une version correspondante d'IDT pour FreeRTOS afin d'effectuer des tests de qualification. Téléchargez la version appropriée d'IDT pour FreeRTOS à [partir des versions](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) prises en charge de pour FreeRTOS. AWS IoT Device Tester Extrayez IDT pour FreeRTOS vers un emplacement du système de fichiers où vous disposez d'autorisations de lecture et d'écriture. Microsoft Windows ayant une limite de caractères pour la longueur du chemin, extrayez IDT pour FreeRTOS dans un répertoire racine tel que ou. `C:\` `D:\` **Note** Plusieurs utilisateurs ne doivent pas exécuter IDT à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé sur le réseau Windows. Cela entraînera des pannes ou une corruption des données. Nous vous recommandons d'extraire le package IDT sur un disque local. ## Télécharger Git Git doit être installé sur IDT comme condition préalable pour garantir l'intégrité du code source. Suivez les instructions du [GitHub](https://github.com/git-guides/install-git)guide pour installer Git. Pour vérifier la version actuellement installée de Git, entrez la commande `git --version` sur le terminal. **Avertissement** IDT utilise Git pour s'aligner sur le statut propre ou sale d'un répertoire. Si Git n'est pas installé, les groupes de `FreeRTOSIntegrity` test échoueront ou ne s'exécuteront pas comme prévu. Si IDT renvoie une erreur telle que `git executable not found` ou`git command not found`, installez ou réinstallez Git et réessayez. **Topics** + [Préparez-vous à la qualification FreeRTOS](#idt-preparing-qualification) + [Télécharger IDT pour FreeRTOS](#idt-download-dev-tester-afr) + [Télécharger Git](#idt-download-git) + [Créez un AWS compte](#lts-config-aws-account) + [AWS IoT Device Tester politique gérée](#managed-policy) + [(Facultatif) Installez le AWS Command Line Interface](#install-cli) ## Créez un AWS compte **Note** La suite de qualification IDT complète n'est prise en charge que dans les cas suivants Régions AWS USA Est (Virginie du Nord) USA Ouest (Oregon) Asie Pacifique (Tokyo) Europe (Irlande) Afin de tester votre appareil, IDT for FreeRTOS crée des ressources telles que des AWS IoT objets, des groupes FreeRTOS et des fonctions Lambda. Pour créer ces ressources, IDT for FreeRTOS nécessite que vous créiez et configuriez AWS un compte, ainsi qu'une politique IAM qui accorde à IDT for FreeRTOS l'autorisation d'accéder aux ressources en votre nom lors de l'exécution des tests. Les étapes suivantes consistent à créer et à configurer votre AWS compte. 1. Si vous avez déjà un AWS compte, passez à l'étape suivante. Sinon, créez un [AWS compte](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/). 1. Suivez les étapes décrites dans [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html). N'ajoutez pas d'autorisations ou de politiques pour le moment. 1. Pour exécuter des tests de qualification OTA, passez à l'étape 4. Sinon, passez à l'étape 5. 1. Associez la politique intégrée d'autorisations OTA IAM à votre rôle IAM. 1. **Important** Le modèle de stratégie suivant accorde à IDT l'autorisation de créer des rôles, de créer des stratégies et d'attacher des stratégies à des rôles. IDT pour FreeRTOS utilise ces autorisations pour les tests qui créent des rôles. Bien que le modèle de politique ne fournisse pas de privilèges d'administrateur à l'utilisateur, les autorisations peuvent être utilisées pour obtenir un accès administrateur à votre AWS compte. 1. Suivez les étapes ci-dessous pour associer les autorisations nécessaires à votre rôle IAM : 1. Sur la page **Autorisations**, choisissez **Ajouter des autorisations**. 1. Choisissez **Créer une politique en ligne**. 1. Sélectionnez l'onglet **JSON** et copiez les autorisations suivantes dans la zone de texte **JSON**. Utilisez le modèle sous **La plupart des régions** si vous n'êtes pas dans la région de Chine. Si vous vous trouvez dans la région de Chine, utilisez le modèle sous **Régions de Pékin et du Ningxia**. ------ #### [ Most Regions ] ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": [ "arn:aws:iotdeviceadvisor:*:*:suiterun/*/*", "arn:aws:iotdeviceadvisor:*:*:suitedefinition/*" ] }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::*:role/idt*", "Condition": { "StringEquals": { "iam:PassedToService": "iotdeviceadvisor.amazonaws.com" } } }, { "Effect": "Allow", "Action": [ "execute-api:Invoke*", "iam:ListRoles", "iot:Connect", "iot:CreateJob", "iot:DeleteJob", "iot:DescribeCertificate", "iot:DescribeEndpoint", "iot:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iot:UpdateThingShadow", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": "*" }, { "Effect": "Allow", "Action": "logs:DeleteLogGroup", "Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*" }, { "Effect": "Allow", "Action": "logs:GetLogEvents", "Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*:log-stream:*" }, { "Effect": "Allow", "Action": [ "iam:CreatePolicy", "iam:DetachRolePolicy", "iam:DeleteRolePolicy", "iam:DeletePolicy", "iam:CreateRole", "iam:DeleteRole", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:policy/idt*", "arn:aws:iam::*:role/idt*" ] }, { "Effect": "Allow", "Action": [ "ssm:GetParameters" ], "Resource": [ "arn:aws:ssm:*::parameter/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2" ] }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:RunInstances", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:CreateKeyPair", "ec2:DeleteKeyPair" ], "Resource": [ "arn:aws:ec2:*:*:key-pair/idt-ec2-ssh-key-*" ] }, { "Effect": "Allow", "Condition": { "StringEqualsIgnoreCase": { "aws:ResourceTag/Owner": "IoTDeviceTester" } }, "Action": [ "ec2:TerminateInstances", "ec2:DeleteSecurityGroup", "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress" ], "Resource": [ "*" ] } ] } ``` ------ ------ #### [ Beijing and Ningxia Regions ] Le modèle de politique suivant peut être utilisé dans les régions de Pékin et de Ningxia. ------ 1. Lorsque vous avez terminé, sélectionnez **Review policy (Examiner une politique)**. 1. Entrez **IDTFreeRTOSIAMPermissions**comme nom de la politique. 1. Choisissez **Create Policy** (Créer une politique). 1. Associez **AWSIoTDeviceTesterForFreeRTOSFullAccess** à votre rôle IAM. 1. Pour associer les autorisations nécessaires à votre rôle IAM, procédez comme suit : 1. Sur la page **Autorisations**, choisissez **Ajouter des autorisations**. 1. Choisissez **Attacher des politiques**. 1. Recherchez la politique **AWSIoTDeviceTesterForFreeRTOSFulld'accès**. Cochez la case. 1. Choisissez **Ajouter des autorisations**. 1. Exportez les informations d'identification pour IDT. Voir [Obtenir les informations d'identification du rôle IAM pour l'accès à la CLI](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html) pour plus de détails. ## AWS IoT Device Tester politique gérée La politique `AWSIoTDeviceTesterForFreeRTOSFullAccess` gérée contient les AWS IoT Device Tester autorisations suivantes pour la vérification des versions, les fonctionnalités de mise à jour automatique et la collecte de métriques. + `iot-device-tester:SupportedVersion` Accorde AWS IoT Device Tester l'autorisation de récupérer la liste des produits pris en charge, des suites de tests et des versions IDT. + `iot-device-tester:LatestIdt` Accorde AWS IoT Device Tester l'autorisation de récupérer la dernière version d'IDT disponible au téléchargement. + `iot-device-tester:CheckVersion` Accorde AWS IoT Device Tester l'autorisation de vérifier la compatibilité des versions pour IDT, les suites de tests et les produits. + `iot-device-tester:DownloadTestSuite` AWS IoT Device Tester Autorise le téléchargement des mises à jour de la suite de tests. + `iot-device-tester:SendMetrics` Accorde AWS l'autorisation de collecter des statistiques relatives à l'utilisation AWS IoT Device Tester interne. ## (Facultatif) Installez le AWS Command Line Interface Vous préférerez peut-être utiliser le AWS CLI pour effectuer certaines opérations. Si vous ne l'avez pas AWS CLI installé, suivez les instructions de la section [Installer le AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html). Configurez le AWS CLI pour la AWS région que vous souhaitez utiliser en l'exécutant à **aws configure** partir d'une ligne de commande. [Pour plus d'informations sur les AWS régions qui prennent en charge IDT pour FreeRTOS,AWS consultez Régions et points de terminaison.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) Pour plus d'informations sur la **aws configure** section [Configuration rapide avec **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config). # Premier test de votre carte microcontrôleur Vous pouvez utiliser IDT pour FreeRTOS pour tester votre implémentation des bibliothèques FreeRTOS. Après avoir porté les bibliothèques FreeRTOS pour les pilotes de périphériques de votre carte, exécutez-les pour exécuter les tests AWS IoT Device Tester de qualification sur votre carte microcontrôleur. ## Ajouter des couches de transfert pour les bibliothèques Pour transférer FreeRTOS sur votre appareil, consultez le Guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/porting-guide.html). Lors de l'implémentation du référentiel de tests FreeRTOS et du portage des couches FreeRTOS, vous devez fournir `manifest.yml` un chemin d'accès à chaque bibliothèque, y compris le référentiel de tests. Ce fichier se trouvera dans le répertoire racine de votre code source. Consultez les [instructions du fichier manifeste](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist-manifest-instr.html) pour plus de détails. ## Configurez vos AWS informations d'identification AWS IoT Device Tester pour communiquer avec le AWS cloud Vous devez configurer vos AWS informations d'identification AWS IoT Device Tester pour pouvoir communiquer avec le AWS Cloud. Pour plus d'informations, voir [Configurer les AWS informations d'identification et la région pour le développement](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). Les AWS informations d'identification valides sont spécifiées dans le fichier `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/config.json` de configuration. ``` "auth": { "method": "environment" } "auth": { "method": "file", "credentials": { "profile": "" } } ``` L'`auth`attribut du `config.json` fichier possède un champ de méthode qui contrôle AWS l'authentification et peut être déclaré en tant que fichier ou environnement. La définition du champ sur environnement extrait vos AWS informations d'identification des variables d'environnement de votre machine hôte. La définition du champ sur fichier permet d'importer un profil spécifié à partir du fichier de `.aws/credentials` configuration. **Topics** + [Ajouter des couches de transfert pour les bibliothèques](#lts-add-port-layer) + [Configurez vos AWS informations d'identification AWS IoT Device Tester pour communiquer avec le AWS cloud](#lts-cfg-aws-afr) + [Créer un pool d'appareils dans IDT pour FreeRTOS](lts-cfg-dt-dp.md) + [Configurer les paramètres de création, de flash et de test](lts-cfg-dt-ud.md) # Créer un pool d'appareils dans IDT pour FreeRTOS 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 IDT pour FreeRTOS afin de tester un seul appareil ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for FreeRTOS peut tester des appareils avec les mêmes spécifications en parallèle. 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 et le même SKU. Pour permettre des compilations parallèles du code source pour différents groupes de test, IDT pour FreeRTOS copie le code source dans un dossier de résultats à l'intérieur du dossier extrait d'IDT pour FreeRTOS. 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. IDT pour FreeRTOS remplace cette variable par un chemin temporaire du code source copié. Pour de plus amples informations, veuillez consulter [IDT pour les variables FreeRTOS](lts-dt-vars.md). 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. La référence est utilisée pour effectuer le suivi des cartes qualifiées. Si vous souhaitez mettre votre carte en vente dans le catalogue des appareils AWS partenaires, le SKU que vous spécifiez ici doit correspondre au 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 cryptographie à clé publique pris en charge par la carte. PKCS11 est requis pour la qualification. Les valeurs prises en charge sont `ECC``RSA`, et`Both`. `Both`indique que le tableau prend en charge les deux `ECC` et`RSA`. ** `KeyProvisioning` ** Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte. Les valeurs valides sont `Import``Onboard`, `Both` et`No`. `Onboard``Both`, 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. `Import`La 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. `No`n'est une option valide que lorsque votre appareil est également préconfiguré. ** `OTA` ** Indique si votre carte mère prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'attribut `OtaDataPlaneProtocol` indique le protocole de plan de données OTA pris en charge par le périphérique. L'OTA avec le protocole de plan de données HTTP ou MQTT est requis pour la qualification. Pour ignorer l'exécution des tests OTA pendant les tests, définissez la fonctionnalité OTA sur `No` et l'`OtaDataPlaneProtocol`attribut sur`None`. Il ne s'agira pas d'une course de qualification. ** `BLE` ** Indique si la carte prend en charge 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 n'est PAS `pre-provisioned` ou n'`PublicDeviceCertificateArn`est pas fournie. Comme `Onboard` il s'agit d'un type obligatoire de fourniture de clés, ce champ est actuellement obligatoire pour le groupe de test FullTransportInterface TLS. Si votre appareil l'est`pre-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ée`base64key`, est ensuite sortie dans le fichier `pubkey.der` : ``` base64 —decode base64key > pubkey.der ``` 1. 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` ** L'ARN du certificat de votre élément sécurisé qui est téléchargé vers 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](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) 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 clés JITR. ** `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 ce paramètre sur **Oui** si l'PKCS11 implémentation principale de l'appareil prend en charge le stockage pour JITP. Cela permettra le test JITP lors du `codeverify` test du noyau PKCS 11 et nécessitera la fourniture d'étiquettes de clé de vérification du code, de certificat JITP et de certificat racine PKCS 11. ** `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. # Configurer les paramètres de création, de flash et de test IDT pour FreeRTOS crée et affiche automatiquement les tests sur votre carte. Pour activer cela, vous devez configurer IDT pour exécuter les commandes de compilation et de flash pour votre matériel. Les paramètres de création et flash sont configurés dans le modèle de fichier `userdata.json` situé dans le dossier `config`. # Configurer les paramètres pour tester un seul appareil Les paramètres de création, de flash et de test sont définis dans le fichier `configs/userdata.json`. L'exemple JSON suivant montre comment configurer IDT pour FreeRTOS afin de tester plusieurs appareils : ``` { "sourcePath": "", "retainModifiedSourceDirectories": true | false, "freeRTOSVersion": "", "freeRTOSTestParamConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_param_config.h", "freeRTOSTestExecutionConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_execution_config.h", "buildTool": { "name": "your-build-tool-name", "version": "your-build-tool-version", "command": [ " -any-additional-flags {{testData.sourcePath}}" ] }, "flashTool": { "name": "your-flash-tool-name", "version": "your-flash-tool-version", "command": [ " -any-additional-flags {{testData.sourcePath}} -any-additional-flags" ] }, "testStartDelayms": 0, "echoServerConfiguration": { "keyGenerationMethod": "EC | RSA", "serverPort": 9000 }, "otaConfiguration": { "otaE2EFirmwarePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process", "otaPALCertificatePath": "/path/to/ota/pal/certificate/on/device", "deviceFirmwarePath" : "/path/to/firmware/image/name/on/device", "codeSigningConfiguration": { "signingMethod": "AWS | Custom", "signerHashingAlgorithm": "SHA1 | SHA256", "signerSigningAlgorithm": "RSA | ECDSA", "signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file", "untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier", "signerCertificateFileName": "signerCertificate-file-name", "compileSignerCertificate": true | false, // ***********Use signerPlatform if you choose AWS for signingMethod*************** "signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF" ] } }, ********** This section is used for PKCS #11 labels of private key, public key, device certificate, code verification key, JITP certificate, and root certificate. When configuring PKCS11, you set up labels and you must provide the labels of the device certificate, public key, and private key for the key generation type (EC or RSA) it was created with. If your device supports PKCS11 storage of JITP certificate, code verification key, and root certificate, set 'pkcs11JITPCodeVerifyRootCertSupport' to 'Yes' in device.json and provide the corresponding labels. ********** "pkcs11LabelConfiguration":{ "pkcs11LabelDevicePrivateKeyForTLS": "", "pkcs11LabelDevicePublicKeyForTLS": "", "pkcs11LabelDeviceCertificateForTLS": "", "pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS": "", "pkcs11LabelPreProvisionedECDevicePublicKeyForTLS": "", "pkcs11LabelPreProvisionedECDeviceCertificateForTLS": "", "pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS": "", "pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS": "", "pkcs11LabelPreProvisionedRSADeviceCertificateForTLS": "", "pkcs11LabelCodeVerifyKey": "", "pkcs11LabelJITPCertificate": "", "pkcs11LabelRootCertificate": "" } } ``` Voici les attributs utilisés dans le fichier `userdata.json` : ** `sourcePath` ** Le chemin d'accès à la racine du code source FreeRTOS porté. ** `retainModifiedSourceDirectories` ** (Facultatif) Vérifie s'il faut conserver les répertoires sources modifiés utilisés lors de la construction et du flashage à des fins de débogage. S'il est défini sur`true`, les répertoires sources modifiés sont nommés RetainedSrc et se trouvent dans les dossiers du journal des résultats de chaque groupe de test exécuté. S'il n'est pas inclus, le champ est défini par défaut sur. `false` ** `freeRTOSTestParamConfigPath` ** Le chemin d'accès au `test_param_config.h` fichier à FreeRTOS-Libraries-Integration-Tests intégrer. Ce fichier doit utiliser la variable `{{testData.sourcePath}}` placeholder pour le rendre relatif à la racine du code source. AWS IoT Device Tester utilise les paramètres de ce fichier pour configurer les tests. ** `freeRTOSTestExecutionConfigPath` ** Le chemin d'accès au `test_execution_config.h` fichier à FreeRTOS-Libraries-Integration-Tests intégrer. Ce fichier doit utiliser la variable d'`{{testData.sourcePath}}`espace réservé pour le rendre relatif à la racine du dépôt. AWS IoT Device Tester utilise ce fichier pour contrôler les tests à exécuter. ** `freeRTOSVersion` ** La version de FreeRTOS, y compris la version de correctif utilisée dans votre implémentation. Voir [Versions prises en charge de AWS IoT Device Tester pour FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) pour les versions de FreeRTOS compatibles avec FreeRTOS. AWS IoT Device Tester ** `buildTool` ** La commande permettant de créer votre code source. Toutes les références au chemin du code source dans la commande de construction doivent être remplacées par la AWS IoT Device Tester variable`{{testData.sourcePath}}`. Utilisez l'`{{config.idtRootPath}}`espace réservé pour référencer un script de génération relatif au chemin AWS IoT Device Tester racine. ** `flashTool` ** Commande permettant de flasher une image sur votre appareil. Toutes les références au chemin du code source dans la commande flash doivent être remplacées par la AWS IoT Device Tester variable`{{testData.sourcePath}}`. Utilisez l'`{{config.idtRootPath}}`espace réservé pour référencer un script flash relatif au chemin AWS IoT Device Tester racine. La nouvelle structure des tests d'intégration avec FRQ 2.0 ne nécessite pas de variables de chemin telles que `{{enableTests}}` et`{{buildImageName}}`. Les tests OTA de bout en bout sont exécutés avec les modèles de configuration fournis dans le [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/config_template/) GitHub référentiel. Si les fichiers du GitHub référentiel sont présents dans votre projet source parent, le code source n'est pas modifié entre les tests. Si une image de compilation différente pour OTA de bout en bout est nécessaire, vous devez créer cette image dans le script de génération et la spécifier dans le `userdata.json` fichier spécifié ci-dessous`otaConfiguration`. ** `testStartDelayms` ** Spécifie le nombre de millisecondes que le lanceur de tests FreeRTOS attendra avant de commencer à exécuter les tests. Cela peut être utile si l'appareil testé commence à produire des informations de test importantes avant qu'IDT n'ait la chance de se connecter et de commencer à se connecter en raison de problèmes de réseau ou d'autres problèmes de latence. Cette valeur s'applique uniquement aux groupes de test FreeRTOS, et non aux autres groupes de test qui n'utilisent pas le lanceur de tests FreeRTOS, tels que les tests OTA. Si vous recevez une erreur liée à la valeur **10 attendue mais que vous en avez reçu 5**, ce champ doit être défini sur 5000. ** `echoServerConfiguration` ** Configuration permettant de configurer le serveur d'écho pour le test TLS. Ce champ est obligatoire. ** `keyGenerationMethod` ** Le serveur Echo est configuré avec cette option. Les options sont EC ou RSA. ** `serverPort` ** Le numéro de port sur lequel s'exécute le serveur Echo. ** `otaConfiguration` ** Configuration pour les tests OTA PAL et OTA E2E. Ce champ est obligatoire. **`otaE2EFirmwarePath`** Chemin d'accès à l'image du bin OTA qu'IDT utilise pour les tests OTA de bout en bout. ** `otaPALCertificatePath` ** Le chemin d'accès au certificat pour le test OTA PAL sur l'appareil. Ceci est utilisé pour vérifier la signature. Par exemple, **ecdsa-sha256-signer.crt.pem**. ** `deviceFirmwarePath` ** Chemin d'accès au nom codé en dur de l'image du microprogramme à démarrer. Si votre appareil n'utilise PAS le système de fichiers pour le démarrage du microprogramme, spécifiez ce champ sous la forme`'NA'`. Si votre appareil utilise le système de fichiers pour le démarrage du microprogramme, spécifiez le chemin ou le nom de l'image de démarrage du microprogramme. ** `codeSigningConfiguration` ** ** `signingMethod` ** Méthode de signature de code. Les valeurs possibles sont AWS ou Custom. Pour les régions de Pékin et de Ningxia, utilisez Custom. AWS la signature de code n'est pas prise en charge dans cette région. ** `signerHashingAlgorithm` ** Algorithme de hachage pris en charge sur le périphérique. Les valeurs possibles sont `SHA1` ou `SHA256`. ** `signerSigningAlgorithm` ** Algorithme de signature pris en charge sur le périphérique. Les valeurs possibles sont `RSA` ou `ECDSA`. ** `signerCertificate` ** Certificat de confiance utilisé pour l'OTA. Pour la méthode de signature AWS du code, utilisez l'Amazon Resource Name (ARN) pour le certificat sécurisé chargé sur le AWS Certificate Manager. Pour la méthode de signature de code personnalisée, utilisez le chemin absolu vers le fichier de certificat du signataire. Pour plus d'informations sur la création d'un certificat sécurisé, voir [Création d'un certificat de signature de code](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html). ** `untrustedSignerCertificate` ** L'ARN ou le chemin de fichier d'un deuxième certificat utilisé dans certains tests OTA en tant que certificat non fiable. Pour plus d'informations sur la création d'un certificat, voir [Création d'un certificat de signature de code](https://docs.aws.amazon.com//freertos/latest/userguide/ota-code-sign-cert.html). ** `signerCertificateFileName` ** Nom de fichier du certificat de signature de code sur l'appareil. Cette valeur doit correspondre au nom de fichier que vous avez fourni lors de l'exécution de la `aws acm import-certificate` commande. ** `compileSignerCertificate` ** Valeur booléenne qui détermine le statut du certificat de vérification de signature. Les valeurs valides sont `true` et `false`. Définissez cette valeur sur **true** si le certificat de vérification de signature du signataire du code n'est pas fourni ou flashé. Il doit être compilé dans le projet. AWS IoT Device Tester récupère le certificat sécurisé et le compile dans. `aws_codesigner_certificate.h` ** `signerPlatform` ** Algorithme de signature et de hachage utilisé par AWS Code Signer lors de la création de la tâche de mise à jour OTA. Actuellement, les valeurs possibles pour ce champ sont `AmazonFreeRTOS-TI-CC3220SF` et `AmazonFreeRTOS-Default`. + Choisissez `AmazonFreeRTOS-TI-CC3220SF`, si `SHA1` et `RSA`. + Choisissez `AmazonFreeRTOS-Default`, si `SHA256` et `ECDSA`. + Si vous avez besoin de `SHA256` \$1 `RSA` ou `SHA1` \$1 `ECDSA` pour votre configuration, contactez-nous pour obtenir une assistance complémentaire. + Configurez `signCommand` si vous avez choisi `Custom` pour `signingMethod`. ** `signCommand` ** Deux espaces réservés `{{inputImageFilePath}}` et `{{outputSignatureFilePath}}` sont obligatoires dans la commande. `{{inputImageFilePath}}` est le chemin d'accès au fichier de l'image créée par IDT qu’il faut signer. `{{outputSignatureFilePath}} ` est le chemin d’accès au fichier de la signature qui sera généré par le script. ** `pkcs11LabelConfiguration` ** PKCS11 la configuration des étiquettes nécessite au moins un ensemble d'étiquettes d'étiquette de certificat de périphérique, d'étiquette de clé publique et d'étiquette de clé privée pour exécuter les groupes de PKCS11 test. Les PKCS11 étiquettes requises sont basées sur la configuration de votre appareil dans le `device.json` fichier. Si le paramètre pré-provisionné est défini sur **Oui**`device.json`, les étiquettes requises doivent être l'une des suivantes en fonction de ce qui est choisi pour la PKCS11 fonctionnalité. + `PreProvisionedEC` + `PreProvisionedRSA` Si le préprovisionnement est défini sur **Non**`device.json`, les étiquettes requises sont les suivantes : + `pkcs11LabelDevicePrivateKeyForTLS` + `pkcs11LabelDevicePublicKeyForTLS` + `pkcs11LabelDeviceCertificateForTLS` Les trois libellés suivants sont obligatoires uniquement si vous sélectionnez **Oui** pour `pkcs11JITPCodeVerifyRootCertSupport` dans votre `device.json` fichier. + `pkcs11LabelCodeVerifyKey` + `pkcs11LabelRootCertificate` + `pkcs11LabelJITPCertificate` Les valeurs de ces champs doivent correspondre aux valeurs définies dans le Guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html). ** `pkcs11LabelDevicePrivateKeyForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé privée. Pour les appareils dotés d'un support intégré et d'importation pour l'approvisionnement des clés, cette étiquette est utilisée à des fins de test. Cette étiquette peut être différente de celle définie pour le boîtier préapprovisionné. Si le provisionnement des clés est défini sur **Non** et que le préprovisionnement est défini sur **Oui**`device.json`, ce paramètre ne sera pas défini. ** `pkcs11LabelDevicePublicKeyForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé publique. Pour les appareils dotés d'un support intégré et d'importation pour l'approvisionnement des clés, cette étiquette est utilisée à des fins de test. Cette étiquette peut être différente de celle définie pour le boîtier préapprovisionné. Si le provisionnement des clés est défini sur **Non** et que le préprovisionnement est défini sur **Oui**`device.json`, ce paramètre ne sera pas défini. ** `pkcs11LabelDeviceCertificateForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat de l'appareil. Pour les appareils dotés d'un support intégré et d'importation pour l'approvisionnement des clés, cette étiquette sera utilisée à des fins de test. Cette étiquette peut être différente de celle définie pour le boîtier préapprovisionné. Si le provisionnement des clés est défini sur **Non** et que le préprovisionnement est défini sur **Oui**`device.json`, ce paramètre ne sera pas défini. ** `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé privée. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préapprovisionnement avec une clé EC, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS`, doivent être fournies. Cette étiquette peut être différente de celle définie pour les valises à bord et les valises d'importation. ** `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé publique. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préapprovisionnement avec une clé EC, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS`, doivent être fournies. Cette étiquette peut être différente de celle définie pour les valises à bord et les valises d'importation. ** `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat de l'appareil. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préapprovisionnement avec une clé EC, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedRSADeviceCertificateForTLS`, doivent être fournies. Cette étiquette peut être différente de celle définie pour les valises à bord et les valises d'importation. ** `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé privée. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préprovisionnement à l'aide d'une clé RSA, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS`, doivent être fournies. ** `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé publique. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préprovisionnement à l'aide d'une clé RSA, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedECDevicePublicKeyForTLS`, doivent être fournies. ** `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat de l'appareil. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préprovisionnement à l'aide d'une clé RSA, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedECDeviceCertificateForTLS`, doivent être fournies. ** `pkcs11LabelCodeVerifyKey` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé de vérification du code. Si votre appareil prend en charge le stockage PKCS \$111 du certificat JITP, de la clé de vérification du code et du certificat racine, fournissez cette étiquette. Lorsque `pkcs11JITPCodeVerifyRootCertSupport` la `device.json` valeur Oui est définie sur **Oui**, cette étiquette doit être fournie. ** `pkcs11LabelJITPCertificate` ** (Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat JITP. Si votre appareil prend en charge le stockage PKCS \$111 du certificat JITP, de la clé de vérification du code et du certificat racine, fournissez cette étiquette. Lorsque `pkcs11JITPCodeVerifyRootCertSupport` la `device.json` valeur Oui est définie sur **Oui**, cette étiquette doit être fournie. # IDT pour les variables FreeRTOS Les commandes permettant de créer votre code et de flasher l'appareil peuvent nécessiter une connectivité ou d'autres informations sur vos appareils pour fonctionner correctement. AWS IoT Device Tester vous permet de référencer les informations du périphérique dans Flash et de créer des commandes à l'aide de [JsonPath](https://goessner.net/articles/JsonPath/). À l'aide d' JsonPathexpressions simples, vous pouvez récupérer les informations requises spécifiées dans votre `device.json` fichier. ## Variables de chemin IDT pour FreeRTOS définit les variables de chemin suivantes qui peuvent être utilisées dans les lignes de commande et les fichiers de configuration : ** `{{testData.sourcePath}}` ** Développe le code source du chemin d'accès. Si vous utilisez cette variable, elle doit être utilisée dans les commandes flash et build. ** `{{device.connectivity.serialPort}}` ** Extension au port série. ** `{{device.identifiers[?(@.name == 'serialNo')].value[0]}}` ** Extension jusqu'au numéro de série de votre appareil. ** `{{config.idtRootPath}}` ** S'étend jusqu'au chemin AWS IoT Device Tester racine. # Interface utilisateur pour IDT pour la suite de qualification FreeRTOS 2.0 (FRQ 2.0) AWS IoT Device Tester for FreeRTOS (IDT for FreeRTOS) inclut une interface utilisateur (UI) Web dans laquelle vous pouvez interagir avec l'application de ligne de commande IDT et les fichiers de configuration associés. Vous utilisez l'interface utilisateur IDT pour FreeRTOS pour créer une nouvelle configuration ou modifier une configuration existante pour votre appareil. Vous pouvez également utiliser l'interface utilisateur pour appeler l'application IDT et exécuter les tests FreeRTOS sur votre appareil. Pour plus d'informations sur l'utilisation de la ligne de commande pour exécuter des tests de qualification, consultez[Premier test de votre carte microcontrôleur](lts-qual-steps.md). Cette section décrit les prérequis pour l'interface utilisateur IDT pour FreeRTOS et comment exécuter des tests de qualification à partir de l'interface utilisateur. **Topics** + [Configurer les prérequis IDT](#lts-dev-tester-ui-prereqs) + [Configurer les AWS informations d'identification pour utiliser l'interface utilisateur IDT](lts-configure-aws-credentials.md) + [Ouvrez l'interface utilisateur IDT pour FreeRTOS](lts-open-idt-ui.md) + [Création d'une nouvelle configuration](lts-create-new-configuration.md) + [Modifier une configuration existante](lts-modify-existing-configuration.md) + [Exécuter des tests de qualification](lts-run-tests-from-ui.md) ## Configurer les prérequis IDT Pour exécuter des tests via l'interface utilisateur AWS IoT Device Tester (IDT) pour FreeRTOS, vous devez remplir les conditions requises sur la [Configurez les prérequis de qualification LTS](lts-idt-dev-tester-prereqs.md) page de qualification IDT FreeRTOS (FRQ) 2.x. # Configurer les AWS informations d'identification pour utiliser l'interface utilisateur IDT Vous devez configurer vos informations d'identification utilisateur IAM pour l' AWS utilisateur que vous avez créé dans[Créez un AWS compte](lts-idt-dev-tester-prereqs.md#lts-config-aws-account). Vous pouvez spécifier vos informations d'identification de deux manières : + Dans un fichier d'informations d'identification + En tant que variables d'environnement ## Configurer les AWS informations d'identification avec un fichier d'informations d'identification IDT utilise le même fichier d'informations d'identification que l' AWS CLI. Pour de plus amples informations, veuillez consulter [Fichiers de configuration et d'informations d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html). L'emplacement du fichier d'informations d'identification varie en fonction du système d'exploitation que vous utilisez : + **macOS et Linux** — `~/.aws/credentials` + **Windows** – `C:\Users\UserName\.aws\credentials` Ajoutez vos AWS informations d'identification au `credentials` fichier au format suivant : ``` [default] aws_access_key_id = your_access_key_id aws_secret_access_key = your_secret_access_key ``` **Note** Si vous n'utilisez pas le `default` AWS profil, vous devez spécifier le nom du profil dans l'interface utilisateur IDT pour FreeRTOS. Pour plus d'informations sur les profils, consultez [Configuration et paramètres des fichiers d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html). ## Configurer les AWS informations d'identification avec des variables d'environnement Les variables d'environnement sont des variables gérées par le système d'exploitation et utilisées par les commandes du système. Ils ne sont pas enregistrés si vous fermez la session SSH. L'interface utilisateur IDT pour FreeRTOS utilise les variables d'environnement `AWS_SECRET_ACCESS_KEY` et pour `AWS_ACCESS_KEY_ID` stocker vos informations d'identification. AWS Pour définir ces variables sous Linux, macOS ou Unix, utilisez **export**: ``` export AWS_ACCESS_KEY_ID=your_access_key_id export AWS_SECRET_ACCESS_KEY=your_secret_access_key ``` Pour définir ces variables sous Windows, utilisez **set** : ``` set AWS_ACCESS_KEY_ID=your_access_key_id set AWS_SECRET_ACCESS_KEY=your_secret_access_key ``` # Ouvrez l'interface utilisateur IDT pour FreeRTOS Cette rubrique explique comment ouvrir l'interface utilisateur IDT pour FreeRTOS afin d'utiliser la suite de qualification FreeRTOS. **Pour ouvrir l'interface utilisateur IDT pour FreeRTOS** 1. Téléchargez une version IDT compatible pour FreeRTOS. Extrayez ensuite l'archive téléchargée dans un répertoire pour lequel vous disposez d'autorisations de lecture et d'écriture. 1. Accédez au répertoire d'installation d'IDT pour FreeRTOS : ``` cd devicetester-extract-location/bin ``` 1. Exécutez la commande suivante pour ouvrir l'interface utilisateur IDT pour FreeRTOS : ------ #### [ Linux ] ``` .devicetester_ui_linux_x86-64 ``` ------ #### [ Windows ] ``` ./devicetester_ui_win_x64-64 ``` ------ #### [ macOS ] ``` ./devicetester_ui_mac_x86-64 ``` **Note** Sous macOS, pour autoriser votre système à exécuter l'interface utilisateur, accédez à **Préférences système -> Sécurité et confidentialité**. Lorsque vous exécutez les tests, vous devrez peut-être le faire trois fois de plus. ------ L'interface utilisateur IDT pour FreeRTOS s'ouvre dans votre navigateur par défaut. Les trois dernières versions majeures des navigateurs suivants sont compatibles avec l'interface utilisateur : + Google Chrome + Mozilla Firefox + Microsoft Edge + Apple Safari pour macOS **Note** Pour une meilleure expérience, nous recommandons Google Chrome ou Mozilla Firefox pour accéder à l'interface utilisateur IDT pour FreeRTOS. Microsoft Internet Explorer n'est pas pris en charge par l'interface utilisateur. **Important** Vous devez configurer vos AWS informations d'identification avant d'ouvrir l'interface utilisateur. Si vous n'avez pas configuré vos informations d'identification, fermez la fenêtre du navigateur IDT pour FreeRTOS UI, suivez les étapes [Configurer les AWS informations d'identification pour utiliser l'interface utilisateur IDT](lts-configure-aws-credentials.md) indiquées, puis rouvrez l'interface utilisateur IDT pour FreeRTOS. # Création d'une nouvelle configuration Si vous utilisez IDT pour la première fois, vous devez créer une nouvelle configuration pour configurer les fichiers de configuration JSON dont IDT pour FreeRTOS a besoin pour exécuter des tests. Vous pouvez ensuite exécuter des tests ou modifier la configuration créée. Pour des exemples de `userdata.json` fichiers, et`config.json`,,,`device.json`,,,,,,,,,,[Premier test de votre carte microcontrôleur](lts-qual-steps.md),, **Pour créer une configuration** 1. **Dans l'interface utilisateur IDT pour FreeRTOS, ouvrez le menu de navigation et choisissez Create new configuration.** ![\[Interface Device Tester for FreeRTOS avec bouton « Créer une nouvelle configuration » et informations sur l'autotest automatique des microcontrôleurs.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-create-configuration.png) 1. Suivez l'assistant de configuration pour saisir les paramètres de configuration IDT utilisés pour exécuter les tests de qualification. L'assistant configure les paramètres suivants dans les fichiers de configuration JSON situés dans le `devicetester-extract-location/config` répertoire. + **Paramètres des appareils** : paramètres du pool de périphériques pour les appareils à tester. Ces paramètres sont configurés dans les `sku` champs `id` et, et les **appareils** sont bloqués pour le pool de périphériques dans le `config.json` fichier. ![\[Écran de configuration du Device Tester for FreeRTOS avec les champs Identifiant et SKU pour configurer un pool d'appareils, options de configuration des appareils telles que la méthode de connectivité, l'approvisionnement des clés, les paramètres PKCS #11, les champs de saisie des détails de l'appareil et les commandes pour ajouter des appareils ou des identifiants.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-device-settings.png) + **AWS paramètres du compte** — Les Compte AWS informations utilisées par IDT pour FreeRTOS pour AWS créer des ressources lors des tests. Ces paramètres sont configurés dans le `config.json` fichier. ![\[Compte AWS page de paramètres avec des champs pour la région du compte, l'emplacement des informations d'identification sous forme de fichier ou d'environnement et le nom du profil\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-account-settings.png) + **Implémentation de FreeRTOS** — Le chemin absolu vers le référentiel FreeRTOS et le code porté, ainsi que la version de FreeRTOS sur laquelle vous souhaitez exécuter IDT FRQ. Les chemins d'accès aux fichiers d'en-tête d'exécution et de configuration des paramètres depuis le `FreeRTOS-Libraries-Integration-Tests` GitHub référentiel. Les commandes de compilation et de flash pour votre matériel qui permettent à IDT de créer et de tester automatiquement votre carte mère. Ces paramètres sont configurés dans le `userdata.json` fichier. ![\[Section de configuration de l'implémentation de FreeRTOS avec les chemins du référentiel, les chemins d'exécution des tests, la version de FreeRTOS, les détails de l'outil de génération et les paramètres de l'outil Flash.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-implementation-settings.png) + **Étiquettes PKCS \$111 et serveur Echo** : les étiquettes [PKCS \$111](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) qui correspondent aux clés fournies sur votre matériel en fonction de la fonctionnalité clé et de la méthode de fourniture des clés. Les paramètres de configuration du serveur Echo pour les tests de l'interface de transport. Ces paramètres sont configurés dans les `device.json` fichiers `userdata.json` et. ![\[Étiquettes PKCS #11 et configurations du serveur Echo avec champs de saisie pour les étiquettes clés, la méthode de génération des clés et le numéro de port du serveur\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-pkcs11-settings.png) + **Over-the-air Mises à jour (OTA)** : paramètres qui contrôlent les tests de fonctionnalité OTA. Ces paramètres sont configurés dans le `features` bloc des `userdata.json` fichiers `device.json` et. ![\[Options de configuration de mise à jour OTA : ignorer les tests, les protocoles de données, les chemins du microprogramme, le chemin du certificat PAL, la signature de code, les hash/sign algorithmes, les certificats de trusted/untrusted signataire, le fichier de certificat de signature, le certificat de signature de compilation, la plateforme de signature.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-ota-settings.png) 1. Sur la page **Révision**, vérifiez vos informations de configuration. ![\[La configuration a créé une boîte de dialogue pour Device Tester for FreeRTOS, montrant des détails sur la création d'une nouvelle configuration de test avec des options pour modifier ou exécuter des tests.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-configuration-created.png) Après avoir passé en revue votre configuration, pour exécuter vos tests de qualification, choisissez **Run tests**. # Modifier une configuration existante Si vous avez déjà configuré des fichiers de configuration pour IDT pour FreeRTOS, vous pouvez utiliser l'interface utilisateur IDT pour FreeRTOS pour modifier votre configuration existante. Les fichiers de configuration existants doivent se trouver dans le `devicetester-extract-location/config` répertoire. **Pour modifier une configuration** 1. **Dans l'interface utilisateur IDT pour FreeRTOS, ouvrez le menu de navigation et choisissez Modifier la configuration existante.** Le tableau de bord de configuration affiche des informations sur vos paramètres de configuration existants. Si une configuration est incorrecte ou indisponible, le statut de cette configuration est`Error validating configuration`. ![\[Écran de configuration avec le périphérique Compte AWS, l'implémentation de FreeRTOS, les étiquettes PKCS et le serveur d'écho, les mises à jour et les over-the-air sections de paramètres de test indiquant un statut valide.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/modify-existing-configuration.png) 1. Pour modifier un paramètre de configuration existant, procédez comme suit : 1. Choisissez le nom d'un paramètre de configuration pour ouvrir sa page de paramètres. 1. Modifiez les paramètres, puis choisissez **Enregistrer** pour régénérer le fichier de configuration correspondant. 1. Pour modifier les paramètres d'exécution du test IDT pour FreeRTOS, **choisissez les paramètres du cycle de test IDT dans la vue d'**édition : ![\[Boîte de dialogue des paramètres d'exécution du test IDT avec des options pour sélectionner les tests, ignorer les groupes de tests, multiplier le délai d'attente et arrêter en cas de premier échec.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/idt-testrun-settings.png) Une fois que vous avez terminé de modifier votre configuration, vérifiez que tous vos paramètres de configuration sont validés. Si le statut de chaque paramètre de configuration est`Valid`, vous pouvez exécuter vos tests de qualification avec cette configuration. # Exécuter des tests de qualification Après avoir créé une configuration pour l'interface utilisateur IDT pour FreeRTOS, vous pouvez exécuter vos tests de qualification. **Pour exécuter des tests de qualification** 1. Dans le menu de navigation, choisissez **Exécuter des tests**. 1. Choisissez **Démarrer les tests** pour démarrer le test. Par défaut, tous les tests applicables sont exécutés pour la configuration de votre appareil. IDT pour FreeRTOS génère un rapport de qualification lorsque tous les tests sont terminés. ![\[L'interface Device Tester pour FreeRTOS indique qu'aucun test n'a encore été effectué, avec des options pour créer une nouvelle configuration, modifier la configuration existante et exécuter des tests.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/idt-run-tests.png) IDT pour FreeRTOS exécute les tests de qualification. Il affiche ensuite le résumé du test et les éventuelles erreurs dans la console **Test Runner**. Une fois le test terminé, vous pouvez consulter les résultats du test et les journaux depuis les emplacements suivants : + Les résultats des tests se trouvent dans le `devicetester-extract-location/results/execution-id` répertoire. + Les journaux de test se trouvent dans le `devicetester-extract-location/results/execution-id/logs` répertoire. Pour plus d'informations sur les résultats des tests et les journaux, consultez [Consultez l'IDT gratuitement RTOSresults](view-results-lts.md) et[Consultez l'IDT gratuitement RTOSlogs](view-logs-lts.md). ![\[Journal d'exécution de Device Tester for FreeRTOS indiquant les tests réussis, les groupes de tests et les chemins de fichiers pour les journaux et les rapports.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/idt-results.png) # Exécutez la suite de qualification FreeRTOS 2.0 Utilisez l'exécutable AWS IoT Device Tester for FreeRTOS pour interagir avec IDT pour FreeRTOS. Les exemples de ligne de commande ci-dessous vous montrent comment exécuter les tests de qualification d'un groupe d'appareils (ensemble d'appareils identiques). ------ #### [ IDT v4.5.2 and later ] ``` devicetester_[linux | mac | win] run-suite \ --suite-id suite-id \ --group-id group-id \ --pool-id your-device-pool \ --test-id test-id \ --userdata userdata.json ``` Exécute une suite de tests sur un groupe d'appareils. Le fichier `userdata.json` doit figurer dans le répertoire `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/`. **Note** Si vous utilisez IDT pour FreeRTOS sous Windows, utilisez des barres obliques (/) pour spécifier le chemin du fichier. `userdata.json` Utilisez la commande suivante pour exécuter un groupe de tests spécifique : ``` devicetester_[linux | mac | win] run-suite \ --suite-id FRQ_1.99.0 \ --group-id group-id \ --pool-id pool-id \ --userdata userdata.json ``` Les paramètres `suite-id` et `pool-id` sont facultatifs si vous exécutez une seule suite de tests au niveau d'un seul groupe d'appareils (à savoir, si un seul groupe d'appareils est défini dans votre fichier `device.json`). Utilisez la commande suivante pour exécuter un cas de test spécifique dans un groupe de tests : ``` devicetester_[linux | mac | win_x86-64] run-suite \ --group-id group-id \ --test-id test-id ``` Vous pouvez utiliser la commande `list-test-cases` pour répertorier les cas de test dans un groupe de tests. **Options de ligne de commande IDT pour FreeRTOS** **group-id** (Facultatif) Groupes de tests à exécuter, sous la forme d'une liste séparée par des virgules. Si cette option n'est pas spécifiée, IDT exécute tous les groupes de tests de la suite de tests. **pool-id** (Facultatif) Le groupe d'appareils à tester. Option requise si vous définissez plusieurs groupes d'appareils dans `device.json`. Si vous avez un seul groupe d'appareils, vous pouvez omettre cette option. **suite-id** (Facultatif) Version de la suite de tests à exécuter. Si cette option n'est pas spécifiée, IDT utilise la dernière version dans le répertoire tests de votre système. **test-id** (Facultatif) Tests à exécuter, sous la forme d'une liste séparée par des virgules. Si cette option est spécifiée, `group-id` doit spécifier un groupe unique. **Example** ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion ``` **h** Utilisez l'option d'aide pour en savoir plus sur les options `run-suite`. **Example** **Exemple** ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ ## IDT pour les commandes FreeRTOS La commande IDT pour FreeRTOS prend en charge les opérations suivantes : ------ #### [ IDT v4.5.2 and later ] ** `help` ** Répertorie les informations sur la commande spécifiée. ** `list-groups` ** Répertorie les groupes dans une suite donnée. ** `list-suites` ** Répertorie les suites disponibles. ** `list-supported-products` ** Répertorie les produits et les versions de suite de tests pris en charge. ** `list-supported-versions` ** Répertorie les versions de FreeRTOS et de suites de tests prises en charge par la version actuelle d'IDT. ** `list-test-cases` ** Répertorie les cas de test dans un groupe spécifié. ** `run-suite` ** Exécute une suite de tests sur un groupe d'appareils. Utilisez l'option `--suite-id` pour spécifier une version de suite de tests ou omettez-la pour utiliser la dernière version sur votre système. Utilisez l'option `--test-id` pour exécuter un cas de test individuel. **Example** ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion ``` Depuis IDT v3.0.0, IDT recherche en ligne des suites de tests plus récentes. Pour de plus amples informations, veuillez consulter [Versions de la suite de tests](idt-test-suite-versions.md). ------ # Consultez l'IDT gratuitement RTOSresults Lorsqu'il s'exécute, IDT écrit les erreurs sur la console, les fichiers journaux et les rapports de tests. Après avoir terminé la gamme de test de qualification, IDT écrit un résumé de la série de tests dans la console et génère deux rapports d'essais. Ces rapports se trouvent à l'emplacement `devicetester-extract-location/results/execution-id/`. Les deux rapports capturent les résultats de l'exécution de la suite de tests de qualification. `awsiotdevicetester_report.xml`Il s'agit du rapport de test de qualification que vous soumettez AWS pour inscrire votre appareil dans le catalogue des appareils AWS partenaires. Ce rapport contient les éléments suivants : + La version IDT pour FreeRTOS. + La version de FreeRTOS qui a été testée. + Les fonctionnalités de FreeRTOS prises en charge par l'appareil sont basées sur les tests réussis. + La référente et le nom de l'appareil spécifiés dans le fichier `device.json`. + Les caractéristiques de l'appareil spécifiées dans le fichier `device.json`. + Un récapitulatif des résultats des scénarios de test. + Une répartition des résultats des cas d'utilisation par bibliothèques qui ont été testés en fonction des fonctionnalités de l'appareil. `FRQ_Report.xml`Il s'agit d'un rapport au [format JUnit XML](https://llg.cubic.org/docs/junit/) standard. Vous pouvez l'intégrer à CI/CD des plateformes telles que [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo), etc. Ce rapport contient les éléments suivants : + Un récapitulatif des résultats des scénarios de test. + Une répartition des résultats des cas d'utilisation par bibliothèques qui ont été testés en fonction des fonctionnalités de l'appareil. # Interpréter l'IDT pour les résultats FreeRTOS La section Rapport dans `awsiotdevicetester_report.xml` ou `FRQ_Report.xml` répertorie les résultats des tests exécutés. La première balise XML `` contient le résumé global de l'exécution des tests. Par exemple : `` **Attributs utilisés dans la `` balise** ** `name` ** Nom de la suite de tests. ** `time` ** Durée, en secondes, nécessaire pour exécuter la suite de qualification. ** `tests` ** Nombre de scénarios de test exécutés. ** `failures` ** Nombre de scénarios de tests qui ont été exécutés, mais dont le résultat n'est pas probant. ** `errors` ** Le nombre de cas de test que IDT pour FreeRTOS n'a pas pu exécuter. ** `disabled` ** Cet attribut n'est pas utilisé et peut être ignoré. S'il n'y a aucun échec ou erreur dans le scénario de test, votre appareil répond aux exigences techniques pour exécuter FreeRTOS et peut interagir avec les services. AWS IoT Si vous choisissez de répertorier votre appareil dans le catalogue des appareils AWS partenaires, vous pouvez utiliser ce rapport comme preuve de qualification. En cas d'erreurs ou d'échec de scénarios de test, vous pouvez identifier les scénarios concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` indiquent le récapitulatif des résultats d'un groupe de tests. `` Le format est similaire à la balise ``, mais avec un attribut supplémentaire appelé `skipped` qui n'est pas utilisé et qui ne peut pas être ignoré. Chaque balise XML ``inclut des balises `` pour chaque scénario de test qui a été exécuté pour un groupe de tests. Par exemple : `` **Attributs utilisés dans la `` balise** ** `name` ** Nom du produit testé. ** `version` ** Version du produit testé. ** `features` ** Caractéristiques validées. Les caractéristiques portant la mention `required` sont requises pour pouvoir envoyer votre carte en vue de sa certification. L'extrait suivant montre comment cela apparaît dans le `awsiotdevicetester_report.xml` fichier. ``` ``` Les fonctionnalités marquées comme `optional` ne sont pas requises pour l'éligibilité. Les extraits suivants illustrent des fonctions facultatives. ``` ``` S'il n'y a aucun échec ou erreur de test pour les fonctionnalités requises, votre appareil répond aux exigences techniques pour exécuter FreeRTOS et peut interagir avec les services. AWS IoT Si vous souhaitez répertorier votre appareil dans le [catalogue des appareils AWS partenaires](https://partners.amazonaws.com/qualified-devices), vous pouvez utiliser ce rapport comme preuve de qualification. En cas d'erreurs ou d'échecs de tests, vous pouvez identifier les tests concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` montrent le récapitulatif des résultats d'un groupe de tests. Par exemple : ``` ``` Le format est similaire à celui de la `` balise, mais possède un `skipped` attribut qui n'est pas utilisé et qui peut être ignoré. Chaque balise XML `` inclut des balises `` pour chaque test exécuté pour un groupe de tests. Par exemple : ``` ``` **Attributs utilisés dans la `` balise** ** `name` ** Nom du scénario de test. ** `attempts` ** Le nombre de fois où IDT pour FreeRTOS a exécuté le scénario de test. Lorsqu'un test échoue ou qu'une erreur se produit, les balises `` ou `` sont ajoutées à la balise `` avec des informations relatives au dépannage. Par exemple : ``` Reason for the test case failure Reason for the test case execution error ``` Pour de plus amples informations, veuillez consulter [Résolution des erreurs](dt-afr-troubleshooting.md). # Consultez l'IDT gratuitement RTOSlogs Vous pouvez trouver les journaux générés par IDT pour FreeRTOS à partir de l'exécution des tests dans. `devicetester-extract-location/results/execution-id/logs` Deux ensembles de journaux sont générés : + `test_manager.log` Contient les journaux générés par IDT pour FreeRTOS (par exemple, la configuration associée aux journaux et la génération de rapports). + `test_group_id/test_case_id/test_case_id.log` Fichier journal d'un cas de test, y compris la sortie de l'appareil en cours de test. Le fichier journal est nommé en fonction du groupe de test et du cas de test qui a été exécuté.