Modell-basierte Entwicklung mit der Timing Definition Language (TDL) Prof. Dr. Wolfgang Pree Univ. Salzburg
Inhalt Motivation für einen Paradigmenwechsel bisher: zuerst Plattform, dann Software => Software wird auf Plattform zugeschnitten Ziel: zuerst Software, dann Plattform => Software wird plattform-neutral entwickelt Plattform-neutrale Modellierung mit der Timing Definition Language (TDL) TDL Component-to-ECU-Mapping TDL-Werkzeuge im Entwicklungsprozess 2
Motivation 3
Was bietet TDL? auf verschiedenen Plattformen ausführen K1 SW einmal modellieren dspace 3 mabx 2 Renesas... zeitgest. Ethernet FlexRay-basierte Kommunikation 4
bisher: K1-a K1-b K1-c dspace 3 mabx DeComSys 2 Renesas...... 5
Herausforderung Echtzeit-Software Zeitverhalten Funktionalität Plattform 6
Mit TDL fällt die Plattform-Dimension weg Zeitverhalten Funktionalität Plattform 7
Mit TDL fällt die Plattform-Dimension weg Zeitverhalten sehr vereinfacht Funktionalität Plattform 8
TDL erlaubt, den Fokus auf die Funktionalität zu richten 3D 1,5D Zeitverhalten Funktionalität Plattform 9
20-fach erhöhte Produktivität bei besserer Qualität FlexRay-Entwicklung mit TDL 20x produktiver 1 Personenjahr => 2 Personenwochen deterministisches System: erstmals werden Zeit- & Wert-Determinismus garantiert Simulation und Ausführung auf einem FlexRay- Cluster sind immer äquivalent Flexibilität, die Topologie bzw. Plattform zu ändern automatische Code-/Schedule-Generatoren kümmern sich um die Plattform-Details 10
Die Timing Definition Language (TDL) 11
Was ist TDL? Eine textuelle Sprache, um das Zeitverhalten von Echtzeit- Anwendungen zu beschreiben. [5ms] Tasks Sensoren Aktuatoren 12
Logical Execution Time (LET) release Logical Execution Time (LET) terminate Logische Sicht task invocation time Physische Sicht start suspend resume stop ET <= WCET <= LET Ergebnisse werden exakt zum Zeitpunkt terminate zur Verfügung gestellt 13
TDL-Beispiel component Sender { sensor boolean s1 uses gets1; actuator int a1 uses seta1; public task inc { output int o := 10; uses incimpl(o); } Sender (mode main) s1 inc [5ms] a1 start mode main [period=5ms] { task [freq=1] inc(); // LET = 5ms / 1 = 5ms actuator [freq=1] a1 := inc.o; // update every 5ms mode [freq=1] if exitmain(s1) then freeze; // check every 5ms } } mode freeze [period=1000ms] {} 14
Komponenten-Import component Receiver { } import Sender; task clienttask { input int i1; } mode main [period=10ms] { task [freq=1] clienttask(sender.inc.o); // LET = 10ms / 1 = 10ms } 15 ms Sender Receiver s1 inc [5ms] a1 clienttask [10ms] a1 15
LET-Verhalten unabhängig davon, ob die Komponenten auf einem Single- Node-System oder einem verteilten System ausgeführt werden 5 ms Sender inc inc inc inc t Übertragen des Outputs von inc zu clienttask Receiver clienttask clienttask 10 ms 16
TDL-Modellierung bestehende Reglerimplementierungen TDL-Text mit Texteditor oder visuell/interaktiv mit dem TDL:VisualCreator (Stand-alone-Version) Matlab /Simulink TDL:VisualCreator Simulation und Ausführung auf FlexRay-Cluster sind garantiert äquivalent 17
Beispiel: Aktive Hinterachslenkung (vereinfacht) TDL Komponenten ein Projekt mit MagnaSteyr Fahrzeugtechnik, Graz 18
TDL:VisualCreator als Syntax-gesteuerter TDL Editor Funktionalität mit Matlab /Simulink Blöcken 19
Nahtlose Integration mit Matlab /Simulink 20
Spezifikation des LET-Zeitverhaltens 21
Abbildung auf eine spezifische (FlexRay)- Plattform 22
Spezifikation der Ausführung auf verschiedenen ECUs Sender ECU1 FlexRay bus ECU2 Receiver 23
Transparente Verteilung von TDL-Komponenten TDL-Komponenten verhalten sich exakt gleich (LET-Verhalten), egal ob sie auf einem Knoten oder verteilt über mehrere Knoten ausgeführt werden. Nur das physische Zeitverhalten, das von aussen nicht beobachtbar ist, kann sich ändern. Ein Entwickler einer TDL-Komponente muss sich nicht darum kümmern, wo die Komponente oder davon importierte Komponenten ausgeführt werden. 24
angenommene Ausführungszeiten auf ECU1/ECU2 5 ms Sender inc inc inc inc t ECU1 Receiver ECU2 clienttask 10 ms clienttask 25
Vorgaben für automatische Schedule-Generierung Zeitfenster für Kommunikation Zeitfenster für Kommunikation 5 ms Sender inc inc inc inc t ECU1 Receiver ECU2 clienttask 10 ms clienttask 26
Bus-Schedule-Generierung Sender inc inc ECU1 5 ms Zeitfenster für Kommunikation inc Zeitfenster für Kommunikation inc t lokaler Buffer FlexRay bus Receiver clienttask clienttask lokaler Buffer ECU2 10 ms 27
Component-to-ECU-Mapping(s) Pro Mapping wird ein Distribution block in das Modell platziert: 28
Plattform-Spezifikation und Component-to-ECU-Mapping TDL:VisualDistributor simples Drag & Drop von Komponenten zu ECUs 29
Automatische Code- und Schedule-Generierung 30
TDL-Werkzeuge im V-Modell TDL:VisualCreator in Matlab /Simulink TDL:VisualDistributor Anforderungen Funktionales Modell + timing Code/Schedules generiert für Plattform1 generiert für Plattform2... K1 Validierung Verifikation Test 31
Status und Ausblick TDL-Modellierung: TDL:VisualCreator (TDL-Modellierung) Component-to-ECU-Mapping: TDL:VisualDistributor () TDL:VisualDistributor-PlugIns für spezifische FlexRay-Plattformen inkrementelle Erweiterung von bestehenden Communication Schedules 32
Modellierung von FlexRay-Systemen mit TDL mindestens 20x produktiver als andere modellbasierte Methoden und Werkzeuge Ausführung auf allen gängigen FlexRay- Plattformen, inklusive AUTOSAR und JasPar keine Plattform-/Hersteller-spezifischen Tools erforderlich (TDL ist offener Standard) Investitionssicherheit bisher unerreichte Software-Qualität: Zeit- und Wert-Determinimus 33
Vielen Dank für Ihre Aufmerksamkeit! 34