Run the same SysML v2 model through two tools that both claim full spec compliance and you can get two different simulation traces. Same states, same transitions, same requirement allocations on paper, different numbers out the other end. That's not a bug report. It's the current, documented state of the standard, and it's worth understanding before you bet a program's digital thread on cross-tool simulation portability.
What OMG actually finalized in 2025
In July 2025, the Object Management Group approved final adoption of SysML v2.0, along with Kernel Modeling Language (KerML) 1.0 and the Systems Modeling API and Services specification 1.0. Seven years of committee work went into it, and the result is a real architectural break from SysML v1: models are grounded in KerML instead of layered on top of UML, there's a standardized textual notation alongside the graphical one, and the API finally gives tools a common way to read and write model data instead of fighting over XMI exports.
Those three pieces (KerML, the SysML language on top of it, and the API) cover syntax, abstract semantics, and data access. What they don't cover, at least not to the point of guaranteeing identical results, is execution semantics: the precise rules for how a model actually runs when you simulate it. Two tools can agree on what a state machine or action means structurally and still disagree on the order operations fire, how concurrency resolves, or how a continuous parameter interacts with a discrete event, because the spec doesn't pin those details down tightly enough to eliminate implementation choice.
Where the gap actually shows up
This isn't an abstract concern. It surfaces the moment you try to do anything beyond static model exchange:
- Behavioral models (actions, states, transitions) that import cleanly into a second tool but execute on a different schedule
- Parametric and constraint models whose solvers make different assumptions about evaluation order
- Co-simulation setups where the SysML v2 model needs to hand off to FMI or SSP-based simulators, and the handoff timing depends on execution semantics the standard leaves open
- Digital twin architectures that assume a model's behavior is portable across the design tool and the runtime environment, when in practice it's only the structure that's portable
Cris Kobryn, who led the UML v2 and SysML v1 language design efforts, has been blunt about this in a pair of essays published on sysml.org earlier this year. His framing is that SysML v2 delivers "marketecture" (better exchange mechanics, better tooling infrastructure, a cleaner kernel) without yet delivering "tarchitecture," the unified, deterministic execution semantics that mission-critical digital twins actually need. His conclusion, that SysML v2 is necessary but not sufficient for twin-native engineering, is a minority opinion in the sense that most vendors aren't saying it out loud, but the underlying technical gap he's describing is real and acknowledged in the spec's own scope.
The 2026 update didn't close it
If you were hoping the next revision would quietly fix this, the timeline says otherwise. KerML 1.1 and SysML 2.1 reached Beta 1 in 2026, and the changes were almost entirely to documentation comments and OCL constraints. The abstract syntax metamodel is structurally the same as KerML 1.0 and SysML 2.0. OMG editorially updated the formal specifications again in March 2026 to prepare them for ISO submission, which is a standards-process milestone, not a technical one. None of this is a criticism of the working group's pace; harmonizing execution semantics across a language meant to cover everything from mechanical assemblies to software-defined vehicles to nuclear plant controls is a genuinely hard problem, and rushing it would likely produce a worse spec. But it does mean the gap is a multi-year condition, not a one-release fix.
How the tooling landscape is actually responding
Nobody's waiting on the standard to catch up. At INCOSE IS 2026, vendor participation in SysML v2 demonstrations jumped roughly 50% year over year, and the responses cluster into a few patterns. Established commercial platforms like Dassault Systèmes' Cameo Systems Modeler and CATIA Magic added SysML v2 authoring in their 2026x releases while keeping execution tied to their own solvers. Open-source efforts like Eclipse SysON are building out SysML v2 editing with explicit bridges back to Capella-based architecture models, which sidesteps the execution question by keeping behavioral simulation in familiar territory rather than promising cross-tool portability it can't yet deliver. SysML v2-native platforms, including Dalus, build their modeling environment directly on the KerML foundation rather than bolting v2 support onto a v1-era core, which narrows the gap for models that stay inside one tool but doesn't eliminate it once you need to exchange executable behavior with someone else's environment.
The practical pattern across all of these: everyone standardizes on the parts OMG actually standardized (syntax, structure, API-based exchange) and treats simulation as tool-specific until proven otherwise.
What this means for your program right now
A few things follow directly from this, and none of them require waiting for SysML v3:
- Don't assume a behavioral model built in Tool A will simulate identically in Tool B just because both import the file without errors. Validate it.
- Treat the SysML v2 API as a structural exchange mechanism, not a behavioral one. It moves model data reliably; it doesn't guarantee execution equivalence.
- If your digital twin architecture depends on consistent simulation results across design-time and run-time tools, pin the execution engine, don't assume the standard enforces consistency for you.
- Budget verification effort for cross-tool behavioral comparison the same way you'd budget it for any other integration risk, because right now it is one.
What this won't solve
Standardizing execution semantics for a language this broad is not primarily a documentation problem, so don't expect a future point release to quietly close the gap the way the 2026 beta updated OCL constraints. A canonical execution model has to make real tradeoffs between determinism, expressiveness, and the wildly different domains SysML v2 is meant to serve, and every one of those tradeoffs will disappoint someone. It's also worth being honest that this problem predates SysML v2. SysML v1 and UML never had a single agreed execution semantics either; tool vendors filled the gap with proprietary simulation engines for two decades, and the industry mostly lived with it. SysML v2's KerML foundation makes the gap more visible and more fixable in principle, which is progress, but visibility isn't resolution.
Bottom line
SysML v2 gave systems engineers a genuinely better foundation for model structure, exchange, and tooling interoperability. It did not give them a guarantee that a model will behave the same way in every compliant tool, and the 2026 spec updates didn't change that. If your team is building simulation or digital twin workflows on top of SysML v2 this year, treat execution portability as an open risk to manage, not a solved problem the standard already handles for you.