E N TWI C K LU N G

Mess- und Prüftechnik

Effizientes Testen in der Automobilelektronik Von der Simulation bis zur Diagnose Kaum ein Sachkundiger bestreitet heute noch die wichtige Rolle, die das Thema Testen im Entwicklungsprozess der Automobilelektronik einnimmt. Dennoch bleibt das Gefühl, dass in diesem Bereich bisher ungenutztes Potenzial freigesetzt werden kann. Gesucht sind geeignete Konzepte, Ideen und Hilfsmittel. Vector Informatik analysiert den aktuellen Stand der Technik, beleuchtet die in der Praxis problematischen Zusammenhänge und zeigt, dass bereits heute Werkzeuge zur Verfügung stehen, die konkrete Projektaufgaben rund um das Thema Testen in eleganter und effizienter Weise lösen.

1 Einleitung In den letzten zehn Jahren hat sich der Stellenwert der Automobilelektronik grundlegend verändert. Anfangs wurden nur wenige Steuergeräte im Automobil eingesetzt. Mittlerweile sind in einem Oberklassefahrzeug mehr als 60 verbaut. Als offensichtlich wurde, welches Potenzial zusätzliche elektronische Systeme in den Bereichen Sicherheit, Komfort oder energiesparendem Betrieb bieten, setzte eine starke Dynamik in der Fortentwicklung der Automobilelektronik ein. So basieren Innovationen heute zunehmend auf Elektronik, wobei ein großer Teil der Funktionalität vorrangig in der Software verankert ist. Angesichts der gestiegenen Komplexität sind umfangreiche und effektive Tests wichtiger als je zuvor. Durch den massiven Einsatz zahlreicher Elektronikkomponenten steigt die Anzahl möglicher Fehlerquellen überproportional an. Um Fehler frühzeitig mit möglichst geringen Kosten zu erkennen und zu beheben, sind Tests in allen Phasen der Steuergeräteentwicklung unverzichtbar. Einige Schwachstellen des Gesamtsystems offenbaren sich erst während der Integration der Komponenten in das Fahrzeug unter Real- und Echtzeitbedingungen. Damit ist das Testen zu einer abteilungs- und herstellerübergreifenden Disziplin geworden. Die massiven Elektronikprobleme in den Anfangsjahren haben gezeigt, wohin es führt, wenn diese Tatsachen nicht gebührend respektiert und systematische Tests vernachlässigt werden. Je später man die Probleme im Entwicklungsprozess identifiziert, umso schwerwiegender sind die Kostensteigerungen. Dies wird in extremer Weise deutlich, wenn Fehlerbehebungen nach der Auslieferung zu kostspieligen Rückrufaktionen führen. Inzwischen haben die Beteiligten der Automobilindustrie daraus gelernt und messen dem Thema eine große Bedeutung bei; dennoch lässt sich die Effizienz durch einen konsequenten Einsatz der zur Verfügung stehenden Mittel meist weiter steigern. Die Kosten für Tests nehmen einen nennenswerten Anteil des Projektbudgets in Anspruch. Weiterhin muss die korrekte Funktionalität des Steuergeräts sichergestellt sein. Deshalb ist es wichtig, dass mit klaren Konzepten ein Maximum an Testqualität und Testtiefe erreicht wird, indem man beispielsweise unzureichend automatisierte Arbeitsschritte durch moderne Methoden und Hilfsmittel ersetzt.

2 Werkzeug für Analyse, Simulation und Test Die Vernetzung der Steuergeräte bildet das Rückgrat der Kraftfahrzeugelektronik. Dabei ist die Methode der Restbussimulation eine wichtige Grundlage für die Durchführung von Steuergerätetests. Ohne eine zumindest rudimentäre Simulation der Steuergeräteumgebung lassen sich die meisten Steuergeräte nicht sinnvoll in Betrieb nehmen. Zum Beispiel arbeiten viele Steuergeräte nur dann korrekt, wenn die NetzwerkManagement-Funktionen bedient werden. CANoe von Vector Informatik ist ein weit verbreitetes Werkzeug zur Analyse, Simulation und zum Test verteilter, eingebetteter Systeme, Bild 1. Es wird vielfach für die Restbussimulation eingesetzt und unterstützt alle wichtigen Bussysteme – insbesondere CAN, LIN, MOST und FlexRay, für die Vector Informatik auch die passenden PC-Schnittstellen liefert. Über handelsübliche Interface-Karten lassen sich von CANoe aus auch die I/O-Leitungen der Steuergeräte ansprechen. Darüber hinaus hat Vector eine I/O-Hardware angekündigt, die diese allgemeinen Möglichkeiten um testspezifische Funktionen wie dem Aufschalten von Lasten und Kurzschlüssen direkt an die Steuergeräteanschlüsse ergänzt. Die unterschiedlichen Analysemöglichkeiten, aber auch die Simulationskomponenten und die Testabläufe setzen auf Modellen auf, die in Form von Datenbanken in das Werkzeug eingebunden werden. Das können beispielsweise die Kommunika-

Die Autoren

Dipl.-Ing. Thomas Riegraf ist als Global Product Line Manager verantwortlich für die Produktlinie „Tools for Networks and Distributed Systems“ bei der Vector Informatik GmbH in Stuttgart.

Dipl.-Ing. Siegfried Beeh ist als Teamleiter verantwortlich für Testwerkzeuge sowie Diagnose und Modellierung in CANoe bei der Vector Informatik GmbH in Stuttgart.

Dipl.-Inform. Stefan Krauß arbeitet als Produktmanager an der Konzeption der Testwerkzeuge bei der Vector Informatik GmbH in Stuttgart

Bild 1: CANoe integriert Analyse-, Simulations- und Testmöglichkeiten für vernetzte Steuergeräte Figure 1: CANoe integrates analysis, simulation and test capabilities for networked ECUs ATZ 07-08I2007 Jahrgang 109

649

E N TWI C K LU N G

Mess- und Prüftechnik

Zur Ausführung von CANoe reicht jeder einfache Arbeitsplatz-PC unter dem Betriebssystem Windows aus. Leistungsfähigere Testplätze mit verbesserten Echtzeitfähigkeiten lassen sich in einer Realtime-Konfiguration als Zwei-Rechner-Betrieb aufbauen. Dazu führt man die Restbussimulation und die eigentliche Testausführung auf einem eigenen Rechner (Echtzeit-Tester) unter einem Echtzeitbetriebssystem (Windows CE) aus, während für die grafische Benutzeroberfläche und die Auswertung ein getrennter PC (GUI) zur Verfügung steht, Bild 2. Die zwei Rechner kommunizieren via TCP/IP miteinander. Das System kann so auch als Testausführungsumgebung für einen Komponenten-HIL-Tester dienen.

3 Integration von Test und Entwicklung

Bild 2: Der Zwei-Rechner-Betrieb von CANoe Realtime bietet verbesserte Echtzeitfähigkeiten Figure 2: The dual-computer operation of CANoe Realtime offers improved real-time capabilities

Bild 3: Tests sind in allen Entwicklungsphasen unverzichtbar Figure 3: Tests are indispensable in all phases of development

tionsmatrizen im DBC-Format für CAN, Fibex für FlexRay, XML-Funktionskataloge für MOST oder LDF-Dateien für LIN sein. Ebenso lassen sich CDD- und ODX-Beschreibungen für die Diagnosefähigkeiten eines Steuergeräts verwenden. Neben unverzichtbaren Informationen über das System ent650

ATZ 07-08I2007 Jahrgang 109

halten die Testbeschreibungen auch symbolische Namen für Signale, Botschaften, Diagnose-Dienste usw. Dies erleichtert dem Testanwender und Testentwickler die Arbeit und schafft eine Abstraktionsschicht zwischen Test- und Kommunikationsbeschreibung.

Die heutigen Entwicklungsmodelle sehen Tests in verschiedenen Phasen der Entwicklung vor, Bild 3. In der Regel betrachtet man die einzelnen Tests als abgeschlossene, getrennte Tätigkeiten, die von spezialisiertem Personal an entsprechend ausgestatteten, dedizierten Arbeitsplätzen mit speziellen Werkzeugen, Sprachen und Methoden durchgeführt werden. Auch die Testerstellung wird in diesem Sinn oft als eigenständige Aufgabe organisiert, losgelöst von anderen Entwicklungstätigkeiten. Diese arbeitsteilige Vorgehensweise ergibt sich aus der Verteilung der vielfältigen Aufgaben im Entwicklungsprozess an jeweils spezialisierte Arbeitsgruppen. Wird diese Trennung allerdings zu strikt gelebt, sind die zahlreichen Berührungspunkte zwischen verschiedenen Entwicklungs- und Testaufgaben nicht optimal nutzbar. So verhindert zum Beispiel nur eine gute Abstimmung zwischen Komponenten- und Systemtest die teure Mehrfachentwicklung von inhaltlich gleichen Testfällen. Beim Einsatz kompatibler Werkzeuge können die einmal entwickelten Testfälle in den verschiedenen Bereichen als Grundlage für Weiterentwicklungen dienen. Durch die Vermeidung von Mehrfachentwicklungen werden Ressourcen frei, für die sich beispielsweise eine gewinnbringende Investition in die Validierung der existierenden Testfälle und deren Weiterentwicklung anbietet. Ein übergreifendes Testmanagement liefert eine solide Basis der Zusammenarbeit und sorgt bei gleichem Ressourcen-Einsatz für eine Optimierung der Testtiefe und -breite. Die Abstimmung hilft aber

auch, Testlücken zu erkennen und zu schließen. Neben der Verknüpfung der verschiedenen Testphasen sind auch die Entwicklungs- und die Testtätigkeiten aufeinander abzustimmen. Das Testen muss als integraler Bestandteil der Entwicklung verstanden werden und bedarf einer umfassenden Unterstützung durch die Methoden und Werkzeuge. Dieses muss neben der prozesstechnischen und organisatorischen Einbindung gewährleistet sein. Wichtig ist, dass Tests nicht nur in den geforderten formalen Verifikationsphasen, sondern auch entwicklungsbegleitend zur Verfügung stehen. Idealerweise führt man die Tests direkt am Arbeitsplatz des Steuergeräte-Entwicklers mit den dort vorhandenen Mitteln durch. CANoe bietet dazu eine Ablaufumgebung für die Testausführung an, die parallel zur Restbussimulation und den Analysefunktionen verwendbar ist. Besonders einfach gestaltet sich die Vorgehensweise, wenn CANoe von Entwicklern bereits für Zwecke der Restbussimulation und Analyse der Buskommunikation genutzt wird und so ohnehin am Arbeitsplatz vorhanden und bekannt ist. Die Testkomponente in CANoe erlaubt manuelle, halb- und vollautomatisch ablaufende Tests. Der Entwickler kann mit einfachen Tests beginnen, um sie später auszubauen und zu vervollständigen. Die Erstellung von komplexen Tests ist im Allgemeinen eine Aufgabe der Validierungsbereiche, die auf den Tests der Entwickler aufbauen. Eine wichtige Grundlage der Tests ist die Restbussimulation, die man idealerweise nicht von Hand aufbaut, sondern automatisch generiert und aus den Datenbanken der Systembeschreibung parametriert. Die eigentliche Arbeit übernehmen so genannte Modellierungs-DLLs (zum Beispiel Interaction Layer, Netzwerk-Management usw.), die dem Werkzeug beiliegen beziehungsweise die Vector in OEMspezifischen Modellierungspaketen für die Anwender zusammenstellt. Die von der Restbussimulation für die simulierten Knoten bereitgestellten Signale lassen sich direkt aus den Testskripten heraus erfassen, stimulieren oder manuell bedienen. Im Gegensatz zu den systematisch geplanten, durchgeführten und dokumentierten Aktivitäten der Testphasen, verzichtet man bei entwicklungsbegleitenden Tests meist auf eine formale Ausführung und Dokumentation. Trotzdem tragen diese Tests erheblich zur Gesamtqualität bei, weil sie den Entwickler in die Lage versetzen, der nachgeschalteten Testphase ein stabileres Produkt zur Verfügung zu stellen.

4 Reifegradbestimmung und Fehleranalyse Für die Einschätzung des Reifegrads eines Steuergeräts während der Entwicklung ist eine übergreifende Auswertung aller durchgeführten Tests notwendig. Die Qualität der einzelnen Testergebnisse hinsichtlich Verlässlichkeit und Relevanz ist dabei zwar zu berücksichtigen, wichtiger ist jedoch eine breite Abdeckung der geforderten Eigenschaften durch entsprechende Tests. Für die Reifegradanalyse sind daher auch die Ergeb-

nisse der weniger formal ausgeführten Tests hilfreich. Voraussetzung dafür ist neben der Protokollierung der Testdurchführung der konsequente Einsatz des Konfigurationsmanagements. Dies ist auch aus der Sicht qualitätsorientierter, strukturierter Entwicklungsprozesse unumgänglich. Bei jeder Ausführung eines Tests mit CANoe, sei es im Prüflabor oder am Arbeitsplatz, entsteht ein Testprotokoll. Es wird vom System ohne Zutun des Bedieners oder des Testfallentwicklers erstellt und ist damit ohne zusätzlichen Aufwand auch für

ATZ 07-08I2007 Jahrgang 109

651

E N TWI C K LU N G

Mess- und Prüftechnik

kommunikation. In der Rolle des Analysewerkzeugs erlaubt es CANoe, Aufzeichnungen (Loggings) beliebig abzuspielen und zu analysieren. Zweifellos ist es von Vorteil, wenn am Arbeitsplatz ein gleichartiges Testsystem wie am Prüfstand zum Einsatz kommt, so dass der Entwickler im Fehlerfall die Testfälle selbst nachvollziehen kann. In vielen Fällen wird sogar die Ausführung der betreffenden Testfälle möglich sein, auch wenn dazu vielleicht einige Vereinfachungen notwendig sein mögen, zum Beispiel ein Ansprechen nicht vorhandener Mess-Hardware auszuklammern.

Bild 4: Testfälle und Testergebnisse sind durch IDs eindeutig zugeordnet Figure 4: Test cases and test results are clearly referenced by IDs

Bild 5: Signale bieten eine Abstraktionsebene zwischen Botschaften und I/O-Anschlüssen einerseits sowie den Testdefinitionen und Simulationsmodellen andererseits Figure 5: Signals offer an abstraction level between messages and I/O connections on the one hand, and between test definitions and simulation models on the other hand

entwicklungsbegleitende Tests verfügbar. Das verwendete XML-Format der Protokolle ist offen gelegt; damit stehen sie anderen Werkzeugen für die Weiterverarbeitung zur Verfügung. So kann zum Beispiel ein Testmanagement-System die Protokolle im Sinne der Reifegradanalyse auswerten. Essenziell dafür ist die Zuordnung von Testergebnissen zu Testfällen und von Testfällen zu Anforderungen. Dies lässt sich einfach über eindeutige Kennzeichner (zum Beispiel eine Requirement (Anforderungs-) ID) erreichen, die der Testfallentwickler bei den einzelnen Testfällen vermerkt. CANoe übernimmt diese Kennzeichner automatisch in das Testprotokoll, so dass alle Testfälle, Testergebnisse und Anforderungen eindeutig zugeordnet sind, Bild 4. 652

ATZ 07-08I2007 Jahrgang 109

Mindestens so wichtig wie das Festhalten und Auswerten der Testergebnisse ist die Analyse der eigentlichen Fehlerursachen. Dafür stellen die meisten Testwerkzeuge aber keine oder nur rudimentäre Mittel bereit, nicht zuletzt weil die Fehleranalyse oftmals als völlig unabhängige Aufgabe für die Entwickler betrachtet wird. Diese haben zunächst das Problem, die im Test erkannten Fehler zu verstehen und nachzuvollziehen. Gerade bei den aus Prüflaboren gemeldeten Fehlern hat der Entwickler meist noch nicht einmal Zugriff auf die im Test verwendeten Systeme. Ein Muss am Prüfstand ist daher eine genaue Protokollierung des Testablaufs und eine Aufzeichnung jeder Interaktion mit dem Prüfling, insbesondere der Bus-

5 Signalabstraktion und Diagnose Abstraktion ist ein gängiges und wichtiges Hilfsmittel in der Software-Entwicklung und im Systemdesign zur Beherrschung von Komplexität. Dies gilt in gleicher Weise für den Umgang mit Tests. Steigende Funktionalität in den Steuergeräten erhöht nicht nur die Komplexität der Systeme, sondern erfordert auch immer umfangreichere und komplexere Tests. Die Wahl der richtigen Abstraktionsebene beim Verfassen von Tests beeinflusst nicht nur den Aufwand für die Testfallerstellung und damit die Kosten, sondern auch die Qualität der Testfälle. Wie alle anderen Softwarekomponenten können auch die Testfälle selbst Fehler enthalten und sind vor dem Einsatz zu prüfen. Ein weiterer Aspekt sind notwendige Wartungsaufgaben, zum Beispiel die Anpassung an veränderte Anforderungen und die Korrektur von Testfällen. Für den Test der Steuergerätefunktionalität bietet sich die Abstraktion auf Signalebene an, so wie auch im Steuergerät die eigentliche Applikation in der Regel auf einer Signalabstraktion aufgesetzt ist, Bild 5. Für den CAN-Bus liefert beispielsweise ein Interaction Layer im Steuergerät die Signalabstraktion. Genauso verwendet CANoe einen Interaction Layer; er parametriert sich selbst aus den Informationen der Netzwerkbeschreibungen, die auch der Erstellung der Steuergerätesoftware dienen. Dadurch ist sichergestellt, dass Steuergerät und Testumgebung dieselbe Abstraktionsschicht verwenden und somit optimal aufeinander abgestimmt sind. Die Signalabstraktion stellt gleichzeitig, zumindest auf Protokollebene, die Restbussimulation dar. Sie sorgt zum Beispiel dafür, dass zyklische Signale auch tatsächlich zyklisch übertragen werden. Beim Test findet das Steuergerät somit bezüglich der Buskommunikation eine realistische Umgebung vor. Außerdem lassen sich die Test-

gnalen und Botschaften zu prüfen. Die große Anzahl der Testfälle resultiert letztlich nur aus der großen Menge an möglichen Eingangs- und Ausgangsdaten. Aber auch bei anderen Steuergeräten finden sich gleichartige Muster. Abstrakt ausgedrückt bedeutet dies, man testet viele Funktionen dadurch, dass man das Steuergerät zunächst durch einen entsprechenden Stimulus in einen bestimmten Zustand versetzt und den erreichten Zustand anschließend prüft. Das wiederkehrende Muster dieser Testfälle ist also: Signale setzen (Sti-

mulation), die maximal zulässige Reaktionszeit abwarten, dann die Signale prüfen, die den neuen Steuergerätezustand abbilden. Mit etwas Erfahrung in der Anwendung von Testmustern erkennt man einige weitere Ablaufmuster, auf die sich viele Testfälle zurückführen lassen. Diese Muster sind eine Chance zur weiteren Optimierung der Testfallerstellung. CANoe bietet deshalb neben der klassischen Programmierung von Testfällen eine Möglichkeit, Testfälle auf der Basis von Mustern (Test Pattern) zu definieren. In diesem Fall

06

fälle bei einer Veränderung der Kommunikationsmatrix des Systems meist ohne Anpassung weiter verwenden. Bei gleicher Applikation können durch die Abstraktion Testfälle in ähnlichen Projekten wiederverwendet werden. Für den Test von Steuergeräten ist nicht nur die Signalschnittstelle von Bedeutung. Viele Funktionen der Steuergeräte lassen sich nur dann vernünftig testen, wenn man einen tieferen Zugang zum Steuergerät hat. Diese Zugänge stellen die Diagnoseund Kalibrierschnittstellen dar, die man über die vorhandenen Busschnittstellen eines Steuergeräts erreicht. Diese Schnittstellen über einfache Botschaftsfolgen anzusprechen, ist wenig sinnvoll, weil sich hinter der Kommunikation definierte Protokolle verbergen. Bequemer und sicherer ist es, wenn für die Diagnose und die Kalibrierung entsprechende Abstraktionen vorhanden sind. Für die Parametrierung der DiagnoseZugangsschicht sind bei CANoe Beschreibungsdateien des Werkzeugs CANdela beziehungsweise ODX-Beschreibungsdateien verantwortlich. Wenn keine Beschreibung der konkreten Diagnosefähigkeiten eines Steuergeräts zur Verfügung steht, ist eine generische Beschreibung für KWP2000 und für UDS verwendbar, die CANoe beiliegt. Sowohl die generische, also auch eine möglicherweise direkt auf das Steuergerät zugeschnittene, Diagnose-Beschreibungsdatei bietet einen komfortablen Zugriff auf die dort definierten Diagnosedienste. Man erhält hier also dieselben Abstraktionshilfsmittel und Vorteile wie bei der bereits beschriebenen Signalabstraktion. Über die Mess- und Kalibrierprotokolle CCP und XCP können die Testskripte von CANoe auch auf steuergeräte-interne Größen zugreifen. Die dazu notwendigen Steuergeräte-Beschreibungsdateien (A2L) sowie die Handhabung der Protokolle, erfolgt über das Mess- und Verstellwerkzeug CANape. CANoe steuert dabei CANape über die COM-Schnittstelle. Damit werden die gleichen Ziele wie im bereits dargestellten Fall der Signal- und der Diagnoseabstraktion erreicht.

.",30'0- ˆ %1

#-&*#5
"6$)
#&*
)*5;&
$00- 6 Effiziente Testerstellung Die genaue Betrachtung der Testfälle für ein Steuergerät zeigt, dass sich eine Vielzahl der Testfälle auf einige wenige, immer wiederkehrende Muster zurückführen lassen. Bei Gateway-Steuergeräten ist dies unmittelbar einleuchtend: Ein Großteil der Testfälle dient dazu, das Routing von Si-

1FSGFLUF
'BSCFO
EJF
)JU[F
LBMU
MBTTFO
%JF
HMBTLMBSF
VOE
TDIMBHGFTUF
)JHI5FDI'PMJF
.BLSPGPMˆ %1 
CJFUFU
BMMFSIzDITUF 8jSNFGPSNCFTUjOEJHLFJU
CJT
$
4PNJU
JTU
TJF
HFFJHOFU
GS
*TPMJFSUFJMF
VOE
BMMF
4UFMMFO
BO
EFOFO
FT
IFJ‡
IFSHFIU
6OE EJF
IFSWPSSBHFOEF
0CFSGMjDIFORVBMJUjU
EFS
'PMJF
TPSHU
GS
TDIzOTUF
%SVDLFSHFCOJTTF
.BLSPGPMˆ %1 
JTU
OVS
FJO
1SPEVLU BVT
EFS
VNGBOHSFJDIFO
1BMFUUF
IPDIXFSUJHFS
)JHI5FDI'PMJFO
WPO
#BZFS
.FIS
*OGPSNBUJPOFO
HJCU
FT
IJFS
XXXNBLSPGPMEF 0EFS
XFOO
4JF
VOT
NBJMFO NBLSPGPM!CBZFSNBUFSJBMTDJFODFDPN #BZFS
.BUFSJBM4DJFODF
"(

-FWFSLVTFO
%FVUTDIMBOE

ATZ 07-08I2007 Jahrgang 109

653

8mlg]d]cljacÜYmkÜ ]jkl]jÜ?Yf\œ

Bild 6: Die Verwendung von Testmustern (Test Patterns) abstrahiert den eigentlichen Ablauf des Testfalls und erleichtert so die Testentwicklung Figure 6: The use of test patterns abstracts the actual execution of the test case and thereby simplifies test development

IgZ]jlÜ9gk[`Ü>eZ?Ü©?jk_‘ª

8mlg]d]cljac¤ 8mlg]d]cljgfac ‚‘–Üngddkl‘Ü1Z]jYjZ‘Üm‘Ü]jo‘Ü8m^d‘Ü ‡‡„‘Ü‚€‡ÜJ‘Ü>]Z‘Ü]f]jYlgj]fÜmf\Ü JlYjl]jÜ¥ÜCa[`ll][`facÜ¥ÜJ[`]aZ]fj]afa¥ _mf_Ü¥ÜDacjg]d]cljgfacÜaeÜBjY^l^Y`jr]m_Ü ¥Ü>jmf\dY_]fÜ\]jÜ?YdZd]al]jl][`facÜ¥ÜdgkkYjÜmf\ÜKYZ]dd]fÜrmjÜDacjg]d]cljg¥ facÜ¥ÜJ]fkgj]fÜ¥Ü;Yl]fn]jYjZ]almf_ ;8JÜ9L:? ;a]Ükl1jeak[`]Ü]kYel^Y`jr]m_Ü_]fgee]f‘Ü 8mkÜ\a]k]eÜ>jmf\Üomj\]Ü]af]Üo]al]j]Ü E]mZ]YjZ]almf_Ü\]kÜZ]o`jl]fÜGjYpak¥ =Y[`Zm[`]kÜfglo]f\a_‘Ü;a]ÜYclm]dd]fÜ ]lja]¥ Z]kl]m]jmf_–Ü]d]cljgfak[`]ÜC]fckqkl]e]Ü mf\Ü?qZja\Yflja]Z]Ü`YZ]fÜafÜ\a]k]jÜ8m^¥ dY_]Ü9]j1[cka[`la_mf_Ü_]^mf\]f‘

9
AY–Üa[`ÜZafÜafl]j]kka]jlÜmf\ÜZ]kl]dd] ÜÜÜÜÜeZ?Ü©?jk_‘ªÜ 8mlg]d]cljac¤8mlg]d]cljgfac ‚‘Ü8m^d‘܇‡„‘Ü>]Z‘Ü
MgjfYe]Ümf\ÜEYe]

€~܇„Ü‚ƒ…

=ajeYÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ ÜÜÜÜÜÜ8Zl]admf_ JljYv]Ü©Zall]ÜB<@EÜGgkl^Y[`ª GCQ¤Fjl 8ZjY`Ye¥Caf[gdf¥JljYv]܁ƒÜ ;¥ƒ‚~…†ÜNa]kZY\]f =Yp܇ƒ~~¤„…„…¥‡ ooo‘na]o]_‘\] f\]jmf_]fÜngjZ]`Ydl]f‘Ü]k[`^lk^1`j]j’Ü8f\j]YkÜB+kl]jk–Ü ;j‘ÜIYd^Ü9ajc]dZY[`–Ü8>ÜNa]kZY\]fÜ?I9܆„‚

654

ATZ 07-08I2007 Jahrgang 109

Bild 7: Testfälle lassen sich mit Generatoren aus sehr unterschiedlichen Quellen erzeugen Figure 7: Test cases can be created from very different sources using generators

ist kein Ausprogrammieren der Musterinhalte mehr erforderlich, da die Abläufe bekannt und in den angebotenen Mustern bereits fest integriert sind, Bild 6. Die Testfallerstellung reduziert sich auf die Definition des Soll-Verhaltens inklusive eventuell benötigter Zusatzangaben wie beispielsweise zu tolerierende Einschwingzeiten. Soweit sinnvoll, setzen die bereitgestellten Testmuster (test pattern) selbst auf der beschriebenen Signalabstraktion auf und erlauben über die eingebundenen Datenbanken symbolischen Zugriff auf Signale, Botschaften usw. Außerdem ist die Verwendung von Diagnosediensten oder I/O-Signalen möglich. Kurz: Die gesamte Testinfrastruktur von CANoe ist auch mit Testmustern nutzbar. Bei weiterreichenden Anforderungen gibt es nach wie vor die Möglichkeit, die Testfälle „auszuprogrammieren“. Die (automatische) Generierung von Testfällen ist ein weiteres Hilfsmittel zur effizienten Testerstellung. Dies ist jedoch

nur möglich, wenn entsprechende Informationsquellen zur Verfügung stehen. Die Inhalte der generierten Tests sind zwangsläufig auf die Beschreibungsebenen und -tiefen der Quellen beschränkt. Dennoch liefert die Generierung wertvolle Unterstützung, vor allem wenn es gilt, die formal definierten Basiseigenschaften eines Steuergeräts mit Tests abzudecken. Durch den vergleichsweise geringen Aufwand bei der Testerstellung sind generierte Tests sehr schnell einsatzfähig und leisten damit einen wichtigen Beitrag zu einer frühzeitigen Entdeckung von Fehlentwicklungen. Auch die Werkzeugkette von Vector verwendet solche Testgeneratoransätze. Beschreibungsdateien wie die DBC-Datenbank oder CANdela Definitionen bilden für den Generator die Quelle, Bild 7. Er erzeugt daraus die Testfälle, die CANoe anschließend ausführt. Da die Testskripte auf die gesamte Werkzeug-Infrastruktur zurückgreifen können, werden die Testgeneratoren oft einfach und simpel konzipiert. Mit wenig

Aufwand lässt sich zum Beispiel ein Generator erstellen, der aus einer kundenspezifischen Gateway-Beschreibung (zum Beispiel in Form einer Datenbank oder einer Excel-Tabelle) entsprechende Testfälle erzeugt. Dank der bereits beschriebenen Test Pattern ist dazu nur eine einfache Transformation der kundenspezifischen Daten in das Format der Test Pattern notwendig. Einen solchen Generator können die Anwender ohne Weiteres selbst erstellen. Darüber hinaus reichende Unterstützung bietet Vector in Form projektbezogener Dienstleistungen an.

7 Zusammenfassung Den steigenden Anforderungen an die Steuergerätetests können Automobilhersteller und Zulieferer nur durch effiziente Testerstellung und automatische Testdurchführung begegnen. Das vorgestellte Testwerkzeug CANoe von Vector Informatik bietet für die Automobilelektronik mit Signalabstraktion, der Einbindung von Diagnose-, Kalibrierungs- und I/O-Schnittstellen, dem Konzept der Testmuster und mit Testfallgeneratoren eine erprobte Lösung zur Umsetzung der Testaufgaben. CANoe ist eine leistungsfähige Ablaufumgebung für Tests von Steuergeräten und Netzwerken. Das Werkzeug erlaubt die frühzeitige Erstellung und Durchführung von Tests mit geringem Aufwand bereits am Arbeitsplatz des Entwicklers. Die offenen Schnittstellen ermöglichen die enge Einbindung des Werkzeugs in eine übergreifende Teststrategie und werkzeuggestützte Testverwaltung. Schon heute lässt sich mit der entsprechenden Einbindung von CANoe die Ermittlung von Reifegraden realisieren, was vielen Anwendern vielleicht noch immer nur als Zukunftsvision vorschweben mag. Vector entwickelt CANoe für den Einsatz in den genannten Bereichen fortlaufend weiter und unterstützt so die Anwender mit einer modernen, effizienten Testplattform. O

Systemlösungen auf dem Prüfstand Vogelsang & Benning entwickelt und liefert komplexe Prüfanlagen und Prüfsysteme zur automatischen Funktionsprüfung in der Serienproduktion sowie für den Entwicklungsund Auditbereich.

Wir bieten unseren Partnern • schlüsselfertige Lösungen für die Produktion und Prüfung komplexer Produkte • ausbaufähige Lösungen von der A-Musterfertigung bis zur Großserie • FMEA, Risikoanalyse, Handling, Montage, Prüfung, Kennzeichnung, Rückverfolgbarkeit • Konstruktion, Fertigung, Fähigkeitsnachweise, Montage, Inbetriebnahme, Schulung, Anlaufunterstützung Vogelsang & Benning Prozeßdatentechnik GmbH Hansastraße 92 D-44866 Bochum Postfach 60 02 62 D-44842 Bochum

Tel. + 49 (0) 2 32 75 47-0 Fax + 49 (0) 2 32 75 47-100 [email protected] www.vogelsangbenning.de

www.icd-marketing.de

Schneller Spezialisten finden mit Hays.

Sie brauchen sofort einen ausgewiesenen Spezialisten für ein zeitkritisches Projekt oder zur temporären Unterstützung Ihres Teams? Hays vermittelt Ihnen schnell und effizient den richtigen Experten – in der Regel innerhalb eines Arbeitstages. Unser Pool umfasst über 75.000 hochqualifizierte Spezialisten aus den Bereichen IT, Engineering, Finance und Legal, die umfassendes Know-how und langjährige Erfahrung in Ihr Unternehmen einbringen. Mehr darüber auf www.hays.de

Download des Beitrags online unter I Download this article online at www.all4engineers.de

Specialist Recruitment hays.de For an English version of this article, see ATZ Worldwide. W O R L D W I D E

ATZ 07-08I2007 Jahrgang 109

655