420 likes | 821 Views
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
E N D
Model Driven Engineering Jeroen Voeten Eindhoven University of Technology Embedded Systems Institute Artist MeetingLinköping May 14, 2007
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
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
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
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
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
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
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?”
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
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
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
Start scan 250 s Get params Scan queued Trigger i 166 s Trigger i+1 Timing Constraints
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
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
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
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()().
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
Mapping: Swap Priorities Scan Queued Start scan NO params !! Queue Perform scan Scan queued Takes x secs Queue scan Parameter forwarding at higher priority?
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
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
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?
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
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
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
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
Buffer Molding machine Container Sender Top-level model
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
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 • …
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
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
Embedded Subsystem Environment (Laser) Model: Result
Model: Synthesis • Replace environment model with interface to environment • Predictable code-generation • successfully tested on platform
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
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