Protokollfamilie zur universellen Steuerdatenkommunikation in

Protokollfamilie
zur universellen Steuerdatenkommunikation
in heterogenen Netzwerkumgebungen
DISSERTATION
zur Erlangung des akademischen Grades eines
DOKTOR-INGENIEURS
(DR.-ING.)
der Fakultät für Ingenieurwissenschaften und Informatik
der Universität Ulm
von
DIPL.-ING. ANDREAS MICHAEL WALTER SCHMEISER
AUS HEIDENHEIM AN DER BRENZ
1. Gutachter:
Prof. Dr. Hans Peter Großmann
2. Gutachter:
Prof. Dr. Dr. Wolfgang Minker
Amtierender Dekan: Prof. Dr. Helmuth Partsch
Ulm, 30. Juli 2007
II
Danksagung
Zuallererst möchte ich Herrn Prof. Dr. Hans Peter Großmann danken, der großes Vertrauen
in mich gesetzt, meinen Themenvorschlag angenommen und betreut hat und mir somit diese
Promotion ermöglichte. An seinem Institut mit so viel Freiheit für Forschung und Lehre tätig
zu sein, war für mich eine sehr prägende und geschätzte Erfahrung.
Herrn Prof Dr. Dr. Wolfgang Minker danke ich recht herzlich, dass er das Zweitgutachten für
meine Dissertation übernommen hat. Gerade in der Endphase unterstützte er mich mit hilfreichen Hinweisen und motivierenden Worten.
Das gute Umfeld am Institut für Organisation und Management von Informationssystemen war
ebenfalls wichtig und entscheidend für die erfolgreiche Arbeit. Insbesondere möchte ich mich
hiermit namentlich bei meinen Kollegen und Freunden Matthias Rabel, Nashwa Abdel-Baki,
Yvonne Günter und Bernhard Wiegel für die angenehme Zusammenarbeit bedanken.
Meinen Eltern danke ich für eine vielfältige Unterstützung, die mir das Studium der Elektrotechnik und die anschließende Promotion überhaupt erst ermöglicht haben.
III
IV
Inhaltsverzeichnis
1
Einleitung
1
2
Stand der Technik
3
2.1
Feldbussysteme in verschiedenen Anwendungsbereichen . . . . . . . . . . . .
3
2.1.1
Automobiltechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Industrieautomatisierung . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.3
Gebäudetechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Heterogene Netzstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
Ansätze für höhere Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3
Konzept der Protokollfamilie
13
3.1
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2
Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.3
Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.1
Programmierschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3.2
Hierarchische Protokollfamilie . . . . . . . . . . . . . . . . . . . . . .
18
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4
4
Definition der Protokollfamilie
25
4.1
Micro Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.1
Schnittstelle zu LIN . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.2
Schnittstelle zu CAN . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.3
Schnittstelle zu Bluetooth . . . . . . . . . . . . . . . . . . . . . . . .
36
V
VI
INHALTSVERZEICHNIS
4.1.4
5
Schnittstelle zu IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2
Micro Internet Control Message Protocol . . . . . . . . . . . . . . . . . . . .
46
4.3
Micro User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.4
Micro Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . .
52
4.4.1
Verbindungsorientierte Betriebsart . . . . . . . . . . . . . . . . . . . .
57
4.4.2
Transaktionsbasierte Betriebsart . . . . . . . . . . . . . . . . . . . . .
60
4.5
Micro Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.6
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.6.1
73
Demonstrationssystem
77
5.1
Realisierte Teilaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.1.1
Warenbuchungssystem . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.1.2
Basisfunktionen für das dynamische Routing . . . . . . . . . . . . . .
81
5.1.3
Interoperabilität zwischen MIP und IP . . . . . . . . . . . . . . . . . .
84
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.2
6
Analyse von Effektivität, Transferzeiten und Latenzzeiten . . . . . . .
Zusammenfassung und Ausblick
A Berechnungen
91
95
A.1 Effektivität und Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
A.1.1 LIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
A.1.2 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
A.1.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
A.1.4 IEEE 1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
A.1.5 Zum Vergleich: IP via Ethernet . . . . . . . . . . . . . . . . . . . . . . 100
A.2 Transferdauer und Latenzzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.2.1 LIN unconditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.2.2 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.2.3 Bluetooth DH1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.2.4 IEEE 1394 GASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
INHALTSVERZEICHNIS
VII
B Universalsteuergerät
105
B.1 Basis Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.2 IEEE 1394 Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.3 Prozessor Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
B.4 IEEE 1394 Physical Layer Module . . . . . . . . . . . . . . . . . . . . . . . . 109
B.5 E/A-Aufsatz Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
B.6 Power Line Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
B.7 LIN Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.8 Bluetooth Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.9 Ethernet Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.10 MiniMMI Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.11 Complex Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B.12 LIN Slave Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Abbildungsverzeichnis
119
Tabellenverzeichnis
123
Literaturverzeichnis
125
Veröffentlichungen
133
VIII
INHALTSVERZEICHNIS
Kapitel 1
Einleitung
Komplexe Automatisierungssysteme begegnen uns inzwischen alltäglich in den unterschiedlichsten Facetten. Als vernetzte elektronische Systeme spielen sie in den Anwendungsbereichen
Kraftfahrzeug, industrielle Automatisierung und Gebäudetechnik eine stetig zunehmende Rolle. Für die Vernetzung haben sich eine Vielzahl unterschiedlicher, spezialisierter Feldbusse etabliert. Jedes Bussystem ist für einen speziellen Einsatzzweck entwickelt worden und weist somit
spezifische Eigenschaften auf. Sogar innerhalb der jeweiligen Anwendungsdomänen kommen
nebeneinander verschiedene Netzwerke gleichzeitig zum Einsatz. Aufgrund dieser Spezialisierung ist auch in Zukunft keine Konvergenz der heterogenen Netzstruktur zu erwarten.
Die meisten Anwendungen setzen derzeit auf die unteren Übertragungsschichten des OSIModells auf. Dies erschwert spätere Änderungen oder Erweiterungen erheblich. Um einen organisierten Datenaustausch zu ermöglichen, existieren zwar mehrere Ansätze für höhere Protokolle. Jedoch sind diese Bestrebungen nur für bestimmte abgegrenzte Anwendungsbereiche
und/oder für bestimmte Feldbusse definiert worden. Eine allgemeingültige, universelle Lösung
ist bisher nicht existent.
In Kraftfahrzeugen und in technischen Anlagen ist ein Verbund mehrerer Netzwerksysteme
erforderlich, um die getrennten Teilsysteme mit ihren vielfältigen speziellen Aufgaben als produktives Ganzes miteinander zu betreiben. Darüber hinaus ist heutzutage der Übergang in die
Internet-Welt für die Ferndiagnose und -wartung ein weiterer wichtiger Aspekt. Zwischen den
grundlegend unterschiedlichen Netzen mit zueinander inkompatiblen und zudem nur bis auf
verschiedenen Schichten ausgeprägten Protokollen sind Übergangsknoten für den Datenaustausch notwendig. Entsprechend dem OSI-Modell muss die Konvertierung auf Applikationsebene geschehen, also mittels Gateways.
In Ermangelung einheitlicher Schnittstellen müssen folglich Automatisierungsgeräte und proprietäre Gateways jedesmal mit erheblichem Aufwand neu entwickelt werden.
Die vorliegende Arbeit befasst sich mit diesem bisher nicht zufriedenstellend gelösten Themenfeld vernetzter Automatisierungssysteme. Das Ziel besteht darin, eine Lösung für zukunftssichere Entwicklungen zum Steuerdatenaustausch in heterogenen Netzwerkumgebungen zu entwickeln. Trotz der Verwendung unterschiedlichster Feldbusse soll den Anwendungen eine gemeinsame Schnittstelle zur Verfügung gestellt werden. Darauf aufbauend können dann auch
vereinheitlichte Gateways entstehen. Weitere Aspekte sind einheitliche Transportdienste, ein
einheitliches Adressierungsschema, die Erreichbarkeit von Automatisierungsgeräten bei Aus1
2
KAPITEL 1. EINLEITUNG
fall von einzelnen Netzwerksegmenten in einem ausreichend vermaschten System, die Wegewahl unter Berücksichtigung der Dienstgüte (QoS – Quality of Service) in geeignet strukturierten Feldbusumgebungen und eine möglichst einfache Übergangsmöglichkeit in die InternetWelt.
Diese Dissertation übernimmt konzeptionell Nutzbares von der Internet-Protokollfamilie und
konzipiert davon ausgehend, nach entsprechender Anpassung auf die Automatisierungssysteme
und die dort eingesetzten eingebetteten Systeme, eine neue hierarchische Protokollfamilie für
die Steuerdatenkommunikation.
Für praktische Tests wurden Teilaspekte realisiert. Hierfür wurden Entwicklungsumgebungen
definiert und vielfältige Hardware- und Softwareentwicklungen, teilweise in Kooperation mit
der Industrie, geleistet.
Dieses Dokument gliedert sich wie folgt:
In Kapitel 2 erfolgt eine Übersicht mit dem derzeitigen Stand der Technik. Es wird kurz die
Geschichte und Motivation für die Vernetzung für Steuer-, Regelungs- und Automatisierungsaufgaben umrissen. Aufgeteilt nach den Anwendungsbereichen Automobiltechnik, Industrieautomatisierung und Gebäudetechnik werden bekannte Vertreter der Feldbussysteme vorgestellt.
Hierbei zeigen sich viele Parallelen bei der Entwicklung dieser Netzwerke. Weiterhin wird die
heterogene Netzstruktur, Ansätze für höhere Protokolle und die derzeitige Notwendigkeit für
spezialisierte Gateways aufgezeigt.
Das Konzept für die neu entwickelte Protokollfamilie zur universellen Steuerdatenkommunikation wird in Kapitel 3 entwickelt. Ausgehend von einer Zielsetzung mit einer Reihe von Anforderungspunkten und möglicher Anwendungsbeispiele werden zwei Lösungsansätze vorgestellt
und diskutiert. Die Vorteile überwiegen bei der hierarchischen Protokollfamilie nach dem OSIModell. Dieses Konzept wird weiter verfolgt.
Die Protokollfamilie für die Steuerdatenkommunikation ist im Stil eines Standards in Kapitel 4 definiert und in ihrer Funktion beschrieben. Die hierarchische Familie besteht aus dem
Vermittlungsschichtprotokoll, vier Schnittstellen zu weitverbreiteten Bussystemen und vier
Transportprotokollen. Abgeschlossen wird dieses Kapitel mit einem Vergleich zur InternetProtokollfamilie und der Analyse von Effektivität, Transferzeiten und Latenzzeiten unter Nutzung der zuvor ausgesuchten Feldbusse.
In Kapitel 5 wird ein Demonstrationssystem vorgestellt, das zum Test der entwickelten Protokolle dient. Drei Teilaspekte, die eine möglichst breite Palette der neuen hierarchischen Protokollfamilie abdecken, wurden exemplarisch umgesetzt und auf den Entwicklungsumgebungen
getestet.
Als typischer Vertreter für Knoten in einem embedded System wurde am Institut für Organisation und Management von Informationssystemen (OMI) eine Entwicklungsumgebung auf Basis
eines 16 Bit Mikrocontrollers selbst entwickelt. Der Anhang B gibt einen Überblick über das
sogenannte Universalsteuergerät.
Kapitel 2
Stand der Technik
Noch vor einigen Jahren wurden in Kraftfahrzeugen, aber auch in der industriellen Automatisierung und der Gebäudetechnik, nur vereinzelt Netzwerksysteme eingesetzt. Es war Stand
der Technik, analoge und binäre Signale von Sensoren und Aktoren Punkt-zu-Punkt in sogenannter paralleler Verdrahtung auszuführen. In den 80er Jahren hat die Entwicklungstätigkeit
für spezialisierte Netzwerke für Steuerungs-, Regelungs- und Automatisierungsaufgaben, sogenannte Feldbussysteme, verstärkt begonnen. Durch ihren Einsatz hat man sich folgende Vorteile
versprochen:
• Kosteneinsparung bei der Montage der Verkabelung
• Gewichtseinsparung
• Erhöhung der Zuverlässigkeit
• Verminderung des Wartungsaufwands
• Einfachere und effizientere Fehlerdiagnose
• Erhöhte Flexibilität der Gesamtanlage
• Einfache Zugangsmöglichkeit zu Geräten
• Parametrierbare Sensoren und Aktoren
• Messwerte und Stati von Sensoren/Aktoren überall verfügbar
• Möglichkeit für Redundanz
2.1
2.1.1
Feldbussysteme in verschiedenen Anwendungsbereichen
Automobiltechnik
Die ersten automotiven Entwicklungen hatten nur zum Ziel, Diagnose- und Konfigurationsaufgaben über zusätzliche serielle, digitale Schnittstellen durchzuführen [ISO89, ISO95]. Der
3
4
KAPITEL 2. STAND DER TECHNIK
normale Betrieb wurde zu dieser Zeit jedoch weiterhin mit der konventionellen parallelen Verdrahtung vorgenommen.
Bald danach haben in der Fahrzeugelektronik jedoch vielfältige Anstrengungen begonnen, um
durch serielle Netzwerke den Kabelbaum zu reduzieren, damit eine angestrebte Gewichtsersparnis und in Folge eine Kraftstoffersparnis bei gleichzeitig erweiterter Funktions- und Diagnosefähigkeit zu erreichen. In den 90er Jahren wurde dann damit begonnen, in der oberen
Fahrzeugklasse für den Antriebsstrang und die Chassiselektronik diese Feldbussysteme einzusetzen.
Im heutigen Fahrzeug dominiert so das 1983 von der Robert Bosch GmbH1 entwickelte Controller Area Network (CAN) [BOS91, ISO03]. Besondere Attribute von CAN sind die nachrichtenbasierte Adressierung mit Priorisierung, ereignisgesteuerte Kommunikation, bedingte Echtzeitfähigkeit für Regelkreise und anspruchsvolle Fähigkeiten für die Datenintegrität und das
Fehlermanagement. Je nach Anwendungsbereich bestehen mindestens zwei getrennte Segmente. Für die Chassiselektronik und die Komfortfunktionen ist dies der Low-Speed-CAN (CAN B,
Bitrate um die 100 kBit/s), für den Antriebsstrang und die Fahrdynamikassistenten ist es der
High-Speed-CAN (CAN C, Bitrate zwischen 500 kBit/s und 1 MBit/s). Als Topologie kann
ein Bus oder Stern zum Einsatz kommen, wobei aufgrund der Einbaugegebenheiten des Kabelbaums in der Karosserie oftmals der Stern bevorzugt wird.
Mit der Einführung von multimedialen Anwendungen im Kraftfahrzeug entstanden neue Anforderungen an die Feldbussysteme. Es mußten neue Bussysteme mit den entsprechenden Fähigkeiten für dieses Einsatzfeld entwickelt werden.
Das erste Serien-Bussystem höherer Bandbreite war seit Mitte/Ende der 90er Jahre von der
Firma Communication & Control Electronics Ltd2 der D2B Optical (Digital Data Bus Optical), ein auf polymeroptischen Fasern (POF) basiertes Bussystem zur Anwendung im Infotainment und Entertainment des Fahrzeugs. Aufgrund seiner zur Verfügung gestellten Bandbreite von 5 MBit/s und der synchronen Übertragung eignet es sich besonders für mehrere Audio-Datenströme in CD-Qualität. Gleichzeitig ist D2B Optical in der Lage auch asynchrone Daten, wie z. B. Kartendaten für das Navigationssystem oder Befehle zur Steuerung
von CD-/DVD-/Cassetten-Laufwerken und Raumklang-Verstärkern zu übertragen. Die optische physikalische Schicht verspricht große Vorteile für die elektromagnetische Verträglichkeit
(EMV) mit anderen Komponenten des Fahrzeugs, insbesondere aus dem fahrrelevanten Bereich.
Inzwischen wurde D2B Optical weitgehend vom direkten Nachfolger, MOST (Media Oriented
Systems Transport) [MOS05] abgelöst, der eine Datenrate von 25 MBit/s ermöglicht.
2.1.2
Industrieautomatisierung
Die Entwicklung im Bereich der industriellen Kommunikation verlief zwar unabhängig, aber
mit offensichtlichen Parallelen zum Kraftfahrzeug ab. So wurde z. B. in den späten 80er Jahren
von der Firma Rosemount3 Highway Addressable Remote Transducer (HART) als zusätzliche
Parametrierungs- und Diagnoseschnittstelle für konventionell verdrahtete Sensoren mit einer
1
http://www.bosch.de/
http://www.candc.co.uk/
3
http://www.rosemount.com/
2
2.1. FELDBUSSYSTEME IN VERSCHIEDENEN ANWENDUNGSBEREICHEN
5
analogen 4 bis 20 mA-Schnittstelle geschaffen. Eine Nutzergruppe entstand 1990, seit 1993 ist
die HART Communication Foundation (HCF)4 eine gemeinnützige Organisation, die als eine
ihrer Aufgaben die Verwaltung des Standards betrachtet.
Nun war auch die Automatisierung von einer rasanten Steigerung der Komplexität geprägt.
Das Konzept einer zentralen digitalen Steuerung (SPS – SpeicherProgrammierbare Steuerung)
mit sternförmiger Verkabelung jedes einzelnen Sensors oder Aktors stieß an eine ökonomisch
vertretbare Grenze für den Verkabelungs- und Wartungsaufwand. Das neue Schlagwort hieß
nun „dezentrale Busklemmen“, also die Verlagerung der Ein- und Ausgangsbaugruppen weg
von der SPS in die Nähe der Sensoren und Aktoren an dezentrale Verteiler in der Anlage. Die
Anbindung der Busklemmen an die SPS erfolgt mit einem Feldbus. Bekannte Hersteller von
Automatisierungsgeräten wie z. B. die Siemens AG5 , Asea Brown Boveri Ltd (ABB)6 , General
Electric Company (GE)7 oder Allen-Bradley8 haben daraufhin herstellerspezifische Lösungen
hervorgebracht, die jedoch nur mit dem eigenen Produktportfolio kompatibel sind.
Angestoßen durch Forschungsprojekte in Deutschland und Frankreich Ende der 80er Jahre begann ein internationaler Wettlauf zur Normierung von Feldbussen [Fel02]. Nur einige bekannte
Vertreter sollen hier erwähnt werden.
Die Entwicklung von PROFIBUS (PROcess FIeld BUS) wurde anfangs, 1989, vom Bundesministerium für Forschung und Technologie (BMFT) gefördert. Die Feldbusspezifikation existiert
in drei verschiedenen Ausprägungen: PROFIBUS-FMS (Fieldbus Message Specification) zur
Vernetzung von verteilten Steuerungen, als PROFIBUS-DP (Dezentrale Peripherie) zur Vernetzung von Sensoren und Aktoren und als PROFIBUS-PA (Prozess-Automation) mit der Möglichkeit zur eigensicheren und busgespeisten Vernetzung. PROFIBUS wurde 1991 national in
DIN 19245 [DIN91] genormt, ist 1996 dann in die europäische Norm EN 50170 [EN96] überführt worden und ist seit 2000 international in IEC 61158 [IEC03a] und IEC 61784 [IEC03b]
standardisiert. Seit 1995 existiert die internationale Nutzerorganisation PROFIBUS International9 [Pop00].
Seit den 80er Jahren hat die Firma Phoenix Contact10 mit dem INTERBUS11 ein eigenes System
für dezentrale Klemmen entwickelt, zunächst als nationaler (DIN 19258 [DIN93]) und später
als europäischer Standard (EN 50254 [EN97]) festgeschrieben, wurde INTERBUS im Januar
2000 zur internationalen Norm (IEC 61158, Teile 3 bis 6 [IEC03a]).
Für eine Standard-Schnittstelle für geregelte Antriebe an numerisch gesteuerten Maschinen hat
unter der Federführung des Zentralverbandes Elektrotechnik- und Elektroindustrie e. V. (ZVEI)
und namhafter Hersteller elektromechanischer Antriebe und Steuerungen ein GemeinschaftsArbeitskreis des Vereins Deutscher Werkzeugmaschinenfabriken e. V. (VDW) die Spezifikation
SERCOS (SErial Realtime COmmunication System) interface erarbeitet. Die erste Präsentation
erfolgte 1989. SERCOS interface ist heute eine internationale und europäische Norm IEC/EN
61491 [IEC02]. Die Interessengemeinschaft SERCOS interface e. V. (IGS)12 hat sich zur Auf4
http://www.hartcomm.org/
http://www.siemens.de/
6
http://www.abb.ch/
7
http://www.ge.com/
8
http://www.ab.com/
9
http://www.profinet.com/pi/
10
http://www.phoenixcontact.com/
11
http://www.interbusclub.com/de/
12
http://www.sercos.de
5
6
KAPITEL 2. STAND DER TECHNIK
gabe gemacht, den Standard öffentlich zugänglich zu machen und sie übernimmt die Zertifizierung von Produkten.
Aktor/Sensor-Interface (AS-Interface, AS-i) ist ein einfaches Single-Master-Feldbussystem mit
deterministischem Zyklus, das auf der untersten Steuerungsebene zum Anschluss von Aktoren
und Sensoren 1994 eingeführt worden ist. AS-i ist seit 1998 europäischer und seit 2000 internationaler Standard nach EN 50295 [EN99] und IEC 62026-2 [IEC00]. Die Zertifizierung von
AS-i Produkten übernimmt die AS-International Association13 [KM99].
2.1.3
Gebäudetechnik
Auch für die technische Ausstattung von Gebäuden, wie z. B. für Heizung, Klima, Beleuchtung,
Haushaltsgeräte und Alarmanlagen, wurde unabhängig eine Reihe von Feldbussen entwickelt.
LonWorks (kurz „LON“) ist ein Feldbussystem der Firma Echelon14 . Es wird sowohl in der
industriellen Automatisierungstechnik als auch in der Gebäude- und Heimautomatisierung eingesetzt.
Dieses System ist weit entwickelt und besitzt sogar Eigenschaften wie etwa das Routing. Folgende Übertragungsmedien können eingesetzt werden: Twisted Pair, Powerline, Funk, Infrarot,
und Lichtleiter. Als Datenraten sind wenige kBit/s bis zu einige MBit/s mögich, was stark vom
Medium und der Leitungslänge abhängt. Vorzugsweise werden 78 kBit/s verwendet.
Das verwendete Protokoll heißt „LonTalk“, welches seit 1998 in den Standards EIA 709.1
[EIA99] und ENV 13154-2 [ENV98] offengelegt ist.
Dem European Installation Bus (EIB) kann im europäischen Raum eine führende Rolle zugeschrieben werden. Bis zum Jahr 2000 wurden bereits mehr als 7 Millionen Kommunikationseinheiten eingesetzt. Es handelt sich bei EIB um einen offenen Standard [EIB99], wodurch eine
von Unternehmen unabhängige Zertifizierung gewährleistet wird. Hauptanwendungsgebiet des
EIB ist die Gebäudeautomation [DKS00]. Die Topologie des EIB lehnt sich infolgedessen stark
an einer gebäudeähnlichen Struktur an. Dabei wird ein Peer-to-Peer Netzwerk aufgebaut, welches in Bereiche (max. 15) und Linien (max. 256) eingeteilt wird, die durch Koppler getrennt
werden. Die Koppler fungieren als Router, d. h. Datenrahmen werden gefiltert.
Als Medien werden hauptsächlich Twisted Pair (9.600 Bit/s), aber auch Powerline (1.200 Bit/s),
Funk und Infrarot eingesetzt.
European Home Systems Network (EHS) ist ein Peer-to-peer Netzwerk, das grosse Gemeinsamkeiten mit EIB aufweist. Der EHS Standard 1.3 [EHS96, KJBMS00] definiert folgende
zulässige Medien:
• Twisted Pair TP1 (9.600 Bit/s)
• Twisted Pair TP2 (64.000 Bit/s)
• Powerline (2.400 Bit/s)
• Koaxialkabel (9.600 Bit/s)
13
14
http://www.as-interface.net/
http://www.echelon.com/
2.1. FELDBUSSYSTEME IN VERSCHIEDENEN ANWENDUNGSBEREICHEN
7
• Funk (1.200 Bit/s)
• Infrarot (1.100 Bit/s)
Viele Haushaltsgeräte-Hersteller haben sich bei der Entwicklung eigener kommunikationsfähger Produkte aufgrund der vielen konkurrierenden Standards lange Zeit zurückgehalten. Im
Juni 1996 startete die EHSA (European Home Systems Association)15 eine Initiative mit dem
Ziel, die drei Systeme BatiBUS16 (eine Entwicklung der Firmen Merlin Gerin17 , Airelec18 , Landis+Gyr19 u.a.), EIB und EHS zu einem gemeinsamen Kommunikationsstandard zu vereinigen.
Unter dem Namen „Konnex“ (kurz „KNX“)20 wurde eine Organisation nach belgischem Recht
gegründet, die 1999 eine KNX Spezifikation in der Version 1.0 vorstellte [KNX00]. Der KNX
Standard basiert auf der Kommunikationsschicht von EIB, wird aber erweitert durch die physikalische Schicht und die Konfigurationsmodi von BatiBUS und EHS. KNX definiert folgende
Medien:
• Twisted Pair 0 (TP0, 4.800 Bit/s)
Dieses Kommunikationsmedium wurde von BatiBUS übernommen, KNX und BatiBUS
Geräte benutzen dasselbe Medium, können aber nicht miteinander kommunizieren.
• Twisted Pair 1 (TP1, 9.600 Bit/s)
TP1 wurde von der EIB Spezifikation übernommen, EIB und KNX Geräte können völlig
kompatibel zueinander über dieses Medium kommunizieren.
• Powerline 110 (PL110, Mittenfrequenz 110 kHz, 1.200 Bit/s)
Auch dieses Kommunikationsmedium wurde den EIB Spezifikationen entnommen, wobei
wiederum EIB- und KNX-zertifizierte Geräte miteinander kompatibel sind.
• Powerline 132 (PL132, Mittenfrequenz 132 kHz, 2.400 Bit/s)
PL132 wird im EHS Standard verwendet. EHS und KNX Geräte können nur mit Hilfe
eines Protokoll-Konverters miteinander kommunizieren, der aber im „A-mode“ Unterprotokoll von KNX implementiert ist.
• Funk (RF, Radio frequency, 868 MHz, 38,4 kBit/s)
Dieses Medium wurde eigens im Rahmen von KNX neu entwickelt.
Nach der Verabschiedung des gemeinsamen europäischen KNX Standards [EN03] ist nun der
Weg frei für die Entwicklung neuer Produkte. KNX scheint beste Chancen zu haben, zum Weltstandard für Indoor-Powerline zu werden.
15
http://www.ehsa.com/
http://www.batibus.com/
17
http://www.merlingerin.com/
18
http://www.airelec.fr/
19
http://www.landisgyr.com/
20
http://www.konnex.org/
16
8
KAPITEL 2. STAND DER TECHNIK
2.2
Heterogene Netzstruktur
at
ew
ay
Beispielhaft für alle drei Anwendungsbereiche, läßt sich das Vorhandensein und die Notwendigkeit der heterogenen Netzstruktur sehr gut im Bereich Automotive zeigen.
G
IEEE 1394
Gatewa
y
RS485
CAN I²C LIN
D2B Optical
Control
Byteflight
TTP
FlexRay
Audio
Video
MOST
Bluetooth
y
ewa
Gat
Abbildung 2.1: Netzhierarchie
Aufgrund neuer divergierender Anwendungen kommen auch in Zukunft eine weiter steigende
Anzahl voneinander getrennt arbeitender, spezialisierter Netze oder Bussysteme zum Einsatz
(Abbildung 2.1). Getrieben werden diese Entwicklungen durch
• unterschiedliche Anforderungen an Signallaufzeit, Bandbreite, Störsicherheit, Ausfallsicherheit und Topologie,
• applikationsspezifische Sicherheitsaspekte,
• die Einführung klarerer Schnittstellen,
• die Verfügbarkeit neuer Lösungen, aber auch durch positive Erfahrungen mit bereits eingeführten Systemen,
• sowie dem gestiegenen Kostendruck und der damit einhergehenden möglichst optimalen
Dimensionierung entsprechend dem Einsatzzweck.
So zeichnet sich ab, dass auch in den nächsten Fahrzeuggenerationen für Komfortanwendungen und das Motormanagement weiterhin CAN verwendet wird. Zur Vernetzung von Komponenten innerhalb kleiner lokaler Bereiche, wie der Klimaanlage, der Sitzverstellung oder
2.3. ANSÄTZE FÜR HÖHERE PROTOKOLLE
9
der Fahrzeugtür, werden aber preiswertere Subbusse wie Local Interconnect Network (LIN)
[LIN02, LIN03] eingesetzt. X-by-Wire Applikationen, wie die elektrohydraulische Bremse
oder die elektrische Lenkung ohne mechanische Kopplung, stellen höhere Anforderungen an
Bandbreite, Übertragungs- und Ausfallsicherheit. Dafür wurden mehrere unterschiedliche Netze entwickelt, darunter das Time Triggered Protokoll (TTP/C) [TTP99, TTP03], Byteflight
[PBG99], FlexRay [Fle05] oder das auf CAN basierende Time Triggered Controller Area Network (TTCAN) [ISO04a]. Als ursprünglich nicht für den Automobilbereich konzipierte Vertreter kommen die Spezifikation RS485 [TIA98] für die physikalische Übertragungsschicht zusammen mit herstellerspezifischen Protokollen in Sonderfahrzeugen (Taxi, Polizei, Feuerwehr,
Arbeitsgeräte), sowie der Inter-IC-Bus (I2 C) [I2C00] innerhalb von Geräten des Entertainmentsystems für Steuerungsaufgaben zum Einsatz.
Der Infotainmentbereich benötigt für alle Ausprägungen von Multimedia-Anwendungen geeignete Netzwerke, wie das bedingt für Video geeignete MOST-Protokoll, das audiofähige drahtlose System Bluetooth [SIG03, SIG04c] oder den IEEE 1394 Standard [IEE95, IEE98, IEE01b,
And99].
Mittel bis langfristig ist eine Verschmelzung der Bereiche Audio und Video (Abbildung 2.1)
zu erwarten, da diese Netze beide für isochrone Daten geeignet sein müssen und lediglich mit
der notwendigen Bandbreite skalieren müssen. Netze für den Bereich Control werden auch in
Zukunft vom Bereich Audio/Video und untereinander getrennt bleiben müssen, da hier höchst
unterschiedliche Anforderungen an Bandbreite, Echtzeitfähigkeit und Sicherheitsanforderungen gestellt werden.
2.3
Ansätze für höhere Protokolle
Viele Applikationen, insbesondere für Steuerungs- und Regelungsaufgaben, setzen derzeit noch
auf den beiden unteren Übertragungsschichten des OSI-Modells auf. Die Kommunikation innerhalb der Subsysteme wird über starr administrierte Kommunikationsmatrizen bzw. feste Kanalzuweisungen organisiert, die spätere Änderungen stark erschweren. Hier sollen nun beispielhaft einige der Bestrebungen vorgestellt werden, die höhere Protokolle definieren, um Feldbusse
flexibler nutzen zu können.
OSEK/VDX (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug /
Vehicle Distributed eXecutive)21 war ein Vorstoß, um unter anderem durch die Einführung einer
Interaktionsschicht (vergleichbar OSI Schicht 7) und Netzwerkschicht (OSI Schicht 3) [OSE00,
ISO04b] für eine Vereinheitlichung der Kommunikation im Fahrzeug zu sorgen. Auch wenn
OSEK/VDX nicht ausschließlich die Verwendung eines bestimmten Feldbusses vorschreibt, so
ist doch sehr deutlich die Konzentration der Entwickler auf CAN zu sehen. Eine allgemeine
Verbreitung in anderen Anwendungsbereichen ist nicht zu erwarten, da OSEK/VDX speziell
für Steuerungsapplikationen im Fahrzeug konzipiert worden ist.
CANopen [CiA02] ist ein OSI Schicht 7 Protokoll (Anwendungsschicht), das ausschließlich
auf dem CAN aufsetzt. Die Anwendungen in den Knoten verwenden zur Kommunikation nicht
mehr die CAN-Identifier, sondern Objekte. Alle CANopen-Objekte, die Kommunikations- und
21
http://www.osek-vdx.org/
10
KAPITEL 2. STAND DER TECHNIK
Anwendungsobjekte sind in einem standardisierten Objektverzeichnis im Knoten abgelegt, dort
können Daten und Parameter verändert werden. Das Objektverzeichnis dient somit als zentrales Koppelelement eines CANopen-Knotens auf das sowohl die Anwendung im eigenen Knoten
als auch die anderen Knoten über Kommunikationsobjekte zugreifen können. Bei der Initialisierung erfolgt die Zuordnung zwischen Objekten und CAN-Identifiern mit einem vordefinierten
Schema („predefined connection set“), das in engen Grenzen abänderbar ist. CANopen wird seit
1995 von der internationalen Nutzer- und Herstellerorganisation CAN in Automation (CiA)22
gepflegt, das Protokoll ist in der europäischen Norm EN 50325-4 [EN02] standardisiert. Bekannte Anwendungsbereiche von CANopen sind die industrielle Automatisierung, Medizintechnik, Nutzfahrzeuge, Schienenfahrzeuge, Schiffbau und Gebäudetechnik [Zel01].
Die Dienste von PROFIBUS-FMS (Fieldbus Message Specification) [DIN91, EN96, IEC03a,
IEC03b] werden ebenfalls durch die Definition einer Anwendungsschicht (OSI Schicht 7) bereitgestellt. PROFIBUS-FMS wurde für die objektorientierte, universelle Kommunikation bei
mittleren Echtzeitanforderungen zwischen Steuerungen nach dem Client-Server Prinzip entwickelt. Es setzt auf denselben Schichten 1 und 2 auf, die auch von der PROFIBUS-DP Ausprägung benutzt werden. Das Protokoll findet hauptsächlich in der Automatisierungstechnik seine
Anwendung [Pop00].
Zum EHS Standard [EHS96, KJBMS00] gehört die Definition der OSI Schichten 3 und 7.
Die Vermittlungsschicht bietet die üblichen Dienste eines OSI Schicht 3 Protokolls. Sie sorgt
begrenzt auf ein EHS-System, also z. B. ein Gebäude, für die Weiterleitung von Datenpaketen in miteinander verbundenen EHS-Subnetzen, außerdem ist sie zuständig für die Wegewahl
(Routing).
Die hauptsächliche Aufgabe der Anwendungsschicht ist die Konvertierung von EHSKommandos in einen Datenrahmen für die Vermittlungsschicht. Innerhalb dieser Schicht befinden sich folgende Komponenten:
• Command Language Service Element (CLSE): Abwicklung der Kommando-Syntax
• Message Transfer Service Element (MTSE): Zuordnung zwischen Anwendungsidentifikationen und Untereinheitidentifikationen / Netzwerkadressen
• Application Titel Directory (ATD): Datenstruktur mit Informationen zu entfernten Untereinheiten
• Local Management Service Element (LMSE): Überpüfen und Modifizieren des ATD duch
die lokale Anwendung
In einer Veröffentlichung wurde das Konzept nanoIP [SMR+ 03] diskutiert, welches Transportprotokolle (OSI Schicht 4) und Anwendungsprotokolle (OSI Schicht 7) für eingebettete Netzwerkanwendungen vorstellt. Die Definition dieser Protokolle wurde wiederum durch ein Arbeitspapier mit Protokollvorschlägen für eingebettete Systeme beeinflusst. Dieses unvollendete
Arbeitspapier wurde bei der Internet Engineering Task Force (IETF)23 als INTERNET-DRAFT
eingereicht, ist jedoch nicht als Request for Comments (RFC) angenommen worden. Beide
Konzepte sind bisher nicht weiter verfolgt worden.
22
23
http://www.can-cia.org/
http://www.ietf.org/
2.4. GATEWAYS
2.4
11
Gateways
Um die Erwartung an überall verfügbare Messwerte und Stati (Kapitel 2) zu erfüllen, sind
Koppelelemente zwischen den grundlegend verschiedenen Netzen notwendig. Zum Datenaustausch zwischen den zueinander inkompatiblen Protokollen, die auch nur bis auf unterschiedliche Schichten ausgeprägt sind, benötigt man also Gateways. Entsprechend dem OSI-Modell
geschieht die Konvertierung hierbei auf Applikationsebene.
Dass hierbei die speziellen inherenten Vorteile der Feldbusse negativ beeinflusst werden ist bekannt. Billigend in Kauf genommen wird z. B. der Verlust von deterministischem Zeitverhalten
oder Zyklusszeiten, die Verschlechterung bei Latenzzeit, Einschränkungen bei der Bandbreite
oder die Verminderung der Ausfallsicherheit. Trotzdem überwiegt das mehr an Funktionalität
bei weitem diese Nachteile.
Schon bei einem normal ausgestatteten Fahrzeug werden zur Koppelung an mechanisch geeigneten und der Netzwerktopologie entsprechenden Einbauorten bereits eine Handvoll unterschiedlicher Gateways zwischen fahrrelevanten Systemen, der Komfortelektronik und dem
Infotainments benötigt. Funktionen, wie z. B. E-Mail-/News-/WWW-Zugang, ortsbezogene
Dienste, Diebstahlwarnanlagen mit Ortsbestimmung, Flottenmanagement, Ferndiagnose- und
wartung, usw. erfordern die Einbindung von Netzwerken zur externen Kommunikation, am
naheliegensten Mobilfunk oder Wireless Local Area Network (Wireless LAN, WLAN). Bei
Fahrzeugen der Oberklasse oder bei Arbeitsmaschinen können so leicht mehrere Dutzend spezialisierter Gateways benötigt werden.
Bei industriellen Automatisierungsanlagen oder der Gebäudetechnik koexistiert eine große Zahl
von Feldbussystemen parallel in einem Anlagenteil bzw. einem Gebäude. Deshalb spielen Gateways hier ebenso eine wichtige Rolle für den Standardbetrieb oder beispielsweise zum Zugriff
auf alle Senoren und Aktoren für die Parametrierung. Für die Buchhaltung, für die Ferndiagnose und -wartung bzw. zur Weiterleitung von Störungs- oder Alarmmeldungen greift man gerne
auf gewohnte Konzepte, wie z. B. Datenbankanbindung, Web-Schnittstelle bzw. E-Mail zurück
und benötigt dafür Gateways zum Internet via Local Area Network (LAN).
2.5
Fazit
In den drei verschiedenen Bereichen Automobil-, Automatisierungs- und Gebäudetechnik haben sich unterschiedlichste Feldbusse etabliert. Sogar innerhalb einer Anwendungsdomäne werden mehrere Systeme nebeneinander verwendet und führen so zu einer heterogenen Netzstruktur. Mit einer Konvergenz ist auch in Zukunft nicht zu rechnen, da jedes System bestimmte
Stärken und Schwächen aufweist, die es für einen speziellen Einsatzzweck prädestinieren.
Viele Feldbus-Systeme definieren nur die Bitübertragungsschicht (OSI Schicht 1) und die Sicherungsschicht (OSI Schicht 2). In den Anwendungsbereichen werden eingebettete Systeme
(Embedded Systems) verwendet, diese hatten historisch bedingt nur eine sehr begrenzte Verarbeitungsleistung und limitierten Speicher. Das Auslassen höherer Schichten und somit das
Aufsetzen der Applikation direkt auf die Schicht 2 ermöglichte es auch unter diesen Bedingungen, eine effiziente und schnelle Datenverarbeitung mit geringem Protokolloverhead zu erreichen. Zum Fragmentieren großer Datenpakete sahen die Entwickler keine Notwendigkeit, da
12
KAPITEL 2. STAND DER TECHNIK
der Feldbus so dimensioniert wurde, dass seine Nutzdatenpakete für die geplante Anwendung
ausreichend waren. Außerdem spielten in den anfangs eng begrenzten Einsatzgebieten Funktionen für die Wegewahl (Routing) keine Rolle.
Von der optimierenden Denkweise bei embedded Systemen getrieben, sind höhere Protokolle
nur für eine bestimmte Anwendungsumgebung und/oder einen Feldbus definiert worden. Man
findet die Protokollschichten als Bestandteil eines Feldbus-Standards oder sie wurden von unabhängigen Konsortien (z. B. Benutzergruppen) entwickelt. Angestrebte Funktionen sind oftmals
eine Programmierschnittstelle (API – Application Programming Interface), die durch eine Anwendungsschicht (OSI Schicht 7), realisiert wurde; seltener existiert eine Vermittlungsschicht
(OSI Schicht 3), die z. B. das Routing in einer strukturierten Netzwerkumgebung erlaubt. Durch
die Abhängigkeit von einer Anwendung oder einem Bussystem existieren sogar mehrere, auch
konkurrierende, höhere Protokollschichten.
Die heterogenen Netzwerkumgebungen in Kombination mit den unterschiedlichen höheren Protokollen führen zu einer beinahe unüberschaubaren Vielfalt an Programmierschnittstellen zur
Datenübertragung über die Feldbusse. Die Gateways sind deshalb jeweils spezialisierte aktive
Netzwerkkomponenten, die natürlich die passenden physikalischen Schnittstellen, als auch die
benötigten Netzwerkprotokolle integriert haben müssen und sogar über recht genaue Kenntnisse
der weitergegebenen Nutzdaten verfügen müssen. Obwohl von den Entwicklern der Embbeded
Systeme bereits der Bedarf für eine zukunftssichere übergreifende Lösung erkannt wurde, ist
eine Harmonisierung der verschiedenen Programmierschnittstellen und Protokolle nicht in Aussicht und in Folge dessen ein allgemeines Gatewaykonzept derzeit undenkbar.
Kapitel 3
Konzept der Protokollfamilie
Im Kapitel 2 wurde anhand ausgewählter Beispiele vorgestellt, welche Vielzahl verschiedenster
Feldbusse mit ihren entprechenden Ausprägungen und höheren Protokollen bereits entwickelt
worden sind. Unterschiedliche Randbedingungen rechtfertigen aber auch wiederum die Vielzahl
der Feldbusse. Innerhalb eines eng begrenzten Teilbereiches stellt der entsprechende Feldbus
eine optimale Lösung, z. B. für zeitkritische Regelkreise dar. Hierfür wird man auch noch auf
absehbare Zeit auf die Schicht 2 aufsetzen wollen, um die spezifischen Vorteile des verwendeten
Feldbusses direkt nutzen zu können. Sicherheitsgründe sprechen ebenfalls für die getrennte
Ausführung von Netzen, um eine unerwünschte gegenseitige Beeinflussung von Anlagenteilen
oder gar die Fortpflanzung einer Störung auf das Gesamtsystem zu unterbinden. Ebenso müssen
finanzielle Gründe bei der Wahl eines geeigneten Bussystems für den jeweiligen Teilbereich
einer Anlage berücksichtigt werden. Eine Konvergenz der Systeme ist deshalb auch in Zukunft
nicht zu erwarten.
Höhere Protokolle für standardisierte Programmierschnittstellen und eine mögliche Interoperabilität zwischen den begrenzten Bereichen existieren zwar zum Teil, wurden aber nur für
den Einsatz mit bestimmten Feldbussen oder in bestimmten Anwendungsszenarien konzipiert.
Somit stellen Gateways derzeit den einzigen Weg dar, um einen Datenaustausch zwischen Teilsystemen mit unterschiedlichen Protokollen zu ermöglichen. Jedoch sind diese proprietären und
jeweils neu zu entwickelnden Gateways ein sehr aufwendiger Lösungsweg.
Da immer mehr auch die durchgängige Interoperabilität zwischen Teilsystemen mit verschiedenen Feldbussegmenten gefordert wird, befindet sich die Entwicklung aber nun in einer Sackgasse. Es fehlt eine allgemeine Lösung, die mit möglichst vielen Feldbussen und in einer möglichst
breiten Umgebung eingesetzt werden kann.
3.1
Zielsetzung
Diese Arbeit hat sich deshalb zum Ziel gesetzt, eine Lösung für zukunftssichere Entwicklungen
zum Steuerdatenaustausch in heterogenen Netzwerkumgebungen zu schaffen. Den Anwendungen soll trotz der Verwendung unterschiedlicher Feldbusse eine gemeinsame Schnittstelle zur
Verfügung gestellt werden. Darauf aufbauend können dann auch allgemeine, vereinheitlichte
Gateway Applikationen erstellt werden.
13
14
KAPITEL 3. KONZEPT DER PROTOKOLLFAMILIE
Folgende Anforderungen werden gestellt:
• Gemeinsame Schnittstelle für die Anwendungen.
Diese bietet die Grundlage für die zukunftssichere Anwendungsentwicklung und für die
allgemeinen, vereinheitlichten Gateways.
• Einheitliche Transportdienste.
Dies kann z. B. bestätigter, unbestätigter und transaktionsbasierter Datentransport sein.
• Einheitliche Adressierung,
die unabhängig vom zugrundeliegenden Feldbus und dessen nachrichtenbasierten, kanalbasierten oder knotenbasierten Adressierungsmodell ist.
• Automatisierungsgeräte sollen, solange mindestens ein durchgängiger Pfad in einem ausreichend vermaschten System verfügbar ist, auch bei Ausfall von einzelnen Segmenten
erreichbar bleiben.
• Wegewahl in geeignet strukturierten Feldbusumgebungen mit der Möglichkeit zur Berücksichtigung von Quality of Service (QoS)-Parametern beispielsweise für Echtzeitanwendungen.
• Im Normalbetrieb optimiert für die Steuerdatenkommunikation in embedded Systemumgebungen.
Das bedeutet die Übertragung von wenigen Nutzdatenbyte pro Datenrahmen. Durch die
Protokolle soll dabei nur ein möglichst geringer Overhead hinzugefügt werden.
• Möglichkeit zur Softwareaktualisierung von Steuergeräten.
Dies erfordert die zeitweilige Übertragung größerer Datenmengen.
• Konzipiert für ein komplexes abgegrenztes System, das mehrere unterschiedliche Feldbusse benötigt.
Klassische Beispiele sind der Einsatz im Kraftfahrzeug, in einer industriellen Anlage oder
in Gebäuden.
• Möglichst einfache Übergangsmöglichkeit in die Internet-Welt.
Dies ermöglicht die Diagnose und Wartung auch außerhalb des eng abgegrenzten Systems
mit Standardkomponenten.
Das Protokoll dient also besonders für Steuerungsanwendungen, die einen Einsatz mehrerer
Feldbusse und deren Koppelung mittels Gateways benötigen. Hier ist der Vorteil einer solchen
Entwicklung besonders groß.
3.2
Anwendungsbeispiele
Gerade durch das verbesserte Zusammenwirken der Teilsysteme wird eine weitere Erhöhung
des Funktionsumfanges des Gesamtsystems erwartet. Der Aufwand für die Hardwareausstattung bleibt praktisch identisch, denn schon bei der bisherigen Form der heterogenen Vernetzung
3.2. ANWENDUNGSBEISPIELE
15
musste die Netzwerktopologie und die proprietären Gateways eingeplant werden. Nun werden
Hardware und Software für allgemeine Gateways nur einmal entwickelt und können universell eingesetzt werden. Die Anwendungssoftware auf den Steuergeräten, die über Teilsysteme hinaus kommunizieren soll, kann unabhängig vom verwendeten Bussystem entwickelt und
verwendet werden, da nur noch eine Programmierschnittstelle existiert. Bei Neu- und Weiterentwicklungen kann auf bereits vorhandene und ausgetestete Softwaremodule zurückgegriffen
werden. Zusätzliche Funktionen lassen sich auch später flexibel hinzufügen.
Anhand folgender Beispiele soll der Mehrwert einer Protokollfamilie für die Steuerdatenkommunikation vorgestellt werden.
Reifendruck
Reifendruck
RS232
IEEE 1394 RS232
Gateway
InternetService
Server
elektrische
Fensterheber
Schloß
Reifendruck
Datenbank
IEEE 1394
Display / MMI
Kamera
IEEE 1394
Bridge
GPS
GSM /
UMTS
Display / MMI
Tuner
elektrische
Fensterheber
Gateway /
Verstärker
LIN
Gateway /
Verstärker
Bluetooth
Gateway
elektrische
Fensterheber
Schloß
X-by-Wire
System
FlexRay
IEEE 1394 FlexRay
Gateway
Tacho /
MMI
IEEE 1394
Gateway /
Verstärker
Spiegel
LIN
Fahrzeug PC
(Navigation)
elektrische
Fensterheber
CD / DVD
Wechsler
Schloß
LIN
Kamera
Airbag
System
IEEE 1394 proprietäres
Gateway
IEEE 1394 CAN
Gateway
IEEE 1394
Display /
MMI
Schloß
Body
Elektronik
Gateway /
Verstärker
CAN C
CAN B
Chassis /
Antriebsstrang
LIN
Spiegel
Reifendruck
Hinweis: Auch andere Netze, wie z. B. FlexRay und CAN, breiten sich über das gesamte Fahrzeug aus.
Abbildung 3.1: Fahrzeug Netzarchitektur – Funktionaler Aspekt
Abbildung 3.1 zeigt eine Referenzarchitektur für Fahrzeuge. Dabei handelt es sich um die funktionale Sicht auf ein zukünftiges Automobil, welches für den fahrrelevanten Bereich weiterhin
mit den typischen Feldbussen, wie z. B. FlexRay, CAN oder LIN ausgestattet ist. Gleichzeitig
verfügt dieses Auto aber auch über ein ausgeprägtes Infotainment- und Entertainment-System
basierend auf dem IEEE 1394 und Bluetooth und ist bis hin zur externen Anbindung über Mobilfunknetze (GSM – Global System for Mobile communications, UMTS – Universal Mobile
Telecommunications System) ausgestattet. Eine Vielzahl von Gateways ermöglicht den Datenaustausch zwischen den vorhandenen Netzwerksegmenten.
16
KAPITEL 3. KONZEPT DER PROTOKOLLFAMILIE
Mit der Zielsetzung dieser Arbeit werden erweiterte Möglichkeiten für die Ferndiagnose und
-wartung geschaffen. Der Zugriff auf jedes Steuergerät im Fahrzeug kann über beliebige interne Netze, und sofern gewünscht, auch über eine externe Netzwerkanbindung erfolgen. Hierüber können interne Vorgänge abgefragt, Konfigurationseinstellungen durchgeführt und auch
die Betriebssoftware der Steuergeräte aktualisiert werden. Eine zentrale Datenbank steht allen Komponenten zur Verfügung, um Betriebsdaten, aufgetretene Fehler und benutzerdefinierte
Einstellungen zu erfassen. Hierüber können auch wesentlich detailliertere nutzungsabhängige
Wartungsaufforderungen (sogenannte Condition Based Services) als bisher für den Nutzer generiert werden, die nicht nur im Fahrzeug sondern auch an externe Stellen signalisert werden
können.
Ein weiterer Mehrwert ergibt sich durch die Steuerung von Infotainment-Anwendungen durch
das Mitnutzen vorhandener Body-Elektronik. Entsprechend aufwendig ausgestattete Türbedienmodule, die bisher nur der Einstellung der Spiegel und für die Bedienung der Fensterheber
dienten, können nun auch für die unabhängige Kanalauswahl und die Lautstärkeeinstellung von
Multimediaquellen getrennt für jeden Sitzplatz genutzt werden. Ein Komfort vergleichbar zu
den Bedienmöglichkeiten in modernen Verkehrsflugzeugen kann für alle Insassen erreicht werden.
Bei einer über die in Abbildung 3.1 gezeigten Ausstattung hinausgehenden Ausrüstung des
Fahrzeugs mit Gateways kann sogar auch bei Ausfall von Teilnetzen ein Betrieb über alternative Routen bereitgestellt werden. Teilweise wird dabei zwar nur ein eingeschränkter Notbetrieb
wichtiger Funktionen möglich sein, da auch weniger spezifisch geeignete Netze herangezogen
werden müssen. Gegenüber einem sonstigen Totalausfall ist dies trotz allem eine erhebliche
Verbesserung.
Die Computer Aided Manufacturing (CAM) Pyramide ist eine oft verwendete Symbolik im
Bereich der Automatisierung. Abbildung 3.2 zeigt eine Referenzarchitektur für eine zukünftige
industrielle Anlage, welche mit üblichen Feldbussen, wie z. B. AS-i, CAN, PROFIBUS vernetzt
ist. Auch hier werden moderne Netzwerke wie IEEE 1394 eingeführt und es existiert eine Anbindung an das weltweite Internet. Abgesehen von den verwendeten spezialisierten Netzwerken
und der größeren räumlichen Ausdehnung sind die Parallelen zur Fahrzeug-Referenzarchitektur
(Abbildung 3.1) erkennbar.
Für dieses Einsatzgebiet ergeben sich ebenfalls Vorteile durch die erweiterten Ferndiagnoseund Fernwartungsmöglichkeiten. Das Bedienpersonal hat von der Leitwarte oder soweit gewünscht per weltweiter Internet-Anbindung Zugriff auf sämtliche Automatisierungsgeräte der
Anlage. Alle Aktoren und Sensoren können jederzeit überwacht und parametriert werden. Die
Ablaufprogramme für speicherprogrammierbare Steuerungen müssen nicht mehr vor Ort geladen werden, sondern können praktisch von überall her übertragen werden. So können z. B.
Computerized Numerical Control (CNC) Bearbeitungsmaschinen direkt von der Konstruktionsabteilung oder der Arbeitsvorbereitung programmiert werden.
Umgekehrt wird es möglich, aus der Produktion Daten zum Ausstoß z. B. direkt an die Buchhaltung zu übermitteln. Störmeldungen lassen sich intern und extern weitergeben und können
auf entsprechenden Wunsch sogar als E-Mail oder SMS (Short Message Service) an das Wartungspersonal weitergeleitet werden.
Die Gebäudetechnik weist wiederum Parallelen zur Automatisierung auf, jedoch mit den dort
vorkommenden Netzen für Gebäudeautomatisierung (z. B. EIB und KNX), Unterhaltungselektronik (z. B. IEEE 1394), Internet (z. B. Ethernet) und Telekommunikation (z. B. ISDN – Inte-
3.3. LÖSUNGSANSÄTZE
17
Internet
PC
Firewall
Firewall
PC
Gateway
Gateway
Ethernet, TCP/IP
SPS
SPS
Leitrechner
IEEE 1394, IP over 1394
SPS / GW
PROFIBUS, CAN
Gateway
Prozessebene
MMI
MMI
SPS / GW
SPS
···
Aktor
···
Aktor
···
Aktor
Aktor
Sensor
Sensor
···
Sensor
AS-Interface, CAN
Sensor/Aktor-Ebene
Sensor
Leitebene
Leitrechner
GW – Gateway, MMI – Mensch Maschine Interface, PC – Personal Computer,
SPS – SpeicherProgrammierbare Steuerung
Abbildung 3.2: Computer Aided Manufacturing Modell
grated Services Digital Network). Auch hier ist ein Mehrwert durch das Zusammenwirken der
verschiedenen Feldbusse, Multimedianetze, dem Local Area Network (LAN) und den Telekommunikationsnetzen zu erwarten.
3.3
Lösungsansätze
Zunächst werden zwei unterschiedliche Lösungsansätze vorgestellt mit denen die geforderten
Funktionen umgesetzt werden können. Anschließend im Kapitel 3.4 erfolgt dann die endgültige
Auswahl des weiterverfolgten Konzepts.
Der erste Lösungsvorschlag geschieht ähnlich den bisherigen Industriestandards CANopen oder
PROFIBUS-FMS. Den Awendungsprogrammen steht eine Programmierschnittstelle mit definierten Funktionsaufrufen in Form einer Bibliothek bereit. In der Software-Entwicklung spricht
man bei diesen Bibliotheken, die den Softwarekomponenten eine Programmierschnittstelle zur
transparenten Kommunikation über Netze bereitstellen, auch von kommunikationsorientierter
Middleware.
Der zweite Lösungsvorschlag folgt dem ISO OSI-Modell. Dieses legt fest, dass die Konvergenz
der heterogenen Netze in der Schicht 3 zu erfolgen hat und die Transportdienste in der Schicht 4
angesiedelt sind.
18
3.3.1
KAPITEL 3. KONZEPT DER PROTOKOLLFAMILIE
Programmierschnittstelle
Eine Anpassungsschicht (vergleichbar OSI Schicht 7) stellt eine Programmierschnittstelle
(API – Application Programming Interface) bereit.
SteuerungsApplikation
Gateway Applikation
SteuerungsApplikation
•••
SteuerungsApplikation
Anpassungsschicht
LIN API
CAN API
BT API
IEEE 1394 API
Data Link Layer
Logical Link
Control
Application Layer
(i. e. CANopen)
L2CAP
Medium Access
Control
Physical Layer
LIN
LMP
Link Layer
Baseband
Physical Layer
BT Radio
CAN
Bluetooth
Serial Bus Management
RFCOMM
Transaction
Layer
asynch.
isochr.
Link Layer
Physical Layer
IEEE
1394
Abbildung 3.3: Anpassungsschicht mit API als einheitliche Schnittstelle
Anhand Abbildung 3.3 kann man sehen wie Anwendungen und Gateways über die Anpassungsschicht beispielsweise die Netze LIN, CAN, Bluetooth und IEEE 1394 nutzen können. Die
Funktionen für die geforderte einheitliche Adressierung und die Transportdienste aus Kapitel
3.1 müssen in dieser einen Schicht untergebracht werden. Nach unten hin müssen Anpassmodule zu den verschiedenen Feldbussen definiert werden. Nach oben hin wird eine Programmierschnittstelle definiert auf die Anwendungen sowie Gateways gleichermaßen aufsetzen können.
Die Anpassungsschicht gibt Applikationen die Möglichkeit zur Angabe von QoS-Parametern
für den Datentransport. Die Wegewahl bei Ausfall von Netzwerksegmenten und für die Berücksichtigung von QoS-Parametern muss von der Gateway Applikation berücksichtigt werden. Innerhalb des Systems können dazu vereinheitlichte Gateways zum Einsatz kommen. Der
Übergang in die Internet-TCP/IP-Welt wird durch ein spezielles Gateway ermöglicht.
3.3.2
Hierarchische Protokollfamilie
Die gestellten Anforderungen werden entsprechend dem OSI-Modell auf mehrere Schichten
aufgeteilt. Die Aufgaben der entprechenden Schicht können unabhängig voneinander implementiert und gepflegt werden. Abbildung 3.4 zeigt die Einordnung der Protokolle.
3.3. LÖSUNGSANSÄTZE
19
Applikation
Applikation
Applikationsschicht
7
Darstellungsschicht
6
Sitzungsschicht
5
Transportschicht
Transportschicht
4
Hierarchische
Protokollfamilie
Vermittlungsschicht
Vermittlungsschicht
3
Sicherungsschicht
Sicherungsschicht
···
Sicherungsschicht
Bitübertragungsschicht
Bitübertragungsschicht
···
Bitübertragungsschicht
Medium
···
Medium
2
1
Medium
Abbildung 3.4: Protokollfamilie (rechts) eingeordnet in das OSI-Modell (links)
Das Übertragungsmedium und die Schichten 1 und 2 werden von den jeweils verwendeten
Feldbussen bestimmt. In einem System kommen entsprechend der Anzahl der verschiedenen
verwendeten Netze unterschiedlich viele Definitionen dieser Schichten zum Einsatz. Höhere
Schichten müssen hierauf aufsetzen.
Die Schicht 3 ist die erste von den darunterliegenden Feldbussen unabhängige Schicht. Nach
unten hin definiert sie Anpassmodule zu den verschiedenen Feldbussen mit ihren unterschiedlichen Datenrahmen und Adressierungsmodellen. Nach oben hin stellt sie eine einheitliche logische Adressierung zur Integration der heterogenen Feldbusse bereit. Höheren Schichten steht
damit ein definierter Datenrahmen zur Verfügung.
Bestandteil dieser Schicht ist gegebenenfalls ein feldbusabhängiges Hilfsprotokoll zur Auflösung zwischen der logischen Adressierung und der Netzadressierung auf Schicht 2.
Die verbindungslosen, verbindungsorientierten und transaktionsbasierten Transportdienste werden von der Schicht 4 bereitgestellt. Hierauf können die Anwendungen und die Gateways aufsetzen.
Bestandteil dieser Schicht ist auch ein Hilfsprotokoll für die Vermittlungsschicht zum Austausch von Fehler- und Informationsmeldungen.
Für die Schichten 5 und 6 sieht dieses Konzept keine Verwendung vor. Die Schicht 7 ist anwendungsabhängig und muss für einen konkreten Einsatzzweck definiert werden. Diese drei
20
KAPITEL 3. KONZEPT DER PROTOKOLLFAMILIE
Schichten werden im Folgenden nicht weiter betrachtet, können jedoch später bei Bedarf ohne
Veränderungen am bisherigen Konzept noch hinzugefügt werden.
Heterogene Netze als Subnetze
Zum Datenaustausch zwischen den heterogenen Netzen wurden bisher Gateways eingesetzt, die
bekanntlich eine vollständige Umsetzung der Nutzdaten auf der Schicht 7 vornehmen mußten.
Entwickelt man die Idee der hierarchischen Protokollfamilie weiter und betrachtet jedes spezielle Netz als ein Subnetz, so wird der in Abbildung 3.5 gezeigte beispielhafte Netzwerkverbund
möglich.
1.24
Router 1
CAN
1.3
1.245
1.19
CAN
IEEE 1394
Router 2
CAN
IEEE 1394
IEEE 1394
Abbildung 3.5: Heterogene Netze als Subnetze und durch Router verbunden
Hier wird die Aufgabe statt von Gateways nun von Routern übernommen, die es ermöglichen
eine Weiterleitung der Datenrahmen auf der Schicht 3 vorzunehmen.
3.3. LÖSUNGSANSÄTZE
21
Die Vorteile dieser Vorgehensweise sind:
• Das Durchlaufen des Protokollstapels nur bis zur Schicht 3 bedeutet weniger Overhead in
den Netzübergangsknoten.
• In den Routern ist keine komplette Interpretation der Dateninhalte notwendig. Lediglich
die Header der eingehenden Datenpakte müssen analysiert werden, um das Paket mitsamt
Nutzinhalt anschließend weiterleiten zu können.
• Das Weiterleiten von Paketen durch Router benötigt weniger Ressourcen als eine Interpretation der Nutzinhalte durch Gateways und kommt damit der Implementation in embedded
Systemen entgegen.
• In Folge dessen wird der Datentransport effektiver und schneller.
• Die Wegewahl (Routing) wird sehr einfach möglich, da sie vollkommen unabhängig von
den verwendeten Feldbussen stattfinden kann. Eine Einschränkung besteht jedoch darin, dass die Wegewahl anhand einer statisch konfigurierten Routingtabelle und der darin
festgelegten Metrik vorgenommen wird und nur „manuell“ vom Systembetreuer verändert
werden kann.
• Der Ausfall von Netzwerksegmenten wird handhabbar. Alternative Wege können transparent verwendet werden. Jedoch können die typischen Kenngrößen der Feldbusse, wie
z. B. Bandbreite oder Latenzzeit, nur sehr eingeschränkt anhand der fixen Routingtabelle
berücksichtigt werden.
Der Router stellt also eine wesentlich effektivere Lösung im Gegensatz zu „allgemeinen, universellen Gateways“ dar. Die Wegewahl findet in jeglichem Fall anhand von statisch konfigurierten
Routingtabellen statt. Damit ist eine weitere der in Kapitel 3.1 geforderten Funktionalitäten
erfüllt.
Routing unter Berücksichtigung von QoS
Die Überlegungen bis hierher erlauben nun den Einsatz von Routern als Netzübergangsknoten
und ermöglichen somit die transparente Datenübertragung über alle vorhandenen Feldbusse.
Bei ausreichend vermaschten Netzwerksystem findet sich auch stets mindestens eine intakte
Verbindung. Die Wegewahl findet jedoch noch mit statisch konfigurierten Routingtabellen statt,
welche keine QoS-Parameter, und damit kaum die speziellen Eigenschaften der benutzen Feldbusse, berücksichtigen können.
Voraussetzung zunächst ist, dass jede Applikation beim Versenden von Datenpaketen Angaben
zur gewünschten QoS-Anforderung machen kann. Zur geeigneten Behandlung durch die Router
muss diese Information somit in der Vermittlungsschicht (Schicht 3) zur Verfügung stehen. Bei
der späteren Definition des Schicht 3 Paketheaders wird dafür ein entsprechendes Datenfeld
vorgesehen werden.
22
KAPITEL 3. KONZEPT DER PROTOKOLLFAMILIE
Um die Datenpakete über entsprechende Feldbusse mit den unter gegebenen Umständen optimalsten Verbindungen leiten zu können, müssen die Router nun auch noch untereinander Informationen über die zur Verfügung stehenden Verbindungen austauschen können. Basierend auf
diesen Informationen können dann die Routingtabellen dynamisch angepasst werden. In Folge dessen ist ein frühzeitiges Umleiten der Datenströme auf die derzeit optimalste Verbindung
möglich. Bei Ausfall von Verbindungen in einem stark vermaschten Netz kann die Auswahl
eines weniger optimalen, zweitbesten Weges erfolgen, um so wenigstens noch einen eingeschränkten Betrieb weiterhin zu ermöglichen.
Für den Austausch dieser Informationen und zur dynamischen Anpassung der Routingtabellen
wird der Protokollfamilie hierzu ein spezielles Transportprotokoll und eine darauf aufbauende
Applikation hinzugefügt.
3.4
Fazit
Vorteilhaft für die Programmierschnittstelle (API) ist sicherlich, dass sie der gewohnten Sichtweise von Informatikern und Software-Enwicklern entgegen kommt. Auf den ersten Blick erscheint die Lösung mit der API auch wesentlich effektiver, da nur eine zusätzliche Schicht
durchlaufen werden muss. Dieser Vorteil ergibt sich jedoch nur bei der Kommunikation im selben Netzwerksegement, für den Fokus dieser Arbeit ein Spezialfall.
Denn ein offensichtlicher Nachteil für die API Lösung ist, dass die Netzübergangsknoten weiterhin Gateways bleiben, die basierend auf der Anwendungsschicht arbeiten müssen. Dadurch
müssen die Daten zwischen unterschiedlichen Feldbussen auch jeweils die komplette Anpassungsschicht mit der Umwandlung der Adressierung und der Behandlung des Transportdienstes
durchlaufen.
Definitionsgemäß kann die Schicht 7 einen gesicherten Transportdienst nur für die unmittelbare Verbindung zwischen zwei Knoten zur Verfügung stellen. Kommunizieren zwei Endpunkte
nun über mehrere Netzsegmente, so müssen die verwendeten Gateways bestätigte Verbindungen und Transaktionen erkennen und entsprechend verarbeiten. Dies erzeugt einen zusätzlichen
Aufwand in den Gatewayknoten. Je nach Implementation der Gateway Applikation kommt es
zu Einschränkungen bei der gesicherten Ende-zu-Ende-Verbindung oder bei der Echtzeitfähigkeit.
Wie bereits oben in Kapitel 3.3.1 beschrieben kommen als weitere Funktionen, die von der
Gateway Applikation geleistet werden müssen, die alternative Wegewahl bei Ausfall von Verbindungen und die Berücksichtigung von QoS-Parametern bei der Weiterleitung von Datenpaketen hinzu. Ein spezielles Gateway, das je nach Definition der API erheblich leistungsfähig
sein muss, bietet den Übergang in die Internet-Welt.
Insgesamt betrachtet hat die API Lösung mit dem aufwendigen monolithischen Protokollblock
und der komplexen Gateway Anwendungssoftware doch erhebliche Nachteile. Die Architektur
ist wenig flexibel und dadurch nur schwer zu warten, spätere Änderungen und Erweiterungen,
z. B. das Hinzufügen von Anpassungen für weitere Feldbusse, sind nur mit erheblichem Aufwand durchzuführen. Die Erfahrungen in der Praxis mit solchen Softwaregebilden sind deshalb
bisher oftmals negativ bewertet worden.
Die hierarchische Protokollfamilie hingegen folgt der Definition des OSI Schichtenmodells und
entspricht damit der gewohnten Sichtweise des Netzwerkentwicklers. Die saubere Auftrennung
3.4. FAZIT
23
der geforderten Aufgaben in mehrere Schichten stellt eine bewährte netzwerkgerechte Lösung
dar. Der Aufwand ist jedoch auf den ersten Blick größer, weil für die einheitliche Adressierung
und die Transportdienste die Schichten 3 und 4 benötigt werden.
Ein klarer Vorteil dieser Lösung besteht jedoch darin, dass die Netzübergangsknoten zu Routern werden, damit werden in den embedded Systemen weniger Ressourcen benötigt. Die Wegewahl und das Weiterleiten von Pakten geschieht universell, unabhängig vom verwendeten
Feldbus und vollkommen transparent. Die Daten müssen den Protokollstapel zwischen unterschiedlichen Feldbussen nur bis zur Schicht 3 durchlaufen. In Folge dessen muss der verwendete Transportdienst im Gegensatz zur API hier auch nicht beachtet werden.
Die Berücksichtigung von Quality of Service für Echtzeitanwendungen ist mit der hierarchischen Protokollfamilie möglich. Die Anwendungsprogramme der Knoten können durch eine
entsprechende Definition des Paketheaders der Vermittlungsschicht QoS-Parameter für die Wegewahl angeben. Vorteilhaft ist die ohne Abhängigkeiten implementierbare Routingapplikation
zur Suche des möglichst optimalen Datenpfades und zur Anpassung der Routingtabellen, welche auf eine definierte Schnittstelle des unabhängigen Schicht 4 Routingprotokolls aufsetzen
kann.
Beim Lösungsansatz mit der hierarischen Protokollfamilie sind die Parallelen zur TCP/IPProtokollfamilie deutlich erkennbar. Zwar sind hier weiterhin spezielle Netzübergangsknoten
notwendig, jedoch erleichtert die Parallelität den Übergang zwischen eigener Protokollfamilie
und der TCP/IP-Welt.
Das modulare Konzept der Protokollfamilie ist zwar aufwendiger, jedoch insgesamt von Vorteil.
Durch die getrennten dedizierten Protokolle mit definierten Schnittstellen erleichtert es die Entwicklung, sowie auch spätere Änderungen und Erweiterungen. Solange die Schnittstellendefinitionen beibehalten werden können, sind Optimierungen an einzelnen Protokollen unabhängig
möglich.
Durch die Parallelen zur TCP/IP-Protokollfamilie könnte man beinahe annehmen, dass die
Internet-Protokolle einfach direkt verwendet werden könnten. Aufgrund des großen Ressourcenbedarfs verbietet sich dies jedoch in den vorgesehenen Anwendungsbereichen mit den dort
verwendeten Feldbussen und der embedded Systemumgebung. Begrenzend wirken auch die
Feldbusse mit ihren kleinen Nutzdatenfeldern, die in einem krassen Mißverhältnis zur Dimensionierung des IP-Protokolls mit seinem bereits 20 Byte großen Header stehen. Ebenfalls wäre
der immense Overhead nicht vertretbar, denn für Steuerapplikationen werden ja üblicherweise
nur Datenpakete mit wenigen Nutzdatenbyte übertragen.
Es muss also eine eigene, geeignete Protokollfamilie entwickelt werden. Diese darf, soll aufgrund der in Kapitel 3.1 geforderten Funktionalitäten sogar, eng verwandt zu TCP/IP sein, jedoch muss sie so definiert werden, dass sie mit möglichst vielen Feldbussen zusammen arbeiten kann. Als Mindestanforderung an die verwendten Feldbusse muss ein Nutzdatenfeld von
mehreren (mindestens 4, sinnvollerweise 8) Byte pro Rahmen gestellt werden. LIN/CAN-artige
Systeme stellen also die Untergrenze dar. Dahingegen schließt sich z. B. AS-Interface mit seiner
spartanischen Auslegung auf 4 Bit Nutzdaten je Kommunikationsrichtung aus.
In der TCP/IP-Welt hat sich die hierarische Protokollfamilie vielfältig bewährt. Daher wird
nun das Konzept entsprechend dem OSI Schichtenmodell weiter verfolgt und im folgenden
Kapitel 4 eine entsprechende Protokollfamilie definiert.
24
KAPITEL 3. KONZEPT DER PROTOKOLLFAMILIE
Kapitel 4
Definition der Protokollfamilie
Aufgrund der Diskussion in Kapitel 3 wird zur Gewährleistung der geforderten Funktionalitäten nun die hierarische Protokollfamilie umgesetzt.
Die Konvergenz der heterogenen Feldbusse geschieht über die OSI Schicht 3. Vier weitverbreitete Bussysteme, LIN, CAN, Bluetooth und IEEE 1394, wurden für die Definition von exemplarischen Anpassungen ausgewählt. Diese Busse decken sehr unterschiedliche Einsatzzwecke
und Eigenschaften ab: nachrichtenbasierte und knotenbasierte Adressierung, sehr kleine und
sehr große Nutzdatenfelder, nieder- und hochbitratige Busse, Master/Slave-Zugriff gegenüber
Arbitrierung gleichberechtigter Knoten, drahtgebundene und ein drahtloses System.
Ein Hilfsprotokoll für die Signalisierung von Netzwerkproblemen, die eigentlichen Transportprotokolle für die Übertragbarkeit, Wiederverwendbarkeit und Interoperabilität von Anwendungssoftware und das Routingprotokoll unter Berücksichtigung von QoS-Parametern sind in
der OSI Schicht 4 angesiedelt.
Die Protokolle werden in Anlehung an die TCP/IP-Protokollfamilie definiert, jedoch im Gegensatz zu dieser mit kleineren, optimierten Headern konzipiert, um einen für die Feldbusse
geringeren Overhead zu erzielen. Dementsprechend wurde die Nomenklatur mit einem führenden „M“ für „Micro“ und in Anlehnung an vergleichbare Internet-Protokolle gewählt, also z. B.
MIP (Micro Internet Protocol), MUDP (Micro User Datagram Protocol) und MTCP (Micro
Transmission Control Protocol).
Die gemeinsamen Designrichtlinien der Protokollfamilie sind wie folgt:
• Die Protokolle erhalten keinerlei eigene Header- oder Nutzdaten-Prüfsummen, um bereits
von vorne herein einen unnötigen Overhead zu vermeiden. Die darunterliegenden Netze treffen bereits ausreichende Maßnahmen für die Datenintegrität. So genügen z. B. die
Prüfsumme bei LIN, der Cyclic Redundancy Check (CRC) bei CAN, die Forward Error
Correction (FEC) und/oder der CRC bei Bluetooth und der CRC bei IEEE 1394 schon den
hinlänglichen Anforderungen.
Eigene Prüfsummen hätten zwar theoretisch den Vorteil, dass z. B. von Routern verfälschte
Datagramme als fehlerhaft vom Empfänger erkannt werden. Jedoch bedeutet eine Verfälschung des Datagramms durch einen Knoten, dass ein ernster, nicht hinnehmbarer Hardwaredefekt (beispielsweise Übertragungsfehler zwischen Mikroprozessor, Speicher und Peripherie) vorliegt, der für einen verlässlichen Betrieb grundsätzlich nicht auftreten darf.
25
26
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
• Die Protokollfelder in den Headern werden möglichst so angeordnet, dass sie auf BytePositionen ausgerichtet (Byte aligned) sind. Dies ermöglicht eine effektive Verarbeitung
in den Mikroprozessoren. An einigen Stellen wird zugunsten einer platzsparenden Anordnung der Protokollfelder auf die Byte-Anordnung verzichtet und dadurch der Verminderung des Overheads Vorrang gewährt.
• Zur Vermeidung von Redundanz besitzen die Schicht 4 Protokolle kein eigenes Feld zur
Angabe der Nutzdatenlänge. Das Feld für die Längenangabe im Schicht 3 Protokoll ist
ausreichend. Jedoch muss beachtet werden, dass der Schicht 4 Header hierbei immer einberechnet werden muss.
4.1
Micro Internet Protocol
Das Micro Internet Protocol (MIP) ist das Schicht 3 Protokoll (Vermittlungsschicht) der Protokollfamilie. Es wurde in Anlehung an RFC 791: Internet Protocol (IP) [Pos81a] konzipiert.
MIP ist die Konvergenzschicht zur Anpassung an die heterogenen Netze mit ihren unterschiedlichen Adressierungsschemen und Nutzdatengrößen. Für die darüberliegende Schicht stellt MIP
ein Datagramm mit einem einheitlichen systemweiten Adressierungsschema bereit. Außerdem
gehört zu MIP die Fähigkeit zur Fragmentierung, also der Aufteilung eines Datenpaketes auf
mehrere Datenrahmen der darunterliegenden Schicht, falls das Paket die Nutzdatenkapazität des
genutzten Bussystems überschreitet. Die Fragmentierung wird im Bedarfsfall vom Schnittstellenmodul zur Anpassung an einen bestimmten Feldbus übernommen.
MIP nutzt verbindungslose Datagramme, keine Punkt-zu-Punkt-Verbindungen oder virtuellen
Verbindungen. MIP bietet keine gesicherte Kommunikation oder Mechanismen für erneute
Übertragung (Retransmission), die Pakete werden vom Empfänger nicht bestätigt (kein Acknowledgement). Entsprechend den allgemeinen Designrichtlinien aus Kapitel 4 existieren keine
eigenen Prüfsummen für Header oder Daten, da die Datenintegrität durch die Sicherungsschicht
der zugrundeliegenden Feldbusse gewährleistet wird. MIP selbst unterstützt keine Flußkontrolle, diese Funktion steht nur optional mit dem Pakettyp „Source Quench“ des Hilfsprotokolls
MICMP (Kapitel 4.2) zur Verfügung.
Als Adressierungsschema nutzt MIP Knotenadressen mit 16 Bit, welche in einen 8 Bit Netzteil und einen 8 Bit Hostteil aufgeteilt werden. Unter Berücksichtigung reservierter Adressen
ergeben sich dadurch max. 254 Subnetze mit jeweils max. 254 Knoten. Dies reicht für unsere
anvisierten Anwendungsbereiche aus und bietet noch genügend Reserven:
• Die LIN Spezifikation [LIN03] besagt, dass aufgrund der physikalischen Schnittstelle ein
Bus nicht mehr als 16 Knoten haben soll. Die theoretische Grenze bei LIN besteht aufgrund der 6 Bit großen Identifier. Die Werte von 0 bis 59 können für den normalen Betrieb
(sogenannte signal-carrying frames) genutzt werden. In Folge dessen könnten somit also
maximal 60 Knoten angesprochen werden.
• Bei CAN gibt es eine eher theoretische Begrenzung auf 211 und 229 Knoten durch die
logische Adressierung und die verlustlose Arbitrierung, weil zwei Knoten nicht denselben
Identifier verwenden dürfen [BOS91]. In der Praxis wirkt die physikalische Schnittstelle
4.1. MICRO INTERNET PROTOCOL
27
begrenzend, das ISO 11898 [ISO03] High Speed Interface erlaubt je nach eingesetztem
Transceiver maximal 32 Knoten [Law94], bzw. mindestens 110 Knoten werden garantiert
[PCA00].
• Viele Industriebussysteme erlauben 32 oder 64 Teilnehmer pro physikalischem Segment,
bzw. 128 oder 256 logisch adressierbare Teilnehmer [Law94]. Bei PROFIBUS sind z. B.
pro Segment maximal 32 Teilnehmer, bei Einsatz von Repeatern maximal 126 Teilnehmer
erlaubt [Pop00].
• Bei IEEE 1394 sind maximal 63 Knoten pro Bus möglich [IEE95, IEE98, IEE01b].
Durch die zum Internet Protokoll vergleichbare Struktur der MIP Adresse wird der Übergang
in die Standard-Internet-Welt für entsprechende Gateways erleichtert. Die Domäne der Protokollfamilie kann wie ein Klasse B Subnetz aus Sicht von IP betrachtet werden.
Für das Nutzdatenfeld von MIP sind maximal 255 Byte vorgesehen. Dies stellt einen guten
Kompromiss für die Forderungen aus Kapitel 3.1 nach wenigen Byte im Normalbetrieb und
zeitweilig größeren Datenblöcken zur Softwareaktualisierung von Steuergeräten dar. Außerdem orientiert sich diese Größe an der Dimensionierung von Feldbussen, wie z. B. PROFIBUS
[DIN91, EN96, IEC03a, IEC03b, Pop00] oder LON.
Abbildung 4.1 zeigt den Aufbau eines MIP Datagramms. Die einzelnen Protokollfelder werden
anschließend erläutert.
Ver
ToS
TTL
Protocol
Source Address (SA)
Destination Address (DA)
Data Length
Data
Abbildung 4.1: MIP Datagramm
Version (Ver)
In diesem Feld wird die verwendete Version des MIP Protokolls angegeben. Für die hier vorgestellte Definition gilt Ver = 1.
Bei späteren Änderungen oder Verbesserungen wird die Versionsnummer inkrementiert. Damit
können verschiedene Varianten im selben System verwendet und voneinander unterschieden
werden.
Type of Service (ToS)
Der Type of Service dient den Applikationen zur Angabe des geforderten Quality of Service
28
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
(QoS). Ein kleinerer Zahlenwert bedeutet eine höhere Qualitätstufe, ansonsten wird die genaue
Bedeutung des ToS vom Systembetreuer festgelegt.
Der Wertebereich ist 0x00Hex bis 0x1FHex .
Time To Live (TTL)
Time To Live enthält die Angabe der maximalen Anzahl an Weiterleitungen. Passiert eine Nachricht einen Router, so wird der Wert dekrementiert. Ist TTL = 0, dann muss die Nachricht gelöscht und nicht mehr weiter behandelt werden. Dadurch kann bei einem falsch konfigurierten
System vermieden werden, dass Nachrichten unendlich lange im Netz vorhanden bleiben und
Ressourcen belegen.
Der Wertebereich ist 0x00Hex bis 0x1FHex .
Protocol
Mit Hilfe des Feldes Protocol kann das erhaltene MIP Datagramm unterschiedlichen höheren
Protokollen zugeordnet werden. Es wurden dabei folgende Typen deklariert (Tabelle 4.1).
0x1Hex
0x2Hex
0x3Hex
0x4Hex
Micro Internet Control Message Protocol (MICMP)
Micro User Datagram Protocol (MUDP)
Micro Transmission Control Protocol (MTCP)
Micro Open Shortest Path First (MOSPF)
Tabelle 4.1: MIP Protocol
Destination Address (DA)
Die Destination Address enthält die MIP Empfängeradresse. Der Wertebereich ist 0.0 bis
255.255. Das Subnetz 0 und die Hostadresse 0 ist reserviert. Die Adresse x.255 stellt einen
Broadcast im Subnetz x dar, die Adresse 255.255 einen Broadcast im lokalen Netz.
Source Address (SA)
Die Source Address enthält die MIP Absenderadresse. Anwendung und Wertebereich ist entsprechend der DA.
Data Length
Das Feld Data Length enthält die Angabe über die Anzahl von Nutzdatenbyte im MIP Datagramm.
Der Wertebereich ist 0x00Hex bis 0xF FHex .
Data
Das Feld Data enthält die Nutzdaten. Entsprechend Data Length sind zwischen 0 und 255 Byte
erlaubt.
4.1. MICRO INTERNET PROTOCOL
4.1.1
29
Schnittstelle zu LIN
Local Interconnect Network (LIN) [LIN03] arbeitet mit einem Master/Slave-Buszugriff bei dem
nicht jeder Knoten selbständig auf den Bus zugreifen kann, sondern vom Master angefragt werden muss. Der angesprochene Knoten sendet anschließend sein Datenpaket als Broadcast, so
dass alle Teilnehmer die Information empfangen können. Auf diese Weise können beliebige
Knoten direkt miteinander kommunizieren.
Durch die maximale Datenrate von 20 kBit/s und der Abhängigkeit vom Master eignet sich
LIN jedoch nicht als Backbone-Netzwerk, sondern empfiehlt sich für die Anbindung von Blätterknoten an das System. Nicht zwingend, aber sinnvoll ist, dass der Master die Funktion des
Standardrouters (sogenanntes Default Gateway) für das Subnetz übernimmt und die Slaves die
Blätterknoten sind.
Der Aufbau eines LIN 2.0 Frame ohne Sendepause, Synchronisationsfeld und Leerräume wird
in Abbildung 4.2 gezeigt. Der Protected Identifier wird ausschließlich vom Master gesendet,
Data und Checksum werden vom angesprochenen Knoten, dazu zählt auch der Master selbst,
gesendet.
Protected Identifier
Identifier + Parity
6 + 2 Bit
Data
Checksum
1 .. 8 Byte
1 Byte
Abbildung 4.2: LIN Datenrahmen [LIN03]
Die LIN Spezifikation [LIN03] erlaubt es dem Systembetreuer, verschiedene Strategien zur
Abfrage der Knoten zu verfolgen und damit Einfluß auf das Ansprechverhalten des LIN Subsystems zu nehmen. Mit unbedingten Datenrahmen (unconditional frames) werden die Knoten
zyklisch vom Master aufgerufen. Mit ereignisgesteuerten Datenrahmen (event-triggered frames) kann eine Gruppe von Knoten angesprochen werden, wobei aber nur der oder die Knoten
antworten, die Datenrahmen versenden wollen. Unregelmäßige Datenrahmen (sporadic frames)
erlauben es dem Master, dass er bestimmte Knoten, die Datenrahmen versenden wollen, außerhalb des deterministischen Zyklus aufrufen kann.
Anpassen des Adressierungsschemas
Um zusätzlichen Overhead durch ein Protokoll zur Auflösung von Schicht 3 Adressen in
Schicht 2 Adressen zu vermeiden (vgl. z. B. RFC 826: An Ethernet Address Resolution Protocol
[Plu82]) erfolgt die Zuordnung der MIP Adresse auf den LIN Identifier starr. Für unbedingte
und unregelmäßige Datenrahmen werden hierzu die unteren 6 Bit der MIP Source Address als
LIN Identifier verwendet. Als Folge hiervon und in Kombination mit Beschränkungen der LIN
Spezifikation [LIN03] sind in einem LIN Subnetz damit theoretisch nur die Hostadressen von
1 bis 59 erlaubt, was aber hinnehmbar ist.
Da ein LIN Bus aufgrund der physikalischen Schnittstelle nicht mehr als 16 Knoten haben soll
[LIN03], sind niemals alle verfügbaren Werte des Identifiers mit Hostadressen belegt. Dies eröffnet dem Systembetreuer die Möglichkeit, die ungenutzten Identifier für die Verwendung mit
ereignisgesteuerten Datenrahmen als Gruppenadressen zu definieren.
30
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Zur Übersicht wird die Verwendung des LIN Protected Identifiers in Abbildung 4.3 gezeigt.
LIN SA
Par
Abbildung 4.3: Verwendung des Protected Identifier
LIN Source Address (LIN SA)
Die LIN Source Address enthält die Absenderadresse des angefragten LIN Knotens bei der
Verwendung unbedingter oder unregelmäßiger Datenrahmen bzw. die Gruppenadresse bei der
Verwendung ereignisgesteuerter Datenrahmen.
Der Wertebereich ist 0x00Hex bis 0x3FHex . Die Adresse 0x00Hex ist reserviert. Die Adressen
0x3CHex bis 0x3FHex sind bereits von der LIN Spezifikation [LIN03] reserviert.
Parity (Par)
Der Paritätswert des Protected Identifiers berechnet sich entsprechend der LIN Spezifikation
[LIN03].
Fragmentierung
Beim Vergleich der Größen von einem MIP Datagramm mit einem LIN Datenrahmen wird offensichtlich, dass vor der Übergabe an die LIN Sicherungsschicht fragmentiert werden muss.
Um die MIP Datagramme aufzuteilen und im Empfänger wieder in der richtigen Reihenfolge
zusammenfügen zu können, benutzt das Anpassmodul einen eigenen kleinen Header mit dem
Feld Label, welches zusammengehörende Fragmente kennzeichnet, und dem Feld Fragmentnummer, welches die Position eines Fragments kennzeichnet.
Außerdem muss berücksichtigt werden, dass LIN nur Datenrahmen mit einer festen Größe erlaubt, die vorab vom Systembetreuer festgelegt werden muss. Vereinbarungsgemäß werden vom
Anpassmodul immer Datenrahmen mit den maximal möglichen 8 Byte Nutzdaten verwendet.
Deshalb muss in den Header des Anpassmoduls noch zusätzlich die Information über die Anzahl der transportierten Nutzdaten pro Datenrahmen eingefügt werden. Für unbedingte und unregelmäßige Datenrahmen stehen 8 Nutzdatenbyte zur Verfügung, somit können aufgrund des
Headers zur Fragmentierung also maximal 6 Byte eines MIP Fragments transportiert werden.
Für ereignisgesteuerte Datenrahmen stehen nur 7 Nutzdatenbyte zur Verfügung, es können dann
also maximal nur 5 Byte eines MIP Fragments transportiert werden.
Der Inhalt des LIN Feldes Data für unbedingte und unregelmäßige Datenrahmen wird in Abbildung 4.4 und für ereignisgesteuerte Datenrahmen in Abbildung 4.5 gezeigt. Anschließend
erfolgt die Beschreibung der Protokollfelder.
4.1. MICRO INTERNET PROTOCOL
Label
FragmNum
31
DLen
Data
Abbildung 4.4: LIN Data (unconditional frame, sporadic frame)
ID of unc. frame
Label
FragmNum
DLen
Data
Abbildung 4.5: LIN Data (event-triggered frame)
Protected Identifier of unconditional frame (ID of unc. frame)
Enthält, wie in der LIN Spezifikation [LIN03] festgelegt, den dazugehörigen geschützen Identifier des unbedingten Datenrahmens.
Label
Label enthält eine laufende Nummer, die vom sendenden Knoten im lokalen Subnetz für jedes MIP Datagramm vergeben wird. Im Falle des Überlaufs bei 127 wird die Zählung bei 1
fortgeführt. Damit können die Fragmente wieder einem MIP Datagramm eindeutig zugeordnet
werden.
Der Wert 0 wird für unbedingte Datenrahmen benutzt, falls kein MIP Datagramm zum Versenden ansteht.
Fragment Number (FragmNum)
Mit Hilfe der Fragment Number können die Fragmente eines MIP Datagramms in der richtigen
Reihenfolge vom empfangenden LIN Knoten wieder zusammengesetzt werden (Tabelle 4.2).
Data Length (DLen)
Das Feld Data Length enthält die Angabe über die Anzahl Nutzdatenbyte eines Fragments.
Der Wertebereich für unbedingte und unregelmäßige Datenrahmen ist 0x00Hex bis 0x06Hex , für
ereignisgesteuerte Datenrahmen 0x00Hex bis 0x05Hex .
Data
Das Datenfeld enthält, entsprechend DLen, bei unbedingten und unregelmäßigen Datenrahmenn bis zu 6 Byte bzw. bei ereignisgesteuerten Datenrahmen bis zu 5 Byte des Fragments des
MIP Datagramms. Ungenutzte Byte müssen mit dem Wert 0x00Hex aufgefüllt werden, so dass
der LIN Datenrahmen immer 8 Byte groß ist (sogenanntes Padding).
32
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
0x00Hex
0x01Hex
0x02Hex
..
.
0x2BHex
..
.
0x34Hex
Fragment 0
(Erste 6 bzw. 5 Byte des MIP Datagramms,
enthält ersten Teil des MIP Headers)
Fragment 1
(Nächste 6 bzw. 5 Byte des MIP Datagramms,
enthält zweiten Teil des MIP Headers und MIP Daten)
Fragment 2
(Enthält MIP Daten)
..
.
Fragment 43
(Letztes Fragment bei maximaler Nutzdatenmenge und bei
ausschließlicher Nutzung von unbedingten oder unregelmäßigen Datenrahmen)
..
.
Fragment 52
(Letztes Fragment bei maximaler Nutzdatenmenge und bei
ausschließlicher Nutzung von ereignisgesteuerten Datenrahmen)
Tabelle 4.2: LIN Fragment Number
Aufgrund der Reihenfolge der Datenfelder im MIP Header muss ein Knoten nur das Fragment 0
auswerten, um zu erkennen ob es der Empfänger ist. Trifft dies nicht zu, so können alle darauffolgenden Fragmente anhand des LIN Identifiers und des Labels verworfen werden. Dies spart
Ressources in den nicht adressierten Knoten.
Checksum
Das Feld Checksum enthält, wie in der LIN Spezifikation [LIN03] festgelegt, eine über den LIN
Datenrahmen berechnete Prüfsumme.
4.1.2
Schnittstelle zu CAN
Controller Area Network (CAN) [BOS91] ist ein Bussystem mit gleichberechtigten Knoten. Die
Adressierung geschieht nachrichtenbasiert, d.h. ein Knoten sendet Datenrahmen, die bestimmte
Informationen enthalten, mit einem festgelegten Identifier als Broadcast an alle Teilnehmer. Die
Arbitrierung auf den Bus geschieht priorisiert anhand des Identifiers.
Aufgrund der maximalen Datenrate von 1 MBit/s und dem Multimaster-Betrieb eignet sich
CAN auch als Backbone-Netzwerk für das hier vorgestellte System. Eine Einschränkung stellt
jedoch die maximale Nutzdatenmenge von 8 Byte dar.
Für die Definition dieses Anpassmoduls wurde das Schicht 3 Protokoll nach ISO 15765-2
[ISO04b] und das INTERNET-DRAFT IP over CAN [CF01], welches allerdings nicht als RFC
verabschieded wurde, betrachtet.
Um möglichst viele Headerinformationen, wie z. B. lokale Sender-/Empfängeradressse und die
Informationen für die Fragmentierung, im Identifier unterbringen zu können und dadurch mög-
4.1. MICRO INTERNET PROTOCOL
33
lichst viele Nutzdaten pro Datenrahmen transportieren zu können, verwendet das Anpassmodul
für CAN ausschließlich Extended Frames mit 29 Bit Identifier. Der Aufbau eines CAN 2.0 Extended Frame [BOS91] wird in Abbildung 4.6 gezeigt.
Standard Frames mit 11 Bit Identifier können alle weiterhin für die bisherige nachrichtenbasierte Kommunikation weiterverwendet werden.
Identifier
29 Bit
Data Length Code
3 Bit
Data
0 .. 8 Byte
Checksum
15 Bit
Abbildung 4.6: CAN Extended Datenrahmen [BOS91]
Anpassen des Adressierungsschemas
Um zusätzlichen Overhead durch ein Protokoll zur Auflösung von Schicht 3 Adressen in
Schicht 2 Adressen zu vermeiden (vgl. z. B. RFC 826: An Ethernet Address Resolution Protocol
[Plu82]) erfolgt die Zuordnung der MIP Adressen auf den CAN Identifier starr. Die Umsetzung
der Adressen geschieht wie in INTERNET-DRAFT IP over CAN vorgeschlagen. Hierzu werden jeweils die unteren 8 Bit der MIP Destination Address und Source Address verwendet
und als Teil des CAN Identifiers verwendet. Die Adresse des sendenden Knotens im Identifier
garantiert, dass niemals zwei Knoten denselben Identifier benutzen. Die Adresse des empfangenden Knotens im Identifier ermöglicht eine Entlastung der Knoten, indem die Empfangsfilter
im CAN Controller so konfiguriert werden können, dass nur noch Datenrahmen an die eigene
Adresse und Broadcasts an den Mikroprozessor weitergegeben werden.
Fragmentierung
Die Protokolle ISO 15765-2 und INTERNET-DRAFT IP over CAN realisieren die Fragmentierung von Datagrammen mit einer Gesamtlänge von bis zu 4095 Byte. Jedoch wird für die
Numerierung der Fragmente ein Sequenzzähler verwendet, der nach jeweils 24 = 16 CAN Datenrahmen mit 7 bzw. 8 Byte, entsprechend 112 bzw. 128 Byte, überläuft. Folglich könnte es
vorkommen, dass Fragmente nicht mehr einer eindeutigen Position im Datagramm zugeordnet
werden können.
Eine weitere Einschränkung besteht darin, dass jeweils nur ein fragmentiertes Datagramm pro
Richtung zwischen zwei Knoten übertragen werden kann. Durch das Fehlen eines Feldes zur
Bezeichnung zusammengehörender Fragmente (Label) würden sich ansonsten mehrere Datagramme vermischen können.
Um die zuvor genannten Probleme auszuschließen, wird die Fragmentierung analog zu Kapitel
4.1.1 vorgenommen. Das Anpassmodul benutzt einen eigenen kleinen Header mit dem Feld
Label, welches zusammengehörende Fragmente kennzeichnet, und dem Feld Fragmentnummer,
welches die Position eines Fragments kennzeichnet, um die MIP Datagramme aufzuteilen und
im Empfänger wieder in der richtigen Reihenfolge zusammenfügen zu können.
34
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Verwendung der Datenfelder
Der Aufbau des CAN Identifiers wird in Abbildung 4.7 gezeigt. Anschließend erfolgt die Beschreibung der Protokollfelder.
Die Anordnung der Felder wurde so gewählt, dass von der Priorisierung des CAN profitiert werden kann. Bit 28, höchstwertigstes Bit (MSB – Most Significant Bit) von Type, wird als erstes
gesendet; Bit 0, niederwertigstes Bit (LSB – Least Significant Bit) von CAN Source Address
(CAN SA), wird als letztes gesendet.
Type
ToS
Label hi
CAN DA
CAN SA
Abbildung 4.7: CAN Identifier
Type
Mit Hilfe des Types kann die erhaltene CAN-Nachricht unterschiedlichen Schicht 3-Protokollen
zugeordnet werden. Für MIP Datagramme wird die Kennung 0b100Bin verwendet. Eine Gruppe
von 29 Bit Identifiern bleibt für die Kompatibilität mit ISO 15765-2 [ISO04b] reserviert. Die
verbleibenden Identifier können mit der bisherigen, im CAN Standard [BOS91] definierten,
nachrichtenbasierten Kommunikation verwendet werden. Tabelle 4.3 gibt einen Überblick über
die deklarierten Typen.
0b000Bin
0b001Bin
0b010Bin
0b011Bin
frei für bisheriges nachrichtenbasiertes CAN
frei für bisheriges nachrichtenbasiertes CAN
frei für bisheriges nachrichtenbasiertes CAN
reserviert für Kompatibilität zu ISO 15765-2
0b100Bin
MIP Datagramm
0b101Bin
0b110Bin
0b111Bin
frei für bisheriges nachrichtenbasiertes CAN
frei für bisheriges nachrichtenbasiertes CAN
frei für bisheriges nachrichtenbasiertes CAN
Tabelle 4.3: CAN Type
Type of Service (ToS)
Der Type of Service wird direkt aus dem MIP Datagramm übernommen, um beim Versenden
des CAN Datenrahmens von der priorisierten Arbitrierung des CAN zu profitieren. Damit ist es
möglich die unterschiedlichen Prioritätsstufen für den Quality of Service (QoS) direkt abzubilden.
Bei CAN Controllern mit mehreren Empfangspuffern und jeweils eigenen Empfangsfiltern kann
ToS auch sogleich zur Einordnung in verschiedene Warteschlangen berücksichtigt werden.
4.1. MICRO INTERNET PROTOCOL
35
Label hi
Label hi enthält die oberen 5 Bit (MSBs) einer laufenden Nummer, die vom sendenden Knoten
im lokalen Subnetz für jedes MIP Datagramm vergeben wird. Die zwei dazugehörigen unteren
Bit (LSBs) befinden sich im Datenteil des CAN Datenrahmens. Im Falle des Überlaufs bei
127 wird die Zählung bei 0 fortgeführt. Damit können die Fragmente eines MIP Datagramms
eindeutig wieder zugeordnet werden.
CAN Destination Address (CAN DA)
Die CAN Destination Address enthält die Empfängeradresse des CAN Knotens.
Der Wertebereich ist 0x00Hex bis 0xF FHex . Die Adresse 0x00Hex ist reserviert, die Adresse
0xF FHex wird für Broadcastnachrichten an alle CAN Knoten benutzt.
CAN Source Address (CAN SA)
Die CAN Source Address enthält die Absenderadresse des CAN Knotens.
Der Wertebereich ist 0x00Hex bis 0xF FHex . Die Adressen 0x00Hex und 0xF FHex sind reserviert.
Der CAN Data Length Code (DLC) wird in Abbildung 4.8 gezeigt.
DLC
Abbildung 4.8: CAN Data Length Code
Data Length Code (DLC)
Das Feld Data Length Code enthält, wie im CAN Standard [BOS91] festgelegt, die Angabe
über die Anzahl der Nutzdatenbyte eines CAN Datenrahmen.
Die Verwendung der CAN Nutzdaten (Data) wird in Abbildung 4.9 gezeigt.
L lo
FragmNum
Data
Abbildung 4.9: CAN Data
36
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Label lo (L lo)
Label lo enthält die unteren 2 Bit (LSBs) einer laufenden Nummer, die vom sendenden Knoten
im lokalen Subnetz für jedes MIP Datagramm vergeben wird. Die 5 zugehörigen oberen Bit
(MSBs) befinden sich im Identifier des CAN Datenrahmens.
Fragment Number (FragmNum)
Mit Hilfe der Fragment Number können die Fragmente eines MIP Datagramms in der richtigen
Reihenfolge vom empfangenden CAN Knoten wieder zusammengesetzt werden (Tabelle 4.4).
0x00Hex
0x01Hex
..
.
0x25Hex
Fragment 0
(Erste 7 Byte des MIP Datagramms,
entspricht dem MIP Header)
Fragment 1
(Nächste 7 Byte des MIP Datagramms,
enthält MIP Daten)
..
.
Fragment 37
(Letztes Fragment bei maximaler Nutzdatenmenge)
Tabelle 4.4: Fragment Number
Data
Das Datenfeld enthält 1 bis 7 Byte, entsprechend DLC − 1, des MIP Datagramms.
Checksum
Das Feld Checksum enthält, wie im CAN Standard [BOS91] festgelegt, eine über den CAN
Datenrahmen berechnete Cyclic Redundancy Check (CRC) Prüfsumme.
4.1.3
Schnittstelle zu Bluetooth
Bluetooth (BT) [SIG04c] arbeitet mit einem Master/Slave-Zugriff bei dem nicht jeder Knoten
selbständig auf die Luftschnittstelle zugreifen kann. Die Kommunikation findet nur Punkt-zuPunkt zwischen dem Master und einem der maximal sieben aktiven Slaves des Piconetzes anhand der Logical Transport Address (LT_ADDR) statt, bzw. als Broadcast vom Master zu den
aktiven oder passiven Slaves. Eine direkte Kommunikation von Slave zu Slave ist nicht möglich.
Über die Parked Member Address (PM_ADDR) können sich maximal 255 weitere Slaves in
einem Piconetz im geparkten Zustand befinden. Über die vom Hersteller vergebene eindeutige Geräteadresse (BD_ADDR – Bluetooth Device Address) sind theoretisch sogar bis zu 248
geparkte Slaves möglich. Slaves im geparkten Zustand bleiben auf den Master synchronisiert
und können durch eine vereinfachte, insbesondere schnellere, Prozedur wieder in den aktiven
Zustand wechseln, um wieder die aktive Kommunikation mit dem Master aufzunehmen.
4.1. MICRO INTERNET PROTOCOL
37
Aufgrund der Struktur mit einem Master und maximal 7 aktiven Slaves eignet sich Bluetooth
ebenfalls nicht als Backbone-Netzwerk, sondern sollte auf die Anbindung von Blätterknoten
beschränkt werden. Der Master muss die Funktion des Standardrouters (sogenanntes Default
Gateway) für das Subnetz übernehmen, um Datagramme zwischen den Slaves, welche die Blätterknoten sind, weiterzuleiten.
Mehrere Piconetze mit gemeinsamen Geräten können ein Scatternetz bilden. So kann ein Gerät
sowohl Master mit einem eigenen Piconetz sein, als auch Slave in anderen Piconetzen. Oder
ein Gerät verhält sich in mehreren Piconetzen als Slave. Durch den Aufbau eines Scatternetzes
und unter Einbeziehung geparkter Slaves können die Beschränkungen zwar nicht beseitigt, aber
zumindest aufgeweicht werden.
Für den Transport von Datagrammen wird vom Anpassmodul das Bluetooth Personal Area Networking (PAN) Profile [SIG04b] mit dem Bluetooth Network Encapsulation Protocol (BNEP)
over Logical Link Control and Adaptation Protocol (L2CAP) [SIG04a] verwendet (Abbildung
4.10). Die BNEP Datenrahmen dienen Schicht 3 Protokollen, wie z. B. IP, als Ersatz für Ethernet Datenrahmen (IEEE 802.3 [IEE02]). Der original Ethernet Header wird hierzu durch einen
inhaltlich vergleichbaren BNEP Header ersetzt.
BNEP Type
7 Bit
Extension Flag
1 Bit
Payload based on BNEP Type
0 .. 1500/1504 Byte
Abbildung 4.10: BNEP over L2CAP Datenrahmen [SIG04a]
Um unnötigen Overhead beim Transport von MIP Datagrammen zu vermeiden, ist von Vorteil,
dass bei BNEP im Gegensatz zu Ethernet kein Auffüllen des Datenrahmens auf eine Mindestgröße (sogenanntes Padding) vorgeschrieben ist. Im Falle des BNEP_GENERAL_ETHERNET
Pakettyps, welches z. B. einen Ethernetdatenrahmen vollständig ersetzt, würden aber zum
BNEP Datenrahmen immerhin noch weitere 14 Byte Header (6 Byte Zieladresse, 6 Byte Quelladresse, 2 Byte Protokolltyp) hinzukommen. Dies würde wiederum einen erheblichen Overhead
für MIP erzeugen.
Durch Definition eines eigenen BNEP Type aus dem für zukünftige Verwendung reservierten Bereich 0x05Hex bis 0x7EHex kann jedoch ein eigenes Format definiert werden, welches
für MIP mit einem kleineren Header auskommt. Passend zum Protokollpräfix „M“ der Protokollfamilie wird anhand dem ASCII (American Standard Code for Information Interchange)
Zeichensatz der BNEP Type = 0x4DHex verwendet
Anpassen des Adressierungsschemas –
Hilfsprotokoll Micro Address Resolution Protocol for Bluetooth
Im Gegensatz zu den Anpassmodulen für LIN oder CAN (Kapitel 4.1.1 oder 4.1.2) ist eine starre
Zuordnung von MIP Adressen auf das Bluetooth Adressierungsschema nicht möglich. Je nach
Betriebszustand verwendet Bluetooth verschiedene Adressen, um die Teilnehmer eines Piconetzes zu identifizieren. Es werden hierzu die Bluetooth Device Address (BD_ADDR) oder die
vom Master an aktive bzw. passive Slaves vergebene Logical Transport Address (LT_ADDR)
bzw. Parked Member Address (PM_ADDR) verwendet [SIG04c].
38
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Für dieses Anpassmodul ist deshalb die Definition eines Hilfsprotokolls, das Micro Address Resolution Protocol for Bluetooth (MARP-BT) (vgl. z. B. RFC 826: An Ethernet Address Resolution Protocol [Plu82]), zur Auflösung von Schicht 3 Adressen in Schicht 2 Adressen notwendig.
Die alleinige Mitteilung der MIP Adressen durch MARP-BT ist ausreichend, da die je nach
Betriebszustand notwendigen Bluetooth Adressen (BD_ADDR, LT_ADDR und PM_ADDR)
innerhalb des Bluetooth Protokollstacks im Knoten bereits vorliegen.
Um einen unnötigen Datenverkehr durch MARP-BT zu vermeiden, sollten die Knoten empfangene Informationen der Adressauflösung für einen gewissen Zeitraum zwischenspeichern.
Dazu wird eine MARP-BT Tabelle mit Zuweisungen der MIP Adresse zur BD_ADDR, beim
Master je nach Betriebszustand des Slaves zusätzlich mit der LT_ADDR oder PM_ADDR und
einem Zeitstempel der letzten Aktualisierung bzw. Nutzung festgehalten.
Zwischen Master und einem aktiven Slave wird der gegenseitige Austausch der MIP Adressen
mit dem MARP-BT Datagramm (Abbildung 4.11) in einem BNEP over L2CAP Datenrahmen
(Abbildung 4.10) durchgeführt. Für einen bandbreiteneffizienteren Austausch kann die MARPBT Anfrage (Request) vom Master an alle aktiven oder passiven Slaves mit einem Active Slave
Broadcast (ASB) oder Parked Slave Braodcast (PSB) gestellt werden [SIG04c]. Die MARPBT Antwort (Reply) muss von einem aktiven Slave wiederum in einem BNEP over L2CAP
Datenrahmen erfolgen.
Type Ver OpCode
MIP DA
MIP SA
Abbildung 4.11: MARP-BT Datagramm
Type
Mit Type = 0x0Hex wird angegeben, dass ein MARP-BT Datagramm übertragen werden soll.
Version (Ver)
In diesem Feld wird die verwendete Version des MARP-BT Protokolls angegeben. Für die hier
vorgestellte Definition gilt Ver = 1.
Bei späteren Änderungen oder Verbesserungen wird die Versionsnummer inkrementiert. Damit
können verschiedene Varianten im selben System verwendet und voneinander unterschieden
werden.
OpCode
Der OpCode gibt die Funktion des MARP-BT Datagramms laut Tabelle 4.5 an.
MIP Destination Address (MIP DA)
Bei einer MARP-BT Anfrage per Broadcast wird hier die gesuchte MIP Adresse eingetragen.
Bei einer MARP-BT Antwort wird hier die Adresse des zuvor anfragenden Knotens eingetragen. Ansonsten wird dieses Feld auf 0.0 gesetzt.
4.1. MICRO INTERNET PROTOCOL
0x0Hex
0x1Hex
0x2Hex
39
Info
(Für unaufgeforderte Mitteilung der eigenen MIP Adresse)
Request
(Anfrage der MIP Adresse eines Knotens)
Reply
(Antwort auf eine Anfrage)
Tabelle 4.5: MARP-BT OpCode
MIP Source Address (MIP SA)
In das Feld MIP Source Address wird immer die eigene MIP Adresse des sendenden Knotens
eingetragen.
Transport von MIP Datagrammen
Im BNEP over L2CAP Datenrahmen kann ein komplettes MIP Datagramm ohne Fragmentierung transportiert werden, da Bluetooth notwendige Anpassungen der Datenblockgrößen bereits
selbst vornimmt. Abbildung 4.12 zeigt das Format zur Übertragung eines MIP Datagramms in
einem BNEP over L2CAP Datenrahmen.
Für die Kommunikation zwischen Master und Slaves gelten wiederum dieselben Randbedingungen wie bereits oben beschrieben.
Type
reserved
MIP DA lo
Ver
ToS
TTL
MIP SA
Protocol
MIP DA hi
Data Length
Data
Abbildung 4.12: Format für ein MIP Datagramm per BNEP over L2CAP
Type
Mit Type = 0x1Hex wird angegeben, dass ein MIP Datagramm übertragen werden soll.
Die restlichen Felder entsprechen dem zu transportierenden MIP Datagramm (Kapitel 4.1).
40
4.1.4
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Schnittstelle zu IEEE 1394
Der IEEE 1394 Serial Bus [IEE95, IEE98, IEE01b] ist ein Ad-hoc-Multimediabussystem mit
gleichberechtigten Knoten. Prinzipiell gibt es IEEE 1394 in zwei verschiedenen Varianten, als
Bus innerhalb eines Gerätes (sogenannte Backplane) oder zur Vernetzung von mehreren Geräten mittels Kabel. Die kabelbasierte Variante ist weit verbreitet und für das Anwendungsszenario dieser Arbeit relevant. Dahingegen hat die Backplane bis heute keinerlei praktische
Bedeutung erlangt.
Das Adressierungsschema von IEEE 1394 entspricht der Control and Status Registers (CSR)
Architektur (IEEE 1212 [IEE91], ISO/IEC 13213 [ISO94]). Die CSR Architektur wird als
64 Bit Adreßraum umgesetzt, wovon 10 Bit für die Busidentifikation (bus_ID), 6 Bit für
die Teilnehmeridentifikation (physical_ID) und die verbleibenden 48 Bit für die Adressierung innerhalb des Knotens (offset) verwendet werden. Die Busidentifikation (bus_ID) zusammen mit der Teilnehmeridentifikation (physical_ID) bilden wiederum die Knotennummer
(node_ID). Außerdem besitzt jeder Knoten eine vom Hersteller vergebene eindeutige Geräteadresse (node_unique_ID).
Das Anpassmodul baut auf die ursprünglichen IEEE 1394 Standards [IEE95, IEE98, IEE01b]
auf, die ausschließlich den „lokalen Bus“, gekennzeichnet durch die bus_ID = 0x3F FHex , verwenden. Die Koppelung mehrer Bussegmente wird erst später mit dem IEEE 1394.1 Standard
[IEE01a] definiert, der bisher noch keine praktische Bedeutung erlangen konnte.
Die Teilnehmeridentifikation (physical_ID) ist nicht fest an einen Knoten gebunden. Sie wird
nach jedem Busreset, z. B. dann wenn ein Teilnehmer hinzukommt oder den Bus verlässt, dynamisch zugewiesen und ändert sich somit fallweise.
Für die Definition dieses Anpassmoduls wurde RFC 2734: IPv4 over IEEE 1394 [Joh99] betrachtet.
Das Anpassmodul versendet Unicast Datenrahmen als Write Request for Data Block (WRDB)
[IEE95]. Abbildung 4.13 zeigt den WRDB Datenrahmen, die Beschreibung der Protokollfelder
folgt anschließend.
Destination ID (destination_ID)
Mit Destination ID wird die Knotennummer des Empfängers angegeben.
Transaction Label (tl)
Der Transaction Label ist ein eindeutiger Kennzeichner für eine offene Transaktion zwischen
den beteiligten Knoten.
Retry Code (rt)
Dieses Feld wird für das Wiederholprotokoll von IEEE 1394 [IEE95] genutzt.
Transaction Code (tcode)
WRDB Datenrahmen haben den Transaction Code tcode = 0x1Hex [IEE95].
4.1. MICRO INTERNET PROTOCOL
41
destination_ID
tl
rt
tcode
pri
source_ID
destination_offset
data_length
extended_tcode
header_CRC
data field
zero pad bytes (if necessary)
data_CRC
Abbildung 4.13: Write Request for Data Block (WRDB) Datenrahmen [IEE95]
Priority (pri)
Die Angabe der Priorität hat nur für die Backplane-Variante eine Bedeutung [IEE95].
Source ID (source_ID)
Mit Source ID wird die Knotennummer des Senders angegeben.
Destination Offset (destination_offset)
Der Offsetwert zur Adressierung im Empfängerknoten entsprechend der CSR Architektur.
Hier erwartet der Knoten, der dieses Anpassmodul umsetzt, den Empfang von MIP Datagrammen.
Data Length (data_length)
Angabe über die Größe des Nutzdatenfeldes.
Extended Transaction Code (extended_tcode)
Dieses Feld hat für einen WRDB Datenrahmen keine Bedeutung und sollte auf extended_tcode
= 0x0000Hex gesetzt werden [IEE95].
Header CRC (header_CRC)
Prüfsumme für den Header, sie berechnet sich nach dem IEEE 1394 Standard [IEE95].
42
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Data Field (data field)
Das Feld mit den Nutzdaten. Die Anzahl der Byte muss durch vier teilbar sein, ansonsten muss
mit Nullbytes aufgefüllt werden (sogenanntes Padding).
Data CRC (data_CRC)
Prüfsumme für die Nutzdaten, sie berechnet sich nach dem IEEE 1394 Standard [IEE95].
Broadcast Datenrahmen werden vom Anpassmodul als Global Asynchronous Stream Packet
(GASP) [IEE98] versendet. Der GASP Datenrahmen wird in Abbildung 4.14 gezeigt, anschließend erfolgt die Beschreibung der Protokollfelder.
data_length
tag
channel
tcode
sy
header_CRC
source_ID
specifier_ID_hi
specifier_ID_lo
version
data field
zero pad bytes (if necessary)
data_CRC
Abbildung 4.14: Global Asynchronous Stream Packet (GASP) Datenrahmen [IEE98]
Data Length (data_length)
Angabe über die Größe des Nutzdatenfeldes.
Tag (tag)
Der GASP Datenrahmen wird durch tag = 0x3Hex gekennzeichnet.
Channel (channel)
Aus dem Register BROADCAST_CHANNEL kann die zu verwendende Kanalnummer entnommen werden.
Der aktive Isochronous Resource Manager (IRM) Knoten muss dazu an der Basisadresse
4.1. MICRO INTERNET PROTOCOL
43
0xF F F F F 000 0000Hex mit Offset 224Hex .. 228Hex das Register CHANNELS_AVAILABLE
[IEE95] und mit Offset 234Hex das Register BROADCAST_CHANNEL [IEE98] ablegen.
Standardmäßig ist Kanal 31 für das Versenden von Asynchronous Stream Packets reserviert
[IEE98].
Transaction Code (tcode)
Der GASP Datenrahmen zählt zu den sogenannten Stream Packets, diese haben den Transaction
Code tcode = 0xAHex [IEE98].
Synchronization Code (sy)
Ein applikationsabhängiges Steuerfeld zum Setzen von Synchronisationspunkten im Datenstrom. Dieses Feld ist für die zukünftige Standardisierung reserviert, es sollte deshalb auf sy
= 0x0Hex gesetzt werden [IEE98].
Header CRC (header_CRC)
Prüfsumme für den Header, sie berechnet sich nach dem IEEE 1394 Standard [IEE95].
Source ID (source_ID)
Mit Source ID wird die Knotennummer des Senders angegeben.
Specifier ID (specifier_ID_hi und specifier_ID_lo)
Hier muss ein Organizationally Unique Identifier (OUI), eine Herstelleridentifikationsnummer,
die bei der IEEE Registration Authority (IEEE RA)1 beantragt werden muss, eingetragen werden.
Für diese Arbeit wurde die specifier_ID = 0x00 60 37Hex der Firma Philips Semiconductors2
verwendet, da die ersten Entwicklungsplatinen und integrierten Schaltkreise für die eigene Implementierung von diesem Hersteller stammten.
Version (version)
Die Bedeutung und Verwendung der Versionskennung wird vom Besitzer der Herstelleridentifikationsnummer (specifier_ID) definiert.
Für diese Arbeit wurde die version = 0x4D 49 50Hex benutzt, die anhand dem ASCII (American Standard Code for Information Interchange) Zeichensatz dem Protokollkürzel „M I P“
entspricht.
Data Field (data field)
Das Feld mit den Nutzdaten. Die Anzahl der Byte muss durch vier teilbar sein, ansonsten muss
mit Nullbytes aufgefüllt werden (sogenanntes Padding).
1
2
http://standards.ieee.org/regauth/index.html
http://www.semiconductors.philips.com/
44
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Data CRC (data_CRC)
Prüfsumme für die Nutzdaten, sie berechnet sich nach dem IEEE 1394 Standard [IEE95].
Anpassen des Adressierungsschemas –
Hilfsprotokoll Micro Address Resolution Protocol for IEEE 1394
Wie bei Bluetooth (Kapitel 4.1.3) ist auch hier keine starre Zuordnung von MIP Adressen auf
das IEEE 1394 Adressierungsschema möglich. Nach jedem Busreset muss zu einer bestimmten
MIP Adresse die aktuell vergebene Knotennummer (node_ID) und für WRDB Datenrahmen
die Adresse innerhalb des Knotens (offset) wieder aufgefunden werden.
Mit dem Hilfsprotokoll Micro Address Resolution Protocol for IEEE 1394 (MARP-1394) (vgl.
z. B. RFC 826: An Ethernet Address Resolution Protocol [Plu82]) wird diese Auflösung von
Schicht 3 Adressen in Schicht 2 Adressen vorgenommen. Die Mitteilung der MIP Adresse und
die Offsetadresse für den Empfang von WRDB Datenrahmen durch MARP-1394 ist ausreichend, da die ansonsten notwendigen Adressinformationen innerhalb des IEEE 1394 Protokollstacks im Knoten bereits vorliegen.
Um einen unnötigen Datenverkehr durch MARP-1394 zu vermeiden, sollten die Knoten empfangene Informationen der Adressauflösung für einen gewissen Zeitraum zwischenspeichern.
Dazu wird eine MARP-1394 Tabelle mit Zuweisungen der MIP Adresse zur node_ID, dem offset und einem Zeitstempel der letzten Aktualisierung bzw. Nutzung festgehalten. Nach einem
Busreset muss der Inhalt der Tabelle logischerweise verworfen werden.
Die Anfrage (Request) wird zweckmäßigerweise als Broadcast mit einem GASP Datenrahmen
(siehe Abbildung 4.14) gestellt. Die Antwort (Reply) erfolgt ebenfalls als Broadcast mit einem
GASP Datenrahmen oder als Unicast mit dem WRDB Datenrahmen. Das MARP-1394 Datagramm sieht wie wie in Abbildung 4.15 gezeigt aus. Die Bedeutung der Protokollfelder wird
anschließend erklärt.
Type
OpCode
Version
MIP DA
MIP SA
Sender Unicast Offset
Abbildung 4.15: MARP-1394 Datagramm
Type
Mit Type = 0x0Hex wird angegeben, dass ein MARP-1394 Datagramm übertragen werden soll.
4.1. MICRO INTERNET PROTOCOL
45
Version
In diesem Feld wird die verwendete Version des MARP-1394 Protokolls angegeben. Für die
hier vorgestellte Definition gilt Version = 1.
Bei späteren Änderungen oder Verbesserungen wird die Versionsnummer inkrementiert. Damit
können verschiedene Varianten im selben System verwendet und voneinander unterschieden
werden.
OpCode
Der OpCode gibt die Funktion des MARP-1394 Datagramms laut Tabelle 4.6 an.
0x01Hex
0x02Hex
Request
(Anfrage nach einer MIP Adresse)
Reply
(Antwort auf eine Anfrage)
Tabelle 4.6: MARP-1394 OpCode
MIP Destination Address (MIP DA)
Bei einer MARP-1394 Anfrage wird hier die gesuchte MIP Adresse eingetragen. Bei einer
MARP-1394 Antwort wird hier die Adresse des zuvor anfragenden Knotens eingetragen. Ansonsten wird dieses Feld auf 0.0 gesetzt.
MIP Source Address (MIP SA)
In das Feld MIP Source Address wird immer die eigene MIP Adresse des sendenden Knotens
eingetragen.
Sender Unicast Offset
An die duch Sender Unicast Offset bezeichnete Adresse erwartet der sendende Knoten den
Empfang von MARP-1394 und MIP Datagrammen.
Dieser Wert wird für das Feld Destination Offset (destination_offset) des WRDB Datenrahmens
benötigt.
Transport von MIP Datagrammen
Da nur die kabelbasierten Variante von IEEE 1394 benutzt wird, beträgt die Basisrate S100,
entsprechend 98,304 MBit/s. Bei der Basisrate ist bereits eine maximale Nutzdatengröße von
512 Byte erlaubt. Die Nutzdatengröße skaliert bei höheren Datenraten entsprechend. Somit
muss das Anpassmodul keine Fragmentierung vornehmen.
46
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Ein MIP Datagramm wird mit dem Protokollrahmen laut Abbildung 4.16 und je nach Zieladresse als Unicast in einem WRDB Datenrahmen oder als Broadcast in einem GASP Datenrahmen
übertragen.
Type
reserved Ver
MIP DA lo
ToS
TTL
Protocol
MIP SA
MIP DA hi
Data Length
Data
Abbildung 4.16: Format für ein MIP Datagramm per IEEE 1394
Type
Mit Type = 0x1Hex wird angegeben, dass ein MIP Datagramm übertragen werden soll.
Die restlichen Felder entsprechen dem zu transportierenden MIP Datagramm (Kapitel 4.1).
4.2
Micro Internet Control Message Protocol
Das Micro Internet Control Message Protocol (MICMP) ist ein Schicht 4 Protokoll (Transportschicht), das MIP eng begleitet und in seiner Funktion unterstützt. Es wurde in Anlehnung an
RFC 792: Internet Control Message Protocol [Pos81b] konzipiert.
MICMP dient hauptsächlich für die Signalisierung von Fehlern bei der Verarbeitung von MIP
Datagrammen und hilft bei der Netzwerkdiagnose. Weiterhin können langsame Empfangsknoten mit Hilfe von MICMP Einfluß auf die Paketsenderate schnellerer Knoten nehmen. Für
bestimmte Ziele kann mit MICMP einem Knoten ein empfohlener Router mitgeteilt werden.
MICMP bietet jedoch keinerlei Funktionen für MIP, um eine gesicherte Kommunikation zu
ermöglichen oder um Mechanismen für erneute Übertragung (Retransmission) hinzuzufügen.
Die MICMP Datenpakete beschränken sich nur auf die Rückmeldung von Information an die
Knoten. MICMP muss in jedem Knoten, der MIP verwendet, implementiert sein.
MICMP versendet seine Informationen verbindungslos und ungesichert. Das MICMP Datenpaket in Abbildung 4.17 wird im Nutzdatenfeld eines MIP Datagramms transportiert.
Um das massenhafte Versenden von Datenpaketen und damit eine mögliche Überlastung des
Netzwerks zu verhindern, werden durch MICMP Datenpakete verursachte Fehler nicht signalisiert.
4.2. MICRO INTERNET CONTROL MESSAGE PROTOCOL
Type
47
Code
Data
Abbildung 4.17: MICMP Datenpaket
Type
Mit diesem Feld wird die Funktion des MICMP Paketes laut Tabelle 4.7 angegeben.
0x0Hex
0x1Hex
0x2Hex
0x3Hex
0x4Hex
0x5Hex
Echo Test
(Testpaket)
Source Quench
(Sendeknoten zu niedrigerer Paketrate auffordern)
Redirect
(Mitteilung eines geeigneteren Routers an den Sendeknoten)
TTL Exceeded
(Lebensdauer abgelaufen)
Destination Unreachable
(Ziel nicht erreichbar)
Parameter Problem
(Allgemeines Problem mit einem Protokollfeld)
Tabelle 4.7: MICMP Type
Code
Code enthält eine Angabe, die in Abhängigkeit von Type interpretiert wird.
Data
Enthält weitere Daten in Abhängigkeit von Type. Es sind maximal 254 Byte erlaubt.
Echo Test
Hiermit kann ein durchgehender Test des kompletten Netzwerkpfades zwischen zwei Endknoten durchgeführt werden. In den Test einbezogen sind jeweils die Netzwerkverbindungen und
der Protokollstapel bis zur Schicht 3 in den Endknoten und den beteiligten Routern.
Als Nebeneffekt kann mit dem Echo Test auch die Latenzzeit des Netzwerkpfades zwischen den
48
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
zwei Endknoten ermittelt werden. Unter Annahme derselben Laufzeit für Hin- und Rückweg
errechnet sich die Latenzzeit als halbe Zeit zwischen dem Absenden des Anfragepaketes und
dem Empfangen des zugehörigen Antwortpaketes.
Geht eine Echo Test Anfrage bei einem Knoten ein, so muss diese vereinbarungsgemäß beantwortet werden. Das Feld Code (Tabelle 4.8) gibt an, ob es sich um ein Datenpaket zur Anfrage
oder zur Antwort handelt.
0x0Hex
0x1Hex
Request (Anfrage)
Reply (Antwort)
Tabelle 4.8: Code bei Echo Test
Das Feld Data besteht aus den Angaben laut Abbildung 4.18.
Identifier
1 Byte
Test Pattern
0 .. 253 Byte
Abbildung 4.18: Data bei Echo Test
Identifier
Eine Identifikationsnummer, um das Anfragepaket und das dazu gehörende Antwortpaket einander zuordnen zu können.
Test Pattern
Ein optionales Feld, das bei der Anfrage beliebige Testdaten aufnimmt. Der durch den Echo Test
angesprochene Knoten sendet im Antwortpaket die Daten aus dem Anfragepaket unverändert
zurück.
Source Quench
Erlaubt die Mitteilung von einem Router oder dem Zielknoten an den Sendeknoten, dass ein Datagramm aufgrund unzureichender Ressourcen, z. B. wegen eines vollen Eingangspuffers oder
Überlastung des Mikroprozessors, verworfen werden mußte. In Folge sollte der Sendeknoten
seine Datagramme mit soweit erniedrigter Paketrate verschicken bis diese Meldung nicht mehr
auftritt.
Das Feld Code ist ungenutzt, deshalb ist es immer 0x0Hex .
Das Feld Data enthält den MIP Header und Schicht 4 Header des ursprünglichen Paketes, um
dem Sendeknoten eine Zuordnung zum ursprünglichen Paket zu ermöglichen.
4.2. MICRO INTERNET CONTROL MESSAGE PROTOCOL
49
Redirect
Fordert den Knoten auf, dass Datagramme, die dem durch Code (Tabelle 4.9) bezeichneten
ToS oder Ziel entsprechen, an den empfohlenen Router gesendet werden sollen. Mit dieser
Information kann der durchlaufene Pfad eines Datagramms optimiert werden.
0x0Hex
0x1Hex
0x2Hex
0x3Hex
Network (Netz)
Node (Knoten)
Type of Service and Network (ToS und Netz)
Type of Service and Node (ToS und Knoten)
Tabelle 4.9: Code bei Redirect
Das Feld Data besteht aus den Angaben laut Abbildung 4.19.
Redirect Address
2 Byte
Original Headers
max. 252 Byte
(abhängig vom ursprünglichen Paket)
Abbildung 4.19: Data bei Redirect
Redirect Address
MIP Adresse des empfohlenen Router. An diesen Knoten sollten die Datagramme zukünftig
gesendet werden.
Original Headers
Enthält zur Zuordnung den MIP Header und den Schicht 4 Header des ursprünglichen Paketes.
TTL Exceeded
Informiert einen Knoten darüber, dass sein Datagramm zuviele Router passiert hat, das Feld
TTL hat den Wert 0 erreicht, und deshalb das Datagramm verworfen wurde (vgl. Kapitel 4.1).
Das Feld Code ist ungenutzt, deshalb ist es immer 0x0Hex .
Das Feld Data enthält zur Zuordnung den MIP Header und den Schicht 4 Header des ursprünglichen Paketes.
50
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Destination Unreachable
Dem Sendeknoten wird hiermit mitgeteilt, dass das Datenpaket den adressierten Knoten nicht
erreicht hat oder der Empfangsknoten das Paket intern nicht weitergeben konnte.
Mit dem Code laut Tabelle 4.10 wird dem Sendeknoten mitgeteilt an welcher Stelle das Datenpaket nicht zugestellt werden konnte.
0x0Hex
0x1Hex
0x2Hex
0x3Hex
Network (Netz)
Node (Knoten)
Protocol (Protokoll)
Port (Port)
Tabelle 4.10: Code bei Destination Unreachable
Das Feld Data enthält zur Zuordnung den MIP Header und den Schicht 4 Header des ursprünglichen Paketes.
Parameter Problem
Ein allgemeines Problem, wie z. B. ein undefinierter Wert in einem Protokollfeld, ist erkannt
worden.
Der Code laut Tabelle 4.11 gibt an in welchem Protokollfeld der Header der Fehler aufgetreten
ist.
0x0Hex
0x1Hex
0x2Hex
0x3Hex
0x4Hex
0x5Hex
0x6Hex
0x7Hex
..
.
MIP Header: Ver
MIP Header: ToS
MIP Header: TTL
MIP Header: Protocol
MIP Header: MIP DA
MIP Header: MIP SA
Erstes Feld des Schicht 4 Protokoll Headers
Zweites Feld des Schicht 4 Protokoll Headers
..
.
Tabelle 4.11: Code bei Parameter Problem
Das Feld Data enthält zur Zuordnung den MIP Header und den Schicht 4 Header des ursprünglichen Paketes.
4.3 Micro User Datagram Protocol
Das Micro User Datagram Protocol (MUDP) ist ein Schicht 4 Protokoll, das den verbindungslosen unbestätigten Transportdienst für die Protokollfamilie bereitstellt. Es wurde in Anlehnung
an RFC 768: User Datagram Protocol [Pos80] konzipiert.
4.3. MICRO USER DATAGRAM PROTOCOL
51
MUDP transportiert Datenpakete mit einem möglichst geringen Aufwand. Das Protokoll besitzt keine Wiederholmechanismen, um verlorengegangene Pakete erneut zu versenden. Die
Reihenfolge der Datenpakete wird nicht garantiert. Folglich bleibt es also gegebenenfalls der
Anwendung überlassen, selbst für geeignete (Sicherungs-)Maßnahmen zu sorgen. Eine Möglichkeit besteht z. B. darin, dass in ein Datenpaket mit Sensordaten ein Zeitstempel eingefügt
wird [RSG04].
Entsprechend den allgemeinen Designrichtlinien aus Kapitel 4 besitzt MUDP keine eigene Prüfsumme, da die Datenintegrität durch die Schicht 2 sichergestellt wird.
Zur Adressierung der verschiedenen Applikationen im Knoten stellt MUDP eine Portnummer
mit 4 Bit bereit. Damit können maximal 16 verschiedene Anwendungen gleichzeitig den unbestätigten Transportdienst nutzen. Für die anvisierten Einsatzbereiche in Steuergeräten, Sensoren
und Aktoren, die nur wenige dedizierte Aufgaben erfüllen müssen, sind somit ausreichend Reserven vorhanden.
Die Verwendung der Portnummern bleibt dem Systembetreuer frei überlassen, jedoch wird folgendes Vorgehen empfohlen:
• Der Port 0 sollte für Sonderaufgaben reserviert werden. Damit steht z. B. eine bekannte
Portnummer in einem System zur Verfügung über die Informationen zu Hersteller, Gerätetyp, Verwendung der restlichen Portnummern, etc. abgerufen werden kann (sogenanntes
Service Discovery Protocol – SDP).
• Auf die Ports 1 .. x registrieren sich bekannte oder über SDP abfragbare Applikationen.
Hierüber können Datenpakete an bestimmte Dienste des Knotens geschickt werden.
• Die Ports x+1 .. 15 werden dynamisch von Applikationen, die bisher noch keinen Port belegt haben, für ausgehende Verbindungen benutzt.
Die Festlegung von x, also die Aufeilung zwischen bekannten und dynamisch genutzten Portnummern, kann unabhängig für jeden Knoten erfolgen.
Die Abbildung 4.20 zeigt das MUDP Datenpaket, welches im Nutzdatenfeld eines MIP Datagramms transportiert wird. Die Beschreibung der einzelnen Protokollfelder erfolgt wieder
anschließend.
D Port
S Port
Data
Abbildung 4.20: MUDP Datenpaket
Destination Port (D Port)
Diese Portnummer adressiert eine bestimmte registrierte Applikation im empfangenden Knoten.
Der Wertebereich ist 0x0Hex bis 0xFHex .
52
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Source Port (S Port)
Hier sollte eine Portnummer von der Applikation im Sendeknoten angegeben werden. Damit
wird eine eindeutige Zuordnung auf die Quelle ermöglicht, außerdem kann diese Portnummer
sogleich für Antwortpakete des Empfangsknoten genutzt werden.
Wenn diese Funktion nicht genutzt werden soll, dann muss S Port = 0 sein.
Data
Hier sind die Nutzdaten für die Applikation enthalten. In Schritten von einem Byte sind maximal 254 Byte zulässig.
Im MUDP Header ist entsprechend den allgemeinen Designrichtlinien aus Kapitel 4 keine Längenangabe für das Feld Data vorgesehen, da zum MIP Header bereits ein Feld für die Zahl der
Nutzdatenbyte aus der Schicht 4 gehört. Bei der Angabe der MIP Data Length (Kapitel 4.1)
muss beachtet werden, dass der MUDP Header mit einem Byte berücksichtigt werden muss.
4.4
Micro Transmission Control Protocol
Das Micro Transmission Control Protocol (MTCP) ist ein Schicht 4 Protokoll, das den verbindungsorientierten bestätigten und transaktionsbasierten Transportdienst für die Protokollfamilie bereitstellt. Es wurde in Anlehnung an RFC 793: Transmission Control Protocol [Pos81c],
RFC 1379: Extending TCP for Transactions – Concepts [Bra92] und RFC 1644: T/TCP – TCP
Extensions for Transactions [Bra94] konzipiert.
MTCP stellt sicher, dass versendete Datenpakete den Empfänger erreichen und beim Transport
eventuell auftretende Fehler aufgelöst werden. Das Protokoll besitzt Mechanismen, um verlorengegangene Pakete erneut zu versenden, doppelte Pakete auszusortieren, sowie die korrekte
Reihenfolge der Datenpakete zu garantieren.
Um den Header von MTCP möglichst klein zu halten und mit einer wesentlich vereinfachten
Flußkontrolle arbeiten zu können, wurde im Vergleich zum Vorbild TCP bewusst auf „Urgent-“
und „Push-“Funktionen verzichtet.
MTCP besitzt entsprechend den allgemeinen Designrichtlinien aus Kapitel 4 ebenfalls keine
eigene Prüfsumme, da die Datenintegrität bereits durch die Schicht 2 sichergestellt wird.
MTCP bietet zwei verschiedene Betriebsmodi:
• Die Datenströme werden verbindungsorientiert in drei Phasen – Verbindungsaufbau mit
erstem Datenpaket, bidirektionaler Datentransfer, Verbindungsabbau – transportiert.
In dieser Betriebsart können größere Datenmengen, wie z. B. bei der Softwareaktualisierung von Steuergeräten, gesichert übertragen werden.
• Die Übertragung wird als Transaktion durchgeführt. Dabei wird nur ein Paket mit Nutzdaten gesendet und optional ein Antwortpaket mit Nutzdaten übertragen.
Diese Betriebsart eignet sich für den effektiven, gesicherten Austausch von Datenpaketen,
wie z. B. das ereignisgesteuerte Versenden von Informationen zwischen Steuergeräten.
4.4. MICRO TRANSMISSION CONTROL PROTOCOL
53
Das MTCP Datenpaket besteht, wie Abbildung 4.21 zeigt, aus fünf Protokollfeldern und den
Nutzdaten. Es wird im Nutzdatenfeld eines MIP Datagramms transportiert. Die einzelnen Felder
werden dann anschließend beschrieben.
D Port
S Port
Control
Segment Count
SC.echo
Data
Abbildung 4.21: MTCP Datenpaket
Destination Port (D Port)
Diese Portnummer adressiert eine bestimmte registrierte Applikation im empfangenden Knoten. Die Überlegungen bei MUDP im Kapitel 4.3 zur Verwendung der Ports gelten hier entsprechend.
Der Wertebereich ist 0x0Hex bis 0xFHex .
Source Port (S Port)
Zur eindeutigen Kennzeichnung der Quelle wird hier die Portnummer von der Applikation im
Sendeknoten angegeben. An diese Portnummer werden Antwortpakete des Empfangsknotens
zurückgesendet.
Control
Das Feld Control besteht aus Steuerbits entsprechend der Abbildung 4.22, die zur Signalisierung der verschiedenen Zustände bei der Übertragung dienen. Ein gesetzes Bit bedeutet ein
aktives Signal. In Tabelle 4.12 ist die Bedeutung der Signale aufgeführt.
Bit
Signal
7
unused
6
unused
5
FACK
4
ACK
3
FIN
2
CON
1
WND
0
RST
Abbildung 4.22: Steuerbits im Feld Control
Segment Count (SC)
Jedes Segment wird durch eine fortlaufende Nummer gekennzeichnet, wodurch eine eindeutige
Unterscheidung möglich ist. Dadurch können Wiederholungen erkannt und die richtige Reihenfolge der Segmente beim Empfang wiederhergestellt werden. Eine ungültige Segmentnummer
führt durch das Senden von RST zu einem Abbruch der Verbindung.
Das höchstwertige Bit (MSB – Most Significant Bit) wird nicht für die Darstellung der Segmentnummer verwendet. Es dient als Übertrag (sogenanntes Carry Bit) zur Kennzeichnung
54
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
RESET (RST)
Es ist ein Fehler aufgetreten, die Verbindung wird abgebrochen.
WINDOW (WND)
Dieses Signal bedeutet, dass der Empfangspuffer voll ist.
Es dürfen keine weiteren Daten gesendet werden, bis ein
Segment ohne WND empfangen wird.
CONNECTION (CON)
Es wird eine Anfrage für einen Verbindungsaufbau gestellt.
FINAL (FIN)
Es gibt keine weiteren Daten mehr zu versenden. Die Verbindung kann getrennt werden.
ACKNOWLEDGE (ACK) Dies ist die Bestätigung, dass ein versendetes Segment erfolgreich empfangen wurde.
FINAL ACK (FACK)
Ein Segment mit diesem Signal ist immer das Letzte einer
Verbindung. Es gibt an, dass eine Verbindung ordnungsgemäß beendet wurde.
unused
Dieses Bit wird nicht benutzt, es muss immer auf 0 gesetzt
werden.
Tabelle 4.12: Bedeutung der Signale in Control
eines zyklischen Umlaufs (Wrap around) der Variablen. Es wird automatisch gesetzt, als ob
es Bestandteil der Nummer wäre und gelöscht, sobald die kleinste gespeicherte Nummer größer als 129 ist, was nach Löschen des MSB einer „1“ entspricht. Der zur Verfügung stehende
Wertebereich ist somit 0 .. 127.
Beim Versenden eines ACK oder WND ohne Nutzdaten erfolgt kein Inkrementieren von SC,
da diese Segmente weder zwischengespeichert noch bestätigt werden müssen. Das Gleiche gilt
für das Segment mit dem FACK oder einem RST, da diese jeweils die letzten einer Verbindung
sind.
Segment Count Echo (SC.echo)
SC.echo wird in Zusammenhang mit dem Signal ACK verwendet. Es enthält den Wert von SC
des zu bestätigenden Segments. In Folge dessen gelten für SC.echo dieselben Vereinbarungen
bezüglich Wertebereich und Überlauf wie für SC. Wird ein ACK für gültig befunden, so wird
das dazugehörige Segment aus dem Sendepuffer gelöscht.
Ein ACK ist nur gültig, wenn diese Nummer mit der zuletzt versendeten (SC.save) übereinstimmt. Ist SC.echo < SC.save und in der Liste der empfangenen Nummern nicht mehr enthalten, so wird die Verbindung abgebrochen, da keine Zuordnung des Segments vorgenommen
werden kann.
Data
Hier sind die Nutzdaten enthalten. Es sind maximal 251 Byte zulässig.
4.4. MICRO TRANSMISSION CONTROL PROTOCOL
55
Im MTCP Header ist entsprechend den allgemeinen Designrichtlinien aus Kapitel 4 keine Längenangabe für das Feld Data vorgesehen, da zum MIP Header bereits ein Feld für die Zahl der
Nutzdatenbyte aus der Schicht 4 gehört. Bei der Angabe der MIP Data Length (Kapitel 4.1)
muss beachtet werden, dass der MTCP Header mit vier Byte berücksichtigt werden muss.
Endlicher Zustandsautomat einer Verbindung
Jede Verbindung muss durch einen eigenen endlichen Zustandsautomaten (FSM – Finite State
Machine) beschrieben werden, wobei diese Verbindung durch ihr Socketpaar, also die Kombination von MIP Adressen und Ports der beiden beteiligten Knoten, eindeutig identifizierbar ist.
Der Zustandsautomat muss die Zustände beider Kommunikationspartner berücksichtigen, da
diese nicht unabhängig voneinander agieren. Dabei wird unterschieden, ob es sich jeweils um
den Sender oder Empfänger handelt (Abbildung 4.23 auf Seite 56). Der obere Teil beschreibt
eine Verbindung beginnend mit dem aktiven Aufbau (Sender) und der untere Teil beginnend
mit dem passiven Warten auf eine eingehende Verbindungsanfrage (Empfänger). Bei Zuständen mit demselben Namen handelt es sich auch jeweils nur um einen Zustand, der für eine
übersichtlichere Abbildung getrennt dargestellt wird.
Wird eine Verbindung aktiv geöffnet, so ist der Startzustand Active Open. In diesem wird verweilt, bis das entsprechende ACK empfangen wird. Dadurch kann eine Verbindung in den Zustand Established übergehen, welcher den Normalzustand einer etablierten Verbindung darstellt.
Der andere Startzustand ist Passive Open. Dieser zunächst passive Zustand wird eingenommen, wenn eine Applikation sich für eine Verbindungsanfrage von Außen registriert. Sobald
ein Paket empfangen wurde, wartet die Gegenseite auf ein ACK, was durch den Zustand Req.
for ACK, Start ausgedrückt wird. Wurde ein ACK versendet, so ist die Verbindung etabliert
und befindet sich wiederum im Zustand Established.
Vom Zustand Established gehen alle weiteren Aktionen aus. Treffen Daten ein, so befindet
sich die Verbindung im Zustand Req. for ACK (in der unteren Hälfte dargestellt). Das Versenden von Paketen bewirkt einen Zustandswechsel nach Wait for ACK. Jedes Segment, das
abgesendet wird, bleibt in einem Ausgangspuffer gespeichert bis das entsprechende ACK vom
Empfänger eintrifft. Bleibt dieses Signal aus, so wird nach Ablauf der Paketlaufzeit von Sender zum Empfänger und zurück (sogenannte RTT – Round Trip Time) und einem Zeitzuschlag
(Offset) für die interne Verarbeitung in den beteiligten Knoten das Segment erneut versendet.
Nach dem erstmaligen Senden wird ein Segment noch bis zu dreimal wiederholt, danach wird
die Verbindung abgebrochen.
Die Round Trip Time für einen bestimmten Netzwerkpfad läßt sich mit Hilfe von MICMP
Echo Paketen ermitteln. Die Summe aus RTT und dem Offset für die internen Verarbeitungszeiten kann im Falle eines fehlerfrei arbeitenden Netzwerksystems aus der Latenzzeit zwischen
einem abgesendeten MTCP Datensegment und dem darauf empfangenen ACK Signal abgeschätzt werden.
Beendet wird eine Verbindung entweder durch einen expliziten Befehl der Applikation oder es
erfolgt, um Ressourcen von unnötig offen gehaltenen Verbindungen in den Knoten wieder frei-
56
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
MSL – Maximum Segment Lifetime, Rcv – Receive, Req – Request, Snd – Send
Abbildung 4.23: FSM einer MTCP Verbindung
4.4. MICRO TRANSMISSION CONTROL PROTOCOL
57
zugeben, eine automatische Trennung nach Ablauf des Timeout empty. Diese Zeitüberschreitung geschieht wenn der Sendepuffer leer ist und somit keine Daten mehr zum Versenden anstehen. Vor dem Beenden muss aber sichergestellt werden, dass die Gegenseite ihre Daten noch
versenden kann. Das wird durch die Zustände Rcv-Buffer full und Snd-Buffer full erreicht.
Die Zustände Req. for ACK, End und Wait for ACK, End erfüllen vergleichbare Funktion,
wie die bereits beschriebenen Zustände ohne das Suffix ..., End.
Wird eine Verbindung geschlossen, so befindet sie sich zunächst im Zustand Closing. Daraufhin
wird ein Zeitverzögerung gestartet. Erst nach deren Ablauf ist eine neue Verbindung auf demselben Socketpaar wieder zulässig. Dadurch sollen veraltete Segmente eliminiert werden, die
sich möglicherweise noch im Netz befinden. Die Maximum Segment Lifetime (MSL) bezeichnet die maximale Aufenthaltsdauer eines MTCP Paketes im Netzwerksystem. Die MSL wird
vom Systembetreuer nach eigenem Bedarf, z. B. anhand den verwendeten Feldbussen oder der
Ausdehnung des Netzwerksystems, festgelegt.
Nach Erreichen des Zustands Closed existiert die Verbindung nicht mehr. Aus diesem Zustand
heraus kann eine neue Verbindung entweder aktiv oder passiv aufgebaut werden.
Mehrere Situationen können einen Fehler hervorrufen. Das führt zu einem Übergang in den
Zustand Error und dem sofortigen Abbruch der Verbindung. Beispielhaft sind hier einige Fehlerursachen aufgeführt:
• Die Gesamtzahl zulässiger Verbindungen für den Knoten ist bereits erreicht.
• Die Zahl zulässiger Verbindungen für den angeforderten Port ist erreicht.
• Auch nach dem vierten Senden eines Segmentes ist kein ACK empfangen worden.
• Das empfangene Steuerbit darf im derzeitigen Zustand der FSM nicht auftreten.
4.4.1
Verbindungsorientierte Betriebsart
Verbindungsaufbau
Zum Aufbau einer MTCP Verbindung ist kein Drei-Wege-Handshake nötig (Abbildung 4.24).
Mit der Verbindungsanforderung können gleichzeitig die ersten Daten versendet werden. Der
Aufbau gilt als bestätigt, sobald das erste ACK eintrifft. Ab diesem Zeitpunkt können Daten
bidirektional gesendet und empfangen werden.
Knoten 1 startet die Verbindung, indem er das Signal CON zusammen mit den ersten Daten
sendet. Der Wert für Segment Count wird auf eins und SC.echo auf null gesetzt. Knoten 2
erwidert entweder nur ein ACK mit SC = 0 und SC.echo = 1 (Fall 1). Oder Knoten 2 sendet das
ACK gleichzeitig mit seinem erstes Datenpaket und erhöht SC deshalb auf eins (Fall 2). Der
Erhalt des Signals ACK etabliert die Verbindung.
58
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Abbildung 4.24: Öffnen einer MTCP Verbindung
Abbildung 4.25: Bidirektionales Senden und Empfangen
Aktive Verbindung
Während eine Verbindung sich im etablierten Zustand befindet, ist ein bidirektionaler Austausch
von Segmenten möglich (Abbildung 4.25).
Die Anzahl der Segmente, die gleichzeitig versendet werden können, richtet sich nach der Größe des Ausgangspuffers, da diese gespeichert werden müssen bis sie durch ein ACK quittiert
werden.
Tritt der Fall ein, dass Segmente ihr Ziel nicht in der richtigen Reihenfolge erreichen, so werden
sie im Eingangspuffer des Empfängers zwischengespeichert. Da diese Segmente angenommen
wurden, muss der Absender eine Bestätigung erhalten. Wenn der Empfangspuffer zu 75% gefüllt ist, wird ein Segment mit WND versendet, um dem anderen Knoten mitzuteilen, dass keine
Daten mehr empfangen werden können.
Die Abbildung 4.26 zeigt ein Beispiel bei dem das erste Segment länger als die darauf folgenden
Segmente unterwegs ist. Die Segmente 2 bis 5 werden im Knoten 2 gepuffert. Dann wird ein
4.4. MICRO TRANSMISSION CONTROL PROTOCOL
59
Abbildung 4.26: Unerwartete Segmentreihenfolge
WND gesendet, um Knoten 1 aufzufordern, das Senden weiterer Daten einzustellen. Mit dem
Erhalt von Segment 1 kann Knoten 2 seinen Speicher leeren und sendet nur ein ACK. Wenn
der Puffer noch nicht gelöscht werden kann, wird mit dem ACK für Segment 1 auch das Signal
WND gesendet. Erst wenn Knoten 1 ein ACK erhält, das kein WND beinhaltet, kann er den
Sendebetrieb wieder aufnehmen.
Beenden einer Verbindung
Das Beenden einer aktiven Verbindung wird in der Abbildung 4.27 gezeigt.
Abbildung 4.27: Beenden einer MTCP Verbindung
Knoten 1 initiiert die Trennung indem er bei seinen letzten Daten das Signal FIN setzt. Wurde
zuvor ein Segment von Knoten 2 erhalten, so ist zusätzlich ein ACK zu setzen.
Im ersten Fall in der Abbildung hat Knoten 2 keine Daten mehr zu versenden und bestätigt
das empfangene Segment mit einem ACK. Darauf wird überprüft, ob es noch Segmente gibt,
für die noch kein ACK erfolgt ist. Stehen keine Bestätigungen aus, so wird das Signal FACK
gesendet, wodurch die Trennung ordnungsgemäß abgeschlossen wird. Das FACK darf auch mit
60
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
dem letzten ausstehenden ACK in ein Segment zusammengefasst werden.
Im zweiten Fall hat Knoten 2 noch Daten zu versenden. Das FACK kann erst dann gesendet
werden, wenn alle von Knoten 2 versendeten Segmente von Knoten 1 quittiert worden sind.
4.4.2
Transaktionsbasierte Betriebsart
Der zeitliche Ablauf einer Transaktion ist vergleichbar mit dem Beenden einer Verbindung.
Lediglich das Signal CON wird für die Verbindungsanforderung im ersten Segment gesetzt.
Die Abbildung 4.28 zeigt den Ablauf.
Abbildung 4.28: Eine MTCP Transaktion
Im ersten Fall ist die Möglichkeit dargestellt, dass eine Verbindung geöffnet wird, um beispielsweise eine Statusmeldung, auf die keine Antwort erfolgt, zu versenden.
Eine aus Anfrage und Antwort bestehende Transaktion wird im zweiten Fall gezeigt.
4.5 Micro Open Shortest Path First
Das Micro Open Shortest Path First (MOSPF) ist ein Schicht 4 Protokoll, das der Protokollfamilie das Routingprotokoll bereitstellt. Es wurde als Link State Routing in Anlehnung an RFC
2328: Open Shortest Path First (OSPF) Version 2 [Moy98] konzipiert.
Das in dieser Arbeit vorgestellte abgegrenzte System befindet sich unter der Kontrolle einer
administrativen Einheit. Für das dynamische Routing in solch einem autonomen System dient
ein Interior Gateway Protocol (IGP) [Com02].
Die bekanntesten verteilten adaptiven Routingverfahren hierfür sind:
• Distance Vector Routing (DV Routing)
• Link State Routing (LS Routing)
Beim DV Routing wird der Weg entsprechend der Entfernung zwischen den Routern gewählt.
Die direkte Verbindung zwischen zwei Routern wird mit einem „Kosten“faktor bewertet. Geht
4.5. MICRO OPEN SHORTEST PATH FIRST
61
eine Verbindung über mehrere Router, so werden die Kosten addiert. Die Route mit den kleinsten Kosten ist der Weg mit der kürzesten Entfernung. Ein bekannter Vertreter für das Distance
Vector Routing ist das Routing Information Protocol (RIP) [Mal98].
Der Algorithmus für das DV Routing ist einfach und daher leicht zu implementieren. In der Praxis liegt der Nachteil von DV Routing jedoch in der langsamen Konvergenz. Dies betrifft ganz
besonders schlechte Nachrichten, was dann zur sogenannten „Count-to-Infinity“-Problematik
führt [Tan98]. Die Information über Ausfälle von Routern oder Verbindungen breitet sich damit
also nur sehr langsam aus.
Beim LS Routing erkennt jeder Router periodisch seine Nachbar-Router und bestimmt die „Leitungskosten“ dorthin. Anschließend fasst jeder Router diese Informationen in einem Link State
Paket zusammen. Die Link State Pakete werden periodisch oder ereignisgesteuert an alle Router verteilt. Somit besitzt jeder Router eine identische Datenbank mit Topologie-Informationen
des Gebietes. Aus dieser Datenbank berechnet jeder Router lokal, z. B. mit Hilfe des Dijkstra
Algorithmus3 , den kürzesten Pfad zu allen Zielen. Mit diesem Ergebnis wird dann wiederum
die Routingtabelle aufgebaut. Bei den Berechnungen können auch QoS-Parameter berücksichtigt werden. Bekannte Protokolle hierfür sind Open Shortest Path First (OSPF) [Moy98] und
Intermediate System to Intermediate System (IS-IS) [ISO02].
Die LS Routingprotokolle reagieren wesentlich schneller auf Topologieänderungen als die DV
Routingprotokolle. Die LS Routingprotokolle müssen nur die Änderungen der Topologie austauschen und erzeugen somit weniger Netzwerkverkehr. Andererseits sind jedoch die Berechnungsverfahren aufwendiger, welche jeder Router abarbeiten muss.
Für die Steuerdatenkommunikation wird gerade bei Ausfällen von Routern oder Netzwerksegmenten eine schnelle Konvergenz erwartet. Bereits aus diesem Grund verbietet sich das
DV Routing mit seiner „Count-to-Infinity“-Problematik. Das LS Routing konvergiert schneller und erzeugt außerdem komplette Topologie-Informationen, welche das Erzeugen von QoSabhängigen Routingtabellen ermöglicht. Daher ist das LS Routing vorzuziehen.
Das OSPF Protokoll ist später als IS-IS entstanden und hat viele Vorgehensweisen von IS-IS
übernommen. Die beiden Protokolle sind sich deshalb sehr ähnlich. IS-IS ist in der Lage, Informationen über mehrere Protokolle der Vermittlungsschicht gleichzeitig verwalten zu können.
OSPF unterstützt ausschließlich das Internetprotokoll. Da für die Protokollfamilie ein Routingprotokoll, das nur eine Vermittlungsschicht verwalten kann, ausreichend funktional ist und MIP
nahe an IP angelehnt ist, wurde OSPF als Vorbild ausgewählt.
Das OPSF Protokoll wurde bereits so entwickelt, dass es nur relativ wenig Datenverkehr verursacht, jedoch deckt es weit mehr Aspekte ab als für das hier vorgestellte System benötigt
werden. MOSPF wurde deshalb angepasst und so definiert, dass es mit wesentlich geringerem
Protokollaufwand seine Funktion erfüllen kann:
• Für MOSPF gelten ebenfalls die allgemeinen Designrichtlinien aus Kapitel 4.
Das Protokoll besitzt deshalb keine eigene Prüfsumme, da die Datenintegrität bereits durch
die Schicht 2 sichergestellt wird. Ebenso wird aufgrund dieser Designrichtlinien auf ein
eigenes Feld zur Angabe der Nutzdatenlänge verzichtet, da diese Längenangabe bereits im
Header des MIP Datagramms erfolgt.
3
Der Dijkstra Algorithmus dient zur Berechnung des kürzesten Weges in einem kantengewichteten Graphen.
Ein Beitrag des niederländischen Informatikers Edsger Wybe Dijkstra (* 11.05.1930 in Rotterdam; † 06.08.2002
in Nuenen)
62
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
• Zur Verkleinerung des MOSPF Headers und für eine vereinfachte Protokollabarbeitung
wurde auf die bei OSPF vorhandene Authentifizierung verzichtet.
Bei einem offenen System wie dem Internet sind Sicherheitsmaßnahmen gegen Knoten,
die sich als Router ausgeben und absichtlich falsche Topologie-Informationen verbreiten,
leider notwendig geworden. Innerhalb eines abgeschlossenen embedded Systems kann jedoch davon ausgegangen werden, dass solche unkooperativen Router nicht existieren.
• Ein weiterer Ansatzpunkt für die Optimierung des MOSPF Protokolls besteht darin, dass
gegenüber OSPF keine Funktionen für sehr große Netze, wie z. B. das hierarische Routing
mit Regionen, designierte Router und Reserverouter, mehrere Link State Pakettypen und
das Einbeziehen von externen Routen außerhalb des autonomen Systems benötigt werden.
• Für MOSPF ist die Angabe von Netzwerkmasken überflüssig.
Die MIP Adressen bestehen grundsätzlich aus einem 8 Bit Netzteil und einen 8 Bit Hostteil
(Kapitel 4.1).
• Bei MOSPF wird nur die Zeit angegeben nach der ein Router als ausgefallen gilt (Dead
Interval, bei OSPF: Router Dead Interval). Die bei OSPF zusätzlich vorhandene Ankündigung wie oft ein Paket zum Erkennen von Nachbar-Routern versendet wird (Hello Interval)
wird bei MOSPF eingespart, da diese Pakete implizit vor Ablauf des Dead Intervall gesendet werden müssen.
• Die entstehenden Topologie-Informationen enthalten die Angabe des verwendeten Feldbussystems im jeweiligen Subnetz. Anhand dieser Metrik werden von den Routern die
QoS-abhängigen Routingtabellen erzeugt.
In der Angabe des Feldbussystems lassen sich wesentlich genauere Eigenschaften eines
Netzwerkabschnitts konzentrieren anstatt nur bestimmte Parameter, wie z. B. Bandbreite,
Latenz, mögliche Sendefrequenz, etc. zu berücksichtigen. Auch kann das Einbeziehen von
QoS-Parametern von neuen, weiteren Feldbussystemen dadurch flexibler erfolgen.
In Abbildung 4.29 ist das MOSPF Datenpaket dargestellt. Es wird im Nutzdatenfeld eines MIP
Datagramms transportiert. Die einzelnen Protokollfelder werden anschließend erläutert.
Type
Options
Router ID
Data
Abbildung 4.29: MOSPF Datenpaket
Type
Mit Hilfe des Feldes Type können verschiedene MOSPF Pakete unterschieden werden. Es wurden dabei folgende Typen deklariert (Tabelle 4.13).
4.5. MICRO OPEN SHORTEST PATH FIRST
0x1Hex
0x2Hex
0x3Hex
0x4Hex
0x5Hex
63
Hello
(Erkennen benachbarter Router)
Database Description
(Zusammenfassung des Datenbankinhaltes)
Link State Request
(Anfordern von Datenbankinhalten)
Link State Update
(Transport von Datenbankinhalten)
Link State Acknowledgement
(Bestätigung des Transports)
Tabelle 4.13: MOSPF Type
Options
Im Feld Options ist ein Bitfeld enthalten, das je nach angegebenem Typ unterschiedliche Bedeutung hat.
Sofern bei einem bestimmten MOSPF Pakettyp nichts anderes angegeben ist, bleibt dieses Feld
ungenutzt und muss auf 0x00Hex gesetzt werden.
Router ID
Die Router ID ist eine eindeutige Identifikation des Routers im abgeschlossenen System. Beim
Versenden eines MOSPF Datenpaketes setzt ein Router hier seine Identifikationsnummer ein.
Eine einfache Vorgehensweise zum Erhalt eindeutiger Router IDs ist die Verwendung der
kleinsten MIP Adresse aller vorhandenen Schnittstellen eines Routers als Identifikationsnummer.
Data
Dieses Feld enthält die typabhängigen Nutzdaten. Es sind maximal 252 Byte zulässig.
Erkennen benachbarter Router
Benachbarte Router geben sich gegenseitig ihre Existenz und Funktionstüchtigkeit durch periodisch versendete MOSPF Hello Pakete bekannt. Die Hello Pakete werden von jedem Router
an allen seinen Schnittstellen mit der jeweils zugehörigen MIP Source Address als Broadcast an
die Nachbar-Router versendet. Hierbei geben die Router sich auch gleichzeitig die MIP Adressen ihrer Schnittstellen gegenseitig bekannt.
Das MOSPF Hello Paket besteht aus dem MOSPF Header und weiteren Feldern. Es ist in Abbildung 4.30 dargestellt und wird anschließend erläutert.
64
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Type
Options
Router ID
Dead Interval
Neighbor
Abbildung 4.30: MOSPF Hello Datenpaket
Type
Entsprechend Tabelle 4.13 ist Type = 0x1Hex .
Dead Interval
Nach Ablauf dieser Zeit gilt ein Router als nicht mehr ansprechbar bzw. außer Betrieb. Die
MOSPF Hello Pakete müssen von einem Router logischweise öfter als das angegebene Dead
Intervall versendet werden.
Für den flexiblen Einsatz der Protokollfamilie legt der Systembetreuer für das niederwertigste
Bit (LSB – Least Significant Bit) die Zeiteinheit systemweit fest, z. B. LSB =
b 100 ms.
Neighbor
Dieses Feld kann im Paket mehrfach vorhanden sein. Es bildet eine Liste mit den Router IDs
der Nachbarn an dieser Netzwerkschnittstelle von denen in letzter Zeit MOSPF Hello Pakete
empfangen worden sind. Es werden also nur die Nachbar-Router berücksichtigt, die vor Ablauf
ihres Dead Interval die Funktionstüchtigkeit durch MOSPF Hello Pakete angezeigt haben.
Mit Hilfe dieses Feldes können Router gegenseitig überprüfen, ob sie von ihrem NachbarRouter erkannt werden.
Aufbau der Datenbank mit den Topologie-Informationen
Zunächst erfasst jeder Router die an ihn angeschlossenen Subnetze und die jeweils verwendeten
Feldbussysteme. Dann fasst jeder Router diese Topologie-Informationen, ausgedrückt durch die
erreichbaren MIP Netzadressen und die Netzwerktypen, in einem Link State Advertisement
Paket zusammen.
Ein Link State Advertisement (LSA) Paket ist in Abbildung 4.31 dargestellt. Es besteht aus
einem LSA Header (gelb unterlegt) und weiteren Feldern. Die Beschreibung der Felder erfolgt
anschließend.
Advertising Router
Die Identifikation des Routers von dem diese Beschreibung ausgeht.
4.5. MICRO OPEN SHORTEST PATH FIRST
Advertising Router
Num Links
Network Addr
65
LS Sequence Num
LS Age
Network Type
Abbildung 4.31: Link State Advertisement (LSA) Datenpaket
Link State Sequence Number (LS Sequence Num)
Die Laufnummer dieser Beschreibung. Der Router erzeugt ein neues LSA Paket und inkrementiert diesen Wert, wenn sich Änderungen an den angeschlossenen Subnetzen ergeben haben.
Anhand dieser Nummer lassen sich veraltete oder doppelte LSA Pakete erkennen.
Link State Age (LS Age)
Die Beschreibungen werden mit einer maximalen Lebenszeit vom ausgehenden Router versendet. Die Zeit wird in jedem durchlaufenen Router angepasst, d. h. die Lebenszeit verringert sich
entsprechend. Das LSA Paket wird verworfen, falls dieser Wert 0 erreicht hat bevor die Beschreibung erneuert worden ist.
Der Systembetreuer legt für das niederwertigste Bit (LSB – Least Significant Bit) die Zeiteinheit für das gesamte System fest, z. B. LSB =
b 1 s. Der Wert 0xF FHex bedeutet eine unbegrenzte
Lebenszeit.
Number of Links (Num Links)
Die Anzahl der folgenden Subnetzbeschreibungen Network Addr / Network Type.
Network Address (Network Addr)
Network Type
Diese Felder können mehrfach vorhanden sein. Sie bilden eine Liste mit den Beschreibungen
der angeschlossenen Subnetze. Die Bedeutung der Felder ist:
• Die MIP Netzwerkadresse des Subnetzes.
• Die Typnummer, die den verwendeten Feldbus angibt.
Die Bedeutung der Typnummern muss vom Systembetreuer festgelegt werden. Die Tabelle
4.14 zeigt ein mögliches Beispiel für die Zuordnung.
Der Wertebereich ist 0x00Hex bis 0xF FHex .
Um die identische Datenbank mit den Topologie-Informationen in allen Routern des Systems
aufzubauen, findet ein Austauschprozess der Link State Advertisements statt. Hierzu werden
66
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
0x01Hex
0x02Hex
0x03Hex
0x04Hex
0x05Hex
..
.
IEEE 1394
Bluetooth
CAN C
CAN B
LIN
..
.
Tabelle 4.14: Beispieldefinition: MOSPF Network Type
die weiteren MOSPF Pakettypen genutzt.
Das grundsätzliche Konzept beruht auf dem sogenannten Flooding. Hierbei werden eingehende LSA Pakete im Router mit bereits vorhandenen LSA Paketen verglichen. Ist ein LSA Paket
bisher nicht erfasst oder hat es eine höhere LS Sequence Num, so ist es neu und wird an alle
Nachbarn, mit Ausnahme von den Routern von denen dieses LSA Paket eingegangen ist, weitergegeben. Veraltete LSA Pakete und Duplikate werden verworfen und nicht weiter behandelt.
Mit Hilfe des Database Description Pakets wird von einem Router eine Zusammenfassung der
Datenbank mit den Topologie-Informationen an seine Nachbarn versendet.
Ein Database Description (DD) Paket besteht aus dem MOSPF Header und den anschließend
erläuterten Feldern. Es ist in Abbildung 4.32 dargestellt.
Type
Options
Router ID
DD Seq Number
LSA Header
Abbildung 4.32: MOSPF Database Description (DD) Datenpaket
Type
Entsprechend Tabelle 4.13 ist Type = 0x2Hex .
Options
Das Feld Options besteht aus den Steuerbits entsprechend der Abbildung 4.33, die zur Signalisierung der verschiedenen Zustände bei der Übertragung der LSA Header dienen. Ein gesetzes
Bit bedeutet ein aktives Signal. In Tabelle 4.15 ist die Bedeutung der Signale aufgeführt.
Database Description Sequence Number (DD Sequence Number)
Dieses Feld enthält eine fortlaufende Nummer, um eine Folge von zusammengehörenden DD
4.5. MICRO OPEN SHORTEST PATH FIRST
Bit
Signal
4
unused
3
unused
67
2
unused
1
I
0
M
Abbildung 4.33: MOSPF DD Datenpaket: Steuerbits im Feld Options
More (M)
Init (I)
unused
Die Ankündigung, dass weitere Database Description Pakete folgen.
Kennzeichnet das erste Paket in einer Folge von Database
Description Paketen.
Dieses Bit wird nicht benutzt, es muss immer auf 0 gesetzt
werden.
Tabelle 4.15: MOSPF DD Datenpaket: Bedeutung der Signale in Options
Paketen zu nummerieren. Mit Hilfe dieses Feldes können Zusammenfassungen der Datenbank,
die die maximal erlaubte Größe eines einzelnen MOSPF DD Paketes überschreiten, versendet
werden.
Das erste DD Paket einer Folge wird durch das gesetzte I Bit in den Optionen gekennzeichnet.
Weitere DD Pakete werden mit dem gesetzten M Bit in den Optionen angekündigt.
Link State Advertisement Header (LSA Header)
Dieses Feld kann mehrfach vorhanden sein. Es bildet eine Liste mit den gespeicherten LSA
Headern.
Siehe für den LSA Header die gelb unterlegten Felder in Abbildung 4.31.
Stellt ein Router anhand der empfangenen Zusammenfassung der Datenbank in den MOSPF
DD Paketen fest, dass bestimmte LSA Pakete lokal nicht vorhanden oder veraltet sind, dann
fordert er diese mit Hilfe des Link State Request Pakets vom benachbarten Router an.
Ein Link State Request Paket ist in Abbildung 4.34 dargestellt. Es besteht aus dem MOSPF
Header und den anschließend erläuterten Feldern.
Type
Options
Router ID
Adv Router hi
Adv Router lo
Abbildung 4.34: MOSPF Link State Request Datenpaket
Type
Entsprechend Tabelle 4.13 ist Type = 0x3Hex .
68
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Advertising Router (Adv Router)
Dieses Feld kann mehrfach vorhanden sein. Es bildet eine Liste mit den angeforderten LSA
Beschreibungen. Die Pakete werden durch die Identifikationen der Router von denen diese Beschreibungen ausgegangen sind bezeichnet.
Für den Transport der angeforderten LSA Pakete kommt das MOSPF Link State Update Paket
zum Einsatz.
Ein Link State Update Paket ist in Abbildung 4.35 dargestellt. Die über den MOSPF Header
hinausgehenden Felder werden anschließend erläutert.
Type
Options
Router ID
LSA
Abbildung 4.35: MOSPF Link State Update Datenpaket
Type
Entsprechend Tabelle 4.13 ist Type = 0x4Hex .
Link State Advertisement (LSA)
Dieses Feld kann mehrfach vorhanden sein. Es bildet eine Liste mit den zu transportierenden
Link State Advertisement (LSA) Paketen.
Das LSA Paket wurde oben in Abbildung 4.31 beschrieben.
Der Empfang von LSA Paketen durch ein Link State Update Paket wird mit dem MOSPF Link
State Acknowledgement Paket bestätigt.
Ein Link State Acknowledgement Paket mitsamt dem MOSPF Header ist in Abbildung 4.36
dargestellt. Die zusätzlichen Felder werden anschließend erläutert.
Type
Entsprechend Tabelle 4.13 ist Type = 0x5Hex .
4.5. MICRO OPEN SHORTEST PATH FIRST
Type
Options
Router ID
69
LSA Header hi
LSA Header lo
Abbildung 4.36: MOSPF Link State Acknowledgement Datenpaket
LSA Header
Dieses Feld kann mehrfach vorhanden sein. Es bildet eine Liste mit den bestätigten LSA Paketen, welche durch die jeweiligen LSA Header beschrieben werden.
Der LSA Header besteht aus den gelb unterlegten Feldern in Abbildung 4.31.
Zusammenfassend zeigt die Abbildung 4.37 die Verwendung der MOSPF Pakete und den Ablauf beim Datenbankaustausch zwischen zwei benachbarten Routern.
Abbildung 4.37: Austausch der Datenbank
Aufbau der Routingtabelle
Für das Erzeugen der QoS-abhängigen Routingtabelle muss die Bedeutung der ToS Werte im
MIP Header (Kapitel 4.1) bekannt sein. Mit dem ToS Wert geben die Applikationen in den Knoten an, nach welcher Priorität die Feldbusse für den Datentransport verwendet werden sollen.
Der Systembetreuer legt die Bedeutung der ToS Werte fest. In der Tabelle 4.16 wird ein mögliches Beispiel gezeigt.
Anhand der Prioritätsliste können nun die vom ToS Wert abhängigen Leitungskosten für ein
Subnetz bestimmt werden. Ein Netzabschnitt mit der höchsten Priorität hat den Wert 1, die
70
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
ToS
0x01Hex
0x02Hex
0x03Hex
0x04Hex
0x05Hex
0x06Hex
0x07Hex
..
.
Prioritätsliste
IEEE 1394 – Bluetooth – CAN C – CAN B – andere
IEEE 1394 – CAN C – CAN B – andere
Bluetooth – IEEE 1394 – CAN C – CAN B – andere
CAN C – IEEE 1394 – CAN B – andere
CAN C – CAN B – andere
CAN B – CAN C – andere
LIN – beliebiger CAN – andere
..
.
0x1FHex
beliebiger Bus
Tabelle 4.16: Beispieldefinition: Priorität der Feldbusse abhängig vom ToS Wert
zweite Priorität den Wert k, die n-te Priorität den Wert k n−1 .
Die höher priorisierten Feldbusse werden auf diese Weise jeweils wesentlich besser als die niedriger priorisierten Busse bewertet. Dies führt in Folge dazu, dass das Durchlaufen von maximal
k Netzwerkabschnitten einer bestimmten Priorität besser oder gleich dem Durchlaufen eines
Netzwerkabschnittes des nächst niedriger priorisierten Feldbusses bewertet wird. Der Faktor k
muss deshalb größer als die gewünschte maximale Zahl durchlaufener Subnetze zwischen zwei
Knoten bei der ausschließlichen Verwendung des bevorzugten Feldbusses gewählt werden.
Die Tabelle 4.17 zeigt die aus obigem Beispiel resultierenden Leitungskosten für ein Subnetz
mit einem bestimmten Feldbustyp in Abhängigkeit des ToS Wertes.
ToS
0x01Hex
0x02Hex
0x03Hex
0x04Hex
0x05Hex
0x06Hex
0x07Hex
..
.
0x1FHex
Feldbustyp
IEEE 1394 Bluetooth CAN C
1
k
k2
1
k3
k
k
1
k2
k
k3
1
2
2
k
k
1
k2
k2
k
k2
k2
k
..
..
..
.
.
.
1
1
1
CAN B LIN
k3
k4
k2
k3
3
k
k4
k2
k3
k
k2
1
k2
k
1
..
..
.
.
1
1
Tabelle 4.17: Für das Beispiel: Leitungskosten der Feldbustypen abhängig vom ToS Wert
Jeder Router bestimmt nun lokal aus der Datenbank mit den Topologie-Informationen und aus
den Leitungskosten für jedes Subnetz, also dem kantengewichteten Graphen, abhängig vom ToS
Wert den kürzesten Weg in jedes Subnetz im System.
Daraus wird wiederum die Routingtabelle erstellt. Sie enthält abhängig vom ToS Wert die Information über welche Schnittstelle des Routers und eventuell über welchen Nachbarrouter das
Subnetz eines Zielknotens erreicht werden kann.
4.6. FAZIT
4.6
71
Fazit
Mit den in den vorangegangenen Kapiteln 4.1 bis 4.5 dokumentierten Definitionen existiert nun
die Protokollfamilie zur universellen Steuerdatenkommunikation in heterogenen Netzwerkumgebungen.
Die Abbildung 4.38 zeigt einen Überblick über die entstandene hierarchische Protokollfamilie
(rechts) und im Vergleich dazu das OSI-Modell (links).
Applikation
Applikation
Applikationsschicht
7
Darstellungsschicht
6
Sitzungsschicht
5
MICMP
Transportschicht
MUDP
MTCP
MOSPF
4
Hierarchische
Protokollfamilie
MIP
Vermittlungsschicht
3
Schnittstelle zu LIN
Schnittstelle zu CAN
Schnittstelle zu Bluetooth
Schnittstelle zu IEEE 1394
LIN
CAN
Bluetooth
IEEE 1394
Medium
Medium
Medium
Medium
Sicherungsschicht
2
Bitübertragungsschicht
1
Medium
Abbildung 4.38: Die entstandene hierarchische Protokollfamilie
Micro Internet Protocol
Das Micro Internet Protocol (MIP) stellt zusammen mit den Anpassmodulen zu den Feldbussen die Netzwerkschicht dar. Auf dieser Schicht geschieht die Konvergenz der Feldbusse und
erfolgt die einheitliche logische Adressierung entsprechend den Anforderungen in Kapitel 3.
MIP bietet weiterhin die Voraussetzungen, um die Wegewahl auf der Schicht 3 durchführen zu
können. Auf die Verwendung von Gateways kann innerhalb des Systems fortan verzichtet werden. Somit wird die Forderung, dass Automatisierungsgeräte in einem ausreichend vermaschten
System erreichbar bleiben, solange noch mindestens ein durchgängiger Pfad verfügbar ist, auch
bei Ausfall von einzelnen Segmenten erfüllt.
Mit dem ToS Feld im MIP Header wird ebenfalls die Forderung aus Kapitel 3 erfüllt, dass in
den Routern QoS-Parameter berücksichtigt werden können.
Unter Beibehaltung aller notwendigen Funktionen konnte der MIP Header soweit verkleinert
werden, dass er fast nur noch ein Drittel der Headergröße des Vorbilds IP aufweist. Dieser reduzierte Overhead zeigt den Fokus auf die Optimierung für die Steuerdatenkommunikation in
embedded Systemen.
72
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Exemplarisch sind für vier sehr verschiedene Feldbusse Schnittstellen definiert worden. Die
Kapitel 4.1.1 bis 4.1.4 dokumentieren, wie diese Schnittstellen zu den unterschiedlichen darunterliegenden Feldbussen aussehen und wie eine solche Anpassung möglich ist.
Die Anpassmodule für Bluetooth und IEEE 1394 mussten jeweils mit einem zusätzlichen
Hilfsprotokoll zur Auflösung der logischen Adressierung auf das Adressmodell der zugrundeliegenden Technologie ausgestattet werden. Für LIN und CAN wurde eine elegante Möglichkeit
gefunden, um ohne diesen zusätzlichen Aufwand auszukommen.
Micro Internet Control Message Protocol
Das Micro Internet Control Message Protocol (MICMP) stellt das notwendige Hilfsprotokoll
für die Signalisierung von Fehlern bei der Verarbeitung von MIP Datagrammen zur Verfügung.
Besonders wichtig für den Standardbetrieb ist die Mitteilung der abgelaufenen Lebensdauer von
einem Datagramm und die Information über derzeit nicht erreichbare Ziele.
Die Mitteilung von allgemeinen Problemen mit einem Protokollfeld und das Echo Test Paket
dienen hingegen eher der Hilfestellung während der Entwicklung und bei der Netzwerkdiagnose.
Die Größe des MICMP Headers konnte soweit reduziert werden, dass er gegenüber der Headergröße des Vorbilds ICMP nur noch ein Achtel beträgt.
Micro User Datagram Protocol
Für die Anwendungen in den Knoten bietet das Micro User Datagram Protocol (MUDP) eine einheitliche Schnittstelle für den unbestätigten Datentransport. Ein MIP Datagramm bietet
bereits die meisten notwendigen Funktionen hierfür. Lediglich ein zusätzlicher 1 Byte großer
Header ist für das Multiplexing, also die Zuordnung auf die Applikationen, vonnöten.
Im Vergleich zum Vorbild UDP konnte der Header somit ebenfalls auf ein Achtel der Größe
reduziert werden. Für die Anwendungen stehen maximal 254 Byte Nutzdaten in einem MUDP
Datenpaket zur Verfügung.
Micro Transmission Control Protocol
Das Micro Transmission Control Protocol (MTCP) vereinigt den bestätigten und transaktionsbasierten Datentransport in einem gemeinsamen Protokoll und stellt den Anwendungen hierfür
eine einheitliche Schnittstelle bereit. Bei MTCP wurde der Ablauf so optimiert, dass Nutzdaten bereits während des Verbindungsaufbaus und bis kurz vor der Trennung der Verbindung
noch transportiert werden können. Ein abgegrenzter Drei-Wege-Handshake wie bei TCP zum
Aufbau einer Verbindung entfällt. Die Transaktion kann dadurch quasi als Spezialfall der bestätigten Verbindung gehandhabt werden.
Die Größe des MTCP Headers konnte auf ein Fünftel der Headergröße des Vorbilds TCP verschlankt werden. In einem MTCP Datenpaket können maximal 251 Byte Nutzdaten transportiert werden.
4.6. FAZIT
73
Micro Open Shortest Path First
Micro Open Shortest Path First (MOSPF) vervollständigt die Protokollfamilie mit einem Link
State Routingprotokoll für die Wegewahl unter Berücksichtigung von QoS-Parametern.
MOSPF übernimmt von seinem Vorbild OSPF nur die für das hier vorgestellte System relevanten Funktionen und kann damit mit geringerem Protokollaufwand seine Aufgabe erfüllen. Der
MOSPF Header konnte soweit verkleinert werden, dass er nur noch ein Achtel der Headergröße
von OSPF aufweist.
Bei Änderungen an der Topologie müssen mittels MOSPF nur wenige Informationen zwischen
den Routern ausgetauscht werden, was der begrenzten Bandbreite der Feldbusse sehr entgegen
kommt. Der Aufbau der lokalen Routingtabellen erfordert dafür einigen Rechenaufwand in jedem einzelnen Router, was eigentlich im Widerspruch zu einem embedded System steht. Die
Definition von MOSPF in dieser Form macht trotzdem Sinn: Die Feldbusse mit ihrer begrenzten
Nutzdatenkapazität haben einen sehr langen Lebenszyklus. Die eingesetzten Mikroprozessoren
erleben hingegen eine rasche Fortentwicklung mit ständig steigender Rechenleistung in kurzer
Folge.
Die Tabelle 4.18 gibt abschließend nochmals einen Überblick über die erreichten Verkleinerungen der Header dieser Protokollfamilie hier im Vergleich zu den Internet Protokollen.
Byte
MIP
7
MICMP
1
MUDP
1
MTCP
4
MOSPF
3
Byte
20
8
8
20
24
IP
ICMP
UDP
TCP
OSPF
Tabelle 4.18: Größe der Protokollheader im Vergleich
Die im Kapitel 3 formulierten Anforderungen an das Konzept werden von der Protokollfamilie
also somit erfüllt.
4.6.1
Analyse von Effektivität, Transferzeiten und Latenzzeiten
Die Diagramme in den Abbildungen 4.39 und 4.40 stellen für MIP Datagramme die Effektivität, also das Verhältnis von Nutzdaten zu gesendeten Daten, bei der Nutzung der vier betrachteten Feldbusse und bei verschiedenen Übertragungsarten dar. Die Protokollkombination IP via
Ethernet dient als Referenz der erreichbaren Effizienz. Die Berechnungen hierzu finden sich im
Anhang A.1.
Die Sägezahnform entsteht durch das Fragmentieren der MIP Datagramme durch die Schnittstelle zum Feldbus bzw. bei Bluetooth innerhalb des eigenen Protokollstapels. An den Stellen
mit einer steil abfallenden Flanke wird jeweils ein weiterer Datenrahmen des darunterliegenden
Feldbussystems benötigt.
74
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Abbildung 4.39: Effektivität bei 1 bis 12 Nutzdatenbyte
Die in Kapitel 3.4 bereits angeführte Erklärung, dass IP keine vertretbare Lösung für die Steuerdatenkommunikation darstellt, zeigt sich hier gerade bei kleinen Nutzdatengrößen sehr deutlich.
Die Leistungsfähigkeit bestimmt sich aber nicht allein über die Effizienz. Die unterschiedlichen
Buszugriffsverfahren der Feldbusse haben einen erheblichen Einfluss auf die Transferdauer für
ein Datenpaket und die Latenzzeit zwischen der Übertragung zweier Datenpakete.
Zur Abschätzung der Transferdauer und der Latenzzeit wird ein MTCP Datenpaket mit 8 Nutzdatenbyte, eine typischen Nutzdatenmenge in der Steuerdatenkommunikation, verwendet. Mit
Hilfe der Berechnungen in Anhang A.2 ergeben sich die in der Tabelle 4.19 angegebenen Zeiten.
4.6. FAZIT
75
Abbildung 4.40: Effektivität bei 1 bis 255 Nutzdatenbyte
Feldbus und Übertragungsart
LIN unconditional
CAN
Bluetooth DH1
IEEE 1394 GASP
Im ungünstigsten Fall
Transferdauer Latenzzeit
24,8 ms 396,8 ms
377 µs
393 µs
625 µs 8,125 ms
12,95 µs
3,5 ms
≈ 32 ms
Tabelle 4.19: Transferdauer und Latenzzeiten im Vergleich
76
KAPITEL 4. DEFINITION DER PROTOKOLLFAMILIE
Kapitel 5
Demonstrationssystem
Um die entwickelten Protokolle für Feldbussysteme in einem realen Aufbau testen zu können, wurden möglichst universelle Entwicklungsumgebungen geschaffen. Diese Plattformen
zur Realisierung wurden durch die vorliegende und weitere Arbeiten, als auch durch Kooperationen mit der Industrie getrieben. Folgende drei Umgebungen sind unter Berücksichtigung der
Fahrzeug Netzarchitektur (Abbildung 3.1) und der CAM Pyramide (Abbildung 3.2) im Kapitel 3 zum Einsatz gekommen:
• x86 Architektur und Betriebssystem Linux1 .
Z. B. als Mensch Maschine Interface (MMI) mit grafischer Oberfläche.
• 16 Bit Mikrocontroller C167 mit integriertem CAN Controller der Firma Infineon Technologies AG2 und das multitaskingfähige Echtzeitbetriebssystem EUROS (Enhanced Universal Realtime Operating System)3 .
Im Einsatz als typischer Vertreter eines Knotens in einem embedded System für Steuergeräte und Gateways.
• Reduced Instruction Set Computer (RISC) Mikrocontroller PIC16 der Firma Microchip
Technology Inc.4 ohne Betriebssystem.
Für untergeordnete Aufgaben als Coprozessor auf Zusatzmodulen der 16 Bit Architektur
und für abgesetzte Slave Knoten.
Für die x86 Architektur konnten Standard Personal Computer (PC) Komponenten problemlos zugekauft werden, daher bestand kein Grund zur Eigenentwicklung. Der freie Markt bietet
eine breite Palette an Industrie und Desktop PCs mit integrierten oder erweiterbaren Netzwerkschnittstellen für Ethernet und CAN, zwischenzeitlich auch für IEEE 1394 und Bluetooth.
Die auffälligsten Unterschiede zwischen PCs für Büroumgebungen und industriellen PCs für
embedded Systeme bestehen im mechanischen Aufbau, den zulässigen Umweltbedingungen
im Betrieb und der Leistungsfähigkeit. Für eine Testumgebung unter Laborbedingungen sind
1
Einige bekannte Distributionen: http://www.debian.de/, http://www.suse.de/, http://www.redhat.com/
http://www.infineon.com/
3
http://www.euros-embedded.com/
4
http://www.microchip.com/
2
77
78
KAPITEL 5. DEMONSTRATIONSSYSTEM
gerade die ersten beiden Punkte unerheblich. Die im Allgemeinen höhere Leistungsfähigkeit
von Desktop PCs ist vorteilhaft, sie erlaubt eine komfortablere Durchführung der Tests.
Das Betriebssystem Linux wurde ausgewählt, weil es für mehrere unterschiedliche Prozessorarchitekturen erhältlich ist und mit seinen vielen Treibern bereits eine sehr breite Hardwareunterstützung bietet. Die verwendeten einschlägigen Distributionen stellen außerdem eine Vielzahl
an freien Entwicklungswerkzeugen, Serverdiensten und Anwendungsprogrammen zur Verfügung.
Das freie quelloffene System bietet gerade im universitären Umfeld einen erheblichen Vorteil, weil es einen guten Einblick in seine Funktionsweise bietet, ohne dass kostenpflichtige
Dienstleistungen eines kommerziellen Herstellers in Anspruch genommen werden müssen. Somit steht eine ideale Umgebung zur Verfügung, um Applikationen und im Bedarfsfall sogar
eigene Treiber entwickeln zu können.
Bei der 16 Bit Architektur und dem RISC Mikrocontroller besteht eine etwas andere Situation.
Auf dem freien Markt hierfür Komponenten zu finden, die außer CAN oder vielleicht Ethernet auch gleichzeitig weitere Feldbusse unterstützen können, ist praktisch unmöglich. Vielmehr
waren zu Beginn dieser Arbeit geeignete embedded Systeme mit IEEE 1394, Bluetooth oder
LIN in keinster Weise verfügbar. Und sogar bis heute kann man nur sehr eingeschränkt passende Entwicklungssysteme finden. Eine universelle Entwicklungsumgebung und ein embedded
System widersprechen sich im Grunde auch, deshalb konnte nicht so einfach wie bei der x86
Architektur zugekauft werden.
In Folge dessen wurde eine eigene Enwicklungsumgebung am Institut OMI entwickelt, welche
die vielen unterschiedlichen Anforderungen erfüllen konnte. Die entstandene Hardware um den
16 Bit Mikrocontroller und eine Reihe von Zusatzmodulen wird als sogenanntes Universalsteuergerät bezeichnet und im Anhang B vorgestellt.
Für den C167 Mikrocontroller wurde ebenfalls ein Betriebssystem verwendet, um auch beim
embedded System eine zukunftsweisende Entwicklungsmethodik einsetzen zu können. Bisher
sind freie Systeme in dieser Leistungsklasse jedoch leider nur äußerst selten zu finden. Jedoch
stellt das kommerzielle EUROS, welches inklusive der notwendigen Unterstützung seitens des
Herstellers im Rahmen einer Kooperation zur Verfügung stand, eine gute Alternative dar. Das
Betriebssystem ist für unterschiedliche Prozessoren erhältlich und bietet bereits Treiber für z. B.
Ethernet, CAN und die üblichen synchronen und asynchronen seriellen Schnittstellen. In Eigenentwicklung entstanden weitere Treiber und natürlich die Applikationen.
Der PIC16 verfügt für die zugedachten untergeordneten Aufgaben nur über sehr begrenzte Ressourcen, folglich muss diese Architektur ohne Betriebssystem auskommen. Die Entwicklung
der Applikationen erfolgt damit zwangsläufig auf einem sehr hardwarenahen Niveau.
5.1
Realisierte Teilaspekte
Um mit wenigen exemplarischen Umsetzungen eine möglichst breite Palette der Protokolle der
hierarchischen Familie zu testen, wurden drei Szenarien aufgestellt und exemplarisch umgesetzt:
5.1. REALISIERTE TEILASPEKTE
79
• Beim Warenbuchungssystem kommt in besonderem Maße die transaktionsbasierte Übertragung mittels MTCP zum Einsatz.
• Die Basisfunktionen für das dynamische Routing werden anhand einem überschaubaren Aufbau nachvollzogen. Insbesondere werden hierbei die Abläufe zum Austausch der
Topologie-Informationen mit MOSPF erprobt.
• Die Interoperabilität zwischen MIP und IP ist die Aufgabe dieses Tests. Die Gateway Applikation schließt die Verwendung von MUDP ein.
Die Testszenarien verwenden also die beiden Schicht 4 Transportprotokolle und das Routingprotokoll. Somit kommt logischerweise auch jeweils MIP und – soweit angebracht – das eng
begleitende MICMP zur Anwendung.
Die folgenden Kapitel beschreiben nun detaillierter die realisierten Teilaspekte.
5.1.1
Warenbuchungssystem
Dieser Test beruht auf dem Szenario eines Warenbuchungssystems, ähnlich dem Vorgang an
einer Supermarktkasse. Mehrere Benutzer können in Selbstbedienung Waren aus einem Lager
entnehmen. Zur Identifikation besitzt jeder Benutzer eine Karte mit aufgedrucktem Strichcode,
ebenso ist auf jedem Artikel ein Strichcode aufgebracht. Zunächst muss der Benutzer mit einem
Strichcodeleser seine persönliche Karte einlesen, danach müssen alle Produkte eingelesen werden. Die erfassten Benutzer- und Artikelnummern werden unter Verwendung von MTCP/MIP
an den Datenbankrechner weitergeleitet. Die Buchung kann vom Anwender über ein webbasiertes Benutzerinterface kontrolliert werden.
Der Aufbau besteht aus einem Strichcodeleser, zwei Universalsteuergeräten und einem PC,
der als Webserver und Datenbank fungiert (Abbildung 5.1). Lediglich zur Vereinfachung dient
derselbe PC zusätzlich auch noch als Webclient für das Benutzerinterface. Selbstverständlich
könnte dafür genauso ein beliebiger anderer Client ohne Einschränkung der Funktion verwendet
werden.
Abbildung 5.1: Aufbau des Warenbuchungssystems
Der Handscanner dient zum Einlesen der Strichcodes von Benutzern und Produkten. Er ist am
ersten der beiden Universalsteuergeräte über eine asynchrone serielle Schnittstelle vom Typ
RS232 [TIA97] angeschlossen. Die Aufgabe dieses Knotens besteht darin, den Bytestrom vom
80
KAPITEL 5. DEMONSTRATIONSSYSTEM
Scanner entgegenzunehmen, semantisch zu erfassen, zu einem Datenpaket zusammenzufassen
und als Transaktion an MTCP zu übergeben. Via MIP und in diesem Fall CAN wird die Information dann versendet.
Das zweite Universalsteuergerät arbeitet als Gateway. Es empfängt die Strichcodedaten wiederum via CAN/MIP/MTCP, wandelt diese in das geeignete Format zur Übermittlung an die
Datenbank um und sendet die Information mittels TCP/IP und die vorhandene 10 MBit/s Ethernetschnittstelle an den PC weiter.
Als Webserver kommt der Apache HTTP (HyperText Transfer Protocol [BLe96, Fe99]) Server5 mit Unterstützung für PHP (PHP: Hypertext Preprocessor)6 zum Einsatz. PHP ist eine weit
verbreitete, serverseitig interpretierte Skriptsprache, welche gerne für die Programmierung dynamischer Webseiten genutzt wird. Durch die Anfrage eines Clients an den Webserver wird
das entsprechende PHP Skript ausgeführt, welches daraufhin eine Ausgabe in der Auszeichnungssprache HTML (HyperText Markup Language [RHJ99]) zurückliefert. Als Datenbank
wird MySQL7 verwendet.
In Abbildung 5.2 ist dargestellt, auf welchen Schichten des OSI-Modells die Kommunikation
des gesamten Systems abläuft.
Universalsteuergerät 1
Universalsteuergerät 2
Webserver / Datenbank
Applikation 1
Applikation 2
Webserver
Applikation
Applikationsschicht
Semantik
7
Darstellungsschicht
HTTP
HTTP
TCP
TCP
IP
IP
Ethernet
Ethernet
6
Sitzungsschicht
5
MTCP
Transportschicht
MTCP
4
Vermittlungsschicht
3
MIP
MIP
Schnittstelle zu CAN
Schnittstelle zu CAN
CAN
CAN
Sicherungsschicht
2
RS232
Bitübertragungsschicht
1
Medium
Medium
Medium
Medium
Abbildung 5.2: Einordnung des Warenbuchungssystems in das OSI-Modell
Die Interpretation des Strichcodes aus dem Bytestrom des Handscanners geschieht im Block
Semantik, welcher sich im OSI-Modell auf der Schicht 7 einordnet. Programmiertechnisch ist
5
http://www.apache.org/
http://www.php.net/
7
http://www.mysql.com/
6
5.1. REALISIERTE TEILASPEKTE
81
dieser Teil jedoch als Funktion innerhalb der Applikation 1 realisiert worden, die sich oberhalb
der Protokollschichten des OSI-Modells befindet.
Die Applikation 2 führt die Gatewayfunktionalität aus. Seitens der hierarchischen Protokollfamilie für die Steuerdatenkommunikation werden keine Aufgaben in den Schichten 5 bis 7
erledigt. Erst beim Versenden des Strichcodes über TCP/IP sind diese Schichten betroffen. Das
Gateway übernimmt seitens der Internetprotokolle die Funktion eines einfachen Clients, der
mittels der HTTP Methode „GET“ Daten von einem Server angefordert. In diesem Fall ist es
der Aufruf eines PHP Skripts mit folgender Syntax:
http://WEBSERVER/warenbuchungssystem/php/eintrag.php?zahl=STRICHCODE
5.1.2
Basisfunktionen für das dynamische Routing
Bei diesem Test wird ein besonderes Augenmerk auf die notwendigen Grundfunktionen für das
dynamische Routing unter Berücksichtigung von QoS-Parametern gerichtet. Anhand nachvollziehbarer Netzwerkstrukturen wird das Erkennen von benachbarten Routern und der Austausch
der Topologie-Informationen mit MOSPF vorgenommen.
Zum Erkennen benachbarter Router dient der erste Aufbau. Er besteht aus zwei Universalsteuergeräten, die als Router jeweils über CAN und IEEE 1394 miteinander vernetzt sind (Abbildung
5.3). Zwischen den beiden Routern besteht also eine redundante Verbindung. Außerdem sind
beide Universalsteuergeräte jeweils über eine asynchrone serielle Schnittstelle (RS232) mit einem Entwicklungs PC verbunden.
CAN
01.01
Router ID 01.01
01.02
02.01
Router ID 01.02
02.02
IEEE 1394
Entwicklungs PC 1
RS232
Entwicklungs PC 2
RS232
Abbildung 5.3: Testaufbau 1
An den jeweiligen Entwicklungs PCs können nach dem Herunterladen der Software auf das
entsprechende Universalsteuergerät die Meldungen von dem ablaufenden Programm verfolgt
werden. Für den eingeschwungenen Zustand zeigt die Abbildung 5.4 die Nachbarschaften von
82
KAPITEL 5. DEMONSTRATIONSSYSTEM
Router 01.01 an, welche anhand der zuletzt empfangenen MOSPF Hello Pakete ermittelt worden sind.
Functional Neighbours
--------------------Interface 0, MIP: 01.01, Type: 0x03
Router ID: 01.02, MIP: 01.02
Neighbours: 01.01
Interface 1, MIP: 02.01, Type: 0x01
Router ID: 01.02, MIP: 02.02
Neighbours: 01.01
-> My Neighbours: 01.02
Abbildung 5.4: Testaufbau 1 – Ausschnitt aus dem Protokoll von Router 01.01
Die Übersicht der funtionstüchtigen Nachbar-Router erfolgt aufgeteilt nach den Netzwerkschnittstellen, wobei als zusätzliche Informationen jeweils die zugeordnete MIP Adresse und
der verwendete Feldbustyp entsprechend Tabelle 4.14 in Kapitel 4.5 ausgegeben werden.
Die weiteren Zeilen enthalten Angaben aus den empfangenen MOSPF Hello Paketen. In der
ersten eingerückten Ebene wird die Router ID und die sendeseitige MIP Adresse ausgegeben.
Die zweite eingerückte Ebene enthält die Liste der erkannten Nachbarn. Man sieht hier, dass
die gegenseitige Erkennung funktioniert hat, da die eigene Router ID 01.01 jeweils als Nachbar eingetragen ist. In der letzten Zeile werden zusammenfassend nochmals die Router IDs der
Nachbar-Router, im Testaufbau 1 nur der Router 01.02, angezeigt.
Für das Verteilen der Topologie-Informationen mit den weiteren MOSPF Pakettypen wird sinnvollerweise ein entferntes Netzwerk benötigt. Hierfür wird ein zweiter Testaufbau verwendet,
der aus insgesamt drei Universalsteuergeräten besteht. Die Abbildung 5.5 zeigt wie die Universalsteuergeräte als Router miteinander vernetzt sind.
Wie beim ersten Test sind die Entwicklungs PC über eine asynchrone serielle Schnittstelle
(RS232) angeschlossen, um die Meldungen von der Software der Router ausgeben zu können.
Die Abbildungen 5.6 bis 5.8 zeigen die relevanten Ausschnitte von Router 01.01.
Analog zum ersten Testaufbau werden zunächst die funktionstüchtigen Nachbar-Router ermittelt (Abbildung 5.6).
Im nächsten Schritt ermittelt der Router die angeschlossenen Subnetze und die verwendeten
Feldbustypen und hält sie in Form eines Link State Advertisement (LSA) fest (Abbildung 5.7).
Im dritten Schritt erfolgt nun der eigentliche Austausch der Topologie-Informationen (Abbildung 5.8):
Der Router 01.02 verbreitet mit einem MOSPF Database Description (DD) Paket die neuen
LSA Header.
Der Router 01.01 stellt fest, dass ihm diese beiden LSAs noch nicht bekannt sind und fordert
5.1. REALISIERTE TEILASPEKTE
83
CAN
01.01
Router ID 01.01
01.02
02.01
04.03
04.02
IEEE 1394
IEEE 1394
Entwicklungs PC 1
RS232
Router ID 04.03
Router ID 01.02
Entwicklungs PC 2
RS232
Abbildung 5.5: Testaufbau 2
Functional Neighbours
--------------------Interface 0, MIP: 01.01, Type: 0x03
Router ID: 01.02, MIP: 01.02
Neighbours: 01.01
Interface 1, MIP: 02.01, Type: 0x01
-> My Neighbours: 01.02
Abbildung 5.6: Testaufbau 2 – Übersicht der benachbarten Router
My local LSA
-----------Advertising Router: 01.01
Network: 01, Type: 0x03
Network: 02, Type: 0x01
Abbildung 5.7: Testaufbau 2 – Erfassen der angeschlossenen Subnetze und der Feldbustypen
diese deshalb mit einem MOSPF Link State (LS) Request Paket an.
Der Router 01.02 übermittelt die vollständigen LSAs mit einem MOSPF Link State (LS) Update Paket.
Die Bestätigung an den Router 01.02 mittels eines MOSPF Link State Acknowledgement (LS
Ack) schließt den Austausch ab.
84
KAPITEL 5. DEMONSTRATIONSSYSTEM
DD received from Router ID: 01.02, MIP: 01.02
LSA Header 0, Advertising Router: 01.02
LSA Header 1, Advertising Router: 04.03
Found new LSAs, Starting Database Exchange...
LS Request sent to Router ID: 01.02, MIP: 01.02
Advertising Router 0: 01.02
Advertising Router 1: 04.03
LS Update received from Router ID: 01.02, MIP: 01.02
LSA 0, Advertising Router: 01.02
Network: 01, Type: 0x03
Network: 04, Type: 0x01
LSA 1, Advertising Router: 04.03
Network: 04, Type: 0x01
LS Ack sent to Router ID: 01.02, MIP: 01.02
LSA Header 0, Advertising Router: 01.02
LSA Header 1, Advertising Router: 04.03
Finished Database Exchange.
Abbildung 5.8: Testaufbau 2 – Verteilen der Topologie-Informationen
5.1.3 Interoperabilität zwischen MIP und IP
Durch diesen Test wird die Übergangsmöglichkeit zwischen der hierarchischen Protokollfamilie
für die Steuerdatenkommunikation und der Internet-Welt erprobt. Außerdem dienen MUDP
Datenpakete für einen Dienst zur Namen- und Adressauflösung, welcher IP Hostnamen oder
Adressen zu MIP Adressen zuordnet.
Für diesen Aufbau wurden PCs verwendet. Das Kernstück ist das Gateway zwischen MIP und
IP. Die Abbildung 5.9 zeigt die verwendeten Protokolle im Vergleich zum OSI-Modell.
Ein IP Host initiiert die Kommunikation zu einem MIP Knoten
Die Knoten innerhalb der Domäne der hierarchischen Protokollfamilie für die Steuerdatenkommunikation können aus Sicht von IP als Klasse B Subnetz adressiert werden. Das Gateway
nimmt stellvertretend für alle MIP Knoten die Datenpakete von den IP Hosts entgegen. Die
Inhalte der empfangenen TCP und UDP Datenpakete können sehr einfach von der Gateway
Applikation als MTCP und MUDP Datenpakete weitergegeben werden. Eine Auswertung der
Dateninhalte ist nicht notwendig. Die Quell IP Adresse wird auf eine MIP Adresse abgebildet,
so dass die MIP Zielknoten auf diese Weise Antwortpakete senden können. Das Gateway verwendet neben seiner eigenen MIP Adresse auf derselben Schnittstelle hierfür die MIP Adressen
eines eigenen Subnetzes. Der Zusammenhang zwischen IP Adresse und MIP Adresse wird vom
Gateway in einer Tabelle festgehalten. Ungenutzte Tabelleneinträge werden nach Ablauf einer
gewissen Zeitspanne gelöscht.
5.1. REALISIERTE TEILASPEKTE
85
Gateway
Gateway Applikation
Applikation
Applikationsschicht
Namen- und
Adressauflösung
DNS
7
Darstellungsschicht
6
Sitzungsschicht
5
Transportschicht
UDP
TCP
MUDP
MTCP
4
Vermittlungsschicht
IP
3
MIP
Schnittstelle zum Feldbus
Sicherungsschicht
2
Ethernet
Feldbus
Medium
Medium
Bitübertragungsschicht
1
Medium
Abbildung 5.9: Einordnung der Gateway Applikation in das OSI-Modell
Besonders reibungslos funktioniert die einfache Weitergabe unter der Voraussetzung, dass die
maximal möglichen Nutzdatenmengen, bei MUDP 254 Byte (Kapitel 4.3) bzw. bei MTCP
251 Byte (Kapitel 4.4), von den IP Knoten eingehalten werden und der zulässige Portbereich
0 .. 15 von MUDP und MTCP berücksichtigt wird. Eventuelle Verbindungsversuche auf Ports
ausserhalb des zulässigen Bereichs werden ansonsten als ICMP Paket mit dem Code „port unreachable“ [Pos81b] an den Internet Host mitgeteilt.
Die Kommunikation ist damit transparent.
Ein MIP Knoten initiiert die Kommunikation zu einem IP Host
Die Behandlung von Datenpaketen geschieht analog zur oben beschriebenen Vorgehensweise.
Jedoch kann der Tabelleneintrag für die Zuordnung der MIP Adresse an der Schnittstelle des
Gateways auf die IP Adresse nicht automatisch angelegt werden.
Der Gateway Applikation wurde deshalb ein Dienst angegliedert, der mit einem einfachen Protokoll die Namen- und Adressauflösung ermöglicht. Dieses Protokoll nutzt MUDP Datenpakete.
Die Kommunikation ist nach dieser Initialisierungsphase transparent.
Die Abbildung 5.10 zeigt das Datenformat, welches für die Namen- und Adressauflösung genutzt wird. Die Beschreibung der einzelnen Protokollfelder erfolgt anschließend.
Type
Mit diesem Feld wird die Funktion des Paketes laut Tabelle 5.1 angegeben.
86
KAPITEL 5. DEMONSTRATIONSSYSTEM
Type
4 Bit
Code
4 Bit
Data
0 .. 253 Byte
Abbildung 5.10: Paket für die Namen- und Adressauflösung
0x0Hex
0x1Hex
0x2Hex
0x3Hex
Get Host by Name
(Anforderung einer MIP Adresse durch Namenauflösung)
Get Host by Address
(Anforderung einer MIP Adresse durch Adressauflösung)
MIP Address is
(Bekanntgabe der zugewiesenen MIP Adresse)
Error
(Signalisierung von aufgetretenen Fehlern)
Tabelle 5.1: Type für die Namen- und Adressauflösung
Code
Code enthält eine Angabe, die in Abhängigkeit von Type interpretiert wird.
Data
Enthält weitere Daten in Abhängigkeit von Type. Es sind maximal 253 Byte erlaubt.
Get Host by Name
Hiermit fordert ein MIP Knoten die Gateway Applikation auf, einen Tabelleneintrag für die Zuordnung der MIP Adresse an der Schnittstelle des Gateways auf eine IP Adresse anzulegen. Der
gewünschte Zielhost wird über seinen Hostnamen angegeben. Die Auflösung des Hostnamens
in die IP Adresse geschieht innerhalb des Internet Protokollstapels mit Hilfe des Dienstes DNS
(Domain Name System) [Moc87a, Moc87b].
Das Feld Code ist für die zukünftige Angabe des verwendeten Zeichensatzes im Feld Data reserviert. Es muss derzeit immer auf 0x0Hex gesetzt werden.
In das Feld Data wird im Klartext unter Verwendung des ASCII (American Standard Code for Information Interchange) Zeichensatzes der gewünschte Hostname, z. B.
„hostname.domain.top-level-domain“, eingetragen.
Get Host by Address
Hiermit fordert ein MIP Knoten die Gateway Applikation auf, einen Tabelleneintrag für die
Zuordnung der MIP Adresse an der Schnittstelle des Gateways auf eine IP Adresse anzulegen.
Der gewünschte Zielhost wird über seine IP Adresse angegeben.
5.2. FAZIT
87
Das Feld Code ist ungenutzt, es muss immer auf 0x0Hex gesetzt werden.
Die IP Adresse wird numerisch als vier Byte in das Feld Data eingetragen.
MIP Address is
Dieses Paket wird als Antwort auf die vorherigen Anfragen von der Gateway Applikation versendet, es enthält die zugewiesene MIP Adresse.
Das Feld Code ist ungenutzt, es wird immer auf 0x0Hex gesetzt.
Das Feld Data enthält die MIP Adresse in numerischer Form als zwei Byte.
Error
Dieses Paket dient der Gateway Applikation zur Signalisierung von Fehlern.
Das Feld Code (Tabelle 5.2) spezifiziert den Fehler näher.
Das Feld Data bleibt leer.
0x0Hex
0x0Hex
0x1Hex
Invalid Paket
(Die Anfrage ist ungültig oder hat nicht mit den Paketen
„Get Host by Name“ oder „Get Host by Address“ stattgefunden.)
Host unknown
(Wird versendet wenn die Auflösung des Hostnamens
innerhalb des IP Protokollstapels gescheitert ist.)
Too much connections
(Signalisiert, dass die maximale Verbindungsanzahl des
MIP Protokollstapels erreicht ist und ein erneuter Verbindungsversuch zu einem späteren Zeitpunkt notwendig ist.)
Tabelle 5.2: Code bei Error
5.2
Fazit
Die Funktionsfähigkeit der Protokollfamilie konnte mit den zuvor beschriebenen Tests in realen
Aufbauten nachgewiesen werden. Alle wesentlichen Funktionen der definierten Protokolle der
hierarchischen Familie sind bei den drei Szenarien verwendet worden. Darüber hinaus sind eine
Vielzahl der Anforderungen aus Kapitel 3.1, wie z. B. gemeinsame Schnittstellen, einheitliche
Transportdienste, einheitliches Adressierungsschema, Wegewahl unter Berücksichtigung von
QoS-Parametern, Optimierung für Steuerdaten, Interoperabilität mit der Internet-Welt, von den
Tests ebenfalls bestätigt worden.
Beim Szenario Warenbuchungssystem (Kapitel 5.1.1) stellten die begrenzten Ressourcen der
16 Bit Architektur eine Herausforderung für die Umsetzung das Gateways dar. Einerseits mussten neben der Applikation beide Protokollstapel, MTCP/MIP und TCP/IP, auf dem embedded
88
KAPITEL 5. DEMONSTRATIONSSYSTEM
System zur Verfügung stehen. Andererseits konnte auf dem Universalsteuergerät 2 nur ein Prozessor Modul mit maximal jeweils 512 kByte FlashEPROM und RAM verwendet werden, da
nur in dieser Kombination auch gleichzeitig das benötigte Ethernet Modul eingesetzt werden
kann.
Als besonders hinderlich hat sich der begrenzte Speicher auf dem Universalsteuergerät erwiesen. Während der Phase der Fehlersuche und -behebung (sogenanntes Debugging) wird von
der EUROS Entwicklungsumgebung die Software üblicherweise nicht in das FlashEPROM geladen, sondern der Maschinencode und die Laufzeitvariablen ausschließlich im RAM vorgehalten. Eine weitere Verschärfung ergibt sich außerdem dadurch, dass man als Entwickler die
EUROS Betriebssystem Bibliotheken mit Debugging Informationen einbindet, welche detailliertere Informationen über den Programmablauf ausgeben können. Jedoch sind diese Bibliotheken größer und belegen abermals mehr Speicher.
Durch verschiedene Maßnahmen konnte der benötigte Speicherbedarf beim zweiten Universalsteuergerät soweit verkleinert werden, dass das Gateway funktionsfähig wurde. Für das Betriebssystems EUROS wurde die Speicheraufteilung und die Größe des Stack (Stapelspeichers)
angepasst, die maximal erlaubten Prozesse auf ein Mindestmaß reduziert und zu guter Letzt
die Bibliotheken ohne Debugging Informationen eingesetzt. Beim MTCP/MIP Protokollstapel
wurden die Pufferspeicher für Datenpakete reduziert und nur eine eingehende Verbindung erlaubt. Die Applikation verwendet den TCP/IP Protokollstapel nur zur Übermittlung der Strichcodedaten an den Webserver, verzichtet jedoch auf die Auswertung der in HTML formatierten
Rückmeldung. Das erfolgreiche Senden des Barcodes kann direkt am webbasierten Benutzerinterface verfolgt werden.
Das Szenario Warenbuchungssystem ist somit ein erfolgreicher Test für den verbindungsorientierten und transaktionsbasierten Transportdienst mit MTCP auf Basis der Vermittlungsschicht
mit MIP.
Mit den Aufbauten zum Test der Basisfunktionen für das dynamische Routing (Kapitel 5.1.2)
konnte in überschaubaren Netzwerkstrukturen nachvollzogen werden, dass das Erkennen benachbarter Router und der Austausch der Topologie-Informationen mit dem Routingprotokoll
MOPSF korrekt stattgefunden hat.
Beim zweiten Aufbau wurde beobachtet, dass nach dem Einschalten des System eine erhöhte Netzwerklast durch MOSPF Database Description Pakete und dadurch ausgelöste
Datenbankaustausch-Vorgänge auftrat. Dieser Einschwingvorgang ist eine Folge aus dem aktiv werden der Netzwerkschnittstellen in den Routern und dem Erkennen der Nachbarschaften.
In einem realen System sollte dieser Sachverhalt berücksichtigt werden. Im Testaufbau wurde
dem so begegnet, dass die MOSPF Database Description Pakete beim Start der Router verzögert versendet worden sind.
Ebenfalls beim Aufbau 2 hat der Austausch der Datenbank mit den Topologie-Informationen
fast eine Sekunde gedauert, was doch etwas langsam erscheint. Der Grund hierfür sind künstlich
eingefügte Verzögerungszeiten im Programmablauf, die zum besseren Verfolgen des Vorgänge
dienen. Ein weiterer Grund ergibt sich duch die Ausgabe der Meldungen über die asynchrone
serielle Schnittstelle (RS232) mit 57600 kBit/s. So dauert z. B. das reine Übertragen eines Datenbankaustauschs wie in Abbildung 5.8 in der Größenordnung von 100 ms. In einem realen
Aufbau würden diese Latenzzeiten natürlich nicht auftreten.
Auf eine Realisierung der weniger komplexen Vorgänge, der Berechnung der Leitungskosten
und den Aufbau der Routingtabellen, wurde verzichtet. Solch ein Test würde auch nur in einem
5.2. FAZIT
89
größeren Aufbau einen Sinn machen, der die Wegewahl über viele Router und diverse alternative Routen zulässt. Hierfür standen aber leider nicht genügend Universalsteuergeräte zur
Verfügung.
Mit dem Testaufbau für die Interoperabilität zwischen MIP und IP (Kapitel 5.1.3) konnte die
einfache Übergangsmöglichkeit zwischen der hierarchischen Protokollfamilie für die Steuerdatenkommunikation und der Internet-Welt erfolgreich überprüft werden. Nachdem alle bisherigen Szenarien mit dem 16 Bit Mikrocontroller realisiert worden sind, ist dies auch gleichzeitig
ein Nachweis für die Plattformunabhängig der MIP Familie, da nun die x86 Architektur zum
Einsatz kommt.
Unter Einschränkung auf die maximalen Nutzdatenmengen von MTCP und MUDP und deren
zulässigen Portbereich kann die Gateway Applikation ohne Kenntniss über die Semantik der Inhalte Informationen zwischen den beiden Welten austauschen. Der Datentransfer wird dadurch
erheblich einfacher und effektiver.
Initiiert ein IP Host die Kommunikation zu einem MIP Knoten, so gestaltet sich die Umsetzung
der Adressierung für die Gateway Applikation in der Tat sehr einfach. Für den umgekehrten Fall
ist das Verfahren leider aufwendiger, da hier ein Dienst für die Namen- und Adressauflösung
für MIP Knoten geschaffen werden musste. Von Vorteil bleibt, dass für IP Hosts die Kommunikation in jedem Fall transparent bleibt.
Das Protokoll für die Namen- und Adressauflösung realisiert eine einfache Abfrage/AntwortAufgabenstellung. Es konnte erfolgreich auf Basis von MUDP Datenpaketen in diesem Szenario getestet werden.
90
KAPITEL 5. DEMONSTRATIONSSYSTEM
Kapitel 6
Zusammenfassung und Ausblick
Entsprechend dem Stand der Technik existiert bis heute kein einheitlicher Standard, der die
Kommunikation zwischen verschiedenen Automatisierungsgeräten festlegt.
Die Netzwerkstruktur in Kraftfahrzeugen, bei der industriellen Automatisierung und in Gebäuden ist heterogen, weil sich für die Anwendungsbereiche die unterschiedlichsten Feldbusse
nebeneinander etabliert haben. Eine Konvergenz der Netze ist auch in Zukunft nicht zu erwarten, da jedes System seine spezifischen Eigenschaften aufweist.
Viele Anwendungen setzen noch direkt auf der Sicherungsschicht auf. Aufgrund der eingesetzten eingebetteten Systeme mit ihren historisch bedingten begrenzten Ressourcen wird einem
geringen Overhead der Vorrang eingeräumt. Wegen der anwendungsspezifischen Dimensionierung besteht kein Bedarf für das Fragmentieren großer Datenpakete. In den eng begrenzten
Einsatzgebieten mit anfangs nur einem Bussegment bestand keine Notwendigkeit für die Wegewahl (Routing).
Gewisse höhere Protokolle, wie sie beispielsweise vom OSI-Modell vorgesehen werden, existieren zwar. Jedoch sind diese Protokollschichten nur für bestimmte Anwendungen und/oder
einem Feldbus definiert worden. Demzufolge existieren auch nur sehr unterschiedlich Ausprägungen auf oder bis zu einer gewissen Schicht des OSI-Modells.
Die bisherige Vorgehensweise hat nun eine konzeptionelle Grenze erreicht. In großen Automatisierungssystemen kommen nebeneinander für verschiedene Bereiche unterschiedlich spezialisierte Feldbusse zum Einsatz. Aus Gründen der erwünschten Interaktion der Teilsysteme kann
die Kommunikation zwischen den Netzwerksystemen nur über aufwendige, nicht standardisierte Gateways untereinander ermöglicht werden.
Hier beginnt nun der Beitrag dieser Arbeit. Es wird ein Konzept entwickelt, das eine Lösung
für zukunftssichere Entwicklungen zum Steuerdatenaustausch in heterogenen Netzwerkumgebungen bietet.
Bei der Formulierung der Anforderungen an das Protokoll werden besonders Steuerungsanwendungen, die einen Einsatz mehrerer Feldbusse und ihr Zusammenwirken benötigen, in Betracht
gezogen. Den Applikationen muss eine gemeinsame Schnittstelle zur Verfügung gestellt werden. Darauf aufbauend können dann vereinheitlichte Gateways entstehen. Einheitliche Transportdienste und ein einheitliches Adressierungsschema, die Erreichbarkeit von Automatisierungsgeräten bei Ausfall von einzelnen Netzwerksegmenten in einem ausreichend vermaschten
System und die Wegewahl unter Berücksichtigung des Quality of Service (QoS) in geeignet
91
92
KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK
strukturierten Feldbusumgebungen sind geforderte Aspekte. Im normalen Betrieb werden nur
wenige Nutzdatenbyte pro Datenrahmen übertragen, dabei spielt ein möglichst geringer Overhead eine wichtige Rolle. Um die Möglichkeit zur Softwareaktualisierung von Steuergeräten zu
bieten, müssen zeitweilig auch größere Datenmengen übertragen werden. Für die Diagnose und
Wartung ist eine Integration in bestehende Kommunikations- und Computersysteme notwendig.
Deshalb ist eine möglichst einfache Übergangsmöglichkeit in die Internet-Welt erforderlich.
Anhand von Anwendungsbeispielen wird der Mehrwert einer Protokollfamilie für die Steuerdatenkommunikation vorgestellt. Für verschiedene Einsatzbereiche werden Referenzarchitekturen
entwickelt und daran die Vorteile beim verbesserten Zusammenwirken der Teilsysteme diskutiert.
Es werden zwei unterschiedliche Lösungsansätze vorgestellt mit denen die geforderten Funktionen für die Steuerungsanwendungen umgesetzt werden könnten. Der erste Vorschlag sieht für
Applikationen eine Programmierschnittstelle (API) mit definierten Funktionsaufrufen vor. Die
API wird durch eine Anpassungsschicht bereitgestellt, die für Softwareentwickler als Middleware und für Netzwerkentwickler als vergleichbar mit der Schicht 7 gesehen werden kann.
Der zweite Lösungsvorschlag sieht eine hierarchische Protokollfamilie vor, welche dem ISO
OSI-Modell folgt und konzeptionell Nutzbares von der Internet-Protokollfamilie übernimmt.
Entsprechend der gewohnten Sichtweise eines Netzwerkentwicklers erfolgt die Konvergenz der
heterogenen Netze dabei in der Schicht 3 und die Transportdienste sind in der Schicht 4 angesiedelt. Im Folgenden werden die beiden Lösungsansätze diskutiert, dabei wird dem offenen
modularen Konzept der hierarchischen Protokollfamilie der Vorrang gegenüber dem aufwendigen monolithischen Protokollblock mit der Anpassungsschicht für die API gegeben.
Der Kern dieser Arbeit besteht in der Definition der hierarchischen Protokollfamilie und der
Beschreibung der Funktionsweise im Stil eines Standards. Um einen für die Feldbusse geringeren Overhead unter Gewährleistung der zuvor geforderten Eigenschaften zu erzielen, wurden
Protokolle mit kleinen, optimierten Headern konzipiert.
Das Micro Internet Protocol (MIP) stellt zusammen mit den Anpassmodulen zu den Feldbussen die Netzwerkschicht dar. Auf dieser Schicht geschieht die Konvergenz der Feldbusse und
erfolgt die einheitliche logische Adressierung. Auf die Verwendung von Gateways kann innerhalb dieses Systems fortan verzichtet werden, da MIP die Voraussetzungen bietet, um die
Wegewahl mittels Routern auf der Schicht 3 durchführen zu können. Die Berücksichtigung des
QoS erfolgt mit dem ToS Feld im MIP Header. Die Optimierung für die Steuerdatenkommunikation zeigt sich durch den verkleinerten Header, der unter Beibehaltung aller notwendigen
Funktionen fast nur noch ein Drittel der Headergröße von IP aufweist.
Vier weitverbreitete Bussysteme, LIN, CAN, Bluetooth und IEEE 1394, wurden aufgrund ihrer
unterschiedlichen Einsatzzwecke und Eigenschaften für die Definition von exemplarischen Anpassungen ausgewählt. Die Anpassmodule für Bluetooth und IEEE 1394 mussten jeweils mit
einem zusätzlichen Hilfsprotokoll zur Auflösung der logischen Adressierung auf das Adressmodell der zugrundeliegenden Technologie ausgestattet werden. Für LIN und CAN wurde eine
elegante Möglichkeit gefunden, um ohne diesen zusätzlichen Aufwand auszukommen.
Alle weiteren Protokolle sind auf der Schicht 4 angesiedelt.
Das Micro Internet Control Message Protocol (MICMP) ist das notwendige Hilfsprotokoll für
die Signalisierung von Fehlern bei der Verarbeitung von MIP Datagrammen. Außerdem dient
MICMP der Netzwerkdiagnose. Die Größe des MICMP Headers konnte soweit reduziert werden, dass er gegenüber der Headergröße von ICMP nur noch ein Achtel beträgt.
93
Das Micro User Datagram Protocol (MUDP) stellt den Anwendungen eine einheitliche Schnittstelle für den unbestätigten Datentransport bereit. Der MUDP Header konnte im Vergleich zu
UDP auf ein Achtel der Größe reduziert werden.
Das Micro Transmission Control Protocol (MTCP) vereinigt auf elegante Weise den bestätigten und transaktionsbasierten Datentransport in einem gemeinsamen Protokoll und stellt den
Anwendungen hierfür eine einheitliche Schnittstelle bereit. Der Ablauf bei MTCP wurde so
optimiert, dass Nutzdaten bereits während des Verbindungsaufbaus und bis kurz vor der Trennung der Verbindung noch transportiert werden können. Die Transaktion kann dadurch quasi
als Spezialfall der bestätigten Verbindung gehandhabt werden. Die Größe des MTCP Headers
konnte auf ein Fünftel der Headergröße von TCP verschlankt werden.
Micro Open Shortest Path First (MOSPF) vervollständigt die Protokollfamilie mit einem Link
State Routingprotokoll für die Wegewahl unter Berücksichtigung von QoS-Parametern. Mit
MOSPF werden nur die Änderungen an der Topologie ausgetauscht und somit nur wenig Netzwerkverkehr erzeugt. Als Link State Routingprotokoll reagiert MOSPF wesentlich schneller auf
Topologieänderungen als ein Distance Vector Routingprotokoll. Beides kommt dem Einsatz für
die Steuerdatenkommunikation mit Feldbussen entgegen. Der MOSPF Header konnte soweit
verkleinert werden, dass er nur noch ein Achtel der Headergröße von OSPF aufweist.
Eine eingehendere Analyse betrachtet die Effektivität von MIP, sowie die Transferzeiten und
Latenzzeiten eines MTCP/MIP Datenrahmens. Dabei zeigt sich, dass IP via Ethernet gerade
bei kleinen Nutzdatengrößen keine vertretbare Lösung für die Steuerdatenkommunikation darstellt. Bei ≤ 18 Nutzdatenbyte verursacht MIP unabhängig von den vier ausgewählten Feldbussen immer einen wesentlich kleineren Overhead als IP. Beim Versenden von Datagrammen
via Bluetooth ACL DH5 Paketen oder via dem IEEE 1394 ist MIP grundsätzlich besser. Die
geringere Leistungsfähigkeit von LIN bei der Transferzeit und Latenzzeit verwundert aufgrund
der Kenndaten dieses Feldbusses nicht. Der geringe Overhead beim hochbitratigen IEEE 1394
läßt eine hohe Leistungsfähigkeit erwarten. Wegen der fairen Arbitrierung und der Optimierung
auf große Datenpakete fällt die Latenzzeit aber relativ groß aus. Bei gleichzeitigem isochronem Datenverkehr kann sie im Extremfall sogar bis auf beinahe das Zehnfache ansteigen. Diese
Analysen unterstreichen auch nochmals die Sinnhaftigkeit für den Einsatz der unterschiedlichen
Feldbusse nebeneinander in einem Automatisierungssystem.
Zur Demonstration der zuvor entwickelten Protokolle wurden möglichst universelle Entwicklungsumgebungen geschaffen. Für anspruchsvollere Aufgaben mit grafischer Bedienoberfläche
wird die x86 Architektur und das Betriebssystem Linux verwendet. Als typischer Vertreter eines
Knotens in einem embedded System kommt der 16 Bit Mikrocontroller C167 mit integriertem
CAN Controller und das multitaskingfähige Echtzeitbetriebssystem EUROS zum Einsatz. Für
untergeordnete Aufgaben als Coprozessor auf Zusatzmodulen der 16 Bit Architektur und für
abgesetzte Slave Knoten findet der RISC Mikrocontroller PIC16 Verwendung.
In Ermangelung geeigneter Komponenten auf dem freien Markt wurde am Institut OMI eine
eigene Entwicklungplattform, das sogenannte Universalsteuergerät, auf Basis der 16 Bit Architektur und dem RISC Mikrocontroller entwickelt. Das Hardwarekonzept ist stark modular
ausgelegt, um eine möglichst hohe Flexibilität zu erreichen.
Alle wesentlichen Funktionen der hierarchischen Protokollfamilie sind in drei Testszenarien
verwendet worden. Die Funktionsfähigkeit und Plattformunabhängigkeit der Protokolle konnte
mit diesen Tests in realen Aufbauten erfolgreich nachgewiesen werden. Außerdem konnten Erfahrungen zur Einschätzung von Speicherverbrauch und Verarbeitungszeit gesammelt werden.
94
KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK
Die in dieser Dissertationsschrift vorgestellte hierarchische Protokollfamilie zur universellen
Steuerdatenkommunikation in heterogenen Netzwerkumgebungen zeigt ein zukunftsweisendes
Konzept für die Automatisierung auf.
Aufgrund der rasanten Fortentwicklung bei den Hardwarekomponenten existieren schon jetzt
wesentlich leistungsfähigere embedded Systeme. Somit werden die bei den realisierten Teilaspekten aufgetretenen Engpässe bei den Ressourcen in der Zukunft eine immer geringere Rolle spielen.
Ein wichtiger nächster Schritt wäre nun der Einsatz der Protokollfamilie in einem komplexen realen Automatisierungssystem mit einer Vielzahl von Routern und Endknoten, die über
verschiedene Feldbusse miteinander vernetzt sind, vergleichbar den Referenzarchitekturen in
Kapitel 3. Damit könnten weitere Erfahrungen mit den Protokollen gesammelt werden und Optimierungen an der Implementierung vorgenommen werden.
Weitere Schritte wären die Definition von Schnittstellen zu anderen Feldbussen nach dem Vorbild der bisherigen Anpassungen. Für Router könnten spezielle integrierte Bausteine entwickelt
werden, die MIP Datagramme wesentlich effektiver verarbeiten können als das bisher mit softwaregestützter Hardware möglich ist. Bei einem offenen System, insbesondere mit Anbindung
zum Internet, werden alsbald Fragen zur Sicherheit entstehen. Hierauf wird man mit Firewalls
und vergleichbaren Überlegungen aus der Internet-Welt reagieren können.
Anhang A
Berechnungen
Nomenklatur
Die Funktion
y = AUFRUNDEN (x)
rundet die Zahl x auf den nächstgrößeren ganzzahligen Wert auf.
Die Funktion
y = MAX (x1 ; x2 )
gibt den größeren Wert der beiden Argumente x1 oder x2 zurück.
Mit
n<Bezeichnung>
wird eine Anzahl an Byte bezeichnet.
Mit
m<Bezeichnung>
wird eine Anzahl an Datenrahmen bezeichnet.
Mit
NKnoten
wird eine Anzahl an Knoten bezeichnet.
95
96
ANHANG A. BERECHNUNGEN
Größe der Protokollheader
Größe des Standard IP Headers ohne Optionen [Pos81a]:
nIP Header = 20 Byte
(A.1)
Größe des MIP Headers (Kapitel 4.1):
nMIP Header = 7 Byte
(A.2)
Größe des MTCP Headers (Kapitel 4.4):
nMTCP Header = 4 Byte
A.1
Effektivität und Overhead
A.1.1
LIN
(A.3)
Bei LIN wird ein Bytefeld auf dem physikalischen Medium mit 10 Bit, bestehend aus einem
Startbit, den 8 Nutzdatenbit und einem Stoppbit, gesendet [LIN03].
Der Overhead durch die Schnittstelle zu LIN (Kapitel 4.1.1):
nMIP↔LIN Schnittstelle = 2 Byte
(A.4)
LIN unconditional
Der Overhead durch das LIN Protokoll mit unbedingten Datenrahmen [LIN03]:
nLIN u. Protokoll = nBreak + nSynch + nIdentifier + nChecksum
14
=
Byte + 1 Byte + 1 Byte + 1 Byte
10
= 4,4 Byte
(A.5)
Die Anzahl der Nutzdatenbyte eines LIN Datenrahmens [LIN03]:
nLIN u. Nutzdaten = 8 Byte
(A.6)
Die Anzahl der benötigten unbedingten LIN Datenrahmen zum Transport eines MIP Datagramms:
nMIP Header + nNutzdaten
mLIN u. Datenrahmen = AUFRUNDEN
(A.7)
nLIN u. Nutzdaten − nMIP↔LIN Schnittstelle
Die Anzahl der auf dem physikalischen Medium gesendeten Byte:
nLIN u. Daten = mLIN u. Datenrahmen · (nLIN u. Protokoll + nLIN u. Nutzdaten )
(A.8)
A.1. EFFEKTIVITÄT UND OVERHEAD
97
LIN event triggered
Der Overhead durch das LIN Protokoll mit ereignisgesteuerten Datenrahmen [LIN03]:
nLIN e. Protokoll = nBreak + nSynch + nIdentifier + nID of unc. Frame + nChecksum
14
=
Byte + 1 Byte + 1 Byte + 1 Byte + 1 Byte
10
= 5,4 Byte
(A.9)
Die Anzahl der Nutzdatenbyte eines LIN Datenrahmens [LIN03]:
nLIN e. Nutzdaten = 7 Byte
(A.10)
Die Anzahl der benötigten ereignisgesteuerten LIN Datenrahmen zum Transport eines MIP
Datagramms:
nMIP Header + nNutzdaten
(A.11)
mLIN e. Datenrahmen = AUFRUNDEN
nLIN e. Nutzdaten − nMIP↔LIN Schnittstelle
Die Anzahl der auf dem physikalischen Medium gesendeten Byte:
nLIN e. Daten = mLIN e. Datenrahmen · (nLIN e. Protokoll + nLIN e. Nutzdaten )
A.1.2
(A.12)
CAN
Durch das Bit Stuffing [BOS91] hinzugefügte Bits werden bei der Berechnung vernachlässigt.
Der Overhead durch einen CAN Extended Datenrahmen [BOS91]:
nCAN Protokoll = nSOF + nIdentifier + nSRR + nIDE + nRTR + nreserved Bits +
nDLC + nCRC + nACK + nEOF + nIFS
(1 + 29 + 1 + 1 + 1 + 2 + 4 + 16 + 2 + 7 + 3) Bit
=
Bit
8 Byte
= 8,375 Byte
(A.13)
Die verwendeten Abkürzungen für die Felder sind: SOF – Start of Frame, SRR – Substitute
Remote Request, IDE – Identifier Extension, RTR – Remote Transmission Request, DLC –
Data Length Code, CRC – Cyclic Redundancy Check, ACK – Acknowledgement, EOF – End
of Frame, IFS – Inter Frame Space.
Die Anzahl der maximalen Nutzdatenbyte eines CAN Datenrahmens [BOS91]:
nCAN Nutzdaten = 8 Byte
(A.14)
Der Overhead durch die Schnittstelle zu CAN (Kapitel 4.1.2):
nMIP↔CAN Schnittstelle = 1 Byte
(A.15)
98
ANHANG A. BERECHNUNGEN
Die Anzahl der benötigten CAN Extended Datenrahmen zum Transport eines MIP Datagramms:
nMIP Header + nNutzdaten
mCAN Datenrahmen = AUFRUNDEN
(A.16)
nCAN Nutzdaten − nMIP↔CAN Schnittstelle
Die Anzahl der auf dem physikalischen Medium gesendeten Byte:
nCAN Daten = mCAN Datenrahmen · (nCAN Protokoll + nMIP↔CAN Schnittstelle ) +
(A.17)
nMIP Header + nNutzdaten
A.1.3
Bluetooth
Das BNEP over L2CAP Protokoll verwendet die Asynchronous Logical Transport (ACL) Verbindungen [SIG04a, SIG04c].
Der Overhead durch ein Basic Rate Paket [SIG04c]:
nBasic Rate Header = nAccess Code + nPacket Header
72 Bit + 54 Bit
=
Bit
8 Byte
= 15,75 Byte
(A.18)
Der Overhead durch das BNEP over L2CAP Protokoll [SIG04c]:
nBNEP Protokoll = nL2CAP Header connection−oriented + nBNEP_Type
= 4 Byte + 1 Byte
= 5 Byte
(A.19)
Der Overhead durch die Schnittstelle zu BNEP (Kapitel 4.1.3):
nMIP↔BNEP Schnittstelle = 1 Byte
(A.20)
Die Größe des L2CAP Datenrahmens zum Transport eines MIP Datagramms:
nL2CAP Daten = nBNEP Protokoll + nMIP↔BNEP Schnittstelle +
nMIP Header + nNutzdaten
(A.21)
Bluetooth DH1
Ein ACL DH1 Paket besteht aus einem ein Byte großen Header, maximal 27 Nutzdatenbyte und
einer 16 Bit CRC Prüfsumme [SIG04c].
Im Bedarfsfall nimmt der Bluetooth Protokollstapel an der Schnittstelle zwischen L2CAP und
der ACL Verbindung eine Fragmentierung vor.
A.1. EFFEKTIVITÄT UND OVERHEAD
99
Der Overhead durch das Bluetooth DH1 Protokoll [SIG04c]:
nDH1 Protokoll = nBasic Rate Header + nDH1 Header + nDH1 CRC
= 15,75 Byte + 1 Byte + 2 Byte
= 18,75 Byte
(A.22)
Die Anzahl der maximalen Nutzdatenbyte eines Bluetooth DH1 Datenrahmens [SIG04c]:
nDH1 Nutzdaten = 27 Byte
(A.23)
Die Anzahl der benötigten DH1 Datenrahmen zum Transport eines MIP Datagramms:
nL2CAP Daten
(A.24)
mDH1 Datenrahmen = AUFRUNDEN
nDH1 Nutzdaten
Die Anzahl der gesendeten Byte:
nBluetooth DH1 Daten = mDH1 Datenrahmen · nDH1 Protokoll + nL2CAP Daten
(A.25)
Bluetooth DH5
Ein ACL DH5 Paket besteht aus einem zwei Byte großen Header, maximal 339 Nutzdatenbyte
und einer 16 Bit CRC Prüfsumme [SIG04c]. Die Nutzdatenkapazität eines ACL DH5 Pakets
ist damit ausreichend groß, so dass der Bluetooth Protokollstapel keine Fragmentierung für den
Transport eines MIP Datagramms vornehmen muss.
Der Overhead durch das Bluetooth DH5 Protokoll [SIG04c]:
nDH5 Protokoll = nBasic Rate Header + nDH5 Header + nDH5 CRC
= 15,75 Byte + 2 Byte + 2 Byte
= 19,75 Byte
(A.26)
Die Anzahl der gesendeten Byte zum Transport eines MIP Datagramms:
nBluetooth DH5 Daten = nDH5 Protokoll + nL2CAP Daten
A.1.4
(A.27)
IEEE 1394
Das Nutzdatenfeld bei IEEE 1394 muss immer auf volle Quadlet, entsprechend 4 Byte, aufgefüllt werden.
Die Anzahl der benötigten Quadlet im IEEE 1394 Data Field zum Transport eines MIP Datagramms:
nMIP Header + nNutzdaten
m1394 Data Field = AUFRUNDEN
(A.28)
4 Byte
100
ANHANG A. BERECHNUNGEN
IEEE 1394 WRDB
Der Overhead durch das IEEE 1394 WRDB Protokoll [IEE95]:
n1394 WRDB Protokoll = nWRDB Header + ndata_CRC
= (5 Quadlet + 1 Quadlet) · 4
Byte
Quadlet
= 24 Byte
(A.29)
Die Anzahl der zu versendenden Byte:
n1394 WRDB Daten = n1394 WRDB Protokoll + m1394 Data Field · 4 Byte
(A.30)
IEEE 1394 GASP
Der Overhead durch das IEEE 1394 GASP Protokoll [IEE98]:
n1394 GASP Protokoll = nGASP Header + ndata_CRC
= (4 Quadlet + 1 Quadlet) · 4
Byte
Quadlet
= 20 Byte
(A.31)
Die Anzahl der zu versendenden Byte:
n1394 GASP Daten = n1394 GASP Protokoll + m1394 Data Field · 4 Byte
A.1.5
(A.32)
Zum Vergleich: IP via Ethernet
Der Overhead durch einen Ethernet Datenrahmen ohne Virtual Local Area Network (VLAN)
Tag [IEE02]:
nEth Protokoll = nPreamble + nSFD + nDestination Addr + nSource Addr + nType + nFCS
= (7 + 1 + 6 + 6 + 2 + 4) Byte
= 26 Byte
(A.33)
Die verwendeten Abkürzungen für die Felder sind: SFD – Start Frame Delimiter, FCS – Frame
Check Sequence.
Der Datenrahmen muss auf mindestens 46 Byte Nutzdaten aufgefüllt werden (sogenanntes Padding), um die Minimalgröße von 64 Byte für einen Ethernet Datenrahmen zu erreichen.
Die Anzahl der gesendeten Byte zum Transport eines IP Datagramms:
nEth Daten = nEth Protokoll + MAX (46 Byte ; nIP Header + nNutzdaten )
(A.34)
A.2. TRANSFERDAUER UND LATENZZEIT
A.2
101
Transferdauer und Latenzzeit
Zur Abschätzung der Transferdauer und Latenzzeit wird ein MTCP Datenpaket mit 8 Nutzdatenbyte, der typischen Nutzdatenmenge in der Steuerdatenkommunikation, verwendet.
Folglich müssen
nNutzdaten = nMTCP Header + nMTCP Nutzdaten
= 4 Byte + 8 Byte
= 12 Byte
(A.35)
von einem MIP Datagramm übertragen werden.
Die folgenden Berechnungen basieren auf den obenstehenden Formeln aus Anhang A.1.
A.2.1
LIN unconditional
kBit
s
Für die Berechnung wird die maximal mögliche Bitrate von 20
verwendet [LIN03].
Die Transferdauer des MTCP Datenpakets:
tTransfer LIN u. =
=
nLIN u. Nutzdaten · 10
Bit
Byte
Bitrate
Bit
49,6 Byte · 10 Byte
20
= 24,8 ms
(A.36)
kBit
s
(A.37)
Die Latenzzeit zwischen der Übertragung zweier MTCP Datenpakete bei NKnoten = 16 Knoten
im Netz und einer zyklischen Abfrage aller Knoten durch den Master:
tLatenz LIN u. = NKnoten · mLIN u. Datenrahmen · tLIN u. Datenrahmen
Bit
12,4 Byte · 10 Byte
= 16 · 4 ·
20 kBit
s
= 396,8 ms
A.2.2
(A.38)
(A.39)
CAN
Für die Berechnung wird die maximal mögliche Bitrate von 1 MBit
verwendet [BOS91]. Durch
s
das Bit Stuffing [BOS91] hinzugefügte Bits werden bei der Berechnung vernachlässigt.
Die Transferdauer des MTCP Datenpakets:
tTransfer CAN =
=
nCAN Nutzdaten · 8
Bitrate
47,125 Byte · 8
= 377 µs
1
Bit
Byte
(A.40)
Bit
Byte
MBit
s
(A.41)
102
ANHANG A. BERECHNUNGEN
Die Latenzzeit zwischen der Übertragung zweier MTCP Datenpakete:
tLatenz CAN = mCAN Datenrahmen · tCAN Datenrahmen, max.
Bit
16,375 Byte · 8 Byte
= 3·
1 MBit
s
= 393 µs
A.2.3
(A.42)
(A.43)
Bluetooth DH1
Bluetooth verwendet ein Zeitschlitzverfahren mit tSlot = 625 µs. Der Master beginnt in den
Zeitschlitzen mit gerader Nummer, die Slaves in den Zeitschlitzen mit ungerader Nummer
[SIG04c] zu senden.
Die Transferdauer des MTCP Datenpakets:
tTransfer Bluetooth DH1 = mDH1 Datenrahmen · tSlot
= 1 · 625 µs
= 625 µs
(A.44)
(A.45)
Die Latenzzeit zwischen der Übertragung zweier MTCP Datenpakete bei 7 Slaves im Piconet,
die jeweils eine ACL DH1 Verbindung zum Master haben:
tLatenz Bluetooth DH1 = (NKnoten − 1) · 2 · tSlot + tSlot
= (7 − 1) · 2 · 625 µs + 625 µs
= 8,125 ms
A.2.4
(A.46)
(A.47)
IEEE 1394 GASP
Für die Berechnung wurde die Basisdatenrate S100, entsprechend Bitrate = 98,304
wendet.
MBit
,
s
ver-
Die Übertragungsdauer des MTCP Datenpakets:
tTransfer 1394 GASP = tarb + tdata prefix +
n1394 GASP Daten · 8
Bitrate
Bit
Byte
+
tdata end + tsubaction gap
(A.48)
Bit
40 Byte · 8 Byte
≈ 2,6 µs + 0,1 µs +
+ 0,25 µs + 10 µs
98,304 MBit
s
≈ 12,95 µs
(A.49)
Die Werte für tarb , tdata prefix , tdata end und tsubaction gap sind aus [IEE95] entnommen.
A.2. TRANSFERDAUER UND LATENZZEIT
103
Aufgrund fairer Arbitrierung beträgt die Latenzzeit zwischen der Übertragung zweier MTCP
Datenpakete in einem Netz mit NKnoten = 63 Knoten und Nutzung der maximalen Nutzdatengröße nDaten, max. = 512 Byte der IEEE 1394 GASP Datenrahmen:
tLatenz 1394 GASP = (NKnoten − 1) ·
tarb + tdata prefix +
(nGASP Header + nDaten, max. ) · 8
Bitrate!
tdata end + tsubaction gap
≈ (63 − 1) ·
Bit
Byte
+
(A.50)
2,6 µs + 0,1 µs +
(20 + 512) Byte · 8
98,304
MBit
s
Bit
Byte
+
!
0,25 µs + 10 µs
≈ 3,5 ms
(A.51)
Die Latenzzeit vergrößert sich noch weiter, falls Bandbreite für isochrone Kanäle reserviert
worden ist.
Im denkbar schlechtesten Fall kann die Verzögerungszeit auf bis zu ≈ 32 ms ansteigen. Dieser
Fall wird erreicht, wenn die gesamte erlaubte isochrone Bandbreite auf 64 Kanäle verteilt wird
die von den 63 verschiedenen möglichen Netzknoten einzeln arbitriert werden und zudem alle
Netzknoten asynchrone Datenpakete mit maximaler Größe versenden wollen. Dabei kommt
etwa ein asynchrones Paket auf vier isochrone Zyklen.
104
ANHANG A. BERECHNUNGEN
Anhang B
Universalsteuergerät
Im Rahmen dieser Arbeit und durch mehrere Kooperationen mit Industriepartnern motiviert
wurde zu Testzwecken eine Entwicklungsplattform, das sogenannte Universalsteuergerät, entworfen. Das Hardwarekonzept ist stark modular ausgelegt, um mit möglichst geringem Aufwand einzelne Module tauschen zu können. Primärer Zweck ist umfassende Erfahrungen zu
sammeln im:
• Schaltungsdesign
• Analyse des Stromverbrauchs
• Auslegung des Kommunikationsmediums mit seinen Ansteuerkomponenten
• Protokolldesign
• Applikationsdesign
Hardwareaufbau
Das Universalsteuergerät setzt sich aus folgenden Modulen zusammen:
• Das Basis Modul, auf der sich die Spannungsversorgung und Leistungselektronik befindet
• Das IEEE 1394 Modul als zentrales Element mit dem IEEE 1394 Link Layer-Baustein
• Das Prozessor Modul mit integriertem CAN Controller für die Applikationen
• Die IEEE 1394 Physical Layer Module
• Ein E/A-Aufsatz Modul mit diversen Schnittstellen
• Ein Power Line Modul
• Ein LIN Modul
105
106
ANHANG B. UNIVERSALSTEUERGERÄT
• Ein Bluetooth Modul
• Ein Ethernet Modul
• Ein MiniMMI Modul als einfaches Mensch Maschine Interface (MMI)
Weitere ergänzende Module zum Betrieb mit dem Universalsteuergerät sind:
• Ein Complex Device
• Ein LIN Slave Knoten
Für den Betrieb ist minimal das Basismodul mit der Spannungsversorgung und das IEEE 1394
Modul mit dem Prozessor Modul notwendig. Alle weiteren Module sind je nach Einsatzzweck
optional.
Die am Institut OMI entwickelten Module werden im Folgenden kurz vorgestellt. Für die Funktion entscheidende eingesetzte integrierte Bausteine oder Baugruppen sind entsprechend gesondert erwähnt.
B.1. BASIS MODUL
B.1
107
Basis Modul
Das Basis Modul beinhaltet die Spannungsversorgung für die elektronischen Komponenten
(5 V; 3,3 V; 1,8 V) und 8 niederohmige Leistungsschalter auf einer Europlatine (160 mm x
100 mm). Ein PIC16 Mikrocontroller der Firma Microchip Technology Inc.1 dient als I2 C-Slave
zur Erfassung von bis zu vier Temperaturen, der Ströme und des Zustands der Leistungsschalter.
Die Abbildung B.1 zeigt das Modul.
Abbildung B.1: Basis Modul
B.2
IEEE 1394 Modul
Das IEEE 1394 Modul ist das Herzstück des Aufbaus. Typischerweise werden die unteren beiden Ebenen der IEEE 1394 Spezifikation jeweils als Hardwarekomponenten integriert und gefertigt. Auf dem IEEE 1394-Modul befindet sich als zentrales Element somit der IEEE 1394
Link Layer Baustein von der Firma Texas Instruments Inc.2 . Der hier verwendete Baustein ist
speziell für die Anwendung in optimierten eingebetteten Systemen vorgesehen. Der Baustein
besitzt im wesentlichen drei Schnittstellen. Eine zum Physical Layer, eine für den Host Controller und eine für isochrone Datenströme.
An der Host Controller Schnittstelle ist das Prozessor Modul angeschlossen. Hierüber kann der
Link Layer Baustein programmiert bzw. können die höheren asynchronen Protokolle abgewickelt werden.
Die isochrone Schnittstelle besteht aus zwei gleichen Teil-Schnittstellen. Es können somit zwei
isochrone Kanäle unabhängig voneinander gehandhabt werden. Insbesondere können an einer
Schnittstelle Daten gesendet und an der anderen empfangen werden. An der Schnittstelle werden direkt auf unterster Ebene die isochronen Daten gehandhabt. In einem embedded System
1
2
http://www.microchip.com/
http://www.ti.com/
108
ANHANG B. UNIVERSALSTEUERGERÄT
geht man normalerweise davon aus, dass echtzeitkritische Daten nicht wie in einem PC in Software abgearbeitet werden, sondern direkt in der Hardware. So können direkt an dieser Schnittstelle entsprechende Kodier-/Dekodierbausteine angeschlossen werden. Im Fall des IEEE 1394
Moduls wurde ein Field Programmable Gate Array (FPGA) der Firma Altera Corporation3 angeschlossen, das frei konfiguriert werden kann.
Zusätzlich wurde das FPGA mit RAM und einem ausreichend großen Festspeicher (FlashEPROM) versehen (je 1 MByte). So kann einerseits die Konfiguration des FPGA permanent
abgelegt werden und andererseits kann im FPGA wiederum ein Prozessor vorgesehen werden.
In diesem Fall handelt es sich um den von der Firma Altera zur Verfügung gestellten Nios Core.
Die Abbildung B.2 zeigt das Blockschaltbild des Moduls. Die Abbildung B.3 ist eine Fotografie
der Oberseite des IEEE 1394 Moduls.
Physical
Layer Modul
IEEE 1394 a/b
Configuration
Controller
Link Layer
TSB41AB4
IEEE 1394
Serial Bus
Phytec
phyCORE 167
MODUL
2xRS-232, 2xCAN
Boot+Reset-Switch
2 LED's
ISO Port 1+2
PowerSupply
3.3 V
JTAG
Interface
Altera APEX
EP20K200E
240QFP
Module
Connector-2
120 Pins
je 1 Mbyte
RAM / Flash
memory
1xRS232
Module
Connector-1
120 Pins
Abbildung B.2: Schema des IEEE 1394 Moduls
B.3 Prozessor Modul
Dieses Modul wurde zugekauft. Es kommt das phyCORE-167 Modul der Firma PHYTEC
Messtechnik GmbH4 zum Einsatz. Es enthält einen C167 16 Bit Mikrocontroller mit integriertem CAN Controller der Firma Infineon Technologies AG5 , RAM und FlashEPROM Speicher.
3
http://www.altera.com/
http://www.phytec.de/
5
http://www.infineon.com/
4
B.4. IEEE 1394 PHYSICAL LAYER MODULE
109
Abbildung B.3: IEEE 1394-Modul mit Prozessor Modul (links mitte) und IEEE 1394a Physical
Layer Modul (links unten)
B.4
IEEE 1394 Physical Layer Module
Nachdem die Eigenschaften des Physical Layers für den Einsatz im Fahrzeug entscheidend sind
und zudem verschiedene Varianten (IEEE 1394a, b und mit automotiven Erweiterungen) existieren, wurde hierfür ein eigenes Modul vorgesehen. Das IEEE 1394a Modul in Abbildung B.3
ist ein Entwicklungsmuster von der Firma Texas Instruments. Im wesentlichen wurden zwei
Module selbst aufgebaut. Ein reines IEEE 1394b Modul (Abbildung B.4 links) und ein Modul
an dem zusätzlich verschiedene Filtermaßnahmen vorgesehen und eigene Medien angeschlossen werden können (Abbildung B.4 rechts).
Abbildung B.4: IEEE 1394b Physical Layer Module
110
B.5
ANHANG B. UNIVERSALSTEUERGERÄT
E/A-Aufsatz Modul
Die meisten unbenutzen Anschlüsse des Prozessor Moduls und des FPGA werden über Steckverbinder zur Verfügung gestellt. So können sehr einfach ihrem jeweiligen Zweck entsprechende Erweiterungen als Aufsatz-Module aufgesteckt werden.
Das E/A-Aufsatz Modul stellt 8 digitale Eingänge, die 8 A/D Eingänge des C167 mit Schutzbeschaltung versehen, eine zweite serielle Schnittstelle mit RS232 Pegeln sowie eine galvanisch
und optisch getrennte CAN Schnittstelle bereit. Zusätzlich ist ein PIC16 Mikrocontroller vorgesehen an den alle Signale angeschlossen sind, die mit einem eventuellen Powermanagement
zusammenhängen. Der PIC16 kann als I2 C-Slave programmiert werden. Derzeit ist der Mikrocontroller allerdings nur mit einem Programm versehen, das sicherstellt, dass alle Ein- und
Ausgänge in einem hochimpedanten Zustand verbleiben. Die Abbildung B.5 zeigt eine Fotografie des Moduls.
Abbildung B.5: E/A-Aufsatz-Modul
B.6 Power Line Modul
Das Universalsteuergerät ist für den Einsatz als Feature Controller (FC), einer Art Master Knoten in EHS Netzwerken, vorgesehen. Das Power Line Modul besteht aus zwei getrennten Platinen, die mit einem Flachbandkabel verbunden werden.
Die Power Line Adapterplatine ist in der Größe einer halben Europlatine (100 mm x 80 mm)
entworfen worden. Über die Federkontaktstecker ist sie in den Modulstapel des Universalsteuergeräts integrierbar. Auf der Adapterplatine kommt als Coprozessor ein PIC16 zum Einsatz,
der die Aufgaben der Schicht 2 bei der Power Line Kommunikation übernimmt. Zum Aufgabenbereich des PIC16 zählt folglich die Steuerung des Power Line Modems, sowie die Kommunikation mit dem C167 Prozessor über die I2 C Schnittstelle. Die Abbildung B.6 zeigt eine
Fotografie der Adapterplatine.
B.7. LIN MODUL
111
Abbildung B.6: Power Line Adapterplatine
Das Power Line Modem ist auf einer getrennten Platine untergebracht, die zur Gewährleistung
des Berührungsschutzes gegenüber dem 230 V Wechselspannungsnetz in ein Kunststoffgehäuse
montiert wird. Das zentrale Element ist der Home Automation Modem Baustein ST7537HS1
von der Firma STMicroelectronics6 . Die Abbildung B.7 zeigt das Power Line Modem.
Abbildung B.7: Power Line Modem
B.7
LIN Modul
Das Universalsteuergerät ist für den Einsatz als Master Knoten am LIN Bus vorgesehen. Der
LIN Transceiver Baustein TJA1020, welcher von der Firma Philips Semiconductors7 stammt, ist
daher an die integrierte asynchrone Schnittstelle des C167 Mikrocontroller mit quartzstabilem
Takt angebunden. Die Abbildung B.8 zeigt das Modul.
6
7
http://www.st.com
http://www.semiconductors.philips.com/
112
ANHANG B. UNIVERSALSTEUERGERÄT
Abbildung B.8: LIN Modul
B.8 Bluetooth Modul
Das Bluetooth Modul ist so konzipiert, dass es entweder mit dem Universalsteuergerät genutzt
werden kann oder alternativ auch unabhängig davon an einem beliebigen Gerät mit RS232
Schnittstelle, z. B. einem PC, betrieben werden kann. Die Bluetooth Baugruppe auf dem Modul
stammt von der Firma Taiyo Yuden Co., Ltd8 . Die Abbildung B.9 zeigt das Modul.
Abbildung B.9: Bluetooth Modul mit Bluetooth Baugruppe (rechts)
8
http://www.yuden.co.jp/bt/
B.9. ETHERNET MODUL
B.9
113
Ethernet Modul
Der Ethernet Adapter stammt von der Firma SYS TEC electronic GmbH9 . Er bietet eine
10BASE2 Schnittstelle zum Anschluss an ein Koxialkabel und eine 10BASE-T Schnittstelle zum Anschluss an ein Kabel mit verdrillten Paaren [IEE02]. Auf dem Adapter kommt ein
Ethernet Controller NET91C96 der Firma SMSC (Standard Microsystems Corporation)10 zum
Einsatz.
Zur Verwendung mit dem Universalsteuergerät musste lediglich eine Trägerplatine zur elektrischen und mechanischen Anpassung entwickelt werden. Die Abbildung B.10 zeigt das Modul.
Abbildung B.10: Ethernet Modul mit Ethernet Adapter (rechts)
9
10
http://www.systec-electronic.com/
http://www.smsc.com/
114
B.10
ANHANG B. UNIVERSALSTEUERGERÄT
MiniMMI Modul
Das MiniMMI Modul ist in der Größe einer halben Europlatine ausgeführt. Es ist in den Modulstapel des Universalsteuergeräts integrierbar oder kann abgesetzt davon betrieben werden. Ein
PIC16 Mikrocontroller dient als I2 C-Slave, zur Ansteuerung des alphanumerischen Displays
und zur Abfrage der Tastaturmatrix. Die Abbildung B.11 zeigt die fertig aufgebaute Platine.
Abbildung B.11: MiniMMI Modul
B.11. COMPLEX DEVICE
B.11
115
Complex Device
Ein Complex Device (CoD) ist eine Art Slave Knoten in EHS Netzwerken. Die EHS Spezifikation versteht unter einem CoD Endgeräte wie Sensoren oder Aktoren, die ihre Dienste über
das Netzwerk anderen Knoten in Form von Informationen oder Leistungen selbstständig zur
Verfügung stellen.
Das hier entwickelte CoD wurde aus Platzgründen auf zwei aufeinandergesteckte Platinen aufgeteilt. Es kann außerdem noch mit dem MiniMMI aus Kapitel B.10 ergänzt werden.
Die Basisplatine (Abbildung B.12) im Euro-Format beherbegt alle Funktionsgruppen, die mit
dem 230 V Wechselspannungsbereich in Verbindung stehen. Hier ist die Spannungsversorgung,
Nulldurchgangserkennung, 2 Dimmerausgänge und das Power Line Modem untergebracht. Das
Power Line Modem ist schaltungstechnisch baugleich mit der Modem Platine in Abbildung B.7.
Für den Berührungsschutz existiert eine Plexiglas-Abdeckung.
Abbildung B.12: Complex Device – Leistungsteil und Modem
Auf der Prozessorplatine (Abbildung B.13) im halben Euro-Format sind zwei PIC16 Mikrocontroller untergebracht. Einer davon dient als Hauptprozessor und der andere als Coprozessor,
der wiederum die Aufgaben der Schicht 2 bei der Power Line Kommunikation übernimmt. Außerdem stehen hier Anschlüsse für 4 digitale Ein-/Ausgänge, 5 analoge Eingänge und eine I2 C
Schnittstelle zur Verfügung.
116
ANHANG B. UNIVERSALSTEUERGERÄT
Abbildung B.13: Complex Device – Prozessorplatine
B.12. LIN SLAVE KNOTEN
B.12
117
LIN Slave Knoten
Der LIN Slave Knoten beinhaltet einen 5 V Spannungsregler für die elektronischen Komponenten und einen PIC16 Mikrocontroller zum Einlesen von 10 analogen Eingängen und zur
Ansteuerung von 8 niederohmigen Leistungsschaltern, zwei davon mit Pulsweitenmodulation.
Als Kontroll- und Überwachungsfunktionen stehen die Erfassung von zwei Temperaturen sowie
der Ströme und des Zustands der Leistungsschalter zur Verfügung. Abbildung B.14 zeigt das
Modul.
Abbildung B.14: LIN Slave Knoten – Oberseite (links), Unterseite (rechts)
118
ANHANG B. UNIVERSALSTEUERGERÄT
Abbildungsverzeichnis
2.1
Netzhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1
Fahrzeug Netzarchitektur – Funktionaler Aspekt . . . . . . . . . . . . . . . . .
15
3.2
Computer Aided Manufacturing Modell . . . . . . . . . . . . . . . . . . . . .
17
3.3
Anpassungsschicht mit API als einheitliche Schnittstelle . . . . . . . . . . . .
18
3.4
Protokollfamilie (rechts) eingeordnet in das OSI-Modell (links) . . . . . . . . .
19
3.5
Heterogene Netze als Subnetze und durch Router verbunden . . . . . . . . . .
20
4.1
MIP Datagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
LIN Datenrahmen [LIN03] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.3
Verwendung des Protected Identifier . . . . . . . . . . . . . . . . . . . . . . .
30
4.4
LIN Data (unconditional frame, sporadic frame) . . . . . . . . . . . . . . . . .
31
4.5
LIN Data (event-triggered frame) . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.6
CAN Extended Datenrahmen [BOS91] . . . . . . . . . . . . . . . . . . . . . .
33
4.7
CAN Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.8
CAN Data Length Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.9
CAN Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.10 BNEP over L2CAP Datenrahmen [SIG04a] . . . . . . . . . . . . . . . . . . .
37
4.11 MARP-BT Datagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.12 Format für ein MIP Datagramm per BNEP over L2CAP . . . . . . . . . . . . .
39
4.13 Write Request for Data Block (WRDB) Datenrahmen [IEE95] . . . . . . . . .
41
4.14 Global Asynchronous Stream Packet (GASP) Datenrahmen [IEE98] . . . . . .
42
4.15 MARP-1394 Datagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.16 Format für ein MIP Datagramm per IEEE 1394 . . . . . . . . . . . . . . . . .
46
119
120
ABBILDUNGSVERZEICHNIS
4.17 MICMP Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.18 Data bei Echo Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.19 Data bei Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.20 MUDP Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.21 MTCP Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.22 Steuerbits im Feld Control . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.23 FSM einer MTCP Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.24 Öffnen einer MTCP Verbindung . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.25 Bidirektionales Senden und Empfangen . . . . . . . . . . . . . . . . . . . . .
58
4.26 Unerwartete Segmentreihenfolge . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.27 Beenden einer MTCP Verbindung . . . . . . . . . . . . . . . . . . . . . . . .
59
4.28 Eine MTCP Transaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.29 MOSPF Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.30 MOSPF Hello Datenpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.31 Link State Advertisement (LSA) Datenpaket . . . . . . . . . . . . . . . . . . .
65
4.32 MOSPF Database Description (DD) Datenpaket . . . . . . . . . . . . . . . . .
66
4.33 MOSPF DD Datenpaket: Steuerbits im Feld Options . . . . . . . . . . . . . .
67
4.34 MOSPF Link State Request Datenpaket . . . . . . . . . . . . . . . . . . . . .
67
4.35 MOSPF Link State Update Datenpaket . . . . . . . . . . . . . . . . . . . . . .
68
4.36 MOSPF Link State Acknowledgement Datenpaket . . . . . . . . . . . . . . .
69
4.37 Austausch der Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.38 Die entstandene hierarchische Protokollfamilie . . . . . . . . . . . . . . . . .
71
4.39 Effektivität bei 1 bis 12 Nutzdatenbyte . . . . . . . . . . . . . . . . . . . . . .
74
4.40 Effektivität bei 1 bis 255 Nutzdatenbyte . . . . . . . . . . . . . . . . . . . . .
75
5.1
Aufbau des Warenbuchungssystems . . . . . . . . . . . . . . . . . . . . . . .
79
5.2
Einordnung des Warenbuchungssystems in das OSI-Modell . . . . . . . . . . .
80
5.3
Testaufbau 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.4
Testaufbau 1 – Ausschnitt aus dem Protokoll von Router 01.01 . . . . . . . . .
82
5.5
Testaufbau 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.6
Testaufbau 2 – Übersicht der benachbarten Router . . . . . . . . . . . . . . . .
83
ABBILDUNGSVERZEICHNIS
121
5.7
Testaufbau 2 – Erfassen der angeschlossenen Subnetze und der Feldbustypen .
83
5.8
Testaufbau 2 – Verteilen der Topologie-Informationen . . . . . . . . . . . . . .
84
5.9
Einordnung der Gateway Applikation in das OSI-Modell . . . . . . . . . . . .
85
5.10 Paket für die Namen- und Adressauflösung . . . . . . . . . . . . . . . . . . .
86
B.1 Basis Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.2 Schema des IEEE 1394 Moduls . . . . . . . . . . . . . . . . . . . . . . . . . 108
B.3 IEEE 1394-Modul mit Prozessor Modul (links mitte) und IEEE 1394a Physical
Layer Modul (links unten) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
B.4 IEEE 1394b Physical Layer Module . . . . . . . . . . . . . . . . . . . . . . . 109
B.5 E/A-Aufsatz-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
B.6 Power Line Adapterplatine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.7 Power Line Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.8 LIN Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.9 Bluetooth Modul mit Bluetooth Baugruppe (rechts) . . . . . . . . . . . . . . . 112
B.10 Ethernet Modul mit Ethernet Adapter (rechts) . . . . . . . . . . . . . . . . . . 113
B.11 MiniMMI Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.12 Complex Device – Leistungsteil und Modem . . . . . . . . . . . . . . . . . . 115
B.13 Complex Device – Prozessorplatine . . . . . . . . . . . . . . . . . . . . . . . 116
B.14 LIN Slave Knoten – Oberseite (links), Unterseite (rechts) . . . . . . . . . . . . 117
122
ABBILDUNGSVERZEICHNIS
Tabellenverzeichnis
4.1
MIP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2
LIN Fragment Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3
CAN Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.4
Fragment Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5
MARP-BT OpCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.6
MARP-1394 OpCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.7
MICMP Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.8
Code bei Echo Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.9
Code bei Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.10 Code bei Destination Unreachable . . . . . . . . . . . . . . . . . . . . . . . .
50
4.11 Code bei Parameter Problem . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.12 Bedeutung der Signale in Control . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.13 MOSPF Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.14 Beispieldefinition: MOSPF Network Type . . . . . . . . . . . . . . . . . . . .
66
4.15 MOSPF DD Datenpaket: Bedeutung der Signale in Options . . . . . . . . . . .
67
4.16 Beispieldefinition: Priorität der Feldbusse abhängig vom ToS Wert . . . . . . .
70
4.17 Für das Beispiel: Leitungskosten der Feldbustypen abhängig vom ToS Wert . .
70
4.18 Größe der Protokollheader im Vergleich . . . . . . . . . . . . . . . . . . . . .
73
4.19 Transferdauer und Latenzzeiten im Vergleich . . . . . . . . . . . . . . . . . .
75
5.1
Type für die Namen- und Adressauflösung . . . . . . . . . . . . . . . . . . . .
86
5.2
Code bei Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
123
124
TABELLENVERZEICHNIS
Literaturverzeichnis
[And99]
A NDERSON, Don: Firewire System Architecture. Addison Wesley Longman Inc.,
Reading, Massachusetts, USA, 1999
[BLe96]
B ERNERS -L EE, T. ; ET AL .: RFC 1945: Hypertext Transfer Protocol – HTTP/1.0.
IETF, The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc1945.txt,
May 1996
[BOS91]
CAN Spezifikation Version
http://www.bosch.de/, 1991
[Bra92]
B RADEN, R.: RFC 1379: Extending TCP for Transactions – Concepts. IETF,
The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc1379.txt, November 1992
[Bra94]
B RADEN, R.: RFC 1644: T/TCP – TCP Extensions for Transactions. IETF, The
Internet Engineering Task Force, http://www.ietf.org/rfc/rfc1644.txt, July 1994
[CF01]
C ACH, Petr ; F IEDLER, Petr: INTERNET-DRAFT IP over CAN (draft-cafi-can-ip00.txt). IETF, The Internet Engineering Task Force, http://www.ietf.org/, March
2001. – Document expired September 2001
[CiA02]
CiA DS 301 V4.02: CANopen application layer and communication profile. CiA
CAN in Automation, Am Weichselgarten 26, 91058 Erlangen, http://www.cancia.org/, Februar 2002
[Com02]
C OMER, Douglas E.: Computernetzwerke und Internets. 3., überarbeitete Auflage.
Pearson Studium, München, 2002. – ISBN 3–8273–7023–X
[DIN91]
DIN 19245: PROFIBUS. DIN Deutsches Institut für Normung e.V., 10772 Berlin,
http://www.din.de/, April 1991. – Zurückgezogen: 1997, Ersetzt durch: EN 50170
Teil 2
[DIN93]
DIN 19258: INTERBUS-S. DIN Deutsches Institut für Normung e.V., 10772 Berlin, http://www.din.de/, 1993. – Zurückgezogen, Ersetzt durch: EN 50254
[DKS00]
D IETRICH, Dietmar ; K ASTNER, Wolfgang ; S AUTER, Thilo (Hrsg.): EIB: Gebäudebussystem. Hüthig Verlag, Heidelberg, 2000. – ISBN 3–7785–2795–9
[EHS96]
Home Systems Specification 1.3. EHSA European Home Systems Association,
Brüssel, Belgien, http://www.ehsa.com/, 1996
2.0.
125
Robert
Bosch
GmbH,
Stuttgart,
126
LITERATURVERZEICHNIS
[EIA99]
EIA 709.1: Control Network Protocol Specification. EIA Electronic Industries
Alliance, Arlington, USA, http://www.eia.org/, 1999
[EIB99]
EIBA Handbook Series, Release 3.0. EIBA European Installation Bus Association,
Brüssel, Belgien, http://www.eiba.com/, 1999
[EN96]
EN 50170 Volume 2: PROFIBUS – General purpose field communication system. CENELEC European Committee for Electrotechnical Standardization, rue
de Strassart 35 B, Brussels, Belgium, http://www.cenelec.org/, Dezember 1996.
– Zurückgezogen: 2005, Ersetzt durch: IEC 61158 Teile 2 bis 6 und IEC 61784
Teil 1
[EN97]
EN 50254: High efficiency communication subsystem for small data packages.
CENELEC European Committee for Electrotechnical Standardization, rue de
Strassart 35 B, Brussels, Belgium, http://www.cenelec.org/, 1997. – Zurückgezogen: 2005, Ersetzt durch: IEC 61158 Teile 2 bis 6 und IEC 61784 Teil 1
[EN99]
EN 50295: Niederspannungsschaltgeräte - Steuerungs- und Geräte-InterfaceSysteme - Aktuator Sensor Interface (AS-i). CENELEC European Committee
for Electrotechnical Standardization, rue de Strassart 35 B, Brussels, Belgium,
http://www.cenelec.org/, 1999
[EN02]
EN 50325-4: Industrial communications subsystem based on ISO 11898 (CAN)
for controller-device interfaces – Part 4: CANopen. CENELEC European Committee for Electrotechnical Standardization, rue de Strassart 35 B, Brussels, Belgium, http://www.cenelec.org/, 2002
[EN03]
EN 50090: Home and Building Electronic Systems (HBES). CENELEC European
Committee for Electrotechnical Standardization, rue de Strassart 35 B, Brussels,
Belgium, http://www.cenelec.org/, 2003
[ENV98]
ENV 13154-2: Data Communication for HVAC application field net – Part 2:
Protocols. CEN Comité Européen de Normalisation, Brüssel, Belgien, Juni 1998
[Fe99]
F IELDING, R. ; ET AL .: RFC 2616: Hypertext Transfer Protocol – HTTP/1.1.
IETF, The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2616.txt,
June 1999
[Fel02]
F ELSER, Max (Hrsg.): Vom Feldbus-Krieg zur Feldbus-Koexistenz. Bulletin des
Schweizerischen Elektrotechnischen Vereins (SEV), Fehraltorf, April 2002 . –
Ausgabe 9/2002, S. 24-26, http://felser.ch/download/FE-TR-0202.pdf
[Fle05]
FlexRay Communications System Protocol Specification Version 2.1. FlexRay
Consortium, http://www.flexray.com/, Mai 2005
[I2C00]
The I 2 C-Bus Specification, Version 2.1.
Philips
http://www.semiconductors.philips.com/, January 2000
Semiconductors,
LITERATURVERZEICHNIS
127
[IEC00]
IEC 62026-2: Low-voltage switchgear and controlgear – Controller-device interfaces (CDIs) – Part 2: Actuator sensor interface (AS-i). IEC International
Electrotechnical Commission, 1, rue de Varembé, 1211 Geneva 20, Switzerland,
http://www.iec.ch/, Juli 2000
[IEC02]
IEC 61491: Electrical equipment of industrial machines – Serial data link for
real-time communication between controls and drives. IEC International Electrotechnical Commission, 1, rue de Varembé, 1211 Geneva 20, Switzerland,
http://www.iec.ch/, Oktober 2002
[IEC03a]
IEC 61158: Digital data communications for measurement and control – Fieldbus
for use in industrial control systems. IEC International Electrotechnical Commission, 1, rue de Varembé, 1211 Geneva 20, Switzerland, http://www.iec.ch/, 2003
[IEC03b]
IEC 61784: Digital data communications for measurement and control. IEC International Electrotechnical Commission, 1, rue de Varembé, 1211 Geneva 20,
Switzerland, http://www.iec.ch/, Mai 2003
[IEE91]
IEEE P1212: Draft Standard for a Control and Status Registers (CSR) Architecture for Microcomputer Buses. The Institute of Electrical And Electronics
Engineers, Inc., IEEE Standards Department, Piscataway, NJ 08855-1331, USA,
http://www.ieee.org/, 1991
[IEE95]
IEEE P1394: Standard for a High Performance Serial Bus. The Institute of Electrical And Electronics Engineers, Inc., IEEE Standards Department, Piscataway,
NJ 08855-1331, USA, http://www.ieee.org/, 1995
[IEE98]
IEEE P1394a: Standard for a High Performance Serial Bus. The Institute of Electrical And Electronics Engineers, Inc., IEEE Standards Department, Piscataway,
NJ 08855-1331, USA, http://www.ieee.org/, 1998
[IEE01a]
IEEE P1394.1: Standard for High Performance Serial Bus Bridges (Draft 1.01).
The Institute of Electrical And Electronics Engineers, Inc., IEEE Standards Department, Piscataway, NJ 08855-1331, USA, http://www.ieee.org/, 2001
[IEE01b]
IEEE P1394b: Standard for a High Performance Serial Bus. The Institute of Electrical And Electronics Engineers, Inc., IEEE Standards Department, Piscataway,
NJ 08855-1331, USA, http://www.ieee.org/, 2001
[IEE02]
IEEE 802.3: Standard for Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks –
Specific requirements – Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications. The Institute
of Electrical And Electronics Engineers, Inc., IEEE Standards Department, Piscataway, NJ 08855-1331, USA, http://www.ieee.org/, March 2002
[ISO89]
ISO 9141: Road vehicles – Diagnostic systems – Requirements for interchange of
digital information. ISO International Organization for Standardization, 1, rue de
Varembé, 1211 Geneva 20, Switzerland, http://www.iso.org/, 1989
128
LITERATURVERZEICHNIS
[ISO94]
ISO/IEC 13213: Information technology – Microprocessor systems – Control and
Status Registers (CSR) Architecture for microcomputer buses. ISO International
Organization for Standardization, 1, rue de Varembé, 1211 Geneva 20, Switzerland, http://www.iso.org/, 1994
[ISO95]
ISO/DIS 14230: Road vehicles – Diagnostic systems – Keyword protocol 2000.
ISO International Organization for Standardization, 1, rue de Varembé, 1211 Geneva 20, Switzerland, http://www.iso.org/, 1995
[ISO02]
ISO/IEC 10589: Information technology – Telecommunications and information
exchange between systems – Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the
protocol for providing the connectionless-mode network service (ISO 8473). ISO
International Organization for Standardization, 1, rue de Varembé, 1211 Geneva
20, Switzerland, http://www.iso.org/, 2002
[ISO03]
ISO 11898: Road vehicles – Controller area network (CAN). ISO International
Organization for Standardization, 1, rue de Varembé, 1211 Geneva 20, Switzerland, http://www.iso.org/, 2003
[ISO04a]
ISO 11898-4: Road vehicles – Controller area network (CAN) – Part 4: Timetriggered communication. ISO International Organization for Standardization, 1,
rue de Varembé, 1211 Geneva 20, Switzerland, http://www.iso.org/, 2004
[ISO04b]
ISO 15765-2: Road vehicles – Diagnostics on Controller Area Networks (CAN) –
Part 2: Network layer services. ISO International Organization for Standardization, 1, rue de Varembé, 1211 Geneva 20, Switzerland, http://www.iso.org/, 2004
[Joh99]
J OHANSSON, P.: RFC 2734: IPv4 over IEEE 1394. IETF, The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2734.txt, December 1999
[KJBMS00] K UNG, A. ; J EAN -BART, B. ; M ARBACH, O. ; S AUVAGE, S.: The EHS European
Home Systems Network. First Edition / Second Printing. 25 rue du Général Foy,
75008 Paris, France, http://www.trialog.com/ : Trialog, November 1995 / February
2000
[KM99]
K RIESEL, Werner R. ; M ADELUNG, Otto W. (Hrsg.): AS-Interface: Das AktuatorSensor-Interface für die Automation. 2., überarbeitete und erweiterte Auflage.
Carl Hanser Verlag, München, Wien, 1999. – ISBN 3–446–21064–4
[KNX00]
Konnex Specification 1.0.
KNX Konnex Association, Brüssel, Belgien,
http://www.konnex.org/, 2000
[Law94]
L AWRENZ, Wolfhard (Hrsg.): CAN Controller Area Network – Grundlagen und
Praxis. Hüthig Verlag, Heidelberg, 1994. – ISBN 3–7785–2263–7
[LIN02]
LIN – Local Interconnect Network, LIN Specification Package, Revision 1.3. Audi AG, BMW AG, DaimlerChrysler AG, Motorola Inc., Volcano Communications Technologies AB, Volkswagen AG, Volvo Car Corporation, http://www.linsubbus.org/, Dezember 2002. – Kontakt: H.-Chr. v. d. Wense, Motorola GmbH,
Schatzbogen 7, 81829 München, E-Mail: [email protected]
LITERATURVERZEICHNIS
129
[LIN03]
LIN – Local Interconnect Network, LIN Specification Package, Revision 2.0.
LIN Consortium, http://www.lin-subbus.org/, September 2003. – Kontakt: H.Chr. v. d. Wense, Motorola GmbH, Schatzbogen 7, 81829 München, E-Mail:
[email protected]
[Mal98]
M ALKIN, G.: RFC 2453: RIP Version 2. IETF, The Internet Engineering Task
Force, http://www.ietf.org/rfc/rfc2328.txt, November 1998
[Moc87a]
M OCKAPETRIS, P.: RFC 1034: Domain Names – Concepts and Facilities. IETF,
The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc1034.txt, November 1987
[Moc87b]
M OCKAPETRIS, P.:
RFC 1035: Domain Names – Implementation and Specification.
IETF, The Internet Engineering Task Force,
http://www.ietf.org/rfc/rfc1035.txt, November 1987
[MOS05]
MOST – Media Oriented Systems Transport, MOST Specification, Rev 2.4. MOST
Cooperation, Bannwaldallee 48, 76185 Karlsruhe, http://www.mostnet.de/, Mai
2005
[Moy98]
M OY, J.: RFC 2328: OSPF Version 2. IETF, The Internet Engineering Task Force,
http://www.ietf.org/rfc/rfc2328.txt, April 1998
[OSE00]
OSEK COM: Communication Specification Version 2.2.2. OSEK/VDX Offene
Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug / Vehicle
Distributed eXecutive, http://www.osek-vdx.org/, Dezember 2000
[PBG99]
P ELLER, M. ; B ERWANGER, J. ; G RIESBACH, R.: Byteflight Specification Draft
Version 0.5. Bayerische Motoren Werke Aktiengesellschaft (BMW AG), München, http://www.byteflight.de, 1999
[PCA00]
Data Sheet PCA82C250 – CAN controller interface. Philips Semiconductors,
5600 Eindhoven, The Netherlands, http://www.semiconductors.philips.com, Januar 2000. – Document order number: 9397 750 06609
[Plu82]
P LUMMER, David C.: RFC 826: An Ethernet Address Resolution Protocol – or
– Converting Network Protocol Addresses to 48 bit Ethernet Address for Transmission on Ethernet Hardware. IETF, The Internet Engineering Task Force,
http://www.ietf.org/rfc/rfc0826.txt, November 1982
[Pop00]
P OPP, Manfred: PROFIBUS-DP/DPV1: Grundlagen, Tipps und Tricks für Anwender. 2., überarbeitete Auflage. Hüthig Verlag, Heidelberg, 2000. – ISBN
3–7785–2781–9
[Pos80]
P OSTEL, J.: RFC 768: User Datagram Protocol. IETF, The Internet Engineering
Task Force, http://www.ietf.org/rfc/rfc0768.txt, August 1980
[Pos81a]
P OSTEL, J.: RFC 791: Internet Protocol. IETF, The Internet Engineering Task
Force, http://www.ietf.org/rfc/rfc0791.txt, September 1981
130
LITERATURVERZEICHNIS
[Pos81b]
P OSTEL, J.: RFC 792: Internet Control Message Protocol. IETF, The Internet
Engineering Task Force, http://www.ietf.org/rfc/rfc0792.txt, September 1981
[Pos81c]
P OSTEL, J.: RFC 793: Transmission Control Protocol. IETF, The Internet Engineering Task Force, http://www.ietf.org/rfc/rfc0793.txt, September 1981
[RHJ99]
R AGGETT, Dave ; H ORS, Arnaud L. ; JACOBS, Ian: HTML 4.01 Specification.
World Wide Web Consortium (W3C), http://www.w3.org/TR/html401/, December 1999
[RSG04]
R ABEL, Matthias (Hrsg.) ; S CHMEISER, Andreas (Hrsg.) ; G ROSSMANN, Hans
Peter (Hrsg.) ; IEEE Intelligent Vehicles Symposium, 14-17 June 2004, University
of Parma, Parma, Italy (Veranst.): Communication architecture for sensorfusion
systems. 2004 . – S. 363 ff.
[SIG03]
SIG, Bluetooth: Specification of the Bluetooth System V1.2 / Bluetooth SIG,
Inc. Bellevue, Washington; Malmö, Sweden, http://www.bluetooth.org/, November 2003. – Specification
[SIG04a]
SIG, Bluetooth: Bluetooth Network Encapsulation Protocol (BNEP) Specification V1.0 / Bluetooth SIG, Inc. Bellevue, Washington; Malmö, Sweden,
http://www.bluetooth.org/, February 2004. – Protocol Specification
[SIG04b]
SIG, Bluetooth:
Bluetooth Personal Area Networking (PAN) Profile V1.0 / Bluetooth SIG, Inc.
Bellevue, Washington; Malmö, Sweden,
http://www.bluetooth.org/, November 2004. – Profile
[SIG04c]
SIG, Bluetooth: Specification of the Bluetooth System V2.0 + EDR / Bluetooth
SIG, Inc. Bellevue, Washington; Malmö, Sweden, http://www.bluetooth.org/, November 2004. – Specification
[SMR+ 03]
S HELBY, Zach (Hrsg.) ; M AHONEN, P. (Hrsg.) ; R IIHIJARVI, J. (Hrsg.) ; R AIVIO,
O. (Hrsg.) ; H UUSKONEN, Pertti (Hrsg.) ; ICC ’03. IEEE International Conference
on Communications, 11-15 May 2003 (Veranst.): NanoIP: The Zen of Embedded
Networking. 2003 . – ISBN 0–7803–7802–4. – Volume 2, S. 1218-1222
[Tan98]
TANENBAUM, Andrew S.: Computernetzwerke. 3., revidierte Auflage. Prentice
Hall, München, 1998. – ISBN 3–8272–9568–8
[TIA97]
ANSI/TIA-232-F-1997: Interface Between Data Terminal Equipment and Data
Circuit-Terminating Equipment Employing Serial Binary Data Interchange. TIA
Telecommunications Industry Association, http://www.tiaonline.org/, September
1997
[TIA98]
ANSI/TIA/EIA-485-A-98: Electrical Characteristics of Generators and Receivers
for Use in Balanced Digital Multipoint Systems. TIA Telecommunications Industry Association, http://www.tiaonline.org/, March 1998
[TTP99]
Specification of the TTP/C Protocol, Version 0.5. TTTech Computertechnik
GmbH, Schönbrunner Str. 7, 1040 Wien, Austria, http://www.tttech.com/, Juli
1999
LITERATURVERZEICHNIS
131
[TTP03]
Time-Triggered Protocol TTP/C, High-Level Specification Document, Protocol Version 1.1.
TTA-Group, Schönbrunner Str. 7, 1040 Wien, Austria,
http://www.ttagroup.org/, November 2003
[Zel01]
Z ELTWANGER, Holger (Hrsg.): CANopen. VDE Verlag GmbH, Berlin und Offenbach, 2001. – ISBN 3–8007–2448–0
132
LITERATURVERZEICHNIS
Veröffentlichungen
Konferenzbeiträge
R ABEL, Matthias ; S CHMEISER, Andreas ; G ROSSMANN, Hans Peter
IEEE VTS 53rd Vehicular Technology Conference, Spring 2001, 6-9 May 2001, Rhodes, Greece (Veranst.): Integrating IEEE 1394 as Infotainment Backbone into the Automotive Environment. 2001. – ISBN 0–7803–6728–6. – Proceedings Volume 3, S. 2026-2031
S CHMEISER, Andreas ; R ABEL, Matthias ; G ROSSMANN, Hans Peter
SPS/IPC/DRIVES 2001, 27.-29.11.2001, Nürnberg (Veranst.): Einsatzmöglichkeiten des IEEE
1394 - Serial Bus in der Automatisierungstechnik. Hüthig Verlag, Heidelberg, November 2001.
– ISBN 3–7785–2833–5. – S. 270-278
R ABEL, Matthias ; S CHMEISER, Andreas ; G ROSSMANN, Hans Peter
ECT 2002 Electronics & Communications in Traffic Systems, 04.-06.06.2002, Augsburg (Veranst.): Service Layer zur Kommunikation zwischen MMIs und Steuergeräten des Multimedia
Systems. Hüthig Verlag, Heidelberg, Juni 2002. – ISBN 3–7785–2885–8. – S. 214-224
R ABEL, Matthias ; S CHMEISER, Andreas ; G ROSSMANN, Hans Peter
IEEE Intelligent Vehicles Symposium, 14-17 June 2004, University of Parma, Parma, Italy
(Veranst.): Communication architecture for sensorfusion systems. 2004. – S. 363 ff.
R ABEL, Matthias ; S CHMEISER, Andreas ; G ROSSMANN, Hans Peter
8th International IEEE Conference on Intelligent Transportation Systems, 13-16 September
2005, Vienna, Austria (Veranst.): Ad-hoc in-car networking concept. 2005
W EGHORN, Hans ; S CHMEISER, Andreas ; G ROSSMANN, Hans Peter ; P IRKER, Michael ;
H AUBOLD, Søren
IADIS (International Association for Development of the Information Society) International
Conference WWW/Internet 2005, 19-22 October 2005, Lisbon, Portugal (Veranst.): ISA4G –
Integrated Student Access ID Card of Fourth Generation. Editors: Pedro Isaías and Miguel
Baptista Nunes, October 2005. – ISBN 972–8924–02–X. – Proceedings Volume 2, S. 333-337
W EGHORN, Hans ; R ATIH, Cahya Kusuma ; G ROSSMANN, Hans Peter ; H ELLWIG, Dieter ;
S CHMEISER, Andreas ; H UTSCHENREITER, Heiko
IADIS (International Association for Development of the Information Society) International
Conference e-Society 2006, 13-16 July 2006, Dublin, Ireland (Veranst.): Mobile Ticket Control
System with RFID Cards for Adminstering Annual Secret Elections.
133
134
Vorträge
S CHMEISER, Andreas
Universal Control-API for a general distributed gateway concept
DAAD Workshop an der Universität Kairo, Ägypten
Oktober 2003
S CHMEISER, Andreas
Network and Transport Layer Protocol Family for Control Applications in a Heterogeneous
Network Environment
Workshop an der Universität Palermo, Sizilien
April 2005
Nichtöffentliche Dokumente
R ABEL, Matthias ; S CHMEISER, Andreas ; H OHMANN, Wolfram ; K URRER, Dietmar
Pink Floyd Study: Comparison and Prospects of Interoperability between Serial Optical
MultiMedia Bus Systems for Automotive Applications, MOST and IEEE 1394
Studie im Auftrag der AM3 AG, Fürth
April / Mai 2000
R ABEL, Matthias ; S CHMEISER, Andreas ; H ÖRMANN, Yvonne
Konzept eines IEEE 1394 basierten Kommunikations-Systems für Fahrzeuge
Studie für die DaimlerChrysler AG, Sindelfingen
Oktober 2000 – Dezember 2003