SysML and AADL, patterns for integrated Use

Jérôme Hugues, ISAE

Pierre de Saqui-Sannes, ISAE

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

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 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

Requirements

page 11

Use cases

page 12

Block

page 13

State Machine

page 14

• AVATAR forces the binding of state machines to a block

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

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 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

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 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