Classical CAN vs. CAN FD in Automotive, Medical Devices & Robotics – Key Differences and Usage

Controller Area Network (CAN) is a robust serial bus widely used in embedded systems across industries like automotive, medical devices, and robotics. “Classical” CAN (the original CAN 2.0 standard) has served reliably for decades in vehicle ECUs, industrial machines, and more. However, modern systems demand higher data throughput and efficiency than classical CAN’s 1 Mbit/s bandwidth and 8-byte frame limit can provide. This led to the development of CAN FD (CAN with Flexible Data-Rate) as an enhanced CAN protocol. In this report, we compare Classical CAN vs. CAN FD, discussing their differences, pros and cons, and guidance on when to use each. We also examine how higher-layer protocols (CANopen, SAE J1939) have adapted to CAN FD, why NMEA 2000 chose not to use CAN FD, and how industry adoption has been influenced by regional factors.

Classical CAN and CAN FD: Key Differences

Data Rate and Throughput: Classical CAN is limited to a maximum bit rate of 1 Mbps, whereas CAN FD allows a higher bit rate during the data phase (up to 2 Mbps in many automotive applications, with 5–8 Mbps achievable in ideal conditions). CAN FD achieves this by using the normal CAN arbitration speed for the identifier field (maintaining reliability and priority resolution) and then switching to a higher speed for the data payload section. This dual bit-rate approach means CAN FD can transmit messages much faster, significantly reducing latency for large data transfers. In practice, moving from 1 Mbps to 2–5 Mbps and beyond can roughly triple or more the data throughput of the bus.

Payload Capacity: Classical CAN frames can carry at most 8 bytes of data. CAN FD dramatically extends the payload up to 64 bytes per frame. This eight-fold increase means sensors or devices can send more information in a single message. Larger payloads reduce the overhead and number of frames needed for transmitting datasets, improving overall bus efficiency. For example, instead of splitting a 32-byte data block into four classic CAN messages, it can be sent as one CAN FD frame. This is especially beneficial in data-intensive contexts like advanced driver-assistance systems (ADAS) and high-resolution sensor streams in robotics.

Frame Format and Reliability: CAN FD retains the core structure of the CAN frame for the arbitration phase but introduces new control bits to enable its extended features. Notably, CAN FD repurposes a reserved bit (the FDF bit) to indicate an FD frame, and adds a Bit Rate Switch (BRS) bit that, when set, switches to the higher data rate after the arbitration is won. Because of these changes, a classical CAN controller will misinterpret a CAN FD frame and flag it as an error, meaning CAN FD frames are not understood by Classical CAN-only nodes. CAN FD also improves error detection: it uses a longer CRC (17 bits or 21 bits, depending on payload length) instead of the 15-bit CRC in Classical CAN, along with a “stuff count” mechanism to improve error-checking robustness. These enhancements greatly reduce the risk of undetected errors, which is vital for safety-critical systems in automotive and medical applications. Aside from the CRC, CAN FD’s frame format is very similar to Classical CAN, helping to ease the transition for new controllers.

Efficiency and Bandwidth Utilization: By allowing more data per frame and higher bit rates, CAN FD can deliver a higher effective throughput with less protocol overhead. Classical CAN frames have significant overhead (>50% of bits are non-data) when carrying only 8 bytes. In contrast, a 64-byte CAN FD frame packs much more information per header, yielding far better payload-to-overhead ratio. In fact, moving from 8-byte to 64-byte frames can increase bus bandwidth utilization by a factor of 3–8× under typical conditions. However, for very short messages, Classical CAN has slightly less overhead; in cases of many small (<=8 byte) signals, the efficiency gain of CAN FD might be modest. Overall, CAN FD’s flexibility means it can operate in Classical CAN mode (if only 8-byte messages at 1 Mbps are used) or scale up to high speeds and large frames as needed.

Backward Compatibility: It’s important to note that while CAN FD controllers are generally backward-compatible with Classical CAN (they can send/receive Classical frames), the inverse is not true – Classical CAN controllers cannot decode CAN FD frames. In a mixed-network scenario, any CAN FD frame will cause error frames on a legacy CAN node. Therefore, CAN FD and Classical CAN nodes cannot seamlessly share a bus unless all nodes support CAN FD. This is a crucial consideration for upgrades; a phased transition requires either upgrading all nodes on the bus to FD-capable controllers or using separate bus segments/gateways for new CAN FD traffic. We discuss this more in the context of higher-layer protocols and industry adoption below.

Teensy 4.1 Triple CAN Bus Board With Two CAN 2.0B And One CAN FD Port With 240x240 IPS LCD

Harness the power of robust, multi‑interface connectivity with the Teensy 4.1 Triple CAN Bus Board—a compact, Arduino‑compatible platform featuring two classical CAN 2.0B ports plus a high‑speed CAN FD interface, all built around a blazing-fast 600 MHz ARM Cortex‑M7 microcontroller with 1 MB RAM and 2 MB Flash. Equipped with an integrated 240 × 240 IPS TFT display for real-time diagnostics, onboard termination resistors, voltage regulation, reverse‑polarity protection, and a wide 7–12 V input range, this board delivers a complete, reliable solution for automotive diagnostics, industrial automation, marine electronics, or intelligent gateway prototyping—making it the ideal tool for modern CAN and CAN FD development. More information..

Advantages of CAN FD (Flexible Data-Rate)

Modern embedded systems benefit in several ways by using CAN FD over Classical CAN:

• Higher Bandwidth & Speed: CAN FD’s ability to switch to higher bit rates in the data phase and carry up to 64 bytes per message dramatically increases throughput. This enables use cases like rapid sensor data bursts, over-the-air firmware updates, or intensive logging that Classical CAN would struggle with. Faster communication means systems (e.g. a robot controller or a vehicle ECU network) can exchange more data with less delay, improving performance and responsiveness.

• More Data per Message: With eight times the payload capacity per frame, CAN FD reduces the need for segmenting data. Large data items (e.g. an array of sensor readings, or a detailed diagnostic report) can often fit in a single CAN FD frame instead of multiple Classical CAN frames. This not only saves bandwidth but also simplifies higher-layer protocols (less packet reassembly) and decreases the chance of message backlog on the bus.

• Improved Efficiency: Because of the above two points, CAN FD has much better bus utilization when carrying larger messages. The protocol overhead per byte of data is lower. Systems that were reaching the limits of Classical CAN (near 100% bus load) can get relief by transitioning some traffic to CAN FD, achieving the same data transfer with fewer frames. In effect, CAN FD extends the usable life of CAN bus in the face of growing data demands.

• Enhanced Reliability: The extended CRC and other robustness features in CAN FD improve error detection and reduce the likelihood of undetected bit errors. This is a significant advantage for safety-critical fields like automotive airbag or brake systems and medical devices, where data integrity is paramount. CAN FD’s protocol changes were driven in part by these higher reliability requirements as network speeds and sizes grew.

• Faster ECU Programming: A practical advantage noted by engineers is that CAN FD can dramatically speed up reprogramming or firmware updates for devices on the network. With Classical CAN’s 8-byte frames, programming a large flash image is time-consuming. CAN FD’s larger frames and higher data rate can cut down software download times for ECUs, improving development and service workflows.

• Leverages Existing CAN Infrastructure: CAN FD was designed as an evolutionary upgrade. It keeps the same physical layer and a similar frame structure, which meant many controller manufacturers could extend their CAN controller IP cores to support FD. In the field, new CAN FD controllers can be configured to communicate with legacy CAN nodes (by simply not using FD frames until ready). Thus, industries can upgrade gradually, reusing existing wiring, transceivers, and tools (oscilloscopes, analyzers) that support the CAN physical layer. This incremental adoption path is less disruptive than switching to a completely different bus technology in systems where classical CAN is deeply entrenched.

Limitations and When Classical CAN Still Makes Sense

Despite its benefits, CAN FD introduces some trade-offs and is not universally the best choice for every scenario:

• Backward Compatibility Constraints: The biggest drawback is the lack of interoperability with Classical CAN devices on the same bus. If you have a large installed base of CAN 2.0 nodes (as is common in vehicles or industrial systems), you cannot simply add a CAN FD node that transmits FD frames – the legacy nodes will detect protocol violations and disrupt communication. This means upgrading to CAN FD often requires a forklift upgrade of all nodes to FD-capable hardware or the addition of new parallel CAN FD networks. In contrast, sticking with Classical CAN ensures all devices speak the same language. For systems that must maintain backwards compatibility (e.g. add-ons to an existing medical device network or aftermarket automotive parts), Classical CAN may be the only viable choice unless a gateway is used.

• Added Complexity in Mixed Networks: Managing a gradual transition to CAN FD can introduce complexity. Gateways or bridges might be needed between classical CAN segments and CAN FD segments to maintain data flow without mixing frame types. This adds development and validation overhead. Some industries have been slow to adopt CAN FD precisely because of these complexities – opting either to remain on classical CAN for as long as possible or to leapfrog to a different high-speed network when a major upgrade is needed (more on this in NMEA 2000’s case later).

• Hardware and Tooling Upgrades: Using CAN FD requires CAN FD-compatible controllers and transceivers. While nowadays many microcontrollers come with CAN FD support, older devices do not. All nodes, and any analyzing tools (bus monitors, etc.), need firmware or hardware that understands CAN FD frames. This can add cost. In very cost-sensitive applications with low data needs (say, a simple CAN-based sensor network in a machine), the cheapest microcontrollers or CAN chips might only support Classical CAN. If the 8-byte limitation isn’t a problem, designers might choose the simpler classical CAN silicon to save cost.

• Marginal Benefits for Small Data: If your application predominantly sends very small messages (only a few bytes at low frequency), CAN FD’s advantages in bandwidth might not be compelling. Classical CAN can handle such traffic with ease, and the improved CRC of CAN FD might not justify the switch if the error rate on classical CAN is already acceptable in your environment. Essentially, not every system “needs” the extra payload or speed. For example, many medical devices send short status messages or commands where 8 bytes at 125–500 kbps is sufficient. Using CAN FD in such cases won’t hurt, but it might be an unnecessary upgrade if there are no performance issues.

• Network Length Considerations: CAN FD’s higher bit rates can impose tighter constraints on network propagation delay (cable length, transceiver latency) during the fast data phase. While the arbitration still occurs at 1 Mbps (retaining the ~40 m maximum length at that rate), running the data phase at 5–8 Mbps effectively means the bus can only be a few meters long if those high speeds are to be robust. In many automotive and robotic use cases this is not a problem (since networks are short), but in some larger installations (long cable runs in industrial or medical facilities), one might need to use more repeaters or stay at lower data phase speeds. Classical CAN at 500 kbps or 1 Mbps can sometimes reach nodes over longer distances more easily than a CAN FD network running at maximum rate.

When to Use Classical CAN vs. CAN FD: In summary, use CAN FD for new designs or evolving systems where data requirements are approaching or exceeding Classical CAN’s limits. This includes automotive applications with ADAS, high-resolution sensors, or central gateways aggregating data, as well as advanced robotics and industrial machines that generate large telemetry datasets or require quick firmware updates. CAN FD will provide the necessary headroom and efficiency in these cases. On the other hand, stick with Classical CAN for simple or legacy networks that do not need the extra bandwidth – for example, a CAN-based control network in a medical infusion pump system or a basic robot sensor network that only sends a few bytes per message. Classical CAN’s proven reliability and broad compatibility make it a safe choice if 8-byte frames at moderate speed suffice. In practice, many projects adopt a hybrid approach: critical low-bandwidth control loops (which value stability and compatibility) remain on a Classical CAN bus, while a secondary CAN FD bus is added for high-bandwidth data (e.g. a logging bus or a sensor array). This way, new capabilities are enabled by CAN FD without disturbing existing CAN 2.0 traffic. As CAN FD technology becomes more ubiquitous and older nodes phase out, we can expect more systems to migrate entirely to CAN FD for the sake of simplicity and future-proofing.

SAE J1939 Starter Kit And Network Simulator

The SAE J1939 Starter Kit and Network Simulator by Copperhill is your all-in-one solution for experimenting with J1939 vehicle networks—no diesel engine needed. This kit includes two J1939-capable nodes (USB-based ECU simulator boards) that let you easily monitor, record, analyze, and simulate PGNs from SAE J1939-71 and diagnostic messages from J1939-73 using their free jCOM1939 Monitor software. Designed to work on any PC (or two!) with COM ports, it removes the need for actual ECUs, giving both newcomers and seasoned engineers a simple yet full-featured platform for developing and testing heavy-duty network communications without requiring any physical vehicle. With plug-and-play functionality powered by ESP32-based hardware (providing higher performance and reliable availability), this kit ensures compatibility, flexibility, and productivity. More information...

Impact on Higher-Layer Protocols and Standards

Many higher-layer protocols built on CAN have had to consider or incorporate CAN FD:

CANopen (Industrial Automation / Medical)

CANopen, an application-layer protocol widely used in industrial automation and some medical devices, was originally designed for Classical CAN. To leverage CAN FD’s benefits, the CiA (CAN in Automation) released an updated specification CANopen FD (CiA 1301). CANopen FD retains most of the classic CANopen services (e.g. its object dictionary, PDO/SDO communication models) but extends them to use CAN FD frames up to 64 bytes. For example, Process Data Objects (PDOs) – which carry real-time data like sensor readings or motor commands – can now transmit much larger chunks of data per message (up to 64 bytes) in CANopen FD. This is especially useful in motion control applications that may need to send multiple setpoints or status feedback in one cycle. CANopen FD also introduced a new Universal SDO (USDO) service to improve configuration and data transfer capabilities, taking advantage of the bigger frame size for things like batch uploads/downloads of parameters.

From a developer perspective, migrating to CANopen FD means using a CAN FD-capable stack and controllers, but it allows higher throughput while still following the familiar CANopen paradigm. Importantly, CANopen FD is not backward-compatible with classic CANopen on the same network – a legacy CANopen node (Classic CAN) cannot understand the extended frames – so a system must either upgrade all nodes or run separate segments. Adoption of CANopen FD has been gradual; as of mid-2020s, only a limited number of devices explicitly support it, often in closed systems where a single vendor controls all nodes. Many CANopen deployments in medical and industrial equipment continue with Classical CAN for now, since their bandwidth needs are met. However, for new high-performance devices (e.g. a complex surgical robot or industrial robot controller that needs to send a lot of data), CANopen FD provides a path to use CAN FD’s capacity while still working within a standardized framework.

SAE J1939 (Heavy Vehicles & Off-Road)

SAE J1939 is a high-level protocol used in heavy-duty vehicles (trucks, buses, agricultural and construction machinery) and is built on CAN. Classical J1939 uses 29-bit CAN identifiers and was traditionally run at 250 kbps (sometimes 500 kbps) with 8-byte data frames. As vehicle systems became more complex, this limited bandwidth became a bottleneck. In response, the SAE released new standards J1939-17 and J1939-22, which define the use of CAN FD at the data link layer for J1939 networks. J1939-22 (finalized around 2021) allows J1939 messages to be transmitted over CAN FD, typically using 500 kbps for the arbitration phase and 2 Mbps for the data phase, with up to 64 bytes of data per frame. This yields roughly four times the throughput of classic 500 kbps J1939 and eight times the payload per message, enabling much more data exchange for modern applications like advanced diagnostics, telemetry, and machine vision on heavy equipment. For example, an off-road harvester could stream higher-resolution sensor data from implements, or a truck could send detailed engine performance data in a single message rather than splitting it.

However, because CAN FD frames cannot be understood by classical CAN nodes, the migration to J1939 FD comes with backward compatibility challenges. A legacy J1939 ECU (expecting 8-byte frames) will error out if it sees a J1939-22 message on the same bus. Thus, manufacturers have to decide between upgrading entire vehicle networks to CAN FD or adding separate CAN FD buses. In practice, many off-road vehicles are adopting a hybrid approach: keeping the existing Classical CAN J1939 bus for critical controls (engine, brakes, etc., where 250 kbps still suffices) and adding a parallel CAN FD bus for data-heavy devices (like guidance systems, high-end sensors). Bridging devices or gateways may link the two networks when necessary, though this introduces complexity in maintaining synchronization and data integrity across bus domains. The slow uptake in North America of CAN FD is evident here – the heavy vehicle industry took nearly a decade after CAN FD’s introduction to roll out J1939-22, due in part to the huge installed base of classical CAN and the desire to not disturb proven J1939 systems without a clear ROI. Over time, we expect new vehicle platforms to fully adopt J1939 over CAN FD as older fleets retire, to gain the benefits of increased bandwidth.

NMEA 2000 (Marine) and OneNet

NMEA 2000 is a marine communication standard (essentially a marine flavor of CAN similar to J1939) used in boats for connecting engines, sensors, displays, autopilots, etc. It runs on Classical CAN at 250 kbps with 29-bit IDs. As with J1939, the growing data needs in modern marine electronics (high-detail sonar, radar, video feeds) began to push the limits of NMEA 2000’s bandwidth. When CAN FD emerged, the NMEA organization faced a choice: create a “NMEA 2000 over CAN FD” upgrade or jump to a different technology. They decided not to adopt CAN FD for NMEA 2000. The main reason is that CAN FD’s speed boost (up to ~2 Mbps data phase) was still relatively modest and would break backward compatibility anyway. Instead, NMEA developed OneNet, an Ethernet-based networking standard for marine use. OneNet (officially released around 2020) provides orders of magnitude more bandwidth (100 Mbps and beyond) and uses IPv6/Ethernet to carry NMEA 2000 messages and other data. Essentially, the marine industry skipped CAN FD and went straight to an Ethernet/IP solution for high-bandwidth applications.

The result is that NMEA 2000 remains on Classical CAN for the core low-bandwidth, real-time data (which it handles well), and OneNet is intended as an optional backbone for heavier data like video or large file transfers. This strategy avoids forcing an entire industry to upgrade all CAN devices to CAN FD; instead, manufacturers can add Ethernet gateways and keep using existing N2K devices. It answers the question: if you must add a new network for more speed, why not make it Ethernet (which is exactly what some in the SAE J1939 community have also pondered). The downside is added complexity of a two-network system, but the marine industry deemed it worthwhile. In short, NMEA 2000 does not use CAN FD because the industry opted for a bigger leap in bandwidth via OneNet, rather than a smaller incremental jump that would still break compatibility. This is a prime example of evaluating what to use when – the NMEA chose Classical CAN + Ethernet (OneNet) rather than an intermediate CAN FD step, given their specific needs and legacy constraints.

PICAN CAN Bus FD Board With Real-Time Clock For Raspberry Pi

Elevate your Raspberry Pi into a high-performance CAN FD node with the PiCAN CAN Bus FD Board, powered by Microchip’s MCP2517FD controller and MCP2562FD transceiver for full ISO 11898‑1:2015 compliance. With support for both Classical CAN and high-speed CAN FD communication (arbitration up to 1 Mbps, data up to 8 Mbps), this versatile HAT brings flexible, robust networking to industrial and automotive projects. The onboard PCF8523 real‑time clock with battery backup ensures accurate timestamping—even through power interruptions—while the integrated SMPS allows easy 5 V power delivery to the Raspberry Pi via DB9 connector or screw terminal. With hardware-backed SPI, SocketCAN support (exposing as can0 in Linux), GPIO interrupt signaling, LED status indicators, and Pi HAT compatibility, the PiCAN board delivers a complete, reliable CAN FD solution ready for programming in C or Python—ideal for embedded networking, automation, diagnostics, and data logging applications. More information...

Industry Adoption and Regional Perspectives

CAN FD’s development and adoption have been influenced by the needs of different industries and regions:

• Automotive (Passenger Cars & Light Vehicles): The push for CAN FD largely started with passenger car manufacturers in Germany. Bosch developed CAN FD in 2011–2012 with input from OEMs like Volkswagen, aiming to handle the growing data in luxury and advanced vehicles. German automakers were early adopters, introducing CAN FD for high-speed in-vehicle networks (e.g. in powertrain and ADAS domains) in the late 2010s. In fact, CAN FD (and the upcoming CAN XL) were initiated by German automotive requirements, with relatively less involvement from American standards bodies initially. By 2020, rollouts of CAN FD in production cars had begun, and today many European models use CAN FD for critical data-hungry subsystems while still using Classical CAN for legacy ECU communication. Automakers value that CAN FD extends the life of CAN – a network they trust for its reliability – without jumping straight to Ethernet in every case. However, they are also integrating Automotive Ethernet for backbone networks. Over the next few years, it’s expected that new car platforms will use CAN FD by default (in place of Classical CAN) wherever feasible, for even mundane communications, simply because the cost difference has shrunk and it provides more headroom.

• North America & Backward Compatibility Caution: North American industries have been somewhat slower in CAN FD adoption. One reason is a large installed base of Classical CAN (especially in heavy vehicles and industrial machines) and a mindset of weighing alternatives like Ethernet. As one industry expert noted, CAN FD was developed per German OEM requests “without any sympathy” for the American SAE J1939 standard or compatibility concerns. The lack of backward compatibility meant organizations like the SAE had to carefully plan migration (hence the late introduction of J1939-22). In some cases, manufacturers in NA questioned whether it was better to invest in Ethernet networks for new features rather than incrementally upgrade CAN. Still, this is changing: the performance needs in off-road and automotive systems are leading North American companies to implement CAN FD in new designs, but often gradually. For example, an American heavy-equipment maker might release a new machine with an added CAN FD bus for a high-tech option package, while keeping the base vehicle’s classical CAN network unchanged. Over time, as global suppliers produce more CAN FD components, the North American market is naturally catching up and adopting CAN FD – but the transition is happening alongside a broader move to hybrid network architectures (CAN + Ethernet).

• Medical Devices: The medical device sector has utilized CAN (often via CANopen or proprietary protocols) in applications such as diagnostic equipment, imaging systems, and surgical robots, thanks to CAN’s reliability and real-time capabilities. CAN FD’s impact on medical devices is emerging rather than pervasive. Many existing medical devices do not yet push CAN’s bandwidth limits – for instance, a heart-lung machine or an infusion pump sends relatively small status messages where Classical CAN is sufficient. Additionally, the medical field values stability and long product life cycles; introducing a new protocol can entail regulatory re-certification. That said, as medical technology advances (e.g. high-resolution imaging, robotic surgery systems with many sensors/actuators), the need for more data throughput is growing. CAN FD offers a way to get higher performance while still using CAN’s simple two-wire bus architecture. We are seeing some advanced medical systems adopt CAN FD internally to transmit, for example, more detailed sensor data or to speed up system boot-up diagnostics. In general, embedded developers in medical equipment can consider CAN FD for new designs that demand fast and large data transfer, knowing that the protocol maintains CAN’s error-handling strengths. For devices that remain low-bandwidth and heavily legacy-dependent, classical CAN will continue to suffice in the near term. (It’s worth noting that some medical vendors also look at Ethernet-based fieldbuses for very high data needs, similar to the NMEA OneNet approach, but those come with higher complexity.)

• Robotics and Industrial Automation: These domains were early adopters of CAN and continue to use it extensively for motion controllers, sensors, and actuators in factory machinery, robots, and drones. Robotics can benefit greatly from CAN FD’s improvements. Consider a modern autonomous mobile robot or a collaborative robot arm – it may have multiple lidar units, high-resolution joint encoders, and safety scanners, producing far more data than a 1990s-era industrial robot. CAN FD allows such data to be shared on the existing CAN wiring with less latency and packet fragmentation. For instance, a robot could send a complete set of joint positions and forces in one CAN FD frame each cycle, whereas it might require several frames on Classical CAN. The faster bit rate also means more real-time sensor feedback can be packed into control loops without saturating the bus. In industrial automation, machine builders using protocols like CANopen FD can create high-performance networks for motion control that rival some specialty real-time Ethernet systems, yet with the simplicity of CAN wiring. That said, not all robotics applications immediately need CAN FD – many current robots function well within classical CAN limits by carefully optimizing what data is sent. Moreover, where extremely high bandwidth or hard real-time synchronization is required (for example, vision systems or multi-Mbps control loops), some developers opt for industrial Ethernet or time-sensitive networks. Still, for a large class of robotic and automation systems, CAN FD hits a sweet spot: significantly more capable than Classical CAN, while lighter-weight and more cost-effective than full Ethernet. It is telling that CAN FD is promoted as a way to “use existing CAN systems and knowledge even when demands are high”, underscoring its role as an evolutionary step for industries that built their products around CAN.

• CAN XL – The Next Step: As a final note, the success of CAN FD has paved the way for the development of CAN XL, the “third generation” CAN protocol. Initiated by German automakers (notably a request from VW), CAN XL aims to further increase capacity (up to 10 Mbps or more and a maximum payload of 2048 bytes). Importantly, CAN XL is being designed to be backward-compatible with CAN FD, to avoid repeating the compatibility break that occurred between Classical CAN and CAN FD. This means a CAN XL controller should be able to communicate on a CAN FD network if needed. As of 2025, CAN XL is still in early stages of standardization and testing, and it remains to be seen how quickly it will be adopted (some experts question if CAN XL will gain traction before automotive Ethernet takes over those high-bandwidth roles). For now, CAN FD is the state-of-the-art in CAN technology, and it’s gradually becoming the new normal in automotive and other sectors as older systems are replaced.

Conclusion

Classical CAN vs. CAN FD can be summarized as a trade-off between the old and the new: Classical CAN offers simplicity, proven reliability, and broad compatibility, while CAN FD brings much-needed higher performance at the cost of requiring updated hardware. Embedded developers should evaluate the specific needs of their application – message size, required throughput, legacy constraints – when deciding which CAN protocol to use. In automotive, medical, and robotics fields, CAN FD is enabling more data-intensive and faster communications, extending the lifespan of CAN technology in the face of growing demands. Higher-layer standards like CANopen and J1939 have evolved to support CAN FD, although industries mindful of compatibility (such as marine with NMEA 2000) have sometimes chosen alternative paths. The development of CAN FD, driven largely by European automotive initiatives, underscores how regional strategy can influence technology adoption rates. North America’s slower embrace of CAN FD is turning a corner as the benefits become undeniable and as solutions for coexistence with legacy systems mature.

For embedded systems developers, the ecosystem for CAN FD (controllers, tools, protocol stacks) is now well-established, lowering the barrier to entry. If your project demands more bandwidth or efficiency than classical CAN can provide, CAN FD is likely the right choice – it offers a significant performance boost while preserving the core advantages that made CAN ubiquitous (robust arbitration, error containment, simple wiring). On the other hand, if backward compatibility or minimal data needs are paramount, classical CAN remains a viable and effective solution. In many cases, a combination will yield the best of both worlds. Moving forward, we can expect CAN FD (and eventually CAN XL) to play a central role alongside Ethernet-based networks in automotive, industrial, and robotic systems – each technology used where it fits best. The CAN bus thus continues to evolve, ensuring that even as our devices generate more data and become more connected, engineers have communication options that are up to the task.

Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications: A Technical Approach

This book provides a comprehensive exploration of the most critical technical aspects of vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, positioning these technologies within the broader vision of smart cities. It begins by outlining the smart city concept and its underlying architecture, showing how V2V and V2I communication systems integrate with urban mobility frameworks to improve safety, efficiency, and sustainability.

The text delves into the wireless communication protocols that underpin V2V and V2I systems, explaining their operational principles, standards, and interoperability requirements. It then moves into the hardware design process, guiding readers through the development of vehicle communication transceivers and antenna systems, with an emphasis on practical considerations such as environmental resilience, signal integrity, and cost-effectiveness.

A dedicated section examines next-generation wireless technologies—including 5G, C-V2X (Cellular Vehicle-to-Everything), and emerging 6G concepts—highlighting their performance benchmarks, latency requirements, and bandwidth demands for future-ready vehicle communication protocols.

To bridge theory with practice, the book presents real-world case studies that detail the latest commercial implementations of V2V and V2I systems, offering insights into design trade-offs, deployment strategies, and regulatory compliance. Finally, it provides a hands-on perspective on implementing vehicle communication protocols from the hardware engineer’s point of view, illustrating how design choices at the circuit, antenna, and integration levels directly affect system performance in the field. More information...