sysML 2 versus sysML 1.6

sysML 2 model in System Architect.

The Systems Modeling Language (SysML) has been a cornerstone for model-based systems engineering (MBSE) since its inception by the Object Management Group (OMG) in the mid 2000’s, providing a standardized way to represent complex systems through diagrams and relationships.

System Architect supports the sysML 1.6 specification, which was formally released by the OMG in December, 2019. The last version of the sysML 1-series was sysML 1.7, released in December 2021. The System Architect development team moved on to working on sysML 2.0 by that time. (The updates to version 1.7 focused on minor enhancements, such as updates to conjugated interface blocks and other clarifications.)

sysML 1.6 and sysML 1.7 represent the culmination of incremental refinements to the original sysML 1.0 standard, which was built as an extension of the Unified Modeling Language (UML) via profiles and stereotypes. In contrast, SysML 2, adopted in September 2025, marks a fundamental redesign of sysML — aiming to address longstanding limitations in expressiveness, precision, and interoperability for modern engineering challenges, and make it simpler to use. To that end, sysML 2 is no longer rooted in UML.

While SysML 1.6 refined the graphical notation and semantics inherited from UML, it still struggled with ambiguities in model interpretation, limited automation, and silos in tool integration, often requiring workarounds for complex system-of-systems modeling.

SysML 2 introduces a new metamodel based on the Kernel Modeling Language (KerML), enabling formal semantics that ensure unambiguous definitions and consistent usage patterns across models. This shift allows for both graphical and textual notations, synchronized in real-time, which supports scripting, version control, and automated analysis.

Additionally, sysML 2 incorporates a standardized API for programmatic access, fostering better integration with other engineering tools and domains. The transition to sysML 2 promises significant benefits for systems engineers, including improved reusability through explicit inheritance mechanisms, native handling of requirements and lifecycle states, and enhanced support for variability and verification in large-scale projects.

However, sysML 2 lacks backward compatibility with sysML 1.6 models, necessitating reconstruction or migration strategies.

Overall, sysML 2 promises a more mature, purpose-built language for MBSE, better equipped to handle the demands of digital engineering, AI integration, and collaborative workflows in industries like aerospace, automotive, and defense.

Here are some of the main differences between sysML 1.6 and sysML 2:

1. Architectural Foundation and Metamodel

SysML 1.6 is fundamentally a profile extension of UML 2, inheriting its software-oriented metamodel, which uses stereotypes to adapt UML elements like classes into sysML blocks for systems engineering purposes.

This approach, while effective for initial adoption, led to inconsistencies and limitations in handling non-software systems, as the underlying UML semantics were not always perfectly aligned with systems engineering needs.

sysML 2 departs from this by building on the KerML metamodel, a dedicated foundation for systems modeling that provides a clean, extensible structure without UML’s baggage.

KerML enables domain-specific extensions and formal definitions, making SysML 2 more adaptable to diverse engineering contexts and reducing the need for custom stereotypes.

2. Notation and Syntax

In SysML 1.6, modeling is exclusively graphical, relying on 9 diagram types:

  • Activity diagram,
  • Block definition diagram,
  • Internal block diagram,
  • Package diagram,
  • Parametric diagram,
  • Requirement diagram,
  • Sequence diagram,
  • State machine diagram, and
  • Use case diagram.

This diagram-centric approach can lead to interpretation ambiguities and challenges in version control or automation.

SysML 2 introduces a dual notation system: refined graphical syntax with view types including:

  • Action Flow views,
  • Definition and Usage Views
  • Interconnection views,
  • Individual views,
  • Item definition views,
  • Metadata definition views,
  • Package Views,
  • Sequence Views,
  • State definition views,
  • Transition views,
  • Use case definition views,
  • Requirement definition views, and
  • View definition views (corresponding to activity diagrams, internal block diagrams, and other v1 diagrams for behaviors, structures, requirements, and more),

These modeling views are synchronized with a new textual syntax that resembles programming languages. The textual modeling allows for precise scripting, bulk edits, and integration with tools like Git, enhancing collaboration and enabling automated model generation or validation that was cumbersome in version 1.6.

3. Semantic Precision and Consistency

SysML 1.6 features loosely defined semantics, where elements like definitions and usages are inconsistently applied, often requiring manual interpretation or external documentation to resolve ambiguities in complex models. This can result in miscommunication across teams.

sysML 2 formalizes semantics with unambiguous rules, integrating consistent patterns for definition-versus-usage and decomposition, making models more verifiable and analyzable.

For instance, it standardizes terminology mappings and ensures every element has a clear, machine-interpretable meaning, reducing errors and supporting advanced automation like simulation directly from models.

4. Interoperability and API Support

Tool integration in SysML 1.6 is limited, often confining models to isolated environments without standardized access methods, which hinders cross-domain collaboration. SysML 2 addresses this with a standard REST/OSLC-based API that enables full create-read-update-delete (CRUD) operations on models programmatically.

This sysML 2 API facilitates seamless connections with other tools, such as PLM systems or simulation software, creating a digital thread that supports end-to-end engineering processes and eliminates silos.

5. Enhanced Modeling Capabilities

SysML 1.6 handles reuse and inheritance implicitly through stereotypes, requirements as stereotyped blocks, and lifecycle aspects manually via external tracking, which can be inefficient for large systems. SysML 2 enhances these with explicit syntax for clean reuse and inheritance, native requirement elements with built-in «satisfy» and «verify» relationships, and integrated occurrences and snapshots for lifecycle fidelity. It also better supports variability, deep nesting of features, and system properties like objects over time, making it more suitable for complex, evolving systems.

6. Modeling of Ports

The modeling of ports differs significantly between SysML 1.6 and SysML 2, reflecting the shift toward a more unified and formal approach in the latter.

In SysML 1.6, ports are primarily of 2 types:

  • Full ports, which are physical components that can own features, behaviors, and internal structures, and
  • Proxy ports, which act as delegates to expose internal features or parts without being physical entities themselves.

Standard UML ports and atomic flow ports from earlier versions of the sysML 1 spec were deprecated in favor of these, with interface blocks typing the ports and supporting conjugation via ~InterfaceBlock to reverse directions.

In SysML 2.0, port modeling is simplified and integrated into the definition-usage pattern, eliminating the distinction between full and proxy ports; instead, ports are defined using PortDefinition (for reusable port types) and used via PortUsage (as specialized parts or features), allowing direct connections between parts without proxies, support for nested ports, attributes, and directionality, with conjugation using ~ notation for reversing flows and more flexible interface definitions that can inherit from connections.

This change in SysML 2 enhances consistency, reduces complexity in handling interfaces, and better supports automated analysis and reuse by treating ports as integral parts of the system’s structure.

Support for sysML 2 in System Architect

UNICOM System Architect currently has beta support for the sysML 2 spec in its System Architect 2026 Update 1 release (SA 11.4.13.1, released in February 2026) and intends to provide general availability of its sysML 2 support in its SA 2026 Update 2 release.

Be the first to comment

Leave a Reply

Your email address will not be published.


*