Why classical CAN eventually felt cramped
Classical CAN proved remarkably durable, but its limits were visible as vehicles demanded more from their networks:
- More signals per ECU
- More diagnostic and calibration traffic
- More gateway traffic between domains
- More software features sharing the same physical bus
- More value in carrying a larger unit of data in one transmission
Two limits mattered most:
- Payload size: only up to 8 data bytes per frame
- Data rate: classical CAN is typically limited to 1 Mbit/s
If your traffic is mostly tiny control signals, those constraints are fine. But once network loading grows, those limits become expensive. Engineers start spending more time fragmenting data, scheduling around bus load, and defending network utilization.
What CAN FD changes
CAN FD stands for CAN with Flexible Data-rate. Bosch introduced it to close the gap between classical CAN and newer, higher-bandwidth networking needs while keeping the CAN ecosystem recognizable.
The key changes are straightforward:
- The payload can grow from up to 8 bytes to up to 64 bytes
- The frame format is modified
- The bit rate can switch to a faster value during the data phase
- Controllers can still perform classical CAN communication
That last point matters. CAN FD was not created as a total reset. It was created as an evolution path.
The most important idea: arbitration stays familiar
CAN FD does not throw away the behavior that made CAN useful for control. Arbitration still happens in the arbitration phase before the faster data phase begins. In other words:
- Priority is still determined by the identifier.
- High-priority traffic still wins bus access first.
- The network still feels like CAN in the way engineers think about message importance.
Kvaser describes CAN FD as keeping normal CAN bus arbitration while allowing the bit rate to switch after arbitration. That is a big reason CAN FD felt practical rather than disruptive.
What actually changed in the frame
At a high level, the classical CAN frame was extended to allow:
- A flag that identifies the frame as CAN FD
- New data length coding rules for payloads above 8 bytes
- Optional bit-rate switching in the data phase
- Updated CRC handling suitable for longer payloads
The result is not simply "classical CAN but bigger." It is a protocol refinement meant to maintain robustness while transmitting more data more efficiently.
Why 64 bytes matters more than it sounds
Jumping from 8 bytes to 64 bytes is not just a nice round number. It changes how engineers pack and schedule information.
With classical CAN:
- Large logical data often has to be split over multiple frames
- More frames means more arbitration overhead
- Network utilization climbs quickly
With CAN FD:
- More related signals can travel together
- Overhead per useful byte drops
- Diagnostics, calibration, and richer ECU exchanges become easier to justify
This is one reason CAN FD is especially attractive in systems that are still control-oriented but no longer comfortably small.
Why faster data phase matters
If CAN FD only increased payload size while keeping the entire frame at the old rate, the gain would be smaller. The more important improvement is that the data phase can run faster once arbitration is over.
That means:
- Time spent transmitting the actual payload drops
- Effective throughput rises
- Larger frames do not become as painful as they otherwise would
Bosch positions CAN FD as overcoming classical CAN's 1 Mbps limit by switching to a faster rate inside the frame and expanding data bytes up to 64.
Where CAN FD fits best
CAN FD is often the right next step when:
- Classical CAN bus load is becoming uncomfortable
- Payload fragmentation is wasting bandwidth
- The application still wants CAN-style priority behavior
- The team is not ready to move that network segment to Ethernet
- Existing software, tools, and engineering practices are CAN-centric
Typical examples include:
- Powertrain and chassis domains with growing message sets
- Battery-management and electrification systems
- Gateways that need more efficient transport between network islands
- Development fleets that generate heavier logging or diagnostic traffic
Where CAN FD does not automatically win
CAN FD is an improvement, not a magic replacement for every other network:
- It still is not Ethernet-class bandwidth
- Physical-layer design margins matter more as speeds rise
- Mixed classical CAN and CAN FD environments require compatibility planning
- Some device ecosystems, tools, or legacy nodes may slow migration
In other words, CAN FD is ideal when you want more headroom without changing the architectural character of the network. It is less ideal if the underlying problem is fundamentally "we now need a switched, IP-native, high-bandwidth backbone."
CAN FD versus Ethernet in one sentence
If classical CAN is too small and Ethernet is too heavy for the specific domain, CAN FD is often the most elegant middle ground.
What migration usually looks like
Real migration is typically incremental:
- Engineers identify overloaded classical CAN segments.
- They evaluate which ECUs and tools already support CAN FD.
- They choose whether the network remains mostly CAN-oriented or whether it is time for a bigger architectural shift.
- DBCs, diagnostics, logging, and validation tools are updated accordingly.
This matters because protocol migration is never only about the wire format. It changes test setups, databases, trace files, driver support, and service workflows.
Why DBC tooling still matters in a CAN FD world
CAN FD gives you more room, but it also increases the importance of good message definition and review:
- Larger frames can pack more signals
- Signal layout mistakes become more expensive
- Database maintenance becomes more central to collaboration
That is why the value of a focused DBC editor does not shrink when teams move to CAN FD. If anything, clear database management becomes even more useful because the message payload can carry more semantic complexity.
Working with CAN FD databases in day-to-day engineering
As teams move to larger payloads and mixed-network designs, database correctness becomes even more important. Compare-driven DBC workflows and signal-layout validation help teams catch mistakes before bench or vehicle integration.
Official project links:
Final view
CAN FD succeeded because it did not ask engineers to choose between old CAN habits and new bandwidth needs. It preserved the control-centric strengths of CAN while expanding payload and throughput enough to keep many networks viable for another generation of vehicle electronics.