Modellbasierte erzeugung von testfällen Mit integrierter fehleranalyseZur Validierung von Fahrzeugfunktionen werden Testfälle derzeit per Hand aus der Liste der Systemanforderungen

abgeleitet. Nachteilig sind zum einen der damit verbundene hohe Arbeitsaufwand, zum anderen der fehlende

Nachweis einer Abdeckung der Anforderungen durch die abgeleiteten Testfälle. Daher wurden im Rahmen des

EU-Projekts „Mogentes“ Methoden entwickelt, die das Auffinden von Testfällen automatisieren und gleichzeitig

einen Nachweis über die Abdeckung der Anforderungen sowie auch die Abwesenheit bestimmter Fehler liefern

können. Ford als einer der industriellen Partner stellte Beispielprojekte und Demonstratoren für Fahrzeugfunktio-

nen zur Verfügung, wie die Funktion „Diebstahl-Alarmanlage“. Das Austrian Institute of Technology AIT (Wien)

übernahm die Projektleitung.

62

Entwicklung TESTEN

AusgAngslAgE

Ein Fahrzeug besteht heutzutage aus vie-len elektrischen, elektronischen und elekt-romechanischen Bauteilen, die eine große Anzahl von Sicherheits- und Komfortfunk-tionen bereitstellen. Die aktive Sicherheit wird beispielsweise durch das elektroni-sche Stabilitätsprogramm (ESP) erhöht. Eine Herausforderung stellt das Zusam-menspiel der verschiedenen Funktionen im Fahrzeug dar. Die Klimaanlage erhöht beispielsweise die Motordrehzahl, um mehr Leistung zu entnehmen, oder schal-tet beim Einlegen des Rückwärtsgangs die Zuluft ab.

Um die notwendige Funktionalität des einzelnen Systems wie auch deren Zu -sammenspiel im Fahrzeug zu gewährleis-ten, werden die Systeme bei Ford am Ent-wicklungszentrum in Köln im Gesamtver-bund aufgebaut und verifiziert. Dazu werden die Bauteile auf einen Versuchs-träger montiert und wie im Fahrzeug mit Kabeln und Bussystemen verbunden. Be -dieneingriffe durch den Menschen können dabei entweder durch Handschalter, Pedale oder Lenkrad manuell getätigt werden oder durch Hardware-in-the-Loop (HiL) Systeme simuliert werden. Durch die Anbindung an diese HiL-Systeme können Testfälle darüber hinaus auch automatisch durchgeführt werden.

Das Überprüfen der Anforderungen durch geeignete Testfälle geschieht ent-wicklungsbegleitend. Ziel ist dabei, die Testfälle möglichst frühzeitig im Entwick-lungsprozess zur Verfügung zu haben, damit man ebenso frühzeitig auf den lau-fenden Entwicklungsprozess Einfluss nehmen kann. Die Kosten zur Änderung von Funktionen und Bauteilen wachsen schnell an, je weiter man sich auf das Ende des Entwicklungsprozesses zube-wegt. Eine Frage bleibt allerdings offen: Wie kommt man möglichst frühzeitig und mit möglichst geringem Aufwand an geeignete Testfälle?

ZiElsEtZung und bEtEiligtE PArtnEr

Testfälle zur Funktionsvalidierung werden derzeit von den Prüfingenieuren aus den an die Systeme gestellten Anforderungen abgeleitet. Ein Forschungsziel ist, den damit verbundenen Aufwand zu reduzie-ren und gleichzeitig eine möglichst große

Abdeckung aller Anforderungen sowie die Abwesenheit kritischer Implementierungs-fehler zu garantieren. Daher wurden im Rahmen des EU-Projekts Mogentes (Model-based generation of tests for embedded systems) Methoden und Werkzeuge ent-wickelt, die diese Arbeit automatisieren beziehungsweise unterstützen können.

Mogentes war Teil des siebten europä-ischen Rahmenprogramms FP7 (weiter-führende Informationen im Internet ver-fügbar, ❶. Durch Zusammenarbeit von Forschungsinstituten, Universitäten und Partnern aus der Industrie wurde versucht, die oben angesprochenen Fragen zu lösen. Die industriellen Partner lieferten hierbei aktuelle Applikationen, an denen die Wir-kungsweise der bei dem Projekt entwickel-ten Methoden und Werkzeuge demons-triert wurden.

Die Leitung und Koordination von Mogentes lag beim Austrian Institute of Technology AIT (Wien). Beteiligte Univer-sitäten waren die Eidgenössische Technische Hochschule Zürich in Zusammenarbeit mit der Universität Oxford, die Budapest University of Technology and Economics sowie die TU Graz. Die beteiligten Univer-sitäten untersuchten die theoretischen Grundlagen der automatischen Testfallge-nerierung. Kooperierendes Forschungsins-titut ist das SP Technical Research Institute of Sweden (Borås). Das Institut beschäf-tigte sich mit der Fehlereinbringung in Systeme.

Industrielle Partner aus dem Eisenbahn-bereich waren die Thales Rail Signalling Solutions GesmbH (Wien), die Prolan Irá-nyítástechnikai ZRT (Budapest) und Pro-ver Technology AB (Stockholm). Die ers-teren beiden stellten Beispielanwendungen aus der Stellwerktechnik zur Verfügung. Prover ergänzte sein Verifikationswerk-zeug um neue Techniken. Ein Demonstra-tor für den Agrarbereich kam von der Firma Re:Lab S.R.L. (Reggio Emilia, Ita-lien) mit ihrer Anwendung der Positions-regelung einer Baggerschaufel via ISO-BUS. Das Ford-Forschungszentrum in Aachen und die Ford-Werke GmbH stell-ten als Demonstrator unter anderem die Fahrzeugfunktion „Diebstahl-Alarman-lage“ zur Verfügung. An ihr wurden die im Projekt gefundenen Methoden und Werkzeuge analysiert und bewertet sowie deren mögliche Integration am HiL-Prüf-stand aufgezeigt [3]. ① liefert eine Über-sicht über die Projektpartner.

diPl.-Phys. EkkEhArd PofAhlarbeitet im Bereich Electrical

Integration im Ford Entwicklungs-zentrum Köln.

diPl.-ing. JohAnnEs wiEssAllAarbeitet im Bereich Fahrzeug-dynamik im Ford Forschungs-

zentrum Aachen.

diPl.-ing. otto hofmAnn arbeitet im Bereich Fahrzeug-dynamik am Ford Forschungs-

zentrum Aachen.

diPl.-ing. (fh) thomAs lEnZEnarbeitet im Bereich Electrical

Integration am Ford Entwicklungs-zentrum Köln.

diPl.-ing. ruPErt schlickarbeitet als Wissenschaftler im

Geschäftsfeld Safe and Autonomous Systems des AIT Austrian Institute of

Technologies in Wien.

AUToREN

6301I2012 7. Jahrgang

mEthodEn

Mogentes als Gemeinschaftsprojekt war nicht nur an einer speziell für den HiL-Prüfstand von Ford zugeschnittenen Lösung interessiert, sondern erforschte auch weitere zukunftsweisende Metho-den. Bevor diese in Mogentes entwickel-ten Methoden näher beschrieben werden, wird hier noch auf eine wichtige Klassifi-zierung der Situation für den Software-Test eingegangen. Die beiden möglichen Ausgangslagen erfordern ein differenzier-tes Vorgehen, abhängig davon, inwieweit der Quellcode beim Testen zugänglich ist: : Bei einer „White Box“-Situation liegt

der Quellcode oder Modelle, aus denen er generiert wird, vollständig vor. Dies ist der Fall, wenn die Funktion eine Eigenentwicklung ist oder eine entspre-chende Offenlegung mit dem Zulieferer der Funktion vereinbart wurde.

: Bei der „Black Box“-Variante sind meist nur die Schnittstellenspezifikationen sowie die an das System gestellten Anforderungen bekannt. Dieser Fall tritt in der Systemintegration in der Auto-mobilentwicklung häufiger auf.

Für den Fall eines „White Box“-Tests wurden im Projekt zwei Ansätze verfolgt. Beide verwenden dabei als Basis die Modellierung der Funktion in Matlab/Simulink. Projektpartner SP als Toolent-wickler bringt dabei, um die Stabilität der Software zu prüfen und die Fehlerbehand-lungsmechanismen zu testen, gezielt Feh-ler in die Software ein („Fault injection“). Das Modell der Funktion wird dahinge-hend bewertet, für welche Teile des Algo-rithmus sich Hardware-Fehler am schwers-ten auswirken. Diese Teile werden als besonders kritisch und sensitiv eingestuft und müssen in den folgenden Schritten robuster ausgelegt werden. SP hat für die Analyse mittels Fault Injection spezielle Software entwickelt, unter anderem das Werkzeug MODIFI [5]. Ein anderer An -satz wurde von der ETH Zürich/Universi-tät Oxford untersucht. Die Forscher verän-dern dabei den aus dem Modell generier-ten Quellcode in C und untersuchen die Auswirkungen dieser Mutationen. Beide Ansätze sind bei Ford eher in den Hinter-grund gerückt, da im Fahrzeugbereich viel Software von externer Seite geliefert wird. Damit ist der Quellcode nicht in dem Maße zugänglich, sodass eine dieser Methoden anwendbar wäre.

Im Fall einer „Black Box“-Anwendung wird ein anderer Weg beschritten. Aus den Anforderungen, die meist umgangs-sprachlich vorliegen, wird ein Modell erstellt, ❷. Dieses Anforderungsmodell ist in UML („Unified Modelling Language“) programmiert. Man verwendet UML-Zustandsautomaten, da sie vielen Ent-wicklern bereits geläufig sind und die Kommunikation mit dem Fachbereich gut unterstützen können.

In das Anforderungsmodell werden ge -zielt Mutationen eingebracht. Jetzt muss

man Eingangsvektoren ermitteln, die einen Unterschied zwischen dem Ausgang des Originalmodells und dem des mutierten Modells zur Folge haben. Es kommt also das Prinzip der Fehlermodellierung zur Anwendung. Damit überprüfen generierte Testfälle nicht nur die Erfüllung von An -forderungen, sondern auch die Abwesen-heit bestimmter Fehler [2].

Wenn Unterschiede im Ausgangsverhal-ten vorliegen, wird der Eingangsvektor als Testfall verwendet. Das erwartete Ausgangs-verhalten des Originals wird für das Test-

Toolentwickler

Industrielle Partner

Universitäten und Forschungsinstitute

❶ Übersicht über die Projektpartner

❷ Das Anforderungsmodell der Diebstahlwarnanlage in UML

Entwicklung TESTEN

64

orakel (Entscheidung, ob der Testfall be -standen ist oder nicht) benutzt. Mit Hilfe des Testorakels wiederum können die ent-sprechenden Anforderungen verifiziert werden. Eingangsvektor und der erwar-tete Ausgangsvektor liegen im XML-For-mat vor („Extensible Markup Language“).

Ist die Testfallgenerierung abgeschlos-sen, stehen weitere automatisierte Statisti-ken wie der Abdeckungsgrad zur Verfü-gung. Die Methode kann gezielt redun-dante Testfälle vermeiden, um effiziente Testsequenzen zu erhalten.

diE diEbstAhl-AlArmAnlAgE Als dEmonstrAtor

Anhand von Demonstratoren wurde gezeigt, dass die bei Mogentes entwickel-ten Methoden in der industriellen Praxis zu schnelleren und verbesserten Ergebnis-sen bei der Testfallgenerierung führen können. Von Ford wurden für das Projekt zwei Anwendungen zur Verfügung gestellt. Ein intern entwickelter Algorithmus einer Regelfunktion für die aktive Vorderradlen-kung dient der Untersuchung des „White Box“-Ansatzes. Die Funktion „Diebstahl-Alarmanlage“ konzentriert sich dagegen auf den Pfad der Generierung von Test-fällen mit dem „Black Box“-Ansatz.

Als Ausgangspunkt wird eine Alarm-anlage aus der laufenden Produktion ver-wendet. Auf Basis dieser wurde den Part-nern eine vereinfachte, intern entwickelte Software der Alarmanlage zur Verfügung gestellt.

Für das Anforderungsmodell wurden drei Bedingungen an die Alarmanlage gestellt [1]: : Die Alarmanlage wird beim Verriegeln

des Fahrzeugs nach 20 Sekunden eingeschaltet.

: Bei einem unberechtigten Versuch, das Fahrzeug zu öffnen, ertönt 30 Sekunden lang ein Alarm. Zusätzlich wird für die Dauer von fünf Minuten ein optischer Alarm über die Warnblinkanlage gegeben.

: Die Diebstahlwarnanlage kann – auch im Alarmfall – durch Entriegeln des Fahrzeugs von außen jederzeit deakti-viert werden.

Diese drei Anforderungen ergeben in ein UML-Modell umgesetzt ein Zustandsdia-gramm ❸. Dies erfordert einen gewissen manuellen Aufwand; dieser ist aber grund-

Besuchen Sie uns Besuchen Sie uns Besuchen Sie uns in Halle 1, Stand 616in Halle 1, Stand 616in Halle 1, Stand 616in Halle 1, Stand 616in Halle 1, Stand 616in Halle 1, Stand 616

PCAN-Explorer 5

Universeller CAN-Monitor, Tracer, symbolische Nachrichten-darstellung, VBScript-Schnitt-stelle, erweiterbar durch Add-ins (z. B. CANdb Import Add-in).

ab 450 €

PCAN-USB Pro

High-Speed-USB 2.0-Interface mit galvanischer Trennung für die Anbindung von bis zu 2 CAN- und 2 LIN-Bussen.

490 €

PCAN-USB ProPCAN-USB Pro

CAN-BusDiagnose

PCAN-Diag 2

Handheld-Diagnosegerät für den CAN-Bus, 2-Kanal-Oszilloskop, Übertragungsraten-, Buslast- und Terminierungsmessung, interner Speicher mit USB-Anbindung, symbolische Nachrichtendarstellung.

765 €

PCAN-Diag 2

Handheld-Diagnosegerät für den

CAN-BusDiagnose

PCAN-Diag 2

You CAN get it...Hardware und Software für CAN-Bus-Anwendungen…

All

e P

reis

e ve

rste

hen

sic

h z

zgl.

Mw

St.

, Po

rto

un

d V

erp

acku

ng

. Irr

tüm

er u

nd

tec

hn

isch

e Ä

nd

eru

ng

en v

orb

ehal

ten

.

Otto-Röhm-Str. 6964293 Darmstadt/Germany

Tel.: +49 6151 8173-20Fax: +49 6151 8173-29

info@peak-system.com01I2012 7. Jahrgang

sätzlich für Dokumentation, Auffinden logischer Fehler und Koordination mit dem Zulieferer nötig. Dafür entfällt das

spätere Ermitteln der Testfälle per Hand. Ergebnis sind die Testfälle im XML-For-mat. Sie enthalten nicht nur die nötigen

Eingangsvektoren, sondern beschreiben auch das erwartete Ausgangsverhalten sowie definieren die Zeit beziehungs-weise die erlaubte Zeitspanne zwischen Ereignissen. Diese werden durch Pro-gramme automatisch in Testvektoren umgewandelt, die sowohl die Zeitinfor-mation als auch die Signalinformation enthalten. Zeitintervalle werden durch geeignete Zeitwerte ersetzt, ③. Da die erwarteten Ausgangssignale nicht exakt zeitgleich mit den am System gemesse-nen Ausgängen übereinstimmen können, werden gewisse Toleranzen zugelassen, ❹. Ist man an dieser Stelle angelangt, erfolgt der Übergang zu der am HiL ver-wendeten Testautomatisierungs-Software.

ZusAmmEnfAssung und Ausblick

Das Erstellen von Testfällen per Hand ist mit hohem Aufwand verbunden und bei komplexen Systemen auch fehleranfällig. Daher besteht seitens der Industrie ein großes Interesse, diesen Prozess zu auto-matisieren beziehungsweise dem Ingeni-

❸ Beispiel eines gefundenen Testfalls

0,00 s Eingabe Alarmsensor aus

0,01 s Eingabe Verriegle das Fahrzeug

20,01 s Warte 20 s

20,01 s Ausgabe Alarm scharfgestellt

37,01 s Warte 17 s (Intervall 0 bis unendlich)

37,01 s Eingabe Alarmsensor an

37,02 s Eingabe Alarmsensor aus

37,03 s Ausgabe optisches Alarmsignal an

37,03 s Ausgabe Akustisches Alarmsignal an

67,03 s Warte 30 s

67,03 s Ausgabe Akustisches Alarmsignal aus

130,03 s Warte 63 s (Intervall 0 bis 270 s)

130,03 s Eingabe Entriegle das Fahrzeug

130,04 s Ausgabe Alarm nicht scharfgestellt

130,04 s Ausgabe optisches Alarmsignal aus

145,04 s Warte 17 s (Intervall 0 bis unendlich)

JETZT ONLINE-LESEPROBE STARTEN: www.ATZonline.de/leseprobe/atzeJETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN: JETZT ONLINE-LESEPROBE STARTEN:

Entwicklung TESTEND

OI:

10.1

365/

s356

58-0

12-0

122-

1

0 120

Ausgabe:OptischesAlarmsignal

Ausgabe:AkustischesAlarmsignal

Ausgabe:Alarm scharf

Eingabe:Alarmsensor

Eingabe:Fahrzeugverriegelt

Zeit [s]

Alarm löst aus

Entriegle das Fahrzeug

Erlaubte Toleranz

Alarm stoppt

14080 10040 6020

❹ Der Testfall in zeitlicher Abhängigkeit

rEAd thE English E-mAgAZinE order your test issue now: SAM-service@springer.com

downloAd dEs bEitrAgs www.ATZonline.de

eur Werkzeuge zur Hand zu geben, die seine Arbeit erleichtern und Fehler zu ver-meiden helfen. Im Rahmen des EU-Pro-jekts Mogentes wurde eine Reihe von Werkzeugen entwickelt, die nach Erstel-len eines UML-Anforderungsmodells auto-matisch Testfälle für die gestellten Anfor-derungen generieren. Anhand der Funktio-nalität „Diebstahl-Alarmanlage“ wurden am Ford Entwicklungszentrum in Köln die Möglichkeiten dieser Ansätze untersucht und auf ihre Einsetzbarkeit hin bewertet.

Als Ausblick sollen in weiteren Stufen auch UML-Aktivitätsdiagramme zum Ein-satz kommen, da der Entwurf von Zu -standsdiagrammen bei komplexen Syste-men sehr schnell an seine Grenzen stößt [4]. Ebenso soll in Nachfolgeprojekten die Fehlereinspeisung in Systeme zunehmend in den Vordergrund der Untersuchungen rücken.

litErAturhinwEisE[1] Bedienungsanleitung des Ford Focus (Teilenummer: 9M5J-19A321-AHA (CG3505de) 12/2008 20090126120215)[2] Herzner, W.; Schlick, R.; Brandl, H.; Wiessalla, J.: Towards Fault-based Generation of Test Cases for Dependable Embedded Software. 4. Workshop Entwicklung zuverlässiger Software-Systeme, Bosch Zentrum Feuerbach, Stuttgart, 2011[3] Hofmann, o.; Wiessalla, J.; u. a.: Model Based Generation of Test Cases for Safe and Reliable Vehicle Software in the Framework of Mogentes. Proceedings of the 10th International Symposium on Advanced Vehicle Control (AVEC), Lough-borough, UK, 2010[4] Schlecht, S.; Alt, o.: Strategien zur Testfall-generierung aus SysML Modellen. In: Bleek, W.; Schwentner, H.; Züllighoven, H. (Hg.): Software Engineering 2007 – Beiträge zu den Workshops, Bonn: Gesellschaft für Informatik, 3 2007; GI-Edi-tion Lecture Notes in Informatics, Vol. 106, Gesell-schaft für Informatik, S. 101-106, 2006[5] Svenningsson, R.; Vinter, J.; u. a.: MoDIFI: A MoDel-Implemented Fault Injection Tool. 29th International Conference on Computer Safety, Reliability and Security (SAFECoMP 2010), Vienna, Austria, 2010

ITK Engineering AG

Tel.: 0 72 76 | 98 85-600Fax: 0 72 76 | 98 85-619info@itk-engineering.de

München | Stuttgart | Karlsruhe | Marburg | Braunschweig | Tokyo | Detroit |

ww

w.itk

-engin

eeri

ng.d

e

Michael EnglertGründer und VorstandITK Engineering AG

Profi tieren auch Sie von unserem Expertenwissen und unserer langjährigen Erfahrung.“

„Als Entwicklungspartner unter-stützen wir Sie im Bereich Software-Engineering durchgängig vom Pfl ichtenheft über das Design und die Implementierung bis hin zur Validierung und Verifi kation.

ITK Engineering AG Ganzheitliches Denken und Handeln für Ihren Erfolg.

Weil Professionalität Vertrauen schafft.

In der Implementierungsphase programmieren wir klassisch oder wenden objektorientierte bzw. modellbasierte Methoden ggf. mit automatischer Code-generierung an. Verschiedenste Entwicklungswerkzeuge, Echt-zeitbetriebssysteme und Ziel-plattformen kommen dabei zum Einsatz.

An dieser Stelle möchten Ford und die Auto-

ren den Projektpartnern für die hervorragen-

de Zusammenarbeit danken. Diese war mit

wertvollen Ideen und Anregungen verbun-

den, die auch an den HiL-Prüfständen am

Ford Entwicklungszentrum in Köln zu wichti-

gen Verbesserungen führte.

danke

01I2012 7. Jahrgang