Method for processing diagnostic data in an ecu based on spi communication, ecu

Abstract

The application relates to a processing method of diagnostic data in an ECU based on SPI communication and an ECU, wherein the ECU comprises a master device and a slave device, a SoC is integrated on the master device, and an MCU is integrated on the slave device, the method comprises the following steps: the SoC sets priorities for diagnostic messages sent by a client, and checks and encrypts the diagnostic messages after the priorities are set; the SoC informs the slave device to receive data based on a first signal line after the checking and the encrypting are completed; the MCU informs the SoC to receive and process diagnostic messages based on a second signal line after receiving the information sent by the SoC based on the first signal line, decrypts and analyzes the processed diagnostic messages sent by the MCU based on a third signal line, and sends diagnostic response messages to the SoC based on a fourth signal line; and the SoC returns the diagnostic response messages to the client. Through the application, the problem of low cross-core data transmission efficiency in the ECU in the prior art is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of automobile communication, and particularly relates to a processing method of diagnostic data in an ECU based on SPI communication and an ECU. BACKGROUND

[0002] With the rapid development of automobile electronic technology, the number of electronic control units (ECU) in vehicles is increasing, and these ECUs need to exchange data and perform diagnosis through various communication protocols. Modern automobile electronic systems often include complex network architectures, which use multiple different communication protocols, such as Controller Area Network (CAN), Local Interconnect Network (LIN), Flex Ray, and Ethernet. In order to improve the performance and reliability of the system, especially in the application of diagnosis and control systems, a high-efficiency and reliable cross-core data transmission and processing algorithm is needed. For the cross-core diagnostic data transmission requirement between the System-on-Chip (SoC) module and the Microcontroller Unit (MCU) in the ECU, the current method is to use a dedicated gateway device to realize protocol conversion or to process data through a software algorithm. However, the existing method has the problem of low data transmission efficiency in actual application. SUMMARY

[0003] The present application provides a processing method of diagnostic data in an ECU based on SPI communication and an ECU to solve the problem of low cross-core data transmission efficiency in the ECU in the prior art.

[0004] In a first aspect, the application provides a method for processing diagnostic data in an ECU based on SPI communication, characterized in that the ECU comprises a master device and a slave device, the master device is integrated with a system on chip (SoC), and the slave device is integrated with a micro control unit (MCU), the method comprising: the SoC setting a priority for a diagnostic message sent by a client, and checking and encrypting the diagnostic message after the priority is set; the SoC informing the slave device to receive data based on a first signal line after the checking and encryption are completed; wherein the first signal line corresponds to a general purpose input / output (GPIO1) pin in the master device and the slave device; the MCU informing the SoC to receive a processed diagnostic message based on a second signal line after receiving the notification sent by the SoC based on the first signal line, and decrypting and analyzing the processed diagnostic message sent by the MCU based on a third signal line, and sending a diagnostic response message to the SoC based on a fourth signal line; wherein the second signal line corresponds to a general purpose input / output (GPIO2) pin in the master device and the slave device; the third signal line corresponds to a master-out-slave-in (MISO) data line, and the fourth signal line corresponds to a master-in-slave-out (MOS) data line; and the SoC returns the diagnostic response message to the client.

[0005] In a second aspect, the application provides an electronic control unit (ECU), characterized in that the ECU comprises a master device and a slave device, the master device is integrated with a system on chip (SoC), and the slave device is integrated with a micro control unit (MCU); the SoC is configured to set a priority for a diagnostic message sent by a client, and check and encrypt the diagnostic message after the priority is set; and inform the slave device to receive data based on a first signal line after the checking and encryption are completed; wherein the first signal line corresponds to a general purpose input / output (GPIO1) pin in the master device and the slave device; the MCU is configured to inform the SoC to receive a processed diagnostic message based on a second signal line after receiving the notification sent by the SoC based on the first signal line, and decrypt and analyze the processed diagnostic message sent by the MCU based on a third signal line, and send a diagnostic response message to the SoC based on a fourth signal line; wherein the second signal line corresponds to a general purpose input / output (GPIO2) pin in the master device and the slave device; the third signal line corresponds to a master-out-slave-in (MISO) data line, and the fourth signal line corresponds to a master-in-slave-out (MOS) data line; and the SoC is configured to return the diagnostic response message to the client.

[0006] In a third aspect, the present application provides an electronic device, comprising: at least one communication interface; at least one bus connected with the at least one communication interface; at least one processor connected with the at least one bus; and at least one memory connected with the at least one bus, wherein the processor is configured to execute the method for processing diagnostic data in an ECU based on SPI communication according to the first aspect of the present application.

[0007] In a fourth aspect, the present application further provides a computer storage medium storing computer executable instructions for executing the method for processing diagnostic data in an ECU based on SPI communication according to the first aspect of the present application.

[0008] The above technical solution provided by the embodiments of the present application has the following advantages compared with the prior art: in the embodiments of the present application, the SoC in the master device receives the diagnostic packet sent by the client and performs priority processing on the diagnostic packet, and performs verification and encryption according to the priority. By setting the priority of the diagnostic packet, it can be ensured that important diagnostic requests can be responded quickly. In addition, the master device and the slave device can perform bidirectional notification based on the GPIO1 pin and the GPIO2 pin, that is, when the SoC can send data to the MCU, it can first send a notification to the MCU based on the GPIO1 pin, and then the MCU sends a notification that it can receive data to the SoC based on the GPIO2 pin, thereby avoiding frequent polling of the SoC and improving the efficiency of cross-core synchronization and coordination. In addition, the data can be verified and encrypted in the master device, and the slave device receiving the data can decrypt the data, thereby improving the reliability and stability of the data in the transmission process. As can be seen, by the method of the embodiments of the present application, the problem of low cross-core data transmission efficiency in the prior art is solved, the data transmission efficiency is improved, and the security of the data transmission process is also ensured. BRIEF DESCRIPTION OF DRAWINGS

[0009] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows, and obviously, other drawings can also be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0011] One or more embodiments are illustrated by way of example in the drawings and are described herein in connection with the embodiments presented. The embodiments disclosed herein are not intended to be exhaustive or to limit the claims to the precise form disclosed. Rather, the embodiments are chosen and described so that others skilled in the art can appreciate and understand the implied use of the principles set forth herein. The drawings are not intended to be to scale. Therefor, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to various embodiments.

[0012] Figure 1 A structure schematic diagram of an ECU provided in an embodiment of the present application;

[0013] Figure 2 A flowchart of a processing method of diagnostic data in an ECU based on SPI communication provided in an embodiment of the present application;

[0014] Figure 3 A structure schematic diagram of an ECU in a specific example of the present application;

[0015] Figure 4 A flowchart of data processing of an ECU based on SPI in a specific example of the present application;

[0016] Figure 5 A structure schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0018] The following disclosure provides many different embodiments, or examples, for implementing different structures of the present application. For the purpose of simplicity, the elements and settings of particular examples in the following description are set forth by referring to the drawings. Of course, they are only examples and are not intended to limit the present application. In addition, reference numerals and / or letters can be repeated in different examples in the present application. Such repetition is for the purpose of simplicity and clarity, and does not indicate a relationship between the various embodiments and / or settings being discussed.

[0019] To solve the problem of low efficiency of cross-core data transmission in the ECU in the prior art, the present application provides a processing method of diagnostic data in an ECU based on SPI communication, as shown in Figure 1 The ECU in the embodiment of the present application includes a master device and a slave device, wherein the master device is integrated with a system on chip SoC, and the slave device is integrated with a micro control unit MCU. Based on this, the method in the embodiment of the present application, as shown in Figure 2 may include the following steps:

[0020] Step 201, the SoC sets priority for the diagnostic message sent by the client, and checks and encrypts the diagnostic message after the priority is set;

[0021] Step 202, after the checking and encryption are completed, the SoC notifies the slave device to receive data based on a first signal line; wherein the first signal line corresponds to a general-purpose input / output GPIO1 pin in the master device and the slave device;

[0022] In the embodiment of the present application, by setting the priority, the key task or key data packet can be processed preferentially, so as to ensure that important diagnostic requests can be responded quickly. For example, the current diagnostic message can be used to read ECU information, fault codes, and perform fault diagnosis and ECU flashing. The diagnostic message for fault diagnosis can be set to the highest priority, then the diagnostic message for reading fault codes is set to the second priority, then the diagnostic message for reading ECU information is set to the third priority, and the diagnostic message for ECU flashing is set to the lowest priority. The above is only an example, and the priority of the diagnostic message can be set according to actual needs in specific application scenarios.

[0023] It should be noted that the signal lines in the embodiment of the present application are all based on SPI (Serial Peripheral Interface, serial peripheral interface) protocol for data transmission. In the embodiment of the present application, it can specifically include six signal lines, that is, it includes a clock line (Serial Clock, SCK), a master input slave output data line (Master Input Slave Output, MISO), a master output slave input data line (Master Output Slave Input, MOSI) and a chip selection line (Chip Select, CS), and a signal line composed of GPIO1 pin and GPIO2 pin; wherein the clock line and the chip selection line will be used in the actual data transmission process, that is, the clock line is used for triggering the clock signal, and the chip selection line is used to generate a chip selection signal, so that the master chip selects the slave chip.

[0024] Step 203, after the MCU receives the notification sent by the SoC based on the first signal line, the MCU notifies the SoC to receive the encrypted diagnostic message based on a second signal line, and decrypts and analyzes the processed diagnostic message sent by the MCU based on a third signal line, and sends a diagnostic response message to the SoC based on a fourth signal line; wherein the second signal line corresponds to a general-purpose input / output GPIO2 pin in the master device and the slave device; the third signal line corresponds to the master output slave input data line MISO, and the fourth signal line corresponds to the master input slave output data line MOSI;

[0025] It should be noted that, before the signal lines based on the GPIO1 pin and the GPIO2 pin, the existing MCU end cannot actively notify the SoC data state, resulting in the need for the SoC end to frequently poll, resulting in high data processing delay. In the embodiment of the present application, the GPIO1 pin and the GPIO2 pin can be used to realize bidirectional notification during data exchange between the master device and the slave device, so that the MCU can actively notify the data state (whether it can receive data) through the GPO2 pin, thereby reducing the data processing delay, improving the real-time performance of the system for data processing, and also improving the cross-core synchronization and coordination efficiency.

[0026] Step 204, the SoC returns the diagnostic response message to the client.

[0027] Through the above steps 201 to 204, in the embodiment of the present application, the SoC in the master device receives the diagnostic message sent by the client, and performs priority processing and verification and encryption according to the priority on the diagnostic message. By setting the priority of the diagnostic message, it can be ensured that important diagnostic requests can be quickly responded. In addition, the master device and the slave device can perform bidirectional notification based on the GPIO1 pin and the GPIO2 pin, that is, when the SoC can send data to the MCU, it can first send a notification to the MCU based on the GPIO1 pin, and then the MCU sends a notification that it can receive data to the SoC based on the GPIO2 pin, thereby avoiding frequent polling of the SoC and improving the cross-core synchronization and coordination efficiency. In addition, the data can be verified and encrypted in the master device, and the slave device receiving the data can decrypt the data, thereby improving the reliability and stability of the data in the transmission process. As can be seen, through the method of the embodiment of the present application, the problem of low cross-core data transmission efficiency in the prior art is solved, the data transmission efficiency is improved, and the security of the data transmission process is also ensured.

[0028] In the embodiment of the present application, the received diagnostic message can be set with a priority, that is, the priority is set according to the importance of the diagnostic message, so as to ensure that the diagnostic message with high importance is processed first. Therefore, the method of setting the priority of the diagnostic message sent by the client by the SoC in the above step 201, and verifying and encrypting the diagnostic message after setting the priority, can further include the following steps:

[0029] Step 11, the SoC buffers the diagnostic message sent by the client, and sets a corresponding priority for the buffered diagnostic message according to the importance of the diagnostic message;

[0030] In response, caching received data allows for direct data retrieval from the cache, rather than lengthy data exchanges over the network or ECUs each time, compared to frequent UDS (Unified Diagnostic Services) requests. This significantly improves system response speed and efficiency. Furthermore, caching UDS requests reduces the number of direct accesses to the ECUs, thereby alleviating ECU load, extending their lifespan, and improving the overall vehicle system stability.

[0031] Step 12: The SoC parses the diagnostic messages in the buffer according to the priority to obtain the payload data of the unified diagnostic service, and verifies and encrypts the payload data.

[0032] Through steps 11 and 12 above, different priorities can be set for diagnostic messages, prioritizing critical tasks or data packets to ensure rapid response to important diagnostic requests. Simultaneously, for high-priority diagnostic messages, the UDS (Unified Diagnostic Services) payload data is obtained through parsing. In this embodiment, the UDS data is used for diagnosing and diagnosing electronic devices connected to the vehicle network. UDS diagnostic data is typically transmitted via CAN (Controller Area Network) or FlexRay networks. In a CAN network, each message consists of the following parts: 1) Identifier: This is a unique ID used to specify the message's destination. 2) Control Field: Contains message attributes such as priority and data length. 3) Data Field: This is the actual data payload, which can be a DTC (Diagnostic Trouble Code), PID (Parameter Identifier) ​​value, or other diagnostic information. 4) CRC (Cyclic Redundancy Check): Used to detect errors in message transmission.

[0033] Furthermore, in this embodiment of the application, the method by which the SoC verifies and encrypts the payload data in step 12 above may further include:

[0034] Step 21: Verify the diagnostic session ID of the payload data, and after successful verification, reassemble the payload data; wherein, the reassembled data type is a data type that the MCU can receive;

[0035] Step 22: The SoC determines the corresponding verification algorithm based on the data length of the reassembled data, determines the checksum of the reassembled data based on the verification algorithm, and appends the checksum to the end of the reassembled data to obtain a complete data frame.

[0036] Step 23: The SoC generates an encryption key and uses a preset encryption algorithm to encrypt the complete data frame.

[0037] In this embodiment, the parsed payload data can be reassembled into a data type that can be received by the MCU. Specifically, it is reassembled according to the format of CANID (MCU request ID) + payload. This method simplifies the unpacking process and directly transmits the parsed payload data to the other end, improving transmission efficiency. In this embodiment, data verification is used to detect and correct diagnostic data errors during transmission, ensuring the accuracy and integrity of data transmission. Furthermore, in this embodiment, CRC (Cyclic Redundancy Check) can be used for verification. In a specific example, the verification process can be: 1) Determine the verification algorithm: Determine the length of the data frame. If the length is less than or equal to 256 bytes, CRC-16 is used; if the length is greater than 256 bytes, CRC-32 is used. 2) Calculate the checksum: Calculate the checksum of the data according to the selected verification algorithm. 3) Append the checksum: Append the calculated checksum to the data to form a complete data frame. For example, for 8 bytes of data, a 2-byte CRC-16 checksum can be appended.

[0038] Furthermore, data encryption is used to protect data security during transmission and prevent data from being illegally intercepted and tampered with. Therefore, in this embodiment, AES (Advanced Encryption Standard, a symmetric encryption algorithm) can be used for data encryption. The specific process includes: 1) Selecting an encryption algorithm: Selecting a suitable symmetric encryption algorithm, such as AES-128, AES-192, or AES-256. For example, selecting the AES-128 encryption algorithm, which has a fast encryption and decryption speed and can ensure the real-time transmission of data, has an encryption key length of 128 bits. 2) Presetting an encryption key: Generating or presetting an encryption key. Taking a 16-byte (128-bit) key as an example: {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}. 3) Encrypt data: Use encryption algorithms to encrypt the data. For example, 8-byte data can be encrypted using AES-128.

[0039] In this embodiment, bidirectional notification can be performed using GPIO1 and GPIO2 pins to improve data transmission efficiency. Therefore, the method by which the SoC notifies the device of receiving data based on the first signal line in step 201 above can further include:

[0040] Step 31: The SoC initializes the GPIO1 and GPIO2 pins, as well as the serial peripheral interface (SPI) attributes of the signal lines;

[0041] Step 32: The SoC sets the signal of the GPIO1 pin from low level to high level to notify the slave device to receive data.

[0042] In this embodiment, the GPIO pins (including GPIO1 and GPIO2 pins) and SPI attributes are initialized in the constructor of the encapsulated SPI class. These attributes include whether the SPI is synchronous or asynchronous, whether it supports full-duplex or half-duplex communication, master-slave mode, and multi-slave management. Then, a thread is created to register the GPIO2 FD (FileDescriptor) with the epoll instance and calls the epoll_wait function to block and wait for an event to occur. The thread checks whether it is a rising edge (the level signal changes from low to high). If so, the semaphore is released to notify the user. Finally, a thread is created to block and acquire the semaphore so that the processed data can be returned to the callback function epoll_wait.

[0043] Based on this, the method of the SoC sending the processed diagnostic message to the MCU based on the third signal line involved in step 203 above can be further described as follows: when the SoC determines that the signal of the GPIO2 pin changes from low level to high level as a rising edge, it sends the complete data frame to the MCU based on the third signal line.

[0044] In a specific example, this could be done by first storing the incoming data in the MCU's circular buffer, and then pulling GPIO1 high (the level signal changes from low to high) to notify the MCU to receive the data. Based on the epoll_wait function mentioned above, the system would block and check if GPIO2 is a rising edge signal (the level signal changes from low to high). If so, the semaphore would be released, GPIO1 would be pulled low, and the data would be sent. If not, the system would continue to wait.

[0045] Furthermore, in this embodiment, for the slave device, since the received data is encrypted, it needs to be decrypted. Therefore, the method by which the MCU decrypts the processed diagnostic message involved in 203 of this embodiment may further include:

[0046] Step 41: The MCU extracts the encrypted data from the received data frame;

[0047] Step 42: The MCU uses the decryption algorithm and encryption key corresponding to the preset encryption algorithm to decrypt the encrypted data;

[0048] Step 43: The MCU calculates the checksum of the decrypted data, and if the calculated checksum matches the received checksum, it determines that the received data is correct.

[0049] For steps 41 to 43 above, in a specific example, after receiving data from the buffer, the MCU will decrypt the data, verify the decrypted data, and perform response processing. This data decryption can include the following processes: 1) Extracting encrypted data: Extracting encrypted data from the received data frame. 2) Decrypting data: Decrypting the encrypted data using the same encryption key and decryption algorithm.

[0050] The data verification process can include: after data decryption, calculating a checksum on the received data and comparing it with the received checksum. The specific process is as follows: 1) Extracting the checksum: Extracting the checksum from the received data frame. Taking a 10-byte data frame as an example, extract the last 2 bytes as the checksum. 2) Calculating the checksum: Calculating the checksum on the received data portion (excluding the checksum). 3) Verification comparison: Comparing the calculated checksum with the received checksum. If they match, the data transmission is correct; if they do not match, a data transmission error has occurred and retransmission is required, meaning the SoC needs to retransmit the processed diagnostic message to the MCU.

[0051] In this embodiment of the application, the method of the MCU sending a diagnostic response message based on the fourth signal line in step 203 above may further include:

[0052] Step 51: The MCU determines the source of the diagnostic request based on the diagnostic session ID and generates the corresponding diagnostic response message according to the unified diagnostic service protocol.

[0053] Step 52: The MCU sends a diagnostic response message to the SoC based on the fourth signal line.

[0054] As can be seen, in this embodiment of the application, the diagnostic session ID can be specifically the CANID of the data. That is, the source of the diagnostic request can be determined according to the CANID, and then the corresponding diagnostic response message is generated according to the UDS protocol. The diagnostic response message is transmitted to the SoC through the SPI callback function. The SoC parses and strips the received CAN message to obtain the final diagnostic response data, stores it in the data buffer, and finally sends the diagnostic response data back to the client through the DoIP protocol.

[0055] The present application will now be explained and described in conjunction with specific embodiments of the present application, which provide a method for cross-core diagnostic data transmission and processing based on SPI communication. For example... Figure 3 The diagram shows the system architecture of a cross-core diagnostic data transmission and processing algorithm based on six-wire SPI communication. The system comprises three parts: a SoC, an MCU, and a six-wire SPI communication interface. The SoC is used for scheduling and controlling diagnostic tasks. It includes a doipserver module and a datahandle module. The doipserver module receives diagnostic messages and includes a data buffer and a priority processing unit. The datahandle module handles data parsing and processing, data verification, and encryption to ensure the integrity and security of data transmission. Specifically, it includes data parsing and processing, data verification, and encryption. The MCU is used for diagnostic data processing, which includes receiving diagnostic messages, data verification and decryption, data parsing, data processing, and returning results. The MCU includes a data buffer, a data verification and decryption unit, and a parsing and processing unit.

[0056] Furthermore, existing SPI communication between SoC and MCU uses a 4-wire system. This 4-wire SPI communication interface includes one clock line (SCK), one master-to-slave (MISO) data line, one master-to-slave (MOSI) data line, and one chip select line (CS). However, the existing method lacks a bidirectional notification mechanism, leading to difficulties in synchronization and coordination. The MCU cannot actively notify the SoC of the data status, causing the SoC to need to poll frequently, resulting in high data processing latency. Therefore, this application embodiment adds two signal lines to the original four-wire SPI, that is, this application embodiment is based on a six-wire SPI communication interface for data transmission between the master core and slave core, such as... Figure 3 As shown, the two newly added signal lines are labeled SPI5 and SPI6. These two idle GPIO pins are used to enable bidirectional notification during data exchange between the SOC master and the MCU slave.

[0057] exist Figure 3 On the basis of, such as Figure 4 The diagram illustrates the cross-core diagnostic data transmission and processing flow based on SPI communication. Based on this, the steps of this SPI-based cross-core diagnostic data transmission and processing method include:

[0058] Step 301: The doipclient (Ethernet-based communication protocol client) simulates the diagnostic instrument and sends diagnostic messages to the SoC based on DOIP (Diagnostic Communication Over Internet Protocol). The data buffer of the doipserver in the SoC stores the requested UDS service. Furthermore, the priority processing module in the doipserver sets different priorities for data packets. For high-priority diagnostic messages, it parses them to obtain the payload.

[0059] By employing the above methods, frequent UDS requests can be retrieved directly from the cache, instead of requiring lengthy data exchanges over the network or through the ECU each time. This significantly improves system response speed and efficiency. Furthermore, caching UDS requests reduces the number of direct accesses to the ECU, thereby alleviating the ECU's load, extending its lifespan, and enhancing the overall vehicle system stability.

[0060] Step 302: Pass the payload into the datahandle module to verify its diagnostic session ID.

[0061] Verifying the diagnostic session ID ensures that the ECU can continuously track and correctly process requests, maintain diagnostic state and context consistency, and guarantee the effectiveness of security and authorization verification. This is crucial for implementing complex diagnostic and programming operations, maintaining communication consistency, and preventing unauthorized access. After successful diagnostic session ID verification, data structure transformation, validation, and encryption are required. This process includes:

[0062] 1) Data structure conversion: The payload data obtained from the doipserver module is reassembled into a data type that can be received by the MCU. In this embodiment, it is reassembled in the format of CANID (MCU request ID) + payload. This method simplifies the unpacking process and directly transmits the parsed payload data to the other end, improving the transmission efficiency.

[0063] 2) Data Verification: Data verification is used to detect and correct diagnostic data errors during transmission, ensuring the accuracy and integrity of data transmission. This patent uses CRC (Cyclic Redundancy Check) verification. The following are the implementation steps for data verification:

[0064] Step 61: Determine the verification algorithm, that is, determine the length of the data frame. If the length is less than or equal to 256 bytes, use CRC-16; if the length is greater than 256 bytes, use CRC-32 verification.

[0065] Step 62: Calculate the check code, that is, calculate the check code of the data according to the selected check algorithm.

[0066] Step 63: Append a checksum, that is, append the calculated checksum to the end of the data to form a complete data frame.

[0067] 3) Data Encryption: Data encryption is used to protect data security during transmission and prevent data from being illegally intercepted and tampered with. In this embodiment, the encryption algorithm used is AES, and a suitable symmetric encryption algorithm, such as AES-128, AES-192, or AES-256, is selected. In this embodiment, AES-128 is chosen because it has fast encryption and decryption speeds, ensuring real-time data transmission, and the encryption key length is 128 bits. Then, an encryption key is preset, i.e., a 16-byte (128-bit) key is generated or preset. Finally, the data is encrypted. Specifically, an encryption algorithm can be used to encrypt the data; for example, 8 bytes of data can be encrypted using AES-128.

[0068] Step 303 involves reassembling the data into a complete, encrypted frame and transmitting it via SPI to the data buffer on the MCU side for temporary storage of data during transmission. The data buffer employs a FIFO (First In First Out) mechanism to manage data, ensuring that data is processed and transmitted in the order it is received. The SPI transmission of diagnostic data includes SPI initialization and data transmission.

[0069] The SPI initialization process is as follows: In the constructor of the encapsulated SPI class, the GPIO pins (including GPIO1 and GPIO2) and SPI attributes are initialized. Then, a thread is created to register the FD of GPIO2 with the epoll instance, and the epoll_wait function is called to block and wait for an event to occur, checking for a rising edge and releasing the semaphore. Finally, a thread is created to block and acquire the semaphore, used to return the processed data to the callback function.

[0070] The data transmission process is as follows: The datahandle module first calls the SPI transmit interface, passing in the starting address and length of the encrypted complete data frame. Then, it stores the incoming data into a circular buffer and pulls GPIO1 high to notify the MCU to receive the data. Finally, it blocks using the epoll_wait function and checks if GPIO2 has a rising edge. If it does, it releases the semaphore, pulls GPIO1 low, and sends the data. Otherwise, it continues to wait.

[0071] Step 304: After receiving data from the diagAPP buffer, the MCU will decrypt the data, perform verification after receipt, and process the data response.

[0072] The data decryption process is as follows: Extract encrypted data. The encrypted data is extracted from the received data frame and encrypted as 8 bytes. Decrypt data: The encrypted data is decrypted using the same encryption key and decryption algorithm.

[0073] Furthermore, the data verification process in this embodiment is as follows: After data decryption, the system needs to calculate a checksum on the received data and compare it with the received checksum. Specifically, the process can be as follows: First, extract the checksum, i.e., extract the checksum from the received data frame. Taking a 10-byte data frame as an example, extract the last 2 bytes as the checksum. Then, calculate the checksum, i.e., calculate the checksum on the received data portion (excluding the checksum). Finally, perform a verification comparison, i.e., compare the calculated checksum with the received checksum. If they match, the data transmission is correct; if they do not match, the data transmission has an error and needs to be retransmitted.

[0074] Step 305: In the diagnostic response processing module of diagAPP, the source of the diagnostic request is first determined based on the CANID. Then, a corresponding diagnostic response message is generated according to the UDS protocol and passed to the response callback function registered during SPI initialization. The SPI callback function transmits the diagnostic response message to the priority processing module on the doipserver side. This module parses and extracts the received CAN message to obtain the final diagnostic response data, stores it in the data buffer, and finally sends the diagnostic response data back to the DoIP client via the DoIP protocol.

[0075] Corresponding to the above Figure 2 This application provides an electronic control unit (ECU), such as... Figure 1 As shown, the ECU includes a master device and a slave device. The master device integrates a system-on-a-chip (SoC), and the slave device integrates a microcontroller unit (MCU).

[0076] The SoC is used to set the priority of diagnostic messages sent by the client, and to verify and encrypt the diagnostic messages after the priority is set; after the verification and encryption are completed, the SoC notifies the slave device to receive data based on the first signal line; wherein, the first signal line corresponds to the general-purpose input / output GPIO1 pin in both the master and slave devices.

[0077] The MCU is used to notify the SoC to receive the processed diagnostic message via the second signal line after receiving the notification sent by the SoC via the first signal line, and to decrypt and parse the processed diagnostic message sent by the MCU via the third signal line, and to send a diagnostic response message to the SoC via the fourth signal line; wherein, the second signal line corresponds to the general-purpose input / output GPIO2 pin in the master and slave devices; the third signal line corresponds to the master-output / slave-in data line MISO; and the fourth signal line corresponds to the master-in / slave-output data line MOS.

[0078] The SoC is also used to send diagnostic response messages back to the client.

[0079] In an optional embodiment of this application, the SoC in this application embodiment is further configured to cache diagnostic messages sent by the client, and set corresponding priorities for the cached diagnostic messages according to their importance; and parse the cached diagnostic messages according to their priorities to obtain the payload data of the unified diagnostic service, and verify and encrypt the payload data.

[0080] In an optional embodiment of this application, the SoC in this application embodiment is further used to reassemble the unified diagnostic service data according to the format of the controller local area network CANID and the payload; wherein, CANID is the MCU's request ID;

[0081] In an optional embodiment of this application, the SoC in this application embodiment is further configured to determine the corresponding verification algorithm based on the data length of the reconstructed data, determine the verification code of the reconstructed data based on the verification algorithm, and append the verification code to the end of the reconstructed data to obtain a complete data frame; and the SoC is further configured to generate an encryption key and encrypt the complete data frame using a preset encryption algorithm.

[0082] In an optional embodiment of this application, the SoC in this application embodiment is further configured to initialize the GPIO1 pin and GPIO2 pin, as well as the serial peripheral interface (SPI) attribute of the signal line; and to set the signal of the GPIO1 pin from low level to high level to notify the slave device to receive data.

[0083] In an optional embodiment of this application, the SoC in this application is further configured to send a complete data frame to the MCU based on the third signal line when the signal of the GPIO2 pin changes from low level to low level and then to high level as a rising edge.

[0084] In an optional embodiment of this application, the MCU in this application embodiment is further configured to extract encrypted data from the received data frame, and use a decryption algorithm corresponding to a preset encryption algorithm and an encryption key to decrypt the encrypted data, and calculate a checksum on the decrypted data, and determine that the received data is correct if the calculated checksum matches the received checksum.

[0085] In an optional embodiment of this application, the MCU in this application embodiment is further configured to determine the source of the diagnostic request based on the diagnostic session ID, generate a corresponding diagnostic response message based on the unified diagnostic service protocol, and send the diagnostic response message to the SoC based on the fourth signal line.

[0086] like Figure 5 As shown in the figure, this application provides an electronic device, including a processor 511, a communication interface 512, a memory 513, and a communication bus 514, wherein the processor 511, the communication interface 512, and the memory 513 communicate with each other through the communication bus 514.

[0087] Memory 513 is used to store computer programs;

[0088] In one embodiment of this application, when the processor 511 executes the program stored in the memory 513, it implements the diagnostic data processing method in the ECU based on SPI communication provided in any of the aforementioned method embodiments. Its function is similar and will not be described again here.

[0089] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method for processing diagnostic data in an ECU based on SPI communication as provided in any of the foregoing method embodiments.

[0090] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0091] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0092] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0093] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for processing diagnostic data in an ECU based on SPI communication, characterized in that, The ECU includes a master device and a slave device. The master device integrates a system-on-a-chip (SoC), and the slave device integrates a microcontroller unit (MCU). The method includes: The SoC sets a priority for diagnostic messages sent by the client, and verifies and encrypts the diagnostic messages after setting the priority; After verification and encryption are completed, the SoC notifies the slave device to receive data based on the first signal line; wherein, the first signal line corresponds to the general-purpose input / output GPIO1 pin in both the master and slave devices; After receiving the notification sent by the SoC based on the first signal line, the MCU notifies the SoC to receive the processed diagnostic message based on the second signal line, and decrypts and parses the processed diagnostic message sent by the MCU based on the third signal line, and sends a diagnostic response message to the SoC based on the fourth signal line; wherein, the second signal line corresponds to the general-purpose input / output GPIO2 pin in the master and slave devices; the third signal line corresponds to the master-output / slave-in data line MISO, and the fourth signal line corresponds to the master-in / slave-output data line MOS; The SoC sends the diagnostic response message back to the client; The SoC sets a priority for diagnostic messages sent by the client, and verifies and encrypts the prioritized diagnostic messages, including: The SoC caches diagnostic messages sent by the client and sets corresponding priorities for the cached diagnostic messages according to their importance. The SoC parses the cached diagnostic messages according to the priority to obtain the payload data of the unified diagnostic service, and verifies and encrypts the payload data. The SoC verifies and encrypts the payload data, including: The SoC verifies the diagnostic session ID of the payload data, and after successful verification, reassembles the payload data; wherein the reassembled data type is a data type that the MCU can receive; The SoC determines the corresponding verification algorithm based on the data length of the reassembled data, determines the checksum of the reassembled data based on the verification algorithm, and appends the checksum to the reassembled data to obtain a complete data frame. The SoC generates an encryption key and uses a preset encryption algorithm to encrypt the complete data frame.

2. The method according to claim 1, characterized in that, The SoC notifies the slave device of receiving data based on a first signal line, including: The SoC initializes the GPIO1 and GPIO2 pins, as well as the serial peripheral interface (SPI) attributes of the signal lines; The SoC sets the signal of the GPIO1 pin from low to high to notify the slave device to receive data.

3. The method according to claim 2, characterized in that, The SoC sends a processed diagnostic message to the MCU based on a third signal line, including: When the SoC determines that the signal of the GPIO2 pin changes from low level to high level as a rising edge, it sends the complete data frame to the MCU based on the third signal line.

4. The method according to claim 3, characterized in that, The MCU decrypts the processed diagnostic message, including: The MCU extracts encrypted data from the received data frames; The MCU uses a decryption algorithm and an encryption key corresponding to the preset encryption algorithm to decrypt the encrypted data; The MCU calculates a checksum for the decrypted data, and determines that the received data is correct if the calculated checksum matches the received checksum.

5. The method according to claim 4, characterized in that, The MCU sends a diagnostic response message based on the fourth signal line, including: The MCU determines the source of the diagnostic request based on the diagnostic session ID and generates a corresponding diagnostic response message according to the unified diagnostic service protocol. The MCU sends the diagnostic response message to the SoC based on the fourth signal line.

6. An electronic control unit (ECU), characterized in that, The ECU includes a master device and a slave device. The master device integrates a system-on-a-chip (SoC), and the slave device integrates a microcontroller unit (MCU). The SoC is used to set the priority of diagnostic messages sent by the client, and to verify and encrypt the diagnostic messages after setting the priority; after the verification and encryption are completed, it notifies the slave device to receive data based on the first signal line; wherein, the first signal line corresponds to the general-purpose input / output GPIO1 pin in the master device and the slave device. The MCU is configured to, upon receiving a notification from the SoC sent via the first signal line, notify the SoC to receive the processed diagnostic message via the second signal line, decrypt and parse the processed diagnostic message sent by the MCU via the third signal line, and send a diagnostic response message to the SoC via the fourth signal line; wherein, the second signal line corresponds to the general-purpose input / output GPIO2 pin in the master and slave devices; the third signal line corresponds to the master-output / slave-in data line MISO; and the fourth signal line corresponds to the master-in / slave-output data line MOS. The SoC is used to send the diagnostic response message back to the client; The SoC is also used to cache diagnostic messages sent by the client, and set corresponding priorities for the cached diagnostic messages according to their importance; and to parse the cached diagnostic messages according to their priorities to obtain the payload data of the unified diagnostic service, and to verify and encrypt the payload data. The SoC is also used to reassemble unified diagnostic service data in the format of the Controller Area Network CANID and the payload; wherein, CANID is the MCU's request ID; The SoC is also used to determine the corresponding verification algorithm based on the data length of the reconstructed data, determine the verification code of the reconstructed data based on the verification algorithm, and append the verification code to the end of the reconstructed data to obtain a complete data frame; and the SoC is also used to generate an encryption key and encrypt the complete data frame using a preset encryption algorithm.

7. An electronic device, comprising: At least one communication interface; At least one bus connected to the at least one communication interface; At least one processor connected to the at least one bus; At least one memory connected to the at least one bus, wherein the processor is configured to execute the method for processing diagnostic data in an ECU based on SPI communication as described in any one of claims 1 to 5.

8. A computer storage medium storing computer-executable instructions, said computer-executable instructions being used to execute the method for processing diagnostic data in an ECU based on SPI communication as described in any one of claims 1 to 5.

Images