/mbse-architecture

name: mbse-architecture
description: Use this skill for the architecture phases of an MBSE workflow in MATLAB, when writing idempotent buildXxx.m scripts that produce a three-layer RFLPV architecture (Functional, Logical, Physical) with interface dictionaries, stereotype profiles, allocation sets, and requirements Implement links. Trigger for defining stereotype properties, functional-to-logical / logical-to-physical allocation, mapping requirements to components via slreq Implement links, or running quantitative roll-up analysis on the architecture. Do NOT trigger for ad-hoc structural edits to an already-built System Composer model (adding one component, rewiring a port) — use `building-simulink-models` with `model_edit` for that. Works alongside the `system-composer` skill for detailed SC API patterns.
license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md
metadata:
  author: MathWorks
  version: "1.0"

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:

| Model | Layer | Answers | Interface style | |---|---|---|---| | `MyFunctional.slx` | F — Functions | What does the system *do*? | Abstract flows, solution-neutral | | `MyLogical.slx` | L — Logical | What *kind* of element solves it? | Typed signals, design-agnostic | | `MyPhysical.slx` | P — Physical | *How* is it built? | Concrete fields, physical units |

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`](../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`](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`](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`](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
• `Simuli