1 / 36

Model Driven Engineering

Model Driven Engineering. Jeroen Voeten Eindhoven University of Technology Embedded Systems Institute. Artist Meeting Link ö ping May 14, 2007. Ideals Project. Goal: Complexity reduction by separation of concerns AOP – Separate cross-cutting concerns from basic application logic

aelwen
Télécharger la présentation

Model Driven Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. Embedded System DesignState 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. 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. 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 • Understand the essential system behavior. Is difficult since essential behavior is not represented explicitly • Change and/or extend design • Re-implement design. Is time consuming because of complexity

  6. concept HW SW design detailed design implementation #include<winsock.h> #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)); integration repair/debug/maintain test Embedded Design Flow

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

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

  10. Design Light Control • Combined regular (data flow) and irregular (control) • Dynamic process creation • Blocking behavior • Dependencies between consumed and produced event • Data dependent behavior • … 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

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

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

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

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

  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. prio1 prio2 prio3 ProcessorWithScheduler 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()(). prio3()() | cycles: Real | prio3?compute(cycles); [prio1Busy not & prio2Busy not] delay (cycles / 733); prio2!ready; prio2()(). prio2()() | cycles: Real | prio2?compute(cycles){prio2Busy:=true}; [prio1Busy not]delay (cycles / 733); prio2!ready{prio2Busy:=false}; prio2()().

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

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

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

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

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

  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. Example: A production cell

  27. Buffer Molding machine Container Sender Top-level model

  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()(). Rotation Buffer Output()() [empty=false]out ! request; sel out? grant or out ? refuse; out ? grant les; out ! finish; empty:=true; Output()(). Rotation Feeder Belt

  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. 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. Design Light Control 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

  32. Embedded Subsystem Environment (Laser) Model: Result

  33. Model: Analysis

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

  35. Design Dose Control 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

  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

More Related