Effizienter Diagnosetest durch Simulation

Die Diagnose kontrolliert im laufenden Betrieb permanent die Betriebszustände des mechatronischen Systems und stellt somit eine eigene Fahrzeugfunktion dar. Gleichzeitig stellt sie die Ergebnisse ihrer Überprüfungen bei Bedarf externen Geräten zur Verfügung und ist damit für den Fahrzeughersteller in Produktion und Werkstatt unabdingbar. Sie ist damit aber auch Teil der Testmethodik. Für Diagnosetests ergibt sich daraus eine Zweiteilung: zum einen den Test der Diagnose, zum anderen das Testen unter Verwendung der Diagnose. 

Der Begriff „Diagnose“ beschreibt sowohl ECU-interne Algorithmen, mit denen Fehler in Sensorik/Aktuatorik und der Steuergerätekommunikation ermittelt werden, als auch die Übertragungsprotokolle zu einem externen Diagnosetester hin. Beide Fälle müssen validiert werden. Dazu müssen beispielsweise Fehlerbedingungen geschaffen werden und anschließend geprüft werden, ob ein Fehler richtig erkannt und im Fehlerspeicher eingetragen wird. Bezüglich Protokolle sind Übertragungseigenschaften und Dateninhalte zu testen. Sobald die Diagnose verlässlich funktioniert, dient sie als Testmittel. Über Diagnose ist es einfach auf standardisierte Weise auf interne Größen und Zustände zuzugreifen – genau dafür wurde sie entworfen. So können:

• in Prüfständen vom Steuergerät ermittelte Messgrößen für Regelungen verwendet werden,
• im Fahrversuch Fehler ermittelt und zur Abstellung an die Entwickler gemeldet werden und
• in der Produktion der korrekte Verbau von Komponenten laufend geprüft werden. 

Die verwendeten Testabläufe müssen ihrerseits abgesichert werden, Fehler im Testaufbau würden die gesamte Methodik ad absurdum führen. Dabei ist der gesamte Testaufbau aus Hard- und Software zu prüfen. Dies erfolgt bei vielen Testern keineswegs nur einmal. In der Regel werden fortlaufend neue Fahrzeuge oder Steuergerätevarianten integriert. Der Ist-Stand ist dazu jeweils einem Regressionstest zu unterziehen, damit Änderungen sicher keine Auswirkungen haben. Betrachtet man als Beispiel einen Servicetester, der in 10.000 Werkstätten ausgerollt wird, wird klar, dass Fehler zu einem erneuten Rollout und damit zu enormen Kosten führen. Dies gilt es zu vermeiden. In beiden Fällen weist die Erfahrung auf ein Dilemma hin: der Test des Testers verlangt nach einer Gegenstelle – in der Diagnose ein Fahrzeug oder Steuergerät. Dies ist jedoch meist nicht verfügbar. Während der ersten Erstellung eines Testers oder Testablaufs ist es noch nicht fertig, was wenig überrascht, da es durch den Test ja erst geprüft werden soll. Im Regressionstest ist es in der Regel nicht mehr verfügbar, weil schlicht nicht alle Fahrzeuge in allen Varianten vorgehalten werden können. In Schulungseinrichtungen zeigt sich ein vergleichbares Bild: Das zum Sachverhalt der Übung passende Fahrzeug kann nicht vorgehalten werden und ist nur mit Aufwand beschaffbar. 

Die Lösung ist eine Simulation, die das Steuergerät oder Fahrzeug in Bezug auf das Diagnoseverhalten nachstellt. Ein Beispiel für eine solche Diagnosesimulation ist Softing TCS. Die Lösung besteht aus drei Bausteinen:

• Softing TCS.device stellt die Hardware für die Simulation dar
• Softing TCS.admin ist die Konfigurationsoberfläche für Simulationsdateien
• Softing TCS.testbench ermöglicht die Integration in Testautomatisierungen