2  SysML v2: The Computational Revolution

2.1 From Documentation to Computation

SysML v2 [1] fundamentally transforms Model-Based Systems Engineering from a documentation paradigm to a computational one. Where SysML v1 served primarily as a specification language with ambiguous semantics requiring external tools for analysis, v2 provides formal first-order logic semantics, a comprehensive expression language, and standardized APIs that enable automated verification, simulation, and design space exploration directly from models. The July 2025 OMG adoption marks the culmination of seven years of development by 80+ organizations addressing v1’s core limitation: the inability to compute.

This transformation directly enables the MCP server we’re building (see Section 3.7.3). SysML v2’s textual notation means models can be stored in Git, processed by AI agents, and validated through CI/CD pipelines—the exact workflow this capstone demonstrates.

2.2 Why This Matters for AI-Augmented MBSE

MBSE has struggled with the “model-reality gap”—system architectures that couldn’t be validated, simulated, or traced to requirements without extensive manual effort and custom tooling. SysML v2’s formal foundation, built on the Kernel Modeling Language (KerML) [2] rather than UML, establishes precise execution semantics that tools can implement consistently.

For AI integration specifically, SysML v2 enables:

  • Textual models as code: LLMs can read, generate, and modify SysML v2 text directly
  • Evaluable requirements: Constraints return true/false, enabling automated verification
  • Standardized APIs: The Systems Modeling API provides consistent programmatic access
  • Git-native workflows: Models diff, merge, and branch like source code

This is why an MCP server for SysML v2 is tractable now when it wasn’t before—the language finally supports computational interaction.

2.3 SysML v1’s Inherited Limitations

SysML v1’s computational limitations trace directly to its architecture as a UML profile. When OMG created SysML in 2006-2007, they built atop UML 2’s metamodel—a reasonable choice for leveraging existing tool infrastructure but one that embedded software-centric assumptions and semantic ambiguity into a language intended for systems engineering.

2.3.1 The Semantic Precision Problem

OMG’s SysML v2 requirements documentation states: “The semantics of SysML v1 are often defined in English rather than a more precise formal representation.” This natural language approach meant different practitioners and tools could interpret the same model elements differently. The specification also “does not include a complete formal mapping between the concrete syntax and the abstract syntax,” allowing diagrams that couldn’t be unambiguously interpreted computationally.

2.3.2 Critical Language Gaps

Three gaps prevented automation:

  1. No standardized expression language: Practitioners had to use UML’s Object Constraint Language (OCL), designed for software and ill-suited for engineering calculations with physical quantities
  2. No standardized action language: Behavioral effects lacked specification, leaving semantics interpretation-dependent
  3. No textual control structures: Complex behaviors required graphical syntax that “can quickly become quite large and difficult to oversee and maintain”

2.3.3 Broken Model Interchange

XMI (XML Metadata Interchange) failed in practice because “every tool supports UML differently and exports XMI differently.” The OMG Model Interchange Working Group found systematic incompatibilities even for basic model elements. Diagrams—where practitioners estimated 90% of modeling work occurred—weren’t included in XMI exchange.

This interchange failure is precisely what the SysML v2 API specification addresses, and why our MCP server can rely on standardized REST endpoints rather than proprietary tool integrations.

2.4 KerML: The Formal Foundation

SysML v2’s computational capability rests on KerML (Kernel Modeling Language), an entirely new application-independent foundation replacing UML dependency. KerML provides syntactic and semantic foundations through three layers:

  • Root layer: Elements, relationships, and namespaces
  • Core layer: Types, classifiers, and features
  • Kernel layer: Specialized constructs

The formal semantics are specified as first-order logic (FOL), enabling mathematical precision unprecedented in systems modeling. KerML adopts “4D semantics” treating every occurrence as having both temporal extent (lifetime) and potentially spatial extent that can change over time.

2.4.1 Textual Notation

The textual representation enables computational workflows:

part def Vehicle {
    attribute mass :> ISQBase::mass;
    
    part engine : Engine {
        attribute mass :> ISQBase::mass = 200 [kg];
    }
    
    part transmission : Transmission {
        attribute mass :> ISQBase::mass = 100 [kg];
    }
    
    attribute totalMass :> ISQBase::mass = engine.mass + transmission.mass;
}

This notation enables:

  • Version control through Git (models diff, merge, branch)
  • Programmatic access through standard parsing
  • CI/CD pipeline integration
  • AI-assisted modeling through LLM processing

The textual and graphical notations are complementary renderings of identical underlying models.

2.4.2 Calculations and Constraints

Calculations become first-class reusable definitions:

calc def TotalMass {
    in masses : MassValue[*];
    return result : MassValue = masses->sum();
}

Constraints express evaluable assertions:

constraint def PowerConstraint {
    in totalPower : PowerValue;
    in maxPower : PowerValue;
    totalPower <= maxPower
}

2.4.3 Evaluable Requirements

Requirements transform from text fields to evaluable constraints:

requirement def MassRequirement {
    subject vehicle : Vehicle;
    attribute massActual : ISQ::MassValue;
    attribute massLimit : ISQ::MassValue;
    
    require constraint { massActual <= massLimit }
}

satisfy MassRequirement by vehicle;

The require constraint evaluates to true or false. The satisfy relationship explicitly binds design elements to requirements, creating traceable verification. This structure enables automated verification—tools can systematically evaluate all requirements against a design model, reporting pass/fail status with full traceability.

2.5 The Systems Modeling API

The Systems Modeling API and Services specification [3] standardizes programmatic model access through REST/HTTP, replacing v1’s broken XMI interchange. Tools implementing the API provide consistent endpoints for:

  • Element creation and querying
  • Relationship navigation
  • Version control operations (projects, branches, commits)
  • Ad-hoc and saved queries

This API-first architecture enables the computational workflows our MCP server exposes:

  • Automated validation: Traverse models evaluating requirement constraints
  • CI/CD integration: Run model checks on every commit
  • Cross-tool workflows: Exchange model data through standard REST calls
  • AI-assisted modeling: Process textual notation through language models

2.6 Comparative Standards Landscape

SysML v2 hasn’t eliminated the need for specialized standards. The ecosystem has evolved into a “hub and spoke” architecture:

Standard Relationship to SysML v2 Use Case
Modelica Complementary Continuous physical simulation (DAEs)
AADL Complementary Timing/schedulability analysis for embedded systems
MARTE Overlapping Real-time constraint specification
Capella Alternative Method-integrated architecture tooling
UAF/DoDAF Profile Defense enterprise architecture views

For this project, the key insight is that SysML v2 serves as the architectural backbone while domain-specific tools provide specialized analysis. The MCP server focuses on SysML v2 as the integration point, with future extensions potentially bridging to domain tools.

2.7 Tool Ecosystem Status

As of early 2026, the tool landscape includes:

Commercial tools with announced SysML v2 support:

  • CATIA Magic (Dassault Systèmes) - claims 100% conformance
  • IBM Rhapsody, PTC Modeler, Ansys SAM, Sparx Enterprise Architect - various maturity

Open source alternatives:

  • Eclipse SysON (Obeo/CEA) - web-based graphical environment [4]
  • Syside (Sensmetry) - VS Code extension for textual editing [5]
  • OMG Pilot Implementation - reference Eclipse and Jupyter environments [6]

Key gap: No lightweight Go-based tooling exists. The MCP server fills this gap with basic parsing and API proxy capabilities, aligning with GitLab’s infrastructure-first approach (see Section 9.4 for rationale).

2.8 Implications for This Project

SysML v2’s transformation from documentation to computation directly enables our MCP server architecture:

  1. Textual notation allows storing models in GitLab repositories, enabling the file-based tools our MCP server provides
  2. Standardized API means we can proxy to the reference implementation for full validation while providing lightweight local operations
  3. Formal semantics ensure consistent interpretation across our tools and upstream validators
  4. Git-native workflows align with GitLab’s collaboration model and CI/CD integration

The practical path forward: use the MCP server for AI-augmented model creation and exploration, with GitLab for persistence and collaboration, delegating complex validation to the SysML v2 API Services when formal compliance checking is needed.

2.9 Further Reading

For deeper exploration of SysML v2 concepts, see the OMG specifications [1], [2], [3] and the upstream research in Section 3.1 covering:

  • KerML semantics: 4D semantics, temporal/spatial extent modeling, first-order logic foundation
  • Expression language: Collection operators, conditional expressions, feature chaining
  • Tool implementation: Conformance testing, reference implementations (Section 3.3)
  • API integration: REST endpoints, query language (Section 3.4)