Modellierung von speziellen Komponenten des FlexRay-Protokolls

Diplomarbeit von Jirko Zessack

Einleitung:

Diese Arbeit beschäftigt sich auf den folgenden Seiten mit dem zukünftigen Übertragungsstandard im automobilen Bereich, mit FlexRay. Dabei liegen die Schwerpunkte dieser Arbeit im Übertragungsprotokoll und den einzelnen Protokollfunktionen von FlexRay. Die technischen Spezifikationen und Leistungsdaten, sowie die Hauptanwendungsgebiete von FlexRay werden in dieser Arbeit nur sehr kurz und oberflächlich im Kapitel 2 angesprochen. Wer noch keine Vorkenntnisse zu FlexRay besitzt, sollte sich als Einführung in die Thematik, die Studienarbeit von Stefan Aschenbach [6] ansehen. Für das Verständnis der Kernpunkte dieser Arbeit ist es jedoch nicht erforderlich, sich in andere Literatur einzuarbeiten. Falls doch, dann wird an den entsprechenden Stellen explizit auf die externen Literaturstellen verwiesen.

Als Grundlage für diese Arbeit diente hauptsächlich die „FlexRay Protocol Specification“ in Version 2.1 da es zu FlexRay noch immer sehr wenige Publikationen gibt. Die meisten Veröffentlichungen zu FlexRay sind sehr produktspezifisch und weichen häufig von den originalen Vorgaben ab. Dennoch wurden für diese Arbeit auch Veröffentlichungen anderer Personen verwendet, wobei die Informationen aus diesen Dokumenten sehr genau überprüft wurden, um eine Vermischung von Standards und Eigenentwicklungen zu vermeiden.

Die Kernaufgaben dieser Diplomarbeit liegen beim Cluster – Startup – Mechanismus im Kapitel 3, bei der Synchronisation der einzelnen Nodes im FlexRay im Kapitel 4, sowie bei der Bestimmung der globalen und lokalen Parameter, um eine reibungslose Kommunikation zu gewährleisten, im Kapitel 6. Gestützt werden die Analysen und Formeln dieser Arbeit durch ein im Rahmen dieser Diplomarbeit entwickeltes Modell, welches die Kommunikation bei FlexRay darstellt. Dieses Modell wird im Kapitel 5 und im Kapitel 9 detailliert erklärt. Zum einfacheren Verständnis der Modelle gibt es im Kapitel 9 einen Einschub zu den Grundlagen der „Specification and Description Language“ (SDL) sowie zu den Grundlagen von MLD im Kapitel 9.

Ziel dieser Arbeit ist es, dem Leser Schritt für Schritt und sehr detailliert die einzelnen Protokollkomponenten und deren Funktionsweisen zu erläutern. Dabei werden die abstrakten Komponenten zuerst erläutert und dann folgen die Komponenten der unteren Schichten, wie der Netzwerkschicht. Weiterhin werden die einzelnen Schritte des Startup – Mechanismus detailliert erläutert und auf die Besonderheiten der Synchronisation eingegangen. Denn genau hier liegt der sehr große Vorteil von FlexRay gegenüber anderen Übertragungsmechanismen.

Abschließend gibt es noch einen Hinweis zu Fachbegriffen, Fremdwörtern und Abkürzungen. In dieser Arbeit wird, sofern möglich, die deutsche Sprache verwendet.

Jedoch ist es nicht immer möglich, alle Begriffe, Fachwörter und Eigennamen sinnvoll aus dem Englischen in das Deutsche zu übersetzen. Aus diesem Grund, und auch um eine Vermischung von deutschen und englischen Begriffen und daraus resultierenden Inkonsistenzen zu vermeiden, werden alle Eigennamen für Module, Protokollkomponenten und Variablen grundsätzlich in Englisch verwendet, so wie es die Spezifikation von FlexRay vorsieht. Zu Beginn jedes entsprechenden Abschnitts wird aber, sofern möglich, eine entsprechende Übersetzung angeben. Der Umgang mit Abkürzungen erfolgt im Text sehr sparsam. Allerdings werden in Grafiken und Tabellen aus Platzgründen sehr häufig spezifische aber auch nicht standardisierte Abkürzungen verwendet. Die verwendeten Abkürzungen sind tabellarisch im Abkürzungsverzeichnis auf Seite XV zu finden. Dabei wurde ebenfalls darauf geachtet, dass die Abkürzungen zur offiziellen FlexRay Protokoll Spezifikation konform sind.

Inhaltsverzeichnis:

Inhaltsverzeichnis:

Textprobe:

Kapitel 3.1, Komponentenüberblick und ISO/OSI Referenzmodell: Ein Bus besteht gewöhnlich aus einzelnen Knoten, die über eine bestimmte Leitung verbunden sind. Bei FlexRay kann diese Leitung entweder elektrisch oder optisch realisiert werden. Die an den Bus angeschlossenen Komponenten benötigen daher ein entsprechendes Interface, welches entweder für eine optische oder für eine elektrische Leitung konzipiert wurde.

Viel wichtiger und viel komplexer als die eigentliche Hardwareschnittstelle ist die Protokollschnittstelle, die hinter einem Buskommunikationsstandard steht.

Diese Protokollfunktionen sind in den einzelnen Knoten, im folgenden auch als Nodes bezeichnet, realisiert. Dabei kann die Realisierung direkt als Hardware erfolgen oder als eine Software im Speicher eines Busknotens. Wie das Protokoll realisiert wird, bleibt hierbei jedoch den einzelnen Komponentenherstellern überlassen. Wichtig ist, dass die Funktionalität des FlexRay – Protokolls entsprechend der FlexRay – Spezifikation implementiert wird. Wenn die Realisierung dem Standard entspricht, sollten bei der Verwendung der Buskomponenten nur noch wenige Probleme auftreten.

Die Entwicklung und Realisierung eines Protokolls geschieht nach einem festen Standardschema, welches von der ISO (International Organisation for Standardization) seit 1979 entwickelt und standardisiert wurde. Es handelt sich dabei um das OSI – Referenzmodell (Open Systems Interconnection Reference Model).

Dieses Modell schreibt eine 7 Schichten Architektur vor, bei der übereinander angeordnete Schichten jeweils nur mit Ihren direkten Nachbarn kommunizieren sollen und bestimmte Dienste für Ihre Nachbarn erbringen können. Bei der Realisierung eines Protokolls für Busse der Feldebene ist es außerdem nicht erforderlich, dass alle der 7 Schichten im Protokollstack implementiert sind.

Grundsätzlich werden die Schichten 1 und 2 für die Kommunikation benötigt, alle anderen Schichten dienen vorrangig dem Routing, der protokollgestützten Fehler und Reihenfolgeerkennung sowie der Vorbereitung der Daten von und für spezifische Anwendungen. FlexRay als Feldbus der gehobenen Leistungsebene basiert auf den erforderlichen Schichten 1 und 2, und unterstützt zusätzlich die FlexRay verwendenden Anwendungen durch eine angedeutete Schicht 7 – Funktionalität. Die Schichten 3, 4 ,5 und 6 sind nicht vorhanden.