Freigeben über

Rollen und Vorgänge

Die Phasen der Entwicklung einer IoT-Lösung können wochen- oder monatelang dauern, aufgrund von Produktionsrealitäten wie Herstellungszeit, Versand, Zollprozess usw. Darüber hinaus können sie Aktivitäten über mehrere Rollen hinweg umfassen, da die verschiedenen beteiligten Entitäten beteiligt sind. In diesem Artikel werden die verschiedenen Rollen und Vorgänge im Zusammenhang mit den einzelnen Phasen genauer betrachtet. Anschließend wird der Fluss in einem Sequenzdiagramm veranschaulicht.

Die Bereitstellung stellt auch Anforderungen an den Gerätehersteller, um den Bestätigungsmechanismus zu aktivieren. Fertigungsvorgänge können auch unabhängig vom Zeitpunkt der automatischen Bereitstellungsphase auftreten, insbesondere in Fällen, in denen neue Geräte nach der automatischen Bereitstellung bereits hergestellt werden.

Im Inhaltsverzeichnis auf der linken Seite finden Sie eine Reihe von Schnellstarts, um die automatische Bereitstellung durch praktische Erfahrungen zu verdeutlichen. Um den Lernprozess zu erleichtern, wird Software verwendet, um ein physisches Gerät für die Einschreibung und Registrierung zu simulieren. Einige Schnellstarts erfordern, dass Sie Vorgänge für mehrere Rollen erfüllen, einschließlich Vorgänge für nicht vorhandene Rollen aufgrund der simulierten Natur der Schnellstarts.

Rolle Operation Description
Hersteller Codieren von Identitäts- und Registrierungs-URL Basierend auf dem verwendeten Nachweismechanismus ist der Hersteller für die Codierung der Geräteidentitätsinformationen und der Registrierungs-URL des Gerätebereitstellungsdiensts verantwortlich.

Schnellstarts: Da das Gerät simuliert wird, gibt es keine Herstellerrolle. Ausführliche Informationen dazu, wie Sie diese Informationen erhalten, die beim Codieren einer Beispielregistrierungsanwendung verwendet werden, finden Sie in der Entwicklerrolle.
Bereitstellen der Geräteidentität Als Absender der Geräteidentitätsinformationen ist der Hersteller dafür verantwortlich, ihn an den Betreiber (oder einen bestimmten Agent) zu übermitteln oder ihn über APIs direkt beim Gerätebereitstellungsdienst zu registrieren.

Schnellstarts: Da das Gerät simuliert wird, gibt es keine Herstellerrolle. Ausführliche Informationen dazu, wie Sie die Geräteidentität abrufen, die zum Registrieren eines simulierten Geräts in Ihrer Device Provisioning Service-Instanz verwendet wird, finden Sie in der Rolle "Operator".
Bediener Konfigurieren der automatischen Bereitstellung Dieser Vorgang entspricht der ersten Phase der automatischen Bereitstellung.

Schnellstarts: Sie spielen die Rolle des Operators, konfigurieren die Instanzen des Gerätebereitstellungsdiensts und des IoT Hub in Ihrem Azure-Abonnement.
Registrieren der Geräteidentität Dieser Vorgang entspricht der zweiten Phase der automatischen Bereitstellung.

Schnellstarts: Sie führen die Rolle „Operator“ aus und registrieren Ihr simuliertes Gerät in Ihrer Instanz des Device Provisioning-Diensts. Die im Schnellstart (TPM oder X.509) simulierte Nachweismethode bestimmt die Geräteidentität. Details zur Attestierung finden Sie in der Entwicklerrolle.
Gerätebereitstellungsdienst,
IoT Hub		 <alle Vorgänge> Für eine Produktionsimplementierung mit physischen Geräten und Schnellstarts mit simulierten Geräten werden diese Rollen über die IoT-Dienste erfüllt, die Sie in Ihrem Azure-Abonnement konfigurieren. Die Rollen/Vorgänge funktionieren genau so, wie die IoT-Dienste der Bereitstellung physischer und simulierter Geräte gleichgültig sind.
Developer Erstellen/Bereitstellen von Registrierungssoftware Dieser Vorgang entspricht der dritten Phase der automatischen Bereitstellung. Der Entwickler ist für das Erstellen und Bereitstellen der Registrierungssoftware auf dem Gerät verantwortlich, wobei das entsprechende SDK verwendet wird.

Schnellstarts: Die Beispielregistrierungsanwendung, die Sie erstellen, simuliert ein echtes Gerät für Ihre Plattform/Sprache, die auf Ihrer Arbeitsstation ausgeführt wird (anstatt sie auf einem physischen Gerät bereitzustellen). Die Registrierungsanwendung führt dieselben Vorgänge aus wie eine, die auf einem physischen Gerät bereitgestellt wird. Sie geben die Nachweismethode (TPM- oder X.509-Zertifikat) sowie die Registrierungs-URL und den "ID-Bereich" Ihrer Device Provisioning Service-Instanz an. Die SDK-Nachweislogik zur Laufzeit bestimmt die Geräteidentität basierend auf der von Ihnen angegebenen Methode:
  • TPM-Nachweis – Ihre Entwicklungsarbeitsstation führt eine TPM-Simulatoranwendung aus. Nach der Inbetriebnahme wird eine separate Anwendung verwendet, um den "Endorsement-Key" und die "Registrierungs-ID" des TPM zum Registrieren der Geräteidentität zu extrahieren. Die SDK-Nachweislogik verwendet auch den Simulator während der Registrierung, um ein signiertes SAS-Token für die Authentifizierungs- und Registrierungsüberprüfung darzustellen.
  • X509-Nachweis – Sie verwenden ein Tool, um ein Zertifikat zu generieren. Nach der Erstellung erstellen Sie die Zertifikatdatei, die für die Verwendung bei der Registrierung erforderlich ist. Die SDK-Attestierungslogik verwendet das Zertifikat auch während der Registrierung, um es für die Authentifizierung und Überprüfung der Registrierung vorzulegen.
Device Starten und registrieren Dieser Vorgang entspricht der dritten Phase der automatischen Bereitstellung, die von der vom Entwickler erstellten Geräteregistrierungssoftware erfüllt wird. Weitere Informationen zur Entwicklerrolle finden Sie dort. Beim ersten Start:
  1. Die Anwendung verbindet sich mit der Device Provisioning Service-Instanz über die globale URL und den während der Entwicklung angegebenen Dienst "ID Scope."
  2. Nach der Verbindung wird das Gerät mit der während der Registrierung angegebenen Nachweismethode und identität authentifiziert.
  3. Nach der Authentifizierung wird das Gerät mit der ioT Hub-Instanz registriert, die von der Bereitstellungsdienstinstanz angegeben wird.
  4. Nach erfolgreicher Registrierung werden eine eindeutige Geräte-ID und ein IoT Hub-Endpunkt an die Registrierungsanwendung für die Kommunikation mit IoT Hub zurückgegeben.
  5. Von dort aus kann das Gerät seinen ersten Geräte-Zwilling-Zustand für die Konfiguration abrufen und mit dem Übertragen von Telemetriedaten beginnen.
Schnellstarts: Da das Gerät simuliert wird, wird die Registrierungssoftware auf Ihrer Entwicklungsarbeitsstation ausgeführt.

Das folgende Diagramm fasst die Rollen und Sequenzierung von Vorgängen während der geräte automatischen Bereitstellung zusammen:

Sequenzdiagramm, das die Rollen und Sequenzierung von Vorgängen während der automatischen Bereitstellung des Geräts zeigt.

Hinweis

Optional kann der Hersteller auch den Vorgang "Geräteidentität registrieren" mithilfe von Gerätebereitstellungsdienst-APIs (statt über den Operator) ausführen. Eine ausführliche Erläuterung dieser Sequenzierung und mehr finden Sie in der Zero Touch-Geräteregistrierung mit Azure IoT-Video (beginnend bei Marker 41:00)

Rollen und Azure-Konten

Wie jede Rolle einem Azure-Konto zugeordnet ist, ist szenarioabhängig, und es gibt einige Szenarien, die einbezogen werden können. Die folgenden allgemeinen Muster sollten ein allgemeines Verständnis dafür bieten, wie Rollen einem Azure-Konto zugeordnet werden.

Chiphersteller bietet Sicherheitsdienstleistungen an

In diesem Szenario verwaltet der Hersteller die Sicherheit für Kunden auf Ebene 1. Dieses Szenario ist für diese Kunden auf Ebene 1 vorzuziehen, da sie keine detaillierte Sicherheit verwalten müssen.

Der Hersteller führt Sicherheit in Hardware Security Modules (HSMs) ein. Diese Sicherheit kann den Hersteller umfassen, der Schlüssel, Zertifikate usw. von potenziellen Kunden erhält, die bereits über DPS-Instanzen und Registrierungsgruppen verfügen. Der Hersteller könnte diese Sicherheitsinformationen auch für seine Kunden generieren.

In diesem Szenario sind möglicherweise zwei Azure-Konten beteiligt:

  • Konto Nr. 1: Wahrscheinlich über die Operator- und Entwicklerrollen hinweg geteilt. Diese Partei kann die HSM-Chips vom Hersteller kaufen. Diese Chips werden auf DPS-Instanzen verwiesen, die dem Account #1 zugeordnet sind. Mit DPS-Registrierungen kann diese Partei Geräte an mehrere Zwei-Ebenen-Kunden leasen, indem sie die Geräteregistrierungseinstellungen in DPS neu konfigurieren. Diese Partei könnte auch IoT-Hubs für Endbenutzer-Backend-Systeme haben, um mit ihnen Schnittstellen zu bilden und auf Gerätetelemetrie zuzugreifen. In diesem Fall wäre ein zweites Konto möglicherweise nicht erforderlich.

  • Konto Nr. 2: Endbenutzer, Zwei-Level-Kunden verfügen möglicherweise über eigene IoT-Hubs. Der Konto 1 zugeordnete Beteiligte verweist lediglich gemietete Geräte auf den richtigen Hub in diesem Konto. Diese Konfiguration erfordert das Verknüpfen von DPS und IoT-Hubs über Azure-Konten hinweg, was mit Azure Resource Manager-Vorlagen erfolgen kann.

All-in-One-OEM

Der Hersteller könnte ein "All-in-One-OEM" sein, bei dem nur ein einziges Herstellerkonto erforderlich wäre. Der Hersteller übernimmt die Sicherheit und Bereitstellung von Anfang bis Ende.

Der Hersteller könnte Kunden, die Geräte kaufen, eine cloudbasierte Anwendung bereitstellen. Diese Anwendung würde mit dem vom Hersteller zugewiesenen IoT-Hub verknüpft werden.

Verkaufsautomaten oder automatisierte Kaffeemaschinen stellen Beispiele für dieses Szenario dar.

Nächste Schritte

Möglicherweise ist es hilfreich, diesen Artikel zu Referenzzwecken mit einem Lesezeichen zu versehen, während Sie die entsprechenden Schnellstarts für die automatische Bereitstellung durcharbeiten.

Beginnen Sie mit einem Schnellstart zum Einrichten der automatischen Bereitstellung, der am besten zu Ihrem Verwaltungstool passt und Sie durch die Phase „Dienstkonfiguration“ führt:

Fahren Sie dann mit einem Schnellstart zur Bereitstellung eines Geräts fort, der für Ihren Gerätebestätigungsmechanismus und das SDK Ihres Device Provisioning-Diensts sowie Ihre Spracheinstellung geeignet ist. In dieser Schnellstartanleitung führen Sie die Phasen "Geräteregistrierung" und "Geräteregistrierung und Konfiguration" durch:

Gerätebescheinigungsmechanismus Schnellstart
Symmetrischer Schlüssel Bereitstellen eines simulierten symmetrischen Schlüsselgeräts
X.509 certificate Bereitstellen eines simulierten X.509-Geräts
Simuliertes Trusted Platform Module (TPM) Bereitstellen eines simulierten TPM-Geräts
  • Last updated on