Simulink interfaces against the architecture

The problem this solves

The architecture says a signal flows one way and the implementation says the other, or one says newtons and the other says nothing at all. Nobody compares them line by line because it means opening two tools and reading a hundred rows, so the mismatch survives until two subsystems are wired together.

How it works

Where the block diagram and the architecture disagree about a signal, before integration finds it. Ports, bus elements, types, units, ranges and directions compared both ways, with the matching shown per item and inherited types recorded as unknown rather than as agreement.

What you need

An existing Simulink model, and the MATLAB MCP server connected. Strictly read-only on both sides: the model is loaded to inspect it, never modified, never re-saved, and closed as it was found.

You are comparing the interfaces of a Simulink model against the
interfaces in the Dalus model [model name], through the MATLAB MCP
server, and reporting where the architecture and the implementation
disagree. Signal names, data types, units, ranges and directions drift
between the two constantly, and the drift is usually found at
integration.

THIS WORKFLOW IS STRICTLY READ-ONLY on both sides. Load the Simulink
model to inspect it; never modify it, never re-save it, never change
its configuration, and close it as you found it. Use query calls only.

CHECK THE CONNECTION FIRST: start MATLAB or connect to the running
session, report the release and the installed toolboxes, and confirm
the Simulink model loads. If it fails to load, report the error and
stop rather than reporting on a partially loaded model. Confirm the
Dalus model is reachable.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Simulink model or subsystem, and its path; which Dalus element it
corresponds to, since the mapping between an architecture part and a
Simulink subsystem is rarely inferable; the scope (top level only, or
named subsystems); and whether a data dictionary or bus definition
file holds the interface definitions, since that is often the real
source rather than the block diagram. Ask anything else in the same
message. Then begin.

READ THE SIMULINK SIDE by querying the model: inport and outport
blocks with names, data types, dimensions and sample times; bus
objects and their elements with types, units, minimums and maximums;
signal names on the boundary; any data dictionary or workspace
definitions backing them. State which sources you used. If the
interface is defined in more than one place and those places disagree,
report that before comparing anything, because the implementation
disagreeing with itself is a finding of its own and it invalidates
every comparison built on top of it.

SAY WHAT YOU COULD NOT READ. Where a signal's type resolves to
inherited, where a unit is absent, or where a query returned nothing
usable, record it as unknown rather than as a value. An unknown
compared against a stated value is never agreement.

READ THE DALUS SIDE: the ports and connections of the corresponding
element, the flows with types, units and directions, the interface
requirements constraining them with IDs, and the ranges those
requirements state.

MATCH BEFORE COMPARING, AND SHOW THE MATCHING. Names rarely correspond
exactly across an architecture and an implementation. State per item
how the match was made: identical name, documented alias, position in
a bus, or inferred from type and direction. Mark inferred matches as
such. Items you cannot match go in their own lists and are never
forced into pairs, because a false pairing produces a false
disagreement, and false disagreements are how a report like this gets
ignored after its first outing.

COMPARE AND CLASSIFY:
- AGREES: same name, type, direction and units. Counted, not listed,
  unless asked.
- DIRECTION MISMATCH: the architecture says a signal flows one way
  and the implementation the other. These lead the report; they are
  the integration-day failures.
- TYPE OR WIDTH MISMATCH: including float against fixed-point, and
  scalar against vector.
- UNIT MISMATCH OR MISSING UNIT: including the very common case where
  the architecture states a unit and the Simulink signal carries
  none. Report that as its own class, since it is usually systemic
  rather than a one-off.
- RANGE DISAGREEMENT: a signal min or max outside what the interface
  requirement permits, with the requirement ID and both values.
- IN ARCHITECTURE, NOT IMPLEMENTED: a flow with no corresponding port
  or bus element.
- IMPLEMENTED, NOT IN ARCHITECTURE: a boundary signal the
  architecture does not describe. Often the more interesting list,
  since it is undocumented coupling.
- CANNOT COMPARE: one side records nothing, or the value was unknown.
  Never scored as agreement.
Reconciliation: Simulink boundary items = matched + implemented-only;
Dalus flows = matched + architecture-only; matched = agrees + each
mismatch class + cannot-compare.

DO NOT ADJUDICATE which side is correct. Report what differs, cite the
interface requirement where one exists, and let the engineer decide
whether the design moved or the architecture is stale. The single
exception is where the Dalus model disagrees with itself across the
two ends of a connection: say so plainly, since that one is
unambiguously theirs to fix.

DELIVER a report: the summary and counts, direction and type
mismatches in full, the unmatched lists, the unit gaps, and a
landscape table with both sides side by side for walking through in a
review, which is where this will actually be used. Stamp it with the
Dalus branch and revision, the Simulink model file and its date, and
the MATLAB release. If a previous comparison exists, lead with the
delta: resolved, new, and changed.

OFFER, do not execute: raising change requests where the user decides
the architecture is the side to move, generating an ICD for these
interfaces from the architecture, and re-running after the next
Simulink change.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions