Schedulingsynthese Und Implementierung Einer FlexRay Anwendung Fuer Ein Fahrerloses Transportsystem

Hochschule für Angewandte Wissenschaften Hamburg
Hamburg University of Applied Sciences
Masterarbeit
Dirk Ewerlin
Schedulingsynthese und Implementierung

einer FlexRay-Anwendung für ein
fahrerloses Transportsystem
Fakultät Technik und Informatik Faculty of Engineering and Computer Science

Department Informatik Department of Computer Science
Dirk Ewerlin
Schedulingsynthese und Implementierung
einer FlexRay-Anwendung für ein fahrerloses Transportsystem
Masterarbeit eingereicht im Rahmen der Masterprüfung

im Studiengang Informatik
am Department Informatik
der Fakultät Technik und Informatik
der Hochschule für Angewandte Wissenschaften Hamburg
Betreuender Prüfer: Prof. Dr.-Ing. Bernd Schwarz

Zweitgutachter: Prof. Dr. Franz Korf
Abgegeben am 19. Dezember 2008

Dirk Ewerlin
Thema der Masterarbeit

Schedulingsynthese und Implementierung einer FlexRay-Anwendung für ein fahrer-
loses Transportsystem
Stichworte
Verteilte Hard-Real-Time-Anwendungen, zeitgesteuerte Kommunikation, FlexRay,
eingebettete Systeme, statisches Offline-Scheduling, fahrerloses Transportsystem,
Fahrerassistenzsystem, Time-Triggered Software-Konzept, Transformation Event-
Triggered in Time-Triggered
Kurzzusammenfassung
Diese Masterarbeit beschreibt die Synthese und Implementation einer eingebet-
teten Echtzeit-Anwendung für ein fahrerloses Transportsystem. Die Scheduling-
synthese umfasst die Analyse vorhandener Anwendungen und die Modellierung
in einem Conditional Process Graph, sowie die abgestimmte Einplanung zeitge-
steuerter Tasks und zeitgesteuerter Kommunikation durch ein statisches Offline-
Schedulingverfahren. Das Scheduling einer vorhandenen zeitgesteuerten Anwen-
dung zur Koordinierung der Antriebssteuerung wird nach dem hier vorgestellten
Schedulingverfahren durchgeführt. Erweitert wird diese Anwendung um ein An-
tikollisionssystems, das von einer ereignisgesteuerten Ausführung zu einer zeitge-
steuerten Ausführung transformiert wird. Die Plattform besteht aus Renesas M32C-
Knoten, die über den FlexRay-Bus verbunden sind. Es wird eine Analyse des Ti-
mings der Nachrichtenübertragung und Taskausführung durchgeführt.
Title of the paper

Scheduling Synthesis and Implementation of a FlexRay-Application for an automa-
ted guided transport system
Keywords
Distributed Hard Real-Time-Applications, Time-Triggered Communication, Flex-
Ray, Embedded Systems, Static Offline-Scheduling, Automated Guided Transport
Systems, Driver Assistance System, Time-Triggered Software Concept, Transforma-
tion Event-Triggered to Time-Triggered
Abstract
This master thesis describes the synthesis and implementation of a embedded real-
time application for automated guided transport system. The scheduling synthesis
includes the analysis of an existing application and the modeling as an conditional
process graph, as well as the concerted plannning of time-triggered tasks and time-
triggered communication supported by an static offline scheduling procedure. The
scheduling of an existing application of an drive control system will be executed
by this scheduling procedure. The application will be extended by an anti-collision
system which will be transformed from an event-triggered to and time-triggered exe-
cution. The platform consists of Renesas M32-C-Nodes, which are connect via the
FlexRay-Bus. A timing analysis of the communication and task execution will be
performed.
Danksagung
An dieser Stelle möchte ich den Personen danken, die mich während dieser Abschlussarbeit
unterstützt haben.
An erster Stelle möchte ich mich bei Herrn Prof. Dr.-Ing. Bernd Schwarz für die investierte Zeit
und die hervorragende Betreuung, sowohl als Ansprechpartner als auch als Erstprüfer, bedan-
ken. Ebenso gilt mein Dank Herrn Prof. Dr. Franz Korf für seine Arbeit und Unterstützung als
Zweitprüfer.
Mein ganz besonderer Dank gilt meiner Frau Silke, die mich während dieser Arbeit besonders
unterstützt hat und mir stets zur Seite stand. Ihr und unserer Tochter Lena Sophia danke ich,
dass sie mich die ganze Zeit motiviert haben, sowie auf viele Gemeinsamkeiten verzichten
mussten.
Ein besonderer Dank geht auch an meine Kollegen Uwe Gaack und Lutz Koellner der Firma
TechSAT, die mich während des Studiums stets unterstüzt haben.
Inhaltsverzeichnis
1 Einleitung 1
2 Das fahrerloses Transportsystem SCV 4
3 Zeitgesteuerte Architektur im Automobil 7

3.1 Zeitgesteuerte Architektur im Automobil . . . . . . . . . . . . . . . . . . . . . 7
3.2 Zeitgesteuerte Task-Aktivierung . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Das Kommunikationssystem FlexRay . . . . . . . . . . . . . . . . . . . . . . 10
4 Übersicht zu Entwurfskonzepten für verteilte zeitgesteuerte Systeme 14

4.1 SymTA/S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 TDL - Timing Definition Language . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Timmo Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Schedulingverfahren für verteilte Echtzeitsysteme . . . . . . . . . . . . . . . . 21
4.5 Schwerpunkte der Ansätze im Vergleich . . . . . . . . . . . . . . . . . . . . . 21
5 Entwurfsgrundlagen für die Implementation des zeitgesteuerten Antikollisionssys-

tems 24
5.1 Software-Konzept für verteilte zeitgesteuerte Anwendungen . . . . . . . . . . 24
5.2 Verfahren zum abestimmten Scheduling von verteilten Echtzeit-Anwendungen . 35
6 Systemübersicht zum AKS und Timing-Analyse der Renesas-Zielplattform 44

6.1 Systemübersicht zum ereignisgesteuerten Antikollisionssystem . . . . . . . . . 44
6.2 Systemübersicht zur zeitgesteuerten Antriebsregelung und Fahrzeugkoordinie-
rung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3 Anwendungsrandbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4 Umsetzungskonzept für das ttAKS . . . . . . . . . . . . . . . . . . . . . . . . 53
7 Implementierung des zeitgesteuerten AKS 56

7.1 Modellierung der Antriebsregelung und Fahrzeugkoordinierung . . . . . . . . 56
7.2 Modellierung und Transformation des etAKS in eine zeitgesteuerte Ausführung 64
7.3 Zusammenführung der Funktionen des ttAKS . . . . . . . . . . . . . . . . . . 77
7.4 Scheduling-Analyse des ttAKS . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5 Implementation der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . 82
8 Timinganalyse des zeitgesteuerten Antikollisionssystems 85

8.1 Timing-Messungen zur zeitgesteuerten Kommunikation . . . . . . . . . . . . . 85
8.2 Timing-Messung der zeitgesteuerten Taskausführung . . . . . . . . . . . . . . 88
9 Weitere Entwicklungsschritte 90
10 Zusammenfassung 91
Abbildungsverzeichnis 92
Tabellenverzeichnis 94
Quellcodeverzeichnis 95
Glossar 96
Abkürzungsverzeichnis 100
Literaturverzeichnis 101
A Ergänzende Angaben zum Software-Konzept für verteilte, zeitgesteuerte Anwen-

dungen 104
A.1 Anwendungsmodellierung in einem Prozessgraphen . . . . . . . . . . . . . . . 104
A.2 Scheduling-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
A.3 Ausgewählter Quellcode zum Softwarekonzept für zeitgesteuerte Anwendungen 107
A.4 Ergänzende Angaben zur etAKS-Systemübersicht . . . . . . . . . . . . . . . . 112
B etAKS-Funktionen und deren Quelldateien 113
C Timing-Messungen auf der Zielplattform 114

C.1 Timing-Messungen von Berechnungsoperation auf der Renesas-Plattform . . . 114
D Ergänzungen zur Modellierung des ttAKS 120

D.1 Modellierungsansatz 3 für die Gleichzeitigkeitsbeziehungen in der Antriebsre-
gelung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
D.2 Timing-Messungen der ttAKS-Funktionen . . . . . . . . . . . . . . . . . . . . 122
D.3 Timing-Messung ISR-Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . 128
D.4 CAN-Trace der Messwerterfassung vom Laserscanner . . . . . . . . . . . . . 128
E Ergänzung zur Implementation des ttAKS 132

E.1 CPG zur kompletten Anwendungsrunde des ttAKS . . . . . . . . . . . . . . . 132
E.2 Ausgewählter Quelltext zur Dispatcher-Erweiterung . . . . . . . . . . . . . . . 135
F Daten zum Schedulings des ttAKS 137
G Timing-Messungen der ttAKS-Kommunikation über FlexRay 145

1 Einleitung
Die Integration von Sicherheitssystemen ins Automobil wie Anti-Blockiersystem (ABS) und
Electronic Stability Program (ESP) bewirkte in den letzten 50 Jahren eine starke Reduzierung
der Anzahl an Todesfälle und Verletzungen bei Unfällen. Heute gehen die Automobilhersteller
weiter und entwickeln Fahrerassistenzsysteme, die den Fahrer mit Informationen versorgen und
Unfälle verhindern. In den letzten 10 Jahren sind Fortschritte in elektronischen Systemen und
Design-Techniken gemacht worden, die die Umsetzung dieser Systeme realisierbar macht. Den
Anfang der Fahrerassistenzsystemen machten Einparkhilfen, die akustisch den Abstand zum
Hindernis angeben. Durch weitere technologische Fortschritte gibt es heute Systeme für das
automatische Einparken eines Fahrzeugs. Experten meinen, dass dieses erst der Anfang der
Fahrerassistenzsysteme sei [Xcelljournal (2008)].
Die Steuereinheiten eines Fahrzeugs sind meist in einem Netzwerk über das ganze Fahrzeug
verteilt und bestehen aus unterschiedlichen Hardware-Komponenten. Fahrerassistenzsysteme
mit übergeordneten Aufgaben lassen sich als verteilte Regelung betrachten, die auf die lo-
kal verteilten Steuergeräte zugreifen. Eine Aufteilung der Infrastruktur in zeitgesteuerte und
ereignisgesteuerte Netzwerke kann durch funktionsspezifische Anforderungen an das determi-
nistische Antwortverhalten der Netzwerkkomponenten gebunden sein. Die stetige Zunahme des
Funktionsumfangs in Automobilen, vor allem im Bereich der Fahrerassistenzsysteme, bedingen
neben der Steigerung der Auslastung vorhandener Steuergeräte auch eine Zunahme an Steuer-
geräten im Netzwerk. Mit der steigenden Anzahl an Funktionen und Busteilnehmern, die über
einen ereignisgesteuerten Bus wie CAN kommunizieren, nimmt auch die zu übermittelnde Da-
tenmenge zu. In einem System mit ereignisgesteuerter Kommunikation führt die höhere Da-
tenmenge zu Kollisionen und so zu längeren Antwortzeiten. Wird die Datenrate zu hoch, kann
es dazu führen, dass das Antwortverhalten nicht mehr vorhersagbar ist. Dieses kann in Fahrer-
assistenzsystemen, die auf aktuelle Sensordaten zur Steuerung des Fahrzeugs angewiesen sind,
zu fatalen Folgen führen [Elektr. Automot. (2002)].
Eine Lösung hierfür ist ein System bestehend aus einer zeitgesteuerten Task-Ausführung und
einem zeitgesteuerten Kommunikationssystem wie FlexRay. In einem zeitgesteuerten Bussys-
tem erhält jedes an den Bus angeschlossene Steuergerät eine feste Zeitspanne zur Übertragung
seiner Daten, so dass die Zeitpunkte der Datenübertragung festgelegt sind und es dadurch kei-
nen Jitter wie bei ereignisgesteuerten Bussystemen gibt. Dieses führt zu einem vorhersagbaren,
garantiertem Antwortverhalten. Zusätzlich lässt sich die Datenrate erhöhen, da die Zeitfenster
zur Datenübertragung bekannt sind und keine Kollisionen auf dem Bus entstehen. Die Kopp-
lung aus zeitgesteuerter Task-Ausführung und Datenübertragung erlaubt die Abstimmung der
Task-Ausführung und Datenübermittlung. Diese Kopplung hat vor allem in komplexen Anwen-
dungen, wie Fahrerassistenzsysteme, den Vorteil, dass die Tasks zur Erfassung von Daten, die
Datenübermittlung und die Tasks zur Auswertung und Regelung schnelle Reaktionszeiten lie-
fern.
1 Einleitung 2
Die Umsetzung einer solchen Architektur macht es notwendig, die Task-Ausführung und die
Kommunikation zeitlich aufeinander abzustimmen. In der Industrie sind Werkzeuge wie der
Electrobit tresos Designer im Einsatz, die die Konfiguration des zeitgesteuerten Busses Flex-
Ray unterstützen [EB (2007)]. Der Entwickler definiert Parameter des FlexRay-Protokolls wie
Slotlänge und Slotreihenfolge. Mit Hilfe eines Dispatchers und Timers lässt sich eine zeitge-
steuerte Tasks-Ausführung z. B. auf einem Mikrocontroller realisieren. Der Markt bietet derzeit
kein Werkzeug, das sowohl die Planung der Task-Ausführung und Kommunikation als auch die
Abstimmung zwischen der Task-Ausführung und Kommunikation in einem verteilten, zeitge-
steuerten System unterstützt.
Im Teilprojekt Sensor Controlled Vehicle (SCV) des Projekts Fahrerassistenz- und Autono-
me Systeme (FAUST) an der HAW Hamburg wurde eine zeitgesteuerte Anwendung in einem
prototypischen System umgesetzt. Hierzu wurde ein Software-Konzept im Rahmen einer Mas-
terarbeit entwickelt [Sellentin (2006)]. Dieses Konzept bietet Methoden zur Einplanung von
Tasks in einem verteilten, zeitgesteuerten System. Die Einplanung der Kommunikation in Ab-
stimmung mit der Task-Ausführung wird berücksichtigt, indem die Kommunikation mit einer
Ausführungszeit eingeplant wird. Bei der Einplanung wird jedoch nicht die Konfiguration des
FlexRay-Protokolls während des Schedulings berücksichtigt. Somit bietet es keine Lösung für
komplexe Anwendungen mit einer hohen Datenrate.
In dieser Arbeit wird die Synthese und Implementation einer eingebetteten, verteilten Echtzeit-
Anwendung für ein fahrerloses Transportsystem dokumentiert. Dazu wurden die folgenden In-
halte bearbeitet:
• Es werden Methoden zur Analyse und Modellierung von verteilten Echtzeitanwendungen

vorgestellt.
• Das zur Implementation der Anwendung genutzte Verfahren zum abgestimmten stati-
schen Offline-Scheduling von zeitgesteuerten Tasks und Nachrichten wird dargestellt.
• Die vorgestellten Methoden zur Modellierung und zum Scheduling werden zur Imple-
mentation eines zeitgesteuertes Antikollisionssystem (ttAKS) angewendet.
• Im Projekt FAUST wurde im Rahmen einer Masterarbeit [Schetler (2007)] ein ereignisge-
steuertes Antikollisionssystem (etAKS) implementiert. Diese Anwendung wird in dieser
Arbeit von einer ereignisgesteuerten Ausführung in eine zeitgesteuerte Ausführung als
ttAKS transformiert. Dabei werden die Tasks, die auf einem Rechner mit Pentium-CPU
zum Einsatz kamen, so transformiert, dass sie zeitgesteuert auf einem Mikrocontroller
ausführbar sind.
• Die Tasks des ttAKS benötigen aufgrund der enthaltenen Numerik eine längere Aus-
führungszeit auf dem Mikrocontroller, wodurch Anpassungen der Abtastraten notwendig
sind.
• Zur Implementation des ttAKS wird das in einer Masterarbeit entwickelte Software-
Konzept für eine zeitgesteuerte Antriebsregelung und Fahrzeugkoordinierung [Sellentin
(2006)] vervollständigend dokumentiert, auf die Anwendbarkeit untersucht und teilweise
angewendet.
1 Einleitung 3
• Abschließend wird eine Timing-Analyse für die zeitgesteuerte Task-Ausführung und

Kommunikation durchgeführt.
Die Dokumentation umfasst folgende Kapitel:
• Im Kapitel 2 wird das Sensor Controlled Vehicle vorgestellt. Es wird die ereignisgesteu-
erte Ausgangsplattform des etAKS, sowie die zeitgesteuerte Zielplattform für das ttAKS
beschrieben.
• Ein Überblick der Eigenschaften einer zeitgesteuerten Architektur und deren Notwendig-
keit für sicherheitsrelevante Anwendungen im Automobil wird in Kapitel 3 dargestellt.
Des Weiteren werden die für diese Anwendung wesentlichen Eigenschaften des Kommu-
nikationssystem FlexRay dokumentiert.
• Das Kapitel 4 gibt einen Überblick zu Entwurfskonzepten und Werkzeugen für verteilte,
zeitgesteuerte Systeme und zeigt deren Anwendbarkeit für die ttAKS-Anwendung auf der
zeitgesteuerten Zielplattform.
• Im Kapitel 5 werden Methoden betrachtet, die für die Ausführung, die Modellierung und
das Scheduling der Anwendung angewendet werden. Dabei wird die Dokumentation des
in einer Masterarbeit entwickelten Software-Konzept vervollständigt und auf dessen An-
wendbarkeit für die Implementation des ttAKS untersucht. Berichte zur Modellierung
und zum Scheduling einer zeitgesteuerten Anwendung werden dargestellt und die in die-
ser Arbeit angewendeten Methoden für die Implementation des ttAKS herausgestellt.
• Eine Übersicht über die etAKS-Anwendung, sowie die zeitgesteuerte Anriebsregelung

und Fahrzeugkoordinierung wird in Kapitel 6 gegeben. Zudem werden die Anwendungs-
randbedingungen aufgestellt und das Vorgehen zur Implementation des ttAKS beschrie-
ben.
• Das Kapitel 7 berichtet über die Modellierung und Implementierung des ttAKS. Es
werden die Funktionen des etAKS in eine zeitgesteuerte Ausführung transformiert,
auf der Zielplattform implementiert und Timing-Messungen zur Bestimmung der Task-
Ausführungszeit durchgeführt. Die aufgrund der Task-Ausführungszeiten notwendige
Anpassung der Abtastraten wird durchgeführt. Anschließend wird für die zeitgesteuer-
ten Funktionen ein Task- und Nachrichten-Schedule generiert und auf der Zielplattform
implementiert.
• Im Kapitel 8 werden Timing-Messungen zur Verifizierung der Schedules zum ttAKS

durchgeführt.
• Die beiden letzten Kapitel 9 und 10 zeigen weitere Entwicklungsschritte und geben eine
Zusammenfassung dieser Arbeit.
2 Das fahrerloses Transportsystem SCV
Das Projekt fahrerloses Transportsystem SCV ist ein Teilprojekt des Projekts Fahrerassistenz-
und autonome Systeme im Department Informatik an der HAW Hamburg. Das Sensor Con-
trolled Vehicle (Abb. 2.1) bietet eine autonom gesteuerte Transportplattform mit dem Ziel,
sich autonom fortzubewegen und eigenständig Fahraufträge abzuarbeiten. Innerhalb des Pro-
jekts werden verschiedene Konzepte von Fahrerassistenzsystemen durchdrungen und in der
Praxis erprobt [HAW (2008)]. Das Projekt befasst sich mit Sensorik, Bildverarbeitung, Mo-
dellierung und FPGA basierter Signalverarbeitung. Dabei kommen aktuelle Technologien wie
ein FlexRay-Netz zum Einsatz. Bisher wurden im Rahmen von Masterarbeiten ein Ausweich-,
ein Brems- und ein Einparkassistent am Fahrzeug entwickelt.
Abb. 2.1: Fahrerloses Transportfahrzeug SCV [Schetler (2007)]
Das Transportsystem wird über einen Leitstand, Standard-PC mit WLAN-Anbindung, gesteuert
(Abb. 2.2). An diesem PC sind zur Steuerung ein Lenkrad und zwei Pedale für die Vorwärts-
und Rückwärtsbewegung angeschlossen. Zusätzlich sind über Schalter Fahrerassistenzfunktio-
nen verfügbar. Die vom Benutzer erzeugten Soll-Werte für Geschwindigkeit und Lenkwinkel
werden über WLAN und Ethernet an den Kommunikationsserver des Fahrzeugs übertragen. Der
weitere Aufbau der Plattform unterscheidet sich in der ereignisgesteuerten und zeitgesteuerten
Plattform.
Die ereignisgesteuerte Plattform
Das ereignisgesteuertes Antikollisionssystem (etAKS) kommt auf der ereignisgesteuerten Platt-

form zur Ausführung (Abb. 2.2). Es werden zwei ARM7-TDMI-Mikrocontroller eingesetzt, die
die Aufgaben der Antriebsregelung übernehmen. Das etAKS und die Fahrzeugkoordinierung
werden auf einem GEME-Rechner mit Pentium-CPU ausgeführt. Die vom Leitstand erzeugten
Soll-Werte für Geschwindigkeit und Lenkwinkel werden an den Koordinierungsrechner über-
tragen. Als Alternative werden über die Führungsbox Soll-Werte vorgegeben, die ebenfalls vom
Koordinierungsrechner empfangen werden. Dieser prüft, welche Soll-Werte gültig sind und gibt
diese an die ARM-Controller weiter. Diese Messen die Ist-Werte am vorderen und hinteren Rad
und berechnen mit den Soll-Werte die Stell-Größen für die Antriebseinheiten.
Abb. 2.2: Systemübersicht zur ereignisgesteuerten Plattform [Sellentin (2006)]
Das etAKS wird auf einem ADLINK GEME 2000 Industrierechner ausgeführt. Dieser verfügt
über eine Intel Pentium III CPU mit 650 MHz und 128 MB RAM sowie eine Floating Point Unit
(FPU) [ADLINK (2007)]. Als Betriebssystem wird QNX Neutrino 2 verwendet [QNX Softwa-
re Systems (2008)]. Das Scheduling und die Aktivierung der Tasks wird vom Betriebssystem
verwaltet, wodurch keine vorherige Planung des Task-Schedules erforderlich ist.
Die zeitgesteuerte Plattform
Eine Anwendung zur zeitgesteuerten Antriebsregelung und Fahrzeugkoordinierung wurde im

Rahmen einer Masterarbeit [Sellentin (2006)] auf zwei Renesas-M32C/85-Mikrocontrollern
implementiert, die an ein FlexRay-Netz angeschlossen sind (Abb. 2.3). Auf dieser Plattform
wird das zeitgesteuertes Antikollisionssystem (ttAKS) zur Ausführung kommen. Die in der er-
eignisgesteuerten Ausführung auf dem ARM7-Mikrocontroller und dem Koordinierungsrech-
ner implementierten Funktionen wurden in der zeitgesteuerten Ausführung auf zwei Renesas-
Mikrocontrollern integriert. In der zeitgesteuerten Ausführung werden die Soll-Werte des Leit-
standes an den Mikrocontroller Renesas Vorne weitergegeben, der die Funktionen des Koordi-
nierungsrechners übernimmt. Die Ist-Werte der beiden Räder werden an den beiden Renesas-
Knoten gemessen. Aus den Ist-Werten und den Soll-Werten werden auf dem Knoten Renesas
Hinten Stellgrößen für die Antriebseinheiten generiert.
Abb. 2.3: Systemübersicht zur zeitgesteuerten Plattform [Sellentin (2006)]
Im Rahmen einer Masterarbeit wurde ein „zeitgesteuertes, verteiltes Software-Konzept imple-

mentiert auf FlexRay-Knoten“ erarbeitet [Sellentin (2006)]. Es wurde ein Scheduling-Verfahren
und ein Konzept zur zeitgesteuerten Taskaktivierung entwickelt. Die Ergebnisse werden in die-
ser Masterarbeit auf die Anwendbarkeit für die hier vorgestellte Schedulingsynthese und Im-
plementation untersucht.
Die Hardware besteht aus zwei Knoten aus dem DECOMSYS::NODE<RENESAS> StarterKit
[DECOMSYS StarterKit (2006)]. Die Knoten enthalten einen RENESAS M32C/85 Mikrocon-
troller, der mit einer Taktrate von 24 MHz arbeitet [Renesas HW-Man (2005)]. Der Mikrocon-
troller verfügt über einen Adressraum von 24 Bit, vier 8-Bit und zwei 16-Bit Register, die zu
zwei 32-Bit Registern zusammengefügt werden können. Der Mikrocontroller verfügt über kei-
ne FPU, wodurch Berechnungen nur in Ganzzahlen durchgeführt werden. Der CPU stehen 2
MB statisches RAM und 2 MB Flash-Speicher zur Verfügung. Als FlexRay-Controller kommt
ein ALTERA Cyclone-II zum Einsatz, der auf dem Bosch e-ray-Design basiert. Der Mikro-
controller bietet als Kommunikationsschnittstellen zwei CAN-, einen LIN- und zwei FlexRay-
Transceiver. Des Weiteren gibt es eine RS-232-Schnittstelle und mehrere digitale und analoge
Ein-/Ausgänge.
3 Zeitgesteuerte Architektur im
Automobil
Fahrerassistenzsysteme werden durch Steuergeräte modular aufgebaut, die lokal begrenzte Auf-
gaben durchführen. Durch die Vernetzung der einzelnen Steuergeräte über ein Kommunika-
tionsnetz sind übergeordnete Aufgaben implementierbar. Zukünftige Fahrerassistenzsysteme
sind verteilte Systeme mit Regelkreisen, die über ein Kommunikationsnetz geschlossen werden
und sehr hohe Echtzeitanforderungen erfüllen müssen. Zeitgesteuerte Architekturen erfüllen
diese Echtzeitanforderungen. Deren Kerneigenschaft ist die statische, zeitlich festgelegte Ak-
tivierung von Funktionen im verteilten Softwaresystem. Mit Hilfe dieses Prinzips lassen sich
darauf aufbauende Konzepte wie Fehlertoleranz durch Redundanzen implementieren.
Eine zeitgesteuerte Architektur bildet die Grundlage für die in dieser Masterarbeit zu implemen-
tierende FlexRay-Anwendung. Es wird hier ein Überblick zu einer zeitgesteuerten Architektur,
einer zeitgesteuerten Taskaktivierung und dem Kommunikationssystem FlexRay gegeben und
deren Eigenschaften herausgestellt.
3.1 Zeitgesteuerte Architektur im Automobil
Der folgende Abschnitt beschreibt die Eigenschaften einer zeitgesteuerten Architektur. Es wer-
den die Merkmale eines Echtzeitsystems und eines verteilten Echtzeitsystems dargestellt, sowie
eine Gegenüberstellung zu einer ereignisgesteuerten Architektur durchgeführt.
3.1.1 Eigenschaften einer zeitgesteuerten Architektur
Ein Echtzeitsystem zeichnet sich dadurch aus, dass zu festgelegten Zeitpunkten Aktivitäten
bzw. Tasks ausgeführt werden [Kopetz (1997)]. Im Allgemeinen werden die folgenden Anfor-
derungen an ein Echtzeitsystem gestellt:
• Rechtzeitigkeit: Die Erfassung, Verarbeitung und Ausgabe von Daten und den daraus
abgeleiteten Reaktionen müssen so ausgeführt werden, dass die Reaktion innerhalb von
bestimmten Zeitschranken erfolgt. Die Korrektheit des Systems hängt nicht nur von dem
Berechnungsergebnis ab, sondern auch davon, wann das Ergebnis produziert wird.
• Gleichzeitigkeit: Das Rechnersystem soll mehrere Teilvorgänge zur gleichen Zeit kon-
trollieren.
• Zuverlässigkeit: Die Zuverlässigkeit eines Rechnersystems ist dann von Bedeutung,

wenn ein Ausfall zur Gefährdung von großen Sachwerten oder Menschenleben führen
kann.
• Verfügbarkeit: Ein Rechnersystem soll sich zu einem vorgegebenen Zeitpunkt mit einer
bestimmten Wahrscheinlichkeit in einem funktionsfähigen Zustand befinden.
• Vorhersehbarkeit: Alle Aktionen des Rechnersystems sind vor der Laufzeit bekannt und
müssen deterministisch sein, besonders bei Überlast- und Fehlersituationen.
Ein verteiltes Echtzeitsystem besteht aus einer Anzahl von Knoten und Steuergeräten, die über
ein Bussystem miteinander verbunden sind. Die zeitgesteuerte Architektur wird durch ein zeit-
gesteuertes Kommunikationssystem und eine zeitgesteuerte Task-Aktivierung umgesetzt. Die
Eigenschaften einer zeitgesteuerten Architektur lassen sich wie folgt zusammenfassen:
• Es ist eine global synchronisierte Zeit verfügbar, auf die sich alle Knoten beziehen und
nach der die Tasks aktiviert werden.
• Die Zeitpunkte für die Task-Aktivierung sind statisch festgelegt, wodurch es eine kon-
stante Auslastung gibt. Die Tasks werden zyklisch bearbeitet.
• Die Sicht auf Systemebene erfolgt als Momentaufnahme, wobei alle Knoten eine kon-
stante Sicht haben.
• Die Semantik der Nachrichten ist zustandsbasiert. Da die Kommunikation festgelegt ist,
gibt es keine Überlastung auf dem Bussystem.
3.1.2 Gegenüberstellung von zeitgesteuerten und ereignisgesteuerten

Architekturen
In der zeitgesteuerten Architektur werden Tasks zu vorher bestimmten Zeitpunkten periodisch

aktiviert. Die Zustandsgrößen des Systems werden zu festgelegten Zeitpunkten erfasst und die
Aktivierung von Tasks hängt vom Fortschreiten der Zeit ab. Der Vorteil dieser Architektur ist,
dass sie zeitlich deterministisch ist, da alle Tasks und Nachrichten im Voraus geplant werden
und es so nicht zu Überlastsituationen kommt. Die Nachteile sind, dass sie aufgrund der sta-
tischen Offline-Planung unflexibel ist und sich durch die periodische Aktivierung von Tasks
hauptsächlich für zyklische Vorgänge eignet [Kopetz (1997)].
Die ereignisgesteuerte Architektur führt die Aktivierung von Tasks auf Basis von Ereignissen
aus. Die Organisation der Zeitpunkte, zu denen Tasks ausgeführt werden, wird zur Laufzeit
festgelegt. Zeitliche Signale für die Aktivierung von Tasks werden durch signifikante Zustands-
änderungen hervorgerufen. Die Ereignisse stammen vom Rechnersystem selbst oder von techni-
schen Prozessen innerhalb des Systems. Der Vorteil dieser Architektur ist die schnelle Reaktion
auf asynchrone Vorgänge, da die verarbeitenden Tasks mit geringem Zeitverzug zum Eintreffen
der Ereignisse aktiviert werden. Der Nachteil besteht darin, dass ein ereignisgesteuertes System
nicht deterministisch ist, da die Aktivierungszeitpunkte von Tasks, sowie das Eintreffen von Er-
eignissen nicht vorhersagbar ist und es so zu Überlastsituationen auf den Berechnungseinheiten
und dem Kommunikationsmedium führen kann [Kopetz (1997)].
3.2 Zeitgesteuerte Task-Aktivierung
Die Task-Aktivierung ist ein Bestandteil des Betriebsysystems. Sie ordnet eine Menge von
Tasks den verfügbaren Prozessoren und Ressourcen zu. In Echtzeitsystemen unterliegen die
Tasks oft Bedingungen wie Deadlines. Diese müssen durch das Scheduling eingehalten wer-
den.
Bei einer zeitgesteuerten Task-Aktivierung werden Tasks in bestimmten Zeitabständen peri-

odisch aktiviert. Dabei wird nicht berücksichtigt, ob die Ausführung der Task notwendig ist. In
zeitgesteuerten Echtzeitsystemen wird das Scheduling von Tasks dynamisch zur Ausführungs-
zeit oder statisch in der Entwicklungsphase durchgeführt. Für ein statischen Offline-Scheduling
müssen die Tasks, deren Perioden und deren maximale Ausführungszeiten (Worst Case Execu-
tion Time (WCET)) bekannt sein, um ihnen ausreichend Prozessorzeit zuzuweisen.
Es existiert eine Vielzahl an Verfahren für das Scheduling von Echtzeit-Tasks. Diese lassen sich
wie folgt klassifizieren [Buttazzo (2004)]:
• Preemptiv: In preemptiven Algorithmen kann ein Task, der ausgeführt wird, zu jeder
Zeit unterbrochen werden, um dem Prozessor einen anderen Task zuzuweisen.
• Nicht-preemptiv: Ein Task, der dem Prozessor zugeordnet wird, belegt ihn so lange, bis
er komplett abgearbeitet ist.
• Statisch: Scheduling-Entscheidungen werden basierend auf festen Parameter durchge-

führt, bevor ein Task aktiviert wird.
• Dynamisch: In dynamischen Verfahren werden Scheduling-Entscheidungen auf dynami-

schen Parametern getroffen, die während der Systemausführung variierbar sind.
• Offline: Ein Offline-Algorithmus wird für alle Tasks vor der Laufzeit durchgeführt. Der
generierte Schedule wird in einer Tabelle gespeichert und durch einen Dispatcher ausge-
führt.
• Online: Ein Online-Algorithmus führt die Scheduling-Entscheidungen zur Laufzeit aus.

Eine Scheduling-Entscheidung wird für jeden neuen Task im System und sobald ein Task
terminiert getroffen.
• Optimal: Ein Algorithmus ist optimal, wenn er eine gegebene Kostenfunktion für die
gegebene Task-Menge minimiert. Ist keine Kostenfunktion definiert, so ist das Generieren
eines ausführbaren Schedules die optimale Lösung.
• Heuristisch: Ein heuristischer Algorithmus ermittelt einen ausführbaren Schedule nach

einer heuristischen Funktion. Dabei kann nicht garantiert werden, dass ein optimaler
Schedule erzielt wird, auch wenn einer existiert.
In dieser Arbeit wird ein statisches Scheduling-Verfahren eingesetzt, da dieses die Anforde-
rung an ein Hard Real-Time-System erfüllt. Das Scheduling wird statisch und offline durch-
geführt, um einen deterministischen Schedule zu erhalten. Es wird eine Heuristik verwendet,
deren Ziel es ist, die Länge des erzeugten Schedules zu minimieren. Die nicht-preemptive Task-
Aktivierung wird durch einen Dispatcher auf Basis einer Dispatcher-Tabelle durchgeführt.
3.3 Das Kommunikationssystem FlexRay
Das Kommunikationssystem FlexRay wurde von dem FlexRay-Konsotium als frei zugängli-
che Spezifikation entwickelt. Das im Jahr 2000 gegründete Konsortium ist eine Allianz aus
Automobil- und Elektronikherstellern, die zusammen ein deterministisches und fehlertolerantes
Bussystem mit einer hohen Datenrate entwickeln, das den steigenden Kommunikationsanforde-
rungen im Automobil gerecht werden soll. Zu den Gründungsmitgliedern gehören die Firmen
BMW, Daimler-Chrysler, Motorola und Philips, denen sich in den folgenden Jahren u. a. Bosch,
General Motors und Volkswagen anschlossen. Die Entwicklung als eine frei zugängliche und
frei nutzbare Spezifikation hat das Ziel, möglichst schnell zu einem weit verbreiteten Standard
und günstiger Hardware zu führen [FlexRay (2008)]. Das FlexRay-Protokoll befindet sich der-
zeit in der Version 2.1 Revision A. Dieses Kapitel soll einen Überblick zu die Eigenschaften
von FlexRay geben, die zur Implementation des ttAKS relevant sind. Eine umfangreiche Be-
schreibung ist in der Spezifikation [FlexRaySpec (2005)] und in [Rausch (2008)] zu finden.
3.3.1 Eigenschaften des Kommunikationssystems FlexRay
Der folgende Abschnitt beschreibt die Eigenschaften des Kommunikationssystems FlexRay:
• FlexRay verwendet zwei getrennte Kommunikationskanäle mit einer Datenrate von je-
weils 10 MBit/s, die als redundante oder parallele Leitungen nutzbar sind. Bei redundan-
ter Verwendung werden die selben Informationen auf beiden Kanälen übertragen und so
eine Fehlererkennung beim Empfänger realisiert. Die Verwendung als parallele Leitun-
gen erhöht die Datenrate durch die Übermittlung unterschiedlicher Daten zur selben Zeit.
Diese Einstellung ist für jede Nachricht konfigurierbar.
• Das Protokoll verfügt über ein Statisches und ein Dynamisches Segment, in dem Daten
übertragen werden. Das statische Segment eignet sich besonders für die Übermittlung von
zeitkritischen Informationen, während sich das dynamische Segment für zeitunkritische
Informationen anbietet.
• Die Laufzeit für jede Nachricht ist bekannt und wird mit einer geringen Varianz garan-
tiert. Dieses wird durch die sich wiederholenden Zyklen realisiert. Dem Empfänger ist so
bereits im Voraus der Empfangszeitpunkt bekannt.
• Die Basis für die zeitgesteuerte Kommunikation bildet die gemeinsame Zeitbasis. Die
Synchronisation der Zeitbasis ist im Protokoll integriert und wird selbstständig durchge-
führt. Es wird eine Genauigkeit von 0,5 - 10 µs garantiert, wobei typische Werte zwischen
1 und 3 µs liegen [Rausch (2008)].
• Das Protokoll ist flexibel, da sich Parameter, wie z. B. Redundanz oder Bandbreitenerhö-
hung konfigurieren lassen.
3.3.2 Aufbau eines FlexRay-Knotens
Ein FlexRay-Knoten besteht aus einem Mikrocontroller, einem FlexRay-Kommunikations-

Controller, zwei optionale Bus-Guardian und zwei Bus-Treibern (Abb. 3.1) [Rausch (2008)].
Der Mikrocontroller ist der Teil des Knotens, auf dem die Anwendung ausgeführt wird. Zum
Austausch der zu sendenden und empfangenen Nachrichten ist er mit dem Kommunikations-
Controller verbunden. Zusätzlich wird die Konfiguration des Kommunikations-Controllers über
diese Schnittstelle durchgeführt. Das FlexRay-Protokoll wird durch den Kommunikations-
Controller umgesetzt. Er ist mit den Bus-Treibern verbunden, die an die beiden FlexRay-Kanäle
angeschlossen sind. Die Bus-Treiber beinhalten den Empfänger, Sender und Funktionen zur
Überwachung von Bus-Aktivitäten wie Wake-Up und Fehlererkennung. Zusätzlich ist optional
ein Bus-Guardian vorhanden, der den Zugriff auf das Medium kontrolliert und so Fehlersitua-
tionen erkennt. In der hier verwendeten Hardware der zeitgesteuerten Plattform ist der Bus-
Guardian nicht verfügbar.
Abb. 3.1: Aufbau eines FlexRay-Knotens [Rausch (2008)]
3.3.3 Die TDMA-Runde
Die Kommunikation im FlexRay-Protokoll ist in Zyklen eingeteilt, die als TDMA-Runde be-
zeichnet werden. Diese wiederholen sich nahtlos nacheinander und besitzen eine definierte Dau-
er, die sich über Parameter konfigurieren lässt. Jede TDMA-Runde besitzt eine Zyklusnummer,
die bei Null beginnt und nach dem 63. Zyklus erneut bei Null startet. Eine TDMA-Runde lässt
sich in vier Abschnitte einteilen: Statisches Segment, dynamisches Segment, Symbol Window
und Network Idle Time (NIT) (Abb. 3.2).
Abb. 3.2: Aufbau einer TDMA-Runde
Auf das statische und dynamische Segment folgen in einer TDMA-Runde das optionale Symbol
Window und die Network Idle Time. Das Symbol Window dient zur Funktionsprüfung der Bus-
Guardians. Die NIT wird zur Synchronisation der Uhren aller FlexRay-Knoten verwendet.
Das statische Segment
Die Nachrichtenübertragung im statischen Segment eignet sich besorderns für zeitkritische Ab-
läufe mit deterministischen Verhalten. Die Kommunikation findet nach dem TDMA-Verfahren
statt. Das Segment ist in Zeitschlitze eingeteilt, die als Slots bezeichnet werden. Die Slots wer-
den den Knoten fest und exklusiv zugeordnet, wobei einem Knoten mehrere Slots zuordbar
sind. Auf beiden Kanälen sind die Slots immer synchron. Sie sind durchnummeriert und be-
sitzen eine feste Größe. Die Nachrichten werden in Frames mit einer Frame-ID als Kennung
übertragen, wobei die ID 1 im erstem Slot, die ID 2 im zweiten Slot usw. übertragen wird (Abb.
3.3a).
(a) Frame Slot Zuordnung (b) Knoten Slot Zuordnung
Abb. 3.3: Slot-Zuordnung von Frames und Knoten
Es gibt die folgenden Varianten für die Slot-Knoten-Zuordnung(Abb. 3.3b):
• Ein Knoten sendet wie in Slot 1 und 4 auf beiden Kanälen gleichzeitig (Redundanz).
• Ein Knoten sendet wie in Slot 2 und 3 auf einem Kanal, während der zweite Kanal für
spätere Erweiterungen frei bleibt.
• Es werden wie in Slot 5 beide Kanäle unterschiedlichen Knoten zugeordnet (Bandbrei-

tenerhöhung).
Das dynamische Segment
Das dynamische Segment ist besonders für die Übertragung von zeitunkritischen und spora-
dischen Nachrichten geeignet. Der genaue Übertragungszeitpunkt ist nicht vorhersagbar, wo-
durch es sich für deterministische Anwendung nicht eignet. Das Segment ist in Minislots einge-
teilt. Der Zugriff auf den Bus erfolgt durch das FTDMA-Vefahren, das auch als Mini-Slotting
Scheme bezeichnet wird. Die Slots sind alle gleich groß und kleiner als die statischen Slots,
entsprechen einem oder mehreren Minislots und sind wie im statischen Segment aufsteigend
nummeriert. Die Nachrichten bzw. Frames sind über ihre ID fest den dynamischen Slots zu-
geordnet und werden nur bei Bedarf übertragen. Entspricht die Frame-ID der Slot-Nummer,
darf ein Knoten seine Nachricht übermitteln. Beginnt ein Knoten einen Frame zu senden, so
erweitert sich der dynamische Slot um die zur Übertragung des Frames notwendigen Minislots.
Nachdem eine Übertragung vollständig ist, wird mit dem nächsten dynamischen Slot fortgefah-
ren. Werden viele Frames in einem dynamischen Segment übertragen, kann es dazu führen, dass
ein Frame mit einer hohen ID erst mehrere Runden nach der Generierung übertragen wird.
Abb. 3.4: Frames im dynamischen Segment
3.3.4 Die Uhrensynchronisation
Jeder Knoten im FlexRay-Netzwerk besitzt seinen eigenen internen Takt. Dieser wird in der
Regel von Oszillatoren generiert, die herstellungsbedingt Schwankungen aufweisen. Die hier
verwendeten zeitgesteuerten Buszugriffsverfahren, erfordern eine Globale Zeitbasis für alle
Netzwerkteilnehmer, die in FlexRay durch das integrierte Synchronisationsverfahren hergestellt
wird.
Die Grundeinheit für die Zeitbasis bilden in FlexRay Microticks, die aus dem internen Takt des
Knotens gewonnen werden. Die nächst größere Einheit Macrotick besteht aus mehreren Mi-
croticks. Die Macroticks sind auf jedem Knoten gleich groß und bilden die Zeitbasis für die
statischen Slots und die Minislots. Eine TDMA-Runde besteht immer aus der selben Anzahl an
Macroticks, während die Anzahl an Microticks in den TDMA-Runden variieren kann. Außer-
dem kann die Länge eines Microticks auf den unterschiedlichen Knoten variieren.
In FlexRay wird ein aus Offset- und Frequenzkorrektur bestehendes Verfahren zur Uhrensyn-
chronisation verwendet. Zum Messen der Uhrenabweichung misst jeder Knoten beim Frame-
Empfang dessen Ankunftszeit. Da die Zeit bekannt ist, zu der ein Frame empfangen werden
soll, kann die Zeitdifferenz zum tatsächlichen Empfangszeitpunkt bestimmt werden. Diese Dif-
ferenz gibt die Abweichung der Uhren zwischen dem Sender und dem Empfänger an. Aus den
gesammelten Messwerten berechnet jeder Knoten seine Korrekturwerte auf Basis eines fehler-
toleranten Mittelwert-Algorithmus [Rausch (2008)].
Die Frequenzkorrektur wird auf Basis von Messwerten zweier TDMA-Runden vollzogen. Aus
den Differenzen der Messwertpaare, die die Änderung der Uhrenabweichung pro TDMA-
Runde angibt, wird ein Korrekturwert ermittelt. Die Offsetkorrektur benötigt die Messwerte
aus einer TDMA-Runde. Dazu ist ein Teil der NIT reserviert. Sie wird nur jede zweite TDMA-
Runde durchgeführt, um die Messungen der Frequenzkorrektur nicht zu verfälschen.
4 Übersicht zu Entwurfskonzepten für
verteilte zeitgesteuerte Systeme
Die Kopplung einer zeitgesteuerten Plattform mit einer zeitgesteuerten Task-Ausführung und
Kommunikation erfordert Methoden zur Planung des Systems. Um die Ausführungszeiten
zu minimieren, ist es erforderlich, die Task-Ausführung und die Kommunikation abzustim-
men. Dazu sind Werkzeuge für die Anwendungsmodellierung sowie die Planung der Task-
Ausführung und der Kommunikation notwendig. In der Industrie sind Werkzeuge wie der Elek-
trobit Desinger im Einsatz, die die Konfiguration des zeitgesteuerten Busses FlexRay unterstüt-
zen [EB (2007)]. Diese bietet Funktionen zur Festlegung der Parameter wie Slotgröße, Slotrei-
henfolge und TDMA-Rundenlänge.
Die Recherche zeigte, dass nur wenige dokumentierte Ansätze und Werkzeuge für eine Ana-
lyse zeitgesteuerter Systeme verfügbar sind. Dieser Eindruck wurde auf dem FlexRay-Product
Day 2007 bestätigt [Hanser (2007)]. Daraus lässt sich schließen, dass in der Industrie keine ge-
eigneten Werkzeuge verfügbar sind, die eine Abstimmung zwischen der Task-Ausführung und
Kommunikation in einem verteilten zeitgesteuerten Echtzeit-System unterstützen.
Das folgende Kapitel stellt Werkzeuge vor, die sich zur Planung von verteilten Systemen eignen.
Es wird als erstes das Produkt SymTA/S vorgestellt. Dieses bietet Funktionen zur Modellie-
rung und Planung von verteilten Systemen. Des Weiteren wird die Timing Definition Language
(TDL) vorgestellt, mit deren Hilfe sich zeitgesteuerte Systeme modellieren und implementieren
lassen. Es folgt die Vorstellung des Projekts Timmo, das sich mit der hier beschriebenen Proble-
matik beschäftigt. Aus dem Projekt sind bisher noch keine Dokumente veröffentlicht worden.
Als letztes wird ein Verfahren zur abgestimmten Planung der zeitgesteuerten Task-Ausführung
und Kommunikation vorgestellt, das an der Universität Linköping entwickelt wurde. Zu diesem
Verfahren ist bisher kein Werkzeug entwickelt worden, das auf dem freien Markt zur Verfügung
steht. Es werden in Dokumenten die Methoden beschrieben, die für die abgestimmte Planung
eines zeitgesteuerten Systems angewendet werden. Diese Methoden eignen sich zur Generie-
rung eines Schedules mit einer kurzen Ausführungszeit und zur Planung der zeitgesteuerten
Kommunikation. Abschließend werden in diesem Kapitel die Schwerpunkte der Verfahren im
Vergleich dargestellt.
4.1 SymTA/S
Die Software Symbolic Timing Analysis for Systems (SymTA/S) wurde in einem Forschungs-
projekt des Instituts für Datentechnik und Kommunikationsnetze der Universität Braunschweig
entwickelt ([Hamann u. a. (2006)], [TU Braunschweig (2007)], [GI (2006b)], [GI (2006a)]).
Es unterstützt die Systemintegration verteilter embedded Systeme und bietet eine Methode
zur Performance und Timing Analyse auf Systemebene, basierend auf formalen Scheduling-
Analyse-Techniken und symbolischer Simulation. Das Werkzeug unterstützt die Generierung
eines Schedules und die Simulation der Systemausführung. Der Fokus dieses Forschungspro-
jekts liegt auf verteilten embedded Echtzeit-Systemen im Automobil und heterogenen System-
On-Chips (SoC) bzw. Multi-Processor-System-On-Chips (MPSoC) Systemen. Derzeit ist mit
Hilfe des Werkzeugs eine ereignisgesteuerte Aktivierung von Tasks und eine ereignisgesteuer-
te Kommunikation über den CAN-Bus verfügbar. Protokolle wie z. B. FlexRay, die nach dem
Time Division Multiple Access (TDMA)-Verfahren arbeiten, werden von der Software der-
zeit nicht unterstützt. Die Analyse des SymTA/S-Ansatzes betrachtet nicht das Gesamtsystem.
Für die Scheduling-Analyse werden einzelne Ressourcen betrachtet. Ein System besteht aus
Mikrocontroller- und CAN-Bus-Ressourcen, die miteinander verbunden sind. Es gibt Tasks, die
Mikrocontroller-Ressourcen zugeordnet werden, und externe Quellen und Senken. Diese wer-
den über Ereignisströme miteinander verbunden. Das in SymTA/S verwendete Anwendungs-
modell wird zur Beschreibung von Tasks und Nachrichtenströmen verwendet (Abb. 4.1). Ein
Task wird durch ein Aktivierungsereignis aktiviert. Diese werden u. a. durch den Ablauf eines
Timers, externe oder interne Interrupts oder Task-Verkettungen generiert. Die Kommunikation
zwischen Tasks wird durch FIFOs oder Register modelliert. Werden FIFOs verwendet, so er-
hält jeder Task eine Input-FIFO. Ein Task liest seine Aktivierungsdaten aus dieser Input-FIFO
und schreibt Daten in die Input-FIFO abhängiger Tasks. Bei der Register-Kommunikation ist
es notwendig, dass der sendende Task das Schreiben ins Register des abhängigen Tasks vor
dessen Leseroutine abgeschlossen hat. Diese Art der Kommunikation ist nur für zeitgesteuerte
Kommunikation geeignet. Die Register-Kommunikation wird in den Dokumentationen zu dem
Projekt nicht aufgegriffen.
Abb. 4.1: Eine in SymTA/S modellierte Anwendung
Ein Task muss zur Ausführung einer Berechnungs- oder Kommunikationsressource zugeordnet
werden. Werden mehrere Tasks einer Ressource zugeordnet, so wird ein Scheduler benötigt. Die
Scheduling-Analyse berechnet die Worst Case Execution Time für alle Tasks einer Ressource.
Hierbei wird davon ausgegangen, dass ein Task zum Ende seiner Ausführung seine Output-
Daten ausgibt.
Das Standard Ereignis-Modell repräsentiert das Timing der Aktivierungsereignisse von Tasks.
Sie werden über mehrere Parameter beschrieben. Als Beispiel werden hier drei Modelle vorge-
stellt:
Das strikt periodische Ereignis-Modell legt fest, dass ein Ereignis nach definierten Zeitein-
heiten erneut eintritt.
Das periodische Ereignis-Modell mit Jitter ist eine Erweiterung des strikt periodischen Mo-
dells. Ein periodisches Ereignis variiert um die exakte Position in dem angegebenen Jitter-
Intervall. Ist der angegebene Jitter 0, so handelt es sich um ein strikt periodisches Modell.
Das Bursty Ereignis-Modell beschreibt die Erweiterung des periodischen Ereignis-Modells

mit Jitter um eine minimale Distanz, die zwischen Ereignissen festgelegt wird. Dieses
ist bei einem Jitter sinnvoll, der größer als die Periode ist, da so durch mehrere zeitglei-
che Ereignisse Bursts auftreten können und diese so verhindert werden.
Sporadische Ereignisse beschreiben Ereignisse, die nicht regelmäßig auftreten.
Die Systemanalyse wird durch die zusammengesetzte Performance-Analyse-Methodik vollzo-

gen, in der sich die lokale Scheduling-Analyse und der Ereignis-Modell-Fortschritt während
der Analyse auf Systemebene abwechseln (Abb. 4.2). Hierzu ist die Modellierung von Timings
der Output-Ereignisse zur Übertragung an die nächsten Scheduling-Komponente notwendig.
Output-Ereignisse können z. B. von Sensoren generiert werden. Das Output-Ereignis-Modell
wird mit den selben Parametern wie das Standard-Ereignis-Modell beschrieben.
Abb. 4.2: Phasen der Systemanalyse
Die Systemanalyse wird in den folgenden Schritten vollzogen (Abb. 4.2):
• Zu Beginn wird das externe Ereignis-Modell entlang aller Pfade propagiert, bis es ein
Aktivierungs-Ereignis-Modell für jeden Task gibt.
• Anschließend wird die Phase 1 der Systemanalyse durchgeführt. Sie beinhaltet die lo-
kale Scheduling-Analyse für jede Ressource und die Berechnung eines Output-Ereignis-
Modells.
• Die zweite Phase enthält die Propagierung aller Output-Ereignis-Modelle.
• Anschließend muss geprüft werden, ob die erste Phase erneut durchgeführt werden muss,
da sich die Aktivierungs-Ereignis-Modelle aufgrund der propagierten Output-Ereignis-
Modelle geändert haben könnten.
• Die Analyse ist vollständig, sobald es keine Änderungen mehr an den Aktivierungs-
Ereignis-Modellen gibt oder eine Bedingung, z. B. Verletzung einer Timing-Anforderung,
aufgetreten ist.
Das Beispiel in Abb. 4.1 beinhaltet zwei Ressourcen, R1 und R2. Auf beiden Ressourcen sind
jeweils zwei Tasks zu finden, auf R1 T 1 und T 3, auf R2 T 2 und T 4. T 1 erhält externe Inputs von
der Quelle Src1 und T 3 von Src2. Die Ausgabedaten von T 1 werden von T 2 benötigt, während
die Ausgabe von T 3 von T 4 weiterverwendet wird.
Im ersten Schritt sind nur die Ereignis-Modelle an den externen System-Inputs bekannt. Somit
ist ein Aktivierungs-Ereignis-Modell für jeden Task auf der Ressource R1 vorhanden. Hierauf
erfolgt die Durchführung einer lokalen Scheduling-Analyse dieser Ressource und die Erzeu-
gung eines Output-Ereignis-Modells. In der zweiten Phase werden die Output-Ereignis-Modelle
propagiert. Sie dienen den beiden Tasks auf der zweiten Ressource als Aktivierungs-Ereignis-
Modelle. Anschließend wird eine lokale Scheduling-Analyse auf der zweiten Ressource durch-
geführt.
4.2 TDL - Timing Definition Language
Die Timing Definition Language (TDL) ist eine Plattform unabhängige Sprache zur Modellie-
rung von zeitgesteuerten harten Echtzeit-Anwendungen ([Farcas u. a. (2005)], [Farcas und Pree
(2007)], [Naderlinger u. a. (20–26 May 2007)], [Pree (2007)]). Das Zeitverhalten wird von der
Implementation der Anwendung entkoppelt. Mit TDL wird das Zeitverhalten einer Anwendung
spezifiziert während die Implementation in einer imperativen Programmiersprache wie C oder
Java durchgeführt wird. Es wird die zeitliche Interaktion zwischen Software-Komponenten und
der Umgebung festgelegt. TDL beruht auf der Logical Execution Time (LET), die im Giotto
Projekt eingeführt wurde ([Berkley (2008)]. Sie wurde um ein Komponentenmodell, eine ver-
feinerter Syntax und Semantik sowie eine Unterstützung für verteile Anwendungen erweitert.
Abb. 4.3: Die Logische Ausführungszeit LET
Die LET beschreibt die Periode der Tasks und die Zeitspanne, in der ein Task die Ausführung
beginnen und beenden muss. Sie enthält das Lesen der Eingabewerte zu Beginn und die Ausga-
be der Ausgabewerte zum Ende der LET. Die Ausgabewerte eines Tasks sind erst zum Ende der
LET verfügbar. Bis zu diesem Zeitpunkt sind nur die Ausgabewerte der vorherigen Ausführung
gültig. Das beobachtbare Zeitverhalten eines Tasks ist unabhängig von der physikalischen Aus-
führung (Abb. 4.3). Dabei wird angenommen, dass die physikalische Ausführung schnell genug
ist, um einen Task innerhalb der LET auszuführen.
Abb. 4.4: TDL Komponenten
Das Komponenten-Modell der Timing Definition Language basiert auf Modulen (Abb. 4.4).
In den parallel arbeitenden Modulen wird eine Anwendung oder Teile einer komplexen An-
wendung gekapselt (Dekomposition). Sie enthalten Sensoren, Aktoren und Modi. In einem
Modus wird eine Menge periodisch auszuführender Aktivitäten gekapselt, die Taskaufrufen,
Aktorenupdates und Moduswechseln entsprechen. Die Ausführung von Aktivitäten können
durch Guards, boolsche Funktionen auf Sensordaten oder Task-Ausgaben, eingeschränkt wer-
den. Zwischen den Modi eines Moduls kann gewechselt werden, wobei nur genau ein Modus
zur Zeit aktiv ist. Wenn ein Modul gestartet wird, befindet es sich in einem festgelegten Mo-
dus. Ein Modus enthält eine Menge an Tasks, die eine Funktionalität repräsentieren. Sie haben
eine festgelegte Logical Execution Time (LET), die die Kommunikationszeit enthält. Ein Task
besitzt eine Menge von Eingaben, Ausgaben und Status. Zum Datenaustausch zwischen den
Modulen werden über Ports Import- und Exportmechanismen zur Verfügung gestellt.
Zur Realisierung des Zeitverhaltens gibt es für die einzelnen Komponenten unterschiedliche
Parameter. Tasks besitzen eine LET, Periode und WCET. Dieses ist notwendig, um dem Task
so zur Ausführung zu bringen, dass er innerhalb der LET vollständig bearbeitet wird. Zwischen
den Modi kann es Wechsel geben, für die es wiederum eine Zeitbasis basierend auf der LET
gibt. Die in Modulen gekapselten Modi besitzen eine Periode, die von den Task-Perioden und
den Modi des Moduls abhängt. Weiterhin gibt es eine Bus-Periode, die einem Kommunikations-
zyklus in einer TDMA-Runde beschreibt. Diese Periode ist abhängig von den Moduswechseln
der Modi, die über den Bus kommunizieren [Pree (2007)].
Die Erzeugung von Code für die Ausführung der Anwendung wird in mehreren Schritten durch-
geführt (Abb. 4.5). Der TDL-Compiler generiert auf Basis des TDL-Codes, den der Anwender
erzeugt hat, einen Abstract Syntax Tree (AST) und E-Code. Für jedes Modul wird eine E-
Code-Datei als Repräsentation aller Aktivitäten eines Moduls, deren Timing und Abhängigkei-
ten zwischen den Modulen erzeugt. Diese Informationen werden in der Laufzeitumgebung von
der E-Machine (virtuelle Maschine) ausgewertet. Der AST ist ein Zwischenformat, das u. a.
vom Bus-Schedule-Generator für die Erzeugung eines Bus-Schedules genutzt wird. Neben dem
AST benötigt der Bus-Schedule-Generator eine Konfigurationsdatei, die Informationen über
die physikalischen Eigenschaften des Bus-Protokolls wie minimale und maximale Paketgröße
und Geschwindigkeit beinhaltet. Außerdem enthält sie eine Liste der vorhandenen Knoten und
Informationen über die Zuordnung der Module zu den Knoten. Aus diesen Daten wird offline
ein statischer Bus-Schedule erzeugt. Dieser Schedule wird in der Laufzeitumgebung verwendet,
um Informationen zwischen den Knoten auszutauschen.
Abb. 4.5: Tool Chain zur Generierung einer TDL-Anwendung
Die TDL-Laufzeitumgebung besteht aus drei Komponenten (Abb. 4.6), die auf jedem Kno-
ten implementiert sind: Eine virtuelle Maschine (E-Machine), ein Scheduler (TDL-Scheduler)
und eine Kommunikationsschicht (TDLComm). Die virtuelle Maschine steuert das logische
Verhalten der Anwendung und deren Interaktion mit der Umgebung. Der Scheduler bildet die
physikalische Zeit der Plattform auf die logische Zeit ab, ruft die virtuelle Maschine und die
Kommunikationsschicht auf und unterbricht und startet die Ausführung von Tasks. Die Kom-
munikationsschicht behandelt den Verteilungsaspekt.
Abb. 4.6: TDL-Laufzeitumgebung
Die E-Machine verarbeitet die logischen Aspekte der Laufzeitumgebung. Sie entscheidet wann
und welcher Task zur Ausführung freigegeben wird und welche Treiber ausgeführt werden
müssen, um den korrekten Informationsfluss zu gewährleisten. Die Treiber sorgen u. a. für das
Starten und Beenden von Tasks und die Aktualisierung von Werten. Die Tasks laufen in na-
tiven Code, um die Performanz zu maximieren. Aus logischer Sicht benötigt die Ausführung
des E-Codes keine Zeit, während aus Sicht des Schedulers Zeit verbraucht wird, die bei den
Scheduling-Entscheidungen berücksichtigt werden muss.
Der TDL-Scheduler ist die Brücke zwischen der TDL-Semantik und der darunter liegenden
Plattform. Seine Aufgabe ist es, die E-Machine zum richtigen Zeitpunkt entsprechend der TDL-
Semantik aufzurufen und die freigegebenen Tasks entsprechend der Scheduling-Strategie aus-
zuführen. In einer verteilten Umgebung muss er zusätzlich den Datenaustausch zwischen der
Kommunikationsschicht und den Knoten koordinieren. Die Tasks aller Module auf einem Kno-
ten werden beim Scheduling gleich behandelt. Da die Taskausführung zeitgesteuert durchge-
führt wird und die Perioden der Tasks vorher bekannt sind, wird durch vorkompilierte Tabellen
der Overhead beim Scheduling zur Laufzeit verringert.
Die TDLComm-Schicht abstrahiert den physikalischen Informationsaustausch. Unter Verwen-

dung der vorkompilierten Scheduling-Informationen, führt die Kommunikationsschicht drei
Schritte aus: Kapseln von Portwerten in Pakete, Übermittlung der Pakete übers Kommunika-
tionsmedium und Extrahierung empfangener Portwerte. Zur zeitgesteuerten Übertragung von
Informationen ist die Kommunikationsschicht auf den Scheduler angewiesen, der die Funk-
tionalitäten zum richtigen Zeitpunkt ausführt. Der TDLComm bietet zudem einen Dienst zur
Uhrensynchronisation an.
In TDL wird eine modellbasierte Entwicklung der Anwendung durchgeführt. Durch die Ab-
straktion der Systemdetails wird eine plattformunabhängige Entwicklung erzielt. Zusätzlich ist
das Zeitverhalten der Anwendung von der Implementation der Anwendung entkoppelt. Zur
Ausführung einer TDL-Anwendung wird ein Echtzeit-Betriebssystem voraussetzt, auf dem
die TDL-Laufzeitumgebung zum Einsatz kommt. Die Aktivierung und Bearbeitung von Tasks
sowie die Kommunikation wird durch die Laufzeitumgebung gesteuert. Sie verwendet eine
Dispatcher-Tabelle, die Informationen zur Task-Aktivierung enthält und einen Bus-Schedule,
der die Informationen zur Datenübertragung beinhaltet.
IM TDL Ansatz wird ein Online-Scheduler verwendet, der nach der Earliest Deadline First
(EDF) Strategie arbeitet. Er entscheidet bei jeder Aktivierung anhand der Deadline der Tasks,
welcher ausgeführt wird. Dazu sind Kontextwechsel erforderlich, die Zeit benötigen. Die
Anzahl der Kontextwechsel soll dadurch verringert werden, dass vorkompilierte Dispatcher-
Tabellen verwendet werden.
4.3 Timmo Projekt
Das Forschungprojekt Timing Model (TIMMO) befasst sich mit der Entwicklung einer ge-
meinsamen, standardisierten Infrastruktur zur Behandlung von Echtzeitaspekten für verteilte
Elektronik im Automobil. Das Projekt ist am C-Lab der Univerität Paderborn in Kooperation
mit der Firma Siemens eingegliedert. An TIMMO sind u. a. die Firmen Audi, Bosch, Volvo und
Volkswagen beteiligt [TIMMO (2008)].
Es existiert keine einheitliche mit AUTOSAR kompatible Infrastruktur, um Zeitrestriktionen

während der Modellierung komplexer, vernetzter, eingebetteter Echtzeit-Systeme zu berück-
sichtigen. Mit Hilfe der im Projekt zu entwickelnden Infrastruktur soll der Austausch von Mo-
dellinformationen firmenintern und zwischen Zulieferern und Automobilherstellern erleichtert
werden und die Effizienz im Entwicklungsablauf erhöht werden.
Das Projekt gliedert sich in drei wesentliche Arbeitsschwerpunkte:
• Eine Beschreibungssprache für zeitliche Aspekte in der Entwicklung automobiler Steuer-

geräte und -netze
• Eine Methodik für die firmenübergreifende Anwendung der Beschreibungssprache
• Die Validierung der Sprache anhand prototypischer Entwicklungsvorhaben
Durch eine formale, standardisierte Behandlung von Zeitspezifikationen wird eine durchgän-
gige Erfassung und Verifikation von Echtzeitanforderungen über den gesamten Entwurfsab-
lauf realisiert. Die Analyse des zeitlichen Systemverhaltens ist somit schon sehr früh im Ent-
wurfsprozess durchführbar. Zu diesem Projekt sind bisher keiner Publikationen veröffentlicht
worden, wodurch es für die hier zu implementierende Anwendung nicht anwendbar ist.
4.4 Schedulingverfahren für verteilte Echtzeitsysteme
Ein Verfahren zur Schedulinganalyse und zur Synthese von verteilten Echtzeit-Anwendungen
wurde am Embedded Systems Laboratory der Universität Linköping entwickelt ([ESLAB
(2007)], [Pop u. a. (2004)]). Der Ansatz bildet die Grundlage für die Anwendung, die in dieser
Arbeit implementiert wird. An dieser Stelle wird nur eine Übersicht gegeben. Eine detaillierte
Beschreibung des Ansatzes wird im Kapitel 5.2 dargestellt.
Der Ansatz umfasst die Modellierung einer verteilten Echtzeit-Anwendung, die Generierung
eines Schedules unter Berücksichtigung der Kommunikation und die Erstellung eines TDMA-
Plans für die Datenübertragung. Anwendungen werden in einem Conditional Process Graph
(CPG) dargestellt. Der Graph dient zur Darstellung der Tasks und deren Abhängigkeiten, sowie
die Kommunikation zwischen den Tasks und deren Knotenzuordnung. Zusätzlich bietet der
Graph Konditionen, die die Task-Ausführung steuern.
Die Generierung eines Schedules und eines TDMA-Plans wird auf Basis des Graphens vollzo-
gen. Das statische Offline-Scheduling-Verfahren basiert auf einem List Scheduling Heuristik,
die eine Dispatcher-Tabelle erzeugt, die die Ausführungszeitpunkte der Tasks und die Konditio-
nen beinhaltet, unter denen sie ausgeführt werden. Der erzeugte TDMA-Plan ist so optimiert,
dass die Nachrichten mit geringem Verzug an den Empfänger zur Weiterverarbeitung übertra-
gen werden.
Das vorgestellte Schedulingverfahren verwendet als Kommunikationsmedium das Time-

Triggered Protocol (TTP), das eine zeitgesteuerte Datenübertragung nach dem TDMA-
Verfahren bietet. Dieses ist dem statischen Segment des FlexRay-Protokolls sehr ähnlich, wo-
durch eine Anpassung des Scheduling-Verfahrens realisierbar ist.
4.5 Schwerpunkte der Ansätze im Vergleich
Die wesentlichen, aus der Untersuchung herausgestellten Merkmale der hier betrachteten An-
sätze und Werkzeuge werden in der Tabelle 4.1 dargestellt. Das einzige auf dem Markt ver-
fügbare Werkzeug SymTA/S bietet keine Funktionen, die sowohl die zeitgesteuerte Task-
Ausführung als auch die zeitgesteuerte Kommunikation berücksichtigen. Der Schwerpunkt die-
ses Werkzeugs liegt in der Modellierung von ereignisgesteuerten Anwendungen im SoC- und
MPSoC-Bereich.
Die TDL bietet Funktionen für die Modellierung und Planung einer zeitgesteuerte Anwendung.
Der Ansatz setzt für die Task-Ausführung genügend Ressourcen voraus, um die Tasks innerhalb
der LET auszuführen. Die Hardware muss überdimensioniert werden, um den Einschränkun-
gen gerecht zu werden. Dieses ist in der Industrie nicht praktikabel, da die in Serie produzierten
Komponenten kostengünstig herzustellen sind. Der Ansatz ist für die Zielplattform nicht sinn-
voll, da auf dem verwendeten Mikrocontroller die Ressourcen stark begrenzt sind.
Das Timmo-Projekt ist zur Umsetzung des Projekts nicht geeignet, da bisher keine Ergebnisse
veröffentlicht wurden und so praktisch nicht zur Verfügung steht.
Der Ansatz der Universität Linköping bietet die einzige, derzeit verfügbare Lösung eine zeit-
gesteuerte Anwendung zu modellieren und zu implementieren. Zu diesem Ansatz ist bisher
kein Werkzeug auf dem Markt verfügbar. Es ist daher notwendig auf Basis der dokumentierten
Funktionen eine Anwendung zu entwickeln.
Tabelle 4.1: Vergleich der Werkzeuge und Ansätze nach Funktionen
SymTA/S TDL Timmo Univ. Linköping
Task-Aktivierung ET, TT indirekt LET basiert nicht bekannt TT
Kommunikation ET (CAN-Bus) je nach Modul nicht bekannt TT (TTP)
Architektur verteiltes System verteiltes System verteiltes embedded verteiltes Hard Real-Time
Echtzeit-System System in einem zeitgesteuer-
tem Netzwerk
Scheduler / Scheduling erfolgt nach defi- Dynamischer vermutlich AUTOSAR Dispatcher, basierend auf
Dispatcher nierbarem Verfahren Online-Scheduler: Plattform statischen, offline generiert-
Earliest Deadline-First(EDF), em Schedule-Table, non-pre-
Rate-Monotonic, preemptive emptive Task-Ausführung
Task-Ausführung; Bus-Sche-
duler non-preemptive
System- Tasks auf den Komponenten Gesamtsystem als Module nicht bekannt Ganzheitliche Betrachtung
betrachtung und Kommunikationsströme
Modellierung Standard Event Modell TDL Module (Sensoren, Ak- nicht bekannt Conditional Process Graph
toren, Modi)
Scheduling- Tasks je Komponente und Statisches Offline Scheduling nicht bekannt ListScheduling Heuristik für
4 Übersicht zu Entwurfskonzepten für verteilte zeitgesteuerte Systeme
Analyse Kommunikation einzeln nach Latest Release Time abgestimmte Task- und Kom-
(LRT) munikationsplanung
Besonderheiten Module für FlexRay in der FlexRay in der Evaluation; nicht bekannt Optimierungsfunktionen
Entwicklung automatisches Mapping (Bus-Parameter); Prioritäts-
Funktion, die paralleles
Arbeiten fördert
23
5 Entwurfsgrundlagen für die
Implementation des zeitgesteuerten
Antikollisionssystems
Das folgende Kapitel stellt das Software-Konzept vor, das für die Entwicklung und Ausführung
der FlexRay-Anwendung zur Antriebsregelung und Fahrzeugkoordinierung im Rahmen einer
Masterarbeit entwickelt wurde [Sellentin (2006)]. Das zeitgesteuerte System und die Werkzeug-
kette zur Implementation einer Anwendung wird dargestellt und die Dokumentation erweitert.
Es werden die Modellierung in einem Graphen, das statische Offline-Scheduling-Verfahren und
der Dispatcher zur Task-Ausführung untersucht. Ziel der Untersuchung ist die Anwendbarkeit
des Software-Konzepts bzw. Teile des Konzepts für die zu implementierende Anwendung.
Im zweiten Teil des Kapitels wird ein Scheduling-Verfahren vorgestellt, das zur abgestimmten
Einplanung von zeitgesteuerten Tasks und der zeitgesteuerte Kommunikation dient [Pop u. a.
(2004)], das an der Universität Linköping entwickelt wurde. Es wird ein statisches Offline-
Verfahren verwendet, das einen Task- und einen Nachrichtenschedule generiert. Ziel des Ver-
fahrens ist es, die Ausführungszeit einer Anwendung zu minimieren und die Abstimmung zwi-
schen der Task-Ausführung und Kommunikation während des Schedulings. Das vorgestellte
Verfahren wird für die in der Arbeit implementierte Anwendung angewendet. Es wird dazu
eine Verschmelzung mit dem im ersten Teil vorgestellten Software-Konzept vollzogen.
5.1 Software-Konzept für verteilte zeitgesteuerte

Anwendungen
Im Rahmen des SCV-Projekts wurde ein Software-Konzept für zeitgesteuerte Verteilte Anwen-
dung in einem FlexRay-Netz entwickelt [Sellentin (2006)]. Es umfasst die Modellierung der
Anwendung in einem Prozessgraphen, ein statisches Offline-Scheduling der Tasks und einen
zeitgesteuerten Dispatcher zur Ausführung der Tasks auf den Mikrocontrollern. Das System
umfasst eine zeitgesteuerte Kommunikation und Task-Aktivierung. Die zeitgesteuerte Kommu-
nikation wird mit Kommunikations-Controllern durchgeführt, die an ein FlexRay-Netz ange-
schlossen sind. Die zeitgesteuerte Aktivierung von Tasks wird auf Host-Mikrocontrollern aus-
geführt.
In diesem Abschnitt wird eine Zusammenfassung der Inhalte vorgestellt, die zur Implementati-
on des ttAKS zur Anwendung kommen, und eine zusätzliche Visualisierung der zeitgesteuerten
Task-Aktivierung geliefert. Die Anwendungsmodellierung und das Scheduling-Verfahren, die
für das zu implementierende ttAKS nicht zur Anwendung kommen, werden im Anhang A.1
und A.2 vorgestellt.
5 Entwurfsgrundlagen für die Implementation des zeitgesteuerten Antikollisionssystems 25
5.1.1 Das zeitgesteuerte System
Die zeitgesteuerte Plattform, auf der die zum Konzept entwickelte Anwendung ausgeführt wur-
de und die Zielanwendung zur Ausführung kommt, wurde bereits in Kapitel 2 dargestellt.
Auf dieser Plattform wurde ein zeitgesteuertes System aufgebaut (Abb. 5.1). Das System ent-
hält einen Mikrocontroller, auf dem die Tasks und der Dispatcher in Form einer Interrupt
Service Routine (ISR) zur Ausführung kommen. Der Kommunikations-Controller verbindet
den Mikrocontroller mit dem zeitgesteuerten Bussystem FlexRay. Die Mikrocontroller und
Kommunikations-Controller im FlexRay-Netzwerk besitzen jeweils eine eigene Zeitbasis. Zur
Realisierung eines verteilten, zeitgesteuerten Systems muss eine einheitliche Zeitbasis geschaf-
fen werden.
Abb. 5.1: Zeitliche Kopplung zwischen Taskausführung und Kommunikation
Dieser Ansatz verwendet als Zeitbasis die Zeit des Kommunikations-Controllers, die in jeder
TDMA-Runde durch das FlexRay-Protokoll mit allen Busteilnehmern synchronisiert wird. Da-
durch wird innerhalb des Netzwerks eine globale Zeitbasis geschaffen. Die zeitgesteuerte Task-
Aktivierung basiert auf einem Timer des Kommunikations-Controllers, dessen Referenzwert
durch den Mikrocontroller programmiert wird. Der Timer erzeugt bei Erreichen dieses Werts
einen Interrupt, der den Dispatcher aktiviert. Dieser übernimmt auf Basis einer Dispatcher-
Tabelle die Aktivierung der Tasks.
5.1.2 Die Werkzeugkette zur Anwendungserstellung
Zur Anwendungsentwicklung werden Werkzeuge der Firma DECOMSYS, heute Elektrobit,

eingesetzt (Abb. 5.2). Diese Tools werden auch zur Implementation des ttAKS verwendet.
Der Entwicklungsprozess besteht im Wesentlichen aus den folgenden Arbeitsschritten:
1. Die Tasks, deren Abhängigkeiten und die verwendeten Mikrocontroller-Knoten werden

festgelegt und in einem Prozessgraphen modelliert.
Abb. 5.2: Werzeugkette zur Anwendungsentwicklung

2. Es werden für die Tasks des Prozessgraphens Prioritäten berechnet, die auf den Abhängig-
keiten und Ausführungszeiten der Tasks basieren. Der statische Offline-Scheduler erzeugt
den statischen Task-Schedule für jeden Knoten. Aus dem Task-Schedule der einzelnen
Knoten wird die Dispatcher-Tabelle abgeleitet. Zusätzlich wird ein Schedule mit allen
Tasks erzeugt, der zur Kommunikationsplanung verwendet wird.
3. Die Generierung des TDMA-Schedules wird mit dem Tool DECOMSYS::DESIGNER

v2.0 durchgeführt [DECOMSYS DESIGNER (2005)]. Dazu wird der Schedule aller
Tasks, die WCET der Tasks, die zu übertragenden Nachrichten und deren Bitlänge, sowie
die Knoten, deren Hardware-Eigenschaften und die Länge der Applikationsrunde benö-
tigt. Der daraus erzeugte TDMA-Plan enthält die Länge der TDMA-Runde, die Slotlänge
und die Zuordnung von Nachrichten zu den Slots.
4. Der Quellcode und die Parameter für die Kommunikations-Controller werden mit
dem Werkzeug DECOMSYS::GENERATOR [DECOMSYS GENERATOR (2005)]
und DECOMSYS::COMMSTACK<CONFIGURATOR> [DECOMSYS COMMSTACK
(2004)] erzeugt. Diese Werkzeuge sind Plug-Ins für den DECOMSYS::DESIGNER. Sie
erzeugen anwendungsspezifischen C-Quellcode, der während der Initialisierung des DE-
COMSYS::COMMSTACK<FLEXRAY> [DECOMSYS COMMSTACK FR (2006)] die
Parameter des Kommunikations-Controllers setzt.
Zur Implementation des ttAKS wird im zweiten Schritt statt des Directed Acyclic Graph (DAG)
als Variante ein Condtitional Process Graph verwendet. Das Scheduling-Verfahren aus Schritt
3 wird durch eine List-Scheduling-Heruristik ersetzt. Die Parameter für die Erstellung eines
TDMA-Plans werden bereits vor dem Scheduling festgelegt, da die Nachrichten während des
Scheduling-Vorgangs eingeplant werden. Nach dem Task-Scheduling wird nur die Zuordnung
der Nachrichten zu den Slots nach dem generierten Schedule durchgeführt, um mit den Werk-
zeugen Quellcode zur Nutzung der FlexRay-Controller zu generieren.
5.1.3 Der Dispatcher zur zeitgesteuerten Task-Aktivierung
Der Dispatcher verwendet als Grundlage die Dispatcher-Tabelle, die durch das statische Offline-
Scheduling generiert wird (vgl. Anhang A.2). Die Dispatcher-Tabelle enthält Einträge zu den
Tasks, die aufsteigend nach ihrem Aktivierungszeitpunkt zum Beginn der TDMA-Runde sor-
tiert sind (Abb. 5.3a).
Jeder Task-Eintrag der Dispatcher-Tabelle enthält (Quellcode A.1):
• Pointer auf die auszuführende Funktion.
• Offset in Microticks: entspricht dem Aktivierungszeitpunkt zum Beginn der Anwen-

dungsrunde
• Periode in TDMA-Runden: gibt an, nach wie vielen TDMA-Runden der Task erneut
aktiviert wird.
(a) Dispatcher Tabelle (DispatcherTable)
(b) Dispatcher-Variablen-Tabelle (DispatchVarTable)
(c) Initialisierung der Dispatcher-Variablen-Tabelle
(d) Beispiele zur Initialisierung der Dispatcher-Variablen-Tabelle bei einer TDMA-Runde von 50
Abb. 5.3: Dispatcher Tabellen und deren Initialisierung

Die Angabe des Offsets und der Periode erlauben es, Tasks einzuplanen, die nicht in jeder
TDMA-Runde auszuführen sind und Tasks in unterschiedlichen TDMA-Runden mit dem glei-
chen Aktivierungszeitpunkt in der TDMA-Runde zu realisieren.
Während der Initialisierung des Dispatchers wird eine Dispatcher-Variablen-Tabelle angelegt,

mit der der Dispatcher arbeitet (Abb. 5.3b, Quellcode A.5). Diese Tabelle enthält für jeden Task
(Quellcode A.2):
• tickOffset in Macroticks: gibt an, nach wie vielen Macroticks, ausgehend vom Beginn
der TDMA-Runde, der Task zu aktivieren ist.
• roundCounter in TDMA-Runden: Zähler, der die TDMA-Runden bis zur Aktivierung

dekrementiert. Ist der roundCounter Null, ist der Task in der aktuellen Runde auszu-
führen.
Zur Berechnung der beiden Werte wird der Offset aus der Dispatcher-Tabelle herangezogen
(Abb. 5.3c, Beispiele in Abb. 5.3d).
5.1.4 Implementation der zeitgesteuerten Task-Ausführung
Das hier vorgestellte Software-Konzept sieht eine zeitgesteuerte Taskausführung vor. Ein Inter-
rupt des Timers im Kommunikations-Controller triggert die Task-Aktivierung. Der Timer wird
mit jedem Macrotick inkrementiert. Als Vorgabe für den Interrupt wird ein Referenzwert durch
den Mikrocontroller programmiert, der beim Erreichen des Wertes den Interrupt auslöst. Die
Behandlung des Interrupts wird durch eine ISR im Mikrocontroller durchgeführt, die den Dis-
patcher und die Ausführung des eingeplanten Tasks beinhaltet. Die Abb. 5.4 verdeutlicht diese
Funktionsweise.
Die Anwendungen auf dem Mikrocontroller werden in der Programmiersprache C entwickelt,

die durch eine Main-Funktion gestartet wird (Abb. 5.5). Sie beinhaltet folgende Aktionen
(Quellcode A.3):
• Initalisierung des Mikro- und des Kommunikations-Controllers (Funktion ttStartupHook),

sie beinhaltet zudem die Initialisierung der FAUST-Anwendung.
• Initialisierung des Dispatchers
• Starten der Idle-Funktion
Die Initialisierung des Dispatchers (Abb. 5.6) beinhaltet:
• Die Generierung der Dispatcher-Variablen-Tabelle aus der Dispatcher-Tabelle.
• Bestimmung des Tasks, der als erstes gestartet wird. Dazu wird die Variable
nextTask_Index auf den ersten Eintrag der Dispatcher-Variablen-Tabelle gesetzt,
der einen roundCounter mit dem Wert 0 besitzt.
Abb. 5.4: Timing-Darstellung einer Beispielanwendung

Abb. 5.5: Aktivitätsdiagramm der Main-Prozedur
• Ausführen von Interrupt-Einstellungen: Deaktivieren der Interrupts der Mikrocontroller-

Peripherie, Aktivieren der Interrupts des Kommunikations-Controllers und der Interrupt
des Kommunikations-Controller-Timers, Aktivieren der Interrupts der Mikrocontroller-
Peripherie.
Auf die Initialisierung der Hard- und Software wird die Idle-Funktion ausgeführt (Abb. 5.8).
Sie wird ausgeführt, wenn die ISR nicht aktiv ist. Das erste Starten aktiviert die Interrupts
des Kommunikations-Controllers und plant den ersten Task ein, sobald der Kommunikations-
Controller mit dem FlexRay-Netz synchronisiert ist. Dazu wird der nextTask_Index verwen-
det, der während der Dispatcher-Initialisierung gesetzt wurde. Ist der erste Task eingeplant, wird
bei jedem Schleifen-Durchlauf die Idle_Task_Sleep Funktion ausgeführt.
Ein Interrupt unterbricht die Idle-Funktion und startet die Interrupt Service Routine. In der ISR
(Abb. 5.8) werden folgende Aktionen durchgeführt:
• Es wird ein Acknowledge des Interrupts durchgeführt, indem das definierte Flag für den
Interrupt gelöscht wird
• Der nextTaskIndex wird in der Variable currentTaskIndex gespeichert. Dieser In-

dex ist für die Ausführung des Tasks dieser Aktivierung notwendig.
• Die Dispatcher-Variablen-Tabelle wird nach dem Task für die nächste Aktivierung des
Dispatchers durchsucht. Ist der roundCounter eines Tasks größer 0, bedeutet dieses,
dass der Task in der aktuellen TDMA-Runde nicht auszuführen ist. Der roundCounter
wird daher dekrementiert und die Suche innerhalb der Tabelle beim nächsten Index fort-
gesetzt. Ist das Ende der Tabelle erreicht, wird die Suche am Index 0 fortgesetzt. Ist der
roundCounter eines Task Null, bedeutet dieses, dass der Task in der aktuellen TDMA-
Runde zu aktivieren ist. Damit ist der Task für die nächste Ausführung gefunden.
Abb. 5.6: Aktivitätsdiagramm der Initialisierungs-Prozedur

Abb. 5.7: Aktivitätsdiagramm der Idle-Prodzedur
• Der Referenzwert des Timers wird auf den Offset des gefundenen Tasks gesetzt.
• Es wird geprüft, ob der Kommunikations-Controller mit dem FlexRay-Netz synchroni-

siert ist. Ist dieses nicht der Fall, so werden die roundCounter der Dispatcher-Variablen-
Tabelle neu initialisiert und somit ein Neustart der Anwendung vorbereitet. Anschließend
wird ein Neustart des Kommunikations-Controllers durchgeführt und die Kommunikation
in den Offline-Modus versetzt.
• Ist der Kommunikations-Controller synchronisiert, so kann der Task für diese Aktivierung
ausgeführt werden.
• Mit dem Beenden des Tasks terminiert die ISR.

Abb. 5.8: Aktivitätsdiagramm der Dispatcher Interrupt-Service-Routine

5.2 Verfahren zum abestimmten Scheduling von verteilten

Echtzeit-Anwendungen
Dieses Kapitel stellt einen Ansatz zur Scheduling-Analyse vor, der u. a. durch die Professoren
Paul Pop und Petru Eles des Embedded Systems Lab der Universität Linköping entwickelt wur-
de ([Pop u. a. (2004)], [Eles u. a. (2000)], [Pop u. a. (2006)], [ESLAB (2007)]). Dieses ist der
einzige in einem Buch und mehreren Aufsätzen umfangreich dokumentierte Ansatz, der zur Zeit
zum Thema Scheduling von zeitgesteuerten Anwendungen und zeitgesteuerter Kommunikati-
on zu finden ist. Der vorgestellte Ansatz beinhaltet eine umfassende Analyse des Gesamtsys-
tems. Es wird von einem zeitgesteuerten Kommunikationsbus, der nach dem TDMA-Verfahren
arbeitet, und einer verteilten Architektur, bestehend aus programmierbaren Prozessoren und
dedizierter Hardware, ausgegangen. Die Komponenten sind über mehrere Busse miteinander
verbunden. Jeder programmierbare Prozessor kann genau einen Task zur Zeit ausführen, wäh-
rend die dedizierte Hardware Tasks parallel verarbeiten kann. Der Bus kann nur eine Über-
tragung zur Zeit ausführen. Die Tasks sind Prozessoren zugeordnet, wobei für jeden Task die
maximale Ausführungszeit (WCET) auf der entsprechenden Ressource bekannt ist. Für einen
Kommunikations-Task ist die zu übertragende Datenmenge bekannt. Ziel der Analyse ist es, die
Ausführungszeit der Anwendung, die auf dem System ausgeführt wird, zu minimieren, einen
statischen Schedule zu generieren und die Parameter des Kommunikationsprotokolls zu opti-
mieren.
5.2.1 Anwendungsmodellierung
Eine Anwendung für eingebettete Systeme wird als eine Menge von Funktionen bzw. Tasks
beschrieben, die gewisse Eingaben akzeptieren und Ausgabewerte erzeugen. Die Aufgabe des
Schedulings und Mappings beschäftigt sich mit einer Menge interagierender Tasks. Ein Task
ist eine Berechnungssequenz, die beginnt, sobald alle Eingabedaten verfügbar sind. Ist die
Ausführung abgeschlossen, werden Ausgabewerte produziert. Es wurden bisher Datenfluss-
Prozess-Netzwerke (Dataflow Process Networks, [Lee und Parks (1995)]) verwendet, um inter-
agierende Prozesse zu beschreiben. Dazu wurden gerichtete, azyklische Graphen verwendet, in
denen Knoten einem Task und gerichtete Kanten die Abhängigkeiten zwischen Tasks darstellen.
Ein Nachteil dieser Graphen ist es, dass sie keine Kontrollaspekte darstellen. Die Ausführung
von Tasks könnte z. B. von Konditionswerten, die vorherige Tasks erzeugt haben, abhängen. Die
Verwendung solcher Kontrollaspekte führt zur einer genaueren Modellierung und einer straffe-
ren Rechenzeitzuordnungen zu den Tasks.
In diesem Ansatz wird der Conditional Process Graph (CPG) als Modell verwendet, um das
Anwendungsverhalten zu repräsentieren. Dieser Graph erfasst nicht nur den Datenfluss und
den Kontrollfluss einer Anwendung, sondern eignet sich auch für die Erfassung von Timing-
Aspekten. Die Modellierung von Anwendungen wird in einem CPG vollzogen. In der hier zu
entwickelnden Anwendung auf der gegebenen Plattform werden Tasks betrachtet, da es sich
bei den Funktionen lediglich um Berechnungssequenzen und nicht um vollständige Prozesse
handelt. Die Bezeichnung CPG wird hier verwendet, da sie in der Literatur üblich ist und die
Art des Graphens verdeutlicht.
5.2.2 Conditional Process Graph
Der CPG erfasst sowohl den Datenfluss als auch den Kontrollfluss einer Anwendung und eignet
sich zudem zur Behandlung von Timing-Aspekten [Pop u. a. (2004)]. Eine Anwendung Γ wird
als Menge von Condtitional Process Graphs modelliert: Gi ∈ Γ. Ein CPG stellt einen gerichteten,
azyklischen und polaren Graphen dar: G(V , ES , EC ). Jeder Knoten repräsentiert einen Task im
Graphen: Pi ∈ V . E ist die Menge aller Kanten, die sich aus den einfachen und konditionierten
Kanten zusammensetzt: E = ES ∪ EC , ES ∩ EC = {}. Kanten verbinden Tasks und stellen den
Datenfluss dar. Eine Kante ei j ∈ E von Pi zu Pj bedeutet, dass die Ausgabe von Pi die Eingabe
von Pj ist. Eine Kante ei j ∈ EC ist eine konditionierte Kante, die einen Konditionswert besitzt.
Die Kante wird nur dann überschritten, wenn der angegebene Konditionswert wahr ist.
Die Eigenschaft polar bedeutet, dass es im Graphen eine Quelle und eine Senke gibt, die den
ersten und den letzten Task der Anwendung repräsentieren. Sie sind meist als Dummy-Tasks
mit einer Ausführungszeit von 0 und ohne eine Ressourcenzuordnung implementiert. Hieraus
folgt, dass alle Tasks der Anwendung Nachfolger der Quelle und Vorgänger der Senke sind.
Die Eigenschaft azyklisch bedeutet, dass es im Graphen keine Zyklen gibt. Ein Task darf keine
Nachfolger besitzen, die gleichzeitig auch Vorgänger des Tasks sind. Die Eigenschaft gerichtet
ist durch die Kanten gegeben. Sie legen die Vorgänger-Nachfolger-Beziehungen fest.
Ein zugeordneter CPG G(V ∗ , ES ∗ , EC ∗ , M ) wird durch Hinzufügen von zusätzlichen Tasks
(Kommunikations-Tasks) auf bestimmten Kanten und durch die Zuordnung von Tasks zu Res-
source gebildet. Kommunikations-Tasks werden auf solchen Kanten hinzugefügt, auf denen die
Vorgänger- und Nachfolger-Task auf unterschiedlichen Ressourcen zur Ausführung kommen
und Daten austauschen. Die Zuordnung von Tasks Pi ∈ V ∗ zu Prozessoren und Bussen wird
durch die Funktion M : V ∗ → PE beschrieben, wobei PE = {pe1 , pe2 ..., peNpe } eine Menge
an Ressourcen beschreibt. Die Menge der Ressourcen wird durch die Menge PE beschrieben,
wobei PP die Menge der programmierbaren Prozessoren und B die Menge der Busse darstellt:
PE = PP ∪ B. Zu jedem Prozess Pi ist M (Pi ) die Ressource, auf der Pi ausgeführt wird.
Die Abb. 5.9 zeigt den CPG einer Anwendung. Die Knoten stellen Tasks dar, die bereits Res-
sourcen zugeordnet sind, was durch die farblichen Hinterlegung gekennzeichnet wird. Zwischen
den Knoten befinden sich Kanten, wobei die konditionierten Kanten als dicke Linie dargestellt
werden. Die schwarzen Kreise auf den Kanten sind die Kommunikations-Tasks zwischen Tasks
auf unterschiedlichen Ressourcen, die Daten austauschen. Ein Datenaustausch zwischen Tasks
auf der selben Ressource wird nicht modelliert, da der Datenaustausch nicht über den Bus statt-
findet. Ein Knoten mit konditionierten Kanten als Ausgabe wird „Disjunction Node“ genannt.
Die alternativen Pfade dürfen nur disjunkte Konditionen besitzen. Sie werden in einem „Con-
junction Node“ zusammengeführt.
Ein CPG besitzt die folgende Ausführungssemantik:
• Alle Tasks geben beim Terminieren ihre Ausgabedaten aus.
• Ein Task, der kein Conjunction-Task ist, wird nur dann aktiviert werden, wenn alle Ein-
gabedaten zur Verfügung stehen.
• Ein Conjunction-Task wird aktiviert, sobald Eingabedaten von einem alternativen Pfad
eintreffen.
Abb. 5.9: Zugeordneter Conditional Process Graph einer Anwendung [Pop u. a. (2004)]
• Ein Boolscher Ausdruck XPi (Guard) kann jedem Knoten Pi zugeordnet werden. Er reprä-
sentiert die Bedingung unter der der Task aktiviert wird.
• Datenübermittlung bei konditionierten Kanten wird nur dann durchgeführt, wenn der
Konditionswert wahr ist und nicht, wie bei einfachen Kanten, bei jeder Aktivierung der
Eingabe-Task Pi
• Es werden folgende Ausführungsumgebungen angenommen: non pre-emptive und pre-

epmtive
Die Ausführungssemantik bezieht sich auf ein Single Rate System. Das bedeutet, dass ein Kno-
ten höchstens ein mal pro Aktivierung ausgeführt wird. Gibt es Tasks, die mehrmals ausgeführt
werden müssen, so muss dieses speziell behandelt werden. Dazu müssen mehrere CPGs mit
dem kleinsten gemeinsamen Vielfachem der Periode erstellt werden. Für die weitere Darstel-
lung des Scheduling-Verfahrens wird davon ausgegangen, dass alle Tasks und Nachrichten die
selbe Periode haben Ti = TGi , die der Periode des Graphen entspricht.
Spezifizierung der Timing-Informationen:
• NPi ist die Menge der Ressourcen, zu denen ein Task Pi zugeordnet werden kann. Für jede
Ressource pe j ∈ NPi ist die WCET Ci pe j des Tasks Pi bekannt, wenn sie auf der Ressource
pe j ausgeführt wird. Ein Task Pi besitzt eine Periode Ti und eine Priorität priorityPi .
• Kommunikations-Tasks haben eine Ausführungszeit Ci, j (Kommunikation von Pi zu Pj ),

die der Übertragungszeit entspricht. Zu jeder Nachricht m ist die Größe Sm bekannt. Eine
Nachricht wird ein mal in allen nm Aufrufen mit einer Periode von Tm = nm Ti gesendet,
die von dem Sende-Task Pi geerbt wird. Wird eine ereignisgesteuerte Kommunikation
(z. B. Controller Area Network (CAN))verwendet, besitzen die Nachrichten eine Priority
prioritym .
Die Zeiten der Tasks und Kommunikations-Tasks werden im Graphen rechts neben den Knoten
notiert. In Hard Real-Time Systemen ist dieses die WCET der Tasks. Wird die Aktivierungszeit
des Quell-Tasks betrachtet, so ist die Aktivierungszeit des Senken-Tasks die Ausführungszeit
der Anwendung bei einer gegebenen Ausführung. Diese Ausführungszeit muss kleiner als eine
angenommene Deadline DGi sein.
5.2.3 Modellierung von Tasks mit unterschiedlichen Perioden
Die Modellierung von CPGs mit unterschiedlichen Perioden wird so realisiert, dass für die
Tasks einer Periode ein Graph erstellt wird. Die Graphen werden vor dem Scheduling zu ei-
nem Gesamtgraphen zusammengeführt. Die Periode der Anwendung entspricht dem kleinsten
gemeinsamen Vielfachen der Perioden sller Graphen. Die Graphen, die eine kleiner Periode
als die Periode des Gesamtgraphen besitzen, werden mehrmals ausgeführt. Um die Periodi-
zität zu gewährleisten, werden Dummy-Nodes eingeführt, dessen WCET dem Vielfachen der
Periode entsprichen, die bis zur Ausführung abgelaufen ist. Nach der Ausführung wird ein
Dummy-Node eingeführt, der dem Vielfachen der verbleibenden Perioden entspricht, von dem
die Deadline abgezogen wird. Die Dummy-Nodes entsprechen Tasks, die auf keiner Ressource
ausgeführt werden.
Ein CPG für unterschiedliche Perioden zeigt die Abb. 5.10. Auf dieser Grafik entspricht G2
einem CPG mit einer Periode von 30 ms. Der Condtitional Process Graph G1 entspricht einem
Graphen mit einer Periode von 10 ms. Dieser wird in den drei Graphen G11 , G12 und G13
abgebildet. Der Graph G11 entspricht der ersten Ausführung zum Zeitpunkt 0 ms. Der Graph
G12 entspricht dem Graphen G1 , verzögert um eine Periode. Dazu wurde der weiße Knoten n1
erzeugt. Die Ausführungszeit von n1 entspricht der Länge einer Periode. Für den Graphen G13
gilt das gleiche. Die Knoten n3 , n4 und n5 besitzen die Ausführungszeit, die bis zum Ablauf der
Periode von 30 ms verbleibt.
5.2.4 Scheduling-Verfahren
Beim Scheduling einer Anwendung besteht die Schwierigkeit darin, dass bei jeder Ausführung
des Graphens nur eine Untermenge an Tasks ausgeführt wird, da einige Tasks aufgrund der
Abb. 5.10: CPG für unterschiedliche Perioden
Konditionen nicht ausgeführt werden. Der verwendete Scheduling-Algorithmus basiert auf ei-
ner List-Scheduling-Heuristik (Quelltext 5.1). Es wird dabei eine Schedule-Tabelle erzeugt. Auf
den einzelnen Komponenten befindet sich ein minimaler Scheduler, der anhand dieser Schedule-
Tabelle die Task-Aktivierung vornimmt.
Die List-Scheduling-Heuristik führt den folgenden Ablauf aus:
• Die List-Scheduling-Funktion wird mit den Parametern CurrentTime, ReadyList und

KnownConditions gestartet. CurentTime entspricht dem aktuellen Zeitpunkt innerhalb des
Schedulings. Zu Beginn des Schedulings ist dieser 0. Die ReadyList ist die Liste der zu
CurrentTime einplanbaren Tasks. KnownConditions ist eine Liste der zu CurrentTime be-
kannten Konditionswerte.
• Der Algorithmus durchläuft eine Repeat-Until-Schleife, die endet, wenn alle Tasks des
Zweiges eingeplant sind.
• Innerhalb der Schleife wird als erstes die Aktualisierung (Update) der ReadyList durch-
geführt. Es wird geprüft, ob zu CurrentTime Tasks beendet sind und somit nachfolgende
Tasks in die ReadyList aufzunehmen sind.
• Es wird versucht für jede Ressource eine Task einzuplanen. Dazu wird als erstes geprüft,
ob die Ressource zum Zeitpunkt CurrentTime eine Task ausführt. Ist dieses der Fall, wird
mit der nächsten Ressource fortgefahren. Ist dieses nicht der Fall, so wird aus der Ready-
List die Task mit der höchsten Priorität für diese Ressource entnommen.
• Gibt es einen Task in der ReadyList, so wird dieser in die Dispatcher-Tabelle einge-
fügt. Dabei werden die zu CurrentTime bekannten Konditionen berücksichtigt. Die-
ses ist erforderlich, da es unter unterschiedlichen Konditionen ein anderen Task-
Ausführungszeitpunkt geben kann.
• Nach dem Einplanen eines Tasks wird überprüft, ob es sich bei dem Task um einen
Disjunction-Task handelt. Dieses sind Tasks, die eine Kondition erzeugen und aus de-
nen konditionierte Kanten folgen. Handelt es sich um einen Disjunction-Task so wird die
List-Scheduling-Funktion für den Zweig mit dem wahren Konditionswert und für den
Zweig mit falschen Konditionswert rekursiv aufgerufen.
• Das List-Scheduling ist beendet, wenn alle Tasks eingeplant sind.
Quellcode 5.1: Pseudocode zum List-Scheduling Algorithmus [Pop u. a. (2004)]

1 Procedure ListScheduling(CurrentTime, ReadyList,
KnownConditions)
2 repeat
3 Update(ReadyList)
4 for each processing element PE do
5 if PE is free at CurrentTime then
6 Pi = GetReadyProcess(ReadyList)
7 if there exists a Pi then
8 Insert(Pi , ScheduleTable, CurrentTime,
KnownConditions)
9 if Pi is a disjunction process then
10 Ci condition calculated by Pi
11 ListScheduling(CurrentTime, ReadyList ∪ ready
nodes from the true branch, KnownConditions ∪
true Ci )
12 ListScheduling(CurrentTime, ReadyList ∪ ready
nodes from the false branch, KnownConditions ∪
false Ci )
13 end if
14 end if
15 end if
16 end for
17 CurrentTime = earliest time when a scheduled process
terminates
18 until all processes of this alternative path are scheduled
19 end ListScheduling
Die Prioritätsfunktion bestimmt die Reihenfolge konkurrierender Tasks. Die hier verwendete
Funktion bevorzugt Tasks, auf die eine zeitlich lange Task-Folge auf anderen Ressourcen folgt.
Sie wird im folgenden Abschnitt dargestellt.
Die Kommunikations-Tasks werden im List-Scheduling wie Programm-Tasks behandelt. Sie

werden statt auf einem Prozessor auf dem Kommunikationsbus eingeplant. Bei der Einplanung
der Nachrichten werden die Eigenschaften des Kommunikationsprotokolls berücksichtigt. Es
wird die Länge und die Reihenfolge der Slots berücksichtigt. Ist ein Slot bereits durch ande-
re Nachrichten gefüllt, so wird sie in der nächsten TDMA-Runde in dem entsprechenden Slot
eingefügt. Hierdurch ist die Ankunftszeit einer Nachricht definiert und die abhängigen Tasks
können entsprechend eingeplant werden. Zur Einplanung der Kommunikations-Tasks ist eine
weitere Funktion notwendig, die für die Einplanung von Tasks auf der Bus-Ressource ausge-
führt wird (Quellcode 5.2).
Quellcode 5.2: Pseudocode zum Message-Scheduling Algorithmus [Pop u. a. (2004)]

1 Procedure ScheduleMessage(TimeReady, Sm , Nodem )
2 Slot = the slot assigned to Nodem
3 Round = d TimeReady / RoundLength e
4 if TimeReady - Round * RoundLength > startslot then
5 Round = Round +1
6 end if
7 while Sm > Sslot - Soccupied do
8 Round = Round +1
9 end while
10 return (Round, Slot)
11
12 end ScheduleMessage
Der Message-Scheduling führt folgenden Ablauf aus:
• Der Algorithmus wird mit den Parametern TimeReady, Sm und Nodem gestartet. Time-
Ready entspricht dem Zeitpunkt, zu dem die Nachricht gesendet werden kann, Sm ist die
Länge der Nachricht und Nodem ist der Knoten, der die Nachricht erzeugt. Die Funktion
gibt als Rückgabewerte die früheste Runde und den dazugehörigen Slot zurück, in dem
die Nachricht gesendet werden kann.
• Es wird als erstes der Slot bestimmt, der dem sendenden Knoten zugeordnet ist.
• Anschließend wird die TDMA-Runde berechnet, in der die Nachricht als erstes gesendet
werden kann. Die Suche beginnt mit der ersten TDMA-Runde nach TimeReady.
• Es wird geprüft, ob der Slot in der gewählten Runde bereits verpasst wurde. Ist dieses so,
so wird mit der Suche nach einem Slot in der folgenden Runde fortgefahren.
• Es folgt die Suche nach dem frühesten Slot, der die zu sendende Nachricht aufnehmen
kann. Dazu wird in der While-Schleife geprüft, ob der aktuell gewählte Slot über genug
Platz für die zu sendende Nachricht verfügt. Es wird versucht mehrere Nachrichten in
einem Slot zu senden, um die Nachricht so früh wie möglich senden zu können. Besitzt
der Slot keinen ausreichenden Platz, so wird in der nächsten Runde fortgefahren. Passt
die Nachricht in den Slot, so ist der passende Slot gefunden.
Die Funktion zur Einplanung wird in der hier zu implementierenden Anwendung angepasst. Da
eine TDMA-Runde mehrere Slots besitzt, die dem gleichen Knoten zugeordnet werden können,
wird versucht, der nächste freie Slot in der selben Runde für die Übertragung gewählt, bevor
ein Slot in der folgenden TDMA-Runde gewählt wird.
5.2.5 Die PCP-Prioritätsfunktion
Die hier verwendete Prioritätsfunktion basiert auf der Betrachtung eines Teils des kritischen
Pfads und wird als Partial Critical Path (PCP) Funktion bezeichnet. Prioritäten auf Basis des kri-
tischen Pfads entsprechenden der Summe der WCET vom betrachteten Knoten bis zum Senken-
Knoten. Die PCP-Funktion bevorzugt Tasks, auf die eine zeitlich lange Folge von Tasks auf
anderen Ressourcen folgt. Dazu wird eine untere Grenze L betrachtet, die die gesamte Laufzeit
von zwei konkurrierenden Task-Ketten betrachtet.
Abb. 5.11: Laufzeitannahmen zur Prioritätsfunktion
Zur Bestimmung des auszuführenden Tasks wird die untere Grenze L für konkurrierende Task-
Ketten betrachtet. Die Tasks PA und PB in Abb. 5.11 sind zwei konkurrierende Tasks einer
Ressource. Die Tasks PA bis PX und die Tasks PB bis PY werden auf der selben Ressource
ausgeführt. Die dafür notwendige Ausführungszeit wird als tA bzw. tB bezeichnet. Die restliche
Ausführungszeit zur Ausführung des Graphen wird als λa und λb bezeichnet. Diese enthält
Tasks und Kommunikations-Tasks des restlichen Graphens. Die untere Grenze für die Tasks PA
und PB wie folgt berechnet, wobei T_Current dem aktuellen Ausführungszeitpukt entspricht:
LPA = max(T _Current + tA + λA , T _Current + tA + tB + λB )
LPB = max(T _Current + tB + λB , T _Current + tB + tA + λA )
Die Alternative, die eine kürzere Laufzeit für die Anwendung aufweist, wird verwendet:
L = min(LPA , LPB ). Wie in [Pop u. a. (2004)] beschrieben, wurde für λA > λB beobachtet, dass
LPA > LPB ist und für λB > λA wurde LPB > LPA beobachtet. Daraus lässt sich schließen, dass für
einen Task der Teil des Graphens die Priorität bestimmt, der auf einer anderen Ressource ausge-
führt wird. Durch die Bevorzugung dieser Tasks wird das parallele Arbeiten gefördert, da Tasks
auf anderen Ressourcen früher ausgeführt werden und anschließend die Tasks auf der eigenen
Ressource parallel ausgeführt werden. Eine Prioritätsfunktion, die die PCP-Funktion erweitert
(Modified Partial Critical Path (MPCP)), wird in [Pop u. a. (2004)] dargestellt. Sie verbessert
den Schedule, in dem zur Scheduling-Laufzeit die Prioritäten für die Tasks bestimmt werden.
5.2.6 Optimierungsverfahren
Die Dokumentation zum vorgestelleten Ansatz stellt Methoden zur Optimierungen der
Busprotokoll-Parameter vor [Pop u. a. (2004)]. Dabei sind Optimierungen an der Slotgröße
und der Reihenfolge der Slotzuordnung durchführbar. Eine Anpassung der Slotgröße ist dann
sinnvoll, wenn es viele Nachrichten gibt, die nicht in der aktuellen TDMA-Runde, sondern
erst eine TDMA-Runde später gesendet werden müssen, da der Slot bereits voll ist. Kann eine
Nachricht früher gesendet werden, so kann dieses zu einem kürzerem Schedule führen, wenn
durch die Änderung andere Nachrichten nicht verzögert werden. Eine weitere Möglichkeit ist
die Anpassung der Slotreihenfolge. Durch Vertauschung der Zuordnung kann ebenfalls ein
kürzeres Schedule erzeugt werden. In dieser Arbeit werden keine Methoden zur Optimierungen
der Schedules angewendet.
6 Systemübersicht zum AKS und
Timing-Analyse der
Renesas-Zielplattform
Dieses Kapitel dokumentiert zu Beginn eine Systemübersicht zum Antikollisionssystem (AKS)

und der Antriebsregeleung und Fahrzeugkoordinierung. Es werden die Anwendungen erläutert
und deren Funktionen im Hinblick auf die Implementierung verdeutlicht. Des Weiteren wer-
den die durch die Zielplattform gegebenen Anwendungsrandbedingungen aufgestellt. Aus der
Systemübersicht und den Timing-Eigenschaften der Zielplattform für das ttAKS werden Imple-
mentierungsschritte abgeleitet.
6.1 Systemübersicht zum ereignisgesteuerten

Antikollisionssystem
In einer Masterarbeit [Schetler (2007)] wurde ein etAKS für das Sensor Controlled Vehicle
(SCV) entwickelt, das auf den Arbeiten [Pröhl (2006)] und [Cordes (2006)] basiert. Das etAKS
wird hier vorgestellt, um die Implikationen für die Transformation in ein zeitgesteuertes Sys-
tem aufzuzeigen. Das etAKS basiert auf einer Laserscanner-basierten Abstandsregelung. Ein
Eingriff durch die Anwendung (Abb. 6.1) soll nur dann erfolgen, wenn eine Kollision mit dem
Hindernis unmittelbar bevor steht. Der Fahrzeugführer behält längst möglich die Kontrolle über
das Fahrzeug. Damit einem Hindernis ausgewichen werden kann, wird mit dem Laserscanner
SICK LD-OEM 1000 der Bereich vor und neben dem Fahrzeug abgetastet. Die Messdaten wer-
den über den CAN-Bus alle 50 ms übertragen. Ein Algorithmus erkennt Objekte im abgetasteten
Bereich und berechnet deren Entfernung. Aus den Daten wird der letzte Zeitpunkt berechnet, zu
dem ein Ausweichen notwendig ist, und leitet bei Bedarf einen Ausweichvorgang ein. Im An-
hang B.1 ist eine Auflistung der Funktionen des etAKS und der dazugehörigen Quelltext-Datei
zu finden.
Die Software des etAKS ist nach einer Drei-Ebenen-Struktur aufgebaut:
• Situationserfassung: Erfassung der Umgebungs- und Fahrzeugsituation durch die Sensor-

daten des Laserscanners.
• Situationsanalyse und Aktionsentscheidung: Beurteilung der Situation und die anschlie-

ßende Bestimmung der Reaktion.
• Aktionsausführung: Ausführung der gewählten Aktion, z. B. Ausweichvorgang

Abb. 6.1: Thread-Übersicht Antikollisionssystem [Schetler (2007)]
Die Software kommt als nebenläufige Anwendung auf der in Kapitel 2 dargestellten Plattform
zur Ausführung (Abb. 6.1). Das System besteht aus einem ereignisgesteuerte Koordinierungs-
system, das um das etAKS erweitert wurde. Das Koordinierungssystem ist die Verbindung zwi-
schen dem Kommunikationsrechner, der die Soll-Werte vom Leitstand empfängt und weiterlei-
tet, und den Regelungscontrollern, die die Antriebseinheiten ansteuern und Ist-Werte auslesen,
die über den Kommunikationsrechner an den Leitstand übertragen werden. Das ursprüngliche,
ereignisgesteuerte Koordinierungssystem besteht aus sechs Threads, die über Message-Queues
kommunizieren und nach dem Round-Robin Scheduling-Verfahren abgearbeitet werden (Abb.
6.1):
• Main-Thread: Initialisiert Message-Queues, startet die Kommunikations-Threads und den

Steuerautomat-Thread.
• CAN-Empfang-Thread: Verarbeitet die über den CAN-Bus empfangenen Daten. Es wird

geprüft, ob es sich um Soll-Daten vom Leitstand oder Ist-Daten von den Regelungscon-
trollern handelt. Die Daten werden in eine interne Nachrichtenstruktur verpackt und dem
Steuerautomaten-Thread über die Message-Queue zur Verfügung gestellt.
• CAN-Versand-Thread: Bearbeitet den Versand der Nachrichten, die durch den Steuerau-
tomaten in einer internen Nachrichten-Struktur verpackt werden.
• Steuerautomat-Thread: Beinhaltet einen reaktiven Automaten, der zustandsabhängige

Entscheidungen zur Steuerung durchführt. Für die Ausführung von zeitgesteuerten Er-
eignissen sind die Timer-Tick- und Timer-Execute-Threads zuständig.
• Timer-Tick- und Timer-Execute-Thread: Zur Ausführung von zeitgesteuerten Ereignissen

ist eine Zählerliste implementiert. Bei jedem Durchlauf des Timer-Tick-Threads werden
die Zähler der Liste dekrementiert. Der Timer-Execute-Thread prüft, ob einer der Zähler
abgelaufen ist, und generiert Ereignisse für den Steuerautomaten.
In das Koordinierungssystem wurde die Drei-Ebenen-Struktur des etAKS integriert. Es wurden

drei Threads hinzugefügt und Änderungen an den bestehenden Threads vorgenommen. Eine
Übersicht der Threadstruktur bietet die Abb. 6.1:
• Situationserfassung-Thread: Dieser hinzugefügte Thread führt die Initialisierung des La-

serscanners und die Erfassung und Aufbereitung der Laserscannerdaten aus. Die aufbe-
reiteten Daten werden über ein Messwerte-Array der Situationsanalyse- und Aktionsent-
scheidung zur Verfügung gestellt.
• CAN-Versand-Thread: Während der Initialisierung müssen Daten vom Situationsanalyse-

Thread an den Laserscanner gesendet werden, was eine Anpassung des CAN-Versand-
Threads zur Folge hat.
• CAN-Empfang-Thread: Die gemessenen Laserscannerdaten werden über den CAN-Bus

übertragen. Der CAN-Empfang-Thread muss zusätzlich die Laserscannerdaten unter-
scheiden und sie über eine Message-Queue der Situationserfassung zur Verfügung stellen.
• Situationsanalyse- und Aktionsentschheidung-Thread: Dieser Thread umfasst die Objek-

terkennung, die beim Eintreffen neuer Daten gestartet wird. Die neuen Objektdaten und
der Fahrzeugzustand werden verwendet, um die Kollisionskoordinaten und -zeitpunkte
mit anderen Objekten zu ermitteln. Die Ergebnisse werden dem Aktionsentscheidungs-
modul zur Verfügung gestellt. Soll eine Aktion ausgeführt werden, wird der Thread zur
Aktionsausführung gestartet.
• Aktionsausführung-Thread: Die Ausführung eines durch den Entscheider gewählten Aus-

weichvorgangs wird durch diesen Thread durchgeführt. Der Ausweichvorgang wird durch
die Erzeugung von Soll-Werte für den Steuerautomaten erzeugt. Ist das Ausweichmanö-
ver abgeschlossen, verwendet der Steuerautomat wieder die Soll-Daten des Leitstands.
• Steuerautomat-Thread: Der Steuerautomat musste so angepasst werden, dass während der

Ausführung eines Ausweichmanövers nur die Soll-Werte der Aktionsausführung genutzt
werden und die Vorgaben durch den Leitstand verworfen werden.
• Odometrie-Thread: Mit einem kinematischen Fahrzeugmodell wird die relative Position

des Fahrzeugs zum Ausgangspunkt ermittelt. Dazu werden die Ist-Werte aus den Rege-
lungscontrollern empfangen und verarbeitet. Die Odometrie-Daten werden für den Aus-
weichvorgang verwendet.
6.1.1 Die Odometrie des etAKS
Die Odometrie-Funktion des etAKS wird zur Ermittlung der Fahrzeugposition verwendet. Wäh-
rend der Initialisierung des Threads werden die Odometrie-Daten auf Null gesetzt. Die Ausführ-
ung findet in einer While-Schleife statt, die beim Eintreffen von Nachrichten mit Ist-Daten für
die Geschwindigkeit und den Lenkwinkel durchlaufen wird. Die Ist-Daten werden ausgewertet
und der zurückgelegte Weg berechnet. Daraus wird die Position relativ zur Ausgangsposition
bestimmt. Die Odometrie wird in dieser Anwendung nur während des Ausweichvorgangs ver-
wendet. Sie bietet nach außen folgende Funktionen:
• getOdometrieDaten(): bietet Zugriff auf die errechnete Position
• resetOdometrieDaten(): dient dem Setzen der Odometrie-Daten auf Null
• setOdometrieAchswinkel(neuerAchwinkel): setzt den internen Achswinkelwert

auf den übergebenen Wert
• printOdometrieDaten(): bewirkt eine Ausgabe der Odometrie-Daten auf der Kon-

sole
Aus dem Überblick zur Odometrie-Funktion lassen sich die folgenden Implikationen für die
Transformation in eine zeitgesteuerte Ausführung ableiten:
• Auflösung der While-Schleife in eine sequentiell Funktion mit periodischer Ausführung
• Notwendige Eingabe-Daten sind die Ist-Daten der Antriebseinheiten aus der Antriebsre-
gelung
• Ersetzung der Funktionen getOdometrieDaten() und printOdometrieDaten()

durch Ausgabe der Daten beim Terminieren
• Ausgabe-Daten werden von der Aktionsausführung benötigt
• Ausführung der Funktion daher zwischen der Antriebsregelung und Aktionsausführung
• Implementierung von resetOdometrieDaten() und setOdometrieAchswin-

kel(neuerAchswinkel) erfordert Eingabe-Daten von der Aktionsausführung. Dieses
bietet zwei Implementierungsvarianten: 1. Die Anforderungen werden als Eingangs-
Daten definiert und zu Beginn der Odometrie-Funktion ausgewertet. Da die Daten von
der Aktionsausführung geliefert werden und die Odometrie-Funktion Daten für die
Aktionsausführung generiert, müssen die Daten des vorherigen Ausführungszyklus der
Aktionsausführung verwendet werden. 2. Die beiden Funktionen werden als separate
Funktionen definiert, die nach der Aktionsausführung im selben Ausführungszyklus
ausgeführt werden.
6.1.2 Die Situationserfassung des etAKS
Die Situationserfassung ist für die Initialisierung des Laserscanners und die Aufbereitung der
Messdaten zuständig, die vom Laserscanner empfangen werden. Während der Initialisierung
ist eine bidirektionale Kommunikation mit dem Laserscanner erforderlich, die im Normalbe-
trieb, Erfassung der Messwerte, unidirektional wird. Nach der Initialisierung wird eine While-
Schleife ausgeführt, in der auf Nachrichten mit Daten vom Laserscanner gewartet wird. So-
bald Daten eintreffen, werden die Nutzdaten extrahiert und ausgewertet. Die Daten durchlaufen
einen Filteralgorithmus und werden anschließend in ein Messwerte-Array geschrieben, das von
der Situationsanalyse und Aktionsentscheidung zur weiteren Untersuchung genutzt wird. Als
Filteralgorithmus wird räumliches Filter verwendet [Schetler (2007)].
Aus der Übersicht lässt sich für die Transformation der Funktion in eine zeitgesteuerte Ausführ-
ung folgendes festhalten:
• Als Eingabe-Daten sind die Messdaten vom Laserscanner notwendig.
• Die Daten des Laserscanners werden alle 50 ms übertragen. Die Ausführung ist daher
vom Eintreffen der Daten abhängig.
• Die aufbereiteten Daten werden von der Situationsanalyse und der Aktionsentschiedung
benötigt. Eine Ausführung ist daher vor diesen Funktionen sinnvoll.
6.1.3 Die Situationsanalyse und Aktionsentscheidung des etAKS
Die Situationsanalyse und Aktionsentscheidung gliedert sich in drei Funktionen:
• Objekterkennung: Die Umgebungsanalyse ist zusammen mit dieser Funktion in einem

Thread implementiert. Es werden Messwerte aus dem Messwerte-Array der Situations-
analyse verwendet, um Objekte aus dem Messbereich zu identifizieren. Als Ausgabe wird
eine Liste von Objekten erzeugt.
• Umgebungsanalyse: Als erstes werden die Objektdaten analysiert, wenn kein Ausweich-
manöver ausgeführt wird. Es wird aus der Menge von Objekten das mit dem nähesten
Kollisionszeitpunkt ermittelt. Zu diesem Objekt werden Aufprallinformationen wie Zeit-
punkt und Koordinate der Kollision berechnet. Konnten keine Daten ermittelt werden,
befindet sich im abgetasteten Bereich kein Hindernis. Wurden Daten generiert, wird der
Fahrzeugstatus ermittelt. Es wird geprüft, ob die Zeit ausreicht, um mit einer Vollbrem-
sung vor dem Hindernis zum Stehen zu kommen. Anschließend wird überprüft, ob ein
Ausweichvorgang rechts und links vom Objekt durchführbar ist. Diese Signale werden
an den Entscheider-Automaten weitergegeben.
• Aktionsentscheidung: Diese Funktion ist als reaktiver Automat in einem eigenen Thread
implementiert. Der Automat ist so aufgebaut, dass er erst dann in die Fahrzeugsteuerung
eingreift, wenn der späteste Zeitpunkt zur Kollisionsvermeidung erreicht ist. Es sind vier
Ereignisse zur Situationsbeurteilung definiert: Lon , Lo f f , Ron , Ro f f . Sie geben an, ob ein
Ausweichen rechts oder links vom Hindernis durchführbar ist. Solange die Ausweichzeit
kleiner als die berechnete Aufprallzeit ist, wird Lo f f bzw. Ro f f gesendet, sonst Lon bzw.
Ron . Der Automat besitzt vier Zustände mit Z_ENT als Startzustand(Abb. 6.2). Er zeigt
an, dass links und rechts vom Hindernis Ausweichvorgänge möglich sind. Tritt das Signal
Lon auf, so bedeutet dieses, dass ein Ausweichen links vom Hindernis nicht mehr möglich
ist. Der Automat geht in den Zustand Z_ENT_L über. Es wird noch keine Aktion durch-
geführt, da ein Ausweichvorgang nach rechts möglich ist und der Fahrzeugführer ein
Ausweichen durchführen kann. Kommt das Fahrzeug in eine Situation, in der ein Links-
ausweichen wieder möglich ist oder sich kein Hindernis vor dem Fahrzeug befindet, so
tritt Lo f f auf und der Automat geht in den Zustand Z_ENT über. Folgt auf Lon Ron , geht
der Automat in den Zustand Z_ENT_LR und ein Rechts-Ausweichen-Manöver wird aus-
geführt bis Ro f f oder Lo f f auftritt. Das gleiche gilt für die Kombination Ron , Lon . Tritt der
Fall ein, dass ein Ausweichen rechts und ein Ausweichen links zum gleichen Zeitpunkt
nicht mehr möglich sind, muss eine Entscheidung getroffen werden, welches Ausweich-
manöver durchgeführt werden soll. Die Implementierung sieht vor, dass das Signal Lon
vor Ron an den Entscheider gesendet wird. Dieses legt fest, dass ein Rechtsausweichen
durchgeführt wird.
Abb. 6.2: Entscheidungsautomat für die Aktionsausführung [Schetler (2007)]
Aus der Übersicht zur Situationsanalyse und Aktionsentscheidung lassen sich diese Folgerun-
gen ableiten:
• Die drei Funktionen Objekterkennung, Umgebungsanalyse und Aktionsentscheidung

sind voneinander abhängig, da sie jeweils Informationen für die nächste Funktion er-
zeugen. Die Funktionen können daher sequentiell nacheinander ausgeführt werden.
• Die Objekterkennung hängt von der Situationserfassung ab, da sie die Daten aus dem
Messwerte-Array benötigt. Zusätzlich werden als Eingangs-Daten die Ist-Daten für Ge-
schwindigkeit und Lenkwinkel aus der Antriebsregelung benötigt.
• Die zeitgesteuerte Umgebung ist für die Ausführung von ereignisgesteuerten Automaten
nicht geeignet, da die Reaktion des Automaten von der zeitlichen Reihenfolge der Ereig-
nisse abhängt. Daher sind Methoden für die Transformation des Automatens erforderlich.
6.1.4 Die Aktionsausführung des etAKS
Die Aktionsausführung wird vom Thread für die Objekterkennung und Umgebungsanalyse ge-
startet. Die Entscheidung, welches Manöver ausgeführt werden soll, wird vom Entscheider-
Automat getroffen. Ist die Entscheidung kein Manöver getroffen, wird keine Aktion ausgeführt.
Für die anderen Entscheidungen wird der passende Thread gestartet. Dieser läuft nebenläufig
zu den anderen Funktionen des etAKS.
• Zur Ausführung der Funktion werden Odometrie-Daten, die Ist-Daten für Geschwindig-
keit und Lenkwinkel und die Objektdaten des Hindernisses benötigt. Daher muss diese
Funktion nach den bisherigen Funktionen des etAKS ausgeführt werden.
• Als Ausgabe der Funktion werden Soll-Werte generiert, die in die Antriebsregelung ein-
gehen. Da die Ausführung der Aktionsausführung wiederum von der Antriebsregelung
abhängt, ist es sinnvoll die Solldaten in dem folgenden Ausführungszyklus der Antriebs-
regelung einfliessen zu lassen.
• Die Funktion nutzt Funktionen zum Odometrie-Daten-Reset und Achswinkelsetzen der

Odometrie. Werden die Funktionen einzeln implementiert, sollten diese Funktion Daten
zur Anforderung generieren.
6.2 Systemübersicht zur zeitgesteuerten Antriebsregelung

und Fahrzeugkoordinierung
Im Rahmen einer Masterarbeit [Sellentin (2006)] wurde aus dem ereignisgesteuertes Antikol-
lisionssystem (etAKS) die Antriebsregelung und Fahrzeugkoordinierung auf einer zeitgesteu-
erten Plattform (vgl. Kapitel 2) implementiert. Dabei werden die Funktionen auf zwei Knoten
ausgeführt, die über den FlexRay-Bus kommunizieren(vgl. Kapitel 2). Der Graph in Abb. 6.3
zeigt die Tasks der Anwendung:
• Im oberen Teil des Graphens befinden sich Tasks zum Einlesen der Soll-Werte für Ge-
schwindigkeit und Lenkwinkel, sowie die Auswertung der Status des vorderen und hin-
teren Knotens.
• Diese Informationen gelangen über das Eingangsfilter in die Koordinierung, die den Steu-
erautomaten aus der ereignisgesteuerten Software abbilden. Die beiden Funktionen sor-
gen dafür, dass die gültigen Sollwerte an die Regelungs-Tasks weitergegeben werden.
• Der untere Teil des Graphen beinhaltet die Geschwindigkeits- und Lenkwinkelregelung.
Es werden an beiden Antriebseinheiten gleichzeitig die Ist-Daten aufgenommen, die den
Regelungs-Tasks zur Verfügung gestellt werden. Diese berechnen neue Stellgrößen für
Geschwindigkeit und Lenkwinkel aus den Soll- und Ist-Daten, die an die gleichzeitig
geplanten Stell-Tasks weitergegeben werden.
• Zusätzlich werden die Ist-Daten zur Anzeige an den Leitstand übertragen.
Zwischen den Messen- und Stellen-Tasks auf den beiden Knoten besteht eine Gleichzeitigkeits-
beziehung, die ein gleichzeitiges Messen bzw. Stellen der Größen an beiden Antriebseinheiten
erzwingt.
Die Anwendung ist bereits in Tasks aufgeteilt, die auf zwei FlexRay-Knoten zum Einsatz kom-
men. Der Implementierungsaufwand zur Integration in eine neue Anwendung ist daher gering.
Es ist erforderlich, dass der Graph in einen CPG transformiert wird. Bei der Integration in einen
neuen Graphen ist u. U. die Knotenzuordnung anzupassen. Die Tasks für die Statusauswertung
Abb. 6.3: DAG zur zeitgesteuerten Antriebsregelung und Fahrzeugkoordinierung ([Sellentin

(2006)])
des vorderen und hinteren Knotens sowie die Tasks für das Messen und Stellen der Geschwin-
digeit und des Lenkwinkels haben eine feste Zuordnung, da sie mit der ihnen zugeordneten
Hardware kommunizieren. Die Tasks, die mit den Kommunikationsrechner und der Führungs-
box über CAN kommunizieren, müssen so zugeordnet werden, dass sie eine CAN-Schnittstelle
mit Anschluss an diese beiden Teilnehmer besitzen.
In der Masterarbeit [Sellentin (2006)] wurde die Auslastung der beiden Knoten berechnet. Sie
beträgt für den vorderen Knoten 0,215 und für den hinteren Knoten 0,525. Diese Angaben be-
ziehen sich auf die geschätzten Ausführungszeiten der Tasks. Die tatsächlich gemessenen Tas-
kausführungszeiten (Tabelle 7.1) sind deutlich geringer als die geschätzten Werte. Die Berech-
nung der Knotenauslastung an Hand der gemessenen Werte ergibt eine Auslastung von 0,0302
für den vorderen Knoten und 0,0933 für den hinteren Knoten. Dieses zeigt, dass die Knoten
bei Ausführung der zeitgesteuerte Antriebsregelung und Fahrzeugkoordinierung ausreichend
Reserve für zusätzliche Anwendungen bieten. Die zeitgesteuerte Anwendung beinhaltet kei-
ne numerischen Operationen. In den Funktionen des etAKS werden numerische Operationen
durchgeführt. Dieses macht eine Timinganalyse für diese Operationen notwendig.
6.3 Anwendungsrandbedingungen
Die zu implementierende Anwendung aus Geschwindigkeits- und Lenkwinkelregelung und An-

tikollisionssystem (AKS) unterliegt Randbedingungen, die in dem folgenden Abschnitt darge-
stellt werden.
Die Zielplattform besteht aus zwei Renesas-Knoten, die einen M32C/85 Mikrocontroller mit
einer Taktrate von 24 MHz enthalten (vgl. Kapitel 2). Der Mikrocontroller verfügt über keine
FPU, wodurch Berechnungen nur in Ganzzahlen durchgeführt werden. Die Berechnung von
Gleitkommazahlen ist sehr aufwendig, da spezielle Funktionen zur Berechnung und Umwand-
lung der Zahlen notwendig sind.
Das ereignisgesteuerte Antikollisionssystem (AKS) ist auf einem GEME-Rechner ausgeführt

worden. Dieser verfügt über eine Taktfrequenz von 650 MHz und eine FPU (vgl. Kapitel 2).
Gegenüber dem Renesas Mikrocontroller verfügt er über eine 27-fach höhere Taktfrequenz.
Die Ausführung der Anwendung wird daher auf dem Mikrocontroller deutlich mehr Zeit in
Anspruch nehmen. Da er zusätzlich keine FPU für Operationen mit Gleitkommazahlen besitzt,
sind Gleitkomma-Operationen zu vermeiden.
Die Tasks des ttAKS sollen in der Umgebung der zeitgesteuerten Antriebsregelung und Fahr-
zeugkoordinierung (vgl. Kapitel 5.1) ausgeführt werden. Die zeitgesteuerten Tasks besitzen un-
terschiedliche Perioden. Die Länge der Applikationsrunde wird durch das kleinste gemeinsame
Vielfache der Task-Perioden bestimmt werden. Die Tasks eines Knotens müssen kleiner als die
kleinste Task-Periode auf dem Knoten sein, damit die Perioden eingehalten werden. Sind die
Task-Ausführungszeiten bekannt, ist ein Scheduling durchführbar. Sollten die Ausführungszei-
ten länger als die kleinste Task-Periode sein, so müssen Maßnahmen wie die Code-Optimierung
der Funktion oder Anpassung der Perioden erfolgen.
6.4 Umsetzungskonzept für das ttAKS
Dieses Kapitel beschreibt, welche Schritte zur Umsetzung der Anwendung erforderlich sind.
Dazu werden die Implementationsschritte aufgelistet. Des Weiteren werden die Schritte zur
Transformation des etAKS in das ttAKS und die Ansätze zur Optimierung der Anwendung
dargestellt.
6.4.1 Implementationsschritte
Die Implementation der Anwendung soll in mehreren Schritten vollzogen werden, die im fol-
genden dargestellt werden:
• Umwandlung des etAKS in eine zeitgesteuerte Ausführung. Dieses beinhaltet die Auf-
spaltung des etAKS in Funktionen, die als periodische Tasks implementiert werden. Da-
bei sollen die Perioden der zeitgesteuerten Tasks den Perioden der ereignisgesteuerten
Anwendung entsprechen.
• Modellierung der Funktionen in CPGs, die die Abhängigkeiten zwischen den Tasks und
die Datenflüsse darstellen. Diese dienen als Grundlage für die Implementation und das
Scheduling der Anwendung.
• Messung der Task-Ausführungszeiten der transformierten AKS-Funktionen. Diese sind

für das Scheduling der Anwendung erforderlich.
• Wird festgestellt, dass die Ausführungszeiten von einzelnen Tasks aufgrund der Numerik
so lang ist, dass sie nicht innerhalb der kleinsten Periode ausführbar ist, so sind Code-
Optimierungen durchzuführen, um die Ausführungszeit zu minimieren.
• Aus den CPGs der einzelnen Funktionen wird ein CPG für die gesamte Anwendung er-
zeugt, der die unterschiedlichen Perioden berücksichtigt. Dabei sind die Tasks den Res-
sourcen so zuzuordnen, dass sie die Hardwareanforderung erfüllen und keine Überlast
auf den Knoten erzeugen.
• Generierung eines Schedules anhand des CPGs für die Gesamtanwendung.
• Implementierung der Funktionen und des Schedules auf der Zielplattform
• Test und Timingmessung der Anwendung
6.4.2 Transformation des etAKS in eine zeitgesteuerte Ausführung
Die bisherige Implementation des AKS sieht eine nebenläufige ereignisgesteuerte Ausführung
vor. Die Software besteht aus mehreren Threads, die die einzelnen Funktionen kapseln. Diese
Threads müssen in der zeitgesteuerten Ausführung aufgelöst werden und in sequentielle Funk-
tionen, die periodisch aufgerufen werden, abgebildet werden. Unter den Threads befindet sich
der Entscheidungsautomat, der auf Ereignisse aus den anderen Threads reagiert (vgl. Abb. 6.2).
Die Funktionsweise des Automaten ist dabei von der Reihenfolge der eintreffenden Ereignisse
abhängig. Bei der Transformation muss beachtet werden, dass in der zeitgesteuerten Ausführ-
ung nicht nebenläufig auf Ereignisse reagiert werden kann. Zur Umformung des Automaten
wird ein Ansatz aus einer Masterarbeit verwendet, der sich in der Praxis bewährt hat [Sellentin
(2006)]. Die Kommunikation zwischen den Threads findet ausschließlich über Message-Queues
statt. Diese werden in dem zeitgesteuerte Ansatz nicht verwendet, da auf Nachrichten bzw. Da-
ten nicht gewartet werden muss. Das zeitgesteuerte Konzept sieht vor, dass die Daten, die von
einer Task benötigt werden, vor der Ausführung vorhanden sind. Dazu werden die Datenab-
hängigkeiten im Graphen berücksichtigt und Tasks erst eingeplant, wenn die Eingangs-Daten
verfügbar sind. Welche Daten über FlexRay zu übertragen sind, ist von dem Mapping der Tasks
abhängig. Diese lassen sich, abhängig von den Task-Abhängigkeiten, auf den beiden Knoten
verteilten, um die verfügbare Rechenleistung besser auszunutzen.
Neben den Anpassungen aufgrund der Transformation sind durch die Ausführung der Softwa-
re auf einer anderen Plattform Randbedingungen gegeben. Wie im vorherigen Kapitel bereits
beschrieben, besitzt der Mikrocontroller eine deutlich geringer Rechenleistung als der GEME-
Rechner (vgl. Kapitel 2). Dadurch erhöhen sich die Ausführungszeiten der Tasks. Zusätzlich
sind in den Funktionen Berechnungen mit Gleitkommazahlen vorgesehen. Da der Mikrocon-
troller über keine FPU verfügt, sind u. U. Code-Optimierungen erforderlich.
6.4.3 Timing-Messungen der ttAKS-Funktionen
Die Messungen der Task-Ausführungszeiten werden auf einem Renesas-Microcontroller der

Zielplattform durchgeführt. Die Funktionen des ttAKS werden dazu so angepasst, dass sie ein-
zeln, ausgeführt werden. Die Messung wird mit Hilfe des PC Oszilloskops PicoTech 3204 und
der Software PicoScope 6 durchgeführt. Gemessen wird an einem digitalen Ausgang des Mikro-
controllers. Dieser wird während der Initialisierung auf einen High-Pegel gesetzt. Vor dem Aus-
führen der Funktion wird der Ausgang auf einen Low-Pegel gesetzt und nach der Ausführung
wieder auf einen High-Pegel. Somit entspricht die Dauer des Low-Pegels der Ausführungszeit
der Funktion.
6.4.4 Messungen der Ausführungszeiten von Berechnungsoperationen

und deren Optimierungen auf dem Renesas-Mikrocontroller
Die Ausführungszeiten für die Addition, Multiplikation und Division von Ganz- und Gleitkom-
mazahlen werden in Tabelle 6.1 aufgeführt, um den Aufwand für Gleitkomma-Operationen zu
analysieren. Zur Messung wurden innerhalb einer Schleife 100 Berechnungen ausgeführt. Die
Messung wurde vor Beginn der Schleife begonnen und nach der Schleife beendet (Abb. C.1,
C.2, C.3).
Die Tabelle zeigt, dass Operation mit Gleitkommazahlen mindestens um den Faktor 28 auf-
wändiger als Ganzzahloperationen sind. So benötigt z. B. die Addition von Gleitkommazahlen
ungefähr das 90-fache der Ausführungszeit der Ganzzahladdition. Diese Ergebnisse zeigen,
dass Berechnungen mit Gleitkommazahlen auf Ganzzahlberechnungen zurückgeführt werden
Tabelle 6.1: Timing-Messung für 100 Wiederholungen von Gleitkomma- und Ganzzahlberech-
nungen
Rechenart Datentyp Ausführungs- Faktor Abbildung
dauer in µs
Addition Gleitkommazahlen 18290,0 90 C.1a
Ganzzahlen 204,0 - C.1b
Multiplikation Gleitkommazahlen 12930,0 28 C.2a
Division Gleitkommazahlen 39870,0 98 C.3a
sollten. Dazu sind vor den Berechnungen die Gleitkommazahlen mit einem Skalkierungsfak-
tor so zu multiplizieren, dass die Genauigkeit nicht verloren geht. Anschließend werden die
Berechnungen mit Ganzzahlen durchgeführt. Nach den Berechnungen müssen die Ganzzahlen
mit dem selben Skalierungsfaktor dividiert werden, um die ursprüngliche Größe zu erhalten.
Eine weitere Variante ist es, alle Berechnungen auf Ganzzahlen zurückzuführen. So müssten
nur Größen konvertiert werden, die als Gleitkommazahl in die Anwendung einfließen und die
Anwendung verlassen.
Neben den Grundrechenarten werden trigonometrische Funktionen wie die Sinus- und Cosi-
nusfunktion angewendet. Messungen auf dem Mikrocontroller haben ergeben, dass die Ausfüh-
rungsdauer für solche Funktionen sehr hoch ist (Tab. 6.2, Abb. C.4 und C.5). Zur Optimierung
dieser Funktionen lassen sich Wertetabellen nutzen, in denen zu festgelegten Winkeln die Werte
hinterlegt werden. Die Größe der Tabelle hängt dabei von der Genauigkeit der Werte und vom
Wertebereich ab. Die Tabelle 6.2 zeigt, dass für den Zugriff auf die Wertetabellen eine deutlich
geringer Zeit als für die Berechnung des Wertes notwendig ist. Bei der Sinus-Funktion wird eine
Verkürzung um den Faktor 152 und bei der Cosinus-Funktion eine Verkürzung um den Faktor
485 erreicht. Unter Betrachtung des ersten Optimierungsansatzes, ist es sinnvoll in der Werteta-
belle Ganzzahlen zu hinterlegen, mit denen in den darauf folgenden Berechnungsschritten ohne
Umrechnung weitergearbeitet wird.
Tabelle 6.2: Timing-Messung für 100 Wiederholungen der Cosinus- und Sinus-Funktionen
Funktion Ausführungsart Ausführungs- Faktor Abbildung
dauer in µs
Sinus Berechnung 32000 152 C.4a
Wertetabelle 210 - C.4b
Cosinus Berechnung 102000 486 C.5a
Wertetabelle 210 - C.5b
Zur weiteren Optimierung kann durch Vereinfachung von Rechenschritten wie z. B. das Aus-
klammern von Werten die Ausführungszeit verringert werden. Die Berechnungen in den Funk-
tionen enthalten Konstanten, mit denen Berechnungen mit anderen Konstanten durchgeführt
werden. Diese lassen sich optimieren, indem die Ergebnisse aus diesen Berechnungen durch
neue Konstanten ersetzt werden.
7 Implementierung des zeitgesteuerten
AKS
In diesem Kapitel werden die Funktionen der zeitgesteuerten Antriebsregelung und Fahrzeug-
koordinierung in CPGs modelliert. Dabei werden Modellierungsvarianten für das Abbilden von
Gleichzeitigkeitsbeziehungen und für die Behandlung von Tasks mit unterschiedlichen Perioden
dokumentiert. Im folgenden Abschnitt werden die Funktionen des etAKS in CPGs modelliert
und in eine zeitgesteuerte Ausführung transformiert. Anschließend werden die Funktionen auf
der Zielplattform implementiert und eine Timing-Analyse durchgeführt. Am Ende des Kapitels
werden die beiden Anwendungsteile mit Anpassung der Abtastrate zusammengeführt und ein
Schedule generiert.
7.1 Modellierung der Antriebsregelung und

Fahrzeugkoordinierung
In diesem Abschnitt wird die zeitgesteuerte Anwendung aus Abbildung 6.3 in CPGs umgewan-
delt. Der ursprüngliche DAG der zeitgesteuerten Antriebsregelung und Fahrzeugkoordinierung
(vgl. [Sellentin (2006)]) erlaubt es Gleichzeitigkeitsbeziehungen und Tasks mit unterschied-
lichen Perioden zu modellieren. Die Modellierung von Gleichzeitigkeitsbeziehungen sind in
CPGs nicht vorgesehen. Zusätzlich müssen Tasks mit unterschiedlichen Perioden in verschie-
denen Graphen dargestellt werden, die anschließend wieder zusammengeführt werden (vgl. Ka-
pitel 5.2.3). Die Anwendung enthält Tasks mit einer Periode von 10 ms und 50 ms. Die Tasks
im oberen Teil des Graphens, die mit der Koordinierung enden, besitzen eine Periode von 50
ms. Dazu kommen noch zwei Tasks, die Ist-Daten des vorderen und hinteren Knotens senden.
Sie werden im folgenden als 50-ms-Tasks bezeichnet. Die Tasks im unteren Teil, ausgenommen
der zwei Tasks zum Senden der Ist-Daten, besitzen eine Periode von 10 ms, im folgenden als
10-ms-Tasks bezeichnet. Diese beiden Teile des Graphens werden hier einzeln betrachtet. Die
Perioden der Tasks Status Vorne auswerten und Status Hinten Auswerten inklusive der dazu-
gehörigen Nachricht werden auf 50 ms erhöht, da der Task Eingangsfilter Daten alle 50 ms
auswertet, ist daher eine geringere Abtastrate ausreichend.
7.1.1 Modellierung der Tasks mit einer Periode von 10 ms
Die Geschwindigkeits- und Lenkwinkelregelung aus dem unteren Teil des Graphens wird in Ab-
bildung 7.1 dargestellt. Im bisherige Scheduling-Verfahren wurden Gleichzeitigkeitsbeziehung
berücksichtigt, die in CPGs nicht vorgesehen sind und daher anders modelliert werden müssen.
Es werden hier zwei Modellierungsvarianten untersucht, ein weiterer Ansatz wird im Anhang
D.1 dargestellt. Anhand der CPGs und Schedules werden die Varianten untersucht und ein Er-
gebnis dargestellt. Es werden hier die geschätzten WCETs der Tasks verwendet, da nur die
Modellierungsvarianten betrachtet werden.
Abb. 7.1: DAG zur Geschwindigkeits- und Lenkwinkelregelung
Modellierungsansatz 1
In diesem Ansatz wird der CPG analog zu dem Abhängigkeitsgraphen der bestehenden Anwen-
dung modelliert (Abb. 7.2a). Die Parameter für Geschwindigkeit und Lenkwinkel werden für
beide Knoten in separaten Zweigen abgebildet. Der Graph ist so modelliert, dass das Messen
und das Stellen der Parameter parallel auf beiden Knoten stattfinden kann. Dazu werden die
Zweige für beide Knoten nach dem Regeln zusammengeführt.
Der durch das Scheduling-Verfahren erzeugte 5000 µs lange Schedule ist in Abb. 7.2b darge-
stellt. Es werden die einzelnen Tasks und zur Übersicht die Funktionen Messen, Regeln und
Stellen der Geschwindigkeiten und der Lenkwinkel über die Zeit dargestellt. Die Gleichzeitig-
keitsbeziehungen werden in diesem Schedule nur beim Messen des Lenkwinkels umgesetzt.
Die restlichen Tasks zum Messen und Stellen werden nicht wie vorgegeben gleichzeitig ausge-
führt.
Modellierungsansatz 2
Im zweiten Ansatz werden die Tasks für die Geschwindigkeit und den Lenkwinkel im Gra-
phen sequentiell modelliert (Abb. 7.3a). Es werden erst alle Tasks für die Geschwindigkeit und
(a) CPG mit zugeordneten Tasks und deren WCET in

µs inkl. Prozess- und Astnummer des Scheduling-
Algorithmus
(b) Schedule zum dargestellten CPG
Abb. 7.2: CPG und Schedule zur Geschwindindigkeits- und Lenkwinkelregelung (Modellie-
rungsansatz 1)
anschließend alle Tasks für die Lenkwinkel abgearbeitet. Die Tasks zum Messen und Stellen
werden für beide Parameter parallel modelliert, damit sie gleichzeitig ausgeführt werden.
(a) CPG mit zugeordneten Tasks und deren WCET in

µs inkl. Prozess- und Astnummer im Scheduling-
Algorithmus
(b) Schedule zum CPG
Abb. 7.3: CPG und Schedule zur Geschwindigkeits- und Lenkwinkelregelung (Modellierungs-
ansatz 2)
Aus dem Graphen wird der Schedule aus Abb. 7.3b generiert. Dieser zeigt, dass das gleichzei-
tige Messen und Stellen von Geschwindigkeit und Lenkwinkel umgesetzt wird. Es werden erst
die Tasks für die Geschwindigkeit und anschließend die Tasks für den Lenkwinkel ausgeführt.
Die Zeit zwischen dem Messen und Stellen der Parameter ist dabei minimiert worden, wodurch
die Reglertotzeit ebenfalls minimiert wird. Die Zeit zwischen dem Beginn des Messens und
dem Beenden des Stellens beträgt für jeden Parameter 2532 µs, wodurch eine Schedule-Länge
von insgesamt 5064 µs erreicht wird.
7.1.2 Modellierung der Tasks mit einer Periode von 50 ms
Die Tasks mit einer Periode von 50 ms werden in einem separaten Graphen modelliert. Dieser
Graph umfasst das Empfangen der Sollwerte, das Eingangsfilter und die Koordinierungsfunkti-
on, sowie das Senden der Ist-Werte an den Leitstand (Abb. 7.4).
Abb. 7.4: DAG zu den Tasks mit einer Periode von 50 ms
Die 50-ms-Tasks besitzen keine besonderen Anforderungen wie Gleichzeitigkeitsbeziehungen.

Daher können die einzelnen Aufgaben parallel modelliert werden (Abb. 7.5a). Im CPG ist das
Senden der Ist-Daten in zwei parallelen Ästen modelliert, in einem weiteren Ast ist die Koordi-
nierung modelliert.
Der Schedule zu dem Graphen wird in Abb. 7.5b dargestellt. Insgesamt wird für die 50-ms-
Tasks eine Ausführungszeit von 4750 µs benötigt. Der längste Schedule der 10-ms-Tasks benö-
tigt 5064 µs. Die beiden Graphen sind somit ohne paralleles Ausführen von Tasks nacheinander
innerhalb einer Periode von 10 ms ausführbar. Der Schedule zeigt, dass auf dem Knoten Rene-
sas Hinten nur ein Task ausgeführt wird. In der restlichen Zeit stehen Reserven für weitere
Tasks zur Verfügung.
(a) CPG mit zugeordneten Tasks und deren WCET in µs inkl. Prozess- und Astnummer im Scheduling-
Algorithmus
Abb. 7.5: CPG und Schedule zur Koordinierungsfunktion und Ist-Daten-Übertragung

7.1.3 Zusammenführung der Graphen
Die dargestellten Graphen verwenden die geschätzten Ausführungszeiten, die im Graphen in

Abb. 6.3 dargestellt sind. Messungen in der Masterarbeit [Sellentin (2006)] haben ergeben, dass
die tatsächlichen Task-Ausführungszeiten deutlich geringer sind als die geschätzten Werte. Die
tatsächlichen Werte, erweitert um einen kleinen Puffer, sollen im CPG der Gesamtanwendung
verwendet werden (Tabelle 7.1). Dabei wurde den Tasks, die auf den Knoten Renesas Vorne und
Renesas Hinten die gleichen Aufgaben ausführen, die selben Ausführungszeiten zugeordnet.
Tabelle 7.1: Übersicht der Task-WCET der Antriebssteuerung und Fahrzeugkoordinierung (Sel-
lentin (2006)), sowie die einzuplanende WCET für das ttAKS
Task WCET geschätzt WCET gemessen WCET im CPG
Empfange Soll-Führ 250 µs 44 µs 50 µs
Empfange Soll-Komm 250 µs 42 µs 50 µs
Status vorne auswerten 250 µs 27 µs 30 µs
Status hinten auswerten 250 µs 24 µs 30 µs
Eingangsfilter 250 µs 48 µs 50 µs
Koordinierung 3000 µs 472 µs 500 µs
Sende Fahrzeug-Istwerte 250 µs 45 µs 50 µs
Messe v vorne 250 µs 26 µs 30 µs
Regel v vorne 1000 µs 213 µs 225 µs
Stelle v vorne 250 µs 37 µs 45 µs
Messe v hinten 250 µs 25 µs 30 µs
Regel v hinten 1000 µs 184 µs 225 µs
Stelle v hinten 250 µs 37 µs 45 µs
Messe phi vorne 250 µs 22 µs 30 µs
Regel phi vorne 1000 µs 210 µs 225 µs
Stelle phi vorne 250 µs 39 µs 45 µs
Messe phi hinten 250 µs 22 µs 30 µs
Regel phi hinten 1000 µs 182 µs 225 µs
Stelle phi hinten 250 µs 36 µs 45 µs
Sende Ist hinten 250 µs 49 µs 55 µs
Sende Ist vorne 250 µs 53 µs 55 µs
Der Graph der Gesamtanwendung wird in Abb. 7.6 dargestellt. In ihm sind die Graphen G1
für die 10-ms-Tasks und G2 für die 50-ms-Tasks gekapselt. Der Graph G1 wird insgesamt fünf
mal innerhalb der 50-ms-Periode ausgeführt. Die erste Ausführung findet nach 0 ms und die
folgenden nach 10, 20, 30 und 40 ms statt. Um dieses zu gewährleisten wurden Dummy-Tasks
eingeführt, deren Ausführungszeit dem Offset entspricht. Sie werden keiner Ressource zuge-
ordnet und benötigen somit keine Ausführungszeit.
Abb. 7.6: CPG zur Antriebsregelung und Koordinierung mit gekapselten Untergraphen
7.2 Modellierung und Transformation des etAKS in eine

zeitgesteuerte Ausführung
Der folgende Abschnitt beschreibt die Transformation der Funktionen des Antikollisionssystem
(AKS) von einer ereignisgesteuerten in eine zeitgesteuerte Ausführung. Die daraus entstehen-
den Funktionen werden in CPGs dargestellt, wobei die Knoten nicht den Tasks sondern den ein-
zelnen Funktionen innerhalb des Tasks entsprechen. Die Daten, die zwischen den Funktionen
ausgetauscht werden, werden als Daten auf dem FlexRay-Bus dargestellt, da die Knotenzuord-
nung noch nicht bekannt ist und so der Datenaustausch verdeutlicht wird. Es werden Modellie-
rungsvarianten für einen Teil der Funktionen vorgestellt. Für das Scheduling des ttAKS werden
die Ausführungszeiten der Funktionen auf der Zielplattform gemessen. Eine Code-Optimierung
wird für die Odometrie-Funktion beispielhaft durchgeführt, um die Wirksamkeit der Optimie-
rungsansätze aufzuzeigen.
7.2.1 Transformation der Odometrie-Funktion
Die Odometrie-Funktion des AKS ist eine abgeschlossene Funktion. Sie benötigt als Eingaben
die Ist-Daten der Geschwindigkeit und des Lenkwinkels. Als Ausgabe werden die Odometrie-
Daten zur Verfügung gestellt, die von der Aktionsausführung genutzt werden. Bei Bedarf soll
ein Daten-Reset und das Stellen des Achswinkels durchgeführt werden.
Es werden zwei Ansätze zur Umsetzung der Odometrie-Funktion dargestellt:
• Im ersten Ansatz wird die Odometrie-Funktion so umgesetzt, dass neben den Ist-Daten
die Anforderung für einen Reset und das Achswinkelsetzen als Eingabedaten benötigt
werden. Darauf folgt die Berechnung und die Ausgabe der Odometrie-Daten (Abb. 7.7a).
Die Odometrie-Funktion muss in diesem Ansatz vor der Aktionsausführung eingeplant
werden, da von der Aktionsausführung aktuelle Odometrie-Daten benötigt werden. Da
die Aktionsausführung gleichzeitig einen Reset oder ein Achswinkelsetzen auslöst, hat
dieses den Nachteil, dass der erzeugte Reset und der zu stellende Achswinkel erst in der
folgenden Ausführung der Odometrie-Funktion berücksichtigt werden.
• Der zweite Ansatz spaltet die Odometrie-Funktion, den Daten-Reset und das Achswin-
kelsetzen in einzelne Tasks auf. Die Odometrie-Funktion verarbeitet nur die Ist-Daten und
gibt die Odometrie-Daten beim Terminieren aus (Abb. 7.7b). Diese Funktion ist ausführ-
bar, sobald die Ist-Daten zur Verfügung stehen und muss vor der Aktionsausführung aus-
geführt werden. Die Anforderungen für einen Reset und das Stellen eines neuen Achswin-
kels werden durch die Aktionsausführung erzeugt. Diese beiden Aktionen werden nach
der Aktionsausführung als einzelne Task eingeplant, die durch Konditionen geschützt
werden. Ein Reset wird nur dann durchgeführt, wenn die entsprechende Kondition ge-
setzt ist (Abb. 7.7c). Für das Setzen des Achswinkels gilt das gleiche, nur dass neben der
Kondition der neue Achswinkel übertragen werden muss (Abb. 7.7d). Diese Lösung hat
den Vorteil, dass der Reset und das Achswinkelsetzen nach der Aktionsausführung in der
selben Runde ausgeführt wird.
Die Umsetzung der Odometrie erfolgt nach dem zweiten Ansatz. Dieser bietet den Vorteil,
dass die Odometriefunktion kürzer wird und der Reset und das Achswinkelsetzen im kürzeren
7 Implementierung des zeitgesteuerten AKS
(a) Ansatz 1 (b) Ansatz 2: Odometrie-Funk- (c) Ansatz 2: Reset-Funktion (d) Ansatz 2: Achswinkelsetzen-
65
tion Funktion
Abb. 7.7: Modellierung der Odometrie als CPG

Abstand zur Erzeugung der Anforderung ausgeführt wird. Für die Einplanung der Odometrie-
Funktion ist eine Periode von 10 ms sinnvoll, da die Ist-Werte mit der selben Periode erzeugt
werden. Für die Reset- und die Achswinkelsetzen-Funktion ist eine Periode von 50 ms ausrei-
chend, da sie von der Aktionsausführung und deren Periode abhängt.
Die Umformung von einer ereignisgesteuerten in eine zeitgesteuerte Ausführung ist bei der
Odometrie unkompliziert. Die ereignisgesteuerte Odometriefunktion ist als ein Thread imple-
mentiert. Dieser Thread besteht aus einer Schleife, die bei jedem Eintreffen einer Nachricht
mit Ist-Daten die Position neu berechnet. Die zeitgesteuerte Ausführung setzt voraus, dass die
notwendigen Ist-Daten vor Ausführung des Tasks vorhanden sind. Die Daten müssen, abhän-
gig von der Knotenzuordnung, vorher lokal oder über FlexRay zur Verfügung gestellt worden
sein. Die Odometrie-Funktion besteht nur aus der Berechnung der neuen Position. Die Reset-
und Achswinkelsetzen-Funktionen sind im etAKS als Funktionen implementiert, auf die von
außen direkt zugegriffen werden kann. Dieses ist nicht mehr sinnvoll, da die Odometrie nicht
auf dem selben Knoten wie die Aktionsausführung zur Ausführung kommen muss. Die Funk-
tionen sollen daher in der zeitgesteuerten Umgebung durch Konditionen geschützt werden, die
über FlexRay bekannt gegeben werden. Neben den Konditionen muss der neue Achswinkel
zusätzlich übertragen werden.
Für das Scheduling der drei Funktionen muss die Worst Case Execution Time (WCET) für
jeden Task bekannt sein. Diese sind durch Messungen auf der Zielplattform erhoben worden.
Die Grafiken zu den Messungen sind im Anhang D.2 aufgeführt. Die Timing-Messung der
Odometrie-Funktion auf der Zielplattform ergab eine maximale Ausführungszeit von ca. 14,4
ms (Abb. D.2a). Für die Reset-Funktion wurde eine maximale Ausführungszeit von ca. 42 µs
(Abb. D.3a) und für das Achswinkelsetzen eine maximale Ausführungszeit von ca. 20 µs (Abb.
D.3b) gemessen. Die kleinste Periode der neuen Anwendung beträgt 10 ms. Auf beiden Knoten
werden Tasks mit dieser Periode ausgeführt. Wird kein zusätzliche Knoten verwendet, darf kein
Task eine Ausführungszeit besitzen, die größer als diese Periode ist.
Zur Verkürzung der Ausführungszeit wurde der Code der Odometrie-Funktion optimiert. Die
Funktion besitzt sechs Aufrufe der Sinus-Funktion und fünf Aufrufe der Cosinus-Funktion.
Wie die Timing-Messungen in Tabelle 6.2 zeigen, besitzen diese Funktionen eine hohe Berech-
nungsdauer. Zur Optimierung wurden daher diese Berechnungen durch Wertetabellen ersetzt.
Zusätzlich wurden die Berechnungen durch Ausklammern von Faktoren und durch die Definie-
rung neuer Konstanten vereinfacht. Die Berechnungen mit Gleitkommazahlen wurden beibe-
halten, da nach diesen Optimierungen bereits eine maximale Ausführungszeit von ca. 3,5 ms
(Abb. D.2b) erzielt wurde.
7.2.2 Transformation der Situationserfassung
Die ereignisgesteuerte Situationserfassung umfasst die Initialisierung des Laserscanners, sowie

den Empfang und die Aufbereitung der Messwerte. Die Funktion ist als Thread implementiert,
der zuerst die Initialisierung vornimmt und anschließend in einer Schleife die Daten verarbeitet.
Zur Überführung in eine zeitgesteuerte Ausführung, wird die Initialisierung des Laserscanners
aus der Situationserfassung entkoppelt, da diese Funktion eine lange Ausführungszeit benötigt
und nur ein Mal vor der Ausführung der Anwendung erfolgen muss. Die Situationserfassung
umfasst anschließend nur noch den Empfang und die Aufbereitung von Messwerten (Abb. 7.8).
Der Task ist von keinem anderen Task abhängig, da er nur die Daten vom Laserscanner auswer-
tet. Die Ausführung muss vor der Objekterkennung stattfinden.
Abb. 7.8: Modellierung der Situationserfassung als CPG
Der Laserscanner überträgt in der Konfiguration des etAKS mit einer Frequenz von 20 Hz neue
Messwerte. Daraus ergibt sich für die Situationserfassung eine Periode von 50 ms. Während der
Messung überträgt der Laserscanner 63 Nachrichten über den CAN-Bus, die die Werte der 181
Messungen von 0-180◦ bei einer Auflösung von 1◦ enthalten. Die Nachrichten werden in ei-
nem Abstand von 400-500 µs übertragen (Tab. D.1). Die Timingmessung ergab, dass der Task
nur für den Empfang der CAN-Nachrichten eine Ausführungszeit von 30,7 ms benötigt. Die
Messung der Task-Ausführungszeit ergab einen maximalen Wert von ca. 32 ms (Abb. D.4. Die
Grafiken zu den Timing-Messungen sind im Anhang D.2 zu finden. Der Task besitzt eine Aus-
führungszeit von ca. 32 ms bei einer Periode von 50 ms. Die Antriebsregelung besitzt Tasks
mit einer Periode von 10 ms. Soll die Situationserfassung auf einem der bestehenden Knoten
ausgeführt werden, kann sie aufgrund der 10 ms Tasks nicht in einem Stück ausgeführt werden.
Zusätzlich besteht das Problem, dass der Zeitpunkt nicht bekannt ist, zu dem die Übertragung
der Laserscanner-Daten beginnt. Es ist nur bekannt, dass der Laserscanner mit einer Periode von
50 ms arbeitet. Wann die Übertragung beginnt ist u. a. von der Spiegelstellung während der An-
forderung abhängig. Im schlechtesten Fall wurde der erste zu messende Winkel verpasst und es
muss bis zum ersten Winkel gewartet werden bis eine komplette Messung empfangen wird. Um
den Datenempfang in einem Task abzuarbeiten, ist eine Synchronisation zwischen Laserscan-
ner und dem Mikrocontroller erforderlich. Eine Anforderung jeder einzelnen Messung würde
zu dem Problem führen, dass die Spiegelstellung bei jeder Anforderung nicht bekannt ist. Bei
kontinuierlicher Datenübertragung kann zusätzlich laut Hersteller die Scanfrequenz um bis zu
5 % abweichen. Es wäre daher eine regelmäßige Synchronisation im zeitgesteuerten Betrieb
notwendig. Im folgenden werden drei Ansätze für die Transformation der Situationserfassung
vorgestellt (Abb. 7.9):
1. In diesem Ansatz wird ein zusätzlicher Knoten 1 benötigt, auf dem die Situationserfas-
sung zur Ausführung kommt (Abb. 7.9a). Die Situationserfassung wird als permanenter
Task eingerichtet, in dem der Task z. B. mit einer Ausführungszeit und einer Periode von
50 ms eingerichtet wird. Der Task übernimmt den Empfang der CAN-Nachrichten und
übermittelt sie, wenn die neuen Daten komplett sind, in einem groben, definierten Ras-
ter über den FlexRay-Bus an die anderen Knoten. Dadurch, dass mehrere Zeitpunkte zur
Datenübertragung innerhalb der 50-ms-Periode eingerichtet werden, wird die Aktualität
der Messwerte erhöht. Auf dem anderen Knoten 2 werden Tasks eingerichtet, die die
restlichen Funktionen des ttAKS kapseln. Dieses ist notwendig, da aufgrund des groben
Rasters der genaue Zeitpunkt, zu dem die Daten eintreffen, nicht bekannt ist. Die Ausfüh-
rungszeiten der AKS-Funktionen muss in das 10 ms Raster passen, da auf dem Knoten
10-ms-Tasks eingeplant sind. Bei jeder Ausführung der gekapselten AKS-Task wird ge-
prüft, welche Funktion des AKS ausgeführt werden soll. Stehen z. B. neue Daten von der
Situationserfasung bereit, wird die Situationsanalyse ausgeführt, ist diese abgeschlossen
wird mit der Objekterkennung fortgefahren.
2. Dieser Ansatz erfordert eine Synchronisation zwischen Laserscanner und Mikrocontroller

(Abb. 7.9b). Ist die Kommunikation synchronisiert, kann auf einem zusätzlichen Knoten
1 der 32-ms-Task der Situationserfassung ausgeführt werden. Diese muss auf einem se-
paraten Knoten eingeplant werden, da auf den bisherigen Knoten Tasks mit einer Periode
von 10 ms eingeplant werden. Die restliche Zeit von 18 ms kann für die Aufbereitung
der Daten verwendet werden, um anschließend weniger Daten über den FlexRay-Bus
zur Weiterverarbeitung übertragen zu müssen. Die weitere Verarbeitung im Rahmen des
ttAKS wird auf den anderen Knoten, wie hier Knoten 2, durchgeführt. Es muss jedoch
darauf geachtet werden, dass die Daten verarbeitet sind bis erneut Daten über FlexRay
eintreffen.
3. Der dritte Ansatz benötigt keinen zusätzlichen Knoten (Abb. 7.9c). Es wird die Situa-
tionsanalyse in kleine Tasks aufgeteilt, die jeweils eine CAN-Nachricht empfangen und
auswerten. Die Aufnahme des CAN-Trace (Tab. D.1) zeigt, dass der Empfang einer Nach-
richt eine Zeit von weniger als 250 µs benötigt und die CAN-Nachrichten in einem Ab-
stand von 500 µs eintreffen. Für den Empfang und die Auswertung einer CAN-Nachricht
benötigt der Task 250 µs. Somit ist ein Task mit einer Periode von 500 µs und einer
Ausführungszeit von 250 µs auf Knoten 1 einzurichten. In diesem Ansatz wird keine
Synchronisation zwischen Laserscanner und Mikrocontroller benötigen, da der Task pe-
riodisch ausgeführt wird. Sind neue Daten im Eingangspuffer, werden diese im Array
gespeichert und ausgewertet. Sind keine neuen Daten verfügbar, terminiert der Task. Zur
Weiterverarbeitung der Daten, wird das Array an den Knoten 2 über den FlexRay-Bus
übertragen. Dieses erfolgt wie im ersten Ansatz in einem groben Raster, da durch die
fehlende Synchronisation nicht bekannt ist, wann die Messwerte komplett empfangen
werden. Auf dem Knoten 2 wird ein Task eingeplant, der wie im ersten Ansatz die Funk-
tionen des ttAKS kapselt und bei jeder Ausführung prüft, welche Funktion auszuführen
ist. In diesem Ansatz werden die 10-ms-Tasks der Geschwindigkeits- und Lenkwinkelre-
gelung in den Lücken der Situationserfassungs-Tasks ausgeführt. Dieses ist möglich, da
deren gemessenen Ausführungszeiten kleiner als 250 µs sind. Die zu übertragende Da-
tenmenge des Messwerte-Arrays entspricht 2896 Bits, die sich aus 181 Messwerten mit je
2 Bytes zusammensetzt. Der FlexRay-Bus bietet eine Übertragungsgeschwindigkeit von
10 MBit/s, was einer Übertragungszeit von 0,1 µs je Bit entspricht, und somit insgesamt
eine Übertragungszeit von 289,6 µs ohne Overhead erforderlich ist. Neben den weiteren
AKS-Tasks sind die 10-ms- und die 50-ms-Tasks der Antriebsregelung auf dem zweiten
Knoten einzuplanen. Für die gekapselte ttAKS-Task bleibt somit die verbleibende freie
Zeit.
(a) Ansatz 1
7 Implementierung des zeitgesteuerten AKS
(b) Ansatz 2
(c) Ansatz 3
Abb. 7.9: Modellierungsvarianten der Situationserfassung

69
Einen Überblick über die Tasks und deren Zusammenspiel wird in der Abbildung 7.9 dargestellt.
Es werden jeweils zwei Knoten dargestellt, auf denen die ttAKS Tasks eingeplant werden. Die
Nummer in den Tasks gibt die Sequenznummer der Messwerte an. Dieses verdeutlicht, welcher
Task an welcher Messwertesequenz arbeitet. Der dritte Ansatz wird in dieser Arbeit umgesetzt,
da er den Vorteil bietet, dass kein zusätzlicher Knoten benötigt wird und keine Synchronisation
zwischen dem Laserscanner und dem Knoten erfolgen muss.
7.2.3 Transformation der Situationsanalyse und Aktionsentscheidung
Die Situationsanalyse und Aktionsentscheidung des etAKS lässt sich in drei Einzelaufgaben
aufteilen, die sequentiell abgearbeitet werden. Hierzu gehört die Objekterkennung, Umgebungs-
analyse und der Automat der Aktionsentscheidung. Die Objekterkennung ist von der Situa-
tionserfassung abhängig, die die aufbereiteten Messwerte zur Weiterverarbeitung liefert. Die
Objekterkennung liefert eine Liste von Objekten, die sich im abgetasteten Bereich befinden.
Die Umgebungsanalyse sucht das Objekt aus der Liste, mit dem das Fahrzeug als erstes kol-
lidieren würde und überprüft den Raum neben dem Fahrzeug. Aus diesen Ergebnissen wird
eine Ausweichentscheidung getroffen und, wenn nötig, ein Ausweichvorgang eingeleitet. Die
Objekterkennung und Situationsanalyse des etAKS sind bereits sequentiell in einem Thread
ausgeführt worden. Der Entscheiderautomat wurde in einem separaten Thread ausgeführt.
7.2.3.1 Objekterkennung
Die Objekterkennung verwendet die aufbereiteten Messwerte der Situationsanalyse zur Erken-
nung von Objekten im abgetasteten Bereich. Dabei werden die Ist-Daten für Geschwindigkeit
und Lenkwinkel benötigt. Die Ausführung muss daher nach der Antriebsregelung und der Si-
tuationserfassung und vor der Umgebunsanalyse stattfinden. Die Abb. 7.10 zeigt den CPG zu
der Anwendung.
Abb. 7.10: CPG zur zeitgesteuerten Objekterkennung

Die Timing-Messungen der Objekterkennung ergaben Schwankungen in den Ergebnissen. Auf

der Abbildung D.5 im Anhang D.2 sind zwei Ausführungen der Objekterkennung aufgeführt.
Die erste Ausführung benötigt eine Ausführungszeit von ca. 280 ms, während die zweite Aus-
führung ca. 440 ms benötigt. Da das AKS eine Periode von 50 ms besitzen soll, ist diese Aus-
führungszeit nicht akzeptabel. Es sind wie bereits in der Odometrie-Funktion Optimierungen
notwendig. In dieser Arbeit wird das ttAKS mit der nicht-optimierten Funktion implementiert.
Zur Verringerung der Ausführungszeit sind Code-Optimierungen notwendig, wie sie bereits in
Kapitel 6.4.4 beschrieben sind.
In einer optimierten Ausführung muss die Periode der Objekterkennung zumindest der Peri-
ode der Situationserfassung entsprechen, da sie neue Werte vom Laserscanner zur Verarbeitung
liefert. Eine kürzere Periode wäre denkbar, um die Veränderung der Geschwindigkeit und des
Lenkwinkels in einer höheren Rate zu berücksichtigen.
7.2.3.2 Umgebungsanalyse
Die Umgebungsanalyse verwendet die Objektdaten, die durch die Objekterkennung zur Verfü-
gung gestellt werden. Als erstes werden die Aufpralldaten berechnet. Dazu werden die Objekte
untersucht und die Aufpralldaten zu dem Objekt mit der kürzesten Kollisionszeit berechnet.
Werden keine Aufpralldaten erzeugt, da sich z. B. kein Objekt im abgetasteten Bereich befin-
det, ist die Umgebungsanalyse beendet. Werden Aufpralldaten erzeugt, werden die einzelnen
Ausweichfälle, auf die eine Aktion erfolgen muss, untersucht. Dieses sind Bremsen, Auswei-
chen Links und Ausweichen Rechts. Die Ergebnisse der Untersuchung muss der Aktionsent-
scheidung mitgeteilt werden. Zur Ermittlung werden die Ist-Werte für Geschwindigkeit und
Lenkwinkel benötigt. Für die Aufpralldatenberechnung sind zudem die Daten der Objekterken-
nung erforderlich. Daher muss die Umgebungsanalyse nach der Antriebsregelung und der Ob-
jekterkennung ausgeführt werden. Die Ausgabewerte der Umgebungsanalyse werden von der
Aktionsentscheidung benötigt, wodurch die Umgebungsanalyse vor der Aktionsentscheidung
ausgeführt werden muss. Der CPG zur Umgebungsanalyse wird in der Abb. 7.11 dargestellt.
Die Messung der Ausführungszeit ergab eine WCET von ca. 7 ms (Abb. D.6). Die Umgebungs-
analyse baut auf die Objekterkennung auf, die mit einer Periode von 50 ms ausgeführt wird.
Daher wird für die Umgebungsanalyse die selbe Periode verwendet.
7.2.3.3 Aktionsentscheidung
Die Aktionsentscheidung des etAKS ist in einem Thread als reaktiver Automat implementiert.
Ein reaktiver Automat ist in einer zeitgesteuerten Ausführung nicht implementierbar, da die
Ausführung des Tasks periodisch erfolgt und der Zeitpunkt und die Reihenfolge der zwischen
den Ausführungen erzeugten Ereignisse nicht mehr nachvollzogen werden kann. Eine Varian-
te ist es, die Variablen der letzten Ausführung zu speichern und unter Verwendung der alten
und neuen Signale eine Entscheidung zu treffen. Die Signale, die die Umgebungsanalyse an
die Aktionsentscheidung sendet, werden sequentiell erzeugt. Dadurch ist die Reaktion in einem
zeitgesteuerten Automaten nachvollziehbar. Der CPG zum Automat in der zeitgesteuerten Aus-
führung wird in Abb. 7.12 dargestellt. Die Entscheidung der Aktionsentscheidung wird an die
Aktionsausführung weitergegeben, um ein Manöver zu starten. Sie muss daher vorher ausge-
führt werden.
Abb. 7.11: CPG zur Umgebungsanalyse

Abb. 7.12: CPG zur Aktionsentscheidung

Für die Aktionsentscheidung wurde eine maximale Ausführungszeit von ca. 60 µs gemessen
(Abb. D.7). Die Ausführung der Aktionsentscheidung ist von Daten der Umgebungsanalyse ab-
hängig und wird daher mit einer Periode von 50 ms ausgeführt. Die Ausführung dieser Funktion
muss nach der Umgebungsanalyse und vor der Aktionsausführung stattfinden.
7.2.4 Transformation der Aktionsausführung
Die Aktionsausführung führt den Ausweichvorgang durch, sobald der Entscheider das Signal
zum Ausweichen gibt. Es wird daher zu Beginn geprüft, ob eingegriffen werden soll. Dazu
muss das Signal vom dem Entscheider-Task zur Aktionsausführung übertragen werden. Die
Aktionsausführung des etAKS ist als Thread implementiert, der eine Initialisierung der Daten
vornimmt, anschließend in einer Schleife den Ausweichvorgang durchführt und zum Schluss
das Fahrzeug in der Endposition stoppt.
Abb. 7.13: CPG zur Aktionsausführung

In der zeitgesteuerten Ausführung sind die drei Ausweichvorgänge in einem Task integriert, da-
mit bei der ersten Ausführung mit dem Ausweichen begonnen wird (Abb. 7.13). Anhand einer
Statusvariabeln wird festgelegt, in welcher Phase sich die Aktionsausführung befindet. In der
ersten Ausführung wird die Initialisierung und anschließend der Ausweichvorgang gestartet. In
den darauf folgenden Ausführung wird die Initialisierung übersprungen. Sobald der Ausweich-
vorgang abgeschlossen ist, wird der Vorgang abgeschlossen. Die Aktionsausführung kommuni-
ziert mit der Odometrie. Es werden die Daten der Odometrie für den Ausweichvorgang genutzt.
Da die Odometrie vor der Aktionsausführung ausgeführt wird, stehen diese Daten rechtzeitig
zur Verfügung. Die Aktionsausführung stößt einen Reset der Odometriedaten oder das Setzen
eines neuen Achswinkels bei Bedarf an. Diese Daten müssen an die Odometrie weitergegeben
werden. Während des Ausweichvorgangs werden zudem Soll-Daten für den Lenkwinkel und
die Geschwindigkeit erzeugt. Diese müssen an den entsprechenden Task weitergegeben wer-
den.
Die Aktionsausführung ist von der Aktionsentscheidung abhängig, die eine Periode von 50
ms besitzt. Daher ist für diesen Task eine Periode von 50 ms ausreichend. Sollte genügend
Ausführungszeit zur Verfügung stehen, ist eine höhere Periode denkbar, um häufiger neue Soll-
Daten zu generieren und aktuellere Daten der Odometrie zu verwenden. Dieses hat den Vorteil,
dass die Ausweichkurve genauer eingehalten wird und seltener nachgeregelt werden muss. Die
Messung der Ausführungszeit ergab einen Wert von ca. 3 ms (Abb. D.8).
7.2.5 Zusammenführung der AKS-Funktionen
Einen Überblick über die Funktionen des AKS und deren Abhängigkeiten zeigt die Abbildung
7.14. Die einzelnen Funktionen werden als gekapselte Tasks dargestellt. Im Graphen ist auf der
rechten Seite die Odometrie zu finden, die als eigenständige Funktion parallel zu den anderen
Funktionen ausgeführt wird. Die Funktionen für den Reset und das Achswinkelsetzen sind am
Ende des Graphen aufgeführt. Auf der linken Seite ist die Situationserfassung aufgeführt. Sie
beinhaltet die kurzen periodischen Tasks, die die CAN-Daten aus dem Puffer empfängt und
aufbereitet. In der Mitte ist die gekapselte AKS-Task angedeutet, die die restlichen Funktionen
in einer Task kapselt. Die Ausführungszeiten der Funktionen des ttAKS werden in der Tabel-
le 7.2 aufgeführt. Die Implementierung der Anwendung ist in dieser Form nur durchführbar,
wenn eine Code-Optimierung der Objekterkennung durchgeführt wird und dadurch eine Aus-
führungszeit von weniger als 10 ms erreicht wird.
Tabelle 7.2: Übersicht der Taskausführungszeiten

Task Ausführungszeit (in µs) Periode (in µs)
Odometrie-Funktion 3500 50000
Odometrie Reset 42 50000
Odometrie Achswinkelsetzen 20 50000
Situationserfassung 250 500
Objekterkennung 440000 50000
Umgebungsanalyse 7000 50000
Aktionsentscheidung 60 50000
Aktionsausführung 3000 50000
Abb. 7.14: CPG zum AKS mit Kapselung der Funktionen

7.3 Zusammenführung der Funktionen des ttAKS
Der folgenden Abschnitt dokumentiert die Zusammenführung des ttAKS, bestehend aus der
zeitgesteuerten Antriebsregelung und Fahrzeugkoordinierung und dem transformierten AKS.
Die Abtastrate der Anwendung wird aufgrund der Task-Ausführungszeiten der Objekterken-
nung angepasst und die Implikationen daraus abgeleitet. Die Ausführungszeit der ISR wird
gemessen und Anpassungen der Task-Ausführungszeiten durchgeführt. Anschließend wird die
Zuordnung der Tasks zu den vorhandenen Knoten erfolgen und ein Konzept zur Generierung
des Schedules dokumentiert.
Das ttAKS ist in der angestrebten Periode von 50 ms nicht ausführbar, da die gemessene Aus-
führungszeit der Objekterkennung mit 440 ms deutlich länger als die angestrebte Periode von
50 ms ist. Zur Generierung eines gültigen Schedules muss daher die Abtastrate der Funktio-
nen verringert werden. Die Periode des ttAKS muss so groß gewählt werden, dass alle Tasks
innerhalb dieser Periode ausführbar sind. In dieser Arbeit wird eine Periode von 500 ms ge-
wählt, die dem zehnfachen der angestrebten Periode entspricht. Aus der höheren Periode bzw.
der geringeren Abtastrate des Systems lassen sich folgende Implikationen ableiten:
• Aufgrund der geringeren Abtastrate des ttAKS muss zur rechtzeitigen Einleitung eines
Ausweichvorgangs die Geschwindigkeit des Fahrzeugs verringert werden.
• Die Änderungen der Fahrzeuggeschwindigkeit und die geringere Abtastrate erfordern die
Neuberechnung der Regler-Parameter für den Ausweichvorgang.
• Aufgrund der geringeren Geschwindigkeit ist die hohe Abtastrate der Antriebsregelung
nicht erforderlich. Dadurch wird Berechnungszeit für andere Tasks freigegeben.
Das SCV besitzt eine Maximalgeschwindigkeit von 140 cm/s. Der Laserscanner arbeitet bei
einer Frequenz von 20 Hz, was der Periode der etAKS-Funktionen entspricht. Dieses bedeutet,
dass zwischen zwei Abtastungen durch das Fahrzeug ein maximaler Weg von 7 cm zurückge-
legt wird. Das ttAKS besitzt eine Abtastrate von 500 ms. Bei gleicher Maximalgeschwindigkeit
würde das Fahrzeug einen Weg von maximal 70 cm zurücklegen. Diese Strecke ist zu lang, um
ein AKS sinnvoll zu implementieren. Daher wird in diesem Ansatz die Maximalgeschwindig-
keit auf 14 cm/s reduziert, wodurch der maximale Weg zwischen zwei Messungen im Vergleich
zum etAKS erhalten bleibt. Durch die geringere Geschwindigkeit reicht für Antriebsregelung
im ttAKS eine geringere Abtastrate aus. Sie wird ebenfalls verzehnfacht, was zu einer Periode
von 50 ms führt.
Die Umsetzung des ttAKS soll mit den zwei bisherigen Renesas-Knoten auskommen. Dazu
müssen die transformierten Tasks des AKS auf diesen Knoten verteilt werden. Aufgrund der
physikalischen Lage soll an dem Knoten Renesas Vorne zusätzlich der Laserscanner ange-
schlossen werden, wodurch die Situationserfassung auf diesem Knoten einzuplanen ist. Zu-
sätzlich ist es vorteilhaft, die Objekterkennung auf dem selben Knoten einzuplanen, um nur die
notwendigen Informationen aus der Objekterkennung über FlexRay an die weiteren AKS-Tasks
übertragen zu müssen.
Die Situationserfassung wird nach dem Modellierungsansatz 3 (vgl. Abb. 7.9c) implementiert,
der an die 500 ms Periode angepasst wird. Der Laserscanner wurde im etAKS mit einer Fre-
quenz von 20 Hz betrieben und bietet Einstellungen zwischen 5 und 20 Hz in 1 Hz Schrit-
Abb. 7.15: Schematische Darstellung des AKS Implementierungskonzepts
ten. Aufgrund der langen Periode, wäre eine niedrigere Abtastrate einstellbar. Dieses bedeutet
auch, dass die Nachrichten über einen längeren Zeitraum übertragen werden und Tasks dafür
einzuplanen sind. Um die Messwerte über einen kurzen Zeitraum zu empfangen und für die
Objekterkennung auf dem selben Knoten eine lange zusammenhängende Ausführungszeit be-
reitzustellen, wird die hohe Abtastrate beibehalten, wobei nur jede zehnte Messung erfasst wird.
Die Situationserfassung wird für den Empfang der Messwerte als 250 µs Task mit einer Peri-
ode von 500 µs eingeplant. Diese Tasks werden nur in der ersten 50-ms-Periode der insgesamt
500-ms-Periode eingeplant. Da die Periode des Laserscanners ebenfalls 50 ms entspricht, wird
sichergestellt, dass für jeden Winkel ein Messwert empfangen wird. Diese Implementierung
sieht keine Synchronisation zwischen dem Laserscanner und der Situationserfassung vor. Da-
durch können die Messwerte aus zwei unterschiedlichen Abtastungen stammen. Da sich das
Fahrzeug aufgrund der Geschwindigkeitsbegrenzung zwischen zwei Laserscanner-Messungen
maximal 0,7 cm fortbewegt, ist dieses vernachlässigbar.
Neben der Situationserfassung werden Tasks der Antriebsregelung und Fahrzeugkoordinierung

auf dem Knoten Renesas Vorne ausgeführt. Diese kommen in der ersten 50-ms-Periode in den
Lücken der Situationserfassung zur Ausführung. In den restlichen 50-ms-Perioden wird neben
diesen Tasks die Objekterkennung eingeplant. Dazu werden erst die Tasks der Antriebsregelung
zu Beginn der Periode eingeplant und in einem späteren Schritt die Objekterkennung hinzuge-
fügt. Ist die Objekterkennung abgeschlossen, werden die Objekt-Daten über FlexRay an den
Knoten Renesas Hinten übertragen. Diese führt die restlichen AKS-Tasks aus. Der Task der
Objekterkennung muss in dieser Modellierung in neun einzelne Tasks aufgespalten werden,
da durch die 50-ms-Periode der Antriebsregelung die erforderliche Ausführungszeit nicht zur
Verfügung steht.
Die Tasks Eingangsfilter und Koordinierung werden aufgrund der Ausführungszeit auf den
Knoten Renesas Hinten verlagert. Die Zuordnung der restlichen Tasks der Antriebsregelung
und Koordinierung bleibt bestehen. Das Eingangsfilter und die Koordinierung benötigen Da-
ten, die bisher nicht über FlexRay zur Verfügung gestellt wurden. Dieses sind die Vorgaben für
Geschwindigkeit und Lenkwinkel, die der Leitstand oder die Führungsbox über den CAN-Bus
an den Knoten Renesas Vorne überträgt. Des Weiteren werden vom Knoten Renesas Vorne die
Fahrzeug Ist-Daten an den Leitstand übertragen. Diese werden von der Koordinierung zur Ver-
fügung gestellt. Es ist daher notwendig, diese Daten zusätzlich über FlexRay zu übertragen.
In dieser Anwendung wird das Mapping der Tasks weitestgehend durch die lokalen Anschlüsse
an den Laserscanner und den Leitstand, sowie durch die Task-Ausführungszeiten vorgegeben.
Daher ist die Untersuchung von Mapping-Strategien in dieser Anwendung nicht erforderlich.
Strategien zur Optimierung des Mappings werden u. a. in [Pop u. a. (2004)] dokumentiert.
Die Aktivierung von Tasks wird durch einen Dispatcher durchgeführt, der als Interrupt Ser-
vice Routine implementiert ist. Die Ausführungszeit der ISR beträgt nach Messungen ca. 22 µs
(Abb. D.9). Den Tasks wird für die Ausführung der ISR eine Zeit von 25 µs hinzugefügt. Die
Tasks der Anwendungen, deren angepasste Ausführungszeit und Periode, sowie deren Kno-
tenzuordnung wird in der Tabelle 7.3 dargestellt. Dabei ist die genaue Ausführungszeit der
Objekterkennung zu diesem Zeitpunkt noch nicht festgelegt. Sie kann erst bestimmt werden,
wenn die Tasks der Antriebsregelung eingeplant sind, wobei von einer Ausführungszeit von
mehr als 48000 µs auszugehen ist. Die komplette Anwendungsrunde des ttAKS wird in den
Abbildungen E.1 und E.2 dargestellt, die im Anhang E.1 zu finden sind. Die Tasks wurden
durch Abkürzungen gekennzeichnet, wobei die folgende Nummer die Ausführungsnummer in
der Anwendungsrunde angibt.
Tabelle 7.3: Task-Übersicht mit Abkürzungen, Periode, WCET und Knotenzuordnung

Task Abkürzung Periode in ms WCET in µs Knoten
Messe V Vorne MVV 50 55 Renesas Vorne
Messe V Hinten MVH 50 55 Renesas Hinten
Regel V Vorne RVV 50 250 Renesas Hinten
Regel V Hinten RVH 50 250 Renesas Hinten
Stelle V Vorne SVV 50 70 Renesas Vorne
Stelle V Hinten SVH 50 70 Renesas Hinten
Messe Phi Vorne MPV 50 55 Renesas Vorne
Messe Phi Hinten MPH 50 55 Renesas Hinten
Regel Phi Vorne RPV 50 250 Renesas Hinten
Regel Phi Hinten RPH 50 250 Renesas Hinten
Stelle Phi Vorne SPV 50 70 Renesas Vorne
Stelle Phi Hinten SPH 50 70 Renesas Hinten
Empfange Soll Führ ESF 500 75 Renesas Vorne
Empfange Soll Komm ESK 500 75 Renesas Vorne
Status Vorne auswerten SVA 500 55 Renesas Vorne
Status Hinten auswerten SHA 500 55 Renesas Hinten
Sende Ist Vorne SIV 500 80 Renesas Vorne
Sende Ist Hinten SIH 500 80 Renesas Vorne
Eingangsfilter EF 500 75 Renesas Hinten
Koordinierung KO 500 525 Renesas Hinten
Sende FZ-Ist-Werte SFI 500 75 Renesas Vorne
Odometrie-Funktion OD 500 3625 Renesas Hinten
Situationserfassung (100 Tasks) SE 500 275 Renesas Vorne
Objekterkennung (9 Tasks) OE 500 ca. 48000 Renesas Vorne
Umgebungsanalyse UA 500 7225 Renesas Hinten
Aktionsentscheidung AE 500 95 Renesas Hinten
Aktionsausführung AA 500 3125 Renesas Hinten
Odometrie Reset OR 500 75 Renesas Hinten
Odometrie Achswinkel OA 500 50 Renesas Hinten
Aus dem Mapping der Tasks werden die zu sendenden Nachrichten abgeleitet, die über
FlexRay-Bus ausgetauscht werden. Tasks, die auf dem selben Knoten ausgeführt werden und
Daten austauschen, benötigen keine Kommunikation über den Bus. Eine Übersicht der Nach-
richten wird in Tabelle 7.4 aufgeführt.
Nachricht Abkürzung Bitlänge Sender Empfänger

V Ist Vorne VIV 16 Renesas Vorne Renesas Hinten
Phi Ist Vorne PIV 16 Renesas Vorne Renesas Hinten
Stellwert V Vorne StV 16 Renesas Hinten Renesas Vorne
Stellwert Phi Vorne StP 16 Renesas Hinten Renesas Vorne
Status Hinten StH 16 Renesas Hinten Renesas Vorne
Soll-Werte Führungsbox SoF 32 Renesas Vorne Renesas Hinten
Soll-Werte komm-Server SoK 32 Renesas Vorne Renesas Hinten
Fahrzeug Ist-Werte FZI 32 Renesas Hinten Renesas Vorne
Objektdaten O 256 Renesas Vorne Renesas Hinten
Tabelle 7.4: Nachrichten des ttAKS, deren Länge und Sende- / Empfangsknoten
7.4 Scheduling-Analyse des ttAKS
Die Scheduling-Analyse für das ttAKS wird in mehreren Schritten vollzogen:
1. Bestimmung der Parameter für das FlexRay-Protokoll
2. Berechnung der Task-Prioritäten
3. Generierung eines Schedules für die Situationserkennung
4. Erweiterung des Schedules durch die Antriebssteuerung und Koordinierung
5. Einplanung der 500-ms-Tasks des ttAKS und der Antriebssteuerung in den generierten
Schedule
6. Hinzufügen von der Objekterkennung zum Schedule
7.4.1 Bestimmung der Parameter für das FlexRay-Protokoll
Zu Beginn der Scheduling-Analyse werden die Parameter des FlexRay-Protokolls festgelegt,

die zur Einplanung der Nachrichten während der Scheduling-Analyse notwendig sind. Die we-
sentlichen zu konfigurierenden Parameter sind die Länge der TDMA-Runde, die Größe und
Anzahl der statischen und dynamischen Slots, sowie die Länge des Symbol Windows und der
NIT.
Das ttAKS verwendet ausschließlich zeitgesteuerte Kommunikation. Es werden daher nur sta-
tische Slots und keine dynamischen Slots konfiguriert. Die Slotgröße wird durch die Größe der
zu übertragenden Nachrichten bestimmt. Eine Auflistung der Nachrichten und deren Größe ist
in Tabelle F.1 zu finden. Die Tabelle zeigt, dass viele Nachrichten mit einer Länge von 16 Bit
und Nachrichten mit einer deutlich größeren Länge übertragen werden. In der zeitgesteuerten
Antriebsregelung wurden nur Nachrichten mit einer Länge von 16 Bit übertragen. Dieses ist
für das ttAKS nicht sinnvoll ist, da neben den Daten in jedem Frame ein Overhead von 64
Bit übertragen und zusätzlich Zeit für die Start- und Endsequenz eines Frames benötigt wird.
Insgesamt ist für die Übermittlung einer 16 Bit Nachricht mindestens eine Länge von 25 Ma-
croticks erforderlich, während für eine 32 Bit Nachricht 2 Macroticks mehr benötigt werden.
Um einen Kompromiss für die Übertragung der 16 Bit Nachrichten und größerer Nachrichten
einzugehen, werden hier Nachrichten mit einer Länge von 32 Bit verwendet. Für die Länge
eines statischen Slots wird in dieser Anwendung die empfohlene Länge von 30 µs je Slot ver-
wendet. Die Länge der TDMA-Runde wird auf 10000 µs festgelegt. Die Anzahl der statischen
Slots wird auf 328 festgesetzt, wodurch eine Zeit von 160 Macroticks für die NIT bleibt, die für
die Uhrensynchronisation verwendet wird. Die restlichen Parameter werden durch das Werk-
zeug zur Konfiguration des FlexRay-Systems berechnet. Eine Übersicht über die wesentlichen
Parameter ist in der Tabelle F.2 zu finden. Die Nachrichten werden aufgrund von Beschränkun-
gen in der verwendeten Software zur Konfiguration des FlexRay-Busses nur auf einem Kanal
übertragen.
7.4.2 Berechnung der Prioritäten
Die Prioritäten der Tasks und Nachrichten werden auf Basis der PCP Funktion aus Kapitel 5.2.5
durchgeführt. Für die Berechnung der Prioritäten werden die Ausführungszeiten der Tasks, so-
wie die Ausführungszeiten des Teils des nachfolgenden Graphens herangezogen, dessen Aus-
führung auf einer anderen Ressource beginnt. Für die Berechnung der Nachrichten-Prioritäten
wird als Ausführungszeit die Zeit eines statischen Slots verwendet.
7.4.3 Scheduling der ttAKS-Tasks
Das Scheduling des Graphens für die gesamte Anwendungsrunde (Abb. E.1 und E.2) wird in
mehreren Schritten vollzogen:
• Als erstes werden die Tasks der Situationserfassung eingeplant. Dieses ist notwendig,
da die Tasks die kurze Periode von 500 µs einhalten müssen, um alle Nachrichten des
Laserscanners aus dem CAN-Buffer zu lesen.
• In den generierten Schedule werden die Tasks der Antriebsregelung und Fahrzeugko-
ordinierung integriert. Diese Task werden in den ersten 50 ms zwischen den Tasks der
Situationserfassung eingeplant. In den restlichen Perioden werden die Tasks zu Beginn
der 50-ms-Periode eingeplant, um der Objekterkennung ausreichend Zeit zur Ausführung
zu bieten.
• Im dritten Schritt werden die Tasks mit einer Periode von 500 ms zusätzlich in den Sche-
dule eingeplant. Abschließend werden die Tasks der Objekterkennung hinzugefügt. Diese
nehmen auf dem Knoten Renesas Vorne die restliche Ausführungszeit von 48550 µs nach
der Antriebsregelung in den 50-ms-Perioden ein.
Während des gesamten Schedulings werden die Nachrichten, die über FlexRay übertragen wer-
den eingeplant. Dabei werden die FlexRay-Parameter berücksichtigt. Die von den Nachrichten
abhängigen Tasks werden in den Schedule erst dann eingeplant, wenn die Nachricht übermittelt
wurde. Die durch das Scheduling generierten Dispatcher Tabellen für die Knoten, sowie eine
Auflistung der Nachrichtenplanung sind in Anhang F in den Tabellen F.3, F.4 und F.5 zu finden.
Dabei erhalten die Tasks und Nachrichten Indizes, die die Ausführungsnummer angeben, die
auch im CPG verwendet werden. In den Schedule für den Knoten Renesas Hinten wurden nach
dem Scheduling Dummy-Tasks eingefügt, da der Dispatcher keine TDMA-Runden unterstützt,
in denen keine Task-Ausführung stattfindet. Ein Teil der Tasks in den Dispatcher-Tabellen be-
sitzen Konditionen, unter denen sie ausgeführt werden. Zur Unterstützung der Konditionen ist
eine Erweiterung des Dispatcher erforderlich.
7.5 Implementation der Anwendung
In diesem Abschnitt werden die notwendigen Schritte zur Implementation des ttAKSs doku-
mentiert. Es werden die weiteren Schritte zur Integration des Schedules dargestellt, die Erwei-
terung des Dispatchers zur Ausführung von konditionierten Tasks und ein Synchronisations-
verfahren zum gemeinsamen Beginn der Anwendungsrunde auf beiden FlexRay-Knoten vorge-
stellt.
7.5.1 Implementation des Schedules
Der generierte Schedule ist in den Quelltext der Anwendung zu integrieren. Dazu sind
Dispatcher-Tabellen zu erstellen, die auf beiden Knoten implementiert werden. Diese enthalten
den Ausführungszeitpunkt des Tasks, dessen Periode und der Name der Funktion, die aufge-
rufen wird. Diese Angaben werden in einem Array gespeichert, wobei für jeden Task-Eintrag
eine Struktur mit den genannten Daten zu erstellen ist (Quelltext A.1). Die Funktionen des
ttAKS müssen ebenfalls implementiert werden. Hierzu werden die bereits zur Timing-Messung
erstellten Funktionen verwendet.
Neben einem Task-Schedule wurde ein Nachrichten-Schedule erstellt. Dieser wird in den DE-
COMSYS::DESIGNER übernommen, um daraus die Konfiguration für die beiden FlexRay
Kommunikations-Controller zu erstellen. Aus dem Quelltext heraus werden die Nachrichten
über die Slot-ID der zu sendenden Nachricht in den entsprechenden, automatisch zugewiesenen
Puffer geschrieben und zur richtigen Zeit durch den Kommunikations-Controller übertragen.
Es ist daher nur notwendig die Slot-IDs im Quelltext zu festzulegen und den generierten Code
einzubinden.
7.5.2 Erweiterung des Dispatcher um eine Konditionsbehandlung
Die Modellierung des ttAKS erlaubt Konditionen, die die Ausführung von Tasks bedingen.
Der Dispatcher aus Kapitel 5.1.3, der zur zeitgesteuerten Ausführung von Tasks verwendet
wird, unterstützt keine Behandlung von Konditionen. Zur Umsetzung des Dispatchers werden
folgende Erweiterungen vorgenommen:
• Jeder Knoten besitzt eine Liste mit lokalen Konditionswerten.
• Tasks, die Konditionen erzeugen, setzten Konditionswerte.

• Die Task-Einträge in der Dispatcher-Tabelle werden um die erforderlichen Konditionen

erweitert.
• Ein positiver Konditionswert gibt an, dass eine Kondition erfüllt sein muss.
• Ein negativer Konditionswert gibt an, dass eine Kondition nicht erfüllt sein darf.
• Der Dispatcher wird so erweitert, dass bei der Suche nach dem nächsten einzuplanenden
Task geprüft wird, ob die Task-Konditionen erfüllt werden. Sind die Kondition erfüllt,
wird der Task eingeplant, ansonsten wird der nächste Task in der Tabelle geprüft.
Erzeugt ein Task Konditionen, so müssen diese auf dem Knoten bekannt gegeben werden.
Eine positive Kondition wird durch die Methode add_cond(Kondition) (Quelltext E.3)
hinzugefügt, eine nicht erfüllte Kondition wird durch die Methode rem_cond(Kondition)
(Quelltext E.4) entfernt. Tasks, die von Konditionen abhängen, besitzen in der Dispatcher-
Tabelle einen zusätzlichen Eintrag für die Kondition (Quelltext E.1). Durch die Funktion
check_cond(Kondition) (Quelltext E.5) lässt sich prüfen, ob die gegebene Kondition er-
füllt ist.
Die Dispatcher-ISR sucht vor Ausführung des Tasks nach dem Task, der in der nächsten Aus-
führung aktiviert wird. Die Suche wird in einer Schleife vollzogen, die zur Berücksichtigung
von Konditionen angepasst wurde. Neben der Bedingung, dass der TDMA-Runden-Offset Null
sein muss, muss nun zusätzlich die Kondition erfüllt sein. Ist die Kondition eines Tasks nicht
erfüllt, so wird der TDMA-Runden-Offset zurückgesetzt. Ist die Kondition erfüllt, ist der Task
für die nächste Ausführung gefunden (Quelltext E.2). Die hier aufgeführten Quelltexte sind im
Anhang E.2 dokumentiert.
In dieser Anwendung werden die Konditionen, die nur Auswirkungen auf die lokale Task-
Ausführung besitzen, nicht zum anderen Knoten übertragen. Im implementierten ttAKS ist nur
die Manöver-Kondition zu übertragen. Sie wird direkt durch die Aktionsentscheidung über den
FlexRay-Bus übertragen, die diese Kondition erzeugt.
7.5.3 Synchronisation der FlexRay-Knoten zum synchronen

Anwendungsrundenbeginn
Das Synchronisationsverfahren, das im FlexRay-Protokoll integriert ist, synchronisiert die

Kommunikations-Controller im FlexRay-Netzwerk. Die beiden FlexRay-Knoten benötigen ei-
ne unterschiedlich lange Zeit zur Initialisierung, da an ihnen zum Teil Peripherie angeschlossen
ist, die gesonderte Initialisierungsroutinen erfordern. Zusätzlich besitzen die Tasks des ttAKS
unterschiedliche Perioden, wodurch ein Knoten nicht später in die Anwendung integrierbar ist.
Daher ist eine Synchronisation zwischen den Knoten im Netzwerk erforderlich, um einen ge-
meinsamen Start der Anwendungsrunde zu gewährleisten.
In dieser Implementierung wird für jeden Knoten ein Slot festgelegt, in dem der Knoten eine
Nachricht sendet, sobald die Initialisierung abgeschlossen ist. Der Knoten Renesas Vorne sendet
im Slot 1 und der Knoten Renesas Hinten im Slot 18. Wird vom anderen Knoten diese Nachricht
empfangen, wird bis zur TDMA-Runde mit dem Index 63 gewartet. Ist diese erreicht, wird der
Timer-Wert für die Ausführung des ersten Tasks gesetzt. Dadurch wird ein gemeinsamer Beginn
in der TDMA-Runde mit dem Index 0 erreicht (Quelltext E.6).
8 Timinganalyse des zeitgesteuerten
Antikollisionssystems
In diesem Kapitel werden Timing-Messungen zum implementierten ttAKS durchgeführt. Es

wird die zeitgesteuerte Kommunikation mit dem DECOMSYS::BUSDOCTOR aufgezeichnet
und mit dem generierten Nachrichten-Schedule verglichen. Die Ausführung der zeitgesteuerten
Tasks wird exemplarisch mit dem Oszilloskop aufgenommen und mit der Task-Planung vergli-
chen.
8.1 Timing-Messungen zur zeitgesteuerten Kommunikation
Zur Analyse der Nachrichtenübermittlungen wird der DECOMSYS::BUSDOCTOR verwen-

det. Hierbei handelt es sich um eine Hardware, die Schnittstellen zum FlexRay-Bus bietet, und
Software zur Anzeige und Aufzeichnung der übertragenen Nachrichten. Es wird eine Nachrich-
tensequenz aufgezeichnet, die zu jeder Nachricht folgende Informationen liefert:
• Bus: Gibt die Datenquelle an, hier wird nur FR für FlexRay verwendet
• ID: Dieser Parameter zeigt die Frame-ID an oder ein Symbol das empfangen wird. Hierzu
gehören Symbols, Error-Frames und Null-Frames.
• Channel: BusDoctor-Kanal, über den die Nachricht empfangen wurde.
• Time: Zeitstempel, der internen Uhr des BusDoctors
• Sync: Ein Sync-Frame wird in diesem Feld durch eine 1 angezeigt.
• Cycle: Wert des Frame-Counters zu dem der Frame empfangen wurde.
• Length: Länge des Frames in Byte, hexadezimal.
• Data: Inhalt des FlexRay-Frames in hexadezimal. Handelt es sich um ein Symbol, werden
Informationen zu dem Symbol angezeigt.
• Valid: Zeigt an, ob der zuvor empfangene Frame mit diesem Identifier gültig war.
• Status: Status des FlexRay-Frames. Hierzu gehören Fehler wie Empfangen eines Frames
innerhalb der NIT(NIT Violation), Empfangen von zwei Frames in einem Slot (Sloto-
verbooked error), falsche Frame-ID (Frame ID Error). Eine vollständige Auflistung ist in
[DECOMSYS BUSDOCTOR (2006)] zu finden.
• NFI: Der Nullframe-Indikator gibt mit einer 0 an, dass es sich um einen Nullframe han-
delt.
• StartUp: Eine 1 gibt an, dass es sich bei dem Frame um einen Startup Frame handelt.
Die Kommunikation des ttAKS wurde in einem Versuchsaufbau aufgezeichnet. Die Nachrich-
tensequenz der ersten TDMA-Runde in der zweiten Anwendungsrunde wird in der Tabelle 8.1
dargestellt. In dieser Tabelle sind nur die wesentlichen Parameter der Nachrichten aufgeführt.
Zur Verifizierung des Nachrichteninhalts wurden Test-Daten (0x1 - 0xF) im ersten Byte der
Nachricht übertragen. Im Testaufbau ist keine Nachricht im Slot mit der ID 98 übertragen wor-
den, da in der Testausführung die Manöver-Kondition auf einen Wert festgesetzt wurde und es
so keine Variation in der Ausführung des abhängigen Tasks gab.
Die FlexRay-Nachrichtensequenz aus Tabelle 8.1 zeigt, dass die Nachrichten in den im Schedu-
le definierten Slots gesendet werden. In der Tabelle sind die relativen Zeitpunkte der Slots zum
Beginn der TDMA-Runde bzw. dem ersten Slot der TDMA-Runde aufgeführt. Diese zeigen,
dass die Slot-Zeiten wie in Slot 4 und 18 nicht durchgängig 30 µs betragen und teilweise um
25 ns abweichen, was einer Abweichung von weniger als 0,1 % entspricht. In Slot 4 wird die
Nachricht V Ist Vorne übertragen, die durch den Task Messe V Vorne erzeugt wird. Der Task ist
bis zu einer Zeit von 330 µs auf dem Knoten zur Ausführung eingeplant, während der Slot 4
bereits bei einer Zeit von 329,975 µs beginnt. Da der Task einen zusätzlichen Puffer zur WCET
besitzt, beeinträchtigen diese Abweichungen die Kommunikation nicht. Insgesamt ist bis zum
Slot 205 eine Abweichung von 0,3 µs zu verzeichnen. Dieses kann durch die Uhr des BusDoc-
tors hervorgerufen werden, da dessen interne Uhr, die als Referenz für die Zeitangabe dient,
eine Auflösung von 25 ns besitzt und deren Genauigkeit in der Dokumentation des Geräts nicht
genannt wird.
Weitere Timing-Messungen zur Kommunikation sind im Anhang G in den Tabellen G.1 bis G.5
zu finden. Dort werden die Synchronisationsphase des FlexRay-Protokolls, die Synchronisation
der FlexRay-Knoten zum Starten der gemeinsamen Anwendungsrunde und die TDMA-Runden
1, 2 und 6 aus der ersten Anwendungsrunde dargestellt.
Tabelle 8.1: Nachrichtensequenz der 51. TDMA-Runde des ttAKS, Beginn der zweiten Anwendungsrunde inkl. der relativen Zeit zum TDMA-Runden-
Beginn
ID Ch Time[s] rel. Time [µs] Cycle NFI Daten[hex] Nachricht Sende-Task Empfangs-Task
1 A 3,367407750 0 50 1 01000000 Objektdaten 1 Objekterkennung Umgebungsanalyse
2 A 3,367437750 30,000 50 1 02000000 Objektdaten 2 Objekterkennung Umgebungsanalyse
12 A 3,367737725 329,975 50 1 0b000000 V Ist Vorne 1 Messe Regel
V Vorne V Vorne
14 A 3,367797725 389,975 50 1 09000000 Sollwerte Empfange Soll Regel V/Phi
Komm-Server Komm-Server Vorne/Hinten
18 A 3,367917700 509,950 50 1 0c000000 Stellwert Regel Stelle
V Vorne 1 V Vorne V Vorne
20 A 3,367977700 569,950 50 1 0c000005
8 Timinganalyse des zeitgesteuerten Antikollisionssystems
26 A 3,368157700 749,950 50 1 0a000005

26 B 3,368157700 749,950 50 1 0a000005
31 A 3,368307700 899,950 50 1 0a000000 Phi Ist Vorne 1 Messe Regel
Phi Vorne Phi Vorne
46 A 3,368757675 1349,925 50 1 0d000005
48 B 3,368817650 1409,900 50 1 0d000000 Stellwert Regel Stelle
Phi Vorne 1 Phi Vorne Phi Vorne
48 A 3,368817675 1409,925 50 1 0d000000 Stellwert Regel Stelle
98 A 3,370317600 2909,850 50 1 0e000000
190 A 3,373077475 5669,725 50 0 00000000
205 A 3,373527450 6119,700 50 1 0f000000
87
8.2 Timing-Messung der zeitgesteuerten Taskausführung
Die Timing-Messungen der zeitgesteuerten Task-Ausführung wird in einem Versuchsaufbau

mit Hilfe des Oszilloskops durchgeführt, das für die Timining-Messungen aus Kapitel 7.2 ver-
wendet wurde. Zur Messung werden zwei digitale Ausgänge des Renesas Mikrocontrollers ver-
wendet. Der eine Ausgang wird nach dem Eintreten der ISR von einem High-Pegel auf einen
Low-Pegel und zum Austritt wieder auf einen High-Pegel gesetzt. An dem anderen Ausgang
wird das gleiche für die Task-Ausführung durchgeführt. An Hand der gemessenen Flanken, die
die ISR begrenzen, kann die Ausführungszeit der ISR gemessen und die genaue Aktivierung
durch den Timer-Interrupt des Kommunikations-Controllers beobachtet werden.
Die Timing-Messungen wurden exemplarisch für die ersten Tasks der Anwendungsrunde auf
beiden Knoten aufgezeichnet. Eine Aufzeichnung der ersten 0,9 ms der Anwendungsrunden,
die auf beiden Knoten sieben Tasks beinhaltet, wird in der Abb. 8.1 dargestellt. Die erste fal-
lende Flanke stellt den Eintritt in die ISR dar, die zweite den Beginn der Task-Ausführung. Die
steigenden Flanken werden am Ende des Tasks und zum Ende der ISR generiert. Die durch den
Schedule geeplanten Ausführungszeiten wurden durch diese Messungen bestätigt.
Die Timing-Messung zum Knoten Renesas Vorne (Abb. 8.1a) zeigt diese Tasks und deren Aus-
führungszeitpunkten: Situationserfassung 1 (0 µs), Messe V Vorne (275 µs), Empfange Soll-
Werte Kommunikations-Server (330 µs), Status Vorne Auswerten (405 µs), Situationserfassung
2 (500 µs), Stelle V Vorne (775 µs), Messe Phi Vorne (845 µs).
Diese Tasks und deren Ausführungszeitpunkte sind auf der Aufzeichnung zum Knoten Renesas
Hinten (Abb. 8.1b)dargestellt: Messe V Hinten (0 µs), Regel V Hinten (55 µs), Regel V Vorne
(360 µs), Stelle V Hinten (540 µs), Status Hinten Auswerten (610 µs), Eingangsfilter (720 µs),
Messe Phi Hinten (845 µs).
(a) Renesas Vorne
(b) Renesas Hinten
Abb. 8.1: Task-Timing-Messung zum Beginn der Anwendungsrunde auf den FlexRay-Knoten
9 Weitere Entwicklungsschritte
In dieser Arbeit sind Methoden zur Modellierung und Implementation einer zeitgesteuerten
Anwendung auf einer zeitgesteuerten Plattform dokumentiert worden. Die Timing-Messungen
zum implementierten ttAKS haben gezeigt, dass die durch die Methoden entwickelte Planung
umgesetzt wurde. Daraus folgt, dass sich diese Methoden zur Umsetzung von zeitgesteuerten
Anwendungen auf einer zeitgesteuerten Plattform eignen. Aufbauend auf den Ergebnissen die-
ser Arbeit lassen sich folgende weitere Entwicklungsschritte ableiten:
• Der Task- und Nachrichten-Schedule wurde mit den vorgestellten Methoden zur Imple-
mentation des ttAKS manuell durchgeführt. Zur effizienten Anwendung der Methoden ist
die Erstellung einer Software sinnvoll, die diese Aufgaben übernimmt.
• Die Task-Prioritäten wurden durch eine einfache Prioritätsfunktion festgelegt, die gute
Ergebnisse liefert. Die Verwendung einer Software erlaubt komplexere Methoden, die
verbesserte Schedules in Bezug auf die Ausführungszeit der Anwendung erzeugen.
• In dieser Arbeit wurden keine Optimierungsmethoden angewendet, wie sie in [Pop u. a.

(2004)] dokumentiert sind. Diese Methoden erlauben die Generierung eines kürzeren
Schedules durch die Anpassung von Parametern des Kommunikations-Protokolls wie die
Länge und Knotenzuordnung der Slots. Aufgrund der Komplexität ist die Anwendung
dieser Methoden erst durch die Verwendung von Software sinnvoll.
• Für die Funktionen des ttAKS wurde in dieser Arbeit keine auf den Mikroprozessor abge-
stimmte Code-Optimierung durchgeführt. Durch die Optimierung sind kürzere Laufzeiten
der Funktionen realisierbar. Mit geringeren Ausführungszeiten lässt sich die Abtastrate
des ttAKS erhöhen.
• Der verwendete Laserscanner bietet einen integrierten Digitaler Signalprozessor (DSP),

der zur Vorverarbeitung von Messwerten einsetzbar ist. Ein weitere Entwicklungsschritt
wäre die Prüfung der Anwendbarkeit für die hier dokumentierte Anwendung mit dem
Ziel die Abtastrate der Anwendung zu erhöhen.
• Eine Alternative zur Optimierung und Auslagerung von Funktionen ist die Verwendung
einer leistungfähigeren Hardware zur Verringerung der Abtastrate des ttAKS Die Ver-
wendung leistungsfähigerer Hardware ist Grundvoraussetzung für die Erweiterung um
weitere Fahrerassistenzfunktionen.
10 Zusammenfassung
In Automobilen ist eine Zunahme an Fahrerassistenzsystemen zu beobachten. Diese lassen sich

als verteilte Regelungen betrachten, die die lokal verteilten und vernetzten Steuergeräte verwen-
den. Mit der Zunahme an Funktionen steigt die Auslastung der Knoten und die Kommunikation.
In einem ereignisgesteuerten Bussystem führt eine hohe Auslastung zu Kollisionen und erzeugt
so ein nicht vorhersagbares Antwortverhalten. In sicherheitskritischen Anwendungen kann die-
ses zu fatalen Folgen führen. Eine Lösung ist eine zeitgesteuerte Task-Ausführung mit einem
zeitgesteuerten Bussystem wie FlexRay.
Die Planung eines solchen Systems erfordert Methoden zur Generierung eines abgestimmten
Task- und Nachrichten-Schedules. Es werden in dieser Arbeit verfügbare Werkzeuge und doku-
mentierte Ansätze zur Planung eines Echtzeitsystems vorgestellt. Die verfügbaren Werkzeuge
eignen sich nur zur Konfiguration des FlexRay-Protokolls. Methoden zur abgestimmten Task-
und Nachrichten-Planung sind zur Zeit nur in einem Ansatz der Universität Linköping doku-
mentiert. Diese Methoden werden hier dargestellt und zur Implementation eines zeitgesteuerten
Antikollisionssystems (ttAKS) angewendet. Die Modellierung der Anwendung wird in einem
polaren, gerichteten, azyklischen Conditional Process Graph (CPG) durchgeführt, der Kondi-
tionen zur bedingten Task-Ausführung unterstützt. Der abgestimmte Task- und Nachrichten-
Schedule wird durch ein statisches Offline-Scheduling-Verfahren generiert, das auf einer List-
Scheduling-Heuristik basiert. Zudem wird ein in einer Masterarbeit entwickeltes Software-
Konzept für verteilte, zeitgesteuerte Anwendungen vorgestellt und dessen Dokumentation ver-
vollständigt. Teile dieses Konzepts werden in dieser Arbeit verwendet und erweitert.
Ein in einer Masterarbeit entwickeltes ereignisgesteuertes Antikollisionssystem (etAKS) wird

in dieser Arbeit in eine zeitgesteuerte Ausführung transformiert. Dazu werden die nebenläu-
figen Threads in periodisch ausführbare Tasks überführt. Die zeitgesteuerte Zielplattform be-
steht aus zwei Renesas M32C/85 Mikrocontrollern, die über FlexRay kommunizieren. Aus den
Eigenschaften der Zielplattform werden Randbedingungen abgeleitet, die zur Anpassung der
Abtastrate des ttAKS führen. Zur Implementation des ttAKS werden die Funktionen in CPGs
modelliert und Timing-Messungen auf der Zielplattform durchgeführt. Die Task-Aktivierung
wird durch einen Timer des Kommunikations-Controllers gesteuert, der einen Dispatcher star-
tet. Dieser führt die Task-Aktivierung auf Basis der generierten Dispatcher-Tabelle aus. Die
Kommunikation wird nach dem generierten Nachrichten-Schedule durchgeführt. Da die Peri-
ode der Anwendung größer als die TDMA-Runde ist, wird vor Beginn der Ausführung ein
Verfahren zur Synchronisation der FlexRay-Knoten implementiert.
Timing-Messungen auf der Zielplattform haben die geplanten Ausführungszeiten und Nach-
richtenübermittlungen bestätigt. Daraus lässt sich ableiten, dass die hier verwendeten Methoden
für die Synthese und Implementation einer zeitgesteuerten Anwendung anwendbar sind.
Abbildungsverzeichnis
2.1 Fahrerloses Transportfahrzeug SCV [Schetler (2007)] . . . . . . . . . . . . . . 4
2.2 Systemübersicht zur ereignisgesteuerten Plattform [Sellentin (2006)] . . . . . . 5
2.3 Systemübersicht zur zeitgesteuerten Plattform [Sellentin (2006)] . . . . . . . . 6
3.1 Aufbau eines FlexRay-Knotens [Rausch (2008)] . . . . . . . . . . . . . . . . . 11

3.2 Aufbau einer TDMA-Runde . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Slot-Zuordnung von Frames und Knoten . . . . . . . . . . . . . . . . . . . . . 12
3.4 Frames im dynamischen Segment . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Eine in SymTA/S modellierte Anwendung . . . . . . . . . . . . . . . . . . . . 15

4.2 Phasen der Systemanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Die Logische Ausführungszeit LET . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 TDL Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Tool Chain zur Generierung einer TDL-Anwendung . . . . . . . . . . . . . . . 19
4.6 TDL-Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 Zeitliche Kopplung zwischen Taskausführung und Kommunikation . . . . . . . 25

5.2 Werzeugkette zur Anwendungsentwicklung . . . . . . . . . . . . . . . . . . . 26
5.3 Dispatcher Tabellen und deren Initialisierung . . . . . . . . . . . . . . . . . . 28
5.4 Timing-Darstellung einer Beispielanwendung . . . . . . . . . . . . . . . . . . 30
5.5 Aktivitätsdiagramm der Main-Prozedur . . . . . . . . . . . . . . . . . . . . . 31
5.6 Aktivitätsdiagramm der Initialisierungs-Prozedur . . . . . . . . . . . . . . . . 32
5.7 Aktivitätsdiagramm der Idle-Prodzedur . . . . . . . . . . . . . . . . . . . . . 33
5.8 Aktivitätsdiagramm der Dispatcher Interrupt-Service-Routine . . . . . . . . . . 34
5.9 Zugeordneter Conditional Process Graph einer Anwendung [Pop u. a. (2004)] . 37
5.10 CPG für unterschiedliche Perioden . . . . . . . . . . . . . . . . . . . . . . . . 39
5.11 Laufzeitannahmen zur Prioritätsfunktion . . . . . . . . . . . . . . . . . . . . . 42
6.1 Thread-Übersicht Antikollisionssystem [Schetler (2007)] . . . . . . . . . . . . 45

6.2 Entscheidungsautomat für die Aktionsausführung [Schetler (2007)] . . . . . . 49
6.3 DAG zur zeitgesteuerten Antriebsregelung und Fahrzeugkoordinierung ([Sel-
lentin (2006)]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1 DAG zur Geschwindigkeits- und Lenkwinkelregelung . . . . . . . . . . . . . . 57

7.2 CPG und Schedule zur Geschwindindigkeits- und Lenkwinkelregelung (Model-
lierungsansatz 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 CPG und Schedule zur Geschwindigkeits- und Lenkwinkelregelung (Modellie-
rungsansatz 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.4 DAG zu den Tasks mit einer Periode von 50 ms . . . . . . . . . . . . . . . . . 60
7.5 CPG und Schedule zur Koordinierungsfunktion und Ist-Daten-Übertragung . . 61
7.6 CPG zur Antriebsregelung und Koordinierung mit gekapselten Untergraphen . 63
7.7 Modellierung der Odometrie als CPG . . . . . . . . . . . . . . . . . . . . . . 65
7.8 Modellierung der Situationserfassung als CPG . . . . . . . . . . . . . . . . . . 67
Abbildungsverzeichnis 93
7.9 Modellierungsvarianten der Situationserfassung . . . . . . . . . . . . . . . . . 69

7.10 CPG zur zeitgesteuerten Objekterkennung . . . . . . . . . . . . . . . . . . . . 70
7.11 CPG zur Umgebungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.12 CPG zur Aktionsentscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.13 CPG zur Aktionsausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.14 CPG zum AKS mit Kapselung der Funktionen . . . . . . . . . . . . . . . . . . 76
7.15 Schematische Darstellung des AKS Implementierungskonzepts . . . . . . . . . 78
8.1 Task-Timing-Messung zum Beginn der Anwendungsrunde auf den FlexRay-

Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.1 Graph einer Anwendung [Sellentin (2006)] . . . . . . . . . . . . . . . . . . . 104

A.2 Ablaufplan des Scheduling-Verfahrens . . . . . . . . . . . . . . . . . . . . . . 106
A.3 Generiertes Task-Schedule zum Graphen aus Abb. A.1 (Sellentin (2006)) . . . 107
C.1 Timing-Messungen der Addition von Gleitkommazahlen und Ganzzahlen bei

100 Wiederholungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.2 Timing-Messungen der Multiplikation von Gleitkommazahlen und Ganzzahlen
bei 100 Wiederholungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
C.3 Timing-Messung der Division von Gleitkommazahlen und Ganzzahlen bei 100
Wiederholungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
C.4 Timing-Messungen der Sinusfunktion als Berechnung und Wertetabelle bei 100
Wiederholungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
C.5 Timing-Messungen der Cosinusfunktion als Berechnung und Wertetabelle bei
100 Wiederholungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
D.1 CPG und Schedule zur Geschwindindigkeits- und Lenkwinkelregelung (Model-

lierungsansatz 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
D.2 Timing-Messungen der Odometrie-Funktion vor und nach der Optimierung . . 123
D.3 Timing-Messungen der Reset- und Achswinkelsetzen-Funktion der Odometrie . 124
D.4 Timingmesseung zur Situationsanalyse . . . . . . . . . . . . . . . . . . . . . . 125
D.5 Timingmessung zur Objekterkennung . . . . . . . . . . . . . . . . . . . . . . 125
D.6 Timingmessung zur Umgebungsanalyse . . . . . . . . . . . . . . . . . . . . . 126
D.7 Timingmessung zur Aktionsentscheidung . . . . . . . . . . . . . . . . . . . . 126
D.8 Timingmessung zur Aktionsausführung . . . . . . . . . . . . . . . . . . . . . 127
D.9 Ausführungszeit des Dispatcher in der Interupt-Service-Routine . . . . . . . . 128
E.1 CPG zum kompletten ttAKS für die gesamte Anwendungsrunde Teil 1: Situati-
onserfassung und Objekterkennung . . . . . . . . . . . . . . . . . . . . . . . . 133
E.2 CPG zum kompletten ttAKS für die gesamte Anwendungsrunde Teil 2: An-
triebssteuerung und Tasks mit einer Periode von 500 ms . . . . . . . . . . . . . 134
Tabellenverzeichnis
4.1 Vergleich der Werkzeuge und Ansätze nach Funktionen . . . . . . . . . . . . . 23
6.1 Timing-Messung für 100 Wiederholungen von Gleitkomma- und Ganzzahlbe-

rechnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Timing-Messung für 100 Wiederholungen der Cosinus- und Sinus-Funktionen . 55
7.1 Übersicht der Task-WCET der Antriebssteuerung und Fahrzeugkoordinierung

(Sellentin (2006)), sowie die einzuplanende WCET für das ttAKS . . . . . . . 62
7.2 Übersicht der Taskausführungszeiten . . . . . . . . . . . . . . . . . . . . . . . 75
7.3 Task-Übersicht mit Abkürzungen, Periode, WCET und Knotenzuordnung . . . 79
7.4 Nachrichten des ttAKS, deren Länge und Sende- / Empfangsknoten . . . . . . 80
8.1 Nachrichtensequenz der 51. TDMA-Runde des ttAKS, Beginn der zweiten An-
wendungsrunde inkl. der relativen Zeit zum TDMA-Runden-Beginn . . . . . . 87
B.1 Quelldateien der ereignisgesteuerten AKS-Funktionen . . . . . . . . . . . . . 113
D.1 CAN-Trace Kommunikation zwischen Laserscanner und µC . . . . . . . . . . 129
F.1 Übersicht der FlexRay-Nachrichten und deren Größe . . . . . . . . . . . . . . 137

F.2 Übersicht zu den wesentlichen Parametern des FlexRay-Netzwerks im ttAKS . 137
F.3 Dispatcher Tabelle für den Knoten Renesas Vorne . . . . . . . . . . . . . . . . 137
F.4 Dispatcher Tabelle für den Knoten Renesas Hinten . . . . . . . . . . . . . . . 140
F.5 Nachrichten-Schedule der ttAKS-Nachrichten . . . . . . . . . . . . . . . . . . 143
G.1 Nachrichtensequenz der FlexRay-Knoten-Synchronisation . . . . . . . . . . . 147

G.2 Nachrichtensequenz der ttAKS-Synchronisation zum gemeinsamen Start der
Anwendungsrunde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
G.3 Nachrichtensequenz der ersten TDMA-Runde des ttAKS, Beginn der ersten
Anwendungsrunde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
G.4 Nachrichtensequenz der zweiten TDMA-Runde des ttAKS . . . . . . . . . . . 152
G.5 Nachrichtensequenz der sechsten TDMA-Runde des ttAKS, Beginn der zweiten
50-ms-Periode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Quellcodeverzeichnis
5.1 Pseudocode zum List-Scheduling Algorithmus [Pop u. a. (2004)] . . . . . . . . 40
5.2 Pseudocode zum Message-Scheduling Algorithmus [Pop u. a. (2004)] . . . . . 41
A.1 Struktur der Dispatcher Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.2 Struktur der Dispatcher Variablen Tabelle . . . . . . . . . . . . . . . . . . . . 107
A.3 Main-Prozedur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A.4 Dispatcher-ISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A.5 Init Dispatcher Prozedur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.6 Idle Prozedur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
E.1 Struktur der um Konditionen erweiterten Dispatcher Tabelle . . . . . . . . . . 135

E.2 Ausschnitt aus der Dispatcher-ISR zur Suche nach dem nächsten auszuführen-
den Task unter Berücksichtigung von Konditionen . . . . . . . . . . . . . . . . 135
E.3 Funktion zum Hinzufügen von Konditionen . . . . . . . . . . . . . . . . . . . 135
E.4 Funktion zum Entfernen von Konditionen . . . . . . . . . . . . . . . . . . . . 135
E.5 Funktion zur Prüfung von Konditionen . . . . . . . . . . . . . . . . . . . . . . 135
E.6 Synchronisation zum gemeinsamen Start der Anwendungsrunde (Ausschnitt
aus der Dispatcher-Idle-Funktion) . . . . . . . . . . . . . . . . . . . . . . . . 136
Glossar
Aktivität Eine Aktivität entspricht einer Funktion oder einem Task einer Anwendung.
Anwendungsrunde Die Anwendungsrunde enthält alle Tasks unterschiedlicher Periode, die

im System vorhanden sind. Die Länge der Anwendungsrunde entspricht im Allgemeinen
dem kleinsten gemeinsamen Vielfachen der Perioden.
Bus-Guardian Der Bus Guardian ist eine optionale Komponente eines FlexRay
Kommunikations-Controllers. Er dient zur Überwachung des Bus-Treibers und zur
Erkennung fehlerhafter Kommunikations-Controller im FlexRay-Netz.
Condtitional Process Graph Der Conditional Process Graph wird zur Modellierung von An-
wendungen verwendet. Es werden die Tasks als Knoten und Abhängigkeit zwischen ih-
nen als Kanten dargestellt. Besonderheit dieser Graphen sind Kanten mit Konditionen,
die nur ausgeführt werden, wenn die Kondition erfüllt ist. Der Graph ist gerichtet, polar
und azyklisch.
Deadline Die Deadline beschreibt eine obere Zeitschranke, bis zu der die Bearbeitung eines
Tasks abgeschlossen sein muss.
Dispatcher Ein Dispatcher ist ein Teil des Betriebssystems, der die Tasks zur Ausführung
bringt. Die Entscheidung welcher Task aktiviert wird, ist vom Scheduler zu treffen.
Dispatcher-Tabelle Eine Dispatcher-Tabelle beinhaltet die im System vorhandenen Tasks und

deren Ausführungszeitpunkte. Sie wird durch einen Offline-Scheduler vor der Implemen-
tierung generiert und steuert die Aktivierung von Tasks durch den Dispatcher.
Dynamisches Segment Das dynamische Segment ist ein Teil der FlexRay TDMA-Runde, der
sich vor allem zur Übertragung von zeitunkritischen Nachrichten eignet.
Fahrerassistenz- und autonome Systeme Projekt der HAW Hamburg, dem mehrere Projek-
te zu den Themen Fahrerassistenzsysteme, Sensorik und Telemetrie in Fahrzeugen und
autonome Fahrzeuge untergeordnet sind.
Fahrerassistenzsystem Ein Fahrerassistenzsystem (FAS) ist ein elektronisches System in ei-

nem Fahrzeug, dass der Unterstützung des Fahrers in bestimmten Fahrsituationen unter-
stützt.
FlexRay Das Kommunikationssystem FlexRay ist ein zeitgesteuertes Bussystem, das für die
Automobilbranche entwickelt wurde. Es bietet Bereiche für die statische zeitgesteuerte
Glossar 97
Datenübertragung nach dem TDMA-Verfahren und dynamische Datenübertragung nach

dem FTDMA-Verfahren.
FPGA Ein FPGA (Field Programmable Gate Array) ist ein programmierbarer integrierter Lo-
gikbaustein, der sich zum Aufbau von verschiedensartigen Schaltkreisen eignet.
Frame Ein Frame kapselt Daten zur Übertragung über ein Kommunikationsmedium. Er bein-
haltet z. B. im FlexRay-Protokoll zusätzliche Informationen wie Frame-ID, Nutzdaten-
länge und Prüfsumme..
FTDMA-Vefahren Das FTDMA-Verfahren ist dem TDMA-Verfahren ähnlich. Die Zeitfenster

sind kleiner und die Nachrichten werden nicht in jedem Zeitfenster übertragen. Ist eine
Nachricht zu übertragen, so wird der Slot auf mehrere FTDMA-Slots erweitert, um die
Nachricht zu übertragen.
Globale Zeit Die globale Zeit beschreibt eine im verteilten System auf allen Knoten einheitli-
che Zeitbasis, die mit der selben Geschwindigkeit fortschreitet.
Interrupt Service Routine Die ISR wird zur Behandlung eines Interrupt Requests (Unterbre-
chungsanforderung) durch die CPU ausgelöst und unterbricht die Ausführung des norma-
len Programmablaufs. Interrupts werden z.B. durch Timer oder Peripheriegeräte erzeugt,
die dadurch eine Reaktion darauf anfordern.
Jitter Jitter beschreibt die Schwankung eines Taktes z.B. bei der Datenübertragung. Es be-
schreibt auch die Varianz der Laufzeit von Nachrichten.
Knoten Mikrorechner mit eigener Hardware und Software, der eine Menge von definierten
Funktionen in einem verteilten Rechner-System wahrnimmt. Besteht meist aus einem
Mikrocontroller mit angeschlossenem Kommunikations-Controller.
Macroticks Macroticks bilden die grundlegende Zeiteinheit für die Definition von Parametern
des FlexRay-Protokolls. Macroticks sind auf allen Knoten eines verteilten Systems gleich
lang. Sie bestehen aus Microticks, die auf allen Systemen unterschiedlich lang sein kön-
nen.
Mikrocontroller Ein Mikrocontroller ist ein Halbleiter-Chip, der einen Prozessor, Peripherie-
funktionen und im Allgemeinen Speicher in einem Chip vereint.
Network Idle Time Die Network Idle Time (NIT) beschreibt ein Segment des FlexRay-
Protokolls. Während dieses Segments werden keine Nachrichten übermittelt. Es dient zur
Uhren-Synchronisation der Kommunikations-Controller aller Knoten in einem FlexRay-
Netz.
Offset Offset entspricht im Bezug auf die Taskaktivierung den Aktivierungszeitpunkt relativ
zum Beginn der TDMA-Runde bzw. Anwendungsrunde.
Glossar 98
Periode Die Periode eines Tasks oder Graphens beschreibt die Zeit, nach der der Task oder
Graph erneut ausgeführt wird.
Redundanz Vorhandensein von mehr als für die Ausführung der vorhergesehen Aufgaben an
sich notwendigen Mitteln.
Scheduler Ein Scheduler plant die Ausführung von Tasks auf einem Prozessor. Dieses kann
nach unterschiedlichen Strategien erfolgen, die sowohl zur Laufzeit als auch in der Ent-
wicklungphase der Anwendung einen Schedule erzeugen.
Scheduling Das Scheduling beschreibt die Erstellung eines Schedules. An Hand eines Sche-
dules werden Tasks einem Prozessort zugeordnet.
Sensor Controlled Vehicle Das SCV ist ein Versuchsfahrzeug einer fahrerlosen Transport-
plattform, auf dem im Projekt FAUST Fahrerassistenzsysteme zur Untersuchung inte-
griert werden.
Slot Ein Slot beschreit ein Zeitfenster, in dem eine Nachricht über ein zeitgesteuertes Kommu-
nikationsmedium wie FlexRay übertragen wird.
Slotlänge Die Slotlänge beschreibt die zeitliche Länge eines Zeitfensters (Slots).
Slotzuordnung Als Slotzuordnung wird die exklusive Zuordnung von Zeitfenstern (Slots) zu
Knoten bezeichnet.
Statisches Segment Das statische Segment ist ein Teil der FlexRay TDMA-Runde, der sich
zur deterministischen Übertragung von zeitkritischen Nachrichten eignet.
Steuergerät Ein Steuergerät (Electronic Control Unit (ECU)) ist ein elektronisches Modul in
einem Kraftfahrzeug, das zur Steuerung von Regelungen und elektronischen geräten ein-
gesetzt wird.
Symbol Window Das Symbol Window ist ein Teil der FlexRay TDMA-Runde, der zur Erken-
nung von fehlerhaften Bus-Guardians genutzt wird.
Task Ein Task ist ein Programmteil, der durch ein durch ein Betriebssystem verwaltetes Pro-
grammteil
TDMA-Runde Die TDMA-Runde beschreibt den Kommunikationszyklus, der sich periodisch

nacheinader wiederholt.
TDMA-Verfahren Das TDMA-Verfahren wird zur zeitgesteuerten Nachrichtenübertragung

eingesetzt. Die Übermittlung von Nachrichten wird in Zeitfenster (Slots) durchgeführt,
wodurch keine Kollisionen auf dem Medium entstehen. Die einzelnen Slots werden sen-
denen Busteilnehmern exklusiv zugeordnet.
Timer Als Timer wird ein Zähler bezeichnet, der im Allgemeinen bei Ablauf oder Erreichen
eines festgelegten Wertes einen Interrupt erzeugt.
Glossar 99
Timing Definition Language Die Timing Definition Language (TDL) ist eine plattformunab-
hängige Sprache zur Modellierung von zeitgesteuerten harten Echtzeit-Anwendungen.
Timmo Das Timing Model Projekt beschreibt ein Projekt zur Entwicklung einer standardisier-
ten Infrastruktur zur Behandlung von Echtzeitaspekten für verteilte Elektronik im Auto-
mobil am C-Lab der Universität Paderborn.
Verteilte Anwendung Die gesamte Anwendung, die auf den Knoten eines verteilten Systems
ausgeführt wird.
Worst Case Execution Time Die WCET definiert die maximale Ausführungszeit eines Tasks
für alle gegebenen Variablen.
Abkürzungsverzeichnis
ABS Anti-Blockiersystem
AKS Antikollisionssystem
AST Abstract Syntax Tree
CAN Controller Area Network

CPG Conditional Process Graph
DAG Directed Acyclic Graph

DSP Digitaler Signalprozessor
EDF Earliest Deadline First

ESP Electronic Stability Program
etAKS ereignisgesteuertes Antikollisionssystem
FAUST Fahrerassistenz- und Autonome Systeme

FPU Floating Point Unit
ISR Interrupt Service Routine
LET Logical Execution Time
MPCP Modified Partial Critical Path

MPSoC Multi-Processor-System-On-Chips
NIT Network Idle Time
PCP Partial Critical Path
SCV Sensor Controlled Vehicle

SoC System-On-Chips
SymTA/S Symbolic Timing Analysis for Systems
TDL Timing Definition Language

TDMA Time Division Multiple Access
TIMMO Timing Model
ttAKS zeitgesteuertes Antikollisionssystem
TTP Time-Triggered Protocol
WCET Worst Case Execution Time

Literaturverzeichnis
[ADLINK 2007] ADLINK: GEME 2000 Datasheet. Internet Homepage. 05 2007
[Berkley 2008] U NIVERSITY OF B ERKLEY ; D EPARTMENT OF E LECTRICAL E NGINEE -

RING AND C OMPUTER S CIENCE: Webpage. 06 2008. – URL http://embedded.eecs.berke
ley.edu/giotto/
[Buttazzo 2004] B UTTAZZO, Giorgio C.: Hard Real-time Computing Systems: Predictable
Scheduling Algorithms And Applications (Real-Time Systems Series). Santa Clara, CA, USA :
Springer-Verlag TELOS, 2004. – ISBN 0387231374
[Cordes 2006] C ORDES, Stefan: Automatischer Bremsassistent auf Basis einer Laserscanner-
Abstandserfassung für ein fahrerloses Transportsystem, HAW Hamburg, Diplomarbeit, 2006
[DECOMSYS BUSDOCTOR 2006] DECOMSYS GmbH (Veranst.): DECOM-

SYS::BUSDOCTOR User Manual. 1.2. Apr 2006
[DECOMSYS COMMSTACK 2004] D IETACHMAYR, C.: DECOMSYS::COMM-

STACK<CONFIGURATOR> User Manual. Stumpergasse 48/28 1060 Wien Austria: DE-
COMSYS GmbH (Veranst.), 06 2004
[DECOMSYS COMMSTACK FR 2006] E GGENBAUER, Markus: DECOMSYS::COMM-

STACK<FLEXRAY> User Manual. Stumpergasse 48/28 1060 Wien Austria: DECOMSYS
GmbH (Veranst.), 03 2006
[DECOMSYS DESIGNER 2005] N OSSAL, R. ; N OWIKOW, K. ; P ESETA, H. ; S CHWAIGER,

E. ; S KOREPA, P.: DECOMSYS::DESIGNER 2.0 User Manual. Stumpergasse 48/28 1060
Wien Austria: DECOMSYS GmbH (Veranst.), 03 2005
[DECOMSYS GENERATOR 2005] M ÖLLER, W.: DECOMSYS::GENERATOR 2.2.8 User

Manual. Stumpergasse 48/28 1060 Wien Austria: DECOMSYS GmbH (Veranst.), 03 2005
[DECOMSYS StarterKit 2006] DECOMSYS: DECOMSYS::NODE<RENESAS> Starter-

Kit User Manual. 1.3. Stumpergasse 48/28 1060 Wien Austria: DECOMSYS GmbH (Ver-
anst.), Juli 2006
[EB 2007] E LEKTROBIT C ORPORATION: EB tresos Designer. 2007. – URL http://www.e

lektrobit.com/index.php?770
[Elektr. Automot. 2002] H EINECKE, Prof. H. ; S CHEDL, Dr. A.: FlexRay - ein Kommuni-
kationssystem für das Automobil der Zukunft. In: Elektronik Automotive September 2002
(2002), S. 36–45
[Eles u. a. 2000] E LES, P. ; D OBOLI, A. ; P OP, P. ; P ENG, Z.: Scheduling with Bus Access
Optimization for Distributed Embedded Systems. In: IEEE Transactions on VLSI Systems 8
(2000), oct, Nr. 5, S. 472–491. – URL http://www2.imm.dtu.dk/pubdb/p.php?4620
[ESLAB 2007] E MBEDDED S YSTEMS L AB ; U NIVERSITY L INKÖPING: Design Environ-

ment for Real-Time Embedded Systems in Control-Related Applications. 2007. – URL http:
//www.ida.liu.se/labs/eslab/new_research/design_control_related.shtml
[Farcas und Pree 2007] FARCAS, Claudio ; P REE, Wolfgang: A Determisistic Infrastructure
for Real-Time Distributed Systems. 2007
[Farcas u. a. 2005] FARCAS, Emilia ; FARCAS, Claudiu ; P REE, Wolfgang ; T EMPL, Josef:
Transparent distribution of real-time components based on logical execution time. In: SIG-
PLAN Not. 40 (2005), Nr. 7, S. 31–39. – ISSN 0362-1340
[FlexRay 2008] F LEX R AY C ONSORTIUM: FlexRay Website. Internet. 06 2008. – URL

www.flexray.com
[FlexRaySpec 2005] F LEX R AY C ONSORTIUM: FlexRay Communications Systems Protocol

Specification Version 2.1 Revision A, 2005
[GI 2006a] I NFORMATIK, Gesellschaft für ; H OCHBERGER, Christian (Hrsg.) ; L ISKOW-

SKY , Rüdiger (Hrsg.): Informatik 2006 - Informatik für Menschen, Band 1, Beiträge der 36.
Jahrestagung der Gesellschaft für Informatik e.V. (GI), 2.-6. Oktober 2006 in Dresden. 2006
[GI 2006b] S TEIN, Steffen ; H AMANN, Arne ; E RNST, Rolf ; H OCHBERGER, Christian
(Hrsg.) ; L ISKOWSKY, Rüdiger (Hrsg.): Real-time Management in Emergent Systems. 2006.
Siehe (GI, 2006a)
[Hamann u. a. 2006] H AMANN, A. ; R ACU, R. ; E RNST, R.: Formal Methods for Automotive
Platform Analysis and Optimization. In: Proc. Future Trends in Automotive Electronics and
Tool Integration Workshop (DATE Conference) (2006), März
[Hanser 2007] H ANSER V ERLAG: FlexRay ProductDay 2007. 11 2007. – URL http://w
ww.flexray-productday.de
[HAW 2008] HAW H AMBURG: SCV - Sensor Controlled Vehicle. Internet. 05 2008. – URL
http://www.informatik.haw-hamburg.de/scv.html
[Kopetz 1997] KOPETZ, Hermann: Real-Time Systems: Design Principles for Distributed
Embedded Applications. Norwell, MA, USA : Kluwer Academic Publishers, 1997. – ISBN
0792398947
[Lee und Parks 1995] L EE, Edward A. ; PARKS, Thomas M.: Dataflow process networks. In:
Proceedings of the IEEE, 1995, S. 773–799
[Marscholik und Subke 2007] M ARSCHOLIK, Christoph ; S UBKE, Peter: Datenkommunika-

tion im Automobil: Grundlagen, Bussysteme, Protokolle und Anwendungen. Hüthig Verlag,
2007. – ISBN 978-3-7785-2969-0
[Naderlinger u. a. 20–26 May 2007] NADERLINGER, A. ; P LETZER, J. ; P REE, W. ; T EM -

PL, J.: Model-Driven Development of FlexRay-Based Systems with the Timing Definition
Language (TDL). In: Software Engineering for Automotive Systems, 2007. ICSE Workshops
SEAS ’07. Fourth International Workshop on (20-26 May 2007), S. 1–6
[Pop u. a. 2004] P OP, P. ; E LES, P. ; P ENG, Z.: Analysis and Synthesis of Distributed Real-
Time Embedded Systems. Kluwer Academic Publishers, 2004. – URL http://www2.imm.d
tu.dk/pubdb/p.php?4600
[Pop u. a. 2006] P OP, Traian ; P OP, Paul ; E LES, Petru ; P ENG, Zebo ; A NDREI, Alexandru:
Timing Analysis of the FlexRay Communication Protocol. In: 18th Euromicro Conference
on Real-Time-System (ECRTS’06) 0 (2006), S. 203–216. – ISSN 1068-3070
[Pree 2007] P REE, Prof. Dr. W.: Die Zeit spielend im Griff. In: Elektronik automotive 4
(2007), S. 44–49. – URL http://preetec.com/fileadmin/docs/Technology_Further_Docs
/Zeit_spielend_im_Griff_April_2007.pdf
[Pröhl 2006] P RÖHL, Andreas: Automatischer Ausweichassistent auf Basis einer Laserscan-
ner-Abstandserfassung für ein fahrerloses Transportsystem, HAW Hamburg, Diplomarbeit,
10 2006
[QNX Software Systems 2008] QNX S OFTWARE S YSTEMS: QNX Neutrino RTOS. Internet
Homepage. 07 2008. – URL http://www.qnx.com/products/neutrino_rtos/
[Rausch 2008] R AUSCH, Dr.-Ing. M.: FlexRay. Carl Hanser Verlag München Wien, 2008. –
ISBN 978-3-446-41249-1
[Renesas HW-Man 2005] R ENESAS T ECHNOLOGY: M32C/85 Group (M32C/85,

M32C/85T) Hardware Manual. Juli 2005
[Schetler 2007] S CHETLER, Denis: Automatischer Ausweichassistent mit einer Laserscan-

ner-basierten Abstandsregelung für ein fahrerloses Transportsystem, HAW Hamburg, Di-
plomarbeit, 11 2007
[Sellentin 2006] S ELLENTIN, Jörn: Ein zeitgesteuertes, verteiltes SW-Konzept implementiert

auf FlexRay-Komponenten für ein fahrerloses Transportsystem, HAW Hamburg, Diplomar-
beit, 08 2006
[TIMMO 2008] S IEMENS ; U NIVERSITÄT PADERBORN: TIMMO - Timing Model. Web

Page. 06 2008. – URL http://www.c-lab.de/de/forschungsprojekte/timmo/index.html
[TU Braunschweig 2007] TU B RAUNSCHWEIG: Projekt SymTA/S / Institute of Computer

and Communication Network Engineering, Technical University of Braunschweig. URL
www.ida.ing.tu-bs.de/index.php?id=symtas, April 2007. – Forschungsbericht
[Xcelljournal 2008] S ABTARINI, Mike: Driver Assistance Revs Up On Xilinx FPGS Pla-
forms. In: Xcelljournal 66 (2008), Feb, S. 8–15
A Ergänzende Angaben zum
Software-Konzept für verteilte,
zeitgesteuerte Anwendungen
Hier werden Ergänzungen zum Software-Konzept aus Kapitel 5.1 dokumentiert.
A.1 Anwendungsmodellierung in einem Prozessgraphen
Die zu entwickelnde Anwendung wird als Prozessgraph modelliert. Dieser beschreibt die im
System vorhandenen Tasks und Abhängigkeiten zwischen den Tasks. Bei dem Graphen han-
delt es sich um einen erweiterten gerichteten azyklischen Graphen (DAG). Er beinhaltet die
Parameter, die der Scheduling-Algorithmus benötigt. Die Abb. A.1 zeigt einen Graphen einer
Anwendung.
Abb. A.1: Graph einer Anwendung [Sellentin (2006)]
Der Prozessgraph enthält folgende Elemente:

A Ergänzende Angaben zum Software-Konzept für verteilte, zeitgesteuerte Anwendungen 105
• Tasks werden durch Kästen gekennzeichnet, in denen deren Periode und die WCET auf-
geführt ist.
• Die Zuordnung der Tasks zu den Knoten wird durch die farbliche Kennzeichnung ver-
deutlicht.
• Abhängigkeiten zwischen den Tasks werden durch gerichtete Kanten dargestellt, wobei
die Richtung den Datenfluss angibt.
• Kanten, die eine zeitkritische Taskfolge beschreiben, werden Fett dargestellt. Solche
Taskfolgen sollen unmittelbar nacheinander abgearbeitet werden.
• Die Kommunikation zwischen Tasks wird als Aktivität auf dem Kommunikationsmedium
betrachtet und während des Schedulings wie Tasks auf einem Knoten behandelt.
• Tasks, die gleichzeitig auszuführen sind, werden durch ungerichtete Kanten miteinander
verbunden.
Der Graph wird genutzt, um eine erste Prüfung der zu entwickelnden Anwendung durchzu-
führen. Die Auslastung der Knoten und der längsten Pfad durch den Prozessgraphen werden
berechnet. Die Anwendung ist in den folgenden Fällen nicht planbar:
• Die Rechenzeit der eingeplanten Tasks ist länger als die Applikationsrunde.
• Der längste Pfad durch den Graphen ist länger als die Applikationsrunde.
• Der Graph enthält einen Zyklus.
• Es existiert eine Gleichzeitigkeitsbeziehung von Tasks auf dem selben Knoten.
A.2 Scheduling-Verfahren
Das Scheduling der Tasks wird in zwei Schritten vollzogen. Im ersten Schritt werden die Prio-
ritäten der Tasks berechnet und im zweiten ein Scheduling der Tasks an Hand der berechneten
Prioritäten durchgeführt. Zur Vorbereitung des Schedulings muss die Länge der Applikations-
runde berechnet und die Häufigkeit eines Tasks in einer Applikationsrunde durch deren Länge
bestimmt werden.
Als erstes werden die Prioritätslevel der Tasks berechnet:
• Hat ein Task keine Nachfolger, so entspricht der Prioriätslevel der WCET des Tasks.
• Besitzt ein Task Nachfolger, so entspricht der Prioritätslevel der eigenen WCET addiert
mit der maximalen WCET der direkten Nachfolge-Tasks. Tasks, die am Anfang einer
langen Taskfolge stehen, werden dadurch bevorzugt.
Abb. A.2: Ablaufplan des Scheduling-Verfahrens

• Der erste Task einer zeitkritischen Taskfolge erhält als Prioritätslevel die eigene WCET.
Die Einplanung der Taskfolge wird durch die niedrige Priorität spät durchgeführt.
• Alle anderen Tasks der zeitkritsichen Taskfolge erhalten als Prioritätslevel die Summe der
WCET aller Knoten der Taskfolge. Die Wahrscheinlichkeit einer zusammenhängenden
Ausführung wird dadurch erhöht.
Abb. A.3: Generiertes Task-Schedule zum Graphen aus Abb. A.1 (Sellentin (2006))
Sind die Prioritäten berechnet, wird das Scheduling durchgeführt. Schrittweise werden die plan-
baren Tasks für jeden Zeittick bestimmt. Tasks sind planbar, wenn sie keine Vorgänger haben
oder die Vorgänger-Tasks abgeschlossen sind, zeitgleiche Tasks auf den entsprechenden Knoten
planbar sind und für alle Vorkommen des Tasks ein Zeitschlitz auf dem zugeordneten Knoten
in der Größe der WCET verfügbar ist. Ist kein Zeitschlitz verfügbar und hat der dem Knoten
zugewiesene Task eine niedrigere Priorität, so kann der zugewiesene Task aus dem Plan entfernt
werden, um Platz für den höher priorisierten Task zu schaffen. Begonnen wird zu dem Zeitpunkt
Null. Aus den zur Verfügung stehenden Tasks wird die mit der höchsten Priorität ausgewählt
und eingeplant. Kann ein Task eingeplant werden, so wird ein Zeitschlitz vom aktuellen Zeittick
mit der Länge der WCET eingeplant. Bei periodischen Tasks werden die weiteren Instanzen des
Tasks entsprechend eingeplant. Der geplante Task wird aus der Liste der verfügbaren Tasks ent-
fernt. Anschließend werden die weiteren Tasks auf den anderen Ressourcen eingeplant. Gibt es
keine weiteren planbaren Tasks zu dem aktuellen Zeitpunkt, so wird der Zeittick inkrementiert
und der Vorgang wiederholt bis der vollständige Schedule erstellt ist. Die Abb. A.3 zeigt den
Schedule für den in Abb. A.1 dargestellten Graphen.
A.3 Ausgewählter Quellcode zum Softwarekonzept für

zeitgesteuerte Anwendungen
Quellcode A.1: Struktur der Dispatcher Tabelle

1 typedef struct
2 {
3 ISR_TaskTypeRef pTask;
4 TDDLL_TickType offset;
5 U8 period; /*in TDMA_ROUNDs*/
6 } ISR_DispatchTable;
Quellcode A.2: Struktur der Dispatcher Variablen Tabelle

1 typedef struct
2 {
3 TDDLL_TickType tickOffset;
4 U8 roundOffset;
5 } ISR_DispatchVar;
Quellcode A.3: Main-Prozedur

1 int main( void )
2 {
3 /* startup whole board
4 * We do this two times because sometimes
5 * the controller ignores the first configuartion attempt
.
6 */
7 ttStartupHook();
8 ttStartupHook();
9
10 /* init Dispatcher */
11 Init_ISR_Dispatcher();
12
13 /* the Idle-Task performs an endless loop */

14 ISR_Dispatcher_idle();
15
16 /**** we should never get here! ****/

17 ttShutdownHook( 0xAB );
18
19 return 0;
20
21 }
Quellcode A.4: Dispatcher-ISR

1 ISR_INT0( void )
2 {
3 /* dispatcher controlling variable */
4 TDDLL_TickType nNextDispatchEvent = 0;
5 static U16 nNextTableEntry = 0;
6 U16 nCurrentTableEntry = 0;
7
8 TDDLL_InterruptResetStatus(0, TDDLL_TIMER_INTERRUPT);
9 /* dispatch table handling */
10 nCurrentTableEntry = nNextTableEntry;
11
12 if (++nNextTableEntry == ISR_nDispatchTableNumEntries)
13 nNextTableEntry = 0;
14
15 while (ISR_aDispatchVarTable[nNextTableEntry].roundOffset >

0)
16 {
17 ISR_aDispatchVarTable[nNextTableEntry].roundOffset--;
nNextTableEntry = 0;
19 }
20
21 nNextDispatchEvent = ISR_aDispatchVarTable[nNextTableEntry
].tickOffset;
22
23 /* load timer register */

24 TDDLL_SetTimer(0, nNextDispatchEvent);
25
26 if(TDDLL_IsSync(0)) /* check if FlexRay Cluster is synchron

*/
27 {
28 static U16 nActivityLED = 0;
29
30 TDDLL_Online(0);
31
32 nActivityLED += nNextDispatchEvent;
33 if( nActivityLED >= US2TICKS( FR_CC_LED_FREQ ) )
34 {
35 dcsHALSetLED(FR_CC_LED, DCSHAL_LED_TOGGLE);
36 nActivityLED = 0;
37 }
38
39 dcsHALDebugpinHigh( RUNTASK_PIN );
40
41 /* execute task according to dispatching table */

42 (*ISR_aDispatchTable[nCurrentTableEntry].pTask)();
43
44 dcsHALDebugpinLow( RUNTASK_PIN );
45
46 /* calculate next round offset */

47 ISR_aDispatchVarTable[nCurrentTableEntry].roundOffset =
ISR_aDispatchTable[nCurrentTableEntry].period - 1;
48 }
49
50 else /* FlexRay Cluster is asynchron

*/
51
52 {
53 static U32 nStartupAttemptTime = 0;
54 U16 i = 0;
55
56 /*recalculate outer round Offset (roundOffset)*/

57 for(i = 0; i < ISR_nDispatchTableNumEntries; i++)
58 {
59 ISR_aDispatchVarTable[i].roundOffset =
ISR_aDispatchTable[i].offset / nDispatcherRound;
60 }
61
62 /* reset dispatcher */
64 while (ISR_aDispatchVarTable[nNextTableEntry].roundOffset
> 0)
65 {
67 nNextTableEntry++;
68 }
69
70 dcsHALDebugpinHigh( RUNTASK_PIN );
71
72 /* try startup every STARTUP_TIME */

73 nStartupAttemptTime += nNextDispatchEvent;
74 if( nStartupAttemptTime >= US2TICKS( STARTUP_TIME ) )
75 {
76 nStartupAttemptTime = 0;
77 TDDLL_Off(0);
78 TDDLL_On(0);
79
80 /* signal startup attempt with LED */

81 dcsHALSetLED(FR_CC_LED, DCSHAL_LED_ON);
82 dcsHALUDelay(50000);
83 dcsHALSetLED(FR_CC_LED, DCSHAL_LED_OFF);
85 dcsHALSetLED(FR_CC_LED, DCSHAL_LED_ON);
87 dcsHALSetLED(FR_CC_LED, DCSHAL_LED_OFF);
88 }
89
90 /* we have to set offline state */

91 TDDLL_Offline(0);
92
93 dcsHALDebugpinLow( RUNTASK_PIN );
94 }
95 }
Quellcode A.5: Init Dispatcher Prozedur

1 void Init_ISR_Dispatcher( void )
2 {
3 /*
4 * Main Clock is 24MHz (Crystal Frequency)
5 * In the Manual this clock is called ’f2n’=12MHz
6 * divide Main Clock by 12 (tcspr register) we get 1us as
timebase
7 */
8
9 U16 i = 0;
10
11 /*calculate inner round Offset (offset) & outer round

Offset (roundOffset)*/
12 for(i = 0; i < ISR_nDispatchTableNumEntries; i++)
13
14 {
15 ISR_aDispatchVarTable[i].roundOffset = ISR_aDispatchTable
[i].offset / nDispatcherRound;
16 ISR_aDispatchVarTable[i].tickOffset = ISR_aDispatchTable[
i].offset % nDispatcherRound;
17 }
18
19 /* reset dispatcher */
20 while (ISR_aDispatchVarTable[nFirstTableEntry].roundOffset
> 0)
21 {
22 ISR_aDispatchVarTable[nFirstTableEntry].roundOffset--;
23 nFirstTableEntry++;
24 }
25
26 /* global interrupt disable */

27 DISABLE_INTERRUPT;
28
29 TDDLL_InterruptEnable(0, TDDLL_GLOBAL_INTERRUPT);
30 TDDLL_InterruptEnable(0, TDDLL_TIMER_INTERRUPT);
31
32 rlvl = 0x07; /*Set Exit Level to 7*/

33
34 ps2_2 = 0;
35 int0ic = 0x05;
36 ir_int0ic = 0;
37
38 NOP;
39 NOP;
40
41 /* global interrupt enable */

42 ENABLE_INTERRUPT;
43
44 } /* eof Init_ISR_Dispatcher */
Quellcode A.6: Idle Prozedur

1 void ISR_Dispatcher_idle(void)
2 {
3 static int first = TRUE;
4
5 while(1)
6 {
7 APPL_TASK_ttIdleTask();
8
9 if ((first == TRUE) && TDDLL_IsSync(0))

10 {
11
12 first = FALSE;
13
14 TDDLL_InterruptEnable(0, TDDLL_GLOBAL_INTERRUPT);
15 TDDLL_InterruptEnable(0, TDDLL_TIMER_INTERRUPT);
16
17 TDDLL_SetTimer(0, ISR_aDispatchVarTable[nFirstTableEntry
].tickOffset);
18 }
19
20 IdleTaskSleep();
21 }
22 }
A.4 Ergänzende Angaben zur etAKS-Systemübersicht

B etAKS-Funktionen und deren
Quelldateien
Tabelle B.1: Quelldateien der ereignisgesteuerten AKS-Funktionen

Funktion Quelltext-Datei
Odometrie Odometrie\odometrie.c
Situationserfassung CA_System\LDcomm.c
Situationsanalyse & CA_System\CA_System.c
Aktionsentscheidung
Objekterkennung CA_System\Objekterkennung.c
Umgebunsanalyse CA_System\AusweichstatusAbstRegl.c
Entscheider-Automat CA_System\EntscheiderAbstRegl\
EntscheiderAbstReglFSM.c
Aktionsausführung CA_System\ AusweichenAbstRegl.c
C Timing-Messungen auf der
Zielplattform
C.1 Timing-Messungen von Berechnungsoperation auf der

Renesas-Plattform
(a) Addition von Gleitkommazahlen
(b) Addition von Ganzzahlen
Abb. C.1: Timing-Messungen der Addition von Gleitkommazahlen und Ganzzahlen bei 100
Wiederholungen
(a) Multiplikation von Gleitkommazahlen
(b) Multiplikation von Ganzzahlen
Abb. C.2: Timing-Messungen der Multiplikation von Gleitkommazahlen und Ganzzahlen bei
100 Wiederholungen
(a) Division von Gleitkommazahlen
(b) Division von Ganzzahlen
Abb. C.3: Timing-Messung der Division von Gleitkommazahlen und Ganzzahlen bei 100 Wie-
derholungen
(a) Sinus-Funktion mit Berechnung
(b) Sinus-Funktion mit Wertetabelle
Abb. C.4: Timing-Messungen der Sinusfunktion als Berechnung und Wertetabelle bei 100 Wie-
derholungen
(a) Cosinus-Funktion mit Berechnung
(b) Cosinus-Funktion mit Wertetabelle
Abb. C.5: Timing-Messungen der Cosinusfunktion als Berechnung und Wertetabelle bei 100
Wiederholungen
D Ergänzungen zur Modellierung des
ttAKS
D.1 Modellierungsansatz 3 für die

Gleichzeitigkeitsbeziehungen in der Antriebsregelung
An dieser Stelle wird eine dritte Variante zur Modellierung der Gleichzeitigkeitsbeziehung der
Tasks zur Antriebsregelung dargestellt (vgl. Kapitel 7.1.1). Im dritten Ansatz werden die Einzel-
schritte Messen, Regeln, Stellen nacheinander abgearbeitet, wobei die Tasks für die Parameter
parallel auf beiden Knoten eingeplant sind (Abb. D.1a). Der Graph wird nach jeder Funktion
zusammengeführt, wodurch z. B. das Regeln erst dann begonnen wird, wenn alle Tasks zum
Messen abgeschlossen sind.
Die Abb. D.1a zeigt den generierten Schedule mit einer Länge von 5032 µs. In diesem Graphen
werden die Tasks zum Stellen wie gewünscht parallel ausgeführt. Beim Messen werden zwei
Tasks gleichzeitig ausgeführt. Hierbei werden das Messen von Lenkwinkel und Geschwindig-
keit parallel ausgeführt. Da die Tasks die gleiche Länge besitzen, würde ein manuelles Tauschen
vor der Implementierung das gewünschte Verhalten herstellen.
(a) CPG mit zugeordneten Tasks und deren WCET in µs inkl.

Prozess- und Astnummer im Scheduling-Algorithmus
Abb. D.1: CPG und Schedule zur Geschwindindigkeits- und Lenkwinkelregelung (Modellie-
rungsansatz 3)
D.2 Timing-Messungen der ttAKS-Funktionen

(a) Odometriefunktion ohne Optimierung
(b) Optimierte Odometriefunktion
Abb. D.2: Timing-Messungen der Odometrie-Funktion vor und nach der Optimierung
(a) Reset-Funktion
(b) Achswinkelsetzen-Funktion
Abb. D.3: Timing-Messungen der Reset- und Achswinkelsetzen-Funktion der Odometrie

Abb. D.4: Timingmesseung zur Situationsanalyse
Abb. D.5: Timingmessung zur Objekterkennung

Abb. D.6: Timingmessung zur Umgebungsanalyse
Abb. D.7: Timingmessung zur Aktionsentscheidung

Abb. D.8: Timingmessung zur Aktionsausführung

D.3 Timing-Messung ISR-Dispatcher
Die Ausführungszeit des zeitgesteuerten Dispatchers, der in einer ISR ausgeführt wird, ist in
der Abb. D.9 dargestellt. In der Grafik ist die erste abfallende Flanke der Eintritt in die ISR.
Die darauf folgende steigende Flanke ist der Beginn der Taskausführung, der mit der fallenden
Flanke beendet wird. Die darauf folgende steigende Flanke beendet die ISR. Die Ausführungs-
zeit der ISR vor der Taskausführung beträgt ca. 20,8 µs, während die Zeit nach der Task ca. 0,7
µs beträgt.
Abb. D.9: Ausführungszeit des Dispatcher in der Interupt-Service-Routine
D.4 CAN-Trace der Messwerterfassung vom Laserscanner

D Ergänzungen zur Modellierung des ttAKS
Tabelle D.1: CAN-Trace Kommunikation zwischen Laserscanner und µC
t [s] ∆t [ms] ID DLC Daten Nachricht
1,2365 - 2A8 8 FF FF 00 02 00 DF 04 01 Reset Anforderung
1,2443 7,8 2A8 4 00 01 00 02
2,2750 1030,7 4DF 8 00 00 00 00 84 01 00 02 Reset Antwort
3,5142 1239,2 2A8 6 00 00 00 DF 04 02 Trans Idle Mode Anforderung
3,5148 0,6 4DF 8 FF FF 00 02 00 00 84 02 Trans Idle Mode Antwort
3,5152 0,4 4DF 6 00 01 00 00 00 01
3,5238 8,6 2A8 8 FF FF 00 02 00 DF 04 03 Trans Rotate Mode Anfoderung
3,5278 4,0 2A8 4 00 01 00 00
10,7779 7250,1 4DF 8 FF FF 00 02 00 00 84 03 Trans Rotate Mode Antwort
10,7783 0,4 4DF 6 00 01 00 00 00 02
12,7939 2015,6 2A8 6 00 00 00 DF 04 04 Trans Measure Mode Anforderung
12,7945 0,6 4DF 8 FF FF 00 02 00 00 84 04 Trans Measure Mode Antwort
12,7950 0,5 4DF 8 00 01 00 00 00 03 00 00
12,8390 44,0 2A8 8 FF FF 00 02 00 DF 03 01 Measurement Service Anforderung
12,8424 3,4 2A8 6 00 01 00 01 01 01
14,0550 1212,6 4DF 8 FF FF 00 3F 00 00 83 01 Messwerte: Nachricht 1
14,0555 0,5 4DF 8 00 3E 01 01 01 02 00 00
14,0560 0,5 4DF 8 00 3D 00 88 00 84 00 7F
14,0565 0,5 4DF 8 00 3C 00 7A 00 76 00 70
14,0570 0,5 4DF 8 00 3B 00 67 00 6C 00 66
14,0574 0,4 4DF 8 00 3A 00 66 00 63 00 5E
14,0579 0,5 4DF 8 00 39 00 5A 00 58 00 59
14,0584 0,5 4DF 8 00 38 00 55 00 50 00 52
14,0589 0,5 4DF 8 00 37 00 50 00 4D 00 4B
14,0594 0,5 4DF 8 00 36 00 4B 00 4A 00 49
14,0599 0,5 4DF 8 00 35 00 45 00 45 00 47
14,0604 0,5 4DF 8 00 34 00 44 00 43 00 40
14,0609 0,5 4DF 8 00 33 00 3E 00 3A 00 3F
129
∆t [ms]

t [s] ID DLC Daten Nachricht
14,0614 0,5 4DF 8 00 32 00 3D 00 3F 00 37
14,0619 0,5 4DF 8 00 31 00 3E 00 3E 00 3A
14,0624 0,5 4DF 8 00 30 00 39 00 3A 00 3A
14,0629 0,5 4DF 8 00 2F 00 3A 00 39 00 34
14,0634 0,5 4DF 8 00 2E 00 31 00 37 00 35
14,0639 0,5 4DF 8 00 2D 00 36 00 37 00 35
14,0644 0,5 4DF 8 00 2C 00 30 00 35 00 3A
14,0649 0,5 4DF 8 00 2B 00 33 00 34 00 34
14,0654 0,5 4DF 8 00 2A 00 36 00 34 00 37
14,0659 0,5 4DF 8 00 29 00 34 00 35 00 35
14,0664 0,5 4DF 8 00 28 00 33 00 36 00 34
14,0669 0,5 4DF 8 00 27 00 30 00 2E 00 34
14,0674 0,5 4DF 8 00 26 00 2E 00 2B 00 34
14,0679 0,5 4DF 8 00 25 00 33 00 32 00 35
14,0684 0,5 4DF 8 00 24 00 33 00 34 00 35
14,0689 0,5 4DF 8 00 23 00 33 00 32 00 36
14,0694 0,5 4DF 8 00 22 00 35 00 2E 00 30
14,0699 0,5 4DF 8 00 21 00 31 00 37 00 31
14,0704 0,5 4DF 8 00 20 00 35 00 34 00 36
14,0709 0,5 4DF 8 00 1F 00 37 00 30 00 39
14,0714 0,5 4DF 8 00 1E 00 37 00 35 00 34
14,0719 0,5 4DF 8 00 1D 00 3A 00 3A 00 37
14,0724 0,5 4DF 8 00 1C 00 3D 00 3A 00 3F
14,0729 0,5 4DF 8 00 1B 00 3C 00 3E 00 40
14,0734 0,5 4DF 8 00 1A 00 3E 00 41 00 40
14,0739 0,5 4DF 8 00 19 00 45 00 3F 00 3C
14,0744 0,5 4DF 8 00 18 00 44 00 44 00 49
14,0749 0,5 4DF 8 00 17 00 45 00 47 00 4B
14,0754 0,5 4DF 8 00 16 00 4A 00 4D 00 4C
130
14,0759 0,5 4DF 8 00 15 00 50 00 51 00 53
∆t [ms]

t [s] ID DLC Daten Nachricht
14,0764 0,5 4DF 8 00 14 00 58 00 56 00 58
14,0769 0,5 4DF 8 00 13 00 57 00 62 00 64
14,0774 0,5 4DF 8 00 12 00 64 00 6A 00 6F
14,0779 0,5 4DF 8 00 11 00 6E 00 75 00 78
14,0784 0,5 4DF 8 00 10 00 7F 00 85 00 88
14,0789 0,5 4DF 8 00 0F 00 8C 00 93 00 9A
14,0794 0,5 4DF 8 00 0E 00 A2 00 AB 00 B6
14,0799 0,5 4DF 8 00 0D 00 BD 00 A9 00 C1
14,0804 0,5 4DF 8 00 0C 00 F4 01 07 00 D6
14,0809 0,5 4DF 8 00 0B 00 BC 00 BB 00 CB
14,0814 0,5 4DF 8 00 0A 00 D7 00 D4 00 DD
14,0819 0,5 4DF 8 00 09 00 D4 00 D0 00 D0
14,0824 0,5 4DF 8 00 08 00 D6 00 DA 00 CF
14,0829 0,5 4DF 8 00 07 00 D6 00 D8 00 D5
14,0834 0,5 4DF 8 00 06 00 D4 04 6C 04 6B
14,0838 0,4 4DF 8 00 05 04 71 04 74 04 76
14,0843 0,5 4DF 8 00 04 04 7F 04 7C 02 D9
14,0848 0,5 4DF 8 00 03 03 2C 03 D8 03 CB
14,0853 0,5 4DF 8 00 02 03 B7 02 AF 02 D1
14,0857 0,4 4DF 4 00 01 02 E5 Messwerte: Nachricht 63
131
E Ergänzung zur Implementation des
ttAKS
E.1 CPG zur kompletten Anwendungsrunde des ttAKS
Dieses Kapitel enthält die CPGs zur kompletten Anwendungsrunde des ttAKS. Der Graph ist
zur besseren Lesbarkeit in zwei Teile aufgeteilt (Abb. E.1 und Abb. E.2. Am oberen und un-
teren Ende befinden sich die Quellen- und Senken-Knoten, die aufgrund des breiten Graphens
dupliziert wurden.
E Ergänzung zur Implementation des ttAKS
133
Abb. E.1: CPG zum kompletten ttAKS für die gesamte Anwendungsrunde Teil 1: Situationserfassung und Objekterkennung
E Ergänzung zur Implementation des ttAKS
134
Abb. E.2: CPG zum kompletten ttAKS für die gesamte Anwendungsrunde Teil 2: Antriebssteuerung und Tasks mit einer Periode von 500 ms
E.2 Ausgewählter Quelltext zur Dispatcher-Erweiterung
Quellcode E.1: Struktur der um Konditionen erweiterten Dispatcher Tabelle

1
2 typedef struct{
3 ISR_TaskTypeRef pTask;
4 TDDLL_TickType offset;
5 U8 period; /*in TDMA_ROUNDs*/
6 U8 condition; /* condition */
7
8 } ISR_DispatchTable;
Quellcode E.2: Ausschnitt aus der Dispatcher-ISR zur Suche nach dem nächsten auszuführen-
den Task unter Berücksichtigung von Konditionen
1
2 while (!cond_check_ok){
3 while (ISR_aDispatchVarTable[nNextTableEntry].roundOffset >
0) {
7 }
8 // Task zur Ausführung gefunden -> condition prüfen
9 cond_check_ok = check_cond(ISR_aDispatchVarTable[
nNextTableEntry].condition);
10 // wenn Kondition nicht erfüllt -> Task-Perioden-Reset
11 if (!cond_check_ok){
12 ISR_aDispatchVarTable[nNextTableEntry].roundOffset =
13 ISR_aDispatchTable[nNextTableEntry].period - 1;
14 }
15 }
Quellcode E.3: Funktion zum Hinzufügen von Konditionen

1
2 void add_cond(unsigned char condition){

3 known_conditions += condition;
4 }
Quellcode E.4: Funktion zum Entfernen von Konditionen

1
2 void rem_cond(unsigned short condition){

3 known_conditions -= condition;
4 }
Quellcode E.5: Funktion zur Prüfung von Konditionen

1
2 unsigned char check_cond(unsigned char task_cond){

3 if (task_coond == 0) // No Condition
4 return 1;
5 else if (task_cond > 0) // Condition positiv
6 return (known_conditions & task_cond);
7 else // negative condition
8 return ! (known_conditions & task_cond)
9 }
Quellcode E.6: Synchronisation zum gemeinsamen Start der Anwendungsrunde (Ausschnitt

aus der Dispatcher-Idle-Funktion)
1
2 while (!TDDLL_IsSync(0));
3
4 TDDLL_Online(0);
5 send_sync();
6 while(!(node_sync && TDDLL_GetCycle(0) == 63) ){
7 if (!node_sync && receive_sync())
8 node_sync = 1;
9 }
10 TDDLL_Offline(0);
F Daten zum Schedulings des ttAKS
Tabelle F.1: Übersicht der FlexRay-Nachrichten und deren Größe

Nachricht Datengröße Anzahl 32-Bit-Nachrichten
V Ist Vorne 16 Bit 1
Phi Ist Vorne 16 Bit 1
Stellgröße V Vorne 16 Bit 1
Stellgröße Phi Vorne 16 Bit 1
Soll-Werte Führ /Komm 32 Bit 1
Fahrzeug Ist-Werte 32 Bit 1
Objektdaten 256 Bit 8
Manöver-Kondition 8 Bit 1
Tabelle F.2: Übersicht zu den wesentlichen Parametern des FlexRay-Netzwerks im ttAKS

Parameter Einstellung
Länge der TDMA-Runde 10000 µs
Nutzdatenlänge 2 16-Bit-Words
Anzahl statischer Slots 328
Länge eines statischen Slots 30 Macroticks
Länge der Network Idle Time 180 Macroticks
Länge eines Macroticks 1 µs
Tabelle F.3: Dispatcher Tabelle für den Knoten Renesas Vorne

Task Aktivierungszeitpunkt in µs WCET Kondition
SE1 0 275 -
MVV1 275 55 -
ESF 330 75 FB
ESK 330 75 not FB
SVA 405 55 -
SE2 500 275 -
SVV1 775 70 -
MPV1 845 55 -
SIV 900 80 -
SE3 1000 275 -
SIH 1275 80 -
SE4 1500 275 -
SPV1 1775 70 -
SE5 2000 275 -
SE6 2500 275 -
SE7 3000 275 -
SE8 3500 275 -
SE9 4000 275 -

SE10 4500 275 -
SE11 5000 275 -
SE12 5500 275 -
SFI 5775 75 not Man
SE13 6000 275 -
SE14 6500 275 -
SE15 7000 275 -
SE16 7500 275 -
SE17 8000 275 -
SE18 8500 275 -
SE19 9000 275 -
SE20 9500 275 -
SE21 10000 275 -
SE22 10500 275 -
SE23 11000 275 -
SE24 11500 275 -
SE25 12000 275 -
SE26 12500 275 -
SE27 13000 275 -
SFI 13275 75 Man
SE28 13500 275 -
SE29 14000 275 -
SE30 14500 275 -
SE31 15000 275 -
SE32 15500 275 -
SE33 16000 275 -
SE34 16500 275 -
SE35 17000 275 -
SE36 17500 275 -
SE37 18000 275 -
SE38 18500 275 -
SE39 19000 275 -
SE40 19500 275 -
SE41 20000 275 -
SE42 20500 275 -
SE43 21000 275 -
SE44 21500 275 -
SE45 22000 275 -
SE46 22500 275 -
SE47 23000 275 -
SE48 23500 275 -
SE49 24000 275 -
SE50 24500 275 -
SE51 25000 275 -
SE52 25500 275 -
SE53 26000 275 -
SE54 26500 275 -
SE55 27000 275 -
SE56 27500 275 -

SE57 28000 275 -
SE58 28500 275 -
SE59 29000 275 -
SE60 29500 275 -
SE61 30000 275 -
SE62 30500 275 -
SE63 31000 275 -
SE64 31500 275 -
SE65 32000 275 -
SE66 32500 275 -
SE67 33000 275 -
SE68 33500 275 -
SE69 34000 275 -
SE70 34500 275 -
SE71 35000 275 -
SE72 35500 275 -
SE73 36000 275 -
SE74 36500 275 -
SE75 37000 275 -
SE76 37500 275 -
SE77 38000 275 -
SE78 38500 275 -
SE79 39000 275 -
SE80 39500 275 -
SE81 40000 275 -
SE82 40500 275 -
SE83 41000 275 -
SE84 41500 275 -
SE85 42000 275 -
SE86 42500 275 -
SE87 43000 275 -
SE88 43500 275 -
SE89 44000 275 -
SE90 44500 275 -
SE91 45000 275 -
SE92 45500 275 -
SE93 46000 275 -
SE94 46500 275 -
SE95 47000 275 -
SE96 47500 275 -
SE97 48000 275 -
SE98 48500 275 -
SE99 49000 275 -
SE100 49500 275 -
MVV2 50000 55 -
SVV2 50600 70 -
MPV2 50670 55 -
SPV2 51380 70 -
OE1 51450 48550 -

MVV3 100000 55 -
SVV3 100600 70 -
MPV3 100670 55 -
SPV3 101380 70 -
OE2 101450 48550 -
MVV4 150000 55 -
SVV4 150600 70 -
MPV4 150670 55 -
SPV4 151380 70 -
OE3 151450 48550 -
MVV5 200000 55 -
SVV5 200600 70 -
MPV5 200670 55 -
SPV5 201380 70 -
OE4 201450 48550 -
MVV6 250000 55 -
SVV6 250600 70 -
MPV6 250670 55 -
SPV6 251380 70 -
OE5 251450 48550 -
MVV7 300000 55 -
SVV7 300600 70 -
MPV7 300670 55 -
SPV7 301380 70 -
OE6 301450 48550 -
MVV8 350000 55 -
SVV8 350600 70 -
MPV8 350670 55 -
SPV8 351380 70 -
OE7 351450 48550 -
MVV9 400000 55 -
SVV9 400600 70 -
MPV9 400670 55 -
SPV9 401380 70 -
OE8 401450 48550 -
MVV10 450000 55 -
SVV10 450600 70 -
MPV10 450670 55 -
SPV10 451380 70 -
OE9 451450 48550 -
Tabelle F.4: Dispatcher Tabelle für den Knoten Renesas Hinten

MVH1 0 55 -
RVH1 55 250 -
RVV1 360 250 -
SVH1 540 70 -
SHA 610 55 -

EF 720 75 -
MPH1 845 55 -
RPH1 900 250 -
RPV1 1150 250 -
SPH1 1440 70 -
UA 1510 7225 Man
OD 1510 3625 not Man
KO 5135 525 not Man
OD 8735 3625 Man
KO 12360 525 Man
AE 12885 95 Man
AA 12980 3125 Man
OR 16105 75 Man, Rst
OA 16105 50 Man, not Rst, AwS
OA 16180 50 Man, Rst, AwS
DUM 20000 0 -
DUM 30000 0 -
DUM 40000 0 -
MVH2 50000 55 -
RVH2 50055 250 -
RVV2 50305 250 -
SVH2 50600 70 -
MPH2 50670 55 -
RPH2 50725 250 -
RPV2 50975 250 -
SPH2 51380 70 -
DUM 60000 0 -
DUM 70000 0 -
DUM 80000 0 -
DUM 90000 0 -
MVH3 100000 55 -
RVH3 100055 250 -
RVV3 100305 250 -
SVH3 100600 70 -
MPH3 100670 55 -
RPH3 100725 250 -
RPV3 100975 250 -
SPH3 101380 70 -
DUM 110000 0 -
DUM 120000 0 -
DUM 130000 0 -
DUM 140000 0 -
MVH4 150000 55 -
RVH4 150055 250 -
RVV4 150305 250 -
SVH4 150600 70 -
MPH4 150670 55 -
RPH4 150725 250 -
RPV4 150975 250 -

SPH4 151380 70 -
DUM 160000 0 -
DUM 170000 0 -
DUM 180000 0 -
DUM 190000 0 -
MVH5 200000 55 -
RVH5 200055 250 -
RVV5 200305 250 -
SVH5 200600 70 -
MPH5 200670 55 -
RPH5 200725 250 -
RPV5 200975 250 -
SPH5 201380 70 -
DUM 210000 0 -
DUM 220000 0 -
DUM 230000 0 -
DUM 240000 0 -
MVH6 250000 55 -
RVH6 250055 250 -
RVV6 250305 250 -
SVH6 250600 70 -
MPH6 250670 55 -
RPH6 250725 250 -
RPV6 250975 250 -
SPH6 251380 70 -
DUM 260000 0 -
DUM 270000 0 -
DUM 280000 0 -
DUM 290000 0 -
MVH7 300000 55 -
RVH7 300055 250 -
RVV7 300305 250 -
SVH7 300600 70 -
MPH7 300670 55 -
RPH7 300725 250 -
RPV7 300975 250 -
SPH7 301380 70 -
DUM 310000 0 -
DUM 320000 0 -
DUM 330000 0 -
DUM 340000 0 -
MVH8 350000 55 -
RVH8 350055 250 -
RVV8 350305 250 -
SVH8 350600 70 -
MPH8 350670 55 -
RPH8 350725 250 -
RPV8 350975 250 -
SPH8 351380 70 -

DUM 360000 0 -
DUM 370000 0 -
DUM 380000 0 -
DUM 390000 0 -
MVH9 400000 55 -
RVH9 400055 250 -
RVV9 400305 250 -
SVH9 400600 70 -
MPH9 400670 55 -
RPH9 400725 250 -
RPV9 400975 250 -
SPH9 401380 70 -
DUM 410000 0 -
DUM 420000 0 -
DUM 430000 0 -
DUM 440000 0 -
MVH10 450000 55 -
RVH10 450055 250 -
RVV10 450305 250 -
SVH10 450600 70 -
MPH10 450670 55 -
RPH10 450725 250 -
RPV10 450975 250 -
SPH10 451380 70 -
DUM 460000 0 -
DUM 470000 0 -
DUM 480000 0 -
DUM 490000 0 -
Tabelle F.5: Nachrichten-Schedule der ttAKS-Nachrichten

Nachricht TDMA-Runde Slot
Objektdaten 1 1 1
Objektdaten 2 1 2
Objektdaten 3 1 3
Objektdaten 4 1 4
Objektdaten 5 1 5
Objektdaten 6 1 6
Objektdaten 7 1 7
Objektdaten 8 1 8
V Ist Vorne 1 1 12
Soll-Werte Komm/Führ 1 14
Stellwert V Vorne 1 1 18
Phi Ist Vorne 1 1 31
Stellwert Phi Vorne 1 1 48
Fahrzeug Ist-Werte 1 190
Fahrzeug Ist-Werte 2 98
V Ist Vorne 2 6 3
Nachricht TDMA-Runde Slot

V Ist Vorne 3 11 3
V Ist Vorne 4 16 3
V Ist Vorne 5 21 3
V Ist Vorne 6 26 3
V Ist Vorne 7 31 3
V Ist Vorne 8 36 3
V Ist Vorne 9 41 3
V Ist Vorne 10 46 3
G Timing-Messungen der
ttAKS-Kommunikation über FlexRay
Zur Timing-Messungen der ttAKS-Kommunikation wurde eine Nachrichtensequenz mit dem

DECOMSYS::BUSDOCTOR aufgenommen. Es werden folgende Tabellen dargestellt:
• Tabelle G.1 zeigt eine Aufzeichnung der im Protokoll integrierten FlexRay-Knoten-

Synchronisation.
• Tabelle G.2 dokumentiert die Nachrichten, die zur Synchronisation der ttAKS-
Anwendungsrunde von den beiden FlexRay-Knoten gesendet werden. Der Start der
Anwendungsrunde beginnt in der ersten TDMA-Runde mit dem Index 0.
• Tabelle G.3 zeigt die Kommunikation in der ersten TDMA-Runde, die gleichzeitig der
Start der Anwendungsrunde ist.
• Tabelle G.4 dokumentiert die hinzugekommen Nachrichten in der zweiten TDMA-Runde
• Tabelle G.5 listet die Nachrichten in der 6. TDMA-Runde auf, die gleichzeitig der Anfang
der zweiten 50-ms-Periode ist.
• Tabelle 8.1 aus Kapitel 8.1 zeigt die Kommunikation aus der 51. TDMA-Runde, die
gleichzeitig der Beginn der zweiten Anwendungsrunde ist.
Die Nachrichtensequenzen der folgenden Tabellen wurden auf diese wesentlichen Parameter
reduziert:
• ID: Frame-ID der Nachricht
• Ch: FlexRay-Kanal, über den die Nachricht empfangen wurde
• Time: relative Zeit des BusDoctors in Sekunden
• Cycle: Nummer der TDMA-Runde
• NFI: NullFrame-Indikator - eine 0 gibt an, dass ein Nullframe empfangen wurde
• Daten: Nutzdaten des Frames in hexadezimalen Zahlen
• Nachricht: Nachrichtenbezeichnung des ttAKS
• Sende-Task: Task, der die Nachricht erzeugt hat

G Timing-Messungen der ttAKS-Kommunikation über FlexRay 146
• Empfangs-Task: Task, der die Nachricht empfängt

G Timing-Messungen der ttAKS-Kommunikation über FlexRay
Tabelle G.1: Nachrichtensequenz der FlexRay-Knoten-Synchronisation
ID Ch Time[s] Cycle NFI Daten[hex] Nachricht Sende-Task Empfangs-Task
48 B 0,008965275 34 0 00000000
48 A 0,008965300 34 0 00000000
48 A 0,028964400 36 0 00000000
48 B 0,028964400 36 0 00000000
48 A 0,038963975 37 0 00000000
48 B 0,038963975 37 0 00000000
48 A 0,048963525 38 0 00000000
48 B 0,048963525 38 0 00000000
48 A 0,058963100 39 0 00000000
48 B 0,058963100 39 0 00000000
48 A 0,068962650 40 0 00000000
48 B 0,068962650 40 0 00000000
48 A 0,088961775 42 0 00000000
48 B 0,088961775 42 0 00000000
48 A 0,098961325 43 0 00000000
48 B 0,098961325 43 0 00000000
48 A 0,108960900 44 0 00000000
48 B 0,108960900 44 0 00000000
48 A 0,118960450 45 0 00000000
48 B 0,118960450 45 0 00000000
26 A 0,128300000 46 0 00000000
26 B 0,128300000 46 0 00000000
48 A 0,128960025 46 0 00000000
48 B 0,128960025 46 0 00000000
26 A 0,138299575 47 0 00000000
26 B 0,138299575 47 0 00000000
48 A 0,138959575 47 0 00000000
48 B 0,138959575 47 0 00000000
147
18 A 0.148059150 48 0 00000000
20 A 0,148119150 48 0 00000000
26 A 0,148299150 48 0 00000000
26 B 0,148299150 48 0 00000000
46 A 0,148899125 48 0 00000000
48 B 0,148959100 48 0 00000000
48 A 0,148959125 48 0 00000000
98 A 0,150459050 48 0 00000000
190 A 0,153218925 48 0 00000000
205 A 0,153668900 48 0 00000000
148
Tabelle G.2: Nachrichtensequenz der ttAKS-Synchronisation zum gemeinsamen Start der Anwendungsrunde
1 A 1,877473200 29 0 00000000
2 A 1,877503200 29 0 00000000
3 A 1,877533200 29 0 00000000
4 A 1,877563200 29 0 00000000
5 A 1,877593200 29 0 00000000
6 A 1,877623200 29 0 00000000
7 A 1,877653175 29 0 00000000
8 A 1,877683175 29 0 00000000
12 A 1,877803175 29 0 00000000
14 A 1,877863175 29 0 00000000
18 A 1,877983150 29 1 00000001 Sync-Signal Hinten - -
20 A 1,878043150 29 0 00000000
26 A 1,878223150 29 0 00000000
26 B 1,878223175 29 0 00000000
31 A 1,878373150 29 0 00000000
31 B 1,878373150 29 0 00000000
46 A 1,878823125 29 0 00000000
48 A 1,878883125 29 0 00000000
48 B 1,878883125 29 0 00000000
98 A 1,880383050 29 0 00000000
190 A 1,883142925 29 0 00000000
205 A 1,883592900 29 0 00000000
1 A 2,757434525 53 1 00000001 Sync-Signal Vorne - -
2 A 2,757464525 53 0 00000000
3 A 2,757494525 53 0 00000000
4 A 2,757524525 53 0 00000000
5 A 2,757554525 53 0 00000000
6 A 2,757584525 53 0 00000000
149
7 A 2,757614525 53 0 00000000
8 A 2,757644525 53 0 00000000
12 A 2,757764525 53 0 00000000
14 A 2,757824525 53 0 00000000
18 A 2,757944500 53 1 00000001
20 A 2,758004500 53 0 00000000
26 A 2,758184500 53 0 00000000
26 B 2,758184500 53 0 00000000
31 A 2,758334500 53 0 00000000
31 B 2,758334500 53 0 00000000
46 A 2,758784450 53 0 00000000
48 A 2,758844450 53 0 00000000
48 B 2,758844450 53 0 00000000
98 A 2,760344400 53 0 00000000
190 A 2,763104275 53 0 00000000
205 A 2,763554250 53 0 00000000
150
Tabelle G.3: Nachrichtensequenz der ersten TDMA-Runde des ttAKS, Beginn der ersten Anwendungsrunde
1 A 2,867429700 0 1 00000001
2 A 2,867459700 0 0 00000000
3 A 2,867489700 0 0 00000000
4 A 2,867519700 0 0 00000000
5 A 2,867549700 0 0 00000000
6 A 2,867579700 0 0 00000000
7 A 2,867609700 0 0 00000000
8 A 2,867639700 0 0 00000000
12 A 2,867759700 0 1 0b000000 V Ist Vorne 1 Messe Regel
V Vorne V Vorne
14 A 2,867819675 0 1 09000000 Sollwerte Empfange Soll Regel V/Phi
Komm-Server Komm-Server Vorne/Hinten
18 A 2,867939675 0 1 0c000000 Stellwert Regel Stelle
20 A 2,867999675 0 0 00000000
26 A 2,868179675 0 0 00000000
26 B 2,868179675 0 0 00000000
31 A 2,868329675 0 1 0a000000 Phi Ist Vorne 1 Messe Regel
Phi Vorne Phi Vorne
46 A 2,868779625 0 0 00000000
48 A 2,868839625 0 1 0d000000 Stellwert Regel Stelle
48 B 2,868839625 0 1 0d000000 Stellwert Regel Stelle
98 A 2,870339550 0 0 00000000
190 A 2,873099450 0 0 00000000
205 A 2,873549425 0 0 00000000
151
Tabelle G.4: Nachrichtensequenz der zweiten TDMA-Runde des ttAKS
1 A 2,877429275 1 1 00000001
2 A 2,877459275 1 0 00000000
3 A 2,877489275 1 0 00000000
4 A 2,877519275 1 0 00000000
5 A 2,877549275 1 0 00000000
6 A 2,877579275 1 0 00000000
7 A 2,877609250 1 0 00000000
8 A 2,877639250 1 0 00000000
12 A 2,877759250 1 1 0b000000
14 A 2,877819250 1 1 09000000
18 A 2,877939225 1 1 0c000000
20 A 2,877999225 1 0 00000000
26 A 2,878179225 1 0 00000000
26 B 2,878179250 1 0 00000000
31 A 2,878329225 1 1 0a000000
46 A 2,878779200 1 0 00000000
48 B 2,878839175 1 1 0d000000
48 A 2,878839200 1 1 0d000000
98 A 2,880339125 1 1 0e000000 Fahrzeug Koordinierung Sende Fahrzeug
Ist-Werte Ist-Werte
190 A 2,883099000 1 0 00000000
205 A 2,883548975 1 1 0f000000 Manöver Aktionsausführung Sende Fahrzeug
Kondition Ist-Werte
152
Tabelle G.5: Nachrichtensequenz der sechsten TDMA-Runde des ttAKS, Beginn der zweiten 50-ms-Periode
1 A 2,917427525 5 1 00000001
2 A 2,917457525 5 0 00000000
3 A 2,917487525 5 1 0b000001 V Ist Vorne 2 Messe Regel
V Vorne V Vorne
4 A 2,917517500 5 0 00000000
5 A 2,917547500 5 0 00000000
6 A 2,917577500 5 0 00000000
7 A 2,917607500 5 0 00000000
8 A 2,917637500 5 0 00000000
12 A 2,917757500 5 1 0b000000
14 A 2,917817500 5 1 09000000
18 A 2,917937475 5 1 0c000000
20 A 2,917997475 5 1 0c000001 Stellwert Regel Stelle
26 A 2,918177475 5 1 0a000001 Phi Ist Vorne 2 Messe Regel
Phi Vorne Phi Vorne
26 B 2,918177475 5 1 0a000001 Phi Ist Vorne 2 Messe Regel
Phi Vorne Phi Vorne
31 A 2,918327475 5 1 0a000000
46 A 2,918777425 5 1 0d000001 Stellwert Regel Stelle
48 A 2,918837425 5 1 0d000000
48 B 2,918837425 5 1 0d000000
98 A 2,920337375 5 1 0e000000
190 A 2,923097250 5 0 00000000
205 A 2,923547225 5 1 0f000000
153
Versicherung über Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach
§22(4) ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Hilfsmittel benutzt
habe.
Hamburg, 19. Dezember 2008

Ort, Datum Unterschrift

Schedulingsynthese Und Implementierung Einer FlexRay Anwendung Fuer Ein Fahrerloses Transportsystem

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Schedulingsynthese Und Implementierung Einer FlexRay Anwendung Fuer Ein Fahrerloses Transportsystem

Hochgeladen von

Copyright:

Verfügbare Formate

Hochschule für Angewandte Wissenschaften Hamburg

Hamburg University of Applied Sciences

Schedulingsynthese und Implementierung

Fakultät Technik und Informatik Faculty of Engineering and Computer Science

Masterarbeit eingereicht im Rahmen der Masterprüfung

Betreuender Prüfer: Prof. Dr.-Ing. Bernd Schwarz

Abgegeben am 19. Dezember 2008

Thema der Masterarbeit

Title of the paper

2 Das fahrerloses Transportsystem SCV 4

3 Zeitgesteuerte Architektur im Automobil 7

4 Übersicht zu Entwurfskonzepten für verteilte zeitgesteuerte Systeme 14

5 Entwurfsgrundlagen für die Implementation des zeitgesteuerten Antikollisionssys-

6 Systemübersicht zum AKS und Timing-Analyse der Renesas-Zielplattform 44

7 Implementierung des zeitgesteuerten AKS 56

8 Timinganalyse des zeitgesteuerten Antikollisionssystems 85

A Ergänzende Angaben zum Software-Konzept für verteilte, zeitgesteuerte Anwen-

B etAKS-Funktionen und deren Quelldateien 113

C Timing-Messungen auf der Zielplattform 114

D Ergänzungen zur Modellierung des ttAKS 120

E Ergänzung zur Implementation des ttAKS 132

F Daten zum Schedulings des ttAKS 137

G Timing-Messungen der ttAKS-Kommunikation über FlexRay 145

• Es werden Methoden zur Analyse und Modellierung von verteilten Echtzeitanwendungen

• Abschließend wird eine Timing-Analyse für die zeitgesteuerte Task-Ausführung und

Die Dokumentation umfasst folgende Kapitel:

• Eine Übersicht über die etAKS-Anwendung, sowie die zeitgesteuerte Anriebsregelung

• Im Kapitel 8 werden Timing-Messungen zur Verifizierung der Schedules zum ttAKS

Abb. 2.1: Fahrerloses Transportfahrzeug SCV [Schetler (2007)]

Die ereignisgesteuerte Plattform

Das ereignisgesteuertes Antikollisionssystem (etAKS) kommt auf der ereignisgesteuerten Platt-

Abb. 2.2: Systemübersicht zur ereignisgesteuerten Plattform [Sellentin (2006)]

Die zeitgesteuerte Plattform

Eine Anwendung zur zeitgesteuerten Antriebsregelung und Fahrzeugkoordinierung wurde im

Abb. 2.3: Systemübersicht zur zeitgesteuerten Plattform [Sellentin (2006)]

Im Rahmen einer Masterarbeit wurde ein „zeitgesteuertes, verteiltes Software-Konzept imple-

3.1 Zeitgesteuerte Architektur im Automobil

3.1.1 Eigenschaften einer zeitgesteuerten Architektur

• Zuverlässigkeit: Die Zuverlässigkeit eines Rechnersystems ist dann von Bedeutung,

3.1.2 Gegenüberstellung von zeitgesteuerten und ereignisgesteuerten

In der zeitgesteuerten Architektur werden Tasks zu vorher bestimmten Zeitpunkten periodisch

3.2 Zeitgesteuerte Task-Aktivierung

Bei einer zeitgesteuerten Task-Aktivierung werden Tasks in bestimmten Zeitabständen peri-

• Statisch: Scheduling-Entscheidungen werden basierend auf festen Parameter durchge-

• Dynamisch: In dynamischen Verfahren werden Scheduling-Entscheidungen auf dynami-

• Online: Ein Online-Algorithmus führt die Scheduling-Entscheidungen zur Laufzeit aus.

• Heuristisch: Ein heuristischer Algorithmus ermittelt einen ausführbaren Schedule nach

3.3 Das Kommunikationssystem FlexRay

3.3.1 Eigenschaften des Kommunikationssystems FlexRay

Der folgende Abschnitt beschreibt die Eigenschaften des Kommunikationssystems FlexRay:

3.3.2 Aufbau eines FlexRay-Knotens

Ein FlexRay-Knoten besteht aus einem Mikrocontroller, einem FlexRay-Kommunikations-

Abb. 3.1: Aufbau eines FlexRay-Knotens [Rausch (2008)]

3.3.3 Die TDMA-Runde

Abb. 3.2: Aufbau einer TDMA-Runde

Das statische Segment

(a) Frame Slot Zuordnung (b) Knoten Slot Zuordnung

Abb. 3.3: Slot-Zuordnung von Frames und Knoten

Es gibt die folgenden Varianten für die Slot-Knoten-Zuordnung(Abb. 3.3b):

• Es werden wie in Slot 5 beide Kanäle unterschiedlichen Knoten zugeordnet (Bandbrei-

Das dynamische Segment

Abb. 3.4: Frames im dynamischen Segment

3.3.4 Die Uhrensynchronisation