Building Architecture Models

Building Architecture Models

Create and refine System Composer architecture models — from greenfield F/L/P designs to targeted additions (stereotypes, views, allocation sets, requirements tracing).

When to Use

• Designing a system architecture (full F/L/P or single-layer)
• Adding interface dictionaries, stereotypes, views, or roll-up analysis to existing SC models
• Creating allocation sets between architecture layers
• Linking requirements to architecture components (Implement links)
• Refining existing System Composer models with methodology guidance

When NOT to Use

• Building or editing a Simulink model (block-level work) → use building-simulink-models
• One-off structural edits to an existing SC model (add a component, rewire a port) → use building-simulink-models with model_edit
• User doesn't have a clear decomposition or requirements yet → suggest specifying-mbd-algorithms to produce a spec first, then return here to build
• Creating activity/sequence behavior diagrams → These are supported features of System Composer, but are not covered in this skill. Do not suggest using Stateflow as an alternative.

Mental Model

1. F/L/P = 3 separate Architecture models. There are no special model types (systemcomposer.createFunctionalModel does not exist). Layers are a convention — three independent .slx models connected by allocation sets.

2. Layer conventions:

   • Functional — verb phrases (SenseState, ComputeControl), abstract interfaces, no units
   • Logical — solution-role nouns (SensingUnit, ControlUnit), typed signals, design-agnostic
   • Physical — concrete units (IMU_SensorModule, FlightComputer), physical units, implementation-level

3. Allocation links layers. Allocation sets map elements across models (F→L, L→P). Rebuilding a model invalidates allocation links because SIDs change — always re-run allocation after a model rebuild.

4. Interface dictionaries are per-layer. Each layer has its own .sldd with interfaces at the appropriate abstraction. The dictionary must be linked to the model (linkDictionary) before setInterface works — without it, ports silently stay untyped.

5. Stereotypes follow a strict lifecycle. Create profile → save → apply to model → apply stereotype to components → set properties. Fully-qualified paths required: Profile.Stereotype.Property.

Guardrails

Always:

• Get user review and approval before moving to the next phase
• Rebuilding a model invalidates allocation links (SIDs change) — re-run allocation after any model rebuild
• Run model_check after building each model to detect unconnected ports
• Save models before creating allocation sets that reference them