Modellierung von speziellen Komponenten des FlexRay-Protokolls
©2006
Diplomarbeit
152 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Diese Arbeit beschäftigt sich auf den folgenden Seiten mit dem zukünftigen Übertragungsstandard im automobilen Bereich, mit FlexRay. Dabei liegen die Schwerpunkte dieser Arbeit im Übertragungsprotokoll und den einzelnen Protokollfunktionen von FlexRay. Die technischen Spezifikationen und Leistungsdaten, sowie die Hauptanwendungsgebiete von FlexRay werden in dieser Arbeit nur sehr kurz und oberflächlich im Kapitel 2 angesprochen. Wer noch keine Vorkenntnisse zu FlexRay besitzt, sollte sich als Einführung in die Thematik, die Studienarbeit von Stefan Aschenbach [6] ansehen. Für das Verständnis der Kernpunkte dieser Arbeit ist es jedoch nicht erforderlich, sich in andere Literatur einzuarbeiten. Falls doch, dann wird an den entsprechenden Stellen explizit auf die externen Literaturstellen verwiesen.
Als Grundlage für diese Arbeit diente hauptsächlich die FlexRay Protocol Specification in Version 2.1 da es zu FlexRay noch immer sehr wenige Publikationen gibt. Die meisten Veröffentlichungen zu FlexRay sind sehr produktspezifisch und weichen häufig von den originalen Vorgaben ab. Dennoch wurden für diese Arbeit auch Veröffentlichungen anderer Personen verwendet, wobei die Informationen aus diesen Dokumenten sehr genau überprüft wurden, um eine Vermischung von Standards und Eigenentwicklungen zu vermeiden.
Die Kernaufgaben dieser Diplomarbeit liegen beim Cluster Startup Mechanismus im Kapitel 3, bei der Synchronisation der einzelnen Nodes im FlexRay im Kapitel 4, sowie bei der Bestimmung der globalen und lokalen Parameter, um eine reibungslose Kommunikation zu gewährleisten, im Kapitel 6. Gestützt werden die Analysen und Formeln dieser Arbeit durch ein im Rahmen dieser Diplomarbeit entwickeltes Modell, welches die Kommunikation bei FlexRay darstellt. Dieses Modell wird im Kapitel 5 und im Kapitel 9 detailliert erklärt. Zum einfacheren Verständnis der Modelle gibt es im Kapitel 9 einen Einschub zu den Grundlagen der Specification and Description Language (SDL) sowie zu den Grundlagen von MLD im Kapitel 9.
Ziel dieser Arbeit ist es, dem Leser Schritt für Schritt und sehr detailliert die einzelnen Protokollkomponenten und deren Funktionsweisen zu erläutern. Dabei werden die abstrakten Komponenten zuerst erläutert und dann folgen die Komponenten der unteren Schichten, wie der Netzwerkschicht. Weiterhin werden die einzelnen Schritte des Startup Mechanismus detailliert erläutert und auf die Besonderheiten der […]
Diese Arbeit beschäftigt sich auf den folgenden Seiten mit dem zukünftigen Übertragungsstandard im automobilen Bereich, mit FlexRay. Dabei liegen die Schwerpunkte dieser Arbeit im Übertragungsprotokoll und den einzelnen Protokollfunktionen von FlexRay. Die technischen Spezifikationen und Leistungsdaten, sowie die Hauptanwendungsgebiete von FlexRay werden in dieser Arbeit nur sehr kurz und oberflächlich im Kapitel 2 angesprochen. Wer noch keine Vorkenntnisse zu FlexRay besitzt, sollte sich als Einführung in die Thematik, die Studienarbeit von Stefan Aschenbach [6] ansehen. Für das Verständnis der Kernpunkte dieser Arbeit ist es jedoch nicht erforderlich, sich in andere Literatur einzuarbeiten. Falls doch, dann wird an den entsprechenden Stellen explizit auf die externen Literaturstellen verwiesen.
Als Grundlage für diese Arbeit diente hauptsächlich die FlexRay Protocol Specification in Version 2.1 da es zu FlexRay noch immer sehr wenige Publikationen gibt. Die meisten Veröffentlichungen zu FlexRay sind sehr produktspezifisch und weichen häufig von den originalen Vorgaben ab. Dennoch wurden für diese Arbeit auch Veröffentlichungen anderer Personen verwendet, wobei die Informationen aus diesen Dokumenten sehr genau überprüft wurden, um eine Vermischung von Standards und Eigenentwicklungen zu vermeiden.
Die Kernaufgaben dieser Diplomarbeit liegen beim Cluster Startup Mechanismus im Kapitel 3, bei der Synchronisation der einzelnen Nodes im FlexRay im Kapitel 4, sowie bei der Bestimmung der globalen und lokalen Parameter, um eine reibungslose Kommunikation zu gewährleisten, im Kapitel 6. Gestützt werden die Analysen und Formeln dieser Arbeit durch ein im Rahmen dieser Diplomarbeit entwickeltes Modell, welches die Kommunikation bei FlexRay darstellt. Dieses Modell wird im Kapitel 5 und im Kapitel 9 detailliert erklärt. Zum einfacheren Verständnis der Modelle gibt es im Kapitel 9 einen Einschub zu den Grundlagen der Specification and Description Language (SDL) sowie zu den Grundlagen von MLD im Kapitel 9.
Ziel dieser Arbeit ist es, dem Leser Schritt für Schritt und sehr detailliert die einzelnen Protokollkomponenten und deren Funktionsweisen zu erläutern. Dabei werden die abstrakten Komponenten zuerst erläutert und dann folgen die Komponenten der unteren Schichten, wie der Netzwerkschicht. Weiterhin werden die einzelnen Schritte des Startup Mechanismus detailliert erläutert und auf die Besonderheiten der […]
Leseprobe
Inhaltsverzeichnis
Jirko Zessack
Modellierung von speziellen Komponenten des FlexRay-Protokolls
ISBN-10: 3-8324-9967-9
ISBN-13: 978-3-8324-9967-9
Druck Diplomica® GmbH, Hamburg, 2006
Zugl. Technische Universität Ilmenau, Ilmenau, Deutschland, Diplomarbeit, 2006
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica GmbH
http://www.diplom.de, Hamburg 2006
Printed in Germany
Modellierung spezieller Komponenten des FlexRay - Protokolls
Danksagung
Danksagung
Im Folgenden möchte ich mich bei allen Personen bedanken, die mich bei der Arbeit
unterstützt haben und zum Gelingen beigetragen haben. Besonderer Dank gilt
hierbei:
Herr Prof. Dr.-Ing. habil W. Fengler
dafür, dass er diese Arbeit betreut hat und es mir überhaupt erst
ermöglicht hat, diese Arbeit zu erstellen.
Herr Dipl.-Inf. Sven Köhler
für die sehr gute fachliche Unterstützung, dafür dass er immer Zeit für
mich hatte und auch dafür, dass er für mich immer erreichbar war.
Herr Thomas Lohfelder
für die Unterstützung bei Problemen mit MLDesigner 2.6
Mission Level Design GmbH (MLD)
für die kostenlose Lizenz zur Nutzung von MLDesigner über die
gesamte Dauer meiner Diplomarbeit.
Herr Dipl.-Pol. Ruslan Schmole
für die Unterstützung bei der Fehlerkorrektur dieser Arbeit
Herr Steffen Lerm
für die Unterstützung bei Problemen jeglicher Art sowie für das
Korrekturlesen dieser Arbeit
Bei meiner Familie und allen Bekannten
dafür, dass sie mir die nötige Zeit für diese Arbeit gegeben haben.
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
III
Modellierung spezieller Komponenten des FlexRay - Protokolls
Erklärung
Erklärung
Hiermit versichere ich, dass ich diese Diplomarbeit selbständig verfasst und nur die
angegebenen Quellen und Hilfsmittel verwendet habe. Alle von mir aus anderen
Veröffentlichungen übernommenen Passagen sind als solche gekennzeichnet.
Ilmenau, 2006-10-02
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
V
Modellierung spezieller Komponenten des FlexRay - Protokolls
Inhaltsverzeichnis
Inhaltsverzeichnis
1. Vorwort
01
2. Motivation
03
2.1. Anwendungsgebiet
03
2.2. Technische Daten und Leistungsfähigkeit im Überblick
05
2.3. FlexRay Konsortium
12
3. Protokollkomponenten von FlexRay
15
3.1. Komponentenüberblick und das ISO/OSI Referenzmodell
15
3.2. Aufgabe und Aufbau der einzelnen Komponenten
20
3.2.1. Komponenten mit Schicht 7 Funktionalität
21
3.2.1.1. CHI Controller Host Interface
21
3.2.2. Komponenten mit Schicht 2 Funktionalität
23
3.2.2.1. POC Protocol Operation Control
24
3.2.2.2. Synchronisationsteil
27
3.2.2.3. FSP Frame and Symbol Processing
27
3.2.2.4. MAC Media Access Control
31
3.2.3. Komponenten mit Schicht 1 Funktionalität
34
3.2.3.1. CoDec Code and Decode
35
4. Synchronisation und Cluster - Startup
37
4.1. Rahmenformat von FlexRay
37
4.2. Synchronisation
40
4.2.1. MTG Macrotick Generation Process
46
4.2.2. CSP Clock Synchronization Process
47
4.2.3. CSS Clock Synchronization Startup Process
50
4.3. Startup
51
4.3.1. Startup Prepare
56
4.3.2. Integration Listen
56
4.3.3. Coldstart Listen
57
4.3.4. Coldstart Collision Resolution
57
4.3.5. Coldstart Consistency Check
58
4.3.6. Coldstart GAP
58
4.3.7. Initialize Schedule
59
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
VII
Modellierung spezieller Komponenten des FlexRay - Protokolls
Inhaltsverzeichnis
4.3.8. Integration Coldstart Check
59
4.3.9. Coldstart Join
59
4.3.10. Integration Consistency Check
60
4.3.11. Abort Startup
60
5. Abstraktes Modell eines FlexRay - Node
61
5.1. Was kann das Modell
61
5.2. Modellbeschränkungen und Abweichungen zur Realität
62
5.3. Modellverwendung
66
6. Erkenntnisse aus dem Modell
77
6.1. Midpoint in NIT und gOffsetCorrectionStart
78
6.2. CRC Frameberechnung
81
6.3. Taktabweichung
83
6.4. Offset- und Anstiegskorrektur
86
6.5. Verwendung von 2 oder mehr als 15 Synchronisationsnodes
87
6.6. Zusammenfassung
88
7. Zusammenfassung
89
7.1. Das Buskonzept
89
7.2. Echtzeitverhalten
91
7.2.1. Zyklenaufbau
91
7.2.2. Alarmsteuerung
92
7.2.3. Fehlerüberwachung
93
8. Ausblick und Einschätzung
95
Anhang A Grundlagen
97
A.1 MLD Grundlagen
97
A.2 SDL Grundlagen
99
Anhang B Modellstruktur
101
B.1 Struktur der Modellierung
101
B.1.1
CHI
117
B.1.2
POC
118
B.1.3
FSP
121
B.1.4
MAC
124
B.1.5
CoDec
126
Anhang C Datenstrukturen des Modells
129
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
VIII
Modellierung spezieller Komponenten des FlexRay - Protokolls
Abbildungsverzeichnis
Abbildungsverzeichnis
2.2.1
Prinzip der Differenzspannung [2]
7
2.2.2
Passiver Bus mit Channel 2 zur Redundanzerzeugung [11]
8
2.2.3
Sterntopologie mit Redundanz [11]
8
2.2.4
Vor- und Nachteile von Bus- und Sterntopologie [9]
9
2.2.5
Buszuteilung beim TDMA
10
3.1.1
OSI Referenzmodell der ISO
16
3.1.2
Schichtenarchitektur vs. OSI bei FlexRay
18
3.1.3
Ebenenmodell einer Automatisierungsanlage der PDV [15]
19
3.2.1
FlexRay Protokollabschnitte mit zusammengefasster Sync [2]
20
3.2.1.1
Zuordnung Schicht 7 in die FlexRay Protokollhierarchie [1]
21
3.2.2.1
Zuordnung Schicht 2 in die FlexRay Protokollhierarchie [1]
23
3.2.2.1.1 POC Zustandsautomat [2]
25
3.2.2.3.1 abstrakter Zustandsautomat vom FSP [2]
30
3.2.2.4.1 Darstellung der Grenzen eines Zyklus [2]
31
3.2.2.4.2 Zustandsmaschine MAC Prozess im statischen Segment [2]
32
3.2.2.4.3 Zustandsmaschine MAC Prozess im dynamischen Segment
[2]
33
3.2.3.1
Zuordnung der Schicht 1 in die FlexRay Protokollhierarchie
[1]
34
4.1.1
MTS und CAS Symbol auf Bitebene [2]
37
4.1.2
Frameaufbau im dynamischen Segment auf Bitebene [2]
38
4.1.3
FlexRay Header Segment [1]
38
4.2.1
Protokollkomponenten von FlexRay [2]
40
4.2.2
Hierarchische Darstellung der FlexRay Synchronisation [9]
41
4.2.3
Messung, Offset- und Anstiegskorrektur [2]
45
4.2.2.1
SDL Diagramm des CSP Prozesses [2]
48
4.3.1
Wichtigste Protokollabschnitte für den Startup [2]
51
4.3.2
Ablauf eines Cluster Startup [2]
52
5.3.1
FlexRay SyncProzess
67
5.3.2
Konfigurationsvariablen und Konstanten eines FlexRay Node
69
5.3.3
Schaltflächen für die Simulationssteuerung
71
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
IX
Modellierung spezieller Komponenten des FlexRay - Protokolls
Abbildungsverzeichnis
5.3.4
Busausgabe und CE-Start Signal
72
5.3.5
Offsetkorrektur von Node Nummer 1
73
5.3.6
Anstiegskorrektur von Node Nummer 3
73
5.3.7
Statusfenster für Node Nummer 10
74
5.3.8
Fehlerausgabe über CHI von Node 10
75
A.2.1
SDL Darstellung zur Beschreibung von ZM's
100
B.1.1
Zusammengefasste Synchronisationskomponenten
101
B.1.2
MTG Prozess im MLD
103
B.1.3
,,Sub-Test-Condition" zur Auswertung von Boolean Variablen"
104
B.1.4
CSS Prozess im MLD
105
B.1.5
,,Sub-Test-Value-Memory" zum Vgl. von Steuervariablen mit
vordefinierten Eingabewerten
106
B.1.6
,,Sub-MDS-IntegrationSuccessful"
106
B.1.7
,,Sub-DSM-StartClock"
107
B.1.8
,,Sub-DSM-vRF"
107
B.1.9
relative Ebene 0 des CSP
108
B.1.10
,,FlexRay-Sync-Node-Syncmodul-CSP-IntegrationControl"
109
B.1.11
,,FlexRay-Sync-Node-Syncmodul-CSP-InitMeasurement"
110
B.1.12
,,FlexRay-Sync-Node-Syncmodul-CSP-Measurement"
111
B.1.13
,,Sub-write-zsDevTable"
112
B.1.14
,,Sub-read-zsDevTable"
112
B.1.15
,,FlexRay-Sync-Node-Syncmodul-CSP-CalcRate"
113
B.1.16
,,FlexRay-Sync-Node-Syncmodul-CSP-CalcOffset"
114
B.1.1.1
SDL für das CHI (nicht standardisiert)
118
B.1.2.1
Startinitialisierung der POC
118
B.1.2.2
Reaktion auf Porteingaben in verschiedenen Zuständen
119
B.1.2.3
POC!normal_active Zustand
119
B.1.2.4
Überprüfungsmakro für POC!normal_active
120
B.1.2.5
POC!normal_passive
120
B.1.2.6
POC!normal_passive Überprüfungsmakro
121
B.1.3.1
Startzustand des FSP
121
B.1.3.2
Makro ,,Wait for CE-Start"
122
B.1.3.3
Makro ,,Wait for Chirp"
122
B.1.3.4
Makro ,,Decoding"
122
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
X
Modellierung spezieller Komponenten des FlexRay - Protokolls
Abbildungsverzeichnis
B.1.3.4
Makro ,,Decoding"
122
B.1.3.5
Makro ,,Process Startupframes"
123
B.1.3.6
Makro ,,Process static frame"
123
B.1.3.7
Makro ,,Slot Segment End"
123
B.1.3.8
Makro ,,Wait for Transmission End"
124
B.1.4.1
MAC Prozess Hauptteil
124
B.1.4.2
MAC Makro ,,Static Segment"
125
B.1.4.3
MAC Makro ,,Assemble Frame in Static Segment"
125
B.1.5.1
CoDec Prozess Hauptzustand
126
B.1.5.2
CoDec Makro ,,Decode"
126
B.1.5.3
CoDec Makro ,,Transmit"
127
B.1.5.4
CoDec Channel Überwachung
127
B.1.5.5
CoDec auf Datenbeginn warten
127
B.1.5.6
CoDec Subprozess BitSTRB
128
B.1.5.7
BitSTRB Submakro für Chirp CE-Start Timing
128
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
XI
Modellierung spezieller Komponenten des FlexRay - Protokolls
Tabellenverzeichnis
Tabellenverzeichnis
2.1.1
Anforderungen von Fahrzeugkomponenten an den ent-
sprechenden zu verwendenden Bus
5
2.2.1
Vor- und Nachteile von FlexRay bezogen auf CAN und MOST
11
2.3.1
Core Mitglieder des FlexRay Konsortiums
12
2.3.2
Premium Mitglieder des FlexRay Konsortiums
13
2.3.3
Standard Mitglieder des FlexRay Konsortiums
14
3.1.1
Anforderungen an Systeme der PDV [15]
19
3.2.2.1.1 wichtige Steuerkommandos für die POC
26
3.2.2.3.1 Eigenschaften, die durch das FSP geprüft werden
29
3.2.2.3.2 Trigger Ereignisse für das FSP
30
3.2.2.4.1 Trigger Ereignisse für MAC
34
5.2.1
Modellbeschränkungen
65
5.3.1
Mögliche Zustände im Startup - Makro
76
6.1
Wichtige Parameter, Variablen und Konstanten
77
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
XIII
Modellierung spezieller Komponenten des FlexRay-Protokolls
Abkürzungsverzeichnis
Abkürzungsverzeichnis
µT
Microtick
A
Bezeichnung für die beiden FlexRay Channel (A und B)
ABS
Anti Blockier System
AP
Actionpoint
(a)zykl.
(a)zyklisch
B
Bezeichnung für die beiden FlexRay Channel (A und B)
BITSTRB
Bit Strobing Process
BSS
Byte Start Sequence
CAS
Collision Avoidance Symbol
CE
Connection Element
Ch
Channel
CHI
Controller Host Interface (Protokollabschnitt)
ChIRP
Channel Idle Recognition Point
CN
Coldstart Node
CoDec
Coding & Decoding (Protokollabschnitt)
Const
Konstante
CRC
Cyclic Redundancy Code
CSP
Clock Synchronization Process (Protokollabschnitt)
CSS
Clock Synchronization Startup Process (Protokollabschnitt)
dec
Dekrementieren (Rechenoperation, -1)
DTS
Dynamic Trailing Sequence
ESP
Elektronisches Stabilitätsprogramm
FCN
Following Coldstart Node
FES
Frame End Sequence
FSP
Frame and Symbol Processing
FSS
Frame Start Sequence
FTDMA
Flexible Time Division Multiple Access
ID
Identifier
IN
Integrating Node
inc
Incrementieren (Rechenoperation, +1)
LCN
Leading Coldstart Node
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
XV
Modellierung spezieller Komponenten des FlexRay-Protokolls
Abkürzungsverzeichnis
MAC
Media Access Control (Protokollabschnitt)
MC
Mikrocontroller
mod
Modulo (Rechenoperation Restrechnen)
MT
Macrotick
MTG
Macrotick Generation Process (Protokollabschnitt)
MTS
Media Access Test Symbol
NIT
Network Idle Time
O(...)
Komplexitätsoberschranke für Algorithmen
OSC
Oscillator Microtick Clock
PDV
Prozessdatenverarbeitung
POC
Protocol Operation Control
PP
Payload Preamble
pTRP
Primary Time Reference Point
RxD
Receive Data Signal
RxEN
Receive Data Enable Signal
SDL
Specification and Description Language
sTRP
Secondary Time Reference Point
SuF
Startup Frame
SuFI
Startup Frame Indicator
SyF
Synchronization Frame
SyFI
Synchronization Frame Indicator
TDMA
Time Division Multiple Access (Buszugriffsverfahren)
TRP
Time Reference Point
TSS
Transmission Start Sequence
TxD
Transmit Data Signal
TxEN
Transmit Data Enable Signal
Var
Variable
WUP
Wakeup Pattern
WUS
Wakeup Symbol
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
XVI
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 1
1. Vorwort
Diese Arbeit beschäftigt sich auf den folgenden Seiten mit dem zukünftigen
Übertragungsstandard im automobilen Bereich, mit FlexRay. Dabei liegen die
Schwerpunkte dieser Arbeit im Übertragungsprotokoll und den einzelnen
Protokollfunktionen
von
FlexRay.
Die
technischen
Spezifikationen
und
Leistungsdaten, sowie die Hauptanwendungsgebiete von FlexRay werden in dieser
Arbeit nur sehr kurz und oberflächlich im Kapitel 2 angesprochen. Wer noch keine
Vorkenntnisse zu FlexRay besitzt, sollte sich als Einführung in die Thematik, die
Studienarbeit von Stefan Aschenbach [6] ansehen. Für das Verständnis der
Kernpunkte dieser Arbeit ist es jedoch nicht erforderlich, sich in andere Literatur
einzuarbeiten. Falls doch, dann wird an den entsprechenden Stellen explizit auf die
externen Literaturstellen verwiesen.
Als Grundlage für diese Arbeit diente hauptsächlich die ,,FlexRay Protocol
Specification" in Version 2.1 [2], da es zu FlexRay noch immer sehr wenige
Publikationen gibt. Die meisten Veröffentlichungen zu FlexRay sind sehr
produktspezifisch und weichen häufig von den originalen Vorgaben ab. Dennoch
wurden für diese Arbeit auch Veröffentlichungen anderer Personen verwendet, wobei
die Informationen aus diesen Dokumenten sehr genau überprüft wurden, um eine
Vermischung von Standards und Eigenentwicklungen zu vermeiden.
Die Kernaufgaben dieser Diplomarbeit liegen beim Cluster Startup Mechanismus
im Kapitel 3, bei der Synchronisation der einzelnen Nodes im FlexRay im Kapitel 4,
sowie bei der Bestimmung der globalen und lokalen Parameter, um eine
reibungslose Kommunikation zu gewährleisten, im Kapitel 6. Gestützt werden die
Analysen und Formeln dieser Arbeit durch ein im Rahmen dieser Diplomarbeit
entwickeltes Modell, welches die Kommunikation bei FlexRay darstellt. Dieses
Modell wird im Kapitel 5 und im Kapitel 9 detailliert erklärt. Zum einfacheren
Verständnis der Modelle gibt es im Kapitel 9 einen Einschub zu den Grundlagen der
,,Specification and Description Language" (SDL) sowie zu den Grundlagen von MLD
im Kapitel 9.
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
1
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 1
Ziel dieser Arbeit ist es, dem Leser Schritt für Schritt und sehr detailliert die einzelnen
Protokollkomponenten und deren Funktionsweisen zu erläutern. Dabei werden die
abstrakten Komponenten zuerst erläutert und dann folgen die Komponenten der
unteren Schichten, wie der Netzwerkschicht. Weiterhin werden die einzelnen Schritte
des Startup Mechanismus detailliert erläutert und auf die Besonderheiten der
Synchronisation eingegangen. Denn genau hier liegt der sehr große Vorteil von
FlexRay gegenüber anderen Übertragungsmechanismen.
Abschließend gibt es noch einen Hinweis zu Fachbegriffen, Fremdwörtern und
Abkürzungen. In dieser Arbeit wird, sofern möglich, die deutsche Sprache verwendet.
Jedoch ist es nicht immer möglich, alle Begriffe, Fachwörter und Eigennamen
sinnvoll aus dem Englischen in das Deutsche zu übersetzen. Aus diesem Grund, und
auch um eine Vermischung von deutschen und englischen Begriffen und daraus
resultierenden Inkonsistenzen zu vermeiden, werden alle Eigennamen für Module,
Protokollkomponenten und Variablen grundsätzlich in Englisch verwendet, so wie es
die Spezifikation von FlexRay vorsieht. Zu Beginn jedes entsprechenden Abschnitts
wird aber, sofern möglich, eine entsprechende Übersetzung angeben. Der Umgang
mit Abkürzungen erfolgt im Text sehr sparsam. Allerdings werden in Grafiken und
Tabellen aus Platzgründen sehr häufig spezifische aber auch nicht standardisierte
Abkürzungen verwendet. Die verwendeten Abkürzungen sind tabellarisch im
Abkürzungsverzeichnis auf Seite XV zu finden. Dabei wurde ebenfalls darauf
geachtet, dass die Abkürzungen zur offiziellen FlexRay Protokoll Spezifikation
konform sind.
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
2
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
3
2. Motivation
2.1 Anwendungsgebiete
Wie für unschwer zu erkennen, gewinnen technologische Neuerungen gerade im
Bereich Komfort und im Bereich von Sicherheitssystemen immer mehr an
Bedeutung. Beide Bereiche basieren in der Regel auf verteilten Systemen. Um
verteilte Systeme sinnvoll realisieren zu können, ist eine entsprechende
Kommunikationsstruktur
notwendig,
wodurch
die
einzelnen
Komponenten
miteinander verbunden werden können. In der Praxis gibt es derzeit viele
Kommunikationssysteme wie LIN, MOST, ByteFlight oder CAN, um nur einige
wenige zu nennen, die jeweils in bestimmten Aufgabengebieten eingesetzt werden.
Insbesondere im Automobilbereich wird heute eine große Zahl dieser verschiedenen
Bussysteme verwendet. Der Einsatz dieser vielen unterschiedlichen Systeme bringt
jedoch entscheidende Nachteile mit sich. So ist eine Kommunikation zwischen
verschiedenen Kommunikationsnetzen nur sehr schwierig realisierbar. Dazu sind
spezielle Zwischennetzsysteme nötig, die mit beiden Kommunikationsprotokollen und
beiden Übertragungsstandards zurechtkommen können und diese unterstützen.
Hinzu kommt das Problem der Erweiterbarkeit und der Skalierbarkeit. So sollte es bei
heutigen verteilten Systemen einfach möglich sein, größere Mengen an Baugruppen
an einen Bus anzuschließen bzw. Baugruppen nachträglich hinzuzufügen. Das hört
sich einfach an, ist es aber keinesfalls. Je mehr Komponenten an einen Bus
angeschlossen werden, umso mehr Daten müssen in möglichst kurzer Zeit über den
Bus übertragen werden. Dafür wiederum ist zum einen eine sehr hohe Bandbreite
erforderlich, zum anderen aber auch ein sehr gutes Übertragungskonzept um die
Daten kollisionsfrei, fehlerfrei und mit möglichst kurzer Übertragungszeit (Latenz)
über den Bus zu transportieren.
Die Entwicklung der elektronischen Komponenten im Automobilbereich verändert
sich ständig und wächst stark an. So gab es vor 10 Jahren kaum Fahrzeuge, die mit
Navigationssystemen, Bordcomputer und Fahrassistenzsystemen serienmäßig
ausgestattet waren. Es war zwar möglich, einige dieser Systeme teuer nachzurüsten,
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
4
aber eine direkte Kommunikation mit vorhandenen Fahrzeugkomponenten und mit
vorhandenen Aktor- und Sensorsystemen war nicht möglich. Zu Zeiten, als
Fahrzeuge lediglich elektrische Fensterheber und eine Klimaanlage hatten, gab es
aber auch noch keinen Bedarf für komplexe Datenübertragungstechniken. Diese aus
heutiger Sicht simplen elektrischen Systeme konnten ohne großen Kostenaufwand
über einfache, dedizierte Steuerleitung in das Fahrzeug integriert werden. Jedoch mit
Zunahme vieler kleiner Helfer wurden die Kabelbäume in den Fahrzeugen immer
größer und aufwendiger. Nicht nur das solche Verdrahtungen kostspielig und
fehleranfällig waren, auch das immer größer werdende Gewicht dieser
Verdrahtungsformen
förderte
die
Entwicklung
von
alternativen
Kommunikationsstrukturen. Zu Beginn der 90er Jahre, als die ersten aktiven
Fahrassistenzsysteme wie ESP und ABS in den Fahrzeugen verwendet werden
sollten, war ein entsprechendes schnelleres, fehlertoleranteres Bussystem
erforderlich. Als Quasistandard für den automobilen Bereich setzten sich ab 1989 die
verschiedenen Formen des CAN Bus (Controller Area Network Bus) durch. Dieser,
auf dem CSMA/CA Zugriffsverfahren basierende Bus, kam in den letzten Jahren in
fast allen Fahrzeugen zum Einsatz.
Aufgrund neuer Entwicklungen im Bereich der aktiven Fahrhilfen und
Fahrassistenzsysteme, die unter dem Schlagwort x-by-wire bekannt sind, stiegen
und steigen die Anforderungen an die Übertragungsstandards stark an. Damit ist ein
Einsatz von CAN in diesen zeitkritischen Systemen kaum noch möglich. So werden
von heutigen Übertragungstechniken Datenraten von 10MBit/s und mehr erwartet.
Außerdem benötigen die neuen x-by-wire Technologien meist sehr kurze
Reaktionszeiten, was sehr hohe Anforderungen an die Latenz eines Bussystems
stellt. Auch die immer sensibler werdenden Sensoren und die immer genauer
regelnden Aktoren verursachen mehr Datenaufkommen auf dem Bus und alles in
allem soll das Kommunikationsmedium der Zukunft einen einheitlichen Standard im
Automobilbereich bilden. Das heißt, es soll alle bisher existierenden Technologien
ablösen. Das bedeutet aber auch, dass sehr bandbreitenintensive Multimediadaten
über dieselben Kommunikationsnetze wie die zeitkritischen x-by-wire Technologien
übertragen werden müssen. Daher musste etwas grundlegend Neues entwickelt
werden.
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
5
Nach anfänglichen Entwicklungen einzelner Hersteller, wie ByteFlight von BMW, und
nach Problemen bei der Spezifikation von MOST, gründeten 1998 die drei
Automobilkonzerne BMW, Daimler-Chrysler und General Motors zusammen mit
Bosch, Motorola und Philips das FlexRay - Konsortium. Ziel dieser Vereinigung war
es, einen neuen einheitlichen Übertragungsstandard zu erschaffen, der die
bisherigen Übertragungstechniken ablösen kann, der den Anforderungen an
zukünftige Bussysteme gewachsen ist und der vor allem im mobilen Fahrzeugeinsatz
eine sehr gute Störsicherheit aufweisen kann. Außerdem sollte es ein offener
Standard werden, der allen Mitgliedern des Konsortiums zur Verfügung steht, um
somit
einen
system-
und
fahrzeugübergreifenden,
einheitlichen
Kommunikationsstandard schaffen zu können. Das führte im Jahr 2000 zur
Entwicklung von FlexRay.
Die folgende Tabelle zeigt die wichtigsten Anforderungen von Fahrzeugkomponenten
an das verwendete Übertragungsmedium.
x-by-Wire-Systeme
- Ausfallsicherheit
- Fehlereindämmung / -lokalisierung
Fahrwerk-Systeme
- zeitlicher Determinismus
Antriebs-Systeme
- hohe Bandbreite
Multitainment - Systeme
- sehr hohe Bandbreite
Nutzung als Basisnetz
- Skalierbarkeit
- Flexibilität
- hohe Bandbreiten
Tabelle 2.1.1 Anforderungen von Fahrzeugkomponenten an den entsprechenden zu
verwendenden Bus
2.2 Technische Daten und Leistungsfähigkeit im Überblick
Was aber ist nun so besonderes an FlexRay? Es sind keine einzelnen Features oder
Leistungsdaten, die FlexRay von der gesamten Masse abheben. FlexRay ist kein
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
6
technologisches Wunder. Es ist vielmehr ein gelungenes Kommunikationssystem,
insbesondere auf das Busprotokoll bezogen, was viele Features von anderen
Systemen übernommen hat und auf diesen basiert. Das Resultat ist ein sehr
ausgewogener Standard, welcher keine großen Schwächen aufweist und in nahezu
allen Bereichen mit den Konkurrenten wie Byteflight und MOST mithalten kann.
In diesem Abschnitt geht es im Folgenden um die technischen Spezifikationen und
Leistungsdaten, die allerdings nur kurz genannt und erläutert werden. Das
eigentliche Thema der Arbeit beginnt dann im Kapitel 3 mit den einzelnen
Komponenten des Protokolls von FlexRay.
Im Gegensatz zu den Konkurrenzprodukten, insbesondere zu CAN, hat FlexRay
einen Vorteil und zwar die garantierten Latenzzeiten. Diese werden durch die
Buszugriffstechniken TDMA bzw. FTDMA kalkulierbar und das ermöglicht Worst -
Case - Abschätzungen für Übertragungsverzögerungen. Da bei TDMA und FTDMA
in Zeitslots zyklisch gesendet wird, kann somit genau berechnet werden, wann im
schlechtesten Fall ein Datenframe von einem Knoten zum anderen übertragen wird.
Somit
können
sehr
zeitkritische
Systeme
besser
in
ein
bestehendes
Übertragungssystem integriert werden. Und wenn die Zykluslänge zeitlich zu lang
sein sollte, so gibt es dennoch Möglichkeiten, diese Systeme sinnvoll über FlexRay
zu betreiben. Das ist zum Beispiel einfach möglich, indem bestimmte Komponenten
in mehreren verschiedenen Slots senden dürfen. Ein weiterer Vorteil besteht in der
hohen Ausfallsicherheit von FlexRay (Robustheit). Diese basiert zum einen auf der
elektrischen Realisierung von Flexray, zum anderen auf dem FlexRay Busprotokoll.
An dieser Stelle sollen jedoch die Eigenschaften der elektrischen Realisierung
genügen. FlexRay unterstützt grundsätzlich die Verwendung von optischen und
elektrischen Medien. Die vorliegende Spezifikation stützt sich jedoch auf die
elektrische Realisierung über zwei Leitungen. Über diese beiden Leitungen je
Channel wird eine Differenzspannung übertragen. Diese wird bei den einzelnen
Knoten ausgewertet und entsprechend der Differenz zwischen beiden Leitungen wird
dann zwischen einer logischen Null und einer logischen Eins unterschieden. Erfolgen
nun Störungen auf diesen Bus, so erfolgen die Störsignale auf beide Leitungen
zeitgleich. Die Differenz bleibt annähernd gleich und das Signal kann trotz
Störeinfluss fehlerfrei erkannt werden. Das dazu verwendete Konzept wird in
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
7
Abbildung 2.2.1 dargestellt. Mehr Informationen zur elektrischen Spezifikation sind in
der FlexRay EPL Specification [3] sowie dem zugehörige Update [5] zu finden.
Termination
Transmitter
Receiver
Termination
Transmitter
Receiver
r
e
v
i
r
d
s
u
B
r
e
v
i
r
d
s
u
B
BP
BM
BP
BM
Abbildung 2.2.1 Prinzip der Differenzspannung
Ein weiterer Vorteil der zur Beseitigung von Störungen beiträgt, ist die Verwendung
von zwei getrennten Übertragungskanälen je FlexRay Knoten. Das heißt, nicht wie
bei derzeitigen Bussen üblich, wo nur ein Busanschluss verwendet wird, sondern
jeder FlexRay Node basiert auf zwei quasiparallelen Protokollstacks. Dass die
beiden Protokollstacks nicht völlig unabhängig sind, soll an dieser Stelle vorerst
keine Rolle spielen. Aufgrund der zwei getrennten Busanschlüsse sind somit
verschiedene neue Verdrahtungsformen realisierbar. Im Hinblick auf die verbesserte
Störanfälligkeit ist es möglich, beide Leitungen parallel zu verwenden und auf beiden
Bussen dieselben Daten zu übertragen. Damit arbeitet der zweite Bus redundant
zum ersten Bus. Dadurch können noch mehr Störungen auf dem Bus erkannt und
entsprechende Maßnahmen getroffen werden. Allerdings ist es nur bedingt möglich,
Fehler von FlexRay Knoten zu erkennen und es ist nicht möglich Fehler der
entsprechenden Anwendungen die über diesen Knoten sitzen zu erkennen oder zu
beheben. Eine Behebung von Fehlern in den FlexRay Knoten ist nur bedingt
möglich, weil die beiden Busanschlüsse über einen quasiparallelen Protokollstack
verfügen. Somit können nur Fehler erkannt werden, die in redundant arbeitenden
Abschnitten auftreten.
Ein weiterer Vorteil von FlexRay ist die flexible Gestaltung der Anschluss- und
Verdrahtungskonzepte. Wie zuvor schon erwähnt verfügen FlexRay Nodes im
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
8
Normalfall über zwei getrennte Businterfaces. Damit ist eine Vielzahl neuer
Verdrahtungsformen möglich, die zum einen zur Steigerung der Datenrate verwendet
werden können, zum anderen aber auch zur Erzeugung von Redundanz. FlexRay
erlaubt grundsätzlich zwei Verdrahtungsarten. Zum einen können alle Knoten in
Form eines passiven Busses verwendet werden, zum anderen ist auch eine
Sternverkabelung ähnlich wie beim Ethernet möglich. Beide Verkabelungsformen
bieten verschiedene Vor- und Nachteile. So führt ein Schaden am passiven Bus bzw.
an den Busleitungen zu einem Totalausfall es gesamten FlexRay Clusters. Fallen
jedoch einzelne Knoten aus, so stellt das kein Problem für die anderen
Busteilnehmer dar. Bei der Sternverkabelung wirkt sich eine beschädigte Busleitung
nur auf einen einzelnen Knoten aus.
Knoten
Redundanz
Linearer Bus
Kommunikations-
controller
Bus
Treiber
Abbildung 2.2.2 Passiver Bus mit Channel 2 zur Redundanzerzeugung
Allerdings gibt es hier einen Zentralen Sternkoppler, der bei einem Ausfall ebenfalls
zu einem Totalausfall führt. Um ein Ausfallrisiko bei beiden Topologien zu
minimieren, könnte bei beiden Verdrahtungsarten der zusätzliche FlexRay
Busanschluss zur Redundanz genutzt werden.
Um die Kosten und den Aufwand für eine Verkabelung möglichst gering zu halten,
können auch beide Topologien gemischt werden. So sind in einem Active - Star -
Netzwerk mehrere Sternkoppler möglich. Allerdings dürfen auf dem längsten Pfad
zwischen zwei FlexRay Knoten höchstens drei Sternkoppler vorkommen.
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
9
Knoten
Aktiver
Stern
Redundanz
Kommunikations-
controller
Bus Treiber und
Bus Guardian
Abbildung 2.2.3 Sternverkabelung mit zusätzlicher Redundanz
Ein weiterer Pluspunkt bei FlexRay besteht darin, dass der Bus über Busguardians,
spezielle Buswächter, überwacht werden kann. Somit können Fehlfunktionen
einzelner Knoten besser erkannt und eliminiert werden. Die Busguardians gehören
jedoch nicht zum FlexRay Kommunikationscontroller und sind deshalb nur der
Vollständigkeit halber erwähnt.
passive medium,
most experience,
cost e cient
Passives Medium,
einfache Verdrahtung
geringe Kosten
allows for
high data rates,
increases error
containment
Hohe Datenraten,
hohe Fehlertoleranz
höherer Aufwasnd,
höhere Kosten
reduced
wire-ss,
experience, cost
wenig Kabelaufwand,
sehr preiswert
tolerates one
faulty channel
hohe Fehlertoleranz,
hohe Geschwindigkeit
Single
channel
Single
channel
Dual
channel
Dual
channel
Bus
Bus
Multiple star
Multiple star
Electrical &
optical
elektrischer &
optischer
physikalischer layer
Abbildung 2.2.4 Vor- und Nachteile von Bus- und Sterntopologie
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
10
Damit sind die wichtigsten Eigenschaften von FlexRay, bezogen auf die elektrische
Spezifikatione genannt. Das ist jedoch bei weitem noch nicht alles. Der Hauptteil aller
Vorzüge von FlexRay liegt im Übertragungsprotokoll und der logischen Spezifikation
begründet. Alle Vor- und Nachteile von FlexRay zeigt die Tabelle 2.2.1 im Detail.
Dabei werden die Eigenschaften von FlexRay im Vergleich zu CAN dargestellt.
Wie bereits erwähnt basiert der Buszugriff bei FlexRay auf einem deterministischen,
zeitlich gesteuerten Verfahren. Dieses Verfahren heißt daher TDMA, Time Division
Multiple Access. Das bedeutet, dass alle an den Bus angeschlossenen Knoten in
jeweils einem für sie speziell zugeteilten Zeitslot senden. Der Determinismus wird
dadurch erreicht, dass der Zugriff zyklisch und zu festen Zeiten geschieht. Es ist
dadurch immer vorhersagbar, wann und wie lang ein bestimmter Knoten den Bus
verwenden darf. Damit ist es möglich, Verzögerungen für bestimmte Daten zu
bestimmen. Durch geeignete Konfiguration der Protokollparameter eines oder aller
FlexRay Nodes ist es so möglich, bestimmte Eigenschaften, die benötigt werden,
künstlich zu erzeugen. Das angesprochene FTDMA Verfahren ist vom Prinzip her
genauso aufgebaut, nur dass die Zeitslots keine konstante Länge besitzen. Somit ist
bei FTDMA die Ausnutzung der verfügbaren Bandbreite im Mittel immer besser als
bei einem statischen Verfahren. Allerdings sind bei FTDMA die Latenzzeiten bei
Worst Case Betrachtungen weit größer. Aus diesem Grunde verwendet FlexRay
eine Mischung aus TDMA im statischen Übertragungsteil und FTDMA im
dynamischen Übertragungsteil. Die folgende Grafik zeigt die Zugriffssteuerung in
einfacher Form beim TDMA.
A B C A D B B D C C
t
Start
t
Ende
Sendeslots der Nodes
Abbildung 2.2.5 Buszuteilung beim TDMA
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
11
Eigenschaft
CAN
Flexray
Topologie
-Stern, Bus, Ring
-Multimaster
-Buslänge 1km
-Stern, Bus (kein Ring)
-Knoten gleichberechtigt*
-Buslänge 1km**
Zugriffsverfahren
-CSMA/CA
-Busarbitrierung nötig
-ereignisgesteuert
-TDMA und FTDMA
-keine Arbitrierung
-zeitgesteuert***
Übertragung
-asynchron
-asynchron + synchron
Übertragungszeiten
-echtzeitfähig
-nicht deterministisch
-keine Latenz bei CSMA
-bis max. 1MBit/s
-echtzeitfähig
-deterministisch
-garantierte Latenz
-bis 20MBit/s****
Adressierung
-nachrichtenorientiert
-kein Routing
-keine Node-Adressierung
-nachrichtenorientiert
-kein Routing
-keine Node-Adressierung
Synchronisation
-keine (außer TTCAN)
-zentrale Zeitgenerierung
-globale Zeit
-dezentr. Zeitgenerierung.
Sonstiges
-kein vollständiges Power-
management
-Powermanagement
vollständig implementiert
*Alle Knoten dürfen in zugeteiltem Slot den Bus exklusiv verwenden ohne dass sie
von anderen Knoten eine Erlaubnis oder Anfrage benötigen
**Die Buslänge variiert und steht im Verhältnis zur max. Datenübertragungsrate
***Der Buszugriff bei TDMA geschieht über Zeitslots. Allerdings gibt es auch die
Möglichkeit von ET - FlexRay. Standard ist aber der TT-Mode
****Die Übertragungsrate ist nach oben nicht beschränkt. Derzeitige Spezifikationen
legen aber einen Wert von 10MBit/s und pro Kanal fest.
Tabelle 2.2.1 Vor- und Nachteile von FlexRay bezogen auf CAN und MOST
Der Große Vorteil der Synchronisation liegt darin, dass zwar alle Nodes ein
einheitliches Verständnis von der globalen Zeit besitzen, jedoch keine Instanz
erforderlich ist, die diese Sicht auf die globale Zeit für alle Nodes anpasst. Die
Synchronisation erfolgt in jedem einzelnen Knoten über ein im Busprotokoll
implementiertes Schema, wonach permanent die Zeit aktualisiert und angepasst
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
12
wird. Sollte es dennoch zu Störungen bei der Buskommunikation kommen, und eine
Synchronisation nicht möglich sein, so ist das Busprotokoll immer noch in der Lage,
ganz normal weiterzuarbeiten, bis die Synchronisation wieder korrekt funktioniert.
Dies kann über mehrere Zyklen hinweg ausgeglichen werden. Sobald die
Synchronisation
wieder
startet,
werden
die
Werte
für
die
einzelnen
Synchronisationsparameter wieder neu berechnet und abgeglichen. Möglich ist der
Betrieb mit ausgefallener Synchronisation dadurch, dass bei FlexRay nicht nur der
Offset für den Zyklusbeginn berechnet wird, sondern zusätzlich dazu auch noch die
Zykluslänge. Dieser Vorgang wird im Folgenden als Anstiegskorrektur bezeichnet.
Aufgrund dieser Korrektur sind die Zykluslängen völlig unabhängig von der
eigentlichen Geschwindigkeit der Mikrocontroller. Mehr dazu jedoch in den folgenden
Kapiteln.
2.3 FlexRay Konsortium
Das FlexRay Konsortium wurde 2000 von den 5 Hauptmitgliedern gegründet. Zu
diesen fünf Hauptgründern gehörten anfangs die führenden Automobilhersteller
BMW, Daimler-Chrysler und General Motors. Als Chiphersteller im Konsortium waren
Philips und Motorola vertreten. Motorola gehört dem Konsortium heute jedoch unter
dem Namen Freescale an. Kurze Zeit später traten dann noch Volkswagen und
Bosch dem Konsortium als Core Member bei. Die Hauptmitglieder des FlexRay
Konsortiums sind aktiv an der Entwicklung von Protokollkomponenten und
Hardwarespezifikationen beteiligt. Sie sind berechtigt, die Entwicklungsrichtung
vorzugeben, sie dürfen aktiven Einfluss auf alle Entwicklungsschritte nehmen, und
sie können Ihre eigenen Wünsche und Features jederzeit einbringen. Außerdem
dürfen die Core Member natürlich die Technologie kostenlos und jederzeit
verwenden.
Core Mitglieder
BMW, Bosch, Daimler-Chrysler, Freescale Semiconductor, General Motors, Philips,
Volkswagen
Tabelle 2.3.1 Core Mitglieder des FlexRay Konsortiums
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
13
Zur Gruppe der Premium Mitglieder gehören eine Vielzahl weiterer wichtiger Firmen.
Unter anderem haben nahezu alle Automobilhersteller die Wichtigkeit und das
Potential von FlexRay erkannt und sind dem Konsortium meist als Premium
Mitglieder beigetreten. Diese Mitglieder müssen eine jährliche Nutzungsgebühr
bezahlen, dürfen aber bei Entscheidungen zur Entwicklung von FlexRay aktiv mit
abstimmen. Außerdem dürfen sie die Technologie jederzeit für Ihre eigenen Produkte
verwenden. Die genaue Mitgliederliste ist in Tabelle 2.3.2 dargestellt.
Premium - Mitglieder
3SOFT, austria microsystems AG, c&s group, DECOMSYS, Delphi Corporation,
Denso, Elmos Semiconductor AG, Fiat, Ford Motor Company, HONDA Motor Co.,
NISSAN MOTOR CO., Ltd., Renault, TTAutomotive Software GmbH, Tyco
Electronics Corporation, TZM, Vector-Informatik
Tabelle 2.3.2 Premium Mitglieder des FlexRay Konsortiums
Die dritte Gruppe von Mitgliedern sind die Mitglieder, welche einen jährlichen Betrag
zu entrichten haben und dafür die Technologie benutzen dürfen. Diese Mitglieder
haben jedoch keinen Einfluss auf die Entwicklung von FlexRay und auch kein
Mitspracherecht bei Entscheidungen im FlexRay Konsortium. Diese Mitglieder sind
in Tabelle 2.3.3 aufgelistet.
Die Inhalte der drei Tabellen haben dem Stand von Januar 2006! Die darin
enthaltenen Mitglieder können sich jederzeit ändern. Bis zum Jahr 2005 gab es im
FlexRay Konsortium vier Gruppen, seit Anfang 2006 wurden die beiden niedrigsten
Gruppen zu einer zusammengefasst.
Modellierung spezieller Komponenten des FlexRay - Protokolls
Kapitel 2
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
14
Standard Mitglieder
NIPPON SEIKI CO., LTD., ADVANCED DATA CONTROLS, CORP. (ADaC), Agilent
Technologies Inc., Aisin Seiki, Alpine Electronics (Europe) GmbH, Analog Devices,
ARC Seibersdorf research GmbH, AVL List GmbH, Berner & Mattner Systemtechnik
GmbH, Bertrandt Ingenieurbüro GmbH, Calsonic Kansei Corporation, dSPACE,
EPCOS AG, ESG - Elektroniksystem und Logistik-GmbH, eSOL, Esterel
Technologies, ETAS, FTZ -Research and Technology Association, Fujitsu, FUJITSU
TEN Limited, G.i.N. mbH, GIGATRONIK, GÖPEL electronic GmbH, HELLA KGaA
Hueck & co., Hitachi, Ltd., HYUNDAI KIA MOTORS, IAV GmbH, IPETRONIK GmbH
& Co.KG, K2L, KEIHIN CORPORATION, Mitsubishi Electric, Movimento Automotive,
NEC Electronics Corporation, Preh Gmbh, Renesas Technology Europe GmbH,
RWTÜV Fahrzeug GmbH, Rücker AG, samtec, Softing AG, SUMITOMO ELECTRIC
INDUSTRIES, LTD., Sunny Giken Inc., Suzuki Motor Corporation, Synopsys, Takata
Tata Elxsi Limited, TDK, Texas Instruments, Tokai Rika, Toyota Tsusho Electronics
Corp., TRW Conekt, WÜRTH ELEKTRONIK eiSos GmbH & Co.KG, Xilinx, Yamaha
Motor Co., Ltd., Yazaki, Yokogawa
Tabelle 2.3.3 Standard Mitglieder des FlexRay Konsortiums
Modellierung spezieller Komponenten des FlexRay-Protokolls
Kapitel 3
3. Protokollkomponenten von FlexRay
3.1 Komponentenüberblick und ISO/OSI Referenzmodell
Ein Bus besteht gewöhnlich aus einzelnen Knoten, die über eine bestimmte Leitung
verbunden sind. Bei FlexRay kann diese Leitung entweder elektrisch oder optisch
realisiert werden. Die an den Bus angeschlossenen Komponenten benötigen daher
ein entsprechendes Interface, welches entweder für eine optische oder für eine
elektrische Leitung konzipiert wurde. Viel wichtiger und viel komplexer als die
eigentliche Hardwareschnittstelle ist die Protokollschnittstelle, die hinter einem
Buskommunikationsstandard steht. Diese Protokollfunktionen sind in den einzelnen
Knoten, im folgenden auch als Nodes bezeichnet, realisiert. Dabei kann die
Realisierung direkt als Hardware erfolgen oder als eine Software im Speicher eines
Busknotens. Wie das Protokoll realisiert wird, bleibt hierbei jedoch den einzelnen
Komponentenherstellern überlassen. Wichtig ist, dass die Funktionalität des FlexRay
Protokolls entsprechend der FlexRay Spezifikation [2] implementiert wird. Wenn
die Realisierung dem Standard entspricht, sollten bei der Verwendung der
Buskomponenten nur noch wenige Probleme auftreten.
Die Entwicklung und Realisierung eines Protokolls geschieht nach einem festen
Standardschema,
welches
von
der
ISO
(International
Organisation
for
Standardization) seit 1979 entwickelt und standardisiert wurde. Es handelt sich dabei
um das OSI Referenzmodell (Open Systems Interconnection Reference Model).
Dieses Modell schreibt eine 7 Schichten Architektur vor, bei der übereinander
angeordnete Schichten jeweils nur mit Ihren direkten Nachbarn kommunizieren
sollen und bestimmte Dienste für Ihre Nachbarn erbringen können. Bei der
Realisierung eines Protokolls für Busse der Feldebene ist es außerdem nicht
erforderlich, dass alle der 7 Schichten im Protokollstack implementiert sind.
Grundsätzlich werden die Schichten 1 und 2 für die Kommunikation benötigt, alle
anderen Schichten dienen vorrangig dem Routing, der protokollgestützten Fehler-
und Reihenfolgeerkennung sowie der Vorbereitung der Daten von und für spezifische
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
15
Modellierung spezieller Komponenten des FlexRay-Protokolls
Kapitel 3
Anwendungen. FlexRay als Feldbus der gehobenen Leistungsebene basiert auf den
erforderlichen Schichten 1 und 2, und unterstützt zusätzlich die FlexRay
verwendenden Anwendungen durch eine angedeutete Schicht 7 Funktionalität. Die
Schichten 3, 4 ,5 und 6 sind nicht vorhanden.
Physical
Data Link
Network
Transport
Session
Presentation
A
lication
7
6
5
4
3
2
1
pp
7
Applicationprocess
Abbildung 3.1.1 OSI Referenzmodell der ISO
Die Schicht 1 im OSI Referenzmodell dient der Spezifikation der verwendbaren
Übertragungsmedien. Mittels der Schicht 1 erfolgt der bitweise Zugriff auf das
Medium. Die Schicht 1 besitzt jedoch keine Funktionalität, um Zugriffe auf ein
gemeinsames Medium zu steuern. Das heißt, Schicht 1 kann einzelne Bits auf das
Medium schreiben bzw. davon lesen, wenn dies durch eine höhere Schicht
angeordnet bzw. erlaubt wird.
Die Schicht 2 steuert den Buszugriff, im Fall von FlexRay das (F)TDMA. Durch
Schicht 2 erfolgt die Auswertung von verschiedenen Parametern, anhand derer sie
entscheiden kann, wann und wie auf einen gemeinsamen Bus zugegriffen werden
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
16
Modellierung spezieller Komponenten des FlexRay-Protokolls
Kapitel 3
kann und darf. Die Schicht 2 bewältigt damit alle Aufgaben, die für den Buszugriff im
FlexRay Protokoll zuständig sind, die nicht in die Bitübertragung einzuordnen sind.
Die Schicht 3 wird von FlexRay nicht genutzt. Der Vollständigkeit halber erläutere ich
aber kurz die Funktion dieser und der darüber liegenden Schichten. Schicht 3 regelt
die Adressierung in einem Netzwerk bzw. auf einem Bus. Das heißt, wenn Daten an
einen bestimmten Knoten in einem Netz oder auf einem Bus gesendet werden
sollen, dann geschieht dies über Adressen, die in der Schicht 3 verarbeitet werden.
Bei FlexRay werden Knoten jedoch nicht direkt angesprochen. Die Nachrichten
werden nicht an bestimmte Empfänger gesendet, sondern als eine Art Broadcast
Nachricht auf den Bus geschrieben. In den Nachrichten ist ein spezieller Identifier
enthalten, anhand welchem die empfangenden Knoten feststellen können, ob die
empfangene Nachricht für sie wichtig ist. Es ist bei FlexRay also keine Adressierung
erforderlich. Das hat zwei entscheidende Vorteile. Zum einen ist der Bus jederzeit
ohne Neukonfiguration von bereits angeschlossenen Knoten erweiterbar und zum
anderen wird durch ein fehlendes zeitaufwendiges Routing die Echtzeitfähigkeit
verbessert. Genutzt wird die Schicht 3 zum Beispiel beim IP Protokoll beim Ethernet.
Die
Schicht
4
dient
hauptsächlich
der
Erkennung
von
verlorenen
Nachrichtenpaketen, dem Sortieren von Multi Frame Messages sowie speziellen
erweiterten Adressierungsformen wie dem Multicast. Wobei letzteres zwischen
Schicht 3 und 4 eingeordnet werden sollte. Messages, die über mehrere Frames
groß sind, gibt es bei FlexRay nicht. Per Definition muss die Slotgröße bei FlexRay
so definiert werden, dass die längsten Nachrichtenpakete in einem Rahmen
übertragen werden können. Damit entfällt das Sortieren und Zusammensetzen dieser
Pakete. Verwendung findet Schicht 4 Funktionalität vor allem beim TCP Protokoll.
Die Schichten 5 und 6 dienen dem Session Management sowie der Bereitstellung
von speziellen anwendungsorientierten Protokollen. Da FlexRay keine direkte
Adressierung verwendet, gibt es bei FlexRay auch keine Ende zu Ende
Verbindungen zwischen Knoten. Damit ist kein Session Management erforderlich.
Die Schicht 7 dient der Bereitstellung von einzelnen Datenstrukturen, um die
Konfiguration und die Nutzung der Protokollfunktionen zu erleichtern. Außerdem
Inventarisierungsnummer: 2006-07-10/070/IN00/2231
17
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2006
- ISBN (eBook)
- 9783832499679
- ISBN (Paperback)
- 9783838699677
- DOI
- 10.3239/9783832499679
- Dateigröße
- 3.1 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Technische Universität Ilmenau – Fakultät für Informatik und Automatisierung, Rechnerarchitektur / Rechnernetze
- Erscheinungsdatum
- 2006 (November)
- Note
- 1,1
- Schlagworte
- flexray protokoll startup mldesigner fahrzeugvernetzung
