User Tools

Site Tools


sysml-roadmap:sysml_v2_model_formalism_working_group

This is an old revision of the document!


Back to System Modeling Assessment and Roadmap Working Group

SysML v2 Model Formalism Working Group

Project Overview

The SysML v2 Model Formalism project originated as part of the SysML Roadmap effort within the OMG Systems Engineering Domain Special Interest Group (SE DSIG). The near term goal is to identify requirements related to the logical formalism that SysML v2 will be derived from.

Driving Requirements

  • The next-generation modeling language must include precise semantics that avoid ambiguity and enable a concise representation of the concepts.
  • The language must derive from a well-specified logical formalism that can leverage the model for a broad range of analysis and model checking.
  • This includes the ability to validate that the model is logically consistent, and the ability to answer questions such as the impact of a requirement or design change, or assess how a failure could propagate through a system.
  • The language and tools must also integrate with a diverse range of equation solvers and execution environments that enable the capture of quantitative data.

Example Use Cases

  • Create, view, update, delete, and execute model transformations to/from SysML models
  • Define, update, delete, and execute model queries to support visualization and analysis
  • Define, update, delete, and execute model validation rules to validate input data and model
  • Define, transform, and execute analytical models

Status Quo

  • SysML 1.x was originally designed to support diagrams rather than analysis; since then, the expectations on modeling have changed.

Limitations of SysML

  • SysML 1.x is defined as a profile of UML 2.x, which renders its extension capabilities limited.
  • SysML execution semantics are based on the current UML execution semantics, which only cover a small portion of the overall language.
    • More precisely, while fUML handles the execution semantics of the core of UML unambiguously, these semantics are based on a discrete model of behavior; whereas SysML needs to embrace both discrete and continuous behavior. Therefore, while SysML has access to unambiguous execution semantics for discrete behavior, the same cannot be said for the continuous behavior that SysML requires, which limits its applicability.
    • However, activity models can describe continuously changing quantities at small increments of time, like Simulink does. The attached activity diagram can be run in a clocked fashion, as in numerical simulation, see description around Figure 26 in http://tinyurl.com/ho537cp. fUML might support clocked execution, even though the reference implementation doesn't, but it doesn't support streaming. Clocked execution is within the UML semantics for activities, and it supports streaming, of course.
  • The current formalism for SysML requires more robust capability to support the full range of reasoning and model checking to ensure system design. Below are some example use cases.
    • After learning of the government regulation to increase MPG to 27.5, the engineer updates this requirement in the SME. As a result, the SME informs the engineer of which elements in the system design might be impacted by this requirement change (e.g., elements dealing with gear selection).
    • After making a change to the gear selection algorithm in the system design, the SME informs the engineer of impacted model elements, along with the associated analysis that need to be re-run. Based on the analysis, the engineer discovers that the vehicle's acceleration performance has been reduced. The engineer then uses the SME to determine what other elements have an impact on the acceleration performance to see what other changes could be made to the system design to restore the acceleration performance to the specified level.
    • The engineer decides that weight reduction will be the preferred approach to restore the acceleration performance. As a result, the engineer uses the SME to consider potential system design changes that could reduce the weight. One such change is to reduce the weight of the transmission. The engineer identifies design alternatives to reduce the transmission weight. For one of the promising candidates, the engineer acquires a model of the transmission from the manufacturer and integrates it into the system model. However, the SME informs the engineer that the electrical connectors are incompatible, and the engineer proceeds to investigate other alternatives.
    • Based on analysis of other alternatives, the engineer identifies a design alternative that satisfies the required acceleration performance and the required increase in fuel efficiency. The engineer then performs a verification analysis through the SME to verify that the system design still meets the requirements.

Derived Requirements for the Model Formalism

  • The SysML 2.0 formalism shall support computer interpretability of SysML 2.0 models.
  • The SysML 2.0 formalism shall support graphical notation.
  • The SysML 2.0 formalism shall support textual notation similar to a programming language.
  • The SysML 2.0 formalism shall support lightweight modeling (i.e., the formalism shouldn't be so rigid as to make sketching in the model cumbersome).

Key Features of New Concepts

  • TBD

Potential Formalism Candidates

Review Documents

Prototypes to Demonstrate Feasibility

  • TBD

SME/SysML v2 Service Requirements (e.g. functions) for the Model Formalism

  • TBD

Current Action Items

  • Emphasize the need for SysML v2 to be computer interpretable.
  • Clarify the need for both a textual notation similar to a programming language such as ALF and graphical notation for the formalism.
  • Clarify that the SME should make you aware of inconsistencies, and provide options for resolving them.
  • Clarify that the formalism should provide a precise and concise extension mechanism (similar to stereotypes).
  • Clarify that the use cases for model checking should include well formedness checking such as for interface compatibility.
  • Clarify the need to be able to apply varying degrees of formalism. For example, the language should not overly constrain the user when developing concepts, recognizing that concepts are formed throughout the life cycle and not just early on. This is partially addressed by differentiating the level of precision from the level of detail, but may also allow for relaxing formalism constraints based on user need.
  • Continue to refine the usability criteria and how the formalism can impact usability. As an example, some system engineers struggle to understand how to organize a model which involves the concepts of namespace and containment. The criteria should enable us to measure and assess how well a concept aligns with the way different representative users think. Consider the following representative users:
    • A new SysML modeler who may be experienced with other models such as Simulink
    • An experienced SysML modeler
  • Identify alternative formalisms and their pros and cons based on the requirements and evaluation criteria.

Team

sysml-roadmap/sysml_v2_model_formalism_working_group.1469473292.txt.gz · Last modified: 2016-07-25 15:01 by cbock