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