Modern mobile machinery contains more electronic devices than ever before.
Construction equipment, agricultural machines, mining vehicles, and special-purpose vehicles may integrate:
Engine ECUs
Sensors
Joysticks
Telematics units
Many of these devices communicate through CAN Bus. As machine architectures become more complex, however, connecting every device to a single CAN network may not be the best solution.
This is why modern mobile machinery controllers often provide multiple CAN interfaces.
Multiple CAN channels allow engineers to separate different subsystems, manage network traffic, support different protocols and baud rates, and build more flexible machine architectures.
A simple machine may use one CAN network to connect several devices.
For example:
Engine ECU
↓
Controller
↓
HMI
↓
I/O Module
As more devices and functions are added, the same CAN network may also need to carry:
Engine data
Hydraulic commands
Operator inputs
Diagnostic messages
Sensor information
HMI data
This increases network complexity.
Instead of placing everything on one bus, engineers can divide the system into several CAN networks.
For example:
CAN 1 → Engine / J1939
CAN 2 → Hydraulic System
CAN 3 → HMI / Remote I/O
The main controller can communicate with all three networks while keeping their traffic separated.
One of the main reasons for using multiple CAN interfaces is network segmentation.
A mobile machine may contain several relatively independent systems.
For example:
This network may include:
Engine ECU
Transmission controller
Battery or power management system
J1939 is commonly used for communication in this part of the machine.
Another CAN channel may connect:
Hydraulic controllers
Valve controllers
Joysticks
Remote I/O modules
This network handles commands and feedback related to machine movement.
A separate network can be used for:
HMI displays
Keypads
Operator controls
Auxiliary devices
Separating these systems makes the overall electronic architecture easier to manage.
Not every electronic device on a machine uses the same CAN protocol.
A machine may simultaneously use:
SAE J1939
CANopen
Proprietary CAN protocols
For example, the engine may communicate through J1939 while a remote I/O module uses CANopen.
Multiple CAN interfaces allow the main controller to communicate with these networks separately.
J1939 Network
↓
CAN 1
↓
Main Controller
↑
CAN 2
↑
CANopen Network
This is particularly useful when OEM manufacturers need to integrate components from different suppliers.
Different CAN networks may operate at different communication speeds.
For example, one subsystem may use:
250 kbps
while another uses:
500 kbps
Devices operating at different CAN baud rates cannot normally share the same physical CAN network directly.
With multiple CAN interfaces, each channel can be configured according to the requirements of its connected devices.
For example:
CAN 1 → J1939 → 250 kbps
CAN 2 → CANopen → 500 kbps
CAN 3 → Custom CAN → Application-specific setting
This gives OEM engineers greater flexibility when integrating existing components.
Every CAN message occupies communication bandwidth.
As more devices and messages are added, bus utilization increases.
High bus load can lead to:
Increased message latency
More competition for bus access
Reduced communication margin
Difficulty adding new devices
Instead of sending all messages through one network, multiple CAN interfaces allow traffic to be distributed across different buses.
For example:
Single CAN Network
Engine + HMI + I/O + Hydraulics + Sensors
↓
Higher Bus Load
Compared with:
CAN 1 → Engine
CAN 2 → Hydraulics
CAN 3 → HMI + I/O
Network segmentation can make communication architecture more manageable as machine functions increase.
CAN networks in mobile machinery operate in demanding environments.
Possible problems include:
Wiring damage
Connector failures
Short circuits
Incorrect termination
Faulty CAN nodes
If every electronic device is connected to one CAN network, a serious network fault may affect communication between many machine systems.
Separating subsystems across multiple CAN channels can help limit the scope of some communication failures.
For example, a fault on an auxiliary-device CAN network does not necessarily have to interrupt the separate engine communication network.
The exact behavior depends on the machine architecture and fault type, but network segmentation provides engineers with more options for fault management.
Multiple CAN networks can also simplify diagnostics.
If the machine has clearly separated networks, engineers can determine whether a communication problem belongs to:
Powertrain
Hydraulic system
Operator interface
Auxiliary equipment
Instead of analyzing one large CAN network containing every device, technicians can troubleshoot individual network segments.
This can make it easier to identify:
Missing CAN messages
Bus errors
Failed nodes
Wiring problems
Abnormal network load
For machines operating in the field, faster troubleshooting can help reduce maintenance time.
Mobile machinery platforms often evolve over time.
An OEM may later add:
New attachments
Additional sensors
Remote I/O
Another HMI
Telematics equipment
Automated functions
If the original CAN network is already heavily loaded or uses a different protocol, adding new devices may require major changes.
Multiple CAN interfaces provide additional communication capacity for future expansion.
For example:
CAN 1 → Existing Powertrain
CAN 2 → Machine Control
CAN 3 → New Attachment
CAN 4 → Telematics / Additional Equipment
This helps OEMs create scalable electronic architectures that can support different machine configurations.
A controller with multiple CAN interfaces can do more than simply connect to several networks.
Depending on the controller software and system design, it can also exchange selected information between them.
For example:
Engine ECU
↓
J1939 / CAN 1
↓
Main Controller
↓
CAN 2
↓
HMI Display
The controller can receive engine information from one network, process the required data, and make relevant information available to another subsystem.
This can be useful when integrating devices that use different network structures or communication requirements.
However, gateway behavior should be carefully designed to avoid unnecessary traffic and ensure that critical messages are handled correctly.
Consider a modern wheel loader.
Its electronic architecture might include:
Connects:
Engine ECU
Transmission system
Protocol:
SAE J1939
Connects:
Main controller
Remote I/O
Hydraulic control devices
Connects:
HMI
Keypad
Other operator devices
The main controller acts as the central control node while communicating independently with each network.
This architecture allows different machine systems to remain organized while still exchanging the information required for coordinated operation.
The number of CAN interfaces alone does not determine whether a controller is suitable for an application.
Engineers should also evaluate:
CAN protocol support
Configurable baud rates
CAN isolation requirements
Network load
Number of connected nodes
Diagnostic capabilities
Software configuration
Environmental protection
The required number of CAN channels depends on the complexity of the machine and its electronic architecture.
A simple machine may only require one or two CAN interfaces, while more complex equipment may benefit from three or more independent channels.
Multiple CAN interfaces provide important flexibility for modern mobile machinery control systems.
By separating different subsystems, supporting multiple protocols and baud rates, distributing network traffic, and simplifying future expansion, multiple CAN channels help OEM manufacturers build more scalable electronic architectures.
As construction equipment, agricultural machinery, mining vehicles, and special-purpose machines integrate more intelligent electronic systems, multi-CAN controllers will become increasingly useful for managing communication across the entire machine.
SonnePower provides programmable controllers for mobile machinery with multiple communication interfaces for complex electronic control applications.
Our solutions support integration with:
J1939 devices
CANopen devices
HMI displays
Remote I/O modules
Hydraulic systems
Sensors and auxiliary equipment
Combined with programmable control logic and flexible I/O configurations, SonnePower controllers help OEM manufacturers build reliable and scalable electronic control systems for modern mobile machinery.
English
