Software Defined für Autos, Staubsauger und Roboter Warum nur? Embedded-Systeme arbeiten noch immer ohne „Docker-Moment“

Anbieter zum Thema

PANDUIT

Rittal GmbH & Co. KG

Während Entwickler im Rechenzentrum ihre Anwendungen in Container packen und sie fröhlich zwischen Servern verschieben, schreiben Embedded-Entwickler oft noch Software, die exakt für einen bestimmten Chip entwickelt wurde, inklusive aller Treiber, Register und Peripheriegeräte. Doch warum ist Embedded-Software so eng an Hardware gebunden?

In der Server- und Cloud-Welt ist Hardware heute weitgehend abstrahiert. Anwendungen laufen in Containern oder virtuellen Maschinen, ganz gleich, ob darunter ein x86- oder ein ARM-Prozessor arbeitet. Entwickler konzentrieren sich auf ihre Anwendungen und nicht auf das genaue Modell des Servers oder die Details des Prozessors. Man könnte sagen: In der Cloud ist Hardware austauschbar geworden.

Der Grund dafür liegt weniger in der Fragmentierung der Prozessorlandschaft als in der Art und Weise, wie Embedded-Systeme historisch entwickelt wurden. Während sich Rechenzentren über Jahrzehnte um eine relativ einheitliche Plattform, etwa x86 und Linux, organisiert haben, wurde Embedded-Software meist direkt auf der Hardware selbst entwickelt.

Mikrocontroller, Echtzeitprozessoren - spezialisierte Prozessoren, die Aufgaben innerhalb garantierter Zeitgrenzen ausführen können - oder Safety-Cores, also Prozessoren, die sicherheitskritische Funktionen überwachen, bringen jeweils eigene Peripherie, Speicherarchitekturen und Spezialfunktionen mit. Treiber, Registerzugriffe und Hardware-Workarounds werden daher oft direkt Teil der Anwendung. Der Code kennt somit nicht nur seinen Prozessor, sondern auch jede einzelne Schnittstelle des Systems.

Code kennt jeden Chip – und das hat seinen Preis

Software wird deshalb in der Regel direkt für einen bestimmten Chip und dessen Peripherie entwickelt. Treiber, Board-Support-Packages, das heißt: Softwarepakete, die alle notwendigen Treiber und Einstellungen für eine bestimmte Hardware-Plattform enthalten, und hardwarenahe Konfiguration sind integraler Bestandteil des Codes. Das Ergebnis ist Software, die das gesamte System kennt – vom Prozessor bis zur letzten Schnittstelle.

Entwicklungszyklen folgen daher häufig den Hardwarezyklen. Erst wenn ein Chip verfügbar ist, kann mit der Software-Entwicklung begonnen werden. Historisch betrachtet hatte dieses Modell gute Gründe: Begrenzte Ressourcen, spezialisierte Hardware und kaum Abstraktionsschichten waren die Regel.

Doch genau dieses Entwicklungsmodell beginnt sich gerade zu verändern. Der Grund dafür ist weniger eine neue CPU oder ein schnellerer Compiler, sondern eine andere Art, Systeme zu entwickeln. Lange Zeit bedeutete „Simulation“ im Embedded-Bereich, einen Prozessor zu emulieren, damit die Software auch ohne reale Hardware starten konnte. Das ist zwar nützlich, löst das eigentliche Problem jedoch nicht, denn ein Chip allein ist noch kein System.

Vom Chip zur Systemsimulation am Beispiel Saugroboter

Interessant wird es, wenn nicht nur der Prozessor simuliert wird, sondern das gesamte Gerät, denn so lassen sich die Auswirkungen auf die gesamte Systemleistung besser analysieren. Betrachten wir beispielsweise einen Saugroboter. Seine Software muss nicht nur auf einem Mikrocontroller laufen, sondern auch mit Sensoren, Motoren, WLAN-Verbindungen und einer chaotischen Umgebung zurechtkommen, inklusive herumliegender Socken.

In der klassischen Embedded-Entwicklung wird die Hardware jedoch meist lange im Voraus festgelegt, oft auf Basis von Datenblättern und Annahmen. Erst Monate später, wenn die ersten Boards verfügbar sind, zeigt sich in der Praxis, ob diese Annahmen zutreffen.

Vielleicht funktioniert die Navigation wie geplant. Es kann aber auch sein, dass sich herausstellt, dass die Sockenerkennung mit der gewählten Hardware schlicht nicht machbar ist, weil der KI-Beschleuniger, ein spezialisierter Prozessor, der Berechnungen für künstliche Intelligenz besonders effizient ausführt,zu wenig Rechenleistung hat oder der Speicher zu knapp bemessen ist. Dann beginnt die eigentliche Herausforderung, denn die Hardwareentscheidung steht bereits fest.

Virtuelle Welten ermöglichen frühere Software-Entwicklung

In einer simulierten Umgebung kann dieses Szenario dagegen schon vorher entstehen: ein virtuelles Wohnzimmer, virtuelle Sensoren, virtuelle Motoren – und ja, auch virtuelle Socken. Entwickler können die Software bereits am PC oder in der Cloud entwickeln und ausprobieren, lange bevor der reale Roboter existiert.

Der entscheidende Unterschied zu klassischen Emulatoren besteht darin, dass hier nicht nur der Prozessor, sondern das Verhalten des gesamten Systems nachgebildet wird. Die Software kann mit simulierten Netzwerken, simulierten oder echten Sensoren oder sogar ganzen Fahrzeug- oder Robotikmodellen interagieren, was den Entwicklungsprozess fundamental verändert.

Software muss nicht mehr ausschließlich entlang der Hardwarezyklen entwickelt werden, sondern kann entlang der Funktion des Systems entstehen. Entwickler können Features erstellen, testen und optimieren, während die eigentliche Hardware noch in der Entwicklung ist.

Neue Chancen für Hyperscaler

Dadurch eröffnet sich für Hyperscaler wie Amazon oder Microsoft eine zusätzliche Dimension: Neben klassischen Cloud-Workloads können künftig auch virtuelle Maschinenwelten entstehen, in denen beispielsweise Roboter, Fahrzeuge oder industrielle Systeme vollständig simuliert werden. Und genau hier beginnt etwas, das man durchaus als den möglichen „Docker-Moment” für Embedded-Systeme bezeichnen könnte.

(ID:50781737)