Zadania na hali produkcyjnej

Produkcja połączonych urządzeń, które zawierają sprzęt Azure Sphere, obejmuje następujące zadania na hali produkcyjnej, aby przygotować urządzenia do wysyłki:

• Łączenie każdego mikroukładu Azure Sphere z komputerem w fabryce
• Uzyskiwanie szczegółów urządzenia i nagrywanie ich do późniejszego użycia
• Aktualizowanie systemu operacyjnego Azure Sphere w razie potrzeby
• Zaktualizuj zaufany klucztor, jeśli to konieczne
• Ładowanie oprogramowania na urządzenie
• Uruchamianie testów funkcjonalnych w celu zweryfikowania prawidłowego działania produktu
• Przeprowadzanie testów i kalibracji fal radiowych
• Weryfikowanie Wi-Fi komunikacji
• Konfigurowanie urządzenia pod kątem sieci Ethernet
• Finalizowanie urządzenia Azure Sphere na potrzeby wysyłki

Najpierw musisz podłączyć mikroukład do komputera, uzyskać szczegóły urządzenia na drugim miejscu i sfinalizować urządzenie jako ostatnie, ale możesz wykonać inne zadania w dowolnej kolejności, która pasuje do Twojego środowiska produkcyjnego.

Ważne

Należy wykonać pewne przygotowania, aby upewnić się, że zadania na hali produkcyjnej mogą być wykonywane bez opóźnień. Przygotowanie obejmuje skonfigurowanie komputera na hali produkcyjnej i dowolnego innego niezbędnego sprzętu oraz zainstalowanie niezbędnych narzędzi oprogramowania komputerowego. Wszystkie zadania, które należy wykonać, aby przygotować się do sprawnego procesu produkcyjnego, opisano w temacie Przygotowanie procesu produkcji.

Łączenie każdego mikroukładu Azure Sphere z komputerem w fabryce

Podczas produkcji musisz połączyć każdy mikroukład Azure Sphere z komputerem w fabryce. Jeśli chcesz jednocześnie połączyć wiele urządzeń Azure Sphere z jednym komputerem, zobacz Sprzęt do zadań na hali produkcyjnej w zadaniach związanych z przygotowaniem produkcji.

Większość zadań na hali produkcyjnej obejmuje polecenie urządzenia azsphere . Jeśli masz wiele urządzeń podłączonych do komputera, musisz określić urządzenie, na którym ma zostać zastosowane polecenie urządzenia az sphere , uwzględniając --device parametr ustawiony na adres IP urządzenia lub ścieżkę połączenia urządzenia. Polecenie zakończy się niepowodzeniem, --device jeśli parametr zostanie pominięty i zostanie dołączonych wiele urządzeń. Aby uzyskać adres IP lub ścieżkę połączenia, zobacz Uzyskiwanie szczegółów urządzenia.

Ważne

Klawiatura SDK Azure Sphere obsługuje komunikację z wieloma dołączonymi urządzeniami tylko z systemem Windows. Jeśli używasz systemu Linux, komunikacja tylko z jednym dołączonym urządzeniem jest obsługiwana. Można jednak używać wielu maszyn wirtualnych systemu Linux, z których każda ma zamapowany jeden port USB, aby mieć jeden komputer z wieloma wystąpieniami systemu Linux, które komunikują się z wieloma urządzeniami Azure Sphere jednocześnie.

Uzyskaj szczegółowe informacje o urządzeniu

Musisz zarejestrować identyfikator urządzenia każdego mikroukładu Azure Sphere, który Twoja firma włączyła do produktów produkowanych. Identyfikator urządzenia będzie potrzebny do wykonywania zadań konfiguracji w chmurze.

Jeśli masz wiele urządzeń podłączonych do komputera w fabryce, musisz również zarejestrować adres IP lub ścieżkę połączenia podłączonych urządzeń do późniejszego użycia w zadaniach fabrycznych. Jak wyjaśniono w temacie Łączenie każdego mikroukładu Azure Sphere, adres IP lub ścieżka połączenia są wymagane do określenia urządzenia docelowego, gdy jest wiele podłączonych urządzeń.

Aby uzyskać identyfikator urządzenia, adres IP i ścieżkę połączenia dołączonych urządzeń, użyj polecenia dołączonego do listy urządzeń az sphere . Poniższe opisy zawierają istotne szczegóły dotyczące identyfikatora urządzenia, adresu IP i ścieżki połączenia.

• Identyfikator urządzenia — producent układu krzemowego tworzy identyfikator urządzenia, zapisuje go w mikroukładach i rejestruje w firmie Microsoft. Ta rejestracja urządzenia gwarantuje, że firma Microsoft zna wszystkie mikroukłady Azure Sphere i że w połączonych urządzeniach można używać tylko wiarygodnych mikroukładów.

• Adres IP — adres IP jest przypisywany, gdy do komputera jest dołączony interfejs urządzenia oparty na interfejsie FTDI; nie wskazuje, że urządzenie reaguje. Adres IP będzie się powtarzał, gdy interfejs urządzenia oparty na interfejsie FTDI jest dołączony do komputera, nawet jeśli do interfejsu jest podłączone inne urządzenie Azure Sphere. Jednak po ponownym uruchomieniu komputera adres IP może ulec zmianie. Do pierwszego podłączonego interfejsu urządzenia opartego na interfejsie FTDI jest przypisany adres 192.168.35.2. Do każdego urządzenia jest przypisany adres IP , nawet jeśli nie odpowiada, dzięki czemu możesz użyć adresu IP do zidentyfikowania urządzenia wymagającego odzyskiwania.

• Ścieżka połączenia — ścieżka połączenia to identyfikator lokalizacji FTDI identyfikujący połączenie USB. Identyfikator lokalizacji będzie się powtarzał, gdy interfejs urządzenia oparty na interfejsie FTDI jest dołączony do tego samego portu USB na tym samym koncentratonie USB, a z kolei do tego samego portu na komputerze. W związku z tym, utrzymuje się po ponownym uruchomieniu. Jednak wszelkie zmiany w okablowaniu między komputerem a urządzeniem mogą spowodować zmiany ścieżki połączenia. Podobnie jak adres IP, nie zmienia się nawet wtedy, gdy inne urządzenie Azure Sphere jest podłączone do interfejsu FTDI.

Aktualizowanie systemu operacyjnego Azure Sphere

Każdy mikroukład Azure Sphere jest ładowany razem z systemem operacyjnym Azure Sphere, gdy jest dostarczany przez producenta układu krzemowego. W zależności od wersji systemu operacyjnego Azure Sphere na mikroukładach dostępnych od dostawcy i w zależności od wymagań dotyczących wersji systemu operacyjnego aplikacji może być konieczne zaktualizowanie systemu operacyjnego Azure Sphere podczas produkcji połączonego urządzenia. System operacyjny można zaktualizować, instalując określone obrazy odzyskiwania, które powinny już być obecne na komputerze. Zobacz Przygotowanie do aktualizacji systemu operacyjnego w zadaniach związanych z przygotowaniem produkcji. Próbki produkcji zawierają przykładowy skrypt, który wykonuje równoległe odzyskiwanie wielu urządzeń.

Możesz zaktualizować system operacyjny na urządzeniu Azure Sphere, wydając polecenie odzyskiwania urządzenia az sphere . Użyj parametru --images , aby zainstalować określone obrazy odzyskiwania:

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

Uwaga

Jeśli z komputerem jest podłączonych wiele urządzeń, podaj --device parametr umożliwiający identyfikację urządzenia docelowego za pomocą adresu IP lub ścieżki połączenia. Aby uzyskać szczegółowe informacje, zobacz Łączenie każdego mikroukładu Azure Sphere z komputerem w fabryce .

Aktualizowanie zaufanego witryny keystore

W celu wstępnego załadowania oprogramowania na urządzenie może być konieczne zaktualizowanie zaufanego folderu kluczy na urządzeniu. Jest to wymagane tylko wtedy, gdy system operacyjny na urządzeniu jest starszy od oprogramowania i tylko wtedy, gdy klucz podpisywania obrazu Azure Sphere używany przez as3 został zaktualizowany między publikowanym systemem operacyjnym a oprogramowaniem podpisanym produkcyjnym. Aby uniknąć tego kroku i skrócić czas produkcji, rozważ zaktualizowanie wersji systemu operacyjnego używanej podczas produkcji.

Możesz łatwo ustalić, czy aktualizacja zaufanego centrum kluczy jest wymagana, próbując załadować oprogramowanie zgodnie z instrukcjami w następnej sekcji. Jeśli ładowanie się powiedzie, nie trzeba aktualizować zaufanej witryny keystore. Jeśli ładowanie zakończy się niepowodzeniem, a komunikat zaczyna się od Internal device error: Image not trusted by device tego, przyczyną jest nieaktualna zaufana skrzynka kluczy.

Aby zaktualizować zaufaną usługę keystore, musisz nabyć aktualny plik z zaufanej witryny keystore. Następnie, w ramach skryptów produkcyjnych, użyj polecenia wdrażania urządzenia az sphere sideload, aby załadować zaktualizowaną zaufaną magazynu kluczy przed załadowaniem oprogramowania aplikacji, zastępując <path-to-trusted-keystore.bin> ścieżkę do pliku zaufanego magazynu kluczy:

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

Załaduj oprogramowanie urządzenia

Wszystkie załadowane oprogramowanie — niezależnie od tego, czy jest to obraz konfiguracji tablicy, aplikacja testowa, czy aplikacja produkcyjna — musi być podpisane jako produkcyjne. Jeśli załadujesz aplikację tymczasową do testowania, musisz ją usunąć po zakończeniu testowania.

Wszystkie obrazy z podpisem produkcyjnym, których potrzebujesz podczas procesu produkcyjnego, powinny być zapisywane na komputerze w fabryce przed rozpoczęciem procesu, zgodnie z opisem w artykule Pobieranie obrazów podpisanych pod nazwą produkcji w zadaniach związanych z przygotowaniem produkcji.

Podczas produkcji urządzenia Azure Sphere nie mogą wymagać żadnych specjalnych możliwości urządzeń, takich jak funkcja rozwoju aplikacji, która umożliwia debugowanie. Nabywanie możliwości dla poszczególnych urządzeń zmniejsza bezpieczeństwo urządzenia i wymaga łączności internetowej, która jest zazwyczaj niepożądana w fabryce.

Aby załadować oprogramowanie na urządzenie w fabryce lub usunąć tymczasowe oprogramowanie z urządzenia po zakończeniu testowania, użyj polecenia ładowania bezpośredniego urządzenia az sphere w następujący sposób:

• Użyj az sphere urządzenie sideload wdrożyć załadować obraz, zastępując <file-path> nazwą i ścieżką do pliku obrazu z podpisem produkcyjnym:

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

• Usuń tymczasowy obraz przy użyciu urządzenia az sphere , aby usunąć obraz tymczasowy, zastępując <component-id> identyfikatorem składnika obrazu do usunięcia:

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

Uwaga

Jeśli z komputerem jest podłączonych wiele urządzeń, podaj --device parametr umożliwiający identyfikację urządzenia docelowego za pomocą adresu IP lub ścieżki połączenia. Aby uzyskać szczegółowe informacje, zobacz Łączenie każdego mikroukładu Azure Sphere z komputerem w fabryce .

Uruchamianie testów funkcjonalnych

Testy funkcjonalne są niezbędne do sprawdzenia, czy produkt działa prawidłowo. Uruchom aplikacje opracowane do testowania funkcjonalnego w ramach zadań związanych z przygotowaniem produkcji. Zobacz Tworzenie aplikacji do testowania funkcjonalności.

Jeśli testy funkcjonalności wymagają komunikacji z testowanym mikroukładem, podłącz urządzenia UART peryferyjne MT3620 (ISU0, ISU1, ISU2 lub ISU3) do komputera w fabryce lub zewnętrznego sprzętu testowego za pomocą odpowiednich obwodów własnych projektów.

Testowanie i kalibrowanie fal radiowych

Mikroukłady Azure Sphere mogą używać Wi-Fi do otrzymywania aktualizacji oprogramowania i komunikowania się z Internetem. Jeśli produkt korzysta z Wi-Fi i zawiera konstrukcję wiórową lub moduł , który nie jest certyfikowany do obsługi fal radiowych, należy przeprowadzić testy fal radiowych i kalibrację dla każdego urządzenia. Sprzęt i narzędzia potrzebne do tego zadania opisano w artykule Sprzęt i oprogramowanie do testowania i kalibracji fal radiowych w zadaniach związanych z przygotowaniem produkcji.

Pakiet Rf Tools zawiera narzędzia i bibliotekę interfejsów API C do użycia podczas testowania. Za pomocą biblioteki interfejsu API C można programować ustawienia fal radiowych specyficznych dla produktu w bezpiecznikach e-bezpieczników. Na przykład bezpieczniki elektroniczne są zaprogramowane w celu skonfigurowania anteny i częstotliwości, dostosowania urządzeń w celu uzyskania optymalnej wydajności oraz włączenia kanałów Wi-Fi. W temacie Narzędzia do testowania fal radiowych opisano sposób używania narzędzi fal radiowych.

Programowanie bezpieczników e-bezpieczników w celu włączenia kanałów Wi-Fi

System operacyjny Azure Sphere wybiera kanały Wi-Fi na podstawie kodu regionu zaprogramowanego w e-bezpieczniki MT3620 dla adresów offsetowych 0x36 i 0x37. Aby uzyskać szczegółowe informacje na temat bezpieczników e-bezpieczników na MT3620, zobacz dokument Mt3620 E-fuse Content Guidelines Mediatek.

Kod regionu to dwuliterowy kod ASCII. System operacyjny Azure Sphere używa ustawienia kodu regionu w e-bezpiecznikach w celu wyszukania regionu w bezprzewodowej bazie danych linuxowej , a następnie wybiera kanały dozwolone dla tego regionu. Jeśli żaden kod regionu nie jest zaprogramowany w bezpiecznikach elektronicznych, wówczas e-bezpieczniki pozostają ustawione na 0x00 0x00 lub jeśli są zaprogramowane znaki "00", system operacyjny domyślnie ustawia konserwatywny zestaw kanałów, które są ogólnie dozwolone we wszystkich regionach. Kanały dozwolone dla regionu "00" są określone w bezprzewodowej bazie danych linuxowych regulatorów.

Ustawienie kodu regionu w bezpiecznikach e-bezpieczników nie musi odpowiadać krajowi, w którym będzie używane urządzenie. Producenci mogą wybrać dowolny kod regionu mapowania na dozwolony zestaw kanałów dla regionu działania. Różne regiony i kraje często przyjmują podobne lub identyczne przepisy, które mogą zezwalać na wymienne stosowanie kodów regionów.

Przykład: Aby polecić systemowi operacyjnego Azure Sphere wybranie kanałów Wi-Fi dla regionu "DE" (Niemcy), program 0x44=D i 0x45=E do bezpieczników elektronicznych pod adresami 0x36 i 0x37. Poniżej przedstawiono dozwolone kanały dla Niemiec, wycinki bezprzewodowej bazy danych linuxowej. Większość krajów Unii Europejskiej zezwala na ten sam zestaw kanałów.

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)

Sprawdzanie konfiguracji fal radiowych

Użyj narzędzia RfSettingsTool, aby sprawdzić, czy opcje konfiguracji radiowej, takie jak docelowa moc nadawczy, kod regionu i adres Wi-Fi Media Access Control (MAC) zostały poprawnie ustawione. Więcej informacji na temat korzystania z tego narzędzia zawiera dokumentacja narzędzia ustawień fal radiowych.

Weryfikowanie Wi-Fi komunikacji

Rozważ nawiązanie połączenia z punktem dostępu Wi-Fi, aby sprawdzić, czy aplikacja produktu może komunikować się za pośrednictwem sieci Wi-Fi. Upewnij się, że połączenie Wi-Fi nie ma dostępu do Internetu, ponieważ aktualizacja za pośrednictwem powietrza może wystąpić, jeśli mikroukład nawiąże połączenie z punktem dostępu z internetem.

Aby podłączyć urządzenie do punktu dostępu Wi-Fi, postępuj zgodnie z instrukcjami na karcie Szybki start (cli). Jeśli wiele urządzeń jest podłączonych do komputera, musisz dołączyć --device parametr w az sphere device wifi show-status command i az sphere device wifi add command. Aby uzyskać szczegółowe informacje na temat używania polecenia urządzenia az sphere z wieloma dołączonymi urządzeniami, zobacz Łączenie każdego mikroukładu Azure Sphere z komputerem w fabryce.

Po Wi-Fi testach należy usunąć wszelkie Wi-Fi punkty dostępu używane do testowania z mikroukładu, aby nie były widoczne dla klientów. Odzyskiwanie urządzenia usuwa wszystkie dane konfiguracji Wi-Fi z mikroukładu.

Konfigurowanie urządzenia pod kątem sieci Ethernet

Urządzenie Azure Sphere może komunikować się za pośrednictwem sieci Ethernet. Urządzenie wymaga zewnętrznej karty Ethernet i obrazu konfiguracji tablicy do komunikacji za pośrednictwem sieci Ethernet.

Aby skonfigurować urządzenie Azure Sphere dla sieci Ethernet, podłącz kartę Ethernet do urządzenia Azure Sphere zgodnie z opisem w temacie Łączenie kart Ethernet.

Dwa urządzenia Ethernet są obsługiwane przez system operacyjny Azure Sphere.

1. Microchip ENC28J60. Jest to karta 10Base-T (10 mb/s). Może być przewodowy ze wskaźnikiem LED z prędkością półdupleksową lub bez wskaźnika LED z pełną prędkością dupleksu. Seeed devkits are wired for half-duplex operation.
2. Wiznet W5500. Jest to łącznik 100Base-TX (100mpbs). Obsługuje zintegrowany stos TCP/IP i tryb przechodzenia kart sieciowych, ale usługa Azure Sphere obsługuje przekazywanie kart sieciowych tylko w przypadku korzystania z W5500 na potrzeby łączności internetowej. Ze względu na ograniczenia przepustowości magistrali pełna prędkość 100 mb/s może nie być osiągalna przez urządzenie MT3620.

Interfejs Ethernet zostanie włączony automatycznie po załadowaniu konfiguracji tablicy, zgodnie z opisem w artykule Ładowanie oprogramowania urządzenia i ponownym uruchomieniu urządzenia. Wszystkie interfejsy domyślnie używają dynamicznych adresów IP.

Finalizowanie urządzenia Azure Sphere

Finalizacja gwarantuje, że urządzenie Azure Sphere jest w stanie zabezpieczonym i jest gotowe do wysłania klientom. Przed wysłaniem urządzenia należy sfinalizować jego wysyłkę. Finalizacja obejmuje:

• Uruchomienie testów gotowych do wysłania w celu upewnienia się, że zainstalowano właściwe oprogramowanie systemowe i aplikację produkcyjną, a narzędzia rf są wyłączone.

• Ustawienie stanu produkcji urządzenia w celu zablokowania narzędzi do konfiguracji i kalibracji fal radiowych oraz zapobiegania naruszeniom bezpieczeństwa.

Uruchom testy gotowe do wysłania

Przed wysłaniem produktu zawierającego urządzenie Azure Sphere należy przeprowadzić testy gotowe do wysłania. Różne kontrole muszą być wykonywane dla różnych stanów produkcyjnych. Testy gotowe do wysyłki zapewniają następujące elementy:

• Stan produkcji urządzenia jest ustawiany poprawnie dla tego etapu produkcji.
• System operacyjny Azure Sphere na urządzeniu jest prawidłowy i ma oczekiwaną wersję. Można to sprawdzić tylko w przypadku urządzeń, które nie są jeszcze w stanie DeviceComplete.
• Obrazy dostarczane przez użytkownika na urządzeniu są zgodne z listą oczekiwanych obrazów. Można to sprawdzić tylko w przypadku urządzeń, które nie są jeszcze w stanie DeviceComplete.
• Na urządzeniu nie skonfigurowano żadnych nieoczekiwanych Wi-Fi sieci. Można to sprawdzić tylko w przypadku urządzeń, które nie są jeszcze w stanie DeviceComplete.
• Urządzenie nie zawiera żadnych specjalnych certyfikatów możliwości. W przypadku urządzeń opartych na platformie MT3620 można to sprawdzić tylko na urządzeniach, które nie są w stanie pustym.

Różne testy są niezbędne na różnych etapach produkcji, ponieważ stan produkcji urządzenia określa możliwości urządzenia.

To, które testy zostaną uruchomione, będzie również zależeć od tego, czy projektujesz moduł, czy podłączone urządzenie. Na przykład jako producent modułu możesz pozostawić mikroukład w stanie Pusta produkcja, aby klient modułu mógł przeprowadzić dodatkowe testy radiowe i konfigurację.

Wykonywanie testów przy użyciu device_ready.py

Pakiet Próbki produkcji zawiera narzędzie o nazwie device_ready.py, które wykonuje powyższe testy, stosownie do każdego stanu produkcji. Powinna być uruchamiana dla każdego z stanów produkcyjnych odpowiednich dla Twojego urządzenia.

W poniższej tabeli wymieniono parametry używane przez skrypt device_ready.py:

Parametr	Opis
--expected_mfg_state	Określa, jaki stan produkcji należy sprawdzić i kontroluje, które testy są uruchamiane. Jeśli ten parametr nie jest określony, domyślnie ma wartość "DeviceComplete". Jeśli stan produkcji urządzenia różni się od tej wartości, sprawdzanie kończy się niepowodzeniem.
--images	Określa listę identyfikatorów obrazów (IDENTYFIKATORÓW GUID), które muszą być obecne na urządzeniu, aby sprawdzanie zakończyło się pomyślnie. Lista składa się z identyfikatorów GUID obrazów rozdzielonych spacjami. Ten parametr domyślnie wyświetla pustą listę, jeśli nie jest określona. Jeśli lista zainstalowanych identyfikatorów obrazów na urządzeniu różni się od tej listy, sprawdzanie kończy się niepowodzeniem. Sprawdzanie identyfikatorów obrazów (a nie identyfikatorów składników) zapewnia, że jest dostępna określona wersja składnika.
--os	Określa listę wersji systemu operacyjnego Azure Sphere. Ten parametr domyślnie wyświetla pustą listę, jeśli nie została podana. Jeśli na tej liście nie ma wersji systemu operacyjnego dostępnej na urządzeniu, to sprawdzanie kończy się niepowodzeniem.
--os_components_json_file	Określa ścieżkę do pliku JSON zawierającego listę składników systemu operacyjnego definiujących każdą wersję systemu operacyjnego. W przypadku urządzeń opartych na platformie MT3620 ten plik nosi nazwę mt3620an.json. download_os_list.py Użyj tego narzędzia, aby pobrać najnowszą wersję.
--azsphere_path	Określa ścieżkę do narzędzia azsphere.exe. Jeśli nie określono, ten parametr domyślnie określa domyślną lokalizację instalacji zestawu SDK Azure Sphere w systemie Windows. Użyj tego parametru tylko wtedy, gdy zestaw Azure Sphere SDK nie jest zainstalowany w lokalizacji domyślnej.
--help	Pokazuje pomoc wiersza polecenia.
--verbose	Zawiera dodatkowe szczegóły danych wyjściowych.

Poniższy przykład to przykładowy przebieg device_ready.py narzędzia z następującymi argumentami:

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

Ustawianie stanu produkcji urządzenia

Wrażliwych operacji produkcyjnych, takich jak umieszczenie urządzenia radiowego w trybie testowym i ustawienie Wi-Fi konfiguracji e-bezpieczniki nie powinny być dostępne dla użytkowników końcowych urządzeń zawierających mikroukład Azure Sphere. Stan produkcyjny urządzenia Azure Sphere ogranicza dostęp do tych poufnych operacji.

Trzy stany produkcyjne są następujące:

• Puste. Stan Pusty nie ogranicza operacji produkcyjnych na mikroukładach. Mikroukłady w stanie pustym mogą wejść w tryb testowania fal radiowych, a ich e-bezpieczniki można zaprogramować. Kiedy mikroukłady są wysyłane z fabryki krzemu, znajdują się w stanie produkcji pustych .

• Moduł1Ukończ. Stan produkcji Module1Complete został zaprojektowany tak, aby ograniczyć dostosowania, jakie użytkownicy mogą wprowadzić w ustawieniach konfiguracji urządzeń radiowych, takich jak maksymalne poziomy mocy nadawczej i dozwolone częstotliwości. Poleceń rf można używać do momentu ustawienia modułu Module1Complete . Ograniczenie dostępu użytkowników końcowych do tych ustawień może być wymagane do spełnienia zasad regulacyjnych dotyczących sprzętu radiowego. To ustawienie dotyczy przede wszystkim producentów, którzy muszą przetestować i skalibrować parametry działania urządzenia radiowego.

  Firma Microsoft zaleca ustawienie tego stanu produkcji po zakończeniu testowania i kalibracji radiowej; Po jej ustawieniu nie można używać poleceń rf. Stan Moduł1Uzupełnianie chroni urządzenie przed zmianami, które mogą zakłócić prawidłowe działanie urządzenia radiowego i innych urządzeń bezprzewodowych w pobliżu.

• Funkcja DeviceComplete. Stan produkcji DeviceComplete umożliwia producentom gotowych produktów zabezpieczanie urządzeń wdrożonych w polu przed zmianami. Po umieszczeniu urządzenia w stanie DeviceComplete należy użyć pliku funkcji specyficznego dla urządzenia przy każdym ładowaniu oprogramowania i wykonywaniu zadań konfiguracyjnych. Funkcja fieldervicing umożliwia ładowanie bezpośrednie obrazów podpisanych przez produkcję, ale nie ich usuwanie. Funkcja appdevelopment umożliwia ładowanie bezpośrednie i usuwanie obrazów.

  Nie ustawiaj funkcji DeviceComplete dla nieukończonych urządzeń lub modułów (modułów Wi-Fi, tablic programistzych itd.), które mogą być używane jako część większego systemu; ten stan ogranicza działalność produkcyjną, taką jak testowanie linii produkcyjnej, instalacja oprogramowania i konfiguracja. Wiele poleceń interfejsu sieciowego jest niedostępnych po ustawieniu funkcji DeviceComplete , więc przed ustawieniem tego stanu należy uruchomić pewne testy gotowe do wysłania. Polecenia z ograniczeniami można ponownie włączyć przy użyciu funkcji urządzenia , takiej jak funkcja fieldervicing , ale tylko dla urządzeń, które zostały zgłoszone, i dlatego nie jest to odpowiednie do użytku w środowisku na hali produkcyjnej, ponieważ wymaga łączności z chmurą.

W poniższej tabeli podsumowano możliwości urządzenia występujące w poszczególnych województwo produkcyjne.

Stan produkcji	Funkcje urządzenia
Puste	włączFrfTestMode, fieldServicing oraz te, które są ładowane bezpośrednio lub przekazywane za pomocą operacji, zgodnie z opisem w temacie Możliwości urządzenia.
Moduł1Ukończ.	fieldServicing i te, które są ładowane bezpośrednio lub przekazywane za pomocą operacji, zgodnie z opisem w temacie Możliwości urządzenia.
DeviceComplete (Funkcja DeviceComplete)	Tylko te, które są ładowane bezpośrednio lub przekazywane za pomocą operacji, zgodnie z opisem w temacie Możliwości urządzenia.

Po zakończeniu produkcji użyj polecenia aktualizacji stanu produkcji urządzenia azsphere , aby ustawić stan DeviceComplete :

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

Uwaga

Jeśli z komputerem jest podłączonych wiele urządzeń, podaj --device parametr umożliwiający identyfikację urządzenia docelowego za pomocą adresu IP lub ścieżki połączenia. Aby uzyskać szczegółowe informacje, zobacz Łączenie każdego mikroukładu Azure Sphere z komputerem w fabryce .

Ważne

Przeniesienie mikroukładu do stanu DeviceComplete jest operacją trwałą i nie można jej cofnąć. Gdy mikroukład znajduje się w stanie DeviceComplete , nie może wejść w tryb testowania fal radiowych; jego ustawień bezpiecznika e-bezpiecznika nie można dostosować; i Wi-Fi ustawienia, aktualizacje systemu operacyjnego i zainstalowane aplikacje nie mogą być zmieniane bez żądania urządzenia i korzystania z funkcji urządzenia. Jeśli chcesz ponownie włączyć funkcje na pojedynczym mikroukładzie, którego możliwości urządzenia nie włączają ponownie, na przykład w scenariuszu analizy błędów, skontaktuj się z firmą Microsoft.