An Interface Control Document (ICD) formally defines the interfaces between two systems, subsystems, or components — typically between teams or organizations. ICDs specify electrical interfaces (pin-out, voltage levels, signal timing, protocol), mechanical interfaces (connector type, mounting pattern, dimensional envelope), thermal interfaces (heat flux limits, interface material), software interfaces (API definitions, data formats, communication protocols), and power interfaces (voltage, current, connector). ICDs are the contractual agreement between subsystem teams on how their deliverables will interconnect.
ICDs are critical in multi-team or multi-organization projects. When the mechanical enclosure team and the electronics team are on different schedules, the ICD defines what each team can assume about the other's deliverable. When a company purchases a subsystem from a supplier, the ICD is the specification the supplier builds to and the customer tests against. In aerospace and defense, ICDs are often contractually binding documents with formal change control.
Interface failures are among the most common and costly hardware integration failures. Subsystems that individually pass all their own tests fail when integrated because the interface was underspecified, misinterpreted, or changed without notification. A rigorous ICD process — with formal approval, version control, and change notification — is one of the highest-leverage investments a hardware team can make in integration success.
Practical Example
An ICD between a system controller and a motor drive module specifies: CAN bus at 500 kbps (ISO 11898), 29-bit extended ID, message set and timing defined in ICD Rev C Appendix A; power: 24VDC ± 10%, max 8A continuous via M12 4-pin connector (pin 1: +24V, pin 2: GND, pin 3: ENABLE, pin 4: FAULT).
How SpecZero handles this
Interface requirements surface in SpecZero as functional requirements with target values defining interface parameters. Research blocks can document supplier datasheets and interface specification decisions that inform the ICD, maintaining the connection between requirement and design choice.
Related terms
System Requirements Specification(SRS)
A formal document defining all requirements a system must satisfy, derived from stakeholder needs.
Design Specification
A document that describes how a system will be designed to meet its requirements — the 'how' to the SRS's 'what.'
Design Decision Log
A structured record of key engineering decisions, capturing the objective, alternatives, analysis, and rationale.
Functional Requirements
Statements of what a system must do — behaviors, inputs, outputs, and capabilities.