docDie Software-Architektur von AUTOSAR
download 
Denúncia Transcrição
Die Software-Architektur von AUTOSAR
Seminar Sommersemester 2012: Automobile Systeme in der Automatisierung Prof. Dr. Dieter Zöbel, Universität Koblenz-Landau, FB Informatik Die Software-Architektur von AUTOSAR Oliver Busch Eingereicht: 27.06.2012 / Fertiggestellt: 04.09.2012 Zusammenfassung Die Automobilindustrie hat 2003 die Entwicklungspartnerschaft AUTOSAR (AUTomotive Open System ARchitecture) gegründet. Sie beabsichtigte den explodierenden Kosten, sowie der wachsenden Komplexität und Vielfältigkeit der verwendeten Herstellungstools für die Erzeugung von Steuergeräte-Software entgegenzuwirken. Ziel dieses Konsortiums war die Bereitstellung einer einheitlichen Software-Architektur zur Kostenreduzierung, Qualitätsverbesserung und Wiederverwendbarkeit von bereits entwickelten Komponenten. Dieses Papier zeigt die Gründe für die Einführung einer neuen Softwarearchitektur auf. Anschließend werden die Bestandteile von AUTOSAR erklärt. Weiterhin wird versucht, den Aufwand für eine Umstellung auf die neue Softwarearchitektur abzuwägen. Schlüsselwörter AUTOSAR, Software-Architektur, Methodik 1 Einleitung 1.1 Das AUTOSAR-Konsortium Das AUTOSAR-Konsortium ist eine Entwicklungspartnerschaft bestehend aus Automobilhersteller, Zulieferer, Werkzeug- und Halbleiterhersteller, sowie Softwarehersteller. Das Konsortium ist in verschiedene Bereiche unterteilt: [1] 1. Core Members: Besteht zurzeit aus neun Mitgliedern. Es setzt sich zusammen aus Automobilherstellern und Zulieferern (Tier1-Supplier). Sie arbeiten aktiv in den verschiedenen Bereichen des Konsortiums mit. 2. Premium Members: Die Zahl der Premium-Members variiert. Zurzeit sind es 50 Mitglieder. Es handelt sich hauptsächlich um Zulieferer (Tier1-Supplier), Automobilhersteller und Werkzeughersteller. Auch die Premium-Mitglieder arbeiten aktiv im Projekt mit. 3. Development Members: Zurzeit gehören diesem Bereich 12 Firmen an, die über Know-How verfügen, das für AUTOSAR relevant ist. Universität Koblenz-Landau, Institut für Informatik [email protected] http://www.uni-koblenz-landau.de/koblenz/fb4/institute/IST/AGZoebel 2 O. Busch 4. Associate Members: 84 Firmen gehören dieser Gruppe an. Hierbei handelt es sich meistens um sonstige Zulieferer oder andere Unternehmen, die den AUTOSARStandard kommerziell nutzen wollen. Sie sind nicht aktiv an der Entwicklung beteiligt, sondern erwerben durch eine jährliche Gebühr die Nutzungsrechte an AUTOSAR. 1.2 Motivation für die Entwicklung der Softwarearchitektur AUTOSAR Die Herausforderungen in der Entwicklung der Steuergeräte (ECU)-Software sind in jüngster Zeit stetig gewachsen. Immer mehr Funktionalitäten für tief eingebettete Automotivsysteme wie z.B. Tür-, Heck-, Licht-, Motor- und Sonnendachsteuergeräte werden benötigt. Diese Steuergeräte bilden ein stark verteiltes und vernetztes System, auf dem die gewünschte Funktionalität installiert ist. Die Entwicklung der Steuergerätesoftware erfolgte bislang steuergerätezentriert und nicht funktionsbasiert. Das bedeutet, dass z.B. eine Warnblinkersteuerung zu einem Warnblinkersteuergerät führt. Da die geforderten Funktionalitäten aber extrem anwachsen, führt diese Vorgehensweise zu einem unüberschaubaren System aus Steuergeräten, die zum Teil gleiche Aufgaben erledigen. Beispielsweise wird die Blinkeranlage im Auto von verschiedenen Funktionen wie z.B. Fernbedienung für die Zentralverriegelung, Warnblinktaster, usw. angesteuert. Für jede dieser Funktionen ein eigenes Steuergerät bereitzustellen ist unsinnig. Das führt zu komplexer Software mit hohem Fehlerpotential. Dazu kommt eine große Vielfalt an verschiedenen Hardwarekomponenten der ECUs, mit unterschiedlichen Prozessoren, Rechenleistung und Speicher. Jeder OEM fordert zudem für die von ihm beim Tier1-Supplier bestellten ECUs die Verwendung seines eigenen Betriebssystems (Basissoftware). Das alles führt dazu, dass Anforderungsänderungen aufwändig und teuer sind. Abbildung 1 zeigt auf der linken Seite die Arbeitsweise vor dem Einsatz von AUTOSAR. Abb. 1 Kosten der ECU-Entwicklung [4]. Die Software-Architektur von AUTOSAR 3 Ein anderes großes Problem in der Herstellung der Steuergeräte-Software ist die starke Vermischung von funktionalem Code (Anwendungslogik, Algorithmen) mit technischem (hardwarespezifischem) Code, siehe Abbildung 2. Das macht die Wiederverwendung von bereits erstellter Anwendungslogik schwierig, zeitaufwändig und damit teuer. Abb. 2 Klassische Steuergeräteentwicklung vs. Entwicklung mit AUTOSAR [5], p.41. 1.3 Ziele von AUTOSAR Der Automobilmarkt ist ein Massenmarkt mit großem Konkurrenzdruck. Folglich ist die oberste Maxime Kostenreduzierung. Mit AUTOSAR wird eine strikte Trennung von funktionalem und technischem Code erreicht. AUTOSAR schreibt die Verwendung der Basissoftware und deren Module für die Steuergeräte exakt vor. Dadurch soll dem AUTOSAR-Leitspruch ’Cooperate on standards, compete on implementation.’ [2] Rechnung getragen werden. Das bedeutet, der technische Anteil der Steuergerätesoftware gehört zum Standard und ist von AUTOSAR genau vorgegeben, während die Anwendungslogik oder der funktionale Code zum ’Implementierungs’Bereich zählt, indem Wettbewerb zwischen den verschiedenen Herstellern ausdrücklich erwünscht ist. Weitere Ziele von AUTOSAR sind die leichte Austauschbarkeit von Modulen und die Wiederverwendung von Softwarekomponenten des funktionalen Codes. Diese Ziele sollen zu einer Vereinfachung der Arbeitsprozesse bei allen beteiligten Firmen führen, was sich dann in einer Kostenreduzierung widerspiegeln soll. Durch die strikte Trennung von technischem und funktionalem Code kann es auch zur Reduktion von Hardwarekosten kommen, wie nachfolgendes Beispiel zeigt. Durch den Einsatz von AUTOSAR wird unnötiger Code, wie er durch die Vermischung von funktionalem und technischem Code schnell entstehen kann, vermieden, was wiederum zum Einsatz eines Steuergerätes mit dem nächst kleineren Speicher führt. Der Zulieferer spart dadurch pro verwendetes Steuergerät ca. 10 Cent. VW hat 2007 ca. 6 Millionen Autos verkauft. Pro Auto wurden ca. 50 ECU verbaut. Damit belaufen sich die Kosten für die Einsparungen 4 O. Busch auf 30 Millionen EURO [3]. Ob alle Ziele auch tatsächlich umgesetzt werden können, wird die Praxis zeigen. 1.4 Vorteile von AUTOSAR Mit AUTOSAR wird eine standardisierte Softwarearchitektur eingeführt, die als Schichtenmodell eine klare Hardwareunabhängigkeit garantiert. Das ermöglicht die Wiederverwendung von Anwendungslogik immens und erleichtert die Umsetzung von Anforderungsänderungen. Die Modularität verbessert die Qualität der Software, da einzelne Modultests möglich sind. Die lose Kopplung der Module ermöglicht den Einsatz dieser in verschiedenen Softwareprojekten ohne großen Aufwand. Wird ein Modul mit einem bestimmten Algorithmus schon längere Zeit in einem Softwareprojekt fehlerfrei eingesetzt, so kann dieses mit geringem Aufwand in einem weiteren Softwareprojekt verwendet werden. Die fehlerfreie Laufzeit des Moduls in dem bisherigen Projekt stellt dabei eine starke Qualitätsaussage dar. Weiterhin wird über AUTOSAR die funktions- oder architekturbasierte Sicht verwendet. Zuerst werden alle zu realisierenden Funktionen gesammelt und entwickelt. Erst danach erfolgt eine Zuordnung der Anwendungslogik auf die verschiedenen ECUs. Damit wird eine Explosion an zu verwendenden Steuergeräten verhindert. AUTOSAR verwendet genau eine Basissoftware, deren Module exakt beschrieben sind. Das hat mehrere Vorteile: – Die Austauschbarkeit von Modulen ist relativ einfach möglich. – Zulieferer, die mehrere verschiedene OEMs bedienen, müssen nicht mehr für jeden OEM eigene Basissoftware und Entwicklungswerkzeuge vorhalten. – Bereits entwickelte Anwendungslogik lässt sich leicht wiederverwenden. – Die Systemintegration auf Seiten des OEM wird vereinfacht. – Durch die späte Zuordnung der Software auf die ECU ist eine hohe Designflexibilität gegeben. Für die Zulieferer ergibt sich als weiterer Vorteil die Möglichkeit, neue Geschäftsmodelle zu etablieren. Kindel et al. beschreiben in [5], dass Zulieferer fertige Bibliotheken an Softwarekomponenten mit reinem funktionalem Code anbieten können, oder kombinierte Hardware/Software-Produkte im Bereich der Sensorik/Aktorik entwickeln und verkaufen. Auch die verteilte Entwicklung mit Offshore-Kräften ist denkbar, da der AUTOSAR-Standard eine klar definierte Arbeitsteilung ermöglicht. 1.5 AUTOSAR und andere Standards des Automotive-Bereiches Alle Fahrzeughersteller sind in allen großen Standards, die für den AutomotiveBereich bestehen, vertreten. In Kooperationsverträgen haben die Fahrzeughersteller geregelt, dass sich verschiedene Standards gegenseitig nicht Konkurrenz machen dürfen. Darüber hinaus sind die Fahrzeughersteller nur an Standards interessiert, die sie als Global Player auch weltweit unverändert einsetzen können. Kommt es doch mal zu Überschneidungen, wenn ein neuer Standard etabliert wird, dann werden bestehende Überschneidungen beseitigt. Am Beispiel der Standards HIS und JasPar haben das Kindel et. al [5] verdeutlicht. Die Software-Architektur von AUTOSAR 5 1.5.1 HIS (Hersteller Initiative Software) HIS wurde von den deutschen Automobilherstellern ins Leben gerufen und hat sich zum Ziel gesetzt, die Qualität mikroprozessorbasierter Steuergeräte zu verbessern. Der Fokus von HIS liegt auf der eigentlichen Software-Entwicklung und SoftwareTest, nicht auf der Bereitstellung einer Software-Architektur. Trotzdem kam es zu Überschneidungen im Teilbereich ’Standard-Software’. HIS hat mit Erscheinen von AUTOSAR die Arbeiten in diesem Bereich eingestellt und diesen in eine Schnittstelle zur AUTOSAR-Entwicklung umgewandelt: ”Der Arbeitskreis Standardsoftware ist zur Zeit inaktiv. Er hat einen aktiven Unterarbeitskreis: AUTOSAR User Group. Die Resultate des Arbeitskreises (Beschlüsse und Dokumente) können hier gefunden werden...” [6]. 1.5.2 JasPar (Japan Automotive Software Platform and Architecture) JasPar wurde von den japanischen Automobilherstellern etabliert, mit dem Ziel eine Standard-Software für die Entwicklung im Automotive-Bereich bereitzustellen. JasPar konzentriert sich dabei allerdings nur auf das Bussystem FlexRay. Mit dem Aufkommen des AUTOSAR-Standards hat sich JasPar darauf spezialisiert den AUTOSARStandard zu nutzen und für FlexRay-Bussysteme zu erweitern. JasPar unterstützt die Arbeit am AUTOSAR-Standard mit einer eigenen Arbeitsgruppe [7]. 2 Der AUTOSAR-Standard AUTOSAR lässt sich in drei Bereiche aufteilen, siehe Abbildung 3 Abb. 3 AUTOSAR-Bereiche. – Methodik: Die AUTOAR-Methodik beschreibt die Herstellung von SteuergeräteSoftware aus Sicht des Produktes, das erzeugt werden soll. In der Methodik werden keine Arbeits- oder Geschäftsprozesse beschrieben; es fehlen sämtliche Rollen und Verantwortlichkeiten. Die Methodik erlaubt eine teilweise Parallelisierung der Herstellung von Steuergerätesoftware dadurch, dass sie drei verschiedene Sichten auf Teilaspekte des Herstellungsprozesses hat. Die Sichten fokussieren auf die Architektur, Kommunikation und Codegenerierung, sowie übergeordnet die Integration der entwickelten Komponenten. – Architektur: Ein Schichtenmodell zur Abstraktion der Software von der zugrunde liegenden Hardware. Dabei unterscheidet man grob drei Schichten: 6 O. Busch 1. Die Applikationsschicht, in der der funktionale Code in Softwarekomponenten realisiert wird. 2. Die Run-Time-Environment-Schicht (RTE), die die Kommunikation zwischen den Softwarekomponenten realisiert. 3. Die Basis-Software-Schicht (BSW), die die Module und Interfaces zur darunterliegenden Hardware bereitstellt. – Interfaces: Hierbei handelt es sich um eine vollständige Beschreibung aller technischen Schnittstellen, die zur Herstellung von Steuergeräte-Software auf unterschiedlicher Hardware nötig ist. 2.1 Die AUTOSAR-Methodik Die AUTOAR-Methodik beschreibt den Herstellungsprozess von Steuergeräte-Software aus drei Sichten, siehe Abbildung 4 Abb. 4 AUTOSAR-Methodik. [8] In Abbildung 4 bedeuten: – Gelb: Aktivitäten die von Menschen durchgeführt werden. – Gestrichelte Linien geben Abhängigkeiten an: Das Template am Pfeilende ist abhängig von dem ausgewählten Format der Datei an der Pfeilspitze. Die Software-Architektur von AUTOSAR 7 Bevor die AUTOSAR-Methodik greift oder gestartet werden kann, muss im allgemeinen Entwicklungsprozess die Anforderungsanalyse bereits abgeschlossen sein. Es steht also fest, welche Funktionalitäten (wie z.B. elektrische Sitzverstellung Fahrer, Dachbedieneinheit, reversibler Gurtstraffer usw.) der Fahrzeughersteller für die geplante Fahrzeugtyp-Serie implementieren will. Während des Prozesses werden zwischendrin verschiedene Werkzeuge zur Erstellung der benötigten Dateien verwendet. Die Werkzeuge sind austauschbar, da AUTOSAR die .XML-Formate für die Dateien fest definiert hat. 2.1.1 Die Systemsicht In der Systemsicht hat der Automobilhersteller die Gesamtsicht auf den Fahrzeugtyp und sämtliche für dieses Fahrzeug zu erstellende Funktionen. Nun wird im ersten Schritt die ’System Configuration Input’-Datei erzeugt. Das ist ein vorgegebenes AUTOSARTemplate, indem die geplanten Soft- und Hardware-Komponenten zur Realisierung der Funktionen erfasst werden. Im Schritt ’Configure System’ wird entschieden welche Softwarekomponenten zum Einsatz kommen. Die grundsätzliche Funktionalität der Softwarekomponenten wird auf einem Virtual Functional Bus (VFB) weitestgehend hardwareunabhängig getestet (siehe entsprechender Abschnitt). Die Entwicklung der Softwarekomponenten kann der OEM selbst durchführen oder an andere vergeben. Erst nach erfolgreichem Abschluss dieses Schrittes wird entschieden, auf welchen Steuergeräten (ECU) die Softwarekomponenten laufen sollen. Mit dieser Entscheidung wird auch das benötigte Kommunikationsnetz zwischen den verschiedenen ECUs, den darauf laufenden Softwarekomponenten und den benötigten Aktoren und Sensoren definiert. Das Ergebnis dieser Arbeit wird in der Datei ’System Configuration Description’ gespeichert. Aus dieser Datei extrahiert der Automobilhersteller im Schritt ’Extract ECU specific Information’ für jede ECU einzeln die ’ECU Extract of System Configuration’-Datei und gibt diese an die Zulieferer, die diese dann in der ECU-Sicht herstellen können. Virtueller Funktioneller Bus (VFB) und Softwarekomponenten Der VFB dient dazu die Kommunikationsbeziehungen zwischen verschiedenen Softwarekomponenten weitgehend hardwareunabhängig darzustellen. Softwarekomponenten dienen als Modellierungswerkzeug zur Strukturierung und Anordnung des funktionalen Codes. Der eigentliche Code wird in sogenannten ’Runnables’ innerhalb der Softwarekomponente gekapselt. Man unterscheidet verschiedene Softwarekomponenten, wobei die Softwarekomponenten für Aktoren und Sensoren noch besonders zu erwähnen sind. Diese sind als einzige nicht hardwareunabhängig, da diese an Aktoren und Sensoren bestimmter Hersteller und den dazu passenden Steuergeräten gebunden sind. Detailliertere Informationen zu Softwarekomponenten findet man unter [5], Kapitel 6. Der Informationsaustausch zwischen Softwarekomponenten erfolgt über sogenannte Ports. Man unterscheidet drei verschiedene Port-Typen, wobei eine Kommunikationsstrecke auf Sende und Empfangsseite immer vom selben Port-Typ sein muss: 1. Sender/Receiver - Senden/Empfangen von Daten. 2. Client/Server - Aufrufen/Bereitstellen von Operationen. 3. Calibration - Bereitstellen und Nutzen statischer Kalibrierungswerte. An dem nachfolgenden Beispiel ’Ansteuerung der Blinkeranlage’ von Robert Warschofsky [9], Abbildung 5 soll die Vorgehensweise verdeutlicht werden. Sie zeigt 8 O. Busch eine mögliche Implementierung einer Anlage zum Ansteuern der Blinker. Die Anlage ist in fünf verschiedene Softwarekomponenten aufgeteilt. Auf der rechten Seite stehen stellvertretend für alle Blinklichter am Auto jeweils nur der vordere linke und vordere rechte Blinker. Abb. 5 Ansteuerung der Blinkeranlage. [9] – DirectionIndicatorSwitch: Sensor-Softwarekomponente, die den Status des Blinkerhebels an die Softwarekomponente ’DirectionIndicationManager’ über ein Client/Server-Port weiterleitet. – WarnLightSwitch: Sensor-Softwarekomponente, die den Status des Warnblinktasters an die Softwarekomponente ’DirectionIndicationManager’ über ein Sender/Receiver-Port weiterleitet. – DirectionIndicationManager: Softwarekomponente, die die Sensorwerte der oben beschriebenen Softwarekomponenten entgegennimmt, diese auswertet und über die Aktor-Sensorkomponenten ’DFrontLeft:DirectionIndicator’ und ’DFrontRight:DirectionIndicator’ den linken und den rechten Frontblinker entsprechend setzt. – DFrontLeft:DirectionIndicator: Aktor-Softwarekomponente, die das linke Blinklicht ein- oder ausschaltet. – DFrontRight:DirectionIndicator: Aktor-Softwarekomponente, die das rechte Blinklicht ein- oder ausschaltet. – nv: AUTOSAR-Service. Stellt Schnittstelle zur Basis-Software der ECU zur Verfügung. Für das Beispiel ohne Bedeutung. Eine Zuordnung der Softwarekomponenten zu ECUs ist noch nicht erfolgt. 2.1.2 Die Komponentensicht Die Kommunikationsbeziehungen zwischen den Softwarekomponenten wurden in der Systemsicht auf dem VFB realisiert. Mit der Zuordnung der Softwarekomponenten zu den ECU wird in dieser Sicht die tatsächliche Kommunikation zwischen den Softwarekomponenten auf den ECU realisiert. Man unterscheidet hierbei Intra- und Interkommunikation zwischen den Softwarekomponenten, je nachdem ob die kommunizierenden Softwarekomponenten auf ein und derselben ECU, oder auf verschiede- Die Software-Architektur von AUTOSAR 9 nen ECUs untergebracht sind. Zur Erstellung der RTE kommen Werkzeuge zum Einsatz, die die tatsächlich benötigten Kommunikationsbeziehungen in Object-Code erstellen. Das können einzelne Werkzeugtools oder ein ganzer Satz an Tools sein, je nach dem von welchem Hersteller die Tools angeboten werden. Die Qualität und Effizienz des erzeugten Codes ist abhängig davon, ob bei der Generierung Randbedingungen wie verwendetes Speichermodell oder Zuordnung der Runnables zu bestimmten Tasks berücksichtigt werden. Dieser Code wird an die ECU-Schicht gegeben, in der dieser dann mit dem Komponenten-Code verlinkt wird. Am Beispiel ’Ansteuerung der Blinkeranlage’ aus dem Abschnitt ’System Sicht’ wird zunächst der Code in den Runnables realisiert. In Abbildung 6 ist beispielhaft für den Warnblinkschalter die Softwarekomponente ’WarnLightSwitch’ und die Softwarekomponente ’DirectionIndicationManager’ um Runnables erweitert worden. Das Sender/Receiver-Interface zwischen den beiden Softwarekomponenten hat den Namen ’WLSInterface’. Über dieses Interface wird das Daten-Element ’SwitchVal’ (8 Bit breiter Integer) gesendet. Die acht Bit ermöglichen nicht nur das Übertragen des Status des Warnblinkschalters an oder aus, sondern auch beliebige Fehlercodes für unbestimmte Zustände des Schalters. Abb. 6 Ansteuerung der Blinkeranlage. [9] Nachfolgend ist der mögliche C-Code der beiden Runnables abgebildet. Der Code ist angelehnt an das Beispiel von [5], Kapitel 7.8.1. Der SensorRunnableCode ermittelt den Status des Schalters (an, aus, undefiniert, Fehlercode). Die Methode ’Rte Write Status SwitchVal’ sendet den aktuellen Status. Hier ist deutlich zu sehen, dass kein Empfänger für den Statuswert angegeben ist. Die RTE sorgt dafür das der richtige Empfänger die Nachricht erhält. Mit der Generierung der RTE werden die notwendigen Kommunikationsbeziehungen zur Übertragung dieser Daten hergestellt. Im TasterRunnable-Code, der in der Softwarekom- 10 O. Busch ponente ’DirectionIndicationManager’ implementiert ist, empfängt die Methode ’Rte ReadWarningLightSwitch SwitchVal’ den aktuellen Status-Wert des WarnblinkSchalters. Zur Unterscheidung merhfach instanziierter Objekte wird in der Methode der self-Parameter mitgeführt. void SensorRunnable (const Rte_WarnLightSwitch* self) { /*individuelle Implementierung beginnt hier */ UInt8 SwitchVal; /*Taster-Wert ermitteln*/ /*Taster-Wert versenden*/ Rte_Write_Status_SwitchVal (self, SwitchVal); /*individuelle Implementierung endet hier*/ } void TasterRunnable (const Rte_DirectionIndicationManager* self) { /*individuelle Implementierung beginnt hier */ UInt8 SwitchVal; Rte_Read_WarningLightSwitch_SwitchVal (self, &SwitchVal); /*Taster-Wert verarbeiten*/ /*individuelle Implementierung endet hier*/ } Ein Ausschnitt über die mögliche Verteilung der Softwarekomponenten aus dem Beispiel ”Ansteuerung einer Blinkeranlage” ist in Abbildung 7 dargestellt. Hier sind die Softwarekomponenten ’DirectionIndicationManager’ und ’DirectionIndicatorSwitch’ der ECU1 zugeordnet, während die Softwarekomponente ’DFrontRight:DirectionIndicator’ auf der ECU3 läuft. Das Werkzeug zur Erzeugung der RTE erstellt eine Intra-Kommunikationsbeziehung zwischen den Softwarekomponenten ’DirectionIndicationManager’ und ’DirectionIndicatorSwitch’, da diese auf derselben ECU laufen. Die Kommunikationsbeziehung zwischen ’DirectionIndicationManager’ und ’DFrontRight:DirectionIndicator’ ist eine Inter-Kommunikationsbeziehung. Sie wird über die IO-Ports der ECU1 auf den Fahrzeug-Bus (z.B.: CAN-Bus) geführt und dann über die IO-Ports der ECU3 nach oben in die Applikationsebene, in der die Softwarekomponente ’DFrontRight:DirectionIndicator’ läuft. Die Software-Architektur von AUTOSAR 11 Abb. 7 Verteilung der SW-C auf ECUs. [9] 2.1.3 Die ECU Sicht Diese Sicht ist auf die Erstellung der Steuergerätesoftware bezogen auf die tatsächlich verwendete Steuergeräte-Hardware ausgerichtet. Ausgehend von der ’ECU Extract of System Configuration’-Datei wird zuerst die Basis-Software, das Betriebssystem und die RTE für die ECU konfiguriert und in der ’ECU Configuration Description’-XMLDatei dokumentiert. Anschließend wird aus diesem Ergebnis mit den Softwarekomponenten via Linker und Compiler ein ausführbares Programm erzeugt. 12 O. Busch 2.2 Die AUTOSAR-Architektur Die AUTOAR-Architektur ist ein Schichtenmodell, in dem mit jeder Schicht weiter von der zugrunde liegenden Hardware abstrahiert wird. Somit weist diese Architektur Schichtenmodell typische Eigenschaften aus. Die Schichten sind lose gekoppelt. Jede Schicht kennt nur die darunter liegende Schicht. Ausnahme von der Regel bilden die ’Complex Drivers’, auf die später nochmal eingegangen wird. Abbildung 8 zeigt die AUTOSAR-Architektur mit ihren verschiedenen Schichten. Abb. 8 AUTOSAR-Schichtenmodell. [10] 2.2.1 Application Layer (Applikationsschicht) In dieser Schicht finden wir die Softwarekomponenten mit ihrem funktionalen Code wieder. Die Entwicklung dieser findet hier unabhängig vom Fahrzeugbus und der verwendeten Hardware statt. Ausnahme bilden hier, wie im Abschnitt ”VFB und Softwarekomponenten” erwähnt, die Softwarekomponenten für Sensoren und Aktoren. 2.2.2 RTE Layer (Laufzeitumgebungsschicht) Während im VFB der Systemsicht die Kommunikation zwischen den Softwarekomponenten ECU-unabhängig realisiert wurde, stellt die RTE die Kommunikation zwischen den Softwarekomponenten abhängig von der Zuordnung der Softwarekomponenten auf die ECUs sicher. Befinden sich zwei miteinander kommunizierende Softwarekomponenten auf ein und derselben ECU, so stellt die RTE die Kommunikationsverbindung direkt zwischen den Softwarekomponenten her. Befinden sich die Softwarekomponenten auf verschiedenen ECUs wird die Verbindung zur anderen Softwarekomponente über Basissoftware und Fahrzeugbus durch die RTE realisiert. Die Software-Architektur von AUTOSAR 13 2.2.3 Basis Software Layer (Basissoftwareschicht) Die Basis Software Schicht ist selbst nochmal in drei Schichten und sechs Spalten unterteilt. BSW Service Layer In diesem Layer befinden sich das Betriebssystem und grundlegende Dienste für die Applikationsschicht. Beim BS handelt es sich um ein OSEKBetriebssystem, das um einige Features wie z.B. Speicherschutz oder erweiterte Zähler ergänzt wurde. Die Systemdienste dieses Layers schirmen die übrige Basissoftware vom direkten Zugriff der darüber liegenden RTE ab. Zu den Systemdiensten gehören Diagnose- und Kommunikationsfunktionen, sowie die Speicherverwaltung. BSW ECU Abstraction Layer Diese Schicht abstrahiert von den Eigenschaften des Steuergerätes und der verbauten Controller für den Zugriff auf den Bus (z.B. onBoard verbauter CAN-Controller). BSW Microcontroller Abstraction Layer Diese Schicht liegt direkt über der Hardware und ist abhängig vom verbauten Microcontroller. Sie erlaubt Initialisierung und Konfiguration des Microcontrollers. Wenn der Microcontroller getauscht wird, dann wird auch diese Schicht komplett ausgetauscht. Complex Drivers Die Complex Drivers gehören keiner Schicht an. Dieser Bereich ist im AUTOSAR Standard nicht näher definiert und sollte eigentlich nur in den nachfolgenden Situationen verwendet werden, da die Complex Driver die Schichtenlogik komplett umgehen: 1. Bei einer schrittweisen Migration auf den AUTOSAR-Standard. 2. Bei der Umsetzung von Funktionen, die im AUTOSAR-Standard (noch) nicht vorgesehen sind. 3. Zeitkritische Funktionen: Viele Module bedeuten auch viel Kommunikation, sodass unter Umständen ein verkürzter und damit schnellerer Zugriff auf die Hardware erforderlich sein kann. Basis Software Stacks Die Basis-Software wird in sechs vertikale Bereiche, die sogenannten Stacks aufgeteilt. Die Stacks und die Layer überschneiden sich und bilden sogenannte Funktionsblöcke. Innerhalb der Funktionsblöcke definiert der AUTOSARStandard sogenannte Module. Die Module innerhalb eines Funktionsblockes besitzen ähnliche Aufgaben oder erledigen gemeinsam eine Aufgabe. Die Abbildung 9 zeigt die Stacks, die Funktionsblöcke und die zugehörigen Module. Die Complex Device Drivers sind in dieser Abbildung weggelassen worden. 14 O. Busch Abb. 9 BSW-Module. [11], p.28 Außer den Complex Device Driver-Stack gibt es noch fünf weitere Stacks. Beispielhaft wird hier nur näher auf die einzelnen Module des Communication-Stacks eingegangen. Weiterführende Informationen liefert [5], Kapitel 9.4 ff oder die Dokumentation unter [1]. 1. System Service-Stack: Bereitstellung grundlegender Netzwerk- und Betriebssystemdienste. 2. Device-Stack: Er enthält die zwei funktionalen Blöcke ’onBoard Device Abstraction’ und ’Micro Controller Drivers’. Sie stellen Treiber für WatchDog-Funktionalitäten bereit. 3. Memory-Stack: Erlaubt das Speichern in nicht flüchtigen Speicher. Er besteht aus den Blöcken ’Memory Services’, ’Memory Hardware Abstraction’ und ’Memory Drivers’. 4. Communication-Stack: Stellt Kommunikationsdienste zum Datenaustausch mit anderen ECUs für Application-Layer und BSW-Layer zur Verfügung. Zu diesem Stack gehören die Funktionsblöcke ’Communication Services’, ’Communication Hardware Abstraction’ und ’Communication Drivers’. – Communication Services: Zu den hier bereitgestellten Modulen gehören unter anderem das Routen von Nachrichten, Mehrfachausnutzung eines Kanals durch Multiplexen und das Bereitstellen der Transportprotokolle für die Bussysteme CAN, LIN und FlexRay. – Communication Hardware Abstraction: Die hier zusammengefassten Module abstrahieren die busspezifische Hardware für CAN-, LIN- und FlexRay-Busse. Die Interfaces stellen Funktionen für den Zugriff auf die verfügbaren Kanäle des jeweiligen Bussystems zur Verfügung. Die Software-Architektur von AUTOSAR 15 – Communication Drivers: Alle Module dieses Funktionblocks bieten je nach Bustyp Funktionen zum Start von Übertragungen oder Call-Back Funktionen zur Verfügung. 5. I/O-Hardware-Stack: In diesem Stack sind alle Funktionsblöcke zum Setzen und Lesen digitaler Ein- und Ausgabewerte konzentriert. Der Stack umfasst die Funktionsblöcke ’I/O Hardware Abstraction’ und ’I/O Drivers’. In Abbildung 10 wird anhand des Beispiels ’Frontlicht-Management’ veranschaulicht, wie die Funktionalitäten, über die AUTOSAR-Architektur verteilt, arbeiten. Konkret betrachtet wird das Betätigen des Lichtschalters zum Einschalten des Abblendlichtes durch den Fahrer. Abb. 10 Frontlicht-Management. [11], p.66 Die Funktionalität ist auf vier Softwarekomponenten verteilt, die wiederum auf drei verschiedene ECUs verteilt sind. Die Softwarekomponente ’SwitchEvent’ ist eine hardwareabhängige Softwarekomponente, die den Schalterstatus des Lichtschalters über die Methode ’check switch()’ periodisch überwacht. Das ermöglicht die AUTOSAR-RTE, die die Verbindung zur Lichtschalter überwachenden Einheit über den I/O-Stack der Basissoftware und den DIO-Treibern zum Auslesen und Setzen von digitalen Ein- und Ausgabeports zur Überwachungseinheit leitet. Ändert sich der Status des Lichtschalters, feuert die Methode ’switch event(event)’. Die Auswertung der Methode ’switch event (event)’ erfolgt in der Softwarekomponente ’LightRequest’, die auf derselben ECU wie die Softwarekomponente ’SwitchEvent’ implementiert ist. Die Kommunikationsverbindung zwischen diesen beiden Softwarekomponenten erfolgt direkt über die RTE, ohne Einbindung der tieferliegenden Schichten. In der Softwarekomponente ’LightRequest’ wird der neue Schalter-Status ausgewertet und die Methode ’request light (type, mode)’ ausgeführt. Für das konkrete 16 O. Busch Beispiel hätte mode als Parameter der Methode ausgereicht, da nur Licht vom Typ Xenon vorhanden ist. Damit diese Softwarekomponente aber universell wiederverwendbar wird, gibt man der Methode noch den Parameter type mit, um verschiedene Lichtarten (z.B. Tageslicht-LED) ansteuern zu können. Die Methode ’request light (type, mode)’ wird in der Softwarekomponente ’Front-Light-Manager’ auf einer anderen ECU ausgewertet. Die RTE stellt die Kommunikationsverbindung zur anderen ECU über den Communication-Stack der Basissoftware und den CAN-Bus her. Die Methode ’get keyposition()’ ermittelt den aktuellen Zustand des Autoschlüssels (z. B. Auto aus, Zündung an, Motor an), um abhängig davon den gewünschten neuen Licht-Modus zu ermitteln. Beispielsweise kann beim Einschalten des Lichtschalters bei gleichzeitig ausgeschaltetem Motor, nur das Standlicht anstatt des Abblendlichtes eingeschaltet werden. Nachdem der neue Licht-Modus ermittelt wurde, wird dieser in der Methode ’set light (type, mode)’ angefordert. ’Set light (type, mode)’ wird in der Softwarekomponente ’Xenonlight’ verarbeitet. Softwarekomponenten die Daten aus Sensoren herauslesen oder Aktoren ansteuern sind nicht hardwareunabhängig. Sie sind an die Hardwarespezifika der verwendeten Sensoren und Aktoren gebunden und laufen auf derselben ECU auf der auch der Sensor oder Aktor verbaut ist. ’Xenonlight’ ist eine Softwarekomponente, die einen Aktor ansteuert (Fahrzeuglicht) und deshalb auf der ECU des Aktors läuft. Über die Methode ’set current(..)’ wird das Licht entsprechend den Anforderungen geschaltet. Die RTE stellt die benötigten Verbindungen über den I/O-Stack der Basissoftware und die PWM-Treiber zur eigentlichen Lampe her. In dem Beispiel wird anschaulich dargestellt, wie funktionaler Code, der in den beiden Softwarekomponenten ’LightRequest’ und ’FrontLightManager’ gekapselt ist, hardwareunabhängig wiederverwendet werden kann. Das ist auch der Grund dafür, dass in der Softwarekomponente ’FrontLightManager’ der Status des Autoschlüssels nicht über eine Sensor-Softwarekomponente ermittelt wird, da diese ja hardwareabhängig ist. Der Status des Autoschlüssels wird also nicht über DIO-ECU-Hardware-Treiber ermittelt, sondern über andere hardwareunabhängige Dienste bereitgestellt. 3 Umstieg auf AUTOSAR Kindel et al. [5] haben in ihrem Buch versucht den Aufwand zu ermitteln, den ein Umstieg auf AUTOSAR verursachen kann. Dabei wurde festgestellt, dass dieser von vielen Faktoren abhängig ist. Die Vorteile, die ein Umstieg mit sich bringt, sind unter anderem Kostenreduzierung, Wiederverwendung von Softwarekomponenten und die Möglichkeit neue Geschäftsmodelle zu etablieren. 3.1 Pilotphase Für eine Aufwands- und Kostenabschätzung empfehlen [5] einen vertikalen Prototypen zu erstellen. Hierbei werden alle Schritte des neuen auf AUTOSAR basierenden Erstellungsprozesses für ECU-Software durchlaufen (System-, Komponenten- und ECU-Sicht). Das hat den Vorteil, dass alle Arbeitsschritte einmal durchgeführt werden müssen und somit eine halbwegs realistische Abschätzung des Gesamtaufwandes möglich wird. Um den Prototypen durchführen zu können, müssen Mitarbeiter Die Software-Architektur von AUTOSAR 17 freigestellt und entsprechend eingewiesen bzw. ausgebildet werden. Die AUTOSARMethodik verschiebt den Aufwand weg von der Entwicklung hin zur Modellierung und Architektur. Das kann die (zeitweise) Einstellung weiterer Mitarbeiter zur Folge haben. Zur Durchführung werden auch die Werkzeuge für den AUTOSAR-Prozess benötigt. Diese sind sehr teuer und unterscheiden sich in Leistungsmerkmalen und Qualität der erzeugten Software. Deshalb sollte man bei der Auswahl der Werkzeuge viel Sorgfalt verwenden, da ein späterer Wechsel der Werkzeuge sehr teuer wird. 3.2 Umstieg auf AUTOSAR Entscheidet sich eine Firma für den Umstieg auf AUTOSAR, dann kommen weitere Aufwände auf sie zu. Die Projektprozesse müssen angepasst werden, Prozessdokumente erstellt werden, was im Hinblick auf eine verteilte Entwicklung (Offshore) extrem wichtig ist. Die Mitarbeiter müssen (um-)geschult bzw. neue Mitarbeiter müssen eingestellt werden. Die Migration auf die neue Softwarearchitektur wird parallel zum Tagesgeschäft durchgeführt werden. Problematisch wird dann die Überführung der bereits entwickelten Steuergerätesoftware auf den AUTOSAR-Standard. Entscheidend hierbei ist, wie gut die bisherige Steuergerätesoftware dokumentiert ist: – Sind alle Anforderungen bekannt und dokumentiert? – Wurde nach diesen Anforderungen auch entwickelt? Im schlimmsten Fall muss ein Reverse Engineering des alten Codes durchgeführt werden, um die tatsächlich verbauten Anforderungen zu ermitteln. Möglicherweise muss eine stufenweise Migration durchgeführt werden, was den Nachteil hat, das parallel also nach neuem und altem Standard entwickelt werden wird. 4 Fazit AUTOSAR tut sich schwer, sich als Standard durchzusetzen. In 2011 wurden 25 Millionen ECUs nach diesem Standard entwickelt. Für 2016 sind 300 Millionen ECUs geplant. Weltweit wurden 2011 circa 65,4 Millionen Fahrzeuge verkauft, siehe [15]. Nimmt man an, dass pro Auto 50 ECUs verbaut wurden, kommt man auf 3,27 Milliarden verbauter ECU in 2011. Der Anteil der ECU die nach dem AUTOSAR-Standard entwickelt wurden liegt demnach bei ca. 0,8 %. Die Core-Partner beabsichtigen bis 2015 sämtliche Steuergeräte-Software-Entwicklung mit diesem Standard zu entwickeln [1]. Außerhalb Europas spielt AUTOSAR zurzeit kaum eine Rolle. Als Lichtblick ist hier China zu nennen. Viele westliche Automobilhersteller bauen vermehrt Entwicklungszentren für Autos in China auf. Dort wird bevorzugt der AUTOSAR-Standard eingeführt, da hier keine etablierten Altsysteme die Einführung von AUTOSAR behindern [16]. AUTOSAR bietet viele Vorteile für OEM und Zulieferer. Allerdings steht dem ein nicht unerheblicher Aufwand bei der Umstellung auf die neue Softwarearchitektur gegenüber. Prof. Dr. Dieter Nazareth von der Universität Landshut bewertet die Akzeptanz von AUTOSAR durch die OEM und Zulieferer in den AUTOSAR-Bereichen unterschiedlich. Für den Bereich der Architektur, die Standardisierung der Basis-Software und Trennung von Hard- und Software sieht er eine hohe Akzeptanz. Im Bereich Interfaces erwartet er den geringsten Nutzen, so dass hier die Firmen das Thema am wenig beachten werden [17]. 18 O. Busch Ob die vom AUTOSAR-Konsortium propagierten Vorteile und Ziele wie die Verbesserung der Qualität der erstellten Softwaremodule, Kostenreduzierung und Etablierung neuer Geschäftsmodelle tatsächlich so zu Buche schlagen, wird erst die langjährige Praxis und die daraus resultierende Erfahrung mit AUTOSAR zeigen. Literatur 1. AUTomotive Open System ARchitecture (2012): Autosar WebSite: www.autosar.org. 2. AUTomotive Open System ARchitecture (2012): Autosar WebSite: www.autosar.org/ index.php?p=1&up=6&uup=0. 3. Kindel, Olaf / Friedrich, Mario: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management in der Praxis. Heidelberg, 1. Auflage 2009, p.152. 4. Dr. Florian Wohlgemut (2008): Erfahrungen bei der Einführung der modellbasierten AUTOSAR-Funktionsentwicklung, Mercedes Benz. 5. Kindel, Olaf / Friedrich, Mario: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management in der Praxis. Heidelberg, 1. Auflage 2009. 6. HIS Hersteller Initiative Software (2012): HIS WebSite: http://portal.automotive-his. de/index.php?option=com_content&task=view&id=16&Itemid=29. 7. AUTomotive Open System ARchitecture (2012): Autosar WebSite: http://www.autosar. org/index.php?p=1&up=6&uup=0&uuup=0&uuuup=0&uuuuup=0, Q22. 8. EETimes europe automotive (2012): EETimes WebSite: FIBEX XML format and AUTOSAR development (30.07.2009) http://www.automotive-eetimes.com/en/ fibex-xml-format-and-autosar-development.html?cmp_id=7&news_id=218900156. 9. Warschofsky, Robert (2009): AUTOSAR Software Architecture. Hasso-Plattner-Institute für Softwaresystemtechnik: http://www.hpi.uni-potsdam.de/fileadmin/hpi/FG_Giese/ Ausarbeitungen_AUTOSAR0809/Software_Architecture_Warschofsky.pdf . 10. Bunzel, Stefan (2010): AUTOSAR: The Standardized Software Architecture. SpringerVerlag. 11. Fürst, Simon: AUTOSAR: An open standardized software architecture for the automotive industry. October 23rd, 2008, Cobo Center, Detroit, MI, USA: http://www.autosar.org/ download/conferencedocs/03_AUTOSAR_Tutorial.pdf. 12. Dr. Freund, Ulrich / Reckels, Bernhard: Praktischer Einsatz von AUTOSARAnwendungen. (2011): http://www.elektroniknet.de/automotive/technik-know-how/ prozesse-standards-und-qualitaet/article/75805/0/Praktischer_Einsatz_von_ AUTOSAR-Anwendungen/ . 13. ] Leitner, Florian: AUTomotive Open System Architecture. Seminar Software Engineering for Automotive Systems WS 07/08.: http://www.inf.uni-konstanz.de/soft/teaching/ ws07/autose/leitner-autosar.pdf . 14. heise online (2012): Heise Developer WebSite: Friedrich,Mario/Kindel,Olaf(2009): AUTOSAR: Chance der Softwareentwicklung im Automotive-Bereich: http://www.auto.de/magazin/showArticle/article/67647/Weltweit-wurden-ueber-65Millionen-Neuwagen-verkauft. 15. auto.de (2012): Auto.de WebSite: Weltweit wurden über 65 Millionen Neuwagen verkauft. http://www.auto.de/magazin/showArticle/article/67647/ Weltweit-wurden-ueber-65-Millionen-Neuwagen-verkauft. 16. elektroniknet.de (2011): elektroniknet.de WebSite: Die AUTOSARWerkzeuglandschaft im Reich der Mitte. http://www.elektroniknet.de/automotive/ technik-know-how/prozesse-standards-und-qualitaet/article/84724/0/Die_ AUTOSAR-Werkzeuglandschaft_im_Reich_der_Mitte/. 17. heise online (2012): heise.de/iX WebSite: Interdisziplinär. Barbara Lange interviewt Professor Dr. Dieter Nazareth zur Automobilinformatik http://www.heise.de/ix/artikel/ Interdisziplinaer-1108269.html.
