Lade Inhalt...

Entwicklung eines Konzeptes zur modellbasierten Verifikation von Fahrzeugcodierdaten

Diplomarbeit 2006 104 Seiten

Ingenieurwissenschaften - Fahrzeugtechnik

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

Vorwort

1. Einleitung
1.1 Problemstellung
1.1.1 Fehlerquellen und Auswirkungen
1.1.2 Abhilfemaßnahmen
1.2 Aufgabenstellung und Zielsetzung
1.3 Gliederung der Arbeit

2. Mögliche Modellierungsansätze
2.1 MATLAB/SIMULINK
2.2 Modellierung mit der Modellierungssprache UML
2.3 Ansatz der Merkmalmodellierung
2.3.1 Merkmalmodellierung mit der UML
2.3.2 Merkmalmodellierung mit der Notation FODA
2.4 Fazit

3. Hintergründe
3.1 Begriffsbestimmung
3.1.1 Codierdaten
3.1.2 Konzept
3.1.3 Modell
3.1.4 Konfiguration
3.1.5 Verifikation
3.1.6 Simulation
3.1.7 Merkmal
3.1.8 Domäne
3.2 Umgebungssituation
3.2.1 Software Calibration Number
3.2.2 SCN-Variantencodierung bei DaimlerChrysler
3.3 Umsetzung der Variantenvielfalt
3.3.1 Methoden zur Realisierungen der Variantenvielfalt
3.3.2 Strukturierung der Konfigurationsdaten
3.4 Modellbasierte Entwicklung
3.4.1 Modellierung
3.4.2 Feature-Oriented Domain Analysis
3.4.3 Merkmalmodell
3.5 Entwicklungsumgebung
3.5.1 Eclipse
3.5.2 pure::variants

4. Modellrealisierung
4.1 Strategie zur Merkmalidentifizierung
4.2 Fahrzeugfunktionen
4.2.1 Adaptives Bremslicht
4.2.2 Fahrdynamischer Sitz bzw. Multikontursitz
4.3 Modellierung der Funktionen
4.3.1 Modellierung der Funktion „adaptives Bremslicht“
4.3.2 Modellierung der Funktion „Multikontursitz“
4.4 Vermeidung von Redundanz
4.5 Variationspunkte im Modell
4.6 Bemerkungen zur Modellierung und Wartung
4.6.1 Identifikationsbenennung
4.6.2 Modellierung mit der Notation FODA
4.7 Fazit

5. Verifikation der Codierlogik
5.1 Konfiguration des Modells
5.2 Verifikationsmethoden
5.2.1 Sichtprüfung
5.2.2 Funktionsmodell als Simulation
5.2.3 Prüfung auf Einhaltung der Kompositionsregeln
5.2.4 Fazit
5.3 Kompositionsregeln
5.4 Einschränkung der Ausstattungsvarianten
5.5 Testprotokollierung
5.6 Voraussetzungen für die modellbasierte Verifikation
5.6.1 Benennung der Merkmale
5.6.2 Codierungslastenheft
5.7 Vorhandene Quellen
5.8 Fazit

6. Zusammenfassung

7. Ausblick

8. Literaturverzeichnis

Danksagung

Sperrvermerk

Eidesstattliche Erklärung

Anhang

Abbildungsverzeichnis

Abb. 1: Beispiel eines heutigen Fahrzeuges und dessen E/E-Komponenten

Abb. 2: Sicherheitsfunktion „Night View“

Abb. 3: Veränderung des Modellangebotes in den Automobilmärkten

Abb. 4: Einfluss mehrerer Entwickler auf eine Funktion

Abb. 5: Verlauf der Änderungskosten nach der 10er Regel

Abb. 6: Beispiel für ein UML-Modell

Abb. 7: Prozess der Fahrzeugcodierung

Abb. 8: Von der Fahrzeugausstattung zur Konfiguration

Abb. 9: Allgemeine Darstellung der Konfigurationsmenge

Abb.10: Konfigurationsmenge bei DaimlerChrysler

Abb.11: Modellbasierter Entwicklungsprozess

Abb.12: Überschaubarkeit als Grundregel der Modellierung

Abb.13: Modellbildung und Simulation

Abb.14: Beispiel für ein Merkmaldiagramm nach FODA

Abb.15: Merkmalmodellierung mit pure::variants

Abb.16: Beispiel für die require-Beziehung in pure::variants

Abb.17: Modellierung der Abhängigkeiten im Merkmaldiagramm

Abb.18: Fahrdynamischer Sitz bzw. Multikontursitz

Abb.19: Steuergeräte als notwendige und optionale Merkmale

Abb.20: Codierdomäne als notwendiges Merkmal

Abb.21: Schalter als notwendige Merkmale

Abb.22: Schalterausprägungen als alternative Merkmale

Abb.23: Ausprägungen aller Schalter der Funktion „adaptives Bremslicht“

Abb.24: Merkmalmodell der Funktion „Multikontursitz“

Abb.25: Sub-Merkmale des Steuergerätes „Multikontursitz_FL“

Abb.26: Redundanz im Modell

Abb.27: Vermeidung von Redundanz

Abb.28: Merkmalmodell Funktionen

Abb.29: Merkmalmodell Steuergeräte und Sub-Ebenen

Abb.30: Redundanzvermeidung in pure::variants

Abb.31: Anzahl möglicher und unterschiedlicher Varianten eines Schalters

Abb.32: Anzahl möglicher und unterschiedlicher Varianten einer Codierdomäne

Abb.33: Identifikationsbenennungen der Funktionen und Steuergeräte

Abb.34: Identifikationsbenennung der Ausprägungen

Abb.35: Identifikationsbenennung in pure::variants

Abb.36: Anpassung der Identifikationsbenennung

Abb.37: Notwendige und optionale Merkmale unterhalb des Konzeptknotens

Abb.38: Oder-Beziehung unterhalb eines Konzeptknotens

Abb.39: Konfiguriertes Merkmalmodell als Basis für die Verifikation

Abb.40: Konfiguration des Modells

Abb.41: Sichtprüfung als Methode der Verifikation

Abb.42: Simulation als Methode der Verifikation

Abb.43: Verifikation durch Prüfung auf Einhaltung der Kompositionsregeln

Abb.44: Kompositionsregeln beim adaptiven Bremslicht

Abb.45: Require-Beziehungen in pure::variants

Abb.46: Kompositionsregeln am Beispiel „adaptives Bremslicht“

Abb.47: Require-Beziehungen am Beispiel „adaptives Bremslicht“

Abb.48: Exclude-Beziehungen am Beispiel „adaptives Bremslicht“

Abb.49: Beispiel für mutually-inclusive-Beziehungen

Abb.50: Übersicht zur Vergabe von Beziehungen

Abb.51: Wertetabelle der Ausstattungselemente

Abb.52: Codierdomäne „VCD_Variantencodierung“

Abb.53: Funktion „adaptives Bremslicht“ als optionales Merkmal

Abb.54: Steuergeräte als notwendige und optionale Merkmale, vgl. Abb.19

Abb.55: Codierdomäne als notwendiges Merkmal, vgl. Abb.20

Abb.56: Schalter als notwendige Merkmale, vgl. Abb.21

Abb.57: Schalterausprägungen als alternative Merkmale, vgl. Abb.22

Abb.58: Gesamtfunktion „adaptives Bremslicht“, vgl. Abb.23

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Vorwort

Die letzten Jahre in der über 100-jährigen Geschichte des Automobils waren durch immer rasanter zunehmende Weiterentwicklungen und Innovationen geprägt.

Ein Meilenstein in diesem Zusammenhang war die Einführung des Bussystems1 CAN, das von der Firma Bosch Mitte der 80er Jahre speziell für die echtzeitfähige und zuverlässige Datenübertragung im Kraftfahrzeug entwickelt wurde. (vgl. [mat 04])

Bedingt durch die steigenden Erwartungen der Kunden bezüglich Leistung, Fahrkomfort, Sicherheit, Verbrauch und Schadstoffausstoß sowie den immer schärfer werdenden gesetzlichen Anforderungen, nimmt die Komplexität der Technik moderner Kraftfahrzeuge weiter zu. Lag früher der Fokus auf der Optimierung mechanischer Bauteile, so nehmen heute vor allen Dingen die elektronischen Systeme im Fahrzeug eine bedeutende Position ein. Sensoren, Aktoren und Steuergeräte halten Einzug in Fahrzeugbereiche, die in der Vergangenheit ausschließlich mechanischen Charakter hatten (z.B. Fahrwerk).

Bereits auf der Jahrespressekonferenz der Volkswagen AG 2000 stellte Dr. F. Piëch fest: „90% der Innovationen im Fahrzeugbau sind heute entscheidend durch Elektronik geprägt. Dabei kommt insbesondere der Software und ihrer Beherrschung eine Schlüsselrolle zu“ [schi 04]. Dies lässt sich an den nahezu exponentiell zunehmenden Umfängen der Software erkennen, wodurch auch eine Kostenreduzierung ermöglicht wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Beispiel eines heutigen Fahrzeuges und dessen E/E-Komponenten

Der Einsatz von Elektrik/Elektronik-Systemen findet inzwischen nicht nur in Fahrzeugen der Oberklasse statt, sondern auch bereits in Klein- und Kleinstwagen. Belief sich die Anzahl der Steuergeräte 1994 auf bis zu 14 Steuergeräte, so werden heute in Fahrzeugen der Luxusklasse bis zu 90 Steuergeräte verbaut. [gsch 04]

Der Zusammenschluss einiger Automobilhersteller (z.B. BMWGroup, DaimlerChrysler) und Systemlieferanten (z.B. Bosch, Continental) zu der Industriepartnerschaft AUTOSAR soll langfristig zu einer Standardisierung der Elektrik/Elektronik-Architektur führen. Ungeachtet dessen wird durch die Umsetzung verschiedener Funktionen mittels neuartigen Technologiesystemen, wie z.B. vernetzten Fahrerassistenzsystemen oder dem „x-by-wire2 “, auch für die Zukunft mit steigenden Elektrik/Elektronik-Umfängen und steigender Komplexität zu rechnen sein.

1. 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“).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Sicherheitsfunktion „Night View“ (vgl. [EE-Doku])

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.

1.1 Problemstellung

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. [bar 95]

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. [wom 97] Speziell bei BMW hat sich die Anzahl der angebotenen Fahrzeugvarianten zwischen 1980 und 1990 um ca. 460% erhöht, mit weiterhin steigender Tendenz. [gro 01]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Veränderung des Modellangebotes in den Automobilmärkten (vgl. [nef 01])

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Einfluss mehrerer Entwickler auf eine Funktion

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 (vgl. [kun 02]), 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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Verlauf der Änderungskosten nach der 10er Regel [kun 02]

1.1.1 Fehlerquellen und Auswirkungen

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. Codierstring3 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.

1.1.2 Abhilfemaßnahmen

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.

1.2 Aufgabenstellung und Zielsetzung

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.

1.3 Gliederung der Arbeit

Nach der Einführung in die Problemstellung, die auf die Notwendigkeit dieser Arbeit hinweist, folgt eine Untersuchung der geeigneten Modellierungsansätze in Kapitel 2.

Die theoretischen Hintergründe des gewählten Ansatzes werden in Kapitel 3 dargelegt.

In Kapitel 4 wird die Problemstellung anhand von Beispielen umgesetzt.

Auf Basis des untersuchten Ansatzes werden Methoden und Möglichkeiten zur Verifikation in Kapitel 5 erörtert.

Es folgen in den Kapiteln 6 und 7 eine Zusammenfassung und ein Ausblick auf die Potenziale der erarbeiteten Lösung sowie Vorschläge zur weiteren Verfolgung der Thematik.

Die verwendeten Quellen werden im Literaturverzeichnis in Kapitel 8 dokumentiert.

2. Mögliche Modellierungsansätze

Zu Beginn der Arbeit wurden mögliche Ansätze zur Modellierung der vorliegenden Problemstellung untersucht. Es stellte sich die Frage, welcher Ansatz für die Modellierung von Variantenvielfalt und die anschließende Verifikation des Regelwerks am besten geeignet ist.

Die Modellierung soll in Abhängigkeit von Funktionen erfolgen, da die Logiken des Regelwerks anhand von Funktionen verifiziert werden. Dies führt dazu, dass in dem Modell Abhängigkeiten abzubilden sind.

Ein weiterer zu beachtender Gesichtspunkt in diesem Zusammenhang ist, dass sich die für die Funktionen notwendigen Daten sehr schnell ändern, was im Modell berücksichtigt werden muss. Das Modell sollte daher sehr flexibel und leicht zu handhaben sein.

2.1 MATLAB/SIMULINK

MATLAB (Matrix Laboratory) ist eine kommerzielle Software der Firma „The MathWorks“ zur Beschreibung und Lösung mathematischer Probleme sowie zur grafischen Darstellung der Ergebnisse. Erweitert wird diese Software durch das blockorientierte Software-Paket SIMULINK, das auf MATLAB aufsetzt.

MATLAB/SIMULINK wird bei DaimlerChrysler für Erprobungen eingesetzt, die parallel zum Entwicklungsprozess durchgeführt werden. Bedeutende Vorgehensweisen in diesem Zusammenhang sind die so genannten „X-in-the-Loop“-Verfahren. Vertreter des „X-in-the-Loop“ sind u.a. „Model-in-the-Loop“ (MiL), „Software-in-the-Loop“ (SiL) und „Hardware-in-the-Loop“ (HiL). Sie beschreiben u.a. Testverfahren für Steuergeräte und überprüfen die softwarebeeinflusste Systemsicherheit in unterschiedlichen Phasen der Entwicklung.

Beim MiL-Verfahren wird ein Modell der spezifizierten Funktion anhand eines simulierten Systemmodells überprüft [bär 05]. Es liegen sowohl das System selbst, als auch die Systemumgebung als Modell vor. Der Test findet ohne den Einsatz spezieller Hardware auf einem oder mehreren Rechnern statt.

Wird das aus der MiL-Phase hervorgegangene Modell unter Beibehaltung der Testumgebung durch ein übersetztes und ausführbares Programm ersetzt, spricht man von SiL.

Bewertung: Derzeit sind nur wenige Funktionsmodelle von Steuergeräten in MATLAB/SIMULINK vorhanden, welche lediglich Teilfunktionen abbilden. Die getesteten Objekte hängen oft nicht unmittelbar mit der Variantencodierung zusammen. Sie kann darüber hinaus nur sehr schwer definiert in das vorliegende Funktionsmodell eingebracht werden. Infolgedessen ist es problematisch, explizit die Variantencodierung zu überprüfen.

Des Weiteren erfordert die Handhabung gute Kenntnisse des Modellierers, da es sich um eine vergleichsweise komplizierte Software handelt.

Die für die Anwendung notwendige und kostspielige Lizenz schließt diese Möglichkeit endgültig aus. Da es jedem Entwickler ermöglicht werden sollte, seine Daten und Logiken selbst zu verifizieren, würde die hohe Anzahl an benötigten Lizenzen enorme Kosten verursachen.

2.2 Modellierung mit der Modellierungssprache UML

Die Unified Modeling Language, kurz UML, ist eine sehr weit verbreitete und vielfältige Modellierungssprache. Sie entstand aus der Kombination mehrerer objektorientierter Entwicklungsmethoden durch Grady Booch, Ivar Jacobson und Jim Rumbaugh (Rational Software). Aufgrund ihrer großen Verbreitung und umfassenden Möglichkeiten wurde die UML 1997 als Standard-Modellierungssprache von der „Object Management Group“ anerkannt.

Sie ist eine grafische Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme, Geschäfts- und Datenmodelle und andere Nicht-Softwaresysteme. Darüber hinaus bietet sie den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaremodellen auf einheitlicher Basis, insbesondere auch mit den Fachleuten, zu diskutieren. (vgl. [dum])

UML, was als „vereinheitlichte Modellierungssprache“ übersetzt werden kann, ist unabhängig von Programmiersprachen und die Basis für die so genannte modellbasierte Architektur.

Wesentliche Elemente dieser Sprache sind mehrere, sich ergänzende Diagrammtypen, wie z.B. Klassen- oder Zustandsdiagramme.

Die UML soll anhand eines Klassendiagramms näher veranschaulicht werden. Bei einem Klassendiagramm werden gleichartige Objekte in Klassen zusammengefasst, wobei die Objekte die Grundelemente einer Anwendung sind. Die Gleichartigkeit dieser Objekte bezieht sich auf ihre Eigenschaften (Attribute) und/oder auf Fähigkeiten (Operationen/Methoden). Eine Klasse enthält gewissermaßen die Konstruktionsbeschreibung für Objekte, die mit ihr erzeugt werden. (vgl. [dum])

In Abbildung 6 sind vier Klassen dargestellt, wobei die Klasse „Automobil“ die Oberklasse ist. Unterklassen sind „Cabriolet“, „Geländewagen“ und „VAN“. Jede Klasse besitzt ein Attribut, das die jeweilige Klasse auszeichnet (z.B. Allradantrieb zeichnet den Geländewagen aus).

In der dritten Zeile einer Klasse wird definiert, welche Operationen bei einer Klasse angewendet werden sollen.

Durch die Vererbungspfeile wird beschrieben, dass die Unterklassen die Eigenschaft der Oberklasse vererbt bekommen. Demnach besitzen sowohl das Cabriolet, als auch der Geländewagen und der VAN einen 6 Zylinder Otto-Motor.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Beispiel für ein UML-Modell

Ein Vorteil, der sich aus der standardisierten Verwendung ergibt, ist die große Anzahl an Werkzeugen zur Modellierung.

Bewertung: Für die Abbildung von Abhängigkeiten einzelner Bestandteile des Modells fehlen in dieser Standardsprache die Notationselemente4. Dadurch müssen diese Abhängigkeiten durch textuelle Beschreibungen im Modell geschaffen werden, was kompliziert, unflexibel und unkomfortabel ist. Eine schnelle Anpassung an Ver- änderungen ist insofern nicht gegeben.

Weiterhin wird das Modell bei einer Abbildung vieler Bestandteile für den Betrachter sehr schnell unübersichtlich und kann infolgedessen nicht als Diskussionsgrundlage eingesetzt werden.

2.3 Ansatz der Merkmalmodellierung

Bei der Recherche nach Modellierung von Variabilitäten bzw. Variantenvielfalt trifft man zwangsläufig auf die Notation der Merkmalmodellierung. Sie dient der Erfassung von Gemeinsamkeiten und Unterschieden verschiedener Systeme, wobei die Unterschiede die Variabilität abbilden. Diese Modellart beschreibt die Beziehungen der modellierten Merkmale untereinander und stellt diese grafisch in einer Baumstruktur dar.

Das Merkmalmodell, auch Feature- oder Variabilitätsmodell genannt, ist ein zentraler Bestandteil bei der Erstellung und Verwaltung von Produktlinien. (vgl. [cle 02])

[eis 00] definiert die Merkmalmodellierung wie folgt:

„Feature Modeling is the activity of modeling the common and the variable properties of concepts and their interdependencies and organizing them into a coherent model referred to as feature model.“

Es existieren verschiedene miteinander konkurrierende Notationen, mit denen Merkmalmodelle abgebildet werden können.

2.3.1 Merkmalmodellierung mit der UML

Die UML lässt es aufgrund der vielfältigen Einsatzmöglichkeiten zu, durch eine Erweiterung den Modelltyp des Merkmalmodells abzubilden.

[cla 01] beschreibt in seiner Arbeit die Modellierung von Variabilität in UML. Er entwickelt eine Erweiterung, die zur Merkmalmodellierung, Beschreibung von Variationspunkten, optionalen Elementen und somit zur Abbildung von Variabilität geeignet ist. Weiterhin untersucht er mögliche Darstellungsformen und erarbeitet daraus einen neuartigen Notationsvorschlag.

Bewertung: Es soll eine einfache Beziehungsstruktur auf einen bestehenden Standard übertragen werden, der den Modellierungstyp der Merkmalmodellierung gegenwärtig nicht berücksichtigt. Zwar ist es bei diesem Ansatz durch größeren Aufwand grundsätzlich möglich, Variabilität abzubilden (vgl. [cla 01]), jedoch müssen dafür zuerst Voraussetzungen z.B. in Form einer geeigneten Notation geschaffen werden. Nimmt der Umfang der modellierten Elemente zu, wird zur Beibehaltung der Übersichtlichkeit eine Beschreibung in mehreren Diagrammen notwendig.

Die Merkmalmodellierung kann durch andere Methoden, die explizit für diesen Modelltyp konzipiert wurden, einfacher abgebildet werden. Dieser Ansatz ist deshalb derzeit noch nicht geeignet.

2.3.2 Merkmalmodellierung mit der Notation FODA

Die Merkmalmodellierung wurde erstmals mit der Methode FODA (Feature-Oriented Domain Analysis) eingeführt. Die Modell-Notation gemäß FODA dient im Bereich der Produktlinien als Grundlage für viele Erweiterungen. (vgl. [fri 05])

Es können hier explizit die Abhängigkeiten verschiedener Merkmale modelliert und durch eine leicht verständliche, grafische Darstellungsweise in Baumstruktur abgebildet werden.

Die Beschreibung von Querbeziehungen zwischen einzelnen Merkmalen, die unterschiedlichen Ästen des Baumes zugehörig sind, ist ebenfalls möglich.

Bewertung: Die Merkmalmodellierung mit dieser Methode erleichtert grundsätzlich die Handhabung von Varianten verschiedener Produktlinien. Die grafische Darstellung der Variantenvielfalt in Baumstruktur führt zu einer übersichtlichen Diskussionsgrundlage für alle Beteiligten. Da dieser Ansatz eine leicht verständliche Notation verwendet, ist die Modellierung nicht nur den Spezialisten vorbehalten. Durch die Möglichkeit, Querbeziehungen zwischen Merkmalen verschiedener Äste herzustellen, ist darüber hinaus Flexibilität gegeben. Die Verifikation könnte auf diesen Querbeziehungen beruhen.

2.4 Fazit

Die Merkmalmodellierung an sich stellt sich als geeigneter Ansatz zur Modellierung von Variantenvielfalt dar. Die Modellierung mit der Notation FODA bringt hier gegenüber der sonst als Standard eingesetzten Modellierungssprache UML entscheidende Vorteile. Die Modellierung der Variantenvielfalt ist durch FODA leicht möglich und kann durch die Darstellung in Baumstruktur übersichtlich abgebildet werden. Eine geeignete Notation zur Abbildung der Beziehungen ist bereits vorhanden.

Aus diesen Gründen steht dieser Ansatz im Mittelpunkt des zu entwickelnden Konzeptes.

3. Hintergründe

Die theoretischen Grundlagen für diese Arbeit werden im folgenden Kapitel zusammengefasst.

3.1 Begriffsbestimmung

Dieser Abschnitt dient zum Verständnis und zur Eingrenzung der in der Umgangssprache oft ungenau verwendeten, für diese Arbeit jedoch notwendigen Begriffe. Erläutert werden hier ebenfalls Ausdrücke, die in bestimmten Bereichen zum Fachjargon gehören.

3.1.1 Codierdaten

Dieser Begriff beschreibt alle für die Fahrzeugcodierung notwendigen Informationen. Es muss allerdings zwischen den eigentlichen Daten und einem Regelwerk, wodurch sich diese Daten steuern lassen, unterschieden werden. Die Daten werden aus Gründen der Verständlichkeit weiterhin als „Codierdaten“ und das Regelwerk als „Codierlogik“ bezeichnet.

3.1.2 Konzept

Der Ausdruck „Konzept“ stammt von lat. concipere ab, was sich als „erfassen“ oder „in sich aufnehmen“ übersetzen lässt. (vgl. [com])

Dieser Begriff kann sowohl als erster Entwurf bzw. Vorstufe einer Theorie, als auch als gedankliche Zusammenfassung eines Sachverhaltes verstanden werden.

In dieser Arbeit wird der Begriff „Konzept“ als theoretische Ausarbeitung bzw. Vorschlag zur möglichen Weiterverfolgung verstanden.

3.1.3 Modell

Ein Modell ist eine mathematische oder grafische Darstellung einer realen Situation oder eines realen Objektes. Modelle lassen sich im Allgemeinen ändern oder manipulieren, so dass man Auswirkungen einer Modifikation oder Variation auf das reale Objekt beobachten kann. (vgl. [mic 05])

Ein Modell zeichnet sich grundsätzlich durch Abstraktion aus, also die bewusste Vernachlässigung bestimmter Merkmale, um die für den Modellierer oder den Modellierungszweck wesentlichen Modelleigenschaften hervorzuheben. Dies orientiert sich an den Fragen: Für wen ist das Modell? Und: Warum wird das Modell erstellt?

3.1.4 Konfiguration

Eine Konfiguration ist eine Menge von Einzelelementen, aus denen ein Sachverhalt in einer speziellen und zu einem bestimmten Zeitpunkt gültigen Ausprägung aufgebaut ist.

Es wird im sprachlichen Gebrauch die Veränderung der Einzelkomponenten bzw. die Einstellung an sich als Konfiguration bezeichnet. Der Vorgang bzw. das Handeln steht also im Vordergrund.

In dieser Arbeit wird der Begriff „Konfiguration“ sowohl im Sinne einer Ausprägung, als auch als Einstellungsvorgang verwendet.

3.1.5 Verifikation

Als „Verifikation“ bzw. „Verifizierung“ (von lat. veritas, Wahrheit (vgl. [com])) wird der Vorgang bezeichnet, einen behaupteten oder vermuteten Sachverhalt zu überprüfen und gegebenenfalls als wahr zu belegen.

Die wichtigste Methode zur Verifikation eines Sachverhaltes ist der Test.

Ein in ähnlichem Zusammenhang verwendeter Begriff ist die „Validierung“, die mit der Verifikation allerdings nicht verwechselt werden darf.

Die Validierung beschäftigt sich mit der Frage: Are we doing the right thing? und ist insofern eine Prüfung, ob das, was entwickelt wird, auch wirklich gewünscht ist.

Im Gegensatz dazu steht die Frage: Are we doing the thing right? bei der Verifikation im Mittelpunkt. Dabei handelt es sich um die Prüfung, ob ein bestimmter Entwicklungsschritt inhaltlich richtig durchgeführt wird. (vgl. [kos 05])

3.1.6 Simulation

Der Begriff „Simulation“ leitet sich aus dem lat. simulare ab, was als „vorgeben“ oder „ähnlich machen“ übersetzt werden kann (vgl. [com]). Eine Simulation ist im Wesentlichen ein Analyse-, aber auch ein entscheidungsunterstützendes Instrument.

Die möglichst realitätsnahe Nachbildung und Ausführung einer bestimmten Funktion bzw. das Verhalten eines Systems auf einem Rechnersystem ist heute die gängigste Bedeutung des Ausdrucks „Simulation“.

Im engeren Sinn entnimmt man der VDI-Richtlinie 3633 von 1993 die folgende Definition:

"Simulation ist ein Verfahren zur Nachbildung eines Systems mit seinen dynamischen Prozessen in einem experimentierbaren Modell, um zu Erkenntnissen zu gelangen, die auf die Wirklichkeit übertragbar sind." [bre 04]

Es können auch Zustände simuliert werden, die nicht real existent und deren Gegebenheiten nicht vollständig bekannt sind.

3.1.7 Merkmal

Als „Merkmal“ wird eine Eigenschaft einer einzelnen Sache, einer Gruppe oder einer Person bezeichnet, die diese auszeichnet. An ihr kann das Objekt bzw. die Person erkannt, beschrieben und von anderen unterschieden werden, die diese Ausprägung nicht bzw. anders haben. (vgl. [wiki])

3.1.8 Domäne

Eine Domäne grenzt einen Systembereich oder ein Problemfeld von der Umgebung ab und beschreibt ein Spezialgebiet bzw. Wissensgebiet, z.B. Bank-, Versicherungs- oder Automotive-Domäne. Sie zeichnet sich durch sehr spezifische Begrifflichkeiten und Inhalte aus, die von Fachleuten in diesem Bereich verstanden werden.

Eine Sub-Domäne ist dann folglich eine Domäne, die in der Hierarchie unterhalb der Domäne liegt. Eine Sub-Domäne in der Automotive-Domäne wäre dann z.B. der Bereich Elektrik/Elektronik.4

3.2 Umgebungssituation

Der gegenwärtig gültige Prozess der so genannten „SCN-Variantencodierung“ in der Entwicklung, Produktion und im After Sales zeigt die Entstehung und die weitere Handhabung der Codierdaten bei DaimlerChrysler auf.

3.2.1 Software Calibration Number

Die Software Calibration Number (SCN) ist eine Zahl, mit der die Software und Codierung eines Steuergerätes eindeutig identifiziert werden kann. Dadurch wird auf den Codierzustand eines einzelnen Fahrzeuges geschlossen.

Ursprung der Entwicklung der SCN waren gesetzliche Vorgaben in den USA und Europa mit dem Ziel, anhand der Software und der Codierung von abgasrelevanten Steuergeräten des Antriebsstranges das Abgasverhalten eines Fahrzeuges zu dokumentieren. Aufgrund der aus diesem Vorgang resultierten Vorteile wurde dieses Verfahren auch auf andere Steuergeräte übertragen (z.B. Komfortsteuergeräte).

Zur Generierung, Verwendung und Pflege dieser Nummern sowie zur Versorgung, Dokumentation und Freigabe der Codierdaten, wurde bei DaimlerChrysler der so genannte „SCN-Prozess“ ins Leben gerufen.

Der komplexe Codierablauf wird dadurch automatisiert. Fehler durch manuelle Schritte im Prozess werden damit unterbunden. Ebenso können Änderungen maschinell gesteuert werden. So wird sichergestellt, dass die verwendete Codierung immer zur aktuellen Software-Freigabe passt. Durch den SCN-Prozess werden die Codierdaten von der Entwicklung direkt bis in die Produktion bzw. Tester der Werkstätten überliefert.

3.2.2 SCN-Variantencodierung bei DaimlerChrysler

Bestellt ein Kunde bei seinem Händler ein Fahrzeug, so wird anhand des von ihm gewählten Modells und der Ausstattung durch das System des Händlers an das Herstellerwerk eine Reihe von Zahlencodes übermittelt.

Durch dreistellige Nummern oder Buchstabenkombinationen sind bestimmte Motorvarianten, Getriebevarianten und Ausstattungsvarianten beschrieben, die durch das System aneinandergereiht werden. Mit dieser Methode der datentechnischen Beschreibung einzelner Ausstattungsmerkmale wird es für den Hersteller möglich, den Produktionsprozess zu automatisieren.

Vorbereitend zur Produktion des Fahrzeuges wird durch den Produktionsserver anhand dieser Zahlencodes eine Stückliste für die benötigten Bauteile generiert.

Die Codierlogik und die Codierdaten werden in den Prozess mit eingespeist und durch den Produktionsserver verarbeitet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7: Prozess der Fahrzeugcodierung

Prozessschritte, die hier nicht aufgeführt sind, sollen an dieser Stelle nicht relevant sein.

Wird durch die Codierlogik z.B. beschrieben, dass im Land „xy“ die „Kopfstützenabklappung bei Rückwärtsgang“ nicht zugelassen ist, so wird die Funktion „Kopfstützenabklappung“ im Codierstring als „nicht aktiv“ vermerkt.

Der Codierstring, der diese Information beinhaltet, wird nun in der Produktion in das jeweilige Fahrzeug eingespielt. Dadurch wird die Funktion „Kopfstützenab-klappung bei Rückwärtsgang“ bei diesem Fahrzeug deaktiviert.

3.3 Umsetzung der Variantenvielfalt

Um den Kunden eine vielfältige Auswahl an Fahrzeugausstattungen anbieten zu können, ist es auf Herstellerseite notwendig, die daraus entstehende Varianten- und Funktionsvielfalt auf eine geeignete Art und Weise zu realisieren.

Die Komplexität muss in der Realität wirtschaftlich abgebildet werden. Dazu bedarf es an Know-how, was hier beschrieben werden soll.

3.3.1 Methoden zur Realisierungen der Variantenvielfalt

Prinzipiell kann die Realisierung der Variantenvielfalt eines Fahrzeuges durch die folgenden Methoden sichergestellt werden:

- Zum einen ist es möglich, die Varianz einer Funktion durch mehrere Bauteilvarianten zu realisieren. Zwangsläufig führt dies jedoch zu einem enormen Lager- und Logistikaufwand.
- Eine andere Möglichkeit besteht darin, ein Hardwarebauteil zu verwenden und die unterschiedlichen Funktionen durch variierende Softwaremodule5, die auf einer Betriebssoftware6 aufsetzen, abzubilden. Ein großer Vorteil dieser Methode ist die Reduktion des Lageraufwandes, die relativ einfache Behebung von Fehlern, die schnelle Anpassung, die problemlose Vervielfältigung der Daten sowie die einfache Darstellung verschiedener Varianten.

Tritt ein Fehler auf, ist meist nicht das Steuergerät zu wechseln, sondern es reicht das Aufspielen einer korrigierten Software.

- Eine zusätzliche Erweiterung ist die Variantenabbildung über Softwarekonfigurationen. In modernen Kraftfahrzeugen werden Fahrzeugfunktionen zusätzlich mittels Konfiguration bzw. Codierung variiert, wobei einerseits die Hardwarebauteile zum Einsatz kommen und andererseits nun auch einzelne, konfigurierbare Softwarebasisversionen. Bildlich gesehen gleicht diese Art und Weise der Variantenabbildung einem umfangreichen Schaltersystem, das über verschiedene Stellungen Zustände regelt. Ist der Schalter auf eine bestimmte Position umgelegt, so ist die dazugehörige Ausprägung aktiviert.

3.3.2 Strukturierung der Konfigurationsdaten

Der Steuergeräteentwickler steht heute vor der Herausforderung, logische Regeln zu implementieren, welche die Konfiguration einer Fahrzeugfunktion in einem automatisierten Vorgang ermöglicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 8: Von der Fahrzeugausstattung zur Konfiguration

Fahrzeugfunktionen werden, wie bereits beschrieben, durch das Zusammenspiel mehrerer Steuergeräte realisiert. In jedem Steuergerät müssen Konfigurationen getätigt werden, um Funktionen so umzusetzen, wie sie vom Kunden bestellt wurden und sie die gesetzlichen Anforderungen erfüllen. Dies kann, je nach Funktion und Steuergerät, enorme Umfänge annehmen.

Für die Realisierung der Funktion „Fahrdynamischer Sitz/Multikontursitz“ beispielsweise, sind für einen einzelnen Sitz ca. 200 Konfigurationen zu berücksichtigen. Darin sind alle Einstellungen der für diese Funktion notwendigen Steuergeräte enthalten.

Sollen alle Sitze eines Fahrzeuges über diese Funktion verfügen, sind es ca. 750 Möglichkeiten zur Einstellung.

Bei einem Vergleich mit dem beschriebenen Schaltersystem kann folgende Rechnung aufgeführt werden:

In dem Fall, dass ein einzelner Schalter 100 Einstellungen besitzt, gibt es 100 Einstellungsmöglichkeiten. Sind diese jedoch auf 20 Schalter verteilt, sind es bereits 520 Kombinationsmöglichkeiten der Einstellungen. Bei 50 Schaltern entspricht dies einer Menge von 250.

Die Möglichkeiten zur Einstellung der Schalter variieren bei der Funktion „Multikontursitz“ zwischen zwei und fünf.

Um diese Vielzahl der Konfigurationsmöglichkeiten in Abhängigkeit von Funktionen abbilden zu können, ist die Untergliederung in Ebenen sinnvoll. Zur Strukturierung der Daten werden mehrere Ebenen eingeführt.

Die Funktionen werden durch mehrere Steuergeräte realisiert, die wiederum mittels Codierdaten („Ebene 1“ bis „Ebene n“) für die jeweilige Funktion konfiguriert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9: Allgemeine Darstellung der Konfigurationsmenge

Bei DaimlerChrysler erfolgt die Unterteilung der Codierdaten in drei Ebenen. Die unter der Steuergeräteebene angesiedelten Codierdomänen fassen mehrere Elemente der funktionalen Gliederung zusammen, die wie die beschriebenen Schalter fungieren. Wird der Schalter umgelegt, können dadurch in der untersten Ebene diverse Einstellungen bzw. Schalterausprägungen aktiviert werden, z.B. Einstellungen wie „an“ oder „aus“ oder die Aktivierung von bestimmten Werten, wie z.B. „100ms“ oder „200ms“.

In der Schalterebene wird nun angegeben, was durch das Umlegen des Schalters an- oder ausgeschalten bzw. eingestellt werden soll, z.B. „Dauer der Dunkelphase“ (bei einem Blinklicht) „100ms“ oder „200ms“.

Abbildung in dieser Leseprobe nicht enthalten

Abb.10: Konfigurationsmenge bei DaimlerChrysler

Jedes Steuergerät beinhaltet für eine Funktion, bei der dieses Steuergerät beteiligt ist, mehrere Codierdomänen, Schalter und Ausprägungen. Diese Informationen können sich sowohl innerhalb eines Steuergerätes, als auch steuergeräteübergreifend beeinflussen, da sie miteinander in Beziehung stehen (verteiltes System). Ist im Steuergerät „A“ eine Einstellung „falsch gesetzt“, kann dies zur Folge haben, dass eine Einstellung im Steuergerät „B“ nicht in Kraft tritt. Es müssen demnach alle Schalterausprägungen, die die jeweiligen Schalter und Codierdomänen betreffen, richtig aufeinander abgestimmt sein, damit die gewünschte Funktion korrekt verfügbar ist.

3.4 Modellbasierte Entwicklung

Kurze Entwicklungszyklen, große Datenmengen und die hohen Anforderungen an die Sicherheit im Automobil führen dazu, dass die klassischen Methoden der Softwareentwicklung den spezifischen Herausforderungen der Automobilhersteller nicht mehr gerecht werden.

Bei der Entwicklung von Softwareanteilen für Steuergeräte vollzieht sich seit einigen Jahren ein Paradigmenwechsel, der durch einen Übergang von der klassischen Programmentwicklung hin zu modellbasierten Techniken gekennzeichnet ist [kle 04]. Es handelt sich hierbei um die so genannte „modellgetriebene Softwareentwicklung“ (Model-Driven Software Development-MDSD).

Man spricht von modellbasierter Entwicklung, wenn Software teilweise oder vollständig aus Modellen generiert wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb.11: Modellbasierter Entwicklungsprozess [bie 04]

3.4.1 Modellierung

Unter „Modellierung“ versteht man den Einsatz von Computern für die Beschreibung des Verhaltens eines Systems. [mic 05]

Die Modellierung unterstützt den Entwickler dabei, die gewünschte Struktur und das Verhalten eines bestimmten Systems zu beschreiben. Ist ein strukturierter Aufbau gegeben, kann das System durch die Visualisierung auch für Laien als gute Diskussionsgrundlage dienen.

Abbildung in dieser Leseprobe nicht enthalten

Abb.12: Überschaubarkeit als Grundregel der Modellierung (vgl. [schäu 04])

Selbst komplexe Systeme werden verständlicher, weil sich der Betrachter auf einen Bereich in dem System konzentrieren kann.

Die Modellierung an sich hilft, frühzeitig Probleme des Modells zu erkennen und zu beheben.

Abbildung in dieser Leseprobe nicht enthalten

Abb.13: Modellbildung und Simulation (vgl. [bub 90])

3.4.2 Feature-Oriented Domain Analysis

FODA ist eine merkmalsorientierte Domänenanalyse und wurde 1990 am Software Engineering Institute der Carnegie Mellon University von [kang 90] entwickelt. Dieser Ansatz liefert ein methodisches Vorgehen für die Domänenanalyse (Domain Analysis), in der Gemeinsamkeiten von verwandten Systemen analysiert und durch die Beschreibung von Anforderungen charakterisiert werden. Bei dieser Methode wurde die Notation der Merkmalmodelle erstmals verwendet.

FODA „beschreibt die wichtigsten Eigenschaften von Anwendungen einer Domäne aus Sicht des Kunden oder Endbenutzers.“ [völ 00]

Weitere Ansätze zur Merkmalmodellierung sind u.a.:

- FODAcom: Erweiterung von FODA für die Telekommunikationsbranche
- FOPLE: Feature-Oriented Product Line Engineering
- FeatuRSEB: Kombination von FODA und RSEB (Reuse-Driven Software Engineering Business)
- FORM: Feature-Oriented Reuse Method

[poh 03]

In dieser Arbeit soll der Ansatz FODA im Mittelpunkt stehen.

3.4.3 Merkmalmodell

In einem Merkmalmodell sind die Merkmale hierarchisch angeordnet, wobei die Wurzel des Baumes den Konzeptknoten enthält, der stellvertretend für die gesamte Systemfamilie steht.

Die hierarchischen Beziehungen zwischen Merkmalen lassen sich folgendermaßen klassifizieren:

Notwendige Merkmale: Ein notwendiges Merkmal muss immer ausgewählt werden, sobald das übergeordnete Merkmal ausgewählt oder das notwendige Merkmal dem Konzeptknoten untergeordnet ist.

Optionale Merkmale: Ein optionales Merkmal kann ausgewählt werden, wenn einerseits das übergeordnete Merkmal ausgewählt oder andererseits das optionale Merkmal dem Konzeptknoten untergeordnet ist.

Alternative Merkmale: Aus einer Gruppe alternativer Merkmale muss genau ein Merkmal gewählt werden, sobald das übergeordnete Merkmal ausgewählt ist. Ebenso, wenn die Gruppe dem Konzeptknoten direkt unterliegt.

Oder-Merkmale: Aus einer Gruppe von Oder-Merkmalen muss mindestens ein Merkmal ausgewählt werden. Auch hier gilt: Dies ist dann der Fall, wenn entweder das übergeordnete Merkmal ausgewählt oder die Gruppe dem Konzeptknoten untergeordnet ist. Zusätzlich können aus der Gruppe beliebig viele weitere Merkmale ausgewählt werden. (vgl. [fri 05])

Abbildung in dieser Leseprobe nicht enthalten

Abb.14: Beispiel für ein Merkmaldiagramm nach FODA (vgl. [eis 00])

Abbildung 14 zeigt die grafische Darstellung einer offenen, einer unvollständigen und einer normalen Merkmalbeziehung am Beispiel Kraftfahrzeug. Ein offenes Merkmal hat die Bedeutung, dass zu dessen untergeordneten Merkmalen (Sub-Merkmalen) noch weitere Merkmale zu einem späteren Zeitpunkt hinzukommen können. Ein unvollständiges Merkmal ist noch nicht komplett beschrieben.

Ein Merkmal kann entweder ein möglicher oder ein fester Bestandteil eines übergeordneten Merkmals sein. Bei einem übergeordneten Merkmal spricht man von einem Eltern-Merkmal.

In dem aufgeführten Beispiel ist es also notwendig, dass das Automobil einen Motor, eine Karosserie und ein Getriebe besitzt. Nicht zwingend notwendig ist eine Anhängerkupplung, was durch das entsprechende Symbol gekennzeichnet ist.

Es besteht nun die Möglichkeit, das Fahrzeug mit einem Elektromotor, einem Ottomotor oder mit beiden Antriebsquellen zu betreiben. Dies wird durch eine Oder-Beziehung dargestellt. Anders verhält es sich bei dem Getriebe. Ein Fahrzeug verfügt nicht über mehrere Getriebe, sondern nur über eines. Die Beziehung der Sub-Merkmale des Merkmals „Getriebe“ legt deshalb fest, dass ein Automobil entweder ein Automatikgetriebe oder ein Handschaltungsgetriebe besitzt.

Einige Abhängigkeiten lassen sich jedoch nicht durch die Baumstruktur abbilden. So müssen die so genannten „Kompositionsregeln“ (Composition Rules) bzw. Constraints, die Querbeziehungen unter den einzelnen Merkmalen herstellen, textuell beschrieben werden.

Die wichtigsten Kompositionsregeln sind:

requires (erfordert): Ein Merkmal erfordert zwingend die Auswahl eines anderen Merkmals.

excludes (schließt aus): Ein Merkmal schließt die Auswahl eines anderen Merkmals aus.

Kompositionsregeln beschreiben einen überprüfbaren Ausdruck, der zu den Wahrheitswerten „wahr“ oder „falsch“ ausgewertet wird. Diese Regeln müssen von jeder konkreten Ausprägung eines Merkmalmodells eingehalten werden, damit das System gültig ist.

3.5 Entwicklungsumgebung

Zur praktischen Umsetzung des Konzeptansatzes sind Softwaretools notwendig, die hier kurz vorgestellt werden.

Die Modellierung wird weitestgehend unabhängig von den verwendeten Tools beschrieben. Da jedoch einige der folgenden Darstellungen auf diesen Werkzeugen basieren, ist für das bessere Verständnis eine Beschreibung der toolspezifischen Umsetzung notwendig.

3.5.1 Eclipse

Als Plattform zur Modellierung des Merkmalmodells wird die sehr weit verbreitete, anwenderfreundliche und freie Entwicklungsumgebung „Eclipse“ verwendet.

Von [OTI 03] wird Eclipse so beschrieben:

"The Eclipse Platform is an IDE for anything, and for nothing in particular."

Eclipse besteht aus einer in der Programmiersprache JAVA geschriebenen Kernsoftware und kann mittels Plug-Ins7 erweitert und zur Erstellung von IDEs (Integrated Development Environment8 ) genutzt werden. Eclipse ist ein Open Source-Projekt9.

Somit ist ein hochflexibles Gerüst die Folge, das sich durch zusätzliche Einzelmodule an viele Aufgaben anpassen lässt. Eclipse erinnert in seiner Funktionsweise an ein Baukastensystem, aus dem sich jeder Anwender aus einer Fülle von Möglichkeiten genau die zusammenstellen kann, die seinen Anforderungen am ehesten genügen.

Ein zur Umsetzung des Merkmalmodells eingesetztes Plug-In stellt das im Folgenden vorgestellte „pure::variants“ der „pure-systems GmbH“ dar.

3.5.2 pure::variants

pure::variants ist ein variables und effizientes Werkzeug zum Variantenmanagement von Produktlinien. Es ist unabhängig von Programmiersprachen und lässt sich einfach in bestehende Entwicklungsprozesse und Umgebungen einbinden.

pure::variants unterstützt die Erzeugung, Verwaltung und Überprüfung aller dazu erforderlichen Modelle und nutzt XML-basierende10 Datenformate zu deren Speicherung. Die hier verwendete „pure::variants Developer Edition“ ist als Plug-In für die Open Source Eclipse IDE verfügbar.

Weitere Tools zur Merkmalmodellierung sind z.B. das an der Fachhochschule Kaiserslautern entwickelte „AmiEddi“ oder dessen direkter Nachfolger „Captain Feature“.

Die Darstellung der Beziehungen im Merkmalmodell erfolgt bei pure::variants durch vier Symbole:

Notwendiges Merkmal: Abbildung in dieser Leseprobe nicht enthalten

Optionales Merkmal: Abbildung in dieser Leseprobe nicht enthalten

Alternatives Merkmal: Abbildung in dieser Leseprobe nicht enthalten

Oder-Merkmal: Abbildung in dieser Leseprobe nicht enthalten

Abbildung in dieser Leseprobe nicht enthalten

Abb.15: Merkmalmodellierung mit pure::variants (vgl. [pur 05])

Hier wird ein einfaches Modell eines Fahrzeuges dargestellt, wie es inhaltlich mit der Abbildung 14 vergleichbar ist.

Das Fahrzeug benötigt Bremsen, ein Getriebe und einen Motor. Optional sind Sicherheitsfunktionen. Es verfügt entweder über ein Automatikgetriebe oder über eine Handschaltung usw.

Bei diesem Modellierungswerkzeug ist ebenfalls die Vergabe von Kompositionsregeln möglich. Muss z.B. für ein bestimmtes Merkmal ein anderes Merkmal vorhanden sein, so werden diese Merkmale mit einer require-Beziehung verbunden und farblich unterlegt.

Abbildung in dieser Leseprobe nicht enthalten

Abb.16: Beispiel für die require-Beziehung in pure::variants

Dieses Beispiel zeigt, dass das Merkmal „SteuergeraetFondsitze_R“ die Merkmale „SteuergeraetMultikontursitz_RR“ und „SteuergeraetMultikontursitz_RL“ erfordert. Werden diese bei einer Auswahl des Merkmals „SteuergeraetFondsitze_R“ nicht ausgewählt, kommt es zur Fehlermeldung.

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 [spi 05].

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb.17: Modellierung der Abhängigkeiten im Merkmaldiagramm

Auf der obersten Ebene werden die Funktionen dargestellt. In der zweiten Ebene sind diejenigen Steuergeräte aufgelistet, die die jeweilige Funktion beeinflussen. In der nächsten Detaillierungsstufe werden den Steuergeräten Codierdomänen zugeordnet, die wiederum aus Schaltern und Schalterausprägungen bestehen.

Die jeweiligen Abhängigkeiten der Ebenen untereinander sind wie folgt festgelegt:

Eine Funktion wird als optionales Merkmal beschrieben. Sind Steuergeräte zur Realisierung der Funktion zwingend erforderlich, werden sie als notwendige Merkmale gekennzeichnet. Sind diese nicht unbedingt notwendig, werden sie als optionale Merkmale festgelegt.

Ebenso verhält es sich mit den Codierdomänen und Schaltern. Sie sind sowohl notwendig, als auch optional. Je Schalter kann nur eine Ausprägung gewählt werden, weshalb diese Ausprägungen alternative Merkmale sind.

Weitere Informationen zu den Merkmalen können Elemente der Codierlogik oder Kompositionsregeln sein, die im Modell dokumentiert werden.

Eine vorausschauende Identifizierung ist die Einbeziehung momentan nicht codierter, für die Umsetzung der Funktion jedoch notwendiger Steuergeräte.

4.2 Fahrzeugfunktionen

Um eine beispielhafte Modellierung durchführen zu können, werden an dieser Stelle zwei Funktionen eines heutigen Fahrzeuges, die durch Codierung beeinflusst werden, festgelegt. Funktionsbeschreibungen sollen zum besseren Verständnis beitragen.

4.2.1 Adaptives Bremslicht

Um nachfolgenden Fahrzeugen anzuzeigen, dass der Fahrer eine Notbremsung durchführt, wird das Bremslicht blinkend angesteuert. Dem Fahrer des folgenden Fahrzeuges wird dadurch eine Gefahrensituation signalisiert. Dies führt durch eine Verringerung der Reaktionszeit beim Hintermann zu einer Erhöhung der Sicherheit und leistet somit einen wichtigen Beitrag zur Reduzierung von Auffahrunfällen.

[...]


1 Ein Bussystem verbindet einzelne Steuergeräte und überträgt Informationen mit Hilfe von Informationseinheiten. [gsch 04]

2 Bei „x-by-wire“ werden mechanische und hydraulische Komponenten durch elektrische und elektronische Systeme ersetzt.

3 Aus Codierinformationen erstellter Datensatz, der als Codierung ins Steuergerät geschrieben wird.

4 Eine Notation ist die Beschreibung der Symbolik im Modell.

5 Softwaremodule lassen sich für den jeweiligen Anwendungsfall individuell parametrieren und kombinieren.

6 Die Betriebssoftware realisiert die anwendungsunabhängigen Grundfunktionen, wie z.B. die Anbindung an die verschiedenen Bussysteme.

7 Ein Plug-In ist ein Ergänzungsmodul, das in ein anderes Softwareprodukt „eingeklinkt“ wird. (vgl. [wiki])

8 Eine integrierte Entwicklungsumgebung ist ein Anwendungsprogramm zur Entwicklung von Software.

9 Open Source-Projekte werden durch Gruppen gebildet, bei denen freiwillige Akteure über das Internet Software entwickeln. Im Gegensatz zu kommerziellen Projekten legen die Open Source-Projekte den Quellcode ihrer Software offen.

10 XML ist ein Standard zur Erstellung maschinen- und maschinenlesbarer Dokumente in Form einer Baumstruktur. XML definiert dabei die Regeln für den Aufbau solcher Dokumente.

Details

Seiten
104
Erscheinungsform
Originalausgabe
Jahr
2006
ISBN (eBook)
9783842815278
Dateigröße
3 MB
Sprache
Deutsch
Katalognummer
v228523
Institution / Hochschule
Fachhochschule Esslingen Hochschule für Technik Esslingen – Maschinenbau / Fahrzeugtechnik, Fahrzeugtechnik
Note
1,7
Schlagworte
variantenmanagement modellierung fahrzeug konzept

Autor

Teilen

Zurück

Titel: Entwicklung eines Konzeptes zur modellbasierten Verifikation von Fahrzeugcodierdaten