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:

springervieweg-service@springer.com

DOWNLOAD DES BEITRAGSwww.springerprofessional.de/ATZelektronik