1. August 2011
Von C-Code zu UML: Ein Architekturmodell für Fahrerassistenzsysteme
Über Jahre gewachsene Fahrerassistenzsoftware mit vielen spezialisierten Modulen, unterschiedlichsten Fachabteilungen und Konventionen — aber ohne durchgängige, abteilungsübergreifende Architekturdokumentation.
Ein konsistentes, technologieunabhängiges Gesamtsystem-Modell in Enterprise Architect etablieren, heterogene Schnittstellendaten (C-Header, ARXML, Excel) automatisiert einlesen und Systemtransparenz für Serie und Vorentwicklung schaffen.
Eine Python-Sync-Toolchain (lxml, AST-Analyse), die Schnittstellen harmonisierte, Diffs berechnete und zur Brücke zwischen Serien- und Vorentwicklung wurde — bei spürbar gemischter Akzeptanz im Entwickleralltag.
Als ich im August 2011 bei Elektrobit Automotive in Böblingen anfing, kam ich direkt in einen zentralen Bereich: die Entwicklungspartnerschaft zwischen Elektrobit und der Daimler AG im Fachbereich Driver Assistance. Es ging um die kontinuierliche Weiterentwicklung von Fahrerassistenzsystemen für Längs- und Querführung — von Komfortfunktionen wie Tempomat und Abstandsregeltempomat (bei Mercedes-Benz als DISTRONIC bekannt) bis zu sicherheitskritischen Systemen für den aktiven Insassenschutz. Mehr als 300 Ingenieure und Spezialisten arbeiteten parallel daran: Regelungstechniker, Elektronik- und Mechanik-Ingenieure, Tester, Integratoren, Konfigurations- und Releasemanager. Das war eine ganz andere Größenordnung als alles, was ich bei Gigatronik bis dahin erlebt hatte.
Warum Daimler einen Software-Partner suchte
Seit dem ersten Tempomaten/Begrenzer und dem Abstandsregeltempomat (1999) war die Funktionsvielfalt kontinuierlich gewachsen: Spurwechsel-/Totwinkel-Assistent, Spurhalte-Assistent, Müdigkeitserkennung, autonome Notbremsung, PRE-SAFE-Systeme. Mit jeder Generation stieg die Softwarekomplexität im Fahrzeug. Anfang 2010 entschied Daimler, sich nicht selbst als Softwareschmiede zu verstehen, sondern einen Partner zu suchen — und wählte nach einem längeren Auswahlverfahren Elektrobit, einen der Pioniere für AUTOSAR-Basissoftware in der Automobilindustrie.
Der Einstieg: VPU und Modellintegration
Meine ersten Monate liefen über die VPU — damals im Automotive-Kontext gebräuchlich für Vision/Video Processing Unit —, ein bereits in Serie befindliches Steuergerät, dessen Funktionen laufend um neue Features und Baureihen-Varianten erweitert wurden. Hier lernte ich die Modellintegration:
Ein Steuergerät hat mehrere Zulieferer, um die Kosten niedrig zu halten — damit eine Komponente wie die VPU trotzdem konsistente Entscheidungen treffen kann, müssen Änderungen je nach Funktion über verschiedene Fachabteilungen und Zulieferer hinweg koordiniert werden. Dazu kommt ein komplexes Variantenmanagement: Radar oder Kamera oder Ultraschall, welcher Sensorhersteller, welche Baureihe, welche K-Matrix. Im Vergleich zu allem, was ich bislang gemacht hatte, war die schiere Menge an Prozessen, Werkzeugen, Ansprechpartnern und Artefakten ein Vielfaches größer — und genau das war der Grund, warum Elektrobit überhaupt gebraucht wurde: mehr Automatisierung, mehr Absicherung, mehr Qualität in einer historisch gewachsenen Softwarelandschaft.
RDU3: Reverse-Architektur und die Kunst der passenden Signalwahl
Nach ein paar Monaten Einarbeitung ergab sich eine attraktive Chance: Ich hatte bei Gigatronik bereits mit Enterprise Architect gearbeitet und eine Zertifizierung darin. Der Bedarf an konsistenter Architekturdokumentation wuchs — sowohl um Einarbeitungszeiten zu verkürzen als auch um die vielen Abstimmungsrunden zu reduzieren, in denen Experten diskutierten, wie eine Funktion am besten umzusetzen sei. Zusammen mit meinem Elektrobit-Kollegen Matthias Brachmann übernahm ich den Aufbau der Reverse-Architekturdokumentation für die RDU3 (das nächste Steuergerät nach der VPU).
Der AUTOSAR-Standard legte zwar die formalen Schnittstellen fest, aber das WHY dahinter — warum wird Signal A von der Kamera genutzt und nicht Signal B vom Radar — stand nirgends konsistent dokumentiert. Genau diese Kontext-Ebene sollte unser Modell liefern. Ein Beispiel aus der Praxis:
- Autobahn, ~130 km/h (DISTRONIC): Für eine komfortable Längsregelung braucht der Regler einen ruhig gefilterten, entprellten Geschwindigkeitswert, der kurze mechanische Schwingungen ausgleicht.
- Rangieren/Parken, ~2 km/h: Hier ist ein gefilterter Wert ungeeignet. Gebraucht werden die ungefilterten Einzelraddrehzahlen aller vier Räder plus Lenkwinkel — mit minimaler Latenz.
Unter der Haube: die Python-Sync-Toolchain
Um C-Header, ARXML und Excel-Spezifikationen aus ganz unterschiedlichen Fachabteilungen automatisiert ins Enterprise-Architect-Modell zu bekommen, bauten Matthias und ich über Monate eine Automatisierungslösung, die wir intern liebevoll ea-driverassistance-reverse-architecture-sync tauften.
Drei Dinge machte das Tooling: Performance-Parsing großer ARXML-Dateien und EA-Exporte mit lxml; Struktur-Analyse der C-Header per Python-AST, um überhaupt erst zu verstehen, wonach wir suchten; und eine automatisierte Diff-Analyse vor jedem Re-Import (neue Schnittstellen, geänderte Datentypen, entfallene Signal-Ports), damit Änderungen bei neuen Software-Releases nachvollziehbar blieben.
Was nicht auf Anhieb funktionierte
So aufgeräumt, wie sich das jetzt liest, war der Alltag nicht. Der Quellcode kam aus verschiedenen Fachabteilungen mit ganz unterschiedlichen Konventionen: mal war eine Funktion sauber als eigene AUTOSAR-Softwarekomponente (SWC) abgebildet, mal steckten mehrere Funktionen in einer „Superkomponente” und waren auf SWC-Ebene kaum zu unterscheiden. Der von TargetLink generierte C-Code einer einzelnen Komponente konnte 200 und mehr Ein- und Ausgangssignale haben, dazu noch interne Messtechnik-Signale für die Entwickler. Header-Dateien sahen von Fachabteilung zu Fachabteilung unterschiedlich aus — der Präprozessor tat sein Übriges. Es hat mehrere Wochen gedauert, bis wir überhaupt eine brauchbare Guideline hatten, wie man dieses System technologieunabhängig in Enterprise Architect abbilden kann.
Für die Komponentenbeschreibungen selbst war ich auch nicht der Fachexperte: Ich bin kein Fahrzeugdynamiker, sondern Softwaremensch. Also haben wir die Steckbriefe erst nach bestem Wissen selbst erstellt und dann eine Interview-Serie mit den jeweiligen Funktionsentwicklern zum Review gestartet — Termine, Vorbereitung, Kontaktaufnahme, über Monate hinweg. Ich habe mich in dieser Zeit oft wie ein technischer Reporter gefühlt, der von Abteilung zu Abteilung zieht und fragt: „Was macht deine Komponente eigentlich, und warum?”
Und nicht jeder fand das Modell hilfreich. Enterprise Architect hat seinen Charme für Leute, die täglich damit arbeiten — für Kollegen, die nur gelegentlich nachschlagen wollten, war es zusätzlicher Overhead: eine weitere komplexe Software neben den ohnehin schon zahlreichen Werkzeugen und Prozessen. Die Rückmeldung war teilweise ernüchternd — mehr Pflegeaufwand, ohne dass jeder den Mehrwert im Tagesgeschäft spürte. Erst in der Vorentwicklung fand das Modell sein eigentliches Publikum.
RDU4-Vorentwicklung: die Brücke zur Serie
Serienentwickler an der RDU3 arbeiteten in einem Drei-Jahres-Zyklus auf die nächste Serienfreigabe hin — knapp genug für ein sicherheitskritisches System. Die Vorentwicklung an der RDU4 dachte in einem Horizont von bis zu sechs Jahren vor Serienanlauf, nicht jede erforschte Funktion schaffte es später überhaupt in Serie. Die Schnittstelle zwischen beiden Welten funktionierte in der Vergangenheit nicht optimal: Vorentwickler prototypten gerne in anderen Sprachen und Umgebungen, ohne dass Aspekte aus der Serienentwicklung einflossen — schnell zum Prototyp, aber mit wenig Übernahmewert für die Serie.
Über zweiwöchentliche Sync-Updates hatte die Vorentwicklung einen verlässlichen Wissensstand zu den aktuellen Serien-Schnittstellen. Automatisierte Diffs machten konkrete Rückfragen an die Serienentwickler möglich, statt Meetings buchen zu müssen — genau das Fallbeispiel von oben: „Warum genau dieses Geschwindigkeitssignal und nicht ein anderes?” Umgekehrt stieg die Bereitschaft der Vorentwicklung, ihre neuen Komponenten früher und konkreter im Modell zu entwerfen — unser Tooling generierte daraus C-Header und TargetLink-Schnittstellen für die Prototypen-Erprobung, was die spätere Übergabe an die Serie erleichterte.
Was ich mitgenommen habe
Nach etwa acht Monaten stand eine statische UML-Architektur für den Fachbereich Driver Assistance — als HTML/PDF-Dokumentengenerator auch firmenintern nutzbar, um Kontext über das Gesamtsystem zu vermitteln.
Der größte persönliche Mehrwert war für mich Python. Seit dieser Zeit ist es meine Hauptsprache geblieben — über lxml, AST-Analyse und automatisierte Toolchains hinweg begleitet mich der Zen of Python bis heute als Kompass: explicit is better than implicit — explizite Schnittstellen schaffen Verlässlichkeit über Abteilungsgrenzen hinweg; simple is better than complex — eine Architektur muss nicht jedes Detail abbilden, präzise Schnittstellenverträge und kompakte Steckbriefe reichen oft aus.
Und die größere Lektion: Ein Architekturmodell ist nur so gut wie sein Publikum. Für die Vorentwicklung war es eine echte Brücke; für Kollegen im engen Tagesgeschäft der Serie war es manchmal zusätzlicher Ballast. Beides war eine berechtigte Reaktion — und beides zu hören, statt nur das positive Feedback zu glauben, war Teil der Lektion. Erfolgreiches Tooling entsteht nicht am Schreibtisch allein, sondern im Dialog — die Fachinterviews waren dafür der Schlüssel, aus Quellcode gelebtes System-Wissen zu machen.
Danke
Herzlichen Dank an Matthias Brachmann, meinen Elektrobit-Kollegen, mit dem ich dieses Architekturmodell und die Python-Toolchain gemeinsam aufgebaut habe — für die vielen gemeinsamen Monate am Whiteboard, im Code und in den Fachinterviews.