For the past 20 years, our models have been boxes and lines, where the most powerful symbolism was the arrow. Possible flows, data flows, control flows. We connect one box to another to say, explicitly, “this thing outputs that thing.” Then we draw another line that says, “that thing is input to this other thing.” Did we create feedback by accident, or was it on purpose? We don’t remember anymore – we’re trying to focus on the fact we can draw arrows.
Why the old approach stopped working
Model-Based Systems Engineering was expected to substitute document-centric workflows. In reality, it frequently only substituted one kind of document for another. Teams would create elaborate architecture models in graphical tools, then manually dump data out into spreadsheets, reports, and slide decks for everybody else. The model is the truth, but it’s a truth nobody can get at without the right software license and a week of training.
The real problem was tool lock-in. Different teams – mechanical, software, safety – used different platforms, and you’d develop a custom translator to break every time e.g. the software tool updated. The decisions you made in mechanical CAD would not automatically propagate to software architecture. The time you spent in the work of maintaining a translation layer was not being spent thinking about designs.
From drawing diagrams to authoring system data
The key change isn’t visual and it’s not even about the future. It is about enabling engineers to write models using a formal textual notation, i.e. something that looks and behaves like code, in addition to traditional graphical diagrams. Text-based model files live in a Git repository, can be reviewed in a pull request, diffed line by line, and tested automatically by a CI/CD pipeline. Branching and merging system architectures will be possible the same way branching and merging software code is possible. A mechanical engineer and a software engineer can work on the same model in parallel and resolve conflicts using tools they already know.
This is the cultural shift the industry has been circling for years: system engineering starts behaving like software engineering, with the collaboration practices and tooling to match.
Solving interoperability at the language level
The standardized API that sysml v2 brings is actually the piece that most directly changes the tool ecosystem. Rather than every vendor building a different custom import/export bridge, they exchange model data via a standard, shared interface. A change you make in one vendor’s tool automatically is reflected in every other tool that you use which can read that data. And read from and write to the same model is a key point – your PLM system, simulation environment, safety analysis tool, and requirements management environment can all interact with your model in real-time. The model isn’t just a static exchange format – it’s a live view.
This matters not only for development, to get walled-off tools to work together better, but it also enables end-to-end vendor and supplier integration. Your OEM can share the same model with its supply chain, without requiring all the suppliers to buy a specific toolsuite. The contracts and the model define precisely how the data is to be structured, so any vendor can bid to supply a tool that reads and writes the data without having to pay to be included in the entire toolchain. The resulting market force makes it much easier for new, niche, interop-focused tools to enter the marketplace, which is great for the user.
A more rigorous foundation with KerML
Beneath the surface, next-gen modeling languages have been built on KerML – a more rigorous, mathematically grounded kernel that formally defines the semantics of everything else. “Legacy” modeling standards tend to have accrued ambiguities after years of committee revisions and compatibility decisions. Even if a single implementation of UML or SysML was perfectly sound, different tools would often add their own minor interpretations, which over time many users came to accept as standard practice. Yet additive interpretation errors can sum, and those ‘minor’ inconsistencies add up.
Connecting models directly to simulation and analysis
The advantage is that stakeholders themselves can define what precise information they need and connect to the metamodel accordingly. For others, having a more precise metamodel is attractive because they are hitting the limits of what they can do with back-of-the-envelope calculations and need a way to let a computer scale up the system for them.
One consequence of a more precise metamodel is that the gap between the system model and the analysis model tends to be orders of magnitude smaller. In the past, the safety engineer and the performance analyst would get a system architecture and then build a separate model in their own tool because it just wasn’t precise or structured enough to feed into, say, a simulation tool.
With next-generation standards, that rebuild step can often be eliminated. You embed in the model itself, in the correct metamodel concepts, the simulation parameters, and safety constraints, and the performance requirements analyses in the way that directly responsible engineers decide, “Yeah, I can live with those assumptions”.
What this means in practice
The first teams to experience the difference are those who are already investing significant time and effort into connecting, translating and updating their engineering models. These are the system owners, the analysts, and the architects whose insights are trapped in the detail of a tool that no one looks at regularly, or the next spreadsheet they need to send out. Who have to check and double-check that they’ve correctly implemented the model-to-model transformations because there are three different copies in as many places. Or who invest countless hours updating a 1000 line MATLAB script to interface with the latest version of the scheduler’s source code rehashing code from 1998.
Next-gen modelers simply don’t have to worry about that.
