Erstellen Sie IDT kostenlos einen Gerätepool RTOS - Kostenlos RTOS

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Erstellen Sie IDT kostenlos einen Gerätepool RTOS

Zu testende Geräte werden in Gerätepools organisiert. Jeder Gerätepool besteht aus einem oder mehreren identischen Geräten. Sie können IDT kostenlos konfigurierenRTOS, um ein einzelnes Gerät oder mehrere Geräte in einem Pool zu testen. Um den Qualifizierungsprozess zu beschleunigen, RTOS kann IDT For Free Geräte mit denselben Spezifikationen parallel testen. Er verwendet eine Round Robin-Methode, um auf jedem Gerät in einem Gerätepool eine andere Testgruppe auszuführen.

Die device.json Datei hat ein Array auf der obersten Ebene. Jedes Array-Attribut ist ein neuer Gerätepool. Jeder Gerätepool hat ein Geräte-Array-Attribut, für das mehrere Geräte deklariert sind. In der Vorlage gibt es einen Gerätepool und nur ein Gerät in diesem Gerätepool. Sie können ein oder mehrere Geräte zu einem Gerätepool hinzufügen, indem Sie den Abschnitt devices der Vorlage device.json im Ordner configs bearbeiten.

Anmerkung

Alle Geräte im selben Pool müssen dieselbe technische Spezifikation haben undSKU. Um parallel Builds des Quellcodes für verschiedene Testgruppen zu ermöglichen, RTOS kopiert IDT For Free den Quellcode in einen Ergebnisordner innerhalb des RTOS extrahierten IDT For Free-Ordners. Sie müssen in Ihrem Build- oder Flash-Befehl mithilfe der testdata.sourcePath Variablen auf den Quellcodepfad verweisen. IDTfor Free RTOS ersetzt diese Variable durch einen temporären Pfad des kopierten Quellcodes. Weitere Informationen finden Sie unter IDTfür kostenlose RTOS Variablen.

Die folgende device.json Beispieldatei wurde verwendet, um einen Gerätepool mit mehreren Geräten zu erstellen.

[ { "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" } ] } ] } ]

Die folgenden Attribute werden in der Datei device.json verwendet:

id

Eine benutzerdefinierte alphanumerische ID, die einen Gerätepool eindeutig identifiziert. Geräte, die zu einem Pool gehören, müssen vom gleichen Typ sein. Bei der Ausführung einer Reihe von Tests werden Geräte im Pool verwendet, um den Workload zu parallelisieren.

sku

Ein alphanumerischer Wert, mit dem das getestete Board eindeutig identifiziert wird. Die SKU wird verwendet, um qualifizierte Foren zu verfolgen.

Anmerkung

Wenn Sie Ihr Board im Gerätekatalog für AWS Partner auflisten möchten, muss das, was SKU Sie hier angeben, dem entsprechenSKU, das Sie bei der Angebotserstellung verwendet haben.

features

Ein Array, das die vom Gerät unterstützten Funktionen enthält. AWS IoT Device Tester verwendet diese Informationen, um die durchzuführenden Qualifikationstests auszuwählen.

Unterstützte Werte sind:

Wifi

Gibt an, ob Ihr Board über WiFi-Funktionen verfügt.

Cellular

Zeigt an, ob Ihr Motherboard über Mobilfunkfunktionen verfügt.

PKCS11

Gibt den Kryptographie-Algorithmus für öffentliche Schlüssel an, der vom Board unterstützt wird. PKCS11ist für die Qualifikation erforderlich. Unterstützte Werte sind ECCRSA, undBoth. Bothgibt an, dass das Board ECC sowohl als auch unterstütztRSA.

KeyProvisioning

Gibt an, wie ein vertrauenswürdiges X.509-Clientzertifikat auf das Board geschrieben werden kann.

Gültige Werte sind ImportOnboard, Both undNo. Onboard,Both, oder die Bereitstellung von No Schlüsseln ist für die Qualifizierung erforderlich. Importallein ist keine gültige Qualifizierungsoption.

  • Verwenden Sie diese Option Import nur, wenn Ihr Board den Import von privaten Schlüsseln zulässt. ImportDie Auswahl ist keine gültige Konfiguration für die Qualifizierung und sollte nur zu Testzwecken verwendet werden, insbesondere bei PKCS11 Testfällen. Onboard, Both oder No ist für die Qualifizierung erforderlich.

  • Verwenden Sie diese Option, Onboard wenn Ihr Board integrierte private Schlüssel unterstützt (z. B. wenn Ihr Gerät über ein sicheres Element verfügt oder wenn Sie es vorziehen, Ihr eigenes Geräteschlüsselpaar und Ihr eigenes Zertifikat zu generieren). Stellen Sie sicher, dass Sie in jedem der Geräteabschnitte ein secureElementConfig-Element hinzufügen und fügen Sie den absoluten Pfad zur Datei des öffentlichen Schlüssels in das Feld publicKeyAsciiHexFilePath ein.

  • Verwenden Sie diese Both Option, wenn Ihr Board sowohl den Import von privaten Schlüsseln als auch die integrierte Schlüsselgenerierung für die Schlüsselbereitstellung unterstützt.

  • Verwenden Sie diese No Option, wenn Ihr Board die Schlüsselbereitstellung nicht unterstützt. Noist nur dann eine gültige Option, wenn Ihr Gerät ebenfalls vorab bereitgestellt wurde.

OTA

Zeigt an, ob Ihr Board die over-the-air Aktualisierungsfunktion (OTA) unterstützt. Das OtaDataPlaneProtocol Attribut gibt an, welches OTA Datenebenenprotokoll das Gerät unterstützt. OTAFür die Qualifizierung ist HTTP entweder ein MQTT Datenebenenprotokoll erforderlich. Um die Ausführung von OTA Tests während des Tests zu überspringen, setzen Sie die OTA Funktion auf No und das OtaDataPlaneProtocol Attribut auf. None Dies wird kein Qualifikationslauf sein.

BLE

Zeigt an, ob Ihr Motherboard Bluetooth Low Energy (BLE) unterstützt.

devices.id

Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.

devices.connectivity.serialPort

Der serielle Port des Host-Computers, der zur Herstellung einer Verbindung mit den getesteten Geräten verwendet wird.

devices.secureElementConfig.PublicKeyAsciiHexFilePath

Erforderlich, ob Ihr Board im NOT pre-provisioned Lieferumfang PublicDeviceCertificateArn enthalten ist oder nicht. Da Onboard es sich um eine erforderliche Art der Schlüsselbereitstellung handelt, ist dieses Feld derzeit für die FullTransportInterface TLS Testgruppe erforderlich. Falls es sich bei Ihrem Gerät um ein pre-provisioned solches handelt, PublicKeyAsciiHexFilePath ist dies optional und muss nicht im Lieferumfang enthalten sein.

Der folgende Block ist ein absoluter Pfad zu der Datei, die den öffentlichen Hex-Byte-Schlüssel enthält, der aus dem Onboard privaten Schlüssel extrahiert wurde.

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

Wenn Ihr öffentlicher Schlüssel im.der-Format vorliegt, können Sie den öffentlichen Schlüssel direkt hexcodieren, um die Hex-Datei zu generieren.

Um die Hex-Datei aus einem öffentlichen .der-Schlüssel zu generieren, geben Sie den folgenden Befehl ein: xxd

xxd -p pubkey.der > outFile

Wenn Ihr öffentlicher Schlüssel im.pem-Format vorliegt, können Sie die Base64-codierten Kopf- und Fußzeilen extrahieren und in das Binärformat dekodieren. Anschließend kodieren Sie die binäre Zeichenfolge hexadezimal, um die Hex-Datei zu generieren.

Gehen Sie wie folgt vor, um eine Hex-Datei für einen öffentlichen PEM-Schlüssel zu generieren:

  1. Führen Sie den folgenden base64 Befehl aus, um die Base64-Kopf- und Fußzeile aus dem öffentlichen Schlüssel zu entfernen. Der dekodierte Schlüssel mit dem Namen wird base64key dann in die Datei ausgegeben: pubkey.der

    base64 —decode base64key > pubkey.der
  2. Führen Sie den folgenden xxd Befehl aus, um in das Hex-Format pubkey.der zu konvertieren. Der resultierende Schlüssel wird gespeichert als outFile

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

Das ARN Zertifikat Ihres sicheren Elements, in das hochgeladen wurde AWS IoT Core. Informationen zum Hochladen Ihres Zertifikats auf AWS IoT Core finden Sie unter X.509-Client-Zertifikate im AWS IoT Developer Guide.

devices.secureElementConfig.SecureElementSerialNumber

(Optional) Die Seriennummer des sicheren Elements. Die Seriennummer wird optional verwendet, um Gerätezertifikate für die JITR Schlüsselbereitstellung zu erstellen.

devices.secureElementConfig.preProvisioned

(Optional) Auf „Ja“ setzen, wenn das Gerät über ein vorab bereitgestelltes sicheres Element mit gesperrten Anmeldeinformationen verfügt, das keine Objekte importieren, erstellen oder zerstören kann. Wenn dieses Attribut auf Ja gesetzt ist, müssen Sie die entsprechenden pkcs11-Labels angeben.

devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport

(Optional) Legen Sie den Wert auf Ja fest, wenn die PKCS11 Core-Implementierung des Geräts Speicher für unterstützt. JITP Dadurch wird der JITP codeverify Test beim Testen von Core PKCS 11 aktiviert und es müssen die Labels für den Code-Verifizierungsschlüssel, JITP das Zertifikat und das Stammzertifikat PKCS 11 bereitgestellt werden.

identifiers

(Optional) Ein Array beliebiger Namen-Wert-Paare. Sie können diese Werte in den im nächsten Abschnitt beschriebenen Build- und Flash-Befehlen verwenden.