Model-Based Design für AUTOSAR Komponenten

Transkript

1 W H I T E P A P E R Model-Based Design für AUTOSAR Komponenten Autoren: Guido Sandmann Automotive Marketing Manager EMEA Dr. Hans Martin Ritt Senior Teamleader Application Engineering Dr. Joachim Schlosser Senior Teamleader Application Engineering ESP, Spurkontrolle und Einparkhilfe zeigen, wohin der Weg in der Automobilelektronik geht: Die neuen Entwicklungen nehmen die Fahrzeugumgebung wahr, interpretieren sie und unterstützen den Fahrer bei seinen Manövern. In Zeiten, in denen der Verkehr immer dichter wird, die Staus und Wartezeiten länger, geht der Trend von unabhängigen elektronischen Funktionen zur komplexen, vernetzten Technologie. Eine standardisierte Architektur-Plattform für elektronische Steuergeräte ist die Antwort auf die Frage, wie sich durch feste Schnittstellen und Prozesse die unterschiedlichen Funktionen besser vernetzen lassen. Der internationale Verbund AUTOSAR Akronym für Automotive Open System Architecture hat es sich zum Ziel gesetzt, einen offenen Standard für Elektrik/Elektronik-Architekturen in Kraftfahrzeugen zu etablieren. Mehr als einhundert Unternehmen wie Fahrzeughersteller, Zulieferer und Werkzeuganbieter arbeiten seit 2003 weltweit zusammen, um einen Standard bezüglich einer Architekturplattform für elektronische Steuergeräte zu definieren und zu entwickeln. Ende 2006 wurde die Version 2.1 des AUTOSAR- Standards freigegeben. Sowohl Automobilhersteller als auch Zulieferer beginnen aktuell mit der Entwicklung und Integration erster Steuergeräte und Funktionskomponenten. Um der Komplexität der neuen, vernetzten Technologie in Funktion, Schnittstellen und Kommunikation zu begegnen, ist der Model-Based Design Prozess ein entscheidender Schritt. Model-Based Design bietet einen durchgängigen Prozess von der Formulierung einer widerspruchsfreien und ausführbaren Spezifikation über Techniken zur automatisierten Verifikation und Validierung bis zur Implementierung durch automatische Codegenerierung. The MathWorks bietet mit MATLAB/Simulink ein Programmpaket für numerische Berechnungen zur Modellierung und Simulation technischer Systeme an. Gemeinsam mit verschiedenen Fahrzeugherstellern, die ebenfalls Mitglieder des AUTOSAR-Verbundes sind, ist es bereits gelungen, Software-Anwendungen AUTOSAR-konform in ein Steuergerät zu implementieren. Model-Based Design für die Automobilelektronik Der Model-Based Design Prozess eignet sich nicht nur für die Entwicklung AUTOSAR-konformer Komponenten, sondern wird in der Automobilindustrie bereits seit einigen Jahren für die Entwicklung und Implementierung komplexer Steuerungen und Komponenten eingesetzt. Model-Based Design begegnet den Problemen bei der Entwicklung komplexer Systeme in der Automobilelektronik mit einem hierarchisch strukturierten Entwicklungsprozess, bei dem der gesamte Entwurf zunächst auf der Konzeptebene definiert und dann je nach den Erfordernissen immer detaillierter ausgearbeitet wird, bis die benötigte Funktionalität vorliegt. Die Ingenieure arbeiten mit Model-Based Design auf einer Abstraktionsebene, die grafische Beschreibungsformen nutzt, welche optimal auf die Anwendung ausgerichtet sind. Der Signalfluss wird von Ingenieuren bereits seit Jahrzehnten in Spezifikationen und Lehrbüchern mit Blockdiagrammen dargestellt; die Arbeit mit grafischen Werkzeugen ist daher eine natürliche Art, signalverarbeitende Systeme direkt in dieser Form zu entwickeln und zu verifizieren. Die neuen grafischen Mittel zur Programmierung erlauben es, Anwendungen direkt in der dem Problem angepassten Form zu entwickeln und den Übersetzungsvorgang in eine von Computern ausführbare Form zu automatisieren. Die Idee wird also in einem grafischen Modell abgebildet, das auch schon sehr früh in der Konzeptphase durch Simulationen verifiziert werden kann. Neben der zu implementierenden Funktion wird auch die reale The MathWorks GmbH Adalperostraße Ismaning info@mathworks.de

2 Umgebung, in der diese Funktion arbeiten wird, modelliert und das Zusammenspiel von Funktion und realer Umgebung für die Auslegung des Verhaltens genutzt. Dies ist ein entscheidender Unterschied zu allen rein auf die Softwareentwicklung ausgerichteten Methoden: Für ingenieurtechnische Anwendungen ist die möglichst frühzeitige Überprüfung der Funktionalität mittels Simulationen unter Einbindung von Modellen der physikalischen Umgebung, etwa des zu regelnden Systems, ein entscheidender Baustein für hochqualitative Ergebnisse. Wie auch von AUTOSAR vorgeschlagen, betrachtet man in dieser Phase die Funktion als abstrahiert von der Implementierung auf einer Hardware. Das Systemmodell, das für die Spezifikation in idealisierter Form entworfen wurde, wird im Model-Based Design Prozess durch kontinuierliches Simulieren, Verfeinern und Testen weiterentwickelt, bis die Ingenieure eine bitgenaue und das Timing exakt wiedergebende Darstellung erhalten. Mittels automatischer Codegenerierung kann anschließend aus dem Modell Software für das Zielsystem erzeugt werden. Man spricht deshalb auch von einer ausführbaren Spezifikation. Im praktischen Einsatz ermöglicht diese Technologie entscheidende Verbesserungen der Effizienz und der Qualität in der Entwicklung von Embedded Systemen für die Automobilbranche. Im AUTOSAR-Kontext entsteht so eine bereits weitestgehend getestete Komponente, die durch entsprechende Ausstattung mit den standardisierten Interfaces in die Architektur des Gesamtsystems eingebunden werden kann. Durch die Konfiguration des Codegenerators kann gewährleistet werden, dass Interface-Konventionen wie die von AUTOSAR bei der Entwicklung automatisch eingehalten werden. AUTOSAR: Automotive Open System Architecture Während Model-Based Design der etablierte Weg für die Beherrschung der Komplexität auf der funktionalen Ebene ist, konzentriert sich die AUTOSAR Initiative besonders auf die Komplexität bei der Interaktion von Hardware- und Software-Komponenten im Fahrzeug. Die Standardisierungsbemühungen des AUTOSAR Konsortiums werden allgemein als einer der wichtigsten Schritte angesehen, die aktuellen und zukünftigen Herausforderungen in der Entwicklung von Automobilen zu meistern. Aus technischer Sicht sind die wichtigsten Ziele der AUTOSAR-Initiative die Modularität, Skalierbarkeit, Transferierbarkeit und Wiederverwendbarkeit von Funktionen. Um diese Ziele zu erreichen, arbeiten die an AUTOSAR beteiligten Automobilfirmen an standardisierten Schnittstellen. Als Basis wurde eine standardisierte Architektur-Plattform für automobile Steuergeräte definiert. Abbildung 1 zeigt die AUTOSAR ECU- Architektur mit ihren unterschiedlichen Schichten, die sich grob in die folgenden drei unterteilen lassen: Application Layer: Umfasst die Software der Steuergeräte-Funktionalität (AUTOSAR Software Components; AUTOSAR SW-C). AUTOSAR Runtime Environment (RTE): Entkoppelt die Steuergerätefunktionalität von der konkreten Infrastruktursoftware. Basic Software: Die Schicht zwischen MicroController und Abb. 1: AUTOSAR ECU Architektur RTE stellt die Infrastruktursoftware in Form von hardwareabhängigen und -unabhängigen, nicht-funktionalen Services zur Verfügung.

3 Wichtig in diesem Zusammenhang ist die bereits erwähnte Entkopplung von Funktionssoftware und Hardware gesetzt wurde dies durch die Definition des Virtual Functional Bus (VFB) (siehe Abbildung 2). AUTOSAR Software Components realisieren den Application Layer und kapseln die Funktionen eines Steuergerätes. Sie haben definierte Schnittstellen, die im Rahmen von AUTOSAR standardisiert sind. Eine AUTOSAR Software Component ist dabei immer genau einem Steuergerät zugeordnet, während ein Steuergerät auch mehrere AUTOSAR Software Components enthalten kann. Der VFB realisiert dann die Kommunikation zwischen verschiedenen AUTOSAR Software Components unabhängig von deren Zuordnung auf konkrete Steuergeräte. Dieses Konzept erlaubt es, AUTOSAR Software Components beliebig in Abb. 2: Virtual Functional Bus ein Netzwerk von Steuergeräten zu integrieren und innerhalb eines solchen Netzwerkes zu verschieben. Das RTE ist in der Phase der Implementierung dann eine konkrete Instanz des Virtual Functional Bus für ein spezielles Steuergerätenetzwerk mit konkreter Hardware. Model-Based Design für AUTOSAR Komponenten Die oben erläuterten Vorteile des Model-Based Design Prozesses sollen nun auch bei der Entwicklung von AUTOSAR-konformen Softwarekomponenten zum Tragen kommen. Wie dies möglich ist, zeigte als erstes Beispiel VW mit der Integration eines vollständig AUTOSAR-konformen Komforsteuergeräts in ein vorhandenes Steuergeräte-Netzwerk für eine Passat-Limousine. Anwender, die bereits mit Simulink von The MathWorks arbeiten und Model-Based Design einsetzen, sollen ihren Arbeitsfluss nicht grundlegend ändern und sich nicht im Detail mit AUTOSAR auseinandersetzen müssen, um AUTOSAR-konforme Softwarekomponenten erstellen zu können. The MathWorks hat deshalb das AUTOSAR Demonstration Kit entwickelt. Diese Erweiterung zu den Produkten für Model-Based Design erfasst die AUTOSAR Standards und ermöglicht die automatische Generierung von AUTOSAR-konformem Code mit Hilfe des Real-Time Workshop Embedded Coder von The MathWorks. Wichtigste Voraussetzung für den Software- oder Funktionsentwickler, der an AUTOSAR Software Components arbeitet, ist Transparenz. Dies bedeutet zum einen, dass die Schnittstellenanforderungen relativ transparent für den Anwender sein sollen. Da mit dem vorliegenden AUTOSAR Demonstration Kit (ADK) kein separates Blockset zum Einsatz kommt, kann mit den bestehenden Blöcken in Simulink weitergearbeitet werden und daraus AUTOSAR-konformer Code generiert werden. Es besteht kein Anlass für eine Block-Ersetzung. Auf der anderen Seite bedeutet Transparenz auch, dass bewährte Mittel des Model-Based Design auch bei der Entwicklung von AUTOSAR-Software Components zur Verfügung stehen. So ist die Durchgängigkeit von Anforderungen mit Hilfe von Simulink Verification and Validation vom Anforderungsdokument (z.b. Telelogic DOORS oder Microsoft Word) über das Modell in Simulink bis in den mittels Real-Time Workshop Embedded Coder generierten C-Code sichergestellt. Für die Entwicklung von AUTOSAR Software Components für den Application Layer sind auf dieser Grundlage zwei Wege möglich: Die AUTOSAR Software Component kann auf Basis einer expliziten Schnittstellendefinition implementiert werden, oder eine bereits vorhandene Funktion wird in den Kontext von AUTOSAR eingebettet. Zusammen mit dem AUTOSAR Interface kommunizieren die Software Components über das AUTOSAR Runtime Environment (RTE). Eine Anwendung mit Regler- oder Steuerlogik oder einer Kombination aus beiden wird klassischerweise in Simulink modelliert und muss nun in den AUTOSAR-Kontext eingebettet werden.

4 Implementierung einer AUTOSAR Software Component auf Basis einer expliziten Schnittstellendefinition Dieses erste Szenario geht davon aus, dass aus einem dedizierten Werkzeug für die AUTOSAR-Architekturmodellierung, wie etwa DaVinci System Architect von Vector Informatik, die Schnittstellenbeschreibungen für die einzelnen Softwarekomponenten extrahiert werden. Diese Schnittstellenbeschreibungen, die sowohl die Aufruf- als auch Datenschnittstelle spezifizieren, liegen in einem im AUTOSAR Standard festgelegten XML-Format vor. Diese Schnittstellenbeschreibung wird mittels des ADK in Simulink importiert und daraus ein leeres Subsystem in Simulink generiert. Bei einer konkreten Entwicklung von Steuergerätesoftware modelliert der Entwickler den vorgesehenen Algorithmus innerhalb dieses Subsystems oder fügt ein existierendes Modell mit den Algorithmen Abb. 3: Import eines AUTOSAR Interface und Export der per Model Referencing ein und nimmt eine AUTOSAR Software Component aus Simulink Schnittstellenadaption vor. Auf diese Weise ist Modularität und insbesondere Wartbarkeit gewährleistet. Abbildung 3 zeigt den Ablauf dieses Szenarios. Die nun fertig im Modell realisierte Funktion wird mit Real-Time Workshop Embedded Coder in C implementiert. Dabei werden die von AUTOSAR geforderten Aufruf- und Datenschnittstellen durch das ADK- Target entsprechend in den C-Code eingeflochten. Zusätzlich wird eine aktualisierte Version der Software Component Description in XML exportiert, um das Ergebnis mit dem AUTOSAR Autorenwerkzeug zu verifizieren. Einbetten einer bereits vorhandenen Funktion in den Kontext von AUTOSAR Im zweiten Szenario wird eine schon existierende Funktion bzw. ein Modells in einen AUTOSAR Kontext eingebettet. Dies bedeutet sozusagen die Veröffentlichung einer Funktion, wie in Abbildung 4 dargestellt. Das schon existierende Modell verfügt über normale Simulink Ein- und Ausgänge. Um diese jetzt der AUTOSAR-Umgebung bekannt zu machen, erlaubt das ADK über das Kontextmenü der normalen Simulink Modell-Ein- und -Ausgänge die Spezifizierung der zusätzlich notwendigen Parameter. Danach wird wie im Szenario 1 neben dem C-Code wieder das Software Component Description XML File erzeugt, mit dessen Hilfe die neue Software Component in einem AUTOSAR Abb. 4: Export einer AUTOSAR Software Component aus Autorenwerkzeug eingelesen werden Simulink kann.

5 Ausblick Mit Model-Based Design steht ein effizienter Weg für die Entwicklung von AUTOSAR-konformen Softwarekomponenten zur Verfügung. Mit seinen strikten Spezifikationen und Formaten bringt AUTOSAR andererseits auch neue Aspekte in den Model-Based Design ein und treibt seine Entwicklung voran. Erste Beispiele wie das von VW zeigen, dass AUTOSAR-konforme Komponenten in bestehende Steuergeräte- Netzwerke integriert werden können. AUTOSAR hat damit den Schritt in die Praxis gemacht und es wird in Zukunft für alle Hersteller und Zulieferer noch wichtiger werden, das Know-How für die Entwicklung von AUTOSAR Komponenten zu erwerben und die entsprechenden Werkzeuge zu beherrschen. Literatur [1] AUTOSAR Partnerschaft: [2] HELLA, Volkswagen, NEC Electronics und Elektrobit: Kooperation bei der Entwicklung AUTOSAR-kompatibler Software, August 2006 [3] Vector Informatik: DaVinci System Architect, [4] AUTOSAR GbR: Layered Software Architecture, Version 2.0.0, Juni 2006 Über The MathWorks The MathWorks ist der weltweit führende Anbieter von Technical Computing und Model-Based Design Software für Ingenieure und Wissenschaftler in der Industrie, Forschung und Lehre. Mit einer breit aufgestellten Produktfamilie, die auf den Kernprodukten MATLAB und Simulink basiert, bietet The MathWorks Entwicklungstools und Dienstleistungen zur Lösung anspruchsvoller technischer Problemstellungen und zur schnelleren Umsetzung von Innovationen für die Bereiche Automobil, Luft- und Raumfahrt, Telekommunikation, Halbleiter-/Elektrotechnik, Medizin, Finanzwesen, Biotechnologie und für weitere Branchen. The MathWorks, mit Hauptsitz in Natick, Massachusetts (USA), wurde 1984 gegründet und beschäftigt über 1800 Mitarbeiter weltweit. Lokale Niederlassungen in der D-A-CH Region befinden sich in Aachen, Bern, München und Stuttgart. Weitere Informationen unter: , The MathWorks MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents und xpc TargetBox sind eingetragene Warenzeichen und The MathWorks, das L-förmige Membran- Logo, Embedded MATLAB und PolySpace sind Handelsmarken von The MathWorks, Inc. Andere Produkt- oder Markennamen sind Handelsbezeichnungen oder eingetragene Warenzeichen der jeweiligen Eigentümer.