Der Funktionsaufruf kehrt zurück, bevor die Welt sich geändert hat

Ein Steuergerät wechselt seinen Zustand in Mikrosekunden. Der Aktor, den es ansteuert, braucht einige hundert Millisekunden. Zwischen diesen beiden Zahlen liegen fünf Größenordnungen, und in dieser Lücke steckt ein guter Teil der Fehler, die erst bei der Integration auffallen und nie im Code Review.

Trotzdem dreht sich gefühlt jede Debatte über schnellere Produktentwicklung um Software. Software-defined Vehicle, Softwareplattform, Feature-Teams, zweiwöchige Sprints. Die Hardware taucht darin zwar auf, aber of als „gelöstes Problem“ oder als Altlast. Diese Sicht ist falsch und erklärt, warum Unternehmen agile Methoden einführen und danach genauso lange für ein Produkt brauchen wie vorher.

Die Ökonomie der Änderung

Softwareentwicklung ist nicht schnell, weil Teams agil arbeiten. Sie sind schnell, weil die Ökonomie der Änderung es zulässt, und agiles Arbeiten ermöglicht das. Dabei hat Software drei wichtige Eigenschaften:

1. Grenzkosten nahe null. Eine Kopie kostet nichts. Der Build läuft in Minuten, die Infrastruktur für Over-the-Air-Delivery ist vorhanden.
2. Reversibilität. Ein Rollback stellt den vorherigen Zustand wieder her. Ein Fehlversuch kostet Rechenzeit, aber kein Material.
3. Feedback in Sekunden bis Stunden. Testsuite, Canary Release, Telemetrie aus dem Feld.

Daher lohnen sich für Software kleine Batches, weil das Zusammenführen billig ist. Auch Experimente sind extrem wertvoll. Mit Continuous Delivery sind Änderungskosten nahe null.

In der Hardware gilt keine dieser drei Eigenschaften. Ein Spritzgusswerkzeug hat acht bis sechzehn Wochen Vorlauf und kostet fünfstellig. Eine Geometrieänderung nach Werkzeugfreigabe ist ein Änderungsantrag mit Freigabeschleife und verbautes Material bleibt verbaut. Selbst beim Einsatz von Rapid Manufacturing fallen Kosten an und das Feedback kommt aus einem Prüfaufbau, den erst jemand aufbauen muss.

Wer in dieser Welt zweiwöchige Sprints einführt, verkürzt keinen Lernzyklus, sondern portioniert die Wartezeit.

Der Kopierfehler

Genau hier setzt Product Velocity an, welches die Prinzipien hinter der Softwaregeschwindigkeit auf hardwarelastige Produkte überträgt. Aber das erfordert Anpassung.

Der Unterschied zeigt sich schon beim Handwerkszeug. Softwareentwicklung arbeitet seit zwanzig Jahren mit nichtlinearer Versionierung. Branch, Merge, Pull Request. Jeder Entwickler probiert eine Variante aus, ohne die anderen zu blockieren. In der Hardwareentwicklung fehlt diese Erfahrung vielerorts, wie Martin Häuer im Interview über Open Source Hardware beschreibt. Ohne billiges Verzweigen und Zusammenführen bleibt paralleles Arbeiten teuer, und ohne paralleles Arbeiten bleibt der kritische Pfad lang.

Ein zweiter Unterschied wiegt schwerer, weil er sich nicht wegorganisieren lässt. Software kennt keine Trägheit. Hardware schon.

Einschwingzeit

Die Regelungstechnik hat für dieses Verhalten längst Begriffe. Zwischen dem Befehl und dem erreichten Zustand liegt eine Einschwingzeit, davor oft noch eine Totzeit, in der überhaupt nichts passiert. Beide fallen je nach Domäne um Größenordnungen verschieden aus.

Ein Zustandswechsel in Software ist aus Sicht des Gesamtsystems sofort. Der Schreibzugriff auf eine Variable ist abgeschlossen, bevor irgendetwas Physisches reagiert hat. Elektrik und Elektronik brauchen länger, meist Millisekunden, und dabei schwingen sie über oder prellen. Mechanik, Hydraulik und Pneumatik brauchen Zehntelsekunden bis Sekunden, mit einem langen Ausläufer, bis der Endwert steht.

Der Satz, der daraus folgt, klingt banal und wird trotzdem ständig übersehen:

Der Funktionsaufruf kehrt zurück, bevor die Welt sich geändert hat.

Solange ein Team Software gegen Software testet, fällt das nie auf. Der Mock antwortet sofort. Erst am realen Aufbau zeigt sich, dass zwischen dem Setzen eines Zustands und dem Zustand selbst eine Zeitspanne liegt, die niemand modelliert hat.

Die Parkbremse

Ilya Lebedev hat auf LinkedIn ein Beispiel beschrieben, das den Fall auf zwei Funktionsaufrufe vereinfacht. Ein Fahrzeug hat mindestens zwei Bremssysteme: die hydraulische Betriebsbremse und die mechanische Feststellbremse. Ein naheliegender Entwurf legt zwei Funktionen offen, ServBrk und ParkBrk, und behandelt sie unabhängig voneinander. Daraus ergeben sich drei zulässige Zustände: beide gelöst und das Fahrzeug rollt, Betriebsbremse aktiv, Feststellbremse aktiv.

Der Wechsel von der Feststellbremse zur Betriebsbremse ist dann ein Zweizeiler. Feststellbremse lösen, Betriebsbremse anlegen. Logisch korrekt, auf der Zustandsebene lückenlos.

In der Realität liegt zwischen den beiden Anweisungen ein Fenster, in dem das Fahrzeug frei rollt. Der Aktor der Feststellbremse braucht seine Zeit, der Druckaufbau in der Hydraulik ebenfalls. Am Hang genügen wenige hundert Millisekunden, damit sich das Fahrzeug bewegt. Die Zustandsmaschine kennt diesen Zustand nicht, weil sie nur Sollzustände kennt.

Das ist kein Programmierfehler. Der Code tut, was im Entwurf steht. Der Fehler steckt im Modell. Es hat drei Zustände, das reale System hat mehr.

Abstraktion, die Zeit kennt

Der übliche Reflex lautet: mehr Tests. Aber das hilft wenig, weil das Problem in der Schnittstelle sitzt und nicht in der Abdeckung.

Ein Hardware Abstraction Layer ist die richtige Antwort auf das Kopplungsproblem. Er verbirgt physikalische Details und macht saubere Black-Box-Modellierung überhaupt erst möglich. Genau diese Stärke wird zur Falle, sobald die Abstraktion die Dynamik gleich mit verbirgt. Eine Schnittstelle, die nur ein release() kennt, behauptet implizit, das Lösen sei ein Ereignis. Es ist ein Vorgang.

Eine funktionierende Schnittstelle muss drei Dinge sichtbar machen:

1. Sollzustand und Istzustand getrennt. Der Befehl ist nicht die Wirkung. Wer beides in einer Variablen führt, hat den Fehler bereits eingebaut.
2. Übergänge als eigene Zustände. „Löst gerade“ und „legt gerade an“ gehören ins Modell, mitsamt der Frage, welche Nachbarzustände erlaubt sind und welche verboten.
3. Zeitschranken als Teil des Vertrags. Wie lange darf ein Übergang dauern, und was gilt bei Überschreitung? Ohne Timeout im Vertrag entscheidet das die Implementierung, und die entscheidet an jeder Stelle anders.

Damit verschwindet die freie Rollphase nicht. Sie wird sichtbar und damit absicherbar. Die Freigabe der Feststellbremse hängt dann am gemessenen Bremsdruck und nicht am abgesetzten Befehl.

Entscheidungen dorthin verschieben, wo Ändern billig ist

Damit steht die eigentliche Frage im Raum. Wenn die Praktiken der Software nicht übertragbar sind, was dann?

Die Antwort in der Software heißt: Änderungen billig machen. In der Hardware geht das nicht. Dort ist die Antwort: die Entscheidung dorthin verschieben, wo Ändern noch billig ist. Das ist das Modell, die Simulation, der Prototyp, der Prüfstand. Jede Entscheidung, die im Modell fällt statt im Werkzeugbau, spart genau den Faktor, um den der Werkzeugbau teurer ist.

Das funktioniert allerdings nur, wenn das Modell die Dynamik enthält. Eine Simulation, in der Aktoren sofort schalten, findet den Parkbremsenfehler nicht. Sie bestätigt den Entwurf. Frontloading ohne Zeitverhalten im Modell verlagert das Problem nur nach hinten, wo es teurer wird.

Deshalb greift eine reine Softwareplattform zu kurz. McKinsey empfiehlt Fahrzeugherstellern eine einheitliche Softwareplattform mit standardisierten Schnittstellen, um Komplexität und Integrationskosten zu senken. Ein Fahrzeug bleibt dabei ein Verbund aus Mechanik, Elektrik und Software. Diesen Denkfehler beim softwaredefinierten Fahrzeug habe ich an anderer Stelle ausführlicher beschrieben. Gebraucht wird eine Systemplattform, die Problemebene, logische und physikalische Lösungsebene abdeckt.

Martin Eigner hat in seiner Keynote über cybertronische Systeme einen Punkt ergänzt, der in Werkzeugdiskussionen gerne untergeht. Kein einzelnes System enthält alle Produktinformationen. Versionsmanagement, Änderungsmanagement und Anforderungsverfolgung laufen in Hardware und Software unterschiedlich, und daran ändert kein Werkzeug etwas, das behauptet, alles zu können. Was hilft, ist ein durchgängiges Datenmodell über mehrere Systeme hinweg.

Warten eliminieren

Die zweite Antwort betrifft die Organisation und nicht die Technik.

Joe Justice hat mit WikiSpeed gezeigt, dass ein Team innerhalb einer Woche ein straßenzugelassenes Fahrzeug entwickeln, bauen und testen kann. Im Interview bringt er den Kern auf einen Satz:

„Schnelle Hardwareentwicklung skaliert durch das Eliminieren vom Warten.“

Joe Justice, WikiSpeed im Interview mit Michael Jastram

Nicht die Physik bremst, sondern die Warteschlange davor. Ein Team wartet auf eine Freigabe, auf ein Testfenster, auf eine Zulieferantwort, auf eine Entscheidung aus einer anderen Abteilung. Diese Zeiten summieren sich auf ein Vielfaches der eigentlichen Bearbeitungszeit. Im Terminplan stehen sie nicht, weil kein einzelnes Gewerk sie verursacht hat.

Der Ausweg führt über die Architektur. Stabile Schnittstellen entkoppeln Teams, und entkoppelte Teams warten weniger. Joe Justice zieht dafür die Linie zu Conway’s Law. Wer Module baut, die ständige Abstimmung erzwingen, bekommt eine Organisation, die ständig abstimmt. Im zweiten Teil des Interviews beschreibt er ein Experiment über dreißig Tage, mit dem sich prüfen lässt, ob ein Unternehmen tatsächlich schneller wird oder nur agiles Vokabular übernommen hat.

Dazu kommt die Reihenfolge im Entwurf selbst. „Hardware first“ erzeugt Komplexität, weil beide Domänen isoliert arbeiten und die Software am Ende ausbügelt, was im Entwurf vermeidbar gewesen wäre. Parallelentwicklung von Hardware und Software ist keine Frage der Werkzeuge, sondern eine Frage der Zuständigkeit. Jemand muss die Kopplung zwischen den Disziplinen verantworten.

Fazit

Die Aufmerksamkeit folgt der Software, weil dort die sichtbaren Fortschritte entstehen. Der Takt des Produkts entsteht woanders. Er entsteht an Werkzeugvorläufen, Prüffenstern, Freigabeschleifen und an Aktoren, die ihre Zeit brauchen.

Daraus folgt kein Verzicht auf agile Methoden, sondern eine andere Reihenfolge. Zuerst die Frage, was eine Änderung an dieser Stelle kostet und wie lange das Feedback dauert. Danach die Praktik, die zu dieser Ökonomie passt. Zwei Wochen Sprintlänge sind keine Antwort auf sechzehn Wochen Werkzeugvorlauf. Kürzere Wege ins Modell und weniger Warteschlangen dagegen schon.

Ein Test für die eigene Architektur kostet zehn Minuten. Nimm die Spezifikation einer beliebigen Aktorschnittstelle und suche nach drei Angaben: gemessener Istzustand, Übergangszustände, Zeitschranke. Fehlt eine davon, steckt die freie Rollphase bereits im Entwurf. Sie wartet nur auf den passenden Hang.