Electronic communication bus protocols define how devices inside a product or system exchange data. For OEM electronics, the choice is not only a firmware decision. It affects PCB routing, connector selection, cable length, noise immunity, power consumption, test coverage, field diagnostics, and long-term manufacturability.

A sensor board, motor controller, medical device, industrial control module, or aerospace assembly may use more than one communication protocol. The right choice depends on where the communication happens: inside the PCB, between boards, through a wire harness, inside a vehicle, across a factory network, or into a cloud-connected monitoring system.

At ANZER, we look at communication protocols through the manufacturing lens: Can the board be routed cleanly? Can it be assembled repeatably? Can it be tested? Can the harness survive the environment? Can the product be diagnosed in the field?

What Is an Electronic Communication Bus Protocol?

An electronic communication bus protocol is a defined method for moving data between electronic devices. It may describe electrical signaling, timing, addressing, data framing, arbitration, error handling, or application-level messages.

The important point: not every “protocol” belongs to the same layer.

Some are board-level interfaces, such as I2C, SPI, and UART. Some define physical signaling, such as RS-485. Some are network or data-link systems, such as CAN and Ethernet. Some are higher-level industrial or IoT protocols, such as Modbus, SAE J1939, and MQTT.

That distinction matters because each layer creates different design and manufacturing risks.

Quick Comparison of Common Communication Protocols

Protocol / Interface	Typical Use	Best Fit	Main Manufacturing Risk
I2C	IC-to-IC communication on a PCB	Low-speed sensors, EEPROMs, board-local peripherals	Pull-up sizing, bus capacitance, addressing conflicts, short-distance limits
SPI	Microcontroller to peripheral communication	ADCs, DACs, displays, memory, high-speed board-local devices	Signal integrity, clock routing, chip-select routing, trace length
UART	Simple serial communication	Debug ports, point-to-point device communication	Voltage-level mismatch, connector documentation, limited native multi-drop support
RS-232	Point-to-point serial interface	Service ports, legacy equipment, industrial devices	Level shifting, grounding, connector pinout control
RS-485	Differential multi-node serial signaling	Industrial controls, long cable runs, Modbus RTU networks	Termination, biasing, isolation, topology, ESD protection
CAN / CAN FD	Robust multi-node communication	Automotive, industrial, mobile equipment, real-time control	Termination, stub length, transceiver selection, EMI, diagnostic planning
SAE J1939	Higher-layer vehicle network over CAN	Heavy-duty vehicles, off-highway equipment, ag systems	PGN/SPN documentation, network compatibility, harness integration
USB	Device and service connectivity	Programming, diagnostics, high-speed peripheral links	Controlled impedance, ESD, connector durability, cable compliance
Ethernet	Network communication	Industrial controllers, gateways, higher-bandwidth systems	Magnetics, isolation, impedance control, PHY layout, cybersecurity planning
Modbus RTU / TCP	Industrial automation data exchange	PLCs, meters, sensors, controls, factory systems	Addressing, line termination, register mapping, interoperability
MQTT	Publish/subscribe messaging for IoT	Remote monitoring, telemetry, cloud-connected equipment	Network security, broker dependency, payload structure, device identity
Bluetooth / BLE	Short-range wireless communication	Handheld configuration, mobile interfaces, low-power sensors	RF layout, antenna placement, enclosure effects, regulatory planning

Start With the Communication Location

Before selecting a bus protocol, define where the data must travel.

Inside the PCB

Board-local communication usually favors I2C, SPI, UART, or similar embedded interfaces. These are common between microcontrollers, sensors, memory devices, display controllers, power monitors, and support ICs.

For this type of communication, the main manufacturing questions are:

Are the traces routed cleanly with stable return paths?
Are pull-ups, terminations, and voltage levels correct?
Are test points available for bring-up and troubleshooting?
Will the bus still work after conformal coating or potting if those protections are required?
Can firmware be programmed and verified during production?

This is where electronic design for manufacturability matters. A protocol may work on the bench and still create issues when the board is assembled, tested, enclosed, and shipped.

Between Boards or Subassemblies

When communication moves between PCBAs inside the same enclosure, connector and harness decisions become more important. UART, CAN, RS-485, USB, and Ethernet may all appear in this space depending on speed, distance, and noise environment.

The design should define:

Connector type
Pinout
Cable length
Shielding requirement
Grounding approach
Expected data rate
ESD protection
Isolation requirement
Serviceability
Functional test method

This is where box build assembly services and wire harness and cable assembly become part of the protocol decision, not an afterthought.

Across Industrial Equipment

For factory and industrial equipment, RS-485, CAN, Ethernet, Modbus RTU, Modbus TCP, EtherNet/IP, and IO-Link-style systems may appear depending on the control architecture.

Industrial communication should be selected around noise, distance, diagnostic needs, service skill level, and interoperability with existing PLCs or controllers.

A clean RFQ should not say only “needs Modbus.” It should say whether the requirement is Modbus RTU over RS-485, Modbus TCP over Ethernet, expected baud rate, register map status, cable length, connector type, and test procedure.

Across Vehicles or Mobile Equipment

CAN and SAE J1939 are common in vehicles, heavy equipment, agricultural electronics, and other mobile systems. In these applications, the protocol decision affects the PCB, transceiver, harness, diagnostics, firmware, and field service workflow.

For vehicle-related electronics, define:

CAN or CAN FD requirement
J1939 or other higher-layer protocol requirement
Bitrate
Node count
Connector and harness environment
Diagnostic connector needs
Termination responsibility
Message database ownership
Test procedure for production

ANZER’s experience with industrial, automotive, agriculture, medical, and aerospace electronics makes this type of requirement easier to manage when the documentation is complete before assembly starts.

I2C: Good for Board-Level Simplicity

I2C is commonly used for short, board-level communication between a controller and low-speed peripherals. It uses a clock line and data line, which reduces pin count compared with interfaces that need more dedicated signals.

Use I2C when:

Devices are on the same PCB or very close together
Data rate requirements are modest
Multiple low-speed devices need to share a simple bus
Pin count is limited
The design can manage addressing and bus capacitance

Avoid treating I2C as a long-distance wiring solution. Long cables, noisy environments, weak pull-ups, high capacitance, or poor grounding can turn a simple interface into a field reliability problem.

Manufacturing note: include accessible test points for SDA, SCL, power, and ground where practical. If the design includes programming, calibration, or sensor verification, the production test plan should specify how I2C devices will be checked.

SPI: Strong for Fast Board-Level Peripheral Links

SPI is often used when a controller needs faster communication with memory, ADCs, DACs, displays, or other peripherals. It uses separate clock and data lines, which helps speed and timing control.

Use SPI when:

Throughput matters more than pin count
Devices are close to the controller
The design needs predictable timing
A clear master-to-peripheral structure is acceptable
The board can support additional chip-select routing

SPI can become messy when too many devices are added without a clean chip-select and routing plan. Clock integrity, trace length, return paths, and connector crossing should be reviewed early.

Manufacturing note: SPI failures can be hard to isolate if test access is poor. Define test points, programming headers, or fixture access before layout release.

UART, RS-232, and RS-485: Do Not Treat Them as the Same Thing

UART is a basic asynchronous serial interface used by many microcontrollers. RS-232 and RS-485 define electrical signaling methods that are often used with serial data.

That distinction matters.

UART may exist at logic-level voltage inside a board. RS-232 requires level conversion and is typically point-to-point. RS-485 uses differential signaling and is better suited for longer cable runs and multi-node industrial networks.

Use RS-485 when:

The system needs a rugged wired interface
Multiple devices share a line
The cable run is longer than a board-level link
The environment has electrical noise
Modbus RTU or another serial protocol is required

Common mistake: saying “RS-485 protocol” when the actual requirement is “Modbus RTU over RS-485.” RS-485 is the physical layer. Modbus defines the message structure.

Manufacturing note: RS-485 designs should define termination, biasing, isolation, connector pinout, cable type, and acceptable topology before the board reaches assembly.

CAN and CAN FD: Built for Shared, Rugged Control Networks

CAN is widely used when multiple controllers need reliable communication in noisy environments. Automotive and industrial systems use CAN because it supports multi-node communication, arbitration, and error handling.

CAN FD extends CAN with a more flexible data-rate approach and larger payloads, depending on system requirements.

Use CAN or CAN FD when:

Multiple controllers must communicate on a shared bus
Real-time behavior matters
The system must tolerate electrical noise
Diagnostics are important
The product belongs in automotive, industrial, mobile equipment, agriculture, or similar environments

CAN design is not only a firmware task. It requires the right transceiver, termination plan, connector strategy, cable design, ESD protection, and test method.

Manufacturing note: for production, define how the node will be programmed, addressed, verified, and tested on the bus. If a board passes electrical inspection but cannot communicate reliably inside the full assembly, the cost of rework rises quickly.

SAE J1939: CAN-Based Communication for Heavy-Duty Systems

SAE J1939 is a higher-layer communication system commonly used in heavy-duty vehicles and mobile equipment. It builds on CAN-based communication and defines message behavior for vehicle systems.

Use J1939 when:

The product must integrate with heavy-duty vehicle networks
The customer requires J1939 message compatibility
Diagnostics and parameter groups must be documented
The product connects into vehicle or equipment harnessing
Long-term serviceability matters

A J1939 RFQ should include message requirements, PGN/SPN expectations, connector requirements, environmental requirements, and how the device will be validated.

Related ANZER resource: SAE J1939 communication protocol.

USB and Ethernet: Higher-Speed Interfaces Need Layout Discipline

USB and Ethernet are common, but they add more layout and manufacturing sensitivity than simple low-speed interfaces.

USB may be used for programming, service access, data transfer, or device connectivity. Ethernet may be used for plant networks, gateways, test systems, industrial controllers, and connected equipment.

These interfaces often require:

Controlled impedance routing
Differential pair discipline
Connector ESD protection
Proper ground reference
PHY and magnetics layout review
Clear cable and enclosure planning
Functional test coverage

Manufacturing note: do not leave USB or Ethernet validation to the final build. If the design has high-speed interfaces, include DFM and design-for-test review early. See ANZER’s PCB manufacturing and assembly support and IPC total quality management pages for related quality context.

Modbus and MQTT: Application-Layer Protocols Need System Definition

Modbus and MQTT are often listed beside hardware buses, but they solve a different problem.

Modbus is common in industrial automation. It may run as Modbus RTU over RS-485 or Modbus TCP over Ethernet. MQTT is commonly used for publish/subscribe telemetry in IoT and remote monitoring systems.

Use Modbus when:

PLCs, meters, sensors, and industrial devices must exchange structured data
The system needs predictable register-based communication
Industrial maintenance teams need a familiar protocol

Use MQTT when:

Data must be published to a broker or cloud-connected system
Remote monitoring or telemetry matters
The system has network connectivity and security planning
Device identity and payload structure are defined

Manufacturing note: application-level communication still affects production. Functional test software must know what data to request, what response to expect, and what pass/fail limits apply.

How Protocol Choice Affects PCB Assembly

A communication protocol affects more than the schematic. It can influence the complete assembly path.

Manufacturing Area	Protocol-Related Risk
PCB layout	Trace length, differential pairs, controlled impedance, return path, crosstalk
Component selection	Transceivers, isolators, ESD parts, connectors, magnetics
Wire harness	Cable type, shielding, pinout, strain relief, connector locking
Box build	Routing path, separation from power wiring, service access, labeling
Testing	ICT access, programming access, functional test scripts, diagnostic readout
Compliance	EMC, ESD, safety, medical, aerospace, or customer-specific documentation
Field service	Diagnostic connector, firmware update method, readable fault data

This is why protocol selection should be part of custom electronic design solutions, not only firmware selection.

Common Mistakes to Avoid

Choosing a board-level bus for a cable-run problem

I2C and SPI are useful on PCBs, but they are not automatically suitable for long cables, external devices, or noisy environments. If the signal leaves the board, the design needs a stronger physical-layer decision.

Confusing the physical layer with the protocol

RS-485 is not the same as Modbus. Ethernet is not the same as Modbus TCP or MQTT. CAN is not the same as SAE J1939. The RFQ should define both the physical interface and the data protocol.

Forgetting termination and biasing

RS-485 and CAN networks depend on correct termination and topology. If the board, harness, and enclosure are developed separately, termination responsibility can become unclear.

Leaving ESD and isolation decisions too late

External communication ports are common entry points for electrical stress. ESD protection, surge protection, isolation, grounding, and connector selection should be reviewed before layout release.

Not planning production test access

A working prototype is not enough. The production team needs a practical method to program firmware, verify communication, read diagnostic data, and confirm pass/fail limits.

Treating wireless as only a software decision

Bluetooth, Wi-Fi, cellular, or other wireless interfaces affect antenna placement, enclosure material, PCB layout, EMI behavior, regulatory planning, and test method.

What to Include in a Communication Protocol RFQ

For a stronger PCB assembly or box build RFQ, include these details:

Product application and operating environment
Protocol or interface name
Physical layer, if separate from the protocol
Expected data rate or baud rate
Cable length or board-to-board distance
Connector type and pinout
Shielding and grounding expectations
Isolation requirement
ESD or surge protection requirement
Node count
Master/client or controller/device roles
Addressing plan
Register map, message database, or payload document
Firmware programming method
Production test requirements
Field diagnostic requirements
Regulatory or customer quality requirements
Environmental protection needs, such as conformal coating or potting

If the product is medical, aerospace, industrial, or automotive-adjacent, also include documentation and traceability expectations.

How ANZER Supports Communication-Heavy Electronics

ANZER supports OEM electronics from design review through PCB assembly, wire harnessing, box build, testing, and final packaging. For communication-heavy products, that means reviewing the practical manufacturing details that can decide whether the product works reliably after assembly.

ANZER can help with:

DFM and DFA review
PCB assembly for SMT, through-hole, and mixed-technology boards
Component sourcing support
Wire harness and cable assembly
Box build integration
Functional testing
ICT or flying probe strategy
Conformal coating and potting when environmental protection is required
Prototype, pre-production, and production support

For OEM teams, the goal is not simply to choose a familiar protocol. The goal is to build an assembly that communicates reliably, can be tested repeatedly, and can be supported in the field.

Related ANZER resources:

Conclusion

Electronic communication bus protocols should be selected with the complete product in mind: PCB layout, firmware, cable length, electrical noise, connector strategy, test access, documentation, and field service.

I2C, SPI, UART, CAN, RS-485, USB, Ethernet, Modbus, MQTT, and SAE J1939 each solve different problems. The right choice depends on where the data travels, how harsh the environment is, how the assembly will be tested, and what the product must do after it leaves the factory.

If your next product depends on reliable board-level, machine-level, vehicle-level, or networked communication, involve manufacturing early. ANZER can review your design, assembly requirements, and test strategy before avoidable communication issues become production problems.

Request a quote or contact ANZER to discuss your electronic assembly requirements.

FAQs

What are electronic communication bus protocols?

Electronic communication bus protocols are methods that define how electronic devices exchange data. They may cover electrical signaling, timing, addressing, message structure, error handling, or application-level communication.

What is the difference between I2C and SPI?

I2C uses fewer signal lines and is useful for low-speed board-level communication with multiple devices. SPI usually supports faster communication but needs more signals, especially when multiple peripheral devices require separate chip-select lines.

Is RS-485 a protocol?

RS-485 is better understood as an electrical signaling standard, not a full application protocol. A system may use Modbus RTU, a proprietary protocol, or another message structure over RS-485 wiring.

When should an OEM use CAN bus?

CAN is a strong fit when multiple controllers need reliable communication in noisy automotive, industrial, mobile equipment, or control-system environments. It is especially useful when diagnostics, arbitration, and rugged multi-node communication matter.

Why does protocol selection matter for PCB assembly?

Protocol selection affects PCB routing, connector choice, ESD protection, wire harness design, test access, firmware programming, functional testing, and field diagnostics. A poor protocol or layout decision can create failures that are expensive to fix after production starts.

Blog Post

Electronic Communication Bus Protocols for OEM Electronics