1. 1 Model Driven Engineering Jeroen Voeten Eindhoven University of Technology Embedded Systems Institute Artist Meeting Linköping May 14, 2007

2. 2 Ideals Project Goal: Complexity reduction by separation of concerns AOP – Separate cross-cutting concerns from basic application logic MDE – Separate technological concerns from application logic - September 2003 - February 2008 - 10 fte/yr - 6 partners - 4 M Euro

3. 3 Embedded System Design State of Practice Embedded systems –Real-time –Concurrent –Hardware, embedded software, mechtronics, … Concurrent engineering with multiple disciplines Engineering deliverables are integrated just before shipment Design problems turning up during integration require rapid reengineering and release of upgrades in the field

4. 4 Encountered Problems Integration –Too many design problems are detected too late –Unpredictable integration phase, both w.r.t. time and outcome Evolvability –Key performance parameters are tightened  mutual dependencies, increasing functionality, tighter performance requirements –Calls for occasional system redesign –Considered to be too time consuming  not done –Instead detailed, competency-driven design optimizations are made –This is risky, inefficient and endangers future evolvability

5. 5 Technical Problem Analysis Integration: Why do design problems turn up in the first place? –There is a lot of design documentation, but given in the form of text and block diagrams –System behavior and the impact of design decisions cannot be verified Evolvability: Why is system redesign so difficult? –Design documentation is low-level and discipline-dependent –To redesign one has to 1.Understand the essential system behavior. Is difficult since essential behavior is not represented explicitly 2.Change and/or extend design 3.Re-implement design. Is time consuming because of complexity

6. 6 Embedded Design Flow concept SW HW design detailed design #include #define MAX_LINE 256 int main(int argc, char* argv[]) { struct sockaddr_in server_address; char buf[MAX_LINE]; … n = strlen(buf); send(s,buf,n,0); n=recv(s, buf, sizeof(buf), 0); buf[n] = '\0'; inet_ntoa(server.sin_addr)); implementation integration repair/debug/maintain test

7. 7 Implementation Design Model analyze Design Model Design Model refine underpin design decisions abstract Analysis Model analyze Goal: analysis and exploration Goal: design representation and refinement Implementation Model Driven Engineering Dream synthesize : informal : formal

8. 8 Analysis Models: Case Study Light Control Subsystem Twinscan Platform “We expect timing problems with this system” “We expect the problem to lie in the on-board communication switch” “Can you analyze the problem and derive a solution?”

9. 9 Light Control subsystem ActionInterface Wafer Control Light Control machine control Reticle Control … HRT_Sync Perform scan action Generate light pulses at the right time instances following a given light intensity profile to expose one cell on wafer light source reticle lens wafer slit die map patterns of electronic circuits on wafer

10. 10 Behavior Model Executable model (POOSL) –Concurrency, stochasticity, non-determinism, real-time –Synchronous message passing, object-oriented data –Choice, parallel composition, abort, interrupt, … Formal semantics –Real-time probabilistic labelled transition system Design Light Control Combined regular (data flow) and irregular (control) Dynamic process creation Blocking behavior Dependencies between consumed and produced event Data dependent behavior …

11. 11 Untimed System Behavior Perform scanTakes x secsQueue scan Queue params Get params Start scan Trigger 1Generated engery Generated energySetpoint Trigger 2 Etcetera… Setpoint Scan queued Scan Queued Scan ready Params Generated engery Generated energy Perform scanTakes x secsQueue scan Queue params Params Setpoint Trigger 3

12. 12 Timing Constraints Trigger i Trigger i+1 166  s  250  s Scan queued Get params Start scan

13. 13 Hardware Platform Light Source FPGA PCI-bus, 32-bit, 33MHz PLX bridge CPU i 64-bit, 133MHz DDR SDRAM, (183MHz) SDRAM i 100 Mbps Ethernet Crossbar Fabric Switch ActionInterface HRT_Sync 64-bit, 133MHz MAC PCI Processor 733MHz 512 kB on-chip L2 cache

14. 14 Mapping Light Source FPGA PCI-bus, 32-bit, 33MHz PLX bridge 64-bit, 133MHz DDR SDRAM, Ethernet Crossbar Fabric Switch ActionInterface HRT_Sync 64-bit, 133MHz Processor VXWorks Possible timing problem caused by priority assignment No timing problem; relative short and predictable delays

15. 15 Model Extension To analyze the impact of priority assignment, extend executable model with Processor/scheduler model and mapping VXWorks scheduling –FCFC per priority –higher priority can pre-empt lower priority

16. 16 POOSL model of Processor/scheduler start()() prio1Busy:=false; prio2Busy:=false; par prio1()() and prio2()() and prio3()() rap. prio1()() | cycles: Integer | prio1?compute(cycles){prio1Busy:=true}; delay (cycles / 733); prio1!ready{prio1Busy:=false}; prio1()(). prio2()() | cycles: Real | prio2?compute(cycles){prio2Busy:=true}; [prio1Busy not] delay (cycles / 733); prio2!ready{prio2Busy:=false}; prio2()(). ProcessorWithScheduler prio1prio2prio3 prio3()() | cycles: Real | prio3?compute(cycles); [prio1Busy not & prio2Busy not] delay (cycles / 733); prio2!ready; prio2()().

17. 17 Initial Mapping Perform scan Get params Start scan Generated engerySetpoint Scan queued Scan Queued Takes x secsQueue scan Queue Forward Trigger Generated engerySetpoint too late… Trigger too late … Control algorithm should run at highest priority

18. 18 Mapping: Swap Priorities Perform scan Start scan Scan queued Scan Queued Takes x secsQueue scan Queue NO params !! Parameter forwarding at higher priority?

19. 19 Forwarding: Robust Solution Perform scanTakes x secsQueue scan Queue Scan queued Forward ! The deadline of 250 is no issue anymore; forwarding can now run at user priority

20. 20 Case Study: Conclusions Modeling the system to analyze performance properties was valuable –provided ‘insight’ in overall system behaviour –design document provide many details, but do not shed light on ‘the big picture’ and are ‘dead’ –executable model combines separate pieces into one unified whole –feedback from model eases communication with design team –understand, verify and explore design alternatives before implemented in HW/SW components –e.g. effect of priority assignments could be investigated –e.g. timing problem w.r.t. parameter forwarding was found during model construction, provided inspiration and possibilities for verification

21. 21 Analysis Models: Major Concerns Heterogeneity –specialized languages and tools for different aspects (correctness, performance, exploration, …) –general-purpose modeling languages –what language to choose? Predictability –no (formal) relation between the different models and the realization –unknown reliability/accuracy of predictions Refinement –analysis models are no suitable starting point for systematic refinement / synthesis –do we have to make models just for analysis?

22. 22 Design Models Use models to derive implementation in a systematic way  model refinement and synthesis Split QueueGenerate code Light Source FPGA PCI-bus, 32-bit, 33MHz PLX bridge CPU i 64-bit, 133MHz DDR SDRAM, (183MHz) SDRAM i 100 Mbps Ethernet Crossbar Fabric Switch ActionInterface HRT_Sync 64-bit, 133MHz MAC PCI Processor 733MHz 512 kB on-chip L2 cache

23. 23 Challenge: Predictability Predictability –Make sure the refined model/realization behaves as the model –Make sure that real-time model properties are preserved MDA/UML does not deal with these issues (yet) –Most work on syntactic transformations  key problem is in semantics (behavior), not in syntax –No predictable commercial UML tool available

24. 24 Predictability Problem: Example Tau G2 pwait reply_signal ptimer Process P syn_signal Charstring wout=“wrong” ; Charstring cout=“correct” ; Timer ptimer() set(ptimer, now+3) out_signal(cout) out_signal(wout) reset(ptimer) reply_signal qwait qtimer qstart syn_signal qstart Process Q Timer qtimer() set(qtimer, now+2.99) Model execution semantics is not respected by the code generators!

25. 25 Predictable Approach Formal Semantics: Timed Labeled Transition System Generate timed trace from transition system –virtual (model) time is kept –ordering of events is kept Run-time synchronization upto  of virtual time with physical time –if an action happens at virtual time t in the model it must happen in physical time interval (t-  /2,t+  /2) in implementation –every (MTL) formula in model is preserved upto  in realization –epsilon can be determined by model simulation / exhaustive analysis or by measurement –Huang, Voeten, Corporaal, Predictable real-time software synthesis, Real-Time Systems journal (online), March 2007 Predictable method –from abstract executable models to implementation –via property-preserving refinements –Huang, Voeten, Corporaal, A model-driven approach for mechatronic systems, to be published in ACSD 2007

26. 26 Example: A production cell

27. 27 Top-level model Molding machine Container Buffer Sender

28. 28 Top-level model: behavior Input()() in? request; sel [empty=true] in! grant or [empty=false] in ! refuse; [empty=true] in ! grant les; in? finish; empty:=false; Input()(). Buffer Feeder Belt Rotation Output()() [empty=false]out ! request; sel out? grant or out ? refuse; out ? grant les; out ! finish; empty:=true; Output()(). Rotation

29. 29 Top level model: properties Properties that can be checked: –At most one block in the buffer –The rotation player will not insert a block to the feeder belt, if there is a block at the left end. –Nine blocks or more  potential deadlock –Less than 9 blocks  deadlock free –…

30. 30 Refinement and synthesis Local property-preserving refinement Separation of discrete-event and continuous behaviour Addition of feedback control loops (automatically generated from 20-Sim) Predictable code generation

31. 31 Example: Light Control Starting point –Design documentation (a lot) –Performance model in POOSL Construct POOSL model –Powerful language constructs Facilitates problem domain mapping –Incremental modeling with immediate behavioral feedback simulation dynamic model inspection automatically generated MSCs Design Light Control

32. 32 Model: Result Environment (Laser) Embedded Subsystem

33. 33 Model: Analysis

34. 34 Model: Synthesis 1.Replace environment model with interface to environment 2.Predictable code-generation –successfully tested on platform

35. 35 Case Studies: Conclusions Big picture is quickly obtained through executable model  replace/supplement documentation with executable models in future Incremental modeling with behavioral feedback is very powerful Expressive modeling languages narrow the gap between domain concepts and implementation Predictable automatic code generation is feasible Step-wise property-preserving refinement approach works very natural for production cell –still have to apply it to light control model –current model is too complex and detailed No clear relation with performance modeling –Performance prediction from top-level model e.g. is not possible Design Dose Control

36. 36 Future Challenges Code efficiency (performance, footprint) Predictable refinement and synthesis for multi-processor platforms Heterogeneity –control and data-flow –discrete-event and continuous-time –mixing hard and softly timed subsystems –hardware and software implementations Seamless integration of analysis and design models into Model-Driven Design Flows –for different application domains