Modell-basierte Entwicklung mit der Timing Definition Language (TDL)

Transkript

1 Modell-basierte Entwicklung mit der Timing Definition Language (TDL) Prof. Dr. Wolfgang Pree Univ. Salzburg

2 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

3 Motivation 3

4 Was bietet TDL? auf verschiedenen Plattformen ausführen K1 SW einmal modellieren dspace 3 mabx 2 Renesas... zeitgest. Ethernet FlexRay-basierte Kommunikation 4

5 bisher: K1-a K1-b K1-c dspace 3 mabx DeComSys 2 Renesas

6 Herausforderung Echtzeit-Software Zeitverhalten Funktionalität Plattform 6

7 Mit TDL fällt die Plattform-Dimension weg Zeitverhalten Funktionalität Plattform 7

8 Mit TDL fällt die Plattform-Dimension weg Zeitverhalten sehr vereinfacht Funktionalität Plattform 8

9 TDL erlaubt, den Fokus auf die Funktionalität zu richten 3D 1,5D Zeitverhalten Funktionalität Plattform 9

10 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

11 Die Timing Definition Language (TDL) 11

12 Was ist TDL? Eine textuelle Sprache, um das Zeitverhalten von Echtzeit- Anwendungen zu beschreiben. [5ms] Tasks Sensoren Aktuatoren 12

13 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

14 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

15 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

16 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

17 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

18 Beispiel: Aktive Hinterachslenkung (vereinfacht) TDL Komponenten ein Projekt mit MagnaSteyr Fahrzeugtechnik, Graz 18

19 TDL:VisualCreator als Syntax-gesteuerter TDL Editor Funktionalität mit Matlab /Simulink Blöcken 19

20 Nahtlose Integration mit Matlab /Simulink 20

21 Spezifikation des LET-Zeitverhaltens 21

22 Abbildung auf eine spezifische (FlexRay)- Plattform 22

23 Spezifikation der Ausführung auf verschiedenen ECUs Sender ECU1 FlexRay bus ECU2 Receiver 23

24 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

25 angenommene Ausführungszeiten auf ECU1/ECU2 5 ms Sender inc inc inc inc t ECU1 Receiver ECU2 clienttask 10 ms clienttask 25

26 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

27 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

28 Component-to-ECU-Mapping(s) Pro Mapping wird ein Distribution block in das Modell platziert: 28

29 Plattform-Spezifikation und Component-to-ECU-Mapping TDL:VisualDistributor simples Drag & Drop von Komponenten zu ECUs 29

30 Automatische Code- und Schedule-Generierung 30

31 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

32 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

33 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

34 Vielen Dank für Ihre Aufmerksamkeit! 34