Message verification method and device and vehicle

Abstract

The invention relates to a message verification method and device and a vehicle, relates to the technical field of hardware-in-the-loop testing, and aims to solve the problem of difference between original data of a bottom layer of a controller and data processed by an application layer. The method comprises the following steps: acquiring message description information corresponding to a target message sent by a controller in a hardware-in-the-loop test process of the controller; determining whether the message description information comprises target information or not; wherein the target information is used for indicating the data bit without the signal value in the target message. And under the condition that the message description information does not comprise the target information, generating the target information. And updating the target information to the message description information. And the updated message description information is utilized to perform message verification on the target message, so that the problem of data difference between a bottom layer and an application layer can be solved, and the efficiency and reliability of system development are improved.

Description

Technical Field

[0001] This application relates to the field of hardware-in-the-loop testing technology, specifically to a message verification method, device, and vehicle. Background Technology

[0002] Hardware-in-the-loop (HIL) testing is a high-level simulation technique widely used in the development of control systems and embedded systems. Its essence is to construct a highly realistic virtual environment, enabling control algorithms to be fully verified without actual hardware, thereby significantly reducing testing costs and shortening development cycles. In this system, the controller, as the core unit, has internal verification algorithms that are crucial for ensuring the integrity and reliability of data transmission.

[0003] However, as system complexity increases, verifying the verification algorithm becomes more complex, and current data acquisition methods face significant challenges. The core issue lies in the discrepancy between the raw data emitted from the controller's underlying layer and the data processed by the application layer when acquiring data from within the controller. This inconsistency can cause deviations in the performance of the verification algorithm between simulation environments and real-world applications, thus affecting the accuracy of the verification results.

[0004] Therefore, ensuring the consistency and integrity of data during cross-level transmission is of great significance for improving the reliability and accuracy of HIL testing. Summary of the Invention

[0005] This application provides a message verification method, apparatus, and vehicle that can solve the problem of data discrepancies between the underlying and application layers, thereby improving the efficiency and reliability of system development.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows: According to a first aspect of this application, a message verification method is provided. The method includes: during hardware-in-the-loop testing of a controller, obtaining message description information corresponding to a target message sent by the controller; determining whether the message description information includes target information, wherein the target information is used to indicate data bits in the target message that have no signal value; if the message description information does not include target information, generating target information; updating the message description information with the target information; and performing message verification on the target message using the updated message description information.

[0007] Based on the aforementioned technical means, this application accurately identifies a potential key defect in the message description information—namely, the lack of explicit definitions for data bits that do not carry specific signal values ​​(such as reserved bits, padding bits, alignment bits, etc.)—by determining whether the message description information includes target information. This deficiency is one of the root causes of discrepancies between the underlying raw data and the application layer parsed data. By actively checking whether the message description information includes target information, a decision-making basis is provided for subsequent message description information updates. Subsequently, when it is determined that the message description information is incomplete, the missing target information is dynamically generated. The generated target information can clearly identify invalid regions in the message that do not carry specific signal values, thereby distinguishing these regions from valid regions that carry actual signal values ​​during subsequent verification, ensuring the consistency between the data bit definition and the actual situation at the controller's underlying layer from the source. Finally, verification is performed based on complete message description information containing explicit definitions of invalid data bits. The verification logic can accurately compare the data processed by the application layer with the original data sent by the controller's underlying layer. The verification algorithm ignores differences in bits marked as having no signal values ​​and only focuses on the consistency of valid signal data bits. This greatly improves the accuracy of verification, as well as the efficiency and reliability of system development.

[0008] In one possible approach, generating target information includes: determining the message length of the target message and the signal start bit and signal length of each signal in the target message based on message description information; determining a first target array based on the message length, wherein each data item in the first target array is identified by a first identifier, which indicates that it is unoccupied; determining the target data item corresponding to each signal in the first target array based on the signal start bit and signal length of each signal; updating the identifier of the target data item to a second identifier, which indicates that it is occupied; and generating target information based on the data item corresponding to the first identifier in the updated first target array.

[0009] Based on the aforementioned technical means, the message length defines the boundary of the entire data field; the signal start bit and signal length precisely describe the position and occupied space of each valid signal in the data field. In this application, the message data bit space is transformed into a concrete, programmable array model. Each data item in the array corresponds to a data bit. The array is initialized entirely to unoccupied (e.g., represented by 0 or False), effectively creating a complete and clean bit map, preparing for subsequent bit-occupancy operations. Then, based on the information extracted in the first step, all positions already occupied by valid signals are accurately marked on the blank array created in the second step. Then, the identifiers of all data items occupied by signals are changed from unoccupied to occupied (e.g., represented by 1 or True). At this point, the entire array is clearly divided into two types of regions: valid signal bits marked with the second identifier and unoccupied bits still marked with the first identifier. Finally, all data items that still retain the first identifier (unoccupied) (i.e., their corresponding bit positions) are determined; these positions are the data bits in the message that do not carry valid signals. Based on the data items corresponding to the first identifier, target information is generated, providing a reliable basis for subsequent verification.

[0010] In one possible approach, based on the signal start bit and signal length of each signal, the target data item corresponding to each signal in the first target array is determined, including: for each target signal in the signals, determining the first data item index corresponding to the signal start bit of the target signal; determining the second data item index corresponding to the target signal bit based on the bit difference between the target signal bit and the signal start bit in the target signal and the first data item index; and determining the target data item corresponding to the target signal bit based on the second data item index.

[0011] Based on the aforementioned technical means, this application first locates the starting position of the target signal within the entire message data field (signal start bit) and determines its corresponding index number in the first target array (first data item index). This index becomes a reference point or coordinate origin, and all subsequent positioning calculations for bits within this signal will be based on it. This ensures the accuracy of positioning and avoids the tediousness and potential errors of calculating from the message start position. Furthermore, the bit difference indicates the relative position of the target signal bit within the signal, and the first data item index provides the absolute starting position of the signal in the message. Based on the bit difference and the first data item index, the precise index of the target signal bit in the global message bitmap can be obtained. This method decomposes the complex global positioning problem into a simple reference lookup and relative offset calculation, with clear logic and high computational efficiency. Finally, using the calculated second data item index, the corresponding data item is directly locked in the first target array. This data item represents the specific physical data bit corresponding to the target signal bit.

[0012] In one possible approach, determining the target data item corresponding to the target signal bit based on the second data item index includes: determining a first sum value between the second data item index and 1; determining the byte corresponding to the target signal bit by combining the first sum value with the number of bits contained in each byte; wherein one byte occupies one row in the first target array; determining whether the target signal bit spans multiple rows based on the byte; and determining the target data item corresponding to the target signal bit based on whether the target signal bit spans multiple rows.

[0013] In one possible approach, target information is generated based on the data items corresponding to the first identifier in the updated first target array, including: merging the data items corresponding to the first identifier according to a preset rule to obtain at least one data block; wherein the preset rule includes: the data items in the data block are consecutive. Target information is then generated based on at least one data block.

[0014] Based on the above technical means, this application can merge a large number of discrete data items into continuous interval blocks based on preset rules (continuity rules), and then generate target information based on at least one data block for use by subsequent verification algorithms.

[0015] In one possible approach, the preset rules include: the data items in the data block are continuous, and the number of data items in the data block does not exceed a preset threshold.

[0016] In one possible approach, the target information includes a description of the starting data item index value and the number of data items for each data block in at least one data block.

[0017] In one possible approach, obtaining message description information corresponding to the target message sent by the controller includes: obtaining message description information corresponding to the message type of the target message from a database file; wherein the database file includes message description information corresponding to each of the multiple message types sent by the controller.

[0018] Based on the above technical means, this application can quickly and accurately obtain the message description information corresponding to the message type of the target message from the database file.

[0019] In one possible approach, message description information corresponding to the target message is obtained from a database file, including: determining the controller's node number; and searching the database file for message description information matching the message type and node number; wherein the database file includes message description information corresponding to each combination of multiple message types and sender node numbers sent by the controller.

[0020] Based on the above technical means, this application can search for the message description information corresponding to the message type of the target message from the database file based on the message type and node number, which can ensure the accuracy of the message description information.

[0021] In one possible approach, message verification of the target message is performed using the updated message description information, including: determining a first message verification code based on the updated message description information; obtaining a second message verification code sent by the controller; and determining that the message verification has passed if the first and second message verification codes match. The first and second message verification codes are generated using the same message verification algorithm.

[0022] Based on the aforementioned technical means, this application calculates a first message checksum based on the updated message description information. This first checksum represents the correct checksum that, under ideal conditions, should be generated solely from all valid signal data (ignoring padding bits, reserved bits, etc.). The second message checksum is independently calculated by the HIL system using the same checksum algorithm based on the received original message data. If the first and second message checksums are consistent, it proves that all valid signal data that needs to be protected in the message data sent by the controller completely matches the result expected by the application layer and calculated based on the updated description information. This indicates that no bit errors occurred during the process from the controller's underlying layer to the completion of message construction, and the integrity and reliability of the message are verified. Through this scheme, accurate and reliable integrity verification of the controller's communication behavior in HIL testing is achieved, greatly improving the overall quality and efficiency of HIL testing.

[0023] According to a second aspect provided in this application, a message verification device is provided, the device comprising: an acquisition unit, a determination unit, a generation unit, a processing unit, and a verification unit.

[0024] The acquisition unit is used to acquire message description information corresponding to the target message sent by the controller during the hardware-in-the-loop test of the controller.

[0025] The determining unit is used to determine whether the message description information includes target information; wherein the target information is used to indicate data bits in the target message that have no signal value.

[0026] The generation unit is used to generate target information when the target information is not included in the message description information.

[0027] The processing unit is used to update the target information into the message description information.

[0028] The verification unit is used to verify the target message using the updated message description information.

[0029] In one possible implementation, the generation unit includes a first determining subunit, a second determining subunit, a third determining subunit, a first processing subunit, and a generation subunit. The first determining subunit is used to determine the message length of the target message and the signal start bit and signal length of each signal in the target message based on message description information. The second determining subunit is used to determine a first target array based on the message length; wherein the identifier of each data item in the first target array is a first identifier; the first identifier indicates that it is unoccupied. The third determining subunit determines the target data item corresponding to each signal in the first target array based on the signal start bit and signal length of each signal. The first processing subunit is used to update the identifier of the target data item to a second identifier; wherein the second identifier indicates that it is occupied. The generation subunit is used to generate target information based on the data item corresponding to the first identifier in the updated first target array.

[0030] In one possible approach, the third determining subunit is specifically used to determine, for each target signal in the signals, the first data item index corresponding to the signal start bit of the target signal; based on the bit difference between the target signal bit and the signal start bit in the target signal and the first data item index, determine the second data item index corresponding to the target signal bit; and based on the second data item index, determine the target data item corresponding to the target signal bit.

[0031] In one possible approach, the third determining subunit is further configured to determine a first sum value between the index of the second data item and 1. The first sum value and the number of bits contained in each byte are used to determine the byte corresponding to the target signal bit; wherein one byte occupies one row in the first target array. Based on the byte, it is determined whether the target signal bit spans multiple rows. Based on whether the target signal bit spans multiple rows, the target data item corresponding to the target signal bit is determined.

[0032] In one possible approach, a sub-unit is generated, specifically used to merge data items corresponding to a first identifier according to a preset rule to obtain at least one data block; wherein the preset rule includes: data items in the data block are continuous. Target information is generated based on at least one data block.

[0033] In one possible approach, the acquisition unit is specifically used to acquire message description information corresponding to the message type of the target message from a database file; wherein the database file includes message description information corresponding to each of the multiple message types sent by the controller.

[0034] In one possible approach, the acquisition unit includes a fourth determining subunit and a searching subunit. The fourth determining subunit is used to determine the node number of the controller. The searching subunit is used to search a database file for message description information that matches the message type and node number; wherein the database file includes message description information corresponding to each combination of multiple message types and message sender node numbers sent by the controller.

[0035] In one possible implementation, the verification unit includes a fifth determining subunit, an acquiring subunit, and a sixth determining subunit. The fifth determining subunit determines a first message checksum based on the updated message description information. The acquiring subunit acquires a second message checksum sent by the controller. The sixth determining subunit determines that the message verification is successful if the first and second message checksums match. The first and second message checksums are generated using the same message verification algorithm.

[0036] According to the third aspect provided in this application, a vehicle is provided, which is equipped with the message verification device of the second aspect described above.

[0037] According to a fourth aspect provided in this application, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions. The processor is configured to execute instructions to implement the message verification method of the first aspect and any possible implementation thereof.

[0038] According to the fifth aspect provided in this application, a computer-readable storage medium is provided, which, when the instructions in the computer-readable storage medium are executed by the processor of an electronic device, enables the electronic device to perform the message verification method of the first aspect and any possible implementation thereof.

[0039] According to the sixth aspect provided in this application, a computer program product is provided, the computer program product including computer instructions, which, when executed on an electronic device, cause the electronic device to perform the message verification method of the first aspect and any possible implementation thereof.

[0040] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0041] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the structure of a message verification system provided in an embodiment of this application; Figure 2 This is a schematic diagram of another message verification system provided in an embodiment of this application; Figure 3 A flowchart illustrating a message verification method provided in an embodiment of this application; Figure 4This is a schematic diagram of the structure of a first target data provided in an embodiment of this application; Figure 5 A flowchart illustrating another message verification method provided in this application embodiment; Figure 6 A flowchart illustrating another message verification method provided in this application embodiment; Figure 7 This is a schematic diagram of the structure of a message verification device provided in an embodiment of this application; Figure 8 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0044] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0045] In the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0046] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0047] like Figure 1 As shown in the figure, a message verification system provided in this application embodiment includes: a hardware-in-the-loop test bench 101 and a controller 102, and the hardware-in-the-loop test bench 101 and the controller 102 are communicatively connected.

[0048] Among them, such as Figure 2As shown, the controller 102 may include a body domain controller (BDC), body control module (BCM), seat control unit (SCU), vehicle control unit (VCU), integrated thermal management system (ITMS), and battery management system (BMS) deployed in the vehicle 100, etc., which are not limited in this application.

[0049] In some embodiments, firstly, according to the HIL simulation structure for new energy vehicles, the controller 102 under test is connected to a hardware-in-the-loop test bench 101 simulating its working environment via wiring harnesses to build a HIL test environment. In the HIL test environment, the hardware-in-the-loop test bench 101 can send a wake-up signal to the controller 102 to determine whether the controller 102 can normally send and receive messages. If a signal is received from the controller 102 within a preset time, the hardware-in-the-loop test bench 101 can determine that the controller 102 can normally send and receive messages; if no signal is received from the controller 102 within the preset time, the hardware-in-the-loop test bench 101 can determine that the controller 102 cannot normally send and receive messages.

[0050] In some embodiments, if it is determined that the controller 102 can normally send and receive messages, the hardware-in-the-loop test bench 101 can perform a HILL test on the controller 102. During the HILL test on the controller 102, the hardware-in-the-loop test bench 101 can receive the target message sent by the controller 102 and obtain the message description information corresponding to the target message from the database file. Then, the hardware-in-the-loop test bench 101 can determine whether the message description information includes target information, wherein the target information is used to indicate data bits with no signal value in the target message. If the message description information does not include target information, the hardware-in-the-loop test bench 101 can generate target information and update the message description information with the target information.

[0051] Subsequently, the hardware-in-the-loop test bench 101 can use the updated message description information to convert the target message, obtain the corresponding digital signal, and verify the corresponding digital signal to obtain the first message checksum. Then, the hardware-in-the-loop test bench 101 can compare the first message checksum with the second message checksum in the target message. If the first and second message checksums match, the message verification is deemed successful; if they do not match, the message verification is deemed unsuccessful, indicating that the test is unqualified, and corresponding optimization operations (such as optimizing the test software) are required based on the verification results.

[0052] The message verification method provided in this application can be applied to vehicles. Vehicles can also be referred to as vehicles, mobile carriers, electric vehicles (EVs), hybrid electric vehicles (HEVs), plug-in hybrid electric vehicles (PHEVs), fuel cell vehicles (FCVs), autonomous vehicles, intelligent and connected vehicles (ICVs), driverless vehicles, etc.

[0053] In this application, the vehicle can be a sedan, a sport utility vehicle (SUV), a truck, an electric vehicle, a motorcycle, a tricycle, a special vehicle (such as an ambulance, fire truck, police car, etc.), a driverless taxi, an intelligent connected bus, an autonomous logistics vehicle, an electric truck, etc. Furthermore, this method is also applicable to various special-purpose vehicles, such as agricultural vehicles, mining vehicles, forestry vehicles, airport vehicles, and port vehicles. This application does not impose specific limitations in this regard.

[0054] For ease of understanding, the message verification method provided in this application will be described in detail below with reference to the accompanying drawings.

[0055] like Figure 3 As shown in the embodiment of this application, a message verification method includes: S301. During the hardware-in-the-loop test of the controller, obtain the message description information corresponding to the target message sent by the controller.

[0056] In some embodiments, the hardware-in-the-loop test bench (hereinafter referred to as the HILL bench) can obtain message description information corresponding to the message type of the target message from a database file.

[0057] The database file includes message description information corresponding to each of the multiple message types sent by the controller.

[0058] In this embodiment, the database file is a data file used to describe communication data on the vehicle network. The database file may include, but is not limited to, Controller Area Network (CAN) database container (DBC) files, ARXML files, LDF files, and Field Bus Exchange Format (FIBEX) files. Specifically, the DBC file is the de facto standard description file for the CAN bus, using specific syntax rules to define nodes, messages, signals, and their attributes in the CAN network; the ARXML file is applicable to various vehicle networks (CAN, LIN, and Ethernet, etc.) and can be used to describe all communication information such as frames, signals, and encodings of buses like CAN and LIN; the LDF file is a standardized file used to describe LIN networks, describing nodes, frames (or messages), signals, scheduling tables, and node configuration information in the LIN network; and the FIBEX file is used to describe various automotive bus networks, such as CAN, LIN, FlexRay, and Ethernet, and is a more general and comprehensive network description file format.

[0059] The message description information may include, but is not limited to: the names of all controller nodes on the vehicle network corresponding to the database file, the message (message identification (ID), message name, message data length, and message sender node number), the signal (signal name, signal start bit, signal length, value type, and list of controller nodes receiving the signal), and the signal value description (mapping the special values ​​of the signal into meaningful descriptions, often used for enumerating type signals), etc., which are not limited in this application. CAN messages, LDF messages, FlexRay messages, and Ethernet messages may correspond to different database files, and each type of message has its own corresponding message description information.

[0060] For example, the HILL platform can determine the node number of the controller and search for message description information that matches the message type and node number in a database file. The database file includes message description information corresponding to each combination of multiple message types sent by the controller and the message sender node number.

[0061] For example, taking a CAN message as the target message and a DBC file as the database file, the DBC file corresponds to the CAN message, meaning it can be used to describe / parse the CAN message. In this case, the HILL test bench can obtain the node to which the target message belongs to determine which controller node the target message originated from, thus obtaining the node number of the controller corresponding to the target message. Then, the HILL test bench can search the DBC file for a node number that matches the node number. If a node number matching the target message's node number exists in the DBC file, the operations in S302-S305 below are executed.

[0062] If no matching node number is found in the DBC file, the HILL test bench can directly use the DBC file to convert the CAN message to obtain the corresponding digital signal, and then use the corresponding digital signal for subsequent HILL testing.

[0063] S302. Determine whether the message description information includes target information.

[0064] The target information is used to indicate data bits in the target message that have no signal value. Generally, data bits in a message that are not occupied or used by any signal definition are usually called padding bits. However, the original database file did not describe or define these padding bits. This application generates target information about these padding bits and updates the target information to the message description information corresponding to the target message in the database file.

[0065] In some embodiments, the HILL rack can determine the message description information corresponding to the target message from the database file, and then determine whether the message description information stores the target information, that is, whether the message description information contains the description information corresponding to the padding bits in the target message.

[0066] S303. If the target information is not included in the message description information, generate the target information.

[0067] In an optional implementation, if the target information is not included in the message description information, the target information can be generated through the following steps 1-4.

[0068] Step 1: Based on the message description information, determine the message length of the target message and the signal start bit and signal length of each signal in the target message.

[0069] In some embodiments, the message description information defines the message length of each message in multiple messages and the information of each signal in each message (such as the signal start bit and signal length). Based on this, the HILL rack can query the message description information to find messages that match the message ID and the node to which the target message belongs, and then determine the message length of the target message and the signal start bit and signal length of each signal in the target message.

[0070] Step 2: Determine the first target array based on the message length.

[0071] In this array, each data item in the first target array is identified by the first identifier, which indicates that it is not occupied.

[0072] In some embodiments, the HILL platform can generate a first target array with the same length as the message, and set the identifier of each data item in the first target array to the first identifier.

[0073] For example, assuming the target message is a Controller Area Network with Flexible Data Rate (CANFD) message, the message length (also known as the data field length) of a CANFD message is typically 512 bits. Based on this, the HILL test bench can generate a first target array with 512 data items. In this first target array, the first identifier of each data item is 0, indicating that the current position of that data item is not occupied.

[0074] Step 3: Based on the signal start bit and signal length of each signal, determine the target data item corresponding to each signal in the first target array.

[0075] In some embodiments, for a target signal among the signals, the HILL test bench can determine the first data item index corresponding to the signal start bit of the target signal. Then, based on the bit difference between the target signal bit and the signal start bit in the target signal and the first data item index, a second data item index corresponding to the target signal bit can be determined, and based on the second data item index, the target data item corresponding to the target signal bit can be determined.

[0076] In one example, the HILL bench can determine a first sum between the index of the second data item and 1, and use this first sum and the number of bits contained in each byte to determine the byte corresponding to the target signal bit. Then, based on the byte, it determines whether the target signal bit spans a row, and based on whether the target signal bit spans a row, it determines the target data item corresponding to the target signal bit.

[0077] One byte occupies one row in the first target array.

[0078] Step 4: Update the identifier of the target data item to the second identifier.

[0079] The second identifier indicates that the space is occupied.

[0080] In some embodiments, after determining the target data item corresponding to the target signal bit for each target signal in step three above, the identifier of the target data item can be modified from the first identifier to the second identifier to indicate that the current data item is occupied, while the remaining unoccupied data items can indicate those data bits (also called padding bits) in the target message that are not occupied or used by any signal definition.

[0081] For example, each data item in the initial first target data is first identifier 0. After determining the target data item corresponding to the target signal bit in the first target array, the identifier of the target data item can be changed from first identifier 0 to second identifier 1 to indicate that the data item in the first target array is occupied.

[0082] Step 5: Generate target information based on the data item corresponding to the first identifier in the updated first target array.

[0083] In some embodiments, the HILL platform can merge the data items corresponding to the first identifier according to a preset rule to obtain at least one data block, and then generate target information based on at least one data block.

[0084] The preset rules include: data items in a data block are consecutive, or data items in a data block are consecutive and the number of data items in the data block does not exceed a preset threshold. For example, the preset threshold can be 8, 16, 32, etc., and there is no limitation on it.

[0085] The target information includes a description of the starting data item index value and the number of data items for each data block in at least one data block.

[0086] For example, such as Figure 4 As shown, the first target data is an 8x8 array containing 64 data items. Data items in black correspond to the second identifier (i.e., the data item is occupied), and data items in white correspond to the first identifier (i.e., the data item is not occupied). Assuming a preset threshold of 8, the maximum number of items in each data block will not exceed 8. For example, Figure 4 In the example, the 8 data items in row 4 form one data block; similarly, rows 2, 5, 7, and 8 each form one data block. For example... Figure 4 The two white data items on the far right of the first row form a data block.

[0087] For example, for each data block in at least one data block, target information for the target signal corresponding to that data block can be generated based on the starting data item index value and the number of data items in that data block. That is, one data block corresponds to one target signal.

[0088] The target information includes the target signal's signal length, start bit, signal name, and signal value, etc., which are not limited in this application. The signal length is equal to the number of data items in the data block corresponding to the target signal, the start bit is the same as the starting data item index value of the data block corresponding to the target signal, the signal value can be 0, and the signal name can be generated according to the specification.

[0089] S304. Update the target information to the message description information.

[0090] In some embodiments, the HILL test bench can store the target information corresponding to each signal in a new structure and update the new structure to the message description information in a specific format, thereby updating the database file.

[0091] S305. Use the updated message description information to perform message verification on the target message.

[0092] In some embodiments, the HILL test bench can convert the target message based on the updated message description information to obtain the digital signal corresponding to the target message. Then, it uses a message verification algorithm to calculate the first message checksum corresponding to the digital signal of the target message. Afterward, the HILL test bench obtains the second message checksum of the target message sent by the controller and compares the first and second message checksums. If the first and second message checksums match, the message verification is deemed successful; if they do not match, the message verification is deemed unsuccessful, and the test software needs to be optimized.

[0093] The first and second message check codes are generated using the same message check algorithm.

[0094] Optionally, the message verification algorithm may include parity check, cyclic redundancy check (CRC), redundancy code check, etc., and this application does not limit it.

[0095] Based on the above technical solution, the updated database file can correctly parse the data in the underlying or data structure, ensuring the integrity of the verification data and guaranteeing consistency between the data inside the controller and the data collected externally. This solves the problem of inconsistency between data verification results and controller internal data verification results in HIL testing, improves the accuracy of verification results, and provides data support for the stable transmission of real vehicle data. Furthermore, this method improves the accuracy of data verification results, reduces data analysis time, and greatly enhances testing economy. A script-based automatic completion method for database files (such as DBC files) is proposed and implemented to ensure the collection of underlying data and improve the integrity of data collection and the accuracy of data verification in hardware-in-the-loop testing.

[0096] In an optional implementation, step 3 in S303 above can utilize a signal bit mapping function (such as the GetBit function) to determine the target data item corresponding to each signal in the first target array based on the signal start bit and signal length of each signal, such as... Figure 5 As shown, for the target signal in each signal, the target data item corresponding to the target signal bit is determined based on the signal bit mapping function (GetBit function), which may specifically include: S501. Determine the signal start bit MsgStrBit and signal length MsgLen of the target signal.

[0097] Among them, the index of the first data item corresponding to the signal start bit of the target signal is MsgStrBit.

[0098] S502, set the index of the second data item corresponding to the target signal bit, CurBit, to be equal to the index of the first data item corresponding to the signal start bit, MsgStrBit.

[0099] Among them, the target signal bit is the signal start bit at the beginning. When the target signal bit is the signal start bit, its corresponding second data item index CurBit is equal to MsgStrBit.

[0100] S503, Set the byte corresponding to the target signal bit to Byte= (CurBit+1) / 8 .

[0101] in, The integer symbol (round down). Byte can be used to represent the position of the target signal in the first target array (or matrix), i.e., which row it is in.

[0102] S504, Let BitInByte = CurBit - Byte * 8.

[0103] BitInByte can be used to determine whether the target signal bit spans multiple rows.

[0104] S505. Determine if BitInByte is equal to -1. If yes, proceed to S506. If no, proceed to S507.

[0105] Where BitInByte equals -1, it indicates that the target signal bit spans a row; if BitInByte is not equal to -1, it indicates that the target signal bit spans a row.

[0106] S506, Let CurBit = (Byte-1) * 8 - 8.

[0107] If BitInByte equals -1, it skips to the previous byte.

[0108] S507, Let CurBit = CurBit + 1.

[0109] If BitInByte is not equal to -1, the calculation of CurBit continues in the current Byte.

[0110] S508. Let i=i+1.

[0111] The initial value of i is 0.

[0112] S509. Determine if i is equal to MsgStrBit. If yes, end the process. If no, execute S503.

[0113] Based on the above technical solution, this application achieves the above... Figure 5 The steps in this process can determine the CurBit corresponding to the target signal bit as the target data item corresponding to the target signal bit, providing a basis for the subsequent generation of target information.

[0114] In one optional implementation, the HILL platform can simultaneously receive multiple messages sent by the controller, or receive messages sent by different controllers. Therefore, it is necessary to update the message description information corresponding to each message to obtain an updated database file. For example... Figure 6 As shown, the message verification method provided in this application will be described in detail below with reference to the above embodiments.

[0115] S601. Receive N messages sent by the controller and sort the N messages in the order of receipt.

[0116] S602. Obtain the message ID and the node to which the i-th message belongs among multiple messages.

[0117] The initial value of i is 1.

[0118] S603. Determine if the i-th message exists in the DBC file. If not, proceed to S604. If yes, proceed to S605.

[0119] In some embodiments, the HILL rack can parse the node number defined in the DBC file. If there is a node number in the DBC file that matches the node number (i.e., the node to which the i-th message belongs), then it is determined that the i-th message exists in the DBC file. If there is no node number in the DBC file that matches the node number (i.e., the node to which the i-th message belongs), then it is determined that the i-th message does not exist in the DBC file.

[0120] S604, i = i + 1, then execute S602.

[0121] S605. Obtain the message description information corresponding to the i-th message from the DBC file.

[0122] S606. Based on the message description information, determine the message length of the i-th message and the signal start bit and signal length of each signal in the i-th message.

[0123] S607. Determine the first target array based on the message length of the i-th message.

[0124] S608. Based on the signal start bit and signal length of each signal in the i-th message, determine the target data item corresponding to each signal in the first target array.

[0125] S609. Update the identifier of the target data item to the second identifier.

[0126] S610: Is i greater than N? If yes, end the process; otherwise, execute S604.

[0127] like Figure 7 As shown in the embodiment of this application, a message verification device includes: an acquisition unit 701, a determination unit 702, a generation unit 703, a processing unit 704, and a verification unit 705.

[0128] The acquisition unit 701 is used to acquire the message description information corresponding to the target message sent by the controller during the hardware-in-the-loop test of the controller.

[0129] The determining unit 702 is used to determine whether the message description information includes target information; wherein, the target information is used to indicate data bits in the target message that have no signal value.

[0130] The generation unit 703 is used to generate target information when the target information is not included in the message description information.

[0131] The processing unit 704 is used to update the target information into the message description information.

[0132] The verification unit 705 is used to perform message verification on the target message using the updated message description information.

[0133] In one possible embodiment, the generation unit 703 includes a first determining subunit, a second determining subunit, a third determining subunit, a first processing subunit, and a generation subunit. The first determining subunit is used to determine the message length of the target message and the signal start bit and signal length of each signal in the target message based on message description information. The second determining subunit is used to determine a first target array based on the message length; wherein the identifier of each data item in the first target array is a first identifier; the first identifier indicates that it is unoccupied. The third determining subunit determines the target data item corresponding to each signal in the first target array based on the signal start bit and signal length of each signal. The first processing subunit is used to update the identifier of the target data item to a second identifier; wherein the second identifier indicates that it is occupied. The generation subunit is used to generate target information based on the data item corresponding to the first identifier in the updated first target array.

[0134] In one possible approach, the third determining subunit is specifically used to determine, for each target signal in the signals, the first data item index corresponding to the signal start bit of the target signal; based on the bit difference between the target signal bit and the signal start bit in the target signal and the first data item index, determine the second data item index corresponding to the target signal bit; and based on the second data item index, determine the target data item corresponding to the target signal bit.

[0135] In one possible approach, the third determining subunit is further configured to determine a first sum value between the index of the second data item and 1. The first sum value and the number of bits contained in each byte are used to determine the byte corresponding to the target signal bit; wherein one byte occupies one row in the first target array. Based on the byte, it is determined whether the target signal bit spans multiple rows. Based on whether the target signal bit spans multiple rows, the target data item corresponding to the target signal bit is determined.

[0136] In one possible approach, a sub-unit is generated, specifically used to merge data items corresponding to a first identifier according to a preset rule to obtain at least one data block; wherein the preset rule includes: data items in the data block are continuous. Target information is generated based on at least one data block.

[0137] In one possible approach, the acquisition unit 701 is specifically used to acquire message description information corresponding to the message type of the target message from a database file; wherein, the database file includes message description information corresponding to each of the multiple message types sent by the controller.

[0138] In one possible embodiment, the acquisition unit 701 includes a fourth determining subunit and a searching subunit. The fourth determining subunit is used to determine the node number of the controller. The searching subunit is used to search a database file for message description information that matches the message type and node number; wherein the database file includes message description information corresponding to each combination of multiple message types and message sender node numbers sent by the controller.

[0139] In one possible implementation, the verification unit 705 includes a fifth determining subunit, an acquiring subunit, and a sixth determining subunit. The fifth determining subunit is used to determine a first message verification code based on the updated message description information. The acquiring subunit is used to acquire a second message verification code sent by the controller. The sixth determining subunit is used to determine that the message verification is successful if the first and second message verification codes match. The first and second message verification codes are generated using the same message verification algorithm.

[0140] like Figure 8 As shown in the embodiments of this application, an electronic device includes, but is not limited to, a processor 801 and a memory 802.

[0141] The memory 802 described above is used to store the executable instructions of the processor 801. It is understood that the processor 801 is configured to execute instructions to implement the message verification method in the above embodiments.

[0142] It should be noted that those skilled in the art will understand that Figure 8 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 8 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0143] The processor 801 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 802, and by calling data stored in the memory 802, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 801 may include one or more processing units. Optionally, the processor 801 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 801.

[0144] The memory 802 can be used to store software programs and various data. The memory 802 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 802 may include high-speed random access memory and may also include non-volatile memory. For example, the non-volatile memory may include at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0145] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 802 including instructions, which can be executed by a processor 801 of an electronic device to implement the methods in the above embodiments.

[0146] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0147] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by a processor 801 of an electronic device to perform the methods described above.

[0148] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of an electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0149] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0150] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0151] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0152] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0154] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A message verification method, characterized in that, The message verification method includes: During the hardware-in-the-loop test of the controller, the message description information corresponding to the target message sent by the controller is obtained; Determine whether the message description information includes target information; wherein the target information is used to indicate data bits in the target message that have no signal value; If the target information is not included in the message description information, the target information is generated. Update the target information into the message description information; The target message is verified using the updated message description information.

2. The message verification method according to claim 1, characterized in that, The generation of the target information includes: Based on the message description information, the message length of the target message and the signal start bit and signal length of each signal in the target message are determined; Based on the message length, a first target array is determined; wherein, the identifier of each data item in the first target array is a first identifier; the first identifier indicates that it is not occupied; Based on the signal start bit and signal length of each signal, determine the target data item corresponding to each signal in the first target array; Update the identifier of the target data item to a second identifier; wherein the second identifier indicates occupancy; The target information is generated based on the data item corresponding to the first identifier in the updated first target array.

3. The message verification method according to claim 2, characterized in that, The step of determining the target data item corresponding to each signal in the first target array based on the signal start bit and signal length of each signal includes: For the target signal among the signals, determine the index of the first data item corresponding to the signal start bit of the target signal; Based on the bit difference between the target signal bit and the signal start bit in the target signal and the first data item index, the second data item index corresponding to the target signal bit is determined; Based on the second data item index, the target data item corresponding to the target signal bit is determined.

4. The message verification method according to claim 3, characterized in that, Determining the target data item corresponding to the target signal bit based on the second data item index includes: Determine the first sum value between the index of the second data item and 1; The first summation value and the number of bits contained in each byte are used to determine the byte corresponding to the target signal bit; wherein, one byte occupies one row in the first target array; Based on the bytes, determine whether the target signal bit spans multiple rows; The target data item corresponding to the target signal bit is determined based on whether the target signal bit spans multiple rows.

5. The message verification method according to claim 2, characterized in that, The step of generating the target information based on the data item corresponding to the first identifier in the updated first target array includes: The data items corresponding to the first identifier are merged according to a preset rule to obtain at least one data block; wherein, the preset rule includes: the data items in the data block are continuous; The target information is generated based on the at least one data block.

6. The message verification method according to claim 5, characterized in that, The preset rules include: the data items in the data block are continuous, and the number of data items in the data block does not exceed a preset number threshold.

7. The message verification method according to claim 5, characterized in that, The target information includes a description of the starting data item index value and the number of data items for each data block in the at least one data block.

8. The message verification method according to claim 1, characterized in that, The step of obtaining the message description information corresponding to the target message sent by the controller includes: Obtain the message description information corresponding to the message type of the target message from the database file; The database file includes message description information corresponding to each of the multiple message types sent by the controller.

9. The message verification method according to claim 8, characterized in that, The step of retrieving the message description information corresponding to the target message from the database file includes: Determine the node number of the controller; The database file is searched for message description information that matches the message type and the node number; wherein, the database file includes message description information corresponding to each combination of multiple message types and message sender node numbers sent by the controller.

10. The message verification method according to any one of claims 1-9, characterized in that, The step of performing message verification on the target message using the updated message description information includes: Based on the updated message description information, determine the first message checksum; Obtain the second message verification code sent by the controller; If the first message checksum and the second message checksum are consistent, the message checksum is determined to be valid. The first message verification code and the second message verification code are generated using the same message verification algorithm.

11. A message verification device, characterized in that, The message verification device includes: The acquisition unit is used to acquire message description information corresponding to the target message sent by the controller during the hardware-in-the-loop test of the controller. A determining unit is configured to determine whether the message description information includes target information; wherein the target information is used to indicate data bits in the target message that have no signal value; A generation unit is configured to generate the target information when the target information is not included in the message description information; The processing unit is used to update the target information into the message description information; The verification unit is used to perform message verification on the target message using the updated message description information.

12. A vehicle, characterized in that, The vehicle is equipped with the message verification device as described in claim 11.

Images