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›
15
Embed
future of a standard for System Engineering By Yves ...download.afnet.fr/ASD2018/ASD2018-2A-YvesBernard-Airbus.pdfDIESAR Direction Internationale de l’EvaluationAFNeT Standardization
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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.
DIESAR Direction Internationale de l’Evaluation, de la Sécurité et des Affaires Réglementaires AFNeT Standardization Days 2018
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.