SysML and AADL, patterns for integrated Use and AADL, patterns for integrated Use Jérôme Hugues, ... Longitudinal Flight Management System ... Requirement diagram Use cases Block

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