Vorlage für ika und fka Berichte deutsch

Inhalt
3
Inhalt
1
Einleitung....................................................................................................................... 6
2
Fahrerassistenzsysteme ................................................................................................ 7
2.1
Einteilung von Fahrerassistenzsystemen ................................................................. 8
2.2
Umgebungserfassende Assistenzsysteme ............................................................ 10
2.2.1
Parkassistent ..................................................................................................... 11
2.2.2
Adaptive Cruise Control ..................................................................................... 12
2.2.3
Stauassistent ..................................................................................................... 14
2.2.4
Nightvision ......................................................................................................... 14
2.2.5
Spurhaltungsassistent ........................................................................................ 16
2.2.6
Kreuzungsassistent ............................................................................................ 17
2.2.7
Fußgänger und Radfahrerschutz ........................................................................ 18
2.2.8
Prädiktive Fahrdynamikregelung ........................................................................ 19
2.2.9
Weiterentwicklungen von umgebungserfassenden Assistenzsystemen ............. 19
3
Simulation.................................................................................................................... 22
3.1
Rapid Prototyping .................................................................................................. 22
3.1.1
Konzeptorientiertes Rapid Prototyping ............................................................... 24
3.1.2
Architekturorientiertes Rapid Prototyping ........................................................... 25
3.1.3
Implementierungsorientiertes Rapid Prototyping ................................................ 25
3.1.4
Bewertung .......................................................................................................... 26
3.1.5
In-the-loop-Simulation ........................................................................................ 26
3.1.5.1
Software-In-the-loop.................................................................................... 27
3.1.5.2
Hardware-In-the-loop .................................................................................. 28
3.1.6
3.2
Beispiel .............................................................................................................. 31
Verkehrliche Simulation ......................................................................................... 32
3.2.1
Grundlagen ........................................................................................................ 32
3.2.1.1
Makroskopische Simulationsmodelle........................................................... 33
3.2.1.2
Mikroskopische Simulationsmodelle ............................................................ 34
75941168
Inhalt
4
3.2.1.3
3.2.2
4
Submikroskopische Simulationsmodelle ..................................................... 34
Anforderung an die umgebungserfassende Simulation ...................................... 34
Produkte ...................................................................................................................... 37
4.1
MATLAB/SIMULINK/STATEFLOW ........................................................................ 37
4.1.1
Produktinformationen ......................................................................................... 37
4.1.2
Leistungsumfang ................................................................................................ 39
4.1.3
Ähnliche Produkte .............................................................................................. 39
4.2
PI AutoSim ............................................................................................................ 40
4.2.1
Produktinformationen ......................................................................................... 40
4.2.2
Leistungsumfang ................................................................................................ 41
4.3
dSpace .................................................................................................................. 41
4.3.1
Produktinformationen ......................................................................................... 41
4.3.2
Leistungsumfang ................................................................................................ 42
4.4
TESIS DYNAware.................................................................................................. 42
4.4.1
Produktinformationen ......................................................................................... 42
4.4.2
Leistungsumfang ................................................................................................ 43
4.5
AVL Cruise ............................................................................................................ 44
4.5.1
Produktinformationen ......................................................................................... 44
4.5.2
Leistungsumfang ................................................................................................ 45
4.6
MELROSE ............................................................................................................. 46
4.6.1
Produktinformationen ......................................................................................... 46
4.6.2
Leistungsumfang ................................................................................................ 46
4.7
ADAMS .................................................................................................................. 47
4.7.1
Produktinformationen ......................................................................................... 47
4.7.2
Leistungsumfang ................................................................................................ 48
4.8
SHIVA.................................................................................................................... 49
4.8.1
Produktinformationen ......................................................................................... 49
4.8.2
Leistungsumfang ................................................................................................ 50
75941168
Inhalt
5
4.9
PELOPS ................................................................................................................ 53
4.9.1
Produktinformationen ......................................................................................... 53
4.9.2
Leistungsumfang ................................................................................................ 55
4.10
LabCar................................................................................................................... 56
4.10.1
Produktinformationen...................................................................................... 56
4.10.2
Leistungsumfang ............................................................................................ 57
4.11
SIMPACK Automotive+ .......................................................................................... 58
4.11.1
Produktinformationen...................................................................................... 58
4.11.2
Leistungsumfang ............................................................................................ 59
5
Marktanalyse und Vergleich......................................................................................... 60
6
Zusammenfassung ...................................................................................................... 64
7
Literatur ....................................................................................................................... 66
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
6
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
1
Einleitung
Laut der Strukturdatenprognose wird sich die Einwohnerzahl der Bundesrepublik
Deutschland von 1997 bis 2015 von 82,1 auf 83,5 Millionen, also um ca. 2 % erhöhen.
Gleichzeitig wächst aufgrund der Altersstrukturverschiebung die Zahl der Einwohner über 18
Jahren, die so genannte fahrfähige Bevölkerung, um etwa 6 % - stärker als die
Einwohnerzahl. Der PKW-Bestand wächst in diesem Zeitraum von 41,4 auf 49,8 Millionen
PKW um 20,4 %. Die PKW-Dichte nimmt dabei von 504 auf 597 PKW/1000 Einwohner um
18,3 % zu. Die Verkehrsleistung, die die Straße zu tragen hat, steigert sich im
Personenverkehr von 833 Pkm/a im Jahr 1997 auf zwischen 861 und 993 Pkm/a und im
Güterverkehr von 236 tkm/a auf zwischen 353 und 422 tkm/a. Die Anzahl und Flächen der
Verkehrswege wird jedoch gleichzeitig aus politischen und finanziellen Gründen nicht in
diesem Umfang wachsen. Dies führt dazu, dass die Zahl der Staus in Deutschland weiter
steigen wird. Aus diesem Grund arbeitet die Automobilindustrie verstärkt an der Entwicklung
von Fahrerassistenzsystemen, um den Fahrer bei steigender physischer und psychischer
Belastung zu entlasten. [BMV03]
Um die Geschwindigkeit der Entwicklung zu erhöhen müssen neue Entwicklungsmethoden
genutzt werden. Im Zuge der Anwendung von Rapid-Prototyping-Methoden bei
Entwicklungsaufgaben werden vermehrt soft- und hardwarebasierte Simulationswerkzeuge
eingesetzt. Dies gilt auch für die Entwicklung von Fahrerassistenzsystemen. Der klassische
Ansatz, bei dem nur das Versuchsfahrzeug selbst simuliert wird, reicht hier nicht mehr aus,
da moderne Assistenzsysteme die Umgebung des Fahrzeugs erfassen und mit den
umgebenden Fahrer-Fahrzeug-Einheiten interagieren. Aus diesem Grund ist es notwendig,
dem zu testenden System auch Informationen zur Verfügung zu stellen, die diesen Bereich
abdecken.
Im folgenden sollen die kurz beschriebenen Sachverhalte genauer erläutert werden.
Außerdem werden zur Zeit verfügbare „In-the-loop“-Simulationswerkzeuge näher erläutert.
Insbesondere wird dabei herausgestellt, welcher Leistungsumfang im Bezug auf Art und
Umfang der simulierten Verkehrsumgebung geboten wird. Daran schließt sich eine
Aufstellung an, die zeigt, welches Werkzeug von welchem Hersteller genutzt wird.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
7
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
2
Fahrerassistenzsysteme
Abbildung 2-1: Einflussfaktoren bei einem modernen Automobil [DAR03]
Das bis vor einiger Zeit noch weitestgehend aus mechanischen Komponenten bestehende
“technische System Automobil“ steht vor einem fundamentalen Wandel. Die Elektronik im
KFZ hat immer mehr Einfluss auf innovative Entwicklungen. Sie ermöglicht neue
Funktionalitäten, sowohl in den Bereichen Antriebstechnik, Komfort und Kommunikation, als
auch in der Sicherheitstechnik. [AAK02]
Während passive Sicherheitssysteme das Ziel haben, Unfallfolgen zu reduzieren, sollen
aktive Sicherheitssysteme zusätzlich zur Unfallvermeidung beitragen.
Ein Ansatz der aktiven Sicherheit besteht in der Unterstützung des Fahrers bei der
Durchführung der Fahraufgaben. Durch eine Entlastung des Fahrers soll ein
Sicherheitsgewinn für ihn und weitere Verkehrsteilnehmer erreicht werden. Somit bilden
Fahrerassistenzsysteme einen wichtigen Einflussfaktor in einem modernen Automobil
(Abb.2-1).
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
8
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Die Aufgaben eines Fahrerassistenzsystems sind:

Den Fahrer bei seinen Fahraufgaben zu unterstützten

Die Schwächen des Menschen als Fahrer ausgleichen
Die Randbedingungen, die dabei zu beachten sind, sind zum einen, dass der Fahrer nicht
bevormundet werden darf und zum anderen, dass die letzte Entscheidung, und somit auch
die Verantwortung beim Fahrer bleibt.
Als erstes Assistenzsystem könnte man z. B. den Bremskraftverstärker oder die
Servolenkung nennen, die zunächst noch rein mechanisch waren. Heute umfasst dieser
Begriff zumeist elektronisch unterstützte Systeme. [WRE03]
2.1
Einteilung von Fahrerassistenzsystemen
Fahrerassistenzsysteme lassen sich auf verschiedene Weise einteilen, zum einen anhand
der Aufgaben, bei der der Fahrer unterstützt wird, und zum andere nach der Art der
Unterstützung. Die vom Fahrer durchzuführenden Aufgaben lassen sich in der Regel in drei
verschiedene Hauptgruppen unterteilen:

Navigation

Führung

Stabilisierung [VUK01]
Bei der Navigation wird die Fahrtroute innerhalb des bestehenden Straßennetzes festgelegt
und bis zum Ziel verfolgt. Die Festlegung der Route erfolgt meistens schon vor Fahrtantritt.
Dabei müssen verschiedene Dinge berücksichtigt werden. Es muss die Strategie festgelegt
werden, mit der das Ziel erreicht werden soll (schnell, sicher, einfach, kürzeste
Streckenlänge o. ä.), und die Randbedingungen müssen mit einbezogen werden. So sind
Kenntnisse über Geschwindigkeitsbegrenzungen, Knotenpunkte, Baustellen und ähnliches
erforderlich. Während der Fahrt ist dann darauf zu achten, der festgelegten Route zu folgen
und im Falle von geänderten Randbedingungen wie Straßensperrung oder Stau die Route
anzupassen. Beim Durchführen dieser Fahraufgaben sollen Navigationssysteme helfen.
Die Führung hat die Aufgabe der Realisierung der geplanten Fahrtroute. Die Fahrweise
muss dem wahrgenommenen Straßenverlauf und dem umgebenden Verkehr angepasst
werden. Somit zählen zur Gruppe Führung Teilaufgaben wie Spurhaltung, Folgefahren,
Überholen, Reaktion auf Verkehrszeichen. Man kann diese Gruppe in Längs- und
Querführung unterteilen. Ziel der Querführung ist es, dem Straßenverlauf zu folgen und
dabei den gewünschten Fahrstreifen festzulegen und auch einzuregeln. Die Längsführung
beinhaltet die Geschwindigkeitswahl. Diese wird hauptsächlich durch Verkehrsregelung und
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
9
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
den lokalen Verkehrszustand festgelegt. Der lokale Verkehrszustand beschreibt die
Wechselwirkung zwischen dem eigenen und den umgebenden Fahrzeugen. Von Bedeutung
ist dabei die Anpassung der Geschwindigkeit und des Abstandes zu dem Vorrausfahrenden.
Ein Beispiel für eine solche Unterstützung ist der Spurhaltungsassistent.
Bei der Stabilisierung findet die Umsetzung der Zielgrößen des Fahrerwunsches in Bezug
auf Quer- und Längsführung in der Fahrzeugbewegung statt. Die Stabilisierung enthält die
Umwandlung in die fahrzeugseitigen Stellgrößen wie Lenkbewegung, Gaspedal, Bremse und
Gangstellung. Es findet ein permanenter Abgleich zwischen Soll- und Istwerten von
Geschwindigkeit und Spur statt, um Abweichungen zu korrigieren, die z. B. durch Seitenwind
oder glatte Fahrbahn zustande kommen können. Übergeordnetes Ziel ist die Stabilität des
Fahrzustandes. Dieses bedeutet für den Fahrer die Vermeidung einer unkontrollierten
Eigendynamik des Fahrzeugs. Fahrdynamische Gegebenheiten, die durch Kopplung
zwischen Straße und Fahrzeug bestimmt werden, wirken als limitierender Faktor für die
Fahrerhandlung. Vorraussetzung für die Fahrerhandlung ist die Wahrnehmung der
Straßenoberfläche, des Straßenverlaufs und des aktuell eigenen Fahrzustandes. Die
bekanntesten Beispiele hierfür sind das ABS und das ESP/DSC. [GRI88]
Die zweite Möglichkeit der Einteilung von Fahrerassistenzsystemen nach der Art und Weise,
mit der der Fahrer unterstützt wird zeigt Abb. 2-2. In der ersten Phase, unterstützt das
System durch Information, wie z. B. durch Routenführung und Verkehrsinfo. In der zweiten
Phase gibt das System eine Warnung an den Fahrer, die ihm dabei helfen soll, eine
Entscheidung zu treffen, wie z. B. ein Kollisionswarnsystem oder es unterstützt den Fahrer
beim durchführen seiner Fahraufgaben wie z. B. das Adaptive Cruise Control System. In der
dritten Phase greift das System selbständig ein. Es hilft dem Fahrer beim Ausführen der
erforderlichen Maßnahmen, wie z. B. der Notbremsassistent oder das ABS.
Abbildung 2-2: Funktion von Fahrer und Assistenzsystem [AHS03]
Bei den zuvor beschriebenen Fahraufgaben stehen besonders die Stabilisierungs- und
Führungsebene in dynamischer Wechselwirkung mit der Umwelt. Der Fahrer nimmt Reize
auf und verarbeitet diese zu einer internen Repräsentation des Umfelds. Ähnlich wie der
Mensch wird das Fahrzeug der Zukunft sein Umfeld mit unterschiedlichen Sensoren
wahrnehmen und eine interne Repräsentation des Umfeldes ableiten. Nur so wird es möglich
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
10
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
sein, die Fahrsituation korrekt zu interpretieren und dem Fahrer die gewünschte
Unterstützung zu geben. [VUK01]
Abb. 2-3 zeigt, wie die Zukunft der aktiven Sicherheit aussehen könnte, und wie sie zum
automatisierten Fahren führt.
Abbildung 2-3: Zukunft der aktiven Sicherheit [TUB03]
2.2
Umgebungserfassende Assistenzsysteme
Umgebungserfassende Assistenzsysteme enden in ihrer Betrachtung nicht beim eigenen
Fahrzeug, sondern verarbeiten Informationen aus der Umgebung. Abb. 2-4 zeigt den Aufbau
einer Sensorerfassung mit einem Lasersensor zur Bestimmung des Abstands zum
Vorderfahrzeug und einem Sensor zur Bestimmung der eigenen Fahrgeschwindigkeit, wie
sie für ein ACC-Gerät eingesetzt werden kann (Kap. 2.1.2). Die folgenden Unterkapitel
zeigen Beispiele für Assistenzsysteme, die das Umfeld des Fahrzeugs erkennen und
bewerten.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
11
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 2-4: Sensorik [GLO03]
2.2.1
Parkassistent
Abbildung 2-5: Parkassistent [ZTR03]
Das zur Zeit am meißten verbreitete umgebungserfassende Assistenzsystem ist der
Parkassistent. Unter Parkassistenz versteht man ein System, welches mittels einer Sensorik
den Nahbereich von Fahrzeugen beobachtet, die Signale verarbeitet und dann den Fahrer
entweder informiert, vor kritischen Objekten warnt oder ihm Assistenz beim Einparken bzw.
langsamen Manövrieren gibt. Die zur Zeit auf dem Markt befindlichen Systeme werden
ausschließlich als Einpark- bzw. Rückfahrhilfen benützt, und verwenden entweder
Ultraschallsensoren (Abb. 2-6) oder Kamerasysteme. [GOT03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
12
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 2-6: Ultraschallsensoren [OFF03]
2.2.2
Adaptive Cruise Control
Das Adaptive Cruise Control System (ACC) ist ein Assistenzsystem, das den Fahrer in der
längsdynamischen Fahrzeugführung unterstützt. Das System stellt eine Weiterentwicklung
des konventionellen Tempomaten dar, der eine vom Fahrer eingestellte Geschwindigkeit
einregelt. Beim konventionellen Tempomaten muss der Fahrer jedoch eingreifen und das
System ausschalten, sobald auf seiner Spur ein langsameres Fahrzeug vor ihm erscheint.
Ein ACC kann ein solches Fahrzeug selbständig anhand von Abstandssensoren (meist
Radar oder Lidar) detektieren und dementsprechend die Fahrzeuggeschwindigkeit
verringern, so dass ein sicherer Abstand zu dem vorausfahrenden Fahrzeug eingehalten
wird. Bei Geschwindigkeitsänderungen des Vorderfahrzeugs werden die eigene
Geschwindigkeit und der Abstand entsprechend angepasst (Abb. 2-7).
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
13
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 2-7: ACC [IKA03]
Sobald das Vorderfahrzeug den beeinflussenden Bereich vor dem ACC-Fahrzeug verlässt,
beschleunigt das ACC auf die vom Fahrer eingestellte Geschwindigkeit. Dieses System ist
nicht im eigentlichen Sinne dazu konzipiert, die Sicherheit zu erhöhen, sondern vielmehr um
den Komfort durch Entlastung des Fahrers zu verbessern. Abb. 2-8 zeigt den prinzipiellen
Aufbau eines ACCs. Das Eingangssignal vom Sensor wird im RF (Radar Front) Signal
Prozessor ausgewertet mit Hilfe eines Kontroll- und eines Stellsignals. Der Signal Prozessor
sendet die errechneten Daten an den Controller, der wiederum den Motor und die Bremse
steuert. [WEI00]
Abbildung 2-8: Aufbau eines ACC [DAI03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
14
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
2.2.3
Stauassistent
Die Technologie, die bei ACC-Systemen genutzt wird soll in Zukunft auch im Stadtverkehr
oder Stadtnahem Bereich, wie auch bei Geschwindigkeiten bis zum Stillstand genutzt
werden. Er soll den Fahrer dabei unterstützen, das Fahrzeug in der Spur zu halten und den
Abstand zum Vordermann zu regeln. Besonders der Stau bietet mit seinem hohen Verbrauch
an Kraftstoff und Zeit ein großes Potential. Assistenzsysteme können nicht nur den Fahrer
bei ständigem Anfahren und Abbremsen unterstützen, sondern auch durch einen
gleichmäßigeren Verkehrsfluss und homogenere Fahrzeugabstände dabei helfen, den
Verkehr sicherer zu machen und den Stau schneller aufzulösen. Für diese Art der
Fahrerassistenz ist eine Leistungsstarke Sensorik notwendig, da das Fahrzeug sowohl den
Bereich vor sich, als auch den Bereich zu den Seiten detektieren muss. Auch
Fahrspurmarkierungen müssen Erkannt werden. Abb. 2-9 zeigt die Erkennungsbereiche, die
für den Stauassistenten notwendig sind. [INV03]
Abbildung 2-9: Stauassistent [INV03]
2.2.4
Nightvision
Bei Bosch wird ein System entwickelt, dass die Verbesserung der Nachtsicht zum Ziel hat.
Dazu wird die kurzwellige Infrarotstrahlung eines modifizierten Halogenscheiwerfers genutzt
der die Straße ausstrahlt. Außerdem wird das vor dem Fahrer liegende Blickfeld mit einer
Videokamera aufgezeichnet, die einen großen Bereich der Helligkeitsdynamik aufweist. Das
Bild wird auf die Scheibe projiziert und somit eine bessere Nachtsicht gewährleistet. Die
Fahrbahnmarkierungs- und Verkehrsschildererkennung sorgen zusätzlich für Sicherheit. Die
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
15
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Reichweite des Systems bei Nacht liegt bei über 100 Metern bei guten Sichtverhältnissen.
[EGE03]
Abb. 2-10 zeigt ein älteres System welches zur Zeit von Cadillac angeboten wird. Bei diesem
System, welches auch mit Infrarottechnologie arbeitet ist anders als bei dem System von
Bosch keine Fahrbahnmarkierungs- und Verkehrsschildererkennung eingebaut.
Abbildung 2-10: Night Vision [CAD03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
16
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
2.2.5
Spurhaltungsassistent
Abbildung 2-11: Aufbau eines Querführungsassistenten [SAN03]
Auf Basis der Sensorik des ACC können weitere Funktionen der Fahrerassistenz aufgebaut
werden. Neben der Längsdynamischen (z. B. ACC) kann auch die querdynamische
Fahrzeugführung mit einem Assistenzsystem unterstützt werden. Abb. 2-11 zeigt den groben
Aufbau eines solchen Systems. Anhand von Sensoren wird die Verkehrsumgebung erfasst,
und mit Hilfe eines Reglers das Lenkrad den Erfordernissen entsprechend gedreht. Abb. 212 zeigt die dafür notwendige Sensorik.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
17
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 2-12: Querführungsassistent [INV03]
In Europa geht die Entwicklung heute in Richtung infrastrukturabhängiger, autonomer
Spurhaltungssysteme zur querdynamischen Fahrzeugführung. Diese Systeme arbeiten mit
einer Bildauswertung, die aus den Fahrbahnmarkierungen die Krümmung und
Krümmungsänderung der Straße, die Spurbreite und den seitlichen Versatz des Fahrzeugs
zu den Begrenzungslinien in einem festgelegten Abstand vor dem Wagen bestimmt (Abb. 213). Aus diesen Größen sowie möglichen Störgrößen lässt sich der erforderliche Lenkwinkel
zur Spurhaltung ermitteln. Störgrößen sind unter anderem Seitenwind und geneigte
Fahrbahn. [INV03]
Abbildung 2-13: Fahrspurerkennung [HEL03]
2.2.6
Kreuzungsassistent
Aufgrund der oft hohen Komplexität der Verkehrssituation an Kreuzungen und der damit
verbundenen hohen Anforderung an den Fahrer, ereignen sich im Stadtverkehr an
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
18
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Kreuzungen
die
meisten
Unfälle
im
Straßenverkehr.
Daher
besitzen
Fahrerassistenzsysteme, die den Fahrer in diesem Bereich entlasten ein großes Potential.
Dieses soll mit Neuentwicklungen genutzt werden. Assistenzsysteme, die vor Rotüberfahrten
und Vorfahrtsmissachtung schützen bilden den Anfang. Anschließend werden diese
Systeme um Funktionen zur Vermeidung von Abbiegeunfällen erweitert, mit zusätzlichem
Blick zur Seite und auch mit Erfassung der anderen Verkehrsteilnehmer wie Radfahrer,
Fußgänger und Gegenverkehr. Bevor aktive Sicherheitssysteme eingreifen, müssen die
Assistenzsysteme schon bei der Kreuzungsannäherung dabei helfen, sich in der richtigen
Spur einzuordnen. Dies kann anhand digitaler Karten und Satellitenortung geschehen (Abb.
2-14). Gleichzeitig können Geschwindigkeitsbegrenzungen und gefährliche Kurven im
voraus erkannt werden. Außerdem ist beim Spurwechsel die Überwachung des Raums
hinter, neben und vor dem Fahrzeug notwendig. [INV03]
Abbildung 2-14: Satellitenortung [SAN03]
2.2.7
Fußgänger und Radfahrerschutz
Zum Schutz von Fußgängern und Radfahrern werden zur Zeit Lösungsansätze entwickelt.
Sicherheitssysteme in PKW und Nutzfahrzeugen warnen die schwächeren
Verkehrsteilnehmer in gefährlichen Situationen bei Unaufmerksamkeit des Fahrers. Diese
Warnung der Fußgänger und Radfahrer ist besonders nützlich, weil diese schneller
reagieren, also stehen bleiben oder ausweichen können. Durch Precrash- und
Kontaktsensoren sollen gleichzeitig Schutzmechanismen aktiviert werden, die die schwere
des Unfalls mindern wie z. B. reversibel ausfahrende Stoßfängersysteme und reversibel
ausfahrende flexible Motorhaube, die bei einem Aufprall eine Knautschzone für den
Fußgänger oder Radfahrer bilden (Abb. 2-15). [INV03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
19
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 2-15: Fußgängerschutz [INV03]
2.2.8
Prädiktive Fahrdynamikregelung
Die heute gängigen Fahrdynamikregelungen wie ESP oder DSC, die ausschließlich auf
Informationen über Fahrervorgaben, den aktuellen Bewegungszustand des Fahrzeugs sowie
das Kraftschlusspotential zwischen Reifen und Straße basieren sollen erweitert werden. Mit
Nutzung einer Umfeldsensorik können die bekannten Systeme erheblich verbessert werden.
Neben der Lenkbewegung des Fahrers wird die Lage des Fahrzeugs in der Spur mit
einbezogen. In Situationen, in denen der Fahrer Überfordert ist, sollen gezielte Brems und
Lenkeingriffe eine Unterstützung bei der Spurhaltung bieten und damit das Abkommen von
der Spur verhindern. In einem zweiten Schritt soll das System so erweitert werden, dass es
durch frühere Aktionen, etwa Abbremsen oder Anstellen des Fahrzeugs vor einer zu schnell
angefahrenen Kurve, das Fahrzeug gar nicht erst in den Grenzbereich kommt. [INV03]
2.2.9
Weiterentwicklungen von umgebungserfassenden Assistenzsystemen
Abb. 2-16 zeigt welche Neuentwicklungen bei umgebungserfassenden Assistenzsystemen
schon auf dem Markt zu bekommen sind. Neben der schon etwas länger bekannten
Einparkhilfe sind dies der Abstandsregelautomat und der Spurverlassenswarner. Die dafür
verwendeten Sensoren sind Kameras und Radar- und Ultraschallsensoren.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
20
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 2-16: Derzeitiger Stand von Fahrerassistenzsystemen [INV03]
Moderne Fahrerassistenzsysteme haben das Ziel, Unfälle im Straßenverkehr in Zukunft zu
vermeiden oder zumindest die Anzahl und Schwere zu verringern. Um den Weg zum
„unfallfreien
Fahren“
zu
ebnen,
sind
weitere
Neuentwicklungen
von
Fahrerassistenzsystemen notwendig. Die Realisierung derartiger Systeme erfordert die
konsequente Weiterentwicklung von Basistechnologien. Dazu zählt eine leistungsfähige
Sensorik zur Umgebungserfassung, die je nach Einsatzgebiet des Assistenzsystems den
Verkehrsraum vor, neben oder hinter dem eigenen Fahrzeug, aber auch den Innenraum des
eigenen Fahrzeugs erfassen und überwachen muss. Die rechnergestützte Auswertung der
Sensorinformation muss zu einem vorausschauenden Verständnis der Verkehrssituation
führen und in der Lage sein, diese zuverlässig darauf hin zu bewerten, ob ein Unfall droht.
Daneben wird eine klar verständliche Schnittstelle zum Fahrer, der nach wie vor die
Verantwortung für sein Fahrzeug hat, benötigt, um ihn auf drohende Gefahren hinzuweisen
und ihn effizient zu einem der Situation angemessenen Handeln zu bewegen.
Besonderes Augenmerk muss bei der Umsetzung solcher Systeme darauf gelegt werden,
dass sie nicht durch Fehlfunktion zu einer zusätzlichen Gefahrenquelle im Straßenverkehr
werden. Daher ist es wichtig, ein fehlerfrei funktionierendes Steuergerät zu besitzen.
[VOS03]
Drei Anforderungen werden an die Entwicklung neuer Automobilsteuergeräte für
Fahrerassistenzsysteme gestellt, so schnell wie möglich, so kostengünstig wie möglich und
so genau wie möglich. Die Entwicklung neuer Steuergeräte ist geprägt durch Globalisierung
und harten internationalen Wettbewerb. Zunehmende Funktionskomplexität, ständig
steigende Qualitätsanforderungen, ein vermehrter Einsatz miteinander Vernetzter
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
21
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Einzelgeräte sowie schärfere Auflagen durch den Gesetzgeber stehen der geringe Kosten
und kurze Entwicklungszeiten gegenüber. Dieser Gegensatz macht den Einsatz effizienter
Entwicklungswerkzeuge nötig. Hierbei nehmen computerunterstützte Berechnungs- und
Simulationsverfahren, allgemein als Computer Aided Engeneering (CAE) umschrieben, eine
Entscheidende Rolle ein. Die Hoffnungen auf zukünftige weitere Fortschritte im
Steuergeräte-Entwicklungsprozess sind eng geknüpft an die Leistungsfähigkeit von CAE
und integrative Prozesse. Die Grundlagen der Simulation im Automobilen Bereich sollen im
folgenden Kapitel näher erläutert werden. [BRE02]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
22
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
3
Simulation
Zur automobilen Simulation stehen verschiedene Simulationswerkzeuge zur Verfügung. Eine
wichtige Entwicklungsmethode ist das Rapid Prototyping. Aus der Bedeutung des Namens
lässt sich bereits schließen, dass es sich mit der schnellen Erstellung eines Prototypens
befasst.
3.1
Rapid Prototyping
Unter einem Prototyp wird in der Technik im Allgemeinen ein Produkt verstanden, dessen
Entwicklungsstand zwischen Entwurf und Massenherstellung liegt. Er stellt eine erste
funktionsfähige Einheit dar, die getestet werden kann. Um Aussagen über das fertige
Produkt ableiten zu können, muss sichergestellt sein, dass der Prototyp ein möglichst
genaues Abbild des fertigen Produktes ist. Während eine weitestgehende
Verhaltensübereinstimmung zwischen Prototyp und fertigem Produkt erzielt werden soll, gibt
es bei der Erstellung Unterschiede. Prototyp und fertiges Produkt können sich in der
Beschreibungsart, Programmcodegröße, Ein-/Ausgabehardware und äußerem Design
unterscheiden. Prototypen werden zielgerichtet auf Basis festgelegter Eigenschaften in Form
eines Anforderungskatalogs für die Ermöglichung bestimmter Untersuchungen entwickelt. Im
Bereich des Echtzeitsystementwurfs wird unter dem Begriff Rapid Prototyping eine Art der
Prototypenerzeugung verstanden, bei der bereits in den ersten Entwurfsphasen ein Prototyp
zur konzeptionellen Überprüfung elektronischer Systeme hergestellt wird. Durch Rapid
Prototyping wird ein Einsatz der erstellten Modellierung in der realen Umgebung ermöglicht.
Die frühzeitige konzeptionelle Überprüfung führt i. a. zu einer Verkürzung der
Entwicklungszeiten bei wachsender Konzeptsicherheit. Die Prototypen können hinsichtlich
ihrer Funktionalität und Leistungsfähigkeit untersucht werden und erlauben somit schnelle
Rückschlüsse auf die Richtigkeit und Vollständigkeit der Spezifikation. Zusätzlich wird die
Entwicklung verschiedener Varianten und der Vergleich unterschiedlicher Ansätze stark
vereinfacht und ein schnelles, iteratives Vorgehen beim Entwicklungsprozeß ermöglicht. Mit
Rapid Prototyping findet ein Übergang von der abstrakten Simulation der
Systemfunktionalität zu einem Test unter Einbeziehung der realen Umgebung und
Zeitanforderungen statt. Rapid Prototyping unterstützt dabei die folgenden Möglichkeiten:

Automatische Abbildung der Verhaltensspezifikation in ein ausführbares Programm
(Generierung eines Software–Prototypen).

Bereitstellung einer frei konfigurierbaren Hardwareplattform zur Ausführung des
Prototypen.

Bereitstellung von Analyse– und Meßverfahren zur Untersuchung des zeitlichen
Verhaltens des generierten Prototypen.

Bestimmung der Grenze zwischen Soft– und Hardware, d.h. nach Feststellung des
zeitlichen Verhaltens können Systemteile, die in Software implementiert waren, in
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
23
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Hardware implementiert werden und umgekehrt (dieses Spezialgebiet wird als
Hardware/Software Codesign bezeichnet).
Im Gegensatz zur Simulation der Systemfunktionalität, die in der Regel nicht in der realen
Zeit abgearbeitet wird, muss bei einer Einbettung des Prototyps in der realen Umgebung
außer der Systemfunktionalität auch die Echtzeitfähigkeit gewährleistet sein. Durch
entsprechende Analysemethoden kann das zeitliche Verhalten des Prototyps überprüft
werden. Stimmen sowohl Funktionalität als auch zeitliches Verhalten mit der geforderten
Spezifikation überein, kann der Entwickler in den nächsten Schritten eine weitere
Verfeinerung des Prototyps vornehmen. Können Funktionalität oder zeitliches Verhalten
nicht gewährleistet werden, muss ein Rücksprung zur Spezifikationsphase vollzogen werden.
Bei Rapid Prototyping entfällt im Gegensatz zur Simulation die Notwendigkeit, die
Systemumgebung für vollständige Betrachtungen zu modellieren. Diese Modellierung der
Systemumgebung kann unter Umständen (beispielsweise bei der Modellierung des
Kaltlaufverhaltens eines Verbrennungsmotors) sehr umfangreich werden und deswegen zu
einer vereinfachten Modellierung führen oder in Extremfällen überhaupt nicht erstellbar sein.
Insbesondere unvorhergesehene Störeinflüsse der realen Umgebung und Aspekte des
Echtzeitverhaltens bleiben in einer Simulation unberücksichtigt.
Abbildung 3-1: V-Modell [BUR00]
Ein Ansatz des Rapid Prototypings verwendet drei Phasen und geht auf Ratcliffe zurück.
Sein Vorschlag wird mit dem so genannten V-Modell (Abb. 3-1) in Verbindung gebracht. Der
traditionelle Entwurfsablauf nach dem V–Modell wird durch den Einsatz von Rapid
Prototyping auf mehreren Ebenen der Systementwicklung unterstützt und beschleunigt. Dies
kann anhand eines erweiterten V-Modells gezeigt werden, das mit VP-Modell bezeichnet
wird (Abb. 3-2).
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
24
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 3-2: VP-Modell [BUR00]
Beim VP-Modell werden drei Phasen des Rapid Prototyping unterschieden: das
konzeptorientierte, das architekturorientierte sowie das implementierungsorientierte Rapid
Prototyping. Da Zielsetzung und zeitliches Auftreten der drei Ansätze unterschiedlich sind,
wird jede Form des Rapid Prototypings in bestimmten Phasen des Systementwurfs
eingesetzt. Die drei Formen stehen somit nicht in Konkurrenz zueinander, sondern ergänzen
sich. [ETA03] [BUR00]
3.1.1
Konzeptorientiertes Rapid Prototyping
Auf der höchsten Ebene des VP–Modells wird das konzeptorientierte Rapid Prototyping
eingesetzt und dient hauptsächlich der Klärung der Systemziele. Es repräsentiert dabei die
schnelle Umwandlung einer ausführbaren Spezifikation mittels CASE-Werkzeuge in einen
funktionellen Prototyp. Die CASE-Werkzeuge (Computer Aided Software Engineering)
können nach einer Prüfung auf Konsistenz und Vollständigkeit aus der
Verhaltensbeschreibung des Modells Programmcode (z.B. C, C++, Ada, VHDL-AMS, etc.)
generieren. Der konfigurierte und kompilierte Software Prototyp wird danach auf einer
geeigneten Zielplattform zur Ausführung gebracht. Die Hardware des Rapid Prototyping
Systems besteht aus einem leistungsfähigen Rechner (Zielplattform), der mit geeigneten
Schnittstellen zur realen Umgebung ausgestattet ist. Die Schnittstellen müssen dabei einen
weiten Signalbereich abdecken können und modular erweiterbar sein. Die Kosten eines
konzeptorientierten Rapid Prototyping Systems sind nicht kritisch, da die Hardware für den
Aufbau von weiteren Prototypen verwendet werden kann und nicht auf einen Prototyp
begrenzt ist. Beim konzeptorientierten Rapid Prototyping steht ein schneller Systemaufbau
im Vordergrund. Stellt man bei der Ausführung des Systemmodells ein Fehlverhalten fest,
können in den CASE–Werkzeugen Änderungen der Spezifikation vorgenommen und
innerhalb weniger Minuten das geänderte Modell erneut getestet werden. Auch die
hardwareseitige Anpassung an die Systemumgebung muss unterstützt werden. Deswegen
sollten die Ein-/Ausgabeschnittstellen vom Bildschirm aus konfigurierbar sein und Ein/Ausgabehardware für die benötigten Signalbereiche vorliegen. Die Antwortzeiten heutiger
Rapid Prototyping Systeme liegt im Bereich weniger Millisekunden und darunter. Damit
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
25
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
eignet sich konzeptorientiertes Rapid Prototyping bereits für eine Vielzahl von
Anwendungen, beispielsweise für Entwicklung und Test von Innenraumelektronik oder
Getriebesteuerungen bei Automobilen. Um weitere Anwendungen miteinbeziehen zu
können, die Reaktionszeiten im Bereich von wenigen Mikrosekunden erfordern
(beispielsweise Motorsteuerungen) ist eine hohe Codeoptimierung notwendig. [KAR03]
[BUR00]
3.1.2
Architekturorientiertes Rapid Prototyping
Im Gegensatz zum konzeptorientierten Rapid Prototyping wird beim architekturorientierten
Rapid Prototyping bereits die Zielarchitektur des Systems berücksichtigt, um genauere
Aussagen über die endgültige Leistungsfähigkeit eines Systems vornehmen zu können.
Einige Komponenten des Systems wurden bereits entwickelt oder mittels
Standardkomponenten realisiert, während andere Teile sich noch im Test befinden. Dabei
können für die Evaluation Prozessor- oder Mikrocontrollerboards eingesetzt werden, die über
Schnittstellen mit der realen Umgebung kommunizieren und mit zusätzlicher meist
programmierbarer Hardware ausgestattet sind. Die Softwarekomponenten, die auf den
Prozessor- oder Mikrocontrollerboards eingesetzt werden, werden bereits auf schnelle
Reaktionszeiten und geringen Speicherbedarf hin optimiert, um den Anforderungen des
Zielsystems zu entsprechen. Das architekturorientierte Rapid Prototyping erreicht nicht die
kurzen Änderungszyklen des konzeptorientierten Rapid Prototypings, da die Partitionierung
und Synthese des Modells wesentlich mehr Zeit in Anspruch nehmen. Somit ist dieser
Ansatz weniger für eine Klärung der Systemziele geeignet, sondern dient der Überprüfung,
ob mit der beabsichtigten Zielplattform die Leistungsanforderungen erfüllt werden können.
Insbesondere bei den programmierbaren Bausteinen kann diese Überprüfung nur eine erste
Abschätzung darstellen. Durch die implementierungs-näheren Reaktionszeiten und die
größere Nähe zur endgültigen Realisierung besitzen die architekturorientierten Prototypen
eine höhere Aussagekraft über das zeitliche Verhalten des zu entwickelnden Systems im
Vergleich zum konzeptorientierten Rapid Prototyping. Dies wird um den Preis von längeren
Änderungszyklen und einer stärkeren Bindung an den zu erstellenden Prototypen erreicht.
[KAR03] [BUR00]
3.1.3
Implementierungsorientiertes Rapid Prototyping
Beim
implementierungsorientierten
Rapid
Prototyping
werden
leistungsfähige,
hochspezialisierte Prototypen erzeugt, die auf den expliziten Anwendungsfall zugeschnitten
sind und meist keine Wiederverwendung erlauben. Prototypen dieser Art dienen der
genauen Analyse der Leistungsfähigkeit eines Systems und bestehen oft aus nahe an der
endgültigen Systemrealisierung stehenden Prototypen oder bereits vorhandenen Systemen,
die um neue Teile erweitert wurden. Ein Prototypenaufbau auf dieser Ebene ist bereits seit
vielen Jahren ein fester Bestandteil des Systementwurfs. Dabei müssen die Systemziele und
die Systemstruktur bereits festliegen und Fragen der Realisierung und des Tests im
Vordergrund
stehen.
Der
zeitliche
Aufwand
zur
Generierung
von
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
26
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
implementierungsorientierten Prototypen ist vergleichsweise hoch. Ein Spezifikationsfehler in
dieser Phase verursacht bereits häufig einen erheblichen Änderungsaufwand des
Prototypen. [KAR03][BUR00]
3.1.4
Bewertung
Die Vorteile von Rapid Prototyping liegen in der Steigerung der Konzeptsicherheit und der
damit verbundenen Qualitätserhöhung sowie der Verkürzung von Entwicklungszeiten und
der Reduzierung von Entwicklungskosten. Dies wird durch schnelle Änderungszyklen
erreicht, die zusätzlich die Kreativität des Entwicklers unterstützen. Insbesondere das
konzeptorientierte Rapid Prototyping, das erst in den letzten Jahren von Firmen eingesetzt
wird, unterstützt diese Ziele. Jedoch ergibt erst ein abgestimmtes Vorgehen unter
Verwendung der Prototypen auf den weiteren Ebenen eine optimale Unterstützung des
Systementwurfs. Der Einsatz von Rapid Prototyping Systemen rentiert sich wegen der hohen
Kosten für Hard- und Software nicht bei der Entwicklung sehr kleiner, überschaubarer
Systeme. Es handelt sich vielmehr um eine Methode zur Verkürzung der Entwicklungszeiten
von komplexen Systemen. Rapid Prototyping Systeme können jedoch nicht in allen
Umgebungen eingesetzt werden. Beispielsweise bereitet die Kopplung an bewegte
Mikrosysteme, deren mechanisches Verhalten durch Anbindung an die Prototypenhardware
verändert wird, oder der Einsatz in Systemen mit schwierigen Umgebungsbedingungen (z.B.
hohe Luftfeuchtigkeit, hohe mechanische Belastung), starke Probleme. Ein weiteres Problem
besteht bei der Entwicklung von heterogenen Systemen, deren Teilsysteme oftmals von
unterschiedlichen Werkzeugen beschrieben werden. Die Zusammenführung der Ergebnisse
dieser Werkzeuge muss vom Anwender übernommen werden.
Trotz vieler Vorteile von Rapid Prototyping kommt auch diese Art der Entwicklung nicht ohne
Verifikation aus. Ein erstellter Prototyp kann erst nach eingehenden Tests zur Serienfreigabe
gelangen. Im automobilen Einsatzbereich währe es nahe liegend, einen entwickelten
Steuergerätealgorithmus direkt im Fahrzeug zu testen, also unter realen Bedingungen. Doch
bietet diese Form der Verifikation erhebliche Nachteile. Zum einen ist es sehr Zeit und
Kostenintensiv, das Steuergerät nach jedem Test auszubauen, zu optimieren und wieder
einzubauen, zum anderen sind Extremsituationen je nach Art des Steuergerätealgorithmus
oft nur schwer nachzustellen. Daher bietet sich die Verifikation durch Simulation an, wobei
besonders In-the-loop-Verfahren von großer Bedeutung sind.
3.1.5
In-the-loop-Simulation
„In-the-loop“-Verfahren
stellen
eine
Möglichkeit
zur
Verfügung,
einen
Steuergerätealgorithmus in einer der Realität nachgebildeten Simulationsumgebung zu
testen. Es existieren sog. Closed- und open-loop Verfahren. Bei Open-loop-Simulationen
findet kein Eingriff in den Prozeß statt, und somit kommt auch keine Rückkopplung über die
erzeugten Stellgrößen zustande. Dies ist bei der closed-loop-Simulation anders. Die
eingefügte Stellgröße hat Rückwirkungen durch die Kopplung im Regelkreis.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
27
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Bei den Testobjekten handelt es sich um rückgekoppelte Systeme, welche mit ihrer
Umgebung interagieren. Diese Interaktion bewirkt eine Verhaltensänderung der Umgebung.
Daher muss die Umgebung des Testobjektes (die Strecke) durch eine Simulation
nachgebildet werden. Die Umgebung einer Komponente besteht aus ihren Sensoren und
Aktoren, diese beeinflussen und erfassen ihrerseits die Module des Fahrzeugs wie den
Motor, das Getriebe, die Temperatur im Innenraum o. ä. Die möglichen In-the-loop-Verfahren
sollen im Folgenden näher erläutert werden. Dies sind zum einen die Hardware- und zum
anderen die Software-in-the-loop-Simulation.
3.1.5.1
Software-In-the-loop
Bei Software-in-the-Loop-Testsystemen präsentiert sich das Testobjekt als reine Software.
Die Software kann handgeschriebener Code sein, aus einem Modell generierter Code oder
auch ein mit Hilfe einer Simulationssoftware ausgeführtes Modell der späteren Komponente
oder des späteren Systems. Die Ausführung kann im allgemeinen Fall auf einem eigenen
Simulationsrechner erfolgen, oder aber auf demselben Rechner, der auch das
Umgebungsmodell rechnet.
Im Folgenden soll die Software-In-the-loop-Simulation anhand des Motorsteuergerätes
erklärt werden. Dabei wird nicht das Steuergerät selbst getestet, sondern nur der
Steuergerätealgorithmus.
Bei der Software-In-the-loop-Simulation wird zur Vorbereitung der Simulation der
Programmcode des zukünftigen Motorsteuergerätes in ein Abbild des RAMs und ein Abbild
des ROMs des Steuergerätes geladen. Diese Abbilder werden an den MikrocontrollerSimulator weitergegeben. Der Mikrocontroller-Simulator verarbeitet die erhaltenen Daten und
leitet sie an das simulierte Motormodell und an das simulierte Fahrzeugmodell weiter. Vom
Motor- und Fahrzeugmodell werden Ergebnisse an die Mensch/Maschine-Schnittstelle
(Workstation mit Monitor, Tastatur, Maus) und an den Mikrocontroller-Simulator abgegeben,
da die Ergebnisse diesen auch wieder direkt beeinflussen können. Die Applikation gibt neue
Daten kombiniert mit den Daten aus dem ROM-Abbild an den Mikrocontroller-Simulator ab,
während der Benutzer durch eine Eingabe Daten, die aus dem RAM-Abbild kommen,
beeinflusst (z. B. Werte anpassen, Fehler einbinden) und diese Daten dann auch wieder an
den Mikrocontroller-Simulator weitergegeben werden.
Bei der Software-In-the-loop-Simulation wird kein Prüfstand oder ein Steuergerät benutzt.
Man benutzt nur das, was der binäre Code enthält. Der binäre Code des Motorsteuergerätes
wird direkt auf einer Workstation ausgeführt. Dabei wird die gesamte materielle Umgebung in
der Workstation simuliert, und zwar im Wesentlichen der Mikrocontroller, in dem die Software
für das Motorsteuergerät nachher laufen muss. Möglich wird dies durch einen
Mikroprozessorsimulator, der bei Bedarf an den richtigen Mikrocontroller angepasst wird. Die
einzige Hardware, die in diesem Simulator vorkommt, ist die Hardware der Workstation und
die Mensch/Maschine Schnittstelle (Tastatur, Maus, Monitor).
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
28
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Nachdem der Befehlssatz und die internen Register des Mikrocontrollers in die Workstation
übertragen wurden, kann das Programm des Motorsteuergerätes, d. h. die Abbildung seines
ROMs, auf der Workstation ausgeführt werden.
Bei jeder Simulation kann zur Zeit nur eine Funktion der Steuergerätesoftware nachgebildet
werden. Dazu werden Teile des binären Codes, die nicht zu der nachgebildeten Funktion
gehören, manuell entfernt. Dabei ist darauf zu achten, dass nur Codeteile entfernt werden,
die das Verhalten der Funktion beim Simulieren im Vergleich zum echten Motorsteuergerät
nicht beeinflussen. Das Verhalten bei der Simulation muss also immer identisch sein mit dem
Verhalten des echten Motorsteuergerätes.
Vorteile der Software-In-the-loop-Methode:

Probleme wie bei der Hardware-In-the-loop-Methode wie z. B. physikalische
Anpassungen der Schnittstellen können vermieden werden.

Die Modelle, die im Hardware-In-the-loop-Simulator enthalten sind, können bei der
Software-In-the-loop-Methode verwendet werden.

Auf einer leistungsstarken Workstation kann ein genormter Testzyklus, der im
Hardware-In-the-loop-Simulator z. B. 20 Minuten benötigt, im beschleunigten
Zeitmodus in wenigen Sekunden durchgeführt werden.
Nachteile der Software-In-the-loop-Methode:

Die reale Hardware gehört nicht zur Regelstrecke.

Die Schnittstellen zwischen einzelnen Komponenten werden auch nur simuliert und
können daher nicht mitgetestet werden, wie es bei der Hardware-In-the-loop-Methode
der Fall ist.
[FKF03][HÜL03]
3.1.5.2
Hardware-In-the-loop
Unter dem Begriff Hardware-in-the-Loop versteht man die Verbindung von realem
Steuergerät und einer simulierten Umgebung. Das Ziel von Hardware-in-the-Loop besteht in
der Überprüfung realer Steuergeräte auf Konformität mit ihrer Spezifikation. Die Überprüfung
kann dabei beliebig oft wiederholt werden oder bestimmte Aspekte des Tests, z.B. eine
Grenzsituation, herausgegriffen werden, ohne dass Zeitaufwand und Kosten eines realen
Tests erreicht werden.
Hier soll die eigentliche Bedeutung des Begriffs Hardware-In-the-loop am Beispiel eines
Motorsteuergerätes erklärt werden.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
29
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Bei der Hardware-In-the-loop-Simulation wird ein als reale Hardware vorliegendes
Motorsteuergerät in eine Hardwareumgebung und eine Simulationsumgebung eingebunden
und getestet (Abb. 3-3). Das Motorsteuergerät dient zur Steuerung und Überwachung eines
Motors, der in diesem Beispiel in der Simulationsumgebung durch ein Softwaremodell
simuliert wird.
Abbildung 3-3: Hardware-In-the-loop [DUI03]
Der Hardware-In-the-loop-Simulator besteht aus

einer Simulationssoftware, die noch nicht vorhandene Steuergeräte bzw. Hardware in
einem Computer simulieren kann und

aus Hardware, die andere Steuergeräte und z. B. Bedienelemente zur Interaktion mit
der Simulationssoftware enthält. Diese Hardware ist an den Computer über
bestimmte Schnittstellen angeschlossen (Abb. 3-4). Zu dieser Hardware zählt auch
das zu prüfende Motorsteuergerät.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
30
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 3-4: Hardware-In-the-loop Prüfstand [DUI03]
Steht ein simuliertes Steuergerät bzw. simulierte Hardware als reale Hardware zur
Verfügung, kann sie bei Bedarf als Hardwarekomponente in die Hardwareumgebung
eingebunden werden. Die dazugehörigen Simulations-Module werden durch Ein-/Ausgänge
zu dem neu eingebundenen Steuergerät ersetzt. Anschließend durchläuft das
Motorsteuergerät eine neue Serie von Tests.
Nach und nach können so die simulierten Steuergeräte bzw. die simulierte Hardware wie z.
B. der Motor als echte Hardware in den Simulator eingebunden werden. Da die im
Hardware-In-the-loop-Simulator eingesetzte Verkabelung teilweise der später eingesetzten
Verkabelung entspricht, wird diese bei den Testläufen im Simulator schon im Vorfeld
mitgetestet. Dadurch ist es möglich, schon frühzeitig Steck- oder Kabelfehler und
Schnittstellenprobleme aufzudecken. Außerdem kann im Simulator z. B. eine
Leitungsunterbrechung erzeugt und das entstehende Systemverhalten analysiert werden.
Nach der Hardware-In-the-loop-Simulation kann das reale Motorsteuergerät ohne vorherige
Prüfstandsläufe, die ja durch die Simulation ersetzt werden konnten, in das reale Fahrzeug
übertragen werden. Dadurch kann zusätzlich Geld und Zeit gespart werden.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
31
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Danach kann z. B. das simulierte Fahrzeug-Modell des Laborautos im Hardware-In-the-loopSimulator mit den erfassten Werten des realen Fahrzeugs korrigiert werden. Unerwünschtes
Systemverhalten des realen Fahrzeugs kann dann im Labor erneut nachgefahren und
verbessert werden.
Die Hardware-In-the-loop-Technik ist hauptsächlich ein Werkzeug zur Überprüfung der
Gesamtfunktionalität des Motorsteuergerätes im Labor. Das zu überprüfende
Motorsteuergerät muss dazu in eine Simulationsumgebung eingebunden werden. Diese
Simulationsumgebung entspricht einem Echtzeitmodell der realen Umgebung, zu der auch
der Motor gehört.
Das heißt, dass das Modell einer Hardware in der Simulation nahezu das gleiche
Zeitverhalten wie die reale Hardware hat. Existiert in der realen Hardware z. B. eine
Verzögerungskonstante, muss diese in dem Modell berücksichtigt werden. Das Modell
entspricht einem wirklichkeitsgetreuen Abbild der realen Hardware.
Ein Steuergerät durchläuft auf seinem Weg zur Serienreife eine Vielzahl von Test- und
Entwicklungsstufen. Dieser Prozess soll im Folgenden beispielhaft gezeigt werden.
3.1.6
Beispiel
Abb. 3-5 zeigt den Steuergeräteentwicklungsprozess. Dazu werden zunächst ein Fahrzeugund ein Steuergerätemodell benötigt. Das Steuergerätemodell wird mit Hilfe von Rapid
Prototyping Methoden erstellt. Für das Fahrzeugmodell werden Simulationssoftwares
benutzt, die in Kap. 4 genauer beschrieben werden. Der Funktionsnachweis wird im
Allgemeinen mit Software-In-the-loop-Simulation erbracht. Danach wird geprüft, ob sich das
Steuergerätemodell auf das reale Fahrzeug übertragen lässt. Ist dies der Fall, so wird das
Steuergerätemodell auf ein reales Steuergerät übertragen. Dann wird im Hardware-In-theloop-Verfahren mit Hilfe des Fahrzeugmodells das reale Steuergerät überprüft. Wird der
Zielsoftware- und Schnittstellennachweis erbracht, so kann das Steuergerät in das reale
Fahrzeug integriert werden.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
32
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 3-5: Steuergeräteentwicklungsprozess [DUI03]
Diese Entwicklungsphase kann je nach Steuergerät viel Zeit in Anspruch nehmen und hohe
Anforderungen an die Simulationsumgebung stellen. Besonders die Entwicklung
umgebungserfassender Assistenzsysteme zur Fahrzeugführung machen komplexe
Programme notwendig.
3.2
Verkehrliche Simulation
Anders als für die Stabilisierung und Orientierung reichen die herkömmlichen
Simulationsmodelle, bei denen nur das Versuchsfahrzeug simuliert wurde nicht aus, da auch
die Interaktion zwischen Fahrzeugen von Bedeutung ist. Somit werden neue
Simulationsmodelle benötigt.
3.2.1
Grundlagen
Zum Test von Fahrerassistenzsystemen wie dem ACC sind Simulationsprogramme
erforderlich, die den Verkehrsfluss auf den Verkehrswegen in seiner Dynamik beschreiben.
Je nach Zweck des Modells und der zugrunde liegenden Anwendung sind diese
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
33
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Simulationsprogramme sehr unterschiedlich. Aus diesem Grund unterscheidet man
verschiedene Klassen. Dabei hat sich eine auf die Modellauflösung bezogene Einteilung
allgemein als sinnvoll herausgestellt. [WEI00]
Man unterscheidet makroskopische, mikroskopische und submikroskopische Modelle.
Abb. 3-6 gibt einen Überblick über die einzelnen Modellklassen.
Bezeichnung
Modellansatz
typ. Größen
Schrittweite
der
Berechnung
makroskopisch
Kontinuumstheorie
Verkehrsstärke,
Verkehrsdichte, mittlere
Geschwindigkeit
10 s
Routenumlegung,
Linienbeeinflussung,
Zuflussbeschränkung
1s
Knotenpunkte, lokale
Engpässe,
Kolonnenverhalten,
Spurverteilungen,
Fahrerbeeinflussung
<0,1 s
Antriebsstrangauslegung,
Verbrauchsaussagen
mikroskopisch
Fahrer-Fahrzeug-Einheit,
Fahrzeug mit
Geschwindigkeits- und
statistischen
Wegverläufe, Zeitlücken
Eigenschaften,
Folgemodell des Fahrers
detaillierte Abbildung des Geschwindigkeitverläufe,
submikroskopisch
Fahrers oder des
Motorbetriebspunkte,
Fahrzeugs
Kraftstoffverbrauch
Anwendungsbeispiel
Abbildung 3-6: Klassifizierung von Simulationsmodellen [WEI00]
3.2.1.1
Makroskopische Simulationsmodelle
Beim makroskopischen Simulationsmodell wird nicht das Verhalten von einzelnen
Fahrzeugen beschrieben, sondern immer eine Menge von Fahrzeugen. Mit der
Kontinuumstheorie werden zeitdiskrete Differentialgleichungen für die Änderung typischer
Kenngrößen des Verkehrs eingesetzt. Dies sind die Verkehrsstärke (Zahl der einen lokalen
Querschnitt passierenden Fahrzeuge pro Zeitabschnitt), die Verkehrsdichte (Anzahl der
Fahrzeuge in einem Streckenabschnitt) und die mittlere Geschwindigkeit. Durch Kombination
einzelner Streckenabschnitte ist damit die Untersuchung vernetzter Verkehrsströme möglich.
Ermittlung der Streckenauslastung und das Erstellen einer Verkehrsprognose bei
Zuflussbeschränkungen, Linienbeeinflussungsanlagen oder Umleitungsempfehlungen sind
typische Anwendungsgebiete. [BRA97] [WIL97]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
34
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
3.2.1.2
Mikroskopische Simulationsmodelle
Die Grundlage der Simulation ist die Mensch-Fahrzeug-Einheit. Um die hauptsächlich vom
Fahrer beeinflusste Interaktion zwischen den einzelnen Elementen abzubilden, wurden
verschiedene Folgemodelle erstellt. Das Aufeinanderwirken der einzelnen Fahrer-FahrzeugEinheiten beschreibt den gesamten Verkehrsablauf. Die entwickelten Folgemodelle
unterscheiden sich in drei Klassen, deterministische, reglungstechnische und psychophysische Modelle. Beim deterministischen Modell geht man davon aus, dass alle
Fahrzeuge
eine
vom
Abstand
abhängige
Geschwindigkeit
fahren.
Beim
regelungstechnischen Modell wird der Fahrer als Regler gesehen, der in Abhängigkeit von
den Eingangsgrößen wie z. B. eigene Geschwindigkeit und Geschwindigkeit des
Führungsfahrzeugs die Ausgangsgrößen wie Gas- und Bremspedalstellung regelt. Die
überwiegende Zahl der mikroskopischen Simulationsmodelle sind die psycho-physischen
Folgemodelle. Der Abstand zum Vorausfahrenden und die Differenzgeschwindigkeit sorgen
für eine Reaktion des Fahrers in Form von Beschleunigung. Die Situationserkennung und die
Reaktion sind dabei vom Fahrertypen individuell abhängig. Für ein zuverlässiges Modell wird
eine Vielzahl von zufallsabhängigen Fahrerparametern benutzt.
Mikroskopische Modelle werden zumeist für die Analyse der Interaktion zwischen einzelnen
Fahrer-Fahrzeug-Elementen
und
der
lokalen
Fahrzeugverteilung
verwendet.
Anwendungsbeispiele sind das Verhalten an Knotenpunkten oder örtlichen Engpässe, die
Verteilung der einzelnen Fahrzeuge auf den Fahrspuren oder das Kolonnenverhalten unter
spezifischen Randbedingungen. Des Weiteren können Verkehrsablaufanalysen bei
verschiedenen Fahrbeeinflussungen erstellt werden. [BRA97] [WIL97]
3.2.1.3
Submikroskopische Simulationsmodelle
Sie besitzen die größte Modellierungstiefe. Diese betrifft im Allgemeinen die FahrerFahrzeug-Einheit. Trotz des größeren Detaillierungsgrades im Bezug auf das Fahrverhalten
(z. B. Abbildung der wirkenden Lenkkräfte, feinere zeitliche Aufteilung der Fußkräfte beim
Gasgeben und Bremsen etc., die aufgrund der geringen Schrittweite gewährleistet werden
können) beziehen sich diese Modelle bisher nur auf die genauere Abbildung des Fahrzeugs.
Im Gegensatz zu den mikroskopischen Modellen, in denen das Fahrzeug bestimmte
statistisch verteilte Eigenschaften besitzt und dessen Zustand deterministisch beschrieben
werden kann, wird das Fahrzeug in der submikroskopischen Simulation unter Verwendung
von Kennfeldern auch mit Nichtlinearitäten dargestellt. Neben einer Abschätzung von
Aspekten des Verkehrsablaufs erlauben diese Modelle auch eine fahrerbezogene
Untersuchung und Optimierung, z. B. im Hinblick auf Kraftstoffverbrauch und Emissionen
oder Antriebsstrangauslegung. [BRA97] [WIL97]
3.2.2
Anforderung an die umgebungserfassende Simulation
Zur Simulation eignen sich prinzipiell nur mikroskopische oder submikroskopische Modelle,
da abhängig vom Anwendungsbereich der Grad der Modellierungstiefe entscheidend ist.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
35
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Wichtig ist, dass die Umgebung des Fahrzeugs, die der Verkehr darstellt, wirklichkeitsgetreu
nachgebildet wird. Voraussetzung ist, dass jede Fahrer-Fahrzeugeinheit kalibriert ist. Um
eine höchstmögliche Genauigkeit zu erzielen und die Möglichkeit zur Optimierung des
Systems zu haben, gibt es eine Vielzahl von Eigenschaften, die eine solche Simulation
erfüllen muss.
Abbildung 3-7: Anforderung an die ACC-Simulation [WEI00]
Zentrales Element ist der reale Algorithmus des Steuergerätes. Nur wenn dieser technisch
einsetzbar und fahrbar ist, lassen sich korrekte Aussagen über die Auswirkungen auf den
Verkehrsablauf treffen. Besonders einzelne Fahrsituationen müssen genau dargestellt
werden. Sie dürfen nicht zu sehr vereinfacht werden, da sonst wichtige Verhaltensweisen
von Reglern wie z. B. Aufschaukeln bei Annäherung innerhalb einer Kolonne und die damit
verbundene Verkehrsbeeinflussung verloren ginge. Eine weitere Anforderung an die
Simulationsumgebung des Reglers ist die Taktung. Ein Zeittakt der Simulation darf nicht
größer als ein Takt des Reglers sein, da dieser sonst nicht der Realität entsprechende
Sprünge als Eingangsdaten bekommen würde. Der reale Algorithmus interagiert mit dem
Fahrzeug, der Umwelt, den Sensoren und dem Fahrer (Abb. 3-7).
Der Regler wirkt auf das Fahrzeug und damit auch wieder auf die Simulationsumgebung.
Daher ist es erforderlich, dass das Fahrzeug nicht mikroskopisch, sondern submikroskopisch
mit seinem Antriebsstrang, der Aktuatorik und den Fahrwiderständen abgebildet wird. Ein
mikroskopisches Modell wäre
insbesondere im Hinblick auf Zeitverzögerungen bei
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
36
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Beschleunigungsvorgängen - zu ungenau. Eine besondere Art der Simulationstechnik ist
daher für den Regler erforderlich. Viele Verbrauchsberechnungen erfolgen heute noch nach
dem Wirkung-Ursache-Prinzip, bei dem von den Fahrwiderständen über die
Antriebsstrangübersetzung auf Drosselklappen- bzw. Bremspedalstellung zurückgerechnet
wird. Diese Art der Simulation ist für diesen Anwendungsbereich nicht ausreichend. Eine
andere Art der Simulation, die nach dem Ursache-Wirkung-Prinzip arbeitet, muss daher
eingesetzt werden. Dabei wird von der Drosselklappen- und Bremspedalstellung aus die
Antriebskraft am Rad bestimmt wird und diese mit den Fahrwiderständen bilanziert.
Des Weiteren muss die Umwelt, also Kurvigkeit der Strecke und damit die Möglichkeit des
Zielverlustes und die Verkehrssituation, genau abgebildet sein. Neben der realistischen
Simulation der Verkehrssituation gibt es eine weitere wichtige Voraussetzung, die fordert,
dass die Beschleunigungen der vorausfahrenden Fahrzeuge stetig, also realistisch, sein
muss, da nur so korrekte Eingangswerte erreicht werden können und das Verhalten
wirklichkeitsgetreu untersucht werden kann.
Im Hinblick auf die Interaktion zwischen Regler und Sensor müssen neben der Verarbeitung
der Ausgangsdaten auch die Eingangsdaten in entsprechender Form zur Verfügung gestellt
werden. Um eine hohe Genauigkeit zu erzielen, genügt es nicht, das relevante Zielobjekt mit
seinem Abstand und seiner Relativgeschwindigkeit vorzugeben. Es müssen
Sensoreigenschaften berücksichtigt werden. Dabei müssen die Geometrie und die
Erfassungszeit des Sensors berücksichtigt werden. Bspw. kann ein Sensor bei einem
Spurwechsel des vorausfahrenden Fahrzeugs dieses erst erfassen, wenn es im
Erfassungsbereich des Sensors liegt. Außerdem muss die Zeit, die der Sensor benötigt, um
ein Fahrzeug zu erkennen, berücksichtigt werden. Nach einer Simulation können die
Sensoren weiter optimiert werden, um die Erfassung weiter zu verbessern. Auch Zeittakte
von Sensor und Regler müssen wieder aufeinander abgestimmt werden.
Auch der Fahrer muss simuliert werden - im Hinblick darauf, wie er das Assistenzsystem
nutzt, wann er es ein- oder ausschaltet. Die Grenzen der Übernahme müssen daher ermittelt
werden. Um das Assistenzsystem komfortabel auszulegen, muss die Häufigkeit der
Fahrerübernahme bestimmt werden. [PEL03] [WEI00]
Auf dem Markt befindet sich eine Vielzahl von Produkten, die sich mit automobiler In-theloop-Simulation befassen. Diese sollen im Folgenden beschrieben werden.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
37
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
4
Produkte
In diesem Kapitel sollen die Werkzeuge für die Simulation von Fahrerassistenzsystemen
vorgestellt werden. Manche sind direkt für solche Simulationen ausgelegt, andere sind nicht
nur für dieses Einsatzgebiet konzipiert, eignen sich aber trotzdem. Die Komplexität dieser
Werkzeuge hängt von ihrem Einsatzgebiet ab. Diese ist am höchsten bei Tools für
umgebungserfassende Assistenzsysteme. Im Folgenden werden diese Produkte genauer
betrachtet, und es wird dabei herausgestellt, welcher Leistungsumfang im Bezug auf die
Simulation von umgebungserfassenden Assistenzsysteme und besonders auf Art und
Umfang der simulierten Verkehrsumgebung geboten wird.
4.1
4.1.1
MATLAB/SIMULINK/STATEFLOW
Produktinformationen
MATLAB/SIMULINK/STATEFLOW wurden von TheMathworks entwickelt. Das Unternehmen
besteht seit 1984 und beschäftigt mehr als 1000 Mitarbeiter. MATLAB eignet sich zur
Bearbeitung eines weiten Feldes von rechenintensiven wissenschaftlichen und technischen
Aufgaben von der Datenerfassung und -analyse bis hin zur Entwicklung von Anwendungen.
In der MATLAB-Umgebung sind mathematische Berechnungen, Visualisierung und eine
technische Programmiersprache vereint. Die eingebauten Schnittstellen machen den
schnellen Zugriff und Import von Daten aus Dateien, externen Datenbanken und
Programmen und von Instrumenten möglich. Außerdem kann man Programme in den
Sprachen C, C++, FORTRAN und Java in seine MATLAB-Anwendungen einbetten.
Abb. 4-1 zeigt die Oberfläche von Matlab.
Abbildung 4-1: Matlab-Oberfläche
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
38
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
SIMULINK ist ein interaktives Tool zur Modellierung, Simulation und Analyse. Mit SIMULINK
können Diagramme erstellt, das Systemverhalten simuliert, Leistungsdaten bestimmt und
Entwürfe verfeinert werden. SIMULINK fügt sich in MATLAB ein, wodurch es den
unmittelbaren Zugriff auf eine umfangreiche Sammlung von Analyse- und EntwicklungsTools gestattet. (Abb. 4-2).
Abbildung 4-2: Simulink-Oberfläche
Stateflow ist ein interaktives Entwicklungs-Tool zur Modellierung und Simulation
ereignisgesteuerter Systeme. Es ist in Simulink und MATLAB integriert. Durch die
Kombination von grafischer Modellentwicklung und animierter Simulation sorgt Stateflow für
eine engere Verbindung zwischen der Systemspezifikation und der Systementwicklung. Abb.
4-3 zeigt den Aufbau eines Stateflow Diagramms. Die Produkte wurden von The MathWorks
entwickelt. [MAT03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
39
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 4-3: Stateflow-Diagramm [MAT03]
4.1.2
Leistungsumfang
MATLAB/SIMULINK/STATEFLOW bildet oft die Grundlage zur Erstellung von In-the-loopSimulationswerkzeugen. Dieses Tool ist nicht speziell für automobile Simulationen gedacht.
Es wird in verschiedenen Bereichen wie bspw. der Biologie, Luft- und Raumfahrt, Medizin,
Mechanik oder der Elektrotechnik eingesetzt und bietet daher keine Automobil-Modelle.
Diese müssen selbst erstellt werden. Reglungstechnische und mathematische Modelle
dienen dabei als Grundlage. Beispielsweise können Kennfelder für Motoren oder
Feder/Dämpfersysteme erstellt werden. Gleiches gilt für die Umgebungssimulation. Es wird
sowohl für Hardware-, als auch für Software-in-the-loop-Anwendungen verwendet. Es wird
jedoch keine eigene echtzeitfähige Hardware angeboten. Diese muss für die Hardware-inthe-loop-Simulation von anderen Anbietern bereitgestellt werden.
4.1.3
Ähnliche Produkte
Neben MATLAB/SIMULINK/Stateflow gibt es ähnliche Produkte, die ebenfalls nur als
Grundlage für komplexe In-the-loop-Simulationen genutzt werden können, aber auch nicht
speziell für diesen Einsatzbereich entwickelt wurden. Zu diesen Produkten zählen bspw.
Statemate Magnum und MatrixX.
Statemate MAGNUM von I-Logix ist ein Software-Tool zur Entwicklung von Soft- und
Hardware-Systemen mit hoher Komplexität und Dynamik wie z. B. Steuerungen,
Echtzeitsysteme oder auch Prüf- und Regeltechnik. Es unterstützt nicht nur bei Analysen und
Spezifikationen, sondern auch beim Entwurf, der Codegenerierung, dem Test und der
Dokumentation. Bei Software-Systemen generiert Statemate MAGNUM eine geprüfte,
hochwertige Spezifikation durch Modellbildung, Simulation und Tests. Durch Prototyping wird
die Bedienschnittstelle grafisch und maussensitiv dargestellt. Genauso wird das
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
40
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Bedienpaneel ohne Programmierung an das Modell angebunden, wobei der portierbare Coder Ada-Code automatisch vom Modell generiert wird. Statemate MAGNUM erstellt
überwiegend grafische Systemmodelle mit Beschreibung von Funktion, Systemstruktur und
Verhalten, aus denen ein vollständiger Code erzeugt wird. Die Bedienschnittstellen
(Paneele) werden ebenfalls grafisch dargestellt, Verifikation und Validation erfolgen durch
interaktive Simulation. Das Software-Tool ist durch Schnittstellen offen für andere Produkte
wie z. B. DOORS oder RTM. Die Projektdokumentation wird direkt in Statemate MAGNUM
erstellt. Auch dieses Tool findet Einsatz in verschiedenen Bereichen, ebenso wie
MATLAB/SIMULINK/STATEFLOW.
Mit den Entwicklungswerkzeugen Xmath, SystemBuild, AutoCode, and DocumentIt bietet
MATRIXx eine vollständige Lösung zur mathematischen Analyse, Modellierung, Control
Design, automatischen Codegenerierung und Dokumentation. Außerdem bieten zahlreiche
Add-On-Module die Möglichkeit, das Programm zu erweitern. Es wird in verschiedenen
Bereichen eingesetzt; dazu zählen die Bereiche Automobil, Luft- und Raumfahrt,
Verteidigung und Prozessüberwachung.
4.2
PI AutoSim
4.2.1
Produktinformationen
PI AutoSim, ein Entwicklungswerkzeug der Ford Motor Company, besteht aus zwei Teilen,
zum einen dem Controlling-PC und zum anderen der Input/Output-Einheit, auf der die Realtime-Simulation läuft und die das Ein- und Ausgangssignal steuert. Die beiden Einheiten sind
über Ethernet verbunden (Abb. 4-4).
Abbildung 4-4: PI AutoSim-Aufbau
PI AutoSim benutzt MATLAB/SIMULINK- oder C/C++-Modelle. Die Eingangswerte, die in
das Steuergerät geführt werden, werden von der Input/Output-Einheit in Signale
umgewandelt, die das Steuergerät verarbeiten kann. Ein solcher Eingabewert kann bspw.
die Drosselklappenstellung sein. Gleichzeitig ist die Input/Output-Einheit dazu in der Lage,
Ausgangssignale des Steuergerätes, wie Einspritzzeit oder Einspritzdruck, aufzunehmen und
diese in Daten umzuwandeln, die der Controlling-PC verarbeiten kann. Es können damit
komplexe Testläufe durchgeführt werden. Die Ergebnisse der Testläufe werden in einem
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
41
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Script festgehalten. Dies kann sowohl unter Benutzung der Eingangsprogrammiersprache,
als auch in C/C++ sein. [PIA03]
4.2.2
Leistungsumfang
PI AutoSim ist nur zur Verbindung vorhandener Simulation mit dem Steuergerät, also zum
Hardware-In-the-loop-Test gedacht. Es besitzt kein eigenes Tool zur Erstellung von
Simulationsumgebungen, sondern stellt lediglich die echtzeitfähige Hardware zur Verfügung.
[PIA03]
4.3
4.3.1
dSpace
Produktinformationen
dSPACE bietet eine durchgängige und vollständig integrierte Entwicklungsumgebung für
Bereiche wie Antriebsstrang, Fahrwerk und Komfort. Mit Modellierungstools wie
MATLAB/Simulink können Funktionen entworfen werden und zunächst in der OfflineSimulation validiert werden. Diese Modelle sind die Basis für alle folgenden
Entwicklungsschritte. Der dSPACE Prototyper ist ein flexibles Entwicklungssystem, mit dem
Regler-Entwürfe ohne Programmierung direkt aus Simulink-Modellen an der realen Strecke
ausprobiert und bereits vorhandene Regler über Bypass integriert werden können. DesignFehler werden dadurch sofort gefunden, und Korrekturen können unmittelbar durchgeführt
werden. Die zunehmende Komplexität von Software und Elektronik in Steuergeräten
erfordert ausführliche Tests während der Entwicklung. Mit dSPACE Simulator können fertige
Steuergeräte-Prototypen zuverlässig getestet werden. dSPACE Simulator ersetzt die echte
Umgebung durch ein simuliertes Szenario, wodurch aufwendige oder gefährliche Testläufe
auf der Straße weitestgehend vermieden werden können. Durch Testautomatisierung
werden die Versuche systematisch und reproduzierbar und viele Tests werden durch
Simulation überhaupt erst möglich. dSpace bietet die Verwaltung von Experimenten,
Instrumentierung und 3-D Visualisierung (Abb. 4-5) und teilweise oder vollständige
Automatisierung. [DSP03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
42
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 4-5: dSpace Visualisierung [DSP03]
4.3.2
Leistungsumfang
dSpace bietet keine eigenen Simulationsmodelle an, sondern verwaltet nur andere Modelle.
Diese Modelle sind mit dem Entwicklungstool MATLAB/SIMULINK zu erstellen. Damit
können einzelne Komponenten des Fahrzeugs nachgebildet werden und anschließend das
Steuergerät im Hardware-In-the-loop-Verfahren getestet werden. Dazu bietet dSpace das
Simulationsboard an, mit dem das Steuergerät mit der Simulationsumgebung verbunden
werden kann. Auch die Möglichkeiten im Bezug auf die Umgebungssimulation sind allein
abhängig von den Möglichkeiten der verwendeten Modelle. [DSP03]
4.4
4.4.1
TESIS DYNAware
Produktinformationen
TESIS DYNAware eignet sich für die Echtzeitsimulation eines virtuellen Fahrzeugs. Mit den
zwei Tools ve-DYNA und en-DYNA lassen sich Steuerung und einzelne Komponenten unter
realitätsnahen Bedingungen testen. Es besteht die Möglichkeit, offline zu arbeiten oder im
Hardware-In-the-loop-Prüfstand.
Das Motorsimulationswerkzeug en-DYNA berechnet Drehmoment und Drehzahl zum Test
von Steuergerätealgorithmen, die die Drehunförmigkeit analysieren. Dazu stehen fertig
konfigurierte Standard-Motormodelle zur Verfügung. Mit Hilfe der en-DYNA-SIMULINK
Bibliothek ist es möglich, fast alle Motorkonfigurationen abzurufen. Mit diversen
Beispielskripten für Fahrmanöver können verschiedene Lastkurven abgefahren werden oder
Motormesswerte mit den Simulationsergebnissen verglichen werden.
Ve-DYNA simuliert Fahrwerke. Dabei kann man auf vorhandene Modelle von Fahrzeugen
wie z. B. Klein- oder Mittelklassewagen, Formel 1-Autos oder Zugfahrzeuge mit Anhänger
zurückgreifen. Das Programm läuft über ein einziges SIMULINK-Modell. Mit Hilfe des ve75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
43
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
DYNA GUIs können damit eine unbegrenzte Anzahl von Fahrzeugkonfigurationen erstellt
werden. Teile des ve-DYNA-Modells können durch benutzerdefinierte Simulink- Modelle
ersetzt werden. Dieser modulare Aufbau führt dazu, dass das Modell eine große
Individualisierungsmöglichkeit bietet.
Abbildung 4-6: TESIS DYNAware [TES03]
Als zusätzliche Option wird noch eine Simulation für hydraulische Bremsen angeboten. Für
die Hardware-In-the-loop-Simulation wird das Echtzeit-Simulations-Board dSpace DS 1005
(vgl. Kap. 4.3) zur Verbindung mit dem Steuergerät benötigt. Dabei werden
Ausführungszeiten von weniger als einer Millisekunde erreicht. [TES03]
4.4.2
Leistungsumfang
Wie zuvor bereits beschrieben, ist TESIS DYNAware ein Tool zur Simulation eines virtuellen
Fahrzeugs. Dabei können Fahrwerk und Motor simuliert werden. Außerdem gibt es ein Tool
zur Simulation hydraulischer Bremsen. Es stehen vorgefertigte Modelle zur Verfügung, es
können aber auch eigene Modelle anhand von Kennfeldern erstellt werden. TESIS
DYNAware ist auf SIMULINK aufgebaut. Daher können selbst erstellte Kennfelder auch auf
Basis von SIMULINK-Modellen eingefügt werden. TESIS DYNAware bietet nicht die
Möglichkeit, die Verkehrsumgebungen des Autos zu simulieren, sondern eignet sich lediglich
dazu, Fahrdynamik und Verbrauch o. ä. zu analysieren. Um einen Hardware-in-the-loop-Test
durchzuführen wird zusätzlich ein Simulationsboard von dSpace benötigt, um die Simulation
an die Hardware anzuschließen. TESIS DYNAware ist auf dem Markt frei zu kaufen. [TES03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
44
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
4.5
AVL Cruise
4.5.1
Produktinformationen
CRUISE wird dazu verwendet, Fahrzeuge zu simulieren und den Antriebsstrang zu
analysieren. Es handelt sich um ein modular aufgebautes Konzept zur Simulation von vielen
verschiedenen Fahrzeug- und Motorentypen. Es beinhaltet das Modul eines Fahrers, der
unterschiedliche Fahrweisen besitzt, und für eine realistische Reproduktion des
Fahrzeugverhaltens aufgrund menschlichen Verhaltens sorgt. Dieser Fahrer bremst,
beschleunigt und schaltet je nach Fahrertyp unterschiedlich. Außerdem besitzt CRUISE ein
Kaltstart-Modul für den Motor und torsionselastische Elemente zur Analyse von
Schwingungen. CRUISE besitzt ein Interface zur Einbettung von MATLAB/SIMULINKModulen. Das Simulationswerkzeug wird typischerweise zur Entwicklung von Motor und
Antriebsstrang verwendet, um ein Fahrzeug oder Teile davon zu optimieren. Insbesondere
gilt dies für die Bestimmung von Verbrauch und Emissionen, der Analyse von
Beschleunigung, Bremsen und Bergauffahren, Getriebeübersetzung und Schaltstrategien für
Automatik-Getriebe. Weitere Einsatzgebiete sind die Auswertung neuer Antriebskonzepte,
wie Hybridantriebe, und die Bewertung von Kontrollstrategien. Abb. 4-7 zeigt die Oberfläche,
die dem Anwender dabei zur Verfügung steht. [AVL03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
45
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 4-7: Oberfläche AVL-CRUISE [AVL03]
4.5.2
Leistungsumfang
AVL CRUISE eignet sich nur zur Simulation der auf den Antrieb bezogenen Elemente im
Fahrzeug wie Motor, Getriebe und Bremsen. Dazu liegen Modelle der verschiedenen
Komponenten vor. Es können aber auch eigene Komponenten erstellt werden. Dies
geschieht mit Hilfe der Simulationssoftware von MATLAB/SIMULINK, die über ein Interface
einbezogen werden kann. Die Möglichkeit der Simulation der Umgebung oder am Fahrzeug
angebrachter Sensoren zur Umgebungserkennung ist standardmäßig nicht enthalten. Diese
Komponenten können aber selbst erstellt werden mit einer anderen auf MATLAB/SIMULINK
basierenden Software. Für die Hardware-in-the-loop-Simulation wird auch hier ein
Simulationsboard wie bspw. von dSpace benötigt. Das Produkt ist auf dem Markt frei
käuflich. [AVL03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
46
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
4.6
MELROSE
4.6.1
Produktinformationen
MELROSE steht für Mitsubishi Electric Corp. Road Traffic Simulation Environment und ist ein
Straßenverkehrs-Simulationswerkzeug. Es simuliert nur die Umgebung eines Fahrzeugs. Für
die ACC-Simulation werden noch andere Simulationsprogramme benötigt, die das Fahrzeug
selbst simulieren können. [IKA99]
Abbildung 4-8: Simulation mit Melrose [IKA99]
Abb. 4-8 zeigt, wie mit Hilfe anderer Komponenten eine Simulation erstellt werden kann.
Dieser Aufbau ist eigentlich als Fahrsimulator gedacht, in dem ein Mensch sitzt, der das
simulierte Fahrzeug lenkt, doch eignet er sich auch zur ACC-Simulation. Dazu fehlt in
diesem Fall noch ein Modell, welches die Sensoren simuliert. Statt der Person oder
zusätzlich zur Person wird ein ACC-Steuergerät zwischengeschaltet. [IKA99]
4.6.2
Leistungsumfang
Dieses mikroskopische Umgebungsmodell simuliert andere Fahrzeuge anhand von FahrerEntscheidungsmodellen und Fahrzeugbewegungs-Modellen. Jedes Fahrzeug kann dabei im
Verkehrsnetz selbständig fahren. MELROSE kann verschiedene Verkehrssituationen
simulieren. Bei Simulationszeitintervallen von 100 ms können mehr als 2000 Fahrzeuge
dargestellt werden. MELROSE kann das Fahrzeug selbst nicht simulieren. Dies muss mit
anderen Werkzeugen geschehen. [IKA99]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
47
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
4.7
ADAMS
4.7.1
Produktinformationen
Das Unternehmen MSC bietet Software zur Entwicklung und Validierung physikalischer
Bausteine an. Ein besonders für Verkehrsmittel wie Flugzeug, Bahn oder Automobil oft
genutztes Entwicklungswerkzeug ist ADAMS. Auf dem Gebiet der automobilen Entwicklung
bietet MSC das Entwicklungstool ADAMS/Car an, welches wiederum aus verschiedenen
Modulen besteht.
Abbildung 4-9: ADAMS/Car [MSC03]
ADAMS/Car Conceptional Suspension ist ein Werkzeug zur Modellierung eines
konventionellen Fahrwerks. ADAMS/Car Ride eignet sich für die Fahrkomfortbestimmung
während des Designprozesses. ADAMS/Car Suspension Design simuliert des Fahrverhalten
in Abhängigkeit von der Fahrwerksabstimmung während des Designprozesses. ADAMS/Car
Vehicle Dynamics bietet eine Vielzahl von Fahrmanövern zum Test des gesamten
Fahrzeugs an. Hinzu kommt ADAMS/Chassis zum Entwickeln, Analysieren und Optimieren
des Chassis. ADAMS/Driveline ist ein Modul zur Erstellung des Antriebsstranges.
ADAMS/Engine powered by FEV erlaubt das Designen, Testen und Optimieren des Motors.
Weitere Tools sind ADAMS/Tire, Mechanism Pro und ADAMS/Hydraulics zur Entwicklung
von Reifen, Mechanik und Hydraulikkomponenten und ADAMS/Durability und
ADAMS/Vibration zur Analyse von Haltbarkeit und Vibrationen.
Mit ADAMS/Driver (Abb. 4-10) kann der Fahrer simuliert werden. Dieser kann vorgegebene
Aktionen durchführen, wie Bremsen, Beschleunigen oder Schalten. Mit ADAMS/3D Road,
einem Tool zur Erstellung einer virtuellen Straße, können außerdem Effekte beim
Durchfahren von Kurven, welligem Asphalt oder ähnlichem analysiert werden. Die einzelnen
Unterkomponenten können dabei eingebunden werden. [MSC03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
48
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 4-10: ADAMS/Driver [MSC03]
4.7.2
Leistungsumfang
ADAMS bietet die Möglichkeit, alle Elemente wie z. B. Fahrwerk, Karosserie oder Motor des
Fahrzeugs zu simulieren. ADAMS bietet selbst kein Tool zur Simulation von
umgebungserfassenden Sensoren an. Jedoch können diese mit ADAMS/Controls selbst
basierend auf Blockdiagrammen oder Geometrie erstellt werden. Dazu können Programme
verwendet werden, die auf MATLAB/SIMULINK basieren. Die Umgebungssimulation
ADAMS/3D Road (Abb. 4-11) erlaubt das Fahren auf einer erstellten Straße jedoch keine
zusätzlichen Hindernisse oder Fremdverkehr. Durch den Austausch mit anderen
Simulationswerkzeugen kann dieses Problem gelöst werden. Für Hardware-in-the-loopSimulationen muss auch hier ein Simulationsboard, wie etwa von dSpace verwendet
werden.[MSC03]
Abbildung 4-11: ADAMS/3D Road
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
49
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
4.8
SHIVA
4.8.1
Produktinformationen
SHIVA steht für Simulated Highways for Intelligent Vehicle Algorithms. Es wurde an der
Universität Berkley entwickelt. Die Ziele von SHIVA sind:

Erstellung von realistischen Sensormodellen

Unterstützung von Fahrzeugen, die untereinander Daten austauschen können

Eine Vielzahl an "Driver Models", ein Entscheidungsalgorithmus, der davon ausgeht,
dass sowohl automatisch, als auch manuell gesteuerte Fahrzeuge verwirklicht
werden können

Effiziente Integration mit echten Fahrzeugen
Implementierung:
SHIVA läuft auf SUN SPARC Workstations (unter X) und SGI Workstations.
Eine Klassenhierarchie für Sensoren und Fahrzeuge sowie Displayanzeigen ermöglichen
dem Benutzer, Algorithmen für spezifische Fahrzeug/Sensor Konfigurationen zu entwickeln
und diese dann mittels graphischer Tools zu testen. Simulierte Szenarios können interaktiv
online in 3D dargestellt werden. Informationen wie z. B. Durchsatz können offline abgefragt
werden. SHIVA ist objektorientiert in C++ implementiert.
User Interface (Abb. 4-12):
SHIVAs Design trennt die Simulation vom Benutzerinterface, ohne dabei auf OfflineAnimationen zurückzugreifen. Man kann zwischen verschiedenen Kameraperspektiven
wählen (Fahrersicht, Vogelperspektive, "Fahrzeugsicht", u.a.).
Weiterhin existiert eine Infobox, in der der Benutzer die Attribute eines ausgewählten
Fahrzeugs betrachten kann. [ULM03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
50
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 4-12: User-Interface[ULM03]
4.8.2
Leistungsumfang
Die Umgebungssimulation besteht aus vier Teilbereichen:

Straßen

Fahrzeugen

Regler

Sensor
Straßen:
Durch die objektorientierte Programmierung von SHIVA ergeben sich folgende Klassen zur
Repräsentation der Straße:
RoadSegment, RoadSlices und RoadPosition
Autobahnen sind als Gruppen verbundener Straßensegmente (RoadSegment, vgl. Abb. 413) organisiert, wobei jedes Segment mit beliebiger Form, jedoch fester Fahrbahnanzahl ist.
Durch die Verbindung von Segmenten lassen sich beliebige Autobahnstrukturen realisieren.
Jedes Segment enthält weitere Informationen z. B.
über Fahrbahnbegrenzungen,
Geschwindigkeitsbegrenzungen
und
Oberflächenstruktur.
Spezielle
Arten
von
Straßensegmenten lassen sich ableiten. Jedes "RoadSegment" wird in Straßenstreifen
("RoadSlices", vgl. Abb. 4-14) zerlegt, wobei diese stets senkrecht die Fahrbahn schneiden
und durch einen Ursprung und einen Offset-Vektor definiert sind. Der Abstand zwischen zwei
Streifen hängt vom erwarteten Verkehr und der Kurvenkrümmung ab.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
51
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Die Klasse "RoadPosition" ist ein transparentes Interface zwischen der Straßendarstellung
und andern Objekten in SHIVA. Obwohl die Straßen diskret dargestellt sind, kann ein
Fahrzeug beliebige Positionen einnehmen und unter Umständen sogar die Straße verlassen,
falls der Fahrbahnerkennungsalgorithmus so schlecht ist, dass er dies nicht verhindert.
[ULM03]
Abbildung 4-13: Straßensegmente (RoadSegment) [ULM03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
52
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Abbildung 4-14: Straßenstreifen (RoadSlices) [ULM03]
Fahrzeuge:
Fahrzeuge sind kinematisch exakt, zwei-achsig und vorderradgelenkt implementiert. Es
werden drei Fahrzeugklassen mit ihren jeweiligen physikalischen Charakteristika
unterschieden.
Zusätzlich zu den herkömmlichen physikalischen Eigenschaften besitzen alle SHIVAFahrzeuge folgende Untersysteme:

Regler

Sensormodelle

Fahrermodelle
Außerdem können Fahrzeuge mit der Fähigkeit ausgestattet werden, asynchron mit
anderen, gleichwertig ausgestatteten Fahrzeugen zu kommunizieren.
Regler:
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
53
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.

Die SHIVA Controller sind mit dem selben Interface ausgestattet wie die echten
Controller der Fahrzeuge. Dadurch wird sichergestellt, dass die simulierten
Fahrzeuge nur Aktionen durchführen, die auch in der Wirklichkeit möglich sind, und
umgekehrt, Algorithmen, die für simulierte Fahrzeuge entwickelt wurden, ohne
Änderungen, auf reale Fahrzeuge übertragbar sind.
Sensor:
SHIVA arbeitet nicht mit unrealistischen Annahmen über die Sensoren. So wird z. B. nicht
angenommen, dass die Beschleunigung anderer Fahrzeuge direkt und perfekt gemessen
werden kann, Autobahnen keine Kurven haben und man geht nicht von "durchsichtigen"
Fahrzeugen aus.
Bei SHIVA wird darauf Wert gelegt, dass die entwickelten Algorithmen erfolgreich mit echten
Eingabewerten arbeiten können. SHIVAs Sensorcharakteristika enthalten sowohl den
Sensortyp (Fahrbahnerkennung, Fahrzeugerkennung, Positionserkennung) als auch
Detailstufen wie z. B. Rauschempfindlichkeit. [ULM03]
4.9
4.9.1
PELOPS
Produktinformationen
Abbildung 4-15: PELOPS [PEL03]
PELOPS wird von der fka Vertrieben. Es ist ein Programm zur Entwicklung
längsdynamischer mikroskopischer Verkehrsprozesse in systemrelevanter Umgebung. Die
Aufgabe des Programmsystems PELOPS ist die Analyse der Wechselwirkungen zwischen
Fahrzeug, Mensch und Umwelt unter der besonderen Berücksichtigung des Einflusses des
Automobils auf das Gesamtsystem. PELOPS kombiniert fahrzeug- und verkehrstechnische
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
54
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Modelle und ermöglicht dabei, alle Wechselwirkungen zwischen Fahrer, Fahrzeug und
Verkehr einzubeziehen. Die drei wesentlichen Komponenten des Verkehrs, der
Strecke/Umwelt sowie von Fahrer und Fahrzeug bilden den Kern des Programms. In einer
modularen Programmstruktur werden die genannten Elemente modelliert und durch
Schnittstellen abgegrenzt. PELOPS wird genutzt, um verkehrliche und infrastrukturgestützte
Verkehrsbeeinflussungsmaßnahmen und Fahrerassistenzsysteme zu bewerten. Dies
geschieht in Form von makroskopischen, mikroskopischen und submikroskopischen
Parametern. Die derzeitgigen Forschungsprojekte zeigen die Bandbreite der
Einsatzmöglichkeiten von PELOPS:

Parametervariationen in der Fahrzeugauslegung

Einfluss der Fahrercharakteristik auf Kraftstoffverbrauch und Emissionen

Untersuchung und Auslegung von Fahrerassistenzsystemen zur längsdynamischen
Fahrzeugführung in verschiedenen Verkehrsumgebungen

Einfluss von Verkehrssteuerungsmaßnahmen
innerstädtischen Knotenpunkten

Analyse straßenseitiger Warn- und Informationssysteme

Allgemeine Untersuchungen zu Verkehrsströmen

Auslegung intelligenter Antriebsstrangsteuerungen
auf
den
Verkehrsablauf
an
PELOPS befasst sich ganz speziell mit der Entwicklung von ACC-Systemen. Die Simulation
kann einen realen Verkehrsfluss darstellen. Dazu muss zuerst das Fahrverhalten anderer
Verkehrsteilnehmer realitätsnah dargestellt werden (vgl. Kap. 5.2). Des Weiteren muss das
ACC-Fahrzeug selbst einschließlich der Sensoren simuliert werden. Fahrzeugdaten und
Kennfelder des Motors, des hydrodynamischen Wandlers und der Schalt- und
Lockupkennlinien werden in PELOPS abgebildet. Um die Portabilität des ACC-Reglers
zwischen Simulation und Fahrzeug zu gewährleisten, gibt es eine Schnittstelle, die sowohl
im Fahrzeug, als auch in der Simulation mit den selben Daten gefüllt wird. Die abgreifbaren
Daten im Fahrzeug bei der Simulation werden denen im realen Fahrzeug angepasst. Zu den
Eingangsgrößen des Reglers zählen z. B. der sensierte aktuelle Zustand des eigenen
Fahrzeugs und die über den Abstandssensor erfassten Daten des Vorderfahrzeugs. Zu den
Ausgangsgrößen zählen z. B.
der Solldruck im Bremszylinder oder die
Drosselklappenstellung.
Ein weiterer wichtiger Punkt ist die Interaktion zwischen Fahrer und System. Dazu wird
permanent eine Übernahmeschwelle berechnet, bei der der Fahrer das System abschaltet.
Diese Übernahmeschwelle ergibt sich aus empirischen Untersuchungen - in Abhängigkeit
von Abstand, Differenzgeschwindigkeit, maximaler Verzögerung des ACC-Reglers und der
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
55
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Geschwindigkeit des Vorderfahrzeugs. Weitere mögliche Übernahmen des Fahrers sind bei
Fahrzeugstillstand oder im Bereich von Ampeln. [PEL03]
4.9.2
Leistungsumfang
Es werden detaillierte Fahrzeugmodelle mit allen relevanten Antriebsstrangkomponenten
angeboten die anhand von Fahrversuchen verifiziert wurden. Auf Basis von Messfahrten
verschiedener Fahrer in realem Verkehr wurde ein Fahrermodell entwickelt. Kenngrößen
sind dabei das Beschleunigungsverhalten in Abhängigkeit vom Abstand und der
Geschwindigkeitsdifferenz zum vorausfahrenden Fahrzeug. Mit diesen Kennzahlen, in
Abhängigkeit von der Fahrsituation (Anfahren, Anhalten, Folgen usw.), lässt sich das
Fahrverhalten in seinen Grundzügen beschreiben. Ziel ist es, ein möglichst realitätsnahes
Modell der Umgebung zu erstellen. Ein weiterer wichtiger Punkt ist die wirklichkeitsnahe
Simulation des Sensors. Dieser gibt sowohl die Informationen über den eigenen Zustand des
Fahrzeugs als auch den der vorausfahrenden Fahrzeuge an den Regler weiter. Dazu wird
ein geometrisches Modell verwendet, das dem Erfassungsbereich des Sensors entspricht.
Um realitätsnahe Sensordaten zu bekommen, werden sowohl die Sensordaten als auch die
Daten des eigenen Fahrzeugs verrauscht. Die Verkehrsumgebung kann durch Vorgabe der
Fahrbahngeometrie (Anzahl der Spuren, Höhenplan, Kurvenplan, Beschilderung) und
Definition der umgebenden Fahrzeuge ebenfalls exakt festgelegt werden. So wird es
möglich, einen Regler oder ein gesamtes Assistenzsystem einer problematischen
Verkehrssituation gezielt und reproduzierbar auszusetzen.
Über verschiedene Schnittstellen können in Quellcode vorliegende Regler-Algorithmen
genauso in die Simulationsumgebung eingebunden werden wie Steuergeräte oder sogar
ganze Fahrzeuge. Dazu bietet PELOPS verschiedene Schnittstelle:

Frei konfigurierbare Software-in-the-loop-Schnittstelle für Steuergerätetauglichen
Quelltext

Frei konfigurierbare Schnittstelle für die Kopplung mit MATLAB/SIMULINK zur
integration von Fahrzeug-, Sensor- oder Regler-MATLAB-Modellen

Frei konfigurierbare Hardware-in-the-loop-Schnittstelle zur Integration von
Steuergeräten und kompletten Versuchsträgern, incl. Einbindung von dSpaceWerkzeugen
[PEL03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
56
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
4.10
LabCar
4.10.1
Produktinformationen
LabCar ist ein Produkt von ETAS, einer Tochtergesellschaft der Robert Bosch GmbH.LabCar
ist ein Glied einer durchgängigen Werkzeugkette von ETAS Engineering Tools zur
Entwicklung und zum Test von elektronischen Steuergeräten im Automobilbereich.
LabCar wird an verschiedenen Stationen des Entwicklungsprozesses von Steuergeräten in
unterschiedlichsten Anwendungen eingesetzt. Mit reproduzierbaren Szenarien werden
Steuergeräte systematisch und automatisiert getestet. Die typischen Einsatzgebiete sind alle
Stufen des sog. V-Modells (Abb. 4-16):
Abbildung 4-16: Steuergeräte-Entwicklungsprozess [IAV03]
Alle an der Entwicklung beteiligten Bereiche setzen LabCar in verschiedenen Anwendungen
ein:

Funktionsentwicklung
Dieser Bereich befasst sich mit der Entwicklung neuer Regelstrategien,
Diagnoseverfahren, Adaptionsalgorithmen etc. .
LabCar Modelle werden in Software-In-the-loop Simulationen und Hardware-In-theloop-Anwendungen mit Entwicklungssteuergeräten eingesetzt.
In der Funktionsentwicklung eignet sich LabCar z. B. für Robustheitsuntersuchungen
von Regelstrategien. So können Fertigungstoleranzen und Alterungseffekte realer
Komponenten in der Simulation beliebig verändert werden, um so die
Stabilitätseigenschaften des Reglers herauszufinden.

System- und Hardwareentwicklung
Zu diesem Bereich zählen Hardwareprüfungen (z. B. Endstufentest unter
realistischen Ansteuerbedingungen, Hardwarediagnose, Hardwarefilter,
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
57
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Kommunikationsschnittstellen), Validierung von Sicherheitskonzepten (z. B. bei driveby-wire, brake-by-wire), Entwicklung von steuergeräteübergreifenden Funktionen (z.
B. Drehmomentschnittstelle, Bremsenmanagement, Fahrzeugführung).

Softwareentwicklung
Bei der Softwareentwicklung wird LabCar für den Softwaremodultest,
Timinguntersuchungen (z. B. bei hohen Drehzahlen) und den Test hardwarenaher
Software (z. B. Winkeluhr, Drehzahlerfassung, Filteralgorithmen) eingesetzt.

Applikation, Serienfreigabe
Hier wird LabCar für die Inbetriebnahmen von Steuergeräten, Integrationstests
(Zusammenspiel aller Funktionen im Steuergerät), Simulation kritischer Fahrzustände
(z. B. Höchstgeschwindigkeit, Vollbremsungen, fahren im "roten" Drehzahlbereich),
Simulation extremer Umweltbedingungen (z. B. Höhenfahrt, Kaltstart),
Dauerlaufuntersuchungen (z. B. Suche nach sporadischen Zündaussetzern) und zum
Nachstellen von Situationen aus dem realen Fahrversuch. Außerdem wird LabCar
zum automatischen Steuergerätetest (z. B. automatisches Abfahren von Prüfzyklen)
eingesetzt.

Qualitätssicherung
LabCar eignet sich zum Test von Feldrückläufern, Freigabeuntersuchungen nach
Designänderungen und Untersuchung von 0km-Fehlern am Bandende.
[ETA03]
4.10.2
Leistungsumfang
LabCar bietet die Möglichkeit, ein vollständiges Automobil mit allen relevanten Komponenten
zu erstellen. Außerdem bietet es weitreichende Möglichkeiten der Umgebungssimulation.
Dazu werden offene Modelle verwendet, in die eigene Komponenten eingefügt werden
können. Das vorhandene ACC-Modell ist für die Firma Bosch optimiert worden. Die
Teststrecke kann anhand von Punkten erstellt werden, durch die hinterher die Fahrbahn
verlaufen soll. Neben dem ACC-Fahrzeug befinden sich noch bis zu 20 andere Fahrzeuge
auf dem Parcours als Zielobjekte für den (Radar-)Sensor. Diese Fahrzeuge sind mit eigenen
Fahrermodellen ausgestattet und führen ohne Kollisionen autonom Brems- und
Beschleunigungsvorgänge sowie Spurwechsel durch. Dabei differenziert man zwischen 3
verschiedene Fahrzeugtypen (PKW, LKW, Motorrad) mit unterschiedlichem Brems- und
Beschleunigungsverhalten. Die Daten jedes einzelnen Fahrzeugs werden abgespeichert.
Die Signale, die vom (Radar-)Sensor erfasst werden, und auch die Störsignale werden
nachgebildet.
Es werden ebene Fahrzeugmodelle mit 7 Freiheitsgraden für Längs- und Querdynamik
verwendet. Im Motormodell ist die Eingriffsmöglichkeit eines ACC-Reglers in das
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
58
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Motormanagement nachgebildet. Beliebig Fahrbahnverläufe sind darstellbar. Dies können
Rundkurse oder offene Kurse sein. Ein Fahrermodell bedient das Lenkrad entsprechend.
Die Straße ist mit 1 bis 3 Fahrspuren darstellbar. Die Spurweite ist variabel über der
Streckenlänge der Fahrbahn. Im Modell der Bremsanlage ist die Eingriffsmöglichkeit eines
ACC-Reglers in das Bremsenmanagement nachgebildet. Steigung und Querneigung der
Fahrbahn sind spezifizierbar. Der Antriebstrang enthält wahlweise ein Schalt- oder
Automatikgetriebe.
Visualisierung
Das ETAS-Animationspaket erlaubt die Verfolgung der simulierten Fahrszene in einem
während der Simulation online ablaufenden Film. Damit kann man die Güte einer Regelung
unmittelbar beurteilen.
Abbildung 4-17: LabCar Visualisierung [ETA03]
Auch LabCar benötigt zur Hardware-in-the-loop-Simulation ein Simulationsboard. Es kann
das von ETAS gebaute Board oder eines von dSpace verwendet werden. [ETA03]
4.11
SIMPACK Automotive+
4.11.1
Produktinformationen
Einzelne Komponenten wie Auspuffsysteme, Chassis, Fahrwerk oder ganze Autos können in
unterschiedlicher Komplexität mit SIMPACK Automotive+ modelliert werden. Dabei können
flexible Elemente eingesetzt und Haltbarkeit und Vibrationen analysiert werden. Auch bietet
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
59
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Automotive+ unter anderem die Möglichkeit der Simulation von Reifen, Straße und
Aerodynamik. Sowohl Open-loop- als auch Closed-loop-Verfahren werden zum Testen
angeboten. Für Closed-loop-Verfahren werden die Module Track und Driver angeboten, mit
deren Hilfe vorgegebene Prüfzyklen abgefahren werden können. [SIM03]
4.11.2
Leistungsumfang
SIMPACK Automotive bietet die Möglichkeit, ein vollständiges Automobil mit allen relevanten
Komponenten zu erstellen und im In-the-loop-Verfahren zu testen. Für Hardware-in-the-loopTests wird auch hier ein Simulationsboard benötigt. Ein Tool zur Umgebungssimulation ist
zur Zeit in Arbeit. Es befindet sich noch nicht auf dem Markt. [SIM03]
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
60
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
5
Marktanalyse und Vergleich
Da die großen deutschen Automobil- und Elektronikkonzerne keine Auskunft darüber
erteilten, mit welchen Simulationswerkzeugen sie in der Assistenzsystem-Entwicklung
arbeiten, bezieht sich die folgende Aufstellung (Abb. 5-1) ausschließlich auf Angaben der
Hersteller der einzelnen Simulationswerkzeuge.
Anbieter
Referenzen
MATLAB/ SIMULINK/ STATEFLOW
Autoliv, Borg-Warner, Caterpillar, Cummins
Engine, DaimlerChrylser, Deere, Delphi,
Denso, Detroit Diesel, Federal-Mogul, Eaton,
EcoStar, Fiat, Ford Motor, General Motors,
GKN Automotive, Hitachi, Honda,
International Truck and Engine, Johnson
Controls, Magneti Marelli, Motorola, Navistar
International, Newman, Haas Racing, New
Venture Gear, OnStar, PSA, Renault,
Ricardo, Robert Bosch, Tenneco Automotive,
Sachs Automotive, SAGEM, Siemens,
Toyota, TNO, TRW, Valeo, Visteon,
Volkswagen
Statemate Magnum BMW, Bosch-Blaupunkt, DaimlerChrysler, Denso,
Delphi, Ford, General Motors, Hella AG, Magneti
Marelli, Nippon Denso, Nippon Seiki, Nissan,
PSA, Renault, Rover, SAAB, Siemens AT,
Stirling, Valeo, Volkswagen, Volvo
MATRIXx
Chrysler, Magneti Marelli, Motorola, Toyota,
Philips, Visteon
PI Autosim
Ford Motor Company
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
61
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
dSpace
AFT, AVL, Audi, BEHR HELLA, BMW, Borg
Warner, Bosch, Bridgestone, Brose, Centro
Ricerche Fiat, Continental, ContiTemic, DAF
Trucks, Daihatsu, DaimlerChrysler, DENSO,
Eaton, ELASIS, FEV, Ford, General Motors,
HELLA, HINO Motors, Honda, Hyundai, IAV,
ISUZU, IVECO, JOHNSON CONTROLS,
LAND ROVER, LMS, LuK, MAGNA STEYR,
Magneti Marelli, MAN, Mazda, Michelin,
Mitsubishi Motors, Mitsubishi Electric
Corporation, MATRA, Nissan, NewVenture
Gear, Opel, Porsche, PSA Peugeot, Citroën,
Ricardo, Renault, Renault Sport, Rolls Royce
Motor Cars, SAAB, SCANIA, SEAT Sport,
Siemens VDO, Skoda, TAG, TENNECO,
TNO, Toyota, TRW, Unisisa Jecs, VALEO,
VISTEON, Volkswagen, Volvo Cars, Volvo
Trucks, WABCO, ZF, ZF Lenksysteme
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
62
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Tesis Dynaware Audi AG, AVL List GmbH, BMW AG, BMW M
GmbH, DaimlerChrysler AG, Denso
Corporation, EADS Deutschland GmbH, Ford
Motor Company, GM Fiat Powertrain, Hino
Motors Ltd., Honda R&D Co. Ltd., Infineon
AG, Isuzu Advanced Engineering Center Ltd.,
Liebscher Kunststofftechnik GmbH & Co. KG,
Loewe Opta GmbH, Magna Steyr, Max
Weishaupt GmbH, MAN Roland
Druckmaschinen AG, Sanyo Energy (Europe)
Corporate GmbH, Siemens AG, Telair
International GmbH, Toyota Motorsport
Group, Viessmann Werke GmbH & Co., Voith
AG, Volkswagen AG, Wafios AG, ZF Bosch
GmbH
AVL Cruise
DaimlerChrysler, Ferrari Formula 1, Audi
MELROSE
Mitsubishi Elektric Corp.
ADAMS Car
Aprilla Motorcycle, Thomas Built Buses,
Talfourd-Jones, Gates Rubber, SmarTire,
Hayes Lemmerz, Sanderson Engine
Development, OTTO FUCHS Metallwerke,
Cooper Tire
PELOPS
BMW AG, VW AG, Daimler Chrysler AG, FH
Erfurt, WABCO
LabCar
Robert Bosch GmbH, Siemens VDO
SIMPACK
Ansaldobreda Construzioni Ferroviarie
S.p.A., BMW AG, Bombardier Transportation,
DaimlerChrysler AG, DAF, Land Rover, MAN
AG, Mazda Motor Corp., Robert Bosch
GmbH, Siemens AG, Sumitomo Metal
Industrie, Ltd., WABCO,
Abbildung 5-1: Referenzen
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
63
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Außer MATLAB/SIMULINK/STATEFLOW, MatrixX und Statemate Magnum sind alle
angegebenen Produkte speziell für Simulationen im Automobilbereich entwickelt worden. Für
die Software-in-the-loop-Simulation eigenen sich MATLAB/SIMULINK/STATEFLOW,
Statemate Magnum, MatrixX, TESIS DYNAware, MELROSE, ADAMS Car, AVL Cruise,
PELOPS, LabCar und Simpack Automotive+. Auch Hardware-in-the-loop-Anwendungen sind
mit einigen Werkzeugen möglich. Dazu zählen LabCar, PELOPS, TESIS DYNAware, AVL
CRUISE und ADAMS. TESIS DYNAware, ADAMS und AVL CRUISE benötigen dazu
Simulationsboards von dSpace. Dies ist bei PELOPS und LabCar nicht nötig, jedoch ist die
Nutzung dieser Hardware obligatorisch. Um andere Simulationswerkzeuge in die Simulation
zu integrieren sind Schnittstellen notwendig. Besonders zur Integration von
MATLAB/SIMULINK sind diese bei vielen Produkten vorhanden. Dazu zählen TESIS
DYNAware, AVL CRUISE, ADAMS Car, PELOPS und LabCar. AVL CRUISE hat außerdem
eine Schnittstelle zu TESIS DYNAware. Daraus geht schon hervor, dass
MATLAB/SIMULINK ein sehr oft verwendetes Werkzeug ist. Für die Simulation von
Antriebskomponenten ist TESIS DYNAware sehr gebräuchlich. Oft verwendet werden
außerdem ADAMS Car und LabCar. Letzteres ist neben PELOPS das einzige Werkzeug,
welches eigene Umgebungssimulationen, die sich für die Entwicklung umgebunserfassender
Assistenzsysteme eignen, anbietet.
Bis auf MELROSE und PI Autosim sind alle Produkte auf dem freien Markt zu erwerben.
MELROSE ist ein Produkt der Mitsubishi Electric Corp., PI Autosim eines der Ford Motor
Company.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
64
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
6
Zusammenfassung
Fahrerassistenzsysteme sind in neuen Automobilen in immer größerem Umfang zu finden.
Sie unterstützen den Fahrer beim Durchführen seiner Fahraufgaben und sorgen zugleich für
die Erhöhung der aktiven Sicherheit. Sie lassen sich anhand der Fahraufgaben die sie
unterstützen und anhand der Art der Unterstützung unterteilen. Zu den Fahraufgaben zählen
die Navigation, die Führung und die Stabilisierung. Als Einteilung für die Arten der
Unterstützung lassen sich das Informieren, das Warnen/Unterstützen und das automatische
Intervenieren nennen. Auf dem Weg zum automatisierten Fahren spielen
umgebungserfassende Assistenzsysteme eine immer größere Rolle. Verschiedene Systeme
wie Parkassistent, Adaptive Cruise Control oder Stauassistent wurden im Rahmen dieser
Arbeit näher erläutert.
Zur Beschleunigung der Entwicklung neuer Assistenzsysteme und insbesondere der
zugehörigen Steuergeräte werden neue Entwicklungsmethoden eingesetzt. Im Bereich des
Echtzeitsystementwurfs wird unter dem Begriff Rapid Prototyping eine Art der
Prototypenerzeugung verstanden, bei der bereits in den ersten Entwurfsphasen ein Prototyp
zur konzeptionellen Überprüfung elektronischer Systeme hergestellt wird. Anhand der Höhe
der Ebene im sog. VP-Modell wird in drei Kategorien unterschieden. Auf der Höchsten
Ebene steht das Konzeptorientierte Rapid Prototyping, welches Hauptsächlich der Klärung
der Ziele dient und die schnelle Umwandlung der Spezifikation in einen funktionellen
Prototypens unterstützt. Auf der zweiten Ebene folgt das Architekturorientierte Rapid
Prototyping, welches bereits die Zielarchitektur des Systems berücksichtigt, um genauere
Aussagen über die endgültige Leistungsfähigkeit eines Systems vornehmen zu können. Das
Implementierungsorientierte Rapid Prototyping folgt auf der untersten Stufe des VP-Modells.
Dabei werden hochspezialisierte Prototypen erzeugt, die auf den expliziten Anwendungsfall
zugeschnitten sind und meist keine Wiederverwendung mehr zulassen. Zur Verifizierung
eines Prototypens werden verschiedene Simulationsmethoden eingesetzt. Besonders In-theloop-Verfahren sind in diesem Bereich von großer Bedeutung. Sie stellen eine Möglichkeit
zur Verfügung, einen Steuergerätealgorithmus in einer der Realität nachgebildeten
Simulationsumgebung zu testen. Dazu gibt es zwei verschiedene Verfahren. Bei der
Software-in-the-loop-Simulation werden Softwaremodule durch Kopplung an einen
Testrahmen im geschlossenen Regelkreis auf korrektes Verhalten getestet. Das IstVerhalten der Funktionen wird mit dem spezifizierten Soll-Verhalten verglichen. Die zweite
Möglichkeit ist die Hardware-In-the-loop-Simulation, bei der die Software-Module in einem
Prototyp- oder Seriensteuergerät implementiert werden. Der Test erfolgt durch elektrische
Kopplung an ein auf einem Echtzeit-Rechnersystem implementiertes Streckenmodell. Um
umgebungserfassende Assistenzsysteme im In-the-loop-Verfahren zu testen wird eine
Leistungsfähige verkehrliche Simulation vorausgesetzt. Dazu eignen sich nur
Submikroskopische Simulationsmodelle mit Schrittweiten von weniger als 0,1 s., da
makroskopische und mikroskopische Simulationsmodelle im Hinblick auf Zeitverzögerungen
bei Beschleunigungsvorgängen mit Schrittweiten von 10 bzw. 1 s. zu ungenau wären. Die
Simulation selbst setzt sich aus dem realen Algorithmus in der Mitte und den vier
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
65
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
Komponenten Fahrer, Fahrzeug, Sensor und Umwelt zusammen, welche mit dem realen
Algorithmus interagieren.
Die
zur
Softwareund
Hardware-In-the-loop-Simulation
zum
Test
von
Automobilsteuergeräten zur Verfügung stehenden Simulationswerkzeuge wurden im
Anschluss daran näher erläutert. Dabei wurden die Möglichkeiten der Simulation und
besonders die der simulierten Umgebung besonders herausgestellt. Neben allgemeinen
Simulationswerkzeugen wie MATLAB/SIMULINK befinden sich speziell für automobile
Anwendungen entwickelte Werkzeuge für einzelne Komponenten wie Antrieb oder Fahrwerk
(AVL CRUISE, TESIS DYNAware), für das Gesamte Automobil (ADAMS Car, SIMPACK)
oder für die Umgebung (MELROSE) auf dem Markt. PELOPS und LabCar bieten sowohl die
Simulation des gesamten Automobils, als auch die der Verkehrsumgebung. Mit PI Autosim
und dSpace stehen Simulationsboards für Hardware-in-the-loop-Anwendungen zur
Verfügung.
In Kap. 5 wurde aufgestellt, welcher Hersteller welches Simulationswerkzeug zur
Entwicklung von Steuergeräten benutzt. Außerdem wurde erläutert, welches
Simulationswerkzeug sich für welche Art der Simulation eignet, welche anderen Werkzeuge
zur Simulation benötigt werden und welche Schnittstellen sie besitzen. Außerdem wurde die
Verfügbarkeit am freien Markt beschrieben.
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
66
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
7
Literatur
[AAK02]
Aachener Kolloquium
Fahrzeug- und Motorentechnik, Aachen 2002
[AHS03]
AHSRA Web Page
www.netpar.or.jp
[ASI98]
Adamski, D.; Hiller, M.:
Erstellung einer Simulationsumgebung aus Komponenten. ASIM, Zürich, 1998
[AVL03]
AVL Homepage
AVL CRUISE
www.avl.com
[BRA97]
Brannolte, Ulrich; Kraus, Thomas:
Situationsanalyse über den Stand der Simulationsmodelle im Verkehrswesen.
Abschlussbericht zum Forschungsprojekt des BMBF, Weimar, 1997
[BRE02]
Brendecke, Thomas:
Virtuelle Echtzeitumgebung für Getriebesteuergeräte mit Hardware-in-the-loop.
Braunschweig, 2002
[BUR00]
Burst, Alexander:
Rapid Prototyping eingebetteter elektronischer Systeme auf Basis des CDIF
Datenaustauschformats. Karlsruhe, 2000
[CAD03]
Cadillac Homepage
www.cadillaceurope.de
[DAI03]
Daimler Chrysler Homepage
www.daimler-chrysler.com
[DAR03]
Homepage der TU Darmstadt
www.tu-darmstadt.de
[DUI03]
Homepage der Universität Duisburg
www.uni-duisburg.de
[DSP03]
dSpace Homepage
www.dspace.de
[EGE03]
Egelhaaf, Dr. Jan:
Night Vision. Leonberg, 2003
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
67
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
[ETA03]
ETAS Homepage
LabCar
www.etas.de
[FKF03]
Forschungsinstitut für Kraftfahrwesen und Fahrzeugmotoren Stuttgart
KFZ-Mechatronik und –software
www.fkfs.de
[GLO03]
Global Denso Homepage
www.globaldenso.com
[GOT03]
Gotzig, Dr. Heinrich:
Parkassistenz, Bietigheim-Bissingen, 2003
[GRI88]
Grimm, Hubert G.:
Wahrnehmung und sicheres Fahrverhalten im Straßenverkehr:
Situationsübergreifende Aspekte. Bericht zum Forschungsprojekt 8306 der
Bundesanstalt für Straßenwesen, Bergisch Gladbach, 1988
[HEL03]
Hella Homepage
www.hella.com
[HÜL03]
Hüls, Thomas
Vortrag: Simulation, Dortmund, 2003
[IAV03]
IAV Homepage
www.iav.de
[IGP03]
IGP Homepage
CarMaker
www.igp.de
[IKA99]
Ikawa, Masahiko; Kumazawa, Hiroyuki; Goto, Yukio; Furusawa, Haruki
Simulation Environment For ITS, 1999
[IKA03]
IKA Homepage
www.ika.rwth-aachen.de
[INV03]
INVENT Homepage
www.invent-online.de
[KAR03]
Homepage der Universität Karlsruhe
www.uni-karlsruhe.de
[MAT03]
The MathWorks
www.mathworks.de
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
68
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
[MSC03]
MSC Homepage
www.mscsoftware.com
[NAA99]
Naab, Karl
Driver Assistence in Longitudinal and Lateral Vehicle Guidence. EUROMOTOR
Seminar on Telematic/Vehicle and Environment, Hrsg.: H. Wallentowitz,
Aachen, 1999
[OFF03]
Offroad Homepage
www.offroad.de
[REI95]
Reichart, Günter; Lerner, Georg:
Systeme zur Fahrerunterstützung. in: Datow, Matthias (Hrsg.):
Verkehrstelematik- Projekte und Strategien. Kongressdokumentation TTE ´95,
Berlin, 1995
[SAN03]
Santos Homepage
www.santosweb.de
[SIE03]
Siemens VDO Homepage
www.siemensvdo.de
[SIM03]
SIMPACK Homepage
SIMPACK Automotive+
www.simpack.de
[TES03]
TESIS Homepage
DYNAware
www.tesis.de
[TUB03]
Homepage der TU Berlin
www.tu-berlin.de
[ULM03]
Hauptseminar Robotik Simulation for intelligent transportation systems
Universität Ulm
www.informatik.uni-ulm.de
[VOS03]
Voss, Dr. U. (Daimler Chrysler):
4. Braunschweiger Symposium „Automatisierungs- und Assistenzsysteme für
Transportmittel“. Braunschweig 2003
[VUK01]
Vukotich, Dipl.-Ing. A.; Kirchner, Dr. A.:
Sensorfusion für Fahrerassistenzsysteme. VDI Berichte1646, Düsseldorf 2001
75941168
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
69
here. Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear
here.
[WEI00]
Weilkes, Michael:
Auslegung und Analyse von Fahrerassistenzsystemen mittels Simulation.
Schriftenreihe Automobiltechnik, Aachen, 2000
[WIL97]
Willumeit, Hans-Peter ;Jürgensohn, Thomas:
Fahrermodelle – ein kritischer Überblick ATZ, Hefte 7/8 und 9/1997.
[WRE03]
Wrede, Prof. Jürgen:
Fahrerassistenzsysteme – Status, Trends, Visionen. Pforzheim, 2003
[ZTR03]
Z-Tronic Homepage
www.z-tronic.de
75941168