Insights · Gerätesoftware
Gerätesimulation statt Hardware-Engpass
In vielen Geräteherstellern gibt es eine unsichtbare Warteschlange: Entwickler warten auf ein freies Gerät, Tester warten auf Entwickler, Releases warten auf beide. Der Engpass ist selten das Team — es ist die Annahme, dass Gerätesoftware nur am Gerät entstehen kann.
Das eigentliche Problem: Hardware als Taktgeber
Physische Geräte sind teuer, knapp und oft in Laboren verbaut, die man nicht eben betreten kann. Hängen Entwicklung und Test an dieser Verfügbarkeit, wird das Gerät zum Taktgeber des gesamten Softwareprozesses: Iterationen dauern Tage statt Minuten, Fehlerfälle lassen sich kaum gezielt herstellen, und automatisierte Tests in einer CI-Pipeline sind praktisch unmöglich.
Besonders tückisch sind die Fälle, die man am echten Gerät nicht herbeiführen will oder kann: Abbrüche mitten im Lauf, degradierte Sensorik, Kommunikationsfehler zur Unzeit. Genau diese Fälle entscheiden aber darüber, ob sich Software im Labor robust oder fragil anfühlt.
Simulation als Architekturentscheidung, nicht als Testtrick
Der Unterschied zwischen einem schnellen Mock und einer tragfähigen Simulationsschicht liegt im Anspruch: Eine tragfähige Simulation ist ein vollwertiger Gerätepartner der Software — sie spricht dasselbe Protokoll, führt dieselben Zustandsübergänge aus und kann gezielt in Fehlerzustände geschickt werden.
- Gleiche Schnittstelle wie das Gerät: Die Anwendung merkt nicht, ob sie mit Hardware oder Simulation spricht. Der Umschalter ist Konfiguration, kein Codezweig.
- Deterministisches Verhalten: Läufe sind reproduzierbar; ein Fehlerbild von gestern lässt sich heute exakt wiederholen.
- Fehlerfälle als Repertoire: Abbruch, Timeout, inkonsistente Antworten — als abrufbare Szenarien, nicht als Zufallsfund.
- CI-tauglich: Jede Änderung läuft automatisiert gegen die Simulation, bevor sie ein echtes Gerät sieht.
Nachrüsten in Bestandssoftware: die Naht finden
Kaum jemand startet auf der grünen Wiese. Die gute Nachricht: Fast jede Gerätesoftware hat bereits eine Stelle, an der die Kommunikation mit dem Gerät gebündelt ist — und sei es unordentlich. Diese Naht wird zur Schnittstelle: Man definiert sie explizit, stellt die echte Gerätekommunikation dahinter, und baut die Simulation als zweite Implementierung derselben Schnittstelle.
Wichtig ist die Reihenfolge: erst die Naht sauber ziehen, dann simulieren. Wer die Simulation an einer diffusen Stelle ansetzt, simuliert am Ende das eigene Missverständnis.
Die eine Gefahr: Drift
Eine Simulation ist nur so gut wie ihre Übereinstimmung mit dem Gerät. Ohne Gegenmaßnahme driftet sie: Das Gerät bekommt neue Firmware, die Simulation bleibt stehen, und irgendwann testet man gegen eine Fiktion. Das Gegenmittel sind regelmäßige Abgleichläufe gegen echte Hardware — dieselbe Testsuite läuft gegen Simulation und Gerät, Abweichungen werden laut gemeldet statt still toleriert. So bleibt die knappe Hardware das Prüfmittel, nicht der Engpass.
Kurz gefasst: Eine Simulationsschicht mit gleicher Schnittstelle, deterministischem Verhalten und gepflegtem Fehler-Repertoire entkoppelt den Softwaretakt vom Gerätetakt. Der Abgleich gegen echte Hardware verhindert Drift. Der Effekt: schnellere Iterationen, testbare Grenzfälle, planbare Releases.
Wo die Naht in Ihrer Bestandssoftware liegt und was die Simulation zuerst können muss, klärt ein Gerätesoftware-Assessment — zwei Wochen, Festpreis.