Modern mobile machinery depends on CAN networks to exchange data between controllers, engine ECUs, sensors, HMI displays, and remote I/O modules.But what happens when an expected CAN message suddenly stops arriving?
A controller should not continue using outdated data indefinitely. Instead, it needs to detect the communication timeout, mark the data as invalid, and decide how the machine should respond.
A typical process is:
ECU / Sensor / Remote I/O
↓
CAN Message
↓
Mobile Controller
↓
Timeout Monitoring
↙ ↘ Message OK Timeout
↓
Fault Handling
↓
Warning / Safe Action
Communication timeout handling is therefore an important part of reliable mobile machinery control.
Many CAN devices transmit messages at regular intervals.
For example, an engine ECU may send engine speed every 100 ms, while a CAN sensor may periodically transmit pressure or position data.
The receiving controller monitors the time between messages.
If a new message does not arrive within a predefined period, the controller identifies a communication timeout.
For example:
Expected Message: Every 100 ms
Message Received → Data Valid
No Message for 500 ms → Timeout
Timeout → Data Invalid
The timeout value depends on the application, message frequency, and importance of the data.
A timeout does not necessarily mean that the CAN bus itself has completely failed.
Common causes include:
ECU or sensor power loss
Broken CAN wiring
Loose connectors
Incorrect CAN configuration
Device reset
CAN bus errors
Failed remote I/O module
Software or communication faults
Because different failures can produce the same symptom, the controller should record useful diagnostic information for troubleshooting.
Consider a pressure sensor that sends its value over CAN.
The last received value is:
Hydraulic Pressure = 180 bar
If communication is lost, the controller may still have 180 bar stored in memory.
But this does not mean the actual pressure is still 180 bar.
Continuing to use the old value as current machine data could result in incorrect control decisions.
For this reason, CAN data should normally have both a value and a validity status.
Pressure = 180 bar
Status = Valid
After a timeout:
Pressure = Last Received Value
Status = Invalid
The application logic can then respond appropriately.
Timeout detection is especially important when a mobile controller receives engine information through J1939.
Examples include:
Engine speed
Engine load
Coolant temperature
Oil pressure
Diagnostic information
A simplified process is:
Engine ECU
↓
J1939 Message
↓
Mobile Controller
↓
Timeout Monitoring
If an expected engine message disappears, the controller can generate an Engine ECU Communication Fault and prevent outdated engine information from being used as valid data.
Distributed mobile machinery systems often use remote I/O modules connected through CAN.
If communication with a remote I/O module is lost, the main controller may also lose access to several sensors and actuators at the same time.
For example:
Sensors / Valves
↓
Remote I/O
↓
CAN
↓
Main Controller
The controller should detect the missing remote I/O communication and execute a predefined fault strategy.
This may include disabling affected functions and notifying the operator.
There is no single answer for every application.
For some non-critical information, temporarily displaying the last valid value may be acceptable.
For control-related signals, however, continuing to use old data can create problems.
Possible strategies include:
Marking the value as invalid
Using a predefined fallback value
Limiting the affected function
Disabling an output
Entering a degraded operating mode
The correct strategy depends on what the data controls and the machine's risk assessment.
When a communication timeout occurs, the controller can send fault information to the HMI.
The operator may see messages such as:
Engine ECU Communication Lost
CAN Sensor Timeout
Remote I/O Offline
CAN Device Not Responding
Useful diagnostics can also record:
Device or node
Message identifier
Time of failure
Fault status
Number of occurrences
This information can make field troubleshooting much faster.
Communication recovery also needs to be considered.
The controller should verify that valid messages have resumed before returning to normal operation.
A simple strategy may be:
Communication Lost
↓
Timeout Fault Active
↓
Valid Messages Resume
↓
Data Validated
↓
Fault Cleared
↓
Normal Operation
For some machine functions, several consecutive valid messages may be required before the system considers communication stable again.
A timeout should not be too short or too long.
If it is too short, normal network delays may create unnecessary faults.
If it is too long, the controller may continue using outdated information for too much time.
OEM engineers should consider:
Normal message cycle time
Importance of the signal
CAN network load
Expected communication delays
Required machine response time
Failure strategy
For example, a message normally transmitted every 100 ms may use a timeout longer than one message cycle to avoid triggering a fault because of a single missed message.
CAN communication timeout handling is an important part of mobile machinery control system design.
When an ECU, sensor, or remote I/O module stops transmitting expected data, the controller should detect the missing messages, mark affected data as invalid, generate diagnostic information, and execute an appropriate fault strategy.
A well-designed timeout strategy prevents outdated CAN data from being treated as current machine information and helps improve system reliability and troubleshooting.
English
