Überblick

In diesem kurzen Whitepaper möchten wir eine kurze Einführung geben, wie die Softwareentwicklung im Automobilbereich so komplex wurde, wie sie heute ist, und was wir tun müssen, um die Situation zu verbessern. Wir nähern uns dem Thema aus organisatorischer und tooling-bezogener Sicht.

Zunächst werden wir einen Blick darauf werfen, wie sich der Umfang von Software in den letzten Jahren verändert hat. Dann werden wir zeigen, wie nicht nur der Umfang, sondern auch die Komplexität am Beispiel der Funktionen eines ACC (Adaptive Cruise Control) gestiegen ist. Drittens werden wir sehen, wie solche komplexen Systeme derzeit entwickelt werden. Und schließlich werden wir die Herausforderungen zusammenfassen und darlegen, was getan werden muss, um sie zu entschärfen.

Historische Betrachtung: Warum ist Software viel komplexer geworden?

Beginnen wir unsere Analyse mit einer historischen Betrachtung der Softwaretechnik.

Software ist viel größer geworden

In den Anfängen wurde Software von sehr wenigen hochqualifizierten Experten entwickelt. Diese hatten das komplette Systemdesign und den Code im Kopf. Es gab keinen Koordinationsaufwand, keinen Informationsverlust zwischen verschiedenen Personen, geschweige denn zwischen Abteilungen von Unternehmen.

Seitdem hat die Software immer mehr an Umfang gewonnen. Die Abbildung zeigt einige Zahlen, um einen Eindruck davon zu erhalten, wie viel größer Software geworden ist.

Zum Vergleich: Die Bibel hätte ganz grob einen Wert von <0,8 (800.000k Wörter mit <10 Wörtern pro Zeile).

Softwaresysteme bestehen grundsätzlich aus zwei Arten von Einheiten: Verarbeitung und Transport. Dabei sind die verarbeitenden Einheiten stark hierarchisch und bilden sehr komplexe und zeitgebundene Netzwerke. Dies ist vergleichbar mit einem Logistiknetz in der Fertigung:

Und mit der Größe kommt das Problem der Konsistenz. Wir kennen das aus Büchern oder Filmen: Plötzlich wird in einem späteren Kapitel etwas geschrieben, das nicht zum Anfang passt. In einem Buch oder Film bemerken wir das normalerweise nicht, und wenn doch, ignorieren wir es. Bei einer Autosoftware kann dies zu einem Unfall führen.

Softwaresysteme sind viel komplexer geworden

Warum ist die Software so viel umfangreicher geworden? Frühere Software war eher prozedural und im Stil eines Expertensystems: Der Experte formalisierte sein Wissen in Form von Code. Der Code war eine Prozedur, die genau vorgab, was das System zu tun hatte. Zusammen mit Controllern reichte dies aus, um auf dem Mond zu landen und wieder zurückzukehren!

Aber diese Prozeduren konnten ihre allgemeine Situation und Umgebung nicht einschätzen – dies wurde erst durch die Entwicklung fortschrittlicherer Sensoren im Laufe der Zeit möglich. Diese Verfahren laufen also ihr Drehbuch ab und bleiben – möglicherweise katastrophal – stecken, wenn die reale Welt von den Annahmen abweicht. Moderne Software in einem Auto analysiert und bewertet ständig die Umgebung des Fahrzeugs, auch wenn sie nicht direkt für die Hauptaufgabe benötigt wird. Auf der Grundlage dieser Bewertung kann die Software auf unvorhergesehene Umstände reagieren.

Hinzu kommt, dass die Software mehr und mehr von ungeschulten Nutzern verwendet werden und mit ihnen interagieren kann. Diese können potenziell dumme Dinge tun – die Autosoftware muss trotzdem sicher bleiben!

Werfen wir einen Blick auf die Entwicklungsstufen des ACC – Adaptive Cruise Control als Beispiel:

Um auf den Vergleich mit dem Logistiksystem zurückzukommen: Beide sind zwar sehr komplex, aber das Logistiksystem hat viele menschliche Experten, die es am Laufen halten und im Falle von Störungen eingreifen. Das Softwaresystem muss all dies selbst bewältigen!

Aktuelle Fahrzeugsoftwaresysteme für Fahrfunktionen

Schauen wir uns nun genauer an, wie die Software strukturiert ist. Der exponentielle Anstieg der Komplexität kommt nicht nur von den einzelnen Funktionen wie ACC, die wir oben gesehen haben. Auch die Anzahl der Funktionen nimmt massiv zu, was im Grunde zu einer Komplexität3 führt: [Größe des Softwaremoduls] x [Komplexität der Funktion] x [Anzahl der Funktionen].

Wenn wir die 100 Mio. LOC aus dem Auto nehmen, ergibt dies ca. 2 Mio. Softwarefunktionen (Faustregel: nicht mehr als 50 LOC in einer Funktion). Wenn wir von 10 Funktionen in einem Modul und 10 Modulen in einer Gruppe und 10 Gruppen in einer Komponente ausgehen, erhalten wir sehr grob 200k Module, 20k Gruppen und 2k Komponenten.

In einem modernen Premium Fahrzeug finden wir nicht selten mehr als 150 Steuergeräte („ECU“ – Electronic Control Units = „Computer). Das gibt im Schnitt ca. 10 Komponenten pro ECU – wobei die Varianz erheblich ist. Einfache Steuergeräte wie z.B. eine Sitz-ECU haben oft nur eine Komponenten, während komplexe Fahrfunktionen eine hohe zweistellige Anzahl haben. Diese ECUs sind wiederrum durch eine Vielzahl unterschiedlicher Fahrzeug-Bussysteme verbunden und müssen als ein gesamter zeit-synchroner Verbund funktionieren.

Dies ist interessant, da man dies auf die Organisationsstrukturen von Unternehmen übertragen kann: normalerweise ist ein Team für eine Gruppe verantwortlich.

Ein Modul ist ein Teil der SW, der eine bestimmte Aufgabe erfüllt, z. B. das Auffinden eines Gesichts in einem Bild, während eine SWC eine komplexe Funktion wie das Erkennen und Verfolgen einer bestimmten Person realisiert.

Wie wird ein so komplexes System entwickelt?

Jetzt kommen wir zum Kern des Problems: Wir haben Hunderte von spezialisierten Entwicklungsteams. Jedes kennt sein Modul und vielleicht seine Funktion. Diese Teams sind auf zwei Dutzend Unternehmen aufgeteilt, OEM und TIER-1 bis -3. Allein in der OEM-F&E finden sich leicht 3000 Entwickler. Und das Gleiche gilt für jedes der großen TIER-1-Unternehmen.

Wie können wir das koordinieren?

Normalerweise gibt es einige wenige Architekten, die das System entwerfen und einen perfekten Überblick über das gesamte System und die Entwicklungszustände und Interaktionen haben sollen.

Da der Koordinationsaufwand zu groß ist, werden sie durch komplette Teams von Requirements Engineers ergänzt. Eine mittlere Antriebsfunktion kann mit 10.000 bis 50.000 einzelnen Anforderungen aufwarten. Anforderungen können sehr spezifisch sein wie eine mathematische Formel oder auch abstrakt wie “wenn ein Mensch auf der Straße erkannt wird, soll das Ego-Fahrzeug 1m Abstand halten und nicht schneller als 30km/h fahren”. Dies ist ein Betrag, bei dem das Schreiben auf der OEM-Seite und das Analysieren auf der Zuliefererseite zu einem eigenen Projekt wird. Jetzt ist keine Person mehr in der Lage, einen guten und detaillierten Überblick zu haben.

Erschwerend kommt hinzu, dass die Architekten mit vielen sekundären Koordinationsaufgaben belastet sind. Zum Beispiel die berühmt-berüchtigte “Generierung der RTE” – was im Grunde bedeutet, dass der Architekt die Schnittstellen von Hunderten von Modulen pflegen und alle Änderungen mit den Teams abgleichen muss und dann diese Änderungen von Tausenden von Datenspezifikationen in oft schwerfälligen Tools pflegen muss.

Eine weitere Schlüsselrolle kommt den Function Owners zu. Sie sollen die Entwicklung der einzelnen Module verstehen und koordinieren. Aber auch sie sind mit einer Menge sekundärer Koordinationsaufgaben belastet, wie dem Erstellen von Entwicklungstickets für jede Änderung, die der Architekt vornimmt.

All dies wird noch problematischer, wenn man bedenkt, dass an einem einzigen Entwicklungspfad leicht 5 verschiedene Unternehmen beteiligt sein können, von denen jedes sein eigenes geistiges Eigentum schützt.

Ein Blick auf die Werkzeuge von heute

Was sind Toolchains und welche gibt es heute?

Wenn man von “Toolchain” spricht, meint man in der Regel einfach eine Liste von verschiedenen Werkzeugen, die in einer Entwicklungsphase nacheinander eingesetzt werden. Diese decken typischerweise die Bereiche Anforderungen, Systemarchitektur, Softwarearchitektur, Codierung, Integration, Test und Entwicklung ab.

Es kann nicht gesagt werden, “welche Toolchains” es heute gibt, da sie von verschiedenen Anbietern gesammelt werden und die Zahl der möglichen Kombinationen riesig ist. Selbst große bekannte Anbieter decken nur einen kleinen Teil der benötigten Werkzeuge ab.

Was ist AUTOSAR? Und was sind AUTOSAR-Toolchains?

AUTOSAR ist in erster Linie eine Spezifikation darüber, wie die Softwarekomponenten auf einer Hardware laufen und miteinander interagieren sollen. Wenn man “AUTOSAR” sagt, ist oft nicht die Spezifikation gemeint, sondern eine der Implementierungen durch einen der bekannten Hersteller. In diesem Fall handelt es sich um ein Software-Framework, in dem die Software-Module integriert sind und die dann in einem definierten Prozess auf der Zielhardware zum Laufen gebracht werden.

Die Stärke von AUTOSAR ist, dass es für hunderte von Unternehmen funktioniert.

Die Schwäche von AUTOSAR ist, dass viele Firmen an der Entwicklung mitgewirkt haben und die resultierende Spezifikation ein riesiger Alleskönner ist, der sich nicht auf die eigentliche Absicht konzentriert, sondern die Wünsche aller Mitwirkenden erfüllen soll.

Was ist eigentlich ROS?

ROS ist im Grunde das Gegenteil: Es ist auch ein Rahmenwerk für die Integration von (Roboter-)Modulen, aber es wird von der Gemeinschaft betrieben und der Schwerpunkt liegt auf der schnellen und einfachen Realisierung von Software.

Der Nachteil ist, dass es nicht für einen geringen Hardware-Ressourcenverbrauch optimiert ist und funktionale Sicherheit und Determinismus keine Rolle spielen.

Zusammenfassung der Herausforderungen

Abschließend fassen wir die wichtigsten Herausforderungen aus der Sicht der Werkzeuge und der Organisation zusammen. Probleme in diesem Bereich führen zu Problemen in anderen Bereichen. Wenn z.B. ein überlasteter Architekt einen Widerspruch in der Architektur erzeugt – oder nicht erkennt -, führt dies später zu mehreren Fehlern auf verschiedenen Ebenen.

Lücken zwischen Menschen

Um diese Aufgabe zu bewältigen und die Komplexität zu beherrschen, müssen sehr viele Menschen zusammenarbeiten. Diese Menschen haben jedoch eine begrenzte geistige und zeitliche Kapazität. Diese Personen, nämlich Architekten, Function Owner, Requirement Engineers, Test Manager, FUSI-Manager investieren derzeit einen großen Teil ihrer Zeit in sekundäre Koordinationsaufgaben wie das Verteilen von Informationen, das Aufspüren von verlorenen Informationen, das Diskutieren von Schnittstellen und am schlimmsten: das Einpflegen von Daten in umständliche Tools.

•  Sie müssen durch Werkzeuge unterstützt werden, die sie von sekundären Koordinationsaufgaben entlasten, so dass sie sich auf ihre eigentliche Aufgabe konzentrieren können: die Verwaltung des massiv komplexen Softwaresystems.

Effizienz der Werkzeuge

Die oben beschriebene Situation wird durch die Tatsache verschlimmert, dass viele dieser Werkzeuge inhärente Mängel zweierlei Art aufweisen:

Prozess vs. Benutzerfreundlichkeit

Die Werkzeuge sind oft so konzipiert, dass sie einen formalen Prozess wie das V-Modell und Autosar perfekt reproduzieren. Diese Werkzeuge sind perfekt geeignet, um dem Benutzer die Möglichkeit zu geben, jede kleine Nuance der riesigen Autosar-Spezifikation zu optimieren. Aber 90% davon werden in der täglichen Arbeit nicht benötigt.

Es werden Werkzeuge benötigt, die sich auf die tatsächlich gelebte Entwicklungsinteraktion konzentrieren und nicht auf einen Prozess nach Vorschrift. Sie müssen sich auf Effizienz und Benutzerfreundlichkeit konzentrieren, um genau die Schlüsselpersonen von ihrer Last zu befreien, riesige Datenmengen manuell zu pflegen und abzugleichen.

Inkonsistente Werkzeugketten

Die verwendeten Tools stammen in der Regel von verschiedenen Anbietern und sind für unterschiedliche Zwecke konzipiert, die nicht aufeinander abgestimmt sind. Infolgedessen erfolgt der Datenaustausch häufig über den Export und Import von Daten, E-Mail, Excel-Tabellen, einige selbstgebastelte Skripte und viel manuelle Arbeit. Oft müssen dieselben Daten in mehreren Tools konsistent gepflegt werden.

Die Integration der Tools muss verbessert werden. Wir brauchen eine Tool-Kette aus einem Guss. Sie wird nicht von einem Anbieter kommen, aber dennoch müssen die Tools reibungslos integriert werden, damit gerade die Schlüsselkoordinatoren, die mit vielen Tools arbeiten, ihre wertvolle Arbeit nicht vergeuden.

Lücken zwischen den einzelnen Technologien: Remote-Hardware

Und schließlich besteht eine Herausforderung in der besonderen Verteilung dieser Hunderte von Entwicklungsteams über die halbe Welt. Ein Steuergerät wird an einem Ort entwickelt, die Basissoftware an einem zweiten und die Fahrfunktionen an einem dritten. Nun findet ein Tester einen Fehler in diesem Stück Hardware auf seinem Schreibtisch. Derzeit ist es ein großes Problem, dass die verschiedenen Teams keinen Zugriff auf die fehlerhafte Hardware haben. Ähnliche Situationen treten bei Testfahrzeugen auf der Straße auf. Viel Projektzeit wird durch falsch aufgezeichnete Daten vergeudet, nur weil eine Softwareversion oder ein Parameter der Hunderte von Modulen falsch war und niemand in der Lage war, dies zu überprüfen, während das Fahrzeug auf der Straße war.

Die gesamte Entwicklungsplattform muss cloudbasiert sein, damit jeder unabhängig von seinem physischen Standort auf alle relevanten Informationen zugreifen kann. Außerdem muss jedes Teil der Hardware Cloud-fähig sein, damit darauf zugegriffen werden kann. Zumindest während der Entwicklungsphase.

Fazit

Wenn vom autonomen Fahren die Rede ist, werden in der Regel die technischen Herausforderungen und Errungenschaften diskutiert. Aber auf der Werkzeug- und Prozessseite sind die Herausforderungen ähnlich groß – und im Falle eines Scheiterns vielleicht sogar noch kritischer. Ein technisches Problem kann getestet, identifiziert und behoben werden. Ein organisatorisches Problem ist eine ständige Fehlerquelle.