O On a Specific Model-Based Architectu ure Description Language: - - PowerPoint PPT Presentation
O On a Specific Model-Based Architectu ure Description Language: An Appr roach Based on Standards Sbastien Grard, Bran Selic Sbastien Grard, Bran Selic CEA-LI ST Labo oratory of m odel driven engineering for em bedded system s
O Architectu An Appr
Labo
On a Specific Model-Based ure Description Language: roach Based on Standards
Sébastien Gérard, Bran Selic† Sébastien Gérard, Bran Selic CEA-LI ST
for em bedded system s for em bedded system s
†( Malina Softw are Corp and
Zeligsoft Lim ited)
Sebastien.Gerard@cea.fr @ selic@acm .org
Thesis: A Stan
The CEA LI ST app oach to com
Component Paradigm Paradigm
S1 S3 e1 e3Archite Archite Specific Specific Model-Based Engineering
S2 e1 e2Specific Specific Archite Archite Descri Descri Langu Langu Engineering St d d Standards
ndards-Based ADL Approach
m ple s stem of s stem s design m plex system of system s design
Computer Computer-
Based Tools Tools ectural ectural cations cations Tools Tools cations cations ectural ectural iption iption uage uage
The Problem : Real-Tim
tools
constraints
contradictory requirements
Mechanical system
System System
m e System of System s Developm ent
sponding to real-w orld events
Software system y
m
Electronics system
Requirem e
designed sub-system s
R i “bi i t ” h i
“The fundamental organization of a s relationships to each other and to th relationships to each other, and to th its design and evolution”
Facilitates communications between s requirements
pervasive artifact)
ent: System -Level Approach
than as an aggregate of separately hit t e., an architecture 1 ] : system embodied in its components, their he environment and the principles guiding he environment, and the principles guiding stakeholders and resolution of conflicting stakeholders and resolution of conflicting qualities (e.g., performance, robustness) g and implementation (architecture as a
Requirem ent: Sup
End-user Sales and field support System
Comp1 Comp2
Development manager
Comp3
Developer Tester
porting an I terative Process
tely in one pass icting design choices gain understanding and intuition
Functionality Technology Process .etc Skills Organization and Qualities Skills Organization and culture Business Concerns
Arbiter
Display
Architect
Architectural Exploration Exploration
Automation Automation Support Support
How Architectur
inform al analyses)
E l d t ti f t ti l d i fl
Critical understanding g threshold reached through model evaluation
T2
ral Exploration Reduces Risk
m odels ( using sim ulation, form al and l i t fi aws ⇒ less expensive to fix
Critical understanding g threshold reached through implementation evaluation Problem Understanding/Confidence
Cost of Design
t
Design Risk
g Change
t
T1
Arch
⇒ architectural specifications abstrac ⇒ i.e., they are m odels
Purposeful (i.e., intended for specific
Accurate (i.e., faithfully represent e
requirem ents on m odeling languages ( architectural description languages Wh t h ld ADL f l ti
hitectures, Models, and ADLs
undam ental organization…” ct out non-fundam ental detail g m odels purposes/ viewpoints/ domains/ audiences) purposes/ viewpoints/ domains/ audiences) tial detail) end for intended audience) lements of interest) lements of interest) ct key system characteristics)
articular, im pose im portant s for describing architectures ( ADLs) ) t f t l k lik ? stems of systems look like?
Key I ngredients fo
[1] Component Paradigm
S1 S3 S2 e1 e2 e3[2] Model-Based Engineering [3] Standards
RT Architectural Description RT Architectural Description Description Language Description Language
[ 1
Component Paradigm
generally have identity and may have Pressure Sensor
«flowPort» in : Pressure
[pmeasured(t)]
Compone t generate possibly
Pressure Sensor
«flowPort» in : Pressure «flowPort» pressure : Real
Sensor
«flowPort» pressure : Real
C nn t : R p nt Connector: Represents physical coupling or a communication path
1 ] The Com ponent Paradigm
nents both physical and logical elements, which e state
«flowPort» pressure : Real
Port: Distinct interaction ent: Responds to and t /fl point for particular types of events/flows es events/flows, based on its state
Threshold Detector
«clientServerPort» alarmOut : Binary
Detector
Extending the
Component Paradigm
d and,
factors m ust be accounted for during factors m ust be accounted for during
CompA Co CompA Co Th d1 T S k t Thread1 T Socket Operating System/SW Framewo
Hardware Platform Hardware Platform
Com ponent Paradigm for Real-Tim e
w are com ponents are a function of form stack (e.g., performance, reliability)
ality of service of our system s ⇒ these g design g design
mpB Deployment: allocation of components to platform mpB Th d2 components to platform elements Thread2
Platform: combination of software and hardware required to execute an q application
[ 2 ] Model-B
Model-Based Engineering
S1 S3 S2 e1 e2 e3m odels play an indispensable role
g g
(1) ABSTRACTION
S1 S3
e3/action3
Realm of
S2
e1/action1 e2/action2
Realm of modeling languages
switch (state) { case‘1:action1; newState(‘2’); break; case‘2:action2; case 2:action2; newState(‘3’); break; case’3:action3; newState(‘1’); break;}
ased Engineering ( MBE)
re developm ent in w hich softw are
(2) AUTOMATION
S1 S3
e3/action3
Realm of
S2
e1/action1 e2/action2
Realm of tools
switch (state) { case‘1:action1; newState(‘2’); break; case‘2:action2; case 2:action2; newState(‘3’); break; case’3:action3; newState(‘1’); break;}
Model-Based Engineering
S1 S3 S2 e1 e2 e3g g
p p y
Modeling Modeling Tool Tool
4 5 3.1 3.1 2.5 2.5 Performance Performance annotations
Autom ation in MBE
ations, code generation
ML models using queueing theory g q g y
Automated model transformation
Performance Performance A l i T l A l i T l Analysis Tool Analysis Tool
μ
Automated f inverse transformation
Standards
technological progress
Standards
technological progress
y pp p
(no need to worry too much about ot
providing a UML editing tool
Users have a choice of different vend
[ 3 ] Standards
d the m ost dram atic boosts to fferent specialization domains
ther specialties) ng UML models need not worry about nce dors (no vendor “tie in”) dors (no vendor “tie-in”) mproving their products
W
Standards
Architecture initiative
Standards
modeling languages:
S t d b i t d
tools) (accuracy)
Can take advantage of UML 2 tools (t
g y y
hich Standards for the ADL?
G) has created the Model-Driven support of MBE including standard support of MBE including standard
f Real-Time and Embedded Systems (MARTE) ysML)
many (understandability) t l (t l t)
ized for real-time and systems (accuracy)
rm and allocation
tool support) tool support) ictiveness) stems (accuracy) ( y) nd their respective tools (tool support)
UML 2 : The S
«profile» «profile»
MARTE MARTE
«profile» «profile»
S ML S ML Higher Higher-level behavioral level behavioral MARTE MARTE SysML SysML
. . .
Higher Higher level behavioral level behavioral
UML UML statechart statechart semantics semantics UML UML activities activities semantics semantics Higher Higher-
level UML action UML action semantics semantics M
Foundational UML Foundational UML (fUML) ac (fUML) ac (action executions, token (action executions, token
Generic Generic UML VM UML VM ( ith ( ith
fUML structural elements (ob fUML structural elements (ob
(with (with semantic semantic variation variation points) points)
fUML structural elements (ob fUML structural elements (ob
Shared Sem antic Foundation
«profile» «profile»
P fil XYZ P fil XYZ formalisms formalisms ProfileXYZ ProfileXYZ formalisms formalisms
UML UML interactions interactions semantics semantics UML UML Action Language(s) Action Language(s) Map (compile) to Map (compile) to
ction semantics ction semantics n flows, etc.) n flows, etc.)
Specified Specified by by Basic UML Basic UML (bUML (bUML fUML fUML)
bjects, links, etc.) bjects, links, etc.)
Act on (create, destroy, read, Act on (create, destroy, read, write, etc.) write, etc.)
(bUML (bUML ⊂ fUML fUML) ) [PSL] [PSL]
bjects, links, etc.) bjects, links, etc.)
Dom ain
A special kind of package cont and model libraries that, in co define a group of domain spec define a group of domain-spec
To define a domain-specific m p To define a domain-specific vi
C tl d fi d fil ll Correctly defined profiles allow extensive support structure pr methods, experience, training DSMLs based on UML profiles foundation which can greatly r problem.
Specific Modeling w ith UML
taining stereotypes, modeling rules
cific concepts and relationships cific concepts and relationships different purposes: modeling language (DSML profile) g g g ( p ) ewpoint (annotation profile) di t d ff ti f th w direct and effective reuse of the rovided for UML (e.g., Tools, … ) share a common semantic reduce the language fragmentation
Exam ple: A
“A specialized object that limits the n multithreaded environment. When th are suspended until one of the access are suspended until one of the access which point the earliest suspended ac
… that has all the general characterist
but adds refinements ⇒ Extend those UML concepts that repr InstanceSpecification p
«metaclass»
UML::Class
Iconic Representation
«stereotype»
Semaphore
limit : Integer getSema : Operation lS O i relSema : Operation
Adding a Sem aphore Concept
number of concurrent accesses in a hat limit is reached, subsequent accesses sing threads releases the semaphore at sing threads releases the semaphore, at ccess is given access.”
tics of UML objects tics of UML objects resent objects: e.g., Class and
“Extension” «metaclass» UML::InstanceSpecification Extension active->size() <= limit
limit <= MAXlimit
Constraints
Exam p Exam p
Instance of a UML Class
Binary
get () «semaphore»
DijkstraSem
p () «semap
Binary
«semap
li it 1 get () release () p () v ()
«semaphore»
li it MAXli it limit = 1 getSema = relSema = limit = MAXlimit getSema = p relSema = v
ple: Applying the Stereotype ple: Applying the Stereotype
Object Object
generateXMI()
ySem SomeOtherClass
phore»
ySem
phore»
= get release
Language for system s engineers
g p
Excluded UML Re UM UML concepts UM co
UML
The SysML Profile
ed systems nes, use cases, activities, interactions)
ams grams
diagrams, parametric diagrams) modeling of continuous quantities
eused ML
Extended
ML ncepts
UML concepts
SysML y
t etc.
«block» «block» Controller Controller driver : Driver driver : Driver
parts
console : Instrumen console : Instrumen
l policy : Policy policy : Policy references
t t ( ) t t ( )
timeoutInterval timeoutInterval : s = : s =
values {a + b= 0} {a + b= 0} constraints
start ( ) start ( ) stop ( ) stop ( )
{a b 0} {a b 0}
SysML Blocks
ion of the UML Class concept ng nts, data, physical devices, logical devices,
r
Parts are elements of the internal structure
ntation ntation
Defines useful values Parts that are not
= 30 = 30
Defines useful values related to the block
SysM
bdd bdd [package] [package] ControllerSystem ControllerSystem
«block» «block» Controller Controller «block» «block» Panel Panel «block» «block» Driver Driver «block» «block» Instrumentation Instrumentation driver 1 driver 1 console 1 console 1 «block» «block» Policy Policy policy 1 policy 1
ibd ibd [block] Controller [block] Controller Reference part
«block» «block»
policy : policy : Policy Policy
L: Com ponent-Based Design
ations
Block-definition diagram defines classes of SysML defines classes of SysML components
(Owned) part (Owned) part
«block» «block»
driver : driver : Driver Driver
«block» «block»
console : console : Console Console
i:Ideas
«block» «block» author : author : MentalBlock MentalBlock
p:IdeaPo ed:MsgPort a:MsgPort
«block» «block» editor : Pest editor : Pest
Conjuga standar
SysML Ports and Flow s
cept w ith flow ports
ta packets expanded in MARTE
s w:IdeaPort
Flow
«block» «block» sheet : Paper sheet : Paper
Flow port ated rd port Flow port
characteristics of softw are system s a relationships relationships
MARTE MARTE
Foundat
«import»
For precise modeling
Real-Time Domain Modeling Support Annexes
MARTE Profile: Structure
and Em bedded System s ( MARTE) ying quantitative and physical and platform s and their functional ualities
Shared abstractions and concepts
ualities
and concepts tions
«import»
Support for QoS analyses Real-Time Domain Analysis Support s
A
l f b h d
j ( g , p p
hardw are platform ( s)
platforms
A Com ponent-Based Solution
s nts
h h h f s through their interfaces racteristics capacity required to attain some functional ervice) e to the finite nature of the underlying he primary source of complexity related to
MARTE Core
the degree of effectiveness in the prov
R h t i d b ff d
models
e Concept: Quality of Service
vision of a service ime (supply side) d (demand side) d Q S d QoS d QoS wn required QoS in multilayer platform wn required QoS in multilayer platform
clients?
Required QoS QoS 2 ms
Client Client
(e.g., data base user) (e.g., data base user)
readDB() Resource
Key qu (RequiredQoS ≤
Engineering Analyses
e have the capacity to support its
Offered QoS QoS 1 ms
Resource
dDB dDB() ()
Service
(e.g., data base)
readDB readDB() ()
Contract uestion: ≤ OfferedQoS) ?
The B
Architecturally independent co Architecturally independent co become implicitly coupled if the
2 ms
Client 1 Client 1
2 ms
Client 2 Client 2
3 ms
Client 3 Client 3
2 ms
Back-Door Coupling Problem
components (applications) can components (applications) can hey share a platform resource
1 ms
Resource
dDB dDB() ()
Service
(e.g., data base)
readDB readDB() ()
Pillar1 : QoS aw are Modeling
QoS, including qualitative and quantitative concerns.
applying semantically well-formed non-functional concerns.
manipulating its representations.
L i t t l l f
Language is a textual language for specifying algebraic expressions.
based on components interacting by either messages or data.
functionalities to entities realizing them.
The four pillars of MARTE
Pillar3 : Platform based Modelling
platform resources at system- level and for specifying their usage.
based design
platform
subject to quantitative analysis.
subject of scheduling analysis.
subject of performance analysis. subject of performance analysis.
A Partia
Project name Project type Bu VERDE EC* ITEA 26 M ADAMS EC* FP7 300 K INTERESTED EC* FP7 6.7 M LAMBDA System@tic 5.3 M EDONA System@tic 16 M TIMMO EC* ITEA 8.6 M ATESST v1 & v2 EC* STREP 4 M + SATURN EC* FP7 193.2 IMOFIS System@tic 4 M Usine Logicielle System@tic 15.2 Usine Logicielle System@tic 15.2 OpenEmbDD System@tic , Minalogic, AerospaceValley 9 M MeMVaTEx System@tic 2.1 M y @ CESAR EC* ARTEMIS 62.5 PROTEUS French Project, ANR
al List of Projects Using MARTE
Extract of the partners list CEA, Thales, Alstom, ABB, EADS K CEA, Thales, Volvo Tech. M CEA, Airbus, Thales, Siemens, Magneti Marelli M CEA, Thales, ST, INRIA CEA, Continental, PSA, Renault M CEA, Continental, VW, Siemens + 3 M CEA, Volvo Tech, Continental, Siemens 2 K Thales, Artisan Sw., Univ. Paderborn CEA, Alstom, Renault M CEA, INRIA, Dassault, EADS, EDF, Thales, M CEA, INRIA, Dassault, EADS, EDF, Thales, CEA, Airbus, France Telecom, Thales, INRIA, Verimag M CEA, Continental, INRIA , , M CEA, Airbus, Delphi, ABB, Dassault, INRIA Dassault, LIP6, CEA, Thales
Open-Source Tool Support: Papyrus
Sum m
practical ADL, supported by both com
Component Component Paradigm
S1 e3A M d l B d
S1 S3 S2 e1 e2Arc Arc Spe Spe Model-Based Engineering Standards
m ary: A Standards Based ADL
nd UML 2 , provides a foundation for a m m ercial and open-source tools
C t C t B d B d hit t l hit t l Computer Computer-
Based Tools Tools chitectural chitectural cifications cifications ADL ADL