Designing a CAN Bus device that performs well under ideal conditions is relatively straightforward. The real challenge begins when the network no longer behaves as expected. In the field, connectors loosen, ECUs lose power, messages are delayed, wiring deteriorates, and configuration errors inevitably occur. A robust CAN device must continue operating safely—or at the very least fail gracefully—under these conditions.
Unfortunately, many developers spend most of their validation time confirming that their application works correctly when everything is functioning normally. They connect two or three nodes on a workbench, exchange messages, and declare the design complete. While this verifies basic functionality, it does little to reveal how the system behaves when the unexpected happens.
This article discusses practical failure scenarios that every CAN developer should consider during testing. Most of these tests require little more than a programmable CAN node, a few cables, and a willingness to intentionally “break” the network.
Why Failure Testing Matters
Every CAN network consists of multiple independent electronic control units (ECUs). Your application relies on these nodes to transmit data at the correct intervals, using valid values and proper communication parameters.
When one node behaves unexpectedly, every other node on the network must decide how to respond. Should the data be ignored? Should an error be reported? Should the application continue operating using previously received information? Or should the system transition into a safe operating mode?
These decisions cannot be evaluated unless the corresponding failure conditions are intentionally created during development.
1. Simulating a Missing ECU
One of the most common field failures is the complete loss of an ECU. This may be caused by a blown fuse, disconnected connector, damaged wiring, or simply a controller that failed to boot.
Typical tests include:
- Disconnecting one ECU during normal operation.
- Preventing one node from transmitting.
- Delaying startup of a critical controller.
Observe whether your application:
- Detects the missing node.
- Reports the timeout correctly.
- Continues operating safely.
- Recovers automatically when communication resumes.
A missing node should never leave the remainder of the network in an undefined state.
2. Delayed Periodic Messages
CAN applications often assume that periodic messages arrive at precise intervals. In reality, transmission timing may vary because of processor load, interrupt latency, or increased network traffic.
Instead of transmitting every 100 milliseconds, intentionally vary the interval to:
- 120 ms
- 200 ms
- 500 ms
- Random intervals
This allows you to verify whether timeout limits are realistic and whether your application tolerates minor timing variations without generating false alarms.
3. Unexpected Loss of Communication
Unlike a missing ECU at startup, a more realistic situation occurs when communication suddenly stops while the network is already operating normally.
Possible causes include:
- Power loss
- Firmware crash
- Cable disconnection
- Internal hardware failure
Your software should recognize that communication has stopped and transition into an appropriate operating state. Equally important is verifying that communication resumes normally once the problem has been corrected.
4. Invalid Data Values
Receiving a valid CAN frame does not guarantee that its contents are meaningful.
Transmit values that are technically valid but physically impossible, for example:
- Engine speed: 9,000 RPM for an engine that normally operates below 3,000 RPM.
- Battery voltage: 2 volts.
- Coolant temperature: 250°C.
- Vehicle speed: 500 km/h.
Your application should validate incoming data whenever practical rather than assuming every received value is trustworthy.
5. Network Overload
A lightly loaded CAN network behaves very differently from one approaching maximum capacity.
Increase network traffic until bus utilization reaches approximately:
- 50%
- 70%
- 90%
- Near maximum capacity
Observe:
- Message latency.
- Missed deadlines.
- Increased processor load.
- Overall application responsiveness.
This type of testing is particularly valuable for gateways, data loggers, and monitoring systems that must process large amounts of network traffic.
6. Duplicate Source Addresses (SAE J1939)
For SAE J1939 applications, address conflicts are an important test case.
Simulate two ECUs attempting to use the same source address and verify whether your application correctly handles the Address Claim procedure.
Tests may include:
- Simultaneous address claims.
- Address changes after startup.
- Repeated address claims.
- Temporary address conflicts.
Although these situations occur infrequently in production systems, they frequently appear during development and integration.
7. Excessive Request Traffic
Many CAN protocols support request-response communication. Problems can arise when multiple nodes repeatedly request the same information.
Generate frequent request messages and verify:
- Response timing.
- Queue handling.
- Processor utilization.
- Recovery after request bursts.
Applications should continue operating predictably even when network traffic becomes unusually demanding.
8. Wiring Faults
Some of the most valuable tests require no special equipment at all.
Examples include:
- Disconnecting CAN_H.
- Disconnecting CAN_L.
- Removing one termination resistor.
- Disconnecting an entire node.
- Cycling power to individual devices.
While modern CAN controllers automatically detect many wiring faults through error counters and state transitions, the application software should also respond appropriately by notifying the user or initiating recovery procedures.
9. Baud Rate Mismatch
Connecting a node configured for the wrong baud rate is a surprisingly common installation error.
Observe how your device responds as communication errors accumulate.
Typical controller states include:
- Error Active
- Error Passive
- Bus-Off
Your software should detect these conditions and provide meaningful diagnostics rather than simply reporting that communication has stopped.
10. Duplicate Messages
Transmit identical CAN messages from multiple nodes whenever the protocol permits.
This is useful for verifying:
- Source address filtering.
- Message logging.
- Data ownership.
- Arbitration behavior.
- Duplicate detection.
Applications should always identify the origin of received messages rather than relying solely on their identifiers.
11. Interrupted Multi-Packet Transfers
Protocols such as SAE J1939 frequently transmit large data sets using multiple CAN frames.
Terminate the transfer before completion and verify that your application:
- Detects the timeout.
- Discards incomplete data.
- Reports the failure correctly.
- Recovers when communication resumes.
Incomplete multi-packet transfers should never produce partially updated application data.
12. Recovery Testing
Finding failures is only half the job. Equally important is verifying recovery.
After each simulated failure:
- Restore power.
- Reconnect wiring.
- Resume message transmission.
- Correct configuration errors.
The application should return to normal operation without requiring unnecessary resets or user intervention whenever possible.
Final Thoughts
Robust CAN applications are not distinguished by how well they perform under ideal conditions—they are distinguished by how gracefully they handle everything that can go wrong.
Every disconnected cable, delayed message, incorrect configuration, overloaded network, or failed controller represents an opportunity to improve the reliability of your product before it reaches the customer. Many of these tests require only a small laboratory setup and a systematic testing approach, yet they often reveal problems that would otherwise remain hidden until field deployment.
Whether you are developing industrial controllers, agricultural equipment, automotive electronics, marine systems, or embedded gateways, intentionally creating failure conditions should become a routine part of every validation process. The confidence gained from knowing how your device behaves under adverse conditions is just as valuable as verifying that it works perfectly when everything goes according to plan.
SAE J1939 Starter Kit and Network Simulator
Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board with USB Port.
The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). More Information…
Comments are closed.