SysML and AADL, patterns for integrated Use
Jrme Hugues, ISAE Pierre de Saqui-Sannes, ISAE
Objectives
OMG SysML for filling the gap between requirements (textbased) and early design solutions, prior to go to AADL Objective: investigate patterns to bridge SysML and AADL Method: use a lab session from ISAE/ENSICA cursus
Longitudinal Flight Management System Available DOORS requirement base + SCADE design
page 2
Case study: Longitudinal Flight Management System
page 3
Longitudinal FMS
Support for a lab session at ENSICA Mission: pilot the plane on the z axis
Automatic and manual modes 1 system, 4 sub-systems, 27 requirements Support take-off, landing, stall detection Naive piloting laws and environment modeled
Approach: follow typical SCADE development cycle
Model blocks, integrate functional behavior Map requirements to blocks Model coverage, simulation, model checking Integration of a GUI using SCADE Display
page 4
Longitudinal FMS in action
page 5
Metrics for this project
Time to perform the whole case: 20 hours
Include modeling, testing, V&V, demonstration, report
27 requirements, approx. 20 blocks modeled
All requirements traced to block 100% MC/DC covered Functional testing and model checking
Limits: open loop models
No feedback from the environment due to limited models available Only playback of inputs
Yet sufficiently representative
only need to improve the modeling of the plant
page 6
Modeling the L/FMS using SysML/AADL
page 7
Rationale
DOORS/SCADE is a big jump, needs additional steps in the modeling process
Add SysML for first step modeling, then refine down to AADLv2
First, elicit high-level design blocks using SysML, behaviors, and map it to actual architecture represented in AADLv2 Validate on both abstract models and the actual architecture the solution
Note#1: Lab session does not cover the latter step Note#2: SCADE to integrate SysML modeler (using MDT-Papyrus) in September 2011 release
page 8
About the modeling process
SysML is a UML profile, comes with its inherent complexity
Need to tailor it to match one modeling process
We retained a very nave one, limited to SysML-only
Requirement diagram Use cases Block diagrams State machines Parametric diagrams
This constrains the semantics fuzziness of SysML to a tractable subset and prepare for the transition to AADLv2
page 9
Modeling process
Requirement capture: provide a tree-like structures, with hierarchy and clustering of all requirements Modeling assumptions: define perimeter of the model Problem Analysis (-la UML): define use cases Architectural Design (-la UML): define the static architecture Validation: mostly functional at this level Architecture refinement: refine the static architecture into runtime architecture Architecture mapping: map blocks to hardware/software Validation: refine all computed metrics
page 10
AADL
SysML
Requirements
page 11
Use cases
page 12
Block
page 13
State Machine
AVATAR forces the binding of state machines to a block
page 14
Divergences from SysML
Problem: SysML has a weak semantics model
Efforts at ISAE and Telecom ParisTech (Sophia campus) to fill these holes
Solution: AVATAR profile + TEPE
Constraints on the modeling pattern to avoid loopholes in the specs. Reduce the number of diagrams to avoid inconsistencies Ensure models can be mapped onto UPPAAL for verification
Tool support using TTool
http://labsoc.comelec.enst.fr/turtle/ttool.html
Note: this is in-line with typical UML approach
Adapt the notation to a project/company
page 15
TEPE parametric diagram
Definition of observers, used by UPPALL Combined use with Block and State Machine diagrams
page 16
From SysML to AADL
page 17
Rationale for the mapping
Goal: integrate AADLv2 as part of the global workflow
Ideally, round-trip for some parts
Constraints:
Avoid introducing specific properties Do not forbid analysis at SysML-level
Start from a manual mapping perspective
With automation in mind
page 18
Mapping Requirements
Requirements define a hierarchy of concerns Each requirement maps to
A constraint on the architecture
A block shall support function A Shall have such quality of service metric
A check-obligation
System shall exhibit this metric Careful design to trace them to AADL level
page 19
Mapping requirements (contd)
SysML requirements are bound to SysML entities
This feature has to be imported by AADLv2
Quickn dirty way: use a string property
Not sufficient: unsafe, poor support for analysis
Better: interleaves of SysML and AADLv2 meta-models
See interaction with RDALT
Import SysML as an AADLv2 annex language
Allows for naming SysML identifier as a classifier See 11.1.1 Property Types, naming rule (N6) SysML_Req : classifier (<SysML_MM_Req>); Allow for easy navigation, to be evaluated by tool vendors
page 20
Mapping use case
Question: does it make sense? Not clear, depends on the use in the original process Mostly documentation purpose, poor link with other SysML diagrams in tools
Could be used to check high-level connectivity between blocks
page 21
Mapping block diagrams
SysML Data types <-> AADL data types
Map primitive types (boolean, integers, ) to elements from Base_Types package defined in AADLv2 Data Modeling annex
SysML Block and Internal Block
Combination of system/ system implementation for top-level (BD) Abstract/Abstract implementation for internals
Connection in IBD are typed, have a direction, no more
Use abstract features connection facilities introducted in AADLv2
page 22
From IBD to AADLv2
IBD defines a top-level architecture to be mapped to concrete blocks: this is the role of AADLv2 BD (systems) and IBD (abstract) are refined onto concrete AADLv2 components
The approach maps to Incremental design presented in ARAM
Note some requirements also map directly to AADLv2 concrete components
E.g. Airbus requirement to use the IMA2G hardware architecture This implies the parallel construction of a library of AADL blocks This library is used to populate refinements of abstract functions
page 23
Mapping activity
Nothing but automata Mapping to a BA subset? SysML is elusive about dispatch conditions
Timing? Queuing? Deferred to later steps
Does AADL/BA has notion of fuzzy dispatch conditions that can be refined? Are AADL-BA annex subclauses inherited?
page 24
SysML/AADL integrated process
1/ SysML
Requirements Use Cases AADL repository Block diagrams State machines Abstract components
BA annex
2/ AADL
Device Processor Memory
subcomponents Systems Systems Systems
System impls
page 25
Bi-directional model navigation and update
IBD/abstract components is the pivot Any update to one can be reflected to the others Raises concerns for dependencies
SysML updated -> AADL Systems may change
Checked by AADL grammar or tool support
AADL updated -> SysML models to be updated
Tool support, usually weak no incremental checks Question: which IBD to translate? Some of them are really too abstract to be relevant at AADL level
page 26
Conclusion
page 27
Not-so final words
Some interesting results for a restricted case study Modeling process shares a lot of similarities with TASTE incremental modeling
1. Mapping SysML block diagrams to set of abstract functions 2. Mapping of abstract to concrete AADL follow TASTE patterns
Use of AVATAR/TEPE allows for checks at SysML-level, later completed by checks at AADL-level RDATE by UBS/Lab-STICC provides the missing pieces for linking Requirement diagrams to model validation. Should be enriched to point to multiple levels of validation OMG started work on SySML/MARTE alignement
page 28
About tool support
Automated mapping between SysML and AADL
Generation of abstract components from IBD easy Other diagrams more tricky
Behavior diagram <-> AADL-BA to be evaluated Notion of SysML complete models fuzzy
Many SysML models lack key details
E.g. dispatch time, trigger condition Global clock, actual connection, etc
page 29
Acknowledgements
Thanks to Esterel Technologies for providing academic licenses of SCADE Suite and SCADE Display TTool is developed by L. Apvrille, at Telecom ParisTech Avatar profile by L. Aprvrille and P. de Saqui-Sannes ENSICA students for their reports ;)
page 30
