Datengetriebene automatisierte Diagnose-Applikations

© Claas, Vector Informatik
ENT WICKLUNG DIAGNO SE
AUTOREN
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-
Dipl.-Ing. (FH) Nils Niedermark
ist 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 SoftwareEntwickler für CANoe.DiVa tätig.
zeugherstellers. Die entsprechende Schnittstelle eines Steuergeräts kann so nachweislich efﬁzient 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 Diagnoseparametern und Fehlercodes möglich, wie die Zusammenarbeit von Claas und Vector Informatik zeigt.
44
Dipl.-Inf. Simon Müller
ist Produktmanager in der
Produktlinie Kfz-Diagnose bei
der Vector Informatik GmbH
in Stuttgart.
AUFGABENSTELLUNG
Der Landmaschinenkonzern Claas
beschreibt in seinen Diagnosedaten
die Beziehung zwischen Diagnoseparametern und den Steuergeräte Ein- und
Ausgängen. Auch die Beschreibung
von Fehlersetzkriterien wird für Neuimplementierungen formal dokumentiert. In der Vergangenheit wurden diese
Informationen zur Durchführung von
manuellen Tests verwendet oder Testingenieure implementierten spezielle Testfälle. Eine breite Testabdeckung konnte
jedoch nicht erreicht werden.
In Zusammenarbeit mit der Vector
Informatik werden diese Verbindungsinformationen automatisiert mit der vorhandenen Netzwerk-(K-Matrix) und
Hardwarebeschreibung verknüpft. Basierend auf bereits verfügbaren Speziﬁkationsdaten wie CDD (CANdela Diagnostic
Data) oder ODX (Open Diagnostic Data
Exchange) werden vollautomatisiert Diagnoseapplikationstests generiert und in
einer Testumgebung ausgeführt. Durch
automatisierte Stimulation der Steuergeräteumgebung wird das inhaltlich korrekte Verhalten der Diagnose-Implementierung getestet. Dazu werden zum
Beispiel Signale in der Bussimulation
modiﬁziert oder gezielt Hardware-I/Os
angesteuert. So ist es möglich, das korrekte Setzen von Diagnoseparametern
zu prüfen oder Fehlerzustände zu erzeugen und die richtige Ablage zu testen.
AUTOMATISIERTE
TESTGENERIERUNG
Um eine automatisierte Testgenerierung
und Testdurchführung von Applikationstests zu erreichen, müssen Diagnoseparameter und Steuergeräte-I/Os in Verbindung gebracht werden. Als Quelle dafür
dienen neben den Diagnosedaten (ODX,
CDD) auch Speziﬁkationsdaten mit nur
mittelbarem Diagnosebezug. Das sind
beispielsweise Netzwerkbeschreibungen
(dbc, arxml) oder Umgebungskonﬁgurationen wie die Interface-Beschreibung
einer HiL-Konﬁguration. Mit diesen Systeminformationen können in einer Testumgebung die Ein- und Ausgänge des
Steuergeräts stimuliert und gemessen
werden.
Üblicherweise sind die Abhängigkeiten
zwischen Diagnose und Steuergeräteumgebung heute in den Diagnosedaten
nicht formal sondern - falls überhaupt
06I2015
10. Jahrgang
vorhanden - nur natürlichsprachlich
beschrieben. Dadurch ist die automatisierte Weiterverarbeitung im Allgemeinen nicht möglich. Heuristiken können
hier Abhilfe schaffen und zumindest
eine teilweise Nutzung zur Testautomatisierung ermöglichen. Liegen zusätzlich
Fahrzeughersteller-speziﬁsche Detailkenntnisse über Art und Umfang der
Steuergeräte-I/O-Beschreibung vor, so
lassen sich daraus Tests der Diagnoseapplikation ableiteten. Insbesondere sind
dadurch automatisierte Diagnoseparameter- 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 Identiﬁers) oder die Setzbedingungen für DTCs (Diagnostic Trouble
Codes). Letztere liegen jedoch meist in
einer nicht-formalen Beschreibung vor.
Wenn es gelingt, die Diagnosebeschreibung in Beziehung zur Steuergeräteperipherie zu bringen, kann geprüft werden,
ob ein DTC unter den richtigen Bedingungen korrekt im Fehlerspeicher abgelegt 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 jeweilige 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überwachung benötigt (Monitor).
DIAGNOSEPARAMETERTESTS
Analog zu den Fehlerspeichertests wird
auch für Tests der Diagnoseparameter
die Beziehung zwischen Diagnoseparametern und den Steuergeräte-Pins benötigt. Das Validieren eines Diagnosewertes 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 Temperatur im Diagnoseparameter nötig,
um vergleichen zu können. Auch die
Aktualisierungsfrequenz am Diagnoseparameter oder am Steuergeräteausgang
ist zu berücksichtigen. Weiterhin sind
Testwerte für die I/O-Stimulation nötig,
da diese selten in der Diagnosebeschreibung dokumentiert sind und geeignete
Werte sich in der Regel nicht aus den
Speziﬁkationsdaten ableiteten lassen.
Sowohl für Fehlerspeicher- als auch
für Parametertests kann es Vorbedingungen geben, damit eine zu testende
Funktion verfügbar ist. So muss beispielsweise 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 CLA AS
Bei Claas sind viele der für Applikationstests 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/OInformationen werden in CANoe.DiVa
importiert um einen Testgenerator zu
parametrisieren. Anschließend werden
die generierten Applikationstests automatisiert in der bereits für das zu testende Steuergerät vorhandenen CANoeTestumgebung ausgeführt, BILD 1.
Alle für die Applikationstests relevanten
Daten pﬂegt Claas in einer Entwicklungsdatenbank. Da sie auch in die Diagnosebeschreibungsdatei 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 Umrechnungsinformationen benötigt. Diese
werden in Form eines CANoe Mappings
beigesteuert, welches Signalwerte über
eine Umrechnungsvorschrift auf CANoeSystemvariablen abbildet.
Mit diesen Daten lassen sich drei verschiedene Parametertests automatisiert
parametrisieren und generieren:
45
ENT WICKLUNG DIAGNO SE
Löschens des Fehlerspeichers in verschiedenen Sicherheitslevels rundet
die Fehlerspeichertests ab.
Zum Messen und Stimulieren von
Spannungen und Strömen an den Steuergeräte-Pins ist bei Claas ein HiL-System
von Vector Informatik im Einsatz – das
VT-System, BILD 2. Um die Daten der
Diagnosebeschreibung und der Entwicklungsdatenbank für das automatisierte
Ansteuern des VT-Systems verwenden zu
können, wurden Namenskonventionen
für die VT-System-Konﬁguration deﬁniert.
CLA AS ERHÖHT
DIE TESTABDECKUNG
BILD 1 Systemarchitektur:
Automatisierte DiagnoseApplikationstests bei Claas
(© Vector Informatik)
– Eingangstests: Die Testumgebung
stimuliert einen Sensor-Pin des
Steuergeräts. Der zugehörige Diagnoseparameter wird ausgelesen und mit
dem Wert am Pin verglichen.
BILD 2 Testaufbau bei Claas zum Messen
und Stimulieren von Spannungen an Steuergeräte-Pins mit dem VT-System von Vector
(© Claas)
46
– 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 Diagnoseparameters verglichen.
– Passive Tests: Einige Signale können
per Diagnosedienst nicht angesteuert
sondern nur ausgelesen werden. Die
Ansteuerung erfolgt an der Diagnoseschicht vorbei alleine in der Steuergerä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ötigten Daten bei Claas nicht vollständig in
der Diagnosebeschreibung vorhanden.
Sie werden daher aus der Entwicklungsdatenbank 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 veriﬁziert. 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
veriﬁziert werden. Das Überprüfen des
Diagnosefähige Steuergeräte beﬁnden
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 Steuergeräte verbaut. Für alle diese Baureihen müssen Applikationstests durchgeführt werden. So wird sichergestellt,
dass die Steuergeräte per Claas Diagnose
System (CDS) bedient werden können.
Das größte von Claas verbaute Steuergerät besitzt mehr als 75 I/Os, mit denen
je nach Maschinenausstattung bis zu 15
verschiedene erlebbare Maschinenfunktionen 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 Applikationstests reduziert sich der Aufwand
zur Veriﬁkation der Steuergeräte erheblich.
Die herstellerspeziﬁsche Erweiterung des
Test-Tools erlaubt bei Claas eine Erhöhung
der Testabdeckung durch automatisierte
Tests für Fehlerspeicher und Diagnoseparameter von vorher 55 auf nun 95 %.
Claas hat sich zum Ziel gesetzt, mittelfristig 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 Testumgebung ist zeitaufwendig. Je nach
Steuergerät kann die Ansteuerung einzelner I/Os durchaus komplex sein,
sodass ein individueller Zugriff implementiert werden muss. Im Vergleich
dazu ist das Validieren von Diagnoseparameter gegen Netzwerksignale nur mit
geringem initialen Aufwand verbunden:
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 Ausfü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 reduzieren. Für eine vollständige Testabdeckung
durch CANoe.DiVa müssen manche
Funktionalitäten auch bei Claas zurzeit
noch manuell konﬁguriert werden, da
noch keine formale Beschreibung verfügbar ist, die für eine automatisierte Parametrisierung verwendet werden kann. So
gibt es beispielsweise I/Os, deren Ansteuerung für Parametertests sehr komplex
ist: Hier sind teilweise Vorbedingungen
in der Steuergeräteumgebung notwendig,
bevor es möglich ist, einen I/O wie beabsichtigt 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 Selbstheilungsfunktionalität, Priorisieren der Fehlerspeicherablage oder auch das Testen
unterschiedlicher Fehlersituationen,
die zum selben DTC führen. An dieser
Stelle wird sich die Testlösung kontinuierlich weiterentwickeln.
Auch in der Automobilindustrie ist ein
Trend zum Zusammenführen von Entwicklungsdaten für elektrische und elektronische Architekturen zu beobachten.
Datenbanken und Werkzeuge verfügen
damit direkt oder indirekt über Informationen, um Elektrik, Elektronik und
(Diagnose-) Software im Verbund automatisiert 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 voranschreitende Standardisierung (etwa
Autosar) als auch die Integration und
Interoperabilität von Entwicklungswerkzeugen werden vielfältige neue Ansätze
auf dem Feld der automatisierten Testbarkeit ermöglichen. CANoe.DiVa folgt dieser Entwicklung und wird von diesen
neuen Möglichkeiten Gebrauch machen,
um weitere automatisierte Tests der Diagnoseapplikation abzuleiten. Die Möglichkeiten für automatisierte, datengetriebene Tests sind noch lange nicht ausgeschöpft. Es bleibt spannend.
LITERATURHINWEIS
[1] Peti, P.; Timmerberg, A.; Pfeffer, T.; Müller, S.;
Rätz, C.: Automatische Validierung der Diagnoseservices. In: ATZelektronik 3 (2008), Nr. 6, S. 58-64
DOWNLOAD DES BEITRAGS
www.springerprofessional.de/ATZelektronik
READ THE ENGLISH E-MAGAZINE
order your test issue now:
[email protected]

Download Report