BSP-Management mit ToloMEO: ein DevSecOps-Ansatz für industrielle Embedded-Flotten

ToloMEO, die Fleet-Management-Plattform von DAVE Embedded Systems, begegnet dieser Herausforderung direkt durch das Embedded Manager-Modul — den operativen Kern des gesamten Stacks. Das Architektur-Flussdiagramm zeigt in einem einzigen Schema, wie der BSP-Lebenszyklus orchestriert wird: Das Production Management System liefert NPI- und Provisioning-Daten nach unten, der Embedded Manager koordiniert in der Mitte die Build- und Verteilungs-Pipeline, das Board Farm validiert jedes Release auf echter Hardware links, Cyber Security überwacht und klassifiziert Schwachstellen rechts, und das IoT-Modul bringt die validierte Firmware unten ins Feld.

Dieser Artikel folgt diesem Fluss Schritt für Schritt.

Der erste Pfeil im Diagramm zeigt vom Production Management System nach unten zum Embedded Manager und trägt die Bezeichnung NPI / Provisioning. Hier nimmt eine neue Produkteinführung oder eine Gerätekonfigurationsänderung ihren Ursprung.

In der Praxis deckt NPI (New Product Introduction) alles ab, was passieren muss, bevor ein Gerät das Werk verlässt: Auswahl der Hardware-Variante, initiale Zuweisung des Software-Stacks, Zertifikatseinspielung, Secure-Boot-Schlüssel-Provisioning und werksseitige Konfiguration. Das Production Management System hält den Masterdatensatz darüber, was jedes Gerät ist, welche BSP-Version es tragen soll und welche Anmeldedaten ihm zugewiesen wurden. Der Embedded Manager nutzt diese Informationen, um sicherzustellen, dass jede Einheit ihr Leben in einem bekannten, konsistenten und konformen Zustand beginnt.

Diese vorgelagerte Integration ist es, die einen verwalteten BSP-Lebenszyklus von ad-hoc-Firmware-Flashing unterscheidet: Anstatt jedes Gerät manuell zu konfigurieren, wird der Prozess durch strukturierte Daten gesteuert, die aus einer einzigen Quelle der Wahrheit fließen.

Der nach unten zeigende Pfeil vom Embedded Manager zum Production Management System trägt die Bezeichnungen Compile / Build / Create Artifacts / Report — und hier findet der Großteil der Ingenieurarbeit statt.

Der Embedded Manager stellt eine professionelle mehrstufige Build-Infrastruktur auf Basis dedizierter virtueller Maschinen bereit: Eine Build-VM übernimmt Kompilierung und Image-Zusammenstellung, eine Signing-VM verwaltet kryptografische Operationen, und eine Reihe von Git-Repositories (DAVEs eigene, die des Kunden und öffentliche Upstream-Quellen) werden koordiniert, um ein kohärentes Release zu erzeugen. Intelligentes Caching minimiert die Build-Zeiten bei den typischerweise sechs BSP-Releases pro Jahr, die DAVE für seine Hardware-Plattformen pflegt.

Jeder Build-Durchlauf erzeugt nicht nur ein Firmware-Image, sondern einen vollständigen Satz von Artifacts: das signierte Binary, das Software Bill of Materials (SBOM) und das zugehörige VEX-Dokument (Vulnerability Exploitability eXchange), das festhält, welche bekannten Schwachstellen dieses Release betreffen und ob sie auf der Zielplattform ausnutzbar sind. Diese Artifacts werden gespeichert, versioniert und für die nachgelagerte Validierung bereitgestellt.

Das vom Embedded Manager unterstützte Dual-Ownership-Modell verdient hier besondere Beachtung. DAVE pflegt den Kern-BSP — Kernel, Treiber, OS-Hardening gemäß IEC 62443 — während Kunden ihn mit eigenen Anwendungsschichten und Funktionen erweitern. Die Plattform koordiniert beide Beiträge und stellt sicher, dass kundenspezifische Anpassungen BSP-Updates sauber überstehen und dass Security-Hardening niemals versehentlich rückgängig gemacht wird.

Bevor Firmware das Feld erreicht, durchläuft sie das Board Farm — die bidirektionale Verbindung links vom Embedded Manager im Diagramm, mit Report nach rechts und Test nach links fließend.

Das Board Farm ist eine Hardware-in-the-Loop-Testinfrastruktur, die physisch bei DAVE gehostet wird. Jedes neue BSP-Release wird automatisch auf echte Ziel-Hardware geladen, kontrollierten Ein-/Ausschaltvorgängen unterzogen und durch eine vollständige Suite funktionaler Tests geführt, die reale Betriebsbedingungen simulieren. Es handelt sich nicht um Emulation oder Simulation — es ist die echte Hardware, die Kunden einsetzen, geprüft mit der echten Firmware, die verteilt werden wird.

Die Testergebnisse fließen als strukturierter Bericht zurück zum Embedded Manager. Nur BSP-Releases, die die vollständige Validierungssuite bestehen, werden in die Verteilungs-Pipeline übernommen. Dieses Gate verleiht dem Begriff „production ready" auf dem nach unten zeigenden Pfeil Richtung IoT seine konkrete Bedeutung: Ein Firmware-Image verdient diese Bezeichnung durch das Bestehen echter Hardware-Tests — nicht durch das Abhaken einer Checkliste.

Die Boundary-Scan- und Funktionstest-Fähigkeiten des Board Farm dienen auch einem sekundären Zweck: Sie erfassen Hardware-Software-Integrations-Regressionen frühzeitig, bevor sie sich auf im Feld eingesetzte Geräte ausbreiten, wo eine Wiederherstellung einen physischen Eingriff erfordert.

Die rechte Seite des Diagramms zeigt die bidirektionale Verbindung zwischen dem Embedded Manager und dem Cyber Security-Modul: SW/HW BOM fließt nach außen, Report fließt zurück, und die Beschriftung darunter nennt Analyze, Triage, Report.

Dieser Fluss repräsentiert den kontinuierlichen Schwachstellenmanagementprozess. Das beim Build erzeugte SBOM wird an das Cyber-Security-Modul übergeben, das es mit CVE-Datenbanken abgleicht und fortlaufend nach neu offengelegten Schwachstellen Ausschau hält. Wenn ein relevanter CVE identifiziert wird, initiiert das Modul einen Triage-Workflow: Die Schwachstelle wird hinsichtlich ihrer Ausnutzbarkeit auf der spezifischen Hardware- und Softwarekonfiguration bewertet, ein Risikoniveau wird zugewiesen, und der Embedded Manager erhält einen Bericht, der eine Änderungsanforderung für das nächste BSP-Release auslösen kann.

Dieser geschlossene Regelkreis ist es, der Sicherheit von einer einmaligen Aktivität beim Projektstart in eine kontinuierliche operative Fähigkeit verwandelt. In regulierten Märkten — Gesundheitswesen, Eisenbahn, industrielle Automatisierung — ist die Fähigkeit nachzuweisen, dass Schwachstellen aktiv überwacht, klassifiziert und behoben werden, zunehmend eine Compliance-Anforderung im Rahmen von Regelwerken wie NIS2, dem EU Cyber Resilience Act und IEC 62443. Der Embedded Manager erzeugt compliance-fähige Berichte zur Unterstützung genau dieser Verpflichtungen.

Der letzte Pfeil im Flussdiagramm zeigt vom Embedded Manager nach unten zu ToloMEO IoT, mit der Bezeichnung Production ready und der Beschriftung Local update / OTA update / Log.

Sobald ein BSP-Release die Build-Pipeline durchlaufen, die Board-Farm-Tests bestanden und den Security-Triage erfüllt hat, wird es an das OTA-Verteilungssystem übergeben. Der Embedded Manager koordiniert mit dem IoT-Modul das Rollout-Management: Update-Pakete werden vor der Übertragung signiert und verifiziert, Delta-Updates minimieren den Bandbreitenverbrauch, gestufte Rollouts begrenzen den Wirkungsradius bei unerwarteten Problemen im Feld, und ein automatisches Rollback stellt sicher, dass ein fehlgeschlagenes Update kein Gerät in einem nicht startfähigen Zustand zurücklässt.

Der lokale Update-Pfad deckt Geräte ab, die nicht dauerhaft verbunden sind — sie können Firmware über eine lokale Schnittstelle empfangen, wenn sie sich einchecken — während der OTA-Pfad die breitere Flotte verwaltet. Beide Pfade berichten über das Log zurück an den Embedded Manager und pflegen so einen vollständigen Audit-Trail darüber, welches Gerät zu jedem Zeitpunkt welche Firmware-Version ausführt.

Was das Flussdiagramm darstellt und was ToloMEO liefert, ist ein BSP-Managementprozess, der durchgehend kontinuierlich, automatisiert und beobachtbar ist. Jedes Release folgt demselben Pfad: Es wird aus kontrollierten Quellen gebaut, signiert, auf echter Hardware getestet, gegen aktuelle CVE-Intelligence geprüft und mit Rollback-Sicherheit an individuell nachverfolgte Geräte verteilt.

Für Engineering-Teams, die BSP-Updates historisch über manuelle Prozesse verwaltet haben — ein Skript hier, ein USB-Stick dort, eine Tabelle zur Nachverfolgung des Betriebsstatus — ist der Kontrast erheblich. Der Embedded Manager beseitigt den Single Point of Failure impliziten Erfahrungswissens und ersetzt ihn durch eine wiederholbare, prüfbare Pipeline, die von einer Handvoll Prototypen auf Tausende eingesetzte Einheiten skaliert, ohne den Prozess zu verändern.

Für Produktmanager und Compliance-Verantwortliche ist das Ergebnis ein System, dessen Sicherheitsstatus zu jedem Zeitpunkt nachgewiesen werden kann: welche Version auf welchem Gerät läuft, welche Schwachstellen bekannt sind, wie der Behebungszeitplan aussieht und was die Testergebnisse belegen.

BSP-Management ist eines jener Probleme, das bei kleinem Maßstab handhabbar erscheint und mit der Reife eines Produkts und dem Wachstum seiner Flotte echte Schwierigkeiten bereitet. ToloMEO Embedded Manager wurde entwickelt, um diese Komplexität zu absorbieren: Er verbindet Provisioning, Build-Automatisierung, Hardware-Testing, Schwachstellenmanagement und OTA-Verteilung in einem einzigen gesteuerten Workflow und hält industrielle Embedded-Geräte über ihre gesamte Betriebslebensdauer hinweg sicher, aktuell und nachverfolgbar.