Testing Services

CAN FD Testing Guide - What Changes and How to Automate It

CAN FD vs CAN 2.0: dual bitrates, 64-byte payloads, new CRC algorithm. What your test suite must cover and how to automate it - one adapter, no extra hardware.

CAN FD testing guide

WHAT IS CAN FD TESTING?

CAN FD testing is the validation of Controller Area Network Flexible Data-rate communication - verifying that ECUs correctly transmit and receive CAN FD frames with both classical and data-phase bitrates, correct payload sizes up to 64 bytes, and correct bit rate switching behaviour.

CAN FD (ISO 11898-1:2015) extends classical CAN 2.0 in two ways: the data phase can run at a higher bitrate (typically 2–8 Mbit/s vs 500 kbit/s for the arbitration phase), and the payload can carry up to 64 bytes per frame (vs 8 bytes in CAN 2.0). These changes increase throughput for high-bandwidth ECUs - ADAS cameras, V2X modules, domain controllers - but introduce new failure modes that CAN 2.0 testing tools cannot catch.

What changes in CAN FD testing vs CAN 2.0: bitrate switching validation, extended payload encoding, DLC-to-byte-count mapping (CAN FD uses a non-linear DLC field), CRC algorithm differences, and transceiver delay compensation configuration.

CAN FD VS CAN 2.0 - KEY DIFFERENCES

What Changes When You Move to CAN FD

Understanding these differences determines what your test suite must cover beyond classical CAN.

Dual Bitrate - Arbitration + Data Phase

CAN FD uses a lower bitrate for arbitration (typically 500 kbit/s or 1 Mbit/s) and switches to a higher bitrate for the data phase (2–8 Mbit/s). Your test setup must validate correct bitrate switching and that the ECU's transceiver delay compensation is configured correctly for the data phase bitrate.

Up to 64 Bytes Per Frame

CAN FD extends the payload from 8 bytes (CAN 2.0) to up to 64 bytes. The DLC field uses a non-linear encoding: DLC 9–15 map to 12, 16, 20, 24, 32, 48, and 64 bytes respectively. Test cases must cover all valid DLC values and verify correct payload size handling.

Different CRC Algorithm

CAN FD uses a 17-bit or 21-bit CRC (vs 15-bit in CAN 2.0) for improved error detection over longer data phases. Automated testing must verify that the ECU rejects frames with invalid CRCs and that CRC stuffing rules are implemented correctly.

Backward Compatible Hardware

CAN FD-capable transceivers and adapters are backward compatible with classical CAN frames. A CAN FD adapter can send and receive both CAN 2.0 and CAN FD frames on the same network. TestBot's CAN Adapter is CAN FD capable - no separate hardware purchase for CAN FD testing.

TESTBOT CAN FD AGENT

Agent
CAN / CAN FD Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Send and receive CAN 2.0A/B and CAN FD frames using DBC definitions - validate signals, message timing, bus load, and error injection.
Agent
UDS Client Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Run automated UDS diagnostic sessions across all 22 ISO 14229 services - session management, DID read/write, fault memory, flash programming, and security access.
Agent
UDS Server Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Simulate an ECU responding to UDS diagnostic requests - test the tester tool, validate diagnostic sequences from the server side.
Agent
OBD2 Client Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Query OBD-II PIDs, read live sensor data, and validate emissions-related diagnostic services over CAN.
Agent
OBD2 Server Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Simulate an OBD-II-compliant ECU - test diagnostic scan tools and aftermarket testers against a controlled virtual vehicle.
Agent
J1939 Client Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Transmit and receive SAE J1939 PGNs for commercial vehicle ECU validation - trucks, buses, construction, and agricultural equipment.
Agent
J1939 Server Agent
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Simulate a J1939 node on the vehicle bus - test fleet management systems, telematics gateways, and body controllers.
Agent
XCP Server Agent (CAN)
Hardware Required
CAN Adapter (CAN FD capable)
Hardware Required
Simulate an XCP slave over CAN for calibration and measurement workflows - enable ECU parameter write and DAQ list recording in test sequences.
TEST SCENARIOS

CAN FD Test Scenarios With TestBot

ScenarioTestBot Blocks UsedValidated Outcome
CAN FD Frame Transmission at 2 Mbit/s Data PhaseCAN FD Send Frame (data phase 2Mbit/s) + CAN FD Receive + DLC AssertFrame received with correct payload size, DLC correctly decoded
Maximum Payload (64 bytes) ValidationCAN FD Send Frame (DLC=15, 64 bytes) + Payload AssertFull 64-byte payload transmitted and received without CRC error
Mixed CAN 2.0 / CAN FD NetworkCAN 2.0 Send + CAN FD Send + CAN MonitorBoth frame types coexist on bus, no error frames, all signals decoded correctly
Bitrate Switching ValidationCAN FD Send + Bitrate MonitorArbitration phase at 500 kbit/s, data phase at 5 Mbit/s, switching point correct
CAN FD CRC Error InjectionCAN FD Fault Inject (CRC) + Error Frame MonitorECU rejects CRC-invalid frame, error frame counted, no bus-off triggered

Frequently Asked Questions - CAN FD Testing

CAN FD testing FAQ

CAN FD (Flexible Data-rate) extends classical CAN with two-phase bitrate operation and up to 64 bytes of payload per frame. It needs different testing because: (1) bitrate switching must be validated, (2) DLC encoding is non-linear and must be tested for all payload sizes, (3) a different CRC algorithm is used, and (4) transceiver delay compensation must be configured correctly for the data phase bitrate.

Continue Learning

RELATED GUIDES

Start Testing CAN FD on Your ECU

One CAN Adapter covers both CAN 2.0 and CAN FD. 14-day free trial.