The missing integration layer for open MBSE
Roar Georgsen, 27 August 2026
One system, four descriptions. A requirements file, an interface sheet, a power budget spreadsheet, a hazard analysis a third team owns. Every copy starts drifting the moment it is made. Model based systems engineering was supposed to end that, and has been five years from mainstream adoption for about a quarter of a century. The industry tried a central integration platform, then a linked data layer. Both assumed somebody employed to do integration full time. Firms with fewer than 25 engineers have no such person, and they are where most engineering happens. This is for them.
SysML v2 dropped the UML profile and came with a standard API. What it returns is the metamodel, so every downstream tool must learn SysML before it can read a requirement. I would rather the model’s owners published a small, plainly typed projection, joined by federation to whatever else describes the same system. Nobody outside systems engineering should need to know what SysML is.
A demo is being built. A query pipeline of five servers, an analysis that has never parsed a model file, a requirements document that has never computed anything, and a requirement that fails until the right server changes. What the demo has to prove is that the connecting layer can exist with nobody employed to maintain it. The design is written up below in the present tense, and it runs from the first tagged release.
- Why federate a systems model
The integration problem MBSE never solved, what SysML v2 changes, and the claim this repository makes. - The architecture in one sitting
Three services, one router, two apps and one container, with the twelve decisions that shaped them. - How the design was run
Four gates before any code, every document read back against its sources before approval, and the repository rules that held throughout. - What the research overturned
Six topics investigated, every load-bearing claim checked against its primary sources, and four of them refuted. - Twelve use cases and one moving bottleneck
The brief, the personas, the example model and the storyboard, and what the first review changed. - From use cases to requirements
Constraints, 45 requirements, traceability and the capacity model, with the three findings that reached back into the design. - Five views and twenty-six decisions
The architecture description, its viewpoints, the decision records and the review that changed mechanisms without changing decisions. - An A3 sheet for a fifteen-minute reader
Why the overview is a printed sheet, the method it follows, and the two sheets drafted. - Planning the build
Five phases, one pull request each, test first, and the decisions the plan had to make on its own. - Five spikes before the first line
The syntax the reference tools accept, nested requires through the router, a router with no config file whose readiness lies, and cross-platform copying. - The demo being built
What it does once it runs, package by package and service by service, and what a visitor sees in fifteen minutes.
Two apps, one graph, three services that never meet.
Documents
- Architecture views, the five views and the overview board as one PDF, one page per board.
- L0, Federating a systems model, an A3 sheet for the reader asking “What does this demo claim, what is in the box, and what would I keep or replace if I adopted it?”
- L2b, Pipeline example: capacity and verdicts, an A3 sheet for the reader asking “Why does raising one server change nothing and raising another change everything?”
- Use cases, the storyboard as one PDF, one page per use case after the overview.
- Decision records, the 26 decisions with their alternatives and consequences.
The repository
The code is at https://github.com/Roarge/sysml-federation, under the Apache 2.0 licence. The command that starts the demo arrives when the first release is tagged. The same articles are rendered as a site at https://sysml-federation.org/.