CAN XL in the Automotive Industry: History, Technical Capabilities, and Market Outlook

This report was created by Copperhill Technologies, a leading provider of embedded systems solutions specializing in Controller Area Network (CAN) technologies, including both Classical CAN and CAN FD. With extensive experience in automotive, industrial, and off-highway applications, Copperhill Technologies delivers a wide range of development tools, gateways, and custom hardware that support robust and high-performance CAN-based communication systems.

Download our report CAN XL in the Automotive Industry: History, Technical Capabilities, and Market Outlook (PDF)…

From both a personal standpoint and as supported by the findings in this report, I have never been a strong proponent of CAN XL, and I remain skeptical that it will achieve widespread adoption in embedded systems in the way Classical CAN or even CAN FD have. Fundamentally, CAN XL emerged in response to pressure from German automakers—entities that, as recent developments have shown, are no longer at the forefront of innovation in the electric vehicle (EV) space.

The report also confirms that CAN technologies—whether Classical CAN, CAN FD, or CAN XL—are increasingly viewed as supplementary to Automotive Ethernet, not as primary in-vehicle networking solutions. This is consistent with the modest industry uptake of CAN FD, which has fallen short of early expectations. In many low-level control applications, I believe Classical CAN remains not only viable but also the most efficient and cost-effective choice.

Moreover, the notion that transitioning to Automotive Ethernet represents a radical or disruptive change is overstated. A telling example is the National Marine Electronics Association (NMEA), which opted to skip the incremental shift to CAN FD altogether and moved directly to OneNet, the IPv6-based Ethernet standard tailored for marine applications. This decisive move underscores a broader industry sentiment: the time and cost required to adopt CAN XL may not be justified when Ethernet-based solutions already offer superior scalability, bandwidth, and integration with modern software-defined vehicle architectures.

In my view, by the time CAN XL is truly ready for mainstream implementation, most global automakers—except perhaps those in Germany—will have already standardized around Automotive Ethernet. – Wilfried Voss, President & Owner of Copperhill Technologies.

Introduction

Controller Area Network (CAN) bus technology has been a backbone of in-vehicle communications for decades, valued for its simplicity, robustness, and real-time capabilities. However, modern vehicles with advanced driver aids, high-resolution sensors, and over-the-air updates demand far greater bandwidth. This has led to new network solutions: CAN FD (Flexible Data rate) extended CAN’s data rate to ~8 Mbit/s, and Automotive Ethernet introduced 100 Mbit/s or higher speeds. Most recently, CAN XL (Controller Area Network eXtra Long) has emerged as the third-generation CAN protocol, aiming to bridge the gap between traditional CAN and Ethernet. This report provides an academic-style review of CAN XL’s history, technical features, and its reception in the automotive industry. We trace CAN XL’s development (driven largely by German stakeholders), outline its technical benefits (higher data rates, larger payloads, and backward compatibility), and assess its current adoption among major automakers in Germany, the USA (notably Tesla), and China (e.g. BYD). We also compare CAN XL to Automotive Ethernet and Industrial Ethernet in terms of performance, cost, complexity, and ecosystem support. Finally, we evaluate whether CAN XL’s promised benefits are translating into actual market preference and long-term viability in automotive networks.

Historical Development of CAN XL

Origins and Motivation: CAN XL was conceived in response to the growing networking demands in vehicles that classical CAN (1 Mbit/s, 8-byte frames) and even CAN FD (up to 8 Mbit/s, 64-byte frames) could not fully satisfy. By the late 2010s, automakers sought a higher-bandwidth bus that retained CAN’s low-cost, real-time attributes. In 2018, the nonprofit CiA (CAN in Automation) – which coordinates CAN standards – launched the CAN XL development as the “third CAN generation,” initiated by a request from Volkswagen. Volkswagen’s interest signaled a strong industry need for a CAN successor. Early development was spearheaded by VW engineers (Carsten Schanze, Alexander Müller) for the core protocol ideas, with significant contributions from Bosch (Dr. Arthur Mutter) and Fraunhofer (Ralf Hildebrand) experts. This collaborative approach echoed how Bosch had led CAN’s original development in the 1980s, underscoring the continued role of German automakers and suppliers in advancing in-vehicle networking.

Key Milestones: Throughout 2019–2021, CiA working groups fleshed out CAN XL’s data link layer (CiA 610-1 specification) and a new physical layer using faster transceivers. Notably, CAN XL introduced a novel Physical Medium Attachment using pulse-width modulation (PWM) coding instead of the traditional non-return-to-zero (NRZ). Engineers from NXP (Matthias Muth) proposed the PWM scheme, which allows CAN XL transceivers to switch to a high-speed mode for data transmission. This “CAN SIC XL” transceiver technology (Signal Improvement Capability for CAN XL) enables bit rates up to 10–20 Mbit/s on the same two-wire bus. By 2021, prototypes of CAN XL controllers and transceivers were available, and industry plug-fests were held to validate interoperability. In 2022, draft CAN XL specs were submitted to ISO, and by early 2024 the ISO 11898 standard (which governs CAN) was formally updated: the third editions of ISO 11898-1 and ISO 11898-2 now integrate CAN XL as an official standard. This means CAN XL is standardized as of ISO 11898-1:2024 and 11898-2:2024. Major automotive software frameworks like AUTOSAR have also added support for CAN XL, preparing it for series development.

Stakeholders: The development of CAN XL has been driven by a consortium of German industry players and CiA members. Bosch developed and released a new CAN XL controller IP (called “X_CAN”) that supports Classical CAN, CAN FD, and CAN XL. Semiconductor companies including NXP, Infineon, Renesas, and STMicroelectronics announced microcontrollers with CAN XL support (e.g. Infineon AURIX TC4xx and ST Stellar P6 families for 2024 vehicles). These stakeholders underscore a strong ecosystem push: many are the same companies behind earlier CAN innovations. German OEMs (led by VW) were early proponents, while organizations like CiA ensured open specification and interoperability. In summary, by 2024 CAN XL moved from concept to standardized technology, backed by a ready ecosystem of IP, transceivers, and software support.

Technical Features and Benefits of CAN XL

CAN XL’s design extends and modifies the CAN protocol to achieve higher throughput while retaining real-time control capabilities and backward compatibility. Key technical features and benefits include:

• Higher Data Rates: CAN XL significantly increases the achievable data rate on a CAN network. Like CAN FD, it separates the arbitration phase (where nodes contend for the bus) from the data phase. The arbitration phase in CAN XL still operates up to 1 Mbit/s (to maintain compatibility with CAN/CAN FD arbitration), but once a CAN XL frame wins arbitration, it enters a Fast Data phase that can run at 10 Mbit/s or even up to 20 Mbit/s with suitable transceivers. In practice, current CAN SIC XL transceivers support up to 10 Mbit/s over typical automotive cabling, and up to 20 Mbit/s on shorter runs or optimized cabling. This is an order-of-magnitude jump from Classical CAN’s 1 Mbit/s, bringing CAN XL into the low tens of Mbps realm – a range previously exclusive to Automotive Ethernet (10BASE-T1S at 10 Mbps, or 100BASE-T1 at 100 Mbps). Higher bit rates allow CAN XL to carry more sensor and diagnostic data or to support firmware updates much faster than before. For example, CAN FD at 8 Mbit/s is barely sufficient for compressed 1080p video streaming, whereas CAN XL at 10–20 Mbit/s could handle such high-volume data with some margin, extending CAN’s utility in data-intensive applications.
• Longer Payloads: The “XL” in CAN XL refers to its extra-long payload capacity. CAN XL frames can carry up to 2048 bytes of data in a single frame. This is a dramatic increase compared to 8 bytes in Classical CAN and 64 bytes in CAN FD. Such a large payload means protocols that traditionally fragment their data over many CAN messages (for instance, diagnostic protocols or software downloads) can send large chunks in one frame. A single CAN XL frame can transmit the equivalent of 32 CAN FD frames worth of data. The benefit is higher efficiency (lower overhead per byte) and the ability to encapsulate larger protocol data units. For example, sending a large sensor snapshot or an Ethernet frame (1500-byte MTU) over CAN XL becomes feasible within one CAN XL frame. Real-time considerations: A 2048-byte CAN XL frame at 10 Mbps takes roughly 2 ms on the bus, which, while longer than typical CAN frames, is still short enough for many control applications. To ensure this doesn’t introduce undue latency for high-priority signals, CAN XL has an option for frame fragmentation: a longer frame can be interrupted (preempted) by a high-priority message if needed. This feature, specified in an add-on LLC (Logical Link Control) layer, guarantees that urgent control messages can get through with low latency even while large CAN XL frames are being transmitted. In essence, CAN XL’s payload boosts throughput without sacrificing real-time performance, thanks to protocol features that manage frame timing and priority.
• Real-Time Arbitration and Priorities: CAN XL retains CAN’s CSMA/CR arbitration mechanism (Carrier Sense Multiple Access with Collision Resolution) for bus access. Importantly, it introduces a new frame format that separates message priority from content. Instead of a single identifier field doubling as both priority and message ID (as in Classical CAN), CAN XL has an 11-bit “Priority” field used purely for arbitration, and a separate “Acceptance Field” (ID field) of 32 bits for content addressing. The 11-bit priority ensures backward compatibility with CAN’s arbitration concept – lower numerical value means higher priority and wins bus access by asserting a dominant bit. The larger 32-bit ID (plus a 4-bit SDU Type field) allows an extremely large number of distinct message types and even a protocol type indicator, analogous to an EtherType, enabling multiple higher-layer protocols to coexist on the same bus. The upshot is that CAN XL can natively support service-oriented communication (where messages might carry different protocol payloads) and better integrate with Ethernet/IP networks (since an Ethernet frame can be mapped into a CAN XL frame and distinguished by this protocol identifier). Through all these changes, CAN XL maintains deterministic real-time behavior: the non-destructive priority arbitration is preserved, meaning a higher-priority frame will always win access without corrupting the lower-priority frame (the lower-priority node simply backs off, as with classic CAN). This inherent prioritization and latency guarantee is a key advantage over standard Ethernet, which requires additional Quality-of-Service mechanisms for similar real-time guarantees.
• Backward Compatibility: A notable design goal for CAN XL was smooth coexistence with existing CAN and CAN FD networks. While CAN XL is not directly interoperable on the same bus with Classical CAN (the frame formats differ), the CAN XL protocol controllers are generally designed to be multi-protocol. Bosch’s CAN XL IP, for example, supports Classical CAN and CAN FD in addition to CAN XL. This means an automaker can deploy hardware that speaks CAN XL but can fall back to CAN FD or CAN as needed. Moreover, CAN XL’s specification explicitly allows CAN FD frames to be sent on a CAN XL bus as a subset. In practice a CAN XL network can be configured to accept legacy CAN/CAN FD frames, treating them appropriately – this is aided by the protocol type field which can indicate if a frame is a legacy CAN frame or a CAN XL frame. CiA notes that CAN XL “enables integration of CAN FD nodes into CAN XL networks”, easing migration. From a software perspective, the API and object layer remain similar, and even the CAN XL transceivers (CAN SIC XL) are designed to be compatible with older CAN physical layers when operating at lower speeds. In summary, an OEM can introduce CAN XL in new parts of the vehicle network while still supporting existing CAN messages – a degree of backward compatibility that reduces the barrier to adoption compared to a completely new protocol.
• Robustness and Reliability: CAN XL continues CAN’s tradition of robust operation in harsh environments. It uses differential two-wire transmission and retains CAN’s extensive error detection (with some enhancements). For example, CAN XL frames include two cyclic redundancy checks: a 13-bit partial CRC covering the header and a 32-bit full CRC for the data section. This double CRC improves error detection for long frames, ensuring data integrity even as payloads grow. CAN XL also inherits CAN’s fault confinement (nodes will automatically disconnect if malfunctioning) and adds optional CANsec security at the data link layer. CANsec (specified in CiA 613-2) can provide authentication and encryption of CAN XL frames for cybersecurity, a growing concern for connected cars. This security is designed to work “at line-speed” without sacrificing performance. Additionally, CAN XL networks can support virtual CAN channels – essentially allowing multiple logical bus segments over one physical bus by tagging frames, which can aid in isolating traffic types. All these features contribute to a robust, flexible communication system.
• Integration with Ethernet: A unique selling point of CAN XL is its deliberate alignment with Ethernet-based networking. The protocol’s designers envision CAN XL working “in conjunction with Ethernet networks”, not in isolation. Indeed, CAN XL can serve as a feeder or sub-network that seamlessly interfaces with an Ethernet backbone. The CAN XL frame format’s protocol type field allows carrying or identifying Ethernet frames (e.g., an IPv6 packet could be sent via CAN XL). Research has explored Composite CAN XL–Ethernet networks where, for example, a CAN XL bus might act as a deterministic backup or extension to an Ethernet network. In practical terms, this means a vehicle could use an Ethernet backbone for high-bandwidth data and have CAN XL buses in zones or subsystems, with gateways mapping traffic between them. CAN XL supports concepts like service-oriented communication that are common in Ethernet/IP networks (e.g., AUTOSAR Some/IP services). In other words, it’s designed not just as a faster CAN, but as a CAN that speaks the “language” of modern service-based architectures. This interoperability extends the lifespan of CAN technology by making it part of the Ethernet-dominated future of automotive networks, rather than a separate legacy bus.

In summary, CAN XL provides higher throughput (10–20 Mbit/s) and far larger frame payloads (up to 2048 bytes), while preserving CAN’s real-time, priority-based arbitration and robust low-cost physical layer. It introduces flexible addressing and protocol support to integrate with contemporary network architectures. Optional features like CANsec security and frame fragmentation ensure that CAN XL meets modern requirements for safety and security. Because of careful design for backward compatibility and Ethernet integration, CAN XL is touted as an evolutionary upgrade that could be deployed incrementally in vehicles – leveraging existing CAN infrastructure and knowledge, rather than requiring a wholesale replacement. The next sections investigate to what extent these advertised benefits are leading to actual adoption in the automotive industry.

Current Adoption and Market Acceptance

Despite its technical merits, CAN XL’s real-world adoption in vehicles is just beginning. As of 2024, CAN XL is not yet in series production on any mainstream vehicle models. The rollout has been cautious, with many automakers still evaluating the technology or focusing on its predecessor (CAN FD) and on Ethernet solutions. Below we assess adoption region-wise:

German Automakers and Tier-1 Suppliers

German companies have been at the forefront of CAN XL development, so it is unsurprising that they also lead in plans for adoption. Volkswagen (VW), which initiated CAN XL, has explicitly included it in their future in-vehicle network strategy. In a 2021 CAN Conference, VW outlined a transition to a new zonal E/E architecture using CAN FD and CAN XL to replace all legacy CAN buses in next-generation models. The plan is that classical CAN networks will be phased out, with CAN FD handling most standard communication (up to 64-byte frames) and CAN XL used where even higher bandwidth or payload is needed. VW’s approach is pragmatic – they noted that moving to zone controllers (centralizing functions) shortens network lengths (reducing weight) while CAN FD and CAN XL, combined with improved transceivers, can provide the needed bandwidth for these domains. In essence, VW envisions a hierarchy: an Ethernet backbone for ultra-high data (infotainment, ADAS sensors), and CAN FD/XL for zonal or lower-speed domains (powertrain, body control, etc.), all within a streamlined architecture. This indicates a significant endorsement of CAN XL from Europe’s largest automaker, suggesting that VW’s upcoming platforms (mid-2020s) may be among the first to feature CAN XL networks in production. VW’s promotion of CAN XL has also influenced the AUTOSAR consortium (where German OEMs are key members) to include CAN XL support, ensuring that software architects can design for it.

Other German automakers are likewise interested, though details are less public. BMW and Daimler (Mercedes-Benz), which historically spearheaded alternatives like FlexRay, are now focused on Ethernet for high-speed needs but still rely on CAN/CAN FD for many functions. They are likely evaluating CAN XL as a potential supplement or replacement for some CAN FD buses. The German supplier Bosch, having developed CAN XL IP and the first CAN XL silicon, is actively championing the technology to its OEM customers globally. Bosch’s CAN XL transceiver (physical layer chip) was presented in late 2022, supporting up to 20 Mbit/s and designed to be a drop-in upgrade for CAN FD networks. Likewise, Vector, a prominent automotive networking tools provider in Germany, has released CAN XL-capable tools (interfaces, simulators) and published materials to educate industry about CAN XL. This ecosystem readiness in Germany is high. Thus, German automakers – especially VW Group (including Audi, Porsche) and possibly others following – are poised to be early adopters of CAN XL, integrating it in phases alongside Ethernet. Initial use cases may include high-bandwidth sensor hubs, gateways bridging to Ethernet, or OTA firmware update channels where the 2kB frame size is beneficial.

United States Automakers (including Tesla)

In the United States, adoption of CAN XL is more tentative. Traditional Big-3 OEMs (GM, Ford, Stellantis) have not publicly announced CAN XL implementations as of 2025, and many are still in the process of rolling out CAN FD and Ethernet. General Motors (GM), for instance, introduced CAN FD in some platforms around 2019 for faster module reprogramming and some driver-assist sensor networks, but classical CAN remains prevalent for powertrain and body domains. GM has heavily invested in Automotive Ethernet (especially for the backbone of its Ultra Cruise and autonomous vehicle programs), potentially lessening the need for another interim bus like CAN XL. Ford similarly uses CAN FD in newer models’ infotainment and uses Ethernet for ADAS. These OEMs may take a wait-and-see approach on CAN XL: given that their suppliers (Bosch, NXP, etc.) will make CAN XL capabilities largely available by default in next-gen controllers, the OEMs could enable it later if a clear use case appears. For now, their focus appears to be on proven networks and simplifying architectures rather than adopting a brand-new bus type.

A special case is Tesla, which has diverged sharply from conventional CAN networking. Tesla’s vehicles initially used CAN buses like any modern car, but as their technology advanced, Tesla found CAN (even CAN FD) insufficient for the massive data volumes and speed requirements of their systems. Over the past couple of years, Tesla has been actively developing a next-generation in-vehicle network that essentially bypasses CAN altogether. According to Tesla’s disclosures and patents, this new network is a form of Time Division Multiple Access (TDMA) architecture operating over a 48-volt power distribution system. In simpler terms, Tesla is creating a centrally orchestrated network where each node is given precise time slots to communicate, eliminating collisions and ensuring guaranteed latency. The network will likely run over either automotive Ethernet physical layers or even power-line communication (PLC) on the vehicle’s wiring. The motivation is to achieve a unified, high-speed network that can carry everything from control signals to high-bandwidth sensor data with strict timing (leveraging concepts similar to Time-Sensitive Networking). Tesla’s Cybertruck and future platforms are expected to implement this new architecture, which they view as the successor to CAN bus in their designs.

Given this strategy, Tesla is unlikely to adopt CAN XL, as it is instead leapfrogging to a different paradigm entirely. In Tesla’s view, even CAN FD’s ~8 Mbit/s was “glacial” for modern needs, and they opted to pursue >100 Mbit/s networks with microsecond-level time slots for critical data. Tesla’s approach underscores a broader point: some automakers, especially those pushing the envelope on autonomous driving, may prefer to invest in Ethernet-based or other novel networking solutions rather than a faster CAN. Tesla’s stance could influence other tech-focused EV makers in the U.S. to consider skipping CAN XL. For example, startups or high-end EV brands might go straight to gigabit Ethernet and deterministic networking for all high-speed needs, keeping only minimal CAN (or CAN FD) for legacy compatibility.

In summary, among U.S. automakers, no production use of CAN XL is known as of 2025. The big players continue to use classical CAN and CAN FD widely (due to cost and inertia), with Ethernet being adopted for high-data subsystems. Tesla’s case demonstrates an explicit move away from CAN-type buses altogether in favor of a centralized Ethernet/TDMA network. This indicates some skepticism in the U.S. market about the necessity of CAN XL – the view being that if a major network overhaul is needed, one might go directly to Ethernet or other advanced architectures rather than implement another CAN variant.

Chinese Automakers (including BYD)

In China, the automotive landscape is very dynamic, especially with the rapid growth of electric vehicle (EV) manufacturers like BYD, NIO, Xpeng, Geely, and others. Chinese automakers historically have utilized CAN bus extensively (often multiple CAN networks per vehicle, similar to Western designs) and, in newer EV models, have begun integrating CAN FD and Ethernet where appropriate. BYD, one of the world’s largest EV producers, has not publicly detailed its in-vehicle network architecture in depth. However, given BYD’s focus on cutting-edge battery and EV tech, it’s likely they use CAN FD for battery management systems and other critical ECUs, and possibly Automotive Ethernet for high-bandwidth components like infotainment or advanced ADAS sensors (e.g. some BYD models feature robust connectivity and driver assist features that would benefit from Ethernet). To date, there are no clear public reports of BYD adopting CAN XL specifically – which is unsurprising, as CAN XL was only standardized in 2024 and primarily driven by German organizations. Chinese OEMs often source technology from global Tier-1 suppliers; thus, as Bosch, NXP, and others roll out CAN XL-ready hardware, we can expect Chinese automakers to evaluate it in upcoming platforms.

China’s domestic suppliers and tech forums have started discussing CAN XL in the context of next-gen vehicle networks, often alongside Automotive Ethernet. One direct competitor to CAN XL that is notable: the IEEE 10BASE-T1S Ethernet standard (a 10 Mbps multi-drop single-pair Ethernet) has been highlighted in some sources as an attractive option for automotive use in place of CAN. Notably, 10BASE-T1S is seen as “a direct competitor of CAN XL in the automotive space”, offering similar 10 Mbps bus capabilities but with native Ethernet compatibility. Chinese automakers, who are very focused on connectivity and “software-defined” vehicles, might lean towards such Ethernet-based solutions (which fit into an Ethernet/IP framework) rather than championing a new CAN flavor on their own. However, Chinese companies also prioritize cost-effectiveness and reliable local supply chains. If CAN XL can be delivered affordably in Chinese-made MCUs and if it simplifies certain network designs, it could see adoption.

As of 2025, no Chinese OEM has announced CAN XL deployment, but companies like Great Wall Motor, GAC Aion, and others are redesigning their electrical/electronic (E/E) architectures to zonal layouts, similar to Western trends. They will be weighing whether to use CAN FD vs. CAN XL for zone controller networks below the Ethernet backbone. China’s automotive market often moves quickly once a technology is proven – so if, for example, Volkswagen launches vehicles with CAN XL and demonstrates benefits, Chinese automakers may follow suit, possibly in collaboration with their Tier-1 suppliers or via partnerships with technology companies. In addition, China’s heavy commercial vehicle sector (trucks, buses) which uses CAN (and J1939 over CAN) might see value in CAN XL for its higher bandwidth, especially as those vehicles become more connected and instrumented.

In summary, current adoption of CAN XL is nascent. It is essentially in a pre-production or early adoption phase globally. German automakers (VW first and foremost) are preparing to use it in the near future, given their direct involvement in its creation. American automakers are more cautious or pursuing other tech, with Tesla outright dismissing CAN XL in favor of a different networking concept. Chinese automakers are likely taking a pragmatic approach, watching global developments; they will adopt CAN XL if it offers clear advantages in cost or integration for their high-volume EV platforms, otherwise defaulting to CAN FD and Ethernet which are already in use.

It’s telling that industry surveys and experts have noted the slow transition even from classical CAN to CAN FD: as of 2024, the vast majority of vehicles still rely on Classical CAN, with CAN FD present only in a minority of use-cases, and CAN XL in effectively 0% of vehicles on the road. One CAN bus analytics firm observed that “less than 0.1% of use cases involve CAN FD as of 2024 and 0% involve CAN XL (not yet deployed in the field)”. This indicates that automotive engineers are conservative in adopting new network protocols – changes happen slowly due to the long vehicle development cycles, the cost sensitivity, and the requirement for proven reliability. The following section will compare CAN XL to other network technologies to further understand its potential niche and whether it can overcome the inertia favoring established solutions.

CAN XL vs. Automotive Ethernet vs. Industrial Ethernet

How does CAN XL stack up against Automotive Ethernet (the IP/Ethernet networks now used in cars) and Industrial Ethernet (Ethernet-based fieldbuses used in factories and automation)? Each of these networking technologies has distinct strengths. We compare them across performance, cost, complexity, and ecosystem support:

Performance (Bandwidth and Real-Time): CAN XL offers up to 10–20 Mbit/s data rates, which is a leap for CAN but still below Ethernet’s speeds. Automotive Ethernet today commonly runs at 100 Mbit/s (100BASE-T1), 1 Gbit/s, or more, per link. Industrial Ethernet protocols (like EtherCAT, PROFINET, etc.) typically use 100 Mbit/s full-duplex or Gigabit to meet real-time control needs in automation. Thus, in pure bandwidth, CAN XL < Automotive Ethernet < high-end Industrial Ethernet. However, throughput is only one aspect: real-time latency and determinism are equally important in control systems. Here, CAN XL has an inherent advantage of CAN’s arbitration – short high-priority messages get through almost immediately with microsecond-level latency once the bus is free. Ethernet by itself is not deterministic (it’s packet-switched and typically asynchronous), but modern Automotive Ethernet employs Time-Sensitive Networking (TSN) extensions to guarantee latency and synchronization. For example, IEEE 802.3br frame preemption allows an Ethernet switch to interrupt a large low-priority frame to send a high-priority frame with minimal delay, effectively mimicking CAN’s priority arbitration in a full-duplex environment. Industrial Ethernet networks have long used deterministic scheduling (e.g., EtherCAT processes a fixed cycle every 1 ms or less, Profinet IRT uses time slots, etc.). So determinism can be achieved on Ethernet but at the cost of more complex switch and protocol configuration (TSN standards, scheduling, etc.), whereas CAN XL carries its simple built-in priority system. In summary, Automotive Ethernet can far exceed CAN XL in raw bandwidth, especially for streaming data (camera feeds, etc.), but CAN XL can achieve lower worst-case latency for brief control messages due to its bus arbitration. Industrial Ethernet, in high-end forms, generally outperforms both in bandwidth and matches or exceeds CAN XL in real-time control (given specialized hardware), but typically at higher cost.

Cost and Complexity: One reason CAN bus has survived so long is its low cost. A classical CAN transceiver and controller (integrated in most automotive MCUs) is very inexpensive, and the wiring (a simple twisted pair bus) is lightweight and simple. Adding more CAN buses to a car is relatively cheap, which is why some cars ended up with a dozen CAN segments for different domains. Ethernet, on the other hand, traditionally required more complex PHY chips, magnetics or transformers for coupling, and point-to-point cabling to switches – all adding cost. Automotive Ethernet has been cost-optimized (using single-pair unshielded cables and compact PHYs), but an Ethernet network still needs switching infrastructure (or at least active hubs) and more powerful processors in the ECUs to handle the TCP/IP or SOME/IP stacks. This makes Ethernet more expensive and complex particularly for simple devices. Even in 2025, a basic CAN node (just a microcontroller and CAN transceiver) is cheaper than an Ethernet node that might need a microprocessor and an Ethernet PHY. CAN XL inherits much of CAN’s cost-effectiveness: it can run on the same two-wire bus (with upgraded transceivers) and does not necessarily require a switch (it’s multi-drop). Thus, for lower-speed domains or less data-intensive networks, CAN XL can be more cost-efficient than adding an Ethernet switch port for every device. Industrial Ethernet, in factory automation, often tolerates higher costs – PLCs and industrial switches are expensive, but justified by performance and scale. In cars, cost is critical; a few dollars more per vehicle is significant in mass production. So if an automaker only needs ~10 Mbps in a certain subsystem, CAN XL could meet the need without the expense of moving that subsystem to Ethernet. Complexity-wise, CAN XL is also simpler to configure (no MAC addresses, no network routing – just message IDs and bus arbitration). Ethernet’s complexity comes from MAC addressing, IPv4/IPv6, switching logic, etc., which require careful design (though efforts like SOME/IP and service discovery in Autosar have made using Ethernet in cars more plug-and-play). In short, CAN XL targets a sweet spot where its added performance is useful but a full Ethernet network might be overkill in cost or complexity.

Ecosystem and Support: CAN bus has a vast ecosystem built over 30+ years – diagnostic tools, software stacks (CANopen, J1939, OBD-II diagnostics), and a workforce of engineers familiar with it. CAN XL benefits from backward compatibility here: it can leverage existing software (with updates for larger payloads) and is already included in Autosar (the standard automotive software platform). Tool vendors like Vector, PEAK, and others added CAN XL support to their analyzers and test equipment as early as 2022, so developers can work with CAN XL similarly to CAN/CAN FD. Ethernet, by contrast, brings in the huge ecosystem of IT and computer networking – which means a wealth of technology (protocols, security, existing silicon from the consumer industry) but also a learning curve for automotive teams historically used to CAN. In recent years, the automotive industry has adapted many IT protocols (UDP/TCP, RESTful APIs over SOME/IP, etc.) to vehicles, and the “vehicle as a data center on wheels” concept is gaining traction. This favors Ethernet’s ecosystem in the long run because it aligns with general connectivity trends (for example, over-the-air updates to multiple ECUs are far faster and easier with an Ethernet backbone). Industrial Ethernet has its own specialized ecosystem – for instance, many motion-control systems speak EtherCAT or PROFINET, and vendors provide integrated solutions for those. CAN (with CANopen) was once dominant in industrial automation for lower-level control, but today Ethernet-based fieldbuses have largely taken over high-performance control, relegating CAN to simpler tasks. A similar pattern could occur in automotive: Ethernet for high-performance, CAN/XL for simpler or legacy needs. It’s worth noting that Ethernet’s ecosystem includes robust security (built-in IP layer security, mature encryption standards) which CAN XL is just starting to address (via CANsec). Also, Ethernet and Wi-Fi are the basis for V2X (vehicle-to-everything) communications and many off-board services, which further entrenches Ethernet/IP technology in the vehicle. Thus, while CAN XL is well-supported within the traditional automotive ecosystem, the broader industry momentum and developer mindshare is increasingly with Ethernet-based networking.

Capability and Use-Case Fit: CAN XL and Ethernet also differ in the qualitative nature of what they support. CAN (all versions) is inherently a broadcast bus – every message can be received by every node (unless filtered). This is great for certain control applications (e.g., one sensor update is seen by multiple controllers interested in that data) and for diagnostics (you can log all traffic from a single point). Ethernet is typically unicast or multicast; broadcast is limited to network management tasks. Achieving the one-to-many data distribution in Ethernet requires configuring multicast groups or having multiple subscribe mechanisms – doable, but more configuration. CAN’s data is also very low-overhead (no headers aside from the 11/29-bit ID), whereas Ethernet frames carry at least 18 bytes of MAC/IP headers if used with IP, plus protocol overhead. On the other hand, Ethernet can carry video streams, large files, and internet protocols seamlessly, which CAN XL even with 2048-byte frames would struggle with due to latency and throughput constraints (imagine trying to stream a camera feed over CAN XL – it would likely need compression and still use a good portion of the 10 Mbps bandwidth). Industrial Ethernet is often optimized for cyclic data and integrates higher-level protocol features (like object dictionaries in EtherNet/IP or motion profiles in SERCOS). CAN XL remains a fairly low-level transport – a very good one for sensor/actuator control messages and diagnostics, but not a complete networking solution for high-level services.

To illustrate the comparison, Table 1 highlights some differences among CAN XL, automotive Ethernet, and an example industrial Ethernet (EtherCAT as a representative):

Table 1: Comparison of CAN XL with Automotive and Industrial Ethernet in key aspects. (Automotive Ethernet refers to in-vehicle usage of Ethernet/IP networking; Industrial Ethernet refers to Ethernet-based deterministic protocols in automation. Sources: CAN XL specs; industry analyses.)

As Table 1 suggests, each network technology has its niche. Automotive Ethernet excels in raw performance and seamless integration with external networks (necessary for autonomous driving data and connected services), but comes with higher cost and complexity in implementation. CAN XL significantly upgrades CAN capabilities and is well-suited for continued use in traditional automotive domains that demand more bandwidth (like gateways or high-performance ECU networks) yet still prioritize low cost, simplicity, and reliability. It effectively fills a gap: providing a mid-speed network option that is more efficient than CAN FD but not as costly or complex as Ethernet. Industrial Ethernet solutions show where the future could lead – ultra-deterministic, high-speed networks for control – but automotive adoption of those concepts (like TSN) will depend on cost and necessity. Already, we see overlap: Ethernet TSN in cars is borrowing ideas from industrial control, and conversely CAN XL could find use in some industrial or commercial vehicle contexts where its features suffice without needing a full Ethernet stack.

An interesting direct comparison is between CAN XL and 10BASE-T1S Automotive Ethernet. Both aim at ~10 Mbit/s and support multi-drop topology. 10BASE-T1S, standardized in 2019, uses a special PHY-level collision avoidance (PLCA) to allow multiple nodes on a single coax or twisted pair bus. In essence, it lets Ethernet operate a bit like CAN (scheduled access to avoid collisions) on a simple bus, and it can also be seen as a competitor to CAN XL for low-cost domains. The advantage of 10BASE-T1S is that it directly carries Ethernet packets, making integration to the rest of the car’s Ethernet network seamless. CAN XL’s advantage is leveraging existing CAN silicon and infrastructure, and likely lower quiescent power draw (Ethernet PHYs even at 10 Mbps may consume more power than a CAN transceiver). The competition between these two will be a litmus test of whether the industry leans toward extending CAN technology or going all-Ethernet even for traditionally CAN roles.

Market Preference and Future Viability of CAN XL

The big question is: do CAN XL’s benefits translate to a sustained market preference, or will it be bypassed by Ethernet-based networks? Based on the current trajectory, CAN XL’s long-term viability in automotive appears to be as a complementary technology, rather than a dominant backbone. Its advertised benefits are real – greater speed and payload, with CAN’s real-time ease – but the market is cautious and also heavily invested in Ethernet.

One must consider the historical pattern: Classical CAN (1 Mbps) was ubiquitous from the 1990s through 2010s. When CAN FD was introduced (circa 2012), many expected it to rapidly supplant Classical CAN in new vehicles by the late 2010s. That transition has been much slower than anticipated. By 2024, a large portion of CAN FD’s use remains in niche areas (e.g., internal ECU bridging, some diagnostic links), and Classical CAN still “dominates” vehicles on the road. Industry experts have grown skeptical that CAN FD will ever fully replace Classical CAN in all applications. This precedent suggests that introducing CAN XL will face inertia: automakers may find that Classical CAN (with perhaps a few CAN FD upgrades) is “good enough” for many functions, and for those that are not, they might jump straight to Ethernet.

Indeed, automotive networks are moving toward a two-pronged approach: Ethernet for high-speed data and CAN for robust low-speed control. In the foreseeable future, rather than one technology killing the other, a heterogeneous network is likely. “Ethernet will not displace CAN – it will complement it” as one industry article summarized. Ethernet is expected to gradually take over the central and data-heavy roles (especially as vehicles become more software-defined and connected), but CAN (and CAN FD/XL) remain very cost-effective for sensor/actuator loops and fail-safe redundancies. In this context, CAN XL can thrive if it slots into the complementary role without over-complicating things. For example, an automaker may use a 1 Gbit Ethernet backbones but still include some CAN XL subnets for safety-critical communication that must continue even if the Ethernet network is down (a “limp-home” bus). Or use CAN XL in places where adding an Ethernet switch port isn’t justified but CAN FD’s 8 byte frame is too limiting for efficiency.

Another factor in market preference is ecosystem readiness vs. risk. CAN XL is new and unproven in mass production. Automotive Ethernet, while newer than CAN, leverages decades of enterprise Ethernet development and a broad skills base. OEMs may prefer known quantities for core vehicle functions – any new protocol must go through years of validation. CAN XL will likely see initial use in a constrained manner (e.g., between a few ECUs from the same vendor) to build confidence. If any issues arise (interoperability, unexpected error modes), that could hamper wider acceptance. However, since CAN XL is an evolution of CAN, the risk is perceived as lower than completely new protocols. The support from ISO and Autosar, and the availability of chips from top suppliers, gives OEMs a safety net that this is not a proprietary or transient tech.

German luxury brands vs. Tesla’s approach is illustrative: Companies like Mercedes-Benz, BMW, Audi – they must balance cutting-edge features with extreme reliability and compatibility. They tend to introduce changes incrementally. For such companies, CAN XL might be appealing as an incremental upgrade (especially given their involvement via Autosar). Tesla, a newer entrant, is willing to overhaul the network design entirely in pursuit of a high-tech vision, showing less interest in intermediate steps like CAN XL. Traditional OEMs might not all go as far as Tesla’s radical redesign; they might prefer an evolutionary path that CAN XL offers. This difference in philosophy will influence market outcomes. If Tesla’s approach proves vastly superior (in weight reduction, ease of manufacturing, etc.), others might emulate it, which could marginalize CAN XL. Conversely, if Tesla encounters challenges (e.g., EMI issues using power-line communication, or high development costs for custom networking), more conservative approaches like CAN XL plus Ethernet could be validated.

Long-term viability: The longevity of CAN XL will ultimately depend on whether it can establish a clear use-case that isn’t easily covered by Ethernet as Ethernet technology evolves. Right now, CAN XL’s niche is roughly “5–20 Mbit/s, low-cost, real-time bus.” Ethernet is already encroaching from above (down to 10 Mbps with 10BASE-T1S) and possibly from below (very-low-cost Ethernet controllers could emerge). If Ethernet solutions can be made as cheap and low-power as CAN, then Ethernet might “throw CAN XL under the bus,” so to speak, by making it unnecessary. However, even in optimistic Ethernet adoption scenarios, legacy support and fail-safe considerations will keep CAN-based buses in vehicles at least through the 2030s. The question is whether those buses will be CAN XL or just CAN FD. Given that CAN XL is backward-compatible and offers performance headroom, it has a strong chance of becoming the standard for new CAN installations – essentially future-proofing the CAN side of the network.

Major Tier-1 suppliers appear to hedge bets by offering hybrid networking solutions. For instance, some propose combining CAN XL and Ethernet in vehicles such that CAN XL handles critical low-level control communication with guaranteed latency, while Ethernet carries bulk data and connects to cloud services. Such composite networks could be the norm: a vehicle domain controller might have both a CAN XL interface (for local real-time control of actuators) and a Gigabit Ethernet interface (for connecting to the central computer or backbone). If CAN XL finds that kind of role, it could be very viable long-term as part of the multi-network topology of cars.

From a market standpoint, European OEMs (especially German) are likely to be the champions that carry CAN XL into production in the latter half of the 2020s. If their implementations prove successful, American and Asian automakers will adopt “second wave” perhaps by early 2030s for new platforms. If, however, adoption remains tepid (e.g., if VW’s use of CAN XL is limited or short-lived), CAN XL could stall and remain a niche, with Ethernet-based networks overtaking it quickly. One encouraging sign for CAN XL is that it has been included in the roadmap of standards like Autosar and ISO – indicating a commitment to keep it in the toolbox. Additionally, the automotive industry values redundancy and diversity for safety: having both an Ethernet network and a CAN XL network offers redundancy paths (for example, if a cyber-attack or fault takes down the IP network, a CAN XL bus might still operate critical functions). This systems perspective might ensure CAN XL isn’t seen as redundant even when Ethernet is ubiquitous.

In the industrial domain, CAN XL might also find some life (though our focus is automotive). CAN XL’s large payload and built-in security could make it a candidate for upgrading CAN-based industrial systems (like some robotics or heavy machinery that still use CANopen or J1939). Its interplay with Industrial Ethernet (like PROFINET or EtherNet/IP) could mirror the automotive CAN XL vs. Ethernet story: used as a lower-tier network beneath an Ethernet supervisory layer. If that happens, it could increase volume and reduce costs for CAN XL components, indirectly boosting automotive viability too.

Conclusion

CAN XL represents a significant technical evolution of the venerable CAN bus, bringing higher speeds and more flexible communication to meet the demands of modern vehicles. Historically, CAN was revolutionary for automotive electronics, and CAN XL seeks to extend that legacy into the coming decade by offering a pathway to higher performance without abandoning CAN’s core strengths of simplicity, reliability, and real-time control.

From a historical perspective, CAN XL’s development was driven by the German automotive industry’s foresight – recognizing around 2018 that an upgrade would be needed beyond CAN FD for future E/E architectures. With contributions from companies like VW, Bosch, and others, CAN XL quickly went from concept to a standardized reality by 2024. This rapid development reflects both the urgent need for better in-vehicle networks and the strong support from key stakeholders.

Our examination of technical capabilities showed that CAN XL indeed fulfills its promises on paper: supporting data rates up to 10–20 Mbit/s and 2048-byte frames, introducing features for seamless Ethernet integration and improved error handling, all while maintaining backward compatibility and real-time determinism. In a balanced view, CAN XL can be seen as evolutionary, not revolutionary – it does not fundamentally change the paradigm of CAN (it is still a shared bus with CSMA/CR arbitration), but it supercharges it enough to stay relevant in an era of high-speed networking.

However, technology alone does not guarantee adoption. The market acceptance of CAN XL is still in a formative stage. German automakers are likely to lead the way in implementing CAN XL in vehicles, with the first deployments anticipated in the next generation of luxury and high-end cars (late 2020s). American automakers are more circumspect, and Tesla’s novel networking approach starkly contrasts with the idea of extending CAN – showing that there are alternate paths to the same end (high-bandwidth, low-latency communication) that do not involve CAN XL at all. Chinese automakers, on a fast modernization track, will adopt whatever best balances cost and performance; they have shown interest in Ethernet but will not ignore CAN XL if it proves advantageous.

In comparison with Automotive Ethernet, CAN XL occupies a middle ground. Ethernet will undoubtedly continue to gain ground as the backbone of vehicle networks because of its sheer capacity and compatibility with off-board services. CAN XL, at best, will be a complementary technology for domains where its particular mix of features wins out – such as certain control loops or as a redundant bus for safety. A direct competition between CAN XL and low-speed Ethernet (like 10BASE-T1S) will play out in coming years to determine what technology goes into the “last mile” connections of the vehicle network (i.e., linking sensors/actuators to zone controllers). Industrial Ethernet comparisons suggest that industries have successfully transitioned to Ethernet for performance reasons, yet even there, CAN and similar fieldbuses did not disappear overnight. Likewise, in cars, CAN (in one form or another) is likely to persist for quite a long time, especially in lower-end vehicles or simpler functions where cost constraints are tight.

The long-term viability of CAN XL will depend on demonstrated value in production vehicles within the next 5 years. If those early deployments show clear benefits – e.g., reduced wiring weight, faster software updates, easier integration of new features – and if they do so cost-neutrally, CAN XL could become a de facto standard for certain automotive domains. If not, it might remain a specialty solution used only in certain brands or vehicles. It is also possible that CAN XL gains more traction in commercial vehicles (trucks, industrial machines) where its higher bandwidth for telemetry and control is useful, thereby securing its place in that segment even if passenger cars move more aggressively to Ethernet.

In conclusion, CAN XL is poised at the intersection of legacy and future in automotive networks. It extends a trusted technology into a new era, and it arrives just in time as cars evolve into sophisticated, connected computing platforms. The automotive industry tends to favor gradual evolution with assured reliability over abrupt changes. In that sense, CAN XL aligns well with industry ethos – it’s an upgrade that does not throw away the past. However, the simultaneous rise of Ethernet-based zonal architectures is a strong force that could limit how pervasive CAN XL becomes. The likely scenario is that CAN XL will be one of multiple network technologies coexisting in vehicles for the foreseeable future, each used where it makes most sense. Its success will be measured not by replacing Ethernet (which it won’t), but by how well it can carve out and retain a role that adds value to automakers’ design toolbox. Given the backing of standards bodies and the initial commitment by at least some automakers, there is a good chance CAN XL will find that role – ensuring that the CAN bus, in evolved form, remains part of the automotive landscape even as the industry charges toward an Ethernet and software-defined future.

Resources

CAN XL Standards & Technical Specifications

1. CiA (CAN in Automation) – CAN XL Technical Overview:
   https://www.can-cia.org/can-knowledge/can/can-xl/
2. ISO 11898-1:2024 & ISO 11898-2:2024 – CAN XL official standards:
   https://www.iso.org/standard/80082.html
   https://www.iso.org/standard/80083.html
3. Bosch CAN XL IP Core Overview:
   https://www.bosch-semiconductors.com/ipmodules/can-xl/
4. AUTOSAR CAN XL Support Announcement:
   https://www.autosar.org/news/can-xl-support/
5. CAN XL Frame Format (PDF from CiA):
   https://www.can-cia.org/fileadmin/resources/documents/tech/CAN-XL_Frame-Format.pdf

Market and Industry Adoption

1. Volkswagen E/E Architecture and CAN XL Roadmap (CAN Conference):
   https://www.can-cia.org/events/can-conference/
2. Vector CAN XL Tool Support:
   https://www.vector.com/int/en/products/products-a-z/hardware/vn7640/
3. STMicroelectronics Stellar P6 with CAN XL:
   https://www.st.com/en/microcontrollers-microprocessors/stellar-p.html
4. Infineon AURIX TC4x Series (CAN XL-ready):
   https://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-microcontroller/aurix-family/
5. NXP Automotive Microcontrollers with CAN XL:
   https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/can-xl-mcus:CANNX

Comparison with Ethernet Technologies

1. IEEE 802.3cg – 10BASE-T1S Standard (Automotive Ethernet):
   https://standards.ieee.org/standard/802_3cg-2019.html
2. Time-Sensitive Networking (TSN) for Automotive – White Paper by NXP:
   https://www.nxp.com/docs/en/white-paper/TSNWHITEPAPER.pdf
3. Ethernet in Automotive – Overview (ETAS):
   https://www.etas.com/en/products/automotive-ethernet.php
4. Industrial Ethernet Overview (EtherCAT):
   https://www.ethercat.org/default.htm
5. Profinet IRT Overview:
   https://us.profinet.com/technology/profinet/real-time-capability/

Tesla’s Approach to Vehicle Networks

1. Tesla Vehicle Ethernet Architecture & TDMA Patent:
   https://patents.google.com/patent/US10965725B2/en
2. Tesla Powerline Communication and 48V Network Design:
   https://electrek.co/2023/01/04/tesla-next-gen-vehicle-architecture-48v/
3. Tesla’s Cybertruck and Future Vehicle Electrical Redesign:
   https://www.tesla.com/cybertruck

General Automotive Network Trends and Analyses

1. EE Times – Automotive Ethernet vs. CAN:
   https://www.eetimes.com/can-ethernet-coexist-in-automotive-networks/
2. ST – Networking Trends in Software-Defined Vehicles:
   https://blog.st.com/software-defined-vehicles-automotive/
3. Molex White Paper – In-Vehicle Network Evolution:
   https://www.molex.com/molex/products/family/in-vehicle-networking
4. Renesas Automotive Network Solutions:
   https://www.renesas.com/us/en/solutions/automotive/vehicle-networking