SysML v2: Is Modeling Becoming Part of the Engineering Infrastructure?

Boeing has invested in Model-Based Systems Engineering (MBSE) for decades. SpaceX has never done so on a comparable scale, yet it develops its products faster. When discussing rapid hardware development, the same (sometimes overused) terms keep coming up: digital thread, impact analysis, end-to-end traceability. A system model is actually supposed to enable exactly this on a scalable basis. So do we absolutely need modeling, or is it optional?

The contradiction disappears when you ask not whether modeling is taking place, but for what purpose. A model that is maintained and read only by a team of experts is trapped in a silo and has little value. A model that others build upon every day without giving it a second thought is infrastructure.

Among other things, SysML v2 promises to simplify this. On the other hand, other modeling languages also make this claim. Whether SysML v2 will bring about any changes in this regard is a question I will explore with Tim Weilkiens in the webinar on November 2, 2026 (Registration).

System stewardship needs a foundation

Product Velocity describes product development as a velocity loop consisting of four practices. Business defines direction and priorities. Engineering designs and verifies. Delivery builds, operates, and monitors. At the center is System Stewardship. This practice maintains the system architecture, acts as an intermediary between the three outer practices, and preserves knowledge across iterations.

It is important to draw a clear distinction here. System stewardship is a decision-making and structural function, not a documentation or governance function. It makes binding decisions regarding structure, interfaces, and trade-offs. The Product Velocity Model summarizes its tasks into three activities:

1. Structure. Business input is translated into structured information that engineering can work with. The system is broken down so that the subsystems are as decoupled as possible.
2. Commit. Stewardship is responsible for ensuring compliance at the system level: global configuration, system-wide trade-offs, and the differing rates of change in hardware and software.
3. Evolve. Insights gained from operations are fed back into the architecture and, from there, back to the business as business-relevant insights.

All three activities require a representation of the architecture that is precise enough for analysis and clear enough for all stakeholders. A system model is the obvious choice. The question, then, is: To what extent can system stewardship use modeling in general—and SysML v2 in particular—as a foundation?

The Silo Dilemma

Modeling faces an acceptance problem, and it is structural. Models are usually created by an MBSE team that is fluent in the language, has configured the tool, and is familiar with the conventions. Without proactive resource allocation, hardly anyone reads the model.

The tool intended to break down silos ends up creating a new one.

A look at the three external practices illustrates this:. Business describes value, markets, and strategy. A SysML diagram does not answer any of these questions in a language spoken there. Delivery thinks in terms of bills of materials, manufacturing steps, and field data. Here, too, the system model rarely plays a role. The Book on Product Velocity calls that Anti-pattern Linguistic Fragmentation: Different disciplines develop incompatible vocabularies for the same system, and without a common representation, the digital thread breaks.

Most widely accepted Engineering the model. But even there, acceptance stops at the boundary of the design. Mechanics are handled in CAD, electronics in ECAD, and software in code. These design models remain independent, and that’s as it should be. However, the connection to the system model is often missing. In practice, SysML models provide a structured path from requirements to use cases, activities, and system elements. Traceability upward—to stakeholder needs and the business case—is often missing. Downward traceability—for example, from the modeled port to the mechanical mounting point in CAD—rarely emerges on its own.

The situation is similar with verification and validation. Test teams work with their own tools, test benches, and simulation environments. As long as the system model isn’t linked to these artifacts, it remains merely a description separate from the actual work. This also explains why MBSE is successful in certain niche areas but has not yet become mainstream.

What a System Model for Stewardship Can Achieve

Despite these hurdles, the potential is great. A system model differs from a drawing in that elements and relationships are explicitly defined and typed. When a function is assigned to a component or a port is defined as part of a subsystem, traceability is embedded in the model’s semantics. No one has to maintain the link manually. Inconsistencies become apparent, much like a compiler detects errors in source code.

This is a useful feature for system stewardship. Impact analysis becomes a query rather than a research task. Interfaces become explicit contracts. Parameters such as mass or flow rate can propagate through requirements, simulation, and CAD, automatically triggering checks. Added to this is a mechanism from the velocity loop that is often overlooked. Stewardship defines an interface once; after that, the fast loops work directly against it without having to renegotiate the architecture each time. A model makes such commitments visible and verifiable, and it shows when they no longer apply.

However, the path to that goal is paved with well-known pitfalls. The book contains over 100 anti-patterns, nine of which pertain to system models. Five of these are particularly relevant to the issue of infrastructure:

• Ivory Tower Modeling. The model is developed independently of real-world engineering constraints and does not affect implementation. It is clean, complete, and has no real-world consequences.
• Spaghetti Modeling. The model grows without architectural discipline. Circular dependencies and uncontrolled cross-references turn the digital thread into a tangled mess.
• Over-Formalization. Formalities come too early or are too extensive. The effort is required long before any benefits become apparent, and the teams perceive modeling as bureaucracy.
• Modeling as an End. What is measured is the number of elements or diagrams, not the quality of the decisions. The model becomes an end in itself.
• The "Single Source of Truth" Myth. Everything is supposed to be consolidated into a single tool. This approach fails because no repository can replace specialized design environments or operational data.

If you avoid these patterns, you’ll arrive at a simple principle: Precision is worthwhile wherever ambiguity would otherwise lead to rework, coordination efforts, or certification risks. In all other cases, a simpler presentation is sufficient.

Wagner and ZF: It's already working

Two examples from German industry demonstrate that models can become infrastructure.

Wagner develops safety-critical fire protection systems. Every system change requires certification. Wagner did not introduce MBSE with a large-scale tool rollout. It began with a long-term architectural strategy backed by a clear business case and measurable KPIs, such as reducing certification time. From this, the company derived small initiatives, each of which delivered results within a matter of months. Clearer interface specifications reduced integration problems. Model-based testing simplified regression testing. Safety-critical behavior shifted from manual programming to certified code generation. Individual initiatives yielded efficiency gains of 10 to 30 percent. After about six years, Wagner reports that the company is now up to three times more efficient than before. The details can be found in the Case Study on Modeling Strategy and in the Interview with Andreas Willert, who oversaw the project.

ZF Friedrichshafen faced another bottleneck. Validating power electronics under extreme thermal loads took up to twelve months. ZF built an MBSE tool environment that automatically generates digital twins of thermal behavior. Product requirements are linked to the requirements for the simulation models. This allows a simulation model to be approved before a physical prototype even exists. AI methods identify the critical areas to ensure the simulation remains fast enough. The validation time was reduced to two months. Here, too, several years of work went into it, with interim successes along the way. The ZF Case Study describes the process.

Both examples have something in common. Neither began with the selection of a modeling language. Both began with a specific bottleneck: certification at Wagner, validation at ZF. And in both cases, the model was directly linked to verification and validation. It is precisely this connection that is missing in many MBSE initiatives. It is also noteworthy what is missing: Neither of these two successes is tied to SysML v2.

What SysML v2 Changes

SysML v1 was an UML profile, with all the legacy issues that entailed. The OMG finalized SysML v2 in 2025. The new version is a complete redesign based on the Kernel Modeling Language (KerML). Three characteristics are relevant to the infrastructure issue.

1. Textual notation. In addition to its graphical representation, SysML v2 features a standardized text notation. It is a full-fledged representation of the same model semantics, not an export function. Models can be read, written, compared, and reviewed using this notation, just like source code.
2. Standardized API. SysML v2 defines an API for accessing models, including a commit concept. Uwe Kaufmann described in the Interview on se-trends Model replacement is one of the biggest problems with v1. The API is the solution.
3. Legal Basis. KerML defines semantics more precisely than the UML foundation of v1. This makes models machine-processable and enhances the reliability of automatic inferences.

When it comes to infrastructure, the API is the most important of the three characteristics. Infrastructure means that others build on it. A CAD tool, a test automation system, or a business dashboard can access the model via a standardized interface without needing to understand SysML. This addresses the silo dilemma at its root.

Tim Weilkiens summarizes the language in his SysML v2 Book in detail. For strategic context, it is important to note that SysML v2 makes the metamodel explicit and reduces ambiguity. However, the new version does not change the role of modeling as a means rather than an end.

Model as Code: The Appeal and the Reservations

Text notation has sparked a movement characterized by concepts such as Model as Code or System-as-Code is in use. The idea originates from software development, where Infrastructure as Code has transformed operations. Models are stored as text files in Git. Changes are managed via branches and pull requests. A CI pipeline checks for consistency with every commit. This is appealing for teams that already work with Git. The model ends up where the code is, and systems engineering gets the same tools as software development.

The concerns begin with the standard itself. A team from the DLR has examined SysML v2 for the configuration of safety-critical avionics (Ahlbrecht et al., DASC 2024). The authors consider the management of text notation in Git to be an interesting approach, particularly with regard to tool qualification under DO-330. However, they note that the text notation represents only a subset of the server data:

„Unfortunately, the current version of the textual notation includes only a subset of the server data […] and omits essential information such as the unique identifiers. Furthermore, the standardized exchange is defined via the API, not the textual notation.“

Ahlbrecht et al., DASC 2024

So anyone who consistently relies on text in Git is missing out on standardized exchange. On top of that, there are practical problems. A system model is a graph with many cross-references. A line-based merge sees two harmless changes where, semantically, a conflict arises. Diagram layouts are not contained in the text (though many tools now work with text). And code is even less accessible to business and delivery teams than a diagram. “Model as Code” thus shifts the silo toward software development rather than breaking it down.

Another effect is a double-edged sword. Language models can read and write text. A text-based notation thus makes SysML models accessible to AI. This speeds up model creation. However, it also accelerates “spaghetti modeling” when methods and conventions are lacking.

The success of Infrastructure as Code was based on an ecosystem of compilers, tests, and deployment pipelines. It was this ecosystem that made configuration files verifiable. For system models, this ecosystem is still in its infancy. Text-based notation is a prerequisite for System-as-Code, but it is not a sufficient condition. The same could also be achieved with AADL, Event-B, or YAML used in a disciplined manner, provided that the semantics are defined and enforced.

Are there any case studies?

The sad truth is that there is hardly any publicly documented information. Anyone looking for reports on industrial SysML v2 implementations with measurable results will mainly find pilot projects, guidelines, and example projects—though some of these are quite large and realistic, such as the Apollo 11 Model.

The DLR paper mentioned above is another, more concrete example. The authors transferred an avionics configuration model to a server via the API and used a CI/CD pipeline to generate an executable configuration for an ARINC-653 hypervisor from it. Their conclusion: SysML v2 shows potential but requires domain-specific adaptations. Tool qualification and distributed development across company boundaries remain open questions.

ESA adapted its MBSE methodology to SysML v2 as part of a pilot project and tested it on a sample mission (Duroy et al., Systems Engineering 2026). In February 2026, the U.S. Department of Defense issued a Guide to the Transition from v1 to v2 published. It recommends three steps: a strategic plan, familiarization with text notation and the API, and a pilot project. There is no mention of a rollout.

The S2X also demonstrates just how far the community has come, as SysML v2 Extravaganza the GfSE on November 3, 2026, in Hamburg. The call for presentations specifically sought pilot projects, migrations, and the problems solved or discovered in the process. The event is entirely dedicated to the „how.“ The „whether“ is considered answered; the „how“ is not yet.

Tools that hide SysML v2

Of particular interest is a group of newer tools that take a different approach. Dalus positions itself as an AI-powered systems engineering platform for hardware teams. According to its website, Dalus is based on the SysML v2 specification. However, the interface does not refer to part definitions or ports, but rather to subsystems, interfaces, and requirements. An AI copilot generates model structures from requirements documents and natural-language instructions. The OMG Tool List Dalus offers these in addition to traditional modeling tools. Planetary Utilities (Starforge) is another example, in which the company, with Kotar resumes modeling in SysML v2.

That is infrastructure in the literal sense. No one who visits a website writes TCP packets. SysML v2, as an invisible layer beneath domain-specific interfaces, would circumvent the acceptance problem rather than solve it. Business sees business views, engineering sees engineering views, and underneath lies a common, formal model.

One reservation remains. A hidden model is only considered infrastructure if other tools can access it via the standardized API. Otherwise, it is just another proprietary tool using a standard as a selling point. Whether the new platforms are open enough will only become clear once they are integrated with CAD, test environments, and ALM.

Conclusion

It is impossible to say definitively today whether modeling will become part of the engineering infrastructure. The potential is there. A system model can provide system stewardship with exactly the precision required by Structure, Commit, and Evolve. Wagner and ZF demonstrate that this works in practice—even without SysML v2.

SysML v2 lowers the technical barriers. The API makes the model accessible to other tools, the text notation paves the way for the X-as-Code movement, and the formal foundation makes analyses more robust. The organizational barriers remain. A model that neither business nor delivery teams use remains a silo, no matter what language it is written in.

In practice, this leads to a straightforward test. You can recognize infrastructure by the fact that it’s used without anyone talking about it. Can a specific impact question be answered in minutes using the model? Do design and V&V access the model, or do they maintain copies? Does the model emerge as a byproduct of the work or as an extra task alongside the actual work? Anyone who answers these questions honestly will know where they stand. The next step follows the pattern set by Wagner and ZF: select a specific bottleneck, link the model to it, and measure the benefits.

Tim Weilkiens and I will explore this topic in more depth during the webinar „SysML v2 and Product Velocity: Is Modeling Becoming an Engineering Infrastructure?“ on November 4, 2026, at 10:30 a.m. If you have any firsthand experience with SysML v2—whether positive or negative—those are exactly the kinds of reports we’ve been missing so far.