Entwicklung eines AUTOSAR-basierten Eingebetteten Systems zur Evaluierung der eingesetzten Entwicklungsumgebung

Inhaltsverzeichnis

1 Einleitung

2 Stand der Technik
2.1 Steuergeräte im KFZ
2.2 Software im KFZ-Steuergerät
2.3 Automotive Embedded Software Entwicklung
2.4 Kontext für AUTOSAR

3 AUTOSAR
3.1 Vorstellung
3.2 Motive und Ziele
3.3 Der Standard AUTOSAR
3.3.1 Die AUTOSAR Methodology
3.3.2 Die AUTOSAR Architecture
3.3.3 Die AUTOSAR Interfaces
3.4 Positive Aspekte von AUTOSAR
3.5 Kritische Betrachtung von AUTOSAR
3.6 Bemerkungen
3.7 AUTOSAR 4.0

4 Hauptteil
4.1 Arctic Studio
4.1.1 Kontext der Arbeit
4.1.2 Vorstellung
4.1.3 Inbetriebnahme
4.1.4 Arbeitsgrundlage
4.1.5 Workflow und Bezug zu AUTOSAR
4.2 Entwicklung eines AUTOSAR-basierten Eingebetteten Systems
4.2.1 Vorstellung der Hardware
4.2.2 Basis-Konfigurationen
4.2.3 Erstellung einer AUTOSAR-basierten Funktionalität und Interaktion
mit modellbasierten Code-Generatoren
4.3 Evaluierung des Arctic Studio

5 Fazit und Ausblick

1 Einleitung

Ziel dieser Bachelorarbeit ist die Evaluierung der AUTOSAR-Entwicklungsumgebung der schwedischen Firma ArcCore AB: Es handelt sich um das Arctic Studio, welches auf der bekannten Entwicklungsumgebung Eclipse^[1] aufsetzt. Betrachtet wird dabei ein verhältnismäßig neues Produkt aus dem Sortiment der AUTOSAR -Werkzeuge, das gegenüber den renommierten Produkten der Markt-Führer noch kaum verbreitet und erprobt ist. So gilt es für die ITK Engineering AG, diese Integrierte Entwicklungsumgebung aus dem AUTOSAR-Umfeld in Betrieb zu nehmen, erste Erfahrungen bei der Erstellung von eingebetteten Funktionalitäten mit Arctic Studio zu sammeln und das Produkt schlussendlich zu evaluieren. Verhältnismäßig preiswerte Lizenzen für die Nutzung und die Integration des Produkts in Eclipse und dessen AUTOSAR-spezifisches Framework Artop^[2] sind die zentralen Faktoren, die eine Auswertung des Arctic Studio interessant machen.

Nach dieser Einleitung soll das zweite Kapitel dieser Arbeit den Stand der Technik offen legen. Nicht nur die Bedeutung der Elektronik, die den technologischen Fortschritt allgemein vorantreibt, soll dort angesprochen werden. Vielmehr soll auch die Rolle der Embedded Software in der rasanten Innovationsentwicklung des Automobils beleuchtet werden. Diese ist aufgrund ihrer Verborgenheit meist noch weniger bekannt als der ohnehin schon komplexe Bereich der Elektronik. Wie im zweiten Kapitel weiter erläutert, kommt es vor allem auf das Zusammenspiel dieser beiden voneinander abhängigen Teilbereiche der Ingenieursdisziplin an. Als eigener Punkt wird in dem genannten Kapitel die Entwicklung der Automotive Embedded Software angesprochen, nicht zuletzt weil das Thema dieser Arbeit direkt in diesen Kontext einzubetten ist.

Im dritten Kapitel soll der Standard AUTOSAR nicht nur in seinen Grundzügen vorgestellt, sondern auch auf Basis aktueller fachlicher Einschätzungen erörtert werden. An dieser Stelle sei bereits darauf hingewiesen, dass AUTOSAR den Rahmen für das Arctic Studio und zahlreiche weitere Software-Werkzeuge darstellt. Es handelt sich um einen Standard, der international für die Automobil-Industrie und zukünftig wohl auch über diesen Sektor hinaus Maßstäbe setzt, um die Entwicklungsvorgänge für Funktionalitäten, wie sie die Kunden mit ESP^[3] oder ABS^[4] und immer innovativeren Anwendungen beanspruchen, intelligent umzusetzen. Die zum jetzigen Zeitpunkt aufzubringenden Leistungen, um AUTOSAR in der System-Entwicklung umzusetzen, versprechen langfristig eine deutlich übersichtlichere und effizientere Entwicklung fortgeschrittener Embedded Funktionalitäten. Um konform zu dem neuen Standard entwickeln zu können, wird der Einsatz von Software-Werkzeugen, wie der des untersuchten Produkts, notwendig.

Das vierte Kapitel stellt den Hauptteil dieser Arbeit dar. Die ITK Engineering AG verfolgt das Ziel, das Arctic Studio auf seine Einsatzfähigkeit und Eignung im Rahmen von AUTOSAR-Projekten mit Kunden und Partnern der Automobilbranche zu prüfen. Im vierten Kapitel sollen demnach die Grundsteine hierfür gelegt werden. Ein allgemeiner Leitfaden zur Arbeit mit dem Produkt innerhalb des Standards AUTOSAR soll entwickelt werden. Des Weiteren soll dort eine Einsicht in die Erstellung von Embedded Funktionalitäten mit AUTOSAR und dem Arctic Studio auf Basis der Modellbasierten Entwicklung ermöglicht werden. Diese praktischen Erfahrungen machen die Formulierung eines allgemein gültigen Arbeitsablaufs überhaupt erst möglich. Finaler Inhalt des vierten Kapitels soll die Evaluierung des Arctic Studio sein.

Im letzten Kapitel sollen Fazit und Ausblick zu der hier angefertigten Arbeit präsentiert werden.

2 Stand der Technik

2.1 Steuergeräte im KFZ

Das Kraftfahrzeug der heutigen Zeit hat sich von seiner ursprünglichen Form, in der neben dem Antrieb nahezu alle Komponenten rein mechanischer Natur waren, zu einem hochkomplexen Gut entwickelt, indem die Elektronik in Gestalt von Hardware und Software eine unabdingbare Rolle eingenommen hat. Der Einsatz von Elektronik in Kombination mit mechanischen oder auch hydraulischen Bauteilen bietet neben der Erweiterung des Funktionsspektrums eine Vielzahl an technischen und wirtschaftlichen Vorteilen^[5]. Schon im Jahre 2005 war erkennbar, dass rund 90 Prozent der Innovationen im Automobil aus dem Bereich der Elektronik^[6] stammen und diese Tendenz besteht weiterhin. Die so erzeugten Fahrzeugfunktionen stellen für die Automobilhersteller auf dem Markt ein entscheidendes Differenzierungspotenzial dar^[7].

Im Bereich der Funktionserzeugung, kommt heutzutage neben anderen älteren technischen Umsetzungen dem Mikrocontroller (µC) die führende Rolle zu^[8]. Insbesondere wenn es darum geht komplizierte Funktionalitäten im Bereich der Steuerungs- und Regelungstechnik zu realisieren, stellt dessen Einsatz im Zusammenspiel mit Sensorik und Aktuatorik die einzige Möglichkeit dar, der geforderten Komplexität gerecht zu werden. Zusammen mit der Stromversorgung und der Vernetzung bilden Funktionserzeugung, Sensorik und Aktuatorik die 5 wichtigen Einheiten in der Grundstruktur der Kraftfahrzeugelektronik^[9].

Abbildung 1: Übersicht zum funktionalen Aufbau eines Steuergeräts

Der allgemeine Begriff des Steuergeräts, das im technischen Umfeld als ECU (Electronic Control Unit) bekannt ist, bezeichnet das digitalelektronische Bauteil µC, das im diskreten Zeit- und Wertebereich agiert mitsamt Peripherie-Bauteilen, die zu seiner Anbindung dienen. So erfolgt der Anschluss zu der Sensorik und der Aktuatorik, denen meistens Signale aus dem kontinuierlichen Zeit- und Wertebereich zugrunde liegen, über Wandler, einerseits Analog-Digital-Umsetzer (ADU), andererseits Digital-Analog-Umsetzer (DAU). Eine unabdingbare Rolle für die Anbindung der ECUs untereinander und mit der Sensorik und Aktuatorik kommt den diversen BUS (Binary Unit System)-Systemen zu, die in einem wechselseitigen funktionalen Zusammenhang mit den ECUs stehen. Im Kern eines jeden Steuergeräts steht die Software, die maßgeblich die Funktionalität, zu der die ECU beiträgt, festlegt. Sie macht die Realisierung umfangreicher Anwendungen erst möglich. Auf die Software und ihren Einfluss soll im folgenden Unterkapitel eingegangen werden. Abbildung 1 gibt vereinfacht den funktionalen Aufbau eines Steuergeräts wieder.

Der Einsatz von µC und Software beruht auf den gigantischen technologischen Fortschritten der Elektronik^[10] im Bereich der Halbleiter in den letzten Jahrzehnten, und bietet große Flexibilität hinsichtlich der gewünschten Funktionalität gegenüber anderen elektronischen Komponenten wie dem ASIC (Application-Specific Integrated Circuit), die alternativ zum µC zur Funktionserzeugung genutzt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Blockschaltbild des Systems Fahrer-Fahrzeug-Umwelt

Um den Begriff der Funktion einzugrenzen, kann man ihn als „gewollten Ursache-Wirkungs-Zusammenhang“^[11] auffassen. Oft aufgegriffen werden in diesem Kontext das Blockschaltbild aus der Systemtheorie und der Regelkreis aus der Regelungstechnik. Wichtig ist es in diesem Zusammenhang das „System Fahrer-Fahrzeug-Umwelt“^[12] zu betrachten, in dem das Steuergerät seine Anwendung findet. Die Abbildung 2 und die Abbildung 3 sollen zu diesen Zusammenhängen einen Überblick geben. Auf Details der Regelungstechnik, die eine der führenden Ingenieursdisziplinen der heutigen Zeit ist, kann nicht weiter eingegangen werden. Es soll an dieser Stelle hervorgehoben werden, dass nicht nur einzelne, sondern meist ein Verbund von ECUs die Regelung und Steuerung übernehmen, wie es in Abbildung 2 verdeutlicht wird. Dieser wichtige Aspekt für die Umsetzung besonders leistungsfähiger Funktionen im Automobil wird mit dem Begriff Vernetzte Systeme oder Verteilte Systeme bezeichnet. Die abstrakte funktionale Struktur muss also von der technischen Steuergeräte-Struktur differenziert werden. Alternativ zur Abbildung 2 wird der Regelkreis einer typischen Fahrzeugfunktion in Abbildung 3 dargestellt: hervorgehoben wird hier der Einfluss von Sensorik und Aktuatorik im Umfeld des Steuergeräts. Es sollte nicht in den Hintergrund rücken, dass auch zwischen Fahrer und Umwelt Wechseleinflüsse bestehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Regelkreis einer Fahrzeugfunktion

Zu Beginn des Einsatzes von Steuerungselektronik im Fahrzeug, war diese meist lokal in dem Fahrzeug-Subsystem untergebracht, an dem sie ihre Funktion realisierte. Die meisten Steuergeräte werden daher fest einem Bereich des Fahrzeuges zugeordnet. Da der gegenwärtige Markt höchste funktionelle Ansprüche an das Fahrzeug stellt, reicht eine solch Steuergeräte-orientierte Sicht aber längst nicht mehr aus, um den Ansprüchen des Kunden gerecht zu werden. Aus technischen Gründen, bleibt die Verteilung getrennter Steuergeräte im Fahrzeug bestehen, jedoch ermöglicht die Vernetzung über anwendungsspezifische BUS-Systeme, wie das seit den 80er Jahren bei Bosch entwickelte CAN^[13] (Controller Area Network), einen adäquaten Datenaustausch der Steuergeräte untereinander.

Die Anbindung an BUS-Systeme ermöglicht die Verwirklichung von umfangreichen und innovativen Funktionalitäten in Form von Software und eröffnet neue Dimensionen für die Findigkeit der Ingenieure im Automobilbereich. Eine Funktion kann aus verschiedenen Bereichen im Automobil ihre Informationen beziehen, um anschließend nach Verarbeitung derselben an unterschiedlichen Stellen des Fahrzeugs zu agieren. Mehrere Funktionen können auf demselben Steuergerät untergebracht werden^[14]. Eine Funktion kann auch in Teilfunktionen aufgeteilt werden, die anschließend auf verschiedenen ECUs gespeichert werden^[15]. Entscheidend ist es also, wie bereits im vorherigen Absatz erwähnt, zwischen der logischen Funktions-Vernetzung und der Steuergeräte-Vernetzung zu unterscheiden. Der Vergleich von a) und b) in der Abbildung 4 soll diese Differenzierung verdeutlichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Logische Vernetzung „a)“ und Steuergeräte-Vernetzung „b)“ in einem KFZ

Um der Anwendung verteilter Funktionen im aktuellen Automobil etwas näher zu kommen, wird an dieser Stelle Bezug auf das Buch von Toralf Trautmann, „Grundlagen der Fahrzeugmechatronik. Eine praxisorientierte Einführung für Ingenieure, Physiker und Informatiker“^[16] genommen, genauer auf das 8. Kapitel. Die verteilte Funktion der adaptiven Geschwindigkeitsregelung, auch bekannt als ACC (Adaptive Cruise Control), wird dort näher erläutert, und man kann sich einen Eindruck über den Umfang einer solchen Funktionalität verschaffen. Neben diesem verhältnismäßig bekanntem Beispiel werden auch Funktionen erwähnt, die dem Autofahrer wohl meist verborgen bleiben. So bestehen im manchen Automobilen logische Verknüpfungen zwischen dem Regensensor und der Bremsanlage, die bei Feuchtigkeit eine Trocknung der Bremsscheiben und somit ein optimales Bremsverhalten des Automobils bei Regen gewährleisten sollen. Der Überbegriff Embedded Systems, zu Deutsch Eingebettete Systeme, bezeichnet all diese Systeme, die mit Hilfe eines Steuergeräts „quasi verborgen“ eine technische Funktion realisieren^[17]. Die Multimedia-Funktionen werden in der Regel gesondert betrachtet.

Die Anzahl der Funktionen, über die ein durchschnittliches Automobil verfügt, steigt insbesondere seit Anfang des vergangenen Jahrzehnts stark an. Diese Entwicklung geht mit einem Anstieg der Anzahl an Steuergeräten im Fahrzeug einher, wobei zu vermerken ist, dass insbesondere in den letzten Jahren die Dichte der Funktionen, die auf demselben Steuergerät angesiedelt sind, zunimmt^[18]. Oberklassewagen wie der BMW der 7er Serie aus dem Jahre 2008 verfügen bereits über bis zu 90 Steuergeräte^[19] und auch bei Mittelklassewagen sind 30 ECUs keine Seltenheit. Abbildung 5 zeigt die Steuergeräte-Topologie mit serienmäßigen und optionalen Steuergeräten in der gemeinsamen Plattform der Modelle Audi A6 und A7 aus dem Jahre 2011.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Steuergeräte-Topologie der Modell-Plattform Audi A6 und A7 aus dem Jahre 2011

Zunehmend werden auch in höchstem Maße sicherheitsrelevante Funktionen mit Einsatz von Elektronik und Software realisiert^[20]. Der Sammelbegriff X-By-Wire bezeichnet den Trend zur Verkettung von Sensorik, ECU und Aktuatorik. Auch bewährte mechanische Systeme des Fahrzeugs, werden heutzutage zur Optimierung durch mechatronische Systeme ersetzt, in der ECUs und deren Software im Zentrum der Funktionalität stehen. So wird z.B. bei dem Steer-By-Wire der Lenkbefehl ohne durchgängige mechanische Verbindung vom Lenkrad auf die Vorderräder umgesetzt.

Es ist nicht Teil dieser Arbeit nähere Details zur technischen Umsetzung der ECU-Hardware zu geben. Das 8. Kapitel und insbesondere Unterkapitel 8.1 im Buch „Grundlagen der Kraftfahrzeugelektronik“ von Manfred Krüger^[21] liefert hierzu gute Informationen; die Grundzüge der ECU-Hardware werden dort näher erläutert. Aus dem gleichen Grund kann hier nicht ausführlich auf das Themengebiet BUS-Systeme eingegangen werden. Hierzu bietet beispielsweise das Kapitel 1 im Werk „Automobilelektronik. Eine Einführung für Ingenieure“ von Konrad Reif^[22] Basis-Informationen.

2.2 Software im KFZ-Steuergerät

Im vorherigen Kapitel wurde angedeutet, dass Software im hier angesprochenen Kontext eine Schlüsselstellung hat. Es stellt sich aber schnell die Frage, wie sich Software definieren lässt. Es ist für diesen Zweck hilfreich, sich einer Basis-Definition eines Online-Lexikons zu bedienen^[23]: Zum einen ist die Abgrenzung gegenüber der Hardware, die man als Gesamtheit der materiellen Bestandteile eines Systems ansehen kann, wichtig, zum anderen ist die Differenzierung zwischen dem Software-Programm und den Daten, die von der Software verarbeitet werden, von Bedeutung.

Um dies im Bereich der Mikrocontroller zu verdeutlichen^[24]: Programm und Daten sind meist in separaten Speicher-Bereichen untergebracht. So wird das eigentliche Programm in der Regel in einem Flash-ROM (Read-Only Memory) abgelegt und Daten können unter anderem im RAM (Random Access Memory) gespeichert werden. Diese Speicher-Bausteine selbst sind Teil der Hardware, deren Zentrum der Prozessor ist: Er verarbeitet die Programm-Befehle mit einer festgelegten Taktfrequenz.

Im Rahmen dieser Arbeit, soll also mit Software folgendes bezeichnet werden:

- Information, die in einem schöpferischen Vorgang in Modellen und Hochsprachen der Programmierung entwickelt wird, um Funktionalitäten im Automotive Bereich zu produzieren.
- Das Programm in Form digitaler Information, Bits und Bytes, im Speicherbereich von KFZ-Steuergeräten, die deren Anwendung grundlegend mitbestimmt und deren Rechenkapazität kontrolliert.

Aus der ersten Charakterisierung leiten sich vor allem Vorgehensweisen und Techniken für die Entwicklung ab. Die mit der zweiten Beschreibung angesprochene Eigenschaft deutet hingegen mehr auf das Endprodukt hin, welche die eigentliche Funktionalität darstellt und zahlreiche Spezifikationen erfüllen muss.

Von elementarer Bedeutung ist der Prozess der in Abbildung 6 dargestellt wird. In nahezu jedem Software-Entwicklungsprozess ist er aufzufinden. Entwicklungsseitig wird Software meist in Form von Quellcode in Programmierhochsprachen wie ANSI-C gehandhabt. Steuergeräteseitig stehen die digitalen Informationen im Vordergrund, Formate wie -S19, -elf oder -exe müssen aus der Entwicklungssoftware erzeugt werden, um Funktionalitäten auf Steuergeräten umzusetzen. Um also von der Entwicklungssoftware zur Steuergerätesoftware überzugehen, müssen PC-seitig Schritte wie das Kompilieren und Linken vollzogen werden. Man kann diesen Prozess mit den Begriffen Übersetzen und Binden gleichsetzen. Der so erzeugte Maschinencode, der auch als Executable bezeichnet wird, kann nun auf das Steuergerät geflasht werden, ein Vorgang, der seinen Namen in Anlehnung an den hierbei betroffenen Flash-Speicher, der in der Entwicklung als Programmspeicher dient, trägt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Ablauf zur technischen Programmerzeugung

Eine gute Einführung zum Thema Software für Eingebettete Systeme bietet das Skript „SW-Engineering - Strukturen eingebetteten Codes – modellbasierte Modellierungstechniken -“^[25] von Reiner Kriesten. Darüber hinaus liefert sein Buch „Embedded Programming. Basiswissen und Anwendungsbeispiele der Infineon XC800-Familie“ einen profunderen Einstieg in den Umgang mit Mikrocontrollern und deren Programmierung.

Software für Eingebettete Systeme kann ihrem Zweck nach in zwei Kategorien unterteilt werden^[26] –diese Aufteilung spiegelt sich bei der Entwicklung in unterschiedlichen Aufgabenteilungen wieder. So unterscheidet man prinzipiell zwischen Applikationssoftware und Plattformsoftware. Die Applikationssoftware beinhaltet die eigentliche Funktionalität. Die Plattformsoftware dient in erster Linie der Ansteuerung und Abstraktion der verwendeten Hardware. Sie bezeichnet zum einen die Treiber, die für den Betrieb der verschiedenen Einheiten (Ein-und Ausgänge, Speicher, etc.) benötigt werden und zum anderen das Betriebssystem. Die Notwendigkeit der Plattformsoftware rührt von der Artenvielfalt der im Bereich der Eingebetteten Systeme verbreiteten Hardware: Es werden so viele unterschiedlichen Steuergeräte mit verschiedensten Peripherie-Bauteilen eingesetzt, dass deren Ansteuerung eine Aufgabe mit großer Vielfalt darstellt.

Sehr oft werden an die Ausführung von regelungstechnischen Funktionen in der Software strenge zeitliche Anforderungen gestellt^[27]. Dies bedeutet, dass gewisse Aufgaben innerhalb eines begrenzten Zeitraums erledigt werden müssen. Als zentraler Teil der Software wird daher oft ein sogenanntes Echtzeitbetriebssystem, im Fachjargon als RTOS (Real Time Operating System) bezeichnet, vorgesehen, das „die Betriebsmittel verwalten und die Ausführung von anderen Programmen überwachen und steuern“^[28] soll. Einen guten Einstieg in diese Thematik erhält man im Kapitel 2.4 des Werkes [A1] oder im 2. Kapitel des Handbuchs [A14]. Der meist verbreitetste Standard für ein solches Echtzeitbetriebssystem im Fahrzeug ist das von der Organisation OSEK/VDX^[29] (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug/ Vehicle Distributed Executive) definierte OSEK-OS.

Es gilt schließlich nochmal die zentrale Rolle der Software im System Fahrzeug zu verdeutlichen. Die Software ist die Basis der Funktionserzeugung^[30], die nur im Zusammenspiel mit dem gesamten technischen System funktioniert^[31]. Das Thema „Embedded Software“ ist hochkomplex. Nahezu jede erdenkliche Funktionalität kann in Form von Software erstellt werden und dies für die verschiedensten Varianten von Fahrzeugen mit unterschiedlichen ECU-Architekturen. „Die Softwareumfänge liegen bei bis zu 100 Millionen Lines of Code und Tausende von Funktionen werden durch Software bestimmt“^[32].

Der Fachartikel „Mit welcher Software fährt das Auto der Zukunft?“^[33] aus der ATZ extra Ausgabe 2011-03, bündelt mehrere nennenswerte Aspekte: Die Software wird als „dominierender Innovationsfaktor im Auto“ bezeichnet. Als Ursachen für das immer weiter wachsende Bedürfnis an Software im Fahrzeug werden Elektromobilität und immer stärkere Vernetzung des Fahrzeugs nach außen mit dem Schlagwort Car-2-X genannt. In dem Artikel aufgeführte Schätzungen gehen von einer Entwicklung aus, die der Software im Jahre 2025 zwischen 30 und 50 Prozent des Kostenanteils eines Fahrzeugs zuweisen könnten. Ein erheblicher Einfluss auf dieses Geschehen, kommt dem Prozess der Softwareentwicklung zu: Neue Architektur-Überlegungen, noch mehr Qualitätssicherung und Standardisierung sind im Rahmen der Entwicklung angesagt.

2.3 Automotive Embedded Software Entwicklung

Es ist nicht möglich eine Arbeit im Rahmen der Fahrzeugelektronik zu schreiben, ohne das V-Modell^[34] zu erwähnen. Für erfahrene Entwickler und Ingenieure in der Branche der Eingebetteten Systeme mag dieser Begriff eine Selbstverständlichkeit sein. Genau dies ist der Grund ihn zu erwähnen. Es handelt sich um ein Vorgehensmodell, dessen Anwendung sich mehr als bewährt hat und dessen Befolgung maßgeblich hilft, um der Komplexität bei der Entwicklung vernetzter Systeme im Fahrzeug Herr zu werden. Es soll hier mehr auf das Vorgehen an sich als auf die Gründe und Ziele der Entwicklungsstrategien eingegangen werden.

Der zweite Teil des Buchs [A9] erklärt detailliert neben geltende Anforderungen, vor allem Techniken und Methoden der Modellbasierten Software-Entwicklung für Eingebettete Systeme. Hierbei ist der Begriff der Modellbasierten Entwicklung^[35] von größter Bedeutung: Mit Hilfe von graphischen Benutzer-Oberflächen werden viele Entwicklungsschritte auf hohen Abstraktionsebenen durchgeführt. Als bekanntester Vertreter der Programme in der modelbasierten Entwicklung sei hier Simulink von Mathworks^[36] genannt. Größter Vorteil von vielen Tools der Modelbasierten Entwicklung ist die revolutionäre automatische Code-Generierung, bei der Software aus Modellen und Konfigurationen vollautomatisch erstellt wird. Im fünften Kapitel des Werks [A1] können angewandte Methoden und Werkzeuge der Modelbasierten Entwicklung eingesehen werden.

Neben dem V-Model finden auch Normen Anwendung, wie sie in der ISO-9000 Familie, in SPICE (Software Process Improvement and Capability Determination) oder im CMMI (Capability Maturity Model Integration) definiert sind^[37]. Extrem hilfreich für die Arbeitsprozesse ist die Standardisierung: Die Einhaltung von ASAM^[38] (Association for Standardisation of Automation and Measuring Systems), OSEK, JasPar^[39] (Japan Automotive Software Platform Architecture) und nicht zuletzt AUTOSAR vereinfachen erheblich die Abläufe, bei denen der Datenfluss-und Austausch allgegenwertig ist.

Permanente Begleiter in der Software-Entwicklung wie auch im Rest der KFZ-Elektronik sind vor allem die strengen Sicherheitsansprüche und der hohe Kostendruck^[40]. So müssen bei der Funktionsauslegung immer umfangreiche Tests mit Rückschlüssen für die Entwicklung durchgeführt oder auch redundante Auslegungen vorgesehen werden. Speicherbedarf und die notwendige Hardware zur Unterbringung der Software müssen angesichts der extrem hohen Stückzahlen in der Automobilbranche optimiert werden, um die Kosten einzudämmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: V-Modell

Um hier die Grundzüge des V-Modells kompakt darstellen zu können, soll eine Beschreibung in Anlehnung an Konrad Reifs Schilderung im 3. Kapitel seines Buchs [A3] erfolgen. Die Abbildung 7 gibt dieses Vorgehen wieder. Man sollte sich immer im Klaren sein, dass das V-Modell eine ideale Darstellung für das Vorgehen in der Entwicklung ist, welche nur schwer den sich oft wandelnden Charakter des mit dem Kunden erstellten Lastenhefts wiederspiegeln kann. Auch der in Realität oft verschwimmende Übergang zwischen den einzelnen Phasen, ist hier nicht ersichtlich.

Es lassen sich folgende grundlegende Merkmale für das V-Modell ausmachen:

1. Trennung in zwei Äste, die das V bilden, und den idealen Verlauf der Entwicklung darstellen.
2. Vertiefung in die Entwicklung auf der linken Seite und Integration und Tests der Entwicklung auf der rechten Seite.
3. Horizontale Wechselwirkungen zwischen absteigendem und aufsteigendem Ast.
4. Aufteilung der Systementwicklung in Software, Hardware, Aktuatorik und Sensorik.
5. Der Sockel des V stellt den zentralen Implementierungsschritt dar.

Im linken Ast verfährt man nach dem Prinzip einer sogenannten Top-down-Entwicklung, bei der aus den generellen Anforderungen immer mehr ins Detail entwickelt wird. So wie man beim Folgen dieses Asts absteigt, gewinnt die Entwicklung immer mehr an Tiefe. Am Anfang einer jeden Entwicklung stehen die Anforderungen an die gewünschte Fahrzeugfunktion auf Systemebene. Hiervon ausgehend wird ein abstraktes Funktionsmodell, die logische Systemarchitektur, die noch ganz von der technischen Umsetzung gelöst ist, erarbeitet. Bei der Spezifikation der technischen Systemarchitektur wird dann die Verknüpfung der notwendigen ECUs vorgenommen, die Funktionalitäten der logischen Architektur werden auf die ECUs verteilt und passende BUS-Systeme werden gewählt. Bei diesem Entwicklungsstand kommt es nun zur Aufgliederung des Prozesses, aus der ein autarker Pfad für die Softwareentwicklung entsteht.

Es werden einmal mehr Überlegungen zur Architektur, diesmal der Software, angestellt. Schlagwörter sind hier Abstraktion und Schichtenmodell. Nachdem man bei diesem Schritt am Sockel des V angelangt ist, werden die verschiedenen Bestandteile der Software-Architektur, die man als Software-komponenten bezeichnet, nun konkretisiert. So werden Daten-, Verhaltens- und Echtzeitmodell erstellt^[41] und eine prozessornahe Softwarelösung gefertigt. Endergebnis dieses Arbeitsschrittes ist Quellcode in Form einer Hochsprache, meist C im Automotive Bereich, oder Maschinencode. Die Programmierung von Maschinennahem Code kann Vorteile aufweisen, wenn es darum geht relevante Festlegungen hinsichtlich Prozessor und Speicher zu treffen^[42].

Der Verlauf im rechten Ast des V-Modells beinhaltet eine Reihe von Tests, von denen der Komponenten-Test an erster Stelle steht. Es werden ebenfalls die Integrationstests durchgeführt, bei denen die jeweiligen Bestandteile auf das Zusammenspiel in ihr Architektur-Gefüge überprüft werden. Eine Errungenschaft der letzten Jahre sind die im Rahmen der modelbasierten Entwicklung durchführbaren virtuellen Tests, die immer frühzeitigere Rückschlüsse auf das entwickelte Produkt erlauben^[43]. Es soll hier auch nochmal auf die erwähnten horizontalen Beziehungen im V-Modell eingegangen werden: Für jeden Testfall auf einer Ebene im aufsteigenden Ast werden als Bewertungskriterien die Spezifikationen derselben Ebene im absteigenden Ast herangezogen. Aus der Abbildung 7 nicht so klar ersichtlich ist jedoch der Einfluss der Testfälle auf die Spezifikationen. Ohne die notwendigen Rückschlüsse auf die Spezifikationen zu ziehen, wären die Test aber zwecklos.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Teilung des V-Modells zwischen OEM und Zulieferer

Um den Entwicklungsprozess auch wirtschaftlich einzubetten, soll betont werden, dass er geteilt, also im Zusammenspiel mit Zulieferern abläuft. Dies gilt für den gesamten Elektronikbereich, soll aber nur für den Softwarebereich besprochen werden. Die Abbildung 8 veranschaulicht diesen Zusammenhang. Grundsätzlich kann man die Systemüberlegungen im oberen Abschnitt des V den Automobilherstellern, die in ihrer Branche meist als OEMs (Original Equipment Manufacturer) bezeichnet werden, zuordnen. Die eigentliche Softwareentwicklung (in der Basis des V) für eine gewisse Funktionalität wird von spezialisierten Zulieferern übernommen. Hierbei können sich, wie Abbildung 9 zeigt, gewisse Varianten Im Entwicklungsprozess ergeben: Stehen die Anforderungen an das System seitens des Automobilherstellers, können verschiedene Zulieferer mit der Software-Realisierung gewisser Funktionalitäten beauftragt werden. Umgekehrt kann auch ein Zulieferer eine Software-Lösung zu einer gewissen Aufgabe mehreren OEMs anbieten. Die ideale 1:1 Beziehung, bei der die gesamte Software eines Fahrzeugs für einen OEM von einem Zulieferer realisiert wird oder ein Zulieferer seine Lösung lediglich einem OEM anbietet, ist untypisch. Ziel dieses Absatzes ist also, sich hinsichtlich der vorhandenen Multiplizität in den OEM-Zulieferer-Beziehungen bewusst zu machen, dass eine erhöhte Komplexität bezüglich der Schnittstellen der Zulieferer-Software zu den OEM-Systemen besteht und somit eine gewisse Adaptabilität zwischen der Software-Lösung und dem Steuergeräte Netzwerk, das einem Fahrzeug zugrunde liegt, notwendig ist. Die Lieferanten Beziehungen des Herstellers sind hier selbstverständlich vereinfacht dargestellt^[44].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Multiplizität in den OEM-Zulieferer-Beziehungen

2.4 Kontext für AUTOSAR

Um sich erste Vorstellungen zum Thema AUTOSAR bilden zu können, ist es an dieser Stelle sinnvoll, die zentralen Gedankengänge aus den vorherigen Unterkapiteln zu kondensieren. So sticht vor allem ins Auge, dass Embedded Software ein hochkompliziertes Gut ist, das gerade durch seine immaterielle Beschaffenheit schwer zu begreifen ist.

Software für Steuergeräte weist eine stetig wachsende Bedeutung in diversen Gebieten der Automobilbranche auf und schafft sogar neue Bereiche für die Entwicklung, wie es z.B. die Car-2-X Technologien zeigen. Software ist der große Weg zu Wertschöpfung im Automobil unserer Zeit. Sämtliche Randbedingungen der Automobilbranche finden daher auch hier Geltung: So sind ständige Innovationen, geringe Entwicklungskosten, kurze Entwicklungszeiten, extrem hohe Sicherheitsanforderungen und Umweltschutz Faktoren, die allgegenwertig sind. Innovation und Kostensenkung bewirken so z.B. das man immer umfangreichere und leistungsfähigere Software entwickelt und diese bei möglichst geringem Ressourcen-Verbrauch im Fahrzeug einsetzen möchte^[45].

Wie bereits mehrfach angedeutet besteht zwischen Hardware und Software in gewisser Hinsicht eine Diskrepanz. Die Software ist im Bereich der vernetzten Systeme nur als Teil des gesamten Systems vollständig funktionsfähig und somit fest an das System und dessen Hardware gebunden. Trotzdem gelten an sie gewisse Ansprüche, die dafür sprechen sie von einer spezifischen Hardware zu entkoppeln. Es sollen hier exemplarisch folgende Punkte geschildert werden:

- Beispielsweise zielt ein Zulieferer darauf ab, eine Funktion in Form von Software für möglichst viele OEMs und deren Fahrzeugreihen nutzbar zu machen. Hierbei ergibt sich jedoch folgende Problematik: Die Steuergeräte-Topologie mit BUS-Systemen kann von einem Fahrzeug zum anderen völlig unterschiedlich sein und weiterhin unterscheiden sich die einzelnen Steuergeräte vom Prozessor bis zu den Speichereinheiten. Des Weiteren besteht ein grundsätzlicher Unterschied zwischen der Funktionsvernetzung und der Steuergeräte-Vernetzung im Fahrzeug, wie es im Unterkapitel „2.1 Steuergeräte im KFZ“ dargelegt wurde. Es stellt sich demnach die Frage, wie eine Software-Funktionalität für diese unterschiedlichsten Bedingungen ausgelegt werden kann.
- Hardware und Software folgen unterschiedlichen Entwicklungen. Unabhängig voneinander können in beiden Bereichen Innovationen entstehen. Es wäre daher z.B. sinnvoll, wenn eine bereits entwickelte Funktionalität mit einer neuartigen Hardware-Komponente verwendbar wäre. Umgekehrt ist es auch von Vorteil, wenn eine neue Software-Anwendung auf ein bereits produziertes Fahrzeug nachgeladen werden kann^[46], ohne tief auf die Hardware des betroffenen KFZ eingehen zu müssen. Gerade letztere Variante ist insofern von Interesse, als heute produzierte Fahrzeuge meist umfangreich mit Sensorik, Aktuatorik und Steuergeräten ausgestattet und mit langen Lebenszyklen im Gebrauch sind. Eine Erweiterung der Funktionalitäten des Fahrzeuges über ein Software-Update ist daher von Bedeutung.

Die Tatsache, dass die aktuell gängige Embedded Software noch stark auf technische Besonderheiten ausgerichtet ist, erhöht enorm deren Kompliziertheit und verursacht hohe Kosten^[47]. Im allgemeinen Automotive Kontext gelten Kosteneinsparung und Qualitätssteigerung. Mit Blick auf die steigende Bedeutung der Software ist es also an der Zeit, im Fahrzeug rechtzeitig die grundlegenden Maßnahmen zu ergreifen, um die Software-Entwicklung mit all ihren aktuellen Gegebenheiten und bewährten Prinzipien wie der Modellbasierten Entwicklung, beherrschbar und wirtschaftlich zu gestallten^[48].

3 AUTOSAR

3.1 Vorstellung

AUTOSAR steht für „AUTomotive Open System ARchitecture“. Aus wirtschaftlicher Perspektive, handelt es sich um eine internationale Partnerschaft von Automobilherstellern, Automobil-Zulieferern, Standard-Software-und Software-Tool-Herstellern sowie Halbleiter-Produzenten, die im Jahre 2003 gegründet wurde.^[49] Im Zentrum der Entwicklungspartnerschaft, die in vier Mitgliedschaftsebenen strukturiert ist^[50], stehen die neun Core Partner, unter denen denen fünf deutsche Unternehmen auftreten.

Die Vorstellungsbroschüre der AUTOSAR Initiative^[51] präsentiert folgende zwei Leitsätze:

- „PRINCIPLE OF AUTOSAR: AUTOSAR has the principle “Cooperate on standards, compete on implementation”. As the delivery of implementations – in particular implementations of basic software and tooling – must be enabled and supported worldwide, the best quality and service is expected in free competition on implementation level.”
- „AUTOSAR – THE VISION: AUTOSAR aims to improve complexity management of integrated E/E architectures through increased reuse and transferability of SW modules between OEMs and suppliers”
Neben einer Vielzahl an Zielen und Vorteilen, die von der AUTOSAR-Initiative angeführt werden, lassen sich aus den beiden zitierten Aussagen die Hauptgedanken der Partnerschaft entnehmen:
- AUTOSAR legt eine Standardisierung für Software im KFZ-Steuergerät fest.
- Die Software soll so weit wie möglich Hardware-unabhängig gemacht werden.

Wie der Titel „AUTomotive Open System ARchitecture“ andeutet, wird des Weiteren ein besonderes Augenmerk auf die Architektur gelegt. AUTOSAR umfasst in der aktuellsten Version 4.0 ca. 16000 Seiten Spezifikationen^[52], die sich ausschließlich auf Software beziehen. An dieser Stelle lohnt es sich eine begriffliche Auffälligkeit zu analysieren. Im Namen AUTOSAR wird von System-Architektur gesprochen, die Spezifikationen von AUTOSAR betreffen jedoch nur die Software. Man könnte daher meinen, dass der Titel AUTOSAR einen Umfang suggeriert, den er gar nicht umfasst. Handelt es sich um Software oder Systeme? Wie weit greift der Standard AUTOSAR tatsächlich? Wie es Olaf Kindel und Mario Friedrich im 2. Kapitel ihres Buchs „Software-Entwicklung mit AUTOSAR. Grundlagen, Engineering, Management in der Praxis“^[53] deuten, rührt diese begriffliche Vermischung von der zentralen Rolle der Software im Bereich der Automobilelektronik: Die Software fügt die vielen vorhandenen Hardware-Standards zu einer funktionalen Einheit zusammen. Die Aussage „Im Gegensatz zu klassischer IT-Software ist das entwickelte Produkt nicht die Software selbst sondern das Gesamtsystem“^[54] im Buch „Eingebettete Systeme. Systemgrundlagen und Entwicklung eingebetteter Systeme“ von Karsten Berns, Bernd Schürmann und Mario Trapp bündelt sehr gut diesen Sachverhalt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: AUTOSAR Timeline

Die zeitliche Organisation des Gremiums strukturiert sich in drei strategischen Phasen, der Reihe nach Basic Development, Extension und Maintenance die sich zum Teil überlappen. AUTOSAR hat sich mittlerweile fest im Automobilmarkt etabliert^[55]. Nachdem sich Release 3.2 bewähren konnte, stellt Release 4.0 die aktuellste Veröffentlichung von AUTOSAR dar. Wie man es der Abbildung 10, die den zeitlichen Ablauf von AUTOSAR darstellt, entnehmen kann, werden diese beiden letzten Versionen über die nächsten Jahre hinweg nebeneinander unterhalten und weiterentwickelt. Ein Auszug aus der Fachpresse, aus dem Artikel „Autosar 4.0 – und jetzt? Herausforderungen und Lösungsansätze für den Einsatz“^[56], der im März 2012 in der ATZelektronik erschienen ist, beschreibt diesen Sachverhalt besonders treffend: „Die Release 4.0 bietet zahlreiche neue Features, dazu zählen Konzepte bezüglich Functional Safety (Funktionale Sicherheit), Multi-Core, Partial Networking (Teilnetzbetrieb) etc.. Die Version stösst auf grosse Resonanz, BMW und Volvo setzen sie bereits für ihre nächsten Fahrzeugprojekte ein. Auch weitere OEMs, die Autosar neu einführen wollen, interessieren sich für die Release 4. Parallel dazu wird es jedoch noch länger die Autosar Release 3.2 geben, die vor allem bei zwei grossen deutschen OEMs, Daimler und Audi, zum Einsatz kommt“.

Trotz der grundsätzlich positiven Resonanz ist die Verbreitung von AUTOSAR heutzutage noch begrenzt. Schätzungsweise 25 Millionen Steuergeräte, und damit nur ein kleiner Bruchteil der sich im Umlauf befindlichen ECUs, basieren auf der AUTOSAR-Software-Implementierung. Die Prognosen für den Standard stehen jedoch sehr gut: Im Jahre 2009, wurden ca. 80 Prozent der weltweit produzierten Automobile von AUTOSAR Mitgliedern gefertigt und man schätzt die Anzahl der AUTOSAR-konformen ECUs auf ca. 300 Millionen im Jahre 2016^[57].

Um die Vorstellung der AUTOSAR-Partnerschaft abzuschließen, ist es auf jeden Fall noch erwähnenswert, dass AUTOSAR sich in eine Reihe von bestehenden Standards einordnet, die sich gegenseitig idealerweise zum Großteil ergänzen^[58]. So seien an dieser Stelle vor allem Automotive SPICE (Automotive Special Interest Group)^[59], JasPar und HIS (Herstellerinitiative Software)^[60] erwähnt. Es soll nicht weiter auf deren Details sowie die zahlreichen anderen Standards, wie sie zum Beispiel bei den BUS-Systemen vorhanden sind, eingegangen werden.

3.2 Motive und Ziele

Um der Absicht von AUTOSAR näher zu kommen, ohne auf Details in der Umsetzung vorzugreifen, ist wohl ein Zitat von Olaf Kindel und Mario Friedrich erwähnenswert: „AUTOSAR möchte einen Paradigmenwechsel in der automotiven Softwareentwicklung herbeiführen: weg von einem steuergerätezentriertem Ansatz und hin zu einem funktionsbasierten Ansatz“^[61].

AUTOSAR entspringt nicht nur aus generell bewährten Prinzipien der Softwaretechnik, sondern vielmehr auch aus Prinzipien der Embedded Software – Software für Eingebettete Systeme – für das KFZ. Zu seinem Verständnis, bedarf es der Betrachtung der Gesamtpalette an Fahrzeugelektronik mit ihrer aktuellen Entwicklung und vor allem ihrer Entwicklung in der Zukunft (Entwicklung im Sinne von Schaffungsprozess), in der die Modelbasierte Entwicklung unabdingbar ist.

Wie es der Name verrät schreibt der Standard „AUTomotive Open System ARchitecture“ eine Architektur vor. Es ist hierbei von großer Bedeutung, den gesamten Arbeitsprozess, der in Bezug zu dieser Architektur steht, zu betrachten, denn die Architektur der Software steht in permanenter Wechselwirkung zu den geltenden Anforderungen, sowohl den funktionalen als den nicht-funktionalen. Der Schaffungsprozess Verteilter Systeme in einem Entwicklungsprojekt findet oft in mehreren Entwicklungsteams statt. Es besteht eine starke Aufgabenteilung und Kommunikation zwischen OEMs und Zulieferern. Zu betonen ist die bereits genannte zentrale Rolle der Software in einem Gesamtsystem aus Elektronik, Mechanik und Hydraulik. AUTOSAR regt durch ein vorgefertigtes Architekturkonzept und den zugehörigen Konzepten für Arbeitsprozesse eine Verbesserung der Embedded Software Entwicklung unter Einbeziehung all dieser Bedingungen an.

Im Bereich der Software-Architektur spielen die Prinzipien der Abstraktion und der System-Partitionierung sowohl in Schichten als auch Komponenten eine dominante Rolle. Durch diese Prinzipien werden implizit die Grundlagen geschaffen, um mit der Komplexität, dem hohen Vernetzungsgrad, der Größe und kurzen Entwicklungszeit der heutigen Embedded Software Projekte umzugehen. Die Kapitel 2 und 3 des Werks [A8] bieten zu diesen Themen sehr aufschlussreiche Informationen.

Der globale Gedanke der Verbrauchs-und Emissionssenkung setzt auch bei Steuergeräten und der Software, die sie verwaltet, an. Der Verbrauch der Steuergeräte im KFZ wird mit durchschnittlich 5 Prozent des gesamten Energieverbrauchs eines Fahrzeugs^[62] veranschlagt. AUTOSAR hat sich mit „Concepts for Efficient Energy Management“ auch Veränderungen in diesem Bereich zum Ziel gesetzt. So werden Konzepte wie das Partial Networking, bei dem ECUs, die nicht an Kommunikationsprozessen beteiligt sind, in Ruhephasen versetzt werden, von AUTOSAR unterstützt^[63].

Um den kompletten Gedankengang nochmal zusammenzufassen, kann an dieser Stelle eine Aussage des Konsortiums angeführt werden: „The AUTOSAR development partnership is focused on managing the growing complexity in the development of automotive electric/electronic (E/E) architecture, with the aim to improve development efficiency – without making compromises on quality. AUTOSAR paves the way for innovative electronic systems that further improve performance, safety and environmental friendliness“^[64].

3.3 Der Standard AUTOSAR

Dieser Teil der Arbeit soll der Einführung in den Standard, den AUTOSAR definiert, dienen. Grundlage für die Informationen zum Standard sollten in erster Linie die Dokumente der Website (http://www.autosar.org/) sein. Zum Einstieg eignen sich besonders die Dokumente, die unter „Media“ à „Basic Information“ und „Events & Publications“ à „Publications“ zugänglich sind. Der Standard selbst ist über die Spezifikationen der verschiedenen Versionen 2.0 bis 4.0 unter „Specifications“ in vollem Umfang für jedermann zum Download verfügbar. Um die Informationsflut zu überschauen, gilt es die zentralen Dokumente, die ohne Hervorhebung in der jeweiligen Version des Standards enthalten sind, aufzusuchen. Dies kann je nach Arbeitsschwerpunkt sehr unterschiedlich sein, gewisse Dokumente sind jedoch im Umgang mit AUTOSAR unvermeidbar. So eignet es sich im Rahmen der Version 3.2 besonders, eine Herangehendweise, wie sie auf den Seiten 68-71 im Buch „Softwareentwicklung mit AUTOSAR“, [A8], nahgelegt wird, zu befolgen. Von besonderer Bedeutung sind demnach:

- AUTOSAR_Methodology.pdf
- AUTOSAR_SWS_VFB.pdf
- AUTOSAR_LayeredSoftwareArchitecture.pdf
Ebenfalls zu empfehlen sind:
- AUTOSAR_SWS_RTE.pdf
- AUTOSAR_SoftwareComponentTemplate.pdf
- AUTOSAR_TechnicalOverview.pdf

Abbildung 11 zeigt die drei großen Themenbereiche des Standards AUTOSAR: eine Architektur der ECU-Software, „Architecture“, eine Methodik in der Vorgehensweise bei der Entwicklung „Methodology“ und die Festlegung von Schnittstellen von typischen Automotive-Software Teilen „Application Interfaces“. AUTOSAR schafft damit die Richtlinien um weitestgehend den gesamten Bereich der Software-Entwicklung im Fahrzeug abzudecken. So sind die Begriffe derart weitgreifend, dass man mit AUOSAR ein eigens standardisiertes Echtzeitbetriebssystem, das AUTOSAR-OS^[65], in Verbindung bringt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Themenbereiche von AUTOSAR

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Architektonischer Wechsel von AUTOSAR

Um näher auf die drei Bereiche einzugehen, sollen diese im Folgenden vorgestellt werden:

- Der architektonische Wechsel, den AUTOSAR in der Automotive-Branche herbeiführen will, wird in Abbildung 12 angedeutet. Grundgedanke ist es also die Anwendungs-Software, die die eigentliche Funktionalität bestimmt, von der verwendeten Hardware unabhängig zu machen. Dieser Teil der Software, der bereits im Unterkapitel „2.1 Software im KFZ-Steuergerät“ mit dem Begriff Applikationssoftware angesprochen wurde, ist der Kern der Innovation im Automobil. Der zweite Teil der Software, der als Plattformsoftware bezeichnet wurde, befindet sich unter der gestrichelten Linie im Bild. Er ist das Verbindungsglied der Anwendungs-Software zur Hardware. Sie wird im Allgemeinen als BSW (Basis-Software) bezeichnet und ist Kernstück der Architektur-Überlegungen des AUTOSAR Standards. Dieser Hauptgedanke der konsequenten Trennung der Software in Applikationssoftware und Basis-Software ist der Weg von AUTOSAR zu einer gewissen Unabhängigkeit der Software von der Hardware, die ihre Widerverwendbarkeit sowohl für den OEM als auch den Zulieferer steigert und Qualität, Effizienz und Sicherheit bei ihrer Entwicklung in den Vordergrund rücken soll. Es ist an dieser Stelle zu sagen, dass AUTOSAR ein elementares Bindeglied zwischen Applikations-Software und Basis-Software vorsieht, welches als Middleware fungiert: die RTE (Runtime Environment)^[66].

Der Grundansatz wirkt damit vielleicht recht einfach, weißt jedoch einen enormen Umfang auf. Es reicht sich die Vielfalt an Funktionalitäten einerseits und die unterschiedlichen Ausprägungen an verwendeten Steuergeräten andererseits bewusst zu machen und den Entwicklungsprozess in seiner Gänze zu betrachten, um nachzuvollziehen, wie weitgreifend eine solche Überlegung ist.

- Die AUTOSAR „Methodology“^[67] beschreibt die möglichen Arbeitsabläufe in der Entwicklung, von der Systemkonfiguration bis zur abschließenden Generierung einer ausführbaren Datei für ein Steuergerät. Der Entwicklungsprozess als Ganzes wird von der Methodik erfasst, von der Festlegung der gewünschten Funktionalitäten beim Systementwurf des KFZ bis zur Konfiguration der jeweiligen Steuergeräte. In einer Art Produkt-Kette werden aus den Anforderungen an das System, Applikationssoftware, RTE und die BSW Module geschaffen. In verschiedenen Aktivitäten werden mit speziellen Autosar-tools die Produkte realisiert. Für den Austausch der Produkte unter den verschiedenen Aktivitäten mit spezialisierten Werkzeugen wird ein umfassendes XML (Extensible Markup Language)-Format genutzt.

Die Methodik sieht den Austausch und die Integration von Software zwischen beteiligten Entwicklungs-Teams und Firmen vor und unterstützt diese Prozesse^[68], weist aber keine Verantwortlichkeiten und Rollen zu^[69].

Im Umgang mit der Methodology ist eine Herangehensweise mit verschiedenen Sichtweisen von großem Vorteil für das Verständnis und das Vorgehen^[70]: Diese drei Sichtweisen spiegeln auch drei in der Entwicklung abgrenzbare Bereiche wieder: Es handelt sich um eine Unterscheidung in System, ECU und Software-Komponente (SWC)^[71].

Die Begriffe „Aktivitäten“ und „Produkte“ bezeichnen die zentralen Elemente der Methodology, die größtenteils auf graphischen Notationen mit Hilfe des SPEMs (Software Process Engineering Metamodel) beruht^[72]. Von besonderer Bedeutung sind die unter dem Begriff „Guidance“ zusammengefassten Werkzeuge^[73]: AUTOSAR sieht zur Unterstützung bei verschiedenen Aktivitäten Werkzeuge vor, die der AUTOSAR-konformen Umsetzung dienen sollen. Es hat sich auf diesem Wege mittlerweile ein eigener Markt für AUTOSAR-Tools etabliert.

- Das Thema „Anwendungsschnittstellen“ lässt sich schwerer in seinen Grundzügen charakterisieren und wird erst bei einem tieferen Einstieg in die Materie im Detail relevant. Die Architektur von AUTOSAR basiert auf modularen Komponenten, deren Kommunikation untereinander über definierte Schnittstellen abläuft^[74]. Die Unterscheidung in AUTOSAR Interfaces, Standardized AUTOSAR Interfaces und Standardized Interfaces soll der Vollständigkeit halber genannt werden, wird hier aber nicht näher erläutert.

Nachdem nun die Hauptgebiete des Standards genannt wurden, soll in den folgenden Unterpunkten näher auf diese Bereiche eingegangen werden. In der Regel werden in Werken zum bearbeiteten Thema und besonders in Workshops oder Tutorien zuallererst die architektonischen Gesichtspunkte genannt. Dies liegt nahe, da die Architektur wie bereits gesagt Kernstück des Standards ist. Es ist jedoch ebenfalls sinnvoll die Methodik, die AUTOSAR anführt, anfangs zu erklären, da die Entwicklungsabläufe, die sie begleiten, erst die Schaffung der Software nach AUTOSAR erlauben und den Leitfaden für den AUTOSAR-Entwickler bilden.

3.3.1 Die AUTOSAR Methodology

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: AUTOSAR Methodology und zugehörige Sichten

Die in diesem Abschnitt genannten Informationen stammen in erster Linie aus der Spezifikation [B16]. Auch die Spezifikationen [B17] und [B18] dienen als Orientierung.

Die vermeintlich vollständigste Übersicht aus den Spezifikationen zur AUTOSAR-Methodik bietet die Abbildung 13. Sie verbildlicht nicht nur die groben Zusammenhänge der Aufgaben in der Software-Entwicklung für vernetzte KFZ-Steuergeräte mit AUTOSAR, sondern hebt zugleich drei abgrenzbare Bereiche hervor, die miteinander verzahnt sind: Die Systemkonfiguration, mit „System“ in der Abbildung gekennzeichnet, die Konfiguration der Steuergeräte, mit „ECU“ in der Abbildung. gekennzeichnet und die Implementierung der verwendeten SWCs (Software Component), mit „Component“ in der Abbildung gekennzeichnet. AUTOSAR besitzt eine eigene Fachterminologie; die wichtigsten Begriffe dieser Terminologie sollen deshalb im Rahmen dieser Arbeit wie im vorangehenden Satz durch Hervorhebung kenntlich gemacht werden.

Der letzte der drei aufgezählten Bereiche, der sich auf die SWC-Implementierung bezieht, fehlt oftmals in der Übersicht zur Methodik. Dies liegt daran, dass AUTOSAR keine Vorschriften bezüglich der Implementierung der Komponenten macht, nichts destotrotz sollte er als Kernelement erwähnt werden. Er ist ein Arbeitsschritt der mehr oder weniger parallel und unabhängig vom Rest der Methodik durchgeführt werden kann. Selbstverständlich benötigt er bestimmte Ausgangsdaten über das System wie zum Beispiel die sogenannte Component Internal Behaviour Description. Genauso benötigt man zur Vollendung eines Workflows nach der AUTOSAR-Methodik das aus diesem Bereiche anfallende Product. Eine ausführbare Datei für eine ECU ist schließlich nur mit ihrem Applikationsteil vollständig. Der Bereich Implement Component sollte daher keineswegs aus der Methodik-Übersicht ausgelassen werden.

Neben Activities, als gelbe Pfeile dargestellt, und Products, mit blauen Kästchen symbolisiert, fallen auch gestrichelte Pfeile, die sogenannten Dependencies, die Abhängigkeiten zwischen Arbeitsprodukten im Meta-Modell kennzeichnen, ins Auge. Der Begriff der Iteration ist von großer Bedeutung in der Methodology: Oftmals ist ein einziger Durchgang für eine bestimmte Aufgabe nicht genügend, da viele der Arbeitsprodukte in starker Wechselwirkung stehen und aneinander adaptiert werden müssen. Das Dateiformat XML soll den Informationsaustausch zwischen den verschiedenen Activities vereinfachen. Die Verwendung sogenannter Templates dient zur Beschreibung von System-Bestandteilen: Durch Ausfüllen der Templates mit den benötigten Informationen, wird ebenfalls ein Grundrahmen für den Workflow geschaffen. Man muss sich der Tatsache bewusst sein, dass die gezeigte Graphik nur eine Übersicht der Methodik darstellt: Schon bei einem genaueren Blick in die Spezifikation AUTOSAR_Methodology.pdf, wird deutlich, dass die einzelnen Schritte sehr komplex sind und manche Arbeitsschritte in der Übersicht unterschlagen werden

Eine übergeordnete Rolle kommt der System-Entwicklung, in der Methodik mit Configure System bezeichnet, zu, da sie die Rahmenbedingungen für die anderen Arbeitsbereiche schafft. In dieser Tätigkeit liegt die eigentliche Ingenieursaufgabe, da die System-Architektur entworfen wird. Die Abbildung 14 verdeutlicht die Grundzüge dieses Vorgangs. Er ist von grundlegender Bedeutung und sollte daher in seinen Grundzügen erklärt werden: Die gewünschte Software-Funktionalität wird in einem Netz aus einzelnen SWCs, die durch graue Kästchen in der Abbildung verkörpert werden, gebildet. Ihre Vernetzung wird entwicklungsseitig über den VBF (Virtual Functional Bus) vorgenommen, der in diesem Stadium sämtliche Kommunikationsmechanismen zwischen den einzelnen SWCs und BSW-Teilen virtuell vereint. Der Prozess der System-Konfiguration erfolgt auf Basis der folgenden Bestandteile:

- Die Gesamtheit der vernetzten SWCs mit definierten SWC-Schnittstellen. Es soll hier noch keine Abhängigkeit von der Art der Implementierung der einzelnen SWCs bestehen. In der Methodology wird dieser Bestandteil mit SWC-Descriptions bezeichnet. Auf der Abbildung umfasst er den VFB mit den angebundenen SWCs.
- Die Auswahl der benötigten ECUs, die nach Kriterien wie Prozessor, Speicher oder Ein-und Ausgänge geschieht. Dieser Teil wird in der Abbildung mit „ECU Descriptions“ bezeichnet.
- Die System-Eigenschaften wie beispielsweise vorhandene BUS-Systeme und deren Vernetzung, die unter dem Begriff „System Description“ in der Abbildung erfasst werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Methodology, „Configure System“

Zentrales Ergebnis dieses Vorgangs ist die Zuordnung der verschiedenen SWCs auf bestimmte ECUs, das sogenannte Mapping. Dieser Begriff taucht in AUTOSAR mehrmals auf, erlangt in diesem Zusammenhang aber seine Hauptbedeutung.

Einige der bereits hier genannten AUTOSAR-Strukturen wie die SWCs können noch nicht erläutert werden. Dies soll in den folgenden Unterkapiteln geschehen. Die frühzeitige Erwähnung mancher Begriffe soll helfen diese einordnen zu können. Es sei nochmal betont, dass diese Strukturen strengen Vorschriften genügen müssen, die im umfangreichen Spezifikationen-Werk von AUTOSAR zu finden sind.

Wenn man dem Verlauf der Methodology folgt, schließt sich an den vorherigen Schritt, dessen zentrales Produkt die System Configuration Description ist, ein Arbeitsschritt an, der den Übergang von der System-Ebene hin zur Steuergräte-spezifischen Sicht darstellt. Aus der System Configuration Description werden für alle ECUs jeweils ein ECU Extract of System Configuration, das notwendige Hardware-nahe Informationen für die ECU enthält, angelegt. Dieser Vorgang erfolgt ohne notwendige Konfigurationen quasi-automatisiert.

Die sich anschließende Arbeit rund um die Activity Configure ECU ist eine extrem komplexe Aufgabe. Sie benötigt wieder erheblichen Ingenieursaufwand und kann keineswegs, wie der vorherige Schritt automatisiert ablaufen. Endprodukt soll die ECU Configuration Description sein, die eine vollständige Konfiguration der zum Einsatz kommenden Hardware-Ressourcen einer ECU beinhaltet. Neben dem Produkt des vorherigen Schrittes, benötigt man hier hauptsächlich die Collection of Available SWC Implementations, welche die verschiedenen SWC-Varianten darstellt und bereits in den aller ersten Schritt der Methodology eingeflossen ist, und die BSW Module Description, in der die Parameter und die Struktur der Parameter zur Einstellung der Hardware enthalten sind. Auch wenn Details der AUTOSAR-Architektur noch nicht erläutert wurden, soll schon an dieser Stelle darauf hingewiesen werden, dass zentrales Ergebnis dieses Schrittes die Konfiguration der verschiedenen Module der BSW und der Mittelschicht zwischen BSW und Applikation, der bereits erwähnten RTE, welche die konkrete Implementierung des VFB darstellt, ist. Die Abbildung 15 ist ein überarbeiteter Auszug der Spezifikation zur Methodology. Der Schritt „Configure ECU“ wird hier absichtlich in Tiefe dargestellt, um einen detaillierten Einblick in die graphische Notation dieses Arbeitsschrittes zu gewähren. Hierbei wird die Komplexität der AUTOSAR Methodik und insbesondere dieser Activity deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Methodology, Detailansicht auf „Configure ECU“

Bemerkung: Der Übersicht halber wurden in der Abbildung folgende Kennzeichnungen vorgenommen: Die drei aufgezählten Haupt-Edukte des Schrittes „Configure ECU“ wurden grün eingerahmt, die erwähnten Konfigurationsschritte der BSW-Module und der RTE wurden jeweils orange eingerahmt, und das Hauptprodukt wurde in einem roten Rahmen dargestellt.

Als finaler Schritt, der im Gegensatz zu den anderen zeitlich eingeordnet werden kann, da er die Software mit der Hardware vereint und somit eine finale Position einnimmt, erfolgt die Generierung einer ausführbaren Datei für jedes im System enthaltene Steuergerät. Dies soll keines falls bedeuten, dass er nur einmal pro ECU erfolgen kann, schließlich können durch Funktionstest wie das Hardware-Debugging Rückschlüsse auf Konfigurationen, die vorher erfolgt sind, gezogen werden. Dieser Schritt wird als Generate Executable bezeichnet. Für die verschiedenen BSW Module wie OS, oder COM (AUTOSAR-Communication) werden mit eigenständigen Generators C-Dateien erstellt, die anschließend bei der Kompilierung zu Object-Files mitverwendet werden. Das Produkt des grundsätzlich unabhängigen Arbeitsschrittes der SWC-Implementierung, welcher am Anfang dieses Kapitels erwähnt wurde, fließt schlussendlich an dieser Stelle in den Prozess ein: Die konkreten SWC-Implementierungen, die zur jeweiligen ECU gehören, werden ebenfalls als Objekt-Files eingebunden. In einer letzten Etappe werden die verschiedenen Files verlinkt und somit das Executable z.B. in Form einer S19- oder elf-Datei erstellt. Die hier genannten Abläufe des Kompilierens und Linkens wurden bereits im Unterkapitel „2.2 Software im KFZ-Steuergerät“ erläutert. Man sollte betonen, dass es sich um mehr als ein einfaches Linken handelt: Der hoch automatisierte Prozess, der die verschiedenen Objekt-Files, welche unmittelbar einfließen, vereint, nimmt nämlich zusätzliche Informationen beispielsweise aus der „ECU Configuration Description“ auf und ist somit in gewisser Weise Intelligenter als ein gewöhnliches Linken. Der informationstechnische Prozess des Linkens bleibt gleich, allerdings kann der Umfang, der zu verbindenden Dateien konfigurationsabhängig variieren. Die Abbildung 16 veranschaulicht den Schritt, der die verschiedenen Objekt-Files unter Einbeziehung zusätzlicher Informationen aus XML-Files bindet: Das ECU Executable wird erstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Methodology, Detailansicht auf „Generate Executable“

Bemerkung: Auch auf dieser Abbildung wurden zusätzliche Hervorhebungen eingefügt. So wurde das Hauptprodukt des Schrittes „Generate Executable“, die ausführbare Datei, in rot eingerahmt. Die in einem vorherigen Schritt kompilierten Object-Files der BSW-Module wurden in blau und die der Software-Komponenten in grün eingerahmt. Kenntlich gemacht wurden auch die in den Link-Prozess miteinbezogenen XML-Dateien. Diese wurden in einem gelben Rahmen markiert. Es bleibt zu erwähnen, dass die XML-Dateien nicht tatsächlich mitgelinkt werden; sie fügen jedoch je nach Konfiguration der BSW zusätzliche Objekt-Dateien zu dem autarken Link-Prozess hinzu.

3.3.2 Die AUTOSAR Architecture

Zuallererst soll der Begriff der Architektur nochmals aufgegriffen werden. In den Unterkapiteln „2.3 Software im KFZ-Steuergerät“ und „2.4 Automotive Embedded Software Entwicklung“ wurde der Begriff schon mehrfach thematisiert, es soll an dieser Stelle jedoch noch eine Klarstellung erfolgen. Da Software nur schwer materiell zu erfassen ist, mag der Begriff der Architektur fragwürdig erscheinen, zumal die Architektur bei der Software nicht wie bei materiellen Produkten direkt am Endprodukt sichtbar wird. Für Software ist der Begriff der Architektur vor allem für die Entwicklung relevant. Die Architektur der Software ist der grundlegende Aspekt und der erste Schritt bei der Entwicklung in Richtung Erfüllung der Anforderungen. Die Entscheidungen hinsichtlich der Architektur einer Software tragen maßgeblich zu deren Qualität bei. Das Erstellen einer geeigneten Software-Architektur richtet sich nach zahlreichen Prinzipien, von denen hier exemplarisch die Lose Kopplung und der Starke Zusammenhalt erwähnt werden sollen^[75] Architektonische Überlegungen spielen sich noch oberhalb der eigentlichen Code-Implementierung ab, spiegeln sich jedoch z.B. in der Struktur der C-Projekte wieder. Auch wenn die Architektur im Endprodukt, dem Executable, wie bereits erwähnt, nicht primär sichtbar ist, so spielt sie nichtdestotrotz eine entscheidende Rolle für die Funktionsfähigkeit des in ihm enthaltenen Codes, da die richtige Architektur der erste Garant für Qualität ist.

Die Abbildung 12 am Anfang dieses Kapitels zeigt den Kerngedanken der Architektur von AUTOSAR bereits auf. Es wurde an dieser Stelle erklärt, dass eine Grundüberlegung von AUTOSAR die Trennung von Anwendungssoftware und BSW ist. Vergleichbar mit dem Vorgehen im ISO/OSI-Schichtenmodell wird in AUTOSAR eine horizontale Schichtung der Software vorgenommen^[76]. Die in der Software-Entwicklung oft angewandten Schichten-Modelle schaffen unterschiedliche Abstraktionsebenen, für die bestimmte Kommunikations-Vorschriften gelten. Abstraktion ist ein Grundsatz für die AUTOSAR-Architektur.

In AUTOSAR vollzieht die Schichtung hauptsächlich eine Gliederung von Hardware-naher Software (in den AUTOSAR-Darstellungen unten) bis hin zu immer Hardware-unabhängigerer Software (in den AUTOSAR-Darstellungen oben). Die AUTOSAR BSW unterliegt zudem einer vertikalen Gliederung, welche die Hardware-nahe Software je nach Zuständigkeit für einen bestimmten Hardware Bereich wie Speicherverwaltung oder verschiedenste BUS-Kommunikations-Mechanismen einteilt.

Die architektonische Gliederung von AUTOSAR kann sowohl auf System-Ebene als auch auf Steuergeräte-Ebene betrachtet werden. Die erste Perspektive dient in der Regel der Betrachtung der Applikationssoftware vor dem Mapping der SWCs auf konkrete Steuergeräte. In diesen Betrachtungen wird der VFB erwähnt, der für die Kommunikation der SWCs im Entwicklungsstadium verantwortlich ist und so eine Hardware-unabhängige Entwicklung der SWCs ermöglichen soll^[77]. Viel weitreichender ist der Begriff der Architektur auf Steuergeräte-Ebene: Die entsprechenden Schritte der Methodik, „Configure ECU“ und „Generate Executable“, verlangen detailliertes Verständnis für das Architektur-Konzept, das stark auf die BSW fokussiert ist. Die gezeigten Abbildungen zum Architektur-Entwurf beziehen sich in der Regel auf die ECU.

Für eine erste Betrachtung eignet sich die horizontale Schichtung der Software nach AUTOSAR. Die Abbildung 17 soll hierfür als Grundlage dienen: Die unterste Gruppe mit der Inschrift „Microcontroller“ ist kein Teil der Software, er soll lediglich die Hardware und ihren zentralen Baustein, den µC, symbolisieren. Die Hardware-Nähe der untersten Software-Schichten wird auf diese Weise hervorgehoben. Die Hauptunterteilung in Basis-Software, Middleware und Applikationssoftware ist sofort ersichtlich und im Folgenden wird diese Schichtung mit Bezugnahme auf das Dokument [B19] von unten nach oben näher erläutert:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: AUTOSAR Schichten-Architektur

- Die AUTOSAR BSW:

- Der Micro-Controller Abstraction Layer (MCAL): Er dient zur Abstraktion der Hardware-Einheiten des µC und soll höhere Schichten unabhängig vom verwendeten µC machen. Diese Schicht enthält beispielsweise µC-spezifische Treiber für Zugriffe auf Speicher, Inputs and Outputs (I/Os). Fehlende Hardware-Features werden durch entsprechende Software Module egalisiert. Beispiel für einen Software-Bestandteil des MCAL ist der ADC (Analog-Digital-Converter)^[78] -Driver
- Der ECU Abstraction Layer: Dieser steht über dem MCAL und abstrahiert von allen Komponenten, die sich in dem Steuergerät befinden. Diese Schicht bietet einheitlichen Zugriff auf Bestandteile des Steuergerätes, unabhängig davon, ob sie Bestandteil des µC selbst oder seiner Peripherie sind. Sie enthält also z.B. auch Treiber für µC-externe Einheiten. Der ECU Abstraktion Layer liefert demnach Programmier-Schnittstellen, auch API (Application Programming Interface) genannt für µC-interne und -externe Peripherie, und macht so höhere Schichten von der Steuergeräte-Hardware unabhängig. Ein Beispiel-Modul dieser Schicht ist der External EEPROM Driver. Zur Verdeutlichung der Abstraktion, die durch die Schichtung vollzogen wird, kann man hier exemplarisch vermerken, dass die Nummerierung eines digitalen Pins, die in jedem µC unterschiedlich ist und im MCAL Anwendung findet, bereits im ECU Abstraction Layer µC-unabhängig ist. Die Durchdringung der Schicht ECU Abstraction Layer in Richtung RTE rührt von der Tatsache her, dass auch direkte Kommunikationsbeziehungen zur RTE bestehen ohne auf die nächsthöhere Schicht zurückzugreifen: Ein Beispiel ist das Modul IoHwAb (I/O Hardware Abstraction).
- Der Services Layer: Dieser stellt die oberste Schicht der BSW dar und ist schon weitestgehend von der Hardware unabhängig. Er stellt das OS, das Kernelement für zeitliche Vorgänge, und diverse Hintergrunddienste, wie Netzwerkdienste, Speicherverwaltung wie z.B. das NVRAM (Non-Volatile-RAM) oder Diagnose Services für die externe Diagnose in der Werkstatt zur Verfügung. Hauptaufgabe dieser Schicht ist es somit Basisdienste für Anwendungssoftware und Basissoftware zu bieten. In der Abbildung erstreckt sich der Services Layer über die gesamte Basissoftware bis hinunter auf Hardware-Ebene, da er seine Dienste auf allen Ebenen bereitstellt und mit dem OS eine Vormachtstellung über den Rest der Software besitzt. Das OS verfügt. z.B. mittels Hardware-Counter über direkte Verknüpfungen zur Hardware; das OS arbeitet auf Basis der abstrakten OS-Ticks.
- Die Complex Drivers: Dieser Block stellt eine Ausnahme in Bezug auf die Schichtung dar. Er steht für Software zur Verfügung, die nicht nach dem Schichtenmodell aufgebaut werden kann oder soll. In der Regel kontrollieren Complex Drivers über direkten Zugriff von der RTE auf den µC spezielle Sensoren und Aktuatoren, die entweder besonderen Timing-Bedingungen unterliegen oder Ressourcen-kritisch sind: Dazu zählen beispielsweise Aufgaben des Motormanagements wie die Einspritzung. In ihnen kann zudem Firmware, deren AUTOSAR-Migration noch nicht vollendet wurde, implementiert werden^[79]. Der Aufbau der in den Complex Drivers enthalten Software fällt aus der Standardisierung heraus. Auf diese Weise bleibt allen Herstellern die Möglichkeit erhalten besonders wettbewerbs-relevante Basissoftware unterzubringen^[80]. Schließlich soll noch der Zweck genannt werden, über Complex Drivers Treiber zu implementieren, die nicht im Standard erfasst sind. Der Artikel [A19] bietet zu diesem speziellen Software-Block weitere Informationen.

Hinweis: Der Grund für die gleiche farbliche Kennzeichnung in Grün der Complex Drivers und des ECU Abstraction Layer liegt darin begründet, dass beide zur Kommunikation zwischen Hardware-nahen Komponenten und der RTE befähigt sind.

- Das Runtime Environment (RTE)^[81]: Es stellt die Laufzeitumgebung dar und hat im AUTOSAR-Konzept eine besonders wichtige Bedeutung, da sie die Komponenten des Application Layer einer ECU sowohl untereinander als auch mit der Basissoftware verbindet. Sie fungiert wie gesagt als Middleware für die Kommunikationsdienste Die RTE verkörpert zusammen mit BSW-Teilen wie dem OS oder dem AUTOSAR-COM-Modul die Implementierung des VFB für eine spezielle ECU^[82]. Die RTE kann Teilaufgaben, die im Entwicklungsprozess vom VFB übernommen wurden, an Schichten der BSW delegieren. Zusammen mit dem OS, ist die RTE z.B. für die zeitliche Aktivierung, das sogenannte Triggern, der SWCs verantwortlich. Im Zusammenhang mit dem Triggern muss der Begriff des Event erwähnt werden: Verschiedene Kategorien von Events ermöglichen unterschiedliche Aktivierungen. Über das Modul AUTOSAR COM kann die RTE z.B. die Kommunikation von SWCs zwischen zwei verschiedenen Steuergeräten ermöglichen, indem Signale über BUS-Systeme geroutet werden. Das zeitliche Verhalten dieses Kommunikationsschemas unterscheidet sich von der Kommunikation zwischen SWCs auf der gleichen ECU.
- Der Application Layer^[83]: Für die nachfolgenden Erklärungen, kann die Abbildung 18 betrachtet werden. Diese wird abschließend noch erläutert. Diese Schicht, in der die eigentliche Funktionalität der Software enthalten ist, wurde auch schon im Unterkapitel „2.2 Software im KFZ-Steuergerät“ als Gegenstück zu der Basissoftware, die auch Plattformsoftware genannt wird, vorgestellt. Sie ist für den Software-Teil vorgesehen, der die für eine Funktion zentrale Eigenschaft besitzt: Er setzt also die Funktion, die wie im ersten Kapitel erläutert als „gewollten Ursache-Wirkungs-Zusammenhang“ verstanden werden kann, um. Die Kerne der im Fahrzeug vertretenen Funktionalitäten wie z.B. ESP (Elektronisches Stabilitätsprogramm), das bereits erwähnte ACC oder die Reichweitenanzeige liegen im Application Layer. Die Basissoftware und die RTE unterstützen lediglich die Applikationssoftware, damit diese ihre Funktion erfüllt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: AUTOSAR Applikationssoftware

Architektonisch unterscheidet sich diese Software-Schicht vom Rest der AUTOSAR-Software: Bei ihr steht der Begriff der Atomic-SWC, meist einfach als SWC bezeichnet, im Vordergrund. Das Adjektiv „Atomic“ soll verdeutlichen, dass eine SWC in AUTOSAR unteilbar ist, daher immer als Einheit auf einer ECU untergebracht wird. Auch wenn der Begriff SWC und die ihm untergeordneten Begriffe nicht ausschließlich auf die Applikationssoftware beschränkt sind, haben sie für die an der Entwicklung beteiligten Personen in diesem Bereich eine Schlüsselstellung. AUTOSAR macht hinsichtlich der Größe und Komplexität einer SWC keine Einschränkungen. In der Automotive-Branche werden zum Teil hochkomplexe Funktionalitäten in einer einzigen SWC gebündelt.

Der einer SWC untergeordnete Baustein ist die Runnable Entity, kurz als Runnable bezeichnet. Sie stellt in der AUTOSAR-Architektur die kleineste funktionale Code-Einheit dar. Diese Einheit liegt in einem zeitlichen Kontext begründet: der in Ihr enthaltene Code soll in der Anwendung zusammenhängend ausgeführt werden. In der Regel muss ein Runnable einer Task aus dem OS zugeordnet sein und über ein Event aus der RTE aktiviert werden. Die Bezeichnung „Task“ ist in der Embedded Software ein wichtiger Begriff: Er soll hier vereinfacht als kleinste für einen Prozessor simultan ausführbare Einheit mit eigenem Datenraum aufgefasst werden^[84].

Neben den typischen Application SWCs unterscheidet AUTOSAR noch in Sensor SWCs und Actuator SWCs. Diese beiden SWC-Typen sind ein besonderer Bestandteil der Software: Die Sensor-SWCs dienen der Auswertung von Sensor-Signalen, während die Actuator-SWCs der Ansteuerung von Aktuatoren, oft einfach Aktoren genannt, gewidmet sind. Die spezielle Stellung dieser beiden SWC-Typen entspringt unter anderem der Vielzahl der am Markt vorhandenen Sensoren und Aktuatoren. Die Sensor-Partitionierung, also die Aufteilung der Signal-Aufbereitung zwischen einem Sensor und dem Steuergerät, kann z.B. in unterschiedlichen Integrationsstufen realisiert werden^[85]: Es ist zum Teil eine spezifische Aufbereitung der gelieferten Werte im Steuergerät notwendig. Eine eigene SWC, die solche Aufgaben übernimmt, eignet sich also, um von dem verwendeten Sensor und dessen Sensor-Signalen zu abstrahieren. Hauptcharakteristik der Sensor- und Actuator-SWC ist im Gegensatz zur Application SWC die Hardware-Nähe und somit eine gewisse Abhängigkeit von der Hardware^[86].

Ohne Vertiefung, soll an dieser Stelle schon auf die Schnittstellen der SWCs eingegangen werden: Über spezifizierte Ports mit spezifizierten Interfaces können die SWCs mit der Umwelt Daten austauschen. Dies gilt sowohl für deren Kommunikation untereinander innerhalb einer ECU, als auch mit der BSW auf demselben Steuergerät – als direktes Medium dient hier wie bereits erwähnt die RTE – und für die Kommunikation von SWCs auf unterschiedlichen ECUs untereinander, wobei diese Kommunikation über die RTE und BSW der involvierten ECUs stattfindet.

Die Abbildung 18 soll die Punkte zusammenfassen, die zum Application Layer ausgeführt wurden. Die drei Arten, Application-, Sensor-, und Actuator-SWC sind in ihr dargestellt. Jede SWC, unabhängig von ihrer Art, kann unterschiedlich viele Runnable Entities enthalten, die hier zur Übersichtlichkeit nicht dargestellt sind. Auch die zur Kommunikation dienenden Interfaces der SWCs des Application Layer, die unter die Kategorie AUTOSAR Interface fallen und die für die Kommunikationsprozesse verantwortliche RTE sind dargestellt. Die in dieser Abbildung nur unten angedeutete BSW soll nicht außer Betracht bleiben: Ihre verschiedenen Funktionen wurden mehrfach angesprochen.

Neben der gerade erläuterten horizontal abstrahierenden Schichtung, wird die AUTOSAR BSW gleichzeitig senkrecht in verschiedene Zuständigkeitsbereiche unterteilt: Die Abbildung 19 veranschaulicht diese Trennung. Oft werden die auf diese Weise separierten Bereiche mit der aus dem Gebiet der Kommunikationsprotokolle üblichen Bezeichnung Stack bezeichnet. In der Abbildung sind sie mit den aus AUTOSAR üblichen Bezeichnungen aufgezeigt. Diese Gliederung ist nirgends direkt aus den Spezifikationen zu entnehmen; vielmehr verrät die Gliederung der Spezifikationen selbst, wie sie aus der Internet Quelle [B1] des Konsortiums zu entnehmen ist, die Namen der einzelnen Stacks. Die erstellte Abbildung soll in erster Linie als Orientierung dienen: Zusammen mit der nachfolgenden Abbildung kann man die einzelnen BSW-Module nun recht einfach einem Stack zuordnen und die zugehörige Spezifikation des Moduls in AUTOSAR, beispielsweise in [B1] ausmachen, um Details zu erfahren. Die verschiedenen Namen der Stacks sind stark selbsterklärend und sie werden daher hier nicht weiter erläutert. Bis auf wenigen Ausnahmen lässt sich, die in der Abbildung erfolgte Zuweisung mit der Gliederung in AUTOSAR vereinbaren. Sonderfälle stellen z.B. das Modul DCM (Diagnostic Communication Manager) dar, das in der Spezifikation unter Diagnostic Services zu finden ist – Es wird dem Communication Stack zugeordnet -; Auch das Modul SPI (Serial Peripheral Interface) Handler Driver, das in den Spezifikationen den Peripherals zugeordnet wird, erscheint in der Abbildung 20 im Communication Stack.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: Vertikale Gliederung der AUTOSAR Schichten-Architektur

Die aus den vorherigen zwei Gliederungen gebildeten Einheiten können nochmals in sogenannte Module^[87] unterteilt werden. Diese Gliederung soll der Vollständigkeit halber in der Abbildung 20 gezeigt werden. Im MCAL wird eine zusätzliche vertikale Gliederung vorgenommen, während die Aufteilung im ECU Abstraction Layer und im Service Layer komplexer ist. Die in dieser Abbildung dargestellte Gliederung stellt zugleich, die höchst mögliche AUTOSAR-Kompatibilität der BSW-Realisierung mit dem Standard dar – AUTOSAR legt mehrerer sogenannter ICC (Implementation Conformance Classes) zur Umsetzung der BSW fest. Auf den S.130 bis 149 des Buchs [A8], erhält man einen sehr guten Überblick über die verschiedenen Modul-Gruppen und deren Funktion. Das Dokument [B19] ist die zentrale Spezifikation von AUTOSAR zum Architektur-Standard.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: AUTOSAR Architektur nach ICC3

3.3.3 Die AUTOSAR Interfaces

Der AUTOSAR-Anwender kommt vor allem auf Applikationsebene mit diesem Bereich in Berührung. Die nach der Überschrift „Der Standard AUTOSAR“ angesprochene Unterscheidung in AUTOSAR Interfaces, Standardized AUTOSAR Interfaces und Standardized Interfaces wird wie gesagt nicht weiter erläutert. Man kann sich auf den Seiten 11 und 39-54 des Dokuments [B19] und Seite 23 in [B17] nähere Informationen hierzu einholen. Der Begriff „Interfaces“ schließt auch Vorschriften hinsichtlich der in der Architektur geltenden Kommunikationsbeziehungen ein.

Im Umgang mit der Applikationssoftware auf VFB-Ebene stehen Kenntnisse zu der Kategorie der AUTOSAR Interfaces im Vordergrund. Die anderen beiden Kategorien treten in der BSW auf, und der AUTOSAR-Nutzer wird erst bei vertieftem Umgang mit AUTOSAR mit deren Details konfrontiert. Demgegenüber sind Kenntnisse über den Aufbau der BSW für alle Anwender relevant, da diese bei der Arbeit nach der AUTOSAR-Methodology, z.B. beim Schritt „Configure ECU“, fundamental sind.

Für die Gestaltung der Applikationssoftware – vorwiegend die Schritte „Configure System“ und „Implement Component“ der Methodology – sollen also in erster Linie die für AUTOSAR Interfaces relevanten Aspekte erläutert werden. Nichtsdestotrotz sind die im Anschluss gemachten Erklärungen auch für andere Interface-Arten gültig. So kann beispielsweise die Kommunikation über Standardized AUTOSAR Interfaces von einer SWC mit dem Modul ECU State Manager im Services Stack nach den gleichen Prinzipien ablaufen.

Zunächst muss der Begriff des AUTOSAR Ports erklärt werden: Ports werden als Bezugspunkte, sogenannte „Interaction Points“, zwischen SWCs definiert. Man unterscheidet grundsätzlich zwischen den Typen PPort (Provide-Port), die Elemente bereitstellen und RPort (Receive-Port), die Elemente empfangen. Erst in einem weiteren Schritt macht eine Unterscheidung in verschiedene Interfaces Sinn. Auf den Seiten 15-17 der Spezifikation [B17] wird hierauf tiefer eingegangen. Für die Kommunikation zwischen zwei SWCs, muss mindestens jeweils ein RPort mit einem PPort über einen sogenannten Connector verbunden werden. Die an einem gleichen Connector angeschlossenen Ports, werden durch das Interface, mit der Art der kommunizierten Elemente, näher spezifiziert.

In AUTOSAR werden dafür nach Typ des übertragbaren Elements folgende Interfaces unterschieden^[88]:

[...]

---

^[1] [B35]

^[2] [B38]

^[3] ESP: Elektronisches Stabilitätsprogramm

^[4] ABS: Anti-Blockier-System

^[5] Vgl. [A1], S.2, Absatz 4

^[6] Vgl. [A2], S.182, Absatz 3

^[7] Vgl. [A3], S.61, Absatz 2

^[8] Vgl. [A4], S.112 ff. und S.160 ff.

^[9] [A4]

^[10] Vgl. [A4] ,S.6, Absatz 4

^[11] [A3], S.62, Absatz 3

^[12] [A1], S.2

^[13] Vgl. [B2]

^[14] Vgl. [A3], S.64, Bild 3.2

^[15] Vgl. [A1], S.7, Absatz 1

^[16] [A6]

^[17] Vgl. [A3], S.63

^[18] Vgl. [A1], S.15

^[19] Vgl. [A5]

^[20] Vgl. [A15], S.2, Absatz 3

^[21] [A4]

^[22] [A3]

^[23] Vgl. [B15]

^[24] Vgl. [A12], S.5

^[25] [A13]

^[26] Vgl. [A9], S.177 ff.

^[27] Vgl. [A1], S.60, Absatz 3

^[28] [A3], S.35, Absatz 2

^[29] [B12]

^[30] Vgl. [A3], S.61, Absatz 1

^[31] Vgl. [A9], S.169, Absatz 3

^[32] [A7]

^[33] [A7], S.1

^[34] [B13]

^[35] Vgl. [A9], S165 und S.180 ff.

^[36] [B14]

^[37] Vgl. [A1], S.19 und [A3], S.68

^[38] [B11]

^[39] [B8]

^[40] Vgl. [A1], S20/21

^[41] Vgl. [A1], Kap. 6.2

^[42] Vgl. [A12], S.33

^[43] Vgl. [A16]

^[44] Vgl. [A1], S.26

^[45] Vgl. [A8], S. 60

^[46] Vgl. [A1], Kap. 1.4.2.3 und [A8], S.38, Absatz 6/7

^[47] Vgl. [A7], S.3, Absatz 3

^[48] Vgl. [A8], S.47, Absatz 2, 3

^[49] [B3]

^[50] [A8], S.51/52

^[51] [B3]

^[52] Information, die aus einer direkten Nachfrage bei AUTOSAR stammt.

^[53] [B3]

^[54] [A9], S.169, Absatz 3

^[55] Vgl. [B4]

^[56] [A10]

^[57] Vgl. [B5]

^[58] Vgl [A8]

^[59] [B7]

^[60] [B9]

^[61] [A8], S.1, Absatz 5

^[62] Vgl. [A11]

^[63] Vgl. [B10]

^[64] [B3], S.2, Absatz 3

^[65] [A3], S.59, ff.

^[66] Es soll hier „die RTE“ als Bezeichnung für und in Anlehnung an „die Laufzeitumgebung“ genutzt werden.

^[67] Für den gesamten Absatz: Vgl. [A18], S.8/9, S.18-22

^[68] Vgl. [A8], S.49, Absatz 3

^[69] Vgl. [B16], S.5, Absatz 3

^[70] Vgl. [B16], S.76

^[71] Vgl. [B17], S.8

^[72] Vgl. [B16], S.6/7

^[73] Vgl. [B16], S.7

^[74] Vgl. [A18], S.10/11

^[75] Vgl. [A8], S.26-34

^[76] Vgl. [A1], S.165, Absatz 3 und S.87, Bild 2-49

^[77] Vgl. [B18], S.13, Absatz 6

^[78] Gleichbedeutend mit ADU

^[79] Vgl. [B20], S.5, Absatz 3

^[80] Vgl. [B20], S.5, Absatz 3

^[81] Es wurde vorwiegend Bezug auf [B21] genommen.

^[82] Vgl. [B21], S.58/59

^[83] Es wurde vorwiegend Bezug auf [B22] genommen.

^[84] Vgl. [A3], S.35/36

^[85] Vgl. [A17], S.21 ff.

^[86] Vgl. [B19], S.38

^[87] [B19], S.81

^[88] Vgl. [B17], S.13