Anforderungen in Embedded- und Firmware-Projekten: Die Spezifikation früh einfrieren
Embedded-Projekte bestrafen späte Anforderungen härter als jede andere Art von Software. In einer Web-App bedeutet eine geänderte Anforderung ein Redeploy. In einem Embedded-System kann sie ein neues Board-Layout, einen Firmware-Rückruf oder einen Außendienstbesuch an bereits installierten Geräten bedeuten — oft an Orten, die niemand erneut besuchen will.
Deshalb ist die Kerndisziplin des Embedded-Engineerings nicht cleverer Code. Es ist, die Spezifikation früh einzufrieren und die Schnittstellenverträge zwischen Hardware, Firmware und Cloud als tragende Wände des Projekts zu behandeln.
Warum Embedded anders ist
- Hardware hat Vorlaufzeiten — eine Board-Änderung kostet Wochen oder Monate, nicht Minuten.
- Viele Geräte lassen sich nicht über Funk aktualisieren — was im Werk geflasht wird, läuft jahrelang.
- Speicher und CPU sind begrenzt — eine falsche Anforderung lässt sich nicht durch eine größere Laufzeitumgebung kaschieren.
- Das System berührt die physische Welt — Sicherheit, Wärme und Spannung verzeihen keine Mehrdeutigkeit.
- Zertifizierung (CE, UL, funktionale Sicherheit) baut auf einer eingefrorenen Spezifikation auf — sie zu ändern startet den Prozess neu.
Die Spezifikation früh einfrieren
Der richtige Moment, eine falsche Anforderung zu finden, ist vor dem Schaltplan. Eine während der Firmware-Entwicklung geänderte Anforderung ist teuer. Eine nach der Board-Fertigung geänderte Anforderung ist eine Größenordnung schlimmer. Eine erst im Feld entdeckte Anforderung ist eine Katastrophe.
Die Disziplin lautet also: die Spezifikation vereinbaren, als Baseline festhalten und jede spätere Änderung durch einen ausdrücklichen, dokumentierten Änderungsprozess laufen lassen — nicht durch ein informelles Gespräch.
Die Schnittstellenspezifikationen sind der Vertrag
Die Nähte zwischen den Teams sind die Stellen, an denen Embedded-Projekte bluten. Hardware-, Firmware- und Cloud-Team bauen jeweils gegen eine gemeinsame Schnittstelle — und wenn diese Schnittstelle nicht aufgeschrieben ist, erfindet jede Seite ihre eigene Version davon. (Erinnern Sie sich an den Mars Climate Orbiter: Ein Team nutzte Pfund-Kraft-Sekunden, das andere erwartete Newton-Sekunden.)
Die Schnittstellen, die Sie schriftlich festlegen müssen, bevor irgendjemand baut:
- Die Registertabelle — jedes Register mit Adresse, Datentyp, Skalierungsfaktor, Byte-Reihenfolge und Einheit. Standards wie SunSpec existieren genau deshalb, weil „welches Register was bedeutet“ nicht dem Gedächtnis überlassen werden darf.
- Das Kommunikationsprotokoll — Modbus-Funktionscodes oder die MQTT-Topic-Struktur, das Payload-Schema, QoS und Retention.
- Das Datenmodell — Feldnamen, Typen und Einheiten, die Firmware und Cloud teilen, damit ein Wert bei der Übertragung nie uminterpretiert wird.
- Versionierung — eine beim Start ausgehandelte Schema- oder Protokollversion, damit Feldgerät und Cloud sich darüber einig sind, was eine Nachricht bedeutet.
Die Dreiteilung
Hardware, Firmware und Cloud sind drei Teams mit drei verschiedenen Uhren. Hardware denkt in Revisionen und Respin, Firmware in Builds und Flashes, Cloud in Deployments. Das Einzige, was sie aufeinander ausgerichtet hält, ist die eingefrorene Schnittstellenspezifikation zwischen ihnen.
Ist die Schnittstelle aufgeschrieben und versioniert, kann jedes Team seine Seite unabhängig ändern — die Firmware refaktorisiert, ohne die Cloud zu brechen, die Hardware tauscht einen Sensor, ohne die Firmware zu brechen. Ist sie es nicht, wird jede Änderung zu einer Drei-Wege-Verhandlung.
Ein konkretes Beispiel
Stellen Sie sich eine Leistungselektronik (PCS) vor, die ihren Zustand an ein Energiemanagementsystem melden muss. Eine vage Anforderung — „das Gerät muss seine Messwerte melden“ — ist ein Projektkiller im Wartestand.
Eine echte Anforderung legt den Vertrag fest: „Das Gerät muss Ladezustand, DC-Spannung und DC-Strom über Modbus/TCP bereitstellen. Ladezustand an Register 40001 als vorzeichenloser 16-Bit-Wert mit Faktor 0,1 (Einheit: %), DC-Spannung an Register 40002 als vorzeichenloser 16-Bit-Wert mit Faktor 0,1 (Einheit: V), DC-Strom an Register 40003 als vorzeichenbehafteter 16-Bit-Wert mit Faktor 0,1 (Einheit: A). Werte in Big-Endian. Zusätzlich muss das Gerät dieselben Felder alle 10 Sekunden als JSON-Nachricht auf das MQTT-Topic /devices/{id}/telemetry veröffentlichen.“
Der Unterschied ist der Unterschied zwischen einem Gerät, das sich an einem Tag integrieren lässt, und einem, das einen Support-Anruf und einen Firmware-Patch braucht.