Dipl.-Ing. Michael Preussner, Antriebselektronik Management Systeme (AE-MD32) Möglichkeiten für die Automation von Testvorgängen mit dem Steuergeräte- Stimulisystem ECUS In der Automobiltechnik erhöhen sich die Anforderungen an die Steuergeräteentwicklung ständig, während die zur Verfügung stehende Entwicklungszeit immer knapper wird. Dieser Umstand führt zu der Notwendigkeit, den Test der Steuergeräte und der integrierten Diagnosen immer weiter zu automatisieren. Zudem ist es wünschenswert den Zeitaufwand, der notwendig ist, um einen Testplatz für die Steuergeräte einzurichten, möglichst gering zu halten. Um dies zu erreichen, sollte die Simulationstiefe so gering wie möglich und nur so aufwändig wie nötig gehalten werden. Um bei der schnellen Entwicklung im Automobilbereich schritthalten zu können, ist es außerdem sinnvoll bereits bestehende Werkzeuge wie z. B. Applikations- und Diagnosesysteme in das Simulationssystem zu integrieren und somit Entwicklungszeit zu sparen. Mit dem ECUS-System hat die IAV GmbH ein universelles, einfach zu bedienendes System entwickelt, mit dem ein fehlerfreier Betrieb eines Steuergerätes im Labor ermöglicht wird. 1 Einleitung Moderne Motoren besitzen ein leistungsfähiges Motormanagement, um den immer höher werdenden Standards in Bezug auf Umweltschutz und Fahrkomfort gerecht zu werden. Durch die steigende Komplexität der Steuergeräte und der in diesen enthaltenen Software erhöht sich auch der Aufwand für den Funktionstest. Für den Betrieb der Steuergeräte im Labor werden Fahrzeugsimulatoren verwendet, die ein Hardware-in-the-loop (HIL) ermöglichen. Das in der IAV entwickelte ECUS-System ist ein kostengünstiges Stimulisystem für Steuergeräte, das durch Verwendung einfacher Modelle Hardware-in-the-Loop-Tests Testautomation mit ECUS 1 / 13
ermöglicht. Durch den hochflexiblen Aufbau des ECUS können Dieselmotor-, Ottomotor- oder auch Getriebesteuergeräte mit nur einem System betrieben werden. Das ECUS ist entwickelt worden, um einem Steuergerät im Labor eine vollständige Fahrzeugumgebung vorzuspiegeln, wobei die Steuergeräte keinen Unterschied zwischen Simulation und Fahrzeug erkennen. Es wurde bewusst darauf verzichtet, eine vollständige Nachbildung der Realität zu erzeugen, die unter allen Umständen immer physikalisch richtige Ergebnisse liefert. Stattdessen wird das Steuergerät so betrieben, dass die Diagnosen des Steuergerätes den Unterschied zur Realität nicht bemerken. Hierfür ist es vollkommen ausreichend, die für die Diagnosen wichtigen Parameter aus dem Steuergerät auszulesen und hierauf basierend mit einfachen Modellen weiterführende Berechnungen durchzuführen. Diesen Ansatz verfolgt das ECUS und kann somit als quasi closed loop -Simulator bezeichnet werden. Für die vollständige Bedatung eines HIL-Simulators für Motorsteuergeräte werden im Normalfall Monate benötigt, bei der Einrichtung eines Testplatzes mit dem ECUS-System braucht man dafür hingegen nur einige Tage. Durch den hohen Aufwand, der zum Teil bei anderen HIL-Simulatoren betrieben wird, kommt es vor, dass für die Bedatung des Simulators mehr Zeit aufgewendet wird als für den eigentlichen Test der Steuergeräte. Das ECUS ist ein PC-basiertes System, das durch seine unter LabView erstellte Oberfläche einfach zu bedienen ist. Das ECUS kann für die Inbetriebnahme und Überprüfung von Steuergeräten im Labor verwendet werden, so dass eine aufwändige Überprüfung im Fahrzeug unter Umständen entfallen kann. Es können auch Tests durchgeführt werden, die im realen Fahrzeug nur sehr schwer bzw. unter großem Zeitaufwand durchgeführt werden könnten (z. B. reproduzierbare Signalverläufe). Testautomation mit ECUS 2 / 13
Abbildung 1: Benutzeroberfläche des ECUS-Systems Als Erweiterung des ECUS-Systems wurde ein Fehler-Funktions-Test-System entwickelt, mit dem die Leitungsfehler an den Aktoren des Motors nachgebildet werden können (Leitungsbruch, Kurzschluss nach Masse oder Plus und Kurzschlüsse der Leitungen untereinander). Es wurden umfangreiche Möglichkeiten geschaffen, die Bedienung der vollständigen Simulationsumgebung zu automatisieren, um so bei wiederkehrenden Tests Zeit einzusparen. Es sind derzeit über 60 ECUS-Systeme im Einsatz für den Softwaretest und die Funktionsentwicklung von Motorsteuergeräten. Testautomation mit ECUS 3 / 13
2 Simulation der Fahrzeugumgebung Für die Simulation der Fahrzeugumgebung ist es notwendig, dem Steuergerät alle elektrischen Signale und Ersatzlasten für alle Aktoren zur Verfügung zu stellen. Die Signale werden vom Steuergerät anhand des derzeit eingestellten Fahrzustandes plausibilisiert, um so eine defekte Sensorik erkennen zu können. Hierfür werden im Steuergerät über zum Teil einfache Modelle und Kennfelder permanent Werte ermittelt, die mit den von dem jeweiligen Sensor erfassten verglichen werden. Um einen fehlerfreien Betrieb des Steuergerätes zu erreichen, können die Ansteuersignale für die Aktoren erfasst und über umfangreiche Modelle der Zustand des Motors vollständig nachgebildet werden (echtes Hardware-in-the-loop). Eine andere Möglichkeit ist, die vom Steuergerät berechneten Modellwerte abzufragen, diese durch weitere Berechnungen zu ergänzen und dem Steuergerät wiederum als Sensorwert zur Verfügung zu stellen. Dem Steuergerät werden somit die elektrischen Signale geliefert, die dieses als plausibel erachtet (quasi-closed-loop). Ein echter HIL-Ansatz hat den Nachteil, dass die Modelle sehr genau sein müssen, um nicht von den Modellen im Steuergerät abzuweichen und somit Fehlereinträge im Steuergerät zu erzeugen. Durch das Erfragen des Motormoments aus dem Steuergerät kann auf einfache Art der Leerlauf und Fahrbetrieb simuliert werden. Jedes moderne Motorsteuergerät berechnet das Moment, das an der Kurbelwelle anliegt, um dieses über den CAN-Bus anderen im Fahrzeug verbauten Steuergeräten zur Verfügung zu stellen. Durch eine Modellbildung im Simulator ist es möglich, anhand des Motormoments die Drehzahl und die Fahrgeschwindigkeit plausibel zu berechnen. Diese Methode der Vereinfachung kann auch für andere Regelkreise angewandt werden, so dass es möglich wird, die Signale für z. B. den Luftmassenmesser, den Ladedruckfühler und Lambda-Signale dem Steuergerät plausibel zur Verfügung zu stellen. Der Quasi-closed-loop-Ansatz ist die beim ECUS bevorzugte Methode, um einen fehlerfreien Betrieb des Steuergerätes zu erreichen. Grundvoraussetzung für diesen Ansatz ist, dass die vom Steuergerät berechneten Werte erfragt werden können; hierzu ist eine Kommunikation mit dem Steuergerät notwendig. Für die Kommunikation bestehen drei Möglichkeiten, die in den folgenden Unterkapiteln (K-Leitung, CAN-Bus, Applikationssystem) beschrieben werden. Das ECUS verfügt über mehrere zusätzliche Kommunikationsschnittstellen, über die auch eine Kopplung mehrerer ECUS-Systeme untereinander möglich ist. Somit kann auch ein Steuergeräteverbund getestet werden, um das Zusammenspiel der Steuergeräte im Fahrzeug zu überprüfen. Testautomation mit ECUS 4 / 13
2.1 K-Leitung Die serielle Eindraht-Schnittstelle K-Leitung ist derzeit noch in vielen Fahrzeugen verbaut, hierüber können über unterschiedliche Protokolle Daten aus dem Steuergerät ausgelesen werden. Auf allen Steuergeräten ist ein Protokoll für den Kundendienst implementiert, dieses arbeitet meistens nur mit einer geringen Baudrate und nicht immer ist ein Zugriff auf alle benötigten Variablen möglich. Teilweise werden von den Steuergeräteherstellern zusätzlich schnellere Protokolle implementiert, mit denen z. B. zehn Variablen im Raster von 20 ms ausgelesen werden können. Dies ist für die Simulation schnell genug, wenn das Steuergerät im Zeitraster von 10 ms rechnet und keine sehr schnellen Regelvorgänge nachgebildet werden sollen. Der Nachteil dieser Methode die Daten zu erfragen ist, dass nicht in allen Steuergeräten ein ausreichend schnelles Protokoll zur Verfügung steht und dass der Aufwand zur Implementierung der Protokolle auf dem Simulationssystem relativ hoch ist und nicht von dem Anwender durchgeführt werden kann. Abbildung 2: Kommunikation über K-Leitung 2.2 CAN-Bus Der CAN-Bus ist bei allen modernen Fahrzeugen europäischer Hersteller verfügbar. Das ECUS-System verfügt über eine Schnittstelle zu dem Diagnosesystem CANalyzer der Firma Vector. Mit Hilfe des CANalyzers können die CAN-Botschaften der weiteren im Fahrzeug verbauten Steuergeräte wie z. B. ABS- und Getriebesteuergerät nachgebildet werden (CAN- Testautomation mit ECUS 5 / 13
Restbus-Simulation). Weiterhin können mit dem CANalyzer die Daten auf dem CAN-Bus an das ECUS-System weitergereicht werden. Hierfür ist eine Programmierung des CANalyzers in einer C-ähnlichen Sprache notwendig. Wird diese Möglichkeit genutzt, um Werte aus dem Motorsteuergerät in die Simulation einzubinden, wird eine spezielle Software für das Motorsteuergerät benötigt, das die Werte auf dem CAN-Bus zur Verfügung stellt. Bei Verwendung einer Serien-Software kann ausschließlich das Motormoment ausgelesen werden. Da eine spezielle Software für Motorsteuergeräte selten verfügbar ist, kann diese Methode nur sehr selten genutzt werden. Abbildung 3: Kommunikation über CAN-Bus 2.3 Applikationssystem In der Entwicklung von Hard- und Software von Motorsteuergeräten werden sogenannte Applikationssteuergeräte eingesetzt. Dies sind speziell ausgerüstete Steuergeräte, die mit Hilfe von dual-ported RAM einen schnellen Zugriff auf alle internen Daten ermöglichen. Hierfür werden Applikationssysteme verwendet, die zum Erfassen und zur Modifikation von Daten eingesetzt werden, wie z. B. das System INCA der Firma ETAS GmbH. Durch die weite Verbreitung des ASAP3-Standards können die Applikationssysteme über eine genormte Schnittstelle konfiguriert und gesteuert werden. Testautomation mit ECUS 6 / 13
Das ECUS-System unterstützt einen erweiterten Umfang der ASAP3-Schnittstelle und kann somit Daten aus dem Applikationssystem erfragen und für die Simulation verwenden. Der Zugriff auf die Daten erfolgt über TCP/IP und ist sehr schnell. Die Konfiguration des Simulators ist sehr komfortabel, da die Daten über Alias-Namen angesprochen werden und die Zuordnung durch das Applikationssystem erfolgt. Aufgrund der einfachen Bedienung ist dies die Methode der ersten Wahl für die Kommunikation mit dem Steuergerät. Abbildung 4: Kommunikation über Applikationssystem 3 Automation Es sind sehr viele unterschiedliche Szenarien denkbar, die an einem Fahrzeugsimulator automatisiert werden können. Diese Szenarien haben teilweise gegenteilige Ansprüche an die Automationsumgebung. So gibt es z. B. die reinen in Ordnung/nicht in Ordnung -Tests, bei denen es hauptsächlich darauf ankommt, dass der Anwender die Testmuster möglichst schnell und komfortabel eingeben kann. Es besteht aber auch der Bedarf nach hochflexiblen Automationen, die eine Verzweigung des Prüfablaufs anhand von Zwischenergebnissen erfordern. Beim ECUS-System werden die Möglichkeiten für die Automation von Testvorgängen zusätzlich durch die Methode für die Kommunikation zum Steuergerät bestimmt. Denn viele in Testautomation mit ECUS 7 / 13
die Simulation eingebundene Geräte, wie z. B. das Applikationssystem INCA, können nur von einem einzigen anderen Gerät angesprochen werden. 3.1 Tedas Als Erweiterung des ECUS wurde die Automation TEDAS (Test Description & Automation System) entwickelt, die es gestattet, sämtliche in ECUS verfügbaren Signale gleichzeitig dynamisch zu steuern. Somit ist die Erzeugung beliebiger Fahrverläufe realisierbar. In die Automation können reale Messungen, die im Fahrzeug aufgenommen wurden, importiert werden. Diese können problemlos nachbearbeitet und um weitere Signalverläufe ergänzt werden. Eine Umschaltung zwischen einem dem Steuergerät aufgeprägten Signal und dem geschlossenen Regelkreis ist innerhalb des Testvorgangs auf einfachem Wege durchführbar. Die Eingabe der Testszenarien erfolgt komfortabel mittels graphischer Editoren oder in tabellarischer Form. Bei der graphischen Eingabe können die Signalverläufe einfach mit der Maus gezeichnet werden. Es wurden umfangreiche Werkzeuge für die Nachbearbeitung des Signals geschaffen, wie z. B. Glättungs- und Filterfunktionen. Einmal eingegeben, ist ein Fahrverlauf vollständig reproduzierbar. Über Dateilisten können mehrere Tests nacheinander automatisiert abgefahren werden. Als reine Softwarelösung ist TEDAS gänzlich von der am ECUS betriebenen Hardware unabhängig. Auf diese Weise bleibt der größte Teil der Testdateien auch für andere Steuergerätetypen nutzbar. Das Automationsprogramm TEDAS wurde in die Software des ECUS integriert und kann bei allen Konstellationen des Testplatzaufbaus verwendet werden. Die Dokumentation der durchgeführten Tests erfolgt durch ein zusätzlich anzuschließendes Messsystem, wie z. B. das Applikationssystem INCA. Abbildung 5: Steuerung des ECUS über TEDAS Testautomation mit ECUS 8 / 13
3.2 Ablaufsteuerung Um die Durchführung immer wiederkehrender, gleichartiger Tests zu erleichtern, wurde die Automation mit TEDAS noch um ein weiteres Automationsprogamm ergänzt. Nach einer Änderung der Motorsteuergeräte-Software (Programm oder Bedatung) muss diese, bevor sie als Serienprodukt eingesetzt werden kann, erneut vollständig auf ihre Funktionalität hin überprüft werden (Master-EPROM-Check). Für einen automatischen Software-Test muss der Testplatz immer wieder gleich konfiguriert werden. Wenn keine neue Funktionalität in das Steuergerät aufgenommen wurde, besteht der einzige Unterschied zum vorherigen Test darin, dass eine neue Software in das Steuergerät geladen wird. Die vollständige Konfiguration des Testplatzes kann (mit Ausnahme der mechanischen Vorgänge, wie z. B. Anschließen des Steuergerätes) ebenfalls automatisiert werden. Ein zusätzlicher Rechner, auf dem die Daten verwaltet werden, steuert alle konfigurierbaren Elemente des Testplatzes aus vorher erstellten Dateien: In das ECUS wird das Setup für das Steuergerät geladen, das TEDAS-Programm wird bedatet, das Applikationssystem vollständig konfiguriert und die Software in das Steuergerät geladen. Nachdem der Test durchlaufen ist, werden alle im System verfügbaren Daten zentral auf dem Automationsrechner bzw. einem Netzwerklaufwerk gesammelt. Die Ablaufsteuerung ist sozusagen eine Automation der Automation. Bedingt durch den ASAP3-Standard, der für die Steuerung des Applikationssystems verwendet wird, kann die INCA-Kopplung des ECUS zum Auslesen der internen Daten aus dem Steuergerät nicht verwendet werden, da in diesem Fall zwei Geräte auf das Applikationssystem zugreifen müssten. Eine Verzweigung im Testablauf aufgrund von Messergebnissen, wie z. B. Fehlerspeichereinträgen im Steuergerät, ist nicht vorgesehen. Im Fehlerfall kann nur der laufende Test abgebrochen und ein neuer gestartet werden. Testautomation mit ECUS 9 / 13
Abbildung 6: Steuerung von ECUS und INCA mit ASAM3MC 3.3 Scriptsteuerung Die Scriptsteuerung des Testsystems ist eine intelligente Automationsmöglichkeit für die Überprüfung der Fehlerreaktionen des Steuergeräts. Ein beliebiger Script-Server steuert über TCP/IP das ECUS-System und über DDE das auf demselben Rechner laufende Steuergeräte- Diagnose-Programm. Ebenfalls über TCP/IP erfragt das ECUS-System von dem Applikationssystem INCA die Messgrößen, die es für die Regelkreise benötigt und zusätzlich Messgrößen, die Statusbit-Felder des Steuergerätes enthalten. Diese Statusbits werden an den Script-Server weitergereicht, der daraufhin in seinem Programmablauf verzweigen kann. In den Status-Bits wird angezeigt, ob in dem Zustandsautomaten des Steuergerätes alle Bedingungen durchlaufen wurden, die für die Durchführung der Diagnosen notwendig sind. Das Steuergeräte-Diagnose-Programm bildet einen vollständigen Werkstatt-Tester für den Kundendienst nach und kommuniziert mit dem Steuergerät über die K-Leitung oder den CAN- Bus. Auf diesem Weg ist es möglich, den Fehlerspeicher des Steuergerätes auszulesen und zu löschen. Durch die umfangreiche Befehlsbibliothek für die Steuerung des ECUS-Systems kann zusätzlich die Fehlersimulation für die Ersatzlasten gesteuert werden, um so absichtlich Fehlerreaktionen des Steuergerätes zu provozieren. Als Script-Server stehen zwei Varianten zur Verfügung, zum einen das von der IAV in LabView erstellte Programm IRNA und eine Bibliothek für den TCL/TK-Scriptserver. Es können auch beliebige andere Steuerungsprogramme verwendet werden, wie z. B. TestStand von National Instruments oder kundenspezifische Lösungen. Bei der Verwendung des Steuerungsprogramms IRNA, das tabellarische Textdateien abarbeitet, steht für die Steuerung Testautomation mit ECUS 10 / 13
der Fehlersimulation ein automatischer Testmustergenerator zur Verfügung. Bei diesem können durch einfache graphische Bedienung die Lasten verschaltet werden. Es findet eine zusätzliche Plausibilisierung statt, so dass keine ungewollten Fehlerzustände durch die Relaismatrix erzeugt werden. Auch das Diagnose-Tester-Programm ist nicht auf die Verwendung von DiagRA (wie in dem Beispiel dargestellt) beschränkt, es können beliebige Programme verwendet werden, die über DDE oder TCP/IP steuerbar sind. Abbildung 7: Scriptsteuerung von ECUS, INCA und Diagnosetester 4 Automatisierter Fehler-Reaktions-Test Als Beispiel-Szenario eines automatisierten Tests mit der Script-Steuerung kann der Fehler- Reaktions-Test (auch als OBD1-Test bekannt) betrachtet werden. Bei diesem Test werden die Reaktionen des Steuergerätes auf Fehler in der elektrischen Verdrahtung und defekte Sensoren und Aktoren im Fahrzeug getestet. Jedem Fehler, der vom Steuergerät erkannt werden muss, wird ein bestimmter Fehlertext und eine bestimmte Fehlernummer (P-Code) zugeordnet, die beide im Fehlerspeicher des Steuergerätes abgelegt werden. Dieser Test ist sehr umfangreich, da für nahezu jede Leitung, die zum Steuergerät führt, drei Fehlerzustände (Kurzschluss nach Plus, Kurzschluss nach Masse und Leitung offen) nacheinander geprüft werden müssen. Zwischen den Tests müssen die Fehlerspeichereinträge im Steuergerät gelöscht werden, um so sicherstellen zu können, dass der richtige Fehlerspeichereintrag vom Steuergerät vorgenommen wurde. Testautomation mit ECUS 11 / 13
Der Ablauf des Tests wird im folgenden als ein Beispiel stichpunktartig beschrieben: - Anfahren von Betriebspunkten im Closed-loop-Modus Motor starten, Fahrpedalwert erhöhen, bis Drehzahl von 3000 U/min erreicht ist - Erzeugung von Fehlerzuständen an Lasten oder Eingängen Last Nr. 1 mit Fehlerbild 1 (Kurzschluss nach Plus) beschalten - Überprüfung des Zyklusbits, ob Fehlerpfad abgeprüft wurde Bestimmtes Bit im Bitfeld abfragen und warten, bis dieses gesetzt ist - Auswertung des Fehlerbits Überprüfen, ob das entsprechende Fehlerbit des Fehlerpfades gesetzt ist - Auswertung des Fehlerspeichers und der P-Codes Nach vordefinierter Zeit den Fehlerspeicher auslesen und mit Vorgabewert überprüfen - Entfernen des Fehlerzustandes Fehlerbild an der Last entfernen - Anfahren von Betriebspunkten für Heilung Drehzahl senken auf 2000 U/min und erneut auf 3000 U/min erhöhen - Überprüfen des Fehlerbits Steuergerät muss erkannt haben, dass der Fehler aktuell nicht mehr vorliegt - Überprüfen des Fehlerspeichers (sporadischer Fehler) Eintrag im Fehlerspeicher muss von statisch auf sporadisch geändert worden sein - Fehlerspeicher löschen Vorbereitung zur erneuten Durchführung des Tests mit anderem Fehlerbild Testautomation mit ECUS 12 / 13
5 Zusammenfassung Für die Überprüfung der Funktionalität von Motorsteuergeräten sind in der Entwicklungsphase umfangreiche und immer wiederkehrende Tests notwendig. Diese Tests können an Fahrzeugsimulatoren im Labor schneller bzw. mit weniger Ressourcen durchgeführt werden als im realen Fahrzeug, da hier die Möglichkeit besteht, die Tests zu automatisieren. Das ECUS-System ist ein bei der IAV GmbH seit sieben Jahren bewährter Fahrzeugsimulator, der einfach zu bedienen und schnell zu konfigurieren ist. Ein wesentlicher Unterschied des ECUS zu anderen Simulatoren ist, dass es sich auf Werte stützt, die das Steuergerät selbst berechnet. Hierfür ist eine Kommunikation mit dem Steuergerät nötig. Bedingt durch die umfangreichen Konfigurationsmöglichkeiten des Testplatzes ergeben sich unterschiedliche Ansätze für die Automation von Testvorgängen. Abbildung 8: Zusammenfassung der Steuerungsmöglichkeiten Testautomation mit ECUS 13 / 13