MBSE Architecture, Allocation & Analysis (Phases 3–6)

See the system-composer skill for the full System Composer API reference (interfaces, ports, connections, auto-layout). This skill covers the MBSE-specific decisions and patterns layered on top, plus allocation and analysis.

For analysis details see references/analysis.md (prose) plus code/myRollupAnalysis.m and code/runMyAnalysis.m (templates).

When to defer to building-simulink-models / model_edit

This skill produces reusable idempotent build scripts — the whole three-layer architecture, its interface dictionaries, profile, and allocation sets, built from scratch in one buildAll() run. That is its sweet spot.

For one-off edits to an already-built SC model — adding a single SubSystem to explore a variant, tweaking one port name, renaming a component — prefer SATK's building-simulink-models with the model_edit MCP tool. model_edit handles autolayout, undo, and error recovery automatically and is faster for interactive tweaks.

Once the MBSE model is in a state where you need to round-trip it through buildPhysical.m etc. again (for example because you added a stereotype property or changed an allocation), go back to this skill — the buildXxx.m scripts will rebuild from scratch and all of model_edit's ad-hoc changes will be overwritten. That is intentional: the build scripts are the source of truth.

Never mix the two in one script. The two skills use different System Composer API layers (architecture-modeling vs. block-diagram). See the system-composer skill's "When to use this skill vs. building-simulink-models" section for the API-layer differences.

Three-Model Architecture (RFLPV)

The MBSE workflow uses three separate System Composer models, one per layer:

Each model has its own interface dictionary at the appropriate abstraction level. All three dictionaries are independent — no model script depends on another being open.

Build order: Functional first, Logical second, Physical third.

These three models are structural views. For a behavioral companion (message sequences across components for a specific scenario), attach a System Composer Interaction to the Logical model — see system-composer/SKILL.md#sequence-diagrams. The Logical layer is the natural home because it's stable across Physical-layer variant trade studies.

The Logical layer is the key distinction from classic RFLP. Logical components are design-agnostic solution principles (e.g., SensingUnit, ControlUnit, ActuationUnit) — they commit to what kind of element is needed without specifying vendor, geometry, or implementation. Physical components are the actual realization.

Functional architecture model (MyFunctional.slx) — build first

What the system does — logical functions and the abstract information flows between them. Creates and owns the functional interface dictionary.

See code/buildMyFunctional.m for the full parameterized function:

buildMyFunctional(modelName, dictFile, archDir)

Logical architecture model (MyLogical.slx) — build second

What kind of element solves each function — solution principles without physical commitment. Creates and owns the logical interface dictionary.

See code/buildMyLogical.m for the full parameterized function:

buildMyLogical(modelName, dictFile, archDir)

Naming guidance for logical components: Use nouns that describe the role of the solution element, not the specific hardware. Good: SensingUnit, ControlUnit, ActuationUnit, PowerConverter. Avoid hardware brand names or part numbers — those belong in the Physical layer.

Interface guidance: Logical interfaces sit between functional (abstract flows) and physical (hardware-spec signals). Include typed fields with semantic meaning but without datasheet-level specifics — no voltage ranges, baud rates, or tolerance values.

Physical architecture model (MyPhysical.slx) — build third

What the system implements — hardware/software components, physical interfaces, and stereotype properties. Creates and owns the physical interface dictionary.

See code/buildMyModel.m for the full parameterized function:

buildMyModel(modelName, dictFile, archDir)

Key gotchas:

• modelName must be a double-quoted MATLAB string so char(modelName) + ".slx" concatenates; single-quoted char + char does arithmetic
• addpath(archDir) before createDictionary and createModel — SC resolves files via MATLAB path
• Simulink.data.dictionary.closeAll("-discard") before creating a new dictionary — stale handles from a prior run block createDictionary
• Re-fetch interfaces after dict.save() before calling setInterface — handles become stale across a save
• Before deleting a file that is tracked in a MATLAB project, call removeFile(proj, filePath) first. A bare delete() removes the file from disk but leaves a broken reference in the project, which causes health check failures. Pattern:

proj = currentProject();
removeFile(proj, fullfile(archDir, 'OldFile.sldd'));  % untrack first
delete(fullfile(archDir, 'OldFile.sldd'));             % then remove from disk

If the file no longer exists on disk (already deleted) but is still tracked, call removeFile without delete. If no project is open, currentProject() errors — guard with matlab.project.rootProject() if needed.

Component Naming and Domains

Group components by domain — makes the architecture readable and informs interfaces:

% Computation
flightComputer = addComponent(arch, 'FlightComputer');

% Sensing
sensorSuite    = addComponent(arch, 'SensorSuite');

% Actuation
actuatorSystem = addComponent(arch, 'ActuatorSystem');

% Power
powerSystem    = addComponent(arch, 'PowerSystem');

Stereotype Properties — Set Up in the Architecture Script

Define and apply stereotypes at the end of buildMyModel() so property estimates travel with the model and survive every rebuild.

The stereotype can capture any engineering properties relevant to the project — mass, power, cost, reliability, latency, data rate, etc. Choose property names and units based on what decisions the project needs to support.

Naming: Name the stereotype after what the component is or what you are characterizing, not the analysis activity. Good examples: FlightProperties, HardwareProperties, ComponentCharacteristics. Avoid generic names like BudgetProperties — they imply the stereotype is only for budgeting, when in practice it often carries performance, reliability, and other attributes too.

profileName = 'MySystemProfile';
profileXml  = fullfile(archDir, [profileName, '.xml']);

systemcomposer.profile.Profile.closeAll();
profileFile = fullfile(archDir, [profileName, '.xml']);
if isfile(profileFile), delete(profileFile); end
if isfolder(profileFile), rmdir(profileFile, 's'); end   % clean up old bad saves

profile = systemcomposer.profile.Profile.createProfile(profileName);
st = addStereotype(profile, 'ComponentProperties', AppliesTo="Component");
addProperty(st, 'Mass_kg',         Type="double", Units="kg", DefaultValue="0");
addProperty(st, 'PowerEstimate_W', Type="double", Units="W",  DefaultValue="0");
addProperty(st, 'PowerBudget_W',   Type="double", Units="W",  DefaultValue="0");
addProperty(st, 'PowerMargin_W',   Type="double", Units="W",  DefaultValue="0");  % computed

% CRITICAL: pass the FOLDER, not