Datengetriebene automatisierte Diagnose-Applikations ... · Fehler abgelegten DTC-Umgebungsdaten...
Transcript of Datengetriebene automatisierte Diagnose-Applikations ... · Fehler abgelegten DTC-Umgebungsdaten...
Datengetriebene automatisierte Diagnose-Applikations-Validierung
Seit vielen Jahren wird die Diagnoseprotokoll-Implementierung
eines Steuergeräts über automatisch generierte Tests validiert.
Diese basieren auf Diagnosebeschreibungs-Dateien des Fahr-
zeugherstellers. Die entsprechende Schnittstelle eines Steuer-
geräts kann so nachweislich effizient getestet werden und
führt zu einer Verbesserung der Produktqualität. Je nach
Vollständigkeit der Diagnosebeschreibung ist darüber hinaus
auch die automatisierte inhaltliche Validierung von Diagnose-
parametern und Fehlercodes möglich, wie die Zusammen-
arbeit von Claas und Vector Informatik zeigt.
© C
laas,
Vecto
r In
form
ati
k
AUTOREN
Dipl.-Ing. (FH) Nils Niedermarkist als Entwicklungsingenieur
im Bereich Entwicklung
Elektronik Integration bei
der Claas Selbst fahrende
Erntemaschinen GmbH
in Harsewinkel.
Friedemann Löw, B. Sc.ist in der Produktlinie Kfz-Diagnose
bei der Vector Informatik GmbH
in Stuttgart als Software-
Entwickler für CANoe.DiVa tätig.
Dipl.-Inf. Simon Müllerist Produktmanager in der
Produktlinie Kfz-Diagnose bei
der Vector Informatik GmbH
in Stuttgart.
ENTWICKLUNG DIAGNOSE
44
AUFGABENSTELLUNG
Der Landmaschinenkonzern Claas
beschreibt in seinen Diagnosedaten
die Beziehung zwischen Diagnosepara-
metern und den Steuergeräte Ein- und
Ausgängen. Auch die Beschreibung
von Fehlersetzkriterien wird für Neu-
implementierungen formal dokumen-
tiert. In der Vergangenheit wurden diese
Informationen zur Durchführung von
manuellen Tests verwendet oder Testin-
genieure implementierten spezielle Test-
fälle. Eine breite Testabdeckung konnte
jedoch nicht erreicht werden.
In Zusammenarbeit mit der Vector
Informatik werden diese Verbindungs-
informationen automatisiert mit der vor-
handenen Netzwerk-(K-Matrix) und
Hardwarebeschreibung verknüpft. Basie-
rend auf bereits verfügbaren Spezifikati-
onsdaten wie CDD (CANdela Diagnostic
Data) oder ODX (Open Diagnostic Data
Exchange) werden vollautomatisiert Dia-
gnoseapplikationstests generiert und in
einer Testumgebung ausgeführt. Durch
automatisierte Stimulation der Steuerge-
räteumgebung wird das inhaltlich kor-
rekte Verhalten der Diagnose-Implemen-
tierung getestet. Dazu werden zum
Beispiel Signale in der Bussimulation
modifiziert oder gezielt Hardware-I/Os
angesteuert. So ist es möglich, das kor-
rekte Setzen von Diagnoseparametern
zu prüfen oder Fehlerzustände zu erzeu-
gen und die richtige Ablage zu testen.
AUTOMATISIERTE TESTGENERIERUNG
Um eine automatisierte Testgenerierung
und Testdurchführung von Applikations-
tests zu erreichen, müssen Diagnosepa-
rameter und Steuergeräte-I/Os in Verbin-
dung gebracht werden. Als Quelle dafür
dienen neben den Diagnosedaten (ODX,
CDD) auch Spezifikationsdaten mit nur
mittelbarem Diagnosebezug. Das sind
beispielsweise Netzwerkbeschreibungen
(dbc, arxml) oder Umgebungskonfigura-
tionen wie die Interface-Beschreibung
einer HiL-Konfiguration. Mit diesen Sys-
teminformationen können in einer Test-
umgebung die Ein- und Ausgänge des
Steuergeräts stimuliert und gemessen
werden.
Üblicherweise sind die Abhängigkeiten
zwischen Diagnose und Steuergeräteum-
gebung heute in den Diagnosedaten
nicht formal sondern - falls überhaupt
vorhanden - nur natürlichsprachlich
beschrieben. Dadurch ist die automati-
sierte Weiterverarbeitung im Allgemei-
nen nicht möglich. Heuristiken können
hier Abhilfe schaffen und zumindest
eine teilweise Nutzung zur Testautomati-
sierung ermöglichen. Liegen zusätzlich
Fahrzeughersteller-spezifische Detail-
kenntnisse über Art und Umfang der
Steuergeräte-I/O-Beschreibung vor, so
lassen sich daraus Tests der Diagnoseap-
plikation ableiteten. Insbesondere sind
dadurch automatisierte Diagnoseparame-
ter- und Fehlerspeichertests möglich.
FEHLERSPEICHERTESTS
Den Diagnosedaten entnimmt man die
Struktur und die formalen Inhalte der
Fehlerspeicherdaten: beispielsweise den
Aufbau der Fehlerumgebungsdaten aus
DIDs (Data Identifiers) oder die Setzbe-
dingungen für DTCs (Diagnostic Trouble
Codes). Letztere liegen jedoch meist in
einer nicht-formalen Beschreibung vor.
Wenn es gelingt, die Diagnosebeschrei-
bung in Beziehung zur Steuergeräteperi-
pherie zu bringen, kann geprüft werden,
ob ein DTC unter den richtigen Bedin-
gungen korrekt im Fehlerspeicher abge-
legt wird. Darüber hinaus können die
DTC-Statusübergänge und das korrekte
Löschen von DTCs validiert werden.
Für jeden DTC muss dafür die jewei-
lige Setzbedingung bekannt sein. Diese
besteht mindestens aus:
– I/O-Typ (Ein- oder Ausgang,
Netzwerk oder Sensor/Aktor)
– I/O-Bezeichnung
(Botschaftsname, Kanalname)
– Fehlerbild (zum Beispiel
Kurzschluss nach Masse).
Das Fehlerbild kann oft direkt aus
dem standardisierten Failure Type
Byte (FTB) des DTCs abgeleitet werden
(SAE J2012). Je nach Fehlerbild werden
zusätzlich Schwellwerte, Setzzeiten
und Informationen zur Fehlerüberwa-
chung benötigt (Monitor).
DIAGNOSEPARAMETERTESTS
Analog zu den Fehlerspeichertests wird
auch für Tests der Diagnoseparameter
die Beziehung zwischen Diagnosepara-
metern und den Steuergeräte-Pins benö-
tigt. Das Validieren eines Diagnosewer-
tes kann durch Vergleich mit
– einem Messwert eines
Steuergeräte-Pins
– einem Bus-Signal
– einem CCP/XCP-Signal.
erfolgen. Neben I/O-Typ und Bezeichner
sind auch Umrechnungen, wie zum
Beispiel Widerstand am Sensor in Tem-
peratur im Diagnoseparameter nötig,
um vergleichen zu können. Auch die
Aktualisierungsfrequenz am Diagnose-
parameter oder am Steuergeräteausgang
ist zu berücksichtigen. Weiterhin sind
Testwerte für die I/O-Stimulation nötig,
da diese selten in der Diagnosebeschrei-
bung dokumentiert sind und geeignete
Werte sich in der Regel nicht aus den
Spezifikationsdaten ableiteten lassen.
Sowohl für Fehlerspeicher- als auch
für Parametertests kann es Vorbedin-
gungen geben, damit eine zu testende
Funktion verfügbar ist. So muss bei-
spielsweise für das Schleifen der Messer
eines Feldhäckslers der Hauptantrieb
eingeschaltet sein. Diese Abhängigkeiten
müssen bei der Testausführung bekannt
sein und berücksichtigt werden.
ZIEL UND UMSETZUNG BEI CLAAS
Bei Claas sind viele der für Applika-
tionstests erforderlichen Daten formal
beschrieben. Ziel ist es daher auf Basis
dieser Informationen die Testerstellung
und -ausführung zu automatisieren. Um
dies zu erreichen setzt Claas das Tool
CANoe.DiVa von Vector Informatik ein.
Die in der Diagnosebeschreibung (CDD)
und anderen Quellen vorhandenen I/O-
Informationen werden in CANoe.DiVa
importiert um einen Testgenerator zu
parametrisieren. Anschließend werden
die generierten Applikationstests auto-
matisiert in der bereits für das zu tes-
tende Steuergerät vorhandenen CANoe-
Testumgebung ausgeführt, BILD 1.Alle für die Applikationstests relevanten
Daten pflegt Claas in einer Entwicklungs-
datenbank. Da sie auch in die Diagnose-
beschreibungsdatei importiert werden,
reicht diese in der Regel zur Generierung
der Parametertests aus. Nur für I/Os, die
im Diagnoseparameter andere Einheiten
verwenden als am Steuergeräte-Pin,
werden für den Test zusätzliche Umrech-
nungs informationen benötigt. Diese
werden in Form eines CANoe Mappings
beigesteuert, welches Signalwerte über
eine Umrechnungsvorschrift auf CANoe-
Systemvariablen abbildet.
Mit diesen Daten lassen sich drei ver-
schiedene Parametertests automatisiert
parametrisieren und generieren:
06I2015 10. Jahrgang 45
– Eingangstests: Die Testumgebung
stimuliert einen Sensor-Pin des
Steuergeräts. Der zugehörige Diagno-
separameter wird ausgelesen und mit
dem Wert am Pin verglichen.
– Ausgangstests: Ein Diagnosedienst
(I/O Control) schreibt einen neuen
Wert in das Steuergerät, der die
Ansteuerung eines Aktors bewirkt.
Anschließend wird der Wert am
Ausgang gemessen und mit dem
Wert des geschriebenen Diagnose-
parameters verglichen.
– Passive Tests: Einige Signale können
per Diagnosedienst nicht angesteuert
sondern nur ausgelesen werden. Die
Ansteuerung erfolgt an der Diagnose-
schicht vorbei alleine in der Steuerge-
räteapplikation. In diesem Fall kann
ein Test generiert werden, der den
anliegenden Wert per Diagnosedienst
liest und mit dem Wert am Steuergerä-
teeingang oder -ausgang vergleicht.
Im Gegensatz zu den Parameterdaten
sind die für Fehlerspeichertests benötig-
ten Daten bei Claas nicht vollständig in
der Diagnosebeschreibung vorhanden.
Sie werden daher aus der Entwicklungs-
datenbank als Excel-Datei exportiert und
zur Testparametrisierung eingelesen.
Im daraus abgeleiteten Test wird ein
Steuergeräte-I/O so stimuliert, dass es zu
einer Fehlersituation kommt. Anschlie-
ßend wird die richtige Ablage des DTCs
im Fehlerspeicher verifiziert. Durch
Beheben der Fehlersituation, Einbau von
Wartezeiten und wiederholtes Setzen
des Fehlerzustandes können zusätzlich
die DTC-Statusübergänge und die zum
Fehler abgelegten DTC-Umgebungsdaten
verifiziert werden. Das Überprüfen des
Löschens des Fehlerspeichers in ver-
schiedenen Sicherheitslevels rundet
die Fehlerspeichertests ab.
Zum Messen und Stimulieren von
Spannungen und Strömen an den Steuer-
geräte-Pins ist bei Claas ein HiL-System
von Vector Informatik im Einsatz – das
VT-System, BILD 2. Um die Daten der
Diagno sebeschreibung und der Entwick-
lungsdatenbank für das automatisierte
Ansteuern des VT-Systems verwenden zu
können, wurden Namenskonventionen
für die VT-System-Konfiguration definiert.
CLAAS ERHÖHT DIE TESTABDECKUNG
Diagnosefähige Steuergeräte befinden
sich bei Claas nicht nur in Mähdreschern
und Traktoren, sondern zum Beispiel
auch in Mähwerken und Ballenpressen.
In den größten Claas-Maschinen sind
dabei je nach Ausstattung bis zu 40 Steu-
ergeräte verbaut. Für alle diese Baurei-
hen müssen Applikationstests durchge-
führt werden. So wird sichergestellt,
dass die Steuergeräte per Claas Diagnose
System (CDS) bedient werden können.
Das größte von Claas verbaute Steuer-
gerät besitzt mehr als 75 I/Os, mit denen
je nach Maschinenausstattung bis zu 15
verschiedene erlebbare Maschinenfunk-
tionen realisiert sind. Zu diesen I/Os
gehören mehr als 200 DTCs, die im Test
geprüft werden müssen.
Durch den Ausbau der automatisierten
Erstellung und Durchführung von Appli-
kationstests reduziert sich der Aufwand
zur Verifikation der Steuergeräte erheblich.
Die herstellerspezifische Erweiterung des
Test-Tools erlaubt bei Claas eine Erhöhung
der Testabdeckung durch automatisierte
Tests für Fehlerspeicher und Diagnose-
parameter von vorher 55 auf nun 95 %.
Claas hat sich zum Ziel gesetzt, mittel-
fristig alle Steuergeräte automatisierten
Applikationstests mit CANoe.DiVa zu
unterziehen.
Der Aufwand für Diagnosetests an
Hardware-I/Os ist trotz automatischer
Testgenerierung und Testdurchführung
hoch. Insbesondere der Aufbau der Test-
umgebung ist zeitaufwendig. Je nach
Steuergerät kann die Ansteuerung ein-
zelner I/Os durchaus komplex sein,
sodass ein individueller Zugriff imple-
mentiert werden muss. Im Vergleich
dazu ist das Validieren von Diagnosepa-
rameter gegen Netzwerksignale nur mit
geringem initialen Aufwand verbunden:
BILD 2 Testaufbau bei Claas zum Messen
und Stimulieren von Spannungen an Steuer-
geräte-Pins mit dem VT-System von Vector
(© Claas)
BILD 1 Systemarchitektur:
Automatisierte Diagnose-
Applikationstests bei Claas
(© Vector Informatik)
ENTWICKLUNG DIAGNOSE
46
Die benötigte Infrastruktur kann über
das Generieren einer Restbussimulation
aus der K-Matrix automatisch erzeugt
und vom Test verwendet werden.
ZUSAMMENFASSUNG UND AUSBLICK
Das automatisierte Generieren und Aus-
führen von Tests, wie sie bei Claas mit
dem Werkzeug CANoe.DiVa von Vector
durchgeführt werden, bieten ein großes
Potenzial die Testtiefe zu erhöhen und
gleichzeitig den Testaufwand zu reduzie-
ren. Für eine vollständige Testabdeckung
durch CANoe.DiVa müssen manche
Funktionalitäten auch bei Claas zurzeit
noch manuell konfiguriert werden, da
noch keine formale Beschreibung verfüg-
bar ist, die für eine automatisierte Para-
metrisierung verwendet werden kann. So
gibt es beispielsweise I/Os, deren Ansteu-
erung für Parametertests sehr komplex
ist: Hier sind teilweise Vorbedingungen
in der Steuergeräteumgebung notwendig,
bevor es möglich ist, einen I/O wie beab-
sichtigt zu verwenden. Analog dazu gibt
es auch für einige Fehlerspeichertests
Vorbedingungen, die hergestellt werden
müssen, bevor ein Fehlermonitor aktiv
ist und folglich ein DTC erkannt und im
Fehlerspeicher abgelegt werden kann.
Die aktuell umgesetzten Tests lassen
sich noch um weitere Details ergänzen:
zum Beispiel Prüfen von Selbstheilungs-
funktionalität, Priorisieren der Fehler-
speicherablage oder auch das Testen
unterschiedlicher Fehlersituationen,
die zum selben DTC führen. An dieser
Stelle wird sich die Testlösung kontinu-
ierlich weiterentwickeln.
Auch in der Automobilindustrie ist ein
Trend zum Zusammenführen von Ent-
wicklungsdaten für elektrische und elek-
tronische Architekturen zu beobachten.
Datenbanken und Werkzeuge verfügen
damit direkt oder indirekt über Informa-
tionen, um Elektrik, Elektronik und
(Diagnose-) Software im Verbund auto-
matisiert zu testen.
Die weitere Formalisierung der Daten
ist zunächst mit höherem Aufwand
verbunden. Vor allem für automatisierte
Tests ergibt sich durch die formale
Beschreibung aber ein lohnenswert hohes
Optimierungspotenzial. Sowohl die vor-
anschreitende Standardisierung (etwa
Autosar) als auch die Integration und
Interoperabilität von Entwicklungswerk-
zeugen werden vielfältige neue Ansätze
auf dem Feld der automatisierten Testbar-
keit ermöglichen. CANoe.DiVa folgt die-
ser Entwicklung und wird von diesen
neuen Möglichkeiten Gebrauch machen,
um weitere automatisierte Tests der Diag-
noseapplikation abzuleiten. Die Möglich-
keiten für automatisierte, datengetrie-
bene Tests sind noch lange nicht ausge-
schöpft. Es bleibt spannend.
LITERATURHINWEIS[1] Peti, P.; Timmerberg, A.; Pfeffer, T.; Müller, S.;
Rätz, C.: Automatische Validierung der Diagnose-
services. In: ATZelektronik 3 (2008), Nr. 6, S. 58-64
READ THE ENGLISH E-MAGAZINEorder your test issue now:
DOWNLOAD DES BEITRAGSwww.springerprofessional.de/ATZelektronik