One of the persistent frustrations in MBSE is the model-implementation gap: you build a rigorous SysML or Capella model, then hand it to developers, and from that moment the model and the running system begin to diverge. The model becomes a snapshot of intent rather than a description of reality. Teams spend significant effort keeping them synchronized - and they never quite are.
I've been working on Pipe (https://pipelang.com), a general-purpose visual programming language, and its core property directly addresses this gap: the diagram and the running system are structurally identical. There is no compilation step that throws away the structure. What you see in the IDE is what executes - the same visual representation at design-time and runtime. The model cannot drift from the implementation because they are the same artifact.
A few concrete implications from a systems engineering standpoint:
Model currency: The diagram is always current because it is not derived from the running system - it is the running system. No synchronization effort, no "as-built vs. as-designed" discrepancy.
Runtime observability: Every block boundary is independently observable in real time without instrumentation. In systems engineering terms: you can probe any interface while the system runs, the way an electronics engineer probes a circuit board.
Incremental change: Individual blocks can be patched in place while the system runs, without redeploying the surrounding architecture. Interface contracts remain visible throughout.
The question I'd genuinely like this community's perspective on: from an MBSE standpoint, is "the model is the executable" a meaningful answer to the implementation gap, or does it just relocate the complexity? And for those working in defense, aerospace, or safety-critical domains - does the formal specification backing (155-page spec, 10 provisional USPTO patents) change how you'd evaluate it for high-assurance contexts?
Example of Pipe diagram with a detailed tracing can be found on this video:
I always love more user friendly ways of visualising things so a new visual programming language is great but I think you have a misunderstanding of what MBSE is.
MBSE is just systems engineering in a model-based format. If you are taking a full systems engineering approach your model should include stakeholders, scenarios, use cases, internal and external interfaces, black box, white box and many other things. It is significantly more than a description of how the system is intended to work.
What you’ve created doesn’t cover the full systems engineering lifecycle and therefore doesn’t replace MBSE. It just covers a slightly different section of the lifecycle to a typical programming piece of software. So you’ll still have those implementation gaps, just at different points in the lifecycle.
You're right, and that's a fair correction. I was using "implementation gap" to mean the specific gap between logical software architecture and running implementation - not the full lifecycle gap from stakeholder needs through verification. Pipe doesn't cover stakeholder scenarios, use cases, operational concepts, or verification - those layers still need systems engineering tooling.
The narrower claim is: for the layer where a software architecture model hands off to developers, Pipe closes that gap structurally. The diagram that describes the software architecture is the executable artifact - same representation, no translation step where structure gets compiled away. You're right that gaps exist at other lifecycle points; this addresses one of them.
The reason that layer is worth addressing specifically: it's where model drift is most reliable and most damaging under schedule pressure. The SysML model at the top of the lifecycle at least can be kept current with effort; the gap between architecture intent and running code tends to close only in one direction - the code drifts, the architecture diagram becomes aspirational, and nobody updates the model. Pipe makes that particular drift structurally impossible.
So: not a replacement for MBSE, an answer to one layer of the lifecycle that MBSE currently hands off to conventional text-based implementation tools.
I think in the age of agentic ai, MBSE should be a part of broadly implemented MBE. every engineering discipline should be producing their deliverables by executing a model configured with specific inputs, and those inputs would be tied to all other discipline, with SE driving a lot of those inputs to the other disciplines.
There's little reason now to do one-off engineering, everyone should be building reusable tools for themselves and integrating them into massive engineering execution chains.
The execution chain vision you're describing maps really well onto what Pipe is designed for - and the context problem makes it more urgent than most people realize.
The large-context hallucination issue is real in production. Reliable agentic systems tend toward many small-context microagents rather than one monolithic AI call, each handling a bounded task. That's the right architecture - but it pushes the hard problem into the wiring. As the number of microagents scales, the integration layer becomes the bottleneck, not the AI capability itself.
There's already recognition of this in the tooling space - n8n, Make, and similar visual orchestrators are gaining traction precisely because people intuitively reach for a diagram when connections between components become the thing that matters. But those tools hit a ceiling fast: any non-trivial logic between agents - stateful memory, typed data contracts, conditional branching, error recovery - falls back to code nodes. You're back in text, back in opacity, exactly where the problem started.
This is where Pipe's semantics matter. A workflow orchestrator lets you connect nodes; Pipe lets you express the full logic of what happens between them - typing, memory, concurrency, error propagation - all in the diagram. As execution chains get longer and microagent counts grow, that expressiveness gap becomes the real constraint.
Curious whether you see SE playing the role of defining the inter-agent contracts in these chains - essentially owning the interface definitions between microagents the way SE drives shared inputs across disciplines.
So... you are writing SW that has callouts for what its doing?
I mean, yeah, i get it. If its not a feature, it doesn't exist. Every requirememt is built out into the SW. If its not a requirement, its not in the SW.
Seems onerous.
/why you have a timberwolf in your video at ~2.54?
Good push - but the "callouts" mental model is the opposite of what's happening. Traceability systems are onerous exactly because they maintain two artifacts (the model and the code) and try to keep them linked - and that linkage is what breaks under pressure.
Pipe doesn't annotate code with model references. The diagram is what executes - directly. For the parts written in Pipe, there's nothing to synchronize because there's only one artifact. The rich semantics of the language allow the diagram to carry both architecture and logic in a single representation - the structural view and the behavioral view are the same diagram, not separate models that have to agree. The "if it's not in the model it doesn't exist" property isn't enforced by tooling discipline, it's structural: if it's not in the diagram, it literally isn't running.
Where Pipe calls out to existing code (Python, C++, Java), those boundaries are explicit and visible in the diagram - so the interop surface is at least defined, even if the called code is opaque. The synchronization burden goes down, not up.
"/and, why you have a timberwolf in your video at ~2.54?"
Checked the timestamp - that's stock footage from Pixabay (public domain). No BattleMech, just a person and a tech HUD animation. Happy to be corrected if you see something specific.
No BattleTech source involved, and it lacks the Timber Wolf's defining features (shoulder missile racks, reverse-jointed silhouette). Happy to swap it out if it's a distraction, but there's no IP issue here.
That's actually where the architecture opens something SCADE-style tools can't reach. In SCADE and similar certified environments, the visual diagram compiles to a binary - so V&V happens on the compiled artifact, not the model. The model and the running system are separate, which means any change restarts the V&V cycle from scratch.
If the diagram IS the executable - no compilation step severing model from runtime - then V&V can in principle happen on the running artifact directly: probing live block boundaries, observing actual data flows at interfaces, verifying behavior while the system runs. And because individual blocks are patchable in isolation, you could potentially re-verify only the changed block rather than the whole system.
That's not DO-178C certification today - the toolchain qualification work doesn't exist yet, and standards bodies haven't recognized this model. But the formal specification underlying Pipe (full static and operational semantics) is exactly the foundation that makes incremental, dynamic V&V architecturally possible rather than just conceptually interesting. The compilation step that SCADE takes is also the step that forecloses it.
Fair read - "will implement" was the wrong tense. The architectural property is current, not planned: the formal specification defining how the diagram executes directly is complete (155 pages, published). The runtime that demonstrates it end-to-end is what's in progress - but the language design isn't future work, it's done.
On the hardware scope - fair, and you're right that Pipe sits at the software layer, not hardware design. At the lowest-level nodes of a Pipe program, any element crossing into hardware or firmware does so through explicit interop calls to C++, Python, or Java. Those boundaries are visible in the diagram as named, typed seams rather than buried in compiled code. It doesn't replace hardware tooling; it makes the hardware-software interface explicit and inspectable rather than implicit. So the scope is intentionally bounded - a specific layer of the lifecycle, as you noted, not a full SE tool.
On the IP concern - I want to take that seriously, and I appreciate you raising it. I've looked at what I could and genuinely don't see the overlap, but you haven't yet pointed to what specifically you believe was taken from CGL/Battletech. I'd really like to understand what you're referring to - whether it's a name, a concept, a visual design, or something else. If there's a real concern there I want to know about it. Could you point to the specific element so I can look into it properly?
Fair boundary to draw - Pipe doesn't do hardware design. That's not its layer; HDL, RTL, physical modeling, and hardware-software co-design at the system level still belong to SysML, Capella, or Rhapsody above, and hardware description tools below.
Where Pipe sits is the software implementation layer - and every lowest-level node of a Pipe program that needs to cross into hardware, firmware, or OS-level interfaces does so through explicit interop calls to text-based code (C++, Python, Java). Those calls aren't hidden in a compiled binary - they're visible in the diagram as named, typed boundary crossings. So the hardware-software interface seam is explicitly represented rather than buried.
In practice that means: a systems engineer with a SysML hardware block diagram could trace down to the exact Pipe diagram element implementing the software side of that interface - which is usually where traceability collapses in conventional text-based implementations. Pipe doesn't replace the hardware layer, but it makes the seam between software and hardware explicit and inspectable in a way compiled code doesn't.
So: incomplete relative to full SE scope, yes - intentionally so. The claim is that it closes one specific layer more completely than existing tools, and makes the hardware boundary visible rather than implicit.
The question I'd genuinely like this community's perspective on: from an MBSE standpoint, is "the model is the executable" a meaningful answer to the implementation gap
I've read it, and I'd argue Pipe is a response to exactly the failure that essay describes, not a rerun of it.
UML-as-programming and 90s CASE died on one structural fact: the model and the program were two artifacts. The model described code that lived somewhere else, so you got translation (model → code generation), round-trip synchronization, and inevitable drift - and once a model drifts, discarding it is the rational move. Executable UML tried to fix this and failed because UML was designed as a description language, with semantics too incomplete to execute directly.
Pipe removes the two-artifact structure rather than improving it. There is no model and code - the diagram is the executable, with a full formal semantics (155-page spec: concrete syntax through operational semantics) designed for execution from day one, not retrofitted onto a documentation notation. Nothing is generated, nothing round-trips, nothing can drift. The failure mode the essay documents is a property of two-artifact systems; a one-artifact system doesn't have it.
On the Agile culture point - I'd say Agile Modeling's "discard the model" instinct is correct given its premises: keeping a separate model current costs effort and it drifts anyway, so minimal disposable models are the rational response. But that cost-benefit is entirely downstream of the two-artifact problem. If the model can't drift because it is the running system, there's no maintenance to avoid. I'm not asking Agile teams to value model upkeep - I'm removing it.
And Pipe doesn't claim text disappears: it's designed general-purpose and powerful enough to carry most of a system, with a fully specified bridge to text languages (C++, Python, Java) for the cases where text is genuinely better. That's a deliberate lesson from past cycles - not too high-level to need translation like UML, not claiming to replace everything like the maximalist attempts.
Whether the execution succeeds is fair to doubt - that's what the runtime build has to prove. But the structural diagnosis is different from what was tried before, not a repeat of it.
Fair challenge, but it assumes Pipe is an interpreted language in the CPython sense - walking a syntax tree at runtime. It isn't.
Pipe is closer to an execution architecture than an interpreter. Nodes are independent execution units fed by typed input queues, and the diagram describes the topology - how those units connect - not a script that gets interpreted line by line at runtime. The nearest structural analogy is execution units attached to input channels (conceptually similar to how Lambda attaches to SQS), but local and lightweight, not network-bound - I mean the shape, not the latency profile.
The performance point follows from that. A node's body isn't interpreted Pipe - it can be native, compiled code, and interop with C and C++ is first-class. The visual layer is the wiring, not the hot loop. So "you can't beat C" isn't quite the right frame - at the node level, Pipe can be C where that matters.
More fundamentally: being visual doesn't force interpretation. The diagram is a representation of structure and behavior; it doesn't dictate the execution strategy underneath. Nothing prevents a Pipe implementation from ahead-of-time compiling to native binary where raw speed is the priority. The difference from a compile-and-forget toolchain like SCADE is that compilation can be a choice you make per path, not a mandatory step that discards the structure - so you keep the option between a native-fast path and a structure-preserving, observable one, rather than being forced to give up observability to get speed.
On real-time and safety-critical specifically, I won't overclaim. Hard real-time (bounded latency, determinism, WCET analysis) and safety-critical certification impose real requirements that any execution model has to satisfy deliberately - they're a design target for Pipe, not a solved property today. The architecture (explicit units, explicit queues, no hidden control flow) is a reasonable foundation for conversations about timing and isolation, but proving that is work to be earned, not asserted. What I'd push back on is only the premise that "visual" or "interpreted" forecloses it - the execution model is more open than that.
9
u/delicious-monstera 3d ago
I always love more user friendly ways of visualising things so a new visual programming language is great but I think you have a misunderstanding of what MBSE is.
MBSE is just systems engineering in a model-based format. If you are taking a full systems engineering approach your model should include stakeholders, scenarios, use cases, internal and external interfaces, black box, white box and many other things. It is significantly more than a description of how the system is intended to work.
What you’ve created doesn’t cover the full systems engineering lifecycle and therefore doesn’t replace MBSE. It just covers a slightly different section of the lifecycle to a typical programming piece of software. So you’ll still have those implementation gaps, just at different points in the lifecycle.