Embedded Communication and Networking

Introduction and Context

Embedded systems rarely operate as isolated computational units. A sensor node exchanges measurements with a controller, a motor drive receives commands from a supervisory controller, and a medical instrument transfers data to a host computer or cloud gateway. Communication interfaces therefore determine not only how devices exchange bits, but also how reliably, quickly, securely, and interoperably an embedded system performs its intended function.

Embedded communication spans short-distance chip-level buses, board-level peripheral interfaces, vehicle networks, industrial fieldbuses, computer-oriented interfaces, wired local-area networks, and wireless systems. The appropriate choice depends on physical distance, topology, data volume, timing constraints, electromagnetic environment, power budget, cost, safety requirements, and standards compliance.

This chapter treats communication as a systems-engineering decision rather than a catalogue of interfaces. It begins with communication fundamentals, examines UART, SPI, and I²C, then develops CAN, LIN, USB, Ethernet, industrial networks, and wireless protocols. The discussion concludes with comparative evaluation, implementation practice, and an applied case.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the roles of physical, data-link, network, transport, and application layers in embedded communication.

2. Implement and debug UART, SPI, and I²C interfaces.

3. Compare CAN, LIN, USB, and Ethernet in terms of topology, arbitration, bandwidth, latency, reliability, and interoperability.

4. Select industrial and wireless protocols for application-specific requirements.

5. Estimate transmission time, payload efficiency, and bus utilization using appropriate assumptions.

6. Design a communication architecture with fault handling, security, synchronization, and verification provisions.

7. Critically evaluate protocol-stack requirements and trade-offs in a real embedded application.

Communication Models and Selection Criteria

A communication system contains a transmitter, receiver, physical medium, protocol rules, and software that interprets the exchanged information. Protocols may be described using layered models. The physical layer defines signals, voltage levels, connectors, modulation, and bit timing. The data-link layer defines frames, addressing, medium access, error detection, and sometimes retransmission. The network layer supports routing across interconnected networks. The transport layer may provide segmentation, flow control, and end-to-end reliability. Application protocols give the exchanged data meaning.

Embedded systems do not always implement every layer. SPI and I²C generally provide physical and link-level functions without routing or transport services. Ethernet supplies physical and data-link mechanisms, while IP, TCP or UDP, and an application protocol are added when communication extends beyond a local link. CAN provides a robust data-link protocol, but higher-layer standards such as CANopen and J1939 define device models, network management, and application semantics.

Important selection criteria include:

• Bandwidth: the nominal or effective rate of useful data transfer.
• Latency: time between a transmission request and the availability of the corresponding data.
• Jitter: variation in latency, especially important in control loops.
• Reliability: probability of correct delivery under specified conditions, including resistance to noise and fault containment.
• Topology: physical arrangement, such as point-to-point, bus, star, ring, or switched network.
• Determinism: predictability of access time and delivery time.
• Interoperability: ability of devices from different vendors to communicate using common standards and profiles.
• Protocol overhead: non-payload bits, headers, checksums, acknowledgements, and inter-frame gaps.
• Energy and resource cost: processor time, memory, transceiver power, cabling, and connector cost.
• Safety and security: protection against dangerous failures, unauthorized access, manipulation, and loss of availability.

A nominal bit rate must not be confused with application throughput. If a frame contains P payload bits and O overhead bits, and the physical bit rate is R bits per second, the ideal transmission efficiency is

η = P/(P + O),

and the ideal payload throughput is

T = Rη.

These expressions assume one frame type, no retransmissions, no flow-control delay, and continuous transmission. Real throughput is lower when arbitration, inter-frame spacing, processing delays, errors, or idle intervals occur.

Asynchronous Serial Communication: UART

A Universal Asynchronous Receiver/Transmitter converts parallel data into a serial bit stream and reconstructs it at the receiver. UART communication generally uses separate transmit and receive lines, commonly called TX and RX, and a shared reference ground. It is asynchronous because no clock line is transmitted. Both endpoints must therefore agree on baud rate, character format, and sampling convention.

A typical frame consists of one start bit, five to nine data bits, an optional parity bit, and one or more stop bits. The line is normally in the idle logic-high state. A low start bit signals the beginning of a character. The receiver samples near the centre of each bit period, often using an oversampling clock.

The baud rate is the number of symbols per second. For conventional binary UART, one symbol carries one bit, so baud rate and bit rate are numerically equal. If a frame contains N data bits, S start bits, P parity bits, and H stop bits, its duration is approximately

t_frame = (1 + N + P + H)/R_b,

where R_b is the baud rate in bits per second. The useful data rate is therefore

R_data = NR_b/(1 + N + P + H),

assuming continuous transmission and no additional idle time.

For example, an 8-N-1 format has one start bit, eight data bits, no parity, and one stop bit: ten transmitted bits per byte. At 115,200 bit/s, the ideal byte rate is 11,520 bytes/s. The result follows from 115,200/10, not from dividing by eight, because start and stop bits consume bandwidth.

UART is simple, inexpensive, and widely supported. It is suitable for debug consoles, module configuration, GPS receivers, Bluetooth modules, and point-to-point processor links. Its limitations include short practical cable length, lack of inherent addressing, no common arbitration mechanism, and weak error handling. Parity detects some single-bit errors but does not provide strong frame integrity. A robust UART application should define packet boundaries, length or delimiter rules, a checksum or CRC, timeout handling, versioning, and recovery from framing errors.

A UART voltage interface must also be distinguished from a physical standard. TTL or CMOS UART signals are logic-level signals, whereas RS-232 uses different voltage polarities and levels, and RS-485 uses differential signalling with multidrop capability. A UART peripheral may drive any of these through an appropriate transceiver; the UART itself does not define the cable electrical layer.

Synchronous Board-Level Buses

SPI

The Serial Peripheral Interface is a synchronous, usually full-duplex bus. A controller supplies a serial clock (SCLK), transmits data on MOSI, receives data on MISO, and selects a peripheral using a chip-select signal. Multiple peripherals commonly share SCLK, MOSI, and MISO, with a separate chip-select line for each device. Some systems use daisy-chain arrangements or additional interrupt and ready lines.

SPI has no universal frame format, addressing scheme, acknowledgement, or mandatory electrical standard. The controller and peripheral must agree on clock polarity (CPOL), clock phase (CPHA), word length, bit order, maximum frequency, and chip-select timing. The four common SPI modes are defined by the CPOL and CPHA pair. Incorrect mode selection commonly produces shifted or apparently random data.

SPI supports high throughput and low protocol overhead. A full-duplex exchange can transmit and receive simultaneously, although many devices use the received stream only during a read operation. Its principal disadvantages are additional chip-select wiring, limited inherent scalability, no standard device discovery, and the absence of built-in error detection. PCB trace length, signal integrity, ground reference, and clock-edge rate constrain practical performance. Series termination, controlled trace impedance, short connections, and carefully defined chip-select timing may be necessary at high speed.

I²C

The Inter-Integrated Circuit bus uses two open-drain or open-collector lines: serial data (SDA) and serial clock (SCL). Pull-up resistors return the lines to the logic-high state; devices actively pull them low but normally do not drive them high. This arrangement permits wired arbitration and clock stretching.

A transaction begins with a START condition, followed by a seven-bit or ten-bit address and a read/write indication. Each byte is followed by an acknowledge bit. A STOP condition ends the transaction. In a write operation, the controller commonly sends a device address, an internal register address, and one or more data bytes. In a read operation, a repeated START may change direction without releasing the bus.

The maximum practical speed depends on the I²C mode, bus capacitance, pull-up resistance, voltage, and device timing. The rising edge is determined by the pull-up resistor and total bus capacitance. A simplified first-order model is

V(t) = V_DD[1 − exp(−t/(R_P C_B))],

where V_DD is supply voltage, R_P is the pull-up resistance, and C_B is total bus capacitance. This model assumes a lumped capacitance and an approximately resistive pull-up. It shows why lower resistance gives faster rising edges but increases low-level current and power. The resistor must satisfy both rise-time and sink-current constraints.

I²C offers two-wire multidrop operation, addressing, acknowledgement, and multi-controller arbitration. It is well suited to sensors, EEPROMs, real-time clocks, power monitors, and configuration devices on one board. It is slower and more sensitive to capacitance than SPI, and a stuck-low device can hold the entire bus. Recovery procedures may include disabling the peripheral, manually toggling SCL to release a slave, and generating a STOP condition, but hardware isolation may be required in safety-critical systems.

CAN and LIN: Automotive and Distributed Control Networks

CAN

Controller Area Network is a message-oriented, multi-controller bus designed for reliable distributed control. Nodes transmit frames identified by an identifier; the identifier is not necessarily a device address. The identifier also determines arbitration priority: numerically lower identifiers have higher priority in standard CAN arbitration because dominant bits override recessive bits.

CAN uses differential signalling, typically through a twisted pair with termination at both physical ends of a linear bus. Classical CAN supports up to eight data bytes per data frame. CAN FD permits larger payloads and can use a faster data phase, subject to transceiver, network-length, and system constraints. Frames include arbitration, control, data, cyclic redundancy check, acknowledgement, and end fields. Bit stuffing prevents excessive runs of identical bits and supports synchronization.

A transmitting node monitors the bus while sending. If it transmits a recessive bit but observes a dominant bit, it loses arbitration and stops transmitting without corrupting the winning frame. This is non-destructive arbitration. CAN also detects bit, stuff, CRC, form, and acknowledgement errors. Fault confinement uses transmit and receive error counters; nodes may progress through error-active, error-passive, and bus-off states. These mechanisms make CAN highly suitable for noisy environments and systems requiring fault containment.

CAN timing is priority-dependent. A high-priority frame may experience bounded interference from frames already in progress and from higher-priority traffic. Low-priority messages may suffer significant delay under heavy load. Consequently, CAN networks require message-priority analysis, worst-case response-time analysis, correct termination, bit-timing configuration, and bus-load budgeting. A CAN identifier should be allocated according to timing criticality rather than merely numerical device order.

CAN by itself defines communication mechanics, not the meaning of all data. CANopen adds object dictionaries, network management, process data objects, and service data objects. SAE J1939 defines parameter groups and addressing conventions for heavy vehicles and machinery. Such higher-layer profiles substantially improve interoperability.

LIN

Local Interconnect Network is a lower-cost, single-wire serial network for simple automotive and mechatronic devices. It uses a master schedule. A header contains a break, synchronization field, and protected identifier; a designated slave supplies the response. LIN is slower and less flexible than CAN but requires inexpensive transceivers and wiring.

LIN is appropriate for switches, seat controls, mirrors, climate actuators, and simple sensors where strict event-driven arbitration is unnecessary. Its scheduled operation provides predictable communication, but the master is a single point of coordination. It is not an appropriate substitute for CAN in safety-critical high-bandwidth control.

USB and Ethernet

USB

Universal Serial Bus is a host-controlled, generally point-to-point connection system with hubs used to expand connectivity. A USB device does not ordinarily transmit whenever it wishes; the host schedules transactions. Enumeration allows the host to identify a device and obtain descriptors describing its configurations, interfaces, endpoints, and capabilities.

USB transfer types include control, bulk, interrupt, and isochronous transfers. Control transfers support configuration and management. Bulk transfers provide reliable delivery with bandwidth allocated when available and are suitable for storage or data logging. Interrupt transfers support bounded polling latency for small, periodic data exchanges. Isochronous transfers reserve timing and bandwidth for streams such as audio, but normally do not provide retransmission-based reliability.

USB offers standardized connectors, device classes, hot-plug support, and high interoperability when class specifications are followed. However, its host-centric architecture, enumeration complexity, power negotiation, connector constraints, and software-stack requirements can make it unsuitable for a small deterministic control bus. USB-C introduces more sophisticated connector and power-role capabilities; its use must follow the relevant electrical and power specifications rather than assuming that every USB-C connection supports every feature.

Ethernet

Ethernet is a family of wired local-area networking technologies. Modern switched Ethernet commonly uses point-to-point links between endpoints and switches. Link negotiation, frame formats, media access, and physical signalling are defined by IEEE 802.3 families. Ethernet frames include destination and source MAC addresses, a type or length field, payload, and frame check sequence. The frame check sequence detects errors, but ordinary Ethernet does not guarantee delivery, ordering, or bounded latency.

IP can provide addressing and routing. UDP offers low overhead but no inherent delivery guarantee, while TCP provides ordered, reliable byte-stream delivery through acknowledgements, retransmission, and flow control. TCP reliability can increase latency and jitter, so it is not automatically suitable for real-time control. Industrial Ethernet protocols address this limitation through scheduling, prioritized traffic, synchronized clocks, or specialized data-link mechanisms.

Ethernet is attractive because of high bandwidth, mature tools, broad interoperability, and integration with enterprise and cloud systems. Design concerns include electromagnetic compatibility, switch behavior, cybersecurity exposure, time synchronization, congestion, and dependence on multiple software layers. Time-Sensitive Networking (TSN) extends Ethernet with mechanisms such as time synchronization, scheduled traffic, and bounded queuing behavior. Exact guarantees depend on the selected IEEE standards, network configuration, and verification evidence.

Industrial Networks and Wireless Protocols

Industrial systems often combine multiple network classes. Modbus RTU over serial links is simple and widely deployed, while Modbus TCP maps a related application model onto TCP/IP. PROFIBUS, PROFINET, EtherNet/IP, EtherCAT, and CC-Link families provide different combinations of cyclic I/O, diagnostics, synchronization, device profiles, and real-time behavior. No industrial protocol is universally best. The decision must consider installed equipment, engineering tools, vendor ecosystem, cycle time, topology, safety certification, and maintenance capability.

Industrial protocol selection should distinguish standard communication from functional safety. A communication protocol may detect errors without guaranteeing that a hazardous actuator reaches a safe state. Safety layers, redundant channels, watchdogs, safe-state design, and certification evidence may be required. Similarly, interoperability depends on conformance testing and profiles, not merely on sharing a protocol name.

Wireless choices include Wi-Fi, Bluetooth Low Energy (BLE), IEEE 802.15.4-based systems such as Zigbee and Thread, cellular IoT technologies, and proprietary sub-GHz links. Wi-Fi offers relatively high throughput and direct IP integration but can consume substantial energy and experience contention. BLE is optimized for short-range, low-power peripherals and supports advertising, discovery, and connection-oriented data exchange. IEEE 802.15.4 provides a low-power radio foundation; Thread adds IPv6 mesh networking, while Zigbee provides its own application framework. Cellular IoT supports wide-area connectivity but introduces subscription, coverage, power, and regulatory considerations.

Wireless performance varies with channel occupancy, propagation, antenna design, interference, coexistence, transmit power, coding, and duty-cycle restrictions. A nominal physical rate does not guarantee application throughput or latency. Wireless systems should include link-quality monitoring, retransmission limits, timeouts, commissioning procedures, key management, and operation during gateway or cloud failure.

Worked Comparison: Payload Efficiency and Timing

Consider two links that must transfer 1,000 bytes continuously. A UART uses 8-N-1 at 115,200 bit/s. Each byte requires ten line bits, so the transmission time is

t = 1,000 × 10/115,200 = 0.0868 s approximately.

The ideal payload rate is therefore about 11,520 bytes/s, and the transfer takes approximately 86.8 ms, excluding software and inter-message delays.

Now consider a hypothetical bus transmitting frames containing eight payload bytes and eight overhead bytes at 1 Mbit/s, with no arbitration delay or inter-frame gap. Its efficiency is

η = 8/(8 + 8) = 0.5.

The ideal payload rate is 1,000,000 × 0.5 = 500,000 payload bits/s, or 62,500 payload bytes/s. A 1,000-byte transfer would require approximately 16 ms. In an actual CAN network, bit stuffing, arbitration, inter-frame spacing, acknowledgements, and retransmissions alter this result. The example demonstrates why comparing only nominal bit rates can produce misleading conclusions.

Protocol-Stack and Implementation Architecture

A robust embedded communication design separates hardware drivers, protocol framing, transport services, application objects, and system management. A typical stack includes:

1. Driver layer: configures clocks, pins, DMA, interrupts, buffers, and transceivers.

2. Link layer: constructs frames, checks CRC or parity, handles acknowledgement and bus state.

3. Transport layer: segments large messages, reassembles them, controls flow, and detects timeout.

4. Application layer: defines data types, units, scaling, commands, status, and version compatibility.

5. Management layer: performs discovery, diagnostics, configuration, firmware update, logging, and security operations.

Interrupt-driven reception is appropriate for moderate event rates; direct memory access reduces CPU load for sustained transfers. Ring buffers prevent short bursts from being lost, but their capacity must be justified against worst-case arrival rate and service latency. A parser should reject invalid lengths before allocating memory, enforce maximum message sizes, and recover from malformed frames without losing synchronization.

Testing should include normal traffic, boundary values, invalid checksums, dropped frames, duplicated frames, reordered packets, bus disconnection, clock error, power cycling, buffer exhaustion, and electromagnetic interference. Protocol traces and hardware logic analysers are valuable for UART, SPI, and I²C. CAN and Ethernet require bus analysers, packet captures, error-counter monitoring, and time-correlated system logs.

Security should be designed at the architecture stage. Threats include message injection, replay, unauthorized firmware update, denial of service, key extraction, and physical tampering. Confidentiality, integrity, authenticity, freshness, secure boot, signed updates, least privilege, and key rotation may be required. A checksum detects accidental corruption; it is not a substitute for cryptographic authentication.

Illustrative Case Study: Distributed Battery Management System

Background

Consider a fictional but technically representative battery-storage controller containing twelve monitoring modules, a central battery-management controller, a contactor controller, and an Ethernet-connected supervisory gateway.

Problem

Each monitoring module must report cell voltages and temperatures reliably. The contactor controller requires high-priority commands. Service technicians need local diagnostics, while the gateway must expose operating data to an industrial supervisory system. The environment contains switching noise, and a communication fault must not cause unsafe energization.

Analysis

SPI could provide high-speed acquisition inside each monitoring module, but it is unsuitable for a long multidrop connection between physically separated modules. UART is useful for a local service console but does not provide robust arbitration or fault confinement. LIN would be inexpensive but lacks the required robustness and distributed control capability. CAN is appropriate for the battery-control network because it supports differential signalling, priority arbitration, error detection, and fault confinement. Ethernet is appropriate between the central controller and the supervisory gateway because of its bandwidth and integration advantages.

Approach and Solution

Each monitoring module uses SPI to connect its microcontroller to a cell-monitoring integrated circuit. The module controller validates measurements, applies range checks, and publishes them over CAN using a documented application profile. High-priority CAN identifiers are assigned to emergency status and contactor commands; routine diagnostics receive lower priority. The CAN bus is terminated only at its two physical ends and is tested for bit timing and load under worst-case traffic.

A UART service port is isolated from the control network and protected by authentication before configuration changes are accepted. The central controller uses an Ethernet interface to a gateway. A documented application protocol carries measurements, alarms, timestamps, and quality indicators. The gateway cannot directly energize contactors; safety-related commands require local validation, watchdog supervision, and a defined safe-state response.

Firmware updates are signed, version checked, and staged so that loss of power does not leave the controller without a recoverable image. Event logs include communication error counters, reset reasons, rejected commands, and time references.

Outcome

The architecture uses each protocol where its strengths apply: SPI for short board-level acquisition, CAN for robust distributed control, UART for isolated maintenance, and Ethernet for supervisory integration. It avoids using a high-bandwidth network as a substitute for a deterministic safety mechanism. Verification includes fault injection, bus-off recovery tests, gateway disconnection, invalid command tests, and thermal and electromagnetic testing.

Learning Points

The case illustrates that protocol choice is architectural. Interoperability requires defined data models and conformance testing. Reliability requires both protocol mechanisms and system-level fault responses. Security and safety must constrain interfaces that can affect energy flow, rather than being added after basic communication has been implemented.

Challenges, Limitations, and Contemporary Developments

The principal challenge is the gap between nominal protocol capability and real application behaviour. Clock tolerances, physical-layer distortion, queueing, retransmission, software scheduling, and power-state transitions influence actual performance. Wireless links add uncertain propagation and interference. Higher bandwidth can increase attack surface and software complexity.

Contemporary systems increasingly combine time-sensitive Ethernet, edge computing, wireless sensing, secure device identity, and containerized or remotely updated software. AI may assist with predictive maintenance by analysing communication error counters, latency distributions, and sensor trends. However, AI-generated decisions should not replace deterministic protection mechanisms or validated safety logic. Machine-learning models can drift, misclassify rare faults, and create difficult-to-audit dependencies.

Regulatory and governance requirements may include radio-spectrum rules, electromagnetic compatibility, functional safety, cybersecurity standards, data protection, and sector-specific certification. Engineers should maintain traceability from requirements to protocol configuration, implementation, test evidence, and field-update procedures.

Best-Practice Design Rules

1. Select the protocol from timing, reliability, topology, power, safety, and lifecycle requirements rather than familiarity alone.

2. Separate payload semantics from transport details and define units, ranges, scaling, endianness, and versioning.

3. Calculate worst-case latency and bus utilization; do not rely only on average measurements.

4. Use correct termination, grounding, shielding, pull-ups, and transceivers for the physical medium.

5. Treat checksums as error detection and cryptographic authentication as security; they serve different purposes.

6. Design explicit timeout, retry, reset, bus-recovery, and safe-state behaviour.

7. Use conformance testing and documented profiles to achieve interoperability.

8. Test malformed, delayed, duplicated, disconnected, and adversarial traffic.

9. Keep safety functions independent of non-deterministic supervisory or cloud services.

10. Record protocol configuration and diagnostic evidence so that field failures can be reproduced.

Chapter Summary

Embedded communication includes simple point-to-point UART, synchronous SPI and I²C buses, robust CAN and economical LIN networks, host-oriented USB, high-bandwidth Ethernet, industrial fieldbus and industrial Ethernet systems, and wireless protocols. Each technology reflects trade-offs among bandwidth, latency, determinism, reliability, wiring, power, interoperability, and software complexity.

UART is simple but requires an application framing and error strategy. SPI provides fast, low-overhead board-level transfers but needs separate selection and has limited standardization. I²C supports addressed multidrop operation with only two wires but is constrained by pull-up rise time and bus capacitance. CAN offers priority arbitration, error detection, and fault confinement for distributed control; LIN offers lower-cost scheduled communication. USB provides standardized host-managed connectivity, while Ethernet supplies scalable networking but requires additional layers for routing, reliability, security, and real-time behaviour. Industrial and wireless protocols must be selected with attention to profiles, certification, interference, lifecycle, and operational risk.

Successful communication design is a system activity. It requires physical-layer engineering, protocol-stack definition, timing and capacity analysis, defensive software, fault recovery, security, safety, conformance testing, and maintainable diagnostics.

Key Terms

UART: Asynchronous serial peripheral that transmits framed characters.

Baud rate: Number of signalling symbols transmitted per second.

SPI: Synchronous serial bus commonly using clock, data, and chip-select signals.

I²C: Two-wire addressed bus using open-drain signalling and pull-up resistors.

CAN: Message-oriented, fault-tolerant controller network with priority arbitration.

LIN: Low-cost, master-scheduled single-wire network.

USB: Host-controlled universal serial bus with enumeration and defined transfer types.

Ethernet: IEEE local-area networking technology using frames and MAC addressing.

Arbitration: Process by which competing transmitters determine which may use a shared medium.

Determinism: Predictability of communication timing.

Latency: Time from transmission request to data availability.

Jitter: Variation in communication latency or timing.

Payload: Application data carried by a protocol frame.

Protocol overhead: Non-payload information and timing required for communication.

CRC: Cyclic redundancy check used to detect transmission errors.

Bus-off: CAN state in which a node disconnects itself after excessive errors.

Interoperability: Ability of independently developed systems to exchange and interpret data.

TSN: Time-Sensitive Networking extensions for bounded and synchronized Ethernet traffic.

Transceiver: Circuit that converts controller signals to and from a physical medium.

Functional safety: Reduction of risk from hazardous system failures through defined safety measures.

Review Questions

Short Answer Questions

1. Why is UART described as asynchronous, and what must both endpoints agree upon?

2. Explain the purpose of chip-select signals in SPI.

3. Why do I²C lines require pull-up resistors?

4. What is non-destructive arbitration in CAN?

5. Distinguish Ethernet frame integrity from reliable end-to-end delivery.

Long Answer Questions

1. Compare UART, SPI, and I²C in terms of topology, wiring, timing, addressing, error handling, and typical applications.

2. Explain CAN frame arbitration and fault confinement, and discuss their importance in distributed control.

3. Describe USB enumeration and compare bulk, interrupt, and isochronous transfers.

4. Discuss how industrial protocol profiles improve interoperability beyond a basic transport protocol.

5. Explain the architecture of a secure, maintainable embedded communication stack.

Analytical / Application Questions

1. A device uses 8-N-1 UART at 230,400 bit/s. Estimate the ideal time to transmit 2,000 bytes and state the assumptions behind the calculation.

2. Design a communication architecture for a robotic cell containing local sensors, servo drives, a safety controller, and an Ethernet-connected manufacturing system. Justify protocol choices using latency, determinism, safety, and interoperability.

3. A CAN network experiences increasing error counters and intermittent bus-off events after a cable extension. Propose a structured diagnosis covering termination, signal integrity, bit timing, grounding, electromagnetic interference, and traffic load.

Multiple Choice Questions with Answers

Question 1

Which UART format transmits ten line bits for each 8-bit data byte?

A. 7-E-1

B. 8-N-1

C. 8-E-2

D. 9-N-1

Correct Answer: B. 8-N-1

Question 2

Which SPI parameter pair determines the clock idle level and the edge used for data sampling?

A. Baud rate and parity

B. Address and acknowledgement

C. CPOL and CPHA

D. CRC and timeout

Correct Answer: C. CPOL and CPHA

Question 3

Why are I²C pull-up resistors necessary?

A. They generate the serial clock internally

B. They return open-drain lines to the logic-high state

C. They terminate the bus at both physical ends

D. They encode the slave address

Correct Answer: B. They return open-drain lines to the logic-high state

Question 4

In CAN arbitration, which message normally has higher priority?

A. The message with the numerically lowest identifier

B. The message with the longest payload

C. The message transmitted by the physically nearest node

D. The message with the numerically highest identifier

Correct Answer: A. The message with the numerically lowest identifier

Question 5

What is a defining feature of LIN communication?

A. Token passing among equal controllers

B. Master-controlled scheduling

C. Mandatory IP routing

D. Full-duplex differential arbitration

Correct Answer: B. Master-controlled scheduling

Question 6

Which USB transfer type is intended for streams where timing is prioritized and retransmission-based reliability is generally not provided?

A. Control

B. Bulk

C. Interrupt

D. Isochronous

Correct Answer: D. Isochronous

Question 7

What does an Ethernet frame check sequence primarily provide?

A. Encryption of the payload

B. Detection of frame corruption

C. Guaranteed end-to-end delivery

D. Application-layer addressing

Correct Answer: B. Detection of frame corruption

Question 8

A 1 Mbit/s link has frames with 8 payload bytes and 8 overhead bytes, ignoring gaps and retransmissions. What is the ideal payload throughput?

A. 31,250 bytes/s

B. 62,500 bytes/s

C. 125,000 bytes/s

D. 500,000 bytes/s

Correct Answer: B. 62,500 bytes/s

Question 9

Which protocol is most directly associated with high-priority, message-oriented distributed control and fault confinement?

A. CAN

B. UART

C. USB

D. BLE

Correct Answer: A. CAN

Question 10

Which statement best distinguishes a checksum from cryptographic authentication?

A. A checksum provides confidentiality, while authentication provides compression

B. A checksum detects accidental corruption, while authentication helps verify origin and integrity against attackers

C. A checksum guarantees delivery, while authentication controls baud rate

D. A checksum performs encryption, while authentication removes protocol overhead

Correct Answer: B. A checksum detects accidental corruption, while authentication helps verify origin and integrity against attackers