Interface Design and Management

Where Integration Succeeds or Fails

In Lesson 1, we established that architecture is a set of decisions. The most consequential category of architecture decisions involves interfaces — the contracts that govern what crosses boundaries between subsystems. Integration failures are overwhelmingly interface failures, not component failures. A subsystem that passes every internal test can still break the system if its interface was underspecified, misunderstood, or changed without notification.

This was introduced in DGTLENG 103 (Decomposition and Interfaces). Here we go deeper — into the practice of specifying, identifying, and managing interfaces at the level required for real integration.

What an Interface Specification Must Contain

An interface specification answers one question: what crosses the boundary, and under what conditions? A vague answer ("subsystem A sends data to subsystem B") is not a specification — it is a placeholder that guarantees an integration surprise. A complete specification addresses multiple dimensions.

Data Types and Formats

What is the structure of the information exchanged? For software interfaces: message schemas, serialization formats (JSON, Protocol Buffers, binary), encoding (UTF-8, ASCII), units of measure. For electrical interfaces: signal types (analog voltage, digital logic levels, differential pairs), voltage ranges, impedance. For mechanical interfaces: geometric tolerances, material compatibility, fastener specifications.

Ambiguity in data types is the most common source of interface defects. The Mars Climate Orbiter was lost because one team specified impulse in pound-seconds while the other expected newton-seconds. The interface existed — the data type agreement did not.

Protocols

How does the exchange happen? The handshaking sequence, initialization requirements, error handling, timeouts, acknowledgment mechanisms. A protocol defines the temporal choreography of the exchange: who speaks first, how the receiver confirms, what happens when a message is lost.

For physical interfaces, the protocol equivalent is the assembly sequence, mating procedure, or operational startup sequence. A chemical processing interface between a reactor and a heat exchanger has a startup protocol: which fluid flows first, at what rate, to what temperature — get the sequence wrong and you thermal-shock the heat exchanger.

Rates and Timing

How fast, how often, how much latency is tolerable? Data rate (messages per second, bandwidth), update frequency (how often the sender publishes), latency budget (maximum time from send to receive), jitter tolerance (acceptable variation in timing).

For physical interfaces: flow rates (liters per minute, watts), cycling rates (how often a mechanical interface actuates), settling time (how long after a change before the interface reaches steady state).

Quality and Constraints

What are the acceptable ranges, error bounds, and degraded-mode behaviors? Signal-to-noise requirements, data accuracy bounds, allowable error rates, behavior when the interface degrades or fails. What does the receiving subsystem do when it gets out-of-range data? What does the sending subsystem do when the receiver stops acknowledging?

These quality parameters are often the last to be specified and the first to cause integration failures. A sensor interface that specifies data format and rate but not accuracy bounds or failure behavior is only half-specified.

The N-Squared Diagram

For N subsystems, there are N(N-1) potential directed interfaces — each pair can exchange in both directions. The N-squared (N²) diagram is the systematic tool for enumerating all of them. Subsystems line the diagonal; the off-diagonal cell at row i, column j contains what subsystem i provides to subsystem j.

Why Systematic Identification Matters

Engineers naturally identify the obvious interfaces — the ones the architecture makes prominent. The engine talks to the transmission. The sensor talks to the controller. The reactor talks to the heat exchanger. But the non-obvious interfaces — the ones that cross organizational boundaries, that involve shared resources, or that arise from physical proximity rather than functional intent — are the ones that cause late integration surprises.

A satellite example: the communications subsystem and the attitude control subsystem have no direct functional relationship. But the communications antenna has a pointing requirement that depends on spacecraft attitude. If the attitude control team doesn't know the pointing accuracy the comm team needs, and the comm team doesn't know the disturbance torques the attitude system can reject, neither team designs to the right constraint — and the problem surfaces during system-level testing.

The N² diagram forces consideration of every pair, including pairs that seem independent. The discipline is filling in each cell — even if the answer is "no interface" — because the explicit acknowledgment of no interface is more valuable than the implicit assumption of no interface.

From N² to Interface Control Documents

Each non-empty cell in the N² becomes an interface to be specified. In practice, bidirectional exchanges between the same pair are combined into a single Interface Control Document (ICD) or, in an MBSE environment, a single interface block in the system model. The N² diagram is the discovery tool; the ICD or model element is the specification artifact.

Interface Control and Change Management

An interface, once agreed upon, is a contract. Changing it unilaterally breaks the contract and, likely, the integration. Interface change management is therefore more critical than component change management — a component change that stays within its interface contract affects only the component; an interface change affects every component on both sides.

Formal Interface Control

In large programs, interfaces are governed by an Interface Control Working Group (ICWG) — a cross-team body that reviews, approves, and communicates interface changes. The ICWG exists because interface changes have bilateral impact: both the provider and consumer must agree, and both must update their designs.

The ICWG process is often viewed as bureaucratic overhead. It is not — it is the coordination mechanism that prevents unilateral changes from propagating into integration failures. The overhead of the ICWG is far smaller than the overhead of discovering at integration that two subsystems no longer connect.

Change Impact in the System Model

In an MBSE environment (DGTLENG 201), interfaces are model elements — ports, flows, and connectors with typed properties. When an interface change is proposed, the model's traceability relationships enable impact analysis: which components connect through this interface, which requirements depend on its properties, which tests verify its behavior.

This is where MBSE transforms interface management from a coordination problem into a computation problem. Instead of asking engineers to remember all the dependencies, the model traverses relationships and reports them. The decision to approve or reject the change still requires engineering judgment — but the data to inform that judgment is computed, not recalled.

Versioning and Baselining

Interfaces must be versioned. A baseline is a snapshot of all interface specifications at a point in time, agreed upon by all parties. Changes after baseline require formal review. Without versioning, teams work against different assumptions about the same interface — and discover the discrepancy at integration.

In digital engineering terms, the interface baseline is a configuration of the system model. Comparing the current model to the baseline reveals exactly which interfaces have changed, who changed them, and what the downstream effects are.

MBSE Ports and Flows: Formalizing Interfaces

MBSE provides precise constructs for representing interfaces. While the names vary across languages (SysML, CAPELLA, OPM), the concepts are universal.

Ports are defined interaction points on a component. A port specifies what can enter or leave through it — a data type, an energy flow, a material stream. Ports make interfaces explicit and localized: instead of a vague "these two components communicate," you point to the specific port on each component and the typed flow that connects them.

Flows describe what moves between ports. A flow has a type (data item, energy quantity, material substance, control signal), a direction, and rate characteristics. In SysML, item flows annotate connectors between ports. In CAPELLA, functional exchanges connect function ports with defined exchange items.

Connectors link ports between components. A connector says "this port on component A connects to that port on component B, carrying this flow." The connector is the model representation of the interface — and it carries the typed properties that the interface specification requires.

When the system model uses ports, flows, and connectors consistently, the N² diagram can be generated automatically from the model rather than maintained manually. Every structural connection in the model is a potential entry in the N². Gaps in the model — components with unconnected ports, flows without receivers — become visible as modeling artifacts, not as integration test failures.

Expand the tree above to explore the interface definitions between subsystems of an autonomous vehicle. Notice how each interface specifies not just what is exchanged but the data type, rate, timing, and failure behavior. Notice also the Safety Monitor's interfaces: it receives data independently from both Perception and Planning, and its emergency stop command overrides all other control inputs — an architectural decision driven by the safety driver.

Assessment