dSPACE Magazin 2009 2 autosar scenarios de

(1)

Durchstarten!

Einführungsszenarien in den AUTOSAR-Standard

mit Fallstudien aus der Industrie

Mit dem richtigen Standard

AUTOSAR EINFÜHRUNGSSZENARIEN SEITE 54

dSPACE Magazin 2/2009 · © dSPACE GmbH, Paderborn, Germany · info@dspace.com · www.dspace.com

(2)

Die Ausgangssituation in Sachen Steuergeräteentwicklung dürfte in

nahezu allen Fällen ähnlich sein: eine Entwicklungsmethodik ist ein-

geführt, die Werkzeugketten und Prozesse sind installiert und im Ein-

satz. An ihnen wird gelegentlich optimiert – Revolutionen sind jedoch

nicht vorgesehen. Klar, besteht das vorrangige Ziel doch darin, mit

effizienten Werkzeugen und Prozessen erfolgreich und schnell neue

Produkte auf den Markt zu bringen und sich nicht zum Selbstzweck

mit der Infrastruktur zu beschäftigen. Da kommt ein neuer Standard,

der in viele Entwicklungsbereiche eingreift, nur bedingt gelegen.

Der AUTOSAR-Standard bietet zwar genau die Lösungsprinzipien zur Beherrschung komplexer Software- Architekturen, die in den Entwick- lungsabteilungen häufig gefordert werden, wirft jedoch vor seiner Ein- führung auch viele Fragen auf. Kann man existierende, ausgereifte Funktionssoftware bzw. deren Modelle weiterverwenden? Ist die spezifizierte, ausgeklügelte Kommu- nikation des Steuergeräteverbunds noch zu gebrauchen? Benötigt man ein Entwicklerteam, das parallel zur herkömmlichen Entwicklung AUTOSAR- Projekte durchführt? Welche Tools sind erforderlich, und welche braucht man evtl. nicht mehr? Wie geht man bei der Softwareentwicklung strate- gisch vor: möglichst viel neu machen oder die maximale Wiederverwen- dung anstreben? Die Fragen nehmen kein Ende.

Annäherung durch Szenarien Anhand praxiserprobter Szenarien soll aufgezeigt werden, wie man das Thema AUTOSAR angehen kann. Da die Ausgangssituation aufgrund von Firmen- und Projektkonventionen immer unterschiedlich sein wird, können die Szenarien bestenfalls eine grobe Annäherung an die jeweiligen Erfordernisse beschreiben. Es sollte jedoch möglich sein, grundsätzliche Präferenzen auszumachen. Die aufge-

zeigten Wege orientieren sich an tat- sächlich durchgeführten Projekten in verschiedenen Unternehmen. Gerade die unterschiedlichen Ansätze zeigen, dass für die jeweilige Situation eine geeignete Vorgehensweise gefunden werden muss.

AUTOSAR-Quintessenz

Der AUTOSAR-Standard ist vielschich- tig. Der Standard

n identifiziert die Beschreibungs- elemente, die im System- und Architekturentwurf genutzt werden können,

n legt ein Datenaustauschformat fest, mit dem diese Elemente beschrieben werden können,

n führt ein Schichtenkonzept einer Steuergeräte-Softwarearchitektur mit Schnittstellenvereinbarungen ein, und

n beschreibt einen Ablaufrahmen zur Software-Entwicklung nach AUTOSAR.

Folglich kann der Standard an sehr unterschiedlichen Stellen in einem AUTOSAR-Projekt sichtbar werden. Angesichts des Umfangs des Stan- dards ist zu erwarten, dass die Einfüh- rung schrittweise erfolgen wird. Vor einer Einführung ist zunächst die Frage zu klären, wie die AUTOSAR- konformen Beschreibungen entstehen.

SEITE55

(3)

Er ist beherrschbar, wenn die Daten- kataloge konsistent gepflegt wurden. Eine formal auswertbare Struktur ermöglicht sogar den Einsatz auto- matischer Skripte.

Beispiel Motorsteuerung

Ein Beispiel dafür ist ein Projekt des Zulieferers Magneti Marelli S.p.A. Die konkrete Aufgabe bestand darin, die Software eines bereits existierenden Motorsteuergeräts vollständig nach AUTOSAR zu migrieren und wiederum auf demselben Steuer- gerät zu implementieren. Um dies umzusetzen, wurden beispielsweise Informationen, die zur Rekonstruktion der Software-Architektur und des Schedulings wichtig waren, aus den existierenden Steuergerätedaten extrahiert und per Skript in die System architektursoftware dSPACE SystemDesk transferiert. Die Migration wurde von den Entwicklern des Unternehmens in Zusammenarbeit

mit dSPACE vorgenommen und dauerte etwa ein halbes Jahr.¹

Szenario 2: Instrumentale Alternative

Szenario 1 lässt sich auch so abwan- deln, dass sowohl AUTOSAR als auch klassische Entwicklungen durchführbar sind. Dazu bleiben die bestehenden Modelle, C-Codes und Datenkataloge einschließlich der damit verbundenen Toolketten erhalten. Die vorliegenden Beschrei- bungen werden „instrumentiert“, so dass an diesen Eingriffsstellen die Beschreibungen für AUTOSAR- und klassische Implementierungen um- schaltbar sind. Solche Eingriffsstellen sind entweder auf der Code-Ebene

möglich, beispielsweise in Form von Makros für Zugriffsfunktionen, oder auf der Modell-Ebene, beispielsweise durch Verwendung des dSPACE TargetLink AUTOSAR Blocksets mit nachgelagerten Generierungsalter- nativen.

Szenario 3: Top-Down-Ansatz Ein anderer Ansatz geht von der Architekturebene aus. Hierbei wird zunächst das System geplant und dann die Verhaltensmodellierung der Funktionen vorgenommen. Dabei setzt man konsequent auf die AUTOSAR-Beschreibungsformate im Software-Entwicklungsprozess. Autorenwerkzeuge wie SystemDesk zur grafischen Modellierung von Software-Komponenten kommen hier ebenso zum Einsatz wie zentrale Datenbanken zur Verwaltung aller Projektdaten. Die vorher genannten Szenarien sind in diesem Szenario auch enthalten und darstellbar. Aber

kennzeichnend ist die strategische gesamtheitliche Ausrichtung.

Beispiel Body-Steuergerät Im Fall des OEMs Daimler AG wurde zur Einführung des Standards die Softwarearchitektur konsequent in Applikations- und Basissoftware- anteile aufgeteilt, die über eine defi- nierte Schnittstelle miteinander kommunizierten. Basis für die Defi- nition dieser Schnittstelle war der AUTOSAR-Standard. Die Basissoft- ware und die Standard-Software- architektur basierten zunächst auf einem etablierten Standard-Core und wurden um ausgewählte AU- TOSAR-Softwaredienste ergänzt. Durch dieses initial ausgewählte Vorgehen war die Netzwerk-Kom- patibilität der so entwickelten Steuer- geräte mit klassisch entwickelten Steuergeräten weiterhin gegeben. Dadurch war eine schrittweise Ein- führung der AUTOSAR-Technologie möglich.²

Vorteile durch AUTOSAR Nachdem AUTOSAR-konforme Beschreibungen vorliegen, ergeben sich innovative Einsatzmöglichkeiten im Rahmen von Prozessen, Werk- zeugketten und Methoden.

Datenaustausch

Die Stärken von AUTOSAR zeigen sich unter anderem im Datenaus- tausch zwischen Fahrzeugherstellern und Zulieferern. Es ist möglich, Projektvereinbarungen zu treffen, die auf einem Standard basieren. Eine Erkenntnis aus dem ersten AUTOSAR-Serienprojekt der Daimler AG: „Die Voraussetzung für einen prozesssicheren und breiteren Ein- satz der modellbasierten Entwick- lung ist somit eine einheitliche liefe- rantenübergreifende Softwarearchi- tektur und eine standardisierte Beschreibung der Metadaten.“²

Mit AUTOSAR machen wir nicht alles neu;

wir sprechen nur eine andere Sprache.

Szenario 1: Bottom-Up-Ansatz Voraussetzungen für die einfache Gewinnung von AUTOSAR-Beschrei- bungen sind, dass die Software-Ent- wicklung für Steuergeräte schon jetzt nach firmen- oder projektspezi- fischen Vorgaben erfolgt sowie geeignete Richtlinien und Strukturie- rungsansätze existieren. Signallisten, Module und Parameter werden in Excel-Tabellen, A2L-Dateien, grafischen Modellen oder anderen For- maten gespeichert.

Um vorhandene Applikationssoft- ware in ein AUTOSAR-Projekt zu migrieren, kann man die vorhande- nen Datenkataloge in das AUTOSAR- Format transformieren. Dieser Schritt ist einmalig erforderlich.

AUTOSAR EINFÜHRUNGSSZENARIEN SEITE 56

(4)

Der AUTOSAR-Standard erfüllt diese Forderungen. Diese Vorteile sind auch innerhalb eines Unternehmens, beispielsweise eines Zulieferers mit welt- weiter Präsenz darstellbar. Software- Module, die nach einem Standard wie AUTOSAR einheitlich erfasst werden, können in allen Regionen und Ländern in gleicher Weise aus einem zentralen Repository bezogen und eingesetzt werden.

Werkzeugkopplung

Erleichtert werden auch Kopplungen zwischen Werkzeugen. Es ist leichter möglich, Software-Komponenten in einem Autorenwerkzeug wie System- Desk mit Funktionsbeschreibungen in einem Werkzeug wie MATLAB^®/ Simulink^® oder TargetLink zu ver- knüpfen.

Entsprechendes gilt auch für die Kopplung zwischen Autorenwerk- zeug und Werkzeugen für die Kon- figuration der Basis-Software.

„Im Zusammenspiel der unterschiedlichen Tools liegt ein Schlüssel für die erfolgreiche Umsetzung der AUTOSAR-Idee. Hierbei stellt dSPACE

Je strukturierter die bisherigen Prozesse und

Methoden definiert sind, desto einfacher gelingt

die Migration nach AUTOSAR.

mit TargetLink und SystemDesk sowie definierten Dateiformaten und offenen Schnittstellen eine hervorragende Ausgangsbasis zur Verfügung.“³

Offline- und Online-Testprozess Zusätzlich zum Entwurfsprozess ergeben sich durch AUTOSAR auch neue Möglichkeiten für den Testprozess. Durch die formale Beschreibung von Applikationssoftware nach AUTOSAR lassen sich mit einem Systement- wurfswerkzeug die Software-Module frühzeitig simulieren. Die Audi Elect- ronics Venture GmbH führte eine virtuelle Integration eines vernetzten Regelsystems mit SystemDesk durch. Das System konnte mit einer Test- automatisierung auf dem PC systema- tisch simuliert und analysiert werden. Als Zukunftsszenario ist vorstellbar, dass Bestandteile der Offline-Simu- lation für den Steuergerätetest am Simulator wiederverwendbar sind.⁴ Ergänzend kann dieser Testprozess nicht nur die Applikationssoftware, sondern auch Dienste der Plattform- Software umfassen, beispielsweise Diagnosedienste. Dies zeigt ein Pro-

jekt bei der Daimler AG für die Vali- dierung von Diagnosefunktionen in sehr frühen Entwicklungsphasen. Dabei werden Testvektoren her- kömmlicher Diagnosetests auf die Offline-Simulation mit SystemDesk angewendet. Der virtuelle Fehler- speicher konnte in Abhängigkeit von der Stimulation ausgewertet und die Fehlereinträge auf Plausibilität geprüft werden.⁵

1 Alessandro Palma, Luigi Romagnoli, Walter Nesci, Magneti Marelli: Motorsteuerung alla AUTOSAR – Magneti Marelli migriert Steuergeräte-Software in den AUTOSAR- Standard. dSPACE Magazin 2/2008.

2 Christian Dziobek, Dr. Florian Wohlge- muth, Dr. Thomas Ringler, Daimler AG: AUTOSAR im Entwicklungsprozess – Vorgehen bei der Serien-Einführung der modellbasierten AUTOSAR-Funktions- entwicklung mit TargetLink. dSPACE Magazin 1/2008.

3 Dr. Karsten Schmidt, Frank Gesele, Audi Electronics Venture GmbH: Systematische AUTOSAR-Migration. In: dSPACE NEWS 1/2008.

4 Dr. Karsten Schmidt, Dipl.-Inf. Stephan Reichelt, Dipl. Ing. Marko Maleuda, Audi Electronics Venture, Dr. Dirk Stichling, Dr. Oliver Niggemann, dSPACE GmbH: Durchgängige Systemtests – Von der virtuellen Integration bis zum Verbundtest. ATZelektronik 06/2008.

5 Matthias Kohlweyer, Valentin Adam, Daimler AG, Heinrich Balzer, Universität Paderborn, Oliver Niggemann, Dirk Flei- scher, dSPACE GmbH: Using Simulation to Verify Diagnosis Algorithms of Electronic Systems. SAE Paper No. 2009-01-1043 Detroit, USA.

AUTOSAR

Literaturverzeichnis

Zusammenfassung

Die Entwicklung modularer und verteilter Regelsysteme setzt eindeutige Definitionen von Schnittstellen, Sprachen und Protokollen voraus. Der AUTOSAR-Standard bietet Lösungsprinzipien für deren effiziente Ent- wicklung. Anhand von Szenarien lassen sich prinzipielle Vorgehensweisen bei der Einführung von AUTOSAR darstellen. Fallstudien belegen, wie diese in Entwicklungsprojekten umsetzbar sind und welche Vorteile sich dabei ergeben. Die AUTOSAR-Einführungsprojekte zeigen, dass durch eine durchgängige Toolunterstützung auch umfangreiche Projekte beherrschbar bleiben.

Möchten Sie mehr über die Anwendung und den Nutzen von AUTOSAR in Ihren Projekten erfahren? Wir beraten Sie gern:

info@dspace.de oder +49 5251 16380.

SEITE57