Bachelorarbeit, 2018
65 Seiten, Note: 1,7
1 Einleitung
2 Einführung: AUTOSAR
3 Classic AUTOSAR
4 Adaptive AUTOSAR
5 Classic vs. Adaptive
6 Hardware
7 Yocto Project
8 Umsetzung des Projektes
9 Zusammenfassung
10 Ausblick
Literaturverzeichnis
Glossar
Anhang A 1. Code
Anhang A 2. Workflow-Rezept
Anhang A 3. Interaktion der Dienste
Anhang A 4. Ausführung der Basis-Applikation
Anhang A 5. Workflow-OE
Anhang A 6. State Management
Abb. 1: Vergleich der Softwareentwicklung früher und heute
Abb. 2: Einfluss der Mitglieder
Abb. 3: Schwerpunkte von AUTOSAR Classic
Abb. 4: Softwarearchitektur von AUTOSAR Classic
Abb. 5: Softwarearchitektur im Detail
Abb. 6: Methodik von AUTOSAR CLASSIC
Abb. 7: Softwarearchitektur von Adaptive AUTOSAR
Abb. 8: Ausführung des Execution Mangers
Abb. 9: Access Management
Abb. 10: Service Discovery
Abb. 11: Struktur des Communication Managements
Abb. 12: REST-Aufbau
Abb. 13: Time Synchronization
Abb. 14: Logging and Tracing
Abb. 15: Diagnose UCM
Abb. 16: Methodik von Adaptive AUTOSAR
Abb. 17: MinnowBoard Turbo
Tab. 1: Classic Platform vs. Adaptive Platform
Code 1: Service-Interface
Code 2: Anwendungsdesign
Code 3: Executable
Code 4: Process
Code 5: Execution Manager
Code 6: Service Initialisierung
Code 7: Event senden
Code 8: Proxy Initialisieren
Code 9: Blinken
Abbildung in dieser Leseprobe nicht enthalten
Zur Realisierung von Softwareprojekten setzt die Automobilindustrie auf eine einheitliche Softwarearchitektur, die vom AUTOSAR-Konsortium definiert ist. Das Konsortium veröffentlichte im Jahre 2003 den ersten Standard, Classic AUTOSAR, der für tief eingebettete Systeme mit hohen Echtzeit- und Sicherheitsanforderungen entwickelt wurde. Mit dem rapiden Fortschritt der Technologien entstanden neue Anforderungen sowie komplexere Systeme, die von Classic AUTOSAR nicht abgedeckt werden können. Deshalb veröffentlichte das AUTOSAR-Konsortium im Jahre 2017 den neuen Standard, Adaptive AUTOSAR, der für Steuergeräte mit einer hohen Performance und Fehlertoleranz entwickelt ist.
Das Ziel dieser Arbeit ist das Kennenlernen des neuen Standards durch die Entwicklung einer Basis-Applikation auf Grundlage der Adaptive-AUTOSAR-Laufzeitumgebung. Dazu wurde zunächst das Classic AUTOSAR und dessen Architektur vorgestellt. Anschließend wurde das Adaptive AUTOSAR detailliert beschrieben. Hierzu wurden die Funktionsgruppen von Adaptive AUTOSAR erläutert. Um die Unterschiede der beiden Standards hervorzuheben, wurde zudem ein Vergleich aufgezeigt.
Schließlich wurde aus den gewonnenen Informationen eine Basis-Applikation entwickelt, die auf Grundlage des Releases 17-03 entwickelt wurde. Auf dieser Weise wurden Eigenschaften und Funktionalitäten von Adaptive AUTOSAR deutlich.
For the realization of software projects, the automotive industry relies on a uniform software architecture, which is defined by the AUTOSAR consortium. In 2003 the consortium released the first standard, Classic AUTOSAR, which was developed for deeply embedded systems with high real-time and security requirements. With the rapid advances in technology, new requirements have arisen, as well as more complex systems that cannot be managed with Classic AUTOSAR. Therefore, the AUTOSAR consortium released the new standard Adaptive AUTOSAR in 2017, which is designed for ECUs with high performance and fault tolerance.
The aim of this work is to get to know the new standard by developing a basic application, which is grounded on the Adaptive-AUTOSAR runtime environment. First the Classic AUTOSAR and its architecture is explained. Subsequently the Adaptive AUTOSAR is described in detail. For this, the functional groups of Adaptive AUTOSAR are explained. To highlight the differences between the two standards, a comparison was also shown.
Finally, a basic application was developed from the information obtained, which was developed based on the 17-03 release. In this way, features and functionalities of Adaptive AUTOSAR became clear.
Im Folgenden wird das Unternehmen vorgestellt sowie dessen Motivation, die aufgestellten Aufgaben erläutert und der Aufbau der Arbeit aufgezeigt.
Lear Corporation wurde im Jahre 1917 unter dem Namen American Metal Products in Detroid, Michigan, gegründet. Seinerzeit wurden rohrförmige, geschweißte und gestanzte Baugruppen für die Automobil- und Flugzeugindustrie gefertigt. Den uns bekannten Namen Lear erhielt das Unternehmen erst mit dem Gang an die Börse im Jahre 1994 [LearH 2018, S.1].
Neben dem neuen Hauptsitz in Southfield, Michigan hat das Unternehmen weitere Niederlassungen in 39 Ländern auf dem Globus verteilt. Mittlerweile zählt Lear Coperation mit ca. 165000 Mitarbeitern [LearL 2018, S.1] als der elftgrößte Automobilzulieferer der Welt [TopSuppliers 2017, S. 17] und als größter Lieferant für Innenraum Systeme und Komponente [Bayern Int. 2018, S1].
Unter den 257 weltweit verteilten Standorten befinden sich 16 davon in Deutschland. Unter anderem in Sindelfingen, Eisenach, Garching, Wolfsburg und Kronach [LearL 2018, S.1].
Der Standort Kronach betreibt nicht nur Entwicklung, sondern ist auch ein Fertigungsstandort. Auf dieser Weise ist es möglich, ein Produkt vollständig in Kronach zu fertigen. Zu dem aktuellen Produktspektrum zählen Steuergeräte für die Fahrzeugbeleuchtung, Gateway-Module für verschiedene Bus-Systeme und Sound-Systeme [Bayern Innov 2018, S.1].
Der Standard Adaptive AUTOSAR wurde entwickelt, um den neuen Anwendungsszenarien der Automobilindustrie gerecht zu werden. Als Premium Partner (siehe 2.1) des AUTOSAR Konsortiums besteht für Lear Corporation ein großes Interesse an dem neuen Standard. Die Lear Corporation und die Abteilung Gateways möchten den neuen Standard frühzeitig anwenden und somit die Kundenaufträge schneller umsetzen. Deshalb soll eine Basis-Applikation auf Grundlage der Adaptive-AUTOSAR Laufzeitumgebung entwickelt werden.
Zum Kennenlernen der Hardware (MinnowBoard Max Turbot) und der Entwicklungsumgebung sollen kleinere Projekte realisiert werden. Die folgenden Projekte sollen die Entwicklung der Basis-Applikation erleichtern.
- LED-Steuerung
- Yocto-Hello-World
- Some/IP-Hello-World
Im Anschluss soll auf der Basis von AUTOSAR bereit gestellten Daten eine eigene Basis-Applikation mit dazugehörigem Service entwickelt werden.
Die Applikation soll auf der Experimentierplatine MinnowBoard laufen und dessen LED ansteuern. Dieser soll zunächst die Verbindung zum Service aufbauen, welcher einen Blinkservice anbietet. Daraufhin soll dieser Service die Blinkfrequenz für die Basis-Applikation vorgeben.
Das Ziel des Projektes ist das Kennenlernen des neuen AUTOSAR Standards sowie dessen Schichten bzw. Funktionsgruppen.
Die Arbeit gliedert sich in neun Kapitel. Das 2. Kapitel gibt eine Einführung in AUTOSAR, indem die Motivation, Ziele, Organisation und Vorteile von AUTOSAR verdeutlicht sind. Kapitel 3 befasst sich mit dem Classic AUTOSAR Standard sowie dessen Schwerpunkte und Anwendungsbereich. Das 4. Kapitel hingegen beschreibt den neuen Adaptive AUTOSAR Standard, wobei die Eigenschaften, Architektur und Funktionsgruppen der neuen Plattformen sowie deren Methodik klargelegt werden. Zudem behandelt es die SOME/IP-Middleware des Standards und den Anwendungsbereich von Adaptive AUTOSAR. Des Weiteren vergleicht Kapitel 5 die beiden Standards und schildert deren Interoperabilität. Im 6. Kapitel wird die verwendete Hardware vorgestellt. Anschließend wird im 7. Kapitel über das Build-System Yocto-Projekt aufgeklärt. Kapitel 8 erläutert die Realisierung des Projektes, indem die Einstellung des Build-Systems und die Entwicklung der Basis-Applikation erklärt wird. Hier werden Grundkenntnisse in XML und C++ erwartet. Im 9. Kapitel wird eine Zusammenfassung erbracht. Kapitel 10 gibt einen abschließenden Ausblick zu Adaptive AUTOSAR und der Basis-Applikation.
AUTOSAR (Automotive Open System ARchitecture) ist eine Entwicklungspartnerschaft aus Automobilherstellern, Zulieferern, Dienstleistern und Unternehmen aus der Automobilelektronik, Halbleiter und Softwareindustrie [autosar 2018, S.1], die im Jahr 2003 initiiert wurde [autosarH 2018, S.1]. Im Folgenden wird auf die Motivation der Partner sowie deren Ziele und Organisation eingegangen. Außerdem werden die Vorteile von AUTOSAR erläutert.
Im Laufe der letzten Jahrzehnte stiegen die Anforderungen an das Fahrzeug deutlich an. Dies führte dazu, dass die Softwareentwicklung immer mehr an Bedeutung gewann. Um die Anforderungen wie z. B. Sicherheit, Umweltschutz und Komfort zu bewerkstelligen, benötigt man neben Kontrollsystemen auch Sensoren und Aktoren. Außerdem müssen diese Komponenten alle simultan miteinander interagieren können [Fürst+2015, S.106]. Die Umsetzung der Funktionen war meist fahrzeugspezifisch, dadurch wurde die Wiederverwendung der Funktionen in anderen Fahrzeugbaureihen erschwert [Reif 2007 S.51]. Die Abbildung 1 vergleicht die damalige Softwareentwicklung mit und ohne AUTOSAR. Um die wachsende Komplexität und steigende Anzahl an Abhängigkeiten, somit auch die Entwicklungskosten, zu beherrschen, muss ein Standard entworfen werden [Bunzel 2010, S.79].
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Vergleich der Softwareentwicklung früher und heute
Quelle: [Automotive 2018, S. 1]
Die primären Ziele von AUTOSAR lassen sich in folgenden Punkten zusammenfassen ([Reif 2007 S.51], [autosarAbout 20018, S.1]):
- Zukünftige Anforderungen der Verfügbarkeit, Sicherheit und Softwareupdates bzw. -upgrades erfüllen
- Skalierbarkeit und Flexibilität der Funktionen erhöhen
- Unterstützung von Seriensoftware ohne individuelle Anpassung, auch Commercial Off-The-Shelf-Software (COTS) genannt
- Kostenoptimierung
- Wiederverwendbarkeit von Software
- Wartbarkeit über den gesamten Produktionszyklus
Neben den allgemeinen Zielen sind auch detaillierte Ziele der jeweiligen Standards definiert. So sind die Projektziele vom Classic AUTOSAR und der Weiterentwicklung Adaptive AUTOSAR in den Dokumenten „Main Requirements“ [MR 2014, S.7] und „General Requirements specific to Adaptive Platform“ [GRAP 2017, S.7] zu finden.
Um die oben erwähnten Ziele zu erreichen, schlossen sich die BMW Group, Bosch, Continental, Daimler und die Volkswagen Group, als Core Partner für die Entwicklung eines gemeinsamen Standards zusammen [autosarH 2018, S.1]. Zudem schlossen sich dieser Partnerschaft später auch Ford, Toyota, General Motors und die PSA Group an [CorePartners 2018, S.1]. Hier sind vor allem OEMs (Original Equipment Manufacturer) und die zwei größten Automobilzulieferer [TopSuppliers 2017, S. 17] vertreten. Sie koordinieren und betreuen die Entwicklung von AUTOSAR [Fürst+2015, S.106].
Typischerweise zählen die Tier-1-Supplier (diejenigen die direkt an die OEMs liefern) sowie Werkzeughersteller zu den Premium Partnern [Kindel+2009, S.52]. Sie interessieren sich an der Entwicklung und kommerziellen Nutzung von AUTOSAR [Kindel+2009, S. 51]. Dazu stehen ihnen laufende Arbeiten sowie unveröffentlichte Informationen bereit [autosar 2018, S.1]. Deren Anzahl beläuft sich aktuell auf 55 Mitglieder, zu denen auch die Lear Corporation zählt [PPartners 2018, S.1].
Darüber hinaus gibt es die Associate Partner, die sich aus anderen Zulieferern und Unternehmen mit Interesse an kommerzieller Nutzung bilden [Kindel+2009, S. 51f]. Ihnen stehen nur veröffentlichte Informationen und abgeschlossene Ergebnisse zur Verfügung [autosar 2018, S.1]. Die Anzahl dieser Partnerschaft bemisst sich aktuell auf 114 Mitglieder [APartners 2018, S.1]. Die Zusammenarbeit der AUTOSAR-Mitglieder lässt sich mit einer Ringstruktur (siehe Abb. 2) darstellen. Es ist zu erkennen, dass die Rechte und Pflichten in Richtung der äußeren Ringe abnimmt
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Einfluss der Mitglieder
Neben den genannten Partnerschaften gibt es auch die Development Partner, die durch ihr besonderes Fachwissen interessant für AUTOSAR Konsortium sind. Im Gegenzug für ihr Know-how erhalten sie auch ohne finanzielle Beitragsleistung die Ergebnisse von AUTOSAR [Kindel+2009, S. 51].
Wie die Abb. 1. ermöglicht AUTOSAR eine klare Hardwareunabhängigkeit. Neben den Vorteilen, die mit den erwähnten Zielen einhergehen, bietet AUTOSAR die Austauschbarkeit von Komponenten. Auf diese Weise wird auch die Wiederverwendung des Softwareumfeldes gewährleistet. Das bringt den Vorteil, dass ein OEM zwischen Lösungen mehrerer Zulieferer wählen, aber auch, dass ein Zulieferer mehrere OEMs beliefern kann [Kindel+2009, S. 199].
Das Classic AUTOSAR ist die erste Softwarearchitektur, die von AUTOSAR veröffentlicht wurde. Dabei wurden die Bereiche Architektur, Methodik und Anwendungsschnittstellen (API) als Schwerpunkte gesetzt, um die beschriebenen Ziele (siehe 2.3) zu erreichen. Im Folgenden wird auf die einzelnen Schwerpunkte einzeln eingegangen, die durch die Abbildung 3 dargestellt sind [Schäfer 2014, S.18].
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Schwerpunkte von AUTOSAR Classic
Das Einsatzgebiet vom Classic AUTOSAR sind eingebettete Systeme mit einer hohen Echtzeit- und Sicherheitsanforderungen [TR_Fdt 2017, S. 4], die mit einer starken Verteilung, geringen Ressourcen und hohen Kostendruck ausgestattet sind [Kindel+2009, S. 60]. Dadurch erschließen sich neben den Automotivsystemen, als Haupteinsatzgebiet, auch weitere potentielle Einsatzgebiete. Beispiele dafür sind Automatisierungstechnik, Schienenfahrzeuge und Verteidigungssektor [Kindel+2009, S. 63].
Die Architektur erfüllt das Ziel der Unabhängigkeit der Anwendungssoftware von der Hardware. Ferner setzt das Classic AUTOSAR auf ein Schichtenmodel (Layered Software Architecture), dass sich in Anwendungssoftware, Run-Time-Environment (RTE) und Basissoftware unterteilt [Fürst+2015, S.109].
Die Abbildung 4 zeigt den Aufbau dieser Softwareschichten. Des Weiteren wird auf die einzelnen Abstraktionsschichten eingegangen, beginnend mit der Obersten. Zudem wird die Basissoftware im Kapitel 3.3 ausgeführt, da sie eine detailliertere Behandlung erfordert.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4: Softwarearchitektur von AUTOSAR Classic
Quelle: [EXP_Layered 2017, S.10]
Die Anwendungssoftware-Schicht ist die oberste Sicht und beinhaltet die Anwendungssoftwarekomponenten und Sensor- bzw. Aktor-Softwarekomponenten. Da die Sensor- und Aktorsoftwarekomponenten abhängig von der Hardware sind, muss eine Trennung zur hardwareunabhängigen Anwendungssoftwarekomponente stattfinden. Diese Trennung ist notwendig, um die Portierbarkeit der Anwendung auf verschiedener Hardware zu ermöglichen [Kindel+2009, S. 119]. Damit die verschiedenen Softwarekomponenten trotzdem untereinander bzw. mit der Basissoftware kommunizieren können, benötigt man die Runtime Environment. [Fürst+2015, S.109].
Die AUTOSAR Runtime Environment (RTE) liegt zwischen der Anwendungssicht und Basissoftware (BSW). Zudem abstrahiert sie die Anwendungsschicht von der BSW und dient als Schnittstelle zur Plattform [Meroth+2008, S.293]. Von daher ist sie für die Kommunikation zwischen den Anwendungen und der Basissoftware, aber auch zwischen den Softwarekomponenten der Basissoftware zuständig [Fürst+2015, S.114]. Hierzu muss eine Beschreibung der Funktionalität, Übertragungsparameter und Rückgabewerte als XML-Datei bereitgestellt werden. Mithilfe dieser Datei wird durch ein RTE-Generator eine RTE mit entsprechender Kommunikationsverbindungen erzeugt [Kindel+2009, S. 119]. Es muss beachten werden, dass die RTE für jedes Steuergerät, auch ECU (electronic control unit) genannt, spezifisch generiert wird [EXP_Layered 2017, S.17]. Folglich benötigt man eine Neugenerierung bei Verschiebungen von Anwendungen zwischen Steuergeräten, da sich auch die Systemsicht ändert [Kindel+2009, S. 120].
Die Basissoftware dient als Schnittstelle zu den angebotenen Systemdiensten und -funktionen. Dabei gliedert sie sich in die Schichten Serviceschicht, ECU-Abstraktionssicht, Microcontrollerabstraktionsschicht und Complex Device Drivers [Bunzel 2011, S. 79]. Die Abbildung veranschaulicht diese Schichten und deren Aufteilung. Zudem wird auch die Hardwareabhängigkeit dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5: Softwarearchitektur im Detail
Quelle: [EXP_Layered 2017, S.11]
Die Mikrocontrollerabstraktionsschicht liegt, wie die Abbildung 5 zeigt, direkt über der Hardware und hat das Ziel die darüber liegenden Softwareschichten von dem Mikrocontroller zu lösen [Meroth+2008, S.293]. Dazu bietet sie interne Treiber an, womit Softwaremodule direkt auf den Mikrocontroller und den internen Peripherien zugreifen können. Somit ist diese Schicht mikrocontrollerspezifisch und muss beim Austausch des Controllers auch ausgewechselt werden ([Kindel+2009, S. 122], [EXP_Layered 2017, S.13]).
Diese Schicht hat die Aufgabe, die oberen Schichten unabhängig von dem ECU-Hardware-Layout zu machen [Seifert+ 2008, 117]. Dazu abstrahiert die Schicht die steuergerätspezifischen Eigenschaften und bietet Interfacemodule für die Treiber vom Microcontroller Abstraction Layer sowie externer Geräte an [Kindel+2009, S. 122]. Hiermit gewährt diese Schicht den Zugang zu Peripheriegeräten, ungeachtet von deren genauen Ort (intern/extern) und Verbindung zum Mikrocontroller [EXP_Layered 2017, S.14].
Die Service Schicht ist die oberste Schicht der Basissoftware und kommt damit direkt nach der RTE.
Diese Schicht bietet diese grundlegenden Dienste an [EXP_Layered 2017, S.16]:
- Kommunikationsdienste
- Diagnoseprotokolle
- Speicherdienste
- Management der ECU-Betriebsmodi
- AUTOSAR-Betriebssystem
Zudem sind diese Dienste, bis auf das Betriebssystem, hardwareunabhängig. [Kindel+2009, S. 121]. Das AUTOSAR-Betriebssystem bildet ein eigenständiges Modul, das auf dem OSEK/VDX-Betriebssystem basiert [Erlenbach 2009, S.20]. Dieses Betriebssystem ist ein ereignisgesteuertes Echtzeitbetriebssystem mit Multitasking, womit Task-Synchronisation und Ressourcenverwaltung realisiert werden [Streichert+2012, S.53].
Die Complex Device Drivers-Schicht ist für den RTE wie eine Brücke zum Microcontroller (vgl. 5). Dadurch werden die anderen Schichten und deren Abstraktionen ignoriert. Deshalb ist es empfohlen, diese Schicht so wenig wie möglich zu nutzen und die Software nach dem vorgesehenen Schichtmodell zu entwerfen [Kindel+2009, S.123]. Die Schicht soll lediglich als Lösung für zeitkritische Anwendungen, z. B. Airbag-Zündung [Wallentowitz+2011, S.195], Migration existierender Software oder bei nicht AUTOSAR konformer Hardware verwendet werden [EXP_Layered 2017, S.15].
Die Methodik beschreibt die Entwicklungsschritte für AUTOSAR kompatible Softwareprojekte [Bunzel 2011, S80], um die Wiederverwendbarkeit zu unterstützen [Seifert+2008, S.114]. Dabei beruht die Methodik auf einer Beschreibung des Arbeitsproduktflusses, indem die Abhängigkeiten von Aktivitäten, wie z. B. die Umwandlung der Systemschicht in einzelne ECU-Schichten, dargelegt werden. Die Methodik besteht aus den drei Schichten [Kindel+2009, S.75]:
- System
- Steuergerät (ECU)
- Komponenten (Component)
Abbildung in dieser Leseprobe nicht enthalten
Abb. 6: Methodik von AUTOSAR CLASSIC
Quelle: [MethodikG 2008, S.1]
Die Abbildung 6 veranschaulicht so eine Methodik, wobei die Chevron-Pfeile die Aktivitäten, die von Menschen durchgeführt werden, darstellen. Außerdem geben die gestrichelten Linien die Abhängigkeit der Templates am Pfeilende vom Format der Datei an der Pfeilspitze an.
Der erste Schritt der Konfiguration ist die Systemkonfiguration. Die primäre Aufgabe dieser Konfiguration ist die Verteilung der Softwarekomponenten auf die Steuergeräte [Kindel+2009, S.81]. Dazu muss zunächst eine System Configuration Input -Datei definiert werden, welches durch AUTOSAR Templates unterstützt wird. Es enthält Informationen über die geplanten Soft- und Hardwarekomponenten sowie Systemeinschränkungen die zur Realisierung der Funktionen notwendig sind [Methodik 2011, S.11].
Im Anschluss wird beim Schritt Configure System entschieden, welche Softwarekomponenten eingesetzt werden. Daraufhin wird mit Hilfe eines Tools die System Configuration Description -Datei erstellt, indem alle Systeminformationen, wie Bus-Mapping,Topologie sowie die ausgewählten Softwarekomponenten gespeichert sind [Kindel+2009, S.81]. Daraufhin werden im Schritt ECU-Specific Information alle Informationen, die für die ECU nötig sind, extrahiert [Methodik 2011 S.11].
Im ersten Schritt der ECU-Konfiguration werden die benötigten Informationen aus der Extract ECU-Specific Information gewonnen und die ECU Extract of System Configuration erstellt. Daraufhin konfiguriert die ECU mittels dieser Daten die Basissoftware, die RTE und das Betriebssystem [Kindel+2009, S.82]. Anschließend wird diese Konfigurationseinstellung in der ECU Configuration Description -Datei vermerkt [Methodik 2011, S.12].
Die eigentliche Anwendungsentwicklung findet weitgehend von der ECU unabhängig in der Komponentenschicht statt. Nach der Entwicklung wird die Implementierung der ECU-Schicht bereitgestellt [ebenda]. Letztlich kann die ECU-Schicht aus dem Zusammenschluss der Informationen und den Softwarekomponenten beim Schritt Generate Executable die Executable jeder ECU generieren [Kindel+2009, S.82].
Zudem sind die Anwendungsschnittstellen zwischen der RTE und den Anwendungen standardisiert. Dazu sind alle Schnittstellen hinsichtlich der verwendeten Datentypen, Einheiten und Skalierungsfaktoren vom AUTOSAR-Konsortium klar definiert. Zudem wird dadurch die Wiederverwendbarkeit der Softwarekomponenten gewährleistet [Fürst+ 2016, S.940].
Mit der Weiterentwicklung der Technologien steigen auch die Anforderungen. Damit die neuen Anforderungen, wie die des autonomen Fahrens, beantwortet werden können, wurde Adaptive AUTOSAR entwickelt [Fürst+ 2016, S.940].
Adaptive AUTOSAR ist für ECUs mit einer hohen Performance entwickelt, womit fehlertolerante Systeme realisiert werden können [TR_Fdt 2017, S. 4]. Entwicklung von Adaptive AUTOSAR wurde hauptsächlich von den Trends der Automobilindustrie vorangetrieben. Zu den aktuellen Trends zählen ([Fürst+ 2016, S.942], [Albrecht 2017, S.3]):
- Automatisiertes Fahren
- Infotainment
- Connectivity
- Dynamische Software Plattform
Es ist erkenntlich, dass bei den genannten Trends große Datenmengen verarbeitet werden müssen. Für die Bewerkstelligung dieser rechenintensiven Aufgaben, z. B. für das automatisierte Fahren, bietet der objektorientierte Ansatz von Adaptive AUTOSAR eine optimale Grundlage [Vector 2018, S. 1]. Mit Adaptive AUTOSAR lässt sich „das Smartphone auf Rädern“ realisieren [Wille+ 2016, S. 4].
Die neue Softwarearchitektur weist neue Eigenschaften auf, die im Folgenden erklärt werden.
Im Gegensatz zum Classic AUTOSAR, indem die Programmiersprache C lautet, kommt beim Adaptive AUTOSAR die objektorientierte Programmiersprache C++14 zum Einsatz. Jedoch existiert für diese Version von C++ kein Programmierstandard, der für sicherheitskritische Systeme beschrieben ist. Deshalb erarbeitete das AUTOSAR-Konsortium eine Erweiterung, um diese Lücke abzudecken. Diese Erweiterung ergänzt den MISRA C++:2008-Standard, der lediglich C++03 abdeckt [CPP14 2017, S.8]. Somit können alle Anwendungen, unter Berücksichtigung der definierten Richtlinien, mit C++14 entwickelt werden. Der Grund für die Verwendung von C++ ist mit der seiner hohen Bedeutung für leistungskritische und komplexe Anwendungen in der Softwareindustrie bzw. Wissenschaft begründet ([Sham 2008, S. xiii], [EXP_Platform 2017, S. 8]). Dadurch soll eine schnelle Anpassung neuen Algorithmen sowie Verbesserung der Anwendungsentwicklung ermöglicht werden [EXP_Platform 2017, S. 8].
Traditionell ist die Kommunikation im Automobil eine signalbasierte Kommunikation, die für Daten von begrenzter Größe ausgelegt ist. Jedoch erfordern neue Anwendungsfälle, wie z. B. automatisiertes Fahren mit höheren Nutzlastanforderungen, andere Protokolle [Slansky+ 2017, S.22]. Deshalb setzt Adaptive AUTOSAR auf eine serviceorientierte Architektur (SOA), um die Flexibilität [Schweiker 2016, S. 378] und Skalierbarkeit der komplexen Anwendungen bei der Verarbeitung von Verteilten- und Rechenressourcen zu ermöglichen. Das Konzept der SOA basiert auf ein System, dass aus einer Reihe an Diensten besteht. Diese Dienste sind abstrakte Softwareelemente [Heutschi 2007, S.22] und werden wiederum von anderen Diensten oder Anwendungen genutzt. Dabei ist es gleich, ob ein Dienst beispielsweise auf einem lokalen ECU oder auf einem entfernten ECU angeboten wird [EXP_Platform 2017, S. 8f]. Zudem wir durch die Wiederverwendung der Dienste Aktualisierungen und Modifikation unterstützt [Massoud 2017, S.5]. Vergleichbar ist das System mit einem Verteilten System, welches einen eigenen Nachrichtenaustausch besitzt. Solch eine Architektur, die auf Nachrichtenübertragung basiert, kann auch vom Fortschritt der verwendeten Technologien profitieren. Somit kann beispielsweise durch die Weiterentwicklung von Ethernet auch eine größere Bandbreite erzielt werden [EXP_Platform 2017, S. 8f].
Die SOA besitzt die Eigenschaft der Parallelität, da unterschiedliche Anwendungen verschiedene Dienste verwenden können. Um diese Parallelität zu erreichen, werden Vielkernprozessoren, sowie heterogene Computersysteme eingesetzt [EXP_Platform 2017, S. 9]. Zudem sind entsprechende Richtlinien definiert, die unter [EXP_Parallel 2017] zu finden ist.
Eines der Ziele von AUTOSAR ist die Wiederverwendbarkeit, um eine schnellere Entwicklung zu ermöglichen. Dies gilt auch für den adaptiven AUTOSAR-Standard. So werden keine bereits entwickelten offenen Standards ersetzt. Somit werden bsp. keine neuen Schnittstellen eingeführt, wenn die existierenden komplizierter sind [EXP_Platform 2017 S. 9].
Die adaptiven Anwendungen werden inkrementell realisiert [Albrecht 2017, S.6]. Das heißt, dass das Gesamtsystem geplant, aber in Teilen entwickelt werden kann. Die inkrementelle Entwicklung hat auch den Vorteil der explanativen Entwicklungsphasen, welches die frühzeitige Lieferung des Basissystems gewährleistet. Zudem können die Anforderungen während der Entwicklung überarbeitet werden [Dröschel+200, S.124]. Dadurch soll eine dynamische Verwaltung der Ressourcen bzw. Kommunikation und kurze Interaktionszyklen ermöglicht sowie der Aufwand für die Softwareentwicklung bzw. –Integration verringert werden. Zudem bietet die Adaptive Platform dem Systemintegrator an Sicherheitsqualifizierungen durchzuführen, indem das dynamische Verhalten entsprechend begrenzt wird. Demzufolge können unerwünschte oder negative Effekte reduziert werden [EXP_Platform 2017, S. 10].
Die Begrenzung für das dynamische Verhalten einer Anwendung wird im Application Manifest geregelt. Auf das Manifest wird im Kapitel 4.6 gesondert eingegangen. Zu beachten ist, dass eine dynamische Zuordnung von Ressourcen und Kommunikationswegen nur innerhalb definierter Bereiche möglich ist. Im Rahmen einer Implementierung können geplante Dynamiken aus der Softwarekonfiguration entfernt werden. Beispiele für solche geplanten Dynamiken sind [ebenda]:
- Vorgeben des Service Discovery-Prozesses
- Beschränkung der dynamischen Speicherzuweisung nur auf die Startphase
- Korrektur der Zuordnung von Prozesse zu CPU-Kernen
- Fair-Share-Scheduling statt prioritätsbasierendem Scheduling
- Zugriff auf bereits vorhandene Dateien im System
Die Adaptive Platform strebt die Anpassung an verschiedenen Entwicklungsprozessen, besonders der agilen Entwicklung, an. Damit dieses Ziel realisiert werden kann, ist es obligatorisch die Systemarchitektur schrittweise skalierbar und aktualisierbar zu gestalten. Daher werden die Adaptive AUTOSAR-Spezifikation und deren Anwendungen mit Scrum entwickelt, um den Prozess der Agilität zu gewährleisten [EXP_Platform 2017, S. 10].
[...]
Der GRIN Verlag hat sich seit 1998 auf die Veröffentlichung akademischer eBooks und Bücher spezialisiert. Der GRIN Verlag steht damit als erstes Unternehmen für User Generated Quality Content. Die Verlagsseiten GRIN.com, Hausarbeiten.de und Diplomarbeiten24 bieten für Hochschullehrer, Absolventen und Studenten die ideale Plattform, wissenschaftliche Texte wie Hausarbeiten, Referate, Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Dissertationen und wissenschaftliche Aufsätze einem breiten Publikum zu präsentieren.
Kostenfreie Veröffentlichung: Hausarbeit, Bachelorarbeit, Diplomarbeit, Dissertation, Masterarbeit, Interpretation oder Referat jetzt veröffentlichen!
Kommentare