Académique Documents
Professionnel Documents
Culture Documents
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
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
page 5
page 7
Rationale
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
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
Definition of observers, used by UPPALL Combined use with Block and State Machine diagrams
page 16
page 17
Constraints:
Avoid introducing specific properties Do not forbid analysis at SysML-level
page 18
Mapping Requirements
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
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
page 22
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
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
2/ AADL
Device Processor Memory
System impls
page 25
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
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
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
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