koexistenz von autosar softwarekomponenten und linux

Koexistenz von AUTOSAR Softwarekomponenten undLinux-Programmen für zukünftige High Performance

Automotive Steuergeräte

Masterarbeit

zur

Erlangung des akademischen Grades

M.Sc.

Fakultät für Informatik

Professur Technische Informatik

eingereicht von: Christian Jann, geb. am 28.03.1989 in Karl-Marx-Stadt

Betreuer: Prof. Dr. W. Hardt

Dipl.-Ing. Wilken Klee

Jann, ChristianKoexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen für zukünf-tige High Performance Automotive SteuergeräteMasterarbeit, Fakultät für Informatik, Professur Technische InformatikTechnische Universität Chemnitz, Februar 2016

Elektrobit Automotive GmbH Am Wolfsmantel 46 91058 Erlangen

Phone +49 9131 7701 0 Fax +49 9131 7701 6333 automotive.elektrobit.com [email protected]

Managing Directors: Alexander Kocher, Gregor Zink The office is registered in Erlangen Register court Fürth HRB 4886 VAT-ID: DE132503195

Nordea Bank SWIFT: NDEADEFF IBAN: DE40 5143 0300 6301 9400 01

Page 1 of 1

Aufgabenstellung Master-Arbeit für Christian Jann

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen für zukünftige High Performance

Automotive Steuergeräte / Coexistence of Legacy AUTOSAR Software Components and Linux Programs in

Future High Performance Automotive ECUs

In den letzten Jahren fand und findet AUTOSAR als Betriebssystem und Methodologie zur Entwicklung von

Steuergeräten eine immer weitere Verbreitung bei allen Fahrzeugherstellern. Das AUTOSAR-Betriebssystem

basiert, oft bedingt durch preisgünstige Kontroller, vorwiegend auf einer statischen Programmausführung. Diese

begünstigt die Beherrschbarkeit von komplexen Steuergeräten, da das Schedulingverhalten und der

Speicherbedarf weitgehend vorhersagbar sind.

Bedingt durch die technische Weiterentwicklung und den Einsatz von Algorithmen mit hohem Ressourcenbedarf,

die bisher vor allem in anderen IT-Bereichen eingesetzt wurden, ist es erforderlich die Leistungsfähigkeit

hinsichtlich Rechenoperationen und Datendurchsatz massiv zu erweitern. Hiermit geht der Bedarf Speicher zur

Laufzeit zu allokieren und dynamisches Scheduling zu nutzen einher.

Eine Möglichkeit diesem zu begegnen ist der Einsatz von Linux als Betriebssystem. Dieses wird in weiten Teilen

der IT-Industrie für unterschiedlichste Aufgaben eingesetzt und lässt sich sowohl in preisgünstigen

Mikrokontrollern als auch auf Großrechnern einsetzen. Hierbei stellt sich die Frage nach der Nutzung von bereits

bestehenden AUTOSAR-Komponenten sowie von Basissoftwaremodulen, welche beispielsweise die im Fahrzeug

verwendeten Kommunikationsprotokolle umsetzen. Hierzu wurden bisher vor allem Hypervisor-Ansätze verfolgt.

Dabei existieren AUTOSAR und Linux in zwei voneinander getrennten virtuellen Steuergeräten. Dieser Ansatz zeigt

jedoch Nachteile hinsichtlich der Performance und schränkt die effiziente Kommunikation zwischen Linux und

AUTOSAR ein, da konzeptbedingt die Betriebssysteme maximal abgeschottet sind.

Im Rahmen dieser Arbeit soll eine Softwarearchitektur entwickelt, bewertet und umgesetzt werden, welche es

ermöglichet AUTOSAR-Komponenten direkt in einer Linux-Umgebung auszuführen. Dabei soll eine Schnittstelle

definiert werden, welche die Kommunikation zwischen AUTOSAR-Komponenten und Linux-Applikationen

ermöglichen soll.

Mithilfe dieser Architektur soll die Abschottung zwischen Linux und AUTOSAR umgangen werden. Hierdurch wird

nicht nur die Kommunikation zwischen AUTOSAR- und Linux-Applikationen effizienter, sondern auch der Einsatz

von bestehenden Linux-Applikationen erleichtert.

Wissenschaftliche Fragestellungen:

Wie kann eine effiziente Kommunikation zwischen AUTOSAR-Komponenten und Linux-Applikationen

umgesetzt werden?

Welche architektonischen Anforderungen müssen Linux-Applikationen hierzu erfüllen?

Welche architektonischen Anforderungen müssen AUTOSAR-Komponenten hierzu erfüllen?

Wie sollte sich die AUTOSAR-Methodologie ändern, um den Prozess zu unterstützen?

Danksagung

An dieser Stelle möchte ich mich bei allen bedanken, die mich bei der Erstellung dieserArbeit unterstützt haben. Besonderer Dank gilt dabei meinen Kollegen Hermann, Moritz,Thorsten und Wilken.

Kurzfassung

Moderne Fahrerassistenzsysteme und der Weg zum autonomen Fahren stellen immergrößere Anforderungen an die Steuergeräte Hard- und Software im Fahrzeug.

Um diese Anforderungen zu erfüllen kommen vermehrt hochperformante Steuerge-räte mit einer heterogenen Prozessorarchitektur zum Einsatz. Ein Safety-Prozessor,auf dem ein standardmäßiges AUTOSAR-Betriebssystem ausgeführt wird, übernimmtdabei die echtzeitkritischen und sicherheitsrelevanten Aufgaben wohingegen die re-chenintensiven und dynamischen Aufgaben auf einem sehr viel leistungsfähigerenPerformance-Prozessor unter einem POSIX-Betriebssystem wie zum Beispiel Linuxausgeführt werden.

Hierbei soll es ermöglicht werden unter dem Linux System ebenfalls AUTOSAR Soft-warekomponenten und Module auszuführen, welche beispielsweise die im Fahrzeugverwendeten Kommunikationsprotokolle umsetzen oder weniger sicherheitskritischeAufgaben erfüllen. Auf diese Weise lassen sich andere Steuergeräte im Fahrzeug entlas-ten.

Dazu wurde im Rahmen dieser Arbeit eine Softwarearchitektur entwickelt, die esermöglicht AUTOSAR-Komponenten direkt in einer Linux-Umgebung auszuführen.Des Weiteren wurde eine einfache und effiziente Kommunikation zwischen AUTOSAR-Komponenten und Linux-Applikationen erarbeitet.

Schlüsselwörter: AUTOSAR, Linux, ADAS, Softwarearchitektur, Kommunikation,Echtzeit, Koexistenz, Steuergerät, Automotive

Inhaltsverzeichnis

Abbildungsverzeichnis xv

Tabellenverzeichnis xix

Abkürzungsverzeichnis xxi

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Grundlagen 72.1 Allgemeine Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Begriffserklärungen . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Der POSIX Standard . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Interprozesskommunikation (IPC) . . . . . . . . . . . . . . . 92.1.4 Serialisierung und Deserialisierung . . . . . . . . . . . . . . 10

2.2 Der AUTOSAR Standard . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Die AUTOSAR Architektur . . . . . . . . . . . . . . . . . . 112.2.2 Basic Software (BSW) . . . . . . . . . . . . . . . . . . . . . 112.2.3 Das Betriebssystem (OS) . . . . . . . . . . . . . . . . . . . . 122.2.4 Softwarekomponenten (SWC) . . . . . . . . . . . . . . . . . 122.2.5 Ports und Interfaces . . . . . . . . . . . . . . . . . . . . . . . 132.2.6 Complex Device Driver (CDD) . . . . . . . . . . . . . . . . 132.2.7 Basic Software Module . . . . . . . . . . . . . . . . . . . . . 142.2.8 Die Methodologie . . . . . . . . . . . . . . . . . . . . . . . 142.2.9 Adaptive AUTOSAR und die Zukunft von AUTOSAR . . . . 16

2.3 Eingesetzte Hard- und Software . . . . . . . . . . . . . . . . . . . . 172.3.1 Die DRIVE PX Plattform . . . . . . . . . . . . . . . . . . . 172.3.2 Elektrobit Produkte und Terminologie . . . . . . . . . . . . . 18

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte xi

Inhaltsverzeichnis

2.3.3 Weitere Software . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Stand der Technik 213.1 Separate Prozessoren . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Multicore Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Hypervisor Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 RTE on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 AUTOSAR und Linux 294.1 Ausführen von AUTOSAR-Komponenten unter Linux . . . . . . . . 30

4.1.1 Entwicklung eines AUTOSAR-RTE Layers für Linux . . . . 304.1.2 Nutzung des kompletten AUTOSAR OS unter Linux . . . . . 32

4.2 Kommunikation zwischen AUTOSAR und Linux . . . . . . . . . . . 324.2.1 Designziele . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 Möglichkeiten zur Implementierung . . . . . . . . . . . . . . 334.2.3 Designentscheidungen . . . . . . . . . . . . . . . . . . . . . 39

4.3 Konzept zur Implementierung . . . . . . . . . . . . . . . . . . . . . 41

5 Implementierung 435.1 EB tresos LxCore - Der AUTOSAR Stack unter Linux . . . . . . . . 43

5.1.1 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 DsCom - Interprozesskommunikation zwischen AUTOSAR und Linux 475.2.1 Umsetzung als einfacher CDD . . . . . . . . . . . . . . . . . 485.2.2 Umsetzung als EB tresos Studio Plugin . . . . . . . . . . . . 515.2.3 Erstellen eines neuen tresos Studio Plugins . . . . . . . . . . 525.2.4 Der Template Based Code Generator . . . . . . . . . . . . . 535.2.5 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Workflow LxCore und DsCom . . . . . . . . . . . . . . . . . . . . . 655.3.1 Installation von EB tresos Studio . . . . . . . . . . . . . . . . 655.3.2 Import des SimpleDemoRTE Projektes . . . . . . . . . . . . 665.3.3 Hinzufügen des DsCom Modules zum EB tresos Studio Projekt 675.3.4 Hinzufügen eines DsCom Ports im SystemDesk Modell . . . 695.3.5 Import in EB tresos Studio . . . . . . . . . . . . . . . . . . . 725.3.6 Kompilieren und Ausführen . . . . . . . . . . . . . . . . . . 75

6 Ergebnisse und Bewertung 796.1 Grundlegende Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . 796.2 Auswirkung auf die AUTOSAR Methodologie . . . . . . . . . . . . 80

xiiKoexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen

für zukünftige High Performance Automotive Steuergeräte

Inhaltsverzeichnis

6.3 Architektonische Anforderungen . . . . . . . . . . . . . . . . . . . . 806.4 Performance und Jitter Messung . . . . . . . . . . . . . . . . . . . . 81

6.4.1 Testszenario Perf2 . . . . . . . . . . . . . . . . . . . . . . . 826.4.2 Zeitmessung DsCom mit Softwarekomponente . . . . . . . . 90

6.5 Bewertung der Architektur . . . . . . . . . . . . . . . . . . . . . . . 92

7 Zusammenfassung und Ausblick 93

Literaturverzeichnis 95

Selbstständigkeitserklärung 99

Anhang A Quelltextausschnitte 101

Anhang B Inhalt der Daten CD 109

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte xiii

Abbildungsverzeichnis

1.1 Google Self-Driving Car . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Neue Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . 31.3 EB AVP Car-PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 AUTOSAR Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Kommunikation von Softwarekomponenten über die RTE . . . . . . . 122.3 Überblick AUTOSAR Methodologie . . . . . . . . . . . . . . . . . . 152.4 Kontinuierlicher Ausbau von AUTOSAR . . . . . . . . . . . . . . . 162.5 Geplante Architektur der AUTOSAR Adaptive Platform . . . . . . . 172.6 DRIVE PX B00 Hardware . . . . . . . . . . . . . . . . . . . . . . . 182.7 EB tresos AutoCore . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 EBSSHARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Linux und Erika Enterprise . . . . . . . . . . . . . . . . . . . . . . . 223.3 Mixed-Criticallity-System im Rahmen von eConnect Trier . . . . . . 233.4 COQOS SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 EBSSHARP Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . 253.6 COQOS-tP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7 EB tresos AutoCore 7 based on AUTOSAR 4.0.3 & RfCs 4.1.x / 4.2 . 273.8 LINUX/LXTHREADSX86 OS - Simple Demo RTE . . . . . . . . . 27

4.1 Konzeptidee zur Softwarearchitektur des Gesamtsteuergerätes . . . . 294.2 AUTOSAR SW-C Descriptions und VFB . . . . . . . . . . . . . . . 314.3 RTE Abstraction Library . . . . . . . . . . . . . . . . . . . . . . . . 314.4 Implementierung als CDD . . . . . . . . . . . . . . . . . . . . . . . 344.5 Implementierung über Com und PduR . . . . . . . . . . . . . . . . . 354.6 AUTOSAR: Communication Stack Architecture Overview . . . . . . 364.7 IPC Kommunikation über PDU Router . . . . . . . . . . . . . . . . . 364.8 IPC via AUTOSAR IP Stack with SOME/IP . . . . . . . . . . . . . . 37

5.1 LXTHREADSX86 OS MultiCore Demo Projekt . . . . . . . . . . . . 44

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte xv


5.2 LXTHREADSX86 OS Konfiguration . . . . . . . . . . . . . . . . . 445.3 WinCore SimpleDemoRte Projekt . . . . . . . . . . . . . . . . . . . 455.4 LxCore SimpleDemoRte mit gleicher Ausgabe wie OS MultiCore Demo 465.5 DsCom Architektur Überblick . . . . . . . . . . . . . . . . . . . . . 485.6 DsCom als CDD Ausschnitt TopLevelComposition in SystemDesk . . 495.7 Client Server Interface If_FwdData . . . . . . . . . . . . . . . . . . . 495.8 DsCom als CDD Aufbau im Project Manager von SystemDesk . . . . 505.9 DsCom als Modul Ausschnitt aus TopLevelComposition in SystemDesk 525.10 DsCom im Versionskontrollsystem . . . . . . . . . . . . . . . . . . . 535.11 Verzeichnisstruktur DsCom Modul und Projekt . . . . . . . . . . . . 545.12 Konfiguration DsComBufferSize . . . . . . . . . . . . . . . . . . . . 555.13 Konfiguration des DsCom Moduls mit 2 Verbindungen . . . . . . . . 575.14 DsCom Modul: Component Context View . . . . . . . . . . . . . . . 595.15 DsCom Modul: Composition View . . . . . . . . . . . . . . . . . . . 605.16 DsCom Modul: Algorithm View DsComDataReceiverThread . . . . . 625.17 DsCom Modul: Algorithm View IsrDsComDataReceived . . . . . . . 635.18 DsCom Modul: Algorithm View DsCom_FwdDataTask . . . . . . . . 645.19 EB tresos Studio Setup . . . . . . . . . . . . . . . . . . . . . . . . . 655.20 EB tresos Studio Import Demo . . . . . . . . . . . . . . . . . . . . . 665.21 EB tresos Studio Project Explorer . . . . . . . . . . . . . . . . . . . 675.22 EB tresos Studio Module Configurations . . . . . . . . . . . . . . . . 685.23 EB tresos Studio DsCom Configurations . . . . . . . . . . . . . . . . 685.24 EB tresos Studio DsCom DemoCon . . . . . . . . . . . . . . . . . . 695.25 EB tresos Studio Generate SWCD . . . . . . . . . . . . . . . . . . . 695.26 SystemDesk TopLevelComposition . . . . . . . . . . . . . . . . . . . 705.27 SystemDesk SWC_CyclicCounter DsCom Ports . . . . . . . . . . . . 705.28 SystemDesk SWC_CyclicCounter DsCom Receivedata Runnable . . 715.29 SystemDesk SWC_CyclicCounter DsCom TransmitData Operation . 715.30 EB tresos Studio Import System Model . . . . . . . . . . . . . . . . 725.31 EB tresos Studio Create ECU Extract . . . . . . . . . . . . . . . . . 725.32 EB tresos Studio OS Tasks . . . . . . . . . . . . . . . . . . . . . . . 735.33 EB tresos Studio Connection Editor . . . . . . . . . . . . . . . . . . 745.34 Ausführen der launch.bat Datei . . . . . . . . . . . . . . . . . . . . . 755.35 Ausführen des SimpleDemoRTE Programms . . . . . . . . . . . . . 765.36 Senden von Daten an DsCom via Python Script . . . . . . . . . . . . 76

6.1 EB Platform for Autonomous Driving . . . . . . . . . . . . . . . . . 806.2 EB tresos TestSuite Perf2 . . . . . . . . . . . . . . . . . . . . . . . . 836.3 EB tresos TestSuite Perf2 Ergebnisse Aurix . . . . . . . . . . . . . . 84

xviKoexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen



6.4 DrivePx Histogramm Perf2 NSActivateTask (Leerlauf) . . . . . . . . 876.5 DrivePx Histogramm Perf2 NSActivateTask (Last) . . . . . . . . . . 876.6 JetsonPro RT Histogramm Perf2 NSActivateTask (Leerlauf) . . . . . 896.7 JetsonPro RT Histogramm Perf2 NSActivateTask (Last) . . . . . . . . 906.8 Sequenzdiagramm Zeitmessung DsCom . . . . . . . . . . . . . . . . 91

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte xvii

Tabellenverzeichnis

6.1 EB tresos TestSuite Perf2 Testumgebung Aurix . . . . . . . . . . . . 846.2 Perf2 Testumgebung DrivePx . . . . . . . . . . . . . . . . . . . . . . 856.3 DrivePx Perf2 (Leerlauf) . . . . . . . . . . . . . . . . . . . . . . . . 866.4 DrivePx Perf2 (Last) . . . . . . . . . . . . . . . . . . . . . . . . . . 866.5 Perf2 Testumgebung JetsonPro . . . . . . . . . . . . . . . . . . . . . 886.6 JetsonPro RT Perf2 (Leerlauf) . . . . . . . . . . . . . . . . . . . . . 886.7 JetsonPro RT Perf2 (Last) . . . . . . . . . . . . . . . . . . . . . . . . 896.8 Zeitmessung DrivePxApp mit DsCom Modul . . . . . . . . . . . . . 92

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte xix

Abkürzungsverzeichnis

ACG AutoCore GenericACM AutoCore Microcontroller-dependentACP AutoCore PlatformADAS Advanced Driver Assistance SystemsAPI Application Programming InterfaceAUTOSAR AUTomotive Open System ARchitectureAVP Autonomous Valet ParkingBSW Basic SoftwareCDD Complex Device DriverEB ElektrobitECU Electronic Control UnitFPS Frames per SecondHPC High-Performance ComputingIPC InterprozesskommunikationISR Interrupt Service RoutineJET Java Emitter TemplatesMCAL Microcontroller Abstraction LayerOEM Original Equipment ManufacturerOS Operating SystemPAD Platform for Autonomous DrivingPDU Protocol Data UnitPOSIX Portable Operating System InterfaceRTE Runtime EnvironmentSSH Secure ShellSWC Software ComponentVAP Virtuelle AbsicherungsplattformVFB Virtual Functional BusVMM Virtual Machine Monitor

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte xxi

Kapitel 1

Einleitung

Die ganze Welt spricht über autonomes Fahren. Google baut futuristische Fahrzeuge(Abb. 1.1). 44% der Amerikaner können sich vorstellen in 10 Jahren ein selbstfahrendesAuto zu kaufen (vgl. [WIR15a]). Doch was steckt dahinter? Welche Hardware undSoftware braucht man um solche Projekte in die Tat umzusetzen?

Abbildung 1.1 Google Self-Driving Car1

In dem Forschungsprojekt Platform for Autonomous Driving (PAD) bei Elektrobit (EB)wird genau dieses Thema untersucht. Zusammen mit dem ebenfalls bei EB angesie-deltem Autonomous Valet Parking (AVP) Projekt, NVIDIA und Infineon wird eine

1Quelle: [Goo15]

Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmenfür zukünftige High Performance Automotive Steuergeräte 1

Einleitung

Plattform entwickelt, die OEMs bei der Entwicklung und Umsetzung von Projekten imBereich des autonomen Fahrens unterstützen soll (vgl. [PR 15], [Ele15a]).

1.1 Motivation

Während Google versucht sofort zum selbstfahrenden Auto überzugehen, gehen dietraditionellen Autobauer eher schrittweise vor. Es werden nach und nach immer mehrFahrerassistenzsysteme in die Fahrzeuge integriert, um den Kunden so auf dem Wegvom teilautomatisiertem zum vollautomatisiertem Fahren an die Systeme zu gewöhnen(vgl. [WIR15b]).

Ein autonom fahrendes Fahrzeug ist ein äußerst komplexes System, dabei ist die not-wendige Hardware gar nicht so umfangreich und teuer (vgl. [WIR15c]). Der Großteildes Entwicklungsaufwandes steckt in der Software und den Algorithmen.

Bei der Entwicklung von Steuergeräten der Automobilindustrie hat sich die AUTomo-tive Open System ARchitecture (AUTOSAR) als Betriebssystem und Methodologie(vgl. Abschnitt 2.2.8) etabliert. Die AUTOSAR Architektur mit deren Interfaces iststandardisiert (vgl. Abschnitt 2.2.1) und es können Module und Tools verschiedenerHersteller kombiniert werden. Das AUTOSAR Betriebssystem basiert dabei vorwiegendauf einer statischen Programmausführung und begünstig somit die Beherrschbarkeitvon komplexen Steuergeräten. Das Schedulingverhalten und der Speicherbedarf sindweitgehend vorhersagbar. Es existieren geeignete Timing-Analyse Tools. Somit ist esrelativ einfach mit einem AUTOSAR System Echtzeitanforderungen zu erfüllen.

Doch auch an AUTOSAR geht der Trend zu immer mehr Fahrerassistenzsystem, der zu-nehmenden Vernetzung des Fahrzeugs (Car-2-X Kommunikation, Over-the-Air Updatesvon Steuergeräten) und dem autonomen Fahren nicht vorbei. Dies erfordert den Einsatzvon immer mehr Sensoren wie Kameras und Laserscannern. Die Anforderungen an dieLeistung und Integration der Steuergeräte und Infotainmentsysteme wachsen stetig (vgl.Abb. 1.2, [RFB15, S. 25f], [Fü15, S. 21-25]).

2Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen


1.1 Motivation

Abbildung 1.2 Neue Herausforderungen2

So komplexe Fahrerassistenzsysteme (ADAS) benötigen einiges an Rechenleistung. InAbb. 1.3 ist der Fahrzeug-PC vom AVP Projekt bei EB zu sehen. Für die Prototypenent-wicklung ist ein PC äußerst praktisch, für Serienentwicklung muss die Software dannallerdings auf platzsparende Automotive-taugliche Steuergeräte portiert werden.

Solche Steuergeräte sind z.B. das zentrale Fahrerassistenzsystem zFAS von Audi (vgl.[TTT15]), die Chassis Domain Control Unit CDCU von Continental (vgl. [Con15])oder die DRIVE PX Plattform von NVIDIA (vgl. [NVI15b]). Dabei kommen zumeistheterogene Multiprozessorsysteme zum Einsatz. Die DRIVE PX Plattform besitzt zumBeispiel einen Standard Automotive Safety Prozessor von Infineon und zwei High-Performance Prozessoren von NVIDIA (vgl. Abschnitt 2.3.1).

2Quelle: [NVI15a], [NVI15b]


Einleitung

Abbildung 1.3 EB AVP Car-PC3

Doch welche Basissoftware soll auf dem Steuergerät laufen und wie soll die SoftwareArchitektur aussehen? Das System muss echtzeitfähig sein und es müssen zahlreicheSafety-Requirements erfüllt werden.

Auf Automotive Steuergeräten wird üblicherweise AUTOSAR eingesetzt, damit lassensich die Echtzeit- und Safety-Anforderungen erfüllen. Doch AUTOSAR wurde für klei-ne Steuergeräte mit begrenzten Ressourcen entwickelt. Das AUTOSAR Betriebssystembietet kein dynamisches Scheduling, Speicher kann nicht dynamisch allokiert werdenund es ist nicht möglich Module zur Laufzeit nachzuladen.

Auf dem Performance Prozessor zur Kamera und Sensorauswertung bietet sich zumBeispiel Linux oder QNX als Betriebssystem an. Auf dem Safety Prozessor, der direktmit dem Fahrzeugbus verbunden ist und daher besondere Safetyanforderungen erfüllenmuss, könnte dann zum Beispiel ein nach ASIL-D zertifiziertes AUTOSAR OS mitSafety-RTE laufen.

1.2 Zielsetzung

Während die bestehende AUTOSAR Plattform unter dem Namen AUTOSAR ClassicPlatform weiterbestehen soll wird an einer neuen AUTOSAR Adaptive Platform gear-beitet die auf einem POSIX-Betriebssystem basieren soll (vgl. Abschnitt 2.2.9). Dabei

3Quelle: EB



1.3 Vorgehensweise

ist es wünschenswert, wenn man unter diesem POSIX-Betriebssystem ebenfalls be-reits vorhandene Softwarekomponenten und Basissoftwaremodule aus der AUTOSARClassic Platform ausführen könnte.

So ein POSIX Betriebssystem ist beispielsweise Linux. Es hat sich sowohl im EmbeddedBereich als auch im PC und High-Performance Computing (HPC) Bereich bewährt.Doch wie sollen klassische AUTOSAR Softwarekomponenten unter Linux ausgeführtwerden?

In dieser Arbeit soll die Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen für High Performance Automotive Steuergeräte untersucht werden. Durchdie Ausführung von AUTOSAR-Komponenten direkt unter Linux soll die Abschottungzwischen Linux und AUTOSAR aufgehoben werden, eine effizientere Kommunika-tion zwischen AUTOSAR-Softwarekomponenten und Linux-Applikationen ermög-licht werden und der Einsatz von bestehenden Linux-Applikationen zusammen mitAUTOSAR-Softwarekomponenten erleichtert werden.

1.3 Vorgehensweise

In Kapitel 2 „Grundlagen“ werden zuerst die für die nachfolgenden Kapitel wichtigenGrundlagen zusammengefasst sowie die eingesetzte Hardware und Software vorgestellt.

Danach werden in Kapitel 3 „Stand der Technik“ die Ausgangssituation und bereitsexistierende Möglichkeiten zur Koexistenz von AUTOSAR und Linux betrachtet.

Kapitel 4 „AUTOSAR und Linux“ stellt anschließend Lösungsansätze zur Ausführungvon AUTOSAR-Komponenten unter Linux vor und erläutert Möglichkeiten zur Reali-sierung der Kommunikationsschnittstelle zwischen AUTOSR und Linux. Es werdenDesignziele und -Entscheidungen dargelegt und das Konzept zur Implementierungveranschaulicht.

Die Umsetzung des Konzeptes erfolgt in Kapitel 5 „Implementierung“. Hier wirddetailliert auf die gewählte Implementierung und die Funktionsweise eingegangen.

In Kapitel 6 „Ergebnisse und Bewertung“ werden die Ergebnisse des vorangegangenKapitels zusammengefasst, die entstandene Softwarearchitektur evaluiert und auf ar-chitektonische Anforderungen und Auswirkungen auf die AUTOSAR Methodologieeingegangen.

Schließlich wird die Arbeit mit Kapitel 7 „Zusammenfassung und Ausblick“ abge-schlossen.


Kapitel 2

Grundlagen

In diesem Kapitel werden für die nachfolgenden Kapitel wichtige Grundlagen zusam-mengefasst.

2.1 Allgemeine Grundlagen

2.1.1 Begriffserklärungen

Steuergerät (ECU)

Als Steuergerät, oder Electronic Control Unit (ECU) bezeichnet man elektronischeModule im Fahrzeug die zum Schalten und Regeln sowie zum Übertragen von Informa-tionen über Fahrzeugbusse als auch mittels Funktechnologien eingesetzt werden.

Ein High Performance Automotive Steuergerät ist ein Steuergerät, dass deutlich mehrRechenleistung und Speicher bietet als herkömmliche Automotive Steuergeräte.

Statische Programmausführung

Unter statischer Programmausführung versteht man bei Automotive Steuergerätenden Einsatz von statischen Schedulingverfahren und den Verzicht auf dynamischeSpeicherallokation zur Laufzeit.


Grundlagen

Weiterhin werden keine Programmteile zur Laufzeit nachgeladen, d.h. es gibt nurein Binary (im Gegensatz zu Desktop-Betriebssystemen wo weitere Programme zurLaufzeit gestartet werden können).

Architektonische Anforderungen

Unter architektonischen Anforderungen versteht man Anforderungen an die Softwarear-chitektur des Gesamtsystems oder einzelner Module.

Einzelne Softwaremodule müssen z.B. spezielle Anforderungen an die Interfaces unddie Daten, die über diese transportiert werden erfüllen, um mit anderen Modulenkommunizieren zu können.

Hypervisor

Ein Hypervisor (auch Virtual Machine Monitor (VMM)) erlaubt den gleichzeitigenBetrieb von mehreren Gastsystemen auf einem Hostsystem. So können z.B. auf einemProzessor mehrere Betriebssysteme gleichzeitig ausgeführt werden. Der Hypervisorregelt dabei den Zugriff auf die real vorhandene Hardware.

Autonomes Fahren

Unter autonomen Fahren (auch automatisiertes Fahren, pilotiertes Fahren), versteht mandie selbständige Fortbewegung von Fahrzeugen ohne menschlichen Fahrer.

Jitter

Jitter hat technisch gesehen viele Bedeutungen. Allgemein bezeichnet er die Variati-on der Taktzyklen bei digitalen Signalen. Der Wert des Jitter dient dabei häufig alsQualitätsmerkmal, ein großer Jitter ist unerwünscht.

In dieser Arbeit ist mit Jitter die Schwankung der Start- bzw. Ausführungszeit der vomOS getriggerten Funktionen gemeint.



2.1 Allgemeine Grundlagen

2.1.2 Der POSIX Standard

Das Portable Operating System Interface (POSIX) ist ein Application ProgrammingInterface (API) welches die Schnittstelle zwischen Anwendungssoftware und demBetriebssystem zur Verfügung stellt. Entwickelt wurde es von der IEEE und der OpenGroup für Unix. Es ist in der internationalen Norm ISO/IEC/IEEE 9945 standardisiert.(vgl. [Wik15])

Dabei enthält der POSIX Standard mehr Funktionen als die C-Standardbibliothek. Dar-unter sind Funktionen zum Zugriff auf das Dateisystem, zum Starten von Programmen,Prozessen und Threads, Funktionen zur Ein- und Ausgabe als auch Funktionen zumZugriff auf die Systemzeit (vgl. [TT13a]) und viele mehr.

Der komplette POSIX Standard kann online unter http://pubs.opengroup.org/onlinepubs/9699919799/ eingesehen werden.

2.1.3 Interprozesskommunikation (IPC)

Interprozesskommunikation (IPC) bezeichnet die Kommunikation zwischen Program-men oder Prozessen innerhalb des gleichen Betriebssystems.

Unter Linux gib es zahlreiche Möglichkeiten zur IPC-Kommunikation, auf niedrigemAbstraktionslevel sind dies:

• POSIX/System V IPC

– Message Queue

– Semaphores

– Shared Memory

• Named Pipe/FIFO

• TCP/IP Sockets / Unix-Domain-Sockets

Und auf höherem Level:

• D-Bus / Kdbus

• Boost.Interprocess (Wrapper für Low-Level Mechanismen)

• Message Queues / Message Broker: zeroMQ, RabbitMQ, . . .


http://pubs.opengroup.org/onlinepubs/9699919799/

http://pubs.opengroup.org/onlinepubs/9699919799/

Grundlagen

2.1.4 Serialisierung und Deserialisierung

Wenn strukturierte Daten, die nicht als Byte-Array vorliegen, über eine Verbindungübertragen werden sollen, die nur den Byte- oder Bitweisen Transfer zulässt müssendiese zuerst serialisiert (in ein Byte-Array umgewandelt) werden.

Auf Empfängerseite werden diese dann wieder in eine Datenstruktur umgewandelt. Da-mit dies funktioniert muss die Empfängerseite wissen, wie diese Daten auf Senderseitekodiert wurden. Dazu gibt es verschiedene Möglichkeiten:

• Google Protocol Buffers (protobuf)

• XML, JSON, ...

• Binärformate (Kameradaten)

• SOME/IP (Scalable service-Oriented MiddlewarE over IP)

– Teil von AUTOSAR

– Nutzbar für Inter-Prozess und Inter-Prozessor Kommunikation

– Zahlreiche Features: Serialization, Remote Procedure Call (RPC), ServiceDiscovery (SD), Publish/Subscribe (Pub/Sub)

– Es existiert eine GENIVI SOME/IP Bibliothek für Linux

2.2 Der AUTOSAR Standard

„AUTOSAR (AUTomotive Open System ARchitecture) ist ein internationaler Stan-dard der Automobilindustrie. Er beschreibt eine offene und standardisierte Softwa-rearchitektur für die Fahrzeugentwicklung, die gemeinsam von Automobilherstellern,Automobilzulieferern und Werkzeugherstellern entwickelt und getragen wird. Sie ha-ben gemeinsame Ziele definiert, deren Erreichung allen Beteiligten helfen soll, ohnegleichzeitig den für die Innovationen wichtigen Wettbewerb zu behindern.“ ([KF09, S.1])

Der komplette AUTOSAR Standard kann online unter http://www.autosar.org/ eingese-hen werden.



http://www.autosar.org/


2.2.1 Die AUTOSAR Architektur

Die AUTOSAR Architektur fördert eine Entkopplung der Anwendungssoftware vonder Mikrocontroller-Hardware. Dazu ist AUTOSAR Softwarearchitektur in verschiede-ne Schichten unterteilt (vgl. Abb. 2.1). Direkt auf die ECU Hardware setzt die BasicSoftware (BSW) mit dem Microcontroller Abstraction Layer (MCAL) und dem dar-überliegenden Runtime Environment (RTE) auf. Von der RTE können dann AUTOSARSoftwarekomponenten steuergeräteunabhängig ausgeführt werden. Die Schnittstellenzwischen den einzelnen Komponenten sind standardisiert.

Abbildung 2.1 AUTOSAR Architektur1

2.2.2 Basic Software (BSW)

Die AUTOSAR Basissoftware (BSW, Basic Software) stellt den Großteil der Soft-ware eines Automotive Steuergerätes dar. Sie enthält das AUTOSAR OS, die RTE,den Kommunikations-Stack, Treiber für die Mikrocontroller Hardware sowie je nachSteuergerät weitere Module.

1Quelle: [KPI16, S. 3]


Grundlagen

2.2.3 Das Betriebssystem (OS)

Das AUTOSAR OS ist ein Echtzeitbetriebssystem für Mikrocontroller im AutomotiveUmfeld mit Ursprung im OSEK OS [OSE05] und ist wie die komplette BSW imAUTOSAR Standard standardisiert.

Es bietet zahlreiche Funktionen zum Task Scheduling, um Resourcen zu verwaltenund den Zugriff auf diese zu synchronisieren. Man kann Schedule Tables und Alarmeanlegen um Tasks zeitgesteuert zu starten. Für Tasks können Prioritäten festgelegtwerden. Falls das Zeitverhalten von Tasks verletzt wird können ErrorHooks getriggertwerden. Des Weiteren gibt es Counter, Alarme und Interrupt Service Routinen (ISR).

Das AUTOSAR OS von Elektrobit unterstützt zahlreiche Plattformen, darunter auchLinux mit der LXTHREADSX86 Portierung.

2.2.4 Softwarekomponenten (SWC)

„Aus Sicht der Anwendungsentwickler besteht ein AUTOSAR Steuergerät aus Soft-warekomponenten, die über so genannte Ports miteinander kommunizieren“([ZS14, S.403]). Das Bereitstellen dieser Ports und der Nachrichtenaustausch zwischen ihnenwird, wie in Abb. 2.2 zu sehen, durch den RTE Layer realisiert.

Abbildung 2.2 Kommunikation von Softwarekomponenten über die RTE2

2Quelle: [ZS14, S. 403]




Eine Software Component (SWC) kann dabei nach außen hin mehrere unterschiedlichePorts besitzen. Intern besteht eine SWC u.A. aus Runnables, das sind Funktionen dieZeit- oder Eventgesteuert aufgerufen werden können.

2.2.5 Ports und Interfaces

Ports sind Verbindungsstellen zwischen Softwarekomponenten und dienen zu derenKommunikation.

Es gibt folgende Arten an Ports:

• Provided Port: Ein Provided Port ist entweder Sender von Daten (im Falle einesSender-Receiver Interfaces) oder stellt Operationen zur Verfügung (Im Falle einesClient-Server Interfaces).

• Required Port: Ein Required Port ist entweder Empfänger von Daten (im Falleeines Sender-Receiver Interfaces) oder nutzt Operationen eines Provided Ports(Im Falle eines Client-Server Interfaces).

Jedem Port wird ein Port-Interface zugeordnet. Es gibt:

• Sender-Receiver Interfaces: Ein Sender-Receiver Interface wird verwendet wennDaten an einen oder mehrere Empfänger übertragen werden sollen. Für Sender-Receiver Interfaces zwischen Softwarekomponenten auf der gleichen ECU kannDatenaustausch von der RTE zum Beispiel über einfache Variablen erfolgen.

• Client-Server Interfaces: Ein Client-Server Interface wird verwendet wenn eineSoftwarekomponente anderen Softwarekomponenten eine bestimmte Funktionzur Verfügung stellen soll. Für Client-Server Interfaces zwischen Softwarekom-ponenten auf der gleichen ECU werden von der RTE zumeist direkte Funktions-aufrufe generiert.

2.2.6 Complex Device Driver (CDD)

Der AUTOSAR Standard definiert einen Complex Device Driver (CDD) als „softwareentity not standardized by AUTOSAR that can access or be accessed via AUTOSARInterfaces [...] and/ or Basic Software Modules [...] APIs.“ ([AUT22a, S. 30]).

Ein CDD ermöglicht die Integration praktisch beliebiger Software in den AUTOSAR-Stack, solange die Schnittstellen des CDD nach außen hin AUTOSAR konform sind.


Grundlagen

CDDs waren ursprünglich für den Übergang von proprietären Lösungen auf die AUTO-SAR Architektur gedacht und sind äußerst flexibel.

CDDs können ebenso wie Softwarekomponenten in SystemDesk modelliert werdenund unterscheiden sich von Softwarekomponenten nur durch den Softwarekomponen-tentyp (SwComponentType). Wenn eine Softwarekomponente Funktionen eines CDDnutzen möchte, so können die Ports der Softwarekomponente und des CDD direkt inSystemDesk miteinander verknüpft werden. Der wichtigste Unterschied zu Software-komponenten ist das CDDs API-Aufrufe zur Basissoftware (z.B. OS) nutzen dürfen,eine SWC darf dies nicht.

2.2.7 Basic Software Module

Im AUTOSAR Standard wird ein Basic Software Modul definiert als „collection ofsoftware files (code and description) that define a certain basic software functionalitypresent on an ECU.“ ([AUT22a, S. 24])

Ein Basissoftwaremodul (AUTOSAR Modul) ist ein Teil der AUTOSAR Architekturund gehört zur BSW. AUTOSAR Module werden in EB tresos Studio über Pluginseingebunden und können ein eigenes Konfigurationsinterface besitzen. Über sogenannteService Ports können sie anderen BSW-Modulen oder Softwarekomponenten Funktio-nen zur Verfügung stellen. Dabei kann die Verknüpfung der Service Ports mit den Portsan der Softwarekomponente bei der Integration in EB tresos Studio durch den Connec-tion Editor vorgenommen werden. Weiterhin kann ein BSW-Modul API-Aufrufe fürandere BSW-Module bereitstellen.

Als AUTOSAR Module sollten nur solche Module bezeichnet werden, die in AUTOSARauch standardisiert sind, alle anderen sollten als Complex Device Driver bezeichnetwerden.

2.2.8 Die Methodologie

Die generelle Vorgehensweise bei der Entwicklung eines AUTOSAR Systems wird alsAUTOSAR Methodologie bezeichnet. Dies ist eine modellbasierte Entwicklung, die aufeiner Reihe verschiedener aufeinanderfolgender Arbeitsschritte basiert (vgl. Abb. 2.3).




Abbildung 2.3 Überblick AUTOSAR Methodologie3

Im ersten Schritt werden das Design und die Architektur des Systems spezifiziert.Dies ist in Abb. 2.3 als System Configuration Input dargestellt. Der nachfolgendeArbeitsschritt heißt Configure System, hierbei werden die SWCs auf die ECUs gemappt.Das Ergebnis ist die System Configuration Description, welche Informationen über dasgesamte System enthält, wie Bus-Zugriff und das Mapping der SWC auf ECUs.

Die nachfolgenden Schritte erfolgen dann für jede ECU separat. Der Schritt ExtractECU-Specific Information extrahiert aus der kompletten Konfiguration die Informationfür eine spezifische ECU. Diese Information wird in dem ECU Extract of SystemConfiguration gespeichert. Der nachfolgende Schritt Configure ECU versorgt die ECUmit allen notwendigen Informationen, wie Task Scheduling, benötigte Basic SoftwareModule sowie deren Konfiguration und die Zuordnung von Runnables auf Tasks. DieseInformation wird in der ECU Configuration Description gespeichert. Der letzte SchrittGenerate Executable, erzeugt dann ein Binary mit der Basic Software, der RTE undden Softwarekomponenten für die spezifische ECU. Die RTE wird dabei auf Basis derSchnittstellen der Softwarekomponenten und der Basic Software Module generiert. (vgl.[AUT15, S. 11f])

Am Ende der Kette hat man ein relativ statisches System, möchte man an diesem etwasändern, z.B. die Anzahl der Runnables oder das Scheduling, so muss man die Toolketteerneut durchlaufen.

3Quelle: [AUT15, S. 11]


Grundlagen

2.2.9 Adaptive AUTOSAR und die Zukunft von AUTOSAR

Adaptive AUTOSAR, oder AUTOSAR Adaptive Platform / Future of AUTOSAR, isteine Weiterentwicklung des AUTOSAR Standards.

Abbildung 2.4 Kontinuierlicher Ausbau von AUTOSAR4

Seit der Einführung von AUTOSAR im Jahr 2003 hat sich AUTOSAR etabliert undals Standard durschgesetzt (vgl. [RFB15, S. 24], Abb. 2.4). Die bisherige AUTOSAREntwicklung wird dabei unter dem Begriff Autosar Classic Platform zusammengefasst.Neue Herausforderungen wie hochautomatisiertes Fahren, die zunehmende Vernetzungdes Fahrzeugs, die nachträgliche Installation von Softwarekomponenten und UpdatesOver-the-Air , die sich nicht so einfach mit der bisherigen Plattform realisieren las-sen, machen es daher notwendig eine weitere Plattform anzubieten, um die bisherigePlattform, die inzwischen weit verbreitet im Einsatz ist, nicht zu destabilisieren (vgl.[RFB15, S. 25f]).

Dabei wird bei der neuen Plattform stark auf Technologien und existierende Standardsaus dem Consumer- und Telekommunikationsumfeld gesetzt. Grundlage bildet einBetriebssystem auf POSIX-Basis und eine Kommunikations-Middleware (vgl. [RFB15,S. 26, 28], Abb. 2.5).

4Quelle: [RFB15, S. 25]



2.3 Eingesetzte Hard- und Software

Abbildung 2.5 Geplante Architektur der AUTOSAR Adaptive Platform5


2.3.1 Die DRIVE PX Plattform

Zur Entwicklung dient die DRIVE PX Plattform von NVIDIA (vgl. [NVI15b]). DasBoard besitzt eine heterogene Prozessorarchitektur, es gibt einen Infineon Aurix6 SafetyProzessor mit AUTOSAR, zwei 64-bit NVIDIA Tegra X17 Performance Prozessorenmit CUDA8-Unterstützung auf denen Linux läuft, einen On-Board Ethernet Switch, 12Kamera-Eingänge, CAN, LIN, FlexRay und einen FPGA (vgl. Abb. 2.6).

5Quelle: [RFB15, S. 21]6https://en.wikipedia.org/wiki/Infineon_AURIX7http://www.nvidia.de/object/tegra-x1-processor-de.html8https://de.wikipedia.org/wiki/CUDA


https://en.wikipedia.org/wiki/Infineon_AURIX

http://www.nvidia.de/object/tegra-x1-processor-de.html

Grundlagen

Abbildung 2.6 DRIVE PX B00 Hardware

2.3.2 Elektrobit Produkte und Terminologie

EB tresos Studio

EB tresos Studio ist eine AUTOSAR Entwicklungsumgebung von Elektrobit.

EB tresos AutoCore

Der EB tresos AutoCore (vgl. Abb. 2.7) ist eine Zusammenfassung der AUTOSARBasic Software und besteht in der Regel aus dem AUTOSAR OS, der RTE, dem MCALund zahlreichen weiteren Modulen. Es wird unterschieden in AutoCore Generic (ACG),dieser enthält nur hardwareunabhängige Produkte, AutoCore Microcontroller-dependent(ACM), mit hardwareabhängigen Produkten und AutoCore Platform (ACP), welcherTeile aus ACG, ACM, MCAL als auch OEM spezifische Anpassungen enthält und inder Regel an den Kunden ausgeliefert wird.




Abbildung 2.7 EB tresos AutoCore9

SimpleDemoRte

Das SimpleDemoRte Projekt ist ein einfaches Beispielprojekt, dass in den meistenAuslieferungen von EB tresos Studio und EB tresos AutoCore enthalten ist und nur dieAUTOSAR RTE sowie zwingend erforderliche BSW-Module enthält, um die Funktionder RTE auf der Zielplattform zu demonstrieren. Es dient dabei häufig als Ausgangs-punkt für neue Projekte.

2.3.3 Weitere Software

dSPACE SystemDesk

SystemDesk ist ein Werkzeug zur Modellierung von AUTOSAR-Softwarearchitekturender Firma dSPACE.

9Quelle: [Ele16]


Kapitel 3

Stand der Technik

Zur Koexistenz von AUTOSAR Softwarekomponenten und Linux-Programmen gibt esverschiedene Ansätze. Diese werden im Folgenden kurz vorgestellt.

3.1 Separate Prozessoren

Bei dem Ansatz über separate Prozessoren gibt es zwei physikalisch voneinandergetrennte Prozessoren. Dies findet beispielsweise auf DRIVE PX Plattform Anwendung(vgl. Abschnitt 2.3.1). Hier gibt es den Infineon Aurix als Safety Prozessor auf demein Standard AUTOSAR OS läuft und den NVIDIA Tegra als Performance Prozessorauf dem Linux läuft. Bei diesem Ansatz können die Prozessoren über Bus-Systememiteinander verbunden sein.

Hier sind AUTOSAR und Linux maximal voneinander getrennt und man hat zweivollkommen unterschiedliche Entwicklungsprozesse.

3.2 Multicore Ansätze

Eine weitere Variante, die sich auf dem Markt etabliert hat, sind Multicore Ansätze.Hier kommen Mehrkernprozessoren zum Einsatz, wobei auf unterschiedlichen Kernendes gleichen Prozessors unterschiedliche Betriebssysteme laufen.

Ein Beispiel für diesen Ansatz ist EBSSHARP (EB Safe and Secure Hybrid ApplicationReference Platform). Bei EBSSHARP kommt eine Quad-Core CPU zum Einsatz, aufzwei Kernen läuft ein AUTOSAR konformes Multicore OS und auf den anderen zwei


Stand der Technik

Kernen ein Linux Kernel (vgl. Abb. 3.1). Dabei startet das AUTOSAR OS zuerst,initialisiert den Großteil der Hardware und lädt dann Linux auf den anderen zweiKernen nach. Dieser Ansatz hat den Vorteil einer kurzen Systemstartzeit1 bis sich dasSteuergerät am Bus meldet. Allerdings muss der Linux Kernel gepatcht werden, damiter kein zweites mal die Hardware initialisiert.

Abbildung 3.1 EBSSHARP2

Einen ähnlichen Weg verfolgt die Firma Evidence mit Erika Enterprise und Linux (vgl.[GM16, S. 22ff], Abb. 3.2).

Abbildung 3.2 Linux und Erika Enterprise3

2Quelle: EB2Der Vorgabewert für CAN-Bus Aktivität liegt in der Regel bei 200ms.3Quelle: [GM16, S. 21]



3.3 Hypervisor Ansätze

Weiterhin gibt es das Mixed-Criticallity-System im Rahmen von eConnect Trier4 (vgl.Abb. 3.3). Hier kommen AUTOSAR (ArcticCore) und Linux auf 2 Cortex-A9 Kernenzum Einsatz (vgl. [NS13, S. 1]).

Abbildung 3.3 Systemarchitektur Mixed-Criticallity-System im Rahmen von eConnectTrier5

Auch bei diesem Ansatz sind AUTOSAR und Linux stark getrennt. Weiterhin hat dieserAnsatz den Nachteil, dass sich die Betriebssysteme die gleiche Hardware teilen, und esnicht wie bei den nachfolgenden Hypervisor Ansätzen eine Zwischenschicht gibt, dieden Zugriff auf gemeinsam genutzte Hardwareresourcen koordiniert.

3.3 Hypervisor Ansätze

Bei den Hypervisor Ansätzen gibt es zwischen Hardware (Prozessor) und Betriebs-system noch eine weitere Zwischenschicht, den Hypervisor. Dieser koordiniert dengemeinsamen Zugriff auf Speicher und Hardware. Damit ist es möglich selbst auf einemEinkernprozessor mehrere Betriebssysteme „parallel“ auszuführen.

Ein Vertreter dieses Ansatzes aus dem Automotive Bereich ist das COQOS SDK(vgl. Abb. 3.4). „Wesentlicher Bestandteil des COQOS SDK ist ein Hypervisor ausder Avionik. Er erzeugt abgeschottete Software-Partitionen, die die darin integriertenBetriebssysteme völlig voneinander trennt. [...] Die AUTOSAR-Schnittstelle des CO-QOS SDK integriert AUTOSAR-Software-Komponenten und Basic-Software-Modulenahtlos in das Bordnetz. “([Ope16a]).

4http://www.econnect-trier.de5Quelle: [Kil13, S. 5]


http://www.econnect-trier.de

Stand der Technik

Abbildung 3.4 COQOS SDK6

Die unter Abb. 3.2 bereits angesprochene EBSSHARP Plattform soll ebenfalls zueiner Hypervisor-Architektur weiterentwickelt werden (vgl. Abb. 3.5) um Safety- undSecurity-Anforderungen, die an Automotive Systeme gestellt werden, einfacher erfüllenzu können.

6Quelle: [Ope16a]



3.4 RTE on Linux

Abbildung 3.5 EBSSHARP Hypervisor7

Im PC und Serverbereich ist der Einsatz eines Hypervisors bei der Virtualisierung vonBetriebssystemen inzwischen üblich und auch im Embedded Bereich ist er schon aufdem Vormarsch. Diese Hypervisor-Ansätze zeichnen sich durch eine starke Abschot-tung der Betriebssysteme untereinander aus. Dadurch ist die Kommunikation zwischenLinux und AUTOSAR natürlich eingeschränkt und die zusätzliche Zwischenschichtkann auch Nachteile hinsichtlich der Performance bringen. Weiterhin hat man einkomplexes Gesamtsystem und zusätzlich die Abhängigkeit an den Hypervisor. Dieserkann zwar portiert werden, doch gerade im Embedded Bereich bieten die Prozessor-hersteller oft eigene hardwarespezifische Lösungen an. Ein Vertreter mit relativ breiterHardwareunterstützung ist der PikeOS Hypervisor8.

Die Hypervisor-Ansätze sollen in dieser Arbeit nicht weiter betrachtet werden, da dieAbschottung verringert werden soll.

3.4 RTE on Linux

Unter RTE on Linux ist die direkte Ausführung einer AUTOSAR RTE innerhalb einesLinux-Systems zu verstehen.

Als ein Vertreter dieser Kategorie ist das Produkt COQOS-tP der OpenSynergy GmbH inAbb. 3.6 zu sehen. „Mit COQOS-tP können Entwickler AUTOSAR-konforme Software-

7Quelle: EB8https://www.sysgo.com/products/pikeos-rtos-and-virtualization-concept/


https://www.sysgo.com/products/pikeos-rtos-and-virtualization-concept/

Stand der Technik

Komponenten und Basissoftware-Module auf Linux oder einem POSIX-konformenBetriebssystem ausführen. COQOS-tP generiert eine AUTOSAR-konforme Laufzeit-umgebung und eine Adaptionsschicht zum Betriebssystem.“ ([Ope16b])

Abbildung 3.6 COQOS-tP9

Ein ähnlicher Ansatz wird in der Virtuellen Absicherungsplattform für AUTOSAR-Software (VAP) verfolgt. Hier wird unter einem Linux Betriebssystem mit Echtzeiter-weiterungen eine AUTOSAR RTE ausgeführt (vgl. [MCW12]).

Von Elektrobit wird derzeit kein Produkt vertrieben, dass die Entwicklung von AU-TOSAR Softwarekomponenten auf der Zielplattform Linux unterstützt. Für die her-kömmliche Automotive Steuergeräte existiert der komplette EB tresos AutoCore mitAUTOSAR OS, Mikrocontroller Abstraktionslayer und zahlreichen AUTOSAR Modu-len (vgl. Abb. 3.7).

In einem früheren Projekt bei Elektrobit wurde bereits ein AUTOSAR-OS entwickelt,das unter Linux läuft. Dieses hat den Namen LXTHREADSX86 OS und diente in demPraktikum „AUTOSAR: Portierung RTE auf Linux“ (vgl. [Jan15b]) als Ausgangspunkt.Dabei wurden zahlreiche AUTOSAR Module vom EB tresos WinCore (AutoCore unterWindows) zur Integration der AUTOSAR RTE unter Linux genutzt.

Das Ergebnis trägt den Namen „RTE on Linux“ bzw. „LinCore“ (vgl. Abb. 3.8).Damit lassen sich AUTOSAR SWCs direkt unter Linux ausführen. Es gibt allerdingsnoch offene Punkte, beispielsweise fehlt. wie in Abb. 3.8 zu sehen noch der kompletteKommunikations-Stack.

9Quelle: [Ope16b]



3.4 RTE on Linux

Abbildung 3.7 EB tresos AutoCore 7 based on AUTOSAR 4.0.3 & RfCs 4.1.x / 4.2 10

Abbildung 3.8 LINUX/LXTHREADSX86 OS - Simple Demo RTE11

10Quelle: EB11In Anlehnung an Abb. 3.7


Stand der Technik

Der Vorteil von der „RTE on Linux“ ist, dass es auf jedem System mit Linux läuft.Das System ist außerdem bei Nutzung der PREEMPT_RT Erweiterungen des LinuxKernels begrenzt echtzeitfähig. Eine Portierung auf QNX12 oder generell ein POSIX-Betriebssystem wäre möglich.

12https://de.wikipedia.org/wiki/QNX



https://de.wikipedia.org/wiki/QNX

Kapitel 4

AUTOSAR und Linux

Dieses Kapitel beschäftigt sich mit der Koexistenz von AUTOSAR Softwarekomponen-ten und Linux-Programmen auf einem gemeinsamen Steuergerät. Dabei soll es ermög-licht werden AUTOSAR-Komponenten direkt innerhalb einer Linux-Umgebung auszu-führen (vgl. Abb. 4.1, Tegra). Weiterhin soll eine Schnittstelle definiert werden, welchedie Kommunikation zwischen AUTOSAR-Komponenten und Linux-Applikationenermöglicht (vgl. Abb. 4.1, CDD Linux Proxy, Linux App.).

Abbildung 4.1 Konzeptidee zur Softwarearchitektur des Gesamtsteuergerätes1

In diesem Kapitel werden Lösungsansätze zur Ausführung von AUTOSAR-Kompo-nenten (Module, Softwarekomponenten) unter Linux vorgestellt, Möglichkeiten zur

1Quelle: EB


AUTOSAR und Linux

Implementierung der Kommunikation zwischen AUTOSAR-Komponenten und Linux-Applikationen gegenübergestellt und schließlich das Konzept zur Implementierungerläutert.

4.1 Ausführen von AUTOSAR-Komponenten unterLinux

Es soll die Nutzung von bereits bestehenden AUTOSAR-Komponenten sowie vonBasissoftwaremodulen, welche beispielsweise die im Fahrzeug verwendeten Kommuni-kationsprotokolle umsetzen, ermöglicht werden.

Hierbei kristallisieren sich zwei grundlegende Ansätze zur Implementierung heraus.Zum einen nur die Emulation der AUTOSAR RTE und grundlegender BSW-Schnittstellenzu den Softwarekomponenten. Zum anderen ist dies die komplette Implementierungdes AUTOSAR OS unter Linux.

4.1.1 Entwicklung eines AUTOSAR-RTE Layers für Linux

Bei diesem Ansatz wird nur die AUTOSAR-RTE unter Linux emuliert. Dazu musseine Bibliothek entwickelt werden, die den Softwarekomponenten grundlegende Funk-tionen der AUTOSAR-RTE sowie der Basissoftware zur Verfügung stellt. Zu diesenFunktionen zählen beispielsweise der Zeit-gesteuerte Aufruf von Runnables oder dieKommunikation über den Virtual Functional Bus (VFB) (vgl. Abb. 4.2).



4.1 Ausführen von AUTOSAR-Komponenten unter Linux

Abbildung 4.2 AUTOSAR SW-C Descriptions und VFB2

AUTOSAR Softwarekomponenten werden dabei als normale Linux-Anwendungen(Prozesse) ausgeführt wobei die Kommunikation über den VFB unter Linux durchInterprozesskommunikation realisiert wird (vgl. Abb. 4.3).

Alle notwendigen Informationen über die Schnittstellen einer Softwarekomponente zurBasissoftware sowie zu anderen Softwarekomponenten sind dabei in deren SoftwareComponent Description (SW-C Description) enthalten sodass für jede Softwarekom-ponente ein spezifischer Wrapper (Abstraction Layer) automatisch generiert werdenkönnte.

Abbildung 4.3 RTE Abstraction Library3

2Quelle: [AUT22b, S. 10]3In Anlehnung an Abb. 4.2


AUTOSAR und Linux

Dieser Ansatz ist für einfache Softwarekomponenten realisierbar, doch für Module oderCDDs, die direkt Funktionen des AUTOSAR OS nutzen, müsste nahezu das gesamteAUTOSAR OS emuliert werden.

4.1.2 Nutzung des kompletten AUTOSAR OS unter Linux

Bei diesem Ansatz wird das gesamte AUTOSAR OS auf Linux portiert. Dabei werdenalle in der AUTOSAR OS Spezifikation spezifizierten Funktionen auf Linux Funktionenabgebildet beziehungsweise anderweitig emuliert.

Dies ermöglicht das Ausführen von nahezu unveränderten AUTOSAR Modulen, derAUTOSAR RTE und Softwarekomponenten unter Linux.

Dieser Ansatz wurde im vorangegangen Praktikum (vgl. [Jan15b]) begonnen und wirdunter Abschnitt 5.1 „EB tresos LxCore - Der AUTOSAR Stack unter Linux“ weiterverfolgt.

4.2 Kommunikation zwischen AUTOSAR-Komponen-ten und Linux-Applikationen

In diesem Abschnitt werden grundlegende Designziele, Möglichkeiten zur Implemen-tierung als auch Designentscheidungen für die Umsetzung der Kommunikationsschnitt-stelle zwischen AUTOSAR Softwarekomponenten und Linux-Programmen erläutert.

4.2.1 Designziele

Aus der Aufgabenstellung der Masterarbeit lassen sich folgende Ziele zur Implementie-rung ableiten:

• Effiziente Kommunikation: „Wie kann eine effiziente Kommunikation zwi-schen AUTOSAR-Komponenten und Linux-Applikationen umgesetzt werden?“

• Einfacher Einsatz bestehender Linux-Applikationen: Es soll der Einsatz vonbestehenden Linux-Applikationen erleichtert werden. Eine normale Linux-Appli-kation soll ohne großen Mehraufwand mit einer AUTOSAR Softwarekomponentekommunizieren können.

Daraus lassen sich weiterhin folgende Ziele ableiten bzw. ergänzen:



4.2 Kommunikation zwischen AUTOSAR und Linux

• Geringe Verzögerungszeit: Die Übertragungszeiten der Nachrichten sollen kurzsein.

• Berechenbarkeit: Es soll wenig Jitter bei den Übertragungszeiten auftreten.

• Kein Nachrichtenverlust: Keine Daten sollen verloren gehen.

• Datenintegrität: Die Daten sollen unverändert beim Empfänger ankommen.

• Nutzung von AUTOSAR Schnittstellen: Zum Datentransfer sollen AUTOSARkonforme Schnittstellen (RTE Ports, BSW Service Ports) genutzt werden.

• Geringe CPU und Speichernutzung: Das Kommunikationsmodul soll wenigzusätzliche CPU Last verursachen, z.B. durch zyklische Tasks die jede Millise-kunde überprüfen ob neue Daten da sind.

• Einfache Nutzung durch Integrator und Anwender: Es soll sich leicht in einbestehendes AUTOSAR Projekt integrieren und nutzen lassen.

• Programmiersprachenunabhängiges Interface: Das Interface zwischen AU-TOSAR und Linux soll sich mit beliebigen Programmiersprachen nutzen lassen.Das erleichtert den Einsatz bestehender Linux-Applikationen.

4.2.2 Möglichkeiten zur Implementierung

Die Ausgangsidee zur Realisierung der Kommunikation zwischen AUTOSAR Softwa-rekomponenten und Linux Anwendungen war eine beliebige Art AUTOSAR-Modul,CDD oder „Linux Proxy“, der die Schnittstelle realisiert (vgl. Abb. 4.1, CDD LinuxProxy). Hier sollen zunächst Möglichkeiten zur Implementierung auf AUTOSAR Mo-dellebene gegenüber gestellt werden.

Implementierung als CDD

Die erste und verbreitetste Möglichkeit ist die Umsetzung als CDD. Ein CDD erlaubtdie Integration beliebiger Software in den AUTOSAR Stack.

Bei dieser Implementierungsart wird auf Modellebene ein Complex Device Driver zurRealisierung der Kommunikation zwischen AUTOSAR Softwarekomponenten undLinux Anwendungen gewählt. Die Softwarekomponente kommuniziert über die RTEmit dem CDD und der CDD übernimmt dann die Weiterleitung der Daten an eine LinuxAnwendung, beispielsweise über einen Unix Domain Socket (vgl. Abb. 4.4).


AUTOSAR und Linux

Diese Implementierungsart hat den Vorteil, dass sie sich einfach und schnell umsetzenlässt. Die Softwarekomponenten bleiben prinzipiell portabel und haben nur einen weite-ren Port zum CDD. Für den eigentlichen Datenaustausch mit der Linux-Anwendungkönnen praktisch beliebige Verfahren zur Interprozesskommunikation unter Linux ge-nutzt werden (vgl. Abschnitt 2.1.3 „Interprozesskommunikation (IPC)“). Allerdingsmuss der CDD für jede weitere Softwarekomponente, die Daten übertragen will, manu-ell angepasst werden. Im System Modell müssen weitere Ports zu dem CDD hinzugefügtwerden und der Quelltext des CDD muss editiert werden.

Abbildung 4.4 Implementierung als CDD4

Implementierung über Com und PduR

Der generelle Weg zur Kommunikation mit externen ECUs führt bei AUTOSAR überden Com-Stack und den PDU-Router. Dabei gibt es unterhalb des PDU-Routers ver-schiedene busspezifische Module (Netzwerkschichten), zum Beispiel für CAN, FlexRayund LIN. Bei dieser Variante würde man jetzt ein weiteres Modul für die Interprozess-kommunikation hinzufügen (vgl. Abb. 4.5).

4In Anlehnung an Abb. 3.7




Eine AUTOSAR Softwarekomponente kommuniziert dabei über die RTE mittels Signa-len mit dem COM-Stack, dieser packt die Signale in PDUs und versendet sie durch denPDU-Router über die busspezifischen Module (vgl. Abb. 4.6).

Oberhalb des PDU-Routers ist die komplette Kommunikation dabei netzwerkunabhän-gig. Das bedeutet für eine Softwarekomponente ist es egal über welchen Bus die Datenversendet werden, an dem Interface ändert sich nichts. Die Konfiguration des Routingsder Nachrichten findet im PDU-Router statt.

Abbildung 4.5 Implementierung über Com und PduR5



AUTOSAR und Linux

Abbildung 4.6 AUTOSAR: Communication Stack Architecture Overview6

Bei der Implementierung der Interprozesskommunikation können dabei TransportLayer (IPC TP) und Interface (IPC Interface) zu einem Softwaremodul kombiniertwerden. Der IPC Driver greift beispielsweise direkt auf die POSIX API des LinuxKernels zu. Da unter Linux noch keine CAN, FlexRay, LIN oder Ethernet spezifischenNetzwerkschichten vorhanden sind, ergibt sich die in Abb. 4.7 dargestellte Architektur.

Abbildung 4.7 IPC Kommunikation über PDU Router7

6Quelle: EB7In Anlehnung an Abb. 4.6




Bei dieser Implementierungsart bleiben die Softwarekomponenten ebenfalls portabel.Die Kommunikation erfolgt über die RTE und die eigentliche Netzwerkschicht kannleicht ausgetauscht werden. Das Verfahren für die eigentliche Interprozesskommuni-kation kann frei gewählt werden. Allerdings rufen Com und PDU-Router einiges anOverhead hervor und auch die Konfiguration des Com-Stacks und des PDU-Routers istnicht trivial. Unter anderem muss für jede zu übertragende Nachricht eine PDU mit derexakten, oder zumindest maximalen Größe der zu erwartenden Nachricht konfiguriertwerden.

Implementierung über AUTOSAR IP Stack mit SOME/IP

Bei der Implementierungsart über SOME/IP wird der Standard AUTOSAR IP / SO-ME/IP Stack verwendet. Im EB tresos WinCore ist dieser bereits enthalten. Die Modulemüssen in den AUTOSAR Stack unter Linux integriert werden (vgl. Abb. 4.8) undWindows-spezifische Bestandteile müssen portiert werden.

Abbildung 4.8 IPC via AUTOSAR IP Stack with SOME/IP8

Auch hier bleiben die Softwarekomponenten portabel. Zusätzlich erfolgt die Kommu-nikation netzwerktransparent, d.h. die Kommunikation kann lokal auf der gleichenECU oder mit einer über Ethernet per Netzwerk verbundenen ECU erfolgen. Normale



AUTOSAR und Linux

Linux-Applikationen können beispielsweise die GENIVI SOME/IP Bibliothek zurKommunikation mit den AUTOSAR Komponenten verwenden. Auf Linux Seite fehltder komplette AUTOSAR Com-Stack noch. Weiterhin ist der SOME/IP Stack ziemlichkomplex, selbst um eine einfache Kommunikation zwischen zwei Standard AUTOSARSteuergeräten zu konfigurieren (Interface Beschreibung, Publish/Subscribe, Abhängig-keiten zwischen den Modulen). Auch sollte der durch den SOME/IP Stack verursachteOverhead nicht vernachlässigt werden.

Implementierung als konfigurierbares Modul

Die Implementierung als konfigurierbares Modul vereint die Vorteile und Freiheiteneines einfachen CDD mit denen eines AUTOSAR Moduls. Der CDD wird in der Arteines AUTOSAR Moduls als EB tresos Studio Plugin entwickelt. Somit ist es möglichein Konfigurationsinterface in EB tresos Studio zu erstellen und Quelltextbestandteiledynamisch zu generieren. Da das Modul nicht im AUTOSAR Standard spezifiziert ist,ist es eigentlich ein CDD, verhält sich aber wie ein Modul.

Die Softwarekomponenten bleiben portabel und haben einen weiteren Port zur Kommu-nikation mit dem Modul. Dieser muss bei Integration der Softwarekomponente in eineandere Architektur nicht zwangsweise verbunden werden, oder kann, auf einer anderenZielplattform, mit einem ähnlichen Modul verbunden werden. Die Anzahl der Portsdes Moduls als Schnittstelle zur RTE und zu Softwarekomponenten lassen sich überdas Konfigurationsinterface in EB tresos Studio leicht konfigurieren und der Quelltextdes Moduls kann dynamisch generiert werden und muss nicht mehr manuell angepasstwerden. Für grundlegende Kommunikation des Moduls mit den Linux-Applikationensind weiterhin beliebige IPC-Mechanismen möglich und der Mehraufwand im Vergleichzur Implementierung als einfacher CDD ist vertretbar.

IPC Bibliothek einbinden und direkt aus SWC nutzen

Aus einer Softwarekomponente unter Linux kann prinzipiell jede beliebige Linux Bi-bliothek genutzt werden. Somit könnte man also beispielsweise eine weitere Bibliothekzur Interprozesskomunikation zum Projekt linken und aus der Softwarekomponentedirekt deren Funktionen nutzen.

Dies ist zwar einfach und schnell umsetzbar doch dieser Ansatz wäre nicht AUTOSAR-konform. Softwarekomponenten wären nicht mehr portabel. Der Ansatz ist nicht indie Toolkette integriert und der modellbasierte Entwicklungsprozess von AUTOSAR




würde unterbrochen werden. Die Kommunikationsschnittstelle ist nicht mehr im Mo-dell als Port an der Softwarekomponente ersichtlich. Zusätzlich hat man manuelleArbeit, da man sich in jeder Softwarekomponente um das initialisieren und starten derKommunikationsverbindung kümmern muss.

4.2.3 Designentscheidungen

Anhand der Designziele, unter Einbezug der Vorteile und Nachteile der unter Ab-schnitt 4.2.2 aufgeführten Implementierungsarten und der begrenzten Zeit der Mas-terarbeit wurde entschieden, dass die Umsetzung als CDD und bei genügend Zeit dieÜberführung in ein konfigurierbares Modul am sinnvollsten ist.

Aus dem Ziel eine Einfache Nutzung aus bestehenden Linux-Applikationen zu ermögli-chen ergeben sich folgende Designentscheidungen:

• Kommunikation über Sockets:

Es gibt zahlreiche IPC Mechanismen unter Linux (vgl. Abschnitt 2.1.3). Die Kom-munikation über Sockets ist einfach und praktisch von jeder Programmierspracheaus möglich.

• Verwendung von Unix Domain Sockets:

Mit Unix Domain Sockets lassen sich direkt die AUTOSAR Ports abbilden. Siehaben Namen und lassen sich leicht im Dateisystem auffinden. Zugriffsrechtelassen sich über Dateirechte setzen und es werden keine zusätzlichen Firewallre-geln notwendig. Sie sind zwar nicht netzwerktransparent, aber der Übergang zuTCP/IP Sockets, falls erforderlich, ist möglich.

Zudem bieten sie eine gute Performance. „Besondere Eigenschaften von UNIX-Domain-Sockets sind, dass diese vollduplex und auch schneller als TCP-Socketssind. Letzteres ist natürlich nur von Vorteil, wenn sich der Server und der Clientauf demselben Rechner befinden. Das X-Window-System nutzt daher die UNIX-Domain-Sockets.“ ([Wol06])

• SOCK_SEQPACKET:

Für die Sockets soll der Typ SOCK_SEQPACKET verwendet werden.

Es gibt verschiedene Arten von Sockets. Aus der POSIX Spezifikation zumThema Sockets:


AUTOSAR und Linux

– SOCK_STREAM: „Provides sequenced, reliable, bidirectional, connection-mode byte streams, and may provide a transmission mechanism for out-of-band data.“ ([TT13b])

– SOCK_DGRAM: „Provides datagrams, which are connectionless-mode,unreliable messages of fixed maximum length.“ ([TT13b])

– SOCK_SEQPACKET: „Provides sequenced, reliable, bidirectional, connec-tion-mode transmission paths for records. A record can be sent using oneor more output operations and received using one or more input operations,but a single operation never transfers part of more than one record. Recordboundaries are visible to the receiver via the MSG_EOR flag.“ ([TT13b])

Sockets vom Typ SOCK_SEQPACKET haben den Vorteil, dass sie zuverlässige,bidirektionale verbindungsorientierte Datenübertragung wie Sockets vom TypSOCK_STREAM erlauben und zusätzlich die Nachichtengrenzen erhalten wieSockets vom Typ SOCK_DGRAM.

Damit haben wir leicht die Möglichkeit zu detektieren wenn sich ein Client mitdem DsCom Modul verbindet oder wieder trennt. Zudem können Fehler beidem Übertragen detektiert werden und wir können direkt Nachrichten übertragenund nicht nur Streams, d.h. wir müssen uns nicht selber um die Begin- undEnde-Codierung der Nachrichten kümmern.

• Ein Socket für jeden Port:

Für jeden Port einer Softwarekomponente soll ein eigener Socket angelegt werden.Somit ist für eine externe Anwendung schon durch die Wahl des Sockets festgelegtan welche Softwarekomponente und an welchen Port die Daten gesendet werdensollen und es muss nicht mit jeder Nachricht eine Zieladresse oder ähnlichesmitgesendet werden.

Weiterhin soll eine effiziente Kommunikation sichergestellt werden, daraus ergebensich folgende Designentscheidungen:

• Kein Polling, Event-basiert: Um möglichst kurze Reaktionszeiten zu realisierennutzen wir kein Polling, d.h. eine Softwarekomponente muss nicht zyklischüberprüfen ob neue Nachrichten empfangen wurden, sondern ein Runnable wirdbei eintreffen neuer Nachrichten direkt getriggert.

• Blockierende Sockets

Ein Background-Thread wird genutzt, der in einer Endlosschleife versucht blo-ckierend vom Socket zu lesen, er blockiert und wartet wenn keine Daten vor-



4.3 Konzept zur Implementierung

handen sind, und sobald Daten empfangen wurden liest er diese aus leitet sieweiter.

• Zero-Copy: Um eine effektive Datenübertragung zu ermöglichen sollen Nach-richten zwischen Sender und Empfänger selten kopiert werden. Anstatt die Buffervom Modul zu kopieren wird nur ein Pointer an die SWC übergeben.

Weiterhin wurden folgende Entscheidungen getroffen:

• Keine eigene Serialisierung

Die Daten werden direkt als Byte-Stream übertragen. Es wird keine eigene Serial-oder Deserialisierung (vgl. Abschnitt 2.1.4) im Modul umgesetzt.

• Kein dynamischer Speicher Keine Nutzung von dynamischem Speicher direktinnerhalb der Softwarekomponenten. Beim Empfangen von Nachrichten könntedynamisch Speicher allokiert werden und der Softwarekomponente der Pointerzu diesem übergeben werden. Der Anwender müsste dann in der Softwarekom-ponente dafür Sorge tragen, dass der Speicher wieder frei gegeben wird. Das istunzuverlässig.

• Keine neuen Abhängigkeiten Es sollen keine zusätzlichen externen Bibliothe-ken genutzt werden. Das Ziel ist den Code des AUTOSAR Stacks unter Linuxklein und wartbar zu halten und nur POSIX-Schnittstellen zu nutzen.

4.3 Konzept zur Implementierung

Für das Ausführen von AUTOSAR-Komponenten unter Linux wird auf die Erfahrungenaus dem LinCore aus dem vorangegangen Praktikum zurückgegriffen. Dieser Ansatzhat sich bereits als umsetzbar erwiesen. Der LinCore wird neu gebaut und aufgrundder Namensähnlichkeit von Lin (Linux) zu LIN (der Datenbus) in LxCore umbenannt.Das AUTOSAR OS (LXTHREADSX86) wird hierbei von Version 5.1.12 auf 6.0.6aktualisiert und mit den Modulen vom derzeit aktuellen WinCore ACG 7.4 integriert.Dies dient dann als Grundlage zur Implementierung des Kommunikationsmoduls.

Die Umsetzung der Kommunikationsschnittstelle erfolgt als CDD mit anschließenderÜberführung in ein Modul (EB tresos Studio Plugin) unter Berücksichtigung der unterAbschnitt 4.2.3 getroffenen und begründeten Designentscheidungen.


Kapitel 5

Implementierung

Das Kapitel Implementierung ist in drei Teile gegliedert. Der erste Teil beschäftigtsich mit dem EB tresos LxCore, einer Softwarelösung zum Ausführen von AUTOSARSoftwarekomponenten und Modulen unter Linux.

Die Implementierung des Kommunikationsmoduls zwischen AUTOSAR Softwarekom-ponenten und Linux Anwendungen wird im zweiten Teil beschrieben.

Schließlich demonstriert der dritte Teil den AUTOSAR Workflow und die Methodologieanhand eines Beispielprojektes mit dem Kommunikationsmodul auf der Zielplattform.

5.1 EB tresos LxCore - Der AUTOSAR Stack unterLinux

Der EB tresos LxCore erlaubt das Ausführen von AUTOSAR Komponenten auf derZielplattform Linux. Er besteht aus dem EB tresos Studio als Entwicklungsumge-bung, dem AUTOSAR OS LXTHREADSX86, einem Platforms Plugin, generischenplattformunabhängigen AUTOSAR Modulen wie der AUTOSAR RTE sowie einemSimpleDemoRte Projekt.

5.1.1 Umsetzung

Als Ausgangspunkt für die Implementierung dienen der EB tresos WinCore (ACG-7.4,B102822) sowie das EB tresos AutoCore OS LINUX LXTHREADSX86 (Version6.0.6).


Implementierung

Die komplette Integration des AUTOSAR OS für Linux mit dem Modulen vom WinCoreist detailliert in der LxCore Integration Guide beschrieben (vgl. [Jan15d]). Nachfolgendewerden die wichtigsten Schritte zusammengefasst.

Sowohl der WinCore als auch das AutoCore OS für Linux werden mit einem komplettenEB tresos Studio ausgeliefert. Während in der Auslieferung für das OS nur das OSPlugin, das Make Plugin, Dokumentation sowie ein OS MultiCore Demo Projektenthalten ist, beinhaltet der WinCore rund hundert Module aus dem ACG.

Der erste Schritt ist hier das OS MultiCore Demo Projekt mit dem OS und dem MakePlugin (vgl. Abb. 5.1) auf der Zielplattform kompiliert und ausgeführt zu bekommen(vgl. [Jan15d, S. 10-18]).

Abbildung 5.1 LXTHREADSX86 OS MultiCore Demo Projekt

In der OS Konfiguration kann man bereits Tasks hinzufügen, Schedule Tables anlegen,Events erstellen und ISRs konfigurieren. Somit verhält es sich von außen hin wie einherkömmliches AUTOSAR OS auf normalen Automotive Steuergeräten (vgl. Abb. 5.2).

Abbildung 5.2 LXTHREADSX86 OS Konfiguration

Die Generierung der dynamischen Code-Bestandteile findet dabei unter Windowsmit EB tresos Studio statt (make generate) und während des Kompilierens (make



5.1 EB tresos LxCore - Der AUTOSAR Stack unter Linux

compile) werden dann die generierten und statischen Quelltextbestandteile per SecureShell (SSH) auf die Zielplattform kopiert und dort mit dem GCC Compiler unter Linuxkompiliert.

Ziel ist jetzt ein SimpleDemoRte Projekt mit dem Linux AUTOSAR OS zu erstellen,ähnlich dem SimpleDemoRte Projekt vom WinCore (vgl. Abb. 5.3).

Abbildung 5.3 WinCore SimpleDemoRte Projekt

Dazu müssen noch die fehlenden BSW-Module mit dem Linux AutoCore OS integriertwerden, sodass die RTE und Softwarekomponenten oberhalb der RTE ausgeführtwerden.

Die Module Base (Standard Header Dateien), BswM (Basic Services und Mode Mana-gement), Dem (AUTOSAR Diagnostic Event Manager), Det (AUTOSAR DevelopmentError Tracer), EcuM (AUTOSAR EcuM State Manager), Mcu (nur Stubs, auch im Win-Core), MemMap (AUTOSAR Memory Mapping), PbcfgM (Post Build ConfigurationManager) und Rte sind dabei generisch und plattformunabhängig. Make (Buildumge-bung) und OS sind bereits vorhanden und das Plattforms Plugin (Makefiles) kann leichtaus dem Plattforms Plugin vom WinCore und den Makefiles aus der OS MulticoreDemo vom Linux AutoCore OS erstellt werden (vgl. [Jan15d, S. 20]).


Implementierung

Nach der Konfiguration des EB tresos Studio Projekts, dem Hinzufügen der fehlendenModule, dem Konfigurieren der Module, dem Importieren des System Modells undKopieren des Quelltextes der SimpleRteDemo vom WinCore sowie dem Beheben zahl-reicher Konfigurations- und Build-Probleme kann des Projekt und die RTE schließlichgeneriert und kompiliert werden (vgl. [Jan15d, S. 21-41]).

Dabei ist die Ausgabe aber immer noch die gleiche wie bei der OS MultiCore Demo(vgl. Abb. 5.4), denn die neuen Module und Quelltextbestandteile müssen erst nochvom OS aufgerufen werden.

Abbildung 5.4 LxCore SimpleDemoRte mit gleicher Ausgabe wie OS MultiCore Demo

Um dies zu ändern müssen, in den ursprünglich aus der OS MultiCore Demo stam-menden Dateien, der Aufruf von StartCore() und die Aufrufe von StartOS() fürjeden Prozessorkern durch einen einzigen Aufruf von EcuM_Init() ersetzt werden.Damit übernimmt EcuM, der seit ACG 7.4 MultiCore Unterstützung hat, das Starten derOS-Instanzen für jeden Kern. Hinzu kommt noch ein Aufruf von EcuM_StartupTwo()und BswM_RequestMode() im InitTask und die RTE und die von der RTE und weiterenModulen generierten Tasks und Schedule Tables werden gestartet (vgl. [Jan15d, S.42-44]).

5.1.2 Funktionsweise

Ähnlich wie auf einem Embedded System werden beim Kompilieren das AUTOSAROS, die RTE und alle Softwarekomponenten zu einer einzigen ausführbaren Binärdateizusammengefügt.

Softwarekomponenten, die Runnables enthalten, werden dabei in RTE-Partitionengemappt und diese wiederum gehören zu OS-Applikationen. OS-Applikationen sind



5.2 DsCom - Interprozesskommunikation zwischen AUTOSAR und Linux

Container von Tasks und weiteren OS-Objekten, die gesammelt einem CPU-Kernzugewiesen werden.

Die Runnables einer SWC laufen dann in OS-Tasks, die zu der OS-Applikation gehören,zu welcher auch die RTE-Partition zugeordnet ist, in der die SWC läuft.

In der AUTOSAR OS Implementierung für Linux ist dabei die gesamte AUTOSAR-Umgebung ein einziger Linux-Prozess. Jeder OS-Task und auch ISR ist ein Linux-Thread, der entsprechend seiner Zugehörigkeit zu einer bestimmten OS-Applikation aufeinen bestimmten CPU-Kern gemappt ist. Es gibt außerdem noch einen Helper-Threadauf jedem Kern, der das Thread-Management übernimmt - dieser überwacht, dassimmer nur ein OS-Task pro Kern gleichzeitig aktiv ist.

5.2 DsCom - Interprozesskommunikation zwischenAUTOSAR und Linux

Das DsCom Modul erlaubt die direkte Kommunikation zwischen AUTOSAR Soft-warekomponenten auf dem LxCore und generischen Linux-Anwendungen über UnixDomain Sockets. Die Platzierung des DsCom Moduls in der Gesamtsoftwarearchitektureiner Linux basierten ECU ist in Abb. 5.5 dargestellt.

Eine mit dem Modul verbundene Softwarekomponente (vgl. Abb. 5.5, AUTOSAR SWCIPC) sendet und empfängt dabei Daten über RTE Ports und das Modul realisiert dieKommunikation mit der Linux Anwendung (vgl. Abb. 5.5, Generic Linux Application).


Implementierung

Abbildung 5.5 DsCom Architektur Überblick1

5.2.1 Umsetzung als einfacher CDD

Bei der Umsetzung als einfacher CDD wird DsCom Modul zusammen mit allen anderenSoftwarekomponenten des jeweiligen Projekts mit dem Tool SystemDesk modelliertund zusammen als Gesamtsystem exportiert.

Dazu wird im System Model eine neue Softwarekomponente mit Typ Complex DeviceDriver SW Component erstellt (vgl. Abb. 5.6, CDD_DsCom). Dies ist in der LxCoreusers guide im Abschnitt „Creating a new SWC or CDD“ beschrieben (vgl. [Jan15e,S. 16-29]). Anschließend müssen Ports zur Kommunikation mit anderen Software-komponenten, die Daten über das DsCom Modul empfangen oder versenden wol-len, hinzugefügt werden. Dazu wurden in Abb. 5.6 die Ports R_DataOut_IpcTest,P_DataIn_IpcTest, R_DataOut_MsgR und P_DataIn_MsgR angelegt.

1Quelle: EB




Abbildung 5.6 DsCom als CDD Ausschnitt TopLevelComposition in SystemDesk

Die Art des Ports und die Art der Daten, die über diesen transportiert werden, werdendabei vom Port Interface bestimmt. Hier wurden Client-Server Interfaces gewählt diejeweils einen Datenpointer auf einen Puffer und eine Länge übergeben (vgl. Abb. 5.7).Diese Interfaces werden dann dem Port zugewiesen (vgl. Abb. 5.8, unterer Teil).

Abbildung 5.7 Client Server Interface If_FwdData

Wenn der CDD_DsCom jetzt Daten von einer Linux Anwendung empfangen hat, würdedieser beispielsweise über den Required Port R_DataOut_MsgR am Provided PortP_DataIn der Softwarekomponente CDD_MessageRouter ein Runnable triggern unddiesem als Parameter den Pointer auf die empfangenen Daten sowie die Länge derempfangenen Daten übergeben.

Der umgekehrte Weg, dass eine Softwarekomponente Daten versendet erfolgt analog.Hier triggert die Softwarekomponente über einen Provided Port am CDD_DsComein Runnable und übergibt diesem einen Datenpointer und eine Länge. Dieser Aufrufwird dabei von der RTE als direkter Funktionsaufruf realisiert. Der Funktionsaufrufist blockierend und kehrt erst zurück wenn die Daten übertragen wurden und derDatenpointer nicht mehr länger benötigt wird.


Implementierung

Bei einem einfachen CDD muss dazu für jede verbundene Softwarekomponente ein neu-er Required Port zum Senden von Daten, ein Provided Port zum Empfangen von Daten,sowie ein Runnable, das beim Empfangen von Daten getriggert wird, angelegt wer-den. Bei der in Abb. 5.6 dargestellten Variante mit 2 verbunden Softwarekomponenten(CDD_MessageRouter, SWC_IPC_Test) sind das die Runnables RE_TransmitData_-MessageRouter und RE_TransmitData_IpcTest (vgl. Abb. 5.8).

Abbildung 5.8 DsCom als CDD Aufbau im Project Manager von SystemDesk

Das fertige System Model wird anschließend exportiert und kann in EB tresos Studioimportiert werden. Der Code-Generator generiert anschließend Prototypen für die mo-




dellierten Funktionen (vgl. Anhang A: CDD_DsCom_Template.c) welche anschließendmit Leben gefüllt werden müssen.

Unter diesen Prototypen findet sich beispielsweise das oben angesprochene RunnableRE_TransmitData_MessageRouter, dass in der Funktionssignatur die Parameter ausdem Interface If_FwdData enthält (vgl. Auflistung 5.1).

1 vo id CDD_DsCom_RE_TransmitData_IpcTest (P2VAR( u i n t 8 , AUTOMATIC,RTE_APPL_DATA) D a t a P t r , u i n t 3 2 DataLen )

2 {3 S td_Re tu rnType s t a t u s ;4 }

Auflistung 5.1 Funktionsprototyp RE_TransmitData_MessageRouter

Die innere Funktionsweise des CDD soll hier jedoch nicht weiter erläutert werden,diese wird bei der Umsetzung als Plugin unter Abschnitt 5.2.5 detailliert erläutert.

5.2.2 Umsetzung als EB tresos Studio Plugin

Bei der Umsetzung als Plugin ist das Ziel dem Entwickler Arbeit abzunehmen. Es sollennicht mehr für jede verbundene Softwarekomponente manuell Ports am DsCom Modulangelegt werden müssen und auch der Quelltext soll nicht mehr editiert werden müssen.Dazu wird ein Konfigurationsinterface in EB tresos Studio erstellt und der TemplateBased Code Generator genutzt.

In dem Konfigurationsinterface können dann sogenannte Verbindungen (DsComConnec-tions, vgl. Abb. 5.13) angelegt werden. Jede dieser Verbindungen realisiert dabei dieVerbindung zwischen dem Modul und einer Softwarekomponente (vgl. Abb. 5.5, Verbin-dung zu AUTOSAR SWC IPC und CDD MessageRouter). Für jede dieser Verbindungenwerden später vom Modul RTE Service Ports zur Kommunikation mit einer verbun-denen Softwarekomponente sowie ein Unix Domain Socket zur Kommunikation mitgenerischen Linux-Anwendungen angelegt.

Im Vergleich zur Umsetzung als einfachen CDD hat man bei der Umsetzung als Modulkeine zusätzliche Softwarekomponente / CDD im SystemDesk Modell mehr, sondernRTE Service Ports zum DsCom Modul an den Softwarekomponenten, die das Ds-Com Modul verwenden. Diese werden in SystemDesk defaultmäßig grau schraffiertdargestellt (vgl. Abb. 5.9, P_DsCom_Receive, R_DsCom_Transmit).


Implementierung

Abbildung 5.9 DsCom als Modul Ausschnitt aus TopLevelComposition in SystemDesk

Die Integration des DsCom Moduls in ein Projekt ist im Abschnitt 5.3 „WorkflowLxCore und DsCom“ genauer beschrieben.

5.2.3 Erstellen eines neuen tresos Studio Plugins

Zur Entwicklung eines neuen EB tresos Studio Plugins gibt es zwei Möglichkeiten,zum einen über EBA WorkSpace2 , Elektrobits interne Entwicklungsumgebung fürAUTOSAR Module in der Produktentwicklung, zum andern über den manuellenunter „Developing modules“ in der EB tresos Studio developer’s guide beschrie-benen Weg (vgl. [Ele14, S. 50-123]). Dabei geht man entweder Schritt für Schrittvor oder nutzt eines der beiden Templates für neue Module (vgl. [Ele14, S. 101],TemplateGenerator_TS_T00D0M0I0R0, PublicApiTest_TS_T00D0M0I0R0).

Anstelle dieser Templates kann auch ein vorhandenes, nicht zu kompliziertes Modul,dass in etwa die Anforderungen erfüllt, als Grundlage genommen werden und unter Zu-

2EB AutoCore WorkSpace, Standard Entwicklungsumgebung für das gesamte AutoCore Produkt




hilfenahme der Informationen aus der Studio developer’s guide entsprechend abgeändertwerden.

Für das DsCom Modul diente das StbM Modul als Grundlage. Es wurde schrittweiseangepasst und die Funktionalität aus dem CDD integriert (vgl. Abb. 5.10).

Abbildung 5.10 DsCom im Versionskontrollsystem

Für Best-Practice-Methoden zur Lösung häufig auftretender Problemstellungen (z.B.Service Needs, Port Definded Arguments) ist es zudem ratsam den Quelltext vonanderen Modulen mit ähnlichen Anforderungen zu Rate zu ziehen.

5.2.4 Der Template Based Code Generator

Bei der Umsetzung als Modul dient der Template Based Code Generator zur Gene-rierung der konfigurationsspezifischen Quelltextbestandteile. Er ist in der EB tresosStudio developer’s guide unter „Template-based Code Generator API“ beschrieben(vgl. [Ele14, S. 213-227]).

Ein Plugin in EB tresos Studio besteht aus statischen und generierten Quelltextdateien.In Abb. 5.11a ist die Ordnerstruktur des DsCom Moduls zu sehen, die Templates zurGenerierung befinden sich im Unterordner generate und generate_swcd. Nach derGenerierung befinden sich die generierten Dateien dann im Projektverzeichnis unteroutput/generated (vgl. Abb. 5.11b).


Implementierung

(a) Verzeichnissstruktur Modul

(b) Verzeichnissstruktur Projekt

Abbildung 5.11 Verzeichnisstruktur DsCom Modul und Projekt




Wie funktioniert jetzt die Generierung? Im Verzeichnis DsCom_TS_T36D1M1I0R0\config\ gibt es eine Datei DsCom.xdm, diese dient als Basis für das Konfigurati-onsinterface in EB tresos Studio.

In dieser Datei gibt es beispielsweise einen Abschnitt zur Konfiguration der Puffergröße(vgl. Auflistung 5.2).

1 . . .2 <v : c t r name=" DsComGeneral " type =" IDENTIFIABLE">3 . . .4 <v : v a r name=" DsComBufferSize " type ="INTEGER">5 <a : a name="DESC">6 <a : v>& l t ; h tml&gt ;7 & l t ; p&gt ; DsCom b u f f e r s i z e .& l t ; / p&gt ;8 & l t ; / h tml&gt ; < / a : v>9 </ a : a>

10 <a : a name="IMPLEMENTATIONCONFIGCLASS"11 type ="IMPLEMENTATIONCONFIGCLASS">12 < i c c : v c l a s s =" PreCompi le "> V a r i a n t P r e C o m p i l e < / i c c : v>13 </ a : a>14 <a : a name="ORIGIN" v a l u e ="AUTOSAR_ECUC" / >15 <a : a name="SYMBOLICNAMEVALUE" v a l u e =" f a l s e " / >16 <a : da name="DEFAULT" v a l u e =" 4096 " / >17 <a : da name="INVALID" type =" Range " exp r ="&g t ;=100 " / >18 </ v : var >19 . . .20 </ v : c t r >21 . . .

Auflistung 5.2 Modul: Auszug aus DsCom.xdm

Dieser Abschnitt erzeugt dann das in Abb. 5.12 abgebildete Eingabefeld in EB tresosStudio.

Abbildung 5.12 Konfiguration DsComBufferSize

Einstellungen aus der graphischen Oberfläche werden dann im Projektverzeichnis imUnterordner config (vgl. Abb. 5.11b) in der gleichnamigen Datei DsCom.xdm gespeicht(vgl. Auflistung 5.3).

1 <d : v a r name=" DsComBufferSize " type ="INTEGER" v a l u e =" 4096 " / >


Implementierung

Auflistung 5.3 Projekt: Auszug aus DsCom.xdm

Im Quelltexttemplate kann dann über Macros auf die Elemente aus der Konfigurati-on zugegriffen werden. In der Datei DsCom_TS_T36D1M1I0R0\generate\include\DsCom_Cfg_Int.h wird beispielsweise auf den Wert der Puffergröße zugegriffen (vgl.Auflistung 5.4).

1 # d e f i n e DSCOM_BUF_SIZE [ ! " DsComGeneral / DsComBuf fe rS i ze " ! ]

Auflistung 5.4 Template: DsCom_Cfg_Int.h

Bei der Generierung wird dieser Ausdruck dann ersetzt und in der generierten Headerda-tei DrivePxApp_DsCom\output\generated\include\DsCom_Cfg_Int.h steht nurnoch:

1 # d e f i n e DSCOM_BUF_SIZE 4096

Auflistung 5.5 Output: DsCom_Cfg_Int.h

Dabei sind auch kompliziertere Konstrukte möglich, beispielsweise die in Auflistung 5.6dargestellte Iteration über alle DsCom Verbindungen zur Erzeugung einer Enumeration.

1 t y p e d e f enum2 {3 [ ! LOOP " node : o r d e r ( a s : modconf ( ’DsCom ’ ) [ 1 ] / DsComConnections / * ) " ! ]4 [ ! " node : name ( . ) " ! ] [ ! IF " node : name ( . ) != name ( node : o r d e r ( a s : modconf

( ’DsCom ’ ) [ 1 ] / DsComConnections / * ) [ l a s t ( ) ] ) " ! ] , [ ! ENDIF ! ]56 [ !ENDLOOP! ]7 } DsCom_ConnectionType ;

Auflistung 5.6 Code Generator Beispiel

Bei der in Abb. 5.13 dargestellten Konfiguration mit 2 Verbindungen würde es die inAuflistung 5.7 aufgeführte Enumeration mit den Namen der 2 Verbindungen erzeugen.




Abbildung 5.13 Konfiguration des DsCom Moduls mit 2 Verbindungen

1 t y p e d e f enum2 {3 DsComIpcTest ,4 DsComMsgR5 } DsCom_ConnectionType ;

Auflistung 5.7 Erzeugte Enumeration der DsCom Verbindungen

Ähnlich können anhand der Modulkonfiguration beliebig viele, beliebig gestaltete Portsund Interfaces in den erzeugten ARXML Dateien generiert werden. In Auflistung 5.8ist dazu ein Auszug aus der Datei DsCom_TS_T36D1M1I0R0\generate_swcd\swcd\DsCom_swc_internal.arxml dargestellt. Es wird wieder über alle DsCom Verbindun-gen iteriert, pro Verbindung wird ein Provided und ein Required Port erzeugt, dessenName jeweils den Namen der Verbindung enthält.

1 [ ! LOOP " t e x t : s p l i t ( $ C o n n e c t i o n L i s t ) " ! ] [ ! / /2 [ !VAR " tmpConnectionName " = " t e x t : s p l i t ( . , ’ : ’ ) [ 2 ] " ! ] [ ! / /3 <R−PORT−PROTOTYPE>4 <SHORT−NAME>R_DsComReceive_ [ ! " $tmpConnectionName " ! ] < /SHORT−NAME>5 <REQUIRED−INTERFACE−TREF DEST="CLIENT−SERVER−INTERFACE" >/

AUTOSAR_DsCom / P o r t I n t e r f a c e s / DsCom_ReceiveData < /REQUIRED−INTERFACE−TREF>

6 </R−PORT−PROTOTYPE>7 <P−PORT−PROTOTYPE>8 <SHORT−NAME>P_DsComTransmit_ [ ! " $tmpConnectionName " ! ] < /SHORT−NAME>


Implementierung

9 <PROVIDED−COM−SPECS>10 <SERVER−COM−SPEC>11 <OPERATION−REF DEST="CLIENT−SERVER−OPERATION" >/AUTOSAR_DsCom /

P o r t I n t e r f a c e s / DsCom_TransmitData / Transmi tDa ta < /OPERATION−REF>12 <QUEUE−LENGTH>1 </QUEUE−LENGTH>13 </SERVER−COM−SPEC>14 </PROVIDED−COM−SPECS>15 <PROVIDED−INTERFACE−TREF DEST="CLIENT−SERVER−INTERFACE" >/

AUTOSAR_DsCom / P o r t I n t e r f a c e s / DsCom_TransmitData < /PROVIDED−INTERFACE−TREF>

16 </P−PORT−PROTOTYPE>17 [ !ENDLOOP ! ] [ ! / /

Auflistung 5.8 Erzeugung von Provided und Required Ports

Sollte die Template Based Code Generator API nicht ausreichen, kann auch auf eineJava Emitter Templates (JET) basierte Generator API zurückgegriffen werden oder einneues Generator Plugin in Java geschrieben werden (vgl. [Ele14, S. 228-237]).

5.2.5 Funktionsweise

Der nachfolgende Abschnitt gibt einen Überblick über den Aufbau und die Funktions-weise des DsCom Modul und orientiert sich dabei an dessen Software Detailed DesignDocument (vgl. [Jan15a]).

Das erste Diagramm (Abb. 5.14) zeigt das Modul im System Kontext. Das Modulnutzt die POSIX API des zugrundeliegenden Linux Betriebssystems. Weiterhin istexemplarisch eine Softwarekomponente mit dem Modul verbunden.

Für jede Softwarekomponente, die mit dem Modul verbunden werden soll, wird in derModulkonfiguration eine Verbindung angelegt (vgl. Abb. 5.13 mit 2 Verbindungen). Fürjede dieser Verbindungen generiert das Modul später einen Provided-Port des TypesDsCom_TransmitData und einen Required-Port des Types DsCom_ReceiveData.

Über den Port mit Interface DsCom_TransmitData kann die Softwarekomponente Datenversenden und das DsCom Modul leitet diese an den zur Verbindung gehörenden Socketweiter.

Über den Port mit Interface DsCom_ReceiveData triggert das DsCom Modul dasOperationInvoked Event des verbundenen Ports der Softwarekomponente, wenn neueDaten empfangen wurden.




Abbildung 5.14 DsCom Modul: Component Context View

Das folgende Diagramm (Abb. 5.15) zeig den inneren Aufbau das Moduls, bestehendaus Submodulen und Funktionseinheiten.

Das Modul bietet externen Modulen drei öffentliche Funktionen:

• DsCom_Init: Zur Initialisierung des Moduls

• DsCom_GetVersionInfo: Zur Abfrage der Version

• DsCom_TransmitData: Zum Versenden von Daten unter expliziter Angabe derVerbindung. Beim Senden über RTE Ports wird der erste Parameter automatischdurch sogenannte Port Defined Arguments ersetzt.

Die Funktion DsCom_MainFunction wird zeitlich getriggert und gibt defaultmäßig alledrei Sekunden Statistiken zur übertragenen Datenmenge in der Konsole aus.

Für jede Verbindung gibt es einen DsComDataReceiverThread. Das ist ein nativer LinuxThread. Dieser liest Daten von dem zur Verbindung gehörenden Socket und triggert beiempfangen Daten die AUTOSAR ISR IsrDsComDataReceived.

Die Nutzung von Interrupts zum Transport von Daten in die AUTOSAR Welt hilft hiereine klare Trennung beider Welten sicherzustellen, denn normale Linux Threads dür-fen keine anderen Funktionen des AUTOSAR OS aufrufen außer OS_LINUXTrigger-Interrupt.

Die AUTOSAR IsrDsComDataReceived setzt dann das AUTOSAR OsEvent DsCom-DataReceived.

Der DsCom_FwdDataTask wartet über die AUTOSAR OS Funktion WaitEvent aufdieses Event und triggert dann das entsprechende Runnable einer Softwarekompo-nente um die empfangenen Daten an diese weiter zu leiten. Somit ist sichergestellt,


Implementierung

dass alle Runnables die Daten aus dem DsCom Modul empfangen im Kontext desDsCom_FwdDataTask aufgerufen werden. Die Priorität des DsCom_FwdDataTaskkann dann in der OS Konfiguration konfiguriert werden.

Abbildung 5.15 DsCom Modul: Composition View

Die in Abb. 5.15 blau dargestellten Elemente sind globale Datenstrukturen inner-halb des Moduls. Die Struktur DsCom_ConnectionCfg existiert als Array mit Ds-Com_NumberOfConnections Elementen und speichert dabei alle Informationen zueiner DsCom Verbindung. Jeder DsComDataReceiverThread hat dabei über einen Poin-ter con auf ein Element dieses Arrays Lese/Schreib Zugriff, um den Puffer seinerVerbindung mit Daten zu füllen. Die DsCom_TransmitData Funktion braucht eben-falls Schreib-Zugriff auf dieses Datenelement, da sie direkt die zu sendenden Datenin den Socket der Verbindung schreibt. Und das Runnable, dass mit dem Interface




DsCom_ReceiveData verbunden ist erhält Lesezugriff, um die empfangenen Daten ausdem Empfangspuffer der Verbindung zu lesen.

Die nachfolgenden drei Diagramme zeigen die interne Funktionsweise der Subkompo-nenten DsComDataReceiverThread (vgl. Abb. 5.16), IsrDsComDataReceived (vgl. Abb.5.17) und DsCom_FwdDataTask (vgl. Abb. 5.18) des DsCom Moduls.

Der DsComDataReceiverThread (vgl. Abb. 5.16) läuft in einer Endlosschleife. Wenndas DsCom Modul initialisiert ist (DsCom_initStatus == DSCOM_INIT) akzeptierter entweder neue Socketverbindungen sofern kein Client mit dem Socket verbundenist (connected == 0) oder, sofern alle Daten bereits an eine Softwarekomponenteweitergeleitet wurden (bytes_pending == 0) versucht er neue Daten vom Socket zu lesen.Je nach Rückgabewert von dieser Leseoperation wird entweder die Socket-Verbindungauf nicht verbunden gesetzt (connected = 0) und geschlossen, oder die Anzahl derempfangenen Bytes in der Variable bytes_pending gespeichert und der AUTOSAR OSInterrupt IsrDsComDataReceived getriggert. Der Aufruf von accept beim Akzeptiereneiner neuen Socketverbindung bzw. read beim Lesen von einer Socketverbindungerfolgt dabei blockierend, d.h. der Aufruf der Funktion kehrt erst zurück sobald eineVerbindung akzeptiert wurde oder Daten gelesen wurden. Solange wird die Schleifenicht weiter durchlaufen und es wird nicht unnötig Rechenleistung verbraucht.


Implementierung

Abbildung 5.16 DsCom Modul: Algorithm View DsComDataReceiverThread

In der IsrDsComDataReceived (vgl. Abb. 5.17) wird einzig das AUTOSAR OS EventDsComDataREceived für den AUTOSAR OS Task DsCom_FwdDataTask gesetzt.Das ist absichtlich kurz gehalten denn im Interrupt Kontext sollten möglichst wenigeOperationen ausgeführt werden um weitere Tasks und Interrupts nicht zu blockieren.




Abbildung 5.17 DsCom Modul: Algorithm View IsrDsComDataReceived

Der DsCom_FwdDataTask (vgl. Abb. 5.18) läuft ebenfalls in einer Endlosschleife,wobei er über WaitEvent pausiert bis das AUTOAR OS Event DsComDataReceivedaktiviert wird. Dieses setzt er anschließend wieder zurück um über neue Events be-nachrichtigt zu werden. In einer weiteren Schleife über alle DsCom Verbindungenüberprüft er dann ob für die jeweilige Verbindung empfange Daten im Puffer verfügbarsind (bytes_pending > 0), ruft falls vorhanden (callback_function != NULL_PTR) dieentsprechende Callback-Funktion auf (triggert das Runnable einer Softwarekomponen-te das mit dem entsprechenden Port des DsCom Moduls zum Empfangen der Datenverbunden ist) und setzt, nachdem die Softwarekomponente die Daten empfangen hat,bytes_pending wieder auf Null.


Implementierung

Abbildung 5.18 DsCom Modul: Algorithm View DsCom_FwdDataTask

Von der grundlegenden Funktionsweise konnte die Implementierung als einfacher CDDnahezu 1:1 in das Plugin übertragen werden.



5.3 Workflow LxCore und DsCom


In diesem Abschnitt wird anhand der Integration des DsCom Moduls in ein Simple-DemoRte Projekt der komplette AUTOSAR Workflow auf der Zielplattform Linuxdurchlaufen.

5.3.1 Installation von EB tresos Studio

Voraussetzung ist die Datei DPX-EB-Tresos-Tegra-2.03.zip aus der Auslieferung2.15-DPX-EB-B15-2016-01-27. Die Zip-Datei wird entpackt und die setup.exe Da-tei gestartet. Unter EBtresosAutoCore_Linux_DrivePx_2.03_Autosar_en_B8 inAbbildung 5.19 verbirgt sich bereits der LxCore samt DsCom Modul.

Abbildung 5.19 EB tresos Studio Setup


Implementierung

Nach der Installation von EB tresos Studio und Einrichten einer Lizenz wie in der EBtresos installation guide (vgl. [Ele15b]) beschrieben kann mit dem Importieren einesDemo Projektes fortgefahren werden.

5.3.2 Import des SimpleDemoRTE Projektes

Im EB tresos Studio Import Dialog (vgl. Abb. 5.20) wird das simple_demo_rte_LXTHREADSX86_6.0.6 Demoprojekt ausgewählt und importiert. Dieses dient in dennachfolgenden Schritten als Grundlage.

Abbildung 5.20 EB tresos Import Demo

Nach Abschließen des Imports erscheint dieses dann im Projekt Explorer vom EB tresosStudio (vgl. Abb. 5.21). Hier können alle Module gesehen werden, die dieses Projektnutzt.




Abbildung 5.21 EB tresos Studio Project Explorer

5.3.3 Hinzufügen des DsCom Modules zum EB tresos Studio Pro-jekt

Damit eine Softwarekomponente aus dem Projekt das DsCom Modul nutzen kann, mussdieses zuerst zu dem Projekt hinzugefügt werden. Dies geschieht über den ModuleConfigurations Dialog in EB tresos Studio (vgl. Abb. 5.22).


Implementierung

Abbildung 5.22 EB tresos Studio Module Configurations

Daraufhin kann es wie jedes andere Modul in EB tresos Studio konfiguriert werden. InAbb. 5.23 ist dazu das Konfigurationsinterface des DsCom Plugins zu sehen.

Abbildung 5.23 EB tresos Studio DsCom Configurations




Zu Demonstrationszwecken fügen wir eine neue DsCom Verbindung mit Namen Demo-Con hinzu (vgl. Abb. 5.24).

Abbildung 5.24 EB tresos Studio DsCom DemoCon

5.3.4 Hinzufügen eines DsCom Ports im SystemDesk Modell

Um einen DsCom Port zu einer Softwarekomponente im SystemDesk Modell hin-zuzufügen, müssen als erstes über generate_swcd in EB tresos Studio die SoftwareComponent Descriptions generiert werden (vgl. Abb. 5.25).

Abbildung 5.25 EB tresos Studio Generate SWCD

Dadurch wird im Projektverzeichnis die Datei output\generated\swcd\DsCom_swc_interface.arxml erzeugt, die eine Beschreibung des DsCom Port Interfaces enthält.

Anschließend können in SystemDesk die Dateien SoftwareComponents.arxml, AU-TOSAR_Datatypes.arxml, BswMMode.arxml und CanSystem.arxml aus dem sup-


Implementierung

plement Ordner sowie die Datei DsCom_swc_interface.arxml aus dem generatedOrdner importiert werden.

Abbildung 5.26 SystemDesk TopLevelComposition

Über New → Provided Port Prototype und New → Required Port Prototype werden beider Softwarekoponente SWC_CyclicCounter zwei neue Ports erstellt, denen anschie-ßend die Port-Interfaces DsCom_ReceiveData und DsCom_TransmitData zugewiesenwerden. Das Ergebnis ist in Abb. 5.27 zu sehen.

Abbildung 5.27 SystemDesk SWC_CyclicCounter DsCom Ports

Die Softwarekomponente besitzt jetzt zwar Ports mit den korrekten Interfaces, es wirdjedoch noch kein Runnable getriggert wenn Daten empfangen wurden und auch dasVersenden von Daten aus einem Runnable ist noch nicht möglich.




Um dies zu ermöglichen wird im Internal Behavoir der Softwarekomponente ein neuesRunnable erstellt (RE_DsComReceivedData), das durch das OperationInvokedEventder ReceiveData Operation des P_DsCom_ReceiveData Ports getriggert wird (vgl. Abb.5.28).

Abbildung 5.28 SystemDesk SWC_CyclicCounter DsCom Receivedata Runnable

Anschließend wird diesem Runnable ebenfalls die TransmitData Operation zugewiesen(vgl. Abb. 5.29), so kann es die empfangenen Daten über das DsCom Modul auchwieder zurücksenden.

Abbildung 5.29 SystemDesk SWC_CyclicCounter DsCom TransmitData Operation

Jetzt sind im Modell alle Anforderungen erfüllt, sodass die SoftwarekomponenteSWC_CyclicCounter über das DsCom Modul kommunizieren kann. Das SystemDeskModell wird wieder als ARXML exportiert und kann in EB tresos Studio importiertwerden.


Implementierung

5.3.5 Import in EB tresos Studio

Vor dem Import in EB tresos Studio wird zuerst in der ToplevelComposition.arxmlneben dem BswM und Det der DsCom Prototyp hinzugefügt (vgl. Anhang A: Toplevel-Composition.arxml). Dies ist erforderlich, damit das DsCom Modul später im Connec-tion Editor in EB tresos Studio verfügbar ist. Danach kann das System Modell in EBtresos Studio importiert werden (vgl. Abb. 5.30).

Abbildung 5.30 EB tresos Studio Import System Model

Über den EcuExtractCreator wird ein ECU Extract generiert (vgl. Abb. 5.31, Ab-schnitt 2.2.8).

Abbildung 5.31 EB tresos Studio Create ECU Extract




Über Calculate Service Needs werden anschließend automatisch die Service Needs vomDsCom Modul im OS hinzugefügt (vgl. Abb. 5.31). Diese sind:

• ein OsEvent (DsComDataReceived),

• eine OsIsr (IsrDsComDataReceived) und

• ein OsTask (DsCom_FwdDataTask, vgl. Abb. 5.32).

Diese mussten bei der Umsetzung als einfacher CDD manuell in der OS Konfigurationhinzugefügt und konfiguriert werden.

Abbildung 5.32 EB tresos Studio OS Tasks

Anschließend wird im Rte Editor unter Event Mapping das BswTimingEvent derDsCom_MainFunction automatisch auf den SchMComTask_3000ms gemappt. Und inder Os Konfiguration müssen noch alle Tasks und ISRs einer OsApplication zugewiesenwerden. Dies ist in einem AUTOSAR Multicore OS erforderlich um festzulegen aufwelchem Prozessorkern diese Tasks und ISRs ausgeführt werden sollen.

Die Verbindung zwischen Softwarekomponente und Basissoftware wird im ConnectionEditor hergestellt. Hier werden die Ports von der SWC mit dem BSW Modul verbunden(vgl. Abb. 5.33).


Implementierung

Abbildung 5.33 EB tresos Studio Connection Editor

Diese Verbindungen werden vom Connection Editor in der Datei ConnectionEditor-.arxml gespeichert, daher muss das System Modell anschließend mit der aktualisiertenDatei ConnectionEditor.arxml erneut importiert werden. Es wird noch die FunktionUpdate Service Componend and BSWM Descriptions (vgl. Abb. 5.31) ausgeführt.Danach kann das Projekt generiert werden.

Im Ordner source wird dann die Datei SWC_CyclicCounter.c editiert und der Proto-typ der Funktion SWC_CyclicCounter_RE_DsComReceivedData aus der Datei SWC_CyclicCounter_Template.c kopiert und so umgeändert, dass die empfangenen Datenzurückgesendet werden (vgl. Auflistung 5.9).

1 vo id SWC_CyclicCounter_RE_DsComReceivedData (P2VAR( u i n t 8 , AUTOMATIC,RTE_APPL_DATA) D a t a P t r , u i n t 3 2 DataLen )

2 {3 S td_Re tu rnType s t a t u s ;45 s t a t u s = Rte_Cal l_R_DsComTransmi tData_Transmi tData ( D a t a P t r ,

DataLen ) ;67 }

Auflistung 5.9 DsComReceivedData Prototype




5.3.6 Kompilieren und Ausführen

Der letzte Schritt ist das Kompilieren und Ausführen. Dazu wird in das Verzeichnis C:\EB\LxCore\workspace\simple_demo_rte_LXTHREADSX86_6.0.6\util gewech-selt und in der Datei launch_cfg.bat der Pfad zur Tresos Installation angepasst.

Wenn das Target mit dem Host verbunden ist und die IP Adressen richtig konfiguriertsind, kann die launch.bat Datei gestartet werden (vgl. Abb. 5.34) und das Projekt mitden Befehlen aus Auflistung 5.10 kompiliert werden.

Abbildung 5.34 Ausführen der launch.bat Datei

1 make c l e a n _ a l l2 make g e n e r a t e3 make depend4 make

Auflistung 5.10 Kompilieren des Projekts

Wenn das Kompilieren erfolgreich war sollte Finished Fast Build in der Konsoleerscheinen. Jetzt kann das Programm in einem SSH Terminal gestartet werden (vgl.Abb. 5.35).


Implementierung

Abbildung 5.35 Ausführen des SimpleDemoRTE Programms

In einem zweiten Terminal können dann zum Beispiel per Python Script Daten an dasDsCom Modul gesendet werden (vgl. Abb. 5.36).

Abbildung 5.36 Senden von Daten an DsCom via Python Script

Das Python Script ist in Auflistung 5.11 dargestellt. In diesem wird der Socket /run/eb/DemoCon.sock geöffnet welcher zu der Verbindung DemoCon (vgl. Abb. 5.24)gehört. Danach wird der Benutzer in einer Endlosschleife aufgefordert Nachrichten inder Konsole einzugeben, diese werden über den Socket versendet und die empfangeneAntwort wiederum ausgegeben.




1 # −*− co d i ng : u t f −8 −*−2 i m p o r t s o c k e t3 i m p o r t os45 p r i n t ( " C o n n e c t i n g . . . " )6 i f os . path . e x i s t s ( " / run / eb / DemoCon . sock " ) :7 c l i e n t = s o c k e t . s o c k e t ( s o c k e t . AF_UNIX , s o c k e t . SOCK_SEQPACKET)8 c l i e n t . c o n n e c t ( " / run / eb / DemoCon . sock " )9 p r i n t ( " Ready . " )

10 p r i n t ( " C t r l −C t o q u i t . " )11 whi le True :12 msg = r a w _ i n p u t ( "> " )13 i f " " != msg :14 p r i n t ( "SEND: " , msg )15 c l i e n t . send ( msg )16 r e c = c l i e n t . r e c v ( 1 0 2 4 )17 p r i n t ( "RECEIVED" , r e c )18 c l i e n t . c l o s e ( )19 e l s e :20 p r i n t ( " Couldn ’ t Connect ! " )21 p r i n t ( " Done " )

Auflistung 5.11 Python Script zur Kommunikation mit DsCom

Ausführlichere Hinweise finden sich dazu in der EB tresos LxCore Users Guide (vgl.[Jan15e]). Das fertige SimpleDemoRte Projekt mit dem integrierten DsCom Modulbefindet sich auf der beiliegenden Daten CD3.

3Auf Daten CD: simple_demo_rte_LXTHREADSX86_6.0.6_with_dscom.zip


Kapitel 6

Ergebnisse und Bewertung

In diesem Kapitel werden zunächst die Ergebnisse der Implementierungsphase, zusam-mengefasst und anschließend die Softwarearchitektur detailliert evaluiert und bewertet.

6.1 Grundlegende Ergebnisse

Innerhalb der EB PAD Plattform gibt es jetzt die Möglichkeit Standard AUTOSARSoftwarekomponenten auf dem Performance Prozessor unter Linux auszuführen. Eineperformante Kommunikation mit generischen Linux-Applikationen ist über DsCom alsEB tresos Studio Plugin leicht möglich (vgl. Abb. 6.1).

Die Softwareplattform wurde bereits vom AVP Projekt getestet und erste Software-komponenten konnten erfolgreich vom Fahrzeug-PC auf die DRIVE PX Plattformmigriert werden. Gefundene Bugs im AUTOSAR OS für Linux wurden im AutoCoreOS Bugtracker gemeldet und behoben.

Zudem wurde begonnen den Classic AUTOSAR Stack auf Linux Seite schrittweisein die Produktlandschaft von EB zu integrieren und für die DRIVE PX Plattformwurden bereits erste Versionen zur Evaluierung an potentielle Kunden ausgeliefert (vgl.[Ele15a]).



Abbildung 6.1 EB Platform for Autonomous Driving1

6.2 Auswirkung auf die AUTOSAR Methodologie

Es hat sich herausgestellt, dass sich die AUTOSAR-Methodologie unter Linux nichtändern muss. Wie unter Abschnitt 5.3 „Workflow LxCore und DsCom“ gezeigt kann derStandard AUTOSAR Workflow beibehalten werden und es können sogar die gleichenTools benutzt werden.

6.3 Architektonische Anforderungen

Für die Kommunikation zwischen AUTOSAR Softwarekomponenten und Linux-App-likationen ergeben sich nachfolgende Architektonische Anforderungen.

Sollen AUTOSAR Softwarekomponenten unter Linux auf dem LxCore Daten mitLinux-Applikationen austauschen, so muss:

• Das DsCom Modul in die Software Architektur des Projekts integriert werden.

• Eine Softwarekomponente die Daten senden und empfangen will benötigt einenProvided-Port des Types DsCom_TransmitData und einen Required-Port desTypes DsCom_ReceiveData.

1Quelle: EB



6.4 Performance und Jitter Messung

• Zusätzlich muss in der Softwarekomponente ein Runnable angelegt werden,das beim Empfangen von Daten getriggert wird und die DsCom Ports müssenanschließend bei der Integration mit dem DsCom Modul verbunden werden.

Linux-Applikationen die mit einer AUTOSAR-Softwarekomponente kommunizierenwollen, müssen:

• Den entsprechenden UNIX Domain Socket öffnen, der zu der DsCom Verbin-dung gehört mit der die Receive und Transmit Ports der Softwarekomponenteverbunden sind und können darüber Daten senden und empfangen.

Das Datenformat für die zu übertragen Daten und eventuelle Verfahren zur Serial- undDeserialisierung (vgl. Abschnitt 2.1.4) kann der Anwendungsentwickler frei wählen.


In diesem Abschnitt sollen zur Evaluierung und Bewertung der Plattform durchgeführtePerformance und Jitter Messungen ausgewertet werden.

Die einfachste Möglichkeit zur Messung des Jitters auf kleinen Embedded Systemen istaus einem zyklischen Task einen Prozessor-Pin zu toggeln und das Signal mit einemOszilloskop zu messen. Allerdings haben wir an dem Performance Prozessor auf derDRIVE PX Plattform keinen freien IO-Pin mehr, und der Kernel müsste dazu auchangepasst und neu kompiliert werden. Somit ist die Gewinnung von Vergleichsdatenauf anderen Embedded Linux Systemen oder X86 PCs sehr aufwendig.

Im EB tresos Testsystem gibt es allerdings ein paar sehr interessante Testfälle zurPerformance Messung, wodurch Vergleichsdaten für den ebenfalls auf der DRIVE PXPlattform verwendeten Safety Prozessor vorliegen. Dazu wurden unter anderem für denTestfall Perf2 ein EB tresos Studio Projekt für den LxCore unter Linux sowie ein Skriptzur Testdatengewinnung erstellt, sodass die Testergebnisse der AUTOSAR Umgebungunter Linux direkt mit den Daten eines Standard AUTOSAR Systems verglichen werdenkönnen.

Zur Zeitmessung im AUTOSAR OS dient ein freilaufender Hardware-Zähler, der jenach Prozessortakt pro Nanosekunde um eine bestimmte Anzahl von Ticks erhöht wird.Daraus lässt sich dann sehr genau die Zeit berechnen.

Im AUTOSAR OS unter Linux wird der Zähler allerdings nur hochgezählt, während derAUTOSAR Prozess auch wirklich auf dem Prozessor ausgeführt wird, d.h. es wird nurdie Prozessorzeit gemessen. Daher kann damit nicht der, durch das Scheduling unter



Linux verursachte Jitter gemessen werden, wenn andere Prozesse auf dem Prozessorausgeführt werden und der AUTOSAR Prozess unterbrochen wird. Sobald der AUTO-SAR Prozess unterbrochen wird vergeht für das AUTOSAR OS praktisch keine Zeitmehr.

Das wurde korrigiert, in dem für die Zeitmessung unter Linux kein OsCounter genutztwird, sondern die POSIX-Funktion clock_gettime() mit dem Parameter CLOCK_-MONOTONIC. Diese gibt unter Linux die Zeit seit Systemstart in Sekunden und Nanose-kunden zurück (vgl. [TT13a]).

In den nachfolgenden Abschnitten erfolgt die Auswertung der unterschiedlichen Test-szenarien auf verschiedenen Hardwareplattformen und Linux Kernel Versionen. Da essich bei Linux um kein Echtzeitsystem handelt und die CPU Auslastung eine wichtigeRolle spielt, wurden die Messungen jeweils unter niedriger und hoher CPU Auslastungdurchgeführt und sehr oft wiederholt. Die beigefügten Histogramme zeigen dabei dieVerteilung der Messergebnisse.

6.4.1 Testszenario Perf2

In dem Testszenario Perf2 gibt es zwei OS Tasks, Task 1 und Task 2. Task 1 istdabei nicht unterbrechbar, sodass trotz Aktivierung von Task 2, der eine höhere Prioritätbesitzt, Task 1 so lange weiter ausgeführt wird, bis die Funktion Schedule() aufgerufenwird (vgl. Abb. 6.2, Auflistung A.3).




Abbildung 6.2 EB tresos TestSuite Perf22

Die Werte A, B und C aus der Abbildung 6.2 entsprechen der Zeit, die benötigt wird(vgl. EB tresos TestSuite):

• A: NSActivateTask: um einen Task in einem nicht preemptiven System zuaktivieren. Task 1 aktiviert dabei Task 2, welcher eine höhere Priorität hat. Eserfolgt kein Taskwechsel, da Task 1 nicht preemptiv ist.

• B: NSSchedule: um zu einem Task mit höherer Priorität zu wechseln nachdemdie Funktion Schedule() in einem nicht preemptiven System aufgerufen wurde.Task 1 ruft Schedule() auf und Task 2 wechselt in den RUNNING Modus.

• C: NSTerminateTask: um zu einem Task mit geringer Priorität zurückzuwech-seln, nach dem der Task mit höherer Priorität in einem nicht preemptiven Systembeendet wurde. Task 2 ruft dabei TerminateTask() auf.

Die Zeit, die das OS für eine dieser Systemfunktion benötigt kann bestimmt werdenindem direkt vor und nach dem Aufruf der Funktion (z.B. ActivateTask(TASK2))die Systemzeit gemessen und gespeichert wird. Aus der Differenz kann dann die Zeitberechnet werden, die das OS dafür benötigt hat (vgl. Auflistung A.3).

2Quelle: EB



Testergebnisse Aurix

Die Testergebnisse für den Aurix (vgl. Abb. 6.3) stammen direkt aus dem EB Testsystemund wurden auf einen 200 MHz TriCore Prozessor mit einem Standard AutoCore OSgemessen (vgl. Tabelle 6.1).

Tabelle 6.1 EB tresos TestSuite Perf2 Testumgebung Aurix

Bezeichner Wert

Date 2015Oct23OS Version 6.0.15CPU TRICORE 200 MhzDerivate TC275TRESOS AutosarOS V.6.0.15Compiler taskingDebugger Trace32

Abbildung 6.3 EB tresos TestSuite Perf2 Ergebnisse Aurix3

Die Option OsStatus (STATUS, vgl. Abb. 6.3) legt fest, wie das AUTOSAR OS aufFehler reagieren soll. Sie ist ein Enumerationstyp und kann einen der folgenden Wertehaben (vgl. EB tresos Studio):

• STANDARD: Im STANDARD Modus ist in der OSEK/VDX Spezifikation nichtfestgelegt wie das OS reagieren soll wenn ein Fehler auftritt. In diesem Moduskann das AUTOSAR OS den Task oder die Applikation, die den Fehler verursachtanhalten.

3Quelle: EB




• EXTENDED: Im EXTENDED Modus ist in der OSEK/VDX Spezifikation dasVerhalten im Fehlerfall spezifiziert. Hier soll das System bestimmte Fehlercodeszurückgeben wenn ein Fehler detektiert wurde. Das AUTOSAR OS erfüllt dabeidiese Anforderungen.

Die Option OsSchedule (SCHEDULE, vgl. Abb. 6.3) ist ein Enumerationstyp und kanneinen der folgenden Werte haben (vgl. EB tresos Studio):

• NON: NON bedeutet, dass bei allen Tasks das OsSchedule attribute auf NONgesetzt sein muss.

• FULL: FULL bedeutet, dass bei allen Tasks das OsSchedule attribute auf FULLgesetzt sein muss.

• MIXED: MIXED bedeutet, dass eine Mischung der Schedulingtypen erlaubt ist.

Zu den Messergebnissen aus Abb. 6.3 lässt sich sagen, sie liegen bei allen drei Messgrö-ßen im unteren Mikrosekundenbereich und entsprechen damit den Erwartungen an einEmbedded System. Über die genaue Verteilung der Messwerte lässt sich nichts sagen,da dazu keine Daten vorliegen. Da es sich bei dem AUTOSAR OS um ein Echtzeit-betriebssystem handelt wird angenommen, dass diese keinen großen Schwankungenunterliegen.

Testergebnisse DRIVE PX ohne RT Kernel mit AS OS V.6.0.6

Die nachfolgenden Messwerte wurden auf der DRIVE PX Plattform (vgl. Abschnitt2.3.1) mit dem Standard Linux Kernel von NVIDIA (vgl. Tabelle 6.2) aufgenommen.

Tabelle 6.2 Perf2 Testumgebung DrivePx

Bezeichner Wert

Date 2015Dez11OS Version Linux nvidia 3.18.11-tegra #1 SMP PREEMPT Mon Aug 10

17:28:52 PDT 2015 aarch64 aarch64 aarch64 GNU/LinuxCPU Tegra 1632 MhzDerivate X1TRESOS AutosarOS LXTHREADSX86 V.6.0.6Compiler GCCSTATUS EXTENDEDSCHEDULE MIXED



Dabei wurden die Messwerte ein Mal unter gringer CPU Auslastung (vgl. Tabelle 6.3)und ein Mal unter nahezu hundertprozentiger CPU Auslastung (vgl. Tabelle 6.4) aufge-nommen. Die CPU Auslastung wurde mit dem Programm stress für alle CPU Kerneerzeugt (vgl. capture_data.sh4).

Tabelle 6.3 DrivePx Perf2 (Leerlauf)5

Typ Median [µs] Max [µs] Min [µs] STDEV [µs]

NSActivateTask 28,23 294,53 25,47 8,84NSSchedule 24,64 192,92 22,19 7,06NSTerminateTask 23,96 404,95 19,32 16,13

Tabelle 6.4 DrivePx Perf2 (Last)6



Zur Veranschaulichung der Messwertverteilung wurden beispielhaft von der GrößeNSActivateTask ein Histogramm unter geringer (vgl. Abb. 6.4) und unter hoher CPUAuslastung (vgl. Abb. 6.5) erzeugt. Die Histogramme und kompletten Messdaten sowiedie Skripte zur Messwerterfassung befinden sich dabei auf der beiliegen Daten CD7.

Es ist ersichtlich das die Zeit NSActivateTask unter niedriger als auch unter hoher CPUAuslastung im Mittel bei etwas unter 30 µs liegt, jedoch bei starker CPU Auslastungsehr stark streut und bis zu einem Maximum von fast 20000 µs reicht. Das sind 20 msrein für das Aktivieren eines Taskes. Das ist für viele Anwendungen deutlich zu groß.

Allerdings besitzt der hier verwendete Linux Kernel nicht die EchtzeiterweiterungenPREEMPT RT. Diese sind für den Linux Kernel auf dem 64-Bit ARM Prozessor auf derDRIVE PX Plattform noch nicht verfügbar. Daher dient im nachfolgenden Abschnittein Jetson Pro Board (Vorgänger der DRIVE PX Plattform von NVIDIA) mit einem32-Bit ARM Prozessor und einem Linux Kernel mit PREEMPT RT Erweiterungen ausdem vorangegangenen Praktikum (vgl. [Jan15b]) zum Vergleich.

4Auf Daten CD: test_projects_results.zip5Auf Daten CD: DrivePx-2015-12-11_20151211154906_Perf2_data.ods6Auf Daten CD: DrivePx-2015-12-11_20151211154918_Perf2_stress_data.ods7Auf Daten CD: test_projects_results.zip




0

20

40

60

80

100

120

20 25 30 35 40 45 50

Häufigke

it

Zeit in [µs]

Abbildung 6.4 DrivePx Histogramm Perf2 NSActivateTask (Leerlauf)8

0

5

10

15

20

25

30

35

40

20 25 30 35 40 45 50

Häufigke

it

Zeit in [µs]

Abbildung 6.5 DrivePx Histogramm Perf2 NSActivateTask (Last)9

8Auf Daten CD: DrivePx-2015-12-11_20151211154906_Perf2_data.ods9Auf Daten CD: DrivePx-2015-12-11_20151211154918_Perf2_stress_data.ods



Testergebnisse Jetson Pro mit RT Kernel und AS OS V.5.1.12

Die nachfolgenden Messwerte wurden auf Jetson Pro Board mit einem selbst gebautenLinux Kernel mit PREEMPT RT Erweiterungen (vgl. Tabelle 6.5, [Jan15c, S. 73-85])aufgenommen. Dabei kommt ein älteres AutoCore OS für Linux als auf der DRIVE PXPlattform zum Einsatz. Dieses unterstützt die PREEMPT RT Erweiterungen des LinuxKernels.

Tabelle 6.5 Perf2 Testumgebung JetsonPro

Bezeichner Wert

Date 2016Jan18OS Version Linux nvidia 3.10.61-rt65 #3 SMP PREEMPT RT Wed Apr

15 15:07:18 CEST 2015 armv7l armv7l armv7l GNU/LinuxCPU Tegra 1800 MhzDerivate K1TRESOS AutosarOS LXTHREADSX86 V.5.1.12Compiler GCCSTATUS EXTENDEDSCHEDULE MIXED

Interessant an den Messwerten (vgl. Tabelle 6.6, Tabelle 6.7) ist, das diese sich nurunwesentlich in Abhängigkeit von der CPU Auslastung unterscheiden, die Werte fürNSActivateTask betragen weniger als ein Drittel derer des DRIVE PX, wogegen dieWerte für NSSchedule und NSTerminateTask sehr viel größer sind.

Tabelle 6.6 JetsonPro RT (Leerlauf)10



Auch die Histogramme unter niedriger (vgl. Abb. 6.6) und hoher CPU Auslastung (vgl.Abb. 6.7) sind nahezu identisch. Dies kann auf die Verwendung des Echtzeitkernels unddie Nutzung der Echtzeiterweiterungen vom AutoCore OS zurückgeführt werden.

10Auf Daten CD: JetsonPro-2016-01-18_20160118150017_Perf2.ods11Auf Daten CD: JetsonPro-2016-01-18_20160118150042_Perf2_stress.ods




Tabelle 6.7 JetsonPro RT Perf2 (Last)11



0

50

100

150

200

250

300

5 10 15 20 25

Häufigke

it

Zeit in [µs]

Abbildung 6.6 JetsonPro RT Histogramm Perf2 NSActivateTask (Leerlauf)12

12Auf Daten CD: JetsonPro-2016-01-18_20160118150017_Perf2.ods



0

50

100

150

200

250

5 10 15 20 25

Häufigke

it

Zeit in [µs]

Abbildung 6.7 JetsonPro RT Histogramm Perf2 NSActivateTask (Last)13

Die Ergebnisse hier sind mit denen auf der DRIVE PX Plattform zwar nicht direktvergleichbar (unterschiedlicher Prozessor, Kernel und AutoCore OS), sie geben abereinen guten Eindruck welche Zeiten unter einem Embedded Linux System mit undohne Echtzeiterweiterungen realisierbar sind.

Mit einer maximalen Latenz von 20 ms auf der DRIVE PX Plattform ohne RT Kernelund 0,02 ms auf dem Jetson Pro Board mit RT Kernel stimmen die gemessenen Werteziemlich gut mit denen des RT-Test Programms cyclictest des Linux Kernels überein.Hier werden in der README Datei für ein Nicht-Real-Time System etwa 40 ms undfür RT-System etwa 0,02 ms maximale Latenz angegeben (vgl. [Koh11]).

6.4.2 Zeitmessung DsCom mit Softwarekomponente

In diesem Testszenario wird ein Projekt, ähnlich dem aus Abschnitt 5.3 genutzt umdie Zeit zu messen, die benötigt wird um von einer Linux-Applikation eine Nachrichtüber das DsCom Modul an eine Softwarekomponente zu schicken und die Antwort zuempfangen.

Ein Python Script (vgl. Auflistung A.4) sendet dabei eine Nachricht über den Socket desDsCom Moduls. Dieses liest die Daten, triggert das Runnable RE_DsCom_DataReceived

13Auf Daten CD: JetsonPro-2016-01-18_20160118150042_Perf2_stress.ods




der Softwarekomponente SWC IPC Test und übergibt ihr per Pointer die Daten. Die Soft-warekomponente sendet dieselben Daten als Antwort sofort wieder zurück. Währenddes Aufrufs von DsCom_TransmitData werden diese direkt in den Socket geschriebenund das Python Skript empfängt die Antwort (vgl. Abb. 6.8). Das Python Skript misstdabei die Zeit zwischen Senden der Nachricht und Empfangen der Antwort.

Abbildung 6.8 Sequenzdiagramm Zeitmessung DsCom

Der Test findet dabei auf der DRIVE PX Plattform ohne Echtzeitkernel statt, da dasDsCom Modul das neuere AutoCore OS 6.0.6 voraussetzt, und dieses momentan nichtauf dem älteren Jetson Pro Board mit Echtzeitkernel lauffähig ist. Im Mittel vergehenzwischen Senden der Nachricht und Empfangen der Antwort etwa 4 Millisekunden. Eskann aber auch über 20 Millisekunden dauern, und dies bei geringer CPU Auslastung(vgl. Tabelle 6.8).

Wenn man annimmt, dass man einen Computer Vision Algorithmus mit mindestens 30Frames per Second (FPS) als generische Linux Anwendung ausführt und diese Daten ineiner AUTOSAR Softwarekomponente weiter verarbeiten will, dann sind 20 ms allein

14Auf Daten CD: 20150825184834_DrivePxApp_DsCom_data.ods



Tabelle 6.8 Zeitmessung DrivePxApp mit DsCom Modul14

Median [ms] Min [ms] Max [ms] STDEV [ms]

3,59 2,45 23,18 2,34

für die Kommunikation zu viel. Die maximale Latenz darf hier nicht mehr als (1000Millisekunden) / (30 FPS) = 33,33 Millisekunden betragen.

6.5 Bewertung der Architektur

Mit dem LxCore ist es möglich AUTOSAR Softwarekomponenten als auch Modulemit den regulären Tools, die auch für Standard Automotive Steuergeräte eingesetztwerden, zu entwickeln und unter Linux auszuführen. Die Kommunikation zwischenAUTOSAR-Komponenten und Linux-Applikationen kann dabei durch das DsComModul erfolgen.

Es gibt eine geringe Abschottung zwischen AUTOSAR und Linux, ein einfacher undeffizienter Datenaustausch ist möglich und aus einer Softwarekomponente könnendirekt Linux Funktionen aufgerufen werden. Auf Linux Seite fehlen allerdings nochder AUTOSAR Com-Stack und der PDU-Router.

Typische Anforderungen aus dem Embedded Bereich, wie zum Beispiel die Task-Aktivierung innerhalb einer definierten und reproduzierbaren Antwortzeit lassen sichmit diesem System auf einem Linux Kernel ohne Echtzeiterweiterungen allerdingsnicht erfüllen. Ein Jitter von bis zu 20 ms (vgl. Abschnitt 6.4.1) ist inakzeptabel.Unter Verwendungen der PREEMPT RT Erweiterung lassen sich zwar reproduzierbareAntwortzeiten erzielen, diese liegen jedoch selbst auf einem vielfach leistungsfähigerenLinux System deutlich über denen eines typischen AUTOSAR Systems.

Ebenso ist es mit dieser Architektur nicht möglich Softwarekomponenten dynamischwährend der Laufzeit zu dem System hinzuzufügen, wie es mit Linux-Applikationenüblich ist. Das gesamte AUTOSAR System unter Linux muss jedes Mal neu kompiliertwerden. Zudem ist es unschön, dass alle AUTOSAR Softwarekomponenten und Tasksim gleichen Prozess-Kontext unter Linux laufen, so gibt es keinen Speicherschutz zwi-schen den Softwarekomponenten und auch Sicherheitserweiterungen des Linux Kernelswie SELinux15 lassen sich so nicht nutzen um Softwarekomponenten voneinanderabzuschotten.

15Security-Enhanced Linux, Sicherheitserweiterung des Linux Kernels



Kapitel 7

Zusammenfassung und Ausblick

Mit der Implementierung des EB tresos LxCore und dessen Integration in die EB tresosStudio Installation wurde eine Plattform geschaffen um AUTOSAR Softwarekompo-nenten für High Performance Automotive Steuergeräte zu entwickeln und unter Linuxauszuführen. Das ebenfalls entwickelte und in den LxCore integrierte Kommunikati-onsmodul DsCom als EB tresos Studio Plugin ermöglicht eine einfache und effizienteKommunikation zwischen AUTOSAR-Komponenten und Linux-Applikationen. Damitwurde das Ziel dieser Arbeit erreicht.

Es wurde festgestellt, dass sich Latenzen durch das zugrundeliegende Linux Betriebs-system nur schwer beeinflussen lassen, hier ist es sinnvoll einen Linux Kernel mitEchtzeiterweiterungen einzusetzen und diese gezielt zu verwenden.

Klassisches AUTOSAR unter Linux allein ist sicher nicht die optimale Plattform fürselbstfahrende Fahrzeuge, wir haben das gleiche starre Entwicklungsmodell wie unterder klassischen AUTOSAR Plattform, begrenzte Echtzeitfähigkeit und die Möglichkei-ten von Linux werden kaum genutzt. Das hat man auch in der AUTOSAR Entwicklungs-partnerschaft erkannt und mit der Arbeit an der AUTOSAR Adaptive Platform begonnen.In dieser gibt es keine klassische AUTOSAR RTE mehr, Softwarekomponenten sindnormale Linux-Applikationen die über eine Kommunikations-Middleware kommunizie-ren und von einem Ausführungs-Manager gesteuert werden. All dies befindet sich nochin Entwicklung und wird in den AUTOSAR Gremien heftig diskutiert.

Für die weitere Entwicklung sollte untersucht werden wie sich die Echtzeiterweiterun-gen des Linux Kernels effektiv nutzen lassen. Dies ist notwendig, um die Ausführungverschiedener Linux-Applikationen zu koordinieren und echtzeitfähige Kommunika-tion unter Linux und mit Standard AUTOSAR Steuergeräten zu ermöglichen. Zudemsollte untersucht werden, wie sich die hier entwickelte klassische AUTOSAR Plattform


Zusammenfassung und Ausblick

unter Linux am besten in die Adaptive Plattform integrieren lässt. Zur Erhöhung derKompatibilität mit bestehenden AUTOSAR Komponenten ist es außerdem sinnvoll denAUTOSAR Com-Stack und den PDU-Router in den LxCore zu integrieren.



Literaturverzeichnis

[AUT15] AUTOSAR: AUTOSAR Methodology V1.0.1. http://www.autosar.org/fileadmin/files/releases/2-0/methodology-templates/methodology/auxiliary/AUTOSAR_Methodology.pdf. Version: 2015. – Zugriff:18.12.2015

[AUT22a] AUTOSAR STANDARD: Glossary. http://www.autosar.org/fileadmin/files/releases/4-2/main/auxiliary/AUTOSAR_TR_Glossary.pdf. Version: 4.2.2. –Zugriff: 22.01.2016

[AUT22b] AUTOSAR STANDARD: Virtual Functional Bus. http://www.autosar.org/fileadmin/files/releases/4-2/main/auxiliary/AUTOSAR_EXP_VFB.pdf.Version: 4.2.2. – Zugriff: 22.01.2016

[Con15] CONTINENTAL AG: Fahrwerkselektronik für optimiertes Handlingund höheren Komfort - Die Chassis Domain Control Unit als Diri-gent. http://www.continental-automotive.de/www/automotive_de_de/themes/passenger_cars/chassis_safety/ved/fahrwerkselektronik_de.html.Version: 2015. – Zugriff: 18.12.2015

[Ele14] ELEKTROBIT AUTOMOTIVE GMBH: EB tresos Studio developer’s guide.2.4_Studio_documentation_developers_guide.pdf. Version: 15.0, 2014. –Das PDF befindet sich auf der beiliegenden Daten CD.

[Ele15a] ELEKTROBIT AUTOMOTIVE GMBH: EB tresos solution for NVIDIADRIVE™ PX - A software platform for developing advanced driver assi-stance systems (ADAS). https://www.elektrobit.com/products/ecu/eb-tresos/eb-tresos-solution-nvidia-drive-px/. Version: 2015. – Zugriff: 18.12.2015

[Ele15b] ELEKTROBIT AUTOMOTIVE GMBH: EB tresos installation guide. EB_tresos_installation_guide.pdf. Version: 2.1.0, 2015. – Das PDF befindetsich auf der beiliegenden Daten CD.

[Ele16] ELEKTROBIT AUTOMOTIVE GMBH: Elektrobit AutoCore. https://www.elektrobit.com/products/ecu/eb-tresos/autocore/. Version: 2016. – Zugriff:01.02.2016

[Fü15] FÜRST, Simon: AUTOSAR the Next Generation - The Adaptive Plat-form. http://conf.laas.fr/cars2015/CARS-EDCC2015/CARS@EDCC2015_files/AUTOSAR_CARS@EDCC%202015.pdf. Version: 2015. – Zugriff:05.01.2016


http://www.autosar.org/fileadmin/files/releases/2-0/methodology-templates/methodology/auxiliary/AUTOSAR_Methodology.pdf



http://www.autosar.org/fileadmin/files/releases/4-2/main/auxiliary/AUTOSAR_TR_Glossary.pdf

http://www.autosar.org/fileadmin/files/releases/4-2/main/auxiliary/AUTOSAR_TR_Glossary.pdf

http://www.autosar.org/fileadmin/files/releases/4-2/main/auxiliary/AUTOSAR_EXP_VFB.pdf

http://www.autosar.org/fileadmin/files/releases/4-2/main/auxiliary/AUTOSAR_EXP_VFB.pdf

http://www.continental-automotive.de/www/automotive_de_de/themes/passenger_cars/chassis_safety/ved/fahrwerkselektronik_de.html

http://www.continental-automotive.de/www/automotive_de_de/themes/passenger_cars/chassis_safety/ved/fahrwerkselektronik_de.html

2.4_Studio_documentation_developers_guide.pdf

https://www.elektrobit.com/products/ecu/eb-tresos/eb-tresos-solution-nvidia-drive-px/

https://www.elektrobit.com/products/ecu/eb-tresos/eb-tresos-solution-nvidia-drive-px/

EB_tresos_installation_guide.pdf


https://www.elektrobit.com/products/ecu/eb-tresos/autocore/

https://www.elektrobit.com/products/ecu/eb-tresos/autocore/

http://conf.laas.fr/cars2015/CARS-EDCC2015/CARS@EDCC2015_files/AUTOSAR_CARS@EDCC%202015.pdf

http://conf.laas.fr/cars2015/CARS-EDCC2015/CARS@EDCC2015_files/AUTOSAR_CARS@EDCC%202015.pdf


[GM16] GAI, Paolo ; MORELLI, Bruno: A fully Open-Source Platform for Auto-motive Systems. http://events.linuxfoundation.org/sites/events/files/slides/AGLW_Edimburgh_Evidence_v5.pdf. Version: 2016. – Zugriff: 05.01.2016

[Goo15] GOOGLE INC.: Google Self-Driving Car Project. https://www.google.com/selfdrivingcar/. Version: 2015. – Zugriff: 18.12.2015

[Jan15a] JANN, Christian: DsCom Software Detailed Design Document. DsCom_Software_Detailed_Design_Document.pdf. Version: 0.1, 2015. – Das PDFbefindet sich auf der beiliegenden Daten CD.

[Jan15b] JANN, Christian: AUTOSAR: Portierung RTE auf Linux - Praktikumsbericht.Praktikumsbericht_Christian_Jann.pdf. Version: 1.0, 2015. – Das PDFbefindet sich auf der beiliegenden Daten CD.

[Jan15c] JANN, Christian: AUTOSAR: Porting the RTE to Linux - Project Documen-tation. Project_Documentation_RTE_on_Linux.pdf. Version: 1.0, 2015. –Das PDF befindet sich auf der beiliegenden Daten CD.

[Jan15d] JANN, Christian: EB tresos LxCore integration guide (internal). LxCore_integration_guide_internal.pdf. Version: 2.02, 2015. – Das PDF befindetsich auf der beiliegenden Daten CD.

[Jan15e] JANN, Christian: EB tresos LxCore users guide. LxCore_users_guide.pdf.Version: 2.02, 2015. – Das PDF befindet sich auf der beiliegenden DatenCD.

[KF09] KINDEL, Olaf ; FRIEDRICH, Mario: Softwareentwicklung mit AUTOSAR -Grundlagen, Engeneering, Management in der Praxis. dpunkt.verlag, 2009

[Kil13] KILLIG, Sven: Multicore-Kommunikationsmechanismus zwischenAUTOSAR und Linux. http://sven.killig.de/AUTOSAR/Multi-core-Kommunikationsmechanismus%20zwischen%20AUTOSAR%20und%20Linux.pdf. Version: 2013. – Zugriff: 05.01.2016

[Koh11] KOHLHASE, Markus: rt-tests.git - README.markdown. https://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/tree/README.markdown.Version: 2011. – Zugriff: 05.01.2016

[KPI16] KPIT TECHNOLOGIES LTD.: AUTOSAR Handbook. http://www.kpit.com/downloads/kpit-autosar-handbook.pdf. Version: 2016. – Zugriff:05.01.2016

[MCW12] MARTINUS, Marcus ; CUTURA, Zoran ; WÜRZ, Thomas: Einsatzfälleder VAP im E/E-Entwicklungsprozess. https://www.springerprofessional.de/virtuelle-absicherungs-plattform-integration-und-wiederverwendun/6416088. Version: 2012. – Fachartikel aus: ATZelektronik, Ausgabe1/2012, Springer Fachmedien Wiesbaden

[NS13] NETT, Tillmann ; SCHNEIDER, Jörn: Running Linux and AUTOSAR side byside. http://www.hochschule-trier.de/fileadmin/groups/12/ProSyMig/pub/paper/Nett_Schneider-Running_Linux_and_Autosar.pdf. Version: 2013. –Zugriff: 05.01.2016



http://events.linuxfoundation.org/sites/events/files/slides/AGLW_Edimburgh_Evidence_v5.pdf

http://events.linuxfoundation.org/sites/events/files/slides/AGLW_Edimburgh_Evidence_v5.pdf

https://www.google.com/selfdrivingcar/

https://www.google.com/selfdrivingcar/

DsCom_Software_Detailed_Design_Document.pdf


Praktikumsbericht_Christian_Jann.pdf

Project_Documentation_RTE_on_Linux.pdf

LxCore_integration_guide_internal.pdf


LxCore_users_guide.pdf

http://sven.killig.de/AUTOSAR/Multi-core-Kommunikationsmechanismus%20zwischen%20AUTOSAR%20und%20Linux.pdf



https://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/tree/README.markdown

https://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/tree/README.markdown

http://www.kpit.com/downloads/kpit-autosar-handbook.pdf

http://www.kpit.com/downloads/kpit-autosar-handbook.pdf

https://www.springerprofessional.de/virtuelle-absicherungs-plattform-integration-und-wiederverwendun/6416088



http://www.hochschule-trier.de/fileadmin/groups/12/ProSyMig/pub/paper/Nett_Schneider-Running_Linux_and_Autosar.pdf

http://www.hochschule-trier.de/fileadmin/groups/12/ProSyMig/pub/paper/Nett_Schneider-Running_Linux_and_Autosar.pdf


[NVI15a] NVIDIA CORPORATION: NVIDIA DRIVE™ CX. http://www.nvidia.de/object/drive-cx-de.html. Version: 2015. – Zugriff: 14.09.2015

[NVI15b] NVIDIA CORPORATION: NVIDIA DRIVE™ PX. http://www.nvidia.com/object/drive-px.html. Version: 2015. – Zugriff: 14.09.2015

[Ope16a] OPENSYNERGY GMBH: COQOS SDK. http://www.opensynergy.com/produkte/coqos/. Version: 2016. – Zugriff: 05.01.2016

[Ope16b] OPENSYNERGY GMBH: COQOS-tP. http://www.opensynergy.com/produkte/coqos-tp/. Version: 2016. – Zugriff: 05.01.2016

[OSE05] OSEK: OSEK/VDX Operating System Specification 2.2.3. http://portal.osek-vdx.org/files/pdf/specs/os223.pdf. Version: 2005. – Zugriff:17.12.2015

[PR 15] PR NEWSWIRE: Elektrobit, Infineon und NVIDIA stellen gemeinsamePlattform für automatisiertes Fahren vor. http://www.prnewswire.com/news-releases/elektrobit-infineon-und-nvidia-stellen-gemeinsame-plattform-fur-automatisiertes-fahren-vor-527820251.html. Version: 2015. –Zugriff: 18.12.2015

[RFB15] RÜPING, Thomas ; FÜRST, Simon ; BECHTER, Dr. M.: Zukunft von AutosarWeiter- und Neuentwicklung. http://www.springerprofessional.de/zukunft-von-autosar-weiter--und-neuentwicklung/5912188.html. Version: 2015. –Fachartikel aus: ATZelektronik, Ausgabe 07/2015, Springer FachmedienWiesbaden

[TT13a] THE IEEE ; THE OPEN GROUP: clock_getres, clock_gettime, clock_settime- clock and timer functions. http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html. Version: 2013. – The OpenGroup Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition, Zugriff:05.01.2016

[TT13b] THE IEEE ; THE OPEN GROUP: socket - create an endpoint for communi-cation. http://pubs.opengroup.org/onlinepubs/9699919799/functions/socket.html. Version: 2013. – The Open Group Base Specifications Issue 7 IEEEStd 1003.1, 2013 Edition, Zugriff: 05.01.2016

[TTT15] TTTECH COMPUTERTECHNIK AG: zFAS: Advanced Driver AssistanceSystem Platform for Audi. https://www.tttech.com/de/markets/automotive/projekte-referenzen/audi-zfas/. Version: 2015. – Zugriff: 18.12.2015

[Wik15] WIKIPEDIA: Portable Operating System Interface. https://de.wikipedia.org/wiki/Portable_Operating_System_Interface. Version: 2015. – Zugriff:18.12.2015

[WIR15a] WIRED: Americans Want Self-Driving Cars for the Cheaper Ins-urance. http://www.wired.com/2015/04/americans-want-self-driving-cars-cheaper-insurance/. Version: 2015. – Zugriff: 18.12.2015

[WIR15b] WIRED: Ford’s Skipping the Trickiest Thing About Self-DrivingCars. http://www.wired.com/2015/11/ford-self-driving-car-plan-google/.Version: 2015. – Zugriff: 18.12.2015


http://www.nvidia.de/object/drive-cx-de.html

http://www.nvidia.de/object/drive-cx-de.html

http://www.nvidia.com/object/drive-px.html

http://www.nvidia.com/object/drive-px.html

http://www.opensynergy.com/produkte/coqos/

http://www.opensynergy.com/produkte/coqos/

http://www.opensynergy.com/produkte/coqos-tp/

http://www.opensynergy.com/produkte/coqos-tp/

http://portal.osek-vdx.org/files/pdf/specs/os223.pdf

http://portal.osek-vdx.org/files/pdf/specs/os223.pdf

http://www.prnewswire.com/news-releases/elektrobit-infineon-und-nvidia-stellen-gemeinsame-plattform-fur-automatisiertes-fahren-vor-527820251.html



http://www.springerprofessional.de/zukunft-von-autosar-weiter--und-neuentwicklung/5912188.html

http://www.springerprofessional.de/zukunft-von-autosar-weiter--und-neuentwicklung/5912188.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/socket.html

http://pubs.opengroup.org/onlinepubs/9699919799/functions/socket.html

https://www.tttech.com/de/markets/automotive/projekte-referenzen/audi-zfas/

https://www.tttech.com/de/markets/automotive/projekte-referenzen/audi-zfas/

https://de.wikipedia.org/wiki/Portable_Operating_System_Interface

https://de.wikipedia.org/wiki/Portable_Operating_System_Interface

http://www.wired.com/2015/04/americans-want-self-driving-cars-cheaper-insurance/

http://www.wired.com/2015/04/americans-want-self-driving-cars-cheaper-insurance/

http://www.wired.com/2015/11/ford-self-driving-car-plan-google/


[WIR15c] WIRED: Turns Out the Hardware in Self-Driving Cars Is PrettyCheap. http://www.wired.com/2015/04/cost-of-sensors-autonomous-cars/.Version: 2015. – Zugriff: 18.12.2015

[Wol06] WOLF, Jürgen: Linux-UNIX-Programmierung - Das umfassende Hand-buch. http://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap11-017.htm#RxxKap11017040003961F026100. Version: 2006. – 2.aktualisierte und erweiterte Auflage, Rheinwerk Computing

[ZS14] ZIMMERMANN, Werner ; SCHMIDGALL, Ralf: Bussysteme in der Fahrzeug-technik - Protokolle, Standards und Softwarearchitektur. Springer Vieweg,2014



http://www.wired.com/2015/04/cost-of-sensors-autonomous-cars/

http://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap11-017.htm#RxxKap11017040003961F026100

http://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap11-017.htm#RxxKap11017040003961F026100

Selbstständigkeitserklärung

Studentenservice – Zentrales Prüfungsamt

Selbstständigkeitserklärung

�

�

�

Name:

Vorname:

geb. am:

Matr.-Nr.:

Bitte beachten:

1. Bitte binden Sie dieses Blatt am Ende Ihrer Arbeit ein.

Selbstständigkeitserklärung*

Ich erkläre gegenüber der Technischen Universität Chemnitz, dass ich die vorliegende

selbstständig und ohne Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt habe.

Die vorliegende Arbeit ist frei von Plagiaten. Alle Ausführungen, die wörtlich oder inhaltlich aus anderen Schriften entnommen

sind, habe ich als solche kenntlich gemacht.

Diese Arbeit wurde in gleicher oder ähnlicher Form noch bei keinem anderen Prüfer als Prüfungsleistung eingereicht und ist

auch noch nicht veröffentlicht.

Datum: ……………………………………. Unterschrift: ………………………………………………………………………

d

* Statement of Authorship

I hereby certify to the Technische Universität Chemnitz that this thesis is all my own work and uses no external material other

than that acknowledged in the text.

This work contains no plagiarism and all sentences or passages directly quoted from other people’s work or including content

derived from such work have been specifically credited to the authors and sources.

This paper has neither been submitted in the same or a similar form to any other examiner nor for the award of any other

degree, nor has it previously been published.

Jann

Christian

28.03.1989

220004

Masterarbeit

10.02.2015


Anhang A

Quelltextausschnitte

CDD_DsCom_Template.c

12 / **3 * \ f i l e CDD_DsCom_Template . c4 *5 * \ b r i e f Genera ted Templa te f o r DsCom .6 *7 * T h i s f i l e c o n t a i n s an Rte component t e m p l a t e / example code8 *9 * T h i s f i l e has been a u t o m a t i c a l l y g e n e r a t e d by

10 * EB t r e s o s AutoCore Rte Genera tor V e r s i o n 6 . 1 . 1 5 411 * on Wed Dec 16 1 0 : 5 2 : 3 6 CET 2015 . ! ! ! IGNORE−LINE ! ! !12 *13 * \ a u t h o r E l e k t r o b i t A u t o m o t i v e GmbH, 91058 Erlangen , Germany14 *15 * C o p y r i g h t 2005 − 2015 E l e k t r o b i t A u t o m o t i v e GmbH16 * A l l r i g h t s e x c l u s i v e l y r e s e r v e d f o r E l e k t r o b i t A u t o m o t i v e GmbH,17 * u n l e s s e x p r e s s l y agreed t o o t h e r w i s e .18 * /1920 # i n c l u d e "Rte_CDD_DsCom . h "2122 / *−−−−[r u n n a b l e e n t i t y s k e l e t o n s ]−−−−* /2324 v o i d CDD_DsCom_RE_Init ( v o i d )25 {26 S t d _ R e t u r n T y p e s t a t u s ;27



28 R t e _ I r T r i g g e r _ R E _ I n i t _ T P _ A c t i v a t e F w d D a t a T a s k ( ) ;2930 }3132 v o i d CDD_DsCom_RE_TransmitData_IpcTest ( P2VAR ( u i n t 8 , AUTOMATIC ,

RTE_APPL_DATA ) DataPtr , u i n t 3 2 DataLen )33 {34 S t d _ R e t u r n T y p e s t a t u s ;3536 }3738 v o i d CDD_DsCom_RE_TransmitData_MessageRouter ( P2VAR ( u i n t 8 , AUTOMATIC ,

RTE_APPL_DATA ) DataPtr , u i n t 3 2 DataLen )39 {40 S t d _ R e t u r n T y p e s t a t u s ;4142 }4344 v o i d CDD_DsCom_RE_PrintStats ( v o i d )45 {46 S t d _ R e t u r n T y p e s t a t u s ;4748 }4950 v o i d CDD_DsCom_RE_FwdDataTask ( v o i d )51 {52 u i n t 3 2 DataLen_0 ;53 u i n t 8 DataPtr_0 ;54 u i n t 3 2 DataLen ;55 u i n t 8 DataPtr ;56 S t d _ R e t u r n T y p e s t a t u s ;5758 s t a t u s = Rte_Cal l_R_DataOut_IpcTes t_FwdData (& DataPtr , DataLen ) ;5960 s t a t u s = Rte_Call_R_DataOut_MsgR_FwdData(& DataPtr_0 , DataLen_0 ) ;6162 }

Auflistung A.1 CDD_DsCom_Template.c



ToplevelComposition.arxml

1 <?xml v e r s i o n =" 1 . 0 " e n c o d i n g ="UTF−8" ?>2 <AUTOSAR xmlns=" h t t p : / / a u t o s a r . o rg / schema / r4 . 0 "3 xmlns : x s i =" h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema−i n s t a n c e "4 x s i : s chemaLoca t ion =" h t t p : / / a u t o s a r . o rg / schema / r4 . 0 AUTOSAR_4−0−3

_STRICT_COMPACT . xsd ">5 <AR−PACKAGES>6 <AR−PACKAGE>7 <SHORT−NAME>CanSystem </SHORT−NAME>8 <ELEMENTS>9 <SYSTEM>

10 <SHORT−NAME>CanSystem </SHORT−NAME>11 <MAPPINGS>12 <SYSTEM−MAPPING>13 <SHORT−NAME>SystemMappingBsw </SHORT−NAME>14 <SW−MAPPINGS>15 <SWC−TO−ECU−MAPPING>16 <SHORT−NAME>EcuPerformanceNodeMappingBsw </SHORT−

NAME>17 <COMPONENT−IREFS>18 <COMPONENT−IREF>19 <CONTEXT−COMPOSITION−REF DEST="ROOT−SW−

COMPOSITION−PROTOTYPE" >/ CanSystem / CanSystem / TopLevelComposi t ion < /CONTEXT−COMPOSITION−REF>

20 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE" >/ DemoAppl ica t ion / SwComponentTypes / TopLeve lCompos i t ion /BswM</TARGET−COMPONENT−REF>

21 </COMPONENT−IREF>22 <COMPONENT−IREF>23 <CONTEXT−COMPOSITION−REF DEST="ROOT−SW−


24 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE" >/ DemoAppl ica t ion / SwComponentTypes / TopLeve lCompos i t ion /Det < /TARGET−COMPONENT−REF>

25 </COMPONENT−IREF>26 <COMPONENT−IREF>27 <CONTEXT−COMPOSITION−REF DEST="ROOT−SW−


28 <TARGET−COMPONENT−REF DEST="SW−COMPONENT−PROTOTYPE" >/ DemoAppl ica t ion / SwComponentTypes / TopLeve lCompos i t ion /DsCom</TARGET−COMPONENT−REF>

29 </COMPONENT−IREF>



30 </COMPONENT−IREFS>31 <ECU−INSTANCE−REF DEST="ECU−INSTANCE" >/ CanSystem /

ECUINSTANCES / EcuTestNode </ECU−INSTANCE−REF>32 </SWC−TO−ECU−MAPPING>33 </SW−MAPPINGS>34 </SYSTEM−MAPPING>35 </MAPPINGS>36 <SYSTEM−VERSION> 1 . 0 . 0 < /SYSTEM−VERSION>37 </SYSTEM>38 </ELEMENTS>39 </AR−PACKAGE>40 <AR−PACKAGE>41 <SHORT−NAME> DemoAppl ica t ion < /SHORT−NAME>42 <AR−PACKAGES>43 <AR−PACKAGE>44 <SHORT−NAME>SwComponentTypes < /SHORT−NAME>45 <ELEMENTS>46 <COMPOSITION−SW−COMPONENT−TYPE>47 <SHORT−NAME> TopLevelCompos i t ion < /SHORT−NAME>48 <COMPONENTS>49 <SW−COMPONENT−PROTOTYPE>50 <SHORT−NAME>BswM</SHORT−NAME>51 <TYPE−TREF DEST="SERVICE−SW−COMPONENT−TYPE" >/

AUTOSAR_BswM/ SwComponentTypes /BswM</TYPE−TREF>52 </SW−COMPONENT−PROTOTYPE>53 <SW−COMPONENT−PROTOTYPE>54 <SHORT−NAME>Det < /SHORT−NAME>55 <TYPE−TREF DEST="SERVICE−SW−COMPONENT−TYPE" >/

AUTOSAR_Det / SwComponentTypes / D e v e l o p m e n t E r r o r T r a c e r < /TYPE−TREF>56 </SW−COMPONENT−PROTOTYPE>57 <SW−COMPONENT−PROTOTYPE>58 <SHORT−NAME>DsCom</SHORT−NAME>59 <TYPE−TREF DEST="SERVICE−SW−COMPONENT−TYPE" >/

AUTOSAR_DsCom / SwComponentTypes / DsCom</TYPE−TREF>60 </SW−COMPONENT−PROTOTYPE>61 </COMPONENTS>62 </COMPOSITION−SW−COMPONENT−TYPE>63 </ELEMENTS>64 </AR−PACKAGE>65 </AR−PACKAGES>66 </AR−PACKAGE>67 </AR−PACKAGES>68 </AUTOSAR>

Auflistung A.2 ToplevelComposition.arxml



Perf2.c

1 / **2 * \ f i l e P e r f 2 . C3 *4 * \ b r i e f P e r f o r m a n c e t e s t , T e s t s e q u e n c e 25 *6 * \ a u t h o r E l e k t r o b i t A u t o m o t i v e GmbH, 91058 Erlangen , Germany7 * \ a u t h o r M o d i f i e d by C h r i s t i a n Jann8 *9 * C o p y r i g h t 2005 − 2015 E l e k t r o b i t A u t o m o t i v e GmbH

10 * A l l r i g h t s e x c l u s i v e l y r e s e r v e d f o r E l e k t r o b i t A u t o m o t i v e GmbH,11 * u n l e s s e x p r e s s l y agreed t o o t h e r w i s e .12 * /1314 # i n c l u d e " o s e k t e s t . h "15 # i n c l u d e < c o n f i g . h>16 # i n c l u d e <debug . h>17 # i n c l u d e <board . h>18 # i n c l u d e <t i m e . h>1920 DECLARE_SEQUENCE ( " abcd " ) ;2122 s t r u c t t i m e s p e c s t a r t , end ;23 l ong N S A c t i v a t e T a s k = 0;24 l ong NSSchedule = 0;25 l ong NSTerminateTask = 0;2627 l ong my_ge t_ t ime ( )28 {29 s t r u c t t i m e s p e c t ;30 c l o c k _ g e t t i m e (CLOCK_MONOTONIC, &t ) ;31 r e t u r n ( long ) ( t . t v _ s e c ) * 1 . 0 e9 +( long ) ( t . t v _ n s e c ) ;32 }3334 # d e f i n e m y _ s t a r t _ t i m e ( ) ( c l o c k _ g e t t i m e (CLOCK_MONOTONIC, &s t a r t ) )35 # d e f i n e m y _ s t o p _ t i m e ( ) ( c l o c k _ g e t t i m e (CLOCK_MONOTONIC, &end ) )36 # d e f i n e m y _ g e t _ n s _ t i m e ( ) ( ( l ong ) ( end . t v _ s e c − s t a r t . t v _ s e c ) * 1 . 0 e9

+( long ) ( end . t v _ n s e c − s t a r t . t v _ n s e c ) )37 # d e f i n e GetTime1 ( f u n c t i o n , a ) ( m y _ s t a r t _ t i m e ( ) , ( f u n c t i o n ( a ) ) ,

m y _ s t o p _ t i m e ( ) , m y _ g e t _ n s _ t i m e ( ) )3839 TASK ( t a s k 1 ) {4041 OS_WINLINPrint f ( " Task1 e n t r y \ r \ n " ) ;



42 INIT_SEQUENCE ( ) ;43 / * i n i t _ t i m e ( ) ; * /4445 OS_WINLINPrint f ( "ADD_SEQUENCE( ’ a ’ ) \ r \ n " ) ;4647 ADD_SEQUENCE( ’ a ’ ) ;4849 N S A c t i v a t e T a s k = GetTime1 ( A c t i v a t e T a s k , t a s k 2 ) ;5051 OS_WINLINPrint f ( "ADD_SEQUENCE( ’ b ’ ) \ r \ n " ) ;52 ADD_SEQUENCE( ’ b ’ ) ;5354 m y _ s t a r t _ t i m e ( ) ;5556 S c h e d u l e ( ) ;5758 m y _ s t o p _ t i m e ( ) ;5960 NSTerminateTask = m y _ g e t _ n s _ t i m e ( ) ;6162 OS_WINLINPrint f ( "ADD_SEQUENCE( ’ d ’ ) \ r \ n " ) ;63 ADD_SEQUENCE( ’ d ’ ) ;6465 OS_WINLINPrint f ( " N S A c t i v a t e T a s k : %d \ r \ n " , N S A c t i v a t e T a s k ) ;66 OS_WINLINPrint f ( " NSTermina teTask : %d \ r \ n " , NSTermina teTask ) ;67 OS_WINLINPrint f ( " NSSchedule : %d \ r \ n " , NSSchedule ) ;6869 OS_WINLINPrint f ( " CSV , %d , %d , %d \ r \ n " , N S A c t i v a t e T a s k ,

NSTerminateTask , NSSchedule ) ;7071 EVALUATE_RESULTS ( ) ;7273 OS_WINLINPrint f ( " Task1 e x i t \ r \ n " ) ;7475 T e r m i n a t e T a s k ( ) ;76 Panic ( " Shou ld n o t come here ! " ) ;77 }7879 TASK ( t a s k 2 ) {80 m y _ s t o p _ t i m e ( ) ;8182 OS_WINLINPrint f ( " Task2 e n t r y \ r \ n " ) ;8384 NSSchedule = m y _ g e t _ n s _ t i m e ( ) ;8586 OS_WINLINPrint f ( "ADD_SEQUENCE( ’ c ’ ) \ r \ n " ) ;



87 ADD_SEQUENCE( ’ c ’ ) ;8889 OS_WINLINPrint f ( " Task2 e x i t \ r \ n " ) ;9091 m y _ s t a r t _ t i m e ( ) ;9293 T e r m i n a t e T a s k ( ) ;94 }

Auflistung A.3 Perf2.c



dscom_ipctest_timeit.py

1 # −*− co d i ng : u t f −8 −*−2 i m p o r t s o c k e t3 i m p o r t os4 i m p o r t s y s5 i m p o r t random , s t r i n g6 i m p o r t t ime7 i m p o r t t i m e i t89 d a t a = "EBEB−EBEB−EBEB−EBEB−EBEB−EBEB−EBEB−EBEB"

10 num = 101112 c l i e n t = s o c k e t . s o c k e t ( s o c k e t . AF_UNIX , s o c k e t . SOCK_SEQPACKET)13 c l i e n t . c o n n e c t ( " / run / eb / I p c T e s t . sock " )14 p r i n t ( " E x e c u t i n g t h e t e s t f u n c t i o n %d t i m e s : " % num )1516 d e f t e s t _ f c t ( ) :17 c l i e n t . send ( d a t a )18 r = c l i e n t . r e c v ( l e n ( d a t a ) )19 s y s . s t d o u t . w r i t e ( ’ . ’ )20 s y s . s t d o u t . f l u s h ( )21 i f d a t a != r :22 p r i n t ( " E r r o r : Rece ived s t r i n g does n o t match s e n t s t r i n g " )2324 t = t i m e i t . t i m e i t ( " t e s t _ f c t ( ) " , " from __main__ i m p o r t t e s t _ f c t " ,

number=num )2526 p r i n t ( " " )27 p r i n t ( "CSV, %f " % t )28 p r i n t ( "On a v e r a g e i t t ook %f m i l l i s e c o n d s t o e x e c u t e t h e t e s t

f u n c t i o n . " % ( t * 1000) )293031 c l i e n t . c l o s e ( )3233 p r i n t ( " Done " )

Auflistung A.4 dscom_ipctest_timeit.py



Anhang B

Inhalt der beiliegenden Daten CD

2.4_Studio_documentation_developers_guide.pdf

Das ist die Standard EB tresos Studio Dokumentation für Entwickler von Modulenund Erweiterungen.


Software Detailed Design Document für das DsCom Modul. Gibt einen Überblicküber die Funktionsweise des DsCom Moduls.


Standardmäßige EB tresos Studio Installationsanleitung.

LxCore_getting_started.pdf

Diese Anleitung beschreibt die ersten Schritte mit dem LxCore, wie man einBeispielprojekt importiert und kompiliert.


Diese Anleitung beschreibt die Integration des LXTHREADS OS mit der RTEund weiteren Modulen vom WinCore.

LxCore_users_guide.pdf

Die Benutzeranleitung zum EB tresos LxCore mit zahlreichen Tipps und Hinwei-sen.

Praktikumsbericht_Christian_Jann.pdf

Praktikumsbericht zum Praktikum „AUTOSAR: Portierung RTE auf Linux“.

Project_Documentation_RTE_on_Linux.pdf


Inhalt der Daten CD

Projektdokumentation zum Praktikum „AUTOSAR: Portierung RTE auf Li-nux“ mit weiteren Informationen zum Thema RTE on Linux.

DsCom_TS_T36D1M1I0R0.zip

Quelltext des DsCom Moduls.

simple_demo_rte_LXTHREADSX86_6.0.6_with_dscom.zip

Demo-Projekt aus Abschnitt 5.3 „Workflow LxCore und DsCom“ mit dem inte-grierten DsCom Modul.

test_projects_results.zip

Messdaten zur Performance Messung aus Abschnitt 6.4 „Performance und JitterMessung“.

Ergebnisse_Zeitmessung_DsCom_Modul_CDD.zip

Messdaten zu Abschnitt 6.4.2 „Zeitmessung DsCom mit Softwarekomponente“.



koexistenz von autosar softwarekomponenten und linux

Documents