Interface control document (ICD): what it holds and how to keep it current

What an interface control document is

Most integration problems are not inside a subsystem; they sit at the seam between two of them. One team assumes the connector is keyed one way, the other team assumes the opposite. One side sends a status message every 100 ms, the other side's timeout is 80 ms. An interface control document exists to make that seam explicit: it states, in one place both sides have agreed to, what passes between them and under which conditions.

An ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. describes an interface from the outside. It does not say how either side is built, only what each side must present at the boundary: the connector and its pins, the voltage and current, the message layout and timing, the mounting points, the environment the interface has to survive. Each team then designs its own side to match.

Three related document names are often confused:

Programs mix these differently. Some fold the requirements into the ICD; some write an IRSInterface Requirements Specification A document of the requirements an interface must meet, written before the interface is designed. early, then an ICD once the design matures. What matters is that the requirements and the agreed definition are both recorded, and that one of them is clearly the controlling one.

Who owns an ICD

An ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. has two parties, sometimes more, and a single owner. The parties are the organizations or teams responsible for each side: two subsystem teams, a prime contractor and a supplier, a vehicle team and a payload team. The owner is the person or group who keeps the document, chases open items and runs the approval. On larger programs that is an interface control working group (ICWG): representatives of each side plus the systems engineer responsible for integration, meeting on a regular cadence.

A few ownership rules prevent most disputes:

• One owner per interface, named in the document. "The systems team" is not an owner; a named lead is.
• Both parties approve. An ICD signed by one side is a wish list, not a control document.
• The integrating level owns interfaces between its children. The interface between two subsystems belongs to the system level, because neither subsystem can settle it alone.
• External interfaces, to equipment or systems outside the program, are owned on the program side and agreed with the external party, who may have its own document that takes precedence.

What an ICD contains

The exact outline depends on the domain and the program's standards, but a complete ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. covers the same ground. Leave a section in with "not applicable" rather than deleting it, so a reviewer can see it was considered.

Data and timing deserve the most detail

Mechanical and electrical interfaces tend to be checked physically early, at fit checks and first power-up. Data and timing mismatches survive much longer, often until system integration, because each side tests against its own simulator built from its own reading of the document. For every message, write down the identifier, the period and its tolerance, each field's type, range, units and scaling, the byte order, and what the receiver does when the message is late, missing or out of range. A message definition that says "battery current" without units, sign convention (charge or discharge positive) and resolution is not yet controlled.

Verifying the interface itself

Interface requirements are verified like any other requirement (the requirements verification matrix guide covers methods, levels and evidence), but the evidence has a special shape: it needs both sides. A compatibility test between the real units, or between one real unit and a validated emulator of the other, is stronger than two separate tests against two private readings of the ICD. Plan those tests in the ICD so the equipment and schedule exist when they are needed.

Finding the interfaces in the architecture

An ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. can only control the interfaces someone has found. The reliable way to find them is from the architecture, not from memory.

1. Start from the functions. Decompose the mission into functions and their inputs and outputs (the functional analysis guide shows how). An N²N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. diagram places the functions (or subsystems) on the diagonal; the cell in row A, column B holds what A sends to B. Every filled off-diagonal cell is an exchange that needs a path. Clusters of filled cells show which functions belong together; a busy row or column marks a function many others depend on.
2. Allocate the functions to components. Once each function is performed by a physical part, every exchange between functions in different parts becomes an exchange that crosses a part boundary.
3. Give every crossing exchange a physical path. A harness, a bus, a radio link, a pipe or a mechanical joint. An exchange with no path is a gap in the design; a path that carries nothing is either unnecessary or not yet understood.
4. Draw the interface diagram. For each pair of parties, show both sides, their internal parts at the boundary, and each link with what it carries. This becomes the overview figure of the ICD.

Number the interfaces as you find them. The worked example below numbers its links IF-01 to IF-25 and gives a link inside a larger interface a decimal (IF-14.1 inside IF-14). Numbers make interfaces citable in requirements, test procedures and change requests, and they keep a list of interfaces stable when names change.

Keep the ICD tied to the model

An ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. written as a standalone word-processor file starts drifting from the design on the day it is approved. A pin gets reassigned in the harness drawing, a message period changes in the software, a new signal is added for a late requirement, and the ICD is updated weeks later or not at all. Reviewers then compare documents against each other instead of against the design.

Model-based systems engineering turns this around. Each interface is an element of the system model, connected to its two endpoints, to the items it carries and to the requirements that govern it. The ICD is a report generated from those elements. Then:

• The same link appears with the same values in the ICD, the interface diagram, the requirements trace and the verification matrix, because all of them read one definition.
• A change to a message rate or a connector shows up in the next generated ICD, and the change history comes from the model's own record.
• Checks run on the model: an exchange between two parts with no link to carry it, a link with only one endpoint, a link whose load exceeds its capacity, a link with no owner or status.
• Requirements on an interface are traced to it, so the ICD's requirement and verification sections stay complete (see the requirements traceability guide for link types and gap checks).

Not everything belongs in model attributes. Detailed connector drawings, timing diagrams and long message catalogues may stay in attached or referenced documents. The model still holds the interface, its status, its owner and the reference, so the generated ICD points at the right revision.

Interface change control

An interface definition matures in steps, and the step decides how a change is handled. A simple four-stage scheme works for most programs:

A common cadence is to have interfaces drafted by the system requirements review, agreed before the preliminary design review and baselined before the critical design review. Whatever the cadence, a change request against a baselined interface should state the reason, the affected links and items, the impact on each party's design, cost and schedule, the requirements and verification affected, and the effectivity: from which build or serial number the change applies.

Track the TBDsTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date. and TBRsTo Be Reviewed A requirement value that is filled in but still needs to be confirmed. as a list that must shrink. An interface that is still full of open items at the critical design review is a schedule risk, whatever its status says.

Common failure modes

• Interfaces nobody found. An exchange between functions was never given a physical path, or an external interface (ground equipment, test equipment, the operator) was left out. Build the interface list from the architecture, not from the harness list.
• One-sided documents. One team writes the ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram., the other never formally agrees, and the disagreement surfaces at integration. Require both approvals before a status of Agreed.
• Missing units and conventions. A value without units, sign convention, byte order or scaling invites two different readings. Treat each as a defect in review.
• Load not compared with capacity. Each message fits, but together they exceed the bus; each load fits the harness, but together they exceed its rating. Sum the loads on every link and compare with its capacity, with margin. In the example model below, IF-05 Payload Interface carries a 480 Mbps image strip plus a 0.02 Mbps command schedule on a 400 Mbps link: 480.02 of 400 Mbps, 120 %, flagged by the model before integration rather than found on the bench.
• Timing left implicit. Rates are given, tolerances and timeout behavior are not. Record both and what each side does when the other is late.
• Stale copies. The ICD, the harness drawing and the software's message table each hold their own version. Generate from one source, or at least name which one controls.
• Open items with no owner. A TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed. without a person and a date stays open. Give each one both.
• Verification planned too late. Interface tests need both sides' hardware or validated emulators. Plan them when the ICD is agreed, not when the units arrive.

Worked example: C&DH to Communications on a CubeSat

The example is EO-1, a 6U Earth observation CubeSat that images farmland from a 500 km sun-synchronous orbit; the MBSE example project guide walks through the whole model. Here we take one seam inside the spacecraft: between 1.4 C&DHCommand and Data Handling The spacecraft subsystem that runs the flight computer, handles commands and stores and routes data. (command and data handling, a flight computer with 64 GB of payload storage) and 1.5 Communications (the 1.5.1 UHFUltra High Frequency Radio frequencies from 300 MHz to 3 GHz, often used for spacecraft command links. Transceiver for commands and the 1.5.2 S-band Transmitter for payload data). Different teams build the two sides, and every command the satellite executes and every image it sends to the ground crosses this boundary.

Finding the exchanges

The model's nominal imaging pass, OPS Run Nominal Imaging Pass, is decomposed into twelve functions, OPS.1 to OPS.12, and eleven of them are allocated to the asset that performs them. Its N²N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. diagram puts them on the diagonal and the items they exchange in the cells:

Two cells cross the C&DH to Communications boundary:

• Row OPS.2 Receive Imaging Plan (performed by the UHF Transceiver), column OPS.3 Load Command Schedule (performed by C&DH): Command Packets, the decoded command packets from the radio.
• Row OPS.7 Encode and Store Image (C&DH), column OPS.8 Transmit Image Data (the S-band Transmitter): Downlink Frames, compressed and packetized image data.

A third exchange does not appear in this pass because it comes from the spacecraft's mode logic: the C&DH entry action Enable S-band Transmitter sends a Transmitter Enable Command to F9 Transmit Payload Data, performed by the S-band Transmitter. An interface list built only from one scenario would have missed it, which is why the functions are allocated to assets across the whole model before the interfaces are listed.

The links and what they carry

The demo already gives each exchange a physical path. To make one controlled interface out of them, we added a single element to the demo project: a parent conduit, IF-26 C&DH to Communications Interface, connected to both subsystems, status Agreed, owner Comms Lead, with the two existing links as its children. Everything else below is the demo as it ships.

Each link traces to the requirement that drives it: IF-07 satisfies 5.2 UHF Command Uplink ("The UHF transceiver shall receive ground commands at 9.6 kbps"), and IF-08 satisfies 5.1 S-band Downlink Rate ("The S-band transmitter shall downlink payload data at 10 Mbps").

The interface diagram

The Interface Control Diagram shows the two parties as bands, the parent interface in the middle, each link as a bar with its status, capacity and items, and a line from each link to the part it connects:

The C&DH band has no parts in it because the model treats the flight computer as one unit: both links end on C&DH itself. On the Communications side each link ends on a different radio, which is exactly what the harness team needs to know.

The generated ICD

The ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. is exported from the same elements as a Word document. Its first page holds the interface register and a status summary; each conduit then gets its own section with endpoints, connector and pins, medium, conveyed items with direction and rate, the linked requirements and the capacity check.

Download the ICD: EO-1 ICD for the C&DH to Communications interface (.docx), the full three-page document as Holarch exported it, with the export date removed. It contains only the fictional EO-1 demo data.

What the example shows

• The register is the agenda for the working group. IF-07 is baselined, so a change to it goes through a change request. IF-08 is agreed: a change still needs both the C&DH and the Communications team. Neither has an open TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date. or TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed., so this interface is ready to baseline as a whole.
• Check the capacity against what the medium really delivers. IF-07 carries 9.6 kbps on a recorded capacity of 0.1 Mbps, which the document reports as 10 %. A UART at 115.2 kbaud with one start and one stop bit per byte moves 115,200 × 8 / 10 = 92,160 bit/s of data, so the true capacity is about 92 kbps and the load is about 10.4 % of it. The margin is large either way, but the recorded figure rounds up; on a busier link that rounding would hide a problem.
• A link can pass while its system fails. IF-08 runs 10 Mbps of frames over a 100 Mbps SpaceWire link, 10 % of capacity. The constraint sits one interface downstream: IF-12 S-band Downlink carries 9.6 Mbps on a 10 Mbps radio link, 96 %. A faster frame stream would pass IF-08 easily and fail at the antenna, so an ICD review looks at the chain, not one link.
• An item without a rate is not checked. The Transmitter Enable Command has no data rate, so the capacity check leaves it out. It is tiny, but an empty value is an open item: give it a rate, or a TBD with an owner.
• The parent interface carries no capacity of its own. It bundles the items of its links (three here) and gives the pair of parties one document, one owner and one status; the load checks run on each link.
• A change is traceable. If the mission moves to a faster downlink, the Downlink Frames rate changes in one place, the checks on IF-08 and IF-12 rerun, and requirement 5.1, traced to IF-08, names what to re-verify.

Try it in Holarch

1. Create the demo with Manage Projects → Project Files ▾ → New Demo Project.
2. Open Interfaces → N²N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. Diagrams and open the N² Diagram of the action OPS Run Nominal Imaging Pass to see the exchanges between its functions.
3. Open Interfaces → ICDsInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram., click + New Diagram and choose C&DHCommand and Data Handling The spacecraft subsystem that runs the flight computer, handles commands and stores and routes data. as the left and Communications as the right parent asset.
4. Drag the existing conduits IF-07 Radio Command Interface and IF-08 Payload Data Interface from the palette onto the centre box. Their items and connections come with them.
5. Select a link to review its Interface Status, Owner, TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date./TBRTo Be Reviewed A requirement value that is filled in but still needs to be confirmed., Capacity and Units, and its linked requirements.
6. Click Export ICD Document for the Word document, or Export ICD (CSV) for a table.

Interfaces → Interface Register lists every interface in the project with its status and capacity check; in the demo it shows IF-05 over capacity. Step-by-step instructions are in produce an interface control document; baselined interfaces change through change requests.

Where to go next

• Interfaces in Holarch: the interface register, capacity checks and ICDsInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram. from the model.
• Interfaces docs: conduits, items, the Interface Control Diagram, N²N-squared A square chart with elements on the diagonal and what passes between them in the off-diagonal cells. Used to find and check interfaces. and Physical I/O diagrams.
• Change Requests docs: configuration control for baselined items.
• What is MBSE?: why engineers keep the system in a model.