Erläuterungen am Beispiel einer automatischen Außenlichtsteuerung
Diagnoseverifikation in frühen Entwicklungsphasen
Fortsetzung des Artikels von Teil 2
Diagnosetest
Die in dem Systemmodell enthaltenen Diagnosefunktionen können nun bereits früh im Entwicklungsprozess überprüft werden. Folgende Fragen lassen sich untersuchen und beantworten:
- Werden Fehler im System durch die implementierte Diagnosefunktion richtig erkannt und wird auf die erkannten Fehler richtig reagiert?
- Werden alle Fehler erkannt?
- Wurden die Fehlerspeichermodule korrekt konfiguriert und werden die richtigen DTCs in der Basis-Software abgelegt?
Um diese Fragen durch Systemanalysen beantworten zu können, ist eine Werkzeugunterstützung nötig, da die betrachteten Systeme in der Regel sehr komplex sind. Außerdem besteht meistens auch gar nicht die Möglichkeit, ein System – bestehend aus mehreren Software-Komponenten und Steuergeräten – im Verbund zu überprüfen, noch bevor die Steuergeräte zur Verfügung stehen. Hier bietet die Offline-Simulation solcher Systeme am PC die entscheidende Möglichkeit, das implementierte Diagnoseverhalten eines Systems früh abzusichern.
Jobangebote+ passend zum Thema
Das System der Außenlichtsteuerung hat noch offene Eingänge. Hier werden beispielsweise Signale des Regen-Lichtsensors und des Lichtdrehschalters empfangen, die nicht explizit mitmodelliert sind. Um das System testen zu können, müssen die noch offenen Eingänge durch Testvektoren stimuliert werden. Diese Daten werden mit Hilfe spezieller Testwerkzeuge erstellt. Nach einer Transformation in eine Textdatei werden die im realen Testprozess verwendeten Testvektoren in SystemDesk eingelesen und zum Stimulieren der offenen Ports während der Simulation verwendet. Weiterhin liefert das Testwerkzeug Informationen zur Auswertung der Tests. Dazu gehören die zu messenden und zu protokollierenden Daten sowie die erwarteten Ergebnisse.
Die Informationen über die zu messenden Daten werden ebenfalls in SystemDesk eingelesen, so dass während der Simulation diese Daten protokolliert werden. Die gespeicherten Simulationsergebnisse lassen sich anschließend wieder in das Testwerkzeug einlesen, wo dann anhand der zu erwartenden Ergebnisse ausgewertet wird, ob der Test erfolgreich war (das System reagierte wie erwartet) oder nicht (es traten Abweichungen zwischen protokolliertem und erwartetem Verhalten auf). Die für den Diagnosetest notwendigen Werkzeuge und auszutauschenden Daten sind in Bild 2 dargestellt.
Durch die frühzeitige Validierung der Diagnose besteht die Möglichkeit, eventuell entdeckte Schwächen zu korrigieren und Lücken zu schließen. Es ist ebenso möglich, zunächst bewusst nur einen Teil der Diagnose umzusetzen und zu überprüfen. Die Ergebnisse der Überprüfung können dann helfen, weitere Teile der Diagnose zu implementieren und so den Reifegrad der Diagnosefunktion zu erhöhen, indem die Ergebnisse zu mehr Verständnis für das zu diagnostizierende System verhelfen.
Überprüfte Fehlerfälle
Im beschriebenen Beispiel des Systems Außenlichtsteuerung werden in einer Simulation drei unterschiedliche Fehlerfälle untersucht, um anhand des protokollierten Systemverhaltens Aussagen über eine korrekte Diagnose-Implementierung treffen zu können:
Die an ein Steuergerät angeschlossene Komponente erkennt selbstständig einen Fehler und meldet diesen an die Außenlichtsteuerung. Diese Applikation führt als Funktionsmaster eine adäquate Ersatzreaktion durch und übernimmt gleichzeitig das Ablegen eines DTCs im Fehlerspeicher. In der Simulation wird dieses Verhalten nachgebildet, indem der stimulierende Testvektor das entsprechende Diagnosesignal des Regen-Lichtsensors an die Lichtsteuerung übergibt. Als Reaktion auf die nicht zur Verfügung stehenden Sensordaten aktiviert die Funktion das Notlicht und schaltet die Außenbeleuchtung des Fahrzeuges ein.
- Diagnoseverifikation in frühen Entwicklungsphasen
- Diagnoseverifikation in frühen Entwicklungsphasen
- Diagnosetest
- Diagnoseverifikation in frühen Entwicklungsphasen
