Roller och åtgärder

Faserna för att utveckla en IoT-lösning kan sträcka sig över veckor eller månader, på grund av produktionsverkligheter som tillverkningstid, frakt, tullprocess osv. Dessutom kan de omfatta aktiviteter över flera roller med tanke på de olika entiteter som är inblandade. Det här avsnittet tar en djupare titt på de olika roller och åtgärder som är relaterade till varje fas och illustrerar sedan flödet i ett sekvensdiagram.

Etableringen ställer också krav på enhetstillverkaren, särskilt för att aktivera attesteringsmekanismen. Tillverkningsåtgärder kan också ske oberoende av tidpunkten för automatiska etableringsfaser, särskilt i fall där nya enheter införskaffas efter att automatisk etablering redan har upprättats.

En serie snabbstarter finns i innehållsförteckningen till vänster för att förklara automatisk etablering via praktisk upplevelse. För att underlätta/förenkla inlärningsprocessen används programvara för att simulera en fysisk enhet för registrering och registrering. Vissa snabbstarter kräver att du utför åtgärder för flera roller, inklusive åtgärder för obefintliga roller, på grund av snabbstarternas simulerade karaktär.

Roll Operation Beskrivning
Tillverkare Koda identitets- och registrerings-URL Baserat på attesteringsmekanismen som används ansvarar tillverkaren för att koda enhetens identitetsinformation och registrerings-URL:en för Device Provisioning-tjänsten.

Snabbstarter: Eftersom enheten simuleras finns det ingen tillverkares roll. Se utvecklarrollen för mer information om hur du får den här informationen, som används för att koda ett exempelregistreringsprogram.
Ange enhetsidentitet Som upphovsman till enhetens identitetsinformation ansvarar tillverkaren för att kommunicera den med operatören (eller en utsedd agent) eller direkt registrera den till Device Provisioning Service via API:er.

Snabbstarter: Eftersom enheten simuleras finns det ingen tillverkares roll. Mer information om hur du får enhetsidentiteten finns i Operatörsrollen, som används för att registrera en simulerad enhet i instansen av enhetsetableringstjänsten.
Operatör Konfigurera automatisk etablering Den här åtgärden motsvarar den första fasen av automatisk etablering.

Snabbstarter: Du utför operatörsrollen och konfigurerar enhetsetableringstjänsten och IoT Hub-instanserna i din Azure-prenumeration.
Registrera enhetsidentitet Den här åtgärden motsvarar den andra fasen av automatisk etablering.

Snabbstarter: Du utför rollen Operator och registrerar din simulerade enhet i instansen av enhetsetableringstjänsten. Enhetsidentiteten bestäms av attesteringsmetoden som simuleras i snabbstarten (TPM eller X.509). Mer information om attestering finns i utvecklarrollen.
Enhetsetableringstjänst,
IoT Hub
<alla åtgärder> För både en produktionsimplementering med fysiska enheter och snabbstarter med simulerade enheter uppfylls dessa roller via de IoT-tjänster som du konfigurerar i din Azure-prenumeration. Rollerna/driften fungerar exakt likadant, eftersom IoT-tjänsterna inte är likgiltiga för etablering av fysiska eller simulerade enheter.
Utvecklare Skapa/distribuera registreringsprogramvara Den här åtgärden motsvarar den tredje fasen av automatisk etablering. Utvecklaren ansvarar för att skapa och distribuera registreringsprogramvaran till enheten med hjälp av lämplig SDK.

Snabbstarter: Exempelregistreringsprogrammet som du skapar simulerar en riktig enhet, för valfri plattform/språk, som körs på din arbetsstation (i stället för att distribuera den till en fysisk enhet). Registreringsprogrammet utför samma åtgärder som en som distribueras till en fysisk enhet. Du anger attesteringsmetoden (TPM- eller X.509-certifikat), plus registrerings-URL:en och "ID-omfånget" för enhetsetableringstjänstens instans. Enhetsidentiteten bestäms av SDK-attesteringslogiken vid körning, baserat på den metod som du anger:
  • TPM-attestering – din utvecklingsarbetsstation kör ett TPM-simulatorprogram. När du har kört ett separat program används för att extrahera TPM:s "Bekräftelsenyckel" och "Registrerings-ID" för användning vid registrering av enhetsidentiteten. SDK-attesteringslogiken använder också simulatorn under registreringen för att presentera en signerad SAS-token för verifiering av autentisering och registrering.
  • X509-attestering – du använder ett verktyg för att generera ett certifikat. När du har genererat den skapar du den certifikatfil som krävs för användning i registreringen. SDK-attesteringslogiken använder även certifikatet under registreringen för att presentera för verifiering av autentisering och registrering.
Enhet Starta och registrera Den här åtgärden motsvarar den tredje fasen av automatisk etablering, som uppfylls av programvaran för enhetsregistrering som skapats av utvecklaren. Mer information finns i utvecklarrollen. Vid första starten:
  1. Programmet ansluter till enhetsetableringstjänstens instans enligt den globala URL:en och tjänstens "ID-omfång" som angavs under utvecklingen.
  2. När enheten är ansluten autentiseras den mot attesteringsmetoden och identiteten som angavs under registreringen.
  3. När enheten har autentiserats registreras den med den IoT Hub-instans som anges av etableringstjänstinstansen.
  4. Vid lyckad registrering returneras ett unikt enhets-ID och en IoT Hub-slutpunkt till registreringsprogrammet för kommunikation med IoT Hub.
  5. Därifrån kan enheten hämta sitt ursprungliga enhetstvillingtillstånd för konfiguration och börja rapportera telemetridata.
Snabbstarter: Eftersom enheten simuleras körs registreringsprogramvaran på din utvecklingsarbetsstation.

I följande diagram sammanfattas rollerna och sekvenseringen av åtgärder under automatisk etablering av enheter:

Auto-provisioning sequence for a device

Kommentar

Om du vill kan tillverkaren också utföra åtgärden "Registrera enhetsidentitet" med api:er för enhetsetableringstjänsten (i stället för via operatorn). En detaljerad beskrivning av den här sekvenseringen och mycket mer finns i zero touch-enhetsregistrering med Azure IoT-video (från och med markör 41:00)

Roller och Azure-konton

Hur varje roll mappas till ett Azure-konto är scenarioberoende och det finns en hel del scenarier som kan vara inblandade. De vanliga mönstren nedan bör ge en allmän förståelse för hur roller i allmänhet mappas till ett Azure-konto.

Chiptillverkaren tillhandahåller säkerhetstjänster

I det här scenariot hanterar tillverkaren säkerhet för nivå ett-kunder. Det här scenariot kan föredras av dessa nivå ett-kunder eftersom de inte behöver hantera detaljerad säkerhet.

Tillverkaren introducerar säkerhet i maskinvarusäkerhetsmoduler (HSM). Den här säkerheten kan omfatta tillverkaren som hämtar nycklar, certifikat osv. från potentiella kunder som redan har DPS-instanser och konfiguration av registreringsgrupper. Tillverkaren kan också generera den här säkerhetsinformationen för sina kunder.

I det här scenariot kan det finnas två Azure-konton inblandade:

  • Konto nr 1: Delas troligen i viss utsträckning mellan operatörs- och utvecklarrollerna. Denna part kan köpa HSM-chipsen från tillverkaren. Dessa marker pekas på DPS-instanser som är associerade med konto nr 1. Med DPS-registreringar kan den här parten låna ut enheter till flera nivå två-kunder genom att konfigurera om enhetsregistreringsinställningarna i DPS. Den här parten kan också ha IoT-hubbar allokerade för slutanvändarens serverdelssystem att interagera med för att få åtkomst till enhetstelemetri osv. I det senare fallet kanske ett andra konto inte behövs.

  • Konto nr 2: Slutanvändare, nivå två-kunder kan ha egna IoT-hubbar. Den part som är associerad med konto nr 1 pekar bara uthyrda enheter till rätt hubb i det här kontot. Den här konfigurationen kräver länkning av DPS- och IoT-hubbar mellan Azure-konton, vilket kan göras med Azure Resource Manager-mallar.

Allt-i-ett OEM

Tillverkaren kan vara en "Allt-i-ett OEM" där endast ett enda tillverkarkonto skulle behövas. Tillverkaren hanterar säkerhet och etablering från slutpunkt till slutpunkt.

Tillverkaren kan tillhandahålla ett molnbaserat program till kunder som köper enheter. Det här programmet skulle samverka med den IoT Hub som tilldelats av tillverkaren.

Varuautomater eller automatiserade kaffebryggare är exempel för det här scenariot.

Nästa steg

Det kan vara bra att bokmåla den här artikeln som referenspunkt när du går igenom motsvarande snabbstarter för automatisk etablering.

Börja med att slutföra snabbstarten "Konfigurera automatisk etablering" som passar bäst för dina inställningar för hanteringsverktyget, som vägleder dig genom fasen "Tjänstkonfiguration":

Fortsätt sedan med snabbstarten "Etablera en enhet" som passar enhetens attesteringsmekanism och SDK/språkinställningar för Device Provisioning Service. I den här snabbstarten går du igenom faserna "Enhetsregistrering" och "Enhetsregistrering och konfiguration":

Mekanism för enhetsattestering Snabbstart
Symmetrisk nyckel Etablera en simulerad symmetrisk nyckelenhet
X.509-certifikat Etablera en simulerad X.509-enhet
Simulerad betrodd plattformsmodul (TPM) Etablera en simulerad TPM-enhet