Entwicklung eines Konzeptes zur modellbasierten Verifikation von Fahrzeugcodierdaten

Diplomarbeit von Karl Müller

Einleitung:

Ohne die Elektrik/Elektronik wäre eine Vielzahl der heutigen Funktionen im Fahrzeug nicht zu realisieren. Die sich aus den Innovationen in diesem Bereich ergebenden Vorteile für die Kunden liegen klar auf der Hand. Die Fahrzeugfunktionen können sowohl direkt durch den Kunden erlebbar sein (z.B. Komfortfunktionen wie ‘Klimaautomatik’), als auch in sicherheitskritischen Situationen zum Einsatz kommen (z.B. Sicherheitsfunktionen wie ‘ESP’).

Für die Hersteller sind Innovationen im E/E-Bereich zu einem kritischen Erfolgsfaktor geworden und tragen zu den charakteristischen Merkmalen ihrer Fahrzeuge bei. Es wird versucht, sich von anderen Herstellern auf dem hart umkämpften Automobilmarkt abzusetzen. Infolge der Globalisierung stellt dies einen notwendigen Schritt dar.

Aus dieser Entwicklung ergibt sich eine nicht zu unterschätzende Komplexitätssteigerung in der Technik, bei den Informationen und Daten.

Die Komplexität und Vielfalt moderner Kraftfahrzeuge nimmt stetig zu. Differenzierte Bedarfe der Kunden sowie in Unternehmen historisch gewachsene Produktphilosophien führen zu immer differenzierteren Produktstrukturen, woraus sich verschiedene Produktvarianten ergeben.

Der berühmte Ausspruch Henry Fords: ‘Give the customers any color they want, so long it is black!’ besitzt heute keine Gültigkeit mehr. Fords Ausspruch zeigt jedoch sehr deutlich, dass man sich bereits zu jener Zeit Gedanken zur Variantenvielfalt gemacht hat.

Durch den sich in den letzten Jahren vollzogenen Wandel vom Anbieter- zum Käufermarkt besteht die Notwendigkeit zum individuellen Produkt bzw. zur individuellen Problemlösung.

Heute soll der Sättigung der traditionellen Märkte durch Nischenmodelle entgegnet werden, um neue Käuferschichten und Marktsegmente zu erschließen. Der Trend weist daher weg vom Standardmodell mit optionaler Sonderausstattung hin zum Individual-Fahrzeug, das den Bedürfnissen der Kunden besser gerecht wird.

Die große Herausforderung dabei ist die hohe Varianz der Fahrzeugfunktionen, die als Ausstattungsvarianten auftreten. Diese Ausstattungsvielfalt gehört zwar zur Philosophie und zur Markenidentität der deutschen Automobilhersteller, führt aber ebenso zu einer gewaltigen Komplexität.

In Deutschland hat sich die Zahl der PKW-Modelle in den letzten 20 Jahren von 140 auf 260 fast verdoppelt; die Zahl der Varianten nahm dabei um 80% zu. Speziell bei BMW hat sich die Anzahl der angebotenen Fahrzeugvarianten zwischen 1980 und 1990 um ca. 460% erhöht, mit weiterhin steigender Tendenz.

International tätige Unternehmen, wie die Automobilhersteller, werden darüber hinaus von länderspezifischen Normen, Richtlinien, Vorschriften und Standards beeinflusst und müssen sprachliche und kulturelle Unterschiede beachten, wodurch sich die Variantenvielfalt weiter erhöht. Ein Beispiel hierfür ist das ‘Tagfahrlicht’, das in den skandinavischen Ländern gesetzlich vorgeschrieben ist, in anderen Ländern jedoch nur als Option angeboten wird.

Sämtliche Fahrzeugfunktionen müssen durch ein Regelwerk so adaptiert bzw. konfiguriert werden, dass sie die Eigenschaften der verschiedenen Ausstattungen in allen Modellen korrekt wiedergeben und die Gesetzgebungen der belieferten Länder erfüllen.

Bei dieser Konfiguration, die bei DaimlerChrysler als ‘Codierung’ bezeichnet wird, ist eine hohe Fehlerrate festzustellen. Diese Fehlerrate liegt in der Komplexität und dem Informationsvolumen begründet. Die Kombinatorik der für die Funktionsrealisierung benötigten Konfigurations- bzw. Codierdaten kann enorme Umfänge annehmen. Dies führt zwangsläufig dazu, dass die Überschaubarkeit für den Entwickler des Regelwerks leidet und Fehler entstehen.

Ein weiteres Problem ergibt sich aus der Tatsache, dass mehrere Entwickler an den Konfigurationen verschiedener Steuergeräte mitwirken. Ist die Kommunikation zwischen den Entwicklern nicht ausreichend, werden die für die Fahrzeugfunktionen notwendigen Zusammenhänge nicht erkannt oder vernachlässigt.

Simulationen der Funktionen, bei denen die verschiedenen Einstellungen mittels Konfiguration realisiert werden, gibt es nicht. Stattdessen muss diese Konfiguration direkt am Fahrzeug getestet bzw. auf Richtigkeit überprüft werden.

Dieser Zustand zeigt sehr deutlich, zu welch spätem Zeitpunkt im Entwicklungsprozess eine Überprüfung durchführbar ist. Ein Versuchsträger mit seriennaher Technik steht erst in der Nullserie bereit, also wenige Monate vor dem Produktionsanlauf. Bei auftretenden Fehlern bleibt folglich wenig Zeit, die genauen Quellen zu lokalisieren und zu korrigieren. Die Gesamtqualität der Fahrzeuge ist dadurch natürlich ebenfalls betroffen.

Die 10er Regel, bei der die Änderungskosten in den verschiedenen Produktphasen um den ‘Faktor 10’ von Phase zu Phase zunehmen, gilt auch in diesem Fall. Es müssen zwar bei zu ändernden Informationsständen nicht komplette Maschinenparks umgestellt oder angepasst werden; kostspielige Softwareänderungen oder aufwändige Anpassungen von Datenständen können jedoch ebenfalls große Ausmaße annehmen und einen langwierigen Korrekturprozess in Gang setzen. Wird der Fehler nicht erkannt, so können Rückrufaktionen, Nacharbeiten und der entstandene Imageschaden noch weitaus höhere Kosten verursachen.

Sind aufgrund der Komplexität oder der mangelnden Kommunikation zwischen den Entwicklern entstandene Fehler in der Codierung vorhanden (z.B. fehlerhafte Steuerungselemente), gibt der Produktionstester am Bandende eine entsprechende Fehlermeldung aus. Erkennt der Tester die fehlerhafte Codierung jedoch nicht (z.B. Fehler basierend auf der Logik des Regelwerks), wird der Datensatz bzw. Codierstring ohne Fehlermeldung ins Steuergerät geschrieben. Geschieht dies, ist die von der fehlerhaften Codierung betroffene Funktion entweder teilweise oder vollständig beeinträchtigt. Eine Funktion entspricht nur dann den Wünschen des Kunden, wenn alle Funktionsumfänge vollständig vorhanden und aktiv sind. Komplexe Fahrzeugfunktionen werden heute über mehrere Steuergeräte realisiert und sind somit auch auf diese verteilt. Man spricht hier von einem verteilten System. Je mehr Steuergeräte bei der Realisierung einer Funktion mitwirken, desto vielfältiger sind die Ausfallerscheinungen.

Mögliche Konsequenzen einer Falschcodierung können z.B. sein, dass Funktionen nicht aktiviert oder nicht korrekt an die gesetzlichen Vorgaben angepasst werden. Fehler treten auch dann auf, wenn die Konfigurationen mehrerer Steuergeräte nicht aufeinander abgestimmt sind. Selbst wenn eine Funktion an einer Stelle aktiviert wurde, kann die Umsetzung durch eine Konfiguration an einer anderen Stelle blockiert werden.

Bei DaimlerChrysler werden zur Aufdeckung fehlerhafter Codierdaten nur beim Kombiinstrument einzelne Funktionen ausgewählt, die manuell oder mit Hilfe einfacher Simulationen getestet werden. Der Abdeckungsgrad bei der heutigen Funktionsvielfalt ist dementsprechend gering.

Dies ist aber ein Einzelfall. Andere Steuergeräte und die Realisierung der Funktionen im Verbund mit teilhabenden Steuergeräten können auf die Korrektheit ihrer Codierung erst in der Nullserie am Fahrzeug getestet werden.

Ein viel versprechender Ansatz, diesen Zustand dennoch erheblich zu verbessern, ist die Simulation der Codierung in einer für diese Problematik entwickelten Simulationsumgebung. Dem Entwickler würde es dadurch ermöglicht, das Regelwerk in einem früheren Stadium des Entwicklungsprozesses ausreichend zu testen. Der Entwickler würde bei der Variantencodierung wirkungsvoll unterstützt.

Eine geeignete Lösungsmöglichkeit stellt die Methode der modellbasierten Entwicklung dar. Diese Methode wird seit einiger Zeit sowohl bei Herstellern, als auch bei Zulieferern der Automobilindustrie eingesetzt, um mit der steigenden Komplexität und den immer kürzer werdenden Entwicklungszyklen Schritt zu halten. Grundsätzlich wird ein Modell neben der Visualisierung zur Verdeutlichung eines Systems eingesetzt. Auf Basis eines solchen Modells, das die Codierung in Abhängigkeit der Funktionen abbildet, könnten durch Tests in einem frühen Entwicklungsstadium die fehlerhaften Konfigurationen festgestellt werden.

Mit diesem Verfahren ist es auch denkbar, die Codierung aus einem konfigurierten Fahrzeug auszulesen und in das Modell einzuspeisen. Danach können dieselben Tests durchgeführt werden.

Die Aufgabe dieser Arbeit besteht darin, ein Konzept zur modellbasierten, rechnergestützten Funktionsüberprüfung von Fahrzeugcodierdaten zu entwickeln.

Es sollen mögliche Ansätze zur Problemlösung diskutiert und der gewählte Ansatz anhand von einigen Beispielen dargestellt werden. Im Verlauf dieser Arbeit sind heutige Vorgehensweisen in diesem Umfeld zu betrachten und auf den gewählten Ansatz zu übertragen.

Darüber hinaus sollen die aus dem erarbeiteten Ansatz resultierenden Möglichkeiten zur Überprüfung bzw. Verifikation des Regelwerks untersucht werden.

Zielsetzung ist eine Ausarbeitung, die eine Empfehlung zur möglichen Weiterverfolgung dieser Thematik ausspricht.

Inhaltsverzeichnis:

	Inhaltsverzeichnis	I
	Abbildungsverzeichnis	II
	Abkürzungsverzeichnis	III
	Vorwort	1
1.	Einleitung	3
1.1	Problemstellung	4
1.1.1	Fehlerquellen und Auswirkungen	7
1.1.2	Abhilfemaßnahmen	8
1.2	Aufgabenstellung und Zielsetzung	9
1.3	Gliederung der Arbeit	9
2.	Mögliche Modellierungsansätze	10
2.1	MATLAB/SIMULINK	10
2.2	Modellierung mit der Modellierungssprache UML	11
2.3	Ansatz der Merkmalmodellierung	13
2.3.1	Merkmalmodellierung mit der UML	13
2.3.2	Merkmalmodellierung mit der Notation FODA	14
2.4	Fazit	15
3.	Hintergründe	16
3.1	Begriffsbestimmung	16
3.1.1	Codierdaten	16
3.1.2	Konzept	16
3.1.3	Modell	16
3.1.4	Konfiguration	17
3.1.5	Verifikation	17
3.1.6	Simulation	18
3.1.7	Merkmal	18
3.1.8	Domäne	18
3.2	Umgebungssituation	19
3.2.1	Software Calibration Number	19
3.2.2	SCN-Variantencodierung bei DaimlerChrysler	19
3.3	Umsetzung der Variantenvielfalt	21
3.3.1	Methoden zur Realisierungen der Variantenvielfalt	21
3.3.2	Strukturierung der Konfigurationsdaten	22
3.4	Modellbasierte Entwicklung	26
3.4.1	Modellierung	26
3.4.2	Feature-Oriented Domain Analysis	27
3.4.3	Merkmalmodell	28
3.5	Entwicklungsumgebung	31
3.5.1	Eclipse	31
3.5.2	pure::variants	32
4.	Modellrealisierung	34
4.1	Strategie zur Merkmalidentifizierung	34
4.2	Fahrzeugfunktionen	36
4.2.1	Adaptives Bremslicht	36
4.2.2	Fahrdynamischer Sitz bzw. Multikontursitz	37
4.3	Modellierung der Funktionen	38
4.3.1	Modellierung der Funktion ‘adaptives Bremslicht’	38
4.3.2	Modellierung der Funktion ‘Multikontursitz’	43
4.4	Vermeidung von Redundanz	45
4.5	Variationspunkte im Modell	48
4.6	Bemerkungen zur Modellierung und Wartung	50
4.6.1	Identifikationsbenennung	51
4.6.2	Modellierung mit der Notation FODA	53
4.7	Fazit	54
5.	Verifikation der Codierlogik	55
5.1	Konfiguration des Modells	56
5.2	Verifikationsmethoden	58
5.2.1	Sichtprüfung	58
5.2.2	Funktionsmodell als Simulation	60
5.2.3	Prüfung auf Einhaltung der Kompositionsregeln	62
5.2.4	Fazit	66
5.3	Kompositionsregeln	67
5.4	Einschränkung der Ausstattungsvarianten	72
5.5	Testprotokollierung	74
5.6	Voraussetzungen für die modellbasierte Verifikation	74
5.6.1	Benennung der Merkmale	74
5.6.2	Codierungslastenheft	77
5.7	Vorhandene Quellen	78
5.8	Fazit	79
6.	Zusammenfassung	80
7.	Ausblick	82
8.	Literaturverzeichnis	83
	Danksagung	IV
	Sperrvermerk	V
	Anhang	VII

Textprobe:

Kapitel 4, Modellrealisierung:

Die Entwickler überprüfen ihre Codierlogiken derzeit an Erprobungsträgern in der Nullserienphase anhand von funktionalen Tests.

Ist eine Funktion vorhanden bzw. wird eine Funktion korrekt umgesetzt, so war auch die Codierung korrekt. Tritt die Funktion jedoch nicht wie gewünscht ein, wird durch Erfahrungswerte des Entwicklers von der Funktion zurück auf die fehlerhafte Codierung geschlossen.

Durch eine modellbasierte Verifikation soll diese Überprüfung ohne ein reelles Fahrzeug und infolgedessen in einer früheren Phase der Entwicklung möglich sein. Dazu wird die Variantencodierung in Abhängigkeit von Funktionen modelliert und die einzelnen Elemente durch das Merkmalmodell zueinander in Beziehung gesetzt.

Zur Darstellung des Merkmalmodells wurden Funktionen eines heutigen Fahrzeuges gewählt, die beispielhaft modelliert und in einer geeigneten Entwicklungsumgebung abgebildet werden.

Beginnend mit einer Strategie zur Identifizierung der Merkmale wird der Modellierungsprozess angestoßen.

4.1, Strategie zur Merkmalidentifizierung:

Zur Modellierung von Fahrzeugfunktionen durch das Merkmalmodell sind die Identifizierung der Merkmale sowie die Klärung gegenseitiger Abhängigkeiten erforderlich. Eine mögliche Methode hierfür liefert.

Er schlägt die Betrachtung des Systems aus verschiedenen Blickwinkeln vor, die Suche nach Merkmalen in allen Entwicklungsphasen sowie die vorausschauende Identifizierung.

Ein möglicher Ablauf der Merkmalmodellierung wird von ihm wie folgt beschrieben:

1. Gemeinsamkeiten und Unterschiede der Merkmale notieren.

2. Merkmale in Merkmaldiagrammen organisieren.

3. Merkmalkombination und -interaktion analysieren.

• Abhängigkeiten und Konflikte ermitteln.

• Neue Merkmale finden, die man erst durch Analyse der Kombinationen erkennt.

4. weitere Informationen zu Merkmalen aufzeichnen.

Diese Verfahrensweise wird auf die vorliegende Problemstellung übertragen.

Gemeinsamkeiten der Merkmale sind innerhalb der verschiedenen Ebenen zu finden, da die Merkmale denselben Merkmaltyp besitzen.

Das Merkmaldiagramm organisiert die Ebenen in einer hierarchischen Struktur. Die Modellierung erfolgt in einer an FODA angelehnten Darstellungsweise. Notwendige Merkmale werden durch einen ausgefüllten Kreis gekennzeichnet. Die Kreissymbole der optionalen Merkmale sind dagegen nicht ausgefüllt. Sind die Merkmale alternativ, wird dies durch eine zusätzliche Verbindungslinie zwischen den ausgefüllten Kreisen dargestellt.