9. Communication Interfaces and Industrial Networks

Introduction and Context

A microprocessor or microcontroller rarely operates as an isolated computational device. Its value is realized through communication with sensors, actuators, memory devices, displays, motor drives, supervisory computers, and other controllers. Communication interfaces provide the electrical and logical means by which these devices exchange information. Industrial networks extend this exchange across machines, production cells, buildings, and enterprise systems.

The choice of an interface is not merely a programming decision. It involves data rate, distance, wiring, timing, electrical noise, cost, topology, determinism, fault containment, interoperability, and safety. A short-distance sensor connection may require only two signal lines, whereas a distributed motion-control system may require synchronized, deterministic, and fault-tolerant communication. Consequently, engineers must understand both protocol operation and the system context in which a protocol is deployed.

This chapter examines UART, SPI, I²C, CAN, USB, and Ethernet. The first three are commonly used for local device-to-device communication. CAN is designed for robust shared-bus communication and is widely used in vehicles and industrial control. USB provides standardized host-oriented peripheral connectivity, while Ethernet supports scalable local and industrial networks. The central objective is not to memorize frame formats, but to evaluate which communication architecture is appropriate for a given engineering problem.

Learning Objectives

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

1. Explain the electrical, timing, and logical operation of UART, SPI, I²C, CAN, USB, and Ethernet.

2. Select an interface according to distance, bandwidth, topology, determinism, cost, and environmental conditions.

3. Calculate or interpret baud rate, bit time, bus utilization, transmission latency, and timing margins.

4. Design suitable error-detection, timeout, retransmission, and recovery mechanisms.

5. Compare master–slave, host–device, peer-to-peer, and multi-master communication models.

6. Apply industrial networking principles to embedded and automation systems.

7. Diagnose common interoperability, grounding, termination, and configuration problems.

8. Evaluate emerging communication trends, including real-time Ethernet, time synchronization, and cybersecurity requirements.

Communication as a Layered Engineering Problem

A communication interface can be understood through several interacting layers. At the physical layer, voltage levels, connectors, transmission media, impedance, and signaling determine whether bits can be transferred reliably. The data-link layer defines framing, addressing, arbitration, error detection, and acknowledgement. Higher layers define message meaning, device configuration, diagnostics, and application behavior.

This separation is useful because the same physical technology may support different application protocols. Ethernet, for example, can carry TCP/IP traffic, industrial protocols, audio streams, or proprietary messages. Similarly, CAN defines robust bus access and framing, while CANopen and DeviceNet define application-level conventions.

Important performance quantities include:

• Bit time: the duration of one transmitted bit, equal to the reciprocal of the bit rate.
• Baud rate: the number of signaling symbols per second. In common binary serial links, baud rate and bit rate are often numerically equal, but they are not conceptually identical.
• Throughput: useful application data delivered per unit time after protocol overhead.
• Latency: the time between a request and the corresponding response or between data generation and reception.
• Jitter: variation in latency or timing from one transmission to another.
• Determinism: the extent to which a communication delay can be bounded and predicted.
• Bus utilization: the fraction of available communication capacity occupied by valid traffic.

A design that maximizes nominal data rate may still be unsuitable if it has excessive jitter, poor noise immunity, or inadequate error recovery. Industrial systems usually optimize predictable behavior and maintainability rather than peak speed alone.

UART: Simple Asynchronous Serial Communication

The Universal Asynchronous Receiver/Transmitter, or UART, converts parallel data inside a processor into a serial bit stream and reconstructs received serial data. It does not normally provide addressing, arbitration, or a complete network protocol. These functions must be added by software or by a higher-level protocol.

A typical UART character consists of an idle state, a start bit, between five and nine data bits, an optional parity bit, and one or more stop bits. In the common 8-N-1 format, eight data bits are transmitted with no parity and one stop bit. Each character therefore occupies ten bit times: one start bit, eight data bits, and one stop bit. At 115,200 bit/s, the ideal character rate for 8-N-1 is approximately 11,520 characters per second before additional protocol overhead.

UART is asynchronous because the transmitter and receiver do not share a clock line. Both sides are configured with nominally identical baud rates and data formats. The receiver detects the falling edge of the start bit and samples the data bits near their centers. Baud-rate mismatch, clock inaccuracy, distortion, and excessive cable delay reduce the timing margin. A receiver may report framing errors when the expected stop-bit level is not detected, parity errors when parity does not match, or overrun errors when a new character arrives before software or hardware has read the previous one.

UART is normally point-to-point at the logic level. For longer cables or electrically noisy environments, a transceiver can convert logic signals to standards such as RS-232, RS-422, or RS-485. These standards should not be confused with UART itself. UART describes the serial data format and timing; RS-485, for example, describes a differential physical layer capable of supporting a multidrop bus when appropriate termination and driver control are used.

A reliable UART application generally uses a defined frame structure containing a synchronization field, address or message type, payload length, data, and checksum or cyclic redundancy check (CRC). Timeouts are essential because an asynchronous link can lose a byte or become disconnected. A receiver should also reject impossible lengths and resynchronize after corrupted data rather than waiting indefinitely.

SPI: High-Speed Synchronous Peripheral Communication

The Serial Peripheral Interface, or SPI, is a synchronous serial interface commonly used between a microcontroller and displays, converters, flash memories, sensors, and radio modules. A conventional SPI connection uses serial clock (SCLK), master-out/slave-in (MOSI), master-in/slave-out (MISO), and chip-select (CS) signals. The master generates the clock and selects a slave by asserting its chip-select line.

SPI has very little protocol overhead and can operate at high clock frequencies over short distances. However, it does not define a universal frame format, device address, acknowledgement mechanism, or error-detection field. Different devices may use different word lengths, command formats, and chip-select conventions. SPI clock polarity and phase are described by four modes, determined by the idle level of the clock and the edge on which data is sampled.

The absence of addressing is both an advantage and a limitation. Multiple slaves can share SCLK and data lines if each has a separate chip-select. This consumes processor pins as the number of slaves grows. Daisy-chain arrangements reduce chip-select requirements but impose device-specific timing and data-order constraints. Tri-state behavior on MISO is essential when several slaves share the line; a defective or incorrectly configured slave can corrupt the bus by driving it continuously.

SPI is appropriate when low latency and high local bandwidth are more important than cable length, interoperability, or built-in fault handling. Engineers should examine setup time, hold time, clock-to-output delay, signal integrity, chip-select timing, and maximum trace or cable length. At high speed, ground reference, return-current paths, impedance discontinuities, and simultaneous switching become significant.

I²C: Addressed Two-Wire Bus Communication

I²C, or Inter-Integrated Circuit, uses two open-drain or open-collector lines: serial data (SDA) and serial clock (SCL). Pull-up resistors return both lines to the logic-high state. Devices assert a low level but do not actively drive a high level. This wired-AND behavior allows arbitration and clock stretching.

Communication begins with a START condition, in which SDA changes from high to low while SCL is high. A slave address and read/write bit follow. Each transmitted byte is followed by an acknowledgement bit. A STOP condition occurs when SDA changes from low to high while SCL is high. Standard addressing commonly uses seven-bit addresses, although ten-bit addressing is also defined. Some addresses are reserved for special purposes.

Because the bus is open-drain, the rising edge is determined by the pull-up resistor and the total bus capacitance. A resistor that is too large produces slow rising edges and timing violations; a resistor that is too small increases sink current and power dissipation. The maximum practical bus speed and capacitance therefore depend on the electrical implementation, not only on the nominal protocol mode.

I²C supports multiple controllers in principle. Arbitration is performed by monitoring the bus while transmitting: a controller that sends a high but observes a low has lost arbitration. Clock synchronization permits a controller that holds SCL low to slow the bus. A slave may also use clock stretching to delay the controller until it is ready, although some modern controllers and bridges do not support this reliably.

Typical failures include incorrect slave addresses, missing pull-ups, excessive capacitance, address conflicts, a slave holding SDA low, and software that fails to recover a stuck bus. A practical recovery method may toggle SCL several times and then generate a STOP condition, provided that the system design permits such action. I²C is well suited to low- and moderate-speed board-level communication, but it is generally less suitable than differential industrial buses for long cables and severe electromagnetic interference.

CAN: Arbitration and Fault Containment on a Shared Bus

Controller Area Network (CAN) was designed for robust distributed control. It uses differential signaling, usually through a twisted pair, and permits multiple nodes to access a shared bus. A CAN frame includes an identifier, control information, data, and a CRC. Classical CAN carries up to eight data bytes per frame, while CAN FD permits larger payloads and a faster data phase.

CAN uses nondestructive bitwise arbitration. A dominant bit overwrites a recessive bit. During arbitration, a node that transmits recessive but observes dominant withdraws without corrupting the winning frame. The identifier therefore influences priority: lower numerical identifiers generally have higher priority under the conventional arbitration convention. This mechanism avoids collisions but can cause starvation of low-priority messages if bus loading and scheduling are poorly designed.

CAN provides several error mechanisms, including bit monitoring, bit stuffing checks, frame-format checks, acknowledgement checks, and CRC. Nodes maintain transmit and receive error counters. Depending on the error state, a node may remain error active, become error passive, or enter a bus-off state. Bus-off behavior is important because it prevents a persistently defective node from continuously disturbing the network.

The physical network requires correct termination, commonly at both ends of a linear bus. Unnecessary stubs, incorrect cable impedance, poor grounding, and excessive common-mode voltage can cause intermittent faults. CAN is not inherently a complete application protocol. CANopen, J1939, and other higher-level protocols define device profiles, parameterization, message meaning, and network management.

CAN timing must be analyzed with respect to propagation delay, oscillator tolerance, synchronization segments, sample point, and the longest physical path. In a heavily loaded bus, high-priority frames may experience bounded but increasing delay, while low-priority traffic may suffer substantial latency. Thus, message priority must be assigned according to control consequences, not convenience.

USB: Host-Centered Peripheral Connectivity

Universal Serial Bus (USB) is a standardized serial interface intended primarily for connecting peripherals to a host. The host controls bus enumeration, assigns addresses, selects configurations, and schedules transactions. A peripheral normally does not transmit whenever it wishes; it communicates through transactions initiated or permitted by the host.

USB uses a tiered topology involving hosts, hubs, and devices. Devices describe their capabilities through descriptors, allowing the host operating system to identify interfaces and endpoints. Transfer types include control transfers for configuration, bulk transfers for reliable high-volume data, interrupt transfers for bounded polling latency, and isochronous transfers for time-sensitive streams where occasional loss may be preferable to retransmission delay.

USB variants differ substantially in signaling rate, connector, power capability, cable requirements, and protocol details. Therefore, compatibility should not be inferred solely from the presence of a USB connector. Embedded designers must consider enumeration behavior, suspend and resume states, power negotiation, driver support, electromagnetic emissions, and connector reliability.

USB is highly effective for replacing proprietary peripheral interfaces and connecting embedded equipment to computers. It is less naturally suited to deterministic peer-to-peer industrial control because the host controls communication and operating-system scheduling may introduce variable latency. Ruggedized industrial USB solutions may still be useful for configuration, data logging, firmware update, and service access.

Ethernet and Industrial Ethernet

Ethernet is a family of packet-based networks used from embedded boards to enterprise systems. Modern switched Ethernet normally uses full-duplex links, so collisions are not expected on an individual switch port. Frames contain destination and source addresses, a type or length field, payload, and a frame check sequence. Switches forward frames according to learned addresses, while higher layers provide logical addressing, routing, transport, and application services.

Ethernet offers high bandwidth, broad interoperability, long-distance options through copper or fiber, and a mature ecosystem. Its traditional best-effort operation does not by itself guarantee bounded latency. Industrial Ethernet protocols address this limitation in different ways. Some use carefully scheduled traffic, dedicated hardware, time synchronization, traffic prioritization, or specialized frames. Examples include EtherCAT, PROFINET, EtherNet/IP, and Modbus TCP, although their real-time behavior and application models differ.

A useful design distinction is between ordinary information traffic and control traffic. A supervisory dashboard may tolerate occasional delays and retransmissions. A coordinated servo system may require precise synchronization and bounded delay. Quality-of-service mechanisms, network segmentation, managed switches, redundant paths, and accurate time sources can improve performance, but they do not automatically make an arbitrary Ethernet network deterministic.

Time-Sensitive Networking (TSN) extends standardized Ethernet with mechanisms for time synchronization, traffic scheduling, and bounded transmission behavior. TSN is relevant where industrial control, audio/video, and ordinary information technology must share infrastructure. Its successful use requires coordinated configuration of endpoints, switches, clocks, and application schedules.

Selecting an Interface: A Systems Framework

Interface selection should begin with requirements rather than familiarity. The engineer should identify the number of nodes, physical distance, required data volume, maximum acceptable latency, allowable jitter, environmental noise, power constraints, serviceability, and expected product life. The choice can then be evaluated against the following questions:

• Is the communication point-to-point, multidrop, switched, or routed?
• Is communication controller-initiated, peer-to-peer, or event-driven?
• Must delivery be guaranteed, or can the application tolerate loss?
• Is deterministic timing required?
• What happens when a cable is disconnected or a node fails?
• Are standardized connectors, drivers, diagnostic tools, and replacement devices available?
• Does the physical layer require isolation, shielding, termination, or surge protection?
• Can the processor handle interrupts, buffering, protocol parsing, and security functions?

UART is economical for point-to-point links and debugging. SPI is efficient for short, high-speed board-level peripherals. I²C minimizes pins when several low-speed devices share a board bus. CAN is appropriate for robust distributed control with message priority and strong error confinement. USB is suitable for standardized host-peripheral connectivity. Ethernet is preferred when interoperability, high bandwidth, network integration, or substantial physical reach is required.

No comparison is absolute. A product may use several interfaces simultaneously: SPI for local sensors, I²C for configuration devices, CAN for machine control, Ethernet for supervisory communication, and USB for maintenance. Gateways must translate not only data formats but also timing assumptions, error semantics, and device states.

Timing, Buffering, and Error Handling

Protocol timing should be analyzed quantitatively. If a frame contains F bits and the link rate is R bits per second, its serialization time is approximately F/R. The total transaction time also includes propagation, processing, arbitration, inter-frame gaps, acknowledgements, and possible retransmissions. For periodic traffic, bus utilization can be estimated by summing the transmission time of all messages over a scheduling interval and dividing by that interval.

Buffering protects a processor from short bursts, but it does not solve sustained overload. A receive buffer that fills faster than software can service it will eventually overflow. Direct memory access, interrupt thresholds, ring buffers, and flow control can reduce processor load. However, flow control must be coordinated with the protocol and must not create deadlock.

Error handling should distinguish corruption, loss, duplication, delay, and invalid application content. A CRC can detect many transmission errors, but it cannot prove that the message is semantically correct or that it came from an authorized source. Sequence numbers detect loss and duplication; timeouts detect missing responses; acknowledgements indicate different things depending on the protocol. Recovery actions may include retransmission, reinitialization, fallback operation, isolation of a failed node, or transition to a safe state.

A robust implementation uses finite-state machines rather than loosely connected conditional statements. The state machine should define startup, normal exchange, timeout, malformed-frame, link-loss, recovery, and shutdown behavior. Diagnostic counters should record events such as CRC failures, framing errors, arbitration loss, buffer overflow, retries, and bus-off transitions.

Applied Case: Distributed Pump-Control System

Background

Consider an illustrative industrial water-treatment skid containing four variable-speed pumps, pressure and flow sensors, a safety controller, a local operator panel, and a supervisory computer. The skid operates in a noisy motor environment and must continue in a controlled state if the supervisory computer is disconnected.

Situation and Problem

The original prototype connected sensors through I²C cables several metres long and used a USB connection to the supervisory computer for control commands. Intermittent sensor readings occurred when motors started. In addition, pump coordination depended on commands from the computer, so a software crash could leave the local control behavior uncertain.

Analysis

I²C was inappropriate for the long, noise-exposed sensor wiring because its single-ended open-drain signaling and capacitance-dependent rise time provided limited margin. USB offered convenient computer connectivity but was not suitable as the sole control path because it is host-centered and dependent on the computer's operating system. Pump commands also required predictable priority and local fault handling.

Approach and Solution

The redesigned system used short SPI connections between each controller board and local high-resolution converters. A differential CAN bus connected the pump controllers, safety controller, and pressure-control node. Message identifiers were assigned according to control priority: emergency and shutdown messages had the highest priority, followed by pressure feedback and pump commands, with diagnostics assigned lower priority.

The supervisory computer communicated through Ethernet to a gateway. The gateway mapped supervisory requests to CAN messages but did not become essential to the closed-loop safety function. USB was retained as a service interface for firmware updates and commissioning. Both CAN ends were correctly terminated, cable routing was separated from high-power motor conductors, and galvanic isolation was applied where ground potential differences were expected.

Each controller implemented watchdog supervision, message freshness checks, CRC or protocol-level validation where applicable, timeout detection, and a defined safe reaction. The system recorded bus errors, lost messages, and gateway disconnections. A test plan deliberately introduced unplugged nodes, excessive bus load, corrupted frames, and computer restarts.

Outcome

The revised architecture separated local control from supervisory functions, reduced susceptibility to motor noise, and made failure behavior explicit. The system could continue pressure regulation under loss of the supervisory link, while operators received diagnostic information after reconnection. The case also illustrates that a gateway is not merely a format converter: it must preserve priority, timing, state, and fault semantics.

Learning Points

The appropriate interface depends on physical conditions and control responsibility. Short-distance peripheral buses should not automatically be extended into industrial wiring. Supervisory connectivity and real-time control should be separated when their reliability requirements differ. Finally, error handling and safe-state behavior must be designed alongside the communication protocol rather than added after hardware integration.

Security, Governance, and Professional Practice

Connectivity increases the attack surface of embedded systems. UART debugging ports may expose bootloaders; USB devices may accept malicious firmware or unexpected descriptors; Ethernet nodes may be scanned, spoofed, or flooded; and a CAN bus generally authenticates neither node identity nor message origin by itself. Security measures may include disabling unused interfaces, secure boot, signed firmware, access control, network segmentation, authenticated diagnostics, encryption where appropriate, and monitored update procedures.

Security must be balanced against real-time constraints and resource limitations. Encryption can increase processing time and message size, while aggressive filtering may interfere with maintenance. Safety and cybersecurity should be coordinated because a security response, such as isolating a node, must not create an unsafe physical condition.

Professional practice requires traceable interface specifications. A specification should state electrical levels, connector pinout, baud or clock rate, frame format, timing limits, addressing, termination, fault reactions, versioning, and test conditions. Interoperability claims should be verified with actual devices, not inferred from nominal protocol names. Standards compliance, electromagnetic compatibility, functional safety, and applicable industry regulations must be considered for the target application.

Emerging Directions and Best Practices

Industrial communication is moving toward convergence: one infrastructure increasingly carries control, diagnostics, safety-related information, maintenance data, and analytics. Time synchronization, edge computing, software-defined gateways, and TSN are enabling more coordinated systems. CAN FD and higher-speed industrial Ethernet reduce the pressure caused by growing data volumes. Digital twins and predictive maintenance systems use communication data to estimate equipment condition, but their usefulness depends on trustworthy timestamps and data quality.

Effective design practices include:

1. Define communication requirements before selecting a protocol.

2. Separate physical-layer, data-link, and application specifications.

3. Calculate worst-case latency and bus utilization instead of relying on nominal data rate.

4. Use correct termination, grounding, shielding, isolation, and connector practices.

5. Design explicit startup, timeout, retry, reset, and safe-state behavior.

6. Reserve bandwidth for high-priority traffic and prevent starvation.

7. Test with noise, disconnection, malformed frames, overload, clock variation, and power cycling.

8. Provide diagnostic counters, timestamps, logging, and service tools.

9. Control protocol versions and document interoperability assumptions.

10. Treat cybersecurity, safety, and maintainability as system requirements.

Chapter Summary

Communication interfaces connect processors with peripherals, controllers, and supervisory systems. UART provides simple asynchronous point-to-point communication; SPI offers fast synchronous local transfers; I²C provides an addressed two-wire bus; CAN combines differential signaling, priority arbitration, error detection, and fault confinement; USB supplies standardized host-peripheral connectivity; and Ethernet supports scalable packet networking and industrial integration. Interface selection must consider bandwidth, latency, determinism, topology, noise, distance, buffering, fault behavior, and maintainability. Robust systems use layered protocols, quantitative timing analysis, explicit recovery states, suitable physical design, and security controls. Industrial architectures commonly combine several interfaces, using gateways to preserve—not merely translate—data meaning, timing, priority, and fault semantics.

Key Terms

UART: Hardware that performs asynchronous serial transmission and reception.

Baud rate: Number of signaling symbols transmitted per second.

Parity: A simple error-detection bit added to a character.

SPI: Synchronous master-controlled serial interface for local peripherals.

Chip select: Signal used to select an SPI slave device.

I²C: Two-wire addressed serial bus using open-drain signaling.

Clock stretching: A method by which an I²C device holds the clock low to delay communication.

CAN: Differential, multi-node control network with nondestructive arbitration.

Dominant bit: CAN bus state that overrides a recessive state.

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

USB enumeration: Host-controlled process of identifying and configuring a USB device.

Endpoint: Logical USB source or destination for data transfers.

Ethernet: Packet-based networking technology used for local and industrial communication.

CRC: Polynomial error-detection code calculated over transmitted data.

Latency: Time between an event, request, or transmission and its required response.

Jitter: Variation in communication timing or latency.

Determinism: Predictability and boundedness of communication behavior.

Bus utilization: Proportion of communication capacity occupied by traffic.

Time-Sensitive Networking: Ethernet enhancements for synchronization and bounded traffic scheduling.

Gateway: Device that connects networks or protocols and translates their data and behavior.

Review Questions

Short Answer Questions

1. Why is UART called asynchronous, and what timing assumptions must its transmitter and receiver share?

2. Explain the purpose of pull-up resistors in an I²C bus.

3. What is nondestructive arbitration in CAN?

4. Distinguish USB host control from peer-to-peer communication.

5. Define latency, jitter, and determinism.

Long Answer Questions

1. Compare UART, SPI, and I²C with respect to wiring, speed, addressing, timing, and typical applications.

2. Explain CAN frame arbitration, error detection, error states, and termination requirements.

3. Discuss the architecture of Ethernet and the reasons ordinary Ethernet may require industrial enhancements.

4. Develop a systematic framework for selecting a communication interface for an embedded industrial system.

5. Explain how buffering, timeouts, sequence numbers, retries, and safe-state transitions contribute to robust communication.

Analytical / Application Questions

1. A controller must connect six short-distance sensors on one circuit board, using few processor pins. Which interface would you choose, and what electrical limitations must be checked?

2. A factory network carries periodic servo commands and irregular maintenance traffic. Explain how you would separate or schedule the traffic to reduce control jitter.

3. Design a communication architecture for a motor-control machine that must continue safe local operation when its supervisory computer or network cable fails. Justify the interfaces and fault-handling strategy.

22. Multiple Choice Questions with Answers

Question 1

A UART link uses the 8-N-1 format at 115,200 bit/s. Ignoring higher-level overhead, approximately how many complete characters per second can it transmit?

A. 1,152

B. 11,520

C. 92,160

D. 115,200

Correct Answer: B. 11,520

Question 2

Why must an SPI slave release its MISO output when it is not selected?

A. To increase the SPI clock frequency

B. To provide I²C-style clock stretching

C. To prevent contention with another selected slave

D. To generate the chip-select signal

Correct Answer: C. To prevent contention with another selected slave

Question 3

What primarily determines the rising-edge speed of an I²C signal?

A. The pull-up resistor and total bus capacitance

B. The SPI clock phase

C. The CAN identifier

D. The USB endpoint number

Correct Answer: A. The pull-up resistor and total bus capacitance

Question 4

In CAN arbitration, a node transmitting recessive but observing dominant will normally:

A. Continue transmitting and overwrite the dominant bit

B. Withdraw from arbitration without corrupting the winning frame

C. Immediately enter bus-off state

D. Reset every other node

Correct Answer: B. Withdraw from arbitration without corrupting the winning frame

Question 5

Which feature most directly makes CAN suitable for distributed control?

A. Host-controlled enumeration

B. Nondestructive priority arbitration and error confinement

C. Separate chip-select lines for every device

D. Dependence on operating-system drivers

Correct Answer: B. Nondestructive priority arbitration and error confinement

Question 6

Why is USB generally less suitable as the sole deterministic control network for an industrial machine?

A. USB cannot carry digital data

B. USB has no error detection

C. USB communication is primarily host-controlled and may have variable scheduling latency

D. USB requires differential signaling

Correct Answer: C. USB communication is primarily host-controlled and may have variable scheduling latency

Question 7

A system requires high bandwidth, network integration, and communication over substantial physical distance. Which interface is the most natural starting point?

A. Ethernet

B. I²C

C. SPI

D. UART at logic level

Correct Answer: A. Ethernet

Question 8

A gateway between Ethernet and CAN should preserve which property in addition to translating message formats?

A. Only the connector color

B. Priority, timing, state, and fault semantics

C. The exact number of Ethernet switch ports

D. The USB enumeration sequence

Correct Answer: B. Priority, timing, state, and fault semantics

Question 9

If a communication frame contains F bits and the link rate is R bits per second, its ideal serialization time is:

A. F × R

B. R/F

C. F/R

D. F + R

Correct Answer: C. F/R

Question 10

Which design response is most appropriate when a CAN node repeatedly generates errors and threatens network operation?

A. Disable all termination resistors

B. Use bus-off behavior or another defined isolation response

C. Lower the priority of emergency messages

D. Allow the node to transmit continuously

Correct Answer: B. Use bus-off behavior or another defined isolation response