Automobil-Software Effizienter entwickeln mit System-Modellen

Autor / Redakteur: Wolfgang Krenzer* / Martina Hafner

In der modernen Fahrzeugelektronik adressieren viele Einzellösungen und Werkzeuge heute isolierte Themenkreise in den Bereichen Mechanik, Elektrik/Elektronik und Software. Die komplexen Zusammenhänge erfordern es, eine übergeordnete Architektur und eine integrierte Gesamtsystementwicklung zu betrachten. Womit arbeitet man in frühen konzeptionellen Phasen der Entwicklung, um die bestmögliche Implementierungsentscheidung ausgehend von den Produktanforderungen zu treffen?

Firmen zum Thema

( Archiv: Vogel Business Media )

In der Automobilindustrie vollzieht sich seit längerem ein Wandel hin zu komplexeren Fahrzeugsystemen aus vernetzten Komponenten aller Funktionsbereiche. Die Systemfunktion lässt sich nur durch das Zusammenspiel vieler Komponenten erreichen, die von verschiedenen Herstellern und aus unterschiedlichen Anforderungsspezifikationen stammen. Diese vernetzten, Domänen übergreifenden Systeme erhöhen die Komplexität der Beschreibung vielfach und erfordern es, Entwicklungsmethoden und -prozesse sowie die Entwicklungsumgebung grundlegend anzupassen.

Zahlreiche Einzellösungen und Werkzeuge adressieren isolierte Themenkreise für die Mechanik, Elektrik/Elektronik und Software. Die komplexen Zusammenhänge erfordern es jedoch, eine übergeordnete Architektur sowie eine integrierte Gesamtsystementwicklung zu betrachten. In der Mechanikentwicklung sind die Begriffe Modellierung und Simulation schon lange verbreitet und in den verschiedensten Werkzeugen umfangreich unterstützt. Auch in der Softwareentwicklung hat sich in den letzten Jahren verstärkt die Modellierung als zielführende Entwicklungsmethode etabliert. Nur die Beschreibung von komplexen Gesamtsystemen hinkt dem leider hinterher.

Bildergalerie

Warum System-Modellierung?

Modelle machen uns ein Bild von dem, was wir als Endprodukt erreichen wollen. Sie erlauben den Übergang (Transformationen) von Abstraktionen und leicht verständlichen Verhaltensbeschreibungen eines Systems zu komplexen und sehr detailreichen Beschreibungsdarstellungen und der automatisierten Generierung von Artefakten. Viele etablierte Vorgehensweisen in der Funktionsmodellierung finden bereits in einer speziellen Funktionsdomäne statt (Mechanik, Software, Elektronik etc.), d.h. man hat bereits eine Entscheidung getroffen, wie eine bestimmte Funktion zu realisieren ist.

Wie jedoch kommt man zu dieser Entscheidung? Womit arbeitet man in frühen konzeptionellen Phasen der Entwicklung, um die bestmögliche Implementierungsentscheidung gemäß den Produktanforderungen zu treffen? Hier setzt ein strukturiertes „System Engineering“ an. Als Zielführende Methoden empfehlen sich die Modellgetriebene Systementwicklung und Architektur (Model driven system engineering – MDSE; Model driven systems architecture - MDSA).

Mehrschichtig angelegte Architekturansicht

Um Systeme und deren Verhalten im Gesamtkontext zu beschreiben, ist das Konzept einer mehrschichtig angelegten Architektursicht wichtig. In mehreren Ebenen sollten zunächst die Anforderungen an ein System in einer Modellsicht dargestellt werden, um danach in weiteren Detaillierungsschritten z.B. Use Cases, Logisches Systemverhalten, Subsystem Partitionierung und Implementierungsmodelle in den verschiedenen Systemsichten zu erfassen.

Bild 1: Bei der Beschreibung von Systemen und deren Verhalten im Gesamtkontext ist eine mehrschichtig angelegte Architektursicht wichtig. In mehreren Ebenen werden zunächst die Anforderungen an ein System in einer Modellsicht dargestellt werden, um danach in weiteren Detaillierungsschritten z.B. Use Cases, Logisches Systemverhalten, oder Implementierungsmodelle in den verschiedenen Systemsichten zu erfassen. (Archiv: Vogel Business Media)

Hier kommt es darauf an, die einzelnen Artefakte in ihren logischen Abhängigkeiten und Interaktionen zu verknüpfen und diese Verbindungen über die gesamte Lebensdauer der Entwicklung (und des Produkts) aufrecht und nachvollziehbar zu erhalten. Dies ist eine essentielle Anforderung an eine Entwicklungsumgebung, die eine moderne Systems Engineering Methode hinreichend unterstützt. Bild 1 verdeutlicht diese Zusammenhänge.

UML und SysML – ein kurzer Hintergrund

Bild 2: Zusammenhang zwischen UML und SysML (Archiv: Vogel Business Media)

Die UML (Unified Modeling Language) ist nicht nur eine standardisierte Beschreibungssprache für die Software-Entwicklung, sondern stellt in ihrer Gesamtstruktur auch ein Metamodell für die Erzeugung neuer Beschreibungssprachen dar. Für die Beschreibung von Systemen hat man z.B. die UML um spezielle Komponenten erweitert, respektive angepasst. Daraus ist die Beschreibungssprache SysML entstanden. Nicht alle Komponenten der UML werden darin verwendet, so dass sich eine Überlappung der beiden Sprachräume ergibt (Bild 2).

Trennung von fachlichen und technischen Modellen

Modell-Transformationen sind ein wesentliches Element von MDSE/MDSA. Sie unterstützen die verschiedenen Phasenübergänge von Analyse zu Design, von Design zu Implementierung, etc. und sorgen für konsistente Sichten auf die System Architektur. Im Kern besteht der Ansatz der Modellierungsmethodik, fachliche und technische Teile eines Systems in Form von plattformunabhängigen Modellen (PIM) und plattformspezifischen Modellen (PSM) zu trennen, die unabhängig voneinander wieder verwendet werden können. Diese Begriffe der Software-fokussierten MDA müssen für die Systementwicklung sinnvoll interpretiert werden.

In den PIMs wird das logische Verhalten des Systems technologieunabhängig erfasst und modelliert. Ergänzend wird in den plattformspezifischen Modellen die Implementierungstechnologie definiert, d. h. die technischen Aspekte bezogen auf eine konkrete Realisierung. Hierbei kommen die spezifischen Implementierungs-Domänenaspekte zum Einsatz. Die Trennung in logische Funktionsebene und Implementierungsebene unterstützt die Wiederverwendbarkeit von Lösungsaspekten in beiden Bereichen.

Um MDSA im gesamtheitlichen System Engineering zu verwenden, wo neben der Software auch mechanische und elektronische Komponenten einbezogen sind (in der KFZ Industrie gerne auch als mechatronische Systeme bezeichnet), wird es für die sinnvolle Automatisierung von Transformationen erforderlich sein, die unterstützenden Werkzeuge und vorgefertigten Komponenten zu erweitern. Grundsätzlich ist der Einsatz jedoch mit den heute verfügbaren Produkten wie z.B. dem Rational Systems Developer mit SysML Unterstützung bereits möglich. Auch die Unterstützung von automobilen Standards wie AUTOSAR ist dabei gefordert. Wie dies gewährleistet werden kann ist an anderer Stelle bereits beschrieben worden. [1]

Vom abstrakten zum funktionsspezifischen Modell

Die grundsätzliche Motivation modellgetriebene Architekturen für die Systementwicklung anzuwenden basiert auf der Überlegung, dass jede Änderung im Entwicklungsprozess Änderungen auf den einzelnen Abstraktionsebenen nach sich zieht. Diese stehen aber in einem umgekehrt proportionalen Verhältnis in ihrem Umfang zum Abstraktionsgrad. Somit müssen die abstrakteren Modelle entsprechend seltener und weniger umfangreich geändert werden.

Der Übergang von den abstrakteren Modellen (logische Verhaltensmodelle und Architektursichten) zu den mehr funktionsspezifischen Modellierungen (z.B. Matlab + Simulink, Catia oder Ascet Modelle) und die weitere Ableitung von konkret implementierten Lösungsartefakten (Software-Code, Elektronisches Blockschaltbild, Hinterachsmodell etc.) erfolgt auf Basis der Modell-zu-Modell-Transformationen, die zumindest teilweise automatisch auf Basis von Plattformprofilen durchgeführt werden. Dies sichert die Langlebigkeit, Integrierbarkeit und Portierbarkeit der Modelle sowie deren Abbildung auf spezifische Implementierungen.

Durch die Automation dieser Entwicklungsschritte, speziell im Bereich Simulation/Validierung von Architekturmodellen, sowie in der Software-Systementwicklung lassen sich die riesigen Artefaktumfänge der komplexen Systeme im Fahrzeug erzielen und beherrschen.

Diese Entwicklung ist analog zu anderen Industrien, z.B. der Telekommunikation, zu sehen, wo sich komplexe Projekte mit mehreren Millionen LOC (Lines of Code als Maß für die Größe von Software-Artefakten, teilweise Indikator für Komplexität) nur mittels automatischer Code- Generierung beherrschen lässt. Diese Vorgehensweise bedingt zwangsläufig einen Modellansatz.

Funktionale Modelle mit spezialisierten Modellierungs- und Simulationswerkzeugen

Die Ebene der funktionalen Modellierung ist häufig bereits im Bereich der Implementierung angesiedelt, so dass hier die mehr spezialisierten Modellierungs- und Simulationswerkzeuge zum Einsatz kommen. Sie werden durch die vorhergehend beschriebene Modellierung nicht ersetzt, sondern um einen logisch zusammenhängenden Überbau ergänzt, der den Übergang von der Anforderungsanalyse über die Implementierungsentscheidung bis zur konkreten Implementierung in den funktionalen Domänen herstellt und den Gesamtkontext des System erhält.

Integrierte Werkzeugkette ist unverzichtbar

Absolut unumgänglich für die diese Vorgehensweise ist es, die Werkzeugkette zu integrieren. Und zwar nicht nur im Sinne einer Tool-zu-Tool -Schnittstelle, sondern im Besonderen in der Bereitstellung einer Datenkonsistenzschicht sowie der Möglichkeit zur Verkopplung mit den Entwicklungsprozessen und der interaktiven Ausführung von Prozessmodellen.

Hierbei unterstützen offene Standards wie die Eclipse-Plattform für die Werkzeugintegration und neue Kollaborationsplattformen wie Jazz (www.jazz.net) weitreichend. Im Sinne eines kurzen Überblicks sei hierzu jedoch auf die Infoclick-Links (siehe Ende des Beitrags) verwiesen.

Zusammenfassend lässt sich sagen, dass diese Vorgehensweise eine durchgängige Verknüpfung aller Entwicklungsartefakte sowie eine bessere und konsistente Anforderungsübergabe bietet, von den ersten Konzeptbeschreibungen eines KFZ-Systems bis zur Detailumsetzung in der Implementierungsphase. Datenbrüche bei der Fortschreibung von Entwicklungsartefakten werden weitgehend ausgeschlossen und die durchgängige Automatisierung schafft weitere Effizienzsteigerungen und Kostensenkungen bei höherer Gesamtqualität. Die schnellere und eindeutigere Abstimmung zwischen den Funktionsbereichen trägt zu einer besseren Produktqualität und schnelleren Validierung des Gesamtsystems bei.

*Wolfgang Krenzer ist Technical Solution Lead Europe bei IBM ESLM (Embedded Systems Lifecycle Management Solutions) in Frankfurt. Kontakt: wolfgangkrenzer@de.ibm.com

Artikelfiles und Artikellinks

(ID:239185)