Message verification method and device, electronic control unit, storage medium and product
Patent Information
- Application Number
- CN202610740152.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-27
- Publication Date
- 2026-08-18
AI Technical Summary
[0018] In this embodiment, the E2E diagnostic function is abstracted into a general first verification function, which enables different messages to call the previously communicated verification function and pass different verification parameters as needed. This allows the general first verification function to be configured as a second verification function specific to the first message being transmitted, thereby improving the code reusability of the first verification function and reducing the maintenance cost of the E2E diagnostic function.
Smart Images
Figure CN122601137A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of automotive electronics technology, and in particular to a message verification method, device, electronic control unit, storage medium, and product. Background Technology
[0002] With the continuous development of modern automotive technology, the number of Electronic Control Units (ECUs) inside automobiles is gradually increasing. These ECUs communicate with each other through Controller Area Networks (CAN). To ensure the reliability and consistency of message transmission between ECUs in the CAN network, an end-to-end (E2E) protection mechanism has been proposed and applied to the CAN network to verify messages between ECUs. Summary of the Invention
[0003] This application provides a message verification method, apparatus, electronic control unit, storage medium, and product. The technical solution is as follows: On the one hand, a message verification method is provided, which is applied to a vehicle containing multiple electronic control units, the method comprising: Determine the first message transmitted between the first electronic control unit and the second electronic control unit; The message type of the first message is determined, and based on the message type of the first message, the verification requirement information of the first message is determined, wherein the verification requirement information is used to characterize the requirement to verify the first message. Based on the verification requirement information of the first message, determine the verification parameters corresponding to the first message; Based on the verification parameters, the general first verification function is configured to obtain the second verification function specific to the first message; The first message is verified using the second verification function.
[0004] In one possible implementation, the step of verifying the first message using the second verification function includes: Determine the byte length of the first message; If the byte length is not zero, the byte content of each byte in the first message is read sequentially to obtain at least one byte of content; Determine the first checksum of the at least one byte of content; The first message is verified based on the first checksum of the at least one byte of content and the second checksum carried in the first message.
[0005] In another possible implementation, the verification of the first message based on the first checksum of the at least one byte of content and the second checksum carried by the first message includes: For any byte content, if the first status code carried by the first message is the same as the second status code of the first message stored locally, and the first checksum of the byte content is the same as the second checksum of the byte content carried by the first message, then the first message passes the verification. If the first status code carried by the first message is different from the second status code of the first message stored locally, or if the first checksum of the byte content is different from the second checksum of the byte content carried by the first message, the verification of the first message fails.
[0006] In another possible implementation, when the byte length is not zero, sequentially reading the byte content of each byte in the first message to obtain at least one byte of content includes: If the length of the byte is not zero, the receiver controller is activated; The receiving controller sequentially reads the byte content of each byte in the first message to obtain at least one byte of content.
[0007] In another possible implementation, the method further includes: Based on the verification requirement information of the first message, a first verification function matching the verification requirement information is obtained from the set of verification functions.
[0008] In another possible implementation, the method further includes: If the verification result of the first message is that the verification fails, the first message is discarded; Determine the verification failure type of the first message, and based on the verification failure type, determine the recovery measures for the first message; Based on the recovery measures, the first message is recovered.
[0009] On the other hand, a message verification device is provided, which is applied in a vehicle containing multiple electronic control units, the device comprising: The first determining module is used to determine the first message transmitted between the first electronic control unit and the second electronic control unit; The second determining module is used to determine the message type of the first message and, based on the message type of the first message, determine the verification requirement information of the first message, wherein the verification requirement information is used to characterize the requirement to verify the first message. The third determining module is used to determine the verification parameters corresponding to the first message based on the verification requirement information of the first message; The configuration module is used to configure the general first verification function based on the verification parameters to obtain the second verification function specific to the first message; The verification module is used to verify the first message using the second verification function.
[0010] In one possible implementation, the verification module is configured to determine the byte length of the first message; if the byte length is not zero, sequentially read the byte content of each byte in the first message to obtain at least one byte content; determine a first checksum of the at least one byte content; and verify the first message based on the first checksum of the at least one byte content and a second checksum carried in the first message.
[0011] In another possible implementation, the verification module is configured to, for any byte content, verify the first message if the first status code carried by the first message is the same as the second status code of the first message stored locally, and the first checksum of the byte content is the same as the second checksum of the byte content carried by the first message; and fail to verify the first message if the first status code carried by the first message is different from the second status code of the first message stored locally, or if the first checksum of the byte content is different from the second checksum of the byte content carried by the first message.
[0012] In another possible implementation, the verification module is used to activate the receiving controller when the byte length is not zero; and through the receiving controller, sequentially read the byte content of each byte in the first message to obtain at least one byte content.
[0013] In another possible implementation, the device further includes: The acquisition module is used to acquire a first verification function that matches the verification requirement information from the set of verification functions based on the verification requirement information of the first message.
[0014] In another possible implementation, the device further includes: The discard module is used to discard the first message if the verification result of the first message is that the verification fails. The fourth determining module is used to determine the verification failure type of the first message, and based on the verification failure type, determine the recovery measures for the first message; The recovery module is used to recover the first message based on the recovery measures.
[0015] On the other hand, an electronic control unit is provided, which includes a main control module, the main control module including a processor and a memory, the memory storing at least one piece of program code, the at least one piece of program code being loaded and executed by the processor to implement the above-mentioned message verification method.
[0016] On the other hand, a computer-readable storage medium is provided, wherein at least one piece of program code is stored in the storage medium, the at least one piece of program code being loaded and executed by a processor to implement the above-described message verification method.
[0017] On the other hand, a computer program product is provided, the product storing at least one piece of program code, the at least one piece of program code being executed by a processor to implement the above-described message verification method.
[0018] In this embodiment, the E2E diagnostic function is abstracted into a general first verification function, which enables different messages to call the previously communicated verification function and pass different verification parameters as needed. This allows the general first verification function to be configured as a second verification function specific to the first message being transmitted, thereby improving the code reusability of the first verification function and reducing the maintenance cost of the E2E diagnostic function.
[0019] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this disclosure. Attached Figure Description
[0020] Figure 1 This is a block diagram illustrating a vehicle in an exemplary embodiment of this application; Figure 2 This is a flowchart illustrating a message verification method in another exemplary embodiment of this application; Figure 3 This is a flowchart illustrating a message verification method in another exemplary embodiment of this application; Figure 4 This is a block diagram illustrating a message verification device in an exemplary embodiment of this application; Figure 5 This is a block diagram illustrating an exemplary embodiment of the electronic control unit of this application. Detailed Implementation
[0021] To make the technical solution and advantages of this application clearer, the embodiments of this application will be described in further detail below.
[0022] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0023] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0024] Please refer to Figure 1 This document illustrates a block diagram of a vehicle, representing an exemplary embodiment of this application. The vehicle includes multiple electronic control units (ECUs) capable of communicating via a CAN (Controller Area Network) bus. For example, a first ECU 101 transmits a first message to a second ECU 102 via the CAN bus. Upon receiving the first message, the second ECU 102 verifies the message using an end-to-end (E2E) mechanism. Only after successful verification does it execute the corresponding instruction. Similarly, the second ECU 102 transmits the first message to the first ECU 101 via the CAN bus. Upon receiving the first message, the first ECU 101 verifies the message using an E2E mechanism. Only after successful verification does it execute the corresponding instruction.
[0025] Multiple electronic control units (ECUs) include those for the powertrain, chassis, body, and infotainment systems. The powertrain ECUs include the engine control unit (ECU) and transmission control unit (TCU). The engine control unit assists in controlling and managing engine operation, including fuel, fuel supply, ignition, idling, and emissions. The transmission control unit assists in controlling the shift logic and speed matching of automatic or manual transmissions. In the case of an electric vehicle, the powertrain ECUs also include a battery management unit, a charging control unit, and a motor control unit.
[0026] The chassis system's electronic control units include the anti-lock braking system control unit, the vehicle stability control unit, and the electronically controlled suspension unit. The anti-lock braking system control unit controls the anti-lock braking system to ensure vehicle stability during emergency braking. The vehicle stability control unit controls vehicle driving stability to prevent loss of control. The electronically controlled suspension unit adjusts suspension damping or height parameters according to operating conditions.
[0027] The electronic control units of the vehicle body system include the body control unit, the climate control unit, the airbag control unit, and the seat control unit. The body control unit is used to comprehensively control the vehicle's electrical systems, including door locks, lighting, and windshield wipers. The climate control unit controls the interior temperature, fan speed, and air circulation. The airbag control unit controls the airbag system and triggers safety protection. The seat control unit is responsible for adjusting the position, heating, and ventilation of the power seats.
[0028] The electronic control units for the comfort system include the instrument panel control unit, the navigation system control unit, and the on-board diagnostic control unit. The instrument panel control unit controls the instrument cluster display and infotainment system output. The navigation system control unit is responsible for navigation route planning and voice prompts. The on-board diagnostic control unit monitors the performance of the entire vehicle system, triggering alarms and storing fault codes when malfunctions occur.
[0029] It should be noted that the first electronic control unit 101 and the second electronic control unit 102 are any two of the control units mentioned above.
[0030] Please refer to Figure 2 This document illustrates a flowchart of a message verification method according to an exemplary embodiment of this application. The method is applied to a vehicle containing multiple electronic control units (ECUs). The executing entity of the method can be an ECU in the vehicle used to receive a first message; for example, if a second ECU sends a first message to a first ECU, the executing entity can be the first ECU; similarly, if the first ECU sends a first message to a second ECU, the executing entity can be the second ECU. (See reference...) Figure 2 The method includes: Step 201: Determine the first message transmitted between the first electronic control unit and the second electronic control unit.
[0031] The first message can be a message transmitted from the first electronic control unit to the second electronic control unit, or a message transmitted from the second electronic control unit to the first electronic control unit. The first message includes at least one byte of content, and also includes a second checksum for each byte of content.
[0032] Step 202: Determine the message type of the first message, and based on the message type of the first message, determine the verification requirement information of the first message. The verification requirement information is used to characterize the requirement to verify the first message.
[0033] The message type can be at least one of the following: periodic message type, event-driven message type, diagnostic message type, network management message type, calibration message type, and request-response command message type. When the message type is a periodic message type, the first message is used to provide continuous real-time vehicle status information. When the message type is an event-driven message type, the first message can be a message for controlling the door open / close state, a message for controlling the light switch state, or a message corresponding to a user button command, etc.
[0034] When the message type is a diagnostic message, the first message is used to perform fault diagnosis, parameter configuration, and software flashing operations on the second electronic control unit (or the first electronic control unit). When the message type is a network management message, the first message is used to coordinate the sleep, wake-up, and state synchronization of other electronic control units in the network to achieve low-power management of the entire vehicle; for example, coordinating the electronic control units to enter sleep mode after the vehicle is turned off; waking up the electronic control units after the vehicle is unlocked.
[0035] When the message type is a calibration message, the first message is used for reading, modifying, and detecting the internal operating parameters of the electronic control unit between the host computer calibration software and the electronic control unit. When the message type is a request-response command message, the first message is a command request message; or, the first message is a command response message.
[0036] The verification requirement information can be a message verification type, which can be a cyclic redundancy check (CRC) check, message acknowledgment, or timestamp check, etc. In one possible implementation, the correspondence between message types and verification requirement information is stored in advance; accordingly, the step of determining the verification requirement information of the first message based on its message type can be: obtaining the verification requirement information of the first message from the correspondence between message types and verification requirement information based on the message type of the first message.
[0037] In another possible implementation, different message types of different electronic control units correspond to different verification requirement information, and the correspondence between the unit identifier of the first electronic control unit, the unit identifier of the second electronic control unit, the message type, and the verification requirement information is stored in advance; accordingly, the step of determining the verification requirement information of the first message based on the message type of the first message can be: based on the unit identifier of the first electronic control unit, the unit identifier of the second electronic control unit, and the message type, the verification requirement information of the first message is obtained from the correspondence between the unit identifier of the first electronic control unit, the unit identifier of the second electronic control unit, the message type, and the verification requirement information.
[0038] Step 203: Determine the verification parameters corresponding to the first message based on the verification requirement information of the first message.
[0039] When the verification requirement is CRC checksum, the verification parameters can be bit width, generator polynomial, initial value, input inversion flag, and output inversion and final XOR value. Bit width refers to the length of the generated CRC checksum. Generator polynomial is the polynomial used to generate the CRC checksum. Initial value refers to the starting value of the shift register. Input inversion flag is used to indicate whether the bit order of each input byte is reversed. Output inversion and final XOR value is the final processing of the CRC checksum before output: first, the entire bit order is reversed, and then XORed with a fixed value to calibrate the output.
[0040] When the verification requirement is a timestamp, the verification parameters can be the number of check bits and the numerical range. The number of check bits is the number of digits in the timestamp, and it must be purely numeric with a length that meets mainstream precision requirements. The numerical range limits the timestamp to a reasonable range, with the lower limit typically set to no earlier than 1980 and the upper limit to the current system timestamp, to avoid invalid values that are too large or too small.
[0041] When the verification requirement information is message confirmation, the verification parameters include the unit identifier of the electronic control unit, the message integrity confirmation algorithm, and the message sequence number. The message integrity confirmation algorithm can be a hash value algorithm.
[0042] Step 204: Based on the verification parameters, configure the general first verification function to obtain the second verification function specific to the first message.
[0043] The verification parameters in the general first verification function are default parameters; in this embodiment, the verification parameters of the first verification function are modified to the verification parameters corresponding to the first message, resulting in a second verification function specific to the first message.
[0044] Multiple first verification functions can be stored in advance; different first verification functions are used to implement different verification functions; before this step, the first verification function needs to be selected, which can be done as follows: Based on the verification requirement information of the first message, a first verification function matching the verification requirement information is obtained from the set of verification functions. For example, if the verification requirement information is CRC check, the first verification function corresponding to CRC check is obtained; if the verification requirement information is message acknowledgment, the first verification function corresponding to message acknowledgment is obtained; if the verification requirement information is timestamp verification, the first verification function corresponding to timestamp verification is obtained.
[0045] The set of verification functions is equivalent to the E2E protection diagnostic module. The E2E protection diagnostic module includes multiple functional sub-modules, namely CRC verification, message confirmation and timestamp verification. Each functional sub-module is responsible for the implementation of a protection mechanism.
[0046] Different first messages can call the E2E protection diagnostic module and pass different verification parameters according to the message type and verification requirements of the first message. In this way, the E2E protection logic between messages can be uniformly managed and flexibly configured.
[0047] In this embodiment, a set of verification functions is pre-integrated, which includes multiple verification functions. When it is necessary to verify the first message, the first verification function that matches the verification requirement information can be directly obtained from the set of verification functions based on the verification requirement information of the first message. This allows for flexible adaptation to the requirements of different messages and avoids redundant code writing.
[0048] In one possible implementation, as protection mechanisms evolve and requirements change, the general first verification function can be modified and extended without affecting its stability; for example, adding or modifying the functionality of the first verification function. Furthermore, the use of this modular function reduces repetitive development work and facilitates maintenance and upgrades.
[0049] Step 205: Verify the first message using the second verification function.
[0050] In one possible implementation, the second verification function is a CRC verification function. The step of verifying the first message using the second verification function can be implemented through the following steps 2051-2054, including: Step 2051: Determine the byte length of the first message.
[0051] For example, please refer to Figure 3Before determining the byte length of the first message, initialization processing is performed. This initialization includes initializing the message buffer table, initializing the CRC table, initializing the status of the second check function, and clearing the counter. The message buffer table is used to cache messages to be checked; initializing the message buffer table means deleting cached messages from the buffer. The CRC table is used to store the generated first checksum; initializing the CRC table means deleting the first checksum stored in the CRC table. The status of the second check function can be either unchecked or checking; initializing the status of the second check function means updating its status to unchecked. The counter is used to count the bytes of the first message; clearing the counter means resetting the counter to zero.
[0052] For example, please continue to refer to Figure 3 When the length of the first message is zero bytes, the verification function of the second check function and the receiver controller are disabled, thereby saving vehicle energy consumption. The steps to disable the verification function of the second check function and the receiver controller are as follows: set the enable CRC_en corresponding to the verification function of the second check function to 0, and set the enable RC_en corresponding to the receiver controller to 0.
[0053] For example, please continue to refer to Figure 3 Based on the byte length of the first message, assign a value to CRC_Nums of the second verification function, and then determine whether CRC_Nums is zero; if CRC_Nums is zero, disable the verification function of the second verification function and disable the receiver controller; if CRC_Nums is not zero, execute step 2052.
[0054] Step 2052: If the byte length is not zero, read the byte content of each byte in the first message in sequence to obtain at least one byte of content.
[0055] If the byte length is not zero, enable the receive controller; through the receive controller, read the byte content of each byte in the first message sequentially to obtain at least one byte. For example, set the enable RC_en corresponding to the receive controller to 1, and then read the byte content of each byte in the first message sequentially.
[0056] If the byte length is not zero, the second check function is also enabled to determine the first checksum of at least one byte of content. For example, the enable CRC_en corresponding to the second check function is set to 1.
[0057] In this embodiment, the receiving controller is in a closed state when the byte length is zero; it is only set from a closed state to an open state when the node length is not zero, thereby saving vehicle power consumption.
[0058] Step 2053: Determine the first checksum of at least one byte of content.
[0059] If CRC_Nums is not zero, read the first byte content from the first message, determine the first checksum of the first byte content, and then increment the counter i; then read the second byte content from the first message, determine the first checksum of the second byte content, and then increment the counter i again, until i = CRC_Nums.
[0060] After determining the first checksum of each byte of content, mark the first checksum in the first byte of content; for example, add an index to the byte of content, and mark the first checksum in the index.
[0061] Step 2054: Verify the first message based on the first checksum of at least one byte of content and the second checksum carried in the first message.
[0062] Based on the bit position occupied by the second check code carried in the first message, the second check code of each byte of the second message is obtained, and then the first message is verified based on the first check code of at least one byte of the content and the second check code of at least one byte of the content.
[0063] In one possible implementation, the step of verifying the first message based on a first checksum of at least one byte of content and a second checksum carried by the first message can be as follows: For any given byte of content, if the first checksum and the second checksum of that byte are the same, the first message passes verification; if the first checksum and the second checksum of that byte are different, the first message fails verification. Alternatively, For any given byte of content, if the first checksum and the second checksum of the byte of content are the same, the byte of content passes the verification; if the first checksum and the second checksum of the byte of content are different, the byte of content fails the verification; if at least one byte of content passes the verification, the first message passes the verification; if at least one byte of content contains a byte that fails the verification, the first message fails the verification.
[0064] In another possible implementation, the first message is verified in conjunction with the status code; correspondingly, the steps for verifying the first message based on a first checksum of at least one byte of content and a second checksum carried by the first message can be as follows: For any byte content, the first message passes verification if the first status code carried in the first message is the same as the second status code of the first message stored locally, and the first checksum of the byte content is the same as the second checksum of the byte content carried in the first message; otherwise, the first message fails verification if the first status code carried in the first message is different from the second status code of the first message stored locally, or if the first checksum of the byte content is different from the second checksum of the byte content carried in the first message.
[0065] In this embodiment of the application, by verifying the content of each byte of the first message, the accuracy of the verification of the first message can be improved.
[0066] In this embodiment of the application, the first message is verified by combining the status code and the check code, thereby improving the accuracy of the verification of the first message.
[0067] In another possible implementation, when the second verification function is a message acknowledgment function, the step of verifying the first message using the second verification function can be as follows: determining whether the unit identifier of the electronic control unit carried in the first message is the unit identifier of the electronic control unit that sent the first message; determining whether the hash value of the first message is the same as the hash value carried in the first message; determining whether the message sequence number carried in the first message is the same as the theoretical message sequence number of the first message; if the unit identifier of the electronic control unit carried in the first message is the unit identifier of the electronic control unit that sent the first message, and the hash value of the first message is the same as the hash value carried in the first message, and the message sequence number carried in the first message is the same as the theoretical message sequence number of the first message, then the verification of the first message passes; if the unit identifier of the electronic control unit carried in the first message is not the unit identifier of the electronic control unit that sent the first message, or the hash value of the first message is not the same as the hash value carried in the first message, or the message sequence number carried in the first message is not the same as the theoretical message sequence number of the first message, then the verification of the first message fails.
[0068] In another possible implementation, when the second verification function is a timestamp verification function, the step of verifying the first message using the second verification function can be as follows: determine the sending timestamp and receiving timestamp of the first message; if the time difference between the sending timestamp and receiving timestamp is less than or equal to the time difference threshold, the first message passes the verification; if the time difference between the sending timestamp and receiving timestamp is greater than the time difference threshold, the first message fails the verification.
[0069] In another possible implementation, the method further includes: If the verification result of the first message is that the verification fails, the first message is discarded; the verification failure type of the first message is determined, and based on the verification failure type, the recovery measures for the first message are determined; based on the recovery measures, the first message is recovered.
[0070] The verification failure type can be CRC verification failure, message confirmation failure, or timestamp verification failure, etc. In the case of CRC verification failure, the recovery measure is to send a non-acknowledgment response (NAK) to the electronic control unit that sent the first message, notifying the electronic control unit that sent the first message to retransmit the first message.
[0071] In the case of a verification failure type of message confirmation failure, the recovery measure is automatic retransmission; in the case of a verification failure type of timestamp verification failure, the recovery measure is to synchronize the time of the first electronic control unit and the second electronic control unit.
[0072] In another possible implementation, the fault code corresponding to the verification failure type can also be obtained, and the fault code can be returned to the electronic control unit that sent the first message.
[0073] In this embodiment, a robust error detection and recovery mechanism is provided. When E2E protection fails, the system can automatically take corresponding recovery measures or report the fault.
[0074] In this embodiment, the E2E diagnostic function is abstracted into a general first verification function, which enables different messages to call the previously communicated verification function and pass different verification parameters as needed. This allows the general first verification function to be configured as a second verification function specific to the first message being transmitted, thereby improving the code reusability of the first verification function and reducing the maintenance cost of the E2E diagnostic function.
[0075] Please refer to Figure 4 This illustration shows a block diagram of a message verification device according to an exemplary embodiment of this application. The device is applied in a vehicle containing multiple electronic control units, and includes: The first determining module 401 is used to determine the first message transmitted between the first electronic control unit and the second electronic control unit; The second determining module 402 is used to determine the message type of the first message and, based on the message type of the first message, determine the verification requirement information of the first message. The verification requirement information is used to characterize the requirement to verify the first message. The third determining module 403 is used to determine the verification parameters corresponding to the first message based on the verification requirement information of the first message; Configuration module 404 is used to configure the general first verification function based on the verification parameters to obtain the second verification function specific to the first message; The verification module 405 is used to verify the first message using the second verification function.
[0076] In one possible implementation, the verification module 405 is used to determine the byte length of the first message; if the byte length is not zero, read the byte content of each byte in the first message in sequence to obtain at least one byte content; determine a first check code of the at least one byte content; and verify the first message based on the first check code of the at least one byte content and a second check code carried in the first message.
[0077] In another possible implementation, the verification module 405 is configured to verify the first message if, for any byte content, the first status code carried by the first message is the same as the second status code of the first message stored locally, and the first checksum of the byte content is the same as the second checksum of the byte content carried by the first message; and to verify the first message if, for any byte content, the first status code carried by the first message is different from the second status code of the first message stored locally, or the first checksum of the byte content is different from the second checksum of the byte content carried by the first message.
[0078] In another possible implementation, the verification module 405 is used to enable the receiving controller when the byte length is not zero; through the receiving controller, the byte content of each byte in the first message is read sequentially to obtain at least one byte content.
[0079] In another possible implementation, the device further includes: The acquisition module is used to obtain the first verification function that matches the verification requirement information from the set of verification functions based on the verification requirement information of the first message.
[0080] In another possible implementation, the device further includes: The discard module is used to discard the first message if the verification result of the first message fails. The fourth determination module is used to determine the verification failure type of the first message, and based on the verification failure type, determine the recovery measures for the first message; The recovery module is used to recover the first message based on recovery measures.
[0081] In this embodiment, the E2E diagnostic function is abstracted into a general first verification function, which enables different messages to call the previously communicated verification function and pass different verification parameters as needed. This allows the general first verification function to be configured as a second verification function specific to the first message being transmitted, thereby improving the code reusability of the first verification function and reducing the maintenance cost of the E2E diagnostic function.
[0082] It should be noted that the message verification device provided in the above embodiments is only illustrated by the division of the above functional modules when performing message verification. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the electronic control unit can be divided into different functional modules to complete all or part of the functions described above. In addition, the message verification device and the message verification method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.
[0083] Figure 5 This is a schematic diagram of the structure of an electronic control unit provided according to an embodiment of this application.
[0084] Typically, the electronic control unit 500 includes: a main control module 501, a CAN interface 502, a hard-wired input interface 503, and a hard-wired output interface 504. The main control module 501 is connected to the CAN interface 502, the hard-wired input interface 503, and the hard-wired output interface 504, respectively.
[0085] The main control module 501 typically includes a processor and memory. The processor may include one or more processing cores, such as a quad-core processor or a penta-core processor. The processor can be implemented using at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the vehicle's display screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning. The memory may include one or more computer-readable storage media, which may be non-transitory. The memory may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, a non-transitory computer-readable storage medium in the memory is used to store at least one computer program, which is executed by a processor to implement the message verification method provided in the method embodiments of this application.
[0086] The CAN interface 502 may include a powertrain CAN interface, a motor CAN interface, and a diagnostic CAN interface. The powertrain CAN interface is used to communicate with the vehicle's powertrain module, the motor CAN interface is used to communicate with the vehicle's motor controller, and the diagnostic CAN interface is used to communicate with diagnostic equipment.
[0087] The hard-wired input interface 503 is used to receive hard-wired control signals. The hard-wired output interface 504 is used to send control commands to the vehicle's electronic control components, causing them to perform corresponding actions. These electronic control components include a power management system, a motor controller, an on-board charger, and a body control system.
[0088] The main control module 501 can communicate with the vehicle's powertrain module, motor controller, and diagnostic equipment via the CAN interface 502, and generate control commands based on the hard-wired control signals received by the hard-wired input interface 503, so as to send the control commands to the vehicle's electronic control components via the hard-wired output interface 504.
[0089] Those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on the electronic control unit 500, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.
[0090] This application also provides a computer-readable storage medium storing at least one piece of program code, which is loaded and executed by a processor to implement the message verification method of any of the above implementations. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage device.
[0091] This application also provides a computer program product that stores at least one piece of program code, which is loaded and executed by a processor to implement the message verification method shown in the above embodiments.
[0092] In some embodiments, the computer program product involved in this application may be deployed on an electronic control unit for execution, or executed on multiple electronic control units located in one location, or executed on multiple electronic control units distributed in multiple locations and interconnected through a communication network. Multiple electronic control units distributed in multiple locations and interconnected through a communication network may form a blockchain system.
[0093] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.
[0094] The above is merely for the purpose of enabling those skilled in the art to understand the technical solution of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application shall be included within the protection scope of this application.
Claims
1. A message verification method, characterized in that, The method is applied to a vehicle containing multiple electronic control units, and the method includes: Determine the first message transmitted between the first electronic control unit and the second electronic control unit; The message type of the first message is determined, and based on the message type of the first message, the verification requirement information of the first message is determined, wherein the verification requirement information is used to characterize the requirement to verify the first message. Based on the verification requirement information of the first message, determine the verification parameters corresponding to the first message; Based on the verification parameters, the general first verification function is configured to obtain the second verification function specific to the first message; The first message is verified using the second verification function.
2. The method according to claim 1, characterized in that, The step of verifying the first message using the second verification function includes: Determine the byte length of the first message; If the byte length is not zero, the byte content of each byte in the first message is read sequentially to obtain at least one byte of content; Determine the first checksum of the at least one byte of content; The first message is verified based on the first checksum of the at least one byte of content and the second checksum carried in the first message.
3. The method according to claim 2, characterized in that, The verification of the first message based on the first checksum of the at least one byte of content and the second checksum carried in the first message includes: For any byte content, if the first status code carried by the first message is the same as the second status code of the first message stored locally, and the first checksum of the byte content is the same as the second checksum of the byte content carried by the first message, then the first message passes the verification. If the first status code carried by the first message is different from the second status code of the first message stored locally, or if the first checksum of the byte content is different from the second checksum of the byte content carried by the first message, the verification of the first message fails.
4. The method according to claim 2, characterized in that, When the byte length is not zero, the byte content of each byte in the first message is read sequentially to obtain at least one byte of content, including: If the length of the byte is not zero, the receiver controller is activated; The receiving controller sequentially reads the byte content of each byte in the first message to obtain at least one byte of content.
5. The method according to claim 1, characterized in that, The method further includes: Based on the verification requirement information of the first message, a first verification function matching the verification requirement information is obtained from the set of verification functions.
6. The method according to any one of claims 1-5, characterized in that, The method further includes: If the verification result of the first message is that the verification fails, the first message is discarded; Determine the verification failure type of the first message, and based on the verification failure type, determine the recovery measures for the first message; Based on the recovery measures, the first message is recovered.
7. A message verification device, characterized in that, The device is used in a vehicle that includes multiple electronic control units, and the device includes: The first determining module is used to determine the first message transmitted between the first electronic control unit and the second electronic control unit; The second determining module is used to determine the message type of the first message and, based on the message type of the first message, determine the verification requirement information of the first message, wherein the verification requirement information is used to characterize the requirement to verify the first message. The third determining module is used to determine the verification parameters corresponding to the first message based on the verification requirement information of the first message; The configuration module is used to configure the general first verification function based on the verification parameters to obtain the second verification function specific to the first message; The verification module is used to verify the first message using the second verification function.
8. An electronic control unit, characterized in that, The electronic control unit includes a main control module, which includes a processor and a memory. The memory stores at least one piece of program code, which is loaded and executed by the processor to implement the message verification method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the message verification method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, The product stores at least one piece of program code, which is executed by a processor to implement the message verification method as described in any one of claims 1 to 6.