1. Juni 2015
Die leise Klappe: Ein Jahr bis zur Serie — mit selbstgebautem SIL-Testbett
Von drei Jahren Serienentwicklungszeit waren zwei verstrichen, ohne dass die AUTOSAR-Softwarekomponente für die Kamera-Schutzklappe einen Verantwortlichen hatte. Es war kein Code da — und nur noch ein Jahr Zeit.
Einen akustikoptimierten Regelalgorithmus für die Kamera-Schutzklappe modellbasiert entwickeln, als AUTOSAR-SWC spezifizieren und trotz fehlender Testwerkzeug-Lizenzen serienreif absichern.
Nach rund neun Monaten lief die Komponente im Fahrzeug — inklusive Einklemmschutz und Unterstützung zweier grundverschiedener Aktorik-Varianten. Dazu ein eigenes SIL-Testbett (Artop, pytest, pandas, Jenkins), das den generierten Autocode nach Spezifikation prüfte.
Serienentwicklung im Automobil läuft in langen Zyklen — damals oft drei Jahre für eine Funktion. Als ich dazukam, waren zwei davon vorbei. Elektrobit hatte den Auftrag, eine bestimmte AUTOSAR-Softwarekomponente zu liefern, aber aus verschiedenen Gründen war nie jemand als Komponentenverantwortlicher eingesetzt worden. Es existierte kein Code. Und es blieb ein Jahr.
Zusammen mit meinem Product Owner Thorsten Hecht bin ich eingesprungen — er hatte den Draht in die Fachabteilung, ich das passende Profil: AUTOSAR-Softwarekomponenten kannte ich aus den RDU-Jahren gut, und die Fachabteilung Innenraum war bereits vollständig in dieser Welt angekommen. Der dritte Baustein war ein außerordentlich gut geschriebenes Pflichtenheft. Nach zwei, drei Iterationen hatte ich das Projekt verstanden. Das lief parallel zu meiner Rolle im ESP-Längsregler-Projekt.
Worum es ging: eine Klappe, die sauber hält
Rückfahrkameras kannte man damals schon aus vielen Fahrzeugen. Die Kollegen bei Daimler waren einen Schritt weiter: Das Einparken sollte auch bei schlechtem Wetter autonom funktionieren. Die Grundvoraussetzung dafür ist banal und entscheidend zugleich — die Kamera muss sauber sein. Eine Kamera, die während der Fahrt Dreck und Regen abbekommt, sieht am Ziel nichts mehr.
Die Lösung: Die Kamera sitzt hinter einer Klappe (bei Mercedes-Benz hinter dem Stern im Heckdeckel) und fährt nur dann heraus, wenn sie gebraucht wird. Den Rest der Zeit ist sie geschützt.
Die eigentliche Anforderung: Es sollte leise sein
Solche ausklappbaren Kameralösungen gab es schon. Die Besonderheit lag woanders. Stellen wir uns den typischen Besitzer einer Oberklasse-Limousine vor: oft jemand, der nicht selbst fährt, sondern hinten sitzt und arbeitet, während vorne ein Chauffeur lenkt. In diesem Segment war aufgefallen, dass das Geräusch des Elektromotors beim Ein- und Ausfahren als unangenehm empfunden wurde.
Die Anforderung lautete also: Ein Regelalgorithmus soll den Elektromotor so ansteuern, dass er — abhängig von den klimatischen Bedingungen rund ums Fahrzeug — nie über einen als unangenehm empfundenen Schallpegel hinausgeht. Eine akustikoptimierte Kamera-Schutzklappe. Ich fand das von Anfang an ein wunderbar konkretes Problem.
Dazu kam: Das Design sollte per Software für verschiedene Baureihen mit verschiedenen Aktoren funktionieren.
Zwei Wege, dieselbe Klappe zu steuern
Das Pflichtenheft sah zwei grundverschiedene Mechanismen vor, um zu wissen, wo die Klappe gerade steht. Beide muss man verstehen, um die Aufgabe zu verstehen — denn der Motor drückt von sich aus immer weiter, bis er ein Abschaltsignal bekommt, und blockiert dann mechanisch.
Dass ich in diesem mechanisch-elektrischen Grenzbereich zu Hause war, kam nicht von ungefähr — bei Gigatronik hatte ich mit dem PTC-Zuheizer genau solche Systeme betreut, inklusive Überstromerkennung. Und in den Elektrobit-Jahren war ich in modellbasierter Entwicklung und AUTOSAR deutlich stärker geworden. Die Aufgabe passte erstaunlich genau auf das, was ich mitbrachte.
Übrigens: Viele haben beim Thema „Kameraklappe” geschmunzelt und vermutet, so etwas sei eine Studienarbeit. Auf einem Labortisch würde ich sofort zustimmen. In der Serie nicht — dort zählen Verlässlichkeit, Absicherung und Prozessdokumentation, und genau das macht den Unterschied zwischen einem Aufbau, der funktioniert, und einem, der zehn Jahre in hunderttausenden Fahrzeugen funktioniert.
Das erste Problem: kein Prototyp
Die Zeit war knapp, und die ersten Wochen und Monate gab es keine reale Kameraklappe. Man arbeitet dann mit angenommenen Simulationsmodellen — und die waren suboptimal. Die ersten Ergebnisse aus der späteren Prototypen-Evaluierung verliefen entsprechend nicht wie erhofft.
Der Durchbruch kam, als bei Daimler ein Laboraufbau verfügbar wurde, auf dem sich ein Simulink-Modell über eine dSPACE MicroAutoBox betreiben ließ. Zusammen mit den Kollegen aus dem Innenraum entstand ein Aufbau mit zwei verschiedenen Kameraklappen-Systemen. Ab da wurde der Regelalgorithmus in deutlich kürzeren Iterationen von Mal zu Mal besser.
Das zweite Problem: Ich konnte nicht ständig im Labor sein
Der Laboraufbau war großartig, aber nicht ständig für mich verfügbar. Ich brauchte etwas, mit dem ich am eigenen Rechner zuverlässig arbeiten konnte — und zwar nicht nur mit dem Modell (Model in the Loop), sondern mit dem tatsächlich generierten C-Code (Software in the Loop). Denn das ist die Fassung, die später im Fahrzeug läuft.
Üblich wäre dafür TPT gewesen. Ich hatte weder das Know-how noch war eine freie Lizenz übrig — die Werkzeuge sind teuer. Also baute ich mir eins.
Fündig wurde ich bei Artop (AUTOSAR Tool Platform), einem offenen, Eclipse-basierten Projekt: Es konnte aus einer AUTOSAR-SWC-Beschreibung einen Testrahmen in C generieren. Diesen Rahmen ließ ich mit gcc zu einer Bibliothek bauen und rief ihn aus Python auf. Python war zu diesem Zeitpunkt längst mein Standardwerkzeug gegen Komplexität jeder Art, und ich wollte das mitbringen, was ich daran schätzte: pytest (vorher nosetests), Coverage-Messung, Reports — und einen Jenkins-Job, der nach jedem Commit alles durchlaufen lässt.
main()-Funktion des generierten Autocodes zyklisch über die Zeit auf, sammelt die Ausgangssignale und vergleicht sie gegen den SOLL-Datensatz — automatisiert bei jedem Commit.Zwei Erkenntnisse, die ich so nicht erwartet hatte
Erstens: Code-Coverage sagt bei generiertem Code fast nichts aus. Handgeschriebene Software ist schon der Lesbarkeit wegen voller Bedingungen, Schleifen und Kontrollstrukturen. Generierter Autocode ist oft eine einzige riesige main()-Funktion, gefüllt mit bitweisen Operationen. Ergebnis: Beim allerersten Testdurchlauf, in dem man gar nichts tut, steht die C0/C1-Coverage schon bei rund 90 %.
Die Konsequenz: Ich habe nicht auf Modulebene (Unit) getestet, sondern auf SWC-Ebene — also gegen das spezifizierte Verhalten der Komponente. Und ich habe die Testspezifikation zuerst geschrieben, als Python-Code, und gegen ein leeres Modell laufen lassen. Am Anfang war alles rot. Erst dann entstand das Modell, Test für Test. Das ähnelt dem, was man heute Spec-Driven Development nennt — nur war meine Spezifikation nicht in Prosa formuliert, sondern in Python. Ich bin ein Mensch und kann Python lesen, insofern war die Anforderung „menschenlesbar” für mich erfüllt.
Zweitens: Modellwelt denkt in Signalen, nicht in Variablen. Als Softwareentwickler denkt man in Variablen und Zuständen. Modellbasierte Entwicklung denkt in Signalen und Signalverläufen über die Zeit. Das war anfangs eine echte Umstellung — bis ich merkte, dass genau dafür in Python etwas bereitsteht: über matplotlib und numpy/scipy landete ich bei pandas, das den Output der Simulink-Signalgeneratoren als Datensatz einlesen, numerisch ablegen und anschließend gegen die im SIL-Test gesammelten Ausgangssignale abgleichen konnte.
Ein angenehmer Nebeneffekt: Das Projekt war vollständig in Festkomma-Arithmetik umgesetzt, Fließkommazahlen waren tabu. Damit war es unkritisch, dass ich lokal mit gcc baute, obwohl fürs Zielsteuergerät ein anderer Compiler zum Einsatz kam.
Zustände, Sonderfälle und ein Finger
Die Klappe war zustandsgesteuert, und der Algorithmus musste einige Sonderfälle beherrschen — allen voran den Einklemmschutz: Wenn während des Schließens ein Gegenstand in die Klappe gerät, muss das erkannt und die Bewegung zurückgeführt werden. Das Prinzip kennt man von elektrischen Fensterhebern.
Da ich kein Regelungstechniker bin, sondern aus der Softwareentwicklung komme, habe ich in dieser Zeit Stateflow (Teil der Simulink-Werkzeugkette) sehr gerne eingesetzt: Damit ließen sich Zustände sauber verwalten und prüfen — eine Denkweise, die mir deutlich näher lag als reine Regelungstechnik.
Nach etwa neun Monaten war aus dem Prototyp eine Serien-Softwarekomponente geworden. Und dann kam einer der schönsten Momente meiner Laufbahn.
Die Fachabteilung Innenraum konnte die erste Umsetzung in ein Fahrzeug flashen, und ich wurde zum Management-Meeting mit Vorführung dazugeladen — Leute, mit denen ich sonst kaum zu tun hatte, in einer großen Prototypenhalle. Dort stand ein damals noch nicht veröffentlichtes Coupé, für mich zum ersten Mal überhaupt zu sehen. Und darin verbaut: der Stern im Heck mit der aktuellen Version meiner Schutzklappe.
Der Ablauf war der Standard aus dem Prüfkatalog. Fahrzeug starten — Klappe bleibt unten. Rückwärtsgang einlegen — Klappe fährt hoch, alle horchen hin. Bei angenehmen 21 °C in der Halle ist das natürlich nicht mit einem Klimakammertest vergleichbar, aber Öffnen und Schließen wurden deutlich leiser empfunden als zuvor. Vorwärtsgang, ein paar Sekunden warten — Klappe schließt. Alles in Ordnung.
Nächster Test: Einklemmschutz. Wieder Rückwärtsgang, Klappe fährt auf. Ein Kollege wollte gerade einen Gegenstand holen, um ihn in die Klappe zu halten — ich hielt einfach meinen Finger hinein. Der Testfahrer legte den Vorwärtsgang ein, die Klappe fuhr zu, klemmte meinen Finger ganz sachte ein und fuhr sofort wieder auf. Kurz waren alle ziemlich baff, dass ich mir da so sicher war. Dann gab es Applaus.
Was man an so einer Klappe alles übersieht
Was ich hier beschrieben habe, ist die Hauptfunktion. Vieles andere lässt sich schlechter vorführen und war trotzdem aufwendig. Die Kalibrierung zum Beispiel: Fährt die Klappe nicht exakt vollständig auf, ist das Blickfeld der Kamera beschnitten — und das kann dazu führen, dass das automatische Einparken ausfällt. Hinter einer kleinen mechanischen Komponente kann ein großes, teures System komplett stehen bleiben. Dazu kommen diverse Szenarien in Diagnose und Fehlerspeicher, die ebenfalls umgesetzt wurden.
Was ich mitgenommen habe
Rückblickend war ich für dieses Projekt fast auffällig gut vorbereitet — nicht wegen eines einzelnen Skills, sondern weil sich mehrere Linien trafen:
- Mangel an Werkzeug-Lizenzen kannte ich schon aus meiner Diplomarbeit (damals fehlte der TargetLink-Dongle). Die Reaktion war dieselbe: selbst bauen statt warten.
- Elektrotechnische Sachverhalte und Laboraufbauten kamen aus der Gigatronik-Zeit.
- AUTOSAR-Architektur und SWC-Integration aus den RDU-Jahren.
- Python und Open Source aus AIM — inklusive der Selbstverständlichkeit, ein offenes Projekt wie Artop als tragende Säule einzusetzen.
Die Lektion, die ich am häufigsten weitergebe: Eine Metrik, die man nicht hinterfragt, ist gefährlicher als gar keine. 90 % Coverage sahen großartig aus und bedeuteten nichts. Erst die Frage „Was genau soll diese Komponente eigentlich tun?” — zuerst als Test geschrieben, dann implementiert — hat echte Sicherheit gebracht. Vom Rapid Prototyping an der MicroAutoBox bis zur durchgetesteten Seriensoftware war am Ende alles drin.
Danke
Herzlichen Dank an Thorsten Hecht, meinen Product Owner in diesem Projekt — für den Zugang zur Fachabteilung, die Rückendeckung in einer knappen Terminlage und dafür, dass wir gemeinsam in ein Projekt eingestiegen sind, bei dem zwei von drei Jahren bereits verstrichen waren.