Vergessen Sie FlexRay!

Die unzähligen Konfigurationsmöglichkeiten eines FlexRay-Systems reduzieren die Produktivität eines Entwicklungsteams drastisch. Durch die Abstraktion von FlexRay und eine neue Compiler- Technik lässt sich der Fokus jedoch wieder auf innovative Funktionen und solide Algorithmen lenken.

Die unzähligen Konfigurationsmöglichkeiten eines FlexRay-Systems reduzieren die Produktivität eines Entwicklungsteams drastisch. Durch die Abstraktion von FlexRay und eine neue Compiler- Technik lässt sich der Fokus jedoch wieder auf innovative Funktionen und solide Algorithmen lenken.

Wenn es tatsächlich möglich ist, die vielen Detaileinstellungen eines Flex- Ray-Systems und die oft sehr mühsame Erstellung eines FlexRay-Communication- Schedules durch ein Compiler- Werkzeug vollständig automatisieren zu lassen, hat das einen signifikanten Einfluss auf die Entwicklungszeit. Bei einfachen FlexRay-Projekten lässt sich eine Reduktion der Entwicklungszeit um den Faktor 20 feststellen. Bei komplexeren Projekten dürfte sich die Entwicklungszeit sogar noch weiter reduzieren lassen.

Wieviel Zeit haben Sie?

Diese Frage bezieht sich auch auf das Zeitverhalten der Anwendung. Nachfolgend wird gezeigt, dass es genügt, die Zeit für die diversen periodischen Tasks eines Systems festzulegen. Daraus kann ein Compiler-Werkzeug effizient die Software für ein FlexRay- System generieren. Listing 1 spezifiziert eine Software-Komponente Sender etwas vereinfacht in der Timing Definition Language (TDL). Die Komponente Sender hat einen Sensor s1 und einen Aktor a1. Die Task-Funktion senderTask wird periodisch alle 5 ms aufgerufen. „Logical Execution Time“ (LET) bedeutet, dass die Task den Eingang am Beginn einer 5-ms-Periode liest und den Ausgang immer exakt nach 5 ms ausgibt, unabhängig davon, wie lange die Berechnung tatsächlich dauert. Die „Worst Case Execution Time“ der externen Funktion senderTaskImpl muss nur kleiner oder gleich der LET sein. Eine andere Software-Komponente Receiver kann den Output von sender- Task verwenden, weil Receiver die Komponente Sender importiert (Listing 2).

Das Bild zeigt schematisch das spezifizierte Zeitverhalten der beiden Tasks in den Komponenten Sender und Receiver. Die Kommunikation zwischen senderTask und receiverTask findet alle 10 ms statt, und zwar so, dass der Ausgang der sender- Task synchron, also unmittelbar und ohne Verzögerung zu diesem Zeitpunkt an die receiverTask als Eingang übergeben wird. Wenn beide Komponenten auf einem Rechnerknoten beziehungsweise einer ECU sind, kann diese Kommunikation durch ein einfaches Kopieren des Wertes im Hauptspeicher erfolgen.

Wenn die Sender- und Receiver-Software- Komponenten hingegen auf verschiedenen ECU-Knoten liegen, die über einen FlexRay-Bus verbunden sind, muss ein Communication-Schedule generiert und FlexRay entsprechend parametriert werden. Die automatisierte Generierung eines FlexRay- Systems aus einer TDL-Komponenten- Spezifikation übernimmt das TDL:VisualDistributor-Werkzeug von preeTEC (www.preetec.com). Mit diesem Werkzeug kann sowohl die Flex- Ray-Plattform definiert werden als auch die Zuordnung der TDL-Komponeten zu den einzelnen ECU-Knoten. Statt der oben gewählten textbasierten Version zur Modellierung der TDLKomponenten können diese auch grafisch mit dem TDL:VisualCreator- Werkzeug erzeugt werden. Der TDL:VisualCreator lässt sich in Matlab/ Simulink integrieren, dient zur Simulation der Komponenten und garantiert, dass das Verhalten in der Simulation exakt mit dem Verhalten auf einem FlexRay-Cluster übereinstimmt. Der TDL:VisualDistributor kümmert sich bei der automatischen Code-Generierung um die zahlreichen FlexRay- Details. In der neuesten Version können auch bereits definierte FlexRay- Communication-Schedules berücksichtigt werden. So können bereits existierende FlexRay-Projekte problemlos eingelesen und die Vorteile von TDL genutzt werden. W. Pree/sj