To cite this document: Hugues, Jérôme A programming language view to model-driven
engineering. (2013) In: Séminaire DTIM - ONERA, 03 June 2013 - 03 June 2013
(Toulouse, France). (Unpublished)
Open Archive Toulouse Archive Ouverte (OATAO)
OATAO is an open access repository that collects the work of Toulouse researchers and makes it freely available over the web where possible.
This is an author-deposited version published in: http://oatao.univ-toulouse.fr/ Eprints ID: 9292
Any correspondence concerning this service should be sent to the repository administrator: staff-oatao@inp-toulouse.fr
Institut Supérieur de l’Aéronautique et de l’Espace
A programming language view to
model-driven engineering
Jérôme Hugues, ISAE/DMIA
jerome.hugues@isae.fr
> Model-Based System/Software Engineering vs. the real world
> AADL, an overview
> MBSE as an extension to programming in the large
Outline
> Model-Based System/Software Engineering vs. the real world
>
AADL, an overview
>
MBSE as an extension to programming in the large
Outline
> Now typical in SW engineering
» Various refinements
+ traceability across layers
+ split across teams (HW, SW, …)
and consolidation
> Supported by AADL
» Scheduling, safety analysis
» Model checking, Code generation, …
» Single architectural model
Engineering cycles
page 4
!"#$%&'()!"#$#%&$#%'"#%()*+,-.#/0%
Why is analysis in a V-cycle so difficult?
(System Engineers 1 – 0 Software Engineers)
Increased confidentiality requirement
• change of encryption policy
Key exchange frequency changes Message size increases
• increases bandwidth utilization • increases power consumption
Increased computational complexity
• increases WCET
• increases CPU utilization • increases power consumption • may increase latency
B y F e i l e r a n d L e w i s *#$$&'+,(%>'#$&.;#%78+6+-#%)/%)2#?#+.;#@%&26%(#/)A2%+"3)+#% +3,-(%B#35&$()C#%5$#;)3,/%$#/,-'/D% % E##(%'3%$#+32+)-#%4&26%(34&)2/9%4&26%&55$3&+"#/%!)'"%5$#8 #F)/'#2'%()?#$#2'%'33-%/,553$'/%G3$%-&+:%3H%I%JF+#-K7)/)3%DDL% % M-/39%NO%)/%&%-.'&/%5&$'%3H%'"#%43(#-%+345&$#(%'3% 5$35#$.#/9%P#"&;)3$9%)2'#$&+.32/9%#'+D%
> Order of complexity (gratuitous comparison)
» Mathematics: axioms + proof, no interpretation
» Electronics, physics, etc. : bound by physics laws, yet empirics
» (Programming) language: human-defined .. Large variety
> Model-Based: babel tower effect
» Easy to interconnect models, transform them
» But how to manage analysis?
> Analysis: transformation to intermediate model + “evaluation”
» E.g. scheduling analysis: true/false
» Safety: error rate, stop when below threshold
» Also, Analysis part of the GUI space, not the modeling space!
Why is model-based so difficult?
page 6 *#$$&'(%Q2(#$8/5#+)R#(%STJ%5$3+#//%)2+,$/%U%3,'%3H%V%W%!&/'#/%X%% (#5)+'#(%)2%Y#&2%S&2&A#4#2'% ,0 12.%'3()/34#%&2&-6/)/%&$#%.4#8+32/,4)2A9%#DAD%43(#-%+"#+:)2A% 40 56#/78/&9#$$.'3()!"#2%'3%'$)AA#$%&2&-6/)/0% :0 56#/78/&;"9%&'()43(#-%'33%;#$P3/#K(#'&)-#(% <0 =#>#9?$()-&'#%()/+3;#$6%3H%43(#-%)2&++,$&+)#/% ⇒ Z34432%$33'@%&2&-6/)/%)/%&%P,[32%)2%'"#%\Q>9%23'%5&$'%3H%'"#%43(#-% % E##(%'3%$#]#+'%32%&2&-6/)/%5$3+#//@%5$3AD%-&2A,&A#%+&2%"#-5=%
>
Model-Based System/Software Engineering vs. the real world
> AADL, an overview
>
MBSE as an extension to programming in the large
Outline
> International standard promoted by SAE International,
AS-2C committee, released as AS-5506A
> Version 1.0 published in 2004, version 2 in 2009
» Committee driven by inputs from the avionics and space industry
» Academics drive analysis capability, to ensure they match with modeling patterns
>
http://aadl.info
list all resources around AADL
» Public wiki with lot of resources: https://wiki.sei.cmu.edu/aadl/index.php/Main_Page » Include link to most research activities around AADL
> AADL is dedicated to real-time embedded domain
• Modeling software and hardware resources for V&V
• Extension & refinements concept to iterate down to generation
> Different representations
» Graphical: high-level view of the system » Textual: to view all details
» XML: to ease processing by 3rd party tool
> Some interactions with SysML (higher-level design)
AADL:
Architecture Analysis & Design Language
AADL model elements
page 9 Property sets . Units . Property type . Property definition . Constants Component type . Identifier . Extends . Prototypes . Features . Flows . Properties . Annex Component implementation . Identifier . Extends . Subcomponents . Connections . Call sequences . Modes . Flows . Properties . Annex Package . Public decl.. . Private decl. “references” . Ports . Access . Subprogram . Parameter . Feature . Ports . Access . Parameter . Modes . transitions Category . Data . Subprogram . Thread (group) . Process . Memory . Device . (virtual) processor . (virtual) bus . System . Abstractpage 10
AADL in one slide (!)
page 10
page 10
1s
Send
D ata_Sourc e : out event data port
D ata_Sink : in event data port
AADL Process as Partition
AADL Thread as Ada Task object
AADL Data as Ada Protected object
Receiver Local O bject update 500 m s 100 m s
Update Read Watch
R ec eiver_Thread Watcher_Thread SpaceWire SpaceWire LEON TSIM LEON TSIM LEON TSIM Space W ire Sp aceW ire Sender_Thread read D ata_Sink : in event data port
SC_2 SC_1 Concurrency view Physical view Receiver Local O bject update 500 m s 100 m s
Update Read Watch
R ec eiver_Thread Watcher_Thread
read
SC_3 Link to code/model
Workflow with SysML,
Executable models (SCADE, Simulink) Code (Ada, C, lua, …)
Non-functional properties Architectural patterns
Architecture helps you focusing on the actual system
-- Textual AADL
thread Sender_Thread features
Data_Source : out event data port Record_Type.Impl;
properties Dispatch_Protocol => Periodic; Period => 1 Sec; annex real_specification {** -- Contract to be enforced **}; end Sender_Thread;
> AADL is meant to be extensible
> New property sets for specific concerns: e.g. ARINC653
> Additional language to extend semantics
» Behavioral specifications: AADL-BA
» Error modeling, propagation in a system: AADL-EMV2
» Constraints on model (on going)
• Algebraic specifications for contracts, patterns, …
» Requirement engineering (on going)
> Each extension has to remain compatible with core
» Can be safely ignored if not relevant for a particular objective
AADL Extensions
> AADL as a backbone, federating multiple activities
» analysis through generation of intermediate models + external tools > Common tool IDE: OSATE2 from SEI (FLOSS)
» AADL core (SEI) + Behavioral (TPT) + Error (SEI) annexes
> Non exhaustive list of tools, European-centric (see http://www.aadl.info)
» Integration to a process: with SysML, Simulink, SCADE
» Architectural pattern checks: MILS, ARINC, Ravenscar, Synchronous » Model checking:
• Timed/Stochastic/Colored Petri Nets
• Timed automata et al.: UPPAAL, Versa, TASM » Scheduling: MAST, Cheddar, CARTS
» Performance evaluation: real-time and network calculus
» Fault analysis: COMPASS, Stochastic Petri Nets, PRISM, FHA » Simulation: ADeS, Marzhin
» Energy consumption of SoC: OpenPeople project » Code generation: SystemC, C, Ada, RTSJ, Lustre » WCET analysis: mapping to Bound-T
Some examples of AADL tool support
>
Model-Based System/Software Engineering vs. the real world
>
AADL, an overview
> MBSE as an extension to programming in the large
Outline
> AADL has a concrete syntax
» Concrete means also rock-solid to build foundation
> Scalable: AADL package system close to Ada one
» Potential for modular processing
» Optimizations in representation/processing of the AST
• OSATE2: EMF, issues with object ids and cache
• Ocarina: GNAT-like tree: faster, leaner
> Text also means potential for detailed syntactic constructs
» Liskov principle, multiple bindings, formal specs, etc
» Cannot be (easily) represented graphically !
Moving back to programming language
Example#1: SAVI
http://www.avsi.aero
page 15 Q/#%3H%MMTY%'3%+3;#$%&%!"3-#%43(#-)2A%+6+-#9%H3+,/)2A%32%;&-)(&.32%3H% ")A"%-#;#-%P,(A#'/%G4&//9%#2#$A6L9%)2'#$H&+#%+32/)/'#2+)#/9%#'+D% S3(#-)2A%'#&4/%/+&[#$#(%&+$3//%4,-.5-#%'#&4/%&2(%+345&2)#/% *#$$&'(%&%'#F',&-%-&2A,&A#%"#-5/%P#)2A%/+&-&P-#9%/#5&$&.32%3H%+32+#$2/%&+$3//% '#&4/%)2%&%2)+#%!&6@%/,553$'%H3$%5,P-)+K5$);&'#%/#+.32/%'3%#F53$'%32-6%$#^,)$#(% #-#4#2'/9%4#$A#%3H%43(#-/%4&(#%#&/6%!)'"%'#F',&-%5&'+"#/% % S3(#-%();#$A#2+#%+"#+:#(%#&/)-6%P6%-&C68-3&()2A%$#^,)$#(%43(#-%&2(%5&$/)2A9%% +&2%P#%(32#%)2%&%;#$6%-)A"'%!&6%> Code generation and analysis for Space-critical systems
» Subset of AADL as input language + model transformations
Example#2: TASTE
http://assert-project.net/-TASTE-The TASTE Toolset assert-project - Dr Eric Conquet, Maxime Perrotin, Marie-Aude Esteve – European Space
Agency page 16 AOCS Control law 10 Hz sensor data actuators to FDIR Mode Management State Machine Deadline: 3 ms WCET: 1 ms Simulink LEON2 SDL LEON2 FDIR-command ::= ENUMERATED { safe-mode, switch-to-redundant, ... } AOCS-tm ::= SEQUENCE { attitude Attitude-ty, orbit Orbit-ty, ... } process ABB1 idle PI1 RI1 (myData) wait_ABB2 wait_ABB2 PI2 idle FBY 1 false stop status start *#$$&'(%&%'#F',&-%-&2A,&A#9%H$##%H$34%4#'&843(#-%4&2&A#4#2'%)//,#/%)/%&%4,/'%'3%% &;3)(%4&)2'#2&2+#%)//,#/D% _MN_J%)/%V%6#&$/%3-(%G=L9%#&+"%-&6#$%#;3-;#/%)2(#5#2(#2'-69%+33$()2&'#(%P6%&2%3$+"#/'$&'3$% % ⇒ J&+"%'33-%#)'"#$%$#,/#/%32#%#F)/.2A%5&$/#$%GH$34%1+&$)2&%3$%ME_Y`La% ⇒ 1$%/)45-#%$#A#F5%'3%R2(%'"#%)2H3$4&.32%)'%2##(/D% N)45-6%H3--3!%Q2)F%5")-3/35"6%'3%&(($#//%&%+345-#F%'$&2/H3$4&.32%)//,#%
> Based on current practice for space projects at ESA
> Define mission criteria
» Max weight, orbit position, duration, etc.
> Specify functional aspects
» What will be provided by the platform
» Specify requirements & constraints
> Refine the architecture
» Replace functions by implementation
» Reuse existing components
> Validate planned implementation
» Implementation properties vs. Function requirements
» Automate system integration verification
Example#3: ARAM
(joint project with ESA, 2011)
17 L ev el o f d etails Functions Planned implementation Refinem ent Mission criteria
18
ARAM Proposed approach, cont’d
Functional architecture
(functions and their interactions)
Implementation
(processor, bus to be used)
Refinement with generic building blocks
Automatic validation of mission requirements Mission requirements
(duration, mass, etc.)
Build & implement the system Criteria and/or architecture
modification Validation OK Validation KO Step 1 Step 2 Step 3 Up d at e m o d e ls
System exploration, design, integration
19 Function 1 Function 2 Functional bus Sensor 1553 bus Architecture refinementsystem implementation mission.planned extends mission.i
subcomponents
f1 : refined to system obc; f2 : refined to device sensor; bus : refined to bus1553;
-- contracts inherited from mission.i end mission.i;
system implementation mission.i subcomponents
f1 : abstract function1; f2 : abstract function2; b : bus genericbus; connections
bus access f1.ba -> b; bus access f2.ba -> b; annex Constraints {**
-- list of contracts to be met **};
end mission.i;
OBC abstract function1
features
ba : requires bus access genericbus; end function1; system obc features ba : requires bus access bus1553; end obc; device sensor features ba : requires bus access bus1553; end sensor;
Contract example
20
-- gaia::functions
abstract fpa_data_get features
dataout : out data port Data_Types::fpa_data; ctrlout : out data port Data_Types::fpa_ctrl;
end fpa_data_get;
-- blocks
device FPA features
dataout : out data port Data_Types::FPA_data; ctrlout : out data port Data_Types::FPA_ctrl;
properties
ARAM_Properties::Realizes =>
(classifier (GAIA::Functions::FPA_data_get));
end FPA;
-- gaia::validation
system implementation Gaia.Validation subcomponents
Functional : system GAIA::Functions::Gaia.Functional;
Impl : system GAIA::Implementations::Gaia.First_Architecture;
properties
ARAM_Properties::Actual_Function_Binding =>
(reference (Functional.get1)) applies to Impl.fpa1.datapart;
« Interface » of a function
One implementation
Function/implementation mapping
> Problem: ensure that all abstract functions are implemented
to real hardware block
> Solution: extract relevant information from the validation
model dedicated analysis plug-in that generate the connection table (500 SLOCs !)
Function coverage
21 *#$$&'(%,/#%&%+34432%-&2A,&A#%'3%43(#-%'"#%&$+")'#+',$#9%$@2/#;)) P6%/6/'#4%#2A)2##$%&2(%/3b!&$#K"&$(!&$#%#2A)2##$/% % cd%J&+"%W%$3-#%X%+&2%43(#-%)'/%H&+#'%3H%'"#%43(#-% N62'&F%&2(%/#4&2.+/%3H%MMTY%'3%P)2(%'"#4%&--9%G-):#%&%5$3A$&44)2A%-&2A,&A#%=L% JF'#$2&-%43(#-%P3,2(%'3%&$+")'#+',$#%GN6/SY9%N)4,-)2:9%T11`N9%eL%H3$%(#'&)-#(%)2H3% % cd%J&+"%-#;#-%)/%&[&+"#(%)'/%3!2%/#'%3H%;#$)R+&.32%G+32/'$&)2'/9%+"#+:/9%+345,'&.329%DDL% %&2(%&//3+)&'#(%#;&-,&.32%'33-% `#R2#(%#2..#/%4&6%W%)2"#$)'%X%+32/'$&)2'/%H$34%5&$#2'%G<8-&%Y)/:3;L% % ⇒ 7#$)R+&.32%$,-#/%,/)2A%TNY%#;&-,&'#%/5#+)R+%&$+")'#+',$#%5&[#$2/9%% ⇒ f)H%M%)/%+322#+'#(%'3%g9%'"#2%'"#%P&2(!)('"%3H%'"#%P,/%,/#(%)/%-#//%'"&2%DDh% ⇒ i&$'%3H%NMJ%MNj8Z%/'&2(&$()C&.32%#?3$'% ⇒ E)+#%/)(#8#?#+'@%+&2%P#%,/#(%'3%#2H3$+#%$#^,)$#4#2'/9%/,P/#'/9%+32'$&+'/% ⇒ Q/#(%H3$%M`>EZ9%S>YN9%`&;#2/+&$%&$+")'#+',$&-%/'6-#/%,/)2A%1+&$)2&%AADL Constraint Language
> Work in progress as part of SAE AS2-C committee work
» Defines accessors and computation rules on model elements
> E.g. AADLv2 and ARINC653 annex support IMA concepts
» Needs to constraint models to respect some invariants
page 22
theorem scheduling_major_frame -- Check configuration of partition scheduling
foreach cpu in processor_set do
check ((float (property (cpu, "ARINC653::Module_Major_Frame")) = sum (property (cpu, "ARINC653::Partition_Slots"))));
end scheduling_major_frame;
system IMA_System extends AADL_System – implementation/extension must respect profile annex real_specification {**
theorem check_IMA
foreach s in local_set do
requires (check_IMA_profile); -- logical conjuction of theorems
end check_IMA; **}; end IMA_System;
> Analysis of rocket kinematics performance
Example#4: PERSEUS supersonic rocket
page 23
System-level analysis done by combining atomic computations
Each defined separately
Lesson#2: verification should be driven by domain expert
Expert knows what to compute, the dependencies between parameters Architects will attach analysis rule to model entities they apply to
⇒ use of AADL annex subclause mechanism
Lesson#2bis: notion of ordering of rules (makefile-like)
Some properties deduced from analysis, reused in another analysis
⇒ Resolution in a compiler AST
Example#5: Optimization model/code
> Combine code generation, scheduling, analysis
> Three level of evaluations, combined
» Binary: precise evaluation, e.g. memory footprint, WCET
» Model: check constraints, e.g. requirements or higher-level checks » Operation: evaluate the benefits of one modification
» Under supervision of analysis, scheduling in this context
> Integrated in Ocarina (O. Gilles PhD)
Model Code generation
Model evaluation Binary evaluation Transform systems Binary Model! page 24
> Equating Model-Based Analysis and Compiling is appealing
» Text-based allows for optimization and more precise semantics
• Fast evaluation for static/simple contracts, proof for complex one (BLESS) • Integration of IEEE PSL (dynamic traces) for observers
» Links with analysis tools made easy
> Integrating analysis contract to models helps solving
» Waiting, Over-processing, Over-production, Defects
» A compiler/makefile-like approach would optimize analysis effort
• Run only when required (i.e. model changed “significantly”)