1 Model Driven Engineering Jeroen Voeten Eindhoven University of Technology Embedded Systems...
-
Upload
carmella-kelly -
Category
Documents
-
view
218 -
download
0
description
Transcript of 1 Model Driven Engineering Jeroen Voeten Eindhoven University of Technology Embedded Systems...
1
Model Driven Engineering
Jeroen VoetenEindhoven 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
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
Embedded Design Flowconcept
SW HW
design
detaileddesign
#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));
implementation
integrationrepair/debug/maintain
test
7
Implementation
DesignModel
analyze
analyze
DesignModel
DesignModel
refineunderpin
design decisions
abstractAnalysisModel
analyze
Goal: analysis and exploration
Goal: design representation and refinement
Implementation Implementation
Model Driven Engineering Dream
synthesize
: informal: formal
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
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
diemap patterns of electronic
circuits on wafer
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
DesignLight Control
• Combined regular (data flow) and irregular (control)
• Dynamic process creation• Blocking behavior• Dependencies between
consumed and produced event• Data dependent behavior• …
11
Untimed System Behavior
Perform scanTakes x secsQueue scan Queue params Get params
Start scan
Trigger 1Generated engery
Generated energySetpoint
SetpointTrigger 2
Etcetera…
Setpoint
Scan queued
Scan Queued
Scan ready
Scan ready
Scan ready Params
Generated engery
Generated energy
Perform scanTakes x secsQueue scan Queue params Params
Setpoint
SetpointTrigger 3
12
Timing Constraints
Trigger i
Trigger i+1
166 s
250 sScan queued Get params
Start scan
13
Hardware PlatformLight Source
FPGA
PCI-bus, 32-bit, 33MHz
PLX bridge
CPU i64-bit, 133MHz
DDR SDRAM, (183MHz)
SDRAM i
100 Mbps Ethernet
Crossbar Fabric
Switch
ActionInterface
HRT_Sync
64-bit, 133MHz
MAC
PCI
Processor 733MHz512 kB on-chip L2 cache
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
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
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
prio1 prio2 prio3
prio3()() | cycles: Real |
prio3?compute(cycles); [prio1Busy not & prio2Busy not]
delay (cycles / 733); prio2!ready; prio2()().
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…
Setpoint too late…Trigger too late …
Control algorithm should
run at highest priority
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
Forwarding: Robust Solution
Perform scanTakes x secsQueue scan QueueScan queuedScan 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
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 i64-bit, 133MHz
DDR SDRAM, (183MHz)
SDRAM i
100 Mbps Ethernet
Crossbar Fabric
Switch
ActionInterface
HRT_Sync
64-bit, 133MHz
MAC
PCI
Processor 733MHz512 kB on-chip L2 cache
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
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 QTimer qtimer()
set(qtimer, now+2.99)
Model execution semantics is not
respected by the code generators!
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
Top-level model
MoldingmachineContainer
Buffer
Sender
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
FeederBelt
Rotation
Output()() [empty=false]out ! request; sel out? grant or out ? refuse; out ? grant les; out ! finish; empty:=true;Output()().
Rotation
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
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
DesignLight Control
32
Model: Result
Environment (Laser)Embedded Subsystem
33
Model: Analysis
34
Model: Synthesis
1. Replace environment model with interface to environment
2. Predictable code-generation– successfully tested on platform
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
DesignDose Control
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