Vereinfachte FlexRay-Entwicklung mit der „Timing Definition Language“ Die Zeit spielend im Griff

Mit einer geschickt gewählten plattform-neutralen Beschreibung des Zeitverhaltens ist es möglich, die Entwicklungskosten von FlexRay-Software um den gemessenen Faktor 20 gegenüber anderen modellbasierten Methoden und Werkzeugen zu reduzieren. Der Beitrag beschreibt die der „Timing Definition Language“ (TDL) zugrunde liegenden Konzepte und skizziert, wie mit TDL-Werkzeugen FlexRay-Systeme entwickelt werden.

Vereinfachte FlexRay-Entwicklung mit der „Timing Definition Language“

Mit einer geschickt gewählten plattform-neutralen Beschreibung des Zeitverhaltens ist es möglich, die Entwicklungskosten von FlexRay-Software um den gemessenen Faktor 20 gegenüber anderen modellbasierten Methoden und Werkzeugen zu reduzieren. Der Beitrag beschreibt die der „Timing Definition Language“ (TDL) zugrunde liegenden Konzepte und skizziert, wie mit TDL-Werkzeugen FlexRay-Systeme entwickelt werden.

INHALT:
Develop once, deploy anywhere
Die „Logical Execution Time“-Abstraktion
TDL-Komponentenmodell und transparente Verteilung
Entwicklung von TDL-Komponenten
Ausführung von TDL-Komponenten
Links und Literatur
Autor

Das Schlagwort „modellbasiert“ wird derzeit gerne als Attribut für Methoden und Werkzeuge gebraucht, um damit zu suggerieren, dass die Software-Entwicklung einfacher und damit kostengünstiger wird. Leider ist das oft nicht der Fall. Das liegt daran, dass Entwicklungskosten nur dann eingespart werden können, wenn geeignete Konzepte zur Abstraktion der Details eines Systems oder eines Problems existieren.

Bei Echtzeit-Systemen ist das zeitliche Verhalten ausschlaggebend für die korrekte Funktion des Systems. Die Zeitbeschreibungssprache TDL [1, 7] erlaubt die plattform-neutrale Festlegung des Echtzeit-Verhaltens von harten Echtzeit-Systemen, wie zum Beispiel einer aktiven Hinterachslenkung oder künftigen X-by-wire-Systemen. Aus einer TDL- Beschreibung von Software-Komponenten generiert ein Compiler und ein „Bus Schedule“-Generator den nötigen Code, um die Komponenten auf einem spezifischen FlexRay-System ausführen zu können. Dabei wird garantiert, dass das Verhalten sowohl in einer Simulation, etwa mit Matlab/Simulink, und auch auf der Zielplattform exakt der Beschreibung entspricht. Wenn die Plattform nicht genügend Rechenleistung bietet, wird kein Code generiert.

Bild 1 skizziert schematisch die Vorteile der Entwicklung mit TDL, die das Attribut modellbasiert verdient. Eine Software-Komponente (z.B. M1) wird nur einmal entwickelt. Die automatische Code-Generierung erlaubt die Ausführung auf einer beliebigen Plattform, die genügend Ressourcen bietet.

Im Falle von FlexRay könnte M1 beispielsweise einmal auf einem FlexRay-Cluster mit PowerPC-Knoten und dem Betriebssystem AES von Decomsys [5] ausgeführt werden, ein anderes Mal wird der Code für ein FlexRay-Cluster mit MicroAutoBox-Knoten von dSpace [6] generiert.

Develop once, deploy anywhere

Der TDL-Entwicklungsprozess unterscheidet sich daher fundamental von heute üblichen Ansätzen, bei denen die Plattform und die Topologie zuerst festgelegt werden müssen, bevor die Software auf diese Plattformgegebenheiten zugeschnitten wird. Eine Änderung der Plattform oder bereits die Änderung der Topologie (z.B. Erhöhung der Knotenzahl) erfordert typischerweise eine Neuentwicklung. Die Komponente M1 hängt daher von der Plattform ab: M1a wird für die Variante a entwickelt, M1b für die Variante b etc.

Abschliessend haben wir die LET der Task DCMotorController im Modus main (Bild 10) definiert. Es ist zu beachten, dass für jede Task verschiedene LETs in verschiedenen Modi definiert werden können. Die Frequenz von 1 bedeutet, dass die LET 1 ms beträgt (Periode des Modus main, dividiert durch die Frequenz).

Bild 11 zeigt das vollständige Modell der aktiven Hinterachslenkung, das aus den zwei TDL-Komponenten RearActuatorController und VehicleDynamics besteht. Das Subsystem Vehicle modelliert die relevanten Aspekte des Fahrzeugverhaltens.

Der Scope-Block (Bild 12) zeigt das Systemverhalten: Bei niedriger Geschwindigkeit werden die Hinterräder in die andere Richtung als die Vorderräder gelenkt. Bei höheren Geschwindigkeiten zeigen beide Radpaare in die gleiche Richtung.

Um TDL-Komponenten auf Knoten einer bestimmten Plattform abzubilden, wird ein Distribution-Block vom „Simulink Library Browser“ in das Modell gezogen (Bild 13). Dabei lassen sich beliebig viele Zuordnungen von TDL-Modulen zu Plattformen definieren, indem für jede Zuordnung ein Distribution-Block in das Modell platziert wird.

Ein Doppelklick auf einen Distribution-Block öffnet das TDL:VisualDistributor-Werkzeug. Damit können sowohl Plattform und Topologie als auch die Komponenten-zu-Knoten-Zuordnung definiert werden. Ausgehend von einem Decomsys-FlexRay-Cluster, bestehend aus zwei Renesas-Knoten, deren Beschreibung bereits vorliegt, kann die Plattform-Beschreibung in den TDL:VisualDistributor geladen werden (Bild 14). In der Plattform-Beschreibung könnten bei Bedarf FlexRay-Parameter wie die Frame-Größe oder die Größe des statischen und dynamischen Teils festgelegt worden sein.

Die Zuordnung der beiden TDL-Komponenten zu den ECU-Knoten erfolgt durch „Drag and Drop“ der TDL-Komponenten aus dem Ordner Modules zum jeweiligen Knoten. Durch Auswählen des Menü-Eintrages „Build All“ (Bild 15) werden sämtliche benötigten Dateien generiert: der TDL-Quelltext, der C-Code (z.B. mit dem „Real Time Workshop Embedded Coder“) für jede Task-Funktion, der „Bus Schedule“ – auch als Fibex-Datei – sowie die FlexRay-spezifischen Parameter, Einstellungen und makefiles. Nach dem Übersetzen der Quelltexte und dem Laden der ausführbaren Dateien in die einzelnen ECUs verhält sich das System exakt, wie in TDL beschrieben und in Matlab/Simulink simuliert.

Die beiden Werkzeuge TDL:VisualCreator und TDL: VisualDistributor sind als Produkte von preeTEC erhältlich. Gegewärtig werden weitere Zusatzmodule für den TDL:VisualDistributor entwickelt, um unterschiedliche FlexRay-Plattformen zu unterstützen.

Die Werkzeuge werden auch dahingehend erweitert, dass bestehende „Bus Schedules“ eingelesen und bei Bedarf inkrementell erweitert werden können. Damit wird eine Migration von bestehenden FlexRay-Anwendungen zu TDL möglich. sj

Links und Literatur:

[1] Giotto Project – http://embedded.eecs.berkeley.edu/giotto
[2] www.magnasteyr.com
[3] Henzinger, T.A.; Kirsch, C.M.; Sanvido, M.A.A.; Pree, W.: From control models to real-time code using Giotto. IEEE Control Systems Magazine, S. 50 – 64, 23(1), 2003.
[4] J. Templ. TDL Specification – www.preetec.com
[5] www.decomsys.com
[6] www.dspace.com
[7] www.preetec.com