2  Foundation

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 2.7). 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. 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”

XMI (XML Metadata Interchange) failed in practice because “every tool supports UML differently and exports XMI differently.” 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.

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, programmatic access through standard parsing, CI/CD pipeline integration, and AI-assisted modeling through LLM processing.

2.4.2 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.

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), and ad-hoc and saved queries.

This API-first architecture enables the computational workflows our MCP server exposes: automated validation, CI/CD integration, cross-tool workflows, and AI-assisted modeling.

2.6 Upstream Repositories

The SysML v2 reference implementations are hosted at github.com/Systems-Modeling:

Repository	Purpose	License
SysML-v2-Release	Latest incremental releases (start here)	LGPL-3.0
SysML-v2-Pilot-Implementation	Parser, Eclipse IDE, Jupyter kernel	LGPL-3.0 / GPL-3.0
SysML-v2-API-Services	REST/HTTP API reference server	LGPL-3.0 / GPL-3.0
SysML-v2-API-Python-Client	Generated Python client	LGPL-3.0
SysML-v2-API-Cookbook	Jupyter notebook examples	N/A

2.6.1 Parser Technology

Component	Technology
Language	Java 21+ (Eclipse 2025-03)
Framework	Xtext (generates parser from grammar)
Metamodel	Eclipse EMF (Ecore)
Build	Maven with Tycho (for Eclipse plugins)

Key finding: Full SysML v2 parsing requires JVM (Xtext/EMF). Our tree-sitter grammar provides a documented subset with error recovery suitable for AI integration workflows.

2.7 Architecture Selection

Evaluated three integration options:

Option	Approach	Pros	Cons
A	Pure API Proxy	Simple, no JVM	Requires running server
B	Embedded JVM Parser	Offline, full AST	Large footprint
C	Hybrid (selected)	Single binary + validation	Grammar maintenance

┌─────────────┐     ┌─────────────┐     ┌──────────────────┐
│ LLM Client  │────▶│ MCP Server  │────▶│ SysML v2 API     │
│             │     │ (Rust)      │     │ (for validation) │
└─────────────┘     │      │      │     └──────────────────┘
                    │      ▼      │
                    │tree-sitter- │
                    │   sysml     │
                    └─────────────┘

Rationale: Balances deployment simplicity (single Rust binary) with validation capability (API server for full SysML v2 compliance). Tree-sitter grammar handles parsing with error recovery; API server handles complex semantic validation when available.

2.8 Tool Ecosystem

As of early 2026:

Commercial tools with SysML v2 support: CATIA Magic (Dassault), IBM Rhapsody, PTC Modeler, Ansys SAM, Sparx EA

Open source alternatives: Eclipse SysON (web-based graphical), Syside (VS Code extension), OMG Pilot Implementation (reference)

Key gap: No lightweight tooling exists for AI integration with SysML v2. This project fills that gap with a tree-sitter grammar and MCP server.

2.9 Industry Context

[4] argues that agile hardware engineering requires Git-based revision control for system models—not just agile tactics layered on legacy PLM tools. SysML v2’s textual notation enables branching/merging workflows approximating software engineering agility.

Our position: This capstone follows INCOSE processes for academic rigor, while the MCP server aligns with the agile vision—enabling AI tools to interact with SysML models in Git repositories. Commercial tools like SysGit provide mature platforms for this workflow; our open source MCP server provides a lightweight alternative focused on AI integration.

2.10 Key Findings

1. Parser complexity: Full SysML v2 parsing requires JVM (Xtext/EMF). Tree-sitter provides documented subset with error recovery.
2. API maturity: The REST API spec is stable and well-documented. OpenAPI clients available.
3. JSON-LD format: All API responses use JSON-LD with @id, @type conventions.
4. Git-native workflows: Industry momentum toward storing SysML v2 models in Git repositories.

[1]

Object Management Group, “OMG systems modeling language (SysML) v2.0 specification,” 2025. Available: https://www.omg.org/spec/SysML/2.0/

[2]

Object Management Group, “OMG kernel modeling language (KerML) 1.0 specification,” 2025. Available: https://www.omg.org/spec/KerML/1.0/

[3]

Object Management Group, “OMG systems modeling API and services 1.0,” 2025. Available: https://www.omg.org/spec/SystemsModelingAPI/1.0/

[4]

S. Massey, “A discussion on accelerating hardware engineering through agile practices.” 2025. Available: https://resources.sysgit.io/a-discussion-on-accelerating-hardware-engineering-through-agile-practices/