Systems Modelling Language Automotive Open System...

SE Intelligent Vehicular Technology

Institut für Informatik-Systeme

Univ.-Prof. Dr.-Ing. Kyamakya Kyandoghere

SS 2006

Systems Modelling Language &

Automotive Open System Architecture

Silvia Berlinger Mat.Nr.: 0160153 E-Mail: [email protected] Gottfried Weiß Mat.Nr.: 0160040 E-Mail: [email protected]

mailto:[email protected]


1. Einleitung Dieses Dokument soll Modellierungsstandards für Automotive-Anwendungen beschreiben. Der aktuelle Status sieht folgendermaßen aus: Seit Juli 2005 wurde die UML 2.0 von der OMG (Object Management Group) verabschiedet, weiters wird in der AUTOSAR Organisation daran gearbeitet, ein UML Profil für AUTOSAR entwickelt, damit das AUTOSAR Metamodell auf Basis der UML 2.0 genutzt werden kann, und zu guter Letzt wird an der so genannten SysML (Systems Modelling Language) gearbeitet, die ebenfalls auf der UML 2.0 basiert. Nun geht es darum, wie diese Ansätze verbunden werden können. [1] Wir werden hier die Sysml mit ihren Tools und AUTOSAR etwas näher beschreiben.

2. SySML Da die UML (Unified Modelling Language) softwarezentriert ist und es mit ihr nicht möglich ist Zusammenhänge zwischen Soft- und Hardware darzustellen, wurde die SysML (Systems Modelling Language) von der OMG (Object Management Group) als Erweiterung der UML 2.0 eingeführt. Die Erweiterung der UML sieht so aus, dass eine Kombination von hierarchischen Strukturinformationen mit objektorientierten Netzwerkstrukturen, d.h. eine Erweiterung um die funktionale Sicht, durchgeführt wurde. Dies bedeutet eine Integration von Hardware, Software, Daten, Personal, Prozeduren und Einrichtungen bezüglich der Modellierungsmöglichkeiten. Das Ziel der SysML wurde wie folgt definiert: Goal is to provide a „standard modelling language for systems engineering to analyse, specify, design and verify complex systems, intended to enhance systems engineering information amongst tools, and help bridge the semantic gap between systems, software and other engineering desciplines“ (SysML, 2003) Da die SysML aus der UML entstanden ist bzw. es in Zukunft sicher immer wieder neue Erweiterungen geben wird, sehen wir uns zunächst einmal die Gemeinsamkeiten der beiden Modellierungssprachen an. Die folgende Grafik soll die Verwandtschaft der beiden Sprachen deutlicher machen.

Berlinger, Weiß Seite 2 von 39

Abbildung 1: UML und SySML

Die SysML besitzt Diagrammtypen, die auch die UML 2.0 in dieser Art verwendet, aber die SysML hat noch zusätzlich Diagrammtypen, die Erweiterungen zur UML darstellen und in der UML in dieser Form nicht zu finden sind. Natürlich hat auch die UML 2.0 Diagrammtypen, die von der SysML nicht verwendet werden, da diese für die System Modellierung nicht notwendig bzw. unbrauchbar sind.

Abbildung 2: SysML Diagrammtypen [1]

Durch die SysML sollen, wie oben erwähnt, funktionsorientierte Modellanteile dargestellt warden können. Dies ist vor allem für das Systems Engineering von großer Bedeutung. Abbildung 2 zeigt die Vielfalt der SysML Diagramme. Hier sieht man, dass der Sprachumfang der UML 2.0 nicht nur erweitert, sondern auch um nicht notwendige Sichten reduziert wird. Bei den Ergänzungen soll es einerseits möglich sein, Anforderungen direkt modellieren und mit Systemartefakten verbinden zu können andererseits werden auch funktionsorientierte Sichten definiert. Die funktionsorientierten Modellelemente werden in Blockdefinitionsdiagrammen, internen Blockdiagrammen und Constraint Diagrammen dargestellt. Auch kontinuierliche Flüsse, die


das Aktivitätsdiagramm beinhaltet, sind ein wichtiger Bestandteil für die funktionsorientierte Modellierung. Abbildung 3 zeigt ein Anforderungsdiagramm der SysML. Hier geht es um eine Pumpe und den Wassertransfer. Man kann hier deutlich erkennen, dass Systemanforderungen modelliert wurden. Der Block mit den Systems Requirements zeigt den Wasser Transfer und eine Beschreibung vom Ziel. Weiters werden Bestandteile zur Anforderungsanalyse, wie die „Customer Brochure“ modelliert. Auch die Pumpe, die für den Vorgang des Wassertransfers notwendig ist, wird in Form eines Blockes modelliert und auch der Zusammenhang zum Wasser wird dargestellt. Die dunkelgrünen Blöcke stellen die Anforderungen bzw. Ziele des Vorgangs dar und die türkisen Blöcke zeigen die Systeme, die zur Erfüllung dieser Anforderungen notwendig sind und in welchem Zusammenhang sie stehen. Auch ein Testfall ist in diesem Modell integriert worden, sodass auch auf Tests nicht vergessen werden kann.

Abbildung 3: Anforderungsdiagramm [1]

Abbildung 4 zeigt die Blockdefinition der Pumpe selbst. Diese Pumpe war in obigem Diagramm nur ein Teil des Diagramms. Hier ist die Blockdefinition der Pumpe genau modelliert.


Abbildung 4: Blockdefinition einer Pumpe [1]

Gehen wir noch eine Stufe weiter ins Detail, so ist es möglich, ein internes Blockdiagramm der Pumpe mit SysML zu modellieren, das in Abbildung 5 gezeigt wird. Hier sieht man die genauen Abläufe des Pumpvorganges.

Abbildung 5: Detailliertes internes Blockdiagramm [1]

Und last but not least ist es in der SysML natürlich auch möglich, die Aktivitäten der Pumpe zu modellieren. Abbildung 6 zeigt diese Aktivitäten.


Abbildung 6: Die Aktivität einer Pumpe [1]

Nun wollen wir noch kurz die Verbindung von AUTOSAR-SW-C’s und Anforderungsmodellierung ansehen. Das folgende Diagramm soll die Kombination der Metamodelle zeigen:


Abbildung 7: Kombination der Metamodelle [1]

Wie man in dieser Abbildung gut erkennen kann, hängen alle Erweiterungen zur Systems Engineering Modellierungs-Sprache mit der UML 2.0 zusammen, welche wiederum von einer etwas älteren Modellierungssprache abstammt – der MOF. Die SysML ist ein Meta-Modell der UML 2.0 genauso wie AUTOSAR. Und beide Meta-Modelle besitzen ein Profile, das eine spezifische Model-Library darstellt. Auch ein „Automotive domain-spezific Model“ ist Teil von beiden Meta-Modellen, das Re-Use bei den Profiles betreibt. Was bedeutet dies nun? Die UML 2.0 und ihr generisches Erweiterungskonzept besitzt die Flexibilität für eine Darstellung von Automotiver Modellierung. Das AUTOSAR UML-Profil soll die domänenspezifischen Sichten auf Basis der UML 2.0 zeigen. SysML betrachtet die Systems-Engineering-Sicht und ARTiSAN wird beide Erweiterungen mittels Ergonomic Profiling implementieren.


3. Tools Nun wollen wir zu den Tools kommen, die SysML bereits unterstützen. Dies sind vor allem:

• ASCET von ETAS • Matlab/Simulink von The Mathworks • Integrationsplattform Exite der Extessy AG • Rhapsody 6.2 (http://www.ilogix.com/sublevel.aspx?id=692 ) • Enterprise Architect (http://www.sparxsystems.com.au/)

Im Folgenden werden wir diese Tools vorstellen und vergleichen.

3.1. ASCET „ASCET V5.0 ist die flexibel und universell einsetzbare Produktfamilie für die Funktions- und Softwareentwicklung von Embedded Systems in der Kfz-Elektronik“ [2] ASCET-Werkzeuge unterstützen

• das Modellieren, • die Simulation, • das Rapid-Prototyping und • die Codegenerierung von Embedded Software im Automobil

Abbildung 8: ASCET-Produktfamilie [2]

ASCET V5.0 besitzt einzelne Komponenten, die auf spezielle Kundenanforderungen zugeschnitten sind. Abbildung 8 zeigt die ASCET-Produktfamilie, die aus den Grundmodulen ASCET-MD (Modeling & Design), ASCET-RP (Rapid Prototyping) und ASCET-SE (Software Engineering) besteht. Diese Grundmodule können auch noch in beliebiger Kombination erweitert werden. Z.B. besteht ein Modul zur Anbindung an MATLAB®/Simulink®, das


http://www.ilogix.com/sublevel.aspx?id=692

http://www.sparxsystems.com.au/

MATLAB® Integration Package (ASCET-MIP). Weiters gibt es ein Add-On zu ASCET-MD und zu ASCET-RP. Die Werkzeuge sollen die Produktivität durch Verbesserung der Qualität und Verminderung der Entwicklungsrisiken und –kosten steigern. Weiters ermöglichen sie eine effiziente Softwareentwicklung. Ingenieure können sich mit Hilfe dieses Tools bzw. der Werkzeuge dieses Tools auf folgendes konzentrieren:

• „Fokussierung auf die physikalischen Beschaffenheiten des eingebetteten Steuersystems

• Abstrakter und einfacher Entwurf des Steuergeräts • Testen und Verbessern des Steuergeräts, um Produktionscode automatisch

generieren zu können • Sofortiges Validieren eines Entwurfs in einer Rapid-Prototyping-Umgebung • Generieren von sicherem, deterministischem und effizientem C-Code, der die

Anforderungen an Seriencode (hinsichtlich Speicherbedarf, Ausführungszeit und Echtzeitfähigkeit) erfüllt“ [2]

Weitere Vorteile, die dieses Produkt mit sich bringen sind laut Herausgeber:

• „Wiederverwendbarkeit und Austauschbarkeit • Eindeutige Spezifikationen • Flexibilität • Zuverlässigkeit und Sicherheit • Benutzerfreundlichkeit“ [2]

Im Folgenden werden die wichtigsten Module beschrieben. Abbildung 9 zeigt den ASCET-MD Teil des Tools. Es stehen Blockdiagramme, Zustandsautomaten, Konditionstabellen, Boolsche Tabellen oder textuellin den Hochsprachen ESDL oder C zur Modellierung zur Verfügung. Die Modellarchitektur ist objektbasiert und ermöglicht flexibles Kombinieren von Modellkomponenten, die nach deren Definition in unterschiedlichen Projekten verwendet werden können.


Abbildung 9: ASCET-MD (Modellierung und Design) [2]

Es wird sogar eine Reihe von Import- und Exportfunktionen auf allen Hierarchieebenen bereitgestellt. Einige Funktionen (z.B. die Visualisierung von Abhängigkeiten) von ASCET-MD helfen dem Anwender, sich auf das Wesentliche zu konzentrieren. Es werden dem Anwender folgende Funktionalitäten zur Verfügung gestellt:

• „Blockdiagramme • Zustandsautomaten • Betriebssystemspezifikation • Dokumentengenerator • Experimentierumgebung • Integrierter Codegenrator für Fließkomma- und Festkomma-Arithmetik“ [2]

Abbildung 10 zeigt ASCET-RP (Rapid Prototyping). Dieses Rapid-Prototyping wird durch die Integration von der ETAS ES1000.2 und ES1000.3-Experimentalhardware ermöglicht.


Abbildung 10: ASCET-RP (Rapid Prototyping) [2]

Dieser Teil von ASCET kann Echtzeitanforderungen erfüllen, indem es die Spezifikation des Zeitverhaltens der Modelle unterstützt. Es enthält außerdem Erweiterungen für homogene Integration von Compiler- und Linker-Aufrufe und den ERCOSEK Betriebssystemkernel für Experimentalsysteme. Weitere Funktionalitäten:

• I/O-Editor zum Management von Hardware- und I/O-Konfiguration • Online Model Viewer zum Debuggen der Modelle während eines laufenden

Experimentes • Add-On INCA-EIP für das Mess- und Verstellsystem INCA (Zugriff auf die

Experimentalhardware) [2] Abbildung 11 zeigt ASCET-SE (Software Engineering).


Abbildung 11: ASCET-SE (Software Engineering) [2]

Hier geht es darum, die Entwicklung von Embedded Software zu erleichtern. Dazu gehört z.B. die Generierung von sicherem, optimiertem und effizientem C-Code. ASCET-SE führt den Benutzer durch alle Aspekte der Implementierung wie Speicherlayout, Datentypen und –formeln, die Konfiguration des OSEK-Betriebssystems oder compilerspezifische Optimierungsfunktionen. “ASCET-SE unterstützt gegenwärtig die Codegenerierung für sieben Mikrokontroller und RTA-OSEK 4.0:

• ASCET-SE für Infineon C16x - Codegenerator für Infineon C16x • ASCET-SE für Motorola MPC5xx - Codegenerator für Motorola MPC5xx • ASCET-SE für TI TMS470 - Codegenerator für Texas Instruments TMS470 • ASCET-SE für NEC V85x - Codegenerator für NEC V85x • ASCET-SE für Motorola M68HC12 - Codegenerator für Motorola M68HC12 • ASCET-SE für Hitachi SH7055F - Codegenerator für Hitachi SH7055F • ASCET-SE für Infineon TriCore - Codegenerator für Infineon TriCore • ASCET-SE für RTA-OSEK - Codegenerator für von RTA-OSEK V4.0 unterstützte

Mikrocontroller ASCET-SE unterstützt alle OSEK-konformen Betriebssysteme und bietet eine besonders nahtlose Integration der Werkzeugfamilie RTA-OSEK. ASCET-SE erzeugt Beschreibungsdaten nach dem ASAM-2MC Standard.“ [2]

Es ist bei diesem Tool sogar die Zertifizierung des ASCET-SE Codegenerators gemäß des Sicherheitsstandards ISO 61508 für jedes unterstützte Steuergerät möglich, falls dies vom Kunden gewünscht wird.


Abbildung 12 zeigt die MATLAB Erweiterung ASCET-MIP (MATLAB® Integration Package).

Abbildung 12: ASCET-MIP (MATLAB® Integration Package) [2]

ASCET-MIP ermöglicht eine Integration der Funktionalitäten von MATLAB in ASCET. Dies bedeutet, dass die umfassenden Analyse- und Simulationsfunktionen von MATLAB®/Simulink® in ASCET verwendet werden können. Weiters ergänzt MATLAB®/Simulink® die Funktionen von ASCET-MD und erweitert damit die Nutzbarkeit im Entwicklungsprozess. Es ist auch möglich die MATLAB®/Simulink® Schnittstelle mit ASCET-MD und ASCET-RP zu kombinieren. Weitere Funktionalitäten bei der Kombination von ASCET und MATLAB®/Simulink®:

• Datenaustausch • Funktionsaufrufe • Co-Simulationen mit ASCET und MATLAB®/Simulink® • Integration von MATLAB®/Simulink®-Modellen zum Echtzeit-Prototyping


3.2. MATLAB MATLAB ist kein Modellierungstool im herkömmlichen Sinn, es ist vielmehr eine hochentwickelte Sprache für technische Berechnungen und eine interaktive Umgebung für Algorithmenentwicklung, Visualisierung und Analyse von Daten und numerischen Berechnungen. Es lassen sich technische Probleme mit MATLAB besser lösen als mit Programmiersprachen wie z.B. C, C++ oder Fortran. Die Anwendungsgebiete von MATLAB erstrecken sich über:

• Signal- und Bildverarbeitung • Kommunikationssysteme • Steuerungsentwurf • Tests • Messungen • Finanzmodellierung und –analyse • rechenintensive biologische Probleme

Es werden auch ergänzende Toolboxen zur Verfügung gestellt wie z.B. separat erhältliche Sammlungen spezieller MATLAB-Funktionen. Weiters wird die Möglichkeit zur Dokumentation angeboten und diese Dokumentation mit anderen zu teilen. Es lässt sich auch hervorragend in andere Programmiersprachen und Anwendungen integrieren und weitergeben. Abbildung 13 zeigt einen Screenshot dieses Tools.

Abbildung 13: MATLAB Screenshot [3]

Hauptmerkmale von MATLAB:

• „Hochentwickelte Programmiersprache für wissenschaftlich-technische Berechnungen

• Entwicklungsumgebung zur Verwaltung von Code, Dateien und Daten • Interaktive Werkzeuge für iterative Untersuchungen, Entwürfe und die Lösung von

Problemen


• Mathematische Funktionen für die lineare Algebra, die Statistik, die Fourieranalyse, das Filtern, Optimieren und die numerische Integration

• 2D- und 3D-Grafikfunktionen zur Visualisierung von Daten • Tools zur Erstellung eigener grafischer Benutzeroberflächen • Funktionen zur Integration auf MATLAB basierender Algorithmen in externe

Anwendungen und Sprachen wie C/C++, Fortran, Java, COM und Microsoft Excel „Die MATLAB-Entwicklungsumgebung ermöglicht den Algorithmenentwurf, die interaktive Datenanalyse, die Anzeige von Datenfiles und die Projektverwaltung.“[3]


3.3. Simulink Simulink® 6.4.1 ist zum Entwurf und zur Simulation zeitkontinuierlicher und zeitdiskreter Systeme gedacht. Es ist eine Plattform für die Mehrdomänensimulation und die Modell-basierte Entwicklung dynamischer Systeme. Es besitzt eine interaktive Grafikumgebung und individuell erweiterbare Blockbibliotheken. Einsatzgebiete dieses Tools:

• Entwurf • Simulation • Implementierung und • Tests von Regelungs-, Signalverarbeitungs- und Kommunikationssystemen


Simulink bietet ergänzende Produkte zur Simulink-Umgebung, um Werkzeuge für spezielle Modellierungs- und Entwicklungsaufgaben für die Codegenerierung, die Implementierung, das Testen und die Validierung von Algorithmen verwirklichen zu können. Simulink ist mit MATLAB nahtlos verbunden, da es ein weiteres Produkt aus derselben Familie ist. Dadurch ist ein direkter Zugriff auf ein umfassendes Spektrum von Werkzeugen, die in MATLAB zur Verfügung stehen auch in Simulink möglich und umgekehrt. Die Hauptmerkmale von Simulink sind:

• „Breit aufgestellte und frei erweiterbare Bibliotheken vorgefertigter Blöcke • Interaktiver Grafikeditor zum Erstellen und Verwalten intuitiver Blockdiagramme • Verwaltung komplexer Entwürfe durch hierarchische Segmentierung von Modellen in

einzelne Komponenten • Model Explorer zum Einrichten, Konfigurieren und Durchsuchen aller Signale,

Parameter und Eigenschaften eines Modells sowie zum Navigieren in diesen • Schnittstellen zu anderen Simulationsprogrammen sowie Fähigkeit zur Integration

von handgeschriebenem Code und von MATLAB-Algorithmen • Interaktive oder im Batch-Modus abgearbeitete Simulationen zeitvarianter Systeme

mit fester oder variabler Schrittweite • Bewertung des Modellverhaltens mit Hilfe von Funktionen zur interaktiven Definition

von Eingabewerten und zum Anzeigen der resultierenden Ausgabewerte • Grafischer Debugger zur eingehenden Untersuchung von Simulationsergebnissen

und zur Diagnose der Ursachen unerwarteten Verhaltens • Voller Zugriff auf MATLAB zum Analysieren und Visualisieren von Daten, Entwickeln

grafischer Benutzeroberflächen und Definieren von Modelldaten und -parametern • Analyse- und Diagnose-Werkzeuge zur Sicherstellung der Modellkonsistenz und zur

Ermittlung von Fehlern“ [4]


3.4. Rhapsody Rhapsody ist ein Eclipse plug-in, das Designer und Entwicklern helfen soll, die modellgetriebene Entwicklung (MDD) zu erleichtern. Rhapsody 6.2 Hauptmerkmale und Funktionalitäten:

• “Upgraded Rhapsody/ Wind River Workbench integration • Graphical differencing of all diagrams • Easier to use features dialog • IBM Rational Rose model import enhancements • Multiple selection in the model browser • Code generation refinements • Enhanced reverse engineering • Improved populate diagram capability • Helper triggers • Webify support for Mozilla / Firefox • Enhanced SCC CM options“ [5]

Abbildung 14: Rhapsody Diagramme [5]

Ein paar Screenshots sollen zeigen, wie mächtig dieses Plug-in ist.


Abbildung 15: Rhapsody Environment [5]

Abbildung 16: Version Control [5]


Abbildung 17: CM Check in and Check out [5]

Abbildung 18: Rhapsody Gateway [5]


Abbildung 19: Simulation and Dynamic Analysis [5]


3.5. Enterprise Architect Enterprise Architect ist ein Tool, das in einer Trial Version unter … downzuloaden ist. Es ist vom Design her dem MS Visio ziemlich ähnlich, aber unterstützt neben vielen anderen Modellierungssprachen auch die SysML. Funktionalitäten:

• UML 2.0 Notation • Alle UML-Diagramme • C++, Java, C’, VB, VB.NET, Delphi, DDL support • UML Profiles • Benutzerdefinhierte Patterns • Automatisiertes Erzeugen von HTML und RTF Dokumentation • XMI 1.0 und 1.1 Export/Import • Data Modelling und database engineering • Relationsship Matrix für traceabliity und dependency management • Multi-user fähig • Projekt-Aufwandsschätzung mit Hilfe von Use Case Metrics • Testing, issues, changes, glossary, resourcing • Automation Schnittstellt für Standard Script Sprachen wie VB • Replikationsfunktionalität (.EAP files) • Grafik-Unterstützung über Stereotypes/Metafiles und importierte Bildformate (jpg,

png, metafile, etc.) • CSV export/import • Geringe Systemanforderungen, starke Performance, intuitive Benutzerführung [7] • MDA Transformation support • Forward and Reverse Code Engineering • Plug-ins to link EA to Visual Studio.NET or Eclipse • Support for "pluggable technologies" using MDG (Model Driven Generation)

Technologies • Database modeling • Ability to Share models in different ways • XML Schema Support • Reverse Engineer binary files from Java and .NET • Import/Export of Models in XML format • Support for System status information • WSDL Engineering Support [6] • …

Wie man an dieser Liste an Funktionalitäten unschwer erkennen kann, ist dieses Tool ziemlich mächtig und vor allem userfreundlich. Es werden z.B. alle 13 UML 2.0 Diagramme unterstützt (und mehr): “Structural Diagrams: • Class • Object • Composite • Package • Component • Deployment


Behavioral Diagrams: • Use Case • Communication • Sequence • Interaction Overview • Activity • State • Timing Extended: • Analysis (simple activity) • Custom (for requirements, change, UI)” [6] Der Enterprise Architect hilft dem user Komplexität zu managen, unterstützt eine sehr große Menge von Modellen, Versionskontrolle mit CVS oder SCC, hat eine explorerähnliche Oberfläche uvm. Vor allem die Plugin-Möglichkeiten und die Diff-Funktionalität sind zwei von vielen Funktionalitäten, die dieses Tool anbietet. Im Folgenden zeigen wire in paar Screenshots dieses Tools, um dessen Userfreundlichkeit und umfangreichen Funktionalitäten besser zu zeigen:

Abbildung 20: Help Screen [6]


Abbildung 21: EA – System Architect [6]

Abbildung 22: EA Desktop [6]


Abbildung 23: EA UML Diagramms [6]


Abbildung 24: Compare Utility [6]

Abbildung 25: Alternate Images [6]


Abbildung 26: Code Editing in EA [6]

Abbildung 27: Online Help [6]


Abbildung 28: MDA Style Transforms [6]

Abbildung 29: Relationship Matrix [6]


Abbildung 30: RTF Template Editor [6]


Abbildung 31: Tagged Values [6]

Abbildung 32: Iconix Layout [6]


Alles in allem sind all diese Tools, die wir in diesem Dokument beschrieben haben, teilweise sehr spezifische, aber auch sehr umfangreiche Werkzeuge, die sich jetzt schon mit der SysML und vielen anderen Modellierungssprachen auseinandersetzen und diese mäßig bis sehr gut unterstützen. Mein persönlicher Favorit ist der Enterprise Architect, da dieser gratis zum Download zur Verfügung steht – zwar nur in einer Trial Version von 30 Tagen, aber besser als nichts. Außerdem bekommt man dadurch die Möglichkeit, sich ein Tool genauer anzusehen, ob es das richtige ist, für die Anforderungen, die man selbst bzw. ein Unternehmen hat, ohne dieses Produkt gleich kaufen zu müssen.


4. AUTOSAR Die Autohersteller und ihre Zulieferer werden mit immer höheren Ansprüchen von Seiten der Kunden und der Gesetzgeber konfrontiert, beispielsweise auf den Gebieten von Komfort, Umweltschutz und Sicherheit bei Unfällen. Der verstärkte Einsatz von Elektronik in den Automobilen ist bei vielen dieser Anforderungen die einzige Möglichkeit, die Ansprüche zu erfüllen. Über den vermehrten Einbau von elektronischen Komponenten in Automobilen gibt es eine große Anzahl an Untersuchungen verschiedener Beratungsunternehmen. Hier soll als Beispiel ein Artikel von Mercer Management Consulting zitiert werden: Laut Mercer wird die Verwendung von elektronischen Komponenten in Automobilen bis zum Jahr 2015 um 150 % wachsen, ausgehend vom Stand des Jahres 2004. Dadurch wird der Markt der elektronischen Komponenten im Automobilbau einen Gesamtwert von 316 Milliarden Euro repräsentieren, wobei hier sowohl Hardware als auch Software enthalten sind. In einem durchschnittlichen Automobil werden elektronische Komponenten im Wert von 4.150 € verbaut sein. Im Jahr 2004 lag der durchschnittliche Wert der Elektronik noch bei 2.220 €. [8] Durch die Zunahme der Fahrzeugelektronik in Anzahl, Funktionsumfang und Vernetzungsgrad steigt die Komplexität der Elektroniksysteme – und der Elektriksysteme – rapide an, womit sich diese Komplexität nur noch mit großem Aufwand beherrschen lässt. [9] Die Schwierigkeiten mit dieser Komplexität lassen sich in den aktuellen Pannenstatistiken ablesen. Die ADAC-Pannenstatistik für das Jahr 2005 (Abbildung 33) zeigt deutlich, dass die Elektrik mit 35 % die häufigste Pannenursache darstellt, und auch die meisten anderen pannenauslösenden Baugruppen beinhalten Bauteile der Fahrzeugelektronik, sodass auch dort vermutet werden kann, dass es Fälle gibt, in denen die entsprechende Fahrzeugelektronik oder die baugruppenspezifische Software in die Panne verwickelt ist.

Abbildung 33: Verteilung der Pannen 2005, ADAC Pannenstatistik 2005 [10]

Das Fehlerproblem wird dadurch verschärft, dass es auf dem Fahrzeugmarkt viele unterschiedliche Implementierungen ein und derselben Funktion gibt, die oft unter Zeitdruck entwickelt und daher nicht ausreichend getestet wurden. Diese Proprietät der einzelnen Komponenten bedingt durch die wiederholte Neuentwicklung auch hohe Kosten. Eine Möglichkeit, sowohl die Entwicklungskosten pro Fahrzeugmodell als auch die Verlässlichkeit von Elektronik und Software zu senken, ist die Wiederverwendung von einmal entwickelten


Komponenten. [11] Einen besonderen Ansatz verfolgt dabei das AUTOSAR-Projekt, welches im restlichen Artikel kurz vorgestellt werden soll.

4.1. Ziele des AUTOSAR-Projekts AUTOSAR ist die Abkürzung für AUTomotive Open System ARchitecture und das Projekt beschäftigt sich damit, die Zusammenarbeit einzelner Unternehmen auf dem Gebiet der Autoelektronik und Software zu verwirklichen. Dabei soll einerseits eine gemeinsame Architektur für Automobilelektronik geschaffen werden und ihre Grundfunktionen so spezifiziert und teilweise auch implementiert werden, dass sie von allen Mitgliedern übernommen und in allen Fahrzeugen eingesetzt werden kann, andererseits soll der Wettbewerb und die Innovation auf dem Gebiet der einzelnen (Anwendungs-)Funktionen nicht gestört oder gar unterbunden werden. [12] Konkret ist es somit Ziel des AUTOSAR-Projekts, ein verlässlicheres Gesamtsystem aus Software und Hardware zu entwickeln, und das kostensparender als bisher. Dieses Ziel soll softwareseitig durch die Erstellung einer gemeinsamen Basissoftware, standardisierter Funktionsinterfaces und globaler Methoden zur Softwareintegration erreicht werden. Die im Projekt identifizierten Teilziele bezüglich des Gesamtsystems sind die folgenden:

Einhaltung von Verfügbarkeits- und Sicherheitsrequirements Nutzbarmachung von hardwareseitiger Redundanz Skalierbarkeit auf verschiedene Fahrzeuge und Plattformen Implementierung und Standardisierung der Basissoftware Modularer Aufbau des Gesamtsystems und fahrzeugweite Übertragbarkeit von

Funktionen über ein Netzwerk Integration von Modulen verschiedener Hersteller Wartbarkeit über den ganzen Produktlebenszyklus Vermehrte Benützung von „Commercial of the shelf“-Hardware und -Software Software-Updates und –Upgrades über die gesamte Lebensdauer des Fahrzeugs

hinweg [12] Weil das Projekt noch im Laufen ist, steht nicht fest, ob und in welchem Ausmaß diese Ziele erreicht werden können. Das Faktum, dass viele bedeutende Vertreter der Automobilbranche in das AUTOSAR-Projekt involviert sind, kann als Indiz dafür gewertet werden, dass die Chance besteht, dass die Projektergebnisse zukünftig in der Produktion von Fahrzeugen umgesetzt wird.

4.2. Mitglieder des AUTOSAR-Projekts Das AUTOSAR-Projekt wird von einer Arbeitsgruppe durchgeführt, in welcher verschiedene Automobilhersteller und Zulieferer vertreten sind. Die Gruppe ist aus fünf verschiedenen Mitgliederschichten aufgebaut, die sich im Grad der Involvierung in das Projekt im Sinne von Mitbestimmungs- und Nutzungsrechten und zu erfüllenden Leistungen unterscheiden. Diese Unterguppen sind die Core Partner, Premium Members, Associate Members, Development Members und Attendees (einfache Teilnehmer). Die Gruppe der Core Partner ist der Kern des AUTOSAR-Projekts und besteht aus zehn in der Branche einflussreichen Mitgliedern. Diese sind die BMW-Group, Bosch, Continental, Daimler Chrysler, die Ford Motor Company, Opel, PSA Peugeot Citroёn, Siemens VDO, Toyota Motor Corporation und die Volkswagen AG.


Die Gruppe der Premium Members besteht momentan (Juli 2006) aus 51 Mitgliedern. Beispielsweise sind hier die Automobilhersteller FIAT, Honda, Hyunday-Kia Motors, Mazda, Nissan, Porsche, Renault und Volvo vertreten, aber auch die Zulieferer Delphi Corporation, Fujitsu, IBM, Infineon, Magna, NEC und Philips. Diese Premium Members haben beispielsweise das Recht auf Benützung der Ergebnisse des AUTOSAR-Projekts ohne zusätzliche Lizenzkosten sowie Zugang zu allen aktuellen Informationen und Spezifikationen und die Pflicht, entsprechendes Personal zur Arbeit in den Projektgruppen zur Verfügung zu stellen. Mitarbeiter eines Premium Members dürfen auch Arbeitsgruppen leiten. Die Gruppe der Associate Members besteht derzeit aus 37 Zulieferern, wie beispielsweise Texas Instruments oder Michelin. Diese besitzen das Recht auf Information über die aktuellen Entwicklungen und lizenzkostenfreie Benützung der AUTOSAR-Technologie, ohne jedoch eine Möglichkeit zur Mitbestimmung oder Mitarbeit im Projekt zu besitzen. Die weiteren Gruppen „Development Members“ und „Attendees“ haben derzeit keine Mitglieder. [12] Nach der einführenden Behandlung von Projektziel und Projektmitgliedern soll nun eine genauere Betrachtung der technischen Ansätze des AUTOSAR-Projekts erfolgen.

5. Technisches Grundkonzept und Systemarchitektur von AUTOSAR

Um die technischen Ziele der Modularität, Skalierbarkeit, Übertragbarkeit und Wiederverwendbarkeit der Funktionen zu erreichen, wird im AUTOSAR-Projekt eine gemeinsame Softwareinfrastruktur für alle Anwendungsgebiete innerhalb eines Fahrzeugs entwickelt werden. Diese Softwareinfrastruktur wird auf standardisierten Interfaces basieren. Der AUTOSAR-Standard wird folgende Punkte umfassen:

Standardisierung verschiedener API’s, um die AUTOSAR-Softwareschichten zu trennen

Kapselung funktionaler Softwarekomponenten Definition der Datentypen der Softwarekomponenten Identifikation der grundlegenden Softwaremodule der Softwareinfrastruktur und

Standardisierung ihrer Interfaces. AUTOSAR soll die Optimierung des gesamten Fahrzeugnetzwerkes ebenso wie lokale Optimierungen einzelner Komponenten ermöglichen. [13] Die Systemarchitektur von AUTOSAR basiert auf dezentralen Steuergeräten, welche standardgemäß als ECU (Electronic Control Unit) bezeichnet werden. Auf solchen ECUs werden die Basiskomponenten der Software ausgeführt, und die ECUs sind über ein logisches Netzwerk, den VFB (Virtual Functional Bus) verbunden und bilden somit das Gesamtsystem. In diesem Gesamtsystem werden die einzelnen Anwendungssysteme ausgeführt. Die folgende Abbildung 34 stellt diese Architektur grundlegend dar. Dabei stellen die einzelnen SW-Components die Anwendungsfunktionen dar, welche eine für den Benutzer erkennbare Leistung bringen, und die RTE-Schicht (RunTime Environment) ist die ECU-eigene Komponente des gesamtfahrzeuglichen Virtual Functional Bus.


Abbildung 34: Grundlegender Aufbau [8]

5.1. Die Grundlage: Basic Software Die Basic Software ist die standardisierte Softwareschicht, die grundlegende Services wie Speicher, Kommunikation oder I/O-Operationen für die AUTOSAR-Softwarekomponenten zur Verfügung stellt. Sie führt keine eigentliche Aufgabe aus, die ein Benutzer als Problembehandlung ansehen kann. Die Basic Software besteht aus standardisierten und ECU-spezifischen Komponenten. Die Basic Software besteht aus folgenden hardwareunabhängigen Komponenten:

Betriebssystem: Die Standardisierung oder Entwicklung eines eigenständigen Betriebssystems ist nicht das Ziel von AUTOSAR, es wird darauf hingearbeitet, ein existierendes einzusetzen. Dieses Betriebssystem soll statisch konfiguriert werden, Echtzeitverarbeitung ermöglichen (vor allem für Sicherheitsanwendungen), Prozesse schedulieren und voneinander abschirmen. Weiters ist es eine wichtige Anforderung, dass dieses Betriebssystem mit Standard-ECUs arbeiten kann. Deshalb ist die Möglichkeit zum ressourcenschonenden Betrieb eine Grundanforderung an das Betriebssystem.

Communication:

Diese Komponente verwaltet den Zugang zum Netzwerk und arbeitet dafür mit dem Betriebssystem zusammen.

Services:

Die Servicekomponente führt vor allem das Speichermanagement aus. Weiters sind die verschiedenen Diagnoseroutinen zur Hardwareprüfung beim Systemstart in dieser Servicekomponente enthalten.

Microcontroller Abstraction: Die Microcontroller Abstraction wird auch als Standard Peripheral Controller Abstraction (SPAL) bezeichnet. Sie greift indirekt über die ECU Abstraction auf die


Microcontroller zu und dient dazu, die Software höherliegender Schichten von der Hardware abzukoppeln und die Details des Hardwarezugriffs auszuführen. Dazu beinhaltet diese Komponente Microcontroller-Treiber, Speichertreiber und I/O-Treiber.

Die folgenden Komponenten sind hardwarespezifisch, somit erfüllen sie die Aufgabe, die spezifische Hardwareausstattung für die darüberliegenden Komponenten zu abstrahieren.

ECU Abstraction: Sie bildet das Interface zur Microcontroller Abstraction, damit diese hardwareunabhängig implementiert werden kann. Die ECU Abstraction beinhaltet ebenso die Treiber für externe Geräte und bietet ein API für den Zugriff auf die Peripherie und andere ECUs.

Complex Device Drivers:

Ein komplexer Treiber bietet die gesamte Steuerung einer Gerätegruppe, mit dieser Komponente besteht die Möglichkeit, alle anderen Komponenten der ECU-Software zu umgehen. Damit kann eine relativ komplexe Hardware mit strengen Echtzeitanforderungen bedient werden. Beispiele für solche Anwendungen, die durch einen direkten Zugang zur Hardware profitieren, sind beispielsweise die Steuerung der Einspritzung oder die Ventilsteuerung. [12] [14]

5.2. Die Kommunikationsschicht: Runtime Environment Die auf die Schicht der Basic Software aufbauende Schicht ist die des Runtime Environments. Auf der Ebene des Systemdesign wird das Runtime Environment (RTE) zu dem Virtual Function Bus (VFB) abstrahiert, und dieser Virtual Function Bus dient als Kommunikationszentrum zum Informationsaustausch innerhalb einer ECU und zwischen verschiedenen ECUs. Jegliche Kommunikation sowohl zwischen der Basic Software und einer Anwendung als auch zwischen verschiedenen Anwendungen läuft über diesen VFB. Das Service, das der Virtual Functional Bus anbietet, ist ein einheitliches Kommunikationsinterface, egal, ob nun eine Anwendung mit einer ECU, eine Anwendung mit einer anderen Anwendung oder eine ECU mit einer anderen ECU interagiert. Weil sich allerdings die Kommunikationsanforderungen zwischen den einzelnen ECUs unterscheiden, kann sich auch die konkrete Implementierung zweier Runtime Environments unterscheiden. [14]

5.3. Die Anwendungsschicht: AUTOSAR Software Die AUTOSAR Software besteht aus den Softwarekomponenten, welche die eigentliche Funktionalität des Systems implementieren und kapseln. Da jede Komponente auf dem RTE aufsetzt und jegliche Kommunikation über den RTE abgewickelt wird, müssen die Komponenten auch die Interfaces des RTE implementieren. Indem diese Interfaces standardisiert sind, wird auch die Skalierbarkeit, Interoperabilität und die Übertragbarkeit der einzelnen Softwarekomponenten bezüglich verschiedener ECUs sichergestellt. Damit wird auch erreicht, dass die Softwarekomponenten auf verschiedenen Fahrzeugplattformen eingesetzt werden können. [14] Abschließend wird noch die detaillierte Übersicht über die Software angegeben (Abbildung 35). In dieser Übersicht sind auch die einzelnen Kommunikationswege ersichtlich, ebenso die Interfaces:


Abbildung 35: Softwarearchitektur einer ECU [5]

6. Zusammenfassung und Ausblick des AUTOSAR-Projekts Aufgrund der steigenden Bedeutung der Fahrzeugelektronik und der darin enthaltenen Software steigt der Umfang dieser Komponenten und damit sowohl Kosten als auch Fehlerhäufigkeit. Eine Möglichkeit, dem zu begegnen, wurde mit dem AUTOSAR-Projekt aufgezeigt. Der Ansatz dabei ist die Dezentralisierung und Vernetzung standardisierter Komponenten, die entsprechend generell sind, um auf allen Fahrzeugplattformen eingesetzt zu werden. In diesem Artikel wird die grundlegende Architektur des Systems beschrieben. Für eine genauere Beschreibung samt Spezifikationen wird auf die Homepage des Projekts [12] verwiesen. Das AUTOSAR-Projekt befindet sich derzeit in der Phase der Spezifikation. Das letzte noch unvollständige Release der Spezifikation wurde Ende Mai 2006 veröffentlicht, es handelt sich dabei um die Version 2.0. Weitere Releases wurden für September und Dezember 2006 angekündigt, die vorläufig vollständige Spezifikation wird per Ende 2006 mit dem Release 2.1 erwartet. Damit ist das Projekt, verglichen mit der ursprünglichen Terminplanung (Abbildung 36) über ein Jahr im Rückstand.


Abbildung 36: Ursprünglicher Zeitplan des AUTOSAR-Projekts [12]

Mit der endgültigen Spezifikation ist es dann möglich, dass die einzelnen Hersteller AUTOSAR in die spezifische Serienentwicklung integrieren können. Die Umsetzung aller Komponenten wird voraussichtlich zwischen 2008 und 2012 erfolgen, womit dann Fahrzeuge mit der AUTOSAR-Technologie am Markt sein werden. [15]


7. Literatur [1] http://www.tietoenator.de/default.asp?path=486,579,16086,8825,18463,22563,22567,

zuletzt besucht am 08.07.2006 [2] http://de.etasgroup.com/products/ascet/in_detail.shtml, zuletzt besucht am 08.07.2006 [3] http://www.mathworks.de/products/matlab/demos.html, zuletzt besucht am 08.07.2006 [4] http://www.mathworks.de/products/simulink/description1.html, zuletzt besucht am 08.07.2006 [5] http://www.ilogix.com/sublevel.aspx?id=692, zuletzt besucht am 08.07.2006 [6] http://www.sparxsystems.com, zuletzt besucht am 08.07.2006 [7] http://www.sparxsystems.at, zuletzt besucht am 08.07.2006 [8] J. Dannenberg und Ch. Kleinhans: The Coming Age of Collaboration in the Automotive

Industry. Mercer Management Journal, 17:88–94, 2004, http://www.mercermc.com/Perspectives/Journal/MMJ pdfs/17/Auto Industry.pdf, zuletzt besucht am 06.07.2006

[9] Th. Scharnhorst, H. Heinecke, K.-P. Schnelle, H. Fennel, J. Bortolazzi, L. Lundh, P. Heitkämper, J. Leflour, J.-L. Maté und K. Nishikawa: AUTOSAR – Challenges and Achievements 2005, VDI Berichte Nr. 1907, 2005

[10] http://www.oeamtc.at, zuletzt besucht am 05.07.2006 [11] W. Damm, A. Votintseva, A. Metzner, B. Josko, T. Peikenkamp, E. Böde: Boosting Re-

use of Embedded Automotive Applications through Rich Components, http://www.tcs-trddc.com/tecs/2006-reading/Boosting%20Re-use%20of%20Embedded%20Automotive%20Applications%20Through%20Rich%20Components.pdf, zuletzt besucht am 06.07.2006

[12] http://www.autosar.org, zuletzt besucht am 12.07.2006 [13] H. Heinecke, K.-P. Schnelle, H. Fennel, J. Bortolazzi, L. Lundh, J. Leflour, J.-L. Maté,

K. Nishikawa, T. Scharnhorst: AUTomotive Open System ARchitecture – An Industry-Vide Initiative to Manage the Complexity of Emerging Automotive E/E-Architectures, http://www.autosar.org, zuletzt besucht am 10.07.2006

[14] AUTOSAR GbR: AUTomotive Open System ARchitecture - An industry-wide initiative to manage the complexity of emerging Automotive E/E-Architectures http://www.autosar.org/download/AUTOSAR_Light%20Version_V1_5_f.pdf, zuletzt besucht am 06.07.2006

[15] gemäß einem Mail von Michaela Müller, Abteilung Technology Communications, BMW Group ([email protected]), 29. 06. 2006


http://www.tietoenator.de/default.asp?path=486,579,16086,8825,18463,22563,22567

http://de.etasgroup.com/products/ascet/in_detail.shtml

http://www.mathworks.de/products/matlab/demos.html

http://www.mathworks.de/products/simulink/description1.html

http://www.ilogix.com/sublevel.aspx?id=692

http://www.sparxsystems.com/

http://www.sparxsystems.at/

http://www.mercermc.com/Perspectives/Journal/MMJ pdfs/17/Auto Industry.pdf

http://www.oeamtc.at/

http://www.tcs-trddc.com/tecs/2006-reading/Boosting Re-use of Embedded Automotive Applications Through Rich Components.pdf



http://www.autosar.org/

http://www.autosar.org/

http://www.autosar.org/download/AUTOSAR_Light Version_V1_5_f.pdf


Systems Modelling Language Automotive Open System...

Documents

Transcript of Systems Modelling Language Automotive Open System...