Core MBSE Elements

The Building Blocks That Transcend Language

Regardless of whether you use SysML v1, SysML v2, Arcadia/CAPELLA, AADL, OPM, or something else entirely, MBSE deals with the same core concepts. The names differ — SysML calls them "blocks," CAPELLA calls them "components," OPM calls them "objects" — but the underlying concepts are universal. These are the building blocks of every system model.

Understanding these elements at the conceptual level, independent of any specific notation, is what makes you a practitioner who can work across languages and tools rather than a user who is locked to one.

Structure: What the System Is Made Of

Structure captures the composition of the system — what components exist, what properties they have, and how they relate to each other.

Components (blocks, parts, objects). The fundamental structural elements of the model. A satellite might decompose into a bus, a payload, a power subsystem, a communications subsystem, and an attitude control subsystem. Each of these is a structural element with its own properties (mass, power consumption, dimensions, operating temperature range) and its own internal decomposition.

Composition relationships. The "part-of" hierarchy. The power subsystem is part of the satellite. The solar array is part of the power subsystem. The solar cell is part of the solar array. Composition is not optional — it defines what "the system" is at every level of abstraction.

Association relationships. Connections that are not composition. The communications subsystem communicates with the ground station. The attitude control subsystem uses data from the star tracker. These are structural relationships that define how elements interact without implying ownership.

Generalization relationships. Type hierarchies. A "sensor" is a general type; a "temperature sensor" and a "pressure sensor" are specializations that inherit the general sensor's properties and add their own. Generalization enables reuse — define properties once at the general level, specialize where needed.

Structure is the skeleton of the model. Everything else — behavior, requirements, interfaces, parametrics — attaches to structural elements.

Behavior: What the System Does

Behavior captures how the system responds to inputs, conditions, and events. It answers: "What happens when X?"

Functions and activities. The things the system does — sense, process, transmit, control, display. Functions are described in terms of their inputs, outputs, and transformations. An activity diagram or functional flow models the sequence and concurrency of these functions.

States and transitions. The modes the system can be in and the events that cause it to move between them. A spacecraft might have states: launch, orbit insertion, nominal operations, safe mode, end of life. Each state has different active behaviors, different power profiles, and different constraints. State machines model this — and for safety-critical systems, the state model is often the most important behavioral artifact because being in the wrong state can be catastrophic.

Interactions. How components communicate and coordinate. When the ground station sends a command, what sequence of messages flows through the system? What component processes the command, what components are affected, and in what order? Interaction models (sequence diagrams in SysML, functional exchanges in CAPELLA) capture this temporal choreography.

Behavior is where the system comes alive in the model. Structure says "here are the pieces." Behavior says "here is what they do."

Requirements: What the System Must Satisfy

Requirements in MBSE are not paragraphs in a document — they are typed, attributed model elements with formal relationships to other model elements. This is a direct connection to DGTLENG 104 (Requirements Engineering in DE), where requirements-as-data is a foundational concept.

Requirement elements. Each requirement has an identifier, a text statement, a type (functional, performance, interface, environmental, safety), attributes (verification method, priority, status), and a lifecycle state. These are not free-text annotations — they are structured data.

Relationships. Requirements connect to the rest of the model through typed relationships:

• Satisfies: Component X satisfies requirement Y (the design-to-requirement link)
• Verifies: Test Z verifies requirement Y (the test-to-requirement link)
• Derives: Requirement Y derives from stakeholder need N (the parent-child link)
• Allocates: Requirement Y is allocated to subsystem S (the responsibility link)

These relationships are what make traceability structural rather than manual. When a requirement changes, the model can identify every component that satisfies it, every test that verifies it, and every parent need it derives from — automatically, through relationship traversal.

Interfaces: How Components Connect

Interfaces define what crosses component boundaries — data, energy, material, signals. This is where DGTLENG 103 (Systems Thinking) connects, because interfaces are where the system's emergent behavior arises from the interactions of its parts.

Ports. Defined interaction points on a component. A port specifies what can flow in or out — a data type, a signal, a physical quantity. Ports make interfaces explicit: instead of vaguely saying "these two components communicate," you define the port on each component and the type of what flows between them.

Flows. What actually moves between ports — data items, energy quantities, material flows, control signals. Flows have types, directions, and rates. They are the substance of the interface.

Protocols. The rules governing the exchange. Handshaking sequences, timing constraints, error handling. Not every MBSE language models protocols at the same level of detail, but the concept is universal: interfaces are not just what flows, but how it flows.

Well-defined interfaces in the model are the first defense against integration failures. If two teams develop components against the same interface model, the components connect. If the interfaces are ambiguous or undocumented, integration is where you discover the gaps — and discovery at integration is expensive.

Parametrics: Mathematical Relationships Between Properties

Parametrics capture the mathematical constraints that govern the design space. They answer: "Given the properties of the parts, what is the property of the whole?"

Constraint expressions. Equations that relate properties: total system mass equals the sum of component masses. Power budget: total power consumption must not exceed power generation capacity. Thermal balance: heat generated must not exceed heat dissipated. These are not simulation — they are algebraic relationships that can be evaluated to check design consistency.

Bound parameters. Constraint expressions reference properties defined on structural elements. The mass property of each component block feeds into the total mass constraint. When a designer updates a component's mass, the parametric constraint can be re-evaluated to check whether the system-level budget is still met.

Parametrics are where the model starts doing quantitative work. They enable trade studies (if I increase the battery capacity, does the mass budget still close?) and design verification (does the current design satisfy all budget constraints?). They are building blocks that become more powerful in DGTLENG 202 (Digital Twins) and 205 (Automated Pipelines), where parametric models feed into simulation and automated checking.

Traceability: The Relationships Between Elements

Traceability is not a separate element type — it is the web of relationships that connects all the other elements. A requirement is allocated to a component (structure), satisfied by a behavior, verified by a test (itself a model element), and constrained by parametric relationships.

This web is what makes the model more than a collection of independent diagrams. It is what enables:

• Impact analysis: "If I change this interface, what requirements are affected? What tests need to be re-run?"
• Coverage analysis: "Are there requirements with no design allocation? Components with no requirements? Tests that verify nothing?"
• Completeness checking: "Does every requirement have a verification method? Does every interface have a defined protocol?"

Traceability in the model connects directly to the digital thread concept from DGTLENG 105. The system model, with its internal traceability, is a primary node in the digital thread. The thread extends the model's traceability outward — connecting to simulation data, test results, operational telemetry, and supplier information that lives outside the model.

The Model Is Not the Diagram

This point bears repeating because it is the single most common source of confusion for MBSE newcomers.

The model is a database of elements and relationships. It is structured data. It is queryable, traversable, and computationally accessible.

Diagrams are views — visual projections of subsets of the model, created for specific communication purposes. A block definition diagram shows some structural elements and their relationships. A sequence diagram shows some interactions. A requirements diagram shows some requirements and their traces. None of these diagrams IS the model. All of them are generated FROM the model.

Diagrams are disposable. Delete them and the model elements still exist. The model is the asset. Diagrams are presentation.

This distinction matters practically: when you are "building the model," you are creating and relating elements in the model repository. When you are "creating a diagram," you are choosing which existing elements to display and how to lay them out visually. Both are useful, but they are different activities, and the first is where the engineering value lives.

Assessment