NextGenSysML Part 8 – Behavior Requirements
This blog post presents the requirements for behavior modeling with SysMLv2. It is part of a blog post series about the upcoming new SysML v2 and SysML API & Services standard. The blog posts present the requirements for the standard stated in the request for proposals (RFP) published by the OMG. See the end of this post for a list of all posts of this series including a link to the first post of the series that provides an overall introduction.
A behavior is an interaction between structural elements, including a (potential) change of the states of the elements. In SysML v1, a behavior can be specified with activities, state machines, interactions (sequence diagrams), or opaque behaviors to specify the behavior with a textual language other than SysML.
SysML v2 shall support similar capabilities to model…
…function-oriented behaviors (activity, interaction) including the transformation from inputs to outputs, pre- and postconditions, and the order of execution. It includes discrete and continuous time behaviors. An optional requirement for SysML v2 asks for composite inputs and outputs with separate flows for the parts of the composites.
…state-based behaviors of structural elements. Constraints and function-oriented behaviors can be integrated into the state machines, for example, as the behavior on transitions. A non-mandatory requirement requests the capability to represent the state history of an element as a series of snapshots.
…opaque behaviors to embed other specification languages, for example, programming languages
Just as it is crucial to decompose structures, it is also essential to decompose behaviors. SysML v2 shall support decomposition of behaviors to any level.
Behavior can change not only property values but also the whole structure of elements, i.e., connections and compositions. For example, when gearing up or down (= behavior) in a gearbox (= structure). SysML v1 does not well support that, and the RFP requests that now for SysML v2.
SysML v2 shall provide the capability to execute behaviors. It is already possible to do that with SysML v1, but it lacks precision of the formalism and requires non-standard interpretations by the runtime environments. Currently, the SysML v1.7 Revision Task Force works on a non-normative annex of the specification about the precise semantics of SysML to close the “precision gap” already a bit in SysML v1. However, the annex will not be normative, and necessary (more significant) changes to achieve normative precise semantics of SysML will not be realized.
Events in SysML v2 can trigger behaviors in state machines, but also in function-oriented behaviors, for example, as in SysML v1 the accept event action in an activity. An event can be the reception of a signal, a time event, or the change of property values.
The control flow, i.e., the order of execution, can be specified by control nodes like a decision of a fork node.
Time aspects can be specified with time constructs, for example, a duration constraint.
Typically, systems engineers consider behavior and structure both separated and integrated. SysML v2 supports the modeling of behavior and the integration of behavior with structural elements. For example, state machines representing the states of structural elements, or the consistent mapping of structural inputs and outputs to behavior inputs and outputs (e.g., port flow properties to activity parameters).
An optional requirement for SysML v2 requests a behavior library for common functions, for example, functions to manage data or energy.
You probably know use cases. SysML v2 supports a more general concept: the case. A case is a series of steps associated with an objective. Specific cases are the well-known use cases, but also analysis, safety, or assurance cases.
The next blog post covers the requirements about the capability of SysML v2 to model requirements. Stay tuned!
Previous blog posts of this series:
- NextGenSysML Part 0 – Next Generation Modeling: SysML v2 and SysML API & Services – Introduction
- NextGenSysML Part 1 – Overview SysML v2 and SysML API & Services RFP’s
- NextGenSysML Part 2 – The General OMG Requirements
- NextGenSysML Part 3 – Language Architecture and Formalism Requirements
- NextGenSysML Part 4 – Cross-cutting Requirements
- NextGenSysML Part 5 – Properties, Values & Expressions Requirements
- NextGenSysML Part 6 – Structure Requirements
- NextGenSysML Part 7 – Interface Requirements
Planned future blogs posts:
- NextGenSysML Part 9 – Requirements Requirements
- NextGenSysML Part 10 – Verification Requirements
- NextGenSysML Part 11 – Analysis Requirements
- NextGenSysML Part 12 – Example model and Conformance Requirements
- NextGenSysML Part 13 – SysML API & Services Overview
- NextGenSysML Part 14 – SysML API & Services: Architecture and Conformance Requirements
- NextGenSysML Part 15 – SysML API & Services: Service Requirements
