Ein IoT-Board lässt sich in Stunden auswählen; die Entscheidung für dessen SDK, Updateverfahren und Lieferanten bindet den Betrieb oft jahrelang. Meine Position ist unbequem: Für produktive Geräte ist ein langsamerer, nachvollziehbarer Release-Prozess wertvoller als ein Framework, mit dem das erste Demo schneller läuft. Wer die Betriebsfähigkeit eines Anbieters prüfen soll, braucht deshalb keine weitere Feature-Matrix, sondern einen Test auf Austauschbarkeit und kontrollierte Fehler.
Ein Anbieter ist erst dann geeignet, wenn sein Updatepfad einen Ausfall übersteht
Ich lese Warum dein erstes IoT Board mehr Pflege als Code frisst mit Vorbehalt: Pflegeaufwand ist für DevOps nicht die eigentliche Prüfgröße, weil auch ein wartungsintensives System beherrschbar sein kann, solange Updates und Rückwege zuverlässig funktionieren. Die entscheidende Frage an den Vendor lautet: Was passiert, wenn während eines Firmware-Updates Strom oder Netzverbindung ausfallen?
Fordern Sie dafür eine vorführbare Antwort statt einer Folie. Ein Anbieter sollte erklären können, ob sein Bootloader zwei Firmware-Slots nutzt, wann ein neuer Slot als gültig markiert wird und wie das Gerät nach einem fehlgeschlagenen Start auf die vorige Version zurückfällt. Bei ESP-IDF sind OTA-Partitionen und die Rollback-Funktionen des Bootloaders konkrete Prüfpunkte; bei Mender ist es die Kombination aus Update-Modul, Commit und automatischem Rollback. Beides ist nur dann ein Vorteil, wenn die gewählte Board-Partitionierung tatsächlich Platz für zwei Images lässt.
Setzen Sie für einen Labortest beispielsweise 20 absichtlich unterbrochene Updates als selbst gewählten Prüfwert an: Trennen Sie Strom und Netzwerk an unterschiedlichen Stellen und erfassen Sie, ob das Gerät wieder erreichbar wird. Das ist keine Aussage über eine allgemeine Ausfallrate, sondern ein reproduzierbarer Freigabetest. Ein bloßes „OTA unterstützt“ genügt nicht, weil OTA auch bedeuten kann, dass ein fehlgeschriebener Flash nur noch über einen physischen Programmieradapter repariert werden kann.
Verlangen Sie außerdem eine signierte Firmware und lassen Sie sich den Prüfpunkt zeigen. Ein SHA-256-Hash erkennt eine veränderte Datei, beweist aber ohne vertrauenswürdige Signatur nicht, wer sie veröffentlicht hat. OpenSSL kann eine RSA-Signatur eines bereitgestellten Images vor dem Rollout prüfen; der öffentliche Schlüssel muss dabei aus einem kontrollierten Kanal stammen und nicht neben dem Image aus derselben ungeschützten Quelle. Das folgende Skript läuft mit Bash und OpenSSL, sobald die drei Dateipfade als Umgebungsvariablen gesetzt sind:
#!/usr/bin/env bash
set -euo pipefail
: "${FW_IMAGE:?Pfad zum Image fehlt}"
: "${FW_SIG:?Pfad zur Signatur fehlt}"
: "${FW_PUBKEY:?Pfad zum RSA-Public-Key fehlt}"
sha256sum "$FW_IMAGE"
openssl dgst -sha256 -verify "$FW_PUBKEY" \
-signature "$FW_SIG" "$FW_IMAGE"
echo "Firmware-Signatur gültig"
Diese Prüfung ersetzt keine Signaturkontrolle im Bootloader, weil ein Angreifer sonst die Übertragung nach der CI-Prüfung verändern könnte. Sie trennt aber zwei Fehlerklassen: Die Pipeline verwirft ein falsch signiertes Artefakt, während Secure Boot am Gerät das tatsächlich gestartete Image absichert. Fragen Sie den Anbieter, wer Schlüssel erzeugt, rotiert und bei Verlust sperrt. Bleibt die Antwort beim Wort „verschlüsselt“ stehen, würde ich die Lösung nicht freigeben, weil Verschlüsselung allein weder die Herkunft eines Updates noch einen funktionierenden Widerrufsweg belegt.
Die Bibliothek verdient Vertrauen erst nach einem erzwungenen Versionswechsel
Ein SDK wirkt stabil, solange alle Geräte dieselbe Firmware und alle Entwickler denselben Laptop benutzen. Für die Auswahl zählt deshalb nicht, ob ein Beispielprojekt kompiliert, sondern ob ein älterer Gerätestand mit einer neuen Backend-Version weiterarbeitet. Testen Sie das mit einem Gerät auf der derzeit freigegebenen Firmware, einem zweiten auf dem Release-Kandidaten und einem Backend, das Sie unabhängig aktualisieren. Diese kleine Versionsmatrix deckt Kopplungen auf, die ein Happy-Path-Test mit nur einer Version nicht sehen kann.
Ich halte Mikrocontroller und Boards richtig auswaehlen und nutzen für einen sinnvollen Ausgangspunkt, widerspreche aber der impliziten Priorität der Boardwahl: Im Betrieb entscheidet die Dauer der Softwarepflege häufiger über die Nutzbarkeit, weil ein elektrisch passendes Board ohne gepflegte TLS- und Treiberbibliotheken keine sichere Verbindung halten kann. Prüfen Sie daher die Release-Historie des konkreten SDKs und seiner Abhängigkeiten, nicht nur die Popularität des Boards.
Ein belastbarer Kandidat veröffentlicht Versionshinweise, eine dokumentierte Supportdauer und Hinweise zu Sicherheitslücken. Erfassen Sie für ESP-IDF, Zephyr oder Arduino Core for ESP32 die tatsächlich eingesetzten Versionen in einer SBOM nach SPDX oder CycloneDX. Danach spielen Sie ein angekündigtes Update in einer isolierten CI-Umgebung ein und prüfen, welche Änderungen im Lockfile, bei Compiler-Flags und am Firmware-Image entstehen. „Neueste Version“ ist keine brauchbare Betriebsregel, weil ein ungeprüfter Major-Wechsel die Geräteprotokolle ebenso verändern kann wie eine Fehlerkorrektur.
Vergleichen Sie ausdrücklich ESP-IDF gegen Arduino Core for ESP32. ESP-IDF gewinnt, wenn Sie OTA-Partitionen, FreeRTOS-Tasks und die Integration mit dem ESP32-Bootloader gezielt kontrollieren müssen; der Preis ist mehr Konfigurations- und Testaufwand. Arduino Core for ESP32 gewinnt, wenn eine kleine Anwendung mit bekannten Bibliotheken schnell gepflegt werden soll; der Preis ist eine zusätzliche Abstraktionsschicht, deren Release-Zyklus von der darunterliegenden ESP-IDF-Version abweichen kann. Für ein neues Produktionsgerät würde ich nicht allein wegen eines kürzeren Sketches Arduino wählen, weil die eingesparten Entwicklungsstunden einen ungeklärten Update- oder Supportpfad nicht kompensieren.
Bitten Sie den Anbieter um ein Upgrade über eine bewusst übersprungene Version. Als zu vereinbarende Grenze können Sie festlegen, dass ein Gerät nach 18 Monaten ohne Zwischenupdates noch einen unterstützten Weg zum aktuellen Release haben muss. Diese Frist ist kein Naturgesetz; sie zwingt den Vendor jedoch, Aussagen über Migrationsschritte, Zertifikate und Flash-Layout schriftlich zu machen. Scheitert der Test, brauchen Sie einen dokumentierten Zwischenstand oder eine ausdrücklich begrenzte Lebensdauer der Geräte.
Ein offenes Protokoll nützt nichts ohne einen ausführbaren Ersatzplan
„Wir sprechen MQTT“ klingt nach geringer Abhängigkeit vom Hersteller. Das stimmt nur, wenn Payloads, Geräteidentitäten und Provisionierung ebenfalls portierbar sind, weil MQTT 5.0 zwar den Nachrichtentransport beschreibt, aber kein fachliches Schema für Sensordaten festlegt. Lassen Sie sich deshalb Topic-Struktur, Retain-Verhalten, QoS-Stufen und Fehlerantworten als maschinenlesbare Verträge geben. Ein proprietärer JSON-Wert innerhalb eines Standardprotokolls bleibt proprietär.
Der wirksamste Auswahltest ist ein kontrollierter Austausch: Verbinden Sie ein Testgerät mit einem zweiten Broker, etwa Eclipse Mosquitto statt dem Dienst des Vendors, und verarbeiten Sie seine Nachrichten mit einem kleinen eigenen Consumer. Prüfen Sie dabei, ob Geräte per TLS 1.3 oder einer begründeten, weiterhin unterstützten TLS-Konfiguration authentifiziert werden und ob Zertifikate erneuert werden können, ohne jedes Gerät von Hand anzufassen. Ein Wechsel ist nur dann realistisch, wenn die Identität des Geräts nicht unwiderruflich an ein Herstellerkonto gebunden ist.
Für den Pilotbetrieb würde ich eine gemessene Wiederverbindungszeit am 95. Perzentil protokollieren, nicht lediglich den Mittelwert, weil einzelne lange Ausfälle im Mittelwert verschwinden. Als anfängliches, später anhand der Anwendung anzupassendes Ziel können 60 Sekunden dienen. Trennen Sie dazu den Broker, stellen Sie ihn wieder her und beobachten Sie mit Prometheus-Metriken oder einem gleichwertigen Ereignisprotokoll, wann das Gerät erneut eine gültige Nachricht liefert. Dokumentieren Sie zugleich, ob während der Unterbrechung Daten lokal gepuffert, verworfen oder doppelt gesendet werden.
Genau dort wird die Bibliothekswahl operativ: QoS 1 bei MQTT bedeutet mindestens einmalige Zustellung und kann Duplikate erzeugen, weshalb der Consumer Nachrichten anhand einer Geräte-ID und einer monotonen Sequenznummer idempotent behandeln sollte. QoS 2 verspricht eine stärkere Zustellsemantik zwischen MQTT-Teilnehmern, beseitigt aber keine doppelten Wirkungen in einer nachgelagerten Datenbank. Ein Vendor, der auf diese Frage nur mit „QoS 2 einschalten“ antwortet, hat den Ende-zu-Ende-Pfad nicht erklärt.
Lassen Sie auch den Ausstieg kalkulieren. Fragen Sie, ob Sie Provisionierungsdaten exportieren, Zertifikate selbst ausstellen und ein Gerät auf einen anderen Endpoint umstellen können. Ein angebotener Datenexport allein reicht nicht, weil historische Messwerte wenig helfen, wenn bereits installierte Geräte dauerhaft nur den alten Dienst ansprechen. Ich würde keinen Cloud-Dienst beschaffen, dessen Wechsel einen physischen Besuch bei jedem Gerät voraussetzt; dieser Aufwand wächst mit der installierten Flotte und lässt sich später nicht durch bessere CI beseitigen.
Der Vertrag muss die Diagnose eines kaputten Geräts ermöglichen
Produktionssupport beginnt bei einer banalen Frage: Kann das Team unterscheiden, ob ein Gerät offline, stromlos, falsch provisioniert oder auf einem fehlgeschlagenen Release ist? Verlangen Sie vom Vendor ein konkretes Ereignismodell mit Bootgrund, Firmware-Version, Reset-Zähler und Zeitstempel. Der Zeitstempel sollte seinen Synchronisationsstatus erkennen lassen, weil eine Uhr ohne gültige Zeitquelle die Reihenfolge von Fehlern verfälschen kann. OpenTelemetry muss nicht auf dem Mikrocontroller laufen; entscheidend ist, dass Gateway oder Backend Geräteereignisse korrelierbar in die vorhandene Beobachtungsplattform überführen.
Definieren Sie im Vertrag, wer bei einer Sicherheitslücke den Patch baut, signiert, verteilt und den Erfolg bestätigt. Eine veröffentlichte CVE-Meldung ohne zugehörige Aussage über betroffene Firmware-Versionen hilft dem Betrieb wenig, weil das Team sonst jedes Gerät einzeln untersuchen muss. Fragen Sie nach einem maschinenlesbaren Geräteinventar mit Hardware-Revision, Bootloader- und Firmware-Version. Prüfen Sie bei einem Mustergerät, ob die gemeldeten Werte mit dem ausgelesenen Flash und dem Release-Artefakt übereinstimmen.
Für einen Supportversuch können Sie 15 Minuten bis zur eindeutigen Zuordnung als intern festgelegtes Testbudget verwenden: Ein Techniker bekommt nur die Geräte-ID und soll Version, letzten erfolgreichen Kontakt und letzten Updateversuch finden. Diese Zahl ist kein Versprechen des Vendors, sondern ein Maß für Ihre eigene Betriebsfähigkeit. Misslingt die Zuordnung, brauchen Sie bessere Telemetrie oder ein anderes Supportmodell, bevor weitere Geräte ausgerollt werden.
Bestehen Sie schließlich auf einem Exit-Test mit realen Zugangsdaten und einem Ersatzgerät. Der Vendor soll zeigen, wie ein kompromittiertes Zertifikat widerrufen und ein neues Gerät provisioniert wird. Dabei zählen sowohl dokumentierte Kommandos als auch Zuständigkeiten: Ein perfekt beschriebenes Verfahren ist im Incident nutzlos, wenn nur ein einzelner externer Administrator den Signaturschlüssel verwenden darf. Die Freigabe sollte deshalb an einen bestandenen Wiederherstellungstest gebunden sein, nicht an die bloße Existenz einer Support-Hotline.
Die erste Freigabeentscheidung fällt am Testgerät
Nehmen Sie morgen ein Gerät mit der aktuell vorgesehenen Firmware und unterbrechen Sie sein Update dreimal an unterschiedlichen Stellen. Halten Sie fest, welche Version danach startet, wie Sie das erkennen und wer einen Fehlschlag beheben kann. Gibt es darauf keine überprüfbare Antwort, pausieren Sie die Beschaffung: Ein bestandener Demo-Build sagt nichts darüber aus, ob Ihr Team ein ausgefallenes Gerät aus der Ferne zurückholen kann.
