Role i operacje

Fazy tworzenia rozwiązania IoT mogą obejmować tygodnie lub miesiące ze względu na realia produkcji, takie jak czas produkcji, wysyłka, proces celny itp. Ponadto mogą obejmować działania w wielu rolach, biorąc pod uwagę różne zaangażowane jednostki. W tym temacie bardziej szczegółowo przedstawiono różne role i operacje związane z poszczególnymi fazami, a następnie przedstawiono przepływ na diagramie sekwencji.

Aprowizacja nakłada również wymagania producenta urządzenia, specyficzne dla włączenia mechanizmu zaświadczania. Operacje produkcyjne mogą również odbywać się niezależnie od czasu fazy automatycznej aprowizacji, zwłaszcza w przypadkach, gdy nowe urządzenia są pozyskiwane po ustanowieniu automatycznej aprowizacji.

Seria przewodników Szybki start jest dostępna w spisie treści po lewej stronie, aby ułatwić wyjaśnienie automatycznej aprowizacji za pomocą praktycznego środowiska. Aby ułatwić/uprościć proces uczenia, oprogramowanie służy do symulowania urządzenia fizycznego na potrzeby rejestracji i rejestracji. Niektóre przewodniki Szybki start wymagają wykonania operacji dla wielu ról, w tym operacji dla nieistniejących ról ze względu na symulowany charakter przewodników Szybki start.

Rola Działanie opis
Producent Kodowanie tożsamości i adresu URL rejestracji Na podstawie używanego mechanizmu zaświadczania producent jest odpowiedzialny za kodowanie informacji o tożsamości urządzenia oraz adres URL rejestracji usługi Device Provisioning Service.

Przewodniki Szybki start: ponieważ urządzenie jest symulowane, nie ma roli Producent. Zobacz rolę dewelopera, aby uzyskać szczegółowe informacje na temat sposobu uzyskiwania tych informacji, które są używane podczas kodowania przykładowej aplikacji rejestracji.
Podaj tożsamość urządzenia Jako inicjator informacji o tożsamości urządzenia producent jest odpowiedzialny za komunikację z operatorem (lub wyznaczonym agentem) lub bezpośrednią rejestrację w usłudze Device Provisioning Service za pośrednictwem interfejsów API.

Przewodniki Szybki start: ponieważ urządzenie jest symulowane, nie ma roli Producent. Zobacz rolę Operator, aby uzyskać szczegółowe informacje na temat sposobu uzyskiwania tożsamości urządzenia, która służy do rejestrowania symulowanego urządzenia w wystąpieniu usługi Device Provisioning Service.
Operator Konfigurowanie automatycznej aprowizacji Ta operacja odpowiada pierwszej fazie automatycznej aprowizacji.

Przewodniki Szybki start: wykonujesz rolę Operator, konfigurujesz wystąpienia usługi Device Provisioning Service i usługi IoT Hub w ramach subskrypcji platformy Azure.
Rejestrowanie tożsamości urządzenia Ta operacja odpowiada drugiej fazie automatycznej aprowizacji.

Przewodniki Szybki start: wykonujesz rolę Operator, rejestrując symulowane urządzenie w wystąpieniu usługi Device Provisioning Service. Tożsamość urządzenia jest określana przez metodę zaświadczania symulowaną w przewodniku Szybki start (TPM lub X.509). Aby uzyskać szczegółowe informacje na temat zaświadczania, zobacz rolę dewelopera.
Device Provisioning Service,
IoT Hub
<wszystkie operacje> W przypadku wdrożenia produkcyjnego z urządzeniami fizycznymi i przewodników Szybki start z symulowanymi urządzeniami te role są realizowane za pośrednictwem usług IoT skonfigurowanych w ramach subskrypcji platformy Azure. Role/operacje działają dokładnie tak samo, jak usługi IoT są obojętne na aprowizowanie urządzeń fizycznych i symulowanych.
Deweloperzy Kompilowanie/wdrażanie oprogramowania rejestracji Ta operacja odpowiada trzeciej fazie automatycznej aprowizacji. Deweloper jest odpowiedzialny za kompilowanie i wdrażanie oprogramowania rejestracyjnego na urządzeniu przy użyciu odpowiedniego zestawu SDK.

Przewodniki Szybki start: utworzona przykładowa aplikacja rejestracji symuluje rzeczywiste urządzenie dla wybranej platformy/języka, która działa na stacji roboczej (zamiast wdrażać je na urządzeniu fizycznym). Aplikacja rejestracji wykonuje te same operacje co jedna wdrożona na urządzeniu fizycznym. Należy określić metodę zaświadczania (certyfikat TPM lub X.509) oraz adres URL rejestracji i "zakres identyfikatora" wystąpienia usługi Device Provisioning Service. Tożsamość urządzenia jest określana przez logikę zaświadczania zestawu SDK w czasie wykonywania na podstawie określonej metody:
  • Zaświadczenie modułu TPM — stacja robocza deweloperów uruchamia aplikację symulatora modułu TPM. Po uruchomieniu oddzielna aplikacja służy do wyodrębniania "klucza poręczenia" i "identyfikatora rejestracji" modułu TPM do użycia podczas rejestrowania tożsamości urządzenia. Logika zaświadczania zestawu SDK używa również symulatora podczas rejestracji, aby przedstawić podpisany token SAS na potrzeby uwierzytelniania i weryfikacji rejestracji.
  • Zaświadczenie X509 — służy narzędzie do generowania certyfikatu. Po wygenerowaniu należy utworzyć plik certyfikatu wymagany do użycia w rejestracji. Logika zaświadczania zestawu SDK używa również certyfikatu podczas rejestracji do prezentowania na potrzeby weryfikacji uwierzytelniania i rejestracji.
Urządzenie Rozruch i rejestrowanie Ta operacja odpowiada trzeciej fazie automatycznej aprowizacji, realizowanej przez oprogramowanie rejestracji urządzeń utworzone przez dewelopera. Aby uzyskać szczegółowe informacje, zobacz rolę dewelopera. Podczas pierwszego rozruchu:
  1. Aplikacja łączy się z wystąpieniem usługi Device Provisioning Service zgodnie z globalnym adresem URL i usługą "Zakres identyfikatorów" określonym podczas programowania.
  2. Po nawiązaniu połączenia urządzenie jest uwierzytelniane względem metody zaświadczania i tożsamości określonej podczas rejestracji.
  3. Po uwierzytelnieniu urządzenie jest zarejestrowane w wystąpieniu usługi IoT Hub określonym przez wystąpienie usługi aprowizacji.
  4. Po pomyślnej rejestracji unikatowy identyfikator urządzenia i punkt końcowy usługi IoT Hub są zwracane do aplikacji rejestracji w celu komunikowania się z usługą IoT Hub.
  5. Z tego miejsca urządzenie może ściągnąć początkowy stan bliźniaczej reprezentacji urządzenia na potrzeby konfiguracji i rozpocząć proces raportowania danych telemetrycznych.
Przewodniki Szybki start: ponieważ urządzenie jest symulowane, oprogramowanie rejestracyjne działa na stacji roboczej dewelopera.

Na poniższym diagramie przedstawiono podsumowanie ról i sekwencjonowania operacji podczas automatycznej aprowizacji urządzenia:

Auto-provisioning sequence for a device

Uwaga

Opcjonalnie producent może również wykonać operację "Rejestrowanie tożsamości urządzenia" przy użyciu interfejsów API usługi Device Provisioning Service (zamiast za pośrednictwem operatora). Aby zapoznać się ze szczegółowym omówieniem tej sekwencjonowania i nie tylko, zobacz wideo Zero touch device registration with Azure IoT (począwszy od znacznika 41:00)

Role i konta platformy Azure

Sposób mapowania każdej roli na konto platformy Azure jest zależny od scenariusza i istnieje wiele scenariuszy, które mogą być zaangażowane. Poniższe typowe wzorce powinny pomóc w ogólnym zrozumieniu, w jaki sposób role są ogólnie mapowane na konto platformy Azure.

Producent mikroukładu zapewnia usługi zabezpieczeń

W tym scenariuszu producent zarządza zabezpieczeniami klientów na poziomie jednego. Ten scenariusz może być preferowany przez tych klientów na poziomie jednego, ponieważ nie musi zarządzać szczegółowymi zabezpieczeniami.

Producent wprowadza zabezpieczenia do sprzętowych modułów zabezpieczeń (HSM). Te zabezpieczenia mogą obejmować producenta uzyskującego klucze, certyfikaty itp. od potencjalnych klientów, którzy mają już skonfigurowane wystąpienia usługi DPS i grupy rejestracji. Producent może również wygenerować te informacje zabezpieczające dla swoich klientów.

W tym scenariuszu mogą istnieć dwa konta platformy Azure:

  • Konto nr 1: Prawdopodobnie współużytkowane przez operator i role dewelopera do pewnego stopnia. Ta strona może zakupić mikroukłady HSM od producenta. Te mikroukłady są wskazywane na wystąpienia usługi DPS skojarzone z kontem #1. W przypadku rejestracji w usłudze DPS ta strona może dzierżawić urządzenia na wielu poziomach dwóch klientów, konfigurując ponownie ustawienia rejestracji urządzeń w usłudze DPS. Ta strona może również mieć przydzielone centra IoT dla systemów zaplecza użytkownika końcowego do interfejsu w celu uzyskania dostępu do danych telemetrycznych urządzeń itp. W tym ostatnim przypadku może nie być potrzebne drugie konto.

  • Konto nr 2: Użytkownicy końcowi, klienci na poziomie dwóch mogą mieć własne centra IoT. Strona skojarzona z kontem #1 wskazuje tylko dzierżawione urządzenia do odpowiedniego centrum na tym koncie. Ta konfiguracja wymaga łączenia centrów DPS i IoT hub na kontach platformy Azure, które można wykonać za pomocą szablonów usługi Azure Resource Manager.

All-in-one OEM

Producent może być "All-in-one OEM", w którym potrzebne byłoby tylko jedno konto producenta. Producent obsługuje kompleksowe zabezpieczenia i aprowizację.

Producent może udostępnić aplikację opartą na chmurze klientom, którzy kupują urządzenia. Ta aplikacja będzie interfejsem z usługą IoT Hub przydzieloną przez producenta.

Automaty do sprzedaży lub zautomatyzowane ekspresy do kawy stanowią przykłady dla tego scenariusza.

Następne kroki

Warto dodać zakładkę do tego artykułu jako punkt odniesienia podczas pracy z odpowiednimi przewodnikami Szybki start dotyczącym automatycznej aprowizacji.

Zacznij od ukończenia przewodnika Szybki start "Konfigurowanie automatycznej aprowizacji", który najlepiej odpowiada preferencjom narzędzia do zarządzania, który przeprowadzi Cię przez fazę "Konfiguracja usługi":

Następnie przejdź do przewodnika Szybki start "Aprowizowanie urządzenia", który odpowiada mechanizmowi zaświadczania urządzenia i preferencjom zestawu SDK/języka usługi Device Provisioning Service. W tym przewodniku Szybki start przedstawiono fazy "Rejestrowanie urządzenia" i "Rejestracja urządzenia i konfiguracja":

Mechanizm zaświadczania urządzenia Szybki start
Klucz symetryczny Aprowizuj symulowane urządzenie klucza symetrycznego
Certyfikat X.509 Aprowizuj symulowane urządzenie X.509
Moduł TPM (Simulated Trusted Platform Module) Aprowizuj symulowane urządzenie TPM