MBSE

Model-based systems engineering is systems engineering where a connected model, not a set of documents, is the primary way engineering information gets captured, shared, and kept consistent. INCOSE's original working definition, published in its 2007 Systems Engineering Vision 2020, describes MBSE as the formalized application of modeling to support requirements, design, analysis, and verification and validation activities, beginning in the conceptual design phase and continuing through the rest of the system's life cycle (International Council on Systems Engineering, 2007).

The term predates the tooling. Wayne Wymore laid out a mathematical foundation for treating systems engineering as a modeling discipline in his 1993 book, plainly titled Model-Based Systems Engineering (Wymore, 1993). What changed day-to-day practice, rather than just the vocabulary, was the arrival of a standard modeling language everyone could use: the Systems Modeling Language, SysML, adopted by the Object Management Group in 2006 after a joint proposal from INCOSE, the OMG, and industry partners (Friedenthal et al., 2007).

The practical difference shows up the moment something changes. In a document-based program, one requirements change can mean manually updating a requirements spec, a design document, an interface control document, and a test plan, and hoping nobody misses one. In a model-based program, the requirement is an element with explicit relationships to the design elements, interfaces, and test cases that depend on it. Change the requirement, and the model can show you everything connected to it. The documents people actually read get generated from the model rather than maintained by hand.

MBSE is a practice, not a single tool. SysML is the most widely used modeling language for it, but Capella, built around the Arcadia method, and several other languages fill the same role in different organizations. What they share is a way of organizing a system's information into a small number of consistent categories rather than an open-ended pile of documents.

This is also where MBSE connects to the rest of this lesson series. A digital twin's design-stage model and a program's digital thread both assume there's a structured, machine-readable model underneath them in the first place, MBSE is what actually produces that model, not just a name for having one.

MBSE took over three decades to go from a mathematical proposal to a fielded standard, and it's still not finished changing. Wymore's 1993 book supplied the theory. The Object Management Group issued a request for proposals for a systems modeling language in 2003, and adopted SysML version 1.0 in 2006 (Friedenthal et al., 2007). INCOSE formalized MBSE as a named discipline the following year, in its Systems Engineering Vision 2020 (International Council on Systems Engineering, 2007). SysML then went through more than a decade of incremental releases while the OMG, starting in 2017, developed an entirely new foundation for it, which reached final adoption in July 2025 (Object Management Group, 2025).

On July 21, 2025, the OMG approved final adoption of SysML v2 alongside two supporting specifications: the Kernel Modeling Language, KerML, which provides its semantic foundation, and a Systems Modeling API and Services specification that lets SysML v2 models interoperate with other tools (Object Management Group, 2025). That last part matters more than a version bump usually would. SysML v1 was built on top of UML, a modeling language designed for software, adapted for systems work. SysML v2 replaces that borrowed foundation with KerML, a kernel built specifically for systems engineering semantics from the start, aimed at more precise, machine-interpretable models and better interoperability between tools instead of vendor-specific export formats.

Multiple tool vendors, including PTC, committed to SysML v2 support at launch, and the OMG's own reference implementation is open source (Object Management Group, 2025). On the defense side, transition guidance published in February 2026 lays out a notional path for acquisition programs to move from v1 to v2, while expecting v1 to stay in active use for years alongside it (Office of the Under Secretary of War for Research and Engineering, 2026).

Most MBSE literature is written by people who already believe in it, which makes the honest evidence checks worth taking seriously. Henderson and Salado (2021) systematically reviewed research and practice papers across major systems engineering journals and conferences, sorting every claimed MBSE benefit into how it was actually supported: measured, observed without a formal measurement process, perceived with no evidence at all, or simply backed by citing another paper. Two thirds of the claimed benefits they found fell into the weakest category, perceived, and only two papers in the entire review reported measured evidence. Their conclusion was blunt: the evidence for MBSE's value remains inconclusive, even though adoption keeps growing.

That doesn't mean there's no evidence at all. A Sandia National Laboratories review of the literature found real, quantified cases, including a complex submarine program that measurably cut the cost of fixing defects after adopting MBSE, and repeatedly encountered the much older finding that a defect caught late in a program's life cycle can cost on the order of 100 times more to fix than one caught early, which is a large part of MBSE's actual argument for existing (Carroll & Malins, 2016). A follow-up study of organizations that adopted MBSE found an unexpected pattern in who values it: the practitioners who have to build and maintain the models are often less convinced of the payoff than the managers and other disciplines who just consume the resulting views, which suggests some of MBSE's value is organizational and communicative rather than purely technical (Henderson et al., 2024). And a 2025 bibliometric review comparing the last two decades of MBSE research against INCOSE's own roadmap concluded plainly that the field's envisioned future, standardized methodologies, agreed metrics, real tool interoperability, has not yet been achieved (Velthuizen et al., 2025).

Two things are converging on MBSE at once. The standards themselves are being rebuilt, SysML v2's shift to a systems-native kernel and open API is specifically meant to make models easier for other software, not just other engineers, to read and write directly (Object Management Group, 2025). And that same machine-readability is exactly what large language model agents need to interact with a system model at all, INCOSE's own community is already running sessions on enhancing MBSE with large language models, years after treating AI as out of scope for the discipline.

Neither of those threads is finished, and neither gets the full treatment here. Whether an AI agent reading and writing directly to a SysML v2 model actually works in practice, and what happens to engineering judgment when it does, are exactly what the next two lessons in this series cover.