What cars use the CAN-FD protocol?

Taking a certain vehicle model as an example, the project has mass-produced the CAN-FD network. Based on the electronic and electrical functional architecture, the project has built a network architecture that integrates multiple vehicle network protocols. It is a new generation of FAW vehicle network architecture that integrates multiple domains such as information domain, interconnection domain, autonomous driving domain, and chassis power domain. This architecture has the ability to support the expansion of L2+ autonomous driving and vehicle-level OTA technology, and has the technical advantages of high functional safety and high information security.

2.1 Functional Definition

The CAN-FD part of this model mainly realizes ADAS automatic driving and power vehicle control functions. ADAS functions are divided into intelligent driving assistance functions and automatic driving functions, including lever lane change, automatic lane change, adaptive cruise, high-speed driving, congestion following, automatic parking and other basic or advanced functions, which involve the control interaction between the ADAS domain controller and the perception sensors, chassis, power and other execution controllers.

2.2 Solution Design

For the functional requirements described in Section 2.1, CAN bus was often used to transmit related messages in previous project designs. However, with the upgrade of ADAS functional level, the realization of these ADAS functions has higher performance, low latency, high bandwidth and ASIL B+ functional safety requirements for network communication, which can no longer be met by traditional CAN communication. FAW Hongqi used CAN-FD for the first time on this model to build the network architecture of ADAS and other domains, realizing high real-time and stable communication transmission between ADAS domain controller and perception controller and execution controller.

In the network architecture design of this vehicle model, ADAS function-related messages are divided into two categories: control and perception. The ASIL level of each message and signal is determined according to the functional safety ASIL level of each unit function, and then the E2E verification strategy for each signal is formulated. Since the comfort entertainment uses the traditional CAN network framework, the CAN to CAN-FD (CAN-FD to CAN) function design is done in the central gateway, and the functional safety redundancy design of the gateway is done. The content of the gateway functional safety design is not repeated here.

2.3 Design and Implementation

2.3.1 Vehicle CAN-FD Node Topology Design

In this vehicle project, the CAN-FD nodes mainly include the gateway controller, ADAS domain controller, ADAS perception controller, power domain controller, and chassis domain controller (Figure 5).

Figure 5 CAN-FD node topology of vehicle model

The gateway mainly implements the PDUCAN-FD routing function and CAN-CANFD routing function; the ADAS domain controller implements the ADAS planning and decision-making function; the ADAS
perception controller implements the environmental perception and positioning function; the power domain controller implements the power distribution and control function; and the chassis domain controller implements the braking and steering functions.

2.3.2 Routing Strategy Design

For the route from CAN to CAN-FD, considering the transmission efficiency, the gateway packages multiple received CAN messages into one CAN-FD message for sending. To ensure the scalability of the message matrix and the convenience of packaging and parsing, every 8 bytes in CAN-FD corresponds to the traditional CAN message, and at least 32 bits are reserved in every continuous 8 bytes for future function expansion.

The gateway's message routing forms are divided into three types: CAN-CAN routing, CANCANFD routing and CANFD-CAN routing. CAN-CAN routing follows the traditional CAN routing principles and will not be elaborated here. The following article will mainly explain the latter two routing forms in detail.

CAN-CANFD routing: The gateway can forward multiple messages after grouping them, or forward a single message without grouping them; single message forwarding only changes the ID and message type (frame structure and transmission rate) of the source segment message, but does not change the position of the signal in the data field and the data field length (DLC). This form of forwarding is called message routing. Direct routing can be completed by the underlying software itself, without the participation of the upper-level software, and the routing time delay is low, which can generally be controlled within 2ms.

Figure 7 Example of message routing process

CANFD-CAN routing: Message forwarding from CAN-FD to CAN bus requires splitting the CAN-FD message frame with a DLC of up to 64 bytes into multiple CAN message frames with a DLC of up to 8 bytes. It requires splitting and reorganizing the signal in the data field, changing the message ID, message type, DLC length and signal position. This routing method is called signal routing. The signal routing process requires the participation of upper-layer software, and the routing delay is higher than that of message routing. To achieve functional safety, the gateway also needs to do more safety redundancy design work.

2.4 CAN-FD communication performance verification

For the design of this project, a test bench was built to carry out consistency testing and hardware in the loop (HIL) verification of CAN-FD related nodes, and good results were obtained in key performance indicators of the network such as bus load rate, throughput, average delay and peak delay, network utilization and network efficiency.