Upload
buihuong
View
219
Download
1
Embed Size (px)
Citation preview
Objectives
• OMG SysML for filling the gap between requirements (text-
based) and early design solutions, prior to go to AADL
• Objective: investigate patterns to bridge SysML and 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
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
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
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 naïve 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
Sys
ML
• 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
AA
DL
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 Block and State
Machine diagrams
page 16
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 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 (cont’d)
• SysML requirements are bound to SysML entities
� This feature has to be imported by AADLv2
• Quick’n 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)
� Allow for easy navigation, to be evaluated by tool vendors
page 20
SysML_Req : classifier (<SysML_MM_Req>);
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 • 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
page 24
� 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?
SysML/AADL integrated process
Requirements
Use Cases
1/ SysML 2/ AADL
Processor
MemoryDevice
AADL
repository
page 25
Block diagrams
State machines
Abstract
components
BA annex
SystemsSystems
Systems System impls
subcomponents
repository
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� 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
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 alignementpage 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• Avatar profile by L. Aprvrille and P. de Saqui-Sannes
• ENSICA students for their reports ;)
page 30