"SysML v2 Review: The Good, the Bad & the Ugly" by C. Kobryn

SysML v2 Review: The Good, the Bad & the Ugly

by Cris Kobryn 2 Feb 2026

TL;DR — Executable System Architecture Modeling LanguageRating:
⭐⭐⭐½☆ 3.5/5 — Needs Significant Rework

---

Background Context (Optional)

Most of the foundational work required to define Systems Modeling Language (SysML) v1 as a systems engineering dialect of the software-centric Unified Modeling Language (UML) v2 was performed during 2003–2005 by the SysML Partners’ open specification project (https://SysML.org). Because SysML v1 was defined as a UML v2 Profile, it reused UML’s abstract syntax and much of its semantic and execution foundation, including modeling, simulation (ModSim), and code-generation-oriented execution semantics already implemented by tool vendors.

As a result, the deep semantic and execution infrastructure existed prior to SysML-specific specialization.

The SysML Partners’ work therefore focused primarily on:

• Removing UML constructs that were excessively software-centric or gratuitous for systems engineering.
• Generalizing UML components and interfaces to represent hardware and firmware as well as software.
• Refining syntax and usage to make the language more accessible to mechanical and electrical engineers unfamiliar with object orientation.

After a byzantine and politically fraught standardization process, SysML v1 was adopted by the Object Management Group (OMG) in 2006 and released as OMG SysML v1.0 in September 2007. Since then, it has been widely endorsed, implemented by major modeling vendors, and applied to mission-critical programs worldwide. The latest minor revision is OMG SysML v1.7.

A major revision effort, OMG SysML v2, began in 2017 and was published by the OMG in September 2025 (https://www.omg.org/spec/SysML/2.0).

The following sections examine SysML v2 as an executable system architecture modeling language suitable for large-scale, mission-critical systems engineering programs requiring strong ModSim and code-generation capabilities.

---

The Good

SysML v2 introduces several important advances.

1. Textual and Graphical Syntax Support

SysML v2 standardizes both textual notation and graphical projections. The textual form enables:

• Version-controlled modeling
• Diff/merge workflows
• Continuous Integration / Continuous Delivery (CI/CD) pipeline integration
• ModSim and Model-as-code automations for Digital Twins

Unlike SysML v1, textual syntax is standardized rather than vendor-proprietary.

2. Greater Semantic Precision

SysML v2 reduces ambiguities present in SysML v1. Structure, behavior, and requirements are defined with more rigor. While not formal in the proof-theoretic sense, the language is grounded in KerML, which defines a more explicit semantic core than UML Profiles alone.

3. Improved Interoperability Architecture

SysML v2 introduces a standardized API and service-based interaction model, addressing historical inconsistencies of XMI-based interoperability. In principle, this enables:

• Tool-neutral model exchange
• Federated modeling workflows
• Service-based model integration

4. Requirements as First-Class Model Elements

Requirements are machine-readable and tightly integrated with structural and behavioral elements. This enables:

• Traceability automation
• Validation workflows
• Formal dependency analysis

5. Reduced UML Software Bias

By introducing KerML as a modeling kernel, SysML v2 attempts to represent general systems engineering abstractions more directly rather than inheriting UML’s software-centric constructs.

---

The Bad

Despite its advances, SysML v2 presents major technical concerns.

1. Architectural Overreach and Second-System Effects

SysML v2 exhibits characteristics of second-system syndrome. The introduction of KerML as a foundational metamodel expands scope beyond incremental refinement.

Key concerns:

• Additional abstraction layers increase conceptual complexity.
• The language now requires understanding of both KerML and SysML.
• Implementation burden for tool vendors is significantly higher.

Expressiveness improves — but cognitive load and adoption friction increase.

2. Conflated Metamodel Semantics

KerML introduces powerful but conceptually dense primitives.

However:

• Typing and subclassing semantics can overlap in ways that blur conceptual boundaries.
• The distinctions among definition, usage, specialization, and feature membership tend to be academic, subtle, and non-intuitive by practical engineers.
• Overloaded abstraction mechanisms increase reasoning complexity.

This complicates modeling discipline and tool implementation.

3. Heavyweight Extension Mechanisms

SysML v1 Profiles were arguably too lightweight for deep semantic extension. However, SysML v2 library-based mechanisms may be overly heavyweight for routine domain customization:

• Domain tailoring requires disciplined library engineering.
• Extension authors must understand metamodel semantics.
• Simple stereotype-like tagging becomes non-trivial.

The pendulum has swung from under-engineered to over-engineered extensibility.

4. Fragmented Model Execution Semantics

SysML v2 does not deliver a fully unified execution semantic foundation across:

• Action-based behavior
• State-based behavior
• Interaction-based behavior

Although influenced by UML and fUML, it does not define a single harmonized Turing-complete semantic model across all behavioral paradigms.

Consequences include uncertain simulation fidelity and inconsistent code-generation behavior across tools.

5. Textual Bias and Notation Usability Issues

Although graphical projections exist, specification emphasis and early implementations are strongly textual.

Technical usability issues include:

• Non-obvious scope visibility rules
• Name resolution ambiguity without explicit qualification
• Punctuation density and symbolic verbosity
• Limited intrinsic structuring conventions for large models

Review of SysML v2.0 — Language Specification's Annex A: Example Model shows that even relatively simple systems require extensive textual volumes. On large programs, gratuitous verbosity impairs architectural communication and increases errors ("1K words = 1 picture/diagram").

6. Inadequate support for software-centric interfaces

SysML v2 simplifies hardware-oriented interfaces grounded in physical flow metaphors (e.g., atom, electron, photon flows). However, it does not equally emphasize software-centric interfaces based on contractual dependency metaphors (such as service offerers and providers), creating a gross deficiency if software-intensive systems-of-systems.

7. Confusion between diagram views and architecture abstraction views

The specification does not clearly distinguish between two complementary types of views:

• Diagram views per UML v1, UML v2 and SysML v1, which are familiar to most engineers.
• Architecture abstraction views per ISO/IEC/IEEE 42010

This risks weakening stakeholder-oriented system architecture discipline and best practices.

8. Tooling Immaturity and Lack of Automated Migration

SysML v1 benefits from mature ModSim ecosystems, whereas SysML v2 tooling remains early-stage:

• Limited industrial-grade bidirectional editing
• Limited robust execution platforms
• Absence of comprehensive compliance test suites
• Limited automated migration support

Organizations face retraining costs, transition disruption, and uncertain ROI.

---

The Ugly

When transition risk outweighs perceived benefit, adoption slows.

At present, moving from SysML v1 to v2 is high-risk and low-reward for mission-critical programs.

With its steep learning and implementation curves, and without:

• Unified execution semantics for Actions, States and Interactions
• Industrial-scale validation with reference implementations and compliance test suites
• Mature ModSim tooling that will support Digital Twin futures
• Vendor-aligned architecture roadmaps for planning model migrations and large-sale projects

large-scale SysML v1 to v2 transition introduces substantial uncertainty.

Risks include:

• Costly migration
• Substantive process re-engineering overhead
• Ecosystem fragmentation
• Productivity loss

---

Recommendations

The issues identified above are technically solvable.

A focused, vendor-led remediation effort could address:

• Fully synchronized graphical/textual editing, where the textual editing tools offer mproved textual structuring and diagnostics on par with those used for mainstream programming languages
• Unified executable behavioral semantics for ModSim and code generation
• Clear architectural layering aligned with ISO/IEC/IEEE 42010
• Automated SysML v1 → v2 migration pipelines
• Comprehensive reference implementations and compliance test suites

Historically, modeling language stabilization has required coordinated commitment from major tool vendors — a notable example being the UML v1 Semantic Task Force. That task force completely rewrote the semantics of UML v1 between January and August 1997, an intensive eight-month effort that stabilized the language prior to broad industrial adoption. A comparable 6–9 month, ModSim-expert-driven remediation initiative could substantially strengthen SysML v2.

---

In summary, SysML v2 introduces meaningful technical advances in semantic rigor and interoperability. However, its increased abstraction, execution fragmentation, textual complexity, tooling immaturity, and transition risk present substantial challenges for large-scale, mission-critical systems engineering adoption.

---

About the Author
Cris Kobryn is the Founder & CTO of PivotPoint Technology Corp. He previously served as Technical Lead for UML v1, UML v2, and the open source SysML v1 language design teams.