"Graphische Programmierung ist kein Malprogramm"

Der Anteil an Elektrik/Elektronik inklusive Software im Automobil wächst. Gestiegene Rückrufaktionen, die ursächlich mit diesem Thema in Verbindung gebracht werden, haben ihre Fehleranfälligkeit in die Diskussion gebracht. all4engineers sprach mit Oliver Predelli, Vice President Engine Controls bei der IAV GmbH, unter anderem über den Status quo der Software-Entwicklung und ihr Verbesserungspotenzial, die mangelnde Kompatibilität von Maschinenbau und Informationstechnologie sowie Lösungsansätze für dieses Problem.

Herr Predelli, ist Software-Entwicklung mittlerweile besser als ihr Ruf?
Ja, die Software-Entwicklung ist besser als ihr Ruf. Marktstudien beziffern zwar den Anteil der Elektronik an Autopannen auf über 50 Prozent. Wenn man sich die Zahlen jedoch genau anschaut, sind es insbesondere Bordnetzkomponenten, die hohe Ausfallzahlen haben, nicht die Steuergeräte mit ihrer Software.
Durch die zunehmende Verbreitung von Steuergeräten im Fahrzeug müssen Zulieferer immer mehr Kompetenzen bei der Elektronikentwicklung aufbauen. Am Kombiinstrument lässt sich das ganz anschaulich verdeutlichen. Hatte das Kombiinstrument früher wenige Anzeigeinstrumente, so ist es heute zu einer zentralen Fahrzeugeinheit geworden. Es hat viele Funktionen und Schnittstellen unter anderem zum Fahrerinformationssystem und Bordcomputer, zum Bussystem, Radio und Navigationssystem sowie Telefon, Lenkradschalter und zur Wegfahrsperre.
Doch auch die etablierten Steuergerätelieferanten, zum Beispiel für Motorsteuergeräte, müssen individuelle Wünsche der Automobilhersteller und Anforderungen der Emissionsgesetzgebung in immer kürzerer Zeit in Serie bringen. Alle drei Faktoren, neue Lieferanten, kürzere Lebenszyklen und zunehmende Variantenvielfalt, sind für das Qualitätsmanagement eine große Herausforderung.

Was tut ein Entwicklungsdienstleister wie die IAV gegen das Thema Fehleranfälligkeit, das in der Vergangenheit oftmals durch "Software-Entwicklung auf Zuruf" aufgetaucht ist?
Wichtig ist, in einem schnelllebigen Software-Entwicklungsprozess, trotz kurzfristig umzusetzender Anforderungsänderungen, nicht den Überblick zu verlieren. Das geht bereits mit wenigen relevanten Arbeitsanweisungen wie dem Führen einer Change-Request-Liste, einer Versionsverwaltung, dem konsequenten Durchführen von Reviews und dem Testen der Software vor jeder Kunden- Ablieferung.
"Software-Entwicklung auf Zuruf" wird es weiterhin geben. Es ist bisweilen sogar notwendig, schnell zu reagieren. Wenn zum Beispiel auf der letzten Wintererprobung vor dem Serienstart festgestellt wird, dass eine wesentliche Motorfunktion optimiert werden sollte, dann greift der Funktionsverantwortliche zum Telefon.
Wir unterstützen unsere Kunden in allen Aspekten der Software-Erstellung. Dabei legen wir besonderen Wert auf die Codegenerierbarkeit, Testbarkeit, Wartbarkeit und Applizierbarkeit der Funktionen. Die Kundenanforderungen werden in einem "elektronischen Lastenheft" erfasst und kontinuierlich mit den Software-Modellen und dem Code abgeglichen. Bei Modul- und Integrationstests verlassen wir uns nicht allein auf das Geschick des Software-Ingenieurs, sondern nutzen Werkzeuge zur automatischen Testfallerzeugung und Testdurchführung.

Was ist erforderlich, um Software für Motorsteuergeräte im Automobil zu entwickeln?
Um Software für Motorsteuergeräte zu entwickeln sind zunächst die handwerklichen Fähigkeiten notwendig, die in einem Entwicklungsprozess beschrieben werden, wie die Anforderungsanalyse, die Modellierung, die Codierung und die Dokumentation; dann der Qualitätsprozess mit verbindlicher Festschreibung von Reviews und Testplänen, der Testdurchführung, Versionsverwaltung und dem Änderungsmanagement. Und schließlich ist das Systemverständnis vonnöten: Wofür wird eine Motorfunktion gebraucht und wie wird sie in eine bestehende Funktionstopologie eingefügt, welche Schnittstellen gibt es zu dieser Funktion und wie wird sie motor- sowie fahrzeugspezifisch bedatet?

Automobilhersteller sind in zunehmendem Maße bestrebt, eigene Software zu schreiben. Ist das der richtige Weg, Probleme aus der Vergangenheit zu lösen oder ist der "klassische Maschinenbauer" mit der Materie schlicht überfordert?
Das Selbermachen hat den Vorteil, technische Innovationen voranzubringen, ohne dass dieses Wissen zu Wettbewerbern gelangt. Aber man muss die Know-how-Bündelung und die Anforderungen an eine Produktentwicklung gegeneinander abwägen. Eine kreative Funktion herzuleiten und im Rapid-Prototyping zum Laufen zu bringen, erfordert andere System- und Prozesskenntnisse als die Implementierung einer Seriensoftware in ein Steuergerät. Auf jeden Fall ist es einfacher, schneller und in Summe weniger fehleranfällig, wenn ein Automobilhersteller mehr Verantwortung bei der Steuergeräteentwicklung übernimmt. Spezifikationen lassen sich auf kurzem Wege abstimmen, Software-Teilfunktionen sind leichter auf verschiedene Steuergeräte-Varianten übertragbar, Kommunikationsprotokolle können über die gesamte Bustopologie hinweg vereinheitlicht werden. Der Abgleich- und Betreuungsaufwand mit diversen Steuergeräte-Lieferanten wird verringert. Die Fehlinterpretationen von Spezifikationen nehmen ab, wenn der Automobilhersteller fertige Objects für Schlüsselfunktionen an seine Steuergeräte-Lieferanten verteilt.

Welche Werkzeuge stehen dem OEM derzeit zur Verfügung, eigene Software für Motorsteuergeräte zu entwickeln, und wie sind diese zu bewerten?
Inzwischen hat sich die grafische Programmierung weitestgehend durchgesetzt. Hierbei werden Funktionen in Form von Blockschaltbildern und Zustandsautomaten dargestellt. Die Funktionen können "offline", also am PC, oder "online" im Fahrzeug erprobt werden. Werkzeuge hierfür gibt es von verschiedenen Anbietern. Sie sind gut verfügbar und nach kurzer Einarbeitung verhältnismäßig leicht bedienbar.
Wir beobachten seit längerer Zeit eine überproportionale Zunahme neuer Steuergerätefunktionen. Jede neue Steuergerätegeneration kommt, kaum dass sie verfügbar ist, an Speicherplatz- und Programmlaufzeitgrenzen. In der IAV halten wir unsere Funktionsentwickler an, sich zunächst Gedanken über die Strukturierung und Modularisierung einer Funktion zu machen, bevor mit der grafischen Programmierung begonnen wird. Wir arbeiten intensiv an neuen Reglerstrukturen, um Code, Rechenzeit und Bedatungsaufwand zu minimieren. Auf keinen Fall darf man sich dazu verleiten lassen, die grafische Programmierung als "Malprogramm" aufzufassen. Eine systematische Vorgehensweise, Sorgfalt und technische Kompetenz sind unumgänglich. Ich erwarte von unseren Systementwicklern weiterhin, dass sie die Differenzengleichung für einen digitalen PID-Regler aufschreiben können.
Ist die Funktion spezifiziert, kommt man über weitere handelsübliche Programme unter anderem zur Autocode-Generierung und Handcodierung, Compilierung und Integration sowie Bedatung und Versionsverwaltung. Die IAV hat eigene Entwicklungsumgebungen, um die einzelnen Schritte beim Software-Engineering miteinander zu vernetzen.

Bitte sagen Sie uns ein paar Worte zu Möglichkeiten und Grenzen der Autocode-Generierung.
Ich denke, die Autocode-Generierung wird sich mittelfristig gegenüber der Handcodierung durchsetzen. Allerdings ist die automatische Code-Erzeugung anhand eines Blockschaltbildes oder eines Zustandsautomaten alles andere als trivial. Die Hersteller dieser Entwicklungswerkzeuge arbeiten seit vielen Jahren an der Verbesserung dieses Verfahrens. Nicht jedes mitgelieferte Element einer Funktionsbibliothek ist autocodetauglich. Ferner kann man Funktionsstrukturen aufbauen, die nicht eindeutig automatisch interpretierbar sind. Wesentliche Parametrisierungen des Modells, zum Beispiel Normierungen, Quantisierungen und das Sequencing müssen ebenfalls festgelegt sein, bevor man codieren kann. Die Einhaltung strenger Modellierungsrichtlinien sind die Grundvoraussetzung dafür, dass sich ein Modell in der "Floating-point Offline-Simulation" genauso verhält wie der spätere Festkomma-Code im Steuergerät.
Wir haben in der IAV seit mehreren Jahren eigene Modellierungsrichtlinien für diverse Autocode-Programme. Die Modellierungsrichtlinien sind in ihren Beschränkungen strenger als etwa die MAAB Style Guides. Selbstverständlich müssen je nach Anwendungsfall zudem MISRA- und SIL-Standards beachtet werden. Um den Software-Entwickler bei seiner Arbeit zu unterstützen, haben wir automatische Regel-Checker im Einsatz, die ähnlich einer Rechtschreibkorrektur bei Textverarbeitungsprogrammen darauf achten, dass die Modellierungsrichtlinien eingehalten werden.
Es kommt immer noch vor, dass wir Compilerfehler entdecken. Und noch häufiger finden wir Fehler des Autocode-Generators, die dann in verfeinerten Modellierungsrichtlinien berücksichtigt werden müssen. Für die grafische Programmierung erlauben wir unseren Software-Entwicklern nur die Verwendung abgeprüfter Bibliothekselemente. Hierdurch versuchen wir, die Zahl der durch das Werkzeug verursachten Fehler möglichst gering zu halten. Trotzdem ist der Testaufwand bei Autocode-Generierung bisweilen höher als bei einer vergleichbaren Handcodierung. Ein möglicher Zeitvorteil der Autocode-Generierung wird hierdurch wieder aufgehoben.

Wie kann ein Hersteller im Hinblick auf Engineering und Support den Wettbewerbsvorteil nutzen, wieder Mechanik- und Steuergeräteentwicklung im eigenen Hause zu realisieren, ohne einen Qualitätsabfall zu riskieren?
Wie bereits erläutert, stellt das Software-Engineering hohe Ansprüche an die Einhaltung eines strengen Entwicklungsprozesses. Die Mitarbeiter brauchen Erfahrung und Routine. Wir haben daher in der IAV eine Trennung zwischen der Funktionsspezifikation auf der einen und der Software-Entwicklung auf der anderen Seite. Für die Funktionsspezifikation braucht man die Kenntnis des Motors und der Regelungstechnik. Für die Softwareentwicklung braucht man die Kenntnis der hierfür erforderlichen Prozesse und Werkzeuge. Es gibt wenige Mitarbeiter, die beide Qualifikationen in der erforderlichen Tiefe besitzen. Wir arbeiten also immer in gemischten Teams. Bei vielen unserer Auftraggeber sehen wir ebenfalls diese Arbeitsteilung.
An einer Steuergeräteentwicklung ist nichts Mystisches. Man muss die Entwicklungsprozesse kennen, einhalten und überwachen sowie die Mitarbeiter kontinuierlich bezüglich der Prozesse und Werkzeuge schulen.

Software-Entwicklung gilt besonders im Vergleich zur Automobilentwicklung, betrachtet man allein die Entwicklungszyklen, generell als ungleich schnelllebiger. Was muss in Zukunft geschehen, um die Systematik beider Felder besser miteinander zu verzahnen?
Die Software-Entwicklung gilt deshalb als schnelllebig, weil man zügiger zum fertigen Produkt kommt als etwa bei einer Mechanikentwicklung. Änderungen und Erweiterungen können leichter umgesetzt und erprobt werden. Trotzdem gibt es gerade bei der Motorsteueregräte-Software eine Vielzahl an Funktionen, die über mehrere Steuergeräte-Generationen hinweg kaum verändert wurden.
Ich denke, in Zukunft werden sich Mechanik- und Softwareentwicklung noch enger verzahnen. Man muss Mechanik und Elektronik als zusammenhängende Einheit begreifen. Immer häufiger wird von der Automobilindustrie gefordert, bereits für den ersten befeuerten Betrieb eines Motors oder den ersten Motoreinsatz einer neuen mechanischen Komponente die wesentlichen Steuerungs- und Regelungsfunktionen in einem Steuergerät dargestellt zu haben. Schon die Tests und Erprobungen stehen ganz im Zeichen der Serienentwicklung, weshalb das Gesamtsystem mit Mechanik und Elektronik möglichst schnell zur Verfügung zu stehen hat.
In der IAV arbeiten die Steuergeräteentwickler schon lange eng mit den Grundmotor- und Brennverfahrensentwicklern zusammen. Bereits während der Designphase, also noch bevor ein realer Motor verfügbar ist, können wir mit unseren Simulationswerkzeugen einen virtuellen Motor nachbilden und am Hardware-in-the-Loop-Testplatz mit der Funktions- und Software-Entwicklung beginnen. Diese Verzahnung hilft, frühzeitig Spezifikationen zu optimieren, verringert die Zahl der Änderungsschleifen und führt schneller zu einer hohen Produktreife.

Zur Person:
Studium der Mess- und Regelungstechnik an der TU Braunschweig.
Seit 1992 Mitarbeiter der IAV GmbH in Gifhorn.
Hier zunächst tätig bei der Applikation und Systemspezifikation von Dieselmotor-Steuergeräten, später mit Teamleiterverantwortung. Teilprojektleitung für internationale Kundenprojekte.
Seit 1999 Abteilungsleiter für die Entwicklung und Applikation von Ottomotor-Steuergeräten.
Seit 2000 verantwortlicher Fachbereichsleiter für die Applikation, Systemspezifikation, Funktionsentwicklung und Seriensoftwareentwicklung von Otto- und Dieselmotor-Steuergeräten.
Nebenbei Dozent an der Otto-von-Guericke-Universität Magdeburg mit der Vorlesung "Steuerungselektronik für Kfz-Antriebe".

Autor(en): Thomas Jungmann

Suche: