SysML v2: What Changes and Why It Matters

Systems engineering is changing.

Modern systems are no longer simple collections of mechanical, electrical, and software components. They are increasingly software-defined, interconnected, autonomous, safety-critical, cyber-physical, and dependent on complex supply chains. Requirements, architecture, simulation, verification, safety, cybersecurity, manufacturing, and operations all need to stay connected.

This is where SysML v2 matters.

SysML v2 is not just a minor update to SysML v1. It is a major redesign of the Systems Modeling Language intended to make model-based systems engineering more precise, more interoperable, and more automation-ready.

For organizations moving toward digital engineering, SysML v2 may become one of the most important foundations for connecting requirements, architecture, analysis, verification, and downstream engineering workflows.

Before SysML: The UML Story

To understand SysML v2, it helps to begin with UML.

UML, the Unified Modeling Language, emerged in the 1990s as a way to unify several object-oriented software modeling methods. Before UML, software teams used competing notations and methods, including the Booch method, Object Modeling Technique, and Object-Oriented Software Engineering.

Three people became especially important in this history:

• Grady Booch
• James Rumbaugh
• Ivar Jacobson

They are often referred to as the “Three Amigos” of UML. Their work helped consolidate competing object-oriented modeling approaches into a common language for software design.

UML was adopted by the Object Management Group, commonly known as OMG, in the late 1990s. It became widely used for modeling software structure, behavior, interactions, and architecture.

However, UML was primarily created for software engineering. Systems engineering needed something broader.

A system may include software, hardware, people, procedures, sensors, actuators, physical constraints, interfaces, operational concepts, verification activities, and life-cycle considerations. UML could support some of this, but it was not designed specifically for the needs of systems engineers.

That gap led to SysML.

The Birth of SysML v1

SysML v1 was developed to extend and adapt UML for systems engineering. It was created through collaboration involving OMG, INCOSE, and the AP233 systems engineering data exchange community.

The goal was to provide systems engineers with a standard modeling language for specifying requirements, behavior, structure, parametrics, and verification.

SysML v1 was built as a UML profile. In simple terms, that means it reused parts of UML and added systems-engineering-specific extensions. This was practical because UML already had a modeling foundation, tool ecosystem, and standardization history.

Some of the key contributors associated with SysML v1 and its practical adoption include:

• Sanford “Sandy” Friedenthal
• Alan Moore
• Rick Steiner
• Conrad Bock
• Roger Burkhart
• Other members of the OMG and INCOSE SysML working groups

Sandy Friedenthal, Alan Moore, and Rick Steiner also helped make SysML accessible to practitioners through A Practical Guide to SysML, one of the most widely referenced books for engineers learning SysML.

SysML v1 introduced diagrams such as:

• block definition diagrams,
• internal block diagrams,
• requirement diagrams,
• activity diagrams,
• state machine diagrams,
• sequence diagrams,
• parametric diagrams,
• package diagrams,
• use case diagrams.

SysML v1 helped systems engineers move away from purely document-based engineering and toward model-based systems engineering, or MBSE.

But over time, limitations became clear.

Why SysML v1 Needed Improvement

SysML v1 was useful, but it had several challenges.

First, it was heavily diagram-centric. Many teams treated diagrams as the model itself. This could lead to fragmented views, inconsistencies, and difficulty maintaining the model as a coherent engineering asset.

Second, SysML v1 inherited complexity from UML. Because it was built as a UML profile, some parts of the language carried software-oriented assumptions that did not always fit systems engineering cleanly.

Third, tool interoperability remained difficult. Models created in one SysML tool were not always easy to exchange, query, or reuse in another tool.

Fourth, automation was limited. Many SysML v1 workflows still depended heavily on manual diagram creation, manual review, and manual document generation.

Fifth, the language did not always provide the level of semantic precision needed for advanced digital engineering. A diagram could communicate intent to a human, but it was often harder for software tools to interpret the model rigorously.

These issues became more important as engineering organizations began moving toward the digital thread, digital twins, simulation-driven design, AI-assisted engineering, and integrated verification.

A new version of SysML was needed.

The Development of SysML v2

SysML v2 was developed as a major rethinking of the language.

The SysML v2 Submission Team was formed in 2017. Key leadership included Sandy Friedenthal and Ed Seidewitz. The effort involved a broad group of participants from industry, government, academia, and tool vendors.

Other important contributors and working group leaders included people such as Conrad Bock and Karen Ryan, who contributed to the semantic foundations, along with many members of the OMG Systems Modeling Community.

SysML v2 was not designed simply to patch SysML v1. It was designed to support modern systems engineering needs more directly.

The result is a language built around:

• formal semantics,
• textual and graphical notation,
• model interoperability,
• APIs and services,
• better precision,
• improved automation,
• stronger support for digital engineering.

OMG formally approved SysML v2.0, KerML 1.0, and the Systems Modeling API and Services specifications in 2025.

What Changes in SysML v2?

1. SysML v2 Has a Stronger Semantic Foundation

One of the biggest changes is that SysML v2 is based on KerML, the Kernel Modeling Language.

KerML provides the underlying semantic foundation for SysML v2. This matters because models need clear meaning.

In SysML v1, two engineers could create similar diagrams but interpret them differently. Tool vendors could also implement parts of the language in different ways. This created ambiguity and made model exchange difficult.

SysML v2 aims to reduce ambiguity by giving model elements a more precise meaning.

Instead of treating diagrams as the main source of truth, SysML v2 treats the underlying model as the source of truth. Diagrams and views become ways of presenting that model.

This is an important shift.

In mature MBSE, the model should not just be a collection of drawings. It should be a structured, queryable, analyzable engineering asset.

2. Textual Modeling Becomes a First-Class Capability

SysML v2 supports both graphical and textual notation.

This is one of the most important improvements.

Many engineers are used to thinking about SysML as diagrams. Diagrams are valuable because they communicate visually. But diagrams alone are not always ideal for automation, version control, model differencing, model generation, or integration with modern software workflows.

Textual notation makes SysML v2 more compatible with:

• version control,
• peer review,
• automated consistency checks,
• AI-assisted model generation,
• scripting,
• continuous integration,
• reusable templates,
• automated validation.

This does not mean diagrams go away. It means engineers can use diagrams for communication and textual models for precision, automation, and configuration control.

For software-intensive and multidisciplinary systems, this is a major improvement.

3. The Model Is No Longer Just the Diagram

In SysML v1, teams often treated diagrams as the primary artifact. The problem is that a diagram is only one view of the system. It may be incomplete, outdated, or inconsistent with other views.

SysML v2 changes the emphasis.

The model is the underlying data. Views are representations of that data.

This is similar to software engineering. Source code is the authoritative artifact. Diagrams, dependency graphs, and documentation are useful views, but they are not usually the source of truth.

For systems engineering, this distinction is powerful.

If a requirement changes, the model should help engineers understand which architecture elements, interfaces, analyses, and verification activities may be affected.

That is the promise of digital traceability.

4. Better Support for Tool Interoperability

One of the most important additions in SysML v2 is the Systems Modeling API and Services specification.

This matters because engineering organizations rarely use one tool.

A real engineering program may involve:

• requirements tools,
• architecture tools,
• simulation tools,
• CAD tools,
• PLM systems,
• ALM platforms,
• test management tools,
• safety tools,
• cybersecurity tools,
• custom scripts.

If SysML models are trapped inside one vendor’s tool, the value of MBSE is limited.

SysML v2’s API and services specification is intended to improve how tools access, exchange, query, and manage model information.

This is essential for digital engineering.

The future is not one perfect tool. The future is an ecosystem of connected tools where the system model acts as a shared source of engineering truth.

5. Improved Precision for Requirements, Interfaces, Behavior, and Verification

SysML v2 improves how engineers can represent core systems engineering concepts, including:

• requirements,
• parts,
• ports,
• interfaces,
• actions,
• states,
• constraints,
• allocations,
• verification relationships.

This matters because many engineering failures happen at the boundaries:

• unclear requirements,
• misunderstood interfaces,
• incomplete verification logic,
• inconsistent assumptions,
• architecture decisions not linked to stakeholder needs.

SysML v2 does not magically solve these problems. But it gives engineers a better language for representing them clearly.

For example, interface modeling becomes more powerful when the model can define what flows across an interface, what constraints apply, what behavior is expected, and which system element owns or uses that interface.

In aerospace, defense, automotive, medical, energy, robotics, and other complex domains, that precision matters.

6. SysML v2 Is More Automation-Friendly

SysML v2 is better suited for automation than SysML v1.

With formal semantics, textual notation, and standard APIs, SysML v2 can support workflows such as:

• automatic consistency checking,
• model queries,
• requirement impact analysis,
• AI-assisted model creation,
• automated document generation,
• simulation integration,
• test case traceability,
• interface control validation,
• architecture trade studies.

This is where SysML v2 connects directly to the future of AI in engineering.

AI tools are more useful when they can operate on structured engineering data instead of disconnected documents. A SysML v2 model can provide that structure. It gives AI something more reliable to reason over: defined elements, relationships, constraints, and traceability.

For companies like Ngenaire, this is especially important.

AI in engineering should not simply generate text. It should help engineers create better requirements, analyze architectures, identify inconsistencies, and reduce busy work while keeping engineers in control.

SysML v2 is one of the foundations that can make that possible.

Why SysML v2 Matters for Systems Engineers

SysML v2 matters because it moves MBSE closer to what systems engineering actually needs: a connected, rigorous, life-cycle-aware representation of the system.

The value is not just better diagrams.

The value is better engineering decision-making.

A good SysML v2 model can help answer questions such as:

• Which requirements are affected by this design change?
• Which interfaces depend on this subsystem?
• Which verification activities prove this requirement?
• Which behaviors are allocated to which components?
• Which constraints drive this architecture?
• Which assumptions are shared across analysis models?
• Which parts of the system are impacted if a stakeholder need changes?

These are the questions that matter on real engineering programs.

When the model can help answer them, MBSE becomes more than documentation. It becomes a decision-support environment.

What This Means for Organizations

For organizations currently using SysML v1, the transition to SysML v2 should not be treated as a simple tool upgrade.

It is a methodology, training, data, and process change.

Teams should think carefully about:

• which modeling problems they are trying to solve,
• which projects are good candidates for pilot adoption,
• how SysML v2 will connect to requirements, verification, simulation, and configuration management,
• how model governance will work,
• how engineers will be trained,
• how legacy SysML v1 models will be handled,
• how much automation they actually need.

The worst way to adopt SysML v2 is to recreate old document-based habits in a new modeling language.

The best way is to start with engineering value. Pick a specific use case such as interface control, requirement traceability, verification planning, architecture trade studies, or system-of-systems integration. Then use SysML v2 to make that workflow more consistent, more traceable, and more automated.

SysML v2 and the Future of Engineering Work

SysML v2 arrives at an important time.

Engineering teams are under pressure to develop more complex products faster, with fewer errors, stronger traceability, and better integration across disciplines. At the same time, AI is changing how engineers write, review, analyze, and automate technical work.

But AI alone is not enough.

AI needs structured, trustworthy engineering context. SysML v2 can help provide that context.

The combination of SysML v2, MBSE, digital thread, simulation, and AI has the potential to reshape how engineering teams work. Requirements can become more connected. Architectures can become more analyzable. Verification can become more traceable. Engineering knowledge can become less dependent on scattered documents and tribal memory.

This is not about replacing engineers.

It is about giving engineers better tools.

Final Thoughts

SysML v2 matters because it represents a shift from diagram-centric modeling to model-centric engineering.

UML helped standardize software modeling. SysML v1 adapted that foundation for systems engineering. SysML v2 now moves systems modeling toward a more formal, interoperable, and automation-ready future.

For engineers, the message is simple: SysML v2 is worth learning not because it is new, but because it aligns with where engineering is going.

The future of systems engineering will depend on connected models, digital traceability, automation, and AI-assisted workflows. SysML v2 provides one of the key languages for building that future.

For organizations that want to move beyond document-based engineering, SysML v2 is not just another standard.

It is a step toward engineering systems with more clarity, consistency, and intelligence.

References and Further Reading

1. Object Management Group. Systems Modeling Language Version 2.0 Specification. Object Management Group, 2025.
2. Object Management Group. Kernel Modeling Language Version 1.0 Specification. Object Management Group, 2025.
3. Object Management Group. Systems Modeling API and Services Specification. Object Management Group, 2025.
4. Object Management Group. SysML v2 Specification Overview. OMG SysML, 2025.
5. Friedenthal, Sanford, Alan Moore, and Rick Steiner. A Practical Guide to SysML: The Systems Modeling Language. 3rd ed., Morgan Kaufmann, 2015.
6. Friedenthal, Sanford, and Ed Seidewitz. SysML v2: Where We Are and How We Got Here. Object Management Group, 2023.
7. Friedenthal, Sanford. A Look Ahead at SysML v2. INCOSE Wasatch Chapter Presentation, 2020.
8. Kobryn, Cris. “UML 2001: A Standardization Odyssey.” Communications of the ACM, vol. 42, no. 10, 1999, pp. 29–37.
9. Kobryn, Cris. “Will UML 2.0 Be Agile or Awkward?” Communications of the ACM, vol. 45, no. 1, 2002, pp. 107–110.
10. Bock, Conrad. “SysML and UML 2 Support for Activity Modeling.” Systems Engineering, vol. 9, no. 2, 2006, pp. 160–186.
11. Weilkiens, Tim. Systems Engineering with SysML/UML: Modeling, Analysis, Design. Morgan Kaufmann, 2007.
12. INCOSE. Systems Engineering Vision 2035. International Council on Systems Engineering, 2021.
13. Estefan, Jeff A. Survey of Model-Based Systems Engineering Methodologies. INCOSE MBSE Initiative, 2008.
14. Li, Zirui, Stephan Husung, and Haoze Wang. “LLM-Assisted Semantic Alignment and Integration in Collaborative Model-Based Systems Engineering Using SysML v2.” arXiv, 2025.
15. Harrison, Matthew, John Carlin, Chengyuan Liu, Sarah Dunnett, and Siyuan Ji. “Towards Formalising Stakeholder Context Using SysML v2.” arXiv, 2026.