SysML v2 at Industrial Scale: Why Success Depends on Testbeds, Not Technology

A First Assessment of Deployment Realities and De-Risking Strategies

Disclaimer: The views and analysis presented in this article are my own and do not represent the position, strategy, or opinions of my employer, Airbus Defence and Space, or any affiliated organizations.

After an analysis of the newly published SysML v2 specification and its emerging ecosystem, I want to share some findings that I believe are critical for anyone considering industrial-scale deployment. This is a preliminary assessment with indicative figures that will need community refinement — my goal is to start an honest conversation, not deliver final answers.

The core message is uncomfortable but necessary: SysML v2’s technical merits are real, but its industrial success is far from guaranteed. What will determine the outcome is not the language specification, but how we collectively engineer the socio-technical infrastructure around it.

What SysML v2 Gets Right

Let me start with the positives, because they are substantial:

Semantic Foundation: The move from UML profile to KerML (Kernel Modeling Language) provides formal, unambiguous semantics. The separation of definition (reusable types), usage (contextual instances), and occurrence (runtime entities) is a major advancement for configuration management and holarchic modeling.

Modern Architecture: API-first design, textual notation for version control, and standardized REST/OSLC foundations move us beyond XMI file exchange. Support for 4D modeling (spatial + temporal extent) aligns with digital twin requirements.

Ecosystem Awareness: Unlike previous standards, SysML v2 explicitly acknowledges OSLC, PLM integration, and federated environments in its specification context — even if it doesn’t normatively define them.

These are necessary conditions for success. But they are not sufficient.

The Uncomfortable Reality: A Five-Layer Complexity Stack

Here’s what the analysis revealed: SysML v2 is not a modeling language upgrade — it’s a complete technology stack.

Organizations must deploy:

1. Language layer: EBNF grammar, textual syntax, learning curve
2. Metamodel layer: MOF/UML infrastructure dependencies (KerML, OCL, QVT)
3. Transformation layer: Multiple format mappings (textual ↔ graphical ↔ JSON ↔ legacy)
4. Tool ecosystem: Immature (end-2025), fragmented, vendor-dependent
5. Infrastructure layer: Distributed client-server, API management, DevOps for models

Indicative TCO for 50–100 engineers (preliminary estimate requiring validation):

• Initial: €1M-4M
• Recurring: €400k-1M/year

This includes infrastructure, tooling, training, integration development, and dedicated support personnel (admin, DevOps, methodology).

Skills required span systems engineering, software development, ontology/semantics, and infrastructure operations — a rare combination.

The Critical Gaps: What’s Missing Today

1. Configuration Management — The Invisible Crisis

SysML v2 has no native semantic versioning or configuration management. The specification defines model structure beautifully but leaves temporal evolution unaddressed.

Why this matters: In aerospace and automotive, we need to:

• Reconstruct exact configurations from 5–10 years ago
• Manage variants across product lines
• Track supplier component versions
• Support certification baselines

Git is explicitly inadequate for this (line-based diffs, file-centric, no semantic constraints). My analysis suggests organizations will face:

• False conflicts when engineers modify disjoint model regions in same file
• Broken baselines (Git tracks files, not system configurations)
• No validation of configuration coherence

This is not a tooling gap — it’s an architectural omission.

2. Integration with Legacy — The STEP Lesson

Those of us who lived through STEP (ISO 10303) deployment know this story: STEP had APIs, vendor implementations, and OMG services (PDM Enablers, PLM Services) — yet integration largely failed at scale despite actual value creation and investment of many industrial players.

Not because of technical immaturity, but because:

• Vendors had no incentive to enable deep interoperability (preserving lock-in)
• IT departments blocked deployment (security, IP protection, risk)
• Governance frameworks didn’t exist (who owns what semantics, when, how)

SysML v2 will face identical barriers unless we address them explicitly this time.

3. Multi-Enterprise Collaboration — The Sovereignty Challenge

Modern supply chains are no longer vertically integrated. Collaboration is:

• Contractual and short-lived
• Cross-organizational
• Sovereignty-sensitive
• Multi-tool, multi-vendor

SysML v2 API mentions OSLC but doesn’t define integration. The specification acknowledges lifecycle integration needs but leaves implementation as “future work”.

Current reality (validated through tool testing):

• ❌ No semantic merge across repositories
• ❌ No locking/conflict resolution
• ❌ No workflow governance
• ❌ No partial visibility controls
• ❌ No variant baseline management

Why Data-Based Ecosystem (DBE) Platforms Matter

This is where sovereign digital platforms like Catena-X (automotive), Decade-X (aeronautics), and similar DBE initiatives become strategically critical.

These platforms provide:

• Data sovereignty by design (IDS/EDC policy enforcement)
• Federated authority (not centralized control)
• Cross-enterprise trust frameworks
• GAIA-X alignment for European digital autonomy

But here’s the gap: These DBE platforms focus on operational data (parts, logistics, lifecycle events) via technologies like Asset Administration Shell (AAS). They don’t yet address system-level semantic modeling — which is where SysML v2 sits.

The opportunity: Integrate SysML v2 semantic reasoning with DBE operational data. For example:

• A supplier’s AAS describes a physical component
• The OEM’s SysML v2 model defines system-level requirements
• The testbed validates: “Does this component meet interface contracts?”

This requires mediation layers that no standard currently defines.

The Only Credible De-Risking Path: Testbeds

After analyzing failure modes from STEP, UML-based integration attempts, and early SysML v2 deployments, one conclusion is inescapable:

Testbeds are not optional — they are the risk-control instrument.

What a Testbed Must Do

Not a demo. Not a vendor sandbox. An engineering validation platform that:

1. Tests technology combinations (SysML v2 + STEP + Knowledge Graphs + DBE platforms)
2. Exposes failure modes safely (performance, merge conflicts, sovereignty breaches)
3. Produces evidence, not promises (vendor benchmarks, integration patterns, limits)
4. Validates governance models (who owns what, when, under what rules)
5. Measures, not assumes (latency, scalability, configuration complexity)

Critical Test Scenarios

Based on the analysis, these are non-negotiable validations before production:

Why Cross-Domain is Essential

A testbed must NOT be DBE-specific (automotive-only, aerospace-only). Here’s why:

• Standards alignment requires cross-sector validation (STEP AP242, ISA-95, ArchiMate, SysML v2, OSLC)
• Governance patterns are sector-neutral (versioning, authority, mediation)
• Vendor interoperability must be proven across industries
• Sovereign platforms (Catena-X, Decade-X, etc.) share architectural principles

Recommended governance: A consortium involving:

• Big integrators from key sectors (aerospace, automotive, electronics)
• DBE platform representatives
• Standards bodies (OMG, ISO, INCOSE)
• SME suppliers (avoiding large-enterprise bias)
• Academic/research institutions

Realistic Adoption Roadmap

Phase 1: Testbed & Validation (2026–2027) — 18 months

Investment (indicative, needs refinement): €2–3M shared across consortium Team: 8–12 people (multi-profile: systems engineers, ontologists, DevOps, PLM experts)

Deliverables:

• Operational testbed (SysML v2 + STEP + KG + DBE connectors)
• 5 scenarios validated (configuration, scale, sovereignty, temporal, integration)
• API compliance benchmark (vendor-neutral)
• Integration pattern catalog
• Published failure modes and limitations

Success criteria:

• IT departments from 3+ organizations accept security model
• Vendors demonstrate real APIs (not roadmaps)
• Measurable ROI on 1 pilot program

Phase 2: Controlled Adoption (2027–2029)

Strategy: Hybrid coexistence, not replacement

• SysML v1: Existing critical programs (aerospace certification, automotive safety)
• SysML v2: New, non-critical programs (exploration, early-stage design)
• Testbed: Continuous validation for production candidates

Avoid:

• ❌ “Big bang” migration
• ❌ Treating SysML v2 as PLM replacement
• ❌ Mandating v2 before tooling/methodology mature

Phase 3: Ecosystem Maturity (2029+)

Conditions for broad deployment:

• ✅ 3+ vendor tools production-ready (with SLA)
• ✅ Versioning/configuration standard (OMG or de facto community standard)
• ✅ OSLC integration proven in practice
• ✅ Certification authorities accept SysML v2 artifacts
• ✅ Training/methodology mature

Integration Architecture: Federated, Not Monolithic

The analysis strongly indicates this principle:

“STEP tried to standardize the product; SysML v2 must standardize the reasoning — and only integrate the results.”

The Correct Pattern

┌─────────────────────────────────────────┐
│   SysML v2 Semantic Workspace           │
│   (Exploration, Architecture, Trades)   │
└──────────────┬──────────────────────────┘
               │
     ┌─────────▼──────────┐
     │  Mediation Layer    │ ◄─ MANDATORY
     │  • Aggregation      │
     │  • Contracts        │
     │  • Authority Rules  │
     └─────────┬───────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
    ▼          ▼          ▼
┌────────┐ ┌───────┐ ┌──────────────┐
│  PLM   │ │  ALM  │ │ DBE Platform │
│(Parts, │ │(Reqs, │ │  (Suppliers) │
│Change) │ │Tests) │ └──────────────┘
└────────┘ └───────┘

What to integrate: ✅ Interface contracts ✅ Validated requirements ✅ Frozen configurations ✅ Trace links (via OSLC)

What NOT to integrate: ❌ Live work-in-progress models ❌ Internal graph structures ❌ Exploratory variants ❌ Intermediate reasoning steps

This requires permanent mediation — not a transitional phase.

Open Questions Requiring Community Input

This assessment raises questions I cannot answer alone:

1. Configuration management: Should OMG standardize semantic versioning, or will de facto practices emerge from testbeds?
2. DBE integration: How do we align AAS (asset metadata) with SysML v2 (system semantics) without creating dual-truth problems?
3. Certification: Will aerospace (DO-178C) and automotive (ISO 26262) authorities accept SysML v2 artifacts, and under what constraints?
4. Governance: Who defines authority boundaries in multi-enterprise models? Contracts? Standards? Platforms?
5. Tooling maturity: What are realistic production-readiness timelines? Current estimates (2027–2028) need vendor validation.
6. TCO validation: The €1–4M figures are preliminary — we need industry-wide cost/benefit data.

Red Flags = Project Failure

Based on historical analysis (STEP, UML integration attempts), these are warning signs:

• 🚩 Vendor claims “API-ready” but provides no public test endpoint
• 🚩 IT, M&T, Pilot Programs not involved in architecture from day 1
• 🚩 No testbed, jumping directly to production deployment
• 🚩 Treating SysML v2 as “better UML” (semantic shift missed)
• 🚩 Expecting Git alone for configuration management
• 🚩 No mediation layer in integration architecture
• 🚩 “Single source of truth” positioning (ignores legacy reality)

Call to Action: Building the Testbed Consortium

If you’ve read this far, you likely share the concern that SysML v2 success is not automatic.

What’s needed is a cross-sector, open consortium to:

1. Define testbed architecture (federated, not DBE-centric)
2. Align open standards (SysML v2, OSLC, STEP, IDS, AAS)
3. Produce evidence (benchmarks, failure modes, integration patterns)
4. Develop mediation frameworks (semantic ↔ operational)
5. Establish governance models (authority, versioning, sovereignty)

Who should be involved:

• Big integrators from aerospace, automotive, electronics sectors
• DBE platforms (Catena-X, Decade-X, and equivalents)
• Standards bodies (OMG, INCOSE, ISO TC184, OASIS)
• SME suppliers (real-world constraints)
• Tool vendors (transparency, not promotion)
• Research institutions (neutrality, rigor)

Funding models to explore:

• Shared industry investment (€2–3M / 3 years across consortium)
• EU programs (Horizon Europe, Digital Europe)
• National funding (BPI France, similar in Germany/UK)
• In-kind contributions (infrastructure, expertise)

Final Perspective

SysML v2 represents a genuine semantic advancement — but semantic precision alone does not guarantee industrial success.

STEP taught us that APIs and standards are necessary but not sufficient. What blocked STEP wasn’t technology — it was:

• Vendor incentives
• IT risk aversion
• Lack of governance frameworks
• Absence of neutral experimentation spaces

SysML v2 will face identical barriers unless we address them explicitly.

The testbed approach is not academic caution — it’s the only responsible path given:

• Complexity identified (5-layer stack)
• Integration gaps confirmed (configuration, multi-enterprise, legacy)
• Historical precedent (STEP, UML)
• Industrial stakes (digital sovereignty, supply chain resilience)

Next Steps

I’m committed to advancing this work and welcome collaboration. Immediate priorities:

1. Refine cost/benefit analysis with industry data
2. Define testbed technical architecture (open for community input)
3. Engage DBE platforms for alignment discussions
4. Formalize consortium structure (governance, IP, funding)
5. Publish detailed technical assessments (configuration management, OSLC integration patterns)

If you are:

• A decision-maker in aerospace, automotive, or complex systems sectors
• Leading digital transformation or PLM/MBSE initiatives
• Involved in DBE platform governance
• A standards body representative
• An academic/researcher in systems engineering or semantic interoperability

Let’s connect. This challenge requires collective intelligence, not isolated solutions.

Disclaimer

This is a preliminary assessment based on:

• Published SysML v2 specification analysis
• Tool ecosystem evaluation (open-source: SysON, SysML v2 API pilot; commercial: limited public data)
• Historical comparison (STEP, UML/SysML v1 integration)
• Industrial project experience in aerospace PLM

Figures are indicative and require validation:

• TCO estimates (€1–4M initial) need sector-specific refinement
• Timeline projections (2027–2028 maturity) depend on vendor/community progress
• Test criteria (performance, scale) need empirical calibration

I welcome corrections, additional data, and alternative perspectives. The goal is accuracy, not advocacy.

About the Author: 30 years aerospace, PLM interoperability, Standards work, Testbed experience from SIP/IMAGINE, focus on continuous operational interoperability and federated frameworks This paper

What are your experiences with SysML v2 or similar modeling standard deployments? What challenges have I missed? Let’s build this understanding together in the comments.