Interface control document

Overview

An interface control document, often shortened to ICD, records how two parts of a system meet. It states what crosses the boundary between them, in enough detail that two teams, or two companies, can design their sides separately and still have them work together. Once agreed, it is placed under change control, so that neither side can change the interface without the other knowing and agreeing.

How it works

An ICD is written once the system architecture has split the system into parts and named the interfaces between them. For each interface it lists the physical side (connectors, pin assignments, cables, mechanical fit), the electrical side (voltages, currents, signal levels, timing) and the logical side (protocols, message formats, registers, commands, error handling). It also names the owner of each side and how the interface will be tested.

The two teams review the document together and sign it off. From then on it is a controlled item: a change is raised as a request, its effect on both sides is assessed, and the new version is released before either side builds to it. Large programmes keep a list of all their ICDs and check that every interface in the architecture has one.

Integration and validation tests are traced back to the ICD. When parts are brought together on the first engineering builds, a mismatch is checked against the document to find which side departed from it.

Examples

• An ICD between a main board and a display module, listing the connector, the power rails, the video interface and the control commands.
• An ICD between a chip team and a firmware team describing the register map and boot sequence the firmware relies on.
• An ICD between a vehicle controller and the vehicle network, setting the messages it sends and receives and their timing.
• An ICD for a sensor supplied by another company, agreed before either side starts detailed design.

Why it matters

Most integration problems in a system appear at the boundaries between parts made by different teams. An ICD turns assumptions into a written agreement, so that a board team, a chip team and a firmware team can work in parallel and still meet. It is used by system architects, systems engineers, hardware and firmware designers and validation engineers.

In the system lifecycle, ICDs are drafted during architecture, frozen with the design, used to plan integration and validation builds, and kept current through sustaining work, when a part is replaced or a supplier changes.

It matters most to: Configuration Management Engineer, Hardware Design Engineer (Board Level), Hardware-Software Integration Debug Engineer, System Hardware Architect, Systems Engineer

Common confusions

Not the same as an interface specification of a standard bus

A standard such as a bus specification describes an interface in general. An ICD records how one particular pair of parts in one system uses it, including the choices and options the standard leaves open.

Not the same as a datasheet

A datasheet describes one part for anyone who buys it. An ICD is an agreement between two named sides of one system, and both sides sign it.

Sources

1. 6.3 Interface Management (NASA Systems Engineering Handbook) (opens in a new tab), NASA, 2026-11-10
2. ECSS-E-ST-10-24C Rev.1 Interface management (15 November 2024) (opens in a new tab), European Cooperation for Space Standardization (ECSS), 2026-11-10
3. Interface control document (opens in a new tab), Wikipedia, 2026-11-10

Related terms

• Hardware and software partitioning
• Engineering validation test
• Configuration management

Where it appears on the Hub

No other page of the Hub uses this term yet.