Building and Using System Models

The Model Serves Different Purposes

Not all system models deliver the same value. The difference is not in the language or the tool — it is in how the model is built, maintained, and connected to engineering practice. There are three levels of model utility, and understanding where your model sits on this spectrum is essential for making investment decisions.

Model as Documentation

At the lowest level of utility, the system model captures design decisions and serves as a reference. It replaces static documents — requirements specifications, interface control documents, architecture descriptions — with a structured, queryable representation. This is better than documents because the information is structured and traceable rather than scattered across prose. But the model is passive. Engineers consult it, but it does not do work.

What it enables:

• Structured storage of engineering information (components, requirements, interfaces)
• Traceability queries ("which requirements are allocated to subsystem X?")
• Automated generation of documents and reports from the model (instead of maintaining documents separately)
• Consistency within the model — if an interface changes, all views update

What it does not enable:

• The model does not execute. Behaviors are described, not simulated.
• The model does not connect to external tools. Data must be manually transferred to simulation, test, and analysis environments.
• The model reflects the past (captured decisions) but does not actively support the present (current trade studies, ongoing analysis).

Many organizations plateau at this level — and it still represents a significant improvement over document-based practice. But it leaves most of MBSE's potential unrealized.

Model as Executable

At the medium level of utility, the model does work. Behaviors can be simulated: state machines can be executed to check whether the system transitions correctly under all conditions. Activity models can be run to verify functional flow. Parametric constraints can be evaluated to check whether budgets close.

What it enables:

• Behavioral simulation — run state machines, execute activity flows, animate sequences to validate design logic before any hardware or code exists
• Parametric evaluation — automatically check mass budgets, power budgets, link budgets, and other constraint equations as design parameters change
• "What if" analysis — change a parameter and see the cascading effect through the model's constraint network
• Early defect detection — find logical errors, missing transitions, constraint violations, and interface mismatches in the model before they become hardware problems

What changes in practice:

• Design reviews shift from "reviewing a document" to "running the model" — demonstrating behavior, stepping through scenarios, evaluating constraints
• Trade studies become model-driven — rather than building separate analysis spreadsheets, trades are evaluated within the model's parametric framework
• The model becomes a working artifact that engineers interact with regularly, not a reference they consult occasionally

Model as Integration Hub

At the highest level of utility, the model connects to the broader engineering ecosystem. It is not a standalone artifact — it is a node in the digital thread, with bidirectional connections to simulation tools, requirements databases, test management systems, configuration management, and operational data.

What it enables:

• Requirements changes in the model propagate automatically to test management (triggering test case updates)
• Simulation tools read design parameters from the model via API and write results back, keeping the model current with analysis results
• Automated consistency and completeness checks run against the model in a CI/CD-like pipeline — every model change is validated against rules
• Operational data feeds back into the model, enabling comparison of as-designed to as-built to as-operated
• The model becomes the single source of truth that multiple tools and disciplines reference

What changes in practice:

• The model is not maintained by one systems engineer — it is contributed to by multiple disciplines, each responsible for their domain within the model
• Model quality is enforced by automation (like code quality in software), not just by peer review
• The model is versioned, branched, and merged like code — especially with SysML v2's textual notation
• The boundary between "the model" and "the digital thread" blurs — the model IS part of the thread

This is where MBSE delivers its full value, and it is the direction that courses 202-206 build toward.

Practical Patterns for Building Models

Regardless of which level you are targeting, certain patterns consistently lead to more useful models.

Start with Structure

Begin by answering: what are the pieces, and how do they compose? Identify the top-level system, its major subsystems, and their composition relationships. Do not try to model everything at once — start at the level of abstraction where decisions are being made. If you are in concept exploration, model at the subsystem level. If you are in detailed design, model at the component level.

Structure is the scaffold on which everything else hangs. Without it, behavior has no home, requirements have nothing to allocate to, and interfaces have no endpoints.

Add Behavior for Key Scenarios

Once structure exists, model the behavior for the scenarios that matter most — the critical operational scenarios, the failure modes, the key use cases. You do not need to model all behavior. Focus on scenarios that:

• Drive architectural decisions ("we need a separate processor for this function because of its real-time constraints")
• Involve multiple subsystems interacting ("what happens during the handoff between these two subsystems?")
• Have safety or mission-critical implications ("what happens when the primary system fails?")

Link Requirements

Connect requirements to the structural and behavioral elements that satisfy them. This is where traceability becomes real. Every requirement should have at least an allocation (which component is responsible) and a verification method (how you will prove satisfaction). Requirements without allocations are orphans. Components without requirements are either scope creep or missing requirements.

Add Interfaces

Define what crosses component boundaries — the ports, flows, and protocols that connect subsystems. Interface definition is where integration risk lives. The earlier and more precisely you model interfaces, the fewer surprises you face at integration.

Add Parametrics for Key Constraints

Model the mathematical relationships that constrain the design — mass budgets, power budgets, performance equations, thermal balances. These enable quantitative trade studies and automated budget checks. Do not try to turn the model into a simulation — keep parametrics at the algebraic constraint level and connect to dedicated simulation tools (via integration) for high-fidelity analysis.

Anti-Patterns to Avoid

Over-Modeling

Trying to model everything at full fidelity from the start. This leads to months of modeling before any engineering value is extracted, creates models so large that they are difficult to maintain and navigate, and often produces a model that is precisely wrong rather than usefully approximate.

The remedy: Model at the level of fidelity your current decisions require. A concept-phase model should be coarse. A detailed design model should be precise where precision matters (interfaces, critical behaviors, key constraints) and approximate everywhere else.

Diagram-Driven Modeling

Creating visually appealing diagrams without building the underlying model. This happens when the team treats MBSE as "drawing system diagrams" rather than "building a structured model." The result: pretty pictures with no underlying data structure, no traceability, no queryability, and no reuse. Change a component name and every diagram must be manually updated because there is no shared model element.

The remedy: Build the model first. Create diagrams to communicate specific aspects of the model to specific audiences. If a diagram does not trace to model elements, it is a drawing, not a model view.

Solo Modeling

One person builds the model; everyone else views or ignores it. The model captures one engineer's understanding, not the team's shared understanding. It becomes stale when the solo modeler moves on or is overloaded. Other engineers do not trust it because they did not contribute to it.

The remedy: Model collaboratively. Multiple engineers contribute to their domains within the model. Design decisions are captured in the model during the meeting where they are made, not afterward by a lone modeler. The model is a team artifact, not a personal project.

Tool Worship

Believing that the tool IS the model — that buying the right tool constitutes practicing MBSE. Spending months evaluating, procuring, and deploying a tool, then expecting MBSE to "happen" because the tool is available. The tool is an enabler, not a practice. MBSE requires methodology, governance, training, and cultural change — none of which come in the box.

The remedy: Invest at least as much in methodology, training, and practice definition as in tooling. Define what you will model, who will model it, how models will be reviewed, and how models will connect to decisions — before you select a tool.

Assessment