What is the difference between document-centric and model-centric systems engineering in defense programs?

Document-centric systems engineering produces a chain of Microsoft Word and PDF artifacts — System Requirements Specification (SRS), Interface Control Document (ICD), Architecture Description Document — each maintained separately and linked by manual cross-references that become stale as requirements change. When a requirement changes, engineers must manually trace which architecture elements, interface definitions, test cases, and verification reports are affected. Model-centric engineering, the foundation of MBSE, replaces this document chain with a single authoritative SysML model that contains requirements, architecture, interfaces, behavior, and traceability relationships as first-class model elements. A change to a requirement in the model immediately reveals all elements that allocate to it via the tool's impact analysis. The model is the primary engineering artifact; documents are generated views of it. For a defense program with thousands of requirements and hundreds of components, this structural difference eliminates weeks of manual change impact analysis per Engineering Change Proposal and dramatically reduces the frequency of requirements orphans — requirements that no architecture element addresses.

Which SysML diagram types are most useful for defense systems and which should be avoided?

Block Definition Diagrams (BDD) and Internal Block Diagrams (IBD) are the highest-value SysML diagram types for defense systems. BDDs define the structural taxonomy of the system — what blocks exist, their properties, and their type relationships — and are the primary vehicle for system decomposition and interface specification. IBDs show how block instances are connected via ports and connectors for a given context, making them ideal for specifying data flows between sensors, processors, and actuators in a weapon system or C2 architecture. Sequence Diagrams and Activity Diagrams are valuable for behavioral specification of critical use cases, such as authentication sequences and mission execution workflows. Parametric Diagrams are essential when system performance constraints (latency, throughput, power budget) must be formally allocated and tracked. State Machine Diagrams model operational modes and mode transitions. What should be avoided: creating diagrams as illustrations rather than as model elements. A diagram that is drawn in the modeling tool but whose elements are not connected to the underlying model — no requirements allocated, no interface specifications linked — provides no traceability value and creates a maintenance burden. Every diagram element should be a model element, not a graphical annotation.

How does requirements traceability work in a SysML MBSE model for a defense program?

Requirements traceability in SysML is implemented through the «satisfy», «verify», «refine», and «derive» dependency relationships. A stakeholder need (captured as a SysML Requirement with a text property and a unique identifier) is refined into a set of system requirements using «derive» — each derived requirement is traceable to its source stakeholder need. System requirements are then allocated to architecture elements using «satisfy»: a Requirement element has an outbound «satisfy» relationship pointing to the Block (or its feature) that satisfies it. Verification is captured with «verify» relationships from test cases (modeled as TestCase elements in the model) to the requirements they verify. The resulting traceability matrix — which most MBSE tools can generate as a report — shows, for every requirement, which architecture element satisfies it and which test case verifies it. Orphan requirements (no «satisfy» relationship) and unverified requirements (no «verify» relationship) appear immediately as gaps. This is a live document: when a block is modified, all requirements it satisfies are visible in the model without manual search, and the change impact propagates through the traceability graph automatically.

What is the digital thread and how does it connect a SysML model to testing and simulation?

The digital thread is a linked data chain that connects every engineering artifact — from stakeholder need through system requirement, architecture element, software design, implementation, and verification result — so that information created at any point in the lifecycle is accessible and traceable from any other point. In an MBSE context, the digital thread begins with SysML model elements and extends to: generated interface code (IDL or header files derived from SysML interface blocks); generated test scripts (test cases derived from SysML TestCase elements and requirement allocations); and simulation models (Simulink or Modelica models whose parameter interfaces are derived from SysML parametric constraints). The key property of a digital thread is bidirectionality: a change to a SysML block interface propagates forward to generated code and tests, and a test failure can be traced backward through the thread to the requirement it verifies and the architecture decision that produced the design under test. Without the digital thread, these connections are maintained in spreadsheets and personal knowledge — fragile and non-scalable on programs with thousands of components.

How does DoDAF fit into an MBSE approach and which views can be generated from a SysML model?

DoDAF (Department of Defense Architecture Framework) defines a set of model viewpoints — OV (Operational Views), SV (Systems Views), TV (Technical Standards Views) — that acquisition programs must produce to describe the operational context and technical architecture of a defense system. In a document-centric program, these views are produced as standalone Visio diagrams or PowerPoint slides, separate from the engineering model and therefore immediately outdated when the system design changes. In an MBSE program, the same SysML model that drives engineering work is also the source for DoDAF view generation: the OV-1 High-Level Operational Concept Graphic is derived from use case and activity model elements; the OV-2 Operational Resource Flow Description is derived from IBD connectors annotated with operational information flows; the SV-1 Systems Interface Description is derived from the system-level IBD showing physical component interconnections. Most MBSE tools (Cameo, Rhapsody, Capella) have DoDAF profile plugins that map SysML model elements to DoDAF data elements and auto-generate compliant view documents, eliminating the manual synchronization effort between the engineering model and the acquisition documentation.

What is the difference between Cameo Systems Modeler, IBM Rhapsody, and Capella for defense MBSE?

Cameo Systems Modeler (now part of Dassault Systèmes as part of the No Magic acquisition) is the market leader for SysML-based MBSE in defense programs. It features strong SysML 1.x compliance, mature DoDAF and UPDM profile support, extensive report generation, and deep Teamwork Cloud integration for multi-user collaborative modeling. It is the primary tool in the US DoD MBSE community and is used by most prime contractors. IBM Rhapsody is the principal tool for model-driven development where the model drives code generation: Rhapsody has tight integration with C, C++, and Java code generation and is preferred for embedded real-time systems where the model directly produces deployable software. It is widely used in avionics and weapon system embedded software contexts. Capella is an open-source MBSE tool from Thales, based on the ARCADIA method. It is not SysML-native but uses ARCADIA's own viewpoint hierarchy (Operational Analysis, System Analysis, Logical Architecture, Physical Architecture) that closely matches the defense acquisition lifecycle. Capella is increasingly adopted by European defense programs, particularly in France, and has no license cost — making it accessible for smaller programs and for training. The choice between them depends on the program's modeling methodology, the prime contractor's existing tool investment, and whether code generation from the model is a requirement.

How is SysML 2.0 different from SysML 1.x and does it matter for defense programs currently using SysML 1.x tools?

SysML 2.0, finalized by OMG in 2024, is a ground-up redesign of the language that addresses decades of accumulated complaints about SysML 1.x. The most significant changes are: a textual notation (KerML and SysML 2 textual syntax) that allows the model to be stored and diffed in text form rather than as opaque binary XMI; a cleaner, more expressive type system with first-class support for occurrences and temporal semantics; and a standardized API for tool interoperability that replaces the vendor-specific XMI extensions that currently make SysML 1.x model exchange between tools unreliable. For defense programs currently using SysML 1.x tools, SysML 2.0 is not immediately disruptive: existing models remain valid and existing tools (Cameo, Rhapsody) will support SysML 1.x for many years. New programs started in 2026 and beyond should evaluate SysML 2.0-native tools or wait for the established vendors to ship full SysML 2.0 support, expected in 2026–2027. The textual representation is particularly valuable for defense programs that use configuration management baselines — SysML 2.0 models can be versioned and diffed in standard version control systems, whereas SysML 1.x XMI diffs are essentially unreadable.

How do you measure MBSE return on investment on a defense program?

MBSE ROI in defense programs is measured across four cost categories where model-centricity reduces effort compared to document-centric baselines. First, change impact analysis cost: in document-centric programs, an Engineering Change Proposal (ECP) requires manual tracing across SRS, ICD, architecture documents, and test plans — typically 40–80 person-hours per ECP on a complex program. MBSE reduces this to hours by querying the model's traceability graph. Second, requirements orphan and gap detection: automated consistency checks on the model identify unallocated requirements and unsatisfied allocations that would otherwise be found at CDR, when correction is expensive. Third, DoDAF artifact production: auto-generated OV/SV views from the model eliminate 2–4 weeks of manual drafting per major review. Fourth, interface defect rate: IBD-driven interface specification with automated consistency checks between mating port definitions reduces interface defects — historically the most expensive category of defect in defense integration — by 30–50% in programs that enforce model-driven ICDs. The Programs Executive Office for Defense Systems (PEO DS) MBSE pilot data from 2019–2022 reported average savings of 15–20% of total system engineering cost on programs that implemented MBSE with at least 80% model element coverage of system requirements.

What is model governance in MBSE and who should own the authoritative model in a defense program?

Model governance defines the policies, roles, and procedures that determine how the authoritative MBSE model is maintained, versioned, reviewed, and used as the basis for downstream decisions. In a defense program, the authoritative model — the single source of truth for system architecture, requirements traceability, and interface definitions — must be owned by a designated Model Owner role, typically the Chief Systems Engineer or Lead Systems Architect. The Model Owner is accountable for model correctness, has merge approval authority over changes to controlled model elements, and maintains the Model Governance Plan that defines element ownership by discipline (mechanical, electrical, software, human factors) and the Change Control Board process for model changes. Without governance, MBSE models degrade: engineers create local copies to avoid coordination overhead, diverge from the authoritative model, and the program reverts to document-centric behavior. Model governance must be established in the Systems Engineering Management Plan (SEMP) before the program enters SDD. Key governance artifacts include: element ownership matrix, model baseline schedule aligned to CDR/PDR, element state lifecycle (working / baselined / obsolete), and model review procedures equivalent to document review procedures under DI-SESS-81861.

Can MBSE models be used for software-in-the-loop (SIL) and hardware-in-the-loop (HIL) test automation in defense programs?

MBSE models can drive SIL and HIL test automation when the model is connected to a simulation framework through the digital thread. The typical integration architecture uses SysML parametric diagrams to define the system's mathematical constraints and performance requirements, then links those constraints to Simulink or Modelica simulation models that implement the physics and control laws. For SIL testing, the software under test is compiled and linked against model-generated stubs for hardware interfaces, and the simulation environment provides stimuli derived from SysML sequence diagrams and use case specifications. For HIL, the hardware-in-the-loop rig replaces simulation stubs with actual hardware interfaces; the test scripts that drive the HIL rig are generated from the same SysML test case elements that produced the SIL scripts. This model-to-test continuity — which is the core value proposition of the digital thread — means that when a system requirement changes in the model, the change propagates to both the SIL simulation configuration and the HIL test scripts through the model's traceability relationships, rather than requiring manual updates to separate test plan documents. INCOSE's MBSE digital thread pilot with a US Army ground vehicle program demonstrated a 40% reduction in SIL/HIL test script maintenance effort over a two-year development period using this approach.

What organizational changes are needed to successfully adopt MBSE in a defense contractor environment?

Successful MBSE adoption in defense contractor organizations requires changes in three dimensions: skills, processes, and culture. On skills: systems engineers must be trained not just in SysML notation but in modeling methodology — how to decompose a system into the right level of granularity, how to decide which behaviors belong in the model versus in text documents, and how to maintain model consistency across disciplines. A typical MBSE training investment is 40–80 hours per systems engineer for initial proficiency, plus ongoing mentoring for the first 6–12 months. On process: the Systems Engineering Management Plan, drawing tree, data item submission schedule, and CDR/PDR entry and success criteria must be rewritten to reference model artifacts rather than document artifacts. The acquisition authority must accept model-derived views as compliance evidence — this requires coordination with the contracting officer and program manager early in the program. On culture: the most common failure mode is that engineers adopt the tool but not the discipline — they draw diagrams in the modeling tool while maintaining the real engineering information in separate spreadsheets and Word documents. Leadership must enforce the single-source-of-truth principle by refusing to accept information that exists outside the model and by measuring model coverage (percentage of requirements with at least one «satisfy» allocation) as a KPI at program reviews.

Model-based systems engineering for defense programs: SysML, digital thread and DoDAF integration

Defense programs have a systems engineering problem that scales badly. A major weapon system program — a new infantry combat vehicle, a radar upgrade, an airborne communications relay — may involve 10,000 to 50,000 individual requirements distributed across dozens of subsystems, each developed by different engineering teams and often different contractors. Requirements are written in Microsoft Word. Architecture is drawn in Visio. Interface definitions live in Interface Control Documents that are updated asynchronously by each team. Test plans reference requirement paragraph numbers that have silently changed. When an Engineering Change Proposal arrives, three engineers spend a week manually searching across fifty documents to understand what the change affects.

Model-based systems engineering (MBSE) replaces this document web with a single, semantically rich model — a structured repository of requirements, architecture elements, behavioral specifications, and traceability relationships that is the authoritative source from which all documents are generated. SysML provides the modeling language. Tools like Cameo Systems Modeler and IBM Rhapsody provide the environment. The digital thread connects the model to simulation, code generation, and test automation. DoDAF architecture views are produced as reports from the model rather than maintained as separate artifacts.

This article is a practical engineering reference for defense program managers, chief systems engineers, and software architects who are evaluating or implementing MBSE. It covers the document-centric vs model-centric contrast, SysML diagram usage for defense systems, requirements traceability in the model, the digital thread from requirements to prototype, DoDAF view generation, tool ecosystem considerations, and the organizational and governance challenges that determine whether an MBSE initiative succeeds or degrades back into document-centricity.

Why MBSE matters for defense programs

The fundamental problem with document-centric systems engineering is that documents are disconnected. A System Requirements Specification is written; an architecture description is written referencing the SRS paragraph numbers; an Interface Control Document is written referencing the architecture; a test plan is written referencing the ICD. Each document is a snapshot in time. When requirements change — and in defense programs, requirements always change — the chain of manual cross-references that keeps these documents consistent breaks. The SRS paragraph number changes and the architecture description silently references a requirement that no longer exists. The ICD describes an interface that was redesigned but never updated. The test plan verifies a behavior that was superseded by an ECP six months ago.

MBSE addresses this by making the model the single source of truth. Requirements, architecture blocks, interfaces, and behavioral specifications are all elements in the same semantic model with typed relationships between them. When a requirement changes in the model, the tool immediately reveals all architecture blocks that allocate to it, all interfaces those blocks expose, and all test cases that verify the behavior. A change impact analysis that takes a week in a document-centric program takes minutes in a well-maintained MBSE model.

The specific benefits for defense programs — as distinct from commercial software projects — arise from the program's formal review structure. The defense software development lifecycle includes System Requirements Review (SRR), Preliminary Design Review (PDR), and Critical Design Review (CDR) as contractually mandatory gates with defined entry and success criteria. MBSE changes the character of these reviews: instead of evaluating the consistency of a stack of documents, reviewers query the model for coverage metrics — what percentage of requirements have been allocated to architecture elements, what percentage of interfaces have been formally specified, what percentage of test cases have been linked to requirements. These are objective, automatable measures of engineering completeness rather than subjective document quality assessments.

Ambiguity reduction is the other major benefit. Natural-language requirements are inherently ambiguous — the same sentence can be read differently by the systems engineer who wrote it, the software engineer implementing it, and the test engineer verifying it. When a requirement must be expressed as a SysML Requirement element with a specific interface allocation, a specific parametric constraint, and a specific test case, the ambiguity is forced into the open. If the modeling team cannot agree on how to represent the requirement in the model, they have identified a genuine ambiguity in the requirement that needs resolution before implementation begins, not after.

Key metric: Programs that implement MBSE with at least 80% requirement-to-architecture allocation coverage before CDR report a 30–50% reduction in interface defects discovered during integration testing, compared to comparable document-centric programs of similar complexity (INCOSE MBSE Initiative survey data, 2022–2024).

SysML for defense systems

SysML (Systems Modeling Language) is the OMG-standard language for MBSE. It extends UML with diagram types specifically designed for systems engineering: Block Definition Diagrams, Internal Block Diagrams, Requirement Diagrams, Parametric Diagrams, and Allocation Tables. Understanding which diagram types deliver genuine value in a defense context — and which consume effort without proportionate return — is essential for a productive MBSE program.

Block Definition Diagrams (BDD) are the highest-value SysML artifact for defense systems. A BDD defines the structural taxonomy of the system: what blocks exist, what properties and operations they have, how they are specialized through generalization relationships, and what typed ports they expose for connection to other blocks. In a weapon system context, the BDD answers: what are the subsystems, what are their decomposition relationships, and what are the interface types between them? The BDD is not a drawing — it is a formal structural definition from which all downstream artifacts derive. An interface type defined on a BDD port is the authoritative specification for that interface; the ICD is a generated report from it.

Internal Block Diagrams (IBD) show how block instances are connected for a specific context. Where the BDD defines the type "Sensor Subsystem has a port of type DataLink," the IBD shows the specific DataLink connection between the Sensor Subsystem instance and the Mission Computer instance in the top-level system assembly. IBDs are the primary architecture diagram for integration engineers: they specify exactly what connects to what, through what port type, at what level of system assembly. Generated ICDs derived from IBDs are inherently consistent across subsystems — a property impossible to guarantee when ICDs are maintained independently.

Activity Diagrams model system behavior in terms of actions and control flow. In defense contexts, they are most useful for mission execution sequences (the sequence of steps from mission planning through execution through post-mission analysis), for specifying the behavior of safety-critical modes, and for defining the operational workflow that the system must support. Activity diagrams become over-elaborate when applied to low-level software algorithms — that granularity belongs in software design, not system architecture.

Sequence Diagrams model message exchanges between system components across time. They are valuable for specifying security-critical protocols (authentication handshakes, key exchange sequences), time-sensitive coordination protocols (fire control synchronization between sensor, C2, and effector), and human-system interaction sequences for safety-critical operations. Sequence diagrams are a poor choice for modeling the bulk of system behavior — the combinatorial explosion of sequence variants makes them unmaintainable at scale. Reserve them for the 5–10% of behaviors where the precise inter-component message ordering is architecturally significant.

Parametric Diagrams are uniquely valuable for defense systems where performance constraints must be allocated and tracked. A parametric diagram expresses mathematical constraints among block properties — for example, the constraint that end-to-end latency of a targeting solution is the sum of sensor acquisition latency, processing latency, and communication latency, and that the total must be less than 500ms. These constraints can be connected to simulation parameters and evaluated against actual measurements in integration testing, creating a model-driven performance verification process.

What not to model: avoid creating sequence diagrams or activity diagrams for every function in the system. Over-modeling produces a maintenance burden that exceeds the traceability benefit. Model the architecture structure exhaustively (BDD and IBD); model behavior selectively, focusing on safety-critical, security-critical, and architecturally significant interactions.

Requirements modeling and traceability

Requirements traceability is the capability that most consistently justifies MBSE investment in defense programs. The requirements management in defense software discipline has evolved from spreadsheet-based traceability matrices to model-integrated traceability where the relationships themselves are first-class model elements with semantic types.

In SysML, requirements traceability is implemented through four typed dependency relationships:

«derive» — connects a system requirement to the stakeholder need or higher-level requirement it refines. Every system requirement should have at least one «derive» relationship; a requirement without one is either unjustified or its stakeholder need has not been modeled.
«satisfy» — connects an architecture element (Block, Component, Interface) to the requirement it satisfies. This is the core traceability relationship: it answers "which part of the system satisfies this requirement?" An allocated requirement with no «satisfy» relationship is unimplemented.
«verify» — connects a test case or test procedure to the requirement it verifies. A requirement with a «satisfy» relationship but no «verify» relationship is designed but unverified — a gap that would be discovered at TRR in a document-centric program but is visible continuously in the model.
«refine» — connects a more detailed model element (such as a state machine or activity) to the requirement it elaborates. Used when the requirement is satisfied by a behavioral specification rather than directly by a structural element.

The allocation matrix — which most MBSE tools generate as an interactive report — presents requirements against architecture elements in a cross-reference table, with each cell indicating whether a «satisfy» relationship exists. This matrix replaces the manually-maintained traceability matrix spreadsheet that is the center of document-centric compliance evidence. Unlike the spreadsheet, the model-derived matrix is always current: it is regenerated from the live model, not updated by hand.

The stakeholder-to-system requirements hierarchy deserves particular attention. Defense programs receive stakeholder needs from multiple sources: the operational user (expressed in the Concept of Operations), the acquisition authority (expressed in the System Performance Specification), and derived internal requirements (expressed in subsystem ICDs and lower-level specifications). Modeling all these sources as a requirements hierarchy in SysML makes the derivation rationale explicit: a given system requirement exists because it satisfies a specific operational need, which in turn satisfies a specific mission requirement from the ConOps. When a system requirement is challenged — as happens frequently in program cost reduction exercises — the model shows exactly which operational needs would be unaddressed if the requirement were deleted, giving the chief systems engineer a structured basis for the trade-off decision.

-- SysML 2.0 textual notation: requirements hierarchy fragment
requirement def MissionCommunicationsNeed {
    doc /* The system shall maintain a communications link
         with the C2 node throughout the mission envelope. */
}

requirement def DataLatencyRequirement :> MissionCommunicationsNeed {
    doc /* End-to-end voice/data latency from source to C2
         node shall not exceed 500 ms under all conditions. */
    assume constraint { latencyBudget <= 500 [ms] }
}

requirement def LinkAvailabilityRequirement :> MissionCommunicationsNeed {
    doc /* Communications link availability shall exceed
         99.5% averaged over any 24-hour mission period. */
}

The textual SysML 2.0 notation shown above illustrates the derivation hierarchy: DataLatencyRequirement and LinkAvailabilityRequirement are specializations of the stakeholder need, inheriting its context while specifying measurable acceptance criteria. The parametric constraint (latencyBudget <= 500 [ms]) is a formal property that can be linked to simulation parameters and measured test results — not just a sentence that test engineers must interpret.

The digital thread: model-to-prototype continuity

The digital thread is the linked data chain that connects model elements to their downstream implementations and verification results. In the context of defense MBSE, the digital thread has three principal legs: model-to-code generation, model-to-test automation, and model-to-simulation.

Model-to-code generation is the most mature leg of the digital thread. IBM Rhapsody has provided C and C++ code generation from UML/SysML state machines and class diagrams for two decades. Cameo integrates with SysML-to-Ada and SysML-to-C++ transformations. The generated code is a skeleton or framework: the model specifies the interface structure, the state machine transitions, and the data types; engineers implement the computational content within generated method bodies. The value is interface consistency: if the SysML BDD specifies that a block's output port carries a struct of type TargetTrack_t with fields position, velocity, and classification, the generated header files on both sides of every interface that uses this type are identical. The class of integration defect caused by two engineers independently interpreting an ICD text description and arriving at slightly different struct layouts is structurally eliminated.

Model-to-test automation connects SysML TestCase elements to test execution frameworks. In the most mature implementations, a test case in the model specifies: the requirement it verifies (via «verify»), the inputs to the system under test (derived from the requirement's acceptance criteria), the expected outputs (derived from the requirement's shall statement), and the pass/fail criterion. From these model elements, a generator produces test scripts in the target test framework — Robot Framework for system-level testing, pytest for component-level testing, or proprietary HIL scripting languages for hardware integration. When a requirement changes, the generator re-runs and flags test cases whose expected outputs are now inconsistent with the updated requirement, rather than waiting for a human to notice the discrepancy at TRR.

Model-to-simulation (MBSE + SIL/HIL) is the leg of the digital thread with the highest potential value and the highest implementation complexity. SysML parametric diagrams define the mathematical structure of the system's performance model — which physical parameters constrain which performance properties, expressed as constraint blocks. These constraint blocks can be linked to Simulink or Modelica simulation models through MBSE tool integrations (Cameo-MATLAB integration, Rhapsody-Simulink co-simulation). The result is a simulation configuration that is derived from the architecture model rather than maintained in parallel with it.

The practical maturity of this integration varies significantly. Model-to-Simulink parameter synchronization is well-supported by major MBSE tool vendors. Full model-to-HIL test automation — where changing a SysML requirement propagates through the model to updated HIL test scripts without manual intervention — requires significant integration engineering effort and is achieved by fewer than 15% of defense programs that claim MBSE adoption (per INCOSE survey data). The programs that achieve it report the most dramatic reductions in integration test cycle time, typically 35–50% shorter integration phases compared to document-centric baselines of similar system complexity.

The connection between MBSE and formal verification for defense software is through the digital thread: SysML behavioral models (state machines, activity diagrams) can be translated to formal specification languages (TLA+, SPIN Promela) for model checking, providing mathematical evidence of behavioral correctness that supplements the structural traceability the MBSE model provides.

DoDAF architecture views from the model

The Department of Defense Architecture Framework (DoDAF) version 2.02 defines the mandatory architecture viewpoints that defense acquisition programs must produce for capability portfolio management and system-of-systems interoperability assessment. In document-centric programs, DoDAF views are produced as standalone Visio diagrams or PowerPoint slides, updated manually before each program review, and chronically out of sync with the engineering model that represents the actual system design.

MBSE eliminates the manual DoDAF production effort by making DoDAF views generated outputs of the engineering model. The mapping from SysML model elements to DoDAF data elements is standardized in the Unified Profile for DoDAF and MODAF (UPDM), which is supported as a plugin or native profile in all major MBSE tools.

The key DoDAF-to-SysML mappings for defense programs are:

OV-1 (High-Level Operational Concept Graphic) — derived from the system's top-level use case diagram combined with context-level activity diagrams showing the operational environment. In the model, the operational environment actors, their interactions with the system, and the mission phases are represented as use case and actor elements; OV-1 is a styled rendering of these elements in operational context rather than engineering notation.
OV-2 (Operational Resource Flow Description) — derived from IBD connectors annotated with operational information types. When IBD connector types include operational semantics (a connector carries "tactical targeting data" rather than just a data type name), the OV-2 is auto-generated from the connector set filtered by operational flow annotation.
SV-1 (Systems Interface Description) — derived directly from the top-level system IBD showing physical block instances and their connections. This is the most straightforward DoDAF-from-model generation: the SV-1 is essentially the system IBD rendered with DoDAF-compliant iconography and legend.
SV-4 (Systems Functionality Description) — derived from the system's activity model, showing which functions are performed by which system nodes. In SysML, this is the allocation of activity elements to block instances, represented in allocation tables that map directly to SV-4 content.
TV-1 (Technical Standards Profile) — derived from the model's standard elements, where applicable standards (MIL-STD-1553, Link 16, STANAG 4586) are attached as tagged values or stereotype properties to the interface and block elements that implement them.

Auto-publishing to a DoDAF data repository — such as the DoDAF Architecture Registry, an enterprise architecture tool, or a program-specific SharePoint/Confluence repository — is supported through MBSE tool scripting APIs. A nightly automated job can regenerate all DoDAF views, publish them to the architecture repository, and timestamp the publication so that reviewers know the views represent yesterday's model state. This is a qualitative improvement over DoDAF views maintained by a dedicated architect who updates them before reviews — the model-derived views are always current, and their content is traceable to engineering model elements rather than to the architect's interpretation of the design.

Program impact: A US Army ground vehicle modernization program that implemented SysML-to-DoDAF automated view generation reported eliminating 2,400 person-hours of manual DoDAF production effort per program year — the equivalent of one full-time systems engineer dedicated exclusively to architecture documentation, replaced by a nightly generation job.

MBSE tool ecosystem for defense

The defense MBSE tool ecosystem has three principal options, each with distinct strengths that map to different program contexts.

Cameo Systems Modeler (Dassault Systèmes, formerly No Magic) is the dominant MBSE tool in the US defense market. Its strengths are comprehensive SysML 1.x compliance, mature DoDAF/UPDM profile support, a rich plugin ecosystem including Cameo Simulation Toolkit for parametric simulation, and Teamwork Cloud for scalable multi-user collaborative modeling with fine-grained access control. Cameo is used by most US prime contractors on major acquisition programs. Its weaknesses are cost (enterprise licenses are expensive), a steep learning curve for engineers without prior modeling experience, and limited native support for the SysML 2.0 textual notation (expected in 2026–2027 release cycle). For programs where DoDAF compliance and US prime contractor interoperability are primary requirements, Cameo is the default choice.

IBM Rhapsody is the tool of choice when model-driven code generation is a primary program deliverable. Rhapsody's code generation from UML/SysML state machines is the most mature in the industry, and its integration with IBM Rational DOORS for requirements management via IBM Systems Design Rhapsody Model Manager creates a mature traceability pipeline from DOORS requirements to Rhapsody model elements to generated code. Rhapsody is the primary tool for embedded avionics software development on programs where the modeling team generates the bulk of the software skeleton from the model and engineers complete the implementations within generated frameworks. Its DoDAF support is less mature than Cameo's, and its SysML parametric support is weaker. For programs with a strong embedded software model-to-code mandate and existing IBM toolchain investment, Rhapsody is the appropriate choice.

Capella is an open-source MBSE tool developed by Thales and now maintained under the Eclipse Polarsys project. Capella uses the ARCADIA modeling method rather than SysML — its viewpoint hierarchy (Operational Analysis, System Analysis, Logical Architecture, Physical Architecture) does not directly correspond to SysML diagram types but maps naturally to the defense acquisition lifecycle phases. The ARCADIA method has a disciplined sequence of architecture elaboration that guides modeling teams through the correct order of modeling decisions, which reduces the methodological ambiguity that plagues SysML-based programs where the tool provides capability but not method guidance. Capella has zero license cost, making it accessible for programs with constrained budgets, smaller contractors, and academic/training contexts. Add-ons provide DoDAF view generation and Simulink/FMI co-simulation. For European defense programs — particularly those in the French and UK defense industrial base where Thales influence is strong — Capella is increasingly the standard.

Tool qualification for safety-critical development is a consideration that applies regardless of tool choice. Any MBSE tool feature used to generate artifacts that are treated as compliance evidence — generated code, generated test scripts, generated verification reports — must be qualified under DO-330 (for airborne programs) or the program's applicable software tool qualification standard. Tool qualification is not typically required for the modeling and traceability features of MBSE tools, because engineers review the generated views before use. It is required when the tool output is used without independent review — specifically, for code generators and test script generators that are claimed as DO-178C tool credit.

Tool	Primary strength	DoDAF support	License model	Best fit
Cameo Systems Modeler	SysML compliance, DoDAF/UPDM, collaboration	Mature (UPDM plugin)	Commercial (high cost)	US DoD acquisition programs, prime contractors
IBM Rhapsody	Model-to-code generation, embedded systems	Moderate	Commercial (high cost)	Embedded avionics, software-intensive systems
Capella (Eclipse)	ARCADIA method, zero license cost	Via add-on	Open source (free)	European defense, budget-constrained programs

Adoption challenges and lessons learned

MBSE adoption in defense programs fails more often from organizational factors than from technical ones. The tools are mature, the methods are well-documented, and the ROI evidence is substantial. What derails MBSE programs is organizational resistance, model governance failure, and the inability to measure and demonstrate ROI in a way that sustains management commitment through the initial overhead period.

Organizational resistance to modeling takes two forms. The first is skills-based: systems engineers trained in Word-and-Visio document production do not automatically become proficient MBSE modelers after a two-day SysML course. They know the notation but not the method — they do not know how to decompose a system into the right blocks, how to decide what belongs in a behavioral model versus what belongs in a text requirement, or how to maintain model consistency as the design evolves. Adequate MBSE training is 40–80 hours per engineer for initial proficiency, plus 6–12 months of mentoring on the first program. Programs that skip this investment and expect engineers to self-teach from tool documentation consistently produce models that are structurally correct but methodologically wrong — diagrams in the modeling tool that have no traceability relationships and therefore provide none of the change impact analysis value that justifies the tool investment.

The second form of resistance is cultural: senior engineers who have delivered successful programs using document-centric methods perceive MBSE as overhead imposed by management rather than as a capability that makes engineering easier. This perception is not entirely wrong in the short term — the first 6 months of MBSE on a new program genuinely are more overhead than the document-centric equivalent, because the model infrastructure (governance, tools, repositories, templates) must be built while engineering work proceeds. The ROI becomes positive at the first major ECPcycle, typically 12–18 months into a program, when change impact analysis on the model takes hours instead of weeks. Programs that abandon MBSE before reaching this inflection point carry the cost without receiving the benefit.

Model governance failure is the most common technical cause of MBSE program failure. Without defined model ownership, model element naming conventions, a baseline schedule tied to program milestones, and a CCB process for controlled model elements, the model accumulates local variations. Engineers create their own packages to avoid coordination overhead. The "authoritative" model diverges from the engineering reality that is actually being designed. Within 18 months, the program is effectively document-centric again — engineers maintain the real design in separate documents and update the model before program reviews to satisfy contractual requirements.

Effective model governance requires explicit definition of: who owns each model package (by name, not just by role), what approval is required to change a baselined element, how the model baseline schedule aligns with PDR/CDR, and what model coverage metrics are reported at each program review. These policies must be documented in the SEMP and enforced by program leadership — the Chief Systems Engineer must treat an unapproved change to a baselined model element with the same severity as an unapproved change to a CDR-baselined drawing.

MBSE ROI measurement is a persistent challenge because the benefits are largely the avoided cost of problems that do not happen. The interface defects that the model's type-consistent IBD prevented were never discovered — their absence is invisible. The requirements orphans that model consistency checks caught before CDR never became CDR discrepancies — so there is no line item in the program metrics that shows the cost they would have caused. Programs that successfully demonstrate MBSE ROI do so by establishing baselines before MBSE implementation and measuring specific metrics afterward: ECP change impact analysis hours per ECP, interface defects discovered during integration test per interface, DoDAF production hours per major review, and CDR entry discrepancies per requirement count. Without pre-MBSE baselines for these metrics, the ROI argument relies on industry benchmarks rather than program-specific evidence — and that argument is less persuasive to program managers whose budget pressure is immediate and concrete.

The programs that consistently achieve positive MBSE ROI share three characteristics: they start MBSE at program inception rather than retrofitting it onto an existing document-centric program; they invest in model governance infrastructure before modeling begins rather than discovering governance gaps at PDR; and they measure and report model coverage metrics (requirement allocation coverage, interface formalization rate, test linkage rate) at every program review, making the model's engineering completeness as visible as the schedule and budget.

MBSE is not a software tool — it is an engineering discipline that happens to be enabled by software tools. Defense programs that understand this distinction, invest in the organizational change it requires, and maintain governance discipline throughout the program lifecycle consistently find that the digital thread from stakeholder need to verified system performance is worth the investment.