Rollen en bewerkingen

De fasen van het ontwikkelen van een IoT-oplossing kunnen weken of maanden duren, vanwege productie-realiteiten zoals productietijd, verzending, douaneproces, enzovoort. Daarnaast kunnen ze activiteiten omvatten voor meerdere rollen, gezien de verschillende betrokken entiteiten. In dit onderwerp wordt dieper gekeken naar de verschillende rollen en bewerkingen die betrekking hebben op elke fase, waarna de stroom in een sequentiediagram wordt geïllustreerd.

Inrichting plaatst ook vereisten op de fabrikant van het apparaat, specifiek voor het inschakelen van het attestation-mechanisme. Productiebewerkingen kunnen ook onafhankelijk van de timing van automatische inrichtingsfasen plaatsvinden, met name in gevallen waarin nieuwe apparaten worden aangeschaft nadat automatische inrichting al is ingesteld.

Aan de linkerkant ziet u een reeks quickstarts in de inhoudsopgave om automatisch inrichten uit te leggen via praktische ervaring. Om het leerproces te vergemakkelijken/vereenvoudigen, wordt software gebruikt om een fysiek apparaat te simuleren voor inschrijving en registratie. Voor sommige quickstarts moet u bewerkingen uitvoeren voor meerdere rollen, waaronder bewerkingen voor niet-bestaande rollen, vanwege de gesimuleerde aard van de quickstarts.

- Rol	Operation	Beschrijving
Fabrikant	Id en registratie-URL coderen	Op basis van het gebruikte attestation-mechanisme is de fabrikant verantwoordelijk voor het coderen van de apparaat-id-gegevens en de registratie-URL van Device Provisioning Service. Quickstarts: omdat het apparaat is gesimuleerd, is er geen rol Fabrikant. Zie de rol Ontwikkelaar voor meer informatie over hoe u deze informatie krijgt, die wordt gebruikt bij het coderen van een voorbeeldregistratietoepassing.
	Apparaat-id opgeven	Als de originator van de apparaat-id-gegevens is de fabrikant verantwoordelijk voor de communicatie met de operator (of een aangewezen agent) of rechtstreeks inschrijven bij Device Provisioning Service via API's. Quickstarts: omdat het apparaat is gesimuleerd, is er geen rol Fabrikant. Zie de rol Operator voor meer informatie over hoe u de apparaat-id krijgt, die wordt gebruikt voor het inschrijven van een gesimuleerd apparaat in uw Device Provisioning Service-exemplaar.
Operator	Automatische inrichting configureren	Deze bewerking komt overeen met de eerste fase van automatische inrichting. Quickstarts: U voert de rol Operator uit, configureert de Device Provisioning Service- en IoT Hub-exemplaren in uw Azure-abonnement.
	Apparaat-id inschrijven	Deze bewerking komt overeen met de tweede fase van automatische inrichting. Quickstarts: U voert de rol Operator uit en registreert uw gesimuleerde apparaat in uw Device Provisioning Service-exemplaar. De apparaat-id wordt bepaald door de attestation-methode die wordt gesimuleerd in de quickstart (TPM of X.509). Zie de rol Ontwikkelaar voor attestation-details.
Device Provisioning Service, IoT Hub	<alle bewerkingen>	Voor zowel een productie-implementatie met fysieke apparaten als quickstarts met gesimuleerde apparaten worden deze rollen uitgevoerd via de IoT-services die u in uw Azure-abonnement configureert. De rollen/bewerkingen werken precies hetzelfde, omdat de IoT-services niet gedifferentieerd zijn voor het inrichten van fysieke versus gesimuleerde apparaten.
Ontwikkelaar	Registratiesoftware bouwen/implementeren	Deze bewerking komt overeen met de derde fase van automatische inrichting. De ontwikkelaar is verantwoordelijk voor het bouwen en implementeren van de registratiesoftware op het apparaat met behulp van de juiste SDK. Quickstarts: Met de voorbeeldregistratietoepassing die u bouwt, wordt een echt apparaat gesimuleerd voor uw platform/taal die op uw werkstation wordt uitgevoerd (in plaats van deze te implementeren op een fysiek apparaat). De registratietoepassing voert dezelfde bewerkingen uit als één bewerking die is geïmplementeerd op een fysiek apparaat. U geeft de attestation-methode (TPM- of X.509-certificaat) op, plus de registratie-URL en het id-bereik van uw Device Provisioning Service-exemplaar. De apparaat-id wordt tijdens runtime bepaald door de SDK Attestation-logica op basis van de methode die u opgeeft: TPM-attestation : uw ontwikkelwerkstation voert een TPM-simulatortoepassing uit. Zodra deze is uitgevoerd, wordt een afzonderlijke toepassing gebruikt om de goedkeuringssleutel en registratie-id van de TPM te extraheren voor gebruik bij het inschrijven van de apparaat-id. De SDK-attestation-logica maakt ook gebruik van de simulator tijdens de registratie om een ondertekend SAS-token te presenteren voor verificatie en registratieverificatie. X509-attestation: u gebruikt een hulpprogramma om een certificaat te genereren. Zodra het certificaat is gegenereerd, maakt u het certificaatbestand dat is vereist voor gebruik in de inschrijving. De SDK-attestation-logica gebruikt ook het certificaat tijdens de registratie om te presenteren voor verificatie en registratieverificatie.
Apparaat	Opstarten en registreren	Deze bewerking komt overeen met de derde fase van automatische inrichting, uitgevoerd door de apparaatregistratiesoftware die is gebouwd door de ontwikkelaar. Zie de rol Ontwikkelaar voor meer informatie. Bij de eerste opstartbewerking: De toepassing maakt verbinding met het Device Provisioning Service-exemplaar, volgens de globale URL en het servicebereik dat tijdens de ontwikkeling is opgegeven. Zodra het apparaat is verbonden, wordt het geverifieerd op basis van de attestation-methode en identiteit die tijdens de inschrijving is opgegeven. Nadat het is geverifieerd, wordt het apparaat geregistreerd bij het IoT Hub-exemplaar dat is opgegeven door het exemplaar van de inrichtingsservice. Na een geslaagde registratie worden een unieke apparaat-id en een IoT Hub-eindpunt geretourneerd naar de registratietoepassing voor communicatie met IoT Hub. Van daaruit kan het apparaat de eerste status van de apparaatdubbel omlaag halen voor de configuratie en het proces van het rapporteren van telemetriegegevens starten. Quickstarts: omdat het apparaat is gesimuleerd, wordt de registratiesoftware uitgevoerd op uw ontwikkelwerkstation.

Het volgende diagram bevat een overzicht van de rollen en sequentiëren van bewerkingen tijdens het automatisch inrichten van apparaten:

Notitie

Desgewenst kan de fabrikant ook de bewerking 'Apparaat-id inschrijven' uitvoeren met behulp van Device Provisioning Service-API's (in plaats van via de operator). Zie de zero touch-apparaatregistratie met Azure IoT-video (vanaf markering 41:00) voor een gedetailleerde bespreking van deze sequentiëring en meer

Rollen en Azure-accounts

Hoe elke rol wordt toegewezen aan een Azure-account is afhankelijk van scenario's en er zijn een aantal scenario's die kunnen worden betrokken. De onderstaande algemene patronen moeten een algemeen begrip bieden van de manier waarop rollen over het algemeen worden toegewezen aan een Azure-account.

Chipfabrikant biedt beveiligingsservices

In dit scenario beheert de fabrikant de beveiliging voor klanten op niveau één. Dit scenario heeft mogelijk de voorkeur voor deze klanten op niveau één, omdat ze geen gedetailleerde beveiliging hoeven te beheren.

De fabrikant introduceert beveiliging in HSM's (Hardware Security Modules). Deze beveiliging kan de fabrikant omvatten die sleutels, certificaten, enzovoort verkrijgt van potentiële klanten die al DPS-exemplaren en inschrijvingsgroepen hebben ingesteld. De fabrikant kan deze beveiligingsgegevens ook genereren voor zijn klanten.

In dit scenario zijn er mogelijk twee Azure-accounts betrokken:

• Account 1: Waarschijnlijk gedeeld tussen de operator- en ontwikkelaarsrollen. Deze partij kan de HSM-chips van de fabrikant kopen. Deze chips worden verwezen naar DPS-exemplaren die zijn gekoppeld aan het account 1. Met DPS-inschrijvingen kan deze partij apparaten leasen aan meerdere klanten op niveau twee door de instellingen voor apparaatinschrijving opnieuw te configureren in DPS. Deze partij kan ook IoT-hubs hebben toegewezen voor back-endsystemen van eindgebruikers om verbinding mee te maken om toegang te krijgen tot telemetriegegevens van apparaten, enzovoort. In dit laatste geval is mogelijk geen tweede account nodig.

• Account 2: Eindgebruikers, niveau twee klanten hebben mogelijk hun eigen IoT-hubs. De partij die is gekoppeld aan account 1, verwijst alleen geleasede apparaten naar de juiste hub in dit account. Voor deze configuratie moeten DPS- en IoT-hubs worden gekoppeld tussen Azure-accounts. Dit kan worden gedaan met Azure Resource Manager-sjablonen.

Alles-in-één OEM

De fabrikant kan een 'All-in-one OEM' zijn waarbij slechts één fabrikantaccount nodig zou zijn. De fabrikant verwerkt beveiliging en inrichting end-to-end.

De fabrikant kan een cloudtoepassing bieden aan klanten die apparaten aanschaffen. Deze toepassing zou een interface hebben met de IoT Hub die door de fabrikant is toegewezen.

Verkoopautomaten of geautomatiseerde koffiemachines vertegenwoordigen voorbeelden voor dit scenario.

Volgende stappen

Het kan handig zijn om een bladwijzer voor dit artikel te maken als referentiepunt, terwijl u door de bijbehorende snelstartgidsen voor automatisch inrichten werkt.

Begin met het voltooien van een quickstart voor het instellen van automatisch inrichten die het beste past bij uw voorkeur voor het beheerhulpprogramma, waarmee u de fase 'Serviceconfiguratie' doorloopt:

• Automatische inrichting instellen met behulp van Azure CLI
• Automatische inrichting instellen met behulp van Azure Portal
• Automatische inrichting instellen met behulp van een Resource Manager-sjabloon

Ga vervolgens verder met de quickstart 'Een apparaat inrichten' die past bij het attestation-mechanisme van uw apparaat en de SDK/taalvoorkeur van Device Provisioning Service. In deze quickstart doorloopt u de fasen 'Apparaatinschrijving' en 'Apparaatregistratie en -configuratie':

Mechanisme voor apparaatattest	Snelstart
Symmetrische sleutel	Een gesimuleerd symmetrisch sleutelapparaat inrichten
X.509-certificaat	Een gesimuleerd X.509-apparaat inrichten
Gesimuleerde Trusted Platform Module (TPM)	Een gesimuleerd TPM-apparaat inrichten