24. Juli 2007
Diplomarbeit: Eine TargetLink-Bibliothek fürs „Ersatz-Gehirn" im Auto
Funktionsentwickler erzeugten mit Simulink/TargetLink C-Code, doch der lief nicht ohne handgeschriebenen Treibercode auf dem canAIDER-Steuergerät. Das Testen neuer Funktionen im Fahrzeug war dadurch langsam und fehleranfällig.
Eine TargetLink-Bibliothek, die den generierten C-Code ohne Entwickler-Handarbeit direkt auf dem canAIDER (TriCore TC1796) an die realen Hardware-Schnittstellen anbindet.
Bibliothek für Quellen & Senken an IO, ADC, PWM, SPI, I²C und CAN — Simulink-Modelle laufen direkt auf dem Steuergerät im Fahrzeug. Note 1,5; im Anschluss Übernahme als Entwicklungsingenieur.
Diplomarbeit an der Hochschule Esslingen (durchgeführt bei Gigatronik) · offizieller Titel: „Entwicklung einer Autocode-Schnittstelle zur Einbindung von Embedded-Hardware in TargetLink für verschiedene Mikrocontroller-Architekturen"
Nach dem selbstgebauten Betriebssystem kam die Frage: Wohin mit der Diplomarbeit? Die Antwort hatte, zugegeben, auch etwas sehr Pragmatisches.
Wie ich zu Gigatronik kam
Ehrlich? Der erste Auslöser war die Entfernung. Mein Praxissemester bei Leuze electronic in Owen bedeutete 100 km hin und zurück — jeden Tag. Ich wollte etwas mit kürzerem Anfahrtsweg finden. Über Prof. Dr. Joachim Goll an der Hochschule Esslingen wurde ich auf die Gigatronik Stuttgart GmbH aufmerksam: nicht weit weg, und voller spannender Themen in der Embedded-Entwicklung — allerdings mit modellbasierten Werkzeugen (MATLAB, Simulink, TargetLink). Genau das reizte mich: Ich wollte mein hardwarenahes Wissen nach oben erweitern, auf die Applikationsebene.
Gigatronik war 2007 ein Engineering-Dienstleister mit rund 400 Mitarbeitern, überwiegend im Automotive-Sektor. Im Fachbereich Komponenten-/Funktionsentwicklung suchte man einen Studenten mit Embedded-Erfahrung. Nach erfolgreichem Bewerbungsprozess ging es also auf zu neuen Ufern.
Der Star der Arbeit: das canAIDER
Um zu verstehen, was ich gebaut habe, muss man erst das canAIDER kennen — ein hochspezialisiertes Universal-Steuergerät für die Elektronikentwicklung in der Automobilindustrie. Der Name setzt sich aus CAN (dem Automotive-Bussystem) und dem englischen Aider („Helfer”) zusammen: ein All-in-One-Werkzeug, das Ingenieuren hilft, komplexe Elektronikarchitekturen im Auto schnell aufzubauen und zu testen. In der Praxis erfüllte es drei Rollen:
- Rapid Prototyping: Wollte ein Hersteller eine neue Funktion testen, bevor das Serien-Steuergerät existierte, wurde das canAIDER als „Ersatz-Gehirn” ins Fahrzeug eingebaut und die Funktion per Software darauf simuliert.
- Gateway: Autos sprechen viele Sprachen (CAN, LIN, FlexRay, Automotive Ethernet). Das canAIDER übersetzte Daten in Echtzeit von einem Bus in den anderen.
- Restbussimulation: Um ein einzelnes Steuergerät im Labor zu testen, täuschte das canAIDER ihm die Signale des „fehlenden restlichen Autos” vor.
Meine Aufgabe: das Modell direkt an die Hardware anbinden
Die Kollegen aus der Funktionsentwicklung hatten eine klare Vision: Es sollte eine eigene TargetLink-Bibliothek geben, mit der man für Quellen und Senken eine direkte Anbindung an die canAIDER-Hardwareschnittstellen ansteuern kann. Der von TargetLink erzeugte C-Code sollte ohne weiteres Zutun eines Entwicklers direkt auf dem canAIDER lauffähig sein und unmittelbar mit den Hardware-Schnittstellen — IO, ADC, PWM, SPI, I²C und CAN — kommunizieren.
Das Ziel dahinter: Anwendungssoftware zeitnah im Fahrzeug testen zu können. Der Funktionsentwickler zeichnet sein Modell in Simulink, drückt auf „Code generieren” — und das Ergebnis läuft direkt auf dem Ersatz-Gehirn im Auto, ohne dass jemand von Hand Treibercode gegen die Autocode-Ausgabe schreiben muss. Genau diese Lücke zwischen modellbasierter Welt und realer Hardware habe ich geschlossen.
Die Erkenntnis: niemand baut allein — und niemand muss alles können
Ich kam mit einer stillen Annahme nach Stuttgart. Weil ich gerade ein Echtzeitbetriebssystem selbst gebaut hatte, dachte ich, im Automotive-Umfeld kenne sich ohnehin jeder tief mit Betriebssystemen aus. Diese Annahme wurde bei Gigatronik sehr schnell korrigiert.
Die Realität sieht anders — und klüger — aus: Die meisten Entwickler bauen auf Komponenten und Bibliotheken auf, die andere bereits stabil, erfolgreich und vertrauenswürdig umgesetzt haben. Man muss das Rad nicht neu erfinden; man muss wissen, welchem Rad man vertrauen kann.
Und dann lernte ich die Funktionsentwickler kennen — eine ganz eigene Spezies Ingenieur. Diese Kolleginnen und Kollegen sind tief in Mechatronik, Kybernetik und Mathematik zu Hause. Werkzeuge wie MATLAB/Simulink versetzen sie in die Lage, lauffähigen Quellcode zu erzeugen, ohne klassische Programmierer sein zu müssen — ohne jedes Design Pattern und jede Eigenheit einer Programmiersprache zu kennen. Das war mir vorher schlicht nicht bewusst, und es wurde mir im Rahmen der Diplomarbeit rasch klar.
Genau darin lag der eigentliche Wert meiner Arbeit: Meine TargetLink-Bibliothek erlaubte es den Funktionsentwicklern, in ihrer Welt zu bleiben — bei Modellen, Regelungstechnik und Mathematik — während die hardwarenahe Programmierung darunter verlässlich und unsichtbar ihren Dienst tat. Arbeitsteilung, sauber gekapselt. Rückblickend war das meine erste Lektion in etwas, das mich bis heute begleitet: gute Plattformen machen andere produktiv, ohne dass sie wissen müssen, was darunter passiert.
Die andere Schule: knappe Ressourcen und harte Reviews
Neben der Technik habe ich hier zum ersten Mal gelernt, wie das Berufsleben wirklich funktioniert — und das war mindestens so wertvoll.
Meine erste Begegnung mit knappen Ressourcen: Der TargetLink-Lizenz-Dongle war teuer und rar. Ich musste oft warten, bis ein Funktionsentwickler ihn gerade nicht brauchte, bevor ich meine „Trockenübungen” endlich mit echter Codegenerierung gegen die Realität prüfen konnte. Dazu kamen erste innerbetriebliche (friedliche) Eskalationen, das regelmäßige Ringen um die Zeit von Betreuern, die eben nicht permanent verfügbar sind — und ein sehr anspruchsvoller Professor, der die Arbeit mehrfach reviewte. Sie so zu schreiben, dass sie auch akademisch sauber lesbar war, war alles andere als trivial.
Es war eine etwas härtere Schule. Aber genau die gehört zur Geschichte dazu: Ich habe aus vielen Disziplinen gleichzeitig gelernt — Technik, Kommunikation, Priorisierung, Ausdauer.
Das Ergebnis
Unternehmen und Hochschule waren zufrieden. Im Anschluss an die Diplomarbeit wurde ich als Entwicklungsingenieur im Bereich Komponentenentwicklung / Software-Entwicklung übernommen — drei Wochen nach der Diplomurkunde saß ich als Festangestellter am selben Schreibtisch. Aus der Studienarbeit war ein Betriebssystem geworden, aus der Diplomarbeit ein Job. Der Anfang meiner Automotive-Jahre.
Danke an die Menschen, die mir diesen Einstieg geebnet haben: Stefan Harms (mein Betreuer bei Gigatronik), Markus Hauser (Lead Developer, der mir das canAIDER erklärt und mich hardwareseitig unterstützt hat), Prof. Dr.-Ing. Walter Lindermeir (Betreuung seitens der HS Esslingen) und Prof. Dr. Joachim Goll, über den der Kontakt überhaupt erst zustande kam.