IoT-Hardware mit Zukunft

Ein funktionierender Sensor ist der Anfang

In einem aktuellen Projekt entsteht ein professioneller CO₂-Sensor auf ESP32-Basis. Die Sensorfunktionen sind umgesetzt. Die Updatefähigkeit befindet sich in Entwicklung: Updateverfahren werden experimentell geprüft und die benötigte Infrastruktur mit einem Update-Server wird aufgebaut.

Der nächste Entwicklungsschritt betrifft damit den gesamten Lebensweg des Geräts. Wie erreicht eine neue Firmware die bereits ausgelieferten Sensoren? Wie erkennt ein Gerät, ob die Version wirklich für seine Hardware bestimmt ist? Und wie bleibt es nach einem abgebrochenen Update betriebsfähig?

Diese Fragen gehören früh in die Entwicklung. Speicheraufteilung, Vertrauensanker und Wiederherstellungsverfahren lassen sich wesentlich besser planen, bevor Geräte an vielen Standorten eingesetzt werden. Ein Update-Server allein macht ein Gerät noch nicht sicher aktualisierbar.

Eine technische Grundlage für Pflege und neue Funktionen

Sicherheitskorrekturen, Fehlerbehebungen und funktionelle Erweiterungen können denselben technischen Updateweg nutzen. Die neue Firmware wird bereitgestellt, auf das Gerät übertragen, geprüft und kontrolliert aktiviert. Für den Kunden entsteht daraus ein unmittelbarer Vorteil: Das Gerät lässt sich auch nach der Auslieferung verbessern.

So kann eine spätere Version beispielsweise zusätzliche Integrationen oder eine erweiterte Auswertung ermöglichen, sofern Hardware und verfügbare Ressourcen dies zulassen. Das sind Möglichkeiten einer updatefähigen Architektur, keine bereits zugesagten Funktionen des CO₂-Sensors.

Ob eine Änderung eine Sicherheitslücke schliesst oder eine neue Funktion ergänzt, bleibt für Freigabe, Kommunikation und vertragliche Leistungen relevant. Dafür braucht es jedoch nicht zwei getrennte technische Update-Infrastrukturen. Eine gemeinsame, verlässliche Grundlage kann beides tragen.

Architektur verbindet Gerät und Betrieb

Architektur in der Informatik ordnet das Zusammenspiel von Firmware, Hardware, Bereitstellung und Betrieb. Beim Updateverfahren muss klar sein, welcher Baustein welche Verantwortung übernimmt.

Das Gerät muss die Echtheit und Eignung eines Updates prüfen können. Die Bereitstellung muss nachvollziehbar festlegen, welche Version für welches Gerätemodell freigegeben ist. Der Betrieb muss Updates verfügbar halten und erkennen können, wenn die Verteilung fehlschlägt. Signierschlüssel brauchen einen geschützten Umgang und ein Verfahren für ihren Wechsel.

Offene, dokumentierte Schnittstellen helfen, diese Aufgaben zu trennen. Dadurch kann sich die Serverinfrastruktur weiterentwickeln, ohne bei jeder Änderung auch das gesamte Gerät neu entwerfen zu müssen. Das passt zum Zusammenspiel aus bewährten Bausteinen und gezielter Individualsoftware.

Zuerst experimentell prüfen

Ein Update, das einmal unter idealen Bedingungen funktioniert, ist noch kein belastbares Verfahren. Der experimentelle Aufbau dient dazu, Anforderungen an Gerät und Infrastruktur praktisch zu prüfen. Zu den vorgesehenen Prüffragen gehören:

• Wird manipulierte oder für ein anderes Gerätemodell bestimmte Firmware abgelehnt?
• Was passiert, wenn Netzwerkverbindung oder Stromversorgung während der Aktualisierung ausfallen?
• Wie erkennt das Gerät, dass eine neue Firmware tatsächlich funktioniert?
• Wie bleibt eine Wiederherstellung möglich, ohne bekannte unsichere Versionen erneut zuzulassen?
• Bleiben notwendige Einstellungen nach dem Update erhalten?
• Was geschieht, wenn der Update-Server zeitweise nicht erreichbar ist?

Damit werden die Fehlerfälle Teil des Entwurfs. Die Ergebnisse solcher Versuche bestimmen, wie das Verfahren weiterentwickelt und für den regulären Betrieb freigegeben wird.

Sichere Übertragung und kontrollierter Neustart

Für die ESP32-Entwicklung sind signierte Firmware und eine verschlüsselte Übertragung über TLS wichtige Bausteine. Sie erfüllen unterschiedliche Aufgaben: TLS schützt den Übertragungsweg, die Signatur ermöglicht die Prüfung, ob die Firmware von einer vertrauenswürdigen Stelle stammt und unverändert ist. Zusätzlich müssen Gerätemodell und zulässiger Versionsstand geprüft werden.

Das ESP-IDF unterstützt OTA-Aktualisierungen, also Firmwareupdates über eine Kommunikationsverbindung. Für Anwendungsupdates sieht das Verfahren mindestens zwei Firmwarebereiche sowie Verwaltungsdaten vor. Die neue Anwendung wird in den gerade nicht genutzten Bereich geschrieben. Ein aktiviertes Rollback-Verfahren kann nach einem fehlgeschlagenen Start auf die vorherige funktionsfähige Anwendung zurückgehen. Dafür muss die neue Anwendung ihre Funktionsfähigkeit prüfen und bestätigen. Espressif beschreibt diese Abläufe in der OTA-Dokumentation.

Ein Schutz vor unsicheren Altversionen muss dazu passen. Eine Wiederherstellung darf die festgelegte Sicherheitsuntergrenze nicht unterschreiten. Zwei Firmwarebereiche ersetzen deshalb weder geeignete Selbsttests noch ein durchdachtes Versionskonzept. Diese Zusammenhänge gehören in die experimentelle Prüfung.

Der Update-Server gehört zum Produkt

Zur Updatefähigkeit gehört mehr als ein Verzeichnis mit Firmwaredateien. Ein tragfähiger Betrieb braucht nachvollziehbare Versionen, eine Zuordnung zu den unterstützten Geräten, kontrollierte Freigaben und eine verlässliche Bereitstellung.

Dazu kommen praktische Fragen: Wer erstellt und prüft eine Version? Wer gibt sie frei? Wie werden Zertifikate und Schlüssel gepflegt? Welche Informationen sind nötig, um einen fehlgeschlagenen Updateversuch zu untersuchen? Und wie lange werden die Geräte unterstützt?

Diese Arbeit verursacht laufenden Aufwand. Auch wenn ein Update für den Kunden ohne zusätzliche Gebühr bereitgestellt wird, müssen Entwicklung, Prüfung und Infrastruktur finanziert sein. Updatefähigkeit wird damit Teil der Produktverantwortung und der wirtschaftlichen Planung.

Der Cyber Resilience Act verstärkt die Bedeutung

Der EU Cyber Resilience Act, die Verordnung (EU) 2024/2847, führt verbindliche Cybersicherheitsanforderungen für erfasste Produkte mit digitalen Elementen ein. Für kommerziell auf dem EU-Markt bereitgestellte vernetzte Geräte ist er deshalb bereits bei der Produktplanung relevant. Die Hauptpflichten gelten ab dem 11. Dezember 2027; bestimmte Meldepflichten gelten bereits seit dem 11. September 2026. Überblick der EU-Kommission.

Zu den Anforderungen gehören der Umgang mit Schwachstellen und sichere Aktualisierungsverfahren. Automatische Sicherheitsupdates sind vorgesehen, soweit anwendbar, einschliesslich einer Abschaltmöglichkeit. Sicherheitsupdates sind grundsätzlich kostenlos bereitzustellen; für massgeschneiderte Produkte für Geschäftskunden besteht eine begrenzte Möglichkeit abweichender Vereinbarungen. Das ist von optionalen funktionellen Erweiterungen zu unterscheiden. Behördliche Übersicht zu den Sicherheitsanforderungen.

Die konkrete Umsetzung richtet sich nach Produkt, Einsatz und Risiken. OTA ist ein möglicher technischer Weg. Eine Updatefunktion allein belegt noch keine vollständige CRA-Konformität.

Langlebige Hardware braucht Weiterentwicklung

Der CO₂-Sensor macht den Zusammenhang greifbar: Auf die umgesetzten Gerätefunktionen folgt der Aufbau einer überprüfbaren Updatefähigkeit samt Infrastruktur. Damit wird die Voraussetzung geschaffen, ausgelieferte Geräte später mit Sicherheitskorrekturen und funktionellen Verbesserungen zu versorgen.

Der Kundennutzen reicht über die erste Inbetriebnahme hinaus. Geeignete Änderungen können aus der Ferne bereitgestellt werden, ohne dafür das Gerät auszutauschen oder jedes Mal einen Vor-Ort-Einsatz zu benötigen. Entscheidend sind die technischen Möglichkeiten, die zugesagte Unterstützung und ein zuverlässig gepflegter Updateweg.

Wie bei Software ohne Updates gilt auch für vernetzte Hardware: Ihre Nutzbarkeit hängt davon ab, ob die eingebettete Software über die Zeit betreut werden kann. Diese Fähigkeit beginnt mit bewussten Architekturentscheidungen.