MBSE in Space: A Practical Guide

There is a point in almost every spacecraft programme where the engineering stops fitting comfortably into anyone’s head. The mission has a payload. The payload has interfaces. The spacecraft has power, thermal, communications, avionics, software, GNC and structures, each with its own document. The ground segment has its own requirements. The launch vehicle adds another set of constraints. Then somebody changes one requirement, and three subsystems, two interfaces and a verification plan all need to change with it.

This is where Model Based Systems Engineering, MBSE, becomes much more than another engineering tool. At its simplest, MBSE means doing systems engineering with a digital model of the system at the centre of the work, instead of relying primarily on documents, spreadsheets and disconnected diagrams. Engineers build a structured representation of the system, its requirements, architecture, behaviour, interfaces and relationships. The important word there is structured. The model is not a prettier diagram. It is meant to become a living engineering representation of the system, and that matters enormously in space.

Why documents stop being enough

Traditional systems engineering has historically leaned heavily on documents: a requirements document, an interface control document, an architecture document, a verification matrix, a power budget, a thermal model, drawings, spreadsheets, and hundreds of pages of technical notes. Each of those may be perfectly reasonable on its own. The trouble starts when you need to understand how they relate to one another.

ESA describes the motivation well. Space systems have become complex enough that documents alone struggle to describe all of the relationships, dependencies and exceptions inside a mission, which is why ESA has spent more than a decade developing MBSE approaches aimed at improving digital continuity across the mission lifecycle and supply chain.¹ MBSE tries to move the centre of gravity from documents to a model that describes what the system is supposed to do, what requirements apply, what components make it up, how those components interact, what interfaces exist, how the system behaves, and how requirements get verified. The documents do not disappear. They simply stop being the only place the engineering knowledge lives.

Why spacecraft programmes reach for it

Spacecraft are unusually good candidates for model based engineering, being complex systems with long development cycles, expensive hardware, tightly coupled subsystems and very little tolerance for ambiguity. A seemingly small change can propagate a long way: increase the payload power requirement, and the power subsystem changes, which can affect thermal performance, which can affect radiator sizing, which can affect mass, which can affect propulsion, which can affect launch margins. The small change stops being small somewhere along that chain.

NASA has identified several potential benefits of MBSE and model based assurance, including improved management of complex development, better design decisions, reduced development risk and improved cost management, and has explored models supporting requirements coverage, hazard analysis, reliability analysis, test planning, validation and verification.² That does not mean MBSE magically makes a programme cheaper or removes engineering risk. It means engineers get a better mechanism for understanding and managing the complexity that was already there.

A spacecraft is a system of systems

Take a simple Earth observation spacecraft. The mission needs the payload to collect imagery over a particular area, which sounds like a payload requirement, but quickly becomes a systems problem. The spacecraft needs to point accurately. GNC needs to determine and control attitude. The reaction wheels need to deliver the required torque. Flight software needs to command the hardware. Electrical power needs to supply enough energy. Thermal design needs to keep components within their limits. Communications needs to transmit the data. The ground segment needs to schedule the operation and receive it. And mission operations needs to understand what happens if any part of that chain behaves unexpectedly. MBSE gives engineers a way of representing that system coherently, rather than scattered across a dozen documents that each know only their own corner of it.

SysML is a language, not the method

MBSE and SysML are often mentioned together, but they are not the same thing. MBSE is the engineering approach. SysML, the Systems Modeling Language, is one of the languages used to represent systems, describing requirements, blocks and components, interfaces, activities, states, allocations, relationships, constraints and behaviour. ESA has developed its own SysML Solution to support MBSE within its projects and align modelling with ECSS, with the current solution supporting SysML v1.x and, since August 2024, a pilot implementation of SysML v2.³ The point for anyone learning MBSE is not to become obsessed with drawing every possible diagram. The model exists to answer engineering questions, and a beautiful model nobody uses is just another document nobody reads.

Requirements: where MBSE starts earning its keep

A requirement should not sit alone in a spreadsheet. You want to know what higher level requirement generated it, which system element is responsible for satisfying it, which interface it depends on, how it will be verified, and what happens if it changes. That is traceability, and instead of asking someone to search hundreds of pages to trace the consequences of a change, the model can expose those relationships directly. On a complex programme, that is not just a convenience. It becomes a genuine risk control mechanism.

Architecture as a shared reference point

Once requirements are understood, someone has to decide what the system actually looks like, and this is where MBSE becomes particularly useful for holding a design together. Which radio, where does encryption happen, which processor handles packetisation, which software component owns the interface, what happens if the primary radio fails, which power modes exist, how does the ground segment interact with the spacecraft? Those decisions can live inside the system model as a shared reference point for engineers working across disciplines. The problem MBSE solves here is not that individual engineers lack knowledge. It is that the overall system holds more knowledge than any one person can comfortably carry, and the model becomes the place where that knowledge can meet.

NASA’s Launch Services Program ran an MBSE pilot around the Mars 2020 mission, modelling aspects of the Mars Science Laboratory and Mars 2020 interface and operations requirements between the spacecraft and launch vehicle using SysML, specifically to explore whether a model could provide greater insight into that interface and improve requirements management.⁴ That is a good example of practical MBSE. It starts with an engineering problem, and the model is the mechanism used to attack it, not the other way around.

Verification: closing the loop

Spacecraft requirements eventually need evidence, whether through inspection, analysis, demonstration, testing, simulation, or hardware and software in the loop testing. NASA’s work on model based assurance specifically highlights the potential for models to support verification, validation, test planning and requirements coverage.² A model can connect the requirement to the verification evidence directly: requirement, architecture, implementation, verification method, verification evidence, ideally in both directions, so that a changed requirement flags what evidence may need revisiting, and a failed test flags which requirements and system elements are affected. That kind of traceability becomes extremely valuable late in a programme, when time is short and the stakes of missing a connection are high.

NASA’s Lunar Atmosphere and Dust Environment Explorer offers a particularly interesting example, because the modelling went beyond describing the system. LADEE’s flight software development used a model based software engineering approach alongside reused government and commercial components: requirements were prototyped and refined using simulation models, C code was then automatically generated once the model behaved as intended, and that generated software was tested using real time processor in the loop and hardware in the loop test beds.⁴ That is MBSE built into the engineering workflow itself, not sitting beside it.

MBSE is not a substitute for experienced engineers. A model can be perfectly consistent and still represent a bad design. The best systems engineers use models to think more clearly, not to outsource the thinking.

Tools change. The skill does not

There is no single MBSE tool that every space company uses. Common environments include CATIA Magic and Cameo Systems Modeler, Enterprise Architect, Capella, MATLAB and Simulink, OpenMBEE, ESA’s own SysML Solution, and various internally built modelling environments. What transfers between them is not familiarity with one product menu, but understanding how to build useful system models and connect them to real engineering processes. A good MBSE engineer moves comfortably between the tool and the engineering question behind it.

Where it is heading: digital engineering

MBSE is increasingly becoming part of a broader digital engineering approach, where the ambition is not a model sitting beside the programme but engineering information flowing through the full lifecycle: requirements, architecture, simulation, software, hardware, testing, operations, change management, and eventually anomaly response itself. ESA has described its longer term goal as extending MBSE across the lifecycle, across disciplines and throughout the supply chain.¹ NASA is moving in a similar direction. In August 2026, NASA published work connecting MBSE with fault management for autonomous missions, using early design information from the HelioSwarm mission to demonstrate model based generation of failure modes and effects analysis and fault trees.⁵ That is where the model stops being documentation and starts becoming part of how the system understands itself.

What we look for in an MBSE specialist

We are rarely interested in hearing that someone has five years of SysML. We want to know what they actually did with it. What problem were they solving? What was difficult? Who used the model, and did it influence an architecture decision or connect requirements to verification? Did it integrate with simulation, did suppliers use it, and what happened when the design changed? Did the model survive contact with the real programme? Those questions reveal far more than a list of software packages, because the strongest MBSE specialists we place are fundamentally systems engineers first. Modelling is their language. It is not their identity.

There was a time when an engineer could be excellent at systems engineering without touching MBSE, and that is still possible today. But as spacecraft grow more complex, autonomous and software defined, the ability to work fluently with structured digital models is becoming a core systems engineering skill rather than a specialism sitting off to one side. ESA’s own MBSE programme has moved from research and experimentation toward practical project adoption, with real mission and industrial use cases now appearing across its workshops and programmes. The direction of travel is fairly clear, and it is worth hiring for it early rather than catching up later.