Model-Based Systems Engineering (MBSE) promises better decisions, stronger traceability, and clearer alignment across teams. But in many organizations, the day-to-day reality still feels fragmented. Requirements may live in one tool. Architecture lives in another. Analysis happens somewhere else. Verification evidence is scattered across reports, scripts, and specialized tools. Teams may have models, but they still struggle to keep engineering data connected, current, and authoritative.

The gap matters because digital engineering does not succeed just because a team creates more digital artifacts. It succeeds when engineering information stays connected in ways that help people make decisions, understand change, and maintain confidence in what is true. The hard part is rarely just creating models. The hard part is making them work together across disciplines and across tools.

The Evolution of Systems Engineering

Systems engineering has already evolved well beyond a document-only world. Many teams now use descriptive models to define architecture and behavior, and increasingly they want those models to become more executable, more analyzable, and more useful in driving design decisions.

MathWorks has been investing in MBSE workflows to support that shift. At the center of this is System Composer, a tool that enables system decomposition, customizable element properties, interface definition, and behavioral diagrams. Query-based views help engineers extract specific information they need from complex architectures, such as filtering components by owner, safety level, or dependency.

Figure 1 – Model-Based Systems Engineering at MathWorks

The Modern Challenge: Seamless Interoperability

Modern systems engineering demands high-fidelity, multidisciplinary models, a single source of truth, and robust conflict management. The biggest challenge? Achieving seamless interoperability across disciplines and maintaining authoritative, connected data sources. With data flowing between stakeholders – system architects, controls engineers, structural engineers, design engineers, and safety engineers, the complexity of collaboration grows exponentially. According to a recent MathWorks survey, 94% of engineers in Aerospace and Defense identified interoperability of tools and data as one of their biggest workflow challenge.

Traditional solutions often fall short. No single tool can meet every need, and custom-made connectors are costly to build and maintain. They can move data, but they do not necessarily establish a true source of truth. In many cases, they create more copies, more translation issues, and more opportunities for things to drift out of sync.

Figure 2 – Pitfalls of traditional solution to guarantee digital continuity across disciplines

What the SysML v2 API Changes

This is where SysML v2 becomes interesting. Not simply because it is a new version of the language, but because its RESTful API introduces a more service-oriented and repository-centered approach to exchanging engineering information.

This new standard enables a federated ecosystem where tools can exchange data through a central repository, establishing an authoritative source of truth. MathWorks and other vendors can publish and retrieve information seamlessly, supporting true interoperability. The API’s simplicity belies its transformative potential: connecting tools in an engineering workflow through a common mechanism rather than a fragile web of direct integrations.

That does not guarantee a digital thread on its own. But it does create a more credible path toward one by making architecture, analysis, requirements, and verification information easier to connect, query, and evolve together over time.

Figure 3 – Service-based API enabling a federation of ecosystems with information exchange & authoritative source of truth

Also Tim Weilkiens, CEO of oose and one of the lead developer of SysML v2, emphasizes that this API is conceptually revolutionary, enabling tool interoperability and a single source of truth for all users:

Real-World Example: Building a Drone with SysML v2

Consider the development of a quadcopter. Stakeholder specifications are published into the repository using SysML v2, enabling system architects to perform mission analysis and simulate scenarios. Trade-off analyses, such as battery sizing, are run, and results are pushed back into the repository, creating the first links in the digital thread.

Figure 4 – Example of data flow between stakeholder specifications & mission analysis

From there, the workflow can expand across disciplines. Software requirements are formalized mathematically, allowing automated consistency and completeness checks as well as automated verification test case generation.

Geometry metadata can be captured and shared for structural analysis in specialized tools. Controls, structural, design, and safety stakeholders can all read from and write to the repository so that all data remains connected and authoritative, rather than stranded inside isolated workflows.

The Digital Thread: Query, Analyze, and Evolve

The most interesting part of this example is not simply that data moves around. It is that the SysML repository forms a graph of interconnected information. Requirements, architecture elements, analysis results, interfaces, metadata, and verification assets can be queried by team members. Engineers can extract components, requirements, and metadata. That makes it easier to trace dependencies, understand impact, and explore “what-if” analyses, highlighting how changes ripple through the system.

Figure 5 – Example of using graph from SysML v2 repo to perform what-if-type analysis

Key Takeaways

• Models are essential, but MBSE still breaks down when engineering data remains disconnected across disciplines.
• No single tool needs to do everything.  The better goal is to use the right tool for the job in a connected workflow without relying on brittle, one-off integrations.
• SysML v2 is most compelling when it helps teams maintain an authoritative source of truth, query connected engineering data, and trace the impact of change more effectively.

Closing Thought

If you’re considering SysML v2 for your organization, the key question is not simply whether the language is newer or more expressive. The more important question is whether the surrounding ecosystem can help your teams keep requirements, architecture, analysis, and verification connected in a more authoritative way. That is where the real value starts to show up.

For more on real-world use cases, check out the blog from the 2024 SysML v2 Extravaganza workshop, which details how the repository and API facilitate seamless information exchange.

If your organization is evaluating SysML v2, MathWorks can help you turn that evaluation into a practical engineering path forward.

Marco Bimbi is a Principal Application Engineer at MathWorks specializing in MBSE for safety‑critical systems, bringing deep aerospace experience and industry leadership to help advance systems engineering workflows and tools.