Aufgaben in der Fabrikhalle

  • Artikel

Die Herstellung verbundener Geräte, die Azure Sphere-Hardware enthalten, umfasst die folgenden Factory-Floor-Aufgaben, um Geräte für den Versand vorzubereiten:

  • Verbinden der einzelnen Azure Sphere-Chips mit einem PC im Werk
  • Abrufen von Gerätedetails und Aufzeichnen dieser Details zur späteren Verwendung
  • Aktualisieren des Azure Sphere-Betriebssystems bei Bedarf
  • Aktualisieren Sie den vertrauenswürdigen Keystore, falls erforderlich.
  • Laden von Software auf das Gerät
  • Ausführen von Funktionstests zur Überprüfung der korrekten Funktionsweise des Produkts
  • Durchführen von Hochfrequenztests und -kalibrierungen
  • Überprüfen der Wi-Fi Kommunikation
  • Konfigurieren des Geräts für Ethernet
  • Abschließen des Azure Sphere-Geräts für den Versand

Sie müssen zuerst den Chip mit dem PC verbinden, die Gerätedetails abrufen und das Gerät zuletzt fertig stellen. Sie können die anderen Aufgaben jedoch in einer beliebigen Reihenfolge ausführen, die zu Ihrer Produktionsumgebung passt.

Wichtig

Sie sollten einige Vorbereitungen durchführen, um sicherzustellen, dass Ihre Werksaufgaben ohne Verzögerungen abgeschlossen werden können. Die Vorbereitung umfasst die Einrichtung des PC in der Fabrik und alle anderen erforderlichen Geräte und die Installation der erforderlichen PC-Softwaretools. Alle Aufgaben, die Sie ausführen sollten, um sich auf einen reibungslosen Herstellungsprozess vorzubereiten, werden unter Vorbereitung des Herstellungsprozesses beschrieben.

Verbinden der einzelnen Azure Sphere-Chips mit einem PC im Werksbereich

Während der Fertigung müssen Sie jeden Azure Sphere-Chip mit einem PC in der Fabrik verbinden. Wenn Sie mehrere Azure Sphere-Geräte gleichzeitig mit einem einzelnen PC verbinden möchten, finden Sie weitere Informationen unter Ausrüstung für Werksaufgaben in den Fertigungsvorbereitungsaufgaben.

Die meisten Werksaufgaben umfassen den Befehl az sphere device . Wenn sie mehrere Geräte an den PC angeschlossen haben, müssen Sie das Gerät angeben, auf das der Befehl az sphere device angewendet werden soll, indem Sie den Parameter angeben, der --device entweder auf die IP-Adresse des Geräts oder den Verbindungspfad des Geräts festgelegt ist. Der Befehl schlägt fehl, wenn der --device Parameter ausgelassen wird und mehrere Geräte angefügt sind. Informationen zum Abrufen der IP-Adresse oder des Verbindungspfads finden Sie unter Abrufen von Gerätedetails.

Wichtig

Das Azure Sphere SDK unterstützt die Kommunikation mit mehreren angeschlossenen Geräten nur mit Windows. Wenn Sie Linux verwenden, wird nur die Kommunikation mit einem einzelnen angeschlossenen Gerät unterstützt. Sie können jedoch mehrere virtuelle Linux-Computer (VMs) verwenden, die jeweils mit einem einzelnen USB-Port zugeordnet sind, um einen einzelnen PC mit mehreren Linux-Instanzen zu haben, die mit mehreren Azure Sphere-Geräten gleichzeitig kommunizieren.

Abrufen von Gerätedetails

Sie müssen die Geräte-ID jedes Azure Sphere-Chips aufzeichnen, den Ihr Unternehmen in hergestellte Produkte integriert. Sie benötigen die Geräte-ID für Cloudkonfigurationsaufgaben.

Wenn Sie mehrere Geräte an den PC in der Werkshalle angeschlossen haben, müssen Sie auch die IP-Adresse oder den Verbindungspfad der angeschlossenen Geräte zur späteren Verwendung bei Aufgaben im Werksbereich aufzeichnen. Wie unter Verbinden mit jedem Azure Sphere-Chip erläutert, ist die IP-Adresse oder der Verbindungspfad erforderlich, um das Zielgerät anzugeben, wenn mehrere angeschlossene Geräte vorhanden sind.

Verwenden Sie den Befehl az sphere device list-attached , um die Geräte-ID, die IP-Adresse und den Verbindungspfad der angeschlossenen Geräte abzurufen. Die folgenden Beschreibungen enthalten wichtige Details zu Geräte-ID, IP-Adresse und Verbindungspfad.

  • Geräte-ID: Der Hersteller von Silizium erstellt die Geräte-ID, speichert sie auf dem Chip und registriert sie bei Microsoft. Diese Geräteregistrierung stellt sicher, dass Microsoft alle Azure Sphere-Chips kennt und dass nur legitime Chips in verbundenen Geräten verwendet werden können.

  • IP-Adresse – Die IP-Adresse wird zugewiesen, wenn eine FTDI-basierte Geräteschnittstelle an den PC angeschlossen ist; Es gibt nicht an, dass ein reaktionsfähiges Gerät vorhanden ist. Die IP-Adresse bleibt erhalten, während die FTDI-basierte Geräteschnittstelle an den PC angeschlossen ist, auch wenn ein anderes Azure Sphere-Gerät an die Schnittstelle angeschlossen ist. Nach einem PC-Neustart kann sich die IP-Adresse jedoch ändern. Der ersten anzubringenden FTDI-basierten Geräteschnittstelle wird die Adresse 192.168.35.2 zugewiesen. Jedem Gerät wird eine IP-Adresse zugewiesen , auch wenn es nicht reagiert, sodass Sie die IP-Adresse verwenden können, um ein Gerät zu identifizieren, für das eine Wiederherstellung erforderlich ist.

  • Verbindungspfad – Der Verbindungspfad ist eine FTDI-Standort-ID , die die USB-Verbindung identifiziert. Die Standort-ID bleibt erhalten, während die FTDI-basierte Geräteschnittstelle an denselben USB-Anschluss auf demselben USB-Hub und wiederum an denselben Port auf dem PC angeschlossen ist. Daher wird sie bei einem Neustart beibehalten. Änderungen bei der Verdrahtung zwischen dem PC und dem Gerät können jedoch zu Änderungen am Verbindungspfad führen. Wie die IP-Adresse ändert sie sich auch dann nicht, wenn ein anderes Azure Sphere-Gerät an die FTDI-Schnittstelle angeschlossen ist.

Aktualisieren des Azure Sphere-Betriebssystems

Jeder Azure Sphere-Chip wird mit dem Azure Sphere-Betriebssystem geladen, wenn er vom Siliziumhersteller ausgeliefert wird. Abhängig von der Version des Azure Sphere-Betriebssystems auf Chips, die von Ihrem Lieferanten verfügbar sind, und abhängig von den Anforderungen der Betriebssystemversion Ihrer Anwendung müssen Sie das Azure Sphere-Betriebssystem möglicherweise während der Herstellung des verbundenen Geräts aktualisieren. Sie können das Betriebssystem aktualisieren, indem Sie bestimmte Wiederherstellungsimages installieren, die bereits auf Ihrem PC vorhanden sein sollten. Weitere Informationen finden Sie unter Vorbereiten auf ein Update des Betriebssystems in den Fertigungsvorbereitungsaufgaben. Die Fertigungsbeispiele enthalten ein Beispielskript, das eine parallele Wiederherstellung mit mehreren Geräten durchführt.

Sie können das Betriebssystem auf dem Azure Sphere-Gerät aktualisieren, indem Sie den Befehl az sphere device recover ausgeben. Verwenden Sie den --images -Parameter, um bestimmte Wiederherstellungsimages zu installieren:

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

Hinweis

Wenn mehrere Geräte mit dem PC verbunden sind, schließen Sie den --device Parameter ein, um das Zielgerät anhand der IP-Adresse oder des Verbindungspfads zu identifizieren. Weitere Informationen finden Sie unter Verbinden der einzelnen Azure Sphere-Chips mit einem PC in der Fabrik .

Aktualisieren des vertrauenswürdigen Keystores

Als Voraussetzung zum Laden von Software auf Ihr Gerät müssen Sie möglicherweise den vertrauenswürdigen Keystore auf dem Gerät aktualisieren. Dies ist nur erforderlich, wenn das Betriebssystem auf dem Gerät älter als Ihre Software ist, und nur, wenn der von AS3 verwendete Azure Sphere-Imagesignaturschlüssel zwischen dem veröffentlichten Betriebssystem und der Produktionssignatur Ihrer Software aktualisiert wurde. Um diesen Schritt zu vermeiden und die Fertigungszeit zu verkürzen, sollten Sie die Betriebssystemversion aktualisieren, die Sie während der Herstellung verwenden.

Sie können leicht feststellen, ob das Aktualisieren des vertrauenswürdigen Keystores erforderlich ist, indem Sie versuchen, Ihre Software gemäß den Anweisungen im nächsten Abschnitt zu laden. Wenn das Laden erfolgreich ist, müssen Sie den vertrauenswürdigen Keystore nicht aktualisieren. Wenn beim Laden der Nachricht ein Fehler auftritt, der mit Internal device error: Image not trusted by device beginnt, ist ein veralteter vertrauenswürdiger Keystore die Ursache.

Zum Aktualisieren des vertrauenswürdigen Keystores müssen Sie die aktuelle vertrauenswürdige Keystore-Datei abgerufen haben. Verwenden Sie dann als Teil Ihrer Fertigungsskripts den Befehl az sphere device sideload deploy , um den aktualisierten vertrauenswürdigen Keystore vor dem Laden der Anwendungssoftware zu laden. Ersetzen Sie dabei <path-to-trusted-keystore.bin> durch den Pfad zu der vertrauenswürdigen Keystore-Datei:

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

Laden der Gerätesoftware

Alle Software, die Sie laden – unabhängig davon, ob es sich um ein Boardkonfigurationsimage, eine Testanwendung oder eine Produktionsanwendung handelt – muss produktionssigniert sein. Wenn Sie eine temporäre Anwendung zu Testzwecken laden, müssen Sie sie nach Abschluss des Tests löschen.

Alle von der Produktion signierten Bilder, die Sie während des Prozesses in der Fabrik benötigen, sollten vor Beginn des Prozesses auf Ihrem PC in der Fabrik gespeichert werden, wie unter Abrufen von produktionssignierten Bildern in den Fertigungsvorbereitungsaufgaben beschrieben.

PC-Schnittstelle mit Tools

Während der Fertigung dürfen Azure Sphere-Geräte keine speziellen Gerätefunktionen erfordern, z. B. die App-Entwicklungsfunktion, die das Debuggen ermöglicht. Der Erwerb von Funktionen für einzelne Geräte verringert die Gerätesicherheit und erfordert Eine Internetverbindung, was in der Regel in der Fabrik unerwünscht ist.

Um Software auf ein Gerät im Werk zu laden oder temporäre Software von einem Gerät zu löschen, nachdem die Tests abgeschlossen sind, verwenden Sie den Befehl az sphere device sideload wie folgt:

  • Verwenden Sie az sphere device sideload deploy , um ein Image zu laden, und <file-path> ersetzen Sie dabei durch den Namen und Pfad zu Ihrer produktionssignierten Imagedatei:

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

  • Verwenden Sie az sphere device sideload delete , um ein temporäres Image zu löschen, und <component-id> ersetzen Sie dabei durch die Komponenten-ID des zu löschenden Images:

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

Hinweis

Wenn mehrere Geräte mit dem PC verbunden sind, schließen Sie den --device Parameter ein, um das Zielgerät anhand der IP-Adresse oder des Verbindungspfads zu identifizieren. Weitere Informationen finden Sie unter Verbinden der einzelnen Azure Sphere-Chips mit einem PC in der Fabrik .

Ausführen von Funktionstests

Funktionstests sind erforderlich, um zu überprüfen, ob das Produkt ordnungsgemäß funktioniert. Führen Sie die Anwendungen aus, die Sie für Funktionstests im Rahmen der Fertigungsvorbereitungsaufgaben entwickelt haben. Weitere Informationen finden Sie unter Entwickeln von Anwendungen für Funktionstests.

Wenn Ihre Funktionstests eine Kommunikation mit dem getesteten Chip erfordern, verbinden Sie die MT3620-Peripherie-UARTs (ISU0, ISU1, ISU2 oder ISU3) über geeignete Schaltungen Ihres eigenen Designs mit Ihrem Pc in der Fabrik oder externen Testgeräten.

Funktionstestflow

Durchführen von Hochfrequenztests und -kalibrierungen

Azure Sphere-Chips können Wi-Fi verwenden, um Softwareupdates zu empfangen und mit dem Internet zu kommunizieren. Wenn Ihr Produkt Wi-Fi verwendet und entweder ein Chipdown-Design oder ein Modul enthält, das nicht RF-zertifiziert ist, müssen Sie für jedes Gerät RF-Tests und -Kalibrierungen durchführen. Die für diese Aufgabe erforderlichen Geräte und Werkzeuge werden unter Ausrüstung und Software für HF-Tests und -Kalibrierungen in den Fertigungsvorbereitungsaufgaben beschrieben.

Das Rf Tools-Paket enthält Hilfsprogramme und eine C-API-Bibliothek für die Verwendung während des Tests. Sie können die C-API-Bibliothek verwenden, um produktspezifische RF-Einstellungen in E-Sicherungen zu programmieren. E-Sicherungen werden beispielsweise so programmiert, dass sie Antenne und Frequenz konfigurieren, Geräte für eine optimale Leistung optimieren und Wi-Fi Kanäle aktivieren. Im Thema HF-Testtools wird die Verwendung der HF-Tools beschrieben.

Programm-E-Fuses zum Aktivieren von Wi-Fi Kanälen

Das Azure Sphere-Betriebssystem wählt Wi-Fi Kanäle basierend auf dem Regionscode aus, der in den MT3620-E-Fuses an Offsetadressen 0x36 und 0x37 programmiert ist. Ausführliche Informationen zu E-Sicherungen auf dem MT3620 finden Sie im Dokument MT3620 E-fuse Content Guidelines Mediatek.

Der Regionscode ist ein aus zwei Buchstaben bestehender ASCII-Code. Das Azure Sphere-Betriebssystem verwendet die Regionscodeeinstellung in den E-Sicherungen, um die Region in der Linux-Datenbank für drahtlose Regulierungen nachzuschlagen, und wählt dann die für diese Region zulässigen Kanäle aus. Wenn kein Regionscode in die E-Sicherungen programmiert ist, in diesem Fall die E-Sicherungen auf 0x00 0x00 festgelegt bleiben, oder wenn die Zeichen "00" programmiert sind, verwendet das Betriebssystem standardmäßig einen konservativen Satz von Kanälen, die in allen Regionen im Allgemeinen zulässig sind. Die für die Region "00" zulässigen Kanäle werden in der Linux-Datenbank für drahtlose Regulierungen angegeben.

Die Regionscodeeinstellung in den E-Sicherungen muss nicht mit dem Land übereinstimmen, in dem das Gerät verwendet wird. Hersteller können einen beliebigen Regionscode auswählen, der einem zulässigen Satz von Kanälen für den Betriebsbereich zugeordnet ist. Verschiedene Regionen und Länder erlassen häufig ähnliche oder identische Vorschriften, die es ermöglichen können, regionsspezifische Codes austauschbar zu verwenden.

Beispiel: Um das Azure Sphere-Betriebssystem anzuweisen, Wi-Fi Kanäle für die Region "DE" (Deutschland) auszuwählen, 0x44=D und 0x45=E in die E-Fuses unter Adressen 0x36 und 0x37 ein. Die zulässigen Kanäle für Deutschland, die aus der Linux-Drahtlosen Regulierungsdatenbank stammen, sind unten dargestellt. Die meisten Länder in der Europäischen Union (EU) lassen dieselben Kanäle zu.

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)

Überprüfen der RF-Konfiguration

Verwenden Sie das RfSettingsTool, um zu überprüfen, ob die Funkkonfigurationsoptionen wie Zielübertragungsleistung, Regionscode und Wi-Fi Media Access Control (MAC)-Adresse ordnungsgemäß festgelegt wurden. Weitere Informationen zur Verwendung dieses Tools finden Sie in der Dokumentation zum Rf-Einstellungstool .

Überprüfen Wi-Fi Kommunikation

Erwägen Sie, eine Verbindung mit einem Wi-Fi Zugriffspunkt herzustellen, um zu überprüfen, ob Ihre Produktanwendung über WLAN kommunizieren kann. Stellen Sie sicher, dass die Wi-Fi-Verbindung keinen Internetzugang hat, da ein Over-the-Air-Update auftreten kann, wenn der Chip eine Verbindung mit einem internetfähigen Zugriffspunkt herstellt.

Um ein Gerät mit einem Wi-Fi-Zugriffspunkt zu verbinden, befolgen Sie die Anweisungen auf der Registerkarte Schnellstart (CLI).To connect a device to a Wi-Fi access point, follow the instructions in the Quickstart (CLI tab). Wenn mehrere Geräte mit dem PC verbunden sind, müssen Sie den --device Parameter in den Befehl az sphere device wifi show-status und den Befehl az sphere device wifi add einschließen. Ausführliche Informationen zur Verwendung des Befehls az sphere device mit mehreren angeschlossenen Geräten finden Sie unter Verbinden der einzelnen Azure Sphere-Chips mit einem PC in der Fabrik.

Nach Wi-Fi Tests sollten Sie alle Wi-Fi Access Points, die zum Testen verwendet werden, vom Chip entfernen, damit diese für Kunden nicht sichtbar sind. Bei der Gerätewiederherstellung werden alle Wi-Fi Konfigurationsdaten vom Chip entfernt.

Konfigurieren des Geräts für Ethernet

Ein Azure Sphere-Gerät kann über Ethernet kommunizieren. Das Gerät erfordert einen externen Ethernet-Adapter und ein Boardkonfigurationsimage für die Kommunikation über Ethernet.

Um ein Azure Sphere-Gerät für Ethernet zu konfigurieren, verbinden Sie einen Ethernet-Adapter mit dem Azure Sphere-Gerät, wie unter Verbinden von Ethernet-Adaptern beschrieben.

Zwei Ethernet-Geräte werden vom Azure Sphere-Betriebssystem unterstützt.

  1. Mikrochip ENC28J60. Dies ist ein 10Base-T-Adapter (10 Mbps). Es kann mit einer LED-Anzeige bei Halbduplex-Geschwindigkeit oder ohne LED-Anzeige bei Vollduplex-Geschwindigkeit verkabelt werden. Seeed-Devkits sind für den Halbduplexbetrieb verkabelt.
  2. Wiznet W5500. Dies ist ein 100Base-TX-Adapter (100mpbs). Es unterstützt einen integrierten TCP/IP-Stapel und NIC-Passthrough-Modi, aber Azure Sphere unterstützt nur NIC-Passthrough, wenn W5500 für Internetkonnektivität verwendet wird. Aufgrund von Einschränkungen bei der Busbandbreite kann das MT3620-Gerät möglicherweise keine volle Geschwindigkeit von 100 MBit/s erreichen.

Die Ethernet-Schnittstelle wird automatisch aktiviert, sobald die Boardkonfiguration geladen wurde, wie unter Laden der Gerätesoftware beschrieben, und das Gerät wird neu gestartet. Alle Schnittstellen verwenden standardmäßig dynamische IP-Adressen.

Abschließen des Azure Sphere-Geräts

Durch den Abschluss wird sichergestellt, dass sich das Azure Sphere-Gerät in einem sicheren Zustand befindet und bereit für den Versand an Kunden ist. Sie müssen das Gerät fertig stellen, bevor Sie es versenden. Die Finalisierung umfasst Folgendes:

  • Ausführen von sofort einsatzbereiten Überprüfungen, um sicherzustellen, dass die richtige Systemsoftware und Produktionsanwendung installiert und RF-Tools deaktiviert sind.

  • Festlegen des Gerätefertigungszustands, um HF-Konfigurations- und Kalibrierungstools zu sperren und Sicherheitsverletzungen zu verhindern.

Ausführen von sofort einsatzbereiten Überprüfungen

Es ist wichtig, versandfertige Überprüfungen durchzuführen, bevor Sie ein Produkt versenden, das ein Azure Sphere-Gerät enthält. Für verschiedene Herstellungszustände müssen unterschiedliche Prüfungen durchgeführt werden. Versandfertige Überprüfungen stellen Folgendes sicher:

  • Der Fertigungsstatus des Geräts ist für diese Phase der Herstellung richtig festgelegt.
  • Das Azure Sphere-Betriebssystem auf dem Gerät ist gültig und die erwartete Version. Dies kann nur für Geräte überprüft werden, die sich noch nicht im DeviceComplete-Zustand befinden.
  • Vom Benutzer bereitgestellte Bilder auf dem Gerät entsprechen der Liste der erwarteten Bilder. Dies kann nur für Geräte überprüft werden, die sich noch nicht im DeviceComplete-Zustand befinden.
  • Auf dem Gerät werden keine unerwarteten Wi-Fi Netzwerke konfiguriert. Dies kann nur für Geräte überprüft werden, die sich noch nicht im DeviceComplete-Zustand befinden.
  • Das Gerät enthält keine speziellen Funktionszertifikate. Bei MT3620-basierten Geräten kann dies nur auf Geräten überprüft werden, die sich nicht im Leeren Zustand befinden.

In verschiedenen Fertigungsphasen sind unterschiedliche Überprüfungen erforderlich, da der Fertigungszustand des Geräts die Funktionen des Geräts bestimmt.

Welche Überprüfungen Sie ausführen, hängt auch davon ab, ob Sie ein Modul oder ein verbundenes Gerät entwerfen. Als Modulhersteller können Sie beispielsweise den Chip im Fertigungszustand Leer belassen, damit der Kunde des Moduls zusätzliche Funktests und -konfigurationen durchführen kann.

Verwenden von device_ready.py zum Durchführen von Überprüfungen

Das Paket "Fertigungsbeispiele " enthält ein Tool namens device_ready.py, das die oben genannten Überprüfungen entsprechend den einzelnen Fertigungszuständen durchführt. Sie sollte für jeden der für Ihr Gerät relevanten Fertigungszustände ausgeführt werden.

In der folgenden Tabelle sind die Parameter aufgeführt, die das skript device_ready.py verwendet:

Parameter Beschreibung
--expected_mfg_state Bestimmt, auf welchen Fertigungszustand überprüft werden soll, und steuert, welche Tests ausgeführt werden. Wenn dieser Parameter nicht angegeben ist, wird standardmäßig "DeviceComplete" verwendet. Wenn der Fertigungszustand des Geräts von diesem Wert abweicht, schlägt die Überprüfung fehl.
--images Gibt die Liste der Bild-IDs (GUIDs) an, die auf dem Gerät vorhanden sein müssen, damit die Überprüfung erfolgreich ist. Die Liste besteht aus den durch Leerzeichen getrennten Bild-GUIDs. Dieser Parameter wird standardmäßig auf die leere Liste festgelegt, wenn er nicht angegeben wird. Wenn die Liste der installierten Image-IDs auf dem Gerät von dieser Liste abweicht, schlägt die Überprüfung fehl. Durch die Überprüfung von Image-IDs (anstelle von Komponenten-IDs) stellt diese Überprüfung sicher, dass eine bestimmte Version einer Komponente vorhanden ist.
--os Gibt eine Liste der Versionen des Azure Sphere-Betriebssystems an. Dieser Parameter wird standardmäßig auf die leere Liste festgelegt, wenn er nicht angegeben wird. Wenn die auf dem Gerät vorhandene Betriebssystemversion nicht in dieser Liste enthalten ist, schlägt diese Überprüfung fehl.
--os_components_json_file Gibt den Pfad zu der JSON-Datei an, die die Betriebssystemkomponenten auflistet, die die einzelnen Versionen des Betriebssystems definieren. Für MT3620-basierte Geräte hat diese Datei den Namen mt3620an.json. Verwenden Sie das download_os_list.py Tool, um die neueste Version herunterzuladen.
--azsphere_path Gibt den Pfad zum Hilfsprogramm azsphere.exe an. Wenn nicht angegeben, wird für diesen Parameter standardmäßig der Standardinstallationsspeicherort für das Azure Sphere SDK unter Windows verwendet. Verwenden Sie diesen Parameter nur, wenn das Azure Sphere SDK nicht am Standardspeicherort installiert ist.
--help Zeigt die Befehlszeilenhilfe an.
--verbose Stellt zusätzliche Ausgabedetails bereit.

Das folgende Beispiel ist eine Beispielausführung des device_ready.py Tools mit den folgenden Argumenten:

  • --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

Festlegen des Herstellungszustands des Geräts

Sensible Fertigungsvorgänge wie das Versetzen des Funkgeräts in den Testmodus und das Festlegen Wi-Fi Konfiguration von E-Sicherungen sollten Endbenutzern von Geräten, die einen Azure Sphere-Chip enthalten, nicht zugänglich sein. Der Fertigungsstatus des Azure Sphere-Geräts schränkt den Zugriff auf diese vertraulichen Vorgänge ein.

Die drei Fertigungszustände sind wie folgt:

  • Leer. Der Status Leer schränkt die Herstellungsvorgänge auf einem Chip nicht ein. Chips im Leeren Zustand können in den RF-Testmodus wechseln und ihre e-Sicherungen können programmiert werden. Wenn Chips aus der Siliziumfabrik ausgeliefert werden, befinden sie sich im Fertigungszustand Leer .

  • Modul1Vervollständigen. Der Module1Complete-Fertigungszustand wurde entwickelt, um die Anpassungen zu begrenzen, die Benutzer an Funkkonfigurationseinstellungen vornehmen können, z. B. maximale Übertragungsleistungsstufen und zulässige Frequenzen. RF-Befehle können verwendet werden, bis Module1Complete festgelegt ist. Das Einschränken des Endbenutzerzugriffs auf diese Einstellungen ist möglicherweise erforderlich, um die gesetzlichen Richtlinien für Funkhardware zu erfüllen. Diese Einstellung betrifft in erster Linie Hersteller, die Funkbetriebsparameter testen und kalibrieren müssen.

    Microsoft empfiehlt, diesen Herstellungszustand festzulegen, nachdem die Funktests und -kalibrierung abgeschlossen sind. RF-Befehle können nach dem Festlegen nicht mehr verwendet werden. Der Zustand Module1Complete schützt das Gerät vor Änderungen, die den ordnungsgemäßen Betrieb des Funkgeräts und anderer drahtloser Geräte in der Nähe stören können.

  • DeviceComplete. Der DeviceComplete-Fertigungszustand ermöglicht es Herstellern fertiger Produkte, Geräte, die vor Ort bereitgestellt werden, vor Änderungen zu schützen. Sobald ein Gerät in den DeviceComplete-Zustand versetzt wurde, muss eine gerätespezifische Funktionsdatei verwendet werden, wenn Softwarelade- und Konfigurationsaufgaben ausgeführt werden. Mit der Fieldservicing-Funktion können Sie produktionssignierte Images querladen, aber nicht löschen. Die App-Entwicklungsfunktion ermöglicht sowohl das Querladen als auch das Löschen von Bildern.

    Legen Sie DeviceComplete nicht für nicht fertige Geräte oder Module (WLAN-Module, Entwicklungsboards usw.) fest, die als Teil eines größeren Systems verwendet werden können. Dieser Zustand schränkt Fertigungsaktivitäten wie Tests an Produktionslinien, Softwareinstallation und Konfiguration ein. Viele CLI-Befehle sind nach dem Festlegen von DeviceComplete nicht verfügbar, sodass bestimmte sofort einsatzbereite Überprüfungen ausgeführt werden müssen, bevor dieser Zustand festgelegt wird. Eingeschränkte Befehle können mithilfe einer Gerätefunktion wie der Fieldservicing-Funktion erneut aktiviert werden, aber nur für Geräte, die Sie beansprucht haben. Daher ist dies nicht für die Verwendung in einer Fabrikumgebung geeignet, da sie Cloudkonnektivität erfordert.

In der folgenden Tabelle sind die Gerätefunktionen zusammengefasst, die für jeden Fertigungsstatus vorhanden sind.

Fertigungszustand Gerätefunktionen
Leer enableRfTestMode, fieldServicing und solche, die entweder quergeladen oder mit einem Vorgang übergeben werden, wie unter Gerätefunktionen beschrieben.
Modul1Vervollständigen fieldServicing und solche, die entweder quergeladen oder mit einem Vorgang übergeben werden, wie unter Gerätefunktionen beschrieben.
DeviceComplete Nur solche, die entweder quergeladen oder mit einem Vorgang übergeben werden, wie unter Gerätefunktionen beschrieben.

Wenn die Fertigung abgeschlossen ist, verwenden Sie den Befehl az sphere device manufacturing-state update , um den DeviceComplete-Zustand festzulegen:

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

Hinweis

Wenn mehrere Geräte mit dem PC verbunden sind, schließen Sie den --device Parameter ein, um das Zielgerät anhand der IP-Adresse oder des Verbindungspfads zu identifizieren. Weitere Informationen finden Sie unter Verbinden der einzelnen Azure Sphere-Chips mit einem PC in der Fabrik .

Wichtig

Das Verschieben eines Chips in den DeviceComplete-Zustand ist ein permanenter Vorgang und kann nicht rückgängig werden. Sobald sich ein Chip im DeviceComplete-Zustand befindet, kann er nicht in den RF-Testmodus wechseln. die Einstellungen der E-Sicherung können nicht angepasst werden; und Wi-Fi Einstellungen, Betriebssystemupdates und installierten Anwendungen können nicht geändert werden, ohne das Gerät in Anspruch zu nehmen und eine Gerätefunktion zu verwenden. Wenn Sie Funktionen auf einem einzelnen Chip, deren Gerätefunktionen nicht erneut aktiviert werden, wie z. B. in einem Fehleranalyseszenario, erneut aktivieren müssen, wenden Sie sich an Microsoft.