Automatisierte Testplanerstellung für Betriebsstrategien von Hybridfahrzeugen

Diplomarbeit von Robert Poser

Einleitung:

Mit der Debatte um die Auswirkungen steigender CO2-Emissionen auf das Klima sowie mit dem prognostizierten Anstieg des Welt-Fahrzeugbestandes wächst der Bedarf an effizienten und emmissionsarmen Antriebskonzepten. Ein möglicher Ansatz besteht in der Ergänzung des konventionellen Verbrennungsmotors (VM) um eine Elektromaschine (EM) sowie einen Energiespeicher. Dieses als Hybridantrieb bezeichnete Konzept erfreut sich seit der Einführung des Toyota Prius im Jahre 1997 stetig wachsender Beliebtheit: Während die Zulassungszahlen in Deutschland noch gering sind, kletterte der Verkauf von Hybridautos in den USA im zweiten Quartal 2007 um 48 Prozent gegenüber dem Vergleichszeitraum des Vorjahres.

Bis zum Jahr 2015 wird für Hybridfahrzeuge ein Anteil von 18 Prozent unter den neu zugelassenen Fahrzeugen prognostiziert. Die Kombination zweier Antriebsquellen hat eine Reihe neuer Freiheitsgrade zur Folge, deren Koordination den Fahrer nicht zusätzlich belasten sollte. Dieses Betriebsmanagement umfasst dabei grundlegende Funktionen wie die Leistungsverteilung von VM und EM, die Ladezustandsregelung oder die Getriebeübersetzung. Die Anforderungen an das Management können von der Verringerung des Primärenergieverbrauchs bis hin zu der Darstellung sportlichen Fahrverhaltens reichen. Die Spezifikation zur Umsetzung dieser Zielstellungen wird als Betriebsstrategie bezeichnet.

Allgemein ist mit der Zunahme von neuen, softwaregesteuerten Systemen jedoch eine wachsende Komplexität des Gesamtsystems verbunden. Insbesondere wettbewerbsrelevante Innovationen basieren immer mehr auf dem Einsatz von Software. Gleichzeitig führt der hohe Innovationsdruck im Automobilsektor zu immer kürzeren Entwicklungszeiten und steigendem Kostendruck. Damit erhöht sich das Risiko des Auftretens von Fehlfunktionen.

Dem Testvorgang als Form der Qualitätskontrolle kommt damit eine wachsende Bedeutung zu. Ziel des Testens ist es, die Funktionsfähigkeit der spezifizierten Eigenschaften nachzuweisen, Abweichungen aufzuspüren und mit möglichst vielen erfolgreichen Tests das Vertrauen in das Prüfobjekt zu erhöhen. Eine zentrale Rolle kommt dabei der Definition von Testfällen zu. Diese erfolgt in der Regel auf der Grundlage von Spezifikationsdokumenten (z. B. dem Lastenheft) oder durch Gespräche mit den Entwicklern, welche dem Testingenieur eine möglichst realistische Vorstellung des Systemverhaltens geben. Nachteilig dabei ist, dass dieser Prozess in der Regel unsystematisch, nicht reproduzierbar und in seiner Qualität stark von den Erfahrungen des Testers abhängig ist.

Ansatz des modellbasierten Testens ist es, das Sollverhalten in ausführbaren Modellen zu spezifizieren. Aus dem Aufbau dieser Verhaltensmodelle können Testfälle abgeleitet werden. Die Stärke dieses Ansatzes besteht in der systematischen und automatisierbaren Vorgehensweise.

Schätzungen gehen davon aus, dass bis zu 90% der zukünftigen Investitionskosten in den Bereich der Softwareentwicklung fallen werden. Für die Modellierung solcher Verhaltensmodelle existiert unter anderem das Entwurfswerkzeug Stateflow, welches Bestandteil der Entwicklungsumgebung Matlab/Simulink ist. Dieses Programm erlaubt die Abbildung von reaktiven, zustandsbasierten Systemen in Form von Statecharts.

Gang der Untersuchung:

Im Rahmen der vorliegenden Arbeit soll untersucht werden, inwieweit Statechart-Automaten zur automatisierten Testfallererstellung verwendet werden können. Dazu wurde das Verfahren des zustandsbezogenen Tests auf die Notation der Statecharts angewendet. Anhand eines Transitionsbaum und unter Maßgabe von Überdeckungskriterien sollen Zustandsfolgen für die Testplanung bestimmt werden.

Es wurde ein Testtool implementiert, welches ein Stateflow-Modell einlesen und in einen Transitionsbaum umwandeln kann. Unter Berücksichtigung von einigen Randbedingungen kann ein Testplan für das Überdeckungskriterium der Round-trip Pfade bestimmt werden.

Der Inhalt der vorliegenden Arbeit gliedert sich wie folgt:

Kapitel 2 führt zunächst in die Thematik der Hybridfahrzeuge ein. Es werden Unterschiede zu konventionellen Kraftfahrzeugen aufgezeigt und damit verbundene Vorteile genannt. Aufbauend auf einem Überblick möglicher Fahrzustände wird der Begriff der Betriebsstrategie eingeführt.

Kapitel 3 stellt das Entwurfswerkeug Stateflow vor und gibt einen Überblick über dessen Notation. Das Betriebsmanagement von Hybridfahrzeugen wird als ein reaktives System klassifiziert, dessen Modellierung in Form von endlichen Automaten möglich ist.

Kapitel 4 führt das Testen als eine mögliche Methode ein, um die Funktionsweise von Betriebsstrategien zu prüfen. Da sich viele Definitionen von den Softwaretests ableiten, folgt ein Überblick über Software-Testverfahren mit Schwerpunkt auf den Abdeckungstests sowie dem zustandsbasierten Test. Das Kapitel schließt mit einem Überblick des allgemeinen V-Modells.

Kapitel 5 beschreibt eine Vorgehensweise, um aus Statecharts Zustandsabfolgen für die Generierung eines Testplans zu gewinnen. Dazu wird das Verfahren des zustandsbezogenen Tests auf die Notation der Statecharts ausgedehnt. Anhand eines Transitionsbaums und unter Maßgabe von Überdeckungsstrategien können Zustandsfolgen für die Testplanung bestimmt werden. Es lassen sich konkrete Ein- und Ausgangswerte berechnen, indem die Zustandsfolgen schrittweise durchlaufen werden. Dazu werden Regeln der Automatenausführung in Stateflow vorgestellt.

Kapitel 6 stellt ein prototypisches Testtool vor, welches im Rahmen der Arbeit implementiert wurde und auf den Überlegungen des vorhergehenden Kapitels beruht. Es wertet MDL-Dateien aus und ermittelt unter Einhaltung bestimmter Vorrausetzungen Testfälle für das Überdeckungskriterium der Round-trip Pfade.

Kapitel 7 bewertet das Testtool anhand eines in Anlehnung an erstellten Zustandsautomaten einer Betriebsstrategie. Die berechneten Ausgangswerte werden mit den Ausgaben in Simulink verglichen.

Inhaltsverzeichnis:

1.	Einleitung	1
2.	Grundlagen zu Betriebsstrategien	5
2.1	Motivation für Hybridfahrzeuge	5
2.2	Fahrzustände und mögliche Betriebsmodi	8
2.3	Koordinierung der Betriebsmodi	11
3.	Modellierung mit Stateflow	13
3.1	Reaktive Systeme	13
3.2	Endliche Automaten	14
3.3	Statecharts: Erweiterte Notation für endliche Automaten	16
3.4	Stateflow	18
3.4.1	Notation von Zuständen	19
3.4.2	Notation von Transitionen	20
3.4.3	Weitere Objekte	20
4.	Testen als Methode der Systemvalidierung	22
4.1	Einordnung des Testbegriffs	22
4.2	Überblick testender Verfahren	25
4.2.1	Statische Testverfahren	25
4.2.2	Dynamische Testverfahren	26
4.3	Testen im Entwicklungszyklus	31
4.4	Zusammenfassung: Testen von Statecharts	33
5.	Entwurf einer Vorgehensweise zur Testfallerstellung aus Statecharts	34
5.1	Überblick	34
5.2	Generierung eines Zustandsbaums	37
5.3	Generierung eines Transitionsbaums	39
5.4	Formulierung einer Teststrategie	41
5.5	Testdatengenerierung mit Stateflow	45
5.5.1	Lösen boolscher Entscheidungsausdrücke	46
5.5.2	Zustandswechsel	47
5.6	Zusammenfassung	52
6.	Implementierung eines prototypischen Testtools	53
6.1	Überblick	53
6.2	Grafische Nutzeroberfläche	55
6.3	Die Klasse Cstateflow	56
6.4	Aufbau von Simulink-Modelldateien	58
6.5	Ausgewählte Funktionen	64
6.6	Ausgabe des Testplans	68
7.	Ergebnisse und Bewertung	70
8.	Zusammenfassung und Ausblick	74
A.	Anhang	76
A.1	Ergänzende Packages	76
A.2	Quellcode ausgewählter Methoden	78
A.3	Format der Ausgabedatei	80
A.4	Stateflow-Modell einer Betriebsstrategie	81
A.5	Ermittelte Round-trip Pfade	82
	Literaturverzeichnis	83

Textprobe:

Kapitel 5., Entwurf einer Vorgehensweise zur Testfallerstellung aus Statecharts:

Dieses Kapitel beschreibt eine Vorgehensweise, um aus Statecharts Zustandsabfolgen für die Generierung eines Testplans zu gewinnen. Dazu wird das Verfahren des zustandsbezogenen Tests auf die Notation der Statecharts ausgedehnt. Anhand eines Transitionsbaums und unter Maßgabe von Übderdeckungsstrategien können Zustandsfolgen für die Testplanung bestimmt werden. Es lassen sich konkrete Ein- und Ausgangswerte berechnen, indem die Zustandsfolgen schrittweise durchlaufen werden. Dazu werden Regeln der Automatenausführung in Stateflow vorgestellt.

Der Vorgang der automatisierten Erstellung von Ein- und erwarteten Ausgangssequenzen auf der Basis von Statechart-Automaten gliedert sich in zwei Teilabschnitte. Die Aufgabe besteht zunächst darin, Zustandabsfolgen für die Testfallgenerierung zu bestimmen. Dazu ist es notwendig, alle relevanten Objekte, die den Aufbau des Statecharts definieren (Zustände, Zustandsübergange, Verbindungselemente) aus der zugehörigen MDL-Datei zu lesen. Die Hierarchie der Zustände wird in einen Zustandsbaum überführt. Mit dem Ziel, den Automaten abzuflachen1, d.h. seine Hierarchie abzubauen, werden alle abgehenden Transitionen auf die Ebene der Substates verlängert, die im Zustandsbaum als Blattknoten dargestellt sind.

Nach diesem Vorgang kann der Automat in einen Transitionsbaum umgewandelt werden, welcher Grundlage für die weitere Berechnung ist. Jeder der möglichen Wege in dem Baum einen Testfall repräsentierend, besteht die Herausforderung darin, aus der Menge an möglichen Pfaden eine Strategie zu bestimmen, welche eine Auswahl geeigneter Wege für einen Test zum Ziel hat. Neben der zufälligen Wahl von Pfaden kommen hierfür Überdeckungskriterien in Frage. Im Ergebnis erhält man eine Menge von Zustandsabfolgen und zusammen mit ihnen die Bedingungen, welche notwendig sind, um diese auszuführen.

Die zweite Teilaufgabe besteht darin die Pfade zu durchlaufen und dabei passende Eingabewerte für jedes Segment zu finden. Unter der Vorraussetzung die jeweiligen Pfadbedingungen zu erfüllen, muss der Automat analog der Ausführung in Stateflow schrittweise ausgeführt werden. Die Ein- und Ausgangswerte für jeden Schritt werden aufgezeichnet und können danach als Testplan ausgegeben werden. Es wird nicht immer möglich sein alle zunächst ermittelten Pfade auszuführen. Testfälle, die davon betroffen sind, finden keinen Eingang in den Testplan.

Als Beispiel ist ein Modell möglicher Fahrzustände als Zustandsautomat in Abb. 5.1 dargestellt. Es besteht aus den drei Zuständen kein_Antrieb, Vortrieb und Bremsen. Der Eingang Psoll beschreibt die Leistungsanforderung des Fahrers. Der Automatenausgang Modus gibt den aktuellen Fahrzustand aus. Nach dem Start befindet sich der Automat zunächst in dem Modus 1 (kein_Antrieb). Der weitere Verlauf, und damit der Wert des Ausgangs Modus, wird lediglich durch die Größe der Leistungsanforderung bestimmt. Die Tab. 5.1 zeigt einen möglichen Testplan des Automaten, hier zunächst ohne zeitliche Angaben. Er enthält für jeden Testfall, sowie für jeden Ausführungsschritt einen Wert des Eingangs, sowie die jeweils erwartete Antwort auf diese Stimulation. Die notwendigen Schritte um einen Testplan dieser Art zu erhalten, sollen in den folgenden Abschnitten erläutert werden.