From Classical CAN and CAN FD to CAN XL: Functional Safety and Security for Next-Generation In-Vehicle Communication

Abstract

Controller Area Network (CAN) has remained a foundational in-vehicle communication technology because it combines deterministic medium access, efficient broadcast communication, robust error detection, and fault confinement. CAN Flexible Data Rate (CAN FD) extended the payload and data-rate capabilities of Classical CAN while preserving many of the safety-relevant attributes that made CAN successful in automotive control systems. CAN eXtended Length (CAN XL) continues this evolution by increasing payload capacity up to 2048 bytes and enabling substantially higher effective throughput, while introducing additional mechanisms required for longer frames, higher data-phase speeds, and modern cybersecurity needs.

This article reviews the functional-safety attributes of Classical CAN and CAN FD, then explains how CAN XL preserves and extends them. It also discusses higher-layer safety protocols, fault-tolerant CAN XL controller implementations, and CANsec, the CAN XL security extension inspired by the MACsec model. Finally, it highlights how the CAST CAN XL controller IP and CANsec acceleration IP can support the efficient deployment of safety- and security-capable in-vehicle networks.

1. Introduction

In-vehicle networks have evolved from simple control links into distributed computing fabrics. Modern vehicles integrate electrification, advanced driver assistance, over-the-air updates, diagnostics, domain controllers, zonal architectures, and dense sensor and actuator networks. These functions demand more bandwidth, but bandwidth alone is not sufficient. Automotive communication must also remain predictable, fault-aware, available, and protected against cyber threats.

The CAN family has historically addressed many of the communication-safety requirements of embedded control systems. Classical CAN provides deterministic priority-based arbitration, frame acknowledgment, error detection, retransmission, and fault confinement. CAN FD increases payload capacity and allows a faster data phase while retaining the core CAN communication model. CAN XL [1] extends the concept further, targeting payloads up to 2048 bytes and higher-speed data exchange while preserving the essential behavior that makes CAN suitable for control-oriented systems.

2. Functional-Safety Foundations in Classical CAN

Classical CAN was not a complete functional-safety solution on its own, but it provided a strong data link layer foundation for reliable distributed control. Its key safety-relevant features are deterministic non-destructive arbitration, frame acknowledgment, error detection, error signaling, automatic retransmission, synchronization support, and fault confinement.

2.1 Deterministic Non-destructive Arbitration

CAN uses bitwise arbitration on the message identifier. If two or more nodes start transmitting simultaneously, the node sending the numerically lower identifier wins arbitration. Losing nodes stop transmitting and retry later, while the winning frame continues without being destroyed. This provides priority-ordered access without wasting a full frame time on a collision. High-priority control messages can therefore be given deterministic access preference.

2.2 Frame Acknowledgment

CAN includes an acknowledgment mechanism that allows receivers to indicate successful frame reception. If no receiver acknowledges a transmitted frame, the transmitter treats this as an error condition and retransmits according to CAN error-handling rules. Acknowledgment is not an end-to-end application confirmation, but it is an important link-layer indication that at least one node on the bus received the frame correctly. For safety-critical systems, this mechanism is typically complemented by application-level monitoring, sequence counters, and timeout supervision.

2.3 Error Detection Mechanisms

Classical CAN enables several error-detection mechanisms: bit monitoring by the transmitter, bit-stuffing checks, frame format checks, and Acknowledgment error detection. Classical CAN frames also include a 15-bit cyclic redundancy check (CRC) code with a nominal Hamming distance of 6, which detects up to 5 randomly distributed errors [5]. Together, these mechanisms allow nodes to detect corrupted or malformed frames and actively signal errors to the rest of the network. The CRC protects the transmitted frame content against random bit errors, while stuffing and form checks detect violations of expected protocol structure.

A shortcoming of the CRC as defined in Classical CAN is that the CRC code does not include the stuffing bits, effectively reducing the Hamming distance to 2 for specific error patterns.

2.4 Fault Confinement

CAN implements error counters that track transmit and receive errors. Depending on counter values, a node transitions through defined states:

• Error Active
• Error Passive
• Bus-Off

This mechanism prevents a faulty node from indefinitely disrupting the network. A node that repeatedly causes errors is progressively restricted and can eventually be isolated from the bus. Fault confinement is one of CAN’s most important safety-relevant attributes because it turns repeated communication faults into a controlled degradation mode rather than an uncontrolled network failure.

2.5 Clock Synchronization Through Bit Stuffing

CAN uses non-return-to-zero signaling and relies on signal edges for synchronization. Bit stuffing ensures that long runs of identical bits are interrupted, creating periodic edges that receivers can use to remain synchronized. This mechanism is central to reliable reception, especially in distributed networks where oscillator tolerances, propagation delays, and physical-layer effects must be managed. It is worth noting, however, that the bit stuffing in Classical CAN is dynamic (if five consecutive bits of the same polarity are sent, a sixth bit of opposite polarity is inserted), making it hard to predict exactly how long it will take to receive a frame.

3. CAN FD: Extending CAN While Preserving Its Safety Model

CAN FD was introduced to overcome the 8-byte payload limit and practical bit-rate constraints of Classical CAN. CAN FD allows payloads up to 64 bytes and supports bit-rate switching, where the arbitration phase remains compatible with CAN arbitration principles while the data phase can run faster.

CAN FD preserves the central CAN safety model: priority-based arbitration, acknowledgment, CRC protection, error signaling, retransmission, fault confinement, and synchronization support. It is therefore best understood as an evolutionary extension rather than a replacement of the CAN safety philosophy.

It is worth noting, though, that CAN FD addresses a shortcoming of CRC protection in Classical CAN mentioned earlier: CAN FD not only uses longer (17- or 21-bit) CRCs to protect its larger frames but also retains the same nominal Hamming distance of 6 across all stuff-bit cases. It does so by introducing the Stuff Count field before the CRC and applying bit-stuffing to the CRC value itself.

4. CAN XL: Longer Payloads and Higher Speeds

4.1 Why CAN XL Requires Additional Safety Engineering

CAN XL dramatically increases payload size, up to 2048 bytes. Longer frames improve efficiency for large data transfers, but they also increase the amount of information protected by each frame-level integrity mechanism. Higher data-phase speeds also make the quality of synchronization and controller implementation more critical.

The safety challenge is therefore to preserve proven CAN attributes while adding mechanisms suitable for long frames, high-speed operation, and modern vehicle architectures.

4.2 CAN XL Protocol-Level Functional Safety Features

Figure 1 shows the CAN XL frame organization and highlights the safety-relevant fields used for arbitration, control, payload protection, acknowledgment, and error detection.

Figure 1: CAN XL frame organization and protocol-level functional-safety fields, including arbitration, PCRC, FCRC, acknowledgment, and EOF regions. See [2] for further details on message fields.

4.2.1 Reliable frame reception

CAN XL retains frame acknowledgment. A transmitted frame must be acknowledged by at least one receiver, giving the transmitter an immediate link-layer indication that reception was confirmed somewhere on the bus.

4.2.2 Dual CRC protection

CAN XL uses a 32-bit Frame CRC (FCRC) for the frame, featuring a Hamming distance of 6, even for 2048-byte payloads [5], and introduces a 13-bit Preface CRC (PCRC) for early header and control information [1], [4]. The Preface CRC is particularly important because it allows header/control errors to be detected early, rather than waiting until the end of a long payload. Early detection improves fault localization and avoids wasting bus time on frames whose critical control information has already been corrupted.

4.2.3 Arbitration, classification, and collision detection

CAN XL preserves priority-based non-destructive arbitration. Additional fields, including the Acceptance Field (AF), Service Data Unit Type (SDT), and Virtual CAN Network Identifier (VCID), provide classification context and can help reduce or detect message conflicts earlier.

Figure 2 illustrates additional synchronization and fault-confinement aspects of the CAN XL frame, including fixed-pattern fields and stuff-bit regions used around bit-rate transitions.

Figure 2: CAN XL synchronization and bit-stuffing regions, including dynamic stuff bits, fixed stuff bits, no-stuff regions,
and fixed-pattern fields around bit-rate transitions.

4.2.4 Synchronization

CAN XL uses the Start-of-Frame edge, bit stuffing, and dedicated fixed-pattern fields such as the Arbitration to Data Sequence (ADS), Format Check Pattern (FCP), and Data to Arbitration Sequence (DAS) to maintain synchronization across different parts of its longer frames and across bit-rate changes.

It is worth noting that CAN XL deviates from the dynamic bit-stuffing used in Classical CAN and CAN FD, which made the actual frame length dynamic and hard to predict: To maintain backward compatibility and ensure collision resolution works correctly, the Arbitration phase (the very beginning of the frame) still uses dynamic bit-stuffing, but once the protocol switches to the high-speed data phase (the XL portion), it switches to static bit stuffing, where a stuff bit is inserted at fixed intervals (every 10 bits). This makes the payload length predictable and eases synchronization.

4.2.5 Fault confinement and error isolation

CAN XL continues the CAN tradition of error counters and node state transitions. Persistent faults can move a node from Error Active to Error Passive and eventually to Bus-Off. This limits the ability of a defective node to disrupt the rest of the network. Fault confinement is necessary but not sufficient for high-availability systems. In many applications, bus-off isolation prevents further damage but also removes a node from service. This is why controller-level fault tolerance becomes important.

4.2.6 Synchronization

CAN XL uses the Start-of-Frame edge, bit stuffing, and dedicated fixed-pattern fields such as the Arbitration to Data Sequence (ADS), Format Check Pattern (FCP), and Data to Arbitration Sequence (DAS) to maintain synchronization across different parts of its longer frames and across bit-rate changes.

It is worth noting that CAN XL deviates from the dynamic bit-stuffing used in Classical CAN and CAN FD, which made the actual frame length dynamic and hard to predict: To maintain backward compatibility and ensure collision resolution works correctly, the Arbitration phase (the very beginning of the frame) still uses dynamic bit-stuffing, but once the protocol switches to the high-speed data phase (the XL portion), it switches to static bit stuffing, where a stuff bit is inserted at fixed intervals (every 10 bits). This makes the payload length predictable and eases synchronization.

4.2.7 Fault confinement and error isolation

CAN XL continues the CAN tradition of error counters and node state transitions. Persistent faults can move a node from Error Active to Error Passive and eventually to Bus-Off. This limits the ability of a defective node to disrupt the rest of the network. Fault confinement is necessary but not sufficient for high-availability systems. In many applications, bus-off isolation prevents further damage but also removes a node from service. This is why controller-level fault tolerance becomes important.

5. Higher-Layer Functional Safety: The Black-Channel Principle

Data-link-layer protection is essential, but functional safety often requires end-to-end mechanisms above the communication controller. Certain error classes, including burst errors, misrouting, repetition, masquerading, delay, and sequence faults, are better addressed at the safety protocol layer.

CANopen Safety [3] is a representative example. It follows the black-channel principle, meaning the safety protocol does not rely on the underlying communication hardware being safety certified. Instead, safety is achieved by adding application-layer mechanisms (Figure 3).

Figure 3: CANopen Safety black-channel architecture and timing supervision using redundant/inverted frames and
validation timing.

Typical mechanisms include:

• Redundant transmission using inverted data frames
• Additional end-to-end CRC
• Sequence counters
• Safety cycle-time monitoring
• Validation-time monitoring between normal and inverted safety frames

This separation is powerful. It allows systems to use conventional communication components while still achieving safety goals at the application layer. However, black-channel protocols do not eliminate the value of safety-enhanced controllers. They provide end-to-end detection, but controller-level mechanisms can detect faults earlier, localize them better, reduce retransmissions, and improve availability.

6. The Role of the CAN Controller in Functional Safety

The controller is the implementation point where protocol theory becomes silicon behavior. A non-compliant or poorly verified controller can compromise the safety assumptions of the entire communication stack. A safety-oriented CAN XL controller contributes in three ways.

First, it correctly enforces protocol-level mechanisms. CRC checking, arbitration behavior, acknowledgment handling, bit-stuffing rules, error signaling, and state transitions must match the standard.

Second, it provides early error detection and localization. A controller can detect bit-level faults, internal state inconsistencies, CRC mismatches, memory errors, and malformed frames before the application layer sees corrupted behavior.

Third, it fails gracefully. Instead of hanging the bus, emitting malformed traffic indefinitely, or silently corrupting data, a well-designed controller transitions through defined error states and reports diagnostic information to the host.

Even in such a controller, internal transient, persistent, or permanent faults may occur. Transient errors may result from electromagnetic interference, voltage disturbances, or single-event upsets. Persistent errors may occur in configuration registers, memories, or finite-state machines. Permanent errors may result from stuck-at faults, bridging faults, or manufacturing defects. The consequences of such silicon faults include:

• frame retransmissions, which make the frame delivery time non-deterministic, and waste communication bandwidth,
• local node unavailability (node enters the Bus-Off state), or even worse
• bus disruption affecting all nodes.

These risks are mitigated by fault-tolerant controllers. A fault-tolerant controller not only detects silicon faults, but it also operates correctly in their presence. In the following section, we will review the basic techniques for the fault-tolerant design of CAN controllers.

6.1 Fault-Tolerant CAN Controller Design

Fault-tolerant controller design mitigates internal faults through redundant logic, protected memories and registers, and self-test facilities. Figure 4 summarizes the principal techniques that we discuss below.

Figure 4: Fault-tolerant controller techniques: modular redundancy, protected memories/registers, and errordetection/
correction logic.

6.1.1 Modular Redundancy

Dual Modular Redundancy instantiates two copies of a critical logic block and compares their outputs. It detects errors but does not, by itself, decide which copy is correct. Lockstep operation can include clock-cycle delay between redundant paths to reduce common-mode susceptibility to transient events.

Triple Modular Redundancy uses three copies and majority voting. It can both detect and correct a single faulty module output and identify which module disagrees with the other two.

Critical CAN XL controller blocks that benefit from redundancy include CRC generators/checkers, error counters, protocol-state machines, and arbitration-related logic.

6.1.2 Memory and register protection

Internal memories and register files can be protected using redundant data encoding. Single-Error Correction, Double-Error Detection (SECDED) ECC can correct single-bit errors and detect double-bit errors. Parity can protect control and status registers where detection is sufficient and correction is not required.

6.1.3 Built-In Self-Test and Error Injection

Safety mechanisms must themselves be testable. Built-In Self-Test and error-injection facilities allow the system to deliberately introduce known faults and verify that detection, correction, and reporting mechanisms respond correctly.

7. Cybersecurity Requirements for CAN XL

Traditional CAN networks are open broadcast networks. Any node connected to the bus can observe traffic, and a compromised node may attempt to inject or replay messages. In a connected vehicle, these are not only information-security risks; they can become safety hazards.

Common threats include spoofing, sniffing, replay, repudiation, and denial of service. CANsec [7] is intended to address these threats for CAN XL communication.

8. CANsec: Link-Layer Security for CAN XL

CANsec is the CAN XL security extension. Its architecture is inspired by MACsec [8], the Ethernet link-layer security model. As illustrated in Figure 5, a secured CAN XL frame carries a CANsec header, protected payload, and an Integrity Check Value used as an authentication tag.

Figure 5: CANsec frame transformation with CANsec header, authenticated and optionally encrypted payload, and Integrity Check Value (ICV).

CANsec can provide authentication, data integrity, optional encryption, and replay protection through freshness values. Key management, including provisioning and rotation, remains a higher-layer or system-level responsibility.

Figure 6 introduces CANsec security channels. A security channel is a logical group of nodes sharing the same security context. This allows different groups of nodes on the same physical CAN XL bus to use different security policies.

Figure 6: CANsec security-channel grouping, allowing secure node groups and unsecured nodes to coexist on the same CAN XL bus.

9. Latency and Throughput Considerations

CANsec adds a header and authentication tag, which consume payload space. Figure 7 illustrates that the relative bandwidth overhead is significant for small payloads but becomes small for larger CAN XL payloads.

Figure 7: CANsec bandwidth overhead as a function of payload size; the relative overhead decreases as CAN XL payloads become larger.

Cryptographic computation is the other major cost. Software AES-GCM [9] on a microcontroller may require hundreds of cycles per byte, potentially producing millisecond-scale latency for large payloads.

The practical conclusion is that CANsec needs hardware acceleration for demanding systems. With dedicated acceleration, authentication and encryption can be completed while the previous frame is still being transmitted. In back-to-back traffic, security computation can be pipelined with bus transfer. The resulting incremental latency can be reduced to nearly zero, leaving only the bandwidth overhead of the CANsec metadata. To demonstrate this, we have used an experimental setup described in the following section.

9.1 Indicative Experimental Results

The experimental setup consists of commercially available IP cores—an embedded 32-bit RISC-V microcontroller, a CAN XL controller, and a CANsec accelerator—all connected via an AHB multilayer interconnect. The operating frequency for all IP cores and the interconnect fabric is set to 200 MHz, and the experimental system transmits frames with a payload size of 128 bytes at a nominal data rate of 20 Mbits/s. In Figure 8 and Figure 9, we show the captured waveforms of the interfaces of the CAN controller and the CANsec core, allowing us to measure the time it takes for CANsec processing and transmission of CAN frames.

Figure 8 shows that CANsec processing is much shorter than the CAN bus transfer time, enabling security processing to be pipelined with transmission. In this test, CANsec processing increased end-to-end latency—from the transmit-side CPU making the frame available to the controller to the receive-side CPU receiving it—by only 6.7%. At lower CAN link data rates, or in the presence of retransmissions, this percentage would be even smaller.

Figure 8: Measured CANsec acceleration timing showing security processing relative to CAN bus transfer time.

Figure 9 illustrates a busy CAN network with back-to-back CAN frame transmissions. In such a case, while one frame is transferred on the bus, the next frame can be authenticated and encrypted. Thus, the incremental cryptographic latency is hidden behind bus-transfer time, not affecting the effective link rate and reducing the actual latency for the delivery of the second CAN frame.

Figure 9: Pipelined CANsec processing for back-to-back frames, where security processing overlaps with bus transfer.

10. Summary and Conclusion

CAN XL should be viewed as a continuation of the CAN safety philosophy. Classical CAN introduced deterministic arbitration, acknowledgment, error detection, retransmission, synchronization, and fault confinement. CAN FD extended bandwidth and payload size while preserving the basic safety model. CAN XL scales the architecture to much larger payloads and higher throughput, adding stronger header protection, long-frame CRC strategy, synchronization support, and security hooks.

For functional safety, CAN XL protocol mechanisms should be combined with higher-layer safety protocols and safety-capable controller implementations. For cybersecurity, CANsec provides link-layer authentication and optional encryption, but practical deployment requires hardware acceleration and system-level key management.

The result is a layered architecture in which protocol, controller, higher-layer safety software, and security acceleration work together. This combination makes CAN XL suitable for next-generation in-vehicle networks that must carry higher-bandwidth traffic while preserving the predictability, fault awareness, and security protections required for safety-relevant automotive systems.

The preceding discussion has focused on the architectural principles behind CAN XL safety and security: protocol-level error detection, higher-layer safety monitoring, controller-level fault tolerance, and hardware-assisted security processing. In practice, these capabilities must be implemented in silicon in a way that preserves protocol compliance, supports safety diagnostics, and avoids turning security into a performance bottleneck. The following section describes one implementation-oriented example: CAST’s CAN XL controller and CANsec acceleration IP.

11. Implementation Example: CAN XL and CANsec IP Cores from CAST

CAST provides IP cores (Figure 10) that address the controller and security-acceleration aspects of CAN XL deployment.

Figure 10: CAST CAN XL controller and CANsec accelerator IP core diagrams for safety- and security-capable deployment.

The CAN XL controller [10] is designed as an ASIL-D-ready controller implementation. Its safety mechanisms include SECDED ECC protection for memories, parity protection for control and status registers, redundant implementation options for critical modules such as CRC generators/checkers, error counters, and protocol-engine logic, and an error-injection facility for safety-mechanism validation.

These mechanisms build on CAST’s long history of delivering CAN IP cores to a broad customer base. For system designers, the important point is not only protocol support but dependable implementation: protocol-level safety features must be enforced by silicon that is itself robust against internal faults.

CAST also offers a CANsec acceleration engine [11]. The accelerator can be tightly integrated with CAST’s CAN XL controller or used as a standalone accelerator with other CAN controller architectures. This flexibility allows system designers to add line-rate authentication and optional encryption without overloading the host processor.

This implementation example addresses two important building blocks in a broader safety and security architecture: the CAN XL controller and CANsec acceleration. System-level functional safety and cybersecurity also require higher-layer safety protocols, system diagnostics, key management, secure provisioning, lifecycle processes, and vehicle-level safety and threat analysis [12], [13]. Within that broader context, controller fault tolerance and efficient CANsec acceleration help ensure that the communication subsystem can support the safety and security goals of the overall design.

12. References

1. ISO, ISO 11898-1:2024, Road vehicles — Controller area network (CAN) — Part 1.
2. CAN in Automation, CAN XL — Extended Data-Field Length.
3. CAN in Automation, CiA 304 — CANopen Framework for Safety-Relevant Communication.
4. A. Mutter and R. Bosch, CAN XL Error Detection Capabilities, CAN Newsletter, June 2020.
5. CAN in Automation: Cyclic Redundancy Check in CAN frames.
6. C. Senger, CRC Error Detection for CAN XL, CAN Newsletter / CiA technical publication, 2020.
7. CAN in Automation, CiA 613-2 — CAN XL Add-On Services: CANsec. Specification for the CANsec data-link-layer security protocol for CAN XL.
8. IEEE, IEEE Std 802.1AE-2018, Standard for Local and Metropolitan Area Networks — Media Access Control (MAC) Security.
9. NIST, SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 2007.
10. CAST, CAN-CTRL: CAN CC, CAN FD, and CAN XL Bus Controller IP Core.
11. CAST, CAN-SEC: CANsec Acceleration Engine IP Core.
12. ISO, ISO 26262 Series, Road vehicles — Functional safety.
13. ISO/SAE, ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering.