The missing integration layer for open MBSE?

Roar Elias Georgsen, 27 August 2026
LinkedIn · Bluesky · Google Scholar · ORCID

I want SysML v2 models to be easier to connect to everything else an engineering organisation runs, down to the spreadsheets that quietly hold the place together. My proposal is federation. The model’s owners publish a small projection of it, chosen with SysML’s own views and viewpoints, and other services attach their own data to the model’s elements by agreeing on an identifier. Nobody else has to learn SysML to join in.

This site is where I write up the experiments. It is a personal blog, so expect opinions and the occasional admission that I should have known better. The first series builds a proof of concept, a SysML v2 adapter behind a Cosmo router with one worked example, and follows it from the first sketch to a published container image. It is a demo and not a product. The second series, still being written, asks how a systems model’s links to everything else that gets built could be found and kept without anyone typing them.

Federating a systems model

Complete, in thirteen parts, written for release v0.3.0. If a later release changes something an article says, that article gets a note saying so.

The idea

Why do models stay locked in their tools, and what does federation change?

1. Why federate a systems model?
   Models were meant to end the drift between an organisation’s documents, and closed tools kept them out of reach. SysML v2 opens the model up, and federation lets other tools join it without learning SysML.
2. The architecture in one sitting
   How does one query collect its answer from three services that never talk to each other, and which decisions put them all in one container?

The design

How was the demo designed before any code was written, and what did each round of review catch?

1. How the design was run
   Four approval gates stood between the idea and the first line of code. Reading each document back against its sources caught three design errors early.
2. What the research overturned
   Before designing anything, I wrote down what I believed about the tools and tried to knock each belief over. Three of the six claims that mattered fell.
3. Twelve use cases and one moving bottleneck
   The example pipeline and the twelve short stories a visitor walks through. Their one surprise is that raising the bottleneck moves it somewhere else.
4. From use cases to requirements
   Turning the stories into forty-five testable requirements exposed three holes in the design, and pinned down how the capacity number is computed.
5. Five views and twenty-six decisions
   The architecture seen from five angles, each for a different reader, with a written record behind every choice that shaped it.
6. An A3 sheet for a fifteen-minute reader
   Why is the overview one printed sheet, what does the A3 method force on it, and what do the two sheets drawn so far show?

The build

How did the approved design become a published container image?

1. Planning the build
   How did the approved design become five phases of work, one pull request each and tests first? And which choices did the design leave for the plan?
2. Five spikes before the first line
   Five small experiments tested the riskiest assumptions, four of them before any product code existed. None failed outright, and each of those four corrected the plan.
3. The demo as it shipped
   What does the finished demo show once it runs, how does a visitor’s fifteen-minute walk through it go, and what did the build come to?

Looking back

What does the finished demo prove and leave open, and why does it now have a systems model of its own?

1. What shipped, and what did not
   How big is the published image, how is its release guarded, what does a run with no network prove, and where has the demo been run?
2. A model of the demo itself
   I take my own advice at last. This article describes the demo as a SysML v2 model that a test keeps in step with the code, with a Checkly session that runs every storyboard story against the live demo.

The documents behind it

These are the boards, sheets and records the articles draw on, for anyone who wants the source material.

• 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 34 decisions with their alternatives and consequences.
• The model of the demo, the demo itself in SysML v2, with its stories, requirements, architecture, tests and views, validated by the two reference tools on every change.
• The check session, the Checkly project that runs every story against a live instance through a tunnel, with a collector and a trace viewer. It needs your own Checkly account, since mine cannot ship with the image.

Automating traceability

In progress. The second series takes on automating the federation itself. Before the rest of a system’s tools can join the graph, something has to decide which of their objects are which elements of the systems model, and in the demo that’s still me, by hand. New parts appear here as they’re published.

The task

What is entity resolution between a systems model and a built system, and what is a single task of it made of?

1. Why does a systems model need entity resolution?
   Hardly anything a team builds carries the keys from its systems model. What does it take to find the counterparts of each element of the systems model anyway, and why is that job never quite finished?
2. The parts of a resolution task
   What goes into a single resolution task, from what counts as a candidate to where the finished link lands? And why do two tools disagree about whether a renamed thing is still the same thing?

Errors and measurement

Why does no resolver get every link right, and how can you tell how good one is?

1. Why no resolver gets every link right
   One change to a hypothetical pipeline breaks three links nobody touched. What makes a link correct, why are some incorrect and missing links certain, and when can a resolver be left to add links on its own?
2. Measuring a resolver
   How can a perfect score prove nothing, and 99% accuracy mean linking nothing? And how do you measure a resolver against a set of correct links that changes along with the system?

Running a resolver

What decides whether a resolver is worth running, once its links are good enough?

1. What makes a resolver worth running?
   A resolver that measures well can still be a poor choice to run. What else decides it, from where a link came from to who may read the systems model?

Testing a language model

Can a language model on your own hardware follow the links in a systems model, and are the reasons it gives the ones it had?

1. A resolver that reads the systems model
   What does it take to put a language model on a real traceability job, on your own hardware, so that a success is one a sceptic would believe?
2. Why did the language model go round in circles?
   A language model on my own hardware read my web service’s systems model like a wiki, one element at a time, under rules fixed before the run, and a program with no language model beat it 42 to 17 of 69. Why did it go round in circles, and what would have had a better chance?

The repository

The code is at https://github.com/Roarge/sysml-federation, under the Apache 2.0 licence.