Testumgebung mit CORBA-Schnittstelle
Der Einsatz der bisher beschriebenen Modelle in Tests setzt voraus, dass das bei BMW vorhandene Test-Framework mit den Modellen interagieren kann. Modena bietet dazu unter anderem eine integrierte CORBA-Schnittstelle, über die Ereignisse und Eigenschaften der Modelle überwacht und geändert werden können (Bild 7).
Das bei BMW eingesetzte Test-Framework basiert auf Python und nutzt die freie CORBA-Implementierung omniORB. Die Bibliothek wxPython ermöglicht die Entwicklung einer grafischen Benutzeroberfläche mit abgestimmtem Inhalt auf einen gegebenen Funktionsblock. Diese integriert sich in eine Standardoberfläche, die allgemeine Funktionen wie etwa die Kontrolle des MOST-Rings erlaubt. Über die grafische Nutzeroberfläche, die letztlich einen Prototyp der BMW iDrive-Benutzerschnittstelle darstellt, kann das Modell konfiguriert und ausgeführt werden. Dabei ist sowohl ein manueller Testbetrieb als auch eine automatisierte Ausführung von Python-Skripten möglich. Das Verhalten der Steuergeräte wird dabei genauso geprüft wie die Korrektheit der MOST-Sequenzen. Abweichungen werden automatisch erkannt und in einem Log-File zur Fehleranalyse gespeichert.
Ein wesentlicher Erfolgsfaktor bei der Entwicklung von Infotainment-Systemen ist die modellbasierte Entwicklung von der Spezifikation bis zur Validierung. Bereits in der Spezifikationsphase führen die ausführbare Simulation und die dadurch ermöglichten Tests nicht nur zu einer Beschleunigung der Lastenheft-Erstellung, sondern auch zu einer deutlichen Verbesserung von Korrektheit und Vollständigkeit der Spezifikation.
In der Integrationsphase lassen sich weitere Geräte aktiv simulieren und in Konsequenz die Entwicklungsprozesse der einzelnen Steuergeräte entkoppeln. Während der Validierung werden die Kommunikation der einzelnen Steuergeräte auf Schnittstellenebene überwacht und Abweichungen erkannt. Der modellbasierte Ansatz bietet aber noch weitaus mehr Potential, beispielsweise die direkte Generierung von Target-Code für ein Steuergerät aus den Modellen. Die Verwendung des Funktionsblockmodells als Bestandteil der Target-Software eines Infotainment-Steuergerätes wird den Entwicklungsaufwand in Zukunft erheblich reduzieren. sj
Autoren: | |
![]() | Dipl.-Inform. Markus Maier studierte Informatik an der Uni Passau. Er verfügt über langjährige Erfahrung im Bereich modellbasierte Software-Entwicklung von Infotainment-Systemen. markus.maier@berner-mattner.com |
![]() | Dipl.-Inform. Marcus Freitag absolvierte sein Studium der Informatik an der Uni Koblenz-Landau. Er leitet die Abteilung für Telematik- und Fahrerassistenzssysteme bei Berner & Mattner in München. marcus.freitag@berner-mattner.com |
Hier kommt der modellbasierte Ansatz zum Tragen: Die Modellierung und Simulation der einzelnen Funktionsblöcke erlauben eine Verifikation des Zusammenspiels der Komponenten schon in der frühen Entwicklungsphase. Aus der textuellen Spezifikation und den vorhandenen Sequenzen entstehen dabei ausführbare und testbare UML-Zustandsdiagramme (Unified Modeling Language). Die Erkenntnisse aus dieser Entwicklungsphase fließen nicht nur in die Lastenhefte ein, sondern erlauben schon in der Implementierungsphase das Testen der realen Steuergeräte. Damit lassen sich die Modelle durchgängig im Entwicklungsprozess verwenden.
Das Prinzip der modellbasierten Entwicklung wird am Beispiel der Infotainmentfunktion AuxiliaryInput erläutert. AuxiliaryInput steht für die nahtlose und komfortable Integration externer Audioplayer über USB, Bluetooth oder einen analogen Audio-Eingang in das BMW-Infotainment-System. Die Steuerung des externen Geräts erfolgt für den Anwender in gewohnter Weise über das BMW iDrive, wobei die BMW-Head-unit im MOST-Ring die Eingaben des Nutzers an den MOST-Funktionsblock AuxIn sendet.
Die Werkzeugkette im Entwicklungsprozess besteht aus dem Case Tool Rhapsody in C++ von IBM, kombiniert mit dem Framework Modena von Berner & Mattner, sowie der Skriptsprache Python. Rhapsody dient zur Erstellung von Modellen mittels UML-Diagrammen und Generierung von C++-Quell-Code aus selbigen. Modena ermöglicht die nahtlose Anbindung der Modelle an ein reales oder simuliertes Bussystem (in diesem Fall MOST), sowie die Steuerung und Testautomatisierung der Modelle mittels der Skriptsprache Python (Bild 3).
Funktionsblockmodell definiert Sollverhalten
Für einen reibungslosen Entwicklungsprozess sind korrekte und vollständige Ergebnisse der Spezifikationsphase die wichtigste Voraussetzung. Für den Funktionsblock AuxIn wurde in die-ser Phase ein Funktionsblockmodell entwickelt, welches das in der textuellen Spezifikation beschriebene Sollverhalten als UML-Zustandsdiagramm abbildet. Über Modena kommuniziert das Modell mit anderen Modellen oder echten MOST-Steuergeräten am MOST-Bus. Die Steuerung übernimmt ein Controller-Modell, das Anfragen an das Funktionsblockmodell sendet und dessen Antworten auswertet.
Während das Funktionsblockmodell üblicherweise die Funktion innerhalb eines Steuergerätes abbildet (vergleichbar mit einem Server), bildet das Controller-Modell den dazu passenden Anteil der Head-unit ab (vergleichbar mit einem Client). Die Entwicklung beider Modelle wird in einem iterativen und inkrementellen Prozess durchgeführt, bei dem schon nach wenigen Stunden eine lauffähige Version entsteht.
Das ausführbare Modell ermöglicht eine Überprüfung der spezifizierten Funktion durch einen Test an einem virtuellen MOST-Ring in einer Simulationsumgebung. Verhält sich das Modell nicht wie erwartet, bietet sich bereits in dieser frühen Phase die Gelegenheit, die Spezifikation anzupassen. Zudem ergänzen aus dem Modell generierte und damit plausible MOST-Sequenzen, die das Kommunikationsverhalten der Komponenten korrekt beschreiben, das Lastenheft der finalen Spezifikation. Diese Sequenzen werden generiert, indem man verschiedene Anwendungsfälle mit dem Controller- und Funktionsblockmodell durchspielt und dabei die Kommunikationsabläufe auf dem virtuellen MOST-Ring aufzeichnet (Bild 4).