Protokollfamilie zur universellen Steuerdatenkommunikation in heterogenen Netzwerkumgebungen

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 wird eine Anzahl an Byte bezeichnet. Mit m 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