SysML v2 Logo

Print Friendly, PDF & Email

This blog post gives you a brief overview of the general requirements on proposals for SysML v2 and the SysML API & Services. The previous blog post gave an overview of the RFP’s. Following blog posts present details of specific sections of the RFP’s.

The general requirements are valid for all proposals for OMG specifications and are not specific to SysML. So, some of them are only partially relevant for SysML.

General requirements
If a proposal uses models, it shall use an OMG modeling language and provide an XMI representation of the models. This requirement is relevant to SysML v2.

The OMG is a strong advocate of the Model-Driven Architecture (MDA) concept. If a proposal specifies Platform-Independent Models (PIM) and Platform-Specific Models (PSM), it shall also provide the transformation rules between the PIM’s and the PSM’s and specify whether the transformation or the PSM’s are normative.

The general requirements include several quality requirements.

A proposal shall…

  • …be complete according to precision and functionality.
  • …support minimalism, i.e., use reusable parts wherever appropriate.
  • …be independent of other specifications wherever possible.
  • …avoid duplication of other specifications. In that case, reuse is more important than independence.
  • …explicitly address security-sensitive elements like an authentification mechanism, if they are part of the proposal.
  • …minimize changes to existing specification.
  • …be compatible with existing specifications.
  • …preserve implementation flexibility, i.e., a high degree of freedom for the vendors how to implement the standard.
  • …support encapsulation, i.e., the ability to exchange an implementation without the need to change clients of the implementation.
  • …specify the degree of internationalization, for example, if it is specific to a region.

Note again that these are all general requirements for proposals for OMG specifications and that they are not specific to SysML. The requirements are all a little bit vague. Finally, the adoption of a proposal is decided by a vote, and not by a complete satisfaction of all requirements.

A special aspect is the relationship with other specifications (independence, reuse, changes). Specific for this RFP is a list of other specifications that must be considered by the proposal. These are DD, MOF, SMOF, SysML v1, UML, and XMI. The following specification could be considered: ALF, BMM, DMN, FUML, MARTE, OCL, ODM, PSCS, PSSM, ReqIF, SysPhS, UAF. It seems that we love abbreviations. Do you know all of these abbreviations? If not, click the links to find out what it is.

I have some more abbreviations. The RFP also mentions some OMG specifications that are currently in progress and not officially published yet. They should also be considered: MEF, S&R, MVF, SIMF, UOTR. In particular notable is the S&R specification, i.e., the Safety & Reliability Profile that allows capturing safety and reliability information in a system model.

Last, but not least, the RFP also asked to consider some non-OMG work: ISO 80000, FMI, STEP, ISO 42010, ISO 15288, ISO 15704, ISO 26550, ISO 9241-220.2, INCOSE Handbook, SEBoK.

Lot of stuff to read and to manage the links to SysML v2.

Evaluation criteria
Although the specifications should be independent of their implementations, the RFP’s list some evaluation criteria for implementations to check their viability. The evaluation criteria are performance, portability, securability, inspectability, and testability. For example, the OMG considers whether implementations of a specification are available on multiple platforms (portability).

The next blog post covers the requirements about the language architecture of SysML v2. Stay tuned!

Previous blog posts of this series:

Planned future blogs posts:

  • 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
  • NextGenSysML Part 8 – Behavior Requirements
  • 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 – API & Services: Architecture Requirements
  • NextGenSysML Part 15 – API & Services: Conformance Requirements
  • NextGenSysML Part 16 – API & Services: Service Requirements

 

1 Comment

  • Jeffrey R. Cohen, P.E.

    Reply
    30. November 2018at14:15

    The nice thing is that the proposal doesn’t change how we do our jobs of specifying systems. It affects some tools and perhaps some non-standard artifacts. But SysML is only the language, we still need simple and sensible processes/workflows for development. People violate the intent of the new spec proposal when they try to customize and extend the tools in the name of simplification.

Post a Comment