future of a standard for system engineering by yves...

DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018

SysML from v1.5 to v2.0 : present and future of a standard for System

Engineering By

Yves BERNARD (Airbus)

May 17 & 18, 2018 (Paris) – [email protected] - http://standardizationday.afnet.fr/ - ‹1›


Content

What is SysML and how it can help in deploying MBSE?

SysML overview and roadmap of v1.x

SysML v2.0: scope and roadmap

2


SysML & MBSE

• “Model-based systems engineering (MBSE) is the formalized application of modelling to support system requirements, design,

analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development

and later life cycle phases.” INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02), Sept 2007

3

• A model is a simplified and unambiguous representation that is

dedicated to a specific purpose

• Several models can be linked for describing miscellaneous aspects of

the same product/solution/service

• Significant advantages when text based descriptions are replaced

with digitalized representations.

• SysML is a modeling language designed for Systems Engineering that

enables this


SysML Objectives

The OMG Systems Modeling Language™ (OMG SysML®) is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities

4

• SysML is a general-purpose modeling language extending UML to support the needs of the Systems Engineering community.

• Its four pillars are: Structure, Behavior, Requirements and Parametrics


SysML: Structure modeling

“Block” is the primary concept for representing the characteristics of a

structural entity

The characteristics defining the Block are specified as Features that

can be either structural or behavioral.

The structural features of a Block are Properties. The characteristics of

a property are specified by its type (either a Block or a ValueType)

Ports are specific properties intended for encapsulation

The behavioral features represent services that may be invoked on

demand either by an instance of the owning block itself or by other

instances

A generalization represents a taxonomic (i.e. “is a”) relationship. The

specialized element “inherits” the features defined (or inherited) by

the more general one

ValueType are classifiers for items that have no identity (e.g.

numbers, similar to UML::DataType)

5


SysML: Behavior modeling

State machines are abstractions intended for the description of event-

driven behaviors. Mains elements of a state machine are:

regions that define independent automatons. Within a region, only one

state can be active at a time.

the states that describe stable conditions

The transitions that describe how one can switch from one state to another

Activity graphs are abstractions intended for the description of

processes. Their semantics is based on token flows. Mains elements

are:

the actions describing fundamental units of behavior specification (i.e.

behavior steps)

The flows (of “tokens”) describing how the actions are sequenced.

ControlNodes that manage how tokens “move “downstream during the

execution.

Interactions model traces of execution that can be specified either

“valid” or “invalid”

6

Activity

State machine

Interactions


SysML: Requirements modeling

The AbstractRequirement (abstract) stereotype establishes the attributes and relationships essential to any potential kind of requirement. Any intended requirement kind should specialize AbstractRequirement.

The only normative stereotype based on AbstractRequirement is the (legacy) Requirement stereotype

However, this abstract stereotype allows more formal expression of requirements that may include quantitative specification of numerical parameters, relationships, equations and/or constraints (cf. SysML v1.5 Annex E for such non-normative extensions).

7

Standard (v1.5 or above)

Customization

Usage


SysML: Parametrics modeling

There are some cases where values which are related to a system are linked by a mathematical equation. A common example of this

a physical law like the Ohm law (U = R.I) or the Newton law (F = m.a).

In such a physical law there is actually neither “dependent” nor “independent” variable a priori. The equation is “acausal”: it only

states that some parameters are interrelated. In other words, there is a relation that links their values together

ConstraintBlocks intends to represent such a relation. They can be combined in order to provide “networks” of constraints.

8


SysML models interoperability Between SysML implementations (i.e. tools). Main interoperability issues are due to:

Missing serialization specifications for some kinds of data (e.g. stereotypes applications)

Vendor specific usages of some XMI fields

Missing serialization specifications for diagrams: (DD/DI specifications came lately and is not normative)

No real will from tools vendors…

With other modeling standards

UML & xUML: SysML is defined as a UML profile (i.e. specialization). The executable UML specifications (fUML, PSCS, PSSM, …) in

scope of UML4SysML are compatible with SysML

MARTE: is a UML profile as well, compatible with SysML. Useful for time properties modelling

Modelica: see the SysML-Modelica Transformation specification (SyMTM)

AP233: compatibility with a subset of the evolving ISO 10303-233 systems engineering data interchange standard is part of the

initial requirements of SysML, but no formal mapping is available today.

With Simulation Oriented Standards

Executable UML, Modelica

SysPhS

+ Vendor specific bridges and connectors

9

http://www.ap233.org/




The UML for Systems Engineering RFP was developed jointly by the OMG and the International Council on Systems Engineering

(INCOSE) and issued by the OMG in March 2003.

2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020

SysML 1.x Roadmap

10

RFP 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7

??? 1.4

(2001)

1.5 2.0 2.5 2.1.1 2.2 2.3 2.4.1 2.5.1 ? 2.6

Bug fixes

Add QuantityKind and QUDV

lib.

Add Full/ProxyPorts and ISO80000 lib.

deprecates FlowPort

Improves support of Requirements

Add “executable” views & viewpoints

Improves support of nested properties

ISO 19514:2017


SysML v2.0: scope The SysML® v2 RFP was issued on December 8, 2017 (http://doc.omg.org/ad/2017-12-2)

Specifies requirements for SysML v2.0 intended to: • Improve the precision, expressiveness, and usability over SysML v1, according to lessons-learned from applying MBSE with

SysML since its adoption more than 10 years ago.

• Provide a metamodel, a UML profile (for at least a subset) and a mapping between the two

• Backward semantic compatibility with SysML 1.x

Letters of Intent due: 24 September, 2018

Submissions due: 4 November, 2019

A distinct (but linked) RFP is in finalization phase: SysML 2 API and Services RFP. Scope: model navigation & queries, model construction, model analysis, model visualization, model management,

model interoperability, model workflow & collaboration.

Will be submitted for adoption mid-June 2018

11

http://doc.omg.org/ad/2017-12-2






The UML for Systems Engineering RFP was developed jointly by the OMG and the International Council on Systems Engineering

(INCOSE) and issued by the OMG in March 2003.

2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

SysML 2.0 & executable UML Roadmap

12

RFP 1.0

1.0 1.1 1.2.1 1.3

PSCS 1.0 PSCS 1.1

PSSM 1.0β

Time RFP

API RFP

(2020-21)

Time 1.0

1.4

PSSM 1.0


Conclusion SysML is an evolving standard built by and for its community.

With SysML v2.0, we want to address the challenges of tomorrow’s System Engineering

You are welcome to contribute: join us!

How to get involved?

SysML 1.x Revision Task Force: OMG membership (prerequisite): contact Diane ([email protected])

RTF membership: contact either myself ([email protected]) or Tim ([email protected])

SysML v2.0 submissions API RFP: contact Manas ([email protected])

“SST” team: contact either Ed ([email protected]) or Sandy ([email protected])

“SUT” team: contact Matthew ([email protected])

- Thank you! -

13

mailto:[email protected]










Backup slides

29 May

2018 Presentation Title runs here (go to Header & Footer to edit this text)

14


Nested properties issue

29 May

2018 Presentation Title runs here (go to Header & Footer to edit this text)

15

A

b1:B

c:C

b2:B

c:C

future of a standard for system engineering by yves...

Documents