IoT-Best-Practices im Produktionsmaßstab mit AWS (Teil 1)

Dieser Beitrag gliedert sich in folgende Abschnitte:

Software- und Hardware-Setup für den Raspberry Pi
Überblick: gerätespezifische Zugangsdaten bereitstellen
Provisioning-Template und Bootstrap-Zertifikat in der Praxis anlegen
Konnektivitätstest und Streaming von Temperaturdaten
Speicherung der Streaming-Daten (siehe Teil 2)
Visualisierung der Streaming-Daten (siehe Teil 2)

Es gibt einiges zu besprechen – also los geht’s. Für diesen Artikel brauchen Sie lediglich Grundkenntnisse in Bash und Python, ein Basisverständnis der AWS-Webkonsole und eine große Tasse Kaffee, die Sie durch dieses ausführliche Walkthrough begleitet.

Software- und Hardware-Setup für den Raspberry Pi

Bringen Sie zunächst mehrere Raspberry-Pi-Geräte zum Laufen (ich verwende hier Pi 3). Für die OS-Installation auf microSD-Karten empfehle ich den Raspbian OS Imager. Sobald Sie auf dem Desktop sind und das Gerät aktualisiert haben, installieren Sie mit folgendem Befehl das AWS-IoT-spezifische SDK:

pip3 install -U awsiotsdk

Bevor wir weitermachen, lohnt sich ein genauerer Blick auf dieses Paket:

1. Warum ist das IoT-SDK vom allgemeinen boto3-SDK getrennt? Boto3 setzt auf HTTP – ein Protokoll, das sich für die schnelle Ausführung der meisten AWS-Aktionen gut eignet. Für langlebige Verbindungen mit häufig unterbrochener Konnektivität, bei denen Daten überwiegend vom Gerät weg fließen, ist HTTP allerdings nicht geeignet. MQTT, das vom IoT-SDK genutzte Protokoll, wurde gezielt für IoT-Szenarien entwickelt und macht es deutlich einfacher, dass ein Gerät trotz Verbindungsproblemen häufig Nachrichten publizieren und gelegentlich empfangen kann.

2. Das Paket "awsiotsdk" entspricht v2 des AWS IoT SDK. Es ist eine eigenständige Komponente und nicht mit dem ähnlich benannten v1-Paket "AWSIoTPythonSDK" zu verwechseln. Nahezu alle bisher veröffentlichten Walkthroughs zu AWS IoT setzen auf v1 – und v1 erschwert leider einen produktionsreifen Ansatz für die Geräteregistrierung. v2 vereinfacht zudem das Publizieren und Empfangen von Nachrichten, daher arbeiten wir mit der aktuellen Version.

Sobald die nötigen AWS-SDKs auf Ihrem Raspberry Pi installiert sind, müssen Sie einen digitalen Temperatursensor anschließen. Wenn Sie dem Artikel direkt folgen möchten, empfehle ich diesen DS18B20-Sensor.

Für den Anschluss an den Raspberry Pi benötigen Sie außerdem:

Mini-Breadboards

Breadboard-Jumperkabel

Sortiertes Widerstands-Kit (wir brauchen einen 4,7-kOhm-Widerstand)

Falls Sie ein paar Tage auf die Lieferung warten müssen, können Sie im Artikel ruhig weitermachen – wir stellen auch ein Skript bereit, das simulierte Temperaturwerte streamt. Wenn Sie die Komponenten haben, zeigt Ihnen das folgende Tutorial in den ersten fünf Minuten, wie Sie den Sensor an den Raspberry Pi anschließen und prüfen, ob er Temperaturwerte liefert:

Raspberry Pi DS18B20 Temperature Sensor Tutorial

Ergänzend zum dort beschriebenen Vorgehen empfehle ich, Folgendes in /etc/modules einzutragen, damit die OneWire-Module beim Booten geladen werden und Sie nicht nach jedem Reboot modprobe ausführen müssen:

w1-gpio
w1-therm

Überblick: gerätespezifische Zugangsdaten bereitstellen

Die meisten verfügbaren AWS-IoT-Blogposts nutzen v1 des IoT-SDK und führen ein Spielzeugbeispiel vor, in dem ein einzelnes Gerät in einem Cloud-Konto registriert wird. Üblicherweise wird ein Zertifikat samt zugehöriger AWS-IoT-Berechtigungen erstellt, anschließend werden die Zertifikatsdateien auf dem Gerät abgelegt, sodass dieses IoT-API-Aufrufe absetzen und Daten in die Cloud streamen kann.

Solche Beispiele sind allerdings wenig praxistauglich, denn reale IoT-Szenarien umfassen Tausende bis Millionen Geräte, die in eine Cloud-Umgebung streamen. Jedes Gerät einer solchen Flotte sollte eigene Zugangsdaten bekommen. Wird ein Gerät oder dessen AWS-Credentials kompromittiert und missbraucht (etwa um gefälschte Daten in Ihre Plattform einzuschleusen), lassen sich diese Credentials gezielt deaktivieren, ohne andere Geräte der Flotte zu beeinträchtigen.

Wie lässt sich die Vergabe gerätespezifischer Credentials möglichst einfach umsetzen? Geht das auch, ohne im Voraus Millionen Zertifikate zu erzeugen und während der Fertigung jedem Gerät individuell zuzuordnen? Oder ohne dass der Hersteller bei jedem Gerät, das vom Band läuft, per API-Aufruf in Ihrer Umgebung ein neues Zertifikat anfordern muss? Diese Verfahren sollten Sie meiden – sie sind komplex, fehleranfällig und bürden dem Hersteller unnötigen Aufwand auf.

Glücklicherweise gibt es eine einfache Lösung, die sich mit v2 des IoT-SDK noch leichter umsetzen lässt. Die großflächige Vergabe gerätespezifischer Credentials gelingt, indem Sie zwei Komponenten in der AWS-IoT-Konsole anlegen: (1) ein Fleet-Provisioning-Template und (2) ein Bootstrap-Zertifikat, das auf allen Geräten installiert wird. Der folgende Workflow erläutert das Vorgehen:

Es wird ein einzelnes IoT-Zertifikat erstellt, das auf allen IoT-Geräten installiert wird. Dieses sogenannte "Bootstrap"-Zertifikat ist mit einer Berechtigungsrichtlinie verknüpft, die einem Gerät ausschließlich erlaubt, (a) ein gerätespezifisches Zertifikat anzufordern und – bei Genehmigung – die zugehörigen Credentials abzurufen sowie (b) sich selbst in das IoT-Geräte-Registry einzutragen. Optional kann der Request einen eindeutigen Bezeichner für das Gerät enthalten, etwa eine Seriennummer.
Sobald die AWS-IoT-Plattform den Request zur Zertifikatserstellung erhält, generiert sie ein neues Zertifikat und liefert die zugehörigen Dateien an das Gerät aus. Welche IoT-Berechtigungen jedes neue Zertifikat erhält und welche Attribute mit dem neu registrierten Gerät verknüpft werden, basiert auf einer Vorlage, die Sie selbst anlegen – AWS bezeichnet sie als "Fleet Provisioning Template".

Diese Vorlage weist neu registrierten Geräten Attribute zu, beispielsweise {"DeviceType": "RaspberryPi"}, und ermöglicht es zusätzlich, alle gerätespezifischen Zertifikate mit derselben Berechtigungsrichtlinie zu verknüpfen, die dennoch gerätespezifische Berechtigungen abbilden kann.

So lässt sich etwa die einzelne IoT-Policy einer Vorlage so gestalten, dass das Gerät "sensor123" Nachrichten ausschließlich an das IoT-Topic sensors/temp/sensor123 publizieren darf, "sensor456" nur an sensors/temp/sensor456 und so weiter. Anders gesagt: Mit der Berechtigungsrichtlinie des Fleet-Provisioning-Templates müssen Sie nicht für jedes neue Gerät und Zertifikat eine eigene Policy erstellen. Dieser Ansatz erlaubt es zudem, Berechtigungsänderungen über ein einziges Policy-Update auf eine ganze IoT-Flotte auszurollen. 3. Die Erstellung eines Geräte-Zertifikats lässt sich optional über einen sogenannten "Pre-Provisioning Hook" absichern. Dabei handelt es sich um eine selbst geschriebene Lambda-Funktion, die im Zertifikats-Request einen eindeutigen Bezeichner verlangen kann – etwa um ihn gegen eine Whitelist (z. B. eine Liste aller produzierten Seriennummern) und/oder eine Blacklist (z. B. Seriennummern kompromittierter oder missbräuchlich genutzter Geräte) abzugleichen. 4. Wird der Request genehmigt, werden die Zertifikatsdateien an das Gerät ausgeliefert und für das Daten-Streaming genutzt. Das Gerät wird mit den Attributen der Vorlage in das IoT-Registry eingetragen. Das Bootstrap-Zertifikat braucht das Gerät danach nicht mehr.

Mit diesem Workflow muss ein IoT-Gerätehersteller jedem Gerät lediglich das Bootstrap-Zertifikat mitgeben. Das gerätespezifische Zertifikat für das Daten-Streaming kann auf Wunsch direkt im Werk erzeugt und abgerufen werden – oder erst später, wenn das Gerät beim Endanwender ist. Unabhängig davon, wann die Credentials beschafft werden, würde der Hersteller Ihre Software auf das Gerät spielen, die bei jedem Boot – sobald eine Internetverbindung verfügbar ist und kein Geräte-Zertifikat vorhanden ist – den auf dem Fleet-Provisioning-Template basierenden Zertifikatsprozess ausführt.

Praxisbeispiel: Fleet-Provisioning-Template und Bootstrap-Zertifikat im Einsatz

Ich weiß – das war jede Menge Stoff. Sobald Sie den Prozess selbst umsetzen, wird vieles deutlich klarer.

Im Folgenden zeigen wir ein vollständiges, lauffähiges Beispiel, wie Sie Ihr IoT-Registry mit Geräten aufbauen, die per Fleet-Provisioning-Template und Bootstrap-Zertifikat hinzugefügt werden. Anschließend nutzen wir die erzeugten Geräte-Zertifikate, um Temperaturdaten an die AWS-IoT-Plattform zu streamen.

Wechseln Sie zunächst zum Service AWS IoT Core. Falls Sie diesen noch nicht genutzt haben, empfängt Sie eine Wizard-Seite mit den Optionen "Onboard a device" oder "Onboard many devices". Über diesen Wizard kommen wir zwar zum Fleet-Provisioning-Template-Prozess, doch wegen einer Eigenheit des Wizards verlassen wir diese Seite zunächst und legen erst das Bootstrap-Zertifikat an.

Navigieren Sie auf der linken Seite zu Secure → Certificates und klicken Sie auf "Create", anschließend auf "One-click certificate creation". Damit wird sofort ein neues Zertifikat erzeugt, das wir als Bootstrap-Zertifikat verwenden. Laden Sie unbedingt das Zertifikat (cert.pem), den privaten Schlüssel (private.key) sowie die Root-Zertifizierungsstelle herunter (folgen Sie dem Download-Link und speichern Sie die Datei AmazonRootCA1.pem). Klicken Sie anschließend auf "Activate", um das Zertifikat zu aktivieren:

Sobald das Zertifikat aktiviert und die Schlüssel heruntergeladen sind, klicken Sie auf "Attach a policy". Wir legen nun eine Policy an, die aus diesem Zertifikat ein Bootstrap-Zertifikat macht. Klicken Sie im Bildschirm "Add authorization to certificate" auf "Create New Policy" und legen Sie eine Policy mit dem Namen "IoT_Bootstrapping_Certificate" an. Diese Policy bekommt Berechtigungen, um Nachrichten an zwei von AWS reservierte Topics zu publizieren, zu abonnieren und von dort zu empfangen, die für die Zertifikatserstellung und das Fleet-Provisioning-Template verwendet werden:

Achten Sie darauf, Region, Account-ID und templateName durch die für Ihren Account passenden Werte zu ersetzen.

Action: iot:Connect
Resource ARN: *Action: iot:Publish
Action: iot:Receive
Resource ARN: arn:aws:iot:us-west-2:123456789012:topic/$aws/certificates/create/*Action: iot:Publish
Action: iot:Receive
Resource ARN: arn:aws:iot:us-west-2:123456789012:topic/$aws/provisioning-templates/SensorTemplate/provision/*Action: iot:Subscribe
Resource ARN: arn:aws:iot:us-west-2:123456789012:topicfilter/$aws/certificates/create/*Action: iot:Subscribe
Resource ARN: arn:aws:iot:us-west-2:123456789012:topicfilter/$aws/provisioning-templates/SensorTemplate/provision/*

Klicken Sie auf "Create". Sobald die Zertifikats-Policy angelegt ist, navigieren Sie zu dem zuvor erstellten Zertifikat und hängen die Policy an:

Da unser Bootstrap-Zertifikat nun für die Geräte bereitsteht, kehren wir zum Fleet-Provisioning-Template-Wizard zurück. Sie erreichen ihn über Onboard → Get started.

Wählen Sie im Wizard "Onboard many devices" und tragen Sie Folgendes ein:

Template name: "SensorTemplate"
Provisioning role: Legen Sie eine Rolle namens "IoTProvisioningRole" an und verknüpfen Sie sie mit der von AWS verwalteten Policy "AWSIoTThingsRegistration". Diese Rolle erlaubt der AWS-IoT-Plattform, neue Geräte beim Verbinden zu registrieren.
In einem realen Szenario würden Sie eine Pre-Provisioning-Hook-Lambda-Funktion schreiben, die eine Seriennummer prüft, bevor die Erstellung eines Geräte-Zertifikats erlaubt wird – der Kürze halber lassen wir diese Option hier außen vor. Damit ließe sich beispielsweise eine Seriennummer gegen DynamoDB-Tabellen mit gesperrten und bekannten Seriennummern abgleichen. Ein einfaches Beispiel sieht so aus:

def lambda_handler(event, context):
    serial = event["parameters"]["SerialNumber"]    # Implement serial number validation functions
    if is_valid_serial(serial) and not is_blacklisted(serial):
        return {"allowProvisioning": True}    return {"allowProvisioning": False}

Aktivieren Sie die optionale Einstellung "Use the AWS IoT registry to manage your device fleet". Damit können Sie zugehörige Geräte in der IoT-Webkonsole einsehen und Updates für deren Status oder Software ausspielen.

Auf der nächsten Seite definieren wir eine IoT-Policy, die mit der Vorlage verknüpft ist und unseren Geräten erlaubt, Nachrichten an ein gerätespezifisches IoT-Topic zu publizieren bzw. von dort zu empfangen. Wir erstellen die IoT-Policy mit einer Thing-Policy-Variable. Diese erlaubt es Geräten, auf einem für sie eindeutigen IoT-Topic zu publizieren oder Nachrichten zu empfangen. In unserem Beispiel publizieren und abonnieren die Geräte ein Topic, das auf BuildingName, Location (innerhalb des Gebäudes) und ThingName basiert:

Action: iot:Connect
Resource ARN: arn:aws:iot:us-west-2:123456789012:client/${iot:Connection.Thing.ThingName}

Action: iot:Publish
Action: iot:Receive
Resource ARN: arn:aws:iot:us-west-2:123456789012:topic/temperature/${iot:Connection.Thing.Attributes[BuildingName]}/${iot:Connection.Thing.Attributes[Location]}/${iot:Connection.Thing.ThingName}

Action: iot:Subscribe
Resource ARN: arn:aws:iot:us-west-2:123456789012:topicfilter/temperature/${iot:Connection.Thing.Attributes[BuildingName]}/${iot:Connection.Thing.Attributes[Location]}/${iot:Connection.Thing.ThingName}

Definieren Sie auf der nächsten Seite Ihre AWS-IoT-Registry-Einstellungen – das sind die Attribute, die jedem neu provisionierten Gerät zugewiesen werden:

Thing name prefix: sensor_
Legen Sie einen neuen Thing Type "TemperatureSensor" an, mit den durchsuchbaren Thing-Attributen "Location" (z. B. "loft", "downstairs") und "BuildingName" (z. B. "home417").
Erstellen Sie folgende nicht durchsuchbare Thing-Attribute: "DeviceType" (z. B. "RaspberryPi") und "ModelNumber" (z. B. "3").

Wählen Sie im letzten Bildschirm nach dem Klick auf "Create template" das zuvor angelegte Bootstrap-Zertifikat aus, klicken Sie auf "Attach policy" und anschließend auf "Enable template". Damit erhalten Geräte mit dem Bootstrap-Zertifikat über diese Vorlage ein Geräte-Zertifikat mit den nötigen Berechtigungen, um Nachrichten an ein gerätespezifisches IoT-Topic zu publizieren. Zusätzlich nutzt das Gerät das Fleet-Provisioning-Template, um sich selbst in das IoT-Registry einzutragen und die definierten Attribute zu erhalten.

Kurz zusammengefasst – das haben wir gerade umgesetzt:

Erstellung eines Bootstrap-Zertifikats, verknüpft mit einer Policy, die einem Gerät mit diesem Zertifikat ausschließlich erlaubt, über ein Fleet-Provisioning-Template (1) ein neues, gerätespezifisches Zertifikat anzufordern und (2) sich mit Standard-Attributen ins IoT-Registry einzutragen.
Die Geräte-Zertifikate für neu registrierte Geräte sind mit einer IoT-Policy verknüpft, die dem Gerät erlaubt, Nachrichten an ein für dieses Gerät spezifisches IoT-Topic zu publizieren bzw. von dort zu empfangen.

Mit der Vorbereitung im IoT-Service sind wir fast fertig. Es bleibt nur noch, das Fleet-Provisioning-Template so zu aktualisieren, dass es die durchsuchbaren Attribute beim Provisioning-Request akzeptiert und verlangt. Wechseln Sie zurück zu "SensorTemplate" und ergänzen Sie das Template-JSON wie folgt:

# Add "BuildingName" and "Location" within "Parameters"
{
  "Parameters": {
    "SerialNumber": {
      "Type": "String"
    },
    "BuildingName": {
      "Type": "String"
    },
    "Location": {
      "Type": "String"
    },
    "AWS::IoT::Certificate::Id": {
      "Type": "String"
    }
  }
}# Reference these attribute parameters within "thing": "Properties"
      "Properties": {
        "AttributePayload": {
          "DeviceType": "RaspberryPi",
          "ModelNumber": "3",
          "BuildingName": {
            "Ref": "BuildingName"
          },
          "Location": {
            "Ref": "Location"
          }
        },
        "ThingGroups": [],

In der IoT-Konsole haben wir einiges geändert. Prüfen wir nun mit konkreten Codebeispielen, ob Bootstrap-Zertifikat und Fleet-Provisioning-Template wie gewünscht funktionieren.

Konnektivitätstest und Streaming der Temperaturdaten

Kopieren Sie die heruntergeladenen Zertifikatsdateien in einen Ordner auf Ihren RPi-Geräten und legen Sie anschließend die unten gezeigte Datei config.ini mit den passenden Werten an. Neben den Pfaden zu den Zertifikatsdateien benötigen Sie den IoT-Endpoint Ihres Accounts, den Sie auf der Settings-Seite in der AWS-IoT-Konsole finden:

# Set the path to the location containing your bootstrap certificates (root, private, claim certificate)
SECURE_CERT_PATH = /home/pi/iot_certs/

# Specify the names for the root cert, provisioning claim cert, and the private key.
ROOT_CERT = AmazonRootCA1.pem
CLAIM_CERT = <YOURCERT>-certificate.pem.crt
SECURE_KEY = <YOURCERT>-private.pem.key

# Set the name of your IoT Endpoint
IOT_ENDPOINT = <YOUR_ENDPOINT>-ats.iot.us-west-2.amazonaws.com

# Set the IoT topic name
IOT_TOPIC = temperature/${iot:Connection.Thing.Attributes[BuildingName]}/${iot:Connection.Thing.Attributes[Location]}/${iot:Connection.Thing.ThingName}

# Set the IoT provisioning template name
PROVISIONING_TEMPLATE_NAME = SensorTemplate

Führen Sie anschließend das folgende Skript aus, das mit Ihrem Bootstrap-Zertifikat ein Geräte-Zertifikat anfordert (gespeichert in iot_certs/permanent_cert/) und das Gerät dem IoT-Registry hinzufügt. Über den Parameter -l legen Sie das Location-Attribut fest, das angibt, wo sich das Gerät bei Ihnen zu Hause befinden wird. Beispiel:

./connect_rpi_to_iot_core.py -c config.ini -b home417 -l loft

Hier passiert eine Menge – nehmen Sie sich daher unbedingt die Zeit, den Code durchzugehen und den Ablauf der IoT-SDK-API-Aufrufe nachzuvollziehen. Wenn alles korrekt eingerichtet ist, sehen Sie nach Ausführung des Skripts "Success" auf dem Bildschirm, drei Zertifikatsdateien in permanent_cert/ sowie eine neue perm_config.ini in diesem Ordner für die Zertifikatsdateien des Geräts.

Wenn Sie Ihre RPi-Geräte mit diesem Skript hinzufügen, erscheinen neue Zertifikate in der IoT-Konsole. Alle sind mit der einen IoT-Policy verknüpft, die wir im Fleet-Provisioning-Template definiert haben und die das Publizieren und Abonnieren von Nachrichten auf einem auf BuildingName, Location und ThingName basierenden Topic erlaubt.

Jedes über das Skript hinzugefügte Gerät wird mit dem ThingName sensor_{UUID} registriert, wobei UUID ein eindeutiger Bezeichner aus /etc/machine-id auf dem Gerät ist. So publiziert jedes Gerät Nachrichten an sein eigenes, eindeutiges IoT-Topic. In einem realen IoT-Szenario würden Sie als ThingName häufig die Seriennummer des Geräts verwenden.

Testen wir nun unsere Geräte-Zertifikate mit simulierten Temperaturwerten. Führen Sie das folgende Skript aus, das (1) Zufallswerte an das IoT-Topic des Geräts publiziert und (2) dasselbe Topic abonniert und die Werte zurückgibt.

./pubsub_simulated_temps.py -c /home/pi/iot_certs/permanent_cert/perm_config.ini

Sie sollten eine Ausgabe ähnlich dieser sehen:

Glückwunsch – Sie haben gerade erfolgreich eine kleine Flotte von IoT-Geräten nach der AWS-Methodik onboardet, die diesen Registrierungsprozess sicher und im großen Maßstab abbildet.

Um Ihre Verbindungen mit echten Daten zu testen, führen Sie das folgende Skript aus. Es ähnelt dem vorigen, mit dem Unterschied, dass es (1) das Topic, an das es publiziert, nicht abonniert und (2) alle fünf Sekunden echte Temperaturwerte sendet:

./publish_temps.py -c /home/pi/iot_certs/permanent_cert/perm_config.ini

Die Ausgabe sollte folgendermaßen aussehen:

Wenn Sie dieses Skript per Crontab beim Reboot automatisch starten (mit vorgeschaltetem 30-Sekunden-Sleep, damit die OneWire-Module beim Booten geladen werden), nimmt Ihr IoT-Gerät auch nach einem (un)geplanten Neustart das Streaming wieder auf:

$ crontab -e
@reboot sleep 30 && /home/pi/publish_temps.py -c /home/pi/iot_certs/permanent_cert/perm_config.ini

Wiederholen Sie das Onboarding und Streaming für alle Raspberry-Pi-Geräte, die Sie bei sich zu Hause platzieren. Damit sind Sie auf einem guten Weg, mit IoT-Daten im großen Maßstab zu arbeiten.

Als Nächstes: Speicherung und Visualisierung

Bleiben Sie dran für Teil 2, in dem ich die korrekte Speicherung und Visualisierung großvolumiger IoT-Streaming-Daten behandle.

Hinweis

Der oben gezeigte Pub/Sub-Ansatz für das Publizieren von Nachrichten eignet sich am besten für Geräte-Telemetrie, bei der die gestreamten Daten nicht nur von einer Backend-Analytics-Anwendung, sondern auch direkt von Endanwendern genutzt werden – etwa über eine App, mit der Nutzer die Temperaturwerte für ihr Zuhause einsehen. Werden die Streaming-Daten ausschließlich von einer Backend-Anwendung verwendet, ist es kostengünstiger, Nachrichten über den Ansatz "IoT Basic Ingest" zu publizieren, wie im Whitepaper "AWS IoT Core Best Practices for Designing MQTT Topics" beschrieben. Wenn Sie Nachrichten an ein Topic senden, das mit einer IoT Rule verknüpft ist – statt an ein generisches IoT-Core-Topic –, verlieren Sie zwar die Möglichkeit, das Topic zu abonnieren, müssen dafür aber den Messaging-Anteil der IoT-Preise nicht bezahlen.