Software-Kolumne Abgefahren: SOP = Start of Problems

Mit dem „Start of Production” erreicht der automobile Entwicklungsprozess seinen Höhepunkt – ein dreijähriger Hürdenlauf über Quality Gates, Schadenstische, Lieferanteneskalationen, Entfeinerungsklausuren und Task Forces. Dann ist es endlich geschafft: Der Anlauf steht, das Fahrzeug läuft, das Team nimmt seinen Jahresurlaub.

Schöne alte Zeit

Der SOP war in der Vergangenheit so heilig wie Weihnachten am 24. Dezember. Und heute? Der Porsche Macan ist zwei Jahre zu spät, der Volvo EX90 läuft ins dritte Jahr Verzögerung und wird unvollständig beim Kunden eintreffen. Andere wie Fisker haben es gar nicht ins Ziel geschafft.

Zeitgleich gilt das Prinzip „one time right“ nicht mehr – mit dem SOP ist die Entwicklung mitnichten fertig. Das Bündel aus Hardware und Software wurde schon lange aufgeschnürt. Während Blech und Elektronik so lange wie möglich stabil bleiben wollen, entwickelt sich die Software zukünftig ständig weiter. Erstens, weil sie es technologisch kann – alles wird „over the air“ OTA-updatefähig. Und zweitens, weil sie es muss. Die Kunden akzeptieren weder Software-Fehler noch zehn Jahre Stillstand ohne neue Funktionen auf dem Display. Aber auch regulatorische Anforderungen üben Druck aus, Autos müssen z. B. über den gesamten Lebenszyklus bei Cyber-Sicherheitsrisiken aktualisiert werden.

Das setzt einiges voraus, eine nochmals großzügigere Auslegung der Hardware zum Beispiel, was Rechenpower, Speicherplatz und Bandbreiten angeht. Doch die Architektur muss darüber hinaus neu partitioniert werden: Das Infotainment und die Konnektivität verändern sich deutlich hochfrequenter als z. B. der Antriebsstrang. Und das ADAS/AD-System wird sich regional deut-licher als bisher unterscheiden.

Je besser die Allokation von Funktionen auf schnelle und langsam drehende Bereiche segmentiert ist, desto weniger Schwierigkeiten werden an den Schnittstellen entstehen.

Apropos Schnittstellen

Schnittstellen sind ein gutes Stichwort. Würden wir versuchen, in einem Bestandsfahrzeug ein System „herauszuschneiden“ und durch ein neues zu ersetzen – z. B. das Infotainment –, so würden wir schnell in Schwierigkeiten geraten. Zwar werden zum Beginn des Entwicklungsprozesses alle Systeme spezifiziert, doch im Laufe der drei Jahre werden viele Grauzonen detailliert, Probleme gefixt und Änderungen eingebracht. Vieles davon wird nur unzureichend rückdokumentiert. Und auch die Spezifikation von Schnittstellen beschränkt sich oft auf die Botschaften, die ausgetauscht werden – doch das ist nur die halbe Miete.

Die Schwächen der neuen Realität

Die neue Realität zeigt die Schwächen der bisherigen Vorgehensweise auf. Fahrzeuge können nach einem Online-Update nicht mehr bewegt werden, weil der Verbund nach dem Update nicht mehr zusammenpasst. Eine funktionale Änderung in Steuergerät A führt zu einem Fehler in Steuergerät B, weil aus Versehen nun ein Zeitlimit in der Buskommunikation gerissen wird, was aber niemand vorhersehen konnte. Updates misslingen, weil der Verbauzustand des Fahrzeuges anders als dokumentiert ist.

Noch gravierender: OEMs werden zunehmend externe Stacks einsetzen (VW mit Rivian und XPENG, Google Android breitet sich vom Infotainment ins Gesamtfahrzeug aus etc.). Dies erfordert große Weitsicht in der Architekturarbeit – und viel Disziplin im Schnittstellenmanagement.

Fire & forget funktioniert dann eben nicht mehr: Der SOP wird zukünftig nur noch ein Meilenstein im Life Cycle sein. Die Rolle der Gesamtarchitekten wird wichtig wie nie, und die Durchgängigkeit von Prozessen, Toolketten und Mindsets wird der Schlüssel für schnellere Produktentstehung sein.