IAV entwickelt eine serienreife ECU als Umrüstlösung für den bivalenten Gasbetrieb

Extreme Schwankungen der Preise für Benzin und Diesel haben für einen sprunghaften Anstieg der Nachfrage nach Antriebssystemen gesorgt, die auf alternative gasförmige Kraftstoffe wie Flüssiggas (Liquified Petroleum Gas, LPG) oder Erdgas (Compressed Natural Gas, CNG) umgerüstet werden können. LPG und CNG gehören zwar ebenfalls zu den fossilen Brennstoffen, sind aber weniger schädlich für die Umwelt als konventionelle Treibstoffe und zudem – in vielen Märkten – preiswerter.

Die Experten der IAV haben bereits über 6000 Fahrzeuge auf den CNG- und LPG-Betrieb umgerüstet, was das Unternehmen zu Deutschlands erfolgreichstem Nachrüster für diese Kraftstoffe macht.

Vor kurzem hat die IAV ein Motorsteuergerät (Engine Control Unit, ECU) entwickelt, mit dem sich nahezu alle Otto-Konzepte schnell und kostengünstig in ein bivalentes System umbauen lassen, das neben Benzin auch mit Gas betrieben werden kann, ohne dass dazu das Mastersteuergerät des Otto-Motors ausgetauscht werden muss (Abb. 1). Die neue, als Slave-Controller agierende ECU ist zu OEM-spezifischen Komponenten wie Gasinjektoren, Sensoren und Aktuatoren kompatibel.

Die von der IAV entwickelte ECU wird von einem Partnerunternehmen hergestellt und vertrieben werden, wobei Stückzahlen im Bereich von mehreren Hunderttausend angestrebt sind. Die Markteinführung soll nicht nur in den USA und Europa erfolgen, sondern auch in Schwellenländern.

Eines der Hauptziele des Entwicklungsprozesses war, die Kosten niedrig zu halten und straff geplante Produktionstermine einzuhalten. Gleichzeitig sollte das Design flexibel genug sein, um auch noch Änderungen an der bereits im Produktiveinsatz befindlichen ECU vornehmen zu können.

Basierend auf den bisherigen Erfahrungen der IAV mit ähnlichen Projekten hätte es typischerweise mindestens drei Jahre gedauert, um die ECU bis zur Serienreife zu entwickeln. Durch den Einsatz von Model-Based Design wurde dieses Ziel in nur 18 Monaten erreicht.

Spezifikation und Übergabe der Anforderungen

Zu Projektbeginn wurden die Anforderungen sowie deren zugehörige Testfälle entwickelt und gründlich geprüft. Die einzelnen Systemanforderungen wurden dann an die fünf Hauptarbeitsgruppen übergeben: Algorithmenentwicklung, Softwareentwicklung, Testengineering, Elektrik / Elektronik und Gehäusekomponenten. Das Entwicklerteam bestand aus insgesamt 50 Mitarbeitern, von denen etwa die Hälfte mit der Entwicklung und Implementierung des Controllers beschäftigt waren.

Algorithmenentwicklung und automatische Codegenerierung

Die Algorithmenentwickler modellierten und simulierten die Komponenten und Subsysteme der ECU in Simulink^® und Stateflow^®. Sie arbeiteten dabei mit einer Simulink-Blockbibliothek, die speziell für den verwendeten Zielsystem-Prozessor konzipiert war, einen 32-Bit Infineon^® TriCore^®-Mikrocontroller mit Fließkommaeinheit.

Das Software-Team verwaltete die Schnittstelle zwischen den Algorithmen und der Hardware und war außerdem verantwortlich für die Generierung des serientauglichen Codes. Die gesamte Steuersoftware der ECU wurde mit Real-Time Workshop Embedded Coder™ erzeugt. Den generierten Code kompilierten die Ingenieure zu einem Flash-File für den TriCore-Prozessor. Da es sich um automatisch generierten Code handelte, konnte das Team sicher sein, dass das Flash-File sich exakt so verhalten würde wie das Simulink-Modell.

Der gesamte Prozess, vom Modell bis zum serienreifen Flash-File, war automatisiert. Der Build Manager des Teams war verantwortlich für „Ctrl-B“ (der Shortcut für den Aufruf von Real-Time Workshop^®): Er hatte dafür zu sorgen, dass der Ingenieur in Simulink Ctrl-B drücken, einen Kaffee trinken gehen und dann an den Schreibtisch zurückgekommen ein serienreifes Flash-File vorfinden konnte.

Erprobung im Feldeinsatz

Vor Beginn der Testfahrten stand dem Team keine Master-ECU zur Verfügung. Es konnten also keine Hardware-in-the-Loop-Tests durchgeführt und so lediglich 20% der Algorithmen getestet werden, bevor die Straßenerprobung begann. Die restlichen 80% des Programmcodes mussten im Fahrzeug getestet werden. Ohne Model-Based Design wäre diese Vorgehensweise unmöglich gewesen, weil die Zeit gefehlt hätte, um so spät im Entwicklungsprozess entdeckte Fehler noch zu korrigieren. Durch Model-Based Design konnten aber nicht nur die Tests im Fahrzeug früher beginnen, sondern auch der aus Tests, Funktionsanpassung und erneuten Tests bestehende Zyklus verkürzt werden: Mithilfe eines im Fahrzeug mitgeführten Laptops waren die Ingenieure in der Lage, in nur 20 Minuten das Simulink-Modell zu modifizieren, den Code erneut zu generieren und einen neuen Prototypen zu erzeugen.

Falls Tests im Fahrzeug aufzeigten, dass der Definition einer bestimmten Anforderung unzutreffende Annahmen zugrunde lagen, musste sowohl diese Anforderung als auch der Testfall dafür geändert werden. Nachdem das Simulink-Modell entsprechend der modifizierten Anforderungen angepasst worden war, wurde der gesamte Prozess der Codegenerierung und des Testens des Flash-Files wiederholt. Innerhalb von nur drei Tagen konnte auf diese Weise das System dokumentiert, erprobt und produktionsbereit gemacht werden.

Dokumentation und Kalibrierung

Die erzeugten Simulink-Modelle dienten während der gesamten Entwicklung als ausführbare Spezifikation des Entwurfs, die gemeinsam mit IAV-Ingenieuren aus Großbritannien, den USA und Japan genutzt werden konnte. Für die interne Kommunikation der IAV-Teams untereinander war durch diese gemeinsame Nutzung zwar eine effektive Basis vorhanden, aber die internen Modelle konnten nicht an Personen außerhalb des Unternehmens weitergegeben werden. Dafür wurde eine aussagekräftige Dokumentation benötigt.

Zusammen mit MathWorks-Consultants und auf der Basis des Simulink Report Generators™ entwickelte die IAV ein automatisiertes Dokumentations-System (ADoS). ADoS erzeugte aus den Modellen Berichte, in denen Anforderungen und Design-Spezifikationen dokumentiert waren. Bei Erreichen jedes Projekt-Meilensteins erzeugte das Team einen etwa 1000 Seiten langen PDF-Bericht mit Informationen über die ECU mit Signalflüssen sowie Funktions- und Komponentenbeschreibungen. Die Kalibrierungs-Ingenieure nutzten diese Dokumentation einerseits, um das Verhalten der ECU nachzuvollziehen, andererseits vereinfachte sie die Kalibrierung der ECU im Fahrzeug, also die Abstimmung auf einen bestimmten Fahrzeugtyp. Zu diesem Zweck enthielt das System eine Schnittstelle zu in der Automobilindustrie gebräuchlichen Kalibrierungstools wie etwa INCA von der ETAS GmbH.

Übergang zur Produktion

Der neue Gas-Slave-Controller hat alle Anforderungen für eine OEM-Qualitätszertifizierung bestanden, darunter auch strenge Verifikations-Verfahren wie den Nachweis, dass die ECU zwischen -40 und 105°C korrekt arbeitet sowie Tests auf ihre Langlebigkeit.

Die IAV ist ISO 9000-zertifiziert und sämtliche dort eingesetzten Prozesse sind so angelegt, dass sie Automotive Spice-konform sind. Obwohl zur Einhaltung dieser Standards der Workflow um eine ganze Reihe zusätzlicher Tätigkeiten erweitert werden musste, wurde die ECU-Entwicklung termingerecht abgeschlossen – in etwa der Hälfte der in der Branche üblichen Zeit. Die ersten Serien-Controller sind bereits produziert (Abb. 2) und in Kürze beginnt die Großserienproduktion.

Model-Based Design bildet die Basis für die künftigen Entwicklungsaktivitäten der IAV. Mit der aktuellen Toolkette von The MathWorks verfügen die Ingenieure über das Rüstzeug zur Entwicklung flexibler Lösungen, die an unterschiedliche Märkte und Bedürfnisse angepasst werden können. Derzeit arbeitet man dort an einer High-End Version der ECU mit zusätzlichen Funktionen sowie einer für Schwellenmärkte geeigneten, einfachen und preisgünstigen Version mit begrenzter Funktionalität.