Why it matters
Interfaces are where systems integration often fails. Teams may understand their own subsystem but miss the assumptions at the boundary between subsystems.
What is an interface control document?
An interface control document defines how systems, subsystems, or components connect, including signals, protocols, data, power, and responsibilities.
Interface control document
An interface control document, often called an ICD, defines how systems or components connect. It may describe physical connections, data signals, protocols, power interfaces, timing expectations, ownership, constraints, and the responsibilities on each side of a boundary.
Common mistakes
- Documenting an interface after implementation has already made hidden assumptions
- Treating an ICD as a static document disconnected from requirements and verification
- Ignoring ownership at subsystem boundaries
Where this concept fits in Cairn
Cairn models interfaces directly between nodes. Each interface can include source node, target node, protocol, description, and signals, giving teams an early interface model before a formal ICD exists.
FAQ
Is an ICD only for software interfaces?
No. ICDs can cover physical, electrical, data, power, thermal, timing, and operational interfaces.
Does Cairn generate formal ICD documents?
Cairn helps model interface data early. A formal ICD document may still need to be produced in another workflow.