Evolution of In-Vehicle Communication Protocols in the SDV Era: Differentiation of CAN FD, CAN XL, and Automotive Ethernet, and Integrated Design for Zonal Architectures (Deep Dive #16)

Main Abbreviations in This Article

• CAN (Controller Area Network): An in-vehicle bus protocol developed by Bosch in 1986. Standardized as ISO 11898.

• CAN FD (CAN with Flexible Data-rate): A successor standard to CAN that extends the speed of the data phase and the payload size. ISO 11898-1:2015.

• CAN XL (CAN with eXtra Long payload): A standard currently under development as the successor to CAN FD. It is scheduled to be incorporated into a revised version of ISO 11898-1.

• CAN-in-Automation (CiA): An industry association responsible for the standardization of CAN, CAN FD, and CAN XL.

• Automotive Ethernet: In-vehicle Ethernet implemented with single-pair or differential two-wire (Unshielded Twisted Pair: UTP) cabling for noise immunity and weight reduction.

• 100BASE-T1: 100 Mbps automotive Ethernet defined by IEEE 802.3bw. Formerly known as BroadR-Reach.

• 1000BASE-T1: 1 Gbps automotive Ethernet defined by IEEE 802.3bp.

• 10GBASE-T1: 10 Gbps multi-gigabit automotive Ethernet defined by IEEE 802.3ch.

• OPEN Alliance: An industry consortium aimed at promoting the adoption of Automotive Ethernet. Established by Broadcom and BMW in 2011.

• AVB (Audio Video Bridging): A set of real-time AV transmission technologies over Ethernet defined by IEEE 802.1BA.

• TSN (Time-Sensitive Networking): A set of deterministic, low-latency communication standards over Ethernet that extends AVB. IEEE 802.1Q series.

• IEEE 802.1AS: gPTP (generalized Precision Time Protocol). A standard that achieves nanosecond-precision time synchronization over Ethernet.

• IEEE 802.1Qbv: TSN scheduled traffic (time-aware shaper) standard. It provides deterministic latency by establishing periodic communication slots.

• MACsec (Media Access Control Security): An Ethernet frame-level encryption and authentication standard defined by IEEE 802.1AE.

• SOME/IP (Scalable service-Oriented MiddlEware over IP): A protocol for service-oriented communication over Automotive Ethernet. Part of the AUTOSAR standard.

• DoIP (Diagnostic over IP): A protocol for performing vehicle diagnostics (OBD/UDS) over Ethernet/IP. ISO 13400.

• ECU (Electronic Control Unit): Electronic control unit.

• LLCE (Low Latency Communication Engine): A dedicated communication processing core integrated into the NXP S32G processor that achieves ultra-low latency for CAN/LIN/Ethernet interrupts.

• FlexRay: A 10 Mbps deterministic in-vehicle bus led by BMW, Daimler, and Motorola. It was adopted for mass production around 2007, but is no longer used in new designs.

• LIN (Local Interconnect Network): A low-speed, low-cost in-vehicle bus with a maximum speed of 20 kbps. A single-wire bus with a master-slave configuration. Used for simple actuator control such as doors and seats.

• CXPI (Clock Extension Peripheral Interface): A candidate protocol for a LIN successor developed under the leadership of Toyota and Renesas. ISO 20890. Achieves higher noise immunity and lower power consumption than LIN through a clock extension method.

• UN-R155: Vehicle cybersecurity regulation established by the United Nations Economic Commission for Europe (UNECE WP.29). Applicable to new vehicle type approvals from July 2022 onwards.

• CSMA/CD: Carrier Sense Multiple Access with Collision Detection. The conventional collision detection-based access control method for Ethernet.

• OBD (On-Board Diagnostics): In-vehicle diagnostic interface.

Introduction: A Communication Revolution Starting from "Wire Weight"

In the previous installment (Deep Dive #15, Part 2), we discussed the in-vehicle integration of AI inference from the perspectives of deployment pipelines, SOTIF, and sensor fusion. This time, we focus on the "infrastructure" that supports the entire SDV architecture, including that AI inference: in-vehicle communication protocols.

The essence of an SDV is being "software-defined," but this requires being "communication-defined" as a prerequisite. No matter how excellent a software architecture may be, it cannot function unless data flows reliably, with low latency, and securely between ECUs.

Modern mass-produced vehicles are equipped with communication networks that mix CAN, CAN FD, LIN, and Ethernet, and it is not uncommon for vehicle models to have wiring harnesses weighing 30 to 50 kg. It is symbolic that one of the reasons BMW began considering the adoption of Automotive Ethernet in 2008 was to "reduce harness weight." In the context of EV transition, reducing harness weight has implications beyond cost savings, as it directly impacts energy efficiency (power consumption).

In this article, we will organize the history of technological evolution starting from classical CAN to CAN FD, CAN XL, and Automotive Ethernet, and discuss the roles each protocol should play and the challenges in integrated design for zonal architectures.

1. History and Limitations of Classical CAN

Background of its creation

CAN was announced by Bosch in 1986 and standardized as ISO 11898 in 1993. At that time, in-vehicle control was dominated by dedicated wiring for analog signals, and as electronic systems advanced, the number of harnesses increased explosively. CAN dramatically solved this wiring problem with a simple design where "multiple ECUs share the same bus and exchange data via broadcast."

Let's organize the key points of the technical specifications. Classic CAN (ISO 11898-1) is a two-wire bus using differential signaling (CAN-H and CAN-L) with a maximum data rate of 1 Mbps. The maximum payload is 8 bytes. Access control is CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance), similar to CSMA/CD, and through an arbitration method where "the smaller the message ID (identifier) value, the higher the priority," messages with higher priority can always occupy the bus even if multiple ECUs transmit simultaneously. This mechanism excels at guaranteeing real-time performance, which encouraged its adoption in safety-critical systems such as engine control, ABS, and airbags.

The Popularity and Strengths of CAN

There are several reasons why CAN has remained the protagonist of in-vehicle buses for over 30 years.

First, the implementation cost is low. The silicon cost of a CAN transceiver is on the order of tens to hundreds of yen, and the wiring only requires two UTP (Unshielded Twisted Pair) wires. Second, it has high fault tolerance. There are implementations that allow communication to continue in single-wire mode even if one wire is broken, which meets the reliability requirements for automotive applications. Third, due to over 30 years of mass production experience, the ECU CAN software stack (such as AUTOSAR's Com and PDUR stacks) is mature, and the ecosystem of development and diagnostic tools is robust.

The Limits of Classic CAN

As ADAS functions began in earnest in the late 2000s and the demand for exchanging data from cameras, radar, and LiDAR between multiple ECUs increased, the 1 Mbps bandwidth began to be decisively insufficient.

Another limitation is the payload size. A payload of 8 bytes is sufficient for exchanging simple numerical values (speed, steering angle, brake pressure), but to send large data blocks (software updates, codec parameters, raw sensor data), it is necessary to split them into small pieces and send them sequentially, which further reduces throughput and real-time performance.

The first answer to the lack of bandwidth was CAN FD.

2. Technical Details of CAN FD (Flexible Data-rate)

Birth and Standardization

CAN FD was proposed by Bosch in 2011 and officially standardized as ISO 11898-1:2015. As the "FD (Flexible Data-rate)" in its name suggests, it is a protocol that "flexibly" expands the communication speed and payload size of the data phase.

Separation of Arbitration Phase and Data Phase

The most important innovation of CAN FD is the phase separation within the frame. Classic CAN operates at the same bit rate throughout the entire frame. CAN FD divides the frame into two phases.

Arbitration Phase: The section that performs arbitration (priority determination) based on the frame ID. To maintain compatibility with classic CAN, it operates at a maximum of 1 Mbps (often 500 kbps in implementation). This is why the physical layer termination resistance and network length constraints are the same as those of classic CAN.

Data Phase: The transfer section for the payload (actual data). In CAN FD, the bit rate can be increased up to 8 Mbps here. This is the essence of FD (Flexible Data-rate).

In implementation, the speed of the data phase is often selected from 2 Mbps, 4 Mbps, 5 Mbps, or 8 Mbps. The maximum of 8 Mbps is a theoretical value, and it is conditional on the network length (cable length) being short (within a few meters), the number of nodes being small, and the use of high-quality differential pair cables. In mass-produced vehicles, it is realistic to operate stably at 2 to 5 Mbps.

Payload Expansion: From 8 Bytes to 64 Bytes

CAN FD has expanded the payload to a maximum of 64 bytes. This is eight times larger than the 8 bytes of classic CAN. The frequency of fine-grained splitting (multi-frame segmentation) is reduced, and the number of frames required to send the same amount of data is drastically reduced. Bus utilization is improved, and real-time performance is also enhanced.

The DLC (Data Length Code) field has also been expanded in CAN FD, allowing the selection of nine types of payload sizes: 8, 12, 16, 20, 24, 32, 48, and 64 bytes.

Enhanced CRC

In CAN FD, the Cyclic Redundancy Check (CRC) has also been enhanced. While classic CAN used a 15-bit CRC, CAN FD uses a 17-bit CRC (for payloads of 16 bytes or less) or a 21-bit CRC (for 17 to 64 bytes). This is because as the bit rate of the data phase increases, the number of bits per unit time increases, necessitating higher accuracy in error detection.

Backward Compatibility with Classic CAN

CAN FD is designed so that classic CAN nodes can ignore CAN FD frames without treating them as 'errors' by adding an FDF (FD Format) bit to the frame format (however, caution is required for coexistence if classic CAN nodes remain on the bus, and it must be confirmed that all nodes support CAN FD).

This backward compatibility design is crucial. Once designed, automotive networks continue to be used over product cycles of 10 to 15 years or more. A migration path has been designed that allows for the gradual addition of CAN FD-capable ECUs while leveraging existing CAN infrastructure.

Mass Production Adoption Status

CAN FD adoption in mass-produced vehicles began around 2014 with the BMW, GM, and VW groups, and since the start of the 2020s, its adoption in new vehicle models has rapidly become standardized. In current platforms for luxury vehicles and EVs, CAN FD has become established as the primary bus for powertrain and chassis control systems.

3. CAN XL: A Standard for Crossing the Next Barrier

Why CAN XL is Necessary

Challenges that cannot be solved even by CAN FD have become apparent since the late 2010s. There are three main factors.

The first is the demand for even higher bandwidth. As the volume of data for ADAS sensor data, V2X (Vehicle-to-Everything) communication payloads, and OTA software updates increases, there are more use cases where even the 8 Mbps and 64-byte payload of CAN FD are insufficient.

The second is the cost of coexistence with Ethernet. In networks where CAN FD and Automotive Ethernet coexist, ECU designs must incorporate both CAN transceivers and Ethernet transceivers, resulting in burdens on cost and board space. If there were a protocol positioned between CAN FD and Ethernet, this problem could be mitigated.

The third is compatibility with zonal architectures. In the zonal architectures described later, zone ECUs play the role of aggregating numerous sensors and actuators. There is a demand for a protocol with bandwidth and versatility greater than CAN FD but less than Ethernet for communication between these zone ECUs and each subsystem.

Overview of the CAN XL Standard

CAN XL, which is being developed by CAN-in-Automation (CiA), was released as the CiA 610 standard in 2023, but its integration into ISO 11898-1 is currently underway. Maturity as a full-scale mass production standard is expected in 2025–2026, and as of the time of this writing, while the main specifications of the standard are fixed, cases of mass production adoption are still limited.

The main technical parameters are summarized below.

Data Rate: Up to 20 Mbps in the data phase (target value). The arbitration phase operates at 1 Mbps or less, similar to CAN FD, and maintains backward compatibility.

Payload Size: Up to 2,048 bytes (2 KB). This is a 32-fold expansion over the 64 bytes of CAN FD. With this capacity, data equivalent to Ethernet jumbo frames can be transferred in a single CAN XL frame.

SIC (Signal Improvement Capability) Physical Layer: CAN XL requires a new physical layer transceiver that is different from the transceiver for CAN FD. SIC has a mechanism to actively cancel ringing (signal reflection noise), which allows for maintaining high bit rates even over longer network lengths than conventional CAN.

Frame Format: Although the CAN XL frame is structurally different from the CAN FD frame, it is designed so that CAN FD buses and CAN XL buses can coexist on the same network by sharing the specifications of the arbitration phase (subject to strict conditions).

Ethernet Frame Tunneling: CAN XL plans to support an 'Ethernet payload mode' that leverages its maximum 2 KB payload to encapsulate and transfer Ethernet frames as they are. This means that when CAN XL and Ethernet form a continuous network, the stack for Ethernet can be reused in the CAN XL section, making it easier to maintain consistency in the software architecture.

NXP's Support for CAN XL

NXP has been advancing its support for CAN XL from an early stage and has published a roadmap to extend the LLCE (Low Latency Communication Engine) cores of its S32G and S32E series to support CAN XL. The company is also deploying CAN XL-compatible transceiver products such as the TJA1153, which includes the implementation of the SIC physical layer. From the perspective of someone involved in industry discussions, I anticipate that full-scale mass production adoption requests from OEMs will begin around 2026–2027.

4. Automotive Ethernet: Technology Becoming the Backbone of In-Vehicle Networks

Why 'Automotive' Instead of Consumer Ethernet?

Consumer Ethernet (compliant with IEEE 802.3) used in data centers and offices cannot be directly applied to the in-vehicle environment. There are three main reasons for this.

First, consumer Ethernet uses a 4-pair cable (CAT5e/CAT6), which is too heavy for automotive applications. Second, the EMC (electromagnetic compatibility) requirements are different. The vehicle interior is a harsh electromagnetic environment where engine ignition noise, motor drive noise, and power supply noise coexist, requiring ingenuity to establish communication without using shielded cables. Third, standard Ethernet (such as 100BASE-TX) is designed with PHY (physical layer IC) that uses two pairs of cables, which contradicts the automotive requirement to reduce the number of wires.

To solve these challenges, Automotive Ethernet is based on a design philosophy of 'achieving high-speed data transfer while maintaining EMC resistance using a single-wire or differential two-wire (1-pair) UTP cable.'

100BASE-T1 (formerly BroadR-Reach)

100BASE-T1 was developed by Broadcom under the name 'BroadR-Reach,' with the OPEN Alliance formulating the cable and connector specifications, and it was finally standardized as IEEE 802.3bw in 2015.

The technical core is the combination of 'Echo Cancellation' and '3-level PAM (Pulse Amplitude Modulation) encoding.' To achieve bidirectional communication over a single wire (1 pair), the echo of the signal transmitted by the device itself is precisely canceled by a DSP, extracting only the signal from the other party. This technology enables 100 Mbps full-duplex communication over two unshielded wires.

BMW and Daimler began adopting it in mass-produced vehicles around 2012–2014, and it has now become established as the primary bus between cameras and ADAS ECUs.

1000BASE-T1

1000BASE-T1 is a 1 Gbps automotive Ethernet defined by IEEE 802.3bp (standardized in 2016). By combining PAM-3 encoding with a 750 MHz symbol rate, it achieves 1 Gbps over a single pair of wires. The cable length is limited to a maximum of 15m (standard) or 40m (short reach), which is sufficient for in-vehicle wiring.

1000BASE-T1 is used for high-capacity data backbone applications, such as between ADAS ECUs and domain controllers, or between zone ECUs and zone controllers. While it lacks the bandwidth for transferring uncompressed camera video streams (1080p, 30fps: approx. 1.5 Gbps), it is sufficient for camera video compressed with H.264/H.265.

10GBASE-T1 (Multi-Gig: 2.5G/5G/10G)

IEEE 802.3ch (standardized in 2020) is a multi-gigabit automotive Ethernet standard that achieves three data rates—2.5 Gbps, 5 Gbps, and 10 Gbps—over a single pair of wires. It is known as 'MultiGig' or '10GBASE-T1.'

10 Gbps uses higher-order PAM-4 (Pulse Amplitude Modulation 4-level) for encoding, with a symbol rate of approximately 5 Gbaud. The physical layer implementation complexity, PHY cost, and power consumption are higher than those of 100BASE-T1 and 1000BASE-T1. At present, its primary application is for links that truly require high capacity, such as the backbone between the central computing unit (Vehicle Computer) and domain/zone controllers, or for raw LiDAR point cloud data streams.

NXP offers the TJA1120 (1000BASE-T1 PHY) and TJA1110 (100BASE-T1 PHY) as its main products. Companies like Semtech and Marvell are leading in 10GBASE-T1 PHYs, and NXP is also expanding its product lineup.

TSN (Time-Sensitive Networking): Providing Determinism to Ethernet

The biggest weakness of standard Ethernet is the 'lack of deterministic latency.' While CAN can guarantee the worst-case latency for high-priority messages through the arbitration function of CSMA/CA, the CSMA/CD (collision detection)-based access control of standard Ethernet makes transmission timing uncertain when the bus becomes congested.

TSN (Time-Sensitive Networking) is a set of extension standards for the IEEE 802.1Q series, representing a technology framework that realizes deterministic communication over Ethernet. Here, I will organize the most important aspects of automotive TSN.

IEEE 802.1AS (gPTP): Realizes nanosecond-precision time synchronization across all nodes. It serves as a prerequisite for sensor fusion, time-based services in SOME/IP, and TSN scheduling. gPTP is an optimization of the conventional PTP (IEEE 1588) for automotive and bridged networks.

IEEE 802.1Qbv (Enhancements for Scheduled Traffic): Uses a time-aware shaper (TAS) to control transmission queues in time-slot units. By securing time slots exclusively for high-priority real-time traffic (ADAS control), data can be transmitted deterministically without being interrupted by background best-effort traffic (such as OTA update data).

IEEE 802.1Qbu/IEEE 802.3br (Frame Preemption): A function that allows high-priority frames to "preempt" and interrupt low-priority frames currently being transmitted. Even while a large data frame is being sent, high-priority control frames can be sent first via preemption.

By implementing these TSN functions in Automotive Ethernet switches, the "deterministic real-time communication" functionality that CAN has provided for many years can be replicated over Ethernet. However, the implementation complexity is high, and designing and verifying TSN settings (bandwidth reservation, scheduling parameters) is extremely difficult without the support of tools (such as network design tools like Siemens Simcenter).

5. Differentiation of Each Protocol: What to Connect with What

Criteria for Protocol Selection

Protocol selection is determined by a combination of bandwidth, determinism, cost, payload size, and continuity with existing ecosystems. I will organize the current differentiation in mass-produced vehicles.

LIN (Local Interconnect Network)
: Up to 20 kbps. A single-wire bus with a master-slave configuration, with a protocol design that is as simple as possible. Because it is a self-synchronizing system that embeds the clock signal into the data, slave nodes do not require a clock source, reducing ECU costs to the order of several tens of yen. It will continue to remain in peripheral nodes where data rate and real-time requirements are low and cost sensitivity is high, such as door mirrors, seat position adjustment, window switches, and lighting dimming.

CXPI (Clock Extension Peripheral Interface)
: A candidate protocol for a LIN successor, led by Toyota and Renesas and standardized as ISO 20890. The data rate is a maximum of 20 kbps, equivalent to LIN, but it improves noise immunity and power consumption by adopting a "clock extension method" where the master provides an explicit clock signal. It has been used in Toyota and Lexus vehicles since around 2015–2016 for lighting control, switch inputs, and air conditioning panels. However, adoption remains limited to Japanese OEMs centered on Toyota; Western OEMs like VW, BMW, and GM tend not to choose CXPI as a migration path from LIN, opting instead for CAN FD or continuing with LIN. This is a typical case of "technical improvement and widespread adoption being separate issues," which I will address again in the next installment (Deep Dive #17) from the perspective of IP licensing and ecosystem formation.

Classic CAN (1 Mbps)
: Due to the significant inertia of existing mass-production lines, diagnostic tools, and CAN ID-based log systems, it remains in diagnostic frames (OBD-II) for parts replacement and maintenance, as well as in legacy control ECUs. While adoption in new designs is decreasing, I personally believe it will take more than 10 years for it to disappear completely. I will detail this in the "Reasons Why Classic CAN Will Continue to Remain" section below.

CAN FD (Max 8 Mbps, 64-byte payload)
: The protagonist for medium-to-high-speed control data exchange, such as powertrain, chassis, and body control. It has accumulated the most mass-production track record as a "successor to CAN," and the development tool ecosystem, including CAN FD-compatible AUTOSAR software stacks, diagnostic tools, and CAN analyzers, is mature. It will remain the center of control buses in new vehicle designs for the next 5 to 10 years.

CAN XL (Max 20 Mbps, 2 KB payload)
: Expected for use cases where CAN FD lacks bandwidth but the cost and implementation complexity of Ethernet are to be avoided, or as an aggregation bus between zone ECUs and subsystems in zonal architectures. Mass-production adoption is expected to begin in earnest from around 2026–2027. However, this assumes the maturity of the standard and a decrease in the mass-production price of transceivers.

100BASE-T1 (100 Mbps)
: Used for links between cameras/ADAS sensors and ADAS ECUs, as well as for cockpit video systems, for medium-capacity video and sensor data. It has already been adopted in many mass-produced vehicles and will continue to be used in the future.

1000BASE-T1 (1 Gbps)
: The backbone between domain controllers and between zone ECUs and the Central Zone Controller (CZC). It functions as the primary bus for SOME/IP-based service communication and DoIP.

10GBASE-T1 (2.5G/5G/10 Gbps)
: Used for the backbone between the Vehicle Computer (central computing ECU) and domain/zone controllers, for LiDAR raw point cloud data transfer, and for large-capacity data distribution for OTA updates. While adoption is still centered on premium vehicles from the perspective of cost and power consumption, it is expected to expand to mass-market vehicles between 2027 and 2030.

6. Integrated Design for Zonal Architectures

From Domain Architecture to Zonal Architecture

Conventional automotive electronic architectures were "domain-distributed." Dedicated ECU groups were designed for each functional area (domain), such as powertrain ECUs, chassis ECUs, infotainment ECUs, and ADAS domain controllers, with the CAN bus completed within each domain.

The problem with this design is that it is incompatible with the "flexible updating and addition of software" required by SDVs. Every time a function is added, an ECU must be added, causing harnesses to proliferate and the dependencies between ECUs to become spaghetti-like.

A zonal architecture is a design that divides a vehicle into physical zones such as "front-left, front-right, rear-left, rear-right, and roof/center," with a "zone ECU" (or zone controller) placed in each zone. The zone ECU aggregates sensors and actuators within its own zone and provides a communication interface with the central Vehicle Computer (or high-performance domain controller).

Two-layer design of intra-zone bus and backbone bus

The communication design of a zonal architecture naturally becomes a two-layer structure.

Intra-zone bus (between zone ECU and end ECUs): CAN FD (or CAN XL) is the primary player. End-point sensors and actuators have significant cost and power consumption constraints, making Ethernet excessive. The mature ecosystem and low-cost implementation of CAN FD are well-suited here. The zone ECU acts as a "gateway" for this CAN/CAN FD bus, converting CAN frames into Ethernet and sending them to the backbone.

Backbone (between zone ECUs and Vehicle Computers): Automotive Ethernet is the primary player. It connects zone ECUs and Vehicle Computers using 1000BASE-T1 or 10GBASE-T1. Software updates (OTA), large volumes of data for sensor fusion, SOME/IP service communication, and DoIP diagnostic packets flow through here.

Implementation of the zone ECU gateway function

The gateway function of a zone ECU is highly difficult to implement. When converting CAN FD frames to Ethernet, it is necessary to perform protocol conversion, payload reconstruction, and timestamping.

There are two approaches: encapsulating CAN FD data frames into Ethernet UDP payloads (such as XCP on IP) and re-packaging them as SOME/IP services (Service-Oriented implementation). The latter offers higher flexibility but comes with higher implementation costs and requires alignment with the AUTOSAR COM stack.

The continuity of timestamps is also a challenge. CAN FD frames do not carry high-precision timestamps, whereas Ethernet has time synchronization via gPTP (IEEE 802.1AS). A design is required where the zone ECU attaches a gPTP timestamp at the moment it receives a CAN FD frame before sending it to Ethernet; this determines the data alignment accuracy for sensor fusion.

NXP S32G/S32E and LLCE

The NXP S32G processor is designed with zonal architecture zone ECUs in mind. In particular, the "LLCE (Low Latency Communication Engine)" is a unique communication processing engine that handles interrupt handling for CAN/CAN FD/LIN/Ethernet protocols using dedicated hardware with ultra-low latency (sub-microsecond), without relying on the core CPU.

The S32G integrates up to 32 CAN FD controllers and multiple 1000BASE-T1 ports, and is designed for applications that "handle both CAN FD bus gateway functions and Ethernet switch functions on a single chip." BMW and some Japanese OEMs have a track record of adopting the S32G as a zone controller or gateway.

Regarding FlexRay, while it was adopted by BMW, Daimler, and others for a time, new adoptions have effectively ceased since the 2020s. Although the S32G initially integrated a FlexRay controller, the direction for successor products is not to continue investment in FlexRay. While the lifespan of FlexRay-compatible ECUs will be extended, they are being replaced by combinations of CAN FD and Ethernet in new platforms.

7. Automotive Ethernet, MACsec, and UN-R155

Why is Ethernet prone to becoming a target for cybersecurity?

In terms of network design, CAN has limited direct access from the outside, making it difficult to attack without physical contact with the bus (though access to CAN via the OBD-II port is an exception). Automotive Ethernet is placed on the backbone and concentrates OTA updates, diagnostics (DoIP), and SOME/IP communication, making it the "layer where an attacker can access the most ECUs."

Automotive Ethernet, which uses the IP layer (IPv4/IPv6), possesses a TCP/UDP stack, meaning known IP network attacks (Man-in-the-Middle, spoofing, denial of service, etc.) can be applied directly.

MACsec (IEEE 802.1AE)

MACsec is a standard that performs encryption, integrity verification, and replay attack prevention at the Ethernet frame (L2 layer) level. I will explain its specific role in automotive applications.

When MACsec is applied to the Ethernet link between a zone ECU and a Vehicle Computer, all Ethernet frames flowing on the link between the two points are encrypted with AES-GCM (256-bit), and an ICV (Integrity Check Value) is added to the frame's tag (SecTAG). Even if an attacker physically contacts the bus and captures the frames, they cannot decrypt the contents without the key. Furthermore, "replay attacks," where captured frames are retransmitted later, are detected and excluded using sequence numbers.

Because MACsec is designed to provide protection on a point-to-point link basis, decryption and re-encryption within the switch are required when passing through an Ethernet switch (hop-by-hop method). This leads to increased switch hardware costs (requiring MACsec-capable ports) and complicates key management.

UN-R155 and Ethernet

UN-R155 (UNECE WP.29) is a vehicle cybersecurity regulation that applies to new vehicle type approvals from July 2022 onwards. Looking at its specific requirements in relation to Ethernet, it mandates 'implementing appropriate authentication and encryption at the interface for external vehicle communication (V2X, OTA, diagnostics)' and 'risk assessment of cyber threats and continuous monitoring and response (CSMS: Cybersecurity Management System).'

In designs where Automotive Ethernet serves as the backbone, the main pillars of security implementation are link protection via MACsec, application-layer protection via TLS, and authentication control for DoIP (diagnostic) communication. In Japan, the Ministry of Land, Infrastructure, Transport and Tourism has applied requirements equivalent to UN-R155 to new vehicle type approvals since October 2024, making it a mandatory requirement for ongoing new vehicle platform development.

8. Author's Perspective

Why Classic CAN Continues to Persist

I sometimes get asked by engineers outside the industry, 'Why does classic CAN still exist when CAN FD is available?' The answer is 'the inertia of the vehicle lifecycle and supply chain.'

A single vehicle has a lifecycle of 15 to 20 years from design to scrapping. Platforms designed in the early 2010s used classic CAN, and those platforms will continue to be produced until the late 2020s. Dealer diagnostic tools (scan tools), parts distributor CAN loggers, and factory production line inspection equipment also rely on classic CAN (OBD-II). The cost of updating this entire ecosystem at once is enormous, far exceeding the cost of migrating a single protocol.

Furthermore, for low-speed actuators like seat position motors and window switches, even 1 Mbps is excessive bandwidth. The ROI (return on investment) for updating these ECUs from classic CAN (or LIN) is difficult to justify from a mass production cost perspective.

In conclusion, while classic CAN will gradually disappear in new platforms centered on high-end EVs, I personally believe it will continue to remain in budget cars, commercial vehicles, and the aftermarket until the 2030s.

Outlook for CAN XL Adoption

I would like to be candid about the gap between expectations for CAN XL and the reality.

The technical specifications of CAN XL are attractive. The 20 Mbps, 2 KB payload spec makes sense as a design to bridge the gap between CAN FD and Automotive Ethernet. The Ethernet payload mode (tunneling Ethernet frames over CAN XL) allows Ethernet-based software stacks to be applied to buses within a zone, which has the effect of increasing architectural consistency.

However, there are several barriers to its widespread adoption.

First is the mass production price of transceivers. CAN XL SIC physical layer-compatible transceivers are still in the early stages of mass production and are more expensive than CAN FD transceivers. There is a 'chicken and egg' problem where prices will only drop once mass adoption begins.

Second is the sentiment that 'CAN FD is good enough.' Many use cases between zone ECUs and subsystems are already satisfied by CAN FD (8 Mbps, 64 bytes) in terms of design. OEMs are currently in the stage of scrutinizing how many use cases can actually justify the cost of migrating to CAN XL (transceiver updates, software stack updates, and verification costs).

In my view, the most realistic scenario is that full-scale mass production adoption of CAN XL will occur from 2027 onwards, as it is adopted as the standard bus for zonal architectures during the next-generation renewal of EV/SDV platforms. Until then, the dual-track approach of CAN FD + Automotive Ethernet will remain the mainstream.

The Design Challenges Posed by Automotive Ethernet

Automotive Ethernet significantly outperforms CAN in terms of bandwidth and affinity for service-oriented architectures. However, the difficulty of implementation is also significantly higher than that of CAN.

TSN scheduling settings cannot be configured correctly without a precise understanding of the entire network's traffic flow, bandwidth reservation, and time slot design in advance. Compared to CAN arbitration (where priority is determined automatically), the design effort is significantly increased. It is not realistic to manually set TSN parameters without network design tools, and for OEMs where the integration between AUTOSAR wiring descriptions (ARXML) and TSN configuration tools is not established as a design flow, significant man-hours will be incurred during the integration phase after adopting Automotive Ethernet.

MACsec key management is also highly difficult to implement. Managing different keys for each zone ECU, rotating keys via OTA updates, and revoking keys if a specific ECU is stolen or compromised—this entire sequence of 'PKI (Public Key Infrastructure) management' requires new capabilities for existing CAN-centric organizations.

In implementation, there is also a strong concern that 'determinism cannot be guaranteed when migrating to Ethernet.' While TSN is theoretically deterministic if configured correctly, the man-hours required for testing and verification are significantly higher than for CAN. I feel that this 'increase in testing difficulty' is affecting the speed of migration to zonal architectures.

Communication Strategies of Semiconductor Vendors

I would also like to touch upon the competitive landscape of Automotive Ethernet. In the PHY layer, Broadcom, Marvell, TI, NXP, and Microchip are the major vendors. In the Ethernet switch layer, NXP (SJA1110/SJA1124) and Broadcom (BCM8988x series) are competing in the TSN-capable automotive switch market.

NXP's SJA1110 is an 8-port TSN-capable automotive Ethernet switch, an SoC that integrates gPTP, IEEE 802.1Qbv, and MACsec. The configuration combining the S32G processor and the SJA1110 has become a typical reference design for 'zonal gateways' and has been adopted in projects for multiple OEMs.

Regarding CAN XL, each company's roadmap is in the process of solidifying, with NXP, Infineon, and Texas Instruments leading the way in providing samples of CAN XL-capable transceivers. To reach a scale where mass production pricing is viable, formal adoption by major OEMs for at least two to three platforms is required.

Summary

• LIN and CXPI for end-node segmentation: LIN (max 20kbps, single-wire, master-slave) remains the lowest-cost solution for low-speed actuators such as doors, seats, and lighting. CXPI is a candidate for a LIN successor centered on Toyota and Japanese OEMs, but Western OEMs are choosing either CAN FD or continuing with LIN, so it has not reached global standard status.

• The technical legacy of CAN is immense: Classic CAN (1Mbps, 8-byte) will continue to remain in budget and commercial vehicles until the 2030s due to 30 years of mass production track record, ecosystems, and the inertia of diagnostic tools. A complete transition will take longer than a single design cycle.

• CAN FD is already the de facto standard: The maximum 8Mbps, 64-byte payload is sufficient as a control bus, and due to its mass production track record and the maturity of its tool ecosystem, CAN FD will be the center of control buses for the next 5 to 10 years.

• CAN XL is promising but adoption will be after 2027: 20Mbps, 2KB payload, and Ethernet tunneling are technically attractive, but mass-produced transceiver prices and OEM adoption decisions are lagging. Full-scale adoption awaits the refresh timing of next-generation SDV platforms.

• Automotive Ethernet is the backbone of SDVs: The three layers of 100BASE-T1, 1000BASE-T1, and 10GBASE-T1 handle sensors, domains, and the backbone, while SOME/IP, DoIP, and TSN realize service-oriented architectures over Ethernet.

• TSN is essential but difficult to configure: A combination of IEEE 802.1AS (gPTP), Qbv (time-aware shaper), and Frame Preemption can achieve CAN-like determinism over Ethernet, but design and verification costs are significantly higher than for CAN.

• A two-layer design is the realistic solution for zonal architectures: A combination of CAN FD (low cost, mature) within zones and Automotive Ethernet (high bandwidth, SOME/IP support) for the backbone is becoming established as the standard for mass production design.

• MACsec and UN-R155 are unavoidable: In designs where Automotive Ethernet serves as the backbone, link encryption via MACsec and PKI key management become the core of UN-R155 compliance. It is necessary to establish capabilities that existing organizations do not currently possess.

• NXP S32G + SJA1110 is the typical configuration for a zonal gateway: A 'CAN and Ethernet gateway' combining LLCE (Low Latency Communication Engine), 32 CAN FD controllers, and a TSN-capable Ethernet switch is being adopted as a practical design.

Next time (Deep Dive #17), we will take a deep dive into CAN itself. We plan to cover why Bosch succeeded with IP licensing while standardizing CAN as an ISO standard, the history of how it expanded into the industrial equipment market via CANopen before eventually being replaced by Ethernet-based protocols, and the reasons why it still persists in automotive applications today.