If you have some experience with model-based systems engineering, you’ve probably faced a situation where two engineers examine the same diagram and have different perceptions of the system’s intended functionality. This is not a failure in communication. It’s a failure in language, and it’s inherent in the tools we’ve been utilizing for many years.
Why SysML v1 was always a workaround
SysML v1 didn’t start from a blank page. It was developed as a profile of UML, a language for modeling software systems. From day one, that established a critical mismatch between the needs of mechanical and electrical engineers and the nature of the language they were using. UML is not a language for modeling system components of every kind. It’s a language for modeling software objects. That’s a fundamentally different starting point.
Here’s another clue: the languages we develop signal the organization we think is there. In the case of SysML v1, the language signaled a software architecture. The “junk drawer” concept of the SysML v1 block (a block can represent anything) was also a giveaway. In practice, the software perspective showed in the way blocks and relationships could be used. You could make a connection between anything and anything else because in software, you pretty much can. The language encourages a flat structure where everything’s linked to everything else. If there’s a system-engineering concept that’s anathema, that’s probably it.
More than taking on a few bad habits from software, what you end up with is a language fundamentally organized around them. That’s not a good look if you don’t make software. When mechanical, electrical, and software engineers sit down to work from the same block-diagram view of a system (the most basic model you’ve got), they are already interpreting that picture through the lens of their discipline. The language doesn’t prevent them from doing so. It’s not formalized in a way that says a relationship of this kind means that and nothing else, and that just repeats all the mistakes we made in the paper world.
What a formal metamodel actually changes
The metamodel is what lies underneath the language. It consists of the rules that determine the existence of the elements, the allowed relationships, and their semantics. In the case of SysML v1, the metamodel rules were abstract, so tool vendors applied their own interpretation often leading to models that couldn’t be guaranteed to be understood in the same way if you opened them in a different tool.
Modeling languages today already solved this problem. The Object Management Group built sysml 2.0 from the ground up with a clean separation between a formal foundation with precisely defined semantics and a modeling surface that humans can read and write. The foundation is called KerML – the Kernel Modeling Language. Every relationship and element means something, and that meaning is not approximated, not customary, but defined in the precise mathematical terms that underpin KerML.
This may sound like an academic distinction, but it’s not. If the meaning of a relationship is in the KerML described by SysML 2.0, then your tool cannot reinterpret it silently. Two tools based on the same metamodel cannot represent the same concept differently. They can show it differently but if you cascade the relationships, do the inter-element logic, the gory details of the semantics – they must, and will always be the same. If the meaning of the relationship is not specified, this is up to the tool designer, drift returns.
Textual notation and version control
A practical change that has been part of modern modeling is also supporting textual notation in addition to graphical views. While SysML v1 allowed you to draw diagrams, it couldn’t be used like code – you couldn’t diff it, branch it, or review changes in a pull request.
Textual notation means that a systems engineer or developer can write model elements in a structured, human-readable form. This form is meant to be used with standard version control systems. For example, if you’re using Github and want to track a change to an interface definition, you can write out that change, and that becomes a commit. Want to review that change? That’s a pull request. This has been common practice in managing software changes for a long time, but hasn’t been possible with graphical languages before.
For more complex, multi-disciplinary projects, being able to use this kind of structure to your model matters. It becomes something you can govern, not just something you can draw.
The standardized API and the end of tool silos
Even if you have a formally defined language, you still don’t get a viable language for integration if every tool has its own potentially inconsistent copy of the system definition, which is pretty much the case in every traditional toolchain. If the source of truth for your system model remains in your requirements management tool while the architecture model remains the starting point for a simulation, you need translation, and translations can never be free of semantic bias when there is no agreed-upon meaning.
So modern modeling standards define a standardized REST/gRPC-based API and a query language that allows different engineering tools to read from and write to the same system model without going through translators. When a simulation tool pulls a parameter from the model, the requirements tool also recognizes the parameter, and the CAD environment represents the same value as in the model. The meaning travels with the data.
Automated verification becomes possible
All the potential downstream benefits result in a truly revolutionary change in the effectiveness of system engineering at scale. With rules that are mathematically precise (and thus clearly computable) computers can check the model. Automated verification, consistency checking, and simulation-driven validation are just a few of the kinds of engineering tasks that critically depend on the system having a computable representation – not a diagram that a human reads, interprets, and tries to reproduce in the implementation.
That’s the shift – we stop drawing pictures of systems and start building computable representations of them. The tools become active participants in the engineering process, not just passive drawing surfaces.
Getting there requires the semantic foundation to be correct first. Everything else – the automation, the digital thread, the interoperability – builds on that layer. That’s why the semantics problem isn’t a niche concern for language theorists. It’s the foundation that determines whether system engineering at scale is actually possible.