Eine effiziente IPv6 Implementierung für Steuergeräte

Inhaltverzeichnis

Abkürzungen und Begriffe

1 Einleitung
1.1 Motivation
1.2 Ziele dieser Masterarbeit
1.3 Kapitelübersicht

2 Grundlagen Automotive-Markt
2.1 Der Automotive-Markt
2.2 Echtzeitbetriebssysteme
2.3 OSEK
2.4 Implementierungssprache OIL
2.4.1 Task-Verwaltung
2.4.2 Kommerzielle OSEK-Distributionen
2.4.3 AUTOSAR
2.5 Architektur
2.5.1 AUTOSAR-Software
2.5.2 Runtime Environment
2.5.3 AUTOSAR-Basic-Software
2.5.4 ECU-Hardware
2.6 Vorgehensmodell
2.7 Steuergeräte in Fahrzeugen

3 Grundlagen Bussysteme
3.1 CAN
3.2 FlexRay
3.3 LIN
3.4 Most
3.5 Ethernet

4 Grundlagen TCP/IP-Protokolle
4.1 OSI-Referenzmodell
4.2 Das TCP/IP-Referenzmodell
4.3 Ethernet
4.4 IPv4
4.5 ICMPv4
4.5.1 ICMPv4-Anfragen
4.6 IPv6
4.6.1 Warum IPv6?
4.6.2 Änderungen gegenüber IPv4
4.6.3 Der IPv6-Header
4.7 ICMPv6
4.7.1 ICMPv6-Anfragen
4.7.2 Neighbor Discovery (ND)
4.8 UDP
4.9 TCP
4.10 Das Netzwerk-API „Berkeley Sockets“
4.10.1 Schnittstellen-Funktionen

5 Anforderungsanalyse
5.1 Randbedingungen
5.1.1 Zweck des Systems
5.1.2 Auftraggeber, Kunden und andere Beteiligte/Betroffene
5.1.3 Nutzer des Produkts
5.1.4 Randbedingungen für das Produkt
5.1.5 Annahmen
5.2 Funktionale Anforderungen
5.2.1 Die Abgrenzung des Systems
5.2.2 Anforderungen an Funktionen und Daten des Systems
5.3 Nichtfunktionale Anforderungen
5.3.1 Performance/Durchsatz/Sicherheit
5.3.2 Operationale Anforderungen
5.3.3 Wartungs- und Portierungsanforderungen
5.3.4 Zugriffsschutzanforderungen
5.3.5 Normen und Richtlinien
5.4 Projektrandbedingungen
5.4.1 Inbetriebnahme und Migration
5.4.2 Benutzerdokumentation
5.4.3 Warteraum

6 Analyse des bestehenden IPv4-Protokoll-Stacks
6.1 Stack-Architektur
6.2 Speicherverwaltung
6.2.1 Aufbau der PBUF-Speicherverwaltung
6.2.2 Schnittstellenfunktionen der Speicherverwaltung
6.3 Message-Verwaltung
6.4 Netzwerk-Schnittstelle
6.5 Protokoll-Stack-Übersicht
6.5.1 Empfangen eines Nutzdatenpaketes
6.5.2 Senden eines Nutzdatenpaketes
6.6 Das Ethernet-Protokoll
6.6.1 Empfang von Ethernet-Frames
6.6.2 Senden von Ethernet-Frames
6.7 Das IPv4-Protokoll
6.7.1 Empfang von IP-Frames
6.7.2 Senden von IP-Frames
6.8 Das UDP-Protokoll
6.8.1 Empfangen von UDP-Paketen
6.8.2 Senden von UDP-Paketen
6.9 Das TCP-Protokoll
6.9.1 Empfangen von TCP-Paketen
6.9.2 Senden von TCP-Paketen
6.10 Die Socket-Schnittstelle

7 Prototypische Implementierung
7.1 Festlegen der Implementierungsreihenfolge
7.1.1 Schritt 1: Zugriffe auf Protokoll-Header durch Makros ersetzen
7.1.2 Schritt 2: Auf IPv6-Echo-Requests antworten
7.1.3 Schritt 3: ICMP-Neighbor-Discovery-Address-Resolution
7.1.4 Schritt 4: UDP-Pakete senden und empfangen
7.1.5 Schritt 5: TCP-Pakete senden und empfangen
7.1.6 Schritt 6: „Stateless-Autoconfiguration“ ermöglichen
7.2 Stack-Architektur für Dual-Stack
7.3 Zugriffe auf Protokoll-Header durch Makros ersetzen
7.4 Auf ein IPv6-Echo-Request antworten
7.4.1 Arbeitsweise von Ping
7.4.2 Beobachtung eines Ping-Befehls in der Praxis
7.4.3 Anpassen der Ethernet-Empfangsfunktion
7.4.4 Anpassen der Ethernet-Sendefunktion
7.4.5 Anpassen der IP-Adressen-Struktur und Hilfsfunktionen
7.4.6 Anlegen der IPv6-Empfangsfunktion
7.4.7 Anlegen der IPv6-Sendefunktion
7.4.8 Die ICMPv6-Empfangsfunktion
7.4.9 Empfangen von Echo-Request-Nachrichten
7.4.10 Empfangen von Echo-Reply-Nachrichten
7.4.11 Empfangen von Neighbor-Solicitation-Nachrichten
7.4.12 Empfangen von Neighbor-Advertisement-Nachrichten
7.4.13 Der Neighbor Cache
7.5 ICMP-Neighbor-Discovery-Address-Resolution implementieren
7.6 UDP-Pakete senden und empfangen
7.6.1 Anpassung der UDP-Funktionen
7.6.2 Anpassung der Socket-Schnittstelle
7.7 TCP-Pakete senden und empfangen
7.7.1 Anpassung der TCP-Funktionen
7.8 „Stateless Autoconfiguration“ implementieren
7.8.1 Generieren einer Link-lokalen IP-Adresse
7.8.2 “Duplicate Address Detection”-Prozess

8 Resümee
8.1 Rückblick
8.2 Unerwartete Schwierigkeiten
8.3 Ergebnisse
8.4 Ausblicke

Anhang A: RFC-Referenz

Anhang B: CD-ROM

Abbildungsverzeichnis

Tabellenverzeichnis

Literaturverzeichnis

Abkürzungen und Begriffe

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Motivation

Die Firma Elektrobit Automotive GmbH bietet einen für das OSEK-Betriebssystem optimierten TCP/IP-Stack für den gängigen IPv4-Standard an. Diese ressourcenschonende und schlanke Implementierung zeichnet sich durch besonders hohe Performance auf kleinen Prozessoren gegenüber alternativen, freien und kommerziellen TCP/IP-Produkten ab. Insbesondere die Umsetzung eines dynamischen Protokolls wie TCP/IP in der sehr statischen Umgebung eines Automotive-Steuergerätes erfordert besondere Aufmerksamkeit, bietet damit aber auch ein interessantes und herausforderndes Thema für eine wissenschaftliche Arbeit.

IPv4 ist das gegenwärtig am meisten genutzte Internet-Protokoll. Problematisch ist allerdings der auf 32 Bit begrenzte Adressraum, welcher eine maximale Anzahl von 4,295 Milliarden Geräten adressieren kann. Mit dem Wirtschaftsboom in Asien und dem Bedarf an IP-Adressen für mobile Endgeräte, für Haushaltsgeräte (Kühlschrank), Sensor-Netzwerke für Brücken, Häuser usw. oder RFID-Chips und in Zukunft auch für Fernsehgeräte und Kfz-Fahrzeuge, steigt der Bedarf an IP-Adressen rapide an. Die Zahl der Internetnutzer weltweit hat im Jahr 2005 die Milliarden-Marke überschritten berichten die Marktforscher von [ETFO06]. Sie rechnen mit einem Anstieg der Nutzerzahlen auf zwei Milliarden für das Jahr 2011.

Bereits 1993 begann man daher mit der Entwicklung von TCP/IP-Version 6. IPv6 bietet einen Adressbereich von 128 Bit. Damit kann man wesentlich mehr Rechner im Internet mit IP-Adressen versehen: ca. 340 Sextillionen (2 hoch 128)! Es können also rein rechnerisch für jeden Quadratmillimeter Oberfläche der Erde ungefähr 667 Billiarden IPv6-Adressen zur Verfügung gestellt werden. In Asien werden die IPv4-Adressen schon knapp und auch allgemein wird der Adressraum des IPv4-Protokolls nicht ausreichen, denn neben einer exponentiell ansteigenden Zahl von neuen benötigten IP-Adressen ist ein großer Teil des IP-Adressraums nicht nutzbar, da er für Sonderaufgaben (Multicast) zugeteilt ist oder zu großen Subnetzen gehört. Die Normen werden von der IETF gesetzt.

Da die Umstellung von IPv4 auf IPv6 kontinuierlich verlaufen soll, sind bereits viele Geräte mit einer Dual-Stack-Implementierung ausgestattet, d.h. sie verfügen über beide Protokollvarianten. Das heißt zudem, dass im Kernbereich des Netzes beide Protokolle parallel gefahren werden können. Für jedes Teilnetz, zum Beispiel einzelne Unternehmen oder Abteilungen, kann nun separat entschieden werden, ob auf IPv6 umgestellt wird. Geräte, für die es keine Aktualisierung gibt, kommunizieren weiterhin über IPv4.

1.2 Ziele dieser Masterarbeit

Aufbauend auf den IPv4-Protokoll-Stack soll eine ebenso performante und schlanke Implementierung für den kommenden IPv6-Standard entstehen. Dieser Protokoll-Stack soll als Dual-Stack beide IP-Versionen unterstützen können. Innerhalb dieser Arbeit werden die Neuheiten des IPv6-Standards analysiert. Aus den Ergebnissen werden Anforderungen an die Implementierung abgeleitet. Dabei soll auf den bereits gewonnenen Erkenntnissen aus der IPv4-Stack-Entwicklung aufgebaut werden. Anschließend wird ein Softwaredesign erstellt und dieses für einen Prototyp implementiert.

1.3 Kapitelübersicht

Die vorliegende Masterarbeit gliedert sich in acht Hauptkapitel.

In Kapitel 2 werden die Grundlagen zum Automotive-Markt untersucht, um für die geforderte Aufgabenstellung ein Verständnis für das Umfeld zu bekommen, in dem das zu entwickelnde System eingesetzt wird.

Die derzeitige Situation auf dem Automotive-Markt in Bezug auf die Entwicklung neuer Technologien wird vorgestellt. Für die Softwareentwicklung haben die führenden Hersteller einen Standard für die Entwicklung von Steuer-Software entwickelt, der für alle Steuergeräte eine gemeinsame Plattform zur Verfügung stellt. Der Standard OSEK/VDX und dessen Nachfolger AUTOSAR werden beschrieben. Schließlich wird etwas näher auf den Begriff „Steuergerät“ eingegangen, welches die Hardwareplattform für das zu entwickelnde Produkt bildet.

Kapitel 3 beschreibt die Grundlagen zu den in der Automobil-Industrie eingesetzten Bussystemen. Die derzeit gängigen Bussysteme werden kurz beschrieben. Der im Rahmen dieses Projektes verwendete Ethernet-Bus wird vorgestellt.

In Kapitel 4 werden die Grundlagen zum TCP/IP-Protokoll beschrieben, soweit sie für das Verständnis der nachfolgenden Aufgabenstellungen relevant sind. Nach einer einführenden Betrachtung der OSI-Schichtenarchitektur werden die protokollspezifischen Details zu Ethernet, IPv4, ICMPv4, IPv6, ICMPv6 sowie UDP und TCP vorgestellt. Die Neuerungen des IPv6-Protokolls werden erarbeitet.

In Kapitel 5 wird die eigentliche Projektarbeit mit einer Anforderungs-Analyse gestartet. Die geplanten funktionalen und nichtfunktionalen Anforderungen werden spezifiziert. Außerdem wird die System- und Produktgrenze festgelegt und Projektrandbedingungen werden spezifiziert.

Kapitel 6 beschäftigt sich mit der Analyse des bestehenden IPv4-Protokoll-Stacks. Für eine Übersicht wird die Stack-Architektur beschrieben. Weiterhin wird die Speicherverwaltung untersucht, soweit diese für das Projekt relevant ist. Das Konzept der Einbindung von Netzwerktreibern in das Gesamtsystem wird vorgestellt. Schließlich wird der Hin- und Rückweg eines Nutzdatenpaketes auf dem Protokoll-Stack dargestellt. Außerdem werden die wichtigsten Schnittstellenfunktionen und deren Aufgaben beschrieben.

In Kapitel 7 erfolgt eine detaillierte Beschreibung der Implementierung. Zunächst wird die Reihenfolge der zu implementierenden Funktionen mit den für die Umsetzung notwendigen Aufgaben festgelegt. Anschließend wird die erweiterte Software-Architektur gezeigt. Es folgt eine detaillierte Beschreibung für die Realisierung eines PING-Befehls. Die dazu notwendigen Erweiterungen bestehender Funktionen und Schnittstellen, sowie die hierfür notwendige Implementierung neuer Funktionalitäten und Datenstrukturen werden vorgestellt. Anschließend werden die durchzuführenden Aufgaben zur Erweiterung der Protokollschichten UDP und TCP sowie die Erweiterung der SOCKET-Schnittstelle beschrieben. Schließlich wird beschrieben, wie die neue Funktionalität der automatischen Adresskonfiguration für IPv6 zu implementieren ist.

In Kapitel 8 wird ein Rückblick auf die durchgeführten Aufgaben gegeben und die dabei aufgetretenen Schwierigkeiten beschrieben. Nach Vorstellung der Ergebnisse dieser Masterarbeit wird ein Ausblick gegeben, wie es mit diesem Projekt sinnvollerweise weiter gehen kann.

Im Anhang werden alle relevanten RFC-Dokumente vorgestellt, welche die Grundlage für die Umsetzung der IPv6-spezifischen Details gebildet haben. Außerdem findet sich dort eine CD mit den Dokumenten dieser Arbeit.

2 Grundlagen Automotive-Markt

Dieses Kapitel beschäftigt sich mit dem für diese Arbeit notwendigen Grundlagen-Wissen zum Umfeld des Automotive-Marktes.

2.1 Der Automotive-Markt

Die in dieser Arbeit zu entwickelnde Software wird in Steuergeräten für Kraftfahrzeuge zum Einsatz kommen. Aus diesem Grunde gibt dieses Kapitel eine Kurzübersicht, welchen aktuellen und zukünftigen Stellenwert solche Steuergeräte für den Automotive-Markt haben.

Die Automobilbranche ist seit Jahren ein wichtiger Innovationstreiber der deutschen Wirtschaft. Neue Anwendungen wie Infotainment und Fahrerassistenz erfordern neue Lösungen für Kommunikationsnetze und Bussysteme. Außerdem nehmen Technologien wie Fahrzeug-Busse mit hoher Bitrate und drahtlose Vernetzung im Fahrzeugumfeld an Bedeutung zu. Aber auch bei der Fahrzeugsoftware stehen große Innovationsschübe an: die zunehmende Realisierung von Fahrzeugfunktionen durch Steuergeräte-Software, zudem eine stark differenzierte Fertigungskette auch für Software-basierte Komponenten und des Weiteren die große Variantenvielfalt durch die Berücksichtigung individueller Kundenwünsche [FRHO06].

Die Elektronik gilt längst als Schlüsseltechnologie der Fahrzeugentwicklung. Ursprünglich selbstständig arbeitende Steuergeräte werden immer mehr verknüpft. Oberklasse-Limousinen sollen künftig bis zu 100 "Netzteilnehmer" an Bord haben [UlGü01].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Vernetzte Steuergeräte in einem modernen Kraftfahrzeug

2.2 Echtzeitbetriebssysteme

Ein Echtzeitbetriebssystem oder auch kurz RTOS (real-time operating system) ist ein Betriebssystem mit zusätzlichen Echtzeit-Funktionen für die Einhaltung von Zeitbedingungen und die Vorhersagbarkeit des Prozessverhaltens. Ein RTOS ist heutzutage in sehr vielen elektronischen Geräten vorzufinden wie z.B. Mobiltelefone, Satellitenreceivern, Routern, Navigationssystemen, MP3-Playern, Autoradios und neben vielen weiteren Produkten auch in Automobilen.

In den letzten Jahren ging der Trend der Automobilhersteller immer mehr in die Richtung mehr elektronische Geräte in ihre Produkte zu integrieren, welche dem Fahrzeugführer ermöglichen sicherer, komfortabler, ökonomischer und ökologischer zu fahren. Diese so genannten „elektronischen Helfer“ sind mit Begriffen verbunden wie Antiblockiersystem (ABS), elektronisches Stabilitätsprogramm (ESP), Antriebs-Schlupf-Regelung (ASR) und vielen weiteren Anwendungen. „Elektronische Helfer“ sind meist Steuergeräte. Durch eine Vielzahl von Sensoren erhalten die Steuergeräte Informationen, die sie mit Algorithmen auswerten und ggf. eine Reaktion darauf auslösen können. Diese Steuergeräte besitzen ebenfalls wie das Mobiltelefon oder der PC ein Betriebssystem, welches unterschiedliche Prozesse, die gleichzeitig im Steuergerät laufen, verwaltet.

Für Steuergeräte die Betriebssysteme verwenden, gelten bestimmte Anforderungen wie z.B. ein hohes Maß an Sicherheit und Qualität. Der Großteil der heute verbauten Elektronik stammt nicht mehr aus der Hand der Automobilhersteller sondern von externen Lieferanten wie Siemens VDO oder BOSCH. Um die Kosten niedrig zu halten, sowie die Qualität und Zuverlässigkeit zu erhöhen, werden seit Jahren Standardisierungsmaßnahmen vorangetrieben. Zwei Ergebnisse hiervon sind OSEK und AUTOSAR. Hierbei handelt es sich um eine Partnerschaft der größten Automobilherstellern sowie Zulieferern, die es sich zum Ziel gesetzt haben, ein standardisiertes Framework für jegliche Software im Auto bereitzustellen.

2.3 OSEK

OSEK steht für „ O ffene S ysteme und deren Schnittstellen für die E lektronik im K raftfahrzeug“.

Es handelt sich dabei um einen Standard, welcher von internationalen Automobilherstellern und deren Zulieferern erstellt wurde. Das Ziel dieser Spezifikation ist die Schaffung eines Industriestandards für eine offene Fahrzeugarchitektur mit verteilten Steuergeräten. Dazu werden ein Echtzeitbetriebssystem sowie Softwareschnittstellen und Funktionen für Kommunikations- und Netzwerkmanagement herstellerübergreifend spezifiziert. Betriebssysteme, die zu OSEK konform sind, bieten keine Funktionen um Systemkomponenten dynamisch zur Laufzeit zu erzeugen. Das gesamte System ist statisch konfiguriert und enthält alle benötigten Betriebssystemmittel. Dieses Vorgehen erhöht die Zuverlässigkeit sowie die Reaktionsfähigkeit des Systems. Da Betriebssysteme die nach dem OSEK-Standard arbeiten, hauptsächlich in eingebetteten Systemen Verwendung finden, ist eine statische Konfiguration des Systems von Vorteil, da diese während der Laufzeit nicht verändert werden müssen. Des Weiteren wird die Portabilität von verschiedenen Anwendungen und die Plattformunabhängigkeit gewährleistet.

Seit 1997 wird dieser Standard für die Serienfertigung von Steuergeräten verwendet. Eine detaillierte Beschreibung des OSEK Betriebssystems findet sich in [OSEK].

Die in dieser Arbeit zu entwickelnde Software, wird als Modul in einem OSEK Betriebssystem implementiert.

2.4 Implementierungssprache OIL

Ein weiteres Merkmal des OSEK Standards ist die Implementierungssprache OIL (OSEK Implementation Language). In einer OIL-Konfigurationsdatei werden alle Objekte (Tasks, Events, Alarms, Messages etc.) mit ihren Eigenschaften definiert. Über eine spezielle Konfigurationssoftware wird aus dem OIL-File der OSEK-Code erstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Erzeugen eines OSEK-Projektes

Für diese Projektarbeit werden ebenfalls mit Hilfe einer OIL-Konfigurationsdatei die notwendigen Tasks, Events, etc. für denTCP/IP-Protokoll-Stack definiert und der Quellcode des TCP/IP-Protokoll-Stacks in den OSEK-Code mit eingebunden.

2.4.1 Task-Verwaltung

Der eigentliche Anwendungscode wird in einzelne Tasks geschrieben. Diese Tasks werden nun quasi parallel zueinander abgearbeitet. Das hat wiederum zur Folge, dass die Tasks um verfügbare Rechenzeit konkurrieren. Die eigentliche Aufgabe des Betriebssystems besteht nun darin, die Anwendung zu organisieren und zu strukturieren. Jede einzelne Task besitzt immer einen bestimmten Zustand, in dem sie sich befindet. Je nach dem was derzeit im RTOS passiert, wechselt der Zustand der jeweiligen Task.

In einem OSEK-konformen Betriebssystem wird zwischen zwei verschiedenen Taskmodellen unterschieden. Einmal die Basic-Task und zum anderen die Extended-Task.

Die Basic-Tasks können nur drei Zustände einnehmen:

- Suspended (inaktiv)
- Ready (bereit)
- Running (läuft)

Das hat zur Folge, dass eine Task zwar unterbrochen werden kann, jedoch nicht auf ein Ereignis (Event) warten kann. Also ist in diesem Modell das Betriebssystemmittel der Events nicht anwendbar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Zustandsdiagramme der OSEK-Extended-Tasks

Die auch in dieser Projektarbeit eingesetzten Extended-Tasks unterscheiden sich von den Basic-Tasks darin, dass sie mit dem Systemaufruf WaitEvent vom running -Zustand in einen Wartezustand waiting gehen können. Dieser Zustand wird erst bei eintreten eines Ereignisses wieder verlassen.

Diese Möglichkeit wird in diesem Projekt beispielsweise dafür eingesetzt, dass eine Funktion zum Empfangen von Daten solange wartet, bis Daten über die Netzwerk-Karte empfangen wurden.

2.4.2 Kommerzielle OSEK-Distributionen

Es sind etliche OSEK konforme Betriebssysteme auf dem Markt erhältlich wie z.B.

- osCAN von der Firma Vector-Informatik
- RTA-OSEK von der Firma ETAS
- ProOSEK® von der Firma Elektrobit Automotive (ehemals 3SOFT)

Diese Arbeit setzt auf dem Betriebssystem von ProOSEK® auf. ProOSEK® findet in Fahrzeugen namhafter Fahrzeughersteller Verwendung. Es wird beispielsweise in der Mehrzahl der Steuergeräte der aktuelle 7er BMW Serie eingesetzt.

2.4.3 AUTOSAR

AUTOSAR (AUT omotive O pen S ystem AR chitecture) ist eine weltweite Entwicklungspartnerschaft von Automobilherstellern, -zulieferern und weiteren Unternehmen der Elektronik-, Halbleiter- und Softwareindustrie.

Seit 2003 arbeiten sie an der Entwicklung und Einführung einer offenen und standardisierten Software-Architektur für die Automobilindustrie. Der AUTOSAR-Ansatz vereinfacht den Austausch und die Update-Möglichkeiten von Software und Hardware und bildet die Basis, um die wachsende Komplexität der Elektrik und Elektronik im Kraftfahrzeug sicher zu beherrschen. Zudem verbessert AUTOSAR die Kosteneffizienz, ohne Kompromisse in der Qualität einzugehen. Die „Core Partner“ von AUTOSAR sind die BMW Group, Bosch, Continental, DaimlerChrysler, Ford, Opel, PSA Peugeot Citroen, Siemens VDO Automotive, Toyota und Volkswagen. Über diese Unternehmen hinaus spielen rund 50 „Premium Members“ eine wichtige Rolle beim Erfolg der Partnerschaft. Unternehmen, die der AUTOSAR-Entwicklungspartnerschaft beitreten, können die Spezifikationen kostenfrei nutzen [AuSa07].

"Durch die Wiederverwendung von Softwareblöcken könnten wir Hersteller viel sparen", sagt Harald Heinecke, Leiter bei BMW Car IT. "Und auch die Zulieferer würden profitieren. Sie müssten nicht mehr für jeden Hersteller einzeln programmieren, sondern könnten ebenfalls ganze Softwareblöcke wiederverwenden.“ Er erwartet die ersten Autos mit AUTOSAR-kompatibler Software für 2008. Ab 2011 könnte es Standard sein. [DeDi07]

Zu den gewünschten Eigenschaften gehören nach [AuSa06]:

- Implementierung und Standardisierung von Basisfunktionen
- Skalierbarkeit hinsichtlich verschiedener Fahrzeugtypen
- Möglichkeiten zur redundanten Auslegung
- Einbettung von Modulen anderer Hersteller
- Wartbarkeit während des gesamten Produktlebenszyklus
- Software Updates und Upgrades während des gesamten Fahrzeuglebens

Um diese Ziele zu erreichen, werden in [AuSa06] folgende Lösungen vorgeschlagen:

- Standardisierung des Austauschformats, womit die Kompatibilität untereinander erreicht wird.
- Basic Software, hierdurch wird die Software Qualität gesteigert.
- Microcontroller Abstraction, so dass Mikrocontroller ohne notwendige Änderungen in darüber liegenden Schichten ausgetauscht werden können.
- Runtime Environment, das zu einer einheitlichen Kommunikation sowie der Möglichkeit der Verlegung von Funktionen beträgt.
- Standardisierung von Schnittstellen, um Probleme zwischen Produkten verschiedener Hersteller zu vermeiden.

Wie dies umgesetzt werden soll, wird in den folgenden Abschnitten vorgestellt.

2.5 Architektur

Eine Steuergeräte-Einheit in einem AUTOSAR Auto wird wie in Abbildung 4 aussehen.

Von oben nach unten gesehen finden sich:

- die Software Schicht (enthält die SW-Komponenten),
- das Runtime Environment (RTE),
- die Basic-Software,
- sowie darunter die zugrunde liegende Hardware.

2.5.1 AUTOSAR-Software

In dieser Ebene befinden sich die Softwarekomponenten. Dies kann zum einen die notwendige Software für die vorhandenen Aktuatoren beziehungsweise Sensoren sein, sowie die Anwendungssoftware des gesamten Steuergerätes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Überblick über die AUTOSAR Software Architektur

2.5.2 Runtime Environment

Das Runtime Environment (RTE) implementiert die Funktionalität für die jeweils verwendete Hardware. Sie ist zuständig sowohl für die interne Kommunikation als auch für die Verständigung mit anderen Komponenten innerhalb desselben Steuergeräts. Sie stellt unabhängig vom verwendeten BUS und den jeweiligen Softwarekomponenten eine einheitliche Kommunikationsschnittstelle bereit. Hauptaufgabe besteht darin, die Befehle an die darunterliegende Basic Software weiterzugeben.

2.5.3 AUTOSAR-Basic-Software

Wie in der Basic-Software-Schicht in Abbildung 4 zu sehen ist, besteht diese aus mehreren Teilen.

- Operating System - Das AUTOSAR-OS basiert auf dem bereits vorgestellten OSEK-OS. In diesem Teil befindet sich auch das TCP/IP-Modul dieser Arbeit.
- Services - Stellt Systemdienste bereit wie z.B. Diagnose-Protokolle und Speicher-Management.
- Communication - I/O-Management und Netzwerk-Management.
- Microcontroller Abstraction - Kein direkter Mikrocontrollerzugriff, dadurch unabhängig vom jeweiligen Controller.
- Complex Device Drivers - Falls benötigt, ist hier der direkte Zugriff zu speziellen Funktionen des Controllers möglich.

2.5.4 ECU-Hardware

Dieser Bestandteil umfasst die verwendete Hardware wie Prozessoren, Aktuatoren und Sensoren.

2.6 Vorgehensmodell

AUTOSAR stellt ebenfalls eine Vorgehensmethodik zum Erstellen der Software bereit. Hierbei handelt es sich um eine Kette von Schritten, welche in einer ausführbaren ECU-Komponente endet [AuSa06].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: AUTOSAR Vorgehen bei der Softwareerstellung

Alle Beschreibungsdokumente liegen in XML vor. Am Anfang steht die Auswahl der Hardware- und Softwarebestandteile sowie die Festlegung notwendiger Bedingungen. Hierfür stehen jeweils entsprechende Vorlagen zur Verfügung. Der nachfolgende Schritt befasst sich mit der Zuweisung der Softwarekomponenten zu den Hardwarekomponenten. Es erfolgt eine Auswertung der benötigten und der von der Hardware zur Verfügung gestellten Ressourcen. Anhand dieser wird das Mapping durchgeführt. Die vorliegende Beschreibung (System Configuration Description) enthält die Beschreibung des Systems, wie unter anderem Topologie, BUS Mapping und welche Software auf welche ECU kommt.

Die nun folgenden Schritte müssen jeweils für jede ECU einzeln durchgeführt werden. Anschließend wird die ECU-Information einzeln aus der System-Konfigurationsbeschreibung extrahiert, die für eine detaillierte Beschreibung der ECU verwendet wird.

Zuletzt wird aus den so gesammelten beziehungsweise generierten Informationen eine Programmdatei erzeugt. Hierbei wird typischerweise der Code für beispielsweise die RTE und die Basis-Software generiert. Ebenso wird der vorliegende Quellcode der Softwarekomponente kompiliert. Sollte dieser schon als Objektcode vorliegen, dann entfällt das Kompilieren. Anschließend werden die Einzelbestandteile in eine ausführbare Komponente zusammengefasst. Eine ausführlichere Beschreibung dieses Vorgehens findet sich in Kapitel 3 in [AuSar06].

Diese Vorgehensmethodik wird auch für diese Arbeit verwendet, um ein ausführbares Programm für ein Steuergerät zu generieren. Die dazu notwendigen XML-Konfigurationsdateien werden mit dem speziellen Konfigurationsprogramm Tresos® der Firma Elektrobit Automotive erstellt.

2.7 Steuergeräte in Fahrzeugen

Obwohl das zu entwickelnde Produkt prinzipiell in jedem beliebigen Steuergerät eingesetzt werden kann, konzentriert sich die Implementierung auf Steuergeräte, wie sie in der Automobil-Industrie eingesetzt werden.

Ein Steuergerät ist ein elektronisches Gerät, welches Regelungs- und Steuerungsaufgaben übernimmt. Zu diesem Zweck besitzt ein Steuergerät in der Regel eine Anbindung an die fahrzeugeigene Spannungsversorgung. Man unterscheidet hierbei zwischen Klemme-30- und Klemme-15-Steuergeräten. Ein sogenanntes Klemme-30-Steuergerät ist direkt mit der Batteriespannung verbunden und entscheidet selbst, wann es sich in ein Sleep- oder Shutdown-Modus begibt. Dieser Übergang kann von vielen Faktoren abhängen. Beispielsweise von einer internen Datensicherung oder einer Aufrechterhaltung der Funktion aus Sicherheitsgründen. Klemme-15-Steuergeräte werden beim Abschalten der „Zündung“ hart abgeschaltet und haben keine Sicherheitsfunktionen oder Nachlauftätigkeiten.

Steuergeräte sind in der Regel zusätzlich am Fahrzeug-Kommunikationsnetz angebunden und nehmen dort an der Kommunikation teil. Viele Steuergeräte verfügen zudem über elektrische Eingangs- und oder Ausgangsgrößen, um Signale ihrer Umwelt zu lesen oder zu beeinflussen. Im Regelfall werden hier Sensoren oder Aktuatoren eingesetzt.

Im Inneren der Steuergeräte findet man neben diversen diskreten oder integrierten Bauteilen heute im allgemeinen Mikrocontroller welche in der Regel zwischen 8- und 32-Bit-Rechnerarchitekturen enthalten und somit je nach Anwendungsfall und Komplexität der Regelungs- und Steuerungsaufgaben einen weiten Rechenleistungsbereich abdecken.

Die Software in den Steuergeräten besteht aus verschiedenen Schichten vom sog. BIOS über das Betriebssystem und die Treiberebenen bis hin zur eigentlichen Applikation. Die Diagnose, welche das Steuergerät und daran angeschlossene Systeme überwacht und für die Werkstatt als Hilfe zur späteren Fehlersuche dient, nimmt einen immer größeren Stellenwert ein. Um ein Austausch des Steuergerätes bei Fehlern im Feld zu vermeiden, wird die Software heute nicht mehr im ROM sondern in FLASH-Speichern abgelegt, um ein Softwareupdate zu ermöglichen [ArFa07].

3 Grundlagen Bussysteme

Die Kommunikation im Auto wird heute durch ein oder mehrere Bussysteme bewältigt. Ein Bussystem beschreibt im Wesentlichen eine Datenverbindung, an die mehr zwei oder mehr Teilnehmer angeschlossen werden können. Grundsätzlich hört jeder angeschlossene Bus-Teilnehmer jede Nachricht und entscheidet selbst, ob er diese verarbeitet oder nicht.

3.1 CAN

(C ontroller A rea N etwork) ist das derzeit am häufigsten eingesetzte Kfz-Bussystem sowohl für Low-Speed- als auch für High-Speed-Anwendungen.

Es wurde von Bosch in der zweiten Hälfte der 80er Jahre entwickelt und seit 1991 als erstes Class-C-Netz in Fahrzeugen eingesetzt. Mit dem ISO-Standard ISO 11898 und dem SAE-Standard SAE J2284 wurde das Protokoll für die Anwendung im PKW standardisiert [WeZi07].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Kenndaten CAN-Bus

3.2 FlexRay

FlexRay ist ein serielles, deterministisches und fehlertolerantes Feldbussystem für den Einsatz im Automobil, vergleichbar mit TTP/C oder EC-Net. Das FlexRay-Konsortium wurde 2000 von den Firmen BMW, DaimlerChrysler, Motorola und Philips (heute: NXP Semiconductors) gegründet. Von 2001 bis 2004 traten als Core-Partner die Firmen Bosch, General Motors und Volkswagen bei. 2004 übernahm Freescale die Rechte und Pflichten als Core-Mitglied im Konsortium von Motorola.

FlexRay sollte die erhöhten Anforderungen zukünftiger Vernetzung im Fahrzeug erfüllen, insbesondere höhere Datenübertragungsrate, Echtzeit-Fähigkeit und Ausfallsicherheit (für X-by-Wire Systeme). Im aktuellen Fokus steht jedoch vorrangig die höhere Datenrate, welche durch den kontinuierlichen Anstieg von Fahrerassistenzsystemen im Bereich Antrieb und Fahrwerk in Premium-Fahrzeugen heute notwendig ist. In den Bereichen Sicherheit sind neue Bus-Guardian-Konzepte in Arbeit. Diese ermöglichen eine zentrale bzw. dezentrale Überwachung der Buszugriffe auf Basis des statisch festgelegten TDMA-Schemas.

Der erste Serieneinsatz im Automobil erfolgt erstmalig im BMW X5 2006. Der FlexRay-Cluster in diesem Fahrzeug basiert auf der Protokollversion v1.1, die Protokollspezifikation v2.1 wurde Ende 2005 verabschiedet und im Laufe des Jahres 2006 in Silizium implementiert [Wiki07-FlexRay].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Kennzahlen FlexRay-Bus

3.3 LIN

Der LIN-Bus (L ocal I nterconnect N etwork) ist ein relativ junges Bussystem, das Ende der 90er Jahre entwickelt wurde, um eine kostengünstige Alternative zu Low-Speed-CAN-Bussystemen für einfache Sensor-Aktor-Anwendungen zu bieten, z.B. für die Tür-, Sitz- oder Schiebedach-Elektronik. Triebfeder war der Halbleiterhersteller Motorola (heutiger Name: Freescale) in Zusammenarbeit mit verschiedenen Kfz-Herstellern, die sich zu einem LIN-Konsortium zusammengeschlossen haben. Die Spezifikationen sind offen gelegt und da ein einfaches, zeichenorientiertes Protokoll verwendet wird, das mit jeder Seriellen Schnittstelle implementiert werden kann, ist es praktisch frei verfügbar [WeZi07].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Kennzahlen LIN-Bus

3.4 Most

Der MOST-Bus (M OST = Media O riented S ystems T ransport) wurde für Telematik- und Multimedia-Anwendungen (Infotainment Bus) konzipiert, d.h. für die Vernetzung von Autoradio, CD-Wechsler, Autotelefon, Navigationssystem und Bordfernsehgerät. Als erstes etabliertes Multimedia-Bussystem in Fahrzeugen gestattet MOST die digitale und damit störunempfindliche Übertragung von Audio- und Videosignalen zwischen Steuergeräten [WeZi07].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Kennzahlen MOST-Bus

3.5 Ethernet

Das Ethernet (IEEE 802.3) gehört heute zu dem weltweit am häufigsten installierten lokalen Netz. Die einfache Art der Installation, seine Flexibilität, seine Vielseitigkeit und seine einfache Handhabung sind der Schlüssel zum Erfolg dieser Technologie. Die offene Systemarchitektur des IEEE-802.3-Standards bildet die Grundlage für alle Anwendungsbereiche der Datenkommunikation. Die Anfänge des Ethernet reichen bis in die Mitte der siebziger Jahre zurück. Damals wurde vom Palo Alto Research Center (PARC) der Firma Xerox Corporation das Ethernet der Öffentlichkeit vorgestellt. Es dauerte bis 1980, bis ein Firmenkonsortium (DIX-Gruppe), bestehend aus DEC, Intel und Xerox, den offiziellen Ethernet-Standard veröffentlichte. Die neu gegründete IEEE-802.3-Arbeitsgruppe nahm diesen Gedanken auf und entwickelte aus dem firmenspezifischen Standard einen international anerkannten Netzstandard. Im Dezember 1982 wurde der Entwurf der IEEE-802.3-Gruppe als »CarrierSense Multiple Access with Collission Detection« (CSMA/CD) veröffentlicht. In den folgenden Jahren wurde das CSMA/CD-Verfahren auf den unterschiedlichsten Übertragungsmedienadaptiert und als IEEE-802.3-Substandard veröffentlicht.

Heute umfasst der Standard IEEE802.3 folgende Untergruppen [MaHe03]:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Ethernet-Standard IEEE802.3

Bisher ist die Verwendung von Ethernet-Bus im Automotive-Bereich nicht sehr verbreitet. Doch dass kann sich in den nächsten Jahren dramatisch ändern. Im März 2007 stellte das Erlanger Softwareunternehmen Elektrobit Automotive Software den ersten qualifizierten TCP/IP-Stack für Automotive-Steuergeräte auf Ethernet-Basis der Öffentlichkeit vor [ToEn07].

Im Rahmen des Innovationstages „BMW Group Forschung und Entwicklung“ auf der MAN Teststrecke in München, wurden am 25.10.2007 eine Pressemittelung zu den Visionen und Forschungsprojekten von BMW heraus gegeben. Die BMW Group Forschung und Technik forscht an einer einheitlichen Standardsprache für das Netzwerk "Automobil", da die bis zu fünf unterschiedliche Bussysteme wie CAN, LIN, MOST und FlexRay jeweils ihre eigene automobile Sprache sprechen. Basis für diese Standardsprachen-Technologie ist das Internet Protocol (IP). Dieser völlig neue Ansatz kann man als Revolution bezeichnen, der Weg in ein Serienfahrzeug wird aber ein noch langer sein und Sicherheitsaspekte dürfen auch nicht außer Acht gelassen werden. Im Fahrzeug kann IP als weltweit einheitliche Sprache zum Beispiel sehr gut über ein Breitbandnetzwerk wie etwa das Ethernet übertragen werden. Damit wird das Fahrzeug zu einem Teilnehmer am World Wide Web [ElIn07].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Kennzahlen Ethernet-Bus

4 Grundlagen TCP/IP-Protokolle

Dieses Kapitel beschreibt die Grundlagen, die für das Verständnis der TCP/IP-Protokolle im Rahmen dieser Arbeit benötigt werden. TCP/IP-Protokoll steht dabei als Begriff für eine ganze Protokoll-Familie, die sich in mehr als 30 Jahren entwickelt hat. Neben dem TCP-Protokoll und dem IP-Protokoll sind an einer Datenkommunikation noch viele weitere Protokolle wie z.B. ARP, ICMP und DHCP beteiligt. Jedes dieser Protokolle ist für bestimmte Spezialaufgaben zuständig. Die Theorie zu diesem Thema ist sehr umfangreich. In den sogenannten RFC-Dokumenten (Request for Comment), die über das Internet öffentlich zugänglich sind, werden die Details zu den Protokollen sehr genau beschrieben und auch die geplanten Erweiterungen diskutiert. Weiterhin gibt es umfangreiche Literaturquellen, bei denen es sich meist um dicke Bücher mit jeweils ca. 1000 Seiten handelt. Aus diesem Grund werden hier nur die wichtigsten Protokolle und Details vorgestellt, die für das Verständnis dieses Projektes notwendig sind. Es wird nur der Aufbau der entsprechenden Protokoll-Header und die Bedeutung der wichtigsten Felder gezeigt. Für eine weitergehende Beschreibung wird auf die entsprechende Literatur im Anhang verwiesen.

Die TCP/IP-Protokolle wurden entwickelt, um Daten über ein paketvermittelndes Netz (wie dem ARPANET) zu übertragen. Ein Paket ist ein Datenblock zusammen mit den Informationen, die notwendig sind, um sie dem Empfänger zuzustellen. Ein Paket ist also nichts anderes als ein Paket im herkömmliche Sinn. Das Datagramm ist das Paketformat, das vom Internet-Protokoll definiert ist. Ein Paket besteht aus einem Header gefolgt von den Nutzdaten, die auch als „payload“ bezeichnet werden. Die Nutzdaten können ebenfalls wieder aus Header und Nutzdaten einer höheren Protokollschicht bestehen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Allgemeiner Aufbau eines Datenpaketes

Für eine systematische Erläuterung der Protokolle ist ein anschauliches Modell sehr hilfreich. Es basiert auf dem sogenannten OSI-Referenzmodell (O pen S ystem I nterconnection) das Ende der 70er Jahre eingeführt wurde.

4.1 OSI-Referenzmodell

Als man Mitte der 70er Jahre versuchte, die Rechner unterschiedlicher Hersteller miteinander zu vernetzen, ergab sich folgendes Problem: Es sind dringend Kommunikationsregeln nötig, damit ein Rechner des Herstellers X mit einem Rechner des Herstellers Y kommunizieren kann. Es sollte möglich sein, dass jeder Rechner für die Kommunikation mit allen anderen Rechnern offen (bereit) ist. In diesem Zusammenhang wurde bereits damals von der Vernetzung offener Systeme – also von Open System Interconnection (OSI) – gesprochen und nach einem Modell für ihre Verwirklichung gesucht. Daher wurde ein Schichtenmodell eingeführt, das die Prinzipien der Kommunikation zwischen verschiedenen Systemen beschreibt und die OSI-Vorstellung ermöglicht. Es wird deshalb OSI-Referenzmodell genannt. Standardisiert wurde es von ISO (International Organization for Standardization) und es wird auch als ISO/OSI-Referenzmodell bzw. kurz als ISO/OSI-Modell bezeichnet [AnBad07].

Sinn und Zweck der Definition von einzelnen Schichten ist, dass ein recht komplex wirkendes Kommunikationssystem in seiner Funktionalität aufgespaltet werden kann und dann leichter zu implementierende Einzelteile bearbeitet werden können. Wie die Schichten dabei im Einzelnen aufgebaut sind, ist dabei nicht von Bedeutung, sondern es ist lediglich die jeweilige Übergabeschnittstelle (von einer Schicht zur anderen) von Belang, um ein eindeutiges Verhalten innerhalb des Gesamtsystems realisieren zu können. Notwendige Anpassungen sind dadurch leichter durchführbar, da möglicherweise nur ein bestimmter Aspekt in einer einzigen Schicht von einer Änderung betroffen ist, und auch die Wiederverwendbarkeit bestimmter Schichten in unterschiedlichen Systemen dadurch gegeben ist [KlDem03].

Der Aufbau des OSI-Modells ist in der folgende Tabelle vereinfacht dargestellt [AnTa03]:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Aufbau des OSI-Referenzmodells

4.2 Das TCP/IP-Referenzmodell

Das TCP/IP-Referenmodell; benannt nach den beiden primären Protokollen TCP und IP; beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANET gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI-Standardisierung eingeflossen. Im Gegensatz zum OSI-Modell besteht es aus nur vier Schichten, nämlich Application Layer, Transport Layer, Internet Layer und Network Layer.

Die folgende Abbildung gibt einen Vergleich zwischen dem OSI-Modell und dem TCP/IP-Modell:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Vergleich von ISO/OSI- und TCP/IP-Referenmodell

Die Applikationsschicht umfasst alle höher schichtigen Protokolle des TCP/IP-Modells wie z.B. FTP (Dateitransfer), DNS (Domain Name Service) und HTTP (Hypertext Transfer Protocol).

Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-Protokolle definiert: Das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP).

Die Internetschicht im TCP/IP-Modell definiert nur ein Protokoll namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige Rolle. Das I nternet- C ontrol- M essage- P rotocol (ICMP) ist fester Bestandteil jeder IP-Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das Internet-Protokoll. Spricht man von IP, ist damit die derzeit aktuelle Version 4 des Internetprotokolls gemeint. Neu hinzugekommen ist hier das auch als IPnG (I nternet P rotocol n ext G eneration) bezeichnete IPv6-Protokoll, welches in den nächsten Jahren das IPv4-Protokoll ersetzen soll.

Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke. Das Referenzmodell sagt in der Netzwerkschicht nicht viel darüber aus, was hier passieren soll. Festgelegt ist lediglich, dass zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netz angeschlossen werden muss. Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und von Host zu Host ab. Das Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B. dem Ethernet-Protokoll (IEEE 802.3) oder dem Serial Line IP-Protokoll (SLIP).

[...]