Communications interfaces and protocols
Turn electrical connections into dependable contracts: select the right interface, define meaning and timing, and design explicitly for corrupted, delayed, duplicated and missing data.
After this module, you should be able to:
- Separate physical, data-link and application concerns
- Select an interface from system constraints
- Specify a testable protocol contract
- Design and verify failure behaviour
An interface is a boundary; a protocol is an agreement.
A connector and peripheral do not define communication. Dependable exchange needs compatible electrical behaviour, framing, message meaning, timing, ownership and failure responses at both ends.
Layering helps engineers reason about faults. A valid electrical waveform may contain an invalid frame; a valid frame may contain a command that is stale, unsafe in the current state or incompatible with the receiver’s version.
Select from constraints, not familiarity.
| Interface | Useful characteristics | Questions and limitations |
|---|---|---|
| UART / serial | Simple point-to-point link; easy to observe and bring up. | Define framing, level translation, flow control and recovery from lost byte alignment. |
| I²C | Low pin count and addressed peripherals on one board. | Consider pull-ups, capacitance, clock stretching, stuck-bus recovery and address conflicts. |
| SPI | High throughput, low protocol overhead and deterministic local transfer. | Chip-select scaling, no standard message semantics and device-specific timing. |
| CAN | Robust shared bus, arbitration and strong frame-level error handling. | Bus loading, message priorities, physical topology and the selected higher-layer protocol. |
| USB | Standard host/device ecosystem, power options and defined device classes. | Host dependency, enumeration, cable removal, class behaviour and update compatibility. |
| Ethernet / IP | Scalable networking and access to mature transport protocols. | Variable latency, configuration, congestion, security and loss of network services. |
| Wireless | No cable and support for mobile or distributed products. | Interference, coexistence, range, pairing, credentials, power and regulatory constraints. |
Selection criteria should include distance, data rate, maximum latency, topology, environment, EMC, isolation, power, update needs, security, component availability, diagnostics and the consequences of communication loss.
Specify what each endpoint can depend upon.
- Define ownership. State who initiates, who may command, who publishes state and who decides that a link has failed.
- Define messages. Give every field a type, byte order, scale, unit, valid range and reserved-value rule.
- Define framing and integrity. Specify boundaries, length, sequence information, error detection and acknowledgement.
- Define timing. Include rates, deadlines, timeouts, retry limits, freshness and behaviour during overload.
- Define states. Cover start-up, discovery, synchronisation, normal exchange, degraded operation, reconnection and shutdown.
- Define compatibility. State how versions are identified, negotiated, rejected and updated.
- Define trust. Address authentication, authorisation, confidentiality and replay resistance where the threat model requires them.
Worked example: host computer to motor controller
A host sends cycle commands to an MCU over USB virtual serial. A safer contract separates command acceptance from command completion.
The controller rejects duplicates and commands that are invalid in its current state. If the heartbeat expires, it completes only the current bounded safe action, removes drive energy and reports the interruption after reconnection. Retries are bounded so a communications fault cannot create an endless command loop.
Verify both conformance and resilience.
Physical details, message definitions, timing, states, error handling, versions and security properties.
Bandwidth, bus loading, latency, buffers, retry traffic and worst-case utilisation.
Supported endpoint combinations, negotiation rules and regression results.
Corruption, truncation, delay, duplication, reordering, disconnection and reconnection.
Time-correlated captures that show actual messages, states and response times.
Unauthorised commands, malformed input, replay, downgrade and resource-exhaustion tests.
Common failure patterns
The message list is defined, but partial frames, restarts and missing responses are not.
Recovery traffic increases congestion or repeats an unsafe physical action.
Endpoints interpret the same integer differently, often without an obvious communication error.
Independently updated endpoints connect without an explicit compatibility decision.
Further learning
- CAN in Automation: CAN knowledgePhysical, data-link and higher-layer concepts for CAN-based systems.
- IETF RFC 9293: Transmission Control ProtocolA detailed example of a normative protocol specification, including states and error handling.
- USB-IF specifications and documentsPrimary specifications for USB architecture, devices and classes.
Specify the failure semantics, not only the message format.
A dependable interface states what is exchanged, when it is valid, who owns each decision and what both endpoints do when communication fails.