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
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: Read TEA-101 and TEA-102. Recognise the distinction between a physical link and message semantics.
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.
Separate electrical transport from application meaning
UART, I²C, SPI and CAN describe different interface arrangements and capabilities. Their successful operation does not define the meaning of a product command. Specify voltage levels, grounding, topology, termination where relevant, addressing and timing alongside the application message contract.
For a serial message, define framing, byte order, length limits, units, legal values, version and error detection. Separate the parser from the function that changes product state. Validate a whole request before acting so a later invalid field cannot leave a half-applied command.
Set bounds for incomplete frames and noisy inputs. A parser that waits indefinitely for a missing terminator can block valid traffic. A parser that allocates memory from an untrusted length can exhaust the device. Check maximum-size messages, malformed lengths and resynchronisation after an error.
Distinguish acceptance, completion and retry
An acknowledgement can mean bytes arrived, a request passed validation, work was queued or a physical action completed. Name the meaning explicitly. For asynchronous actions, report acceptance separately from completion and carry an operation identifier through both responses.
If the sender loses a completion response, retrying a command may repeat an irreversible action. Define idempotency: repeating the same request either has the same effect or is recognised as a duplicate. State how identifiers behave across reset and how long duplicate records remain valid. No transport acknowledgement by itself guarantees exactly-once physical execution.
Choose timeouts from response budgets and product behaviour. Reconnection does not establish that the endpoints agree on state. Exchange session identity, versions and the outstanding operation state before enabling new work.
| Event | Contract decision |
|---|---|
| Duplicate request | Return the recorded outcome or reject according to the operation identity. |
| Unsupported version | Negotiate an approved version or remain unavailable with a clear reason. |
| Checksum failure | Discard the frame and preserve synchronisation without partial action. |
| Link loss during motion | Apply the local, hazard-derived response and report it after reconnection. |
Verify the interface under competing traffic
Test communication while acquisition, logging, update and fault processing are active. Electrical robustness and software load interact: a burst of receive interrupts can delay control even when every byte is valid. Bound the amount of work performed per interrupt or scheduling cycle.
Use independent observations at both endpoints. Record message time, operation identity and physical outcome. Include delayed, repeated, reordered and truncated messages where the transport permits them, plus disconnects at state boundaries. A checksum detects certain accidental corruption patterns; it does not authenticate a sender or prevent an attacker from generating a new valid checksum.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Prevent a repeated dispense after a lost reply
A controller accepts Dispense(request ID, volume), performs the action and sends Complete. The Complete reply is lost, so the host resends the same request.
- Define acceptance, completion and duplicate handling.
- Specify what happens if the controller resets after dispensing but before retaining the outcome.
- Propose three interface tests that inspect physical delivery.
Show the worked answer
The controller should own operation execution and recognise a repeated identifier within an agreed session and retention model. It can return the known status without dispensing again. Acceptance confirms responsibility for the request; completion reports the verified outcome and any uncertainty.
A reset can create an uncertain interval between physical action and durable recording. Do not promise exactly-once behaviour unless the full mechanism supports it. A defensible policy may inhibit automatic retry, preserve an incomplete-operation record and require reconciliation using available physical evidence or an authorised user. Test a lost acceptance, a lost completion and power interruption at the physical-action boundary. Measure delivered volume as well as protocol responses.
Review criteria
- Replies distinguish acceptance from physical completion.
- Restart uncertainty is explicit.
- Duplicate tests observe the physical effect, not only packet counts.
Check your understanding
Does a CRC make a service command trustworthy?
No. It addresses accidental corruption, not authority. Authentication, authorisation and semantic validation need separate controls.
What must reconnection establish?
Compatible versions, a new or continuing session, valid state and the disposition of outstanding work before operation resumes.
Further learning
- NXP — I²C-bus specification and user manualPublisher source supporting this module’s framework discussion.
- 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.