ADAS deployment method based on Socket CAN communication protocol

Abstract

The invention relates to the technical field of vehicle engineering and automotive electronics, in particular to an ADAS deployment method based on a Socket CAN communication protocol, which comprises the following steps: deploying an ADAS algorithm on an industrial personal computer SOC, and transmitting a CAN signal to a vehicle gauge MCU through a CAN bus by using the Socket CAN communication protocol. A corresponding CAN bus driving program is configured on a vehicle gauge MCU, and functional logic is written to drive a related ECU and a sensor, so that effective scheduling and management of transverse and longitudinal control of a vehicle are realized. In addition, the method is executed based on a Linux operating system, and a user can conveniently and rapidly verify different ADAS algorithms.

Description

Technical Field

[0001] The present invention relates to the field of vehicle engineering and automotive electronic technology, and in particular to an ADAS deployment method based on the SocketCAN communication protocol. Background Art

[0002] With the profound changes in the automotive industry, the electrification transformation has entered its final stage, and the new era of intelligent transformation is accelerating. Major OEMs have accelerated the mass production and delivery of ADAS and even higher-level intelligent driving algorithms to accelerate the intelligent transformation. Autonomous driving algorithms are usually deployed in high-computing power and high-cost domain controller platforms, which integrate SOC and MCU internally. Autonomous driving algorithms are deployed and run on the corresponding SOC system. SOC transmits data between the bus and the MCU. The MCU writes the corresponding bus driver to drive the corresponding ECU. However, the self-driving algorithm deployed on the SOC usually requires the support of the communication component operating system OS. Major OEMs usually communicate by cooperating with suppliers to develop the corresponding OS operating system. The self-driving OS operating system for mass-produced models usually needs to provide process scheduling, memory management, service discovery, complex protocol stacks and middleware (distributed communication, message queues, data synchronization, etc.). The development is difficult and requires the concerted efforts of the entire team, and the resource consumption is large. Summary of the invention

[0003] The purpose of the present invention is to provide an ADAS deployment method based on the SocketCAN communication protocol. By using the SocketCAN communication protocol, the ADAS algorithm transmits the CAN signal to the vehicle-regulatory MCU through the CAN bus, and then configures the corresponding drive to realize the effective scheduling and management of the vehicle's lateral and longitudinal control.

[0004] To achieve the above object, the present invention provides an ADAS deployment method based on the SocketCAN communication protocol, comprising the following steps:

[0005] Step 1: Deploy the ADAS algorithm on the industrial computer SOC;

[0006] Step 2: Use the SocketCAN communication protocol to connect the industrial computer SOC and the vehicle MCU through the CAN bus;

[0007] Step 3: The ADAS algorithm is combined with the CAN communication matrix of the chassis and the camera and transmitted to the vehicle MCU;

[0008] Step 4: The vehicle MCU configures the CAN driver to control the hardware device to complete the vehicle's lateral and longitudinal joint control.

[0009] Optionally, the working steps of the SocketCAN communication protocol are as follows:

[0010] Device initialization and configuration;

[0011] Creation of Socket to communicate with the underlying hardware interface;

[0012] Use the sendto() function to send the data frame to the CAN bus;

[0013] Use the recvfrom() function to receive data from the CAN bus. The received data will be transmitted to the application in the form of CAN frames.

[0014] Perform data filtering and processing.

[0015] Optionally, the data transmitted to the vehicle MCU in step 3 is a CAN message required by the ADAS algorithm, and the CAN message communication matrix exists in the form of a DBC file.

[0016] Optionally, CAN bus communication uses signal lines CAN_H and CAN_L for data transmission, and a 120 ohm terminal resistor needs to be connected between CAN_H and CAN_L.

[0017] Optionally, the vehicle MCU driver configuration process in step 4 includes the following steps:

[0018] Configure the CAN controller and configure CAN nodes for the chassis and camera respectively;

[0019] Configure CAN messages corresponding to the CAN controller;

[0020] Program the signal logic corresponding to the ADAS algorithm in the vehicle MCU.

[0021] Optionally, the baud rate calculation formula of the CAN controller is:

[0022]

[0023] Among them, bit time parameter = synchronization segment + propagation time segment + phase buffer segment 1 + phase buffer segment 2;

[0024] The clock of the CAN bus comes from internal and external clock sources, which are obtained through frequency division and frequency multiplication;

[0025] The frequency division coefficient comes from the frequency division size of the phase-locked loop of the IC circuit inside the CAN bus.

[0026] The present invention provides an ADAS deployment method based on the SocketCAN communication protocol, deploying the ADAS algorithm on the industrial computer SOC, and using the SocketCAN communication protocol to transmit the CAN signal to the vehicle-standard MCU through the CAN bus. On the vehicle-standard MCU, the corresponding CAN bus driver is configured, and the functional logic is written to drive the relevant ECU and sensors, thereby realizing the effective scheduling and management of the lateral and longitudinal control of the vehicle. In addition, the present invention is executed based on the Linux operating system, which is convenient for users to quickly verify different ADAS algorithms. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0028] Figure 1 It is a schematic flow chart of the steps of an ADAS deployment method based on the SocketCAN communication protocol of the present invention.

[0029] Figure 2 This is a diagram of the standard format of a CAN data frame.

[0030] Figure 3 This is a schematic diagram of CAN bit timing.

[0031] Figure 4 It is a schematic diagram of the DBC file structure of the CAN message communication matrix of a specific embodiment of the present invention.

[0032] Figure 5 It is a schematic diagram of the actual vehicle effect of a specific embodiment of the present invention. DETAILED DESCRIPTION

[0033] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present invention, and should not be construed as limiting the present invention.

[0034] The following is a description of the commonly used abbreviations of English terms in the present invention:

[0035] ADAS: Advanced Driver Assistance Systems, advanced driver assistance systems;

[0036] SOC: System on Chip, system chip;

[0037] MCU: Microcontroller Unit, micro control unit;

[0038] ECU: Electronic Control Unit, electronic control unit;

[0039] CAN: Controller Area Network, controller area network (bus).

[0040] See also Figure 1 The present invention provides an ADAS deployment method based on the SocketCAN communication protocol, comprising the following steps:

[0041] S1: Deploy the ADAS algorithm on the industrial computer SOC;

[0042] S2: Use SocketCAN communication protocol to connect the industrial computer SOC and the vehicle MCU through the CAN bus;

[0043] S3: The ADAS algorithm is combined with the chassis and the camera’s CAN communication matrix and transmitted to the vehicle MCU;

[0044] S4: The vehicle MCU configures the CAN driver to control the hardware device to complete the vehicle's lateral and longitudinal joint control.

[0045] The following is a further explanation based on the corresponding terminology and execution process:

[0046] 1. Principle description of CAN bus

[0047] The CAN (Controller Area Network) bus is a serial communication protocol used for data communication between multiple nodes. It is widely used in automotive electronics, industrial automation and other fields. The CAN bus is a serial communication bus based on a multi-master architecture. It allows multiple nodes in the network to initiate communication requests at any time. It is suitable for environments with strong real-time performance and a large number of nodes. Its basic features include: Multi-master architecture: All nodes can send and receive data, allowing multiple controllers to communicate on the same bus. Data priority and arbitration mechanism: The message priority is determined by the message ID (identifier) ​​to ensure that important data is transmitted first. High reliability: CAN has powerful error detection and processing capabilities to ensure data integrity and reliability. The standard frame format of CAN data frames is as follows: Figure 2 As shown: it includes arbitration segment (message ID), control segment (message length DLC), data segment, CRC segment (to ensure data integrity and detect errors during transmission), and ACK segment (to confirm successful reception and ensure the reliability of data transmission).

[0048] The CAN bus uses two signal lines, CAN_H and CAN_L, for data transmission, and the common connection method is differential transmission. Its logic level is defined as follows: Dominant: CAN_H is more than 0.9V higher than CAN_L, and the corresponding logic value is 0; Recessive: The voltage difference between CAN_H and CAN_L is small (about 0.2V or less), and the corresponding logic value is 1. The CAN protocol contains a variety of error detection mechanisms to ensure the reliability of data transmission. These mechanisms include: Bit stuffing error: inserting the opposite bit after 5 consecutive identical bits to prevent the receiver from being unable to synchronize; Frame format error: When the structure or format of the frame does not conform to the protocol definition, an error is triggered;

[0049] Verification error: The receiver verifies the data and CRC fields, and an error is triggered if a mismatch is found; Confirmation error: The receiver does not send an ACK, indicating that the data is not received correctly; Bit monitoring error: When the levels of the transmitter and receiver are not synchronized, an error is triggered. When the errors accumulate to a certain extent, the erroneous node will enter the Bus-Off state and exit from the network to prevent affecting the normal communication of other nodes. The CAN bus has become a highly reliable communication protocol in embedded systems through its multi-master architecture, priority-based arbitration mechanism and efficient error detection methods. The CAN bus uses a "bit synchronization" mechanism to achieve correct sampling of the level. The bit data consists of four segments: synchronization segment (SS), propagation time segment (PTS), phase buffer segment 1 (PBS1), and phase buffer segment 2 (PBS2). The CAN bit timing is as follows Figure 3 As shown, the sampling point refers to the point where the bus level is read and the read level is used as the bit value.

[0050] 2. SocketCAN communication protocol

[0051] SocketCAN is a CAN (Controller Area Network) bus communication protocol stack based on Linux system, which implements the operation of CAN bus by providing standard SocketAPI. It is part of Linux kernel, which aims to simplify the communication interface between CAN bus and high-level application programs, and is widely used in vehicles, industrial control, autonomous driving and other fields. SocketCAN enables developers to communicate with CAN bus through standard network interface in a Unix socket-like way, which is similar to TCP / IP protocol stack, but optimized for the characteristics of vehicle communication.

[0052] 2.1Core components of the SocketCAN protocol

[0053] The design goal of the SocketCAN protocol stack is to achieve seamless integration with the Linux system and simplify development through standardized APIs. Its main components include the following parts: CAN device driver: SocketCAN accesses and manages the CAN controller through different hardware drivers. Common CAN drivers include: can_berkeley: used for basic CAN data frame transmission; can_raw: to implement the sending and receiving of raw CAN data; can_socket: provides an interface for communicating with user space applications. Protocol stack: SocketCAN includes multiple protocol stacks, such as CAN 2.0A / B, and supports FD (Flexible Data-rate) mode, which helps to increase the data transmission rate and meet the needs of higher bandwidth. Interface and API: Through the standard SocketAPI, developers can operate the CAN bus like operating the TCP / IP network interface, which enables developers to send and receive data and monitor the bus status through the programming interface.

[0054] 2.2SocketCAN communication principle

[0055] The basic principle of SocketCAN communication is a network programming model based on the socket interface. Its workflow can be divided into the following steps:

[0056] Device initialization and configuration: When the system starts, the Linux kernel loads the corresponding CAN device driver and configures appropriate hardware parameters, such as baud rate, CAN ID, transmission mode, etc.

[0057] Socket creation: The user space application creates a CAN socket by calling the socket() system call. This socket will communicate with the underlying hardware interface (such as CAN0, can1 and other devices);

[0058] Data transmission: Use the sendto() function to send the data frame to the CAN bus. The data format is a standard CAN frame, including fields such as ID, data length, and data;

[0059] Data reception: Use the recvfrom() function to receive data from the CAN bus. The received data will be transmitted to the application in the form of CAN frames. The application can further parse and process it based on the ID and data.

[0060] Data filtering and processing: SocketCAN supports filtering mechanisms, allowing users to set filtering rules, such as only receiving data frames with specific IDs or data content. This can be configured through setsockopt() to further improve system performance.

[0061] 2.3CAN communication matrix

[0062] SocketCAN communication needs to be combined with the CAN communication matrix of the chassis and the camera, and the CAN messages required by the ADAS algorithm are transmitted to the MCU through the SocketCAN communication protocol and the CAN bus, so as to perform the lateral and longitudinal control of the real vehicle based on the MCU. The DBC file of the CAN message communication matrix is ​​as follows Figure 4 As shown in the figure, the vehicle deceleration CAN message contains signals such as braking deceleration size, deceleration priority, and control mode. The DBC file of the CAN communication matrix usually includes all CAN messages required by the chassis / camera sensor. The CAN message usually contains one or more CAN signals, the arrangement of CAN signals in the CAN message, the message identifier ID of the CAN message, the message length (byte size) of the CAN message, and whether the data frame format of the CAN message is a standard frame or an extended frame.

[0063] 2.4MCU driver configuration

[0064] The ADAS algorithm is deployed in the industrial control computer (SOC). Based on the SocketCAN communication protocol, the output signal of the ADAS algorithm is transmitted to the MCU through the CAN bus. The corresponding CAN driver needs to be configured in the MCU to drive the corresponding hardware devices to complete the lateral and longitudinal joint control of the vehicle. In this specific embodiment, the CAN bus configuration of a domestically produced MCU is taken as an example to describe the CAN bus configuration drive method.

[0065] 2.4.1 CAN controller configuration

[0066] Each sensor is usually defined as a CAN node. For example, if the ADAS algorithm requires data from the chassis and camera sensors, two CAN nodes usually need to be configured, one as the chassis CAN node channel and the other as the camera CAN node channel. One CAN node corresponds to one CAN controller. The CAN controller usually needs to configure the index number of the CAN channel, whether the data is sent and received using interrupt triggering / polling triggering, etc. (interrupt triggering needs to be combined with the timer callback function to complete the periodic sending / receiving of CAN messages), the baud rate of the CAN controller, whether the CAN message is stored in the RAM area or the hardware FIFO area (a frame of CAN message is generally stored in a CAN mailbox, and is stored in the RAM area / hardware FIFO area in the form of a CAN mailbox), the name of the callback function for completing the reception / sending of the CAN message, etc. The baud rate calculation formula for the CAN controller is: Bit time parameter = synchronization segment + propagation time segment + phase buffer segment 1 + phase buffer segment 2. The clock of the CAN bus comes from the internal and external clock sources, and is obtained through frequency division and multiplication. The frequency division coefficient comes from the frequency division size of the phase-locked loop (PLL) of the IC circuit inside the CAN bus.

[0067] 2.4.2 CAN message configuration

[0068] CAN messages usually need to be configured as standard frames or extended frames, which CAN controller the CAN message is in, whether the CAN message is stored in the RAM area or the FIFO area, whether the CAN message is received or sent, etc. If the CAN message is in the form of a corresponding receive message, it is usually necessary to configure the corresponding receive hardware filter FIFO, and configure the corresponding mask in the receive hardware filter to ensure that the message with the specified ID is received when receiving the message, so as to avoid receiving all messages and causing the MCU's CAN mailbox to be overloaded, thereby entering the BusOff state and affecting the normal communication and operation of the CAN bus.

[0069] 2.4.3 MCU CAN message related sending and receiving logic

[0070] The industrial computer (SOC) transmits the control signal of the ADAS algorithm CAN message to the MCU through the CAN bus via the SocketCAN communication protocol. The corresponding signal logic needs to be programmed in the MCU. For example, when a CAN message signal of the steering wheel angle is received, the MCU needs to send the corresponding entire CAN message data segment to the corresponding ECU through the Can_Write() function to complete the lateral and longitudinal joint control.

[0071] Finally, the ADAS adaptive cruise control and lane keeping algorithm was successfully verified by combining the SocketCAN communication protocol with the MCU. The real-car effect was recorded in real time by Canoe. The corresponding real-car effect diagram is shown below. Figure 5 The figure shows the change diagram of key parameters of the lane keeping function implemented in accordance with the method of the present invention. The distance between the vehicle and the right lane line is stabilized at 1.7m, proving the effectiveness of the deployment scheme of this patent.

[0072] What is disclosed above is only a preferred embodiment of the present invention, and it certainly cannot be used to limit the scope of rights of the present invention. Ordinary technicians in this field can understand that all or part of the processes of the above embodiment and equivalent changes made according to the claims of the present invention still fall within the scope of the invention.

Claims

1. An ADAS deployment method based on SocketCAN communication protocol, characterized in that: The following steps are involved: Step 1: Deploy the ADAS algorithm on the industrial computer SOC; Step 2: Use the SocketCAN communication protocol to connect the industrial computer SOC and the vehicle MCU through the CAN bus; Step 3: The ADAS algorithm is combined with the CAN communication matrix of the chassis and the camera and transmitted to the vehicle MCU; Step 4: The vehicle MCU configures the CAN driver to control the hardware device to complete the vehicle's lateral and longitudinal joint control.

2. The ADAS deployment method based on the SocketCAN communication protocol as claimed in claim 1, characterized in that: The working steps of the SocketCAN communication protocol are as follows: Device initialization and configuration; Creation of Socket to communicate with the underlying hardware interface; Use the sendto() function to send the data frame to the CAN bus; Use the recvfrom() function to receive data from the CAN bus. The received data will be transmitted to the application in the form of CAN frames. Perform data filtering and processing.

3. The ADAS deployment method based on the SocketCAN communication protocol as claimed in claim 2, characterized in that: The data transmitted to the vehicle MCU in step 3 is the CAN message required by the ADAS algorithm, and the CAN message communication matrix exists in the form of a DBC file.

4. The ADAS deployment method based on the SocketCAN communication protocol as claimed in claim 3, characterized in that: CAN bus communication uses signal lines CAN_H and CAN_L for data transmission. A 120 ohm terminal resistor needs to be connected between CAN_H and CAN_L.

5. The ADAS deployment method based on the SocketCAN communication protocol as claimed in claim 4, characterized in that: The process of vehicle MCU driver configuration in step 4 includes the following steps: Configure the CAN controller and configure CAN nodes for the chassis and camera respectively; Configure CAN messages corresponding to the CAN controller; Program the signal logic corresponding to the ADAS algorithm in the vehicle MCU.

6. The ADAS deployment method based on the SocketCAN communication protocol as claimed in claim 5, characterized in that: The baud rate calculation formula of the CAN controller is: Among them, bit time parameter = synchronization segment + propagation time segment + phase buffer segment 1 + phase buffer segment 2; The clock of the CAN bus comes from internal and external clock sources, which are obtained through frequency division and frequency multiplication; The frequency division coefficient comes from the frequency division size of the phase-locked loop of the IC circuit inside the CAN bus.

Images