Modellbasierter Funktionsentwurf: Erfolgreiche AUTOSAR-Migration

Für eine erfolgreiche Einführung des AUTOSAR-Standards in Serienprojekten ist es wichtig, die Hürde beim Übergang von konventionellen zu AUTOSAR-konformen Projekten so niedrig wie möglich zu gestalten. Dieser Artikel zeigt, wie dies für die modellbasierte Entwicklung auf der Basis von effizienten Werkzeugen gelingt.

Der AUTOSAR-Standard wird mittlerweile in diversen Serienprojekten erfolgreich angewandt. Um den AUTOSAR-Standard jedoch wirklich in der Breite zu verankern und die Vorteile von AUTOSAR für jeden Anwender in vollem Maße nutzbar zu machen, bedarf es ausgereifter, aufeinander abgestimmter Werkzeuge. Besonders attraktiv ist dabei die Kombination von AUTOSAR mit Techniken des modellbasierten Entwurfs und der automatischen Code-Generierung, wie sie im Automobilbereich mittlerweile auf breiter Front eingesetzt werden. Erste Erfahrungen aus der Anwendung dieser Methoden für AUTOSAR- konforme Projekte finden sich in [1, 2 und 3]. Anhand einer AUTOSARWerkzeugkette, bestehend aus System- Desk und Simulink/TargetLink von dSpace, werden im Folgenden wichtige Aspekte beim Einsatz der Werkzeuge näher beleuchtet.

Funktionsmodelle auf Knopfdruck nach AUTOSAR migrieren

Ein wichtiger Schritt beim Übergang von konventioneller zu AUTOSARkonformer Software-Entwicklung besteht darin, existierende modellbasierte Designs für Regelungs- und Steuerungsfunktionen in die AUTOSARWelt zu überführen. Erfreulicherweise gestaltet sich dieser Schritt sehr viel einfacher als die Migration von handgeschriebenem Legacy-Code. Im Wesentlichen muss das Funktionsmodell lediglich um eine AUTOSAR-konforme Datenzuweisung erweitert werden, auf die dann bei der Generierung von AUTOSAR-konformem Code zurückgegriffen wird. Mit dem „TargetLink AUTOSAR Migration Tool“ [4] können Target- Link-Modelle vollautomatisiert in AUTOSAR-Software-Komponenten (SWC) überführt werden. Aus der konventionellen Datenzuweisung der Modellschnittstellen werden hierzu Spezifikationen für AUTOSAR-Ports, -Schnittstellen, -Datentypen und –Skalierungsformeln extrahiert und im dSpace Data Dictionary abgespeichert (Bild 1). Anschließend kann unmittelbar AUTOSAR-konformer Code generiert und eine Software-Komponenten- Beschreibung exportiert werden. Das Migrationswerkzeug ist flexibel konfigurierbar, um firmenspezifische Namenskonventionen, unterschiedliche AUTOSAR-Kommunikationsarten oder spezielle Anforderungen im Hinblick auf die Software-Architektur umzusetzen. Mit der Target- Link-Version 3.1 ist darüber hinaus die Generierung von konventionellem als auch AUTOSAR-konformem Code aus dem gleichen Modell möglich. Dies reduziert Wartungsaufwände für Modelle, wenn Teilfunktionen in konkonformen Projekten wieder verwendet werden sollen.

Bottom-up-Aufbau der Software-Architektur durch Funktionsmodelle

Nach erfolgter AUTOSAR-Migration der Funktionsmodelle müssen die daraus generierten AUTOSAR-SWCs in die Gesamtarchitektur eines Steuergerätes integriert werden. Hierzu werden spezielle Architektur-Werkzeuge wie SystemDesk eingesetzt, welche die grafische Modellierung der Software- Architektur gestatten. Für ein AUTOSAR-konformes Steuergerät muss typischerweise eine Vielzahl von unterschiedlichen Anwendungskomponenten administriert, integriert und verschaltet werden [5]. Der grundsätzliche Aufbau einer Software-Komponente kann dabei prinzipiell auf unterschiedliche Arten entwickelt werden, etwa durch manuelle Codierung oder durch automatische Code-Generierung aus einem Funktionsmodell. Zur Integration einer TargetLink-AUTOSAR-SWC in die Software-Architektur muss lediglich die von TargetLink exportierte AUTOSAR-XML-Datei importiert und die SWC mit anderen Komponenten oder Basis-Software-Schnittstellen verschaltet werden (Bild 2). Die Software-Architektur wird hierbei im Stile eines Bottom-up-Vorgehens um zusätzliche Komponenten erweitert, die aus existierenden Funktionsmodellen stammen. Diese Vorgehensweise ist besonders dann attraktiv, wenn ein Großteil der Anwendungs-Software eines Steuergeräts bereits in Form von Funktionsmodellen vorliegt, die dann zu einem schrittweisen Auf- und Ausbau der Software-Architektur genutzt werden kann. Die Software-Architekturmodellierung und Integration mittels System- Desk ermöglicht darüber hinaus eine Vielzahl von automatisierten Prüfungen der Schnittstellenkonsistenz bei der Verschaltung von Komponenten. Hierdurch werden viele Fehler von vornherein vermieden, wie sie bei einer manuellen Software-Integration typischerweise auftreten. In System- Desk erfolgt die eigentliche Software- Integration bzw. die Glue-Code-Generierung nach abgeschlossener RTEKonfiguration (Run-Time Environment) automatisch durch den System- Desk-RTE-Generator.

Top-down-Ansatz und effizienter AUTOSAR-Kreislauf

Als Alternative zum Bottom-up-Ansatz bietet sich eine Top-down-Vorgehensweise zur Entwicklung von AUTOSAR-Anwendungs-Software an. Ausgangspunkt ist hierbei die Erstellung von Software-Komponenten im Architektur-Werkzeug, die zusammen mit ihren Ports, Schnittstellen und gegebenenfalls nach ihrem internen Verhalten spezifiziert werden. Erst anschließend erfolgt die Implementierung der einzelnen Komponenten der Architektur durch ein AUTOSAR-konformes Funktionsmodell. In Bild 3 ist skizziert, wie die Werkzeuge System Desk und TargetLink im Sinne eines Top-down-Ansatzes eingesetzt werden können. Nach Erstellung eines ersten Entwurfs der Software-Architektur in SystemDesk (Bild 3, links oben) werden für einzelne, in TargetLink zu implementierende Komponenten AUTOSAR- XML-Beschreibungen exportiert. Der Komponentenentwickler importiert diese in das Data Dictionary und nutzt die Informationen, um ein Rahmenmodell zu generieren (Bild 3, rechts oben), das bereits alle erforderlichen AUTOSAR-Spezifikationen enthält und den Anwender von arbeitsintensiven und fehlerträchtigen Schnittstellenspezifikationen entlastet.

Das AUTOSAR-Rahmenmodell wird anschließend durch die eigentliche Algorithmik der Steuerungs- und Regelungsfunktion ergänzt (Bild 3, unten). Aus dem so komplettierten Modell wird anschließend AUTOSAR-onformer Code sowie eine AUTOSARXML- Beschreibung generiert, die gegenüber der ursprünglichen Version um Implementierungsinformationen angereichert ist. Durch den Re-Import der XML-Datei in SystemDesk erfolgt schließlich die Aktualisierung der Komponente in der Software-Architektur.Während der Entwicklungsphase wird der in Bild 3 skizzierte Kreislauf typischerweise mehrfach durchlaufen, beispielsweise um Änderungen in den Anforderungen zu berücksichtigen oder um Inkonsistenzen in den Schnittstellen der SWCs zu beseitigen. Deshalb ist das effiziente Management der AUTOSAR-bezogenen Daten von zentraler Bedeutung.

Insbesondere muss festgelegt werden, welche Arten von Daten vom Software-Architekten und welche vom Komponenten-Entwickler modifiziert werden dürfen. Typischerweise sollten zumindest Daten von projektglobaler Relevanz wie Schnittstellen, Datentypen und Skalierungsformeln vom Architekten administriert werden. Der Komponentenentwickler verantwortet lediglich das Innenleben einer SWC, wobei es oftmals sinnvoll ist, auch die Spezifikation des internen Verhaltens einer SWC in die Obhut des Software-Architekten zu geben [6].

Simulationen und Tests in allen Entwicklungsphasen

Einer der großen Vorteile der modellbasierten Entwicklung besteht darin, dass modellbasierte Designs fortwährend simuliert und getestet werden können. Diese Eigenschaft bleibt auch bei der modellbasierten Entwicklung von AUTOSAR-konformer Software erhalten: _ Die etablierte Technik des Rapid Control Prototyping (RCP) zur frühen Erlebbarkeit und Validierung von Fahrzeugfunktionen kann auch auf AUTOSAR-Software-Komponenten angewandt werden. Das „dSpace RTI AUTOSAR Package“ ermöglicht dieIntegration von AUTOSAR-Software- Komponenten als Blöcke in ein Simulink- Modell. Die einzelnen Komponenten können dann im Modell verschaltet, mit I/O-Funktionen verbunden und schließlich auf einer Hardware in Echtzeit ausgeführt werden. Liegen die AUTOSAR-SWCs speziell als Funktionsmodelle vor, können diese unter Nutzung der etablierten RCPTechniken auch direkt validiert und erprobt werden. Genau wie im Nicht-AUTOSARFall kann in Simulink/TargetLink ein vollständiger Komponententest durchgeführt werden.

Typischerweise dient dabei eine Simulation auf Blockebene (Model-in-the-Loop) als Referenz, die mit einer Simulation auf Basis des AUTOSAR-konformen Codes (Software- in-the-Loop) verglichen wird. Dieser Vergleich kann auch dazu dienen, die Güte der Festkomma-Implementierung eines Gleitkomma-Algorithmus zu beurteilen und die Skalierung zu optimieren. Auch das sonstige Testinstrumentarium wie Unterstützung bei der Durchführung von Modell- und Code-Reviews oder Code- Abdeckungsanalysen steht im AUTOSAR- Fall vollständig zur Verfügung, was die Durchführung eines Komponententests in TargetLink aufgrund der kleinen Iterationsschleifen attraktiv macht. _ Für einen Software-Integrationstest im AUTOSAR-Kontext bietet System- Desk umfangreiche Simulations- und Testunterstützung (Bild 4).

Hierdurch kann die Verschaltung einer großen Zahl von Komponenten und deren Zusammenspiel mit der Basis-Software auf Basis einer AUTOSAR-konformen RTE getestet werden. Das Zusammenspiel der Komponenten wird nicht nur auf der Ebene des Virtual Functional Bus simuliert, sondern umfasst auch die Emulation von Modulen der Basis- Software, die Berücksichtigung von Timing-Effekten sowie das korrekte Versenden und Empfangen von Nachrichten auf virtuell simulierten Bussen. Durch diese Vorgehensweise ist es möglich, eine Vielzahl von potentiellen Fehlern sehr früh im Entwicklungsprozess zu erkennen und zu beheben.