Interface Control Drawing

Interface Control Drawing

Key Takeaways

How an interface control drawing helps synchronize work across multiple design teams and sub-systems.

The overlapping levels of device interfacing.

Best practices to maintain high standards in interface control drawings.

interface control drawings account for how sub-systems connect and communicate

Whether assembling furniture or playing with building blocks, most people will rely on documentation that provides easy-to-follow instructions. These manuals inform the reader of how to put together pieces to build the final product with varying levels of detail depending on the complexity. However, how do directions for individual devices come together to form a greater system? Generally, these are covered by respective industry standards, but if many devices connect in many different ways that aren’t easily discerned or fall outside the scope of one or more of these standards, confusion may arise.

This is an impractical consideration for most users, but it is an issue that must be addressed by design teams as electronic devices and systems become more complex and departments become more specialized. To solve this problem, product management teams incorporate an interface control drawing that covers every aspect of how different sub-systems interact with each other.

System Engineering Cycle for Interface Control

*: Cycle loops back to the top of the list

Interface Control Drawings Establish Compliance

Following the encapsulation of a PCB (or multiple PCBs) within an enclosure, along with a supporting cabling system (if necessary), the stand-alone unit is complete, but work remains on its integration into a larger system. Consumer electronics may only feature a small number of plugs and receptacles for interfacing with other devices, but with extensive safety precautions built into the design, it is difficult for them to unintentionally cause damage to users or other electronics. This may not be the case with devices in a more rigorous industrial setting with greater electromechanical inputs and demands. An interface control drawing helps technicians safely and optimally integrate electronic devices into new or existing systems with minimal downtime and risk to equipment or operators. Maintenance, scheduled or otherwise, also relies on interface control drawings to ensure systems are correctly inspected and installed to specifications.

Does every system require an interface control drawing? Not necessarily, but design teams may be forgoing documentation that could prove critical at a later time. One of the major strengths of interface control drawings is for evolving system development; different teams do not need to constantly pause their work and arrive at communally-agreed solutions to maintain design symmetry. Instead, documentation at the interface naturally handles the synchronization between different system levels, and so long as each team practices good documentation habits, the path toward conformity is a straightforward one.

At its most fundamental level, an interface control drawing consists of three overlapping elements:

Single-system I/O - All inputs and outputs for a single device, think the cables running to a desktop computer (power, A/V, mouse, keyboard, etc.).

Sub-system interfacing - All connections between “standalone” devices, e.g., the wireless communication between a modem and computer to enable internet access.

Total interface - The collection of all devices and connections, communications, interfaces, etc. within a system. Since the scope of a system can vary tremendously, document designers may wish to employ the 7-layer OSI model, which covers connection from the application layer to the physical level.

It is the total interface that is the subject of the interface control drawing, while single- and sub-system levels of interfacing fall under the overall umbrella. Once again, this underlines the flexibility of designing for interfacing; the interface control drawing is responsible for the minimum number of requirements for compatibility, making its constraints on the design as low-impact as possible.

Best Practices Lead to Ease of Testing and Accelerate Development

Project managers who oversee the responsibility of the interface control drawing creation may employ the following best practices:

Investments - Those closest to the design will have the greatest knowledge of the system and how it needs to appropriately interface with other devices. They should provide the information that will serve as the basis for the document.

Reviews - An initial draft will need to be reviewed by all involved departments for a comprehensive and complete understanding of how interfaces fit into the greater system.

Standardization - Standards help in two ways: they ensure a high level of compatibility and improve the ability to source components for new builds and replacements.

Documentation - Any appropriate detail necessary for the operation of the sub-system within the large whole is fundamental to an interface control drawing. This will rely on and contribute heavily to the system-level document to create a closed design loop.

Motivation - Choices should be properly defended by the design team, and choices that do not possess strong reasoning should be thoroughly investigated to strengthen the interface.

Interconnections - For any level of interfacing (hardware, software, etc.), designers must communicate the requirements of all associated systems. This ensures compliance at all system junctions.

Authentication - Individually and collectively, components, devices, and systems must meet all design requirements expected for standard operations as well as maximum settings.

Considerations - Design is a branching path wherein a selection early on can have significant ripples throughout the system. Be cognizant of every choice within the interfacing systems and what they bring to (and take from) the table.

Focusing on the interfaces between different sub-systems with these practices will also allow for rapid testing. As individual departments may not necessarily be savvy about the operation of the device/sub-system, their focus can rest on mere compatibility with the interface. Within reason, keeping separate departments in the dark about the operation past the interface strengthens the design, as testing cannot “hard code” I/O. Instead, treat complementary sub-systems as black boxes.