An interface control document (ICD) is a formalized description of the methods and structures involved in providing input for and receiving output from a specific system. The system that is described by the interface control document can be a software library or a piece of hardware. The document does not have to follow any single format but can be a collection of paragraphs, charts or even just technical drawings of the interface hardware. When referring specifically to software, an interface control document can resemble and abstract programming interface (API), which describes the public methods or functions that can be used to input information into the library and also describes the output that will result. An interface control document generally describes how to integrate the system into a larger system or to connect it to a parallel system; it does not describe any of the internal workings of the system, which might be spelled out in a separate type of document.
The purpose of an interface control document is to provide developers of hardware or software some documentation that can be used when creating a system or software that will be transferring data to and from the system the ICD is describing. This usually means defining exact functions or hardware components in a way that their signatures are known and the tolerances of the parameters for use are given. In software engineering, this can mean knowing the name of a particular function, what type of variables are accepted as parameters and, possibly, what functional limits are placed on the values that are passed. For a piece of hardware, this information can include what functions the pins of a serial connector control, any hardware interrupts that are used, and the working speed of the device.
One thing an interface control document does not specifically describe is how the system translates input into output, or how output is produced, in general. This allows developers to take a narrowly focused view of the system when creating an interface, but it also requires that the developers of the system that the ICD details adhere strictly to the guidelines spelled out in the document itself. A convenience for the writers of an interface control document and the developers of the system is that the internal implementation of the system is not described in the document and, thus, can be freely changed without affecting the outside development of interfaces relying on the ICD.
In some situations, an interface control document can allow for the testing of systems without actually having to use a completed interface. This can be done by simulating the various types of output that a system can generate as described in the ICD, and then passing that output through the externally developed interface. Systems that are only interested in handling one side of the system — such as the output, in the case of hardware such as a display device — can ensure that the interface functions within specifications without requiring real-world input.
