Automotive Electronics

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einführung und Motivation
1.1 Historische Entwicklung der Automobilelektronik
1.2 Wichtigste Trends der Automobilelektronik
1.3 Problemstellung und Ziel des Projektseminars
1.4 Gliederung des Projektseminars

2 Grundlagen
2.1 Aufbau eingebetteter Systeme
2.2 Steuer- und Regelfunktionen
2.3 Standardisierung
2.4 AUTOSAR Software-Architektur

3 Funktionsbereiche
3.1 Fahrzeug und Diagnose
3.2 Vernetzung
3.3 In-Vehicle-Infotainment

4 AUTOSAR und Infotainment
4.1 Herausforderungen
4.2 COQOS
4.3 GENIVI und Wind River Platform for Infotainment
4.4 Vergleich

5 Zusammenfassung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2.1: Modell eines elektronischen Steuergerätes

Abbildung 2.2: Aufbau eines Mikrocontrollers

Abbildung 2.3: Prinzip der Steuerung

Abbildung 2.4: Prinzip der Regelung

Abbildung 2.5: Echtzeitanforderungen

Abbildung 2.6: Taskzustände

Abbildung 2.7: AUTOSAR Software-Architektur

Abbildung 3.1: Diagnosesystem elektronischer Steuergeräte

Abbildung 3.2: Bussysteme im Fahrzeug

Abbildung 3.3: Aufbau der Kommunikationsdienste mit jeweils busspezifischen Komponenten für CAN, LIN, FlexRay und Ethernet

Abbildung 3.4: Car-to-X Kommunikation

Abbildung 3.5: Aufbau einer Internetverbindung (nach BMW)

Abbildung 3.6: Aufbau einer Internetverbindung (nach Daimler)

Abbildung 4.1: COQOS

Abbildung 4.2: Trustdomänen-Partitionen

Abbildung 4.3: GENIVI Architektur

Abbildung 4.4: Wind River Hypervisor

Abbildung 4.5: Wind River Platform for Infotainment

Tabellenverzeichnis

Tabelle 3.1: Buszugriffsverfahren

Tabelle 4.1: Trust Level Klassifikation von Applikationen und Diensten

Tabelle 4.2: Technische Merkmale

Tabelle 4.3: Ansätze zur Erfüllung der Sicherheitsanforderungen

1 Einführung und Motivation

1.1 Historische Entwicklung der Automobilelektronik

Wenn auch bereits vor 125 Jahren erfunden, ist das Kraftfahrzeug auch heute noch durch eine rasante Weiterentwicklung gekennzeichnet. Die dadurch entstandene individuelle Mobilität hat dabei unseren wirtschaftlichen und gesellschaftlichen Alltag ähnlich radikal verändert wie die heutige Entwicklung in der Informationstechnologie. Hier entsteht eine Verbindung. Der Fortschritt der individuellen Mobilität wird durch neue technologische Entwicklungen in der Mikroelektronik, Leistungselektronik und Software weiter vorangetrieben.

Wenn der in den 70er Jahren entwickelte Mikroprozessor zuerst nur in der Motorsteuerung eingesetzt wurde, kann ein Fahrzeug neuester Bauart bis zu 80 Steuergeräte enthalten ([Lind11a], S. 38). Zu Beginn des Elektronikeinsatzes im Fahrzeug arbeiteten die verschiedenen Steuergeräte weitgehend autonom. Die Funktionen konnten eindeutig einem Steuergerät zugeordnet werden. Heute werden nicht nur die Steuergeräte innerhalb der einzelnen Subsystemen Antriebsstrang, Fahrwerk, Karosserie und Multi-Media vernetzt, sondern über Subsystemgrenzen hinweg. Diese Vernetzung ermöglicht die Realisierung neuer, übergeordneter Software-Funktionen, die die "Fähigkeiten" des Fahrzeugs erweitern lassen. ([ScZu10], S. 6-7).

Diese Funktionen wurden meist unter der Nutzung von fahrzeugspezifischen Lösungen erstellt. Dies führte dazu, dass bereits entwickelte Funktionalitäten zwischen verschiedenen Fahrzeugbaureihen nicht wiederverwendet werden konnten. Eine immer schwerer realisierbare Komplexitätsbeherrschung förderte das Streben nach Standardisierung.

So wurde um 1995 von den Initiativen der deutschen Automobilindustrie „Offene Systeme für die Elektronik im Kraftfahrzeug“ ( OSEK) und der französischen Automobilindustrie „Vehicle Distributed executive“ ( VDX) ein Vorschlag für einen Betriebssystemstandard veröffentlicht. Seit dem Jahr 2000 wird in verschiedenen Arbeitskreisen „ Hersteller-Initiative Software “ (HIS), „ Japanese Automotive Software Platform Architecture “ (JASPAR) und „ Automotive Open Systems Architecture “ (AUTOSAR) an der Standardisierung der Softwarearchitektur für Steuergeräte gearbeitet ([ZiSc08], S. 261). Die Standardisierung von Applikationssystemen, unter anderem für das Messen, Kalibrieren und die Diagnose, wird von der Association for Standardization of Automation and Measuring Systems (ASAM) durchgeführt ([ZiSc08], S. 169).

Für die Weiterentwicklung der OSEK/VDX-Betriebssystemstandards wurde im Juli 2003 die AUTOSAR, Automotive Open System Architecture – die Entwicklungspartnerschaft von Automobilherstellern und Zulieferern gegründet. Sie verfolgt das Ziel, ein standardisiertes Elektrik/Elektronik-Architekturkonzept zu entwickeln und in Kraftfahrzeugen zu etablieren, um eine einfache Austauschbarkeit und Wiederverwendbarkeit von Softwarekomponenten sicherstellen zu können ([BrSe07], S. 635; [Reif09], S. 52; [ZiSc08], S. 261). Heute sind bereits die Softwarearchitektur, Anwendungsschnittstellen, Basissoftware und die Methodik für klassische Fahrzeugsysteme Antriebsstrang, Fahrwerk, Karosserie und Multi-Media spezifiziert ([Fürs10], S. 40).

1.2 Wichtigste Trends der Automobilelektronik

Die Entwicklung der Automobilelektronik wird derzeit von zwei wesentlichen Punkten dominiert. Einerseits sind die Automobilhersteller danach bestrebt, AUTOSAR als weltweit etablierten Standard in ihren Fahrzeugen einzuführen, andererseits gewinnen Infotainment-Anwendungen im Fahrzeug zunehmend an Bedeutung ([Fürs10], S. 41).

Die AUTOSAR-Architektur ermöglicht es den Automobilherstellern, die Anwendungen, die als Baukasten betrachtet werden und von der Hardware des Steuergerätes unabhängig sind, nicht nur von Zulieferern zu beziehen, sondern auch selbst zu entwickeln und sein Knowhow im Hause zu behalten ([Borg10], S. 187; [ZiSc08], S. 262). ([Borg10], S. 187; [ZiSc08], S. 262). So wird die Grundidee der AUTOSAR-Partnerschaft „ Zusammenarbeit bei Standards – Wettbewerb bei der Umsetzung “ („Cooperate on standards – compete on implementation“) realisiert ([Reif08], S. 52). Durch die Entkopplung der Applikationssoftware von der Hardware wird die Austauschbarkeit und Wiederverwendbarkeit von Softwarekomponenten gefördert. Unnötige Parallel- und Mehrfachentwicklungen können vermieden werden, Softwarequalität wird erhöht.

Heute beschränkt sich aber die Vernetzung nicht nur auf die Systeme des einzelnen Fahrzeugs, sondern es eröffnen sich immer mehr Möglichkeiten der Vernetzung vom Fahrzeug zu seiner Umwelt. Neben den Consumer-Schnittstellen, wie USB^[1] oder Bluetooth^[2] , bieten immer mehr Automobilhersteller Fernwartungszugänge an, die es ermöglichen, Fahrzeugdaten aus der Ferne auszulesen und so Informationen über den Fahrzeugzustand zu erhalten ([Lind11a], S. 39). Manche nicht sicherheitsrelevante Fehler lassen sich sogar aus der Ferne beheben [BMW10].

Fahrzeuge der Zukunft werden die sicherheitsrelevante Verkehrsdaten von Verkehrsleiteinrichtungen empfangen (Car-to-Infrastructure Communication) sowie über direkte Datenverbindungen zwischen Fahrzeugen diese austauschen (Car-to-Car Communication) können ([Lind11a], S. 39).

Darüber hinaus hält auch das Internet Einzug in das Fahrzeug. So bieten führende Automobilhersteller wie BMW, Daimler Benz und Audi jetzt schon einen uneingeschränkten Zugriff auf das Internet.

1.3 Problemstellung und Ziel des Projektseminars

Der zunehmende Anteil an Elektronik im Fahrzeug stellt die Automobilhersteller und ihre Zulieferer vor große Herausforderungen, wie eingeschränkte Platzkapazität und kurze Entwicklungszeiten^[3] . Neu entwickelte Anwendungen sollen so schnell wie möglich am Markt eingeführt werden. Um dies zu meistern, bietet sich eine Konsolidierung an. Die bisher strikt getrennten Funktionsbereiche:

- Fahrzeug und Diagnose,
- Kommunikation und
- Infotainment

sollen zusammengefasst und mit einer geringeren Anzahl elektronischer Bauteile umgesetzt werden [KlJo11]. Die datentechnische Verbindung dieser Funktionsbereiche bringt einen großen Nutzen für die Ferndiagnose und Software-Updates. Fahrerassistenzsysteme können mit den aktuellen Daten aus der Navigation oder dem Internet noch effektiver funktionieren [BMSo09]. Gleichzeitig müssen aber die Aspekte der Funktionssicherheit (Safety) und der Angriffssicherheit (Security) berücksichtigt werden. Die Anwendungen des Infotainment-Bereichs nutzen eine Internet-Anbindung und können deshalb von außen „angegriffen“ werden. Sie dürfen keinen Zugang zu den fahrzeugspezifischen AUTOSAR-Anwendungen und dem Bordnetz des Fahrzeugs bekommen, um sicherzustellen, dass Angriffe aus dem Internet sicherheitskritische Systeme des Fahrzeugs nicht erreichen können.

In diesem Projektseminar werden zwei Konsolidierungsplattformen COQOS und GENIVI-konforme Wind River Platform for Infotainment vorgestellt. Diese Plattformen ermöglichen es, die fahrzeugspezifischen AUTOSAR-Anwendungen und die Anwendungen des Infotainment-Systems auf einer gemeinsamen Hardware zu vereinen. Deren Ausführung wird durch die Separations- und Virtualisierungstechnologien strikt voneinander getrennt. Die Echtzeit-, Fastboot- und Sicherheitsanforderungen an AUTOSAR-Funktionsausführung müssen erfüllt werden. Beeinträchtigung durch die Infotainment-Betriebssysteme und deren Anwendungen muss dabei ausgeschlossen sein. Das Ziel des Projektseminars besteht darin, die Architektur der jeweiligen Plattform detailliert darzustellen, mit dem Augenmerk auf Sicherheit zu analysieren und anschließend miteinander zu vergleichen.

1.4 Gliederung des Projektseminars

Nach der Einführung werden in Kapitel 2 die Grundlagen der eingebetteten Systeme erläutert. Es wird auf die Steuer- und Regelfunktionen eines Steuergerätes eingegangen und die Arbeitsweise der Echtzeitbetriebssysteme erläutert. Zum Abschluss des Kapitels wird die AUTOSAR Software-Architektur ausführlich dargestellt.

In Kapitel 3 werden drei Funktionsbereiche Diagnose, Vernetzung und Infotainment detailliert erläutert. Für die Diagnose und Kommunikation zwischen den vernetzten Steuergeräten sieht AUTOSAR spezielle Module und Dienste vor. Diese werden ebenfalls vorgestellt.

In Kapitel 4 wird präsentiert, wie sich die Integra­tion von In-Vehicle-Infotainment-Systemen in das Fahrzeugsystem umsetzen lässt.

Der Abschluss des Projektseminars erfolgt in Kapitel 5 mit einer Zusammenfassung und einem Ausblick.

2 Grundlagen

Heute ist die Elektronik zur Schlüsseltechnologie in der Fahrzeugentwicklung geworden. Fast alle Funktionen des modernen Fahrzeugs werden elektronisch gesteuert, geregelt und überwacht, wobei deren Realisierung für den Fahrzeugbenutzer „nicht einmal sichtbar“ ist, wenn es sich um sogenannte eingebettete Systeme handelt ([ScZu10], S. 3).

In diesem Kapitel werden zunächst die technischen Grundlagen und Aufgaben eingebetteter Systeme dargestellt. Diese elektronischen Systeme bauen auf einer speziellen Hardware auf. Echtzeitbetriebssysteme realisieren anschließend die Aufgaben. In den unterschiedlichen Bereichen der Automobilindustrie werden an die Echtzeitausführung besonders hohe Anforderungen gestellt, da es sich oft um sicherheitskritische Funktionen handelt.

Das Kapitel endet mit der Vorstellung der AUTOSAR Architektur, einer offenen Plattform für eingebettete Systeme.

2.1 Aufbau eingebetteter Systeme

Als eingebettete Systeme werden elektronische Systeme bezeichnet, die durch elektronische Steuergeräte, Sollwertgeber, Sensoren und Aktoren abgebildet werden und die das Fahrzeugverhalten beeinflussen, ohne dass eine direkte Schnittstellen zu dem Fahrer besteht ([ScZu10], S. 47).

Die Steuergeräte sind wiederum die zentralen Rechen- und Steuereinheiten, in denen alle wesentlichen Aufgaben wie Sensorauswertung, Berechnung von Algorithmen, Ansteuerung von Aktoren, sowie Diagnose und Selbsttest durchgeführt werden. Im Kern des Steuergerätes befindet sich der Mikrocontroller, der die Ausführung des Steuergeräteprogramms übernimmt ([WaRe06], S. 182). Abbildung 2.1 zeigt den modellhaften Aufbau eines Steuergerätes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1 : Modell eines elektronischen Steuergerätes

Quelle: Eigene Darstellung in Anlehnung an [ScZu10], S. 42

Die von den Sensoren erfassten Eingangssignale werden zunächst in den Eingangsstufen des Steuergerätes so verarbeitet, dass sie vom Mikrocontroller als interne Eingangsgrößen weiterverarbeitet und ausgewertet werden können. Die Ausgangsstufen verarbeiten die internen Ausgangsgrößen des Mikrocontrollers in die für Aktoren verständliche externe Form ([ScZu10], S. 42-43).

Es wird ein Mikrocontroller eingesetzt, bei dem, im Gegensatz zu den PC-Mikroprozessoren, alle Komponenten sich auf demselben Siliziumchip befinden. Wodurch er für sich allein funktionsfähig ist ([Bosc07], S. 196; [WaRe06], S. 182). Ein weiterer Unterschied zu einem PC besteht darin, dass das Anwenderprogramm des Mikrocontrollers fest vorgegeben ist und nicht für unterschiedliche Anwendungen ausgetauscht werden kann ([Bosc07], S. 200). Eine Ausnahme ist das Software -Update durch Flash-Programmierung.

Abbildung 2.2 erläutert die Struktur eines Mikrocontrollers mit seinen Komponenten:

- Mikroprozessor (CPU, Central Processing Unit) ist die programmierbare Einheit, bestehend aus Steuerwerk und Rechenwerk. Das Rechenwerk sorgt für die Ausführung arithmetischer und logischer Operationen, das Steuerwerk dient der Ausführung der Befehle aus dem Programmspeicher;
- Ein- und Ausgabeeinheiten (I/O, Input/Output) sorgen für die Abwicklung des Datenverkehrs mit der Umgebung, d. h. mit Ein- und Ausgabegeräten sowie mit externen Speichern. Sie sind im begrenzten Umfang programmierbar und können so an die jeweilige Anwendung angepasst werden. Dazu zählen u. a. Analog-Digital-Wandler zum Einlesen von Daten, Digital-Analog-Wandler zur Ausgabe von Daten, Ereigniszähler zum Zählen externer Impulse, Timer zum Messen der Zeitspanne zwischen Ereignissen, sowie serielle und parallele Schnittstellen zur Kommunikation mit externen Komponenten oder anderen Mikrocontrollern (z. B. über CAN);

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2 : Aufbau eines Mikrocontrollers

Quelle: Eigene Darstellung in Anlehnung an [Bosc07], S. 201

- Programmspeicher, in dem das Anwenderprogramm verlustsicher abgelegt ist. Als Speichertechnologien werden nichtflüchtige Lesespeicher wie ROM^[4] , PROM^[5] , EPROM^[6] oder Flash-EPROM^[7] verwendet;
- Datenspeicher, in dem die Daten abgelegt sind, die sich während des Programmablaufs verändern. Auf diese Daten kann mittels RAM^[8] lesend und schreibend zugegriffen werden. Für Daten, die nach dem Abstellen des Fahrzeugs nicht gelöscht werden dürfen, wie z. B. Fehlereinträge im Fehlerspeicher, werden nichtflüchtige EEPROM^[9] Speicher eingesetzt;
- Bussystem, das die einzelnen Elemente des Mikrocontrollers verbindet;
- Taktgenerator, der dafür sorgt, dass alle Operationen im Mikrocontroller mit einer festgelegten Zeitrate ausgeführt werden;
- Überwachungsinstanz (Watchdog), die die Programmausführung überwacht.

([Bosc07], S. 200-201; [ScZu10], S. 48-49, 53-54)

Im Fahrzeug der 70er Jahre hatte bei der Einführung von Steuergeräten jedes Steuergerät eine explizit zugewiesene Funktion, die unabhängig von anderen Steuergeräten realisiert werden konnte. Eine immer weiter steigende Komplexität der Funktionen machte schließlich den Einsatz softwarebasierter Steuergeräte und den Datenaustausch zwischen ihnen erforderlich. So werden heute viele Funktionen nicht mehr nur von einem Steuergerät realisiert, sondern sind auf mehrere vernetzte Steuergeräte verteilt ([WaRe06], S. 196).

„ Ein verteiltes und vernetztes System besteht aus mehreren Subsystemen, die miteinander kommunizieren, wobei sowohl die Steuerung, als auch die Hardware und die Daten zumindest teilweise dezentral organisiert sind. […] Ein Steuergerätenetzwerk, wie es in Fahrzeugen eingesetzt wird, kann […] als verteiltes und vernetztes System bezeichnet werden.“ ([ScZu10], S. 79)

Durch verteilte und vernetzte Systeme wird nicht nur eine höhere Funktionalität dargestellt, sondern auch eine einfachere Erweiterbarkeit, größere Skalierbarkeit und eine Wiederverwendung von Komponenten kann realisiert werden ([ScZu10], S. 79).

2.2 Steuer- und Regelfunktionen

Allgemein sind Steuer - und Regelfunktionen die Hauptfunktionen der Steuergerätesoftware. Dabei ist nicht nur eine saubere und fehlerfreie Ausführung dieser Funktionen von Bedeutung, es werden besondere zeitliche Anforderungen an die Funktionsausführung gestellt. In der Praxis können Störgrößen die korrekte Ausführung verhindern. Daher werden in Steuergeräten derartige Betriebssysteme implementiert, die solche Anforderungen erfüllen können.

2.2.1 Steuerung und Regelung

Steuerung und Regelung lassen sich wie folgt definieren:

„ Das Steuern, die Steuerung, ist ein Vorgang in einem System, bei dem eine oder mehrere Größen als Eingangsgrößen andere Größen als Ausgangsgrößen aufgrund der dem System eigentümlichen Gesetzmäßigkeiten beeinflussen. Kennzeichen für das Steuern ist der offene Wirkungsweg. “ ([DIN95])

„Das Regeln, die Regelung, ist ein Vorgang, bei dem eine Größe, die zu regelnde Größe (Regelgröße), fortlaufend erfasst, mit einer anderen Größe, der Führungsgröße, verglichen und abhängig vom Ergebnis dieses Vergleichs im Sinne einer Angleichung an die Führungsgröße beeinflusst wird. Kennzeichen für das Regeln ist der geschlossene Wirkungskreislauf, bei dem die Regelgröße im Wirkungsweg des Regelkreises fortlaufend sich selbst beeinflusst.“ ([DIN95])

Mit anderen Worten besteht die Aufgabe der Steuerung und Regelung darin, dass bestimmte Größen (Regel- bzw. Steuergrößen X) auf einen bestimmten Wert gebracht und dort gehalten werden. Dazu ist es erforderlich, dass die entsprechenden Führungsgrößen W bekannt und zugänglich sind ([Schr09], S. 1). Die Führungsgrößen W können von dem Fahrzeugführer über einen Sollwertgeber (bspw. Schalter oder Pedale) oder von einem übergeordneten System vorgegeben werden ([ScZu10], S. 39).

Wenn der Zusammenhang zwischen W und X genau bekannt ist und durch die Störgrößen Z nicht beeinflusst werden kann, dann kann durch Verstellen von W der gewünschte X-Wert eingestellt und gehalten werden. Dieser Vorgang wird als Steuerung bezeichnet und wird beispielsweise zur Bemessung der Startmenge verwendet. Dabei werden die Auswirkungen der Steuerung nicht überprüft ([Bosc04], S. 124) ( Abbildung 2.3 ).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3 : Prinzip der Steuerung

Quelle: Eigene Darstellung in Anlehnung an [Bosc04], S. 124

Meistens ist der Zusammenhang zwischen W und X nicht genau bekannt, weil unbekannte Störgrößen Z vorhanden sind, deren Auftreten und zeitlicher Verlauf nicht vorhersehbar sind ([Schr09], S. 2). Um das System gezielt beeinflussen zu können, ist es erforderlich, die Regelkreise, wie in Abbildung 2.4 dargestellt, einzuführen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4 : Prinzip der Regelung

Quelle: Eigene Darstellung in Anlehnung an [Bosc04], S. 124

Die Regelgröße wird dabei ständig mit der Führungsgröße verglichen. Sobald eine Abweichung festgestellt wird, wird eine Korrektur in der Ansteuerung des Aktors (U) vorgenommen, so dass die Regelgröße den vorher vereinbarten Toleranzbereich nicht über- oder unterschreitet ([Bosc04], S. 124; [Schr09], S. 2).

2.2.2 Echtzeitbetriebssysteme

Zur Umsetzung der bereits erläuterten Steuer- und Regelaufgaben kommen Echtzeitbetriebssysteme zum Einsatz.

Nach [DIN85] werden Betriebssysteme allgemein folgendermaßen definiert:

„Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten des Rechensystems bilden und die insbesondere die Abwicklung von Programmen steuern und überwachen.“

Das Betriebssystem eines Steuergerätes ist im Vergleich zu den PC-Betriebssystemen extrem schlank und erfordert nur einige kByte an Speicher ([Borg10], S. 180). Da an die Ausführung der Regel- und Steuerfunktionen des Mikrocontrollers zeitliche Anforderungen gestellt werden, arbeiten die Betriebssysteme in Echtzeit, um jede Aufgabe fristgerecht abzuarbeiten ([Borg10], S. 180; [ScZu10], S. 60).

„ Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig derart betriebsbereit sind, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.“ ([DIN85])

Die auszuführenden Aufgaben werden als Tasks bezeichnet. Die Komponente des Betriebssystems, die die Rechenzeit des Mikroprozessors den Tasks zuteilt, wird als Scheduler bezeichnet. Für die Zuteilung des Prozessors existiert eine Vielzahl von verschiedenen Strategien ([Reif09], S. 41). Bei diesen Strategien müssen Entscheidungen über die Ausführungsreihenfolge getroffen werden, wenn mehrere Tasks um die Zuteilung des Prozessors konkurrieren ([ScZu10], S. 66).

Grundsätzlich wird zwischen statischen (zeitgesteuerten) und dynamischen (ereignisgesteuerten) Zuteilungsstrategien unterschieden. Bei einer dynamischen Strategie werden Zuteilungsentscheidungen erst während der Programmausführung getroffen. So kann flexibel auf die Ereignisse, etwa den „Fahrerwunsch“ oder von dem Sensor gemeldeten kritischen Wert reagiert werden. Dies erfordert allerdings einen höheren Aufwand im Vergleich zu den statischen Strategien. Bei einer statischen Zuteilungsstrategie werden alle Zuteilungsentscheidungen bereits vor der Ausführung des Programms getroffen; hier kann nur auf vorab festgelegte zeitabhängige Ereignisse reagiert werden. Daher muss bei der Strategiefestlegung genau definiert werden, ob das Laufzeitverhalten eines Systems fest definiert ist oder programmbedingt variabel bleiben muss ([ShZu10], S. 69).

2.2.3 Festlegung von Echtzeitanforderungen

Die Randbedingungen zum Zeitverhalten einer Task werden als Echtzeitanforderungen bezeichnet ( Abbildung 2.5 ). Sie können z. B. durch Aktivierungszeitpunkte und dazugehörige relative und absolute Deadlines oder durch eine Aktivierungsrate beschrieben werden ([ScZu10], S. 63).

Der Aktivierungszeitpunkt einer Task ist der Zeitpunkt, zu dem die Ausführung dieser Task freigegeben wird. Der Ausführungsstart dagegen ist der Zeitpunkt, zu dem die tatsächliche Taskausführung beginnt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 5 : Echtzeitanforderungen

Quelle: Eigene Darstellung in Anlehnung an [ScZu10], S. 62

Die Response-Zeit ist die Zeitspanne vom Aktivierungszeitpunkt bis zum Ende der Taskausführung. Die maximal zulässige Response-Zeit wird als relative Deadline bezeichnet. Als eine absolute Deadline wird der Zeitpunkt bezeichnet, zu dem die Taskausführung spätestens beendet sein muss.

Die Zeitspanne zwischen zwei Aktivierungen einer Task wird Aktivierungsrate genannt. Die Zeitspanne zwischen zwei Ausführungsstarten wird als Ausführungsrate bezeichnet ([Reif09], S. 36; [ScZu10], S. 62-63).

Dabei unterscheidet man zwischen harten und weichen Echtzeitanforderungen. Harte Echtzeitanforderungen müssen immer erfüllt sein, weiche dagegen sollen es nur ([Borg10], S. 180; [ScZu10], S. 63).

2.2.4 Zustände von Tasks

Die Betriebssysteme AUTOSAR OS ebenso wie OSEK OS unterscheiden vier Zustände, die die Tasks annehmen können ([Auto11a], S. 68; [ScZu10], S. 64-66). Diese sind in Abbildung 2.6 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 . 6 : Taskzustände

Quelle: Eigene Darstellung in Anlehnung an [Auto11a ], S. 68

Beim Systemstart ist der Zustand jeder Task „suspended“. Sobald eine Task von dem Scheduler aktiviert (activate) ist, geht sie in den Zustand „ready“ über und bleibt in dem solange, bis ihre tatsächliche Ausführung beginnt (start) und die Task den Zustand „running“ annimmt. Diesen Zustand kann die Task auf drei Wegen verlassen:

- Die Ausführung der Task kann beendet sein (terminate), dann wechselt die Task wieder in den Zustand „suspended“.
- Sofern die Ausführung einer Task unterbrochen werden muss, weil eine andere höher priorisierte Task diese verdrängt (preempt), nimmt die verdrängte Task den Zustand „ready“ an und wartet, bis ihre Ausführung fortgesetzt werden kann.
- Die Task kann ihre Ausführung selbst unterbrechen, wenn sie auf Eintreten eines Ereignisses warten muss (wait) und geht dann in den Zustand „waiting“ über. Sobald das erwartete Ereignis eintritt (release), ist die Task wieder ausführungsbereit und wechselt in den Zustand „ready“ ([ScZu10], S. 64-66).

Der Scheduler aktiviert die Tasks anhand sogenannter Schedule Tabellen (Schedule Table), in denen die bereits während der Entwicklungsphase vordefinierten zeitlichen Taskabläufe gespeichert sind. Der Ablauf der Schedule Tabelle wiederholt sich periodisch. Bei Bedarf kann es auf eine andere Tabelle umgeschaltet werden ([ZiSc08], S. 303), wenn z B. eine Task ihren zeitlichen Rahmen überschreitet. Zwar werden die Tasks zu einem vordefinierten Zeitpunkt in den Zustand „ready“ versetzt, wann sie aber tatsächlich ablaufen dürfen, hängt von ihrer Priorität ab. Daher ist es äußerst wichtig, bei der Entwicklung geeignet hohe Prioritäten festzulegen und eine sorgfältige statische Ablaufanalyse durchzuführen, um einen streng deterministischen Ablauf gewährleisten zu können ([ZiSc08], S. 303).

2.3 Standardisierung

In der Praxis wächst mit steigender Funktionalität gleichzeitig die Komplexität eingebetteter Systeme im Fahrzeug. Die Softwareentwickler müssen oft dieselbe Software für unterschiedliche Automobilhersteller von Grund auf neu entwickeln, weil diese auf unterschiedliche Technologien setzen. Das erweist sich als zeitaufwendig und fördert das Streben nach Standardisierung. So sagte Dr. Elmar Degenhardt, CEO der Continental AG, auf dem 15. Fachkongress „Fortschritte in der Automobil-Elektronik“ in Ludwigsburg: „Alles, was nicht der Markendifferenzierung der Automobilhersteller dient, muss standardisiert werden“ ([Voll11], S. 18).

Hier sollen nun beispielhaft die wichtigsten Standardisierungsgremien und deren Arbeit vorgestellt werden.

Offene Systeme für die Elektronik im Kraftfahrzeug (OSEK) ist eine Initiative der deutschen Automobilindustrie, die 1993 gegründet wurde und in Zusammenarbeit mit der Initiative der französischen Automobilindustrie Vehicle Distributed executive (VDX) Standards für Echtzeitbetriebssysteme, Netzwerkverwaltung und Kommunikationsschnittstellen im Fahrzeug definierte. Diese Definition erstreckte sich allerdings über einen längeren Zeitraum, weshalb die in früheren Definitionen enthaltenen Lücken von verschiedenen Anbietern eigenständig geschlossen wurden. Das erklärt die Vielzahl inkompatibler Versionen der OSEK/VDX-Spezifikationen ([Borg10], S. 183; [ZiSc08], S. 261, 264). Die Weiterentwicklung der OSEK/VDX-Standards erfolgt seit 2003 im Rahmen von AUTOSAR, die im Abschnitt 2.4 präsentiert wird.

Die Association for Standardization of Automation and Measuring Systems (ASAM) ist eine Initiative der europäischen Automobilhersteller und deren Zulieferer, die sich mit der Standardisierung der Datenaustausch- und Datenbeschreibungsformate sowie der Schnittstellen zwischen einzelnen Prüfständen beschäftigt. ASAM-MCD, Standardgruppe für Messen, Kalibrieren und Diagnose (auch als Automotive Electronics AE bezeichnet), definiert insgesamt drei Schnittstellen: die zu den Steuergeräten (ASAM 1), die zur Steuergerätedatenbank (ASAM 2) und die zu den Test- und Diagnoseanwendungen (ASAM 3) ([ZiSc08], S. 169-170).

Als Busprotokoll zu den Steuergeräten für den Bereich Messen-Kalibrieren (ASAM MCD 1MC) wurde Universal Measurement and Calibration Protocol XCP definiert, das unterschiedliche Netzwerkvarianten wie CAN, FlexRay, USB sowie Ethernet berücksichtigt. Für Diagnoseaufgaben definiert ASAM keine eigenen Standards und verweist auf etablierte Protokolle KeyWord Protocol 2000 (KWP 2000) und Unifield Diagnosis Service (UDS) ([ZiSc08], S. 171).

Als Datenbeschreibungsformat für Diagnosedaten (ASAM MCD 2D) wurde XML-basiertes Open Data Exchange-Format (ODX) definiert, der diese unter Verwendung UML-Diagramme visuell darstellt ([ZiSc08], S. 219). Für die Beschreibung der On-Board-Kommunikation zwischen den Steuergeräten wurde Field Bus Exchange Format (FIBEX) vorgeschlagen, das ebenfalls XML-basiert ist und als Datenbeschreibungsformat für unterschiedliche Bussysteme einsetzbar ist ([ZiSc08], S. 203).

ASAM MCD 3 definiert eine einheitliche Schnittstelle zu Mess-, Kalibrier- und Diagnosewerkzeugen, um diese nicht für jedes Fahrzeug und/oder Steuergerät erneut programmieren zu müssen. Der sogenannte MCD 3 Server kann sich selbst über MCD 2-Beschreibungsdateien auf einzelne Fahrzeuge und deren Steuergeräte parametrieren und konfigurieren ([ZiSc08], S. 212).

[...]

---

^[1] USB (Universal Serial Bus) – ein serielles Bussystem zur Verbindung zwischen einem Computer und externen Geräten.

^[2] Bluetooth – ein Industriestandard für die kabellose Datenübertragung zwischen Geräten über eine kurze Distanz.

^[3] Von den Aspekten der Kostensenkung und Kosteneffizienz wird in diesem Projektseminar bewusst abstrahiert.

^[4] ROM (Read Only Memory) ist ein Langzeitspeicher. Dieser erlaubt einen direkten lesenden Zugriff auf alle Speicherplätze. Die Inhalte können nur gelesen, und nicht überschrieben werden ([Bosc07], S. 203).

^[5] PROM (Programmable ROM) ist ein programmierbarer Festwertspeicher. Die Daten können „durch entsprechende Programmierung an speziell vorbereiteten Speichern eingeschrieben werden“ ([Bosc07], S. 203).

^[6] EPROM (Erasable PROM) ist ein Wiederbeschreibbarer Festwertspeicher. Dessen Inhalte können durch UV- Bestrahlung gelöscht und auf einer speziellen Programmierstation neu programmiert werden ([Bosc07], S. 203).

^[7] Flash (auch Flash- EPROM genannt) ist eine Weiterentwicklung von EPROM und EEPROM. Entscheidender Vorteil liegt darin, dass Flash-Speicher auch im geschlossenen und im Fahrzeug verbauten Steuergerät umprogrammiert werden kann ([Bosc07], S. 203).

^[8] RAM (Random Access Memory) ist ein Kurzzeitspeicher, der einen direkten Zugriff auf alle Speicherplätze erlaubt. Die Daten können beliebig oft eingeschrieben und ausgelesen werden ([Bosc07], S. 203).

^[9] EEPROM (Electrical EPROM) ist wiederbeschreibbarer Festwertspeicher, dessen Inhalte elektrisch gelöscht und neu programmiert werden können. Jede Speicherzelle kann dabei einzeln überschrieben werden ([Bosc07], S. 203).