Vehicle bus data verification method and device, equipment and storage medium

Abstract

The invention provides a vehicle bus data verification method and device, equipment and a storage medium, and belongs to the technical field of vehicles. The method comprises the steps that bus data are analyzed, an analysis result is obtained, the bus data are data transmitted on a CAN bus of a vehicle, and the analysis result comprises a plurality of signals; based on a plurality of preset keywords, keyword matching is carried out on the analysis result to obtain a matching result, and the matching result comprises at least one to-be-verified signal and the preset keyword matched with each to-be-verified signal; based on the matching result, generating a verification configuration parameter corresponding to each to-be-verified signal; based on the verification configuration parameters, the corresponding to-be-verified signals are verified, verification results are obtained, and the verification results are used for indicating whether each to-be-verified signal is an abnormal signal or not. According to the method, the to-be-verified signal is automatically identified, the verification configuration parameter is automatically generated, and the overall analysis and verification efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, apparatus, device, and storage medium for verifying vehicle bus data. Background Technology

[0002] With the increasing level of vehicle electrification, modern vehicles have integrated a large number of electronic control units (ECUs), which communicate via the CAN (Controller Area Network) bus. Accurate analysis and verification of CAN bus data are crucial during vehicle development and testing.

[0003] Currently, there are various verification algorithms available in the industry. However, the application of these algorithms generally relies on users manually configuring a large number of parameters, including signal definitions, verification method determination, and writing verification scripts adapted for different verification tools. This manual configuration mode is cumbersome and inefficient. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for verifying vehicle bus data, improving overall analysis and verification efficiency. The technical solution is as follows:

[0005] On the one hand, a method for verifying vehicle bus data is provided, the method comprising:

[0006] The bus data is parsed to obtain the parsing result. The bus data is the data transmitted on the vehicle's CAN bus, and the parsing result includes multiple signals.

[0007] Based on multiple preset keywords, keyword matching is performed on the parsing results to obtain matching results. The matching results include at least one signal to be verified and preset keywords matched by each signal to be verified.

[0008] Based on the matching results, generate the verification configuration parameters corresponding to each signal to be verified;

[0009] Based on the verification configuration parameters, the corresponding signals to be verified are verified to obtain verification results. The verification results are used to indicate whether each signal to be verified is an abnormal signal.

[0010] On the other hand, a vehicle bus data verification device is provided, the device comprising:

[0011] The parsing module is used to parse the bus data and obtain the parsing result. The bus data is the data transmitted on the vehicle's CAN bus, and the parsing result includes multiple signals.

[0012] The matching module is used to perform keyword matching on the parsing results based on multiple preset keywords to obtain matching results. The matching results include at least one signal to be verified and preset keywords matched by each signal to be verified.

[0013] The generation module is used to generate verification configuration parameters for each signal to be verified based on the matching results.

[0014] The verification module is used to verify the corresponding signals to be verified based on the verification configuration parameters and obtain the verification result. The verification result is used to indicate whether each signal to be verified is an abnormal signal.

[0015] In some embodiments, the matching module is configured to determine a target message from multiple messages included in the parsing result based on a preset message type, wherein the preset message type includes at least one of a receiving type and a sending type, each message includes at least one signal, and the message type of the target message is the preset message type; and to perform keyword matching on the target message based on the multiple preset keywords to obtain the matching result.

[0016] In some embodiments, the matching module is configured to, for any signal, determine the signal as a signal to be verified if the signal name of the signal includes any preset keyword; and determine the signal as another signal besides the signal to be verified if the signal name of the signal does not include the plurality of preset keywords.

[0017] In some embodiments, the verification configuration parameters include the verification type;

[0018] The generation module is used to determine the verification type corresponding to any preset keyword based on the preset keyword matched by the signal to be verified. The multiple preset keywords each correspond to their own verification type, and different verification types indicate different verification algorithms.

[0019] In some embodiments, the verification configuration parameters include a verification mode;

[0020] The generation module is configured to, for any signal to be verified, determine the length of the message in which the signal to be verified is located; if the length of the message is greater than a preset length threshold, select a first verification mode, wherein the first verification mode indicates segmented verification based on the position of the signal to be verified in the message; if the length of the message is not greater than the preset length threshold, select a second verification mode, wherein the second verification mode indicates verification of the signal to be verified.

[0021] In some embodiments, the parsing module is configured to: identify the format of the bus data to obtain the format type of the bus data; call the parser corresponding to the format type to convert the bus data into bus data in a standard format; and parse the bus data in the standard format to obtain the parsing result.

[0022] In some embodiments, the apparatus further includes:

[0023] The display module is used to display the verification progress and the verification result during the verification process of the corresponding signal to be verified. The verification progress includes at least one of the following: the number of verified signals, the total number of the at least one signal to be verified, and the number of abnormal signals.

[0024] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor to implement the vehicle bus data verification method in the embodiments of this application.

[0025] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the vehicle bus data verification method in the embodiments of this application.

[0026] On the other hand, a computer program product is provided, including a computer program that is executed by a processor to implement the vehicle bus data verification method in the embodiments of this application.

[0027] This application provides a method for verifying vehicle bus data. It automatically filters signals to be verified through keyword matching and automatically generates verification configuration parameters based on the matching results. This reduces manual configuration operations, improves overall verification efficiency, reduces the probability of errors caused by manual configuration, and improves verification accuracy. This efficiently achieves accurate identification of abnormal signals in CAN bus data, ensuring the reliability and security of communication between various electronic control units in the vehicle, and can meet the automated verification needs of bus data during vehicle development and testing. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1This is a schematic diagram of an implementation environment provided according to an embodiment of this application;

[0030] Figure 2 This is a flowchart of a vehicle bus data verification method provided according to an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of a multi-format data processing flow provided according to an embodiment of this application;

[0032] Figure 4 This is a schematic diagram of an automatic configuration algorithm flow provided according to an embodiment of this application;

[0033] Figure 5 This is a schematic diagram of a comprehensive verification process provided according to an embodiment of this application;

[0034] Figure 6 This is a schematic diagram of a functional layout in a user interface according to an embodiment of this application;

[0035] Figure 7 This is a schematic diagram of a system overall architecture provided according to an embodiment of this application;

[0036] Figure 8 This is a block diagram of a vehicle bus data verification device according to an embodiment of this application;

[0037] Figure 9 This is a schematic diagram of the structure of a terminal according to an embodiment of this application;

[0038] Figure 10 This is a schematic diagram of the structure of a server according to an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0040] In this application, the terms "first", "second", etc. are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is there any limitation on the quantity or execution order.

[0041] In this application, the term "at least one" means one or more, and "multiple" means two or more.

[0042] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been 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. For example, bus data, preset keywords, preset message types, etc. involved in this application were all obtained with full authorization.

[0043] Figure 1 This is a schematic diagram of an implementation environment provided according to an embodiment of this application. See also... Figure 1 The implementation environment includes terminal 101 and server 102. Terminal 101 and server 102 can be connected directly or indirectly via wired or wireless communication, which is not limited herein.

[0044] Terminal 101 can be a mobile phone, desktop computer, laptop computer, tablet computer, or other types of terminal, but is not limited to these. Terminal 101 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names. Terminal 101 can refer to one of multiple terminals. Terminal 101 has data processing and display functions. Those skilled in the art will understand that the number of terminals can be more or less. For example, there may be several terminals, or dozens or hundreds of terminals, or even more. This application embodiment does not limit the number or type of terminals.

[0045] Among them, server 102 can be an independent physical server, or it can be a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0046] Optionally, the vehicle bus data verification method provided in this application embodiment can be executed by terminal 101 alone, by server 102 alone, or by interaction between terminal 101 and server 102. Terminal 101 and server 102 are associated, with server 102 providing background services to terminal 101. Optionally, server 102 undertakes the main computational work, and terminal 101 undertakes the secondary computational work; or, server 102 undertakes the secondary computational work, and terminal 101 undertakes the main computational work; or, server 102 and terminal 101 use a distributed computing architecture for collaborative computation. That is, some steps in the method are executed by terminal 101, and other steps are executed by server 102.

[0047] It should be noted that the above implementation environment is merely an example, and the method provided in this application embodiment can also be implemented in other environments, which are not limited thereto. In the following sections, the method for verifying vehicle bus data proposed in this application embodiment will be used as an example for illustration.

[0048] With the increasing level of vehicle electrification, modern vehicles have integrated a large number of ECUs (Electronic Control Units), which communicate via the CAN bus. During vehicle development and testing, precise validity analysis and verification of CAN bus data are necessary to ensure system reliability and functional safety.

[0049] Currently, various verification algorithms are available in the industry. However, these algorithms have many drawbacks, such as limited format support, low integration of verification algorithms, high configuration complexity, insufficient automation, and low analysis efficiency. These will be discussed in detail below. First, most traditional verification tools can only process CAN bus data in specific formats, requiring users to use multiple tools for conversion and analysis. Second, traditional verification tools typically support only one or a few verification algorithms, lacking unified integration and automated processing for multiple verification methods. Furthermore, users need to manually configure numerous parameters, including signal definitions and verification methods, and write different verification scripts for different verification tools. This configuration process is cumbersome, inefficient, and prone to errors. All of these factors affect the effectiveness of CAN bus data validity verification, thus impacting the development and testing process.

[0050] Based on this, this application proposes a method for verifying vehicle bus data, which solves the technical problems existing in traditional CAN bus data analysis technology, such as limited format support, low integration of verification algorithms, complex configuration, insufficient automation, and low analysis efficiency. It provides a validity verification system that can uniformly process CAN bus data of multiple formats, integrate multiple verification algorithms, and has automatic configuration generation capabilities.

[0051] By automatically filtering signals to be verified through keyword matching and automatically generating verification configuration parameters based on the matching results, and then calling the corresponding verification algorithm based on the verification configuration parameters, manual configuration operations are reduced, overall verification efficiency is improved, the probability of errors caused by manual configuration is reduced, and verification accuracy is improved. This efficiently achieves accurate identification of abnormal signals in CAN bus data, ensuring the reliability and security of communication between various electronic control units in the vehicle, and can meet the needs of automated verification of bus data during the vehicle development and testing phases.

[0052] The method will be described in detail below. Figure 2 This is a flowchart of a vehicle bus data verification method according to an embodiment of this application. The method is applied to a terminal. (See attached diagram.) Figure 2 As shown, the method includes the following steps:

[0053] 201. The terminal parses the bus data and obtains the parsing results. The bus data is the data transmitted on the vehicle's CAN bus, and the parsing results include multiple signals.

[0054] In this embodiment, bus data refers to communication data between various electronic control units of the vehicle, including information such as vehicle operating status and control commands. For example, bus data is determined by CAN log files and DBC files. The CAN log file indicates the raw communication data actually transmitted on the CAN bus, recording each message on the bus in a specific format (such as ASCII, BLF, LOG, etc.) in chronological order. The content includes the message transmission timestamp, message ID, data length, specific data bytes, message type, and channel to which it belongs. The DBC file indicates the logical definition relationship between CAN messages and signals, including the correspondence between message IDs and message names, and a list of signals included in each message (such as signal name, the start bit and length of the signal in the data bytes, data precision, physical units, and value range). The parsing result refers to the specific information obtained after parsing the bus data; the parsing result is a collection of messages, with each message including at least one signal.

[0055] It should be noted that the terminal can obtain bus data from multiple sources. For example, the terminal may obtain pre-stored bus data from its local storage component; the terminal may obtain bus data from a backend server; or the terminal may connect to the vehicle controller and obtain bus data from the corresponding interface. These methods are merely illustrative examples, and this application does not limit the source of the bus data.

[0056] In some embodiments, the bus data undergoes unified processing across multiple formats. Accordingly, the bus data is format-identified to determine its format type; the parser corresponding to that format type is invoked to convert the bus data into standard format bus data; and the standard format bus data is parsed to obtain the parsing result.

[0057] The parser is a tool that converts bus data of a specific format into a standard format. For example, bus data formats include ASCII, BLF (Binary Log), MDF (Measurement Data), and DAT (Data File). For ASCII format, the parser parses the timestamps, message IDs, data lengths, and hexadecimal data content from the text lines of the bus data. For BLF format, the parser parses the file header, object header, and message body according to the data structure defined by Vector. For MDF format, the parser reconstructs the message format of the bus data by identifying the signal channels with the "CAN-Monitoring:" suffix and grouping them by timestamp and channel. For DAT format, the parser parses the timestamps, message identifiers, data fields, and other information recorded in the bus data according to specific rules.

[0058] In this context, standard format bus data refers to a data structure that conforms to a unified specification after conversion. For example, the output of all parsers is converted to the standard format through a unified interface. This data structure includes a timestamp, arbitration ID, data length code, data content, and channel information. The timestamp records the precise time of message transmission / acquisition, supporting microsecond-level precision; the arbitration ID is a unique identifier for the CAN message, compatible with both 11-bit (standard frame) and 29-bit (extended frame) types; the data length code indicates the number of bytes of valid data in the message, typically ranging from 0-8 bytes (traditional CAN) or 0-64 bytes (CAN-FD); the data content is stored according to the data length code, supporting the 8-byte upper limit of traditional CAN and the 64-byte extended upper limit of CAN-FD; and the channel information identifies the physical or logical channel from which the message originates.

[0059] By first identifying the format of the bus data and converting it into a standard format, and then calling the corresponding parser to parse it, the compatibility parsing problem of bus data with different formats is effectively solved, providing a reliable data foundation for subsequent verification, avoiding verification errors caused by differences in data formats, and improving the versatility of the method.

[0060] For a clearer description of the multi-format unified processing mechanism described above, please refer to [link / reference]. Figure 3 As shown, Figure 3 This is a schematic diagram of a multi-format data processing flow according to an embodiment of this application. First, the input file (including bus data) is automatically identified by a format recognition module to determine the file's format type. For each type of bus data format, the corresponding parser is invoked for ASCII parsing, BLF parsing, MDF / DAT parsing, and LOG parsing, respectively. The output of all parsers is unified to a standard format to facilitate standardization processing by subsequent processing modules.

[0061] 202. The terminal performs keyword matching on the parsing results based on multiple preset keywords to obtain matching results. The matching results include at least one signal to be verified and the preset keywords matched by each signal to be verified.

[0062] In this embodiment, the preset keywords are keywords selected from candidate keywords, keywords input in advance, or keywords from a predefined keyword set (or thesaurus). This embodiment does not limit the setting method of the preset keywords. For example, serial or parallel keyword matching is performed on multiple messages in the parsing results, and this embodiment does not limit this.

[0063] In some embodiments, messages within a specific range are filtered from the parsing results for subsequent keyword matching. Accordingly, based on a preset message type, a target message is determined from multiple messages included in the parsing results; keyword matching is performed on the target message based on multiple preset keywords to obtain a matching result. The preset message type is used to filter the range of messages to be verified. The preset message type includes at least one of a receiving type and a sending type, and the message type of the target message is the preset message type. The receiving type indicates the message received by the corresponding electronic control unit, and the sending type indicates the message sent by the corresponding electronic control unit.

[0064] By first filtering target messages based on preset message types and then performing keyword matching, the matching range can be narrowed, interference from irrelevant signals can be reduced, invalid matches can be decreased, and matching efficiency can be improved. Simultaneously, verification for specific message types makes the verification process more aligned with actual vehicle communication scenarios, enhancing the targeting and practicality of the verification, and improving its effectiveness.

[0065] In some embodiments, preset keywords are matched by signal names. Accordingly, for any signal, if the signal name includes any preset keyword, that is, it matches any preset keyword, the signal is determined as a signal to be verified; if the signal name does not include multiple preset keywords, that is, it does not match any preset keywords, the signal is determined as another signal besides the signal to be verified, that is, a normal signal that does not require validity verification.

[0066] For example, different check types correspond to different preset keywords. Check types are categorized as RC (Rolling Counter), CRC (Cyclic Redundancy Check), and Checksum. Accordingly, based on a predefined dictionary, RC signals are identified by matching keywords such as "rollgcntr," "rollcnt," and "counter"; CRC signals are identified by matching keywords such as "crc"; and Checksum signals are identified by matching keywords such as "checksum" and "chksum."

[0067] By using the above method, the standardization and automation of signal identification are achieved by using whether the signal name contains preset keywords as the criterion for judging the signal to be verified. This avoids the bias of manual judgment, ensures the consistency of the identification of the signal to be verified, facilitates the system to execute quickly, and improves the verification efficiency.

[0068] 203. Based on the matching results, the terminal generates the verification configuration parameters corresponding to each signal to be verified.

[0069] In this embodiment, based on the matching results, verification configuration parameters are automatically generated according to heuristic rules and stored or output as a standardized configuration file, such as a CSV configuration file. The heuristic rules (algorithms) are used to automatically determine the verification configuration parameters based on the preset verification type corresponding to the keywords matched by the signal to be verified, combined with the length of the message containing the signal, the position of the signal in the message, etc., thus forming a standardized configuration.

[0070] For example, the verification configuration parameters include several key information categories such as verification object, verification type, verification signal position, verification algorithm parameters, verification mode, and segmentation rules. Specifically, the verification object is determined by the message ID, signal name, or data segment to be verified; the verification type specifies the verification algorithm to be used, such as CRC checksum, Checksum checksum, RollingCounter checksum, etc.; the verification signal position is the specific byte / bit coordinate of the signal to be verified in the message; the verification algorithm parameters configure the verification algorithm, such as the CRC polynomial, initial value, and whether to invert the output; the Checksum calculation range and whether to include carry, etc.; the verification mode specifies the specific execution method of the verification, such as segmented verification for long messages and direct verification for short messages; and the segmentation rules are the segment division method during segmented verification.

[0071] In some embodiments, the verification configuration parameters include a verification type. Accordingly, for any signal to be verified, a verification type corresponding to the preset keyword is determined based on the preset keyword matched by the signal to be verified. Multiple preset keywords each correspond to their own verification type, and different verification types indicate different verification algorithms.

[0072] For example, for signals such as MDF / DAT, the preset keywords they match correspond to verification algorithms such as Rolling Counter; for signals such as ASC, BLF, and LOG, the preset keywords they match correspond to verification algorithms such as CRC and Checksum.

[0073] By using the above method, the corresponding verification type is automatically determined based on the preset keywords matched with the signal to be verified, realizing the automatic selection of the verification algorithm without manual selection, reducing configuration steps. By binding keywords with verification types, the adaptability of the verification algorithm to the signal characteristics is ensured, and the verification accuracy is improved.

[0074] In some embodiments, the verification configuration parameters include a verification mode. Accordingly, for any signal to be verified, the length of the message containing the signal to be verified is determined; if the message length is greater than a preset length threshold, i.e., the message is a long message, then a first verification mode is selected, which indicates that segmented verification is performed based on the position of the signal to be verified in the message; if the message length is not greater than the preset length threshold, i.e., the message is a short message, then a second verification mode is selected, which indicates that the signal to be verified is verified without segmented verification.

[0075] By using the above method, the verification mode is automatically selected based on the message length, and segmented verification is adopted for long messages. This can improve processing efficiency while maintaining verification accuracy, making the verification strategy more flexible and adaptable to the characteristics of messages of different lengths.

[0076] For a clearer description of the automatic configuration generation algorithm indicated in steps 202 and 203 above, please refer to... Figure 4 As shown, Figure 4 This is a schematic diagram of an automatic configuration algorithm flow provided according to an embodiment of this application. An automatic configuration generation strategy based on file parsing is adopted. First, the parsing module reads the input file and extracts the message and various signals within the message. This file includes standard format bus data, such as a CAN log file and a DBC file. After obtaining the above parsing results, the signal recognition engine executes the following two-layer recognition strategy. The first-layer signal recognition strategy is keyword matching. By determining whether the signal name includes a preset keyword, it is determined whether the signal is a normal signal or a signal to be verified. If the signal name does not include any preset keyword, it is marked as a normal signal; if the signal name includes any preset keyword, it is marked as a signal to be verified, and the following second-layer signal recognition strategy is executed. The second-layer signal recognition strategy is heuristic configuration. It determines whether the length of the message containing the signal exceeds a preset length threshold (e.g., 8 bytes). If it exceeds, the first verification mode (e.g., Segmented mode) is selected; if it does not exceed, the second verification mode (e.g., Standard mode) is selected. Furthermore, the system determines the positional relationship of signals within messages and the keywords corresponding to those signals. Based on heuristic rules, it automatically generates verification configuration parameters according to the keyword matching results and outputs a standardized configuration file (such as a CSV configuration file), which includes the automatically generated verification configuration parameters.

[0077] 204. The terminal verifies the corresponding signals to be verified based on the verification configuration parameters and obtains the verification results. The verification results are used to indicate whether each signal to be verified is an abnormal signal.

[0078] In this embodiment of the application, the abnormal signal is a signal that is determined to be inconsistent with the preset rules or to have an error after verification.

[0079] The system employs a multi-layered verification algorithm architecture, integrating three core verification algorithms through the invocation of the verification module. For example, a multi-layered verification algorithm architecture is used, with a modular design. The RollingCounter verification module implements the RC verification algorithm, maintaining a multi-dimensional state table to record the historical RC values ​​of each channel, message ID, and signal in real time. A continuity detection algorithm handles complex situations such as normal increments, boundary wrapping, and abnormal transitions, ensuring message sequence integrity. The CRC verification module implements the standard CRC algorithm, supporting three calculation modes: Standard, Segmented_Next, and Segmented_Prev. The Standard mode calculates all data except the check byte; the Segmented_Next mode calculates a data segment of a specified length after the check byte; and the Segmented_Prev mode calculates a data segment of a specified length before the check byte. The Checksum verification module performs verification using the standard XOR algorithm and a variant of the Checksum_XOR_Yas algorithm. The latter supports configuring initial values ​​to meet the diverse needs of different controller platforms. It should be noted that the above verification algorithms are for illustrative purposes only, and other verification algorithms are supported, which will not be elaborated here.

[0080] For a schematic diagram illustrating the comprehensive verification strategy described above, please refer to... Figure 5 As shown, Figure 5 This is a schematic diagram of a comprehensive verification process provided according to an embodiment of this application, which ensures data integrity through a triple verification mechanism.

[0081] The message input and parsing module receives and parses CAN messages, which contain signals to be verified. The configuration reading module reads verification configuration parameters from a CSV configuration file. The verification type identifier automatically determines the verification type of the signals to be verified contained in the message and distributes it to the corresponding verification branch for verification using the appropriate algorithm. Different verification branches call different verification modules. The verification results of each branch are categorized as either successful or failed. The result aggregation module collects the branch verification results from the three verification branches to obtain the final verification result. The error report generator generates a detailed verification failure analysis report based on the verification results. This report indicates error messages and can also include suggestions for handling exceptions.

[0082] The three-tiered verification strategy comprises three branches: RC (Continuity Check) branch performs Rolling Counter length verification to detect lost and duplicate messages, ensuring message sequence integrity through continuity judgment logic; CRC (Corrective Grammar) branch performs automatic CRC position analysis to detect data transmission errors, ensuring data accuracy through calculation correctness judgment and effectively detecting bit errors; and Checksum branch performs Checksum position analysis to verify data integrity, providing an additional layer of protection through calculation verification. This comprehensive system ensures message sequence integrity through RC continuity check, guarantees transmission accuracy through CRC data verification, and provides an additional layer of protection through Checksum integrity check, forming a complete data validity verification system.

[0083] In some embodiments, the terminal also provides a graphical user interface. Accordingly, during the verification process of the corresponding signals to be verified, the verification progress and verification results are displayed. The verification progress includes at least one of the following: the number of verified signals, the total number of at least one signal to be verified, and the number of abnormal signals.

[0084] By displaying the verification progress and results in real time, users can keep track of the verification status, making it easier to identify and intervene in problems promptly. This method improves information transmission efficiency, optimizes user experience, enables users to efficiently obtain verification information, and speeds up problem location and processing.

[0085] For a clearer description of user interface and interaction design, see [link to documentation]. Figure 6 As shown, Figure 6 This is a schematic diagram of the functional layout of a user interface according to an embodiment of this application. The user interface adopts a multi-area layout design. Exemplarily, the user interface includes a title bar area, a file selection area, a configuration generation area, an analysis option area, an execution control area, and a result display area.

[0086] The file selection area includes a log file selection component and multiple DBC file selection components. The diagram illustrates a dual DBC file configuration as an example, supporting a mutually exclusive analysis mode. This means that after configuration, the user can sequentially select to use DBC1 or DBC2 for analysis, but cannot enable them simultaneously. Optionally, fewer or more DBC files can be configured; this embodiment does not impose limitations on this. Accordingly, in response to the triggering operation of the log selection component and at least one DBC file selection component in the file selection area, the corresponding file is configured.

[0087] The configuration generation area includes a keyword configuration component, a message type selection component, and a configuration generation component. The configuration generation area supports custom keywords. Accordingly, in response to a trigger operation on the keyword configuration component, a preset keyword is selected from the candidate keywords, or a preset keyword is entered in the keyword input area. For example, the RC keyword can be configured as "rollgcntr, rollcnt, counter", the CRC keyword as "crc", and the Checksum keyword as "chksum, checksum". The configuration generation area also supports message type filtering. Accordingly, in response to a trigger operation on the message type component, a preset message type is selected from the candidate message types, including TX, RX, ALL, etc. The configuration generation area also supports manual triggering of automatic generation of verification configuration parameters. After completing the configuration of the file selection area, keyword configuration component, and message type selection component, in response to a trigger operation on the configuration generation component, a configuration file including verification configuration parameters is automatically generated.

[0088] The analysis options area includes verification options, a verification parameter configuration component, and a configuration output component. The analysis options area supports secondary editing of the automatically generated configuration file and outputs the adjusted configuration file. Accordingly, after obtaining the automatically generated configuration file, in response to a trigger operation on the verification options, the identified signals to be verified are adjusted; and / or, in response to a trigger operation on the verification parameter configuration component, the generated parameters to be verified are adjusted; after the adjustments are completed, in response to a trigger operation on the configuration output component, based on the adjusted signals and parameters to be verified, the adjusted configuration file is generated and output.

[0089] The execution control area includes a runtime analysis component and a progress display component. Accordingly, in response to a trigger operation on the runtime analysis component, the signals to be verified are automatically verified based on the configuration file; in response to a subsequent trigger operation on the runtime analysis component, the automatic verification process is interrupted. During the automatic verification process, the progress display component shows the verification progress in percentage and / or quantity form to indicate the percentage and / or quantity of verified signals and abnormal signals.

[0090] The results display area is used to display the verification results in real time, and supports highlighting errors in the verification results. The highlighting methods include highlighting, color changing, adding borders, bolding, and increasing font size. For example, it automatically highlights verification failure lines containing keywords such as "FAIL," "error," and "failure."

[0091] For ease of description of the system architecture in the embodiments of this application, see [link to relevant documentation]. Figure 7 As shown, Figure 7This is a schematic diagram of the overall system architecture provided according to an embodiment of this application. The system adopts a layered modular structure design, including a data input layer, a data processing layer, a configuration management layer, a verification algorithm layer, and a user interface layer. The data input layer is used to input bus data in various formats such as ASC, BLF, MDF, DAT, and LOG. The data processing layer includes a format recognizer, a message parser, and a data unifier. The configuration management layer includes an automatic identification module, a heuristic algorithm, and a configuration generation module. The verification algorithm layer includes an RC verification module, a CRC verification module, and a Checksum verification module. The user interface layer includes a file selection module, a parameter configuration module, and a result display module. The system, composed of the above layers, implements steps 201 to 204, which will not be elaborated further here.

[0092] This application provides a method for verifying vehicle bus data. It automatically filters signals to be verified through keyword matching and automatically generates verification configuration parameters based on the matching results. This reduces manual configuration operations, improves overall verification efficiency, reduces the probability of errors caused by manual configuration, and improves verification accuracy. This efficiently achieves accurate identification of abnormal signals in CAN bus data, ensuring the reliability and security of communication between various electronic control units in the vehicle, and can meet the automated verification needs of bus data during vehicle development and testing.

[0093] In other words, this application provides a complete, high-performance, and easy-to-use CAN bus data analysis method that can uniformly process, extract signals, and verify the validity of CAN bus data in various formats. It effectively solves the limitations of traditional methods in terms of format support, algorithm integration, automatic configuration, and processing efficiency. The effects of the method proposed in this application will be explained in more detail below through (1)-(5).

[0094] (1) Improved format compatibility: By establishing a unified data processing interface and using an automatic format recognition and conversion module, it can uniformly process various CAN log formats such as ASC, BLF, LOG, MDF, and DAT. It also provides a CSV format configuration file management mechanism, realizing unified data processing, solving the problem of users needing multiple tools for conversion, and improving work efficiency.

[0095] (2) Enhanced verification coverage: It integrates multiple verification algorithms such as Rolling Counter continuity verification, CRC multi-mode verification, and Checksum XOR variant verification, and supports adaptive selection of different calculation modes based on CRC at different positions in the message. It can comprehensively detect various errors in CAN communication, including message loss, data errors, timing abnormalities, etc.

[0096] (3) Improved automation level: The automatic identification algorithm based on CAN log files can automatically generate verification configuration parameters. That is, based on DBC files, keyword matching and heuristic algorithms are used to automatically identify verification signals such as Rolling Counter, CRC, and Checksum. Verification configuration parameters are automatically generated according to signal characteristics (such as signal position) and message attributes (such as message type). This greatly reduces the workload of manual configuration and lowers the configuration error rate.

[0097] (4) Enhanced adaptability: By using an adaptive segmented verification method, for long CAN messages (such as those exceeding 8 bytes), the segmented verification strategy is automatically selected based on the position of the signal to be verified in the message, thereby improving the accuracy and efficiency of the verification.

[0098] (5) Improved Analysis Efficiency: It provides an intuitive graphical user interface, supporting file selection, parameter configuration, real-time progress display, error statistics, and result visualization, thus improving information transmission efficiency and lowering the user threshold. Simultaneously, it employs a streaming processing method that synchronizes processing and display, along with progress display technology, enabling efficient processing of large log files at the GB level. It provides detailed error statistics and classification reports, supports error highlighting and export functions, and helps users quickly locate and resolve communication problems.

[0099] Figure 8 This is a block diagram of a vehicle bus data verification device according to an embodiment of this application. The device is used to execute the steps of the vehicle bus data verification method described above, see [link to relevant documentation]. Figure 8 The vehicle bus data verification device includes: a parsing module 801, a matching module 802, a generation module 803, and a verification module 804.

[0100] The parsing module 801 is used to parse the bus data and obtain the parsing result. The bus data is the data transmitted on the vehicle's CAN bus, and the parsing result includes multiple signals.

[0101] The matching module 802 is used to perform keyword matching on the parsing results based on multiple preset keywords to obtain matching results. The matching results include at least one signal to be verified and the preset keywords matched by each signal to be verified.

[0102] The generation module 803 is used to generate the verification configuration parameters corresponding to each signal to be verified based on the matching results.

[0103] The verification module 804 is used to verify the corresponding signals to be verified based on the verification configuration parameters and obtain the verification results. The verification results are used to indicate whether each signal to be verified is an abnormal signal.

[0104] In some embodiments, the matching module 802 is used to determine a target message from multiple messages included in the parsing result based on a preset message type. The preset message type includes at least one of a receiving type and a sending type. Each message includes at least one signal. The message type of the target message is the preset message type. Based on multiple preset keywords, keyword matching is performed on the target message to obtain a matching result.

[0105] In some embodiments, the matching module 802 is configured to, for any signal, determine the signal as a signal to be verified if the signal name includes any preset keyword; and determine the signal as another signal besides the signal to be verified if the signal name does not include multiple preset keywords.

[0106] In some embodiments, the verification configuration parameters include the verification type;

[0107] The generation module 803 is used to determine the verification type corresponding to the preset keywords based on the preset keywords matched by the signal to be verified for any signal to be verified. Multiple preset keywords correspond to their own verification types, and different verification types indicate different verification algorithms.

[0108] In some embodiments, the verification configuration parameters include the verification mode;

[0109] The generation module 803 is used to determine the length of the message containing any signal to be verified; if the length of the message is greater than a preset length threshold, a first verification mode is selected, which indicates that segmented verification is performed based on the position of the signal to be verified in the message; if the length of the message is not greater than the preset length threshold, a second verification mode is selected, which indicates that the signal to be verified is verified.

[0110] In some embodiments, the parsing module 801 is used to identify the format of the bus data to obtain the format type of the bus data; call the parser corresponding to the format type to convert the bus data into bus data in a standard format; and parse the bus data in the standard format to obtain the parsing result.

[0111] In some embodiments, the apparatus further includes:

[0112] The display module is used to display the verification progress and verification results during the verification process of the corresponding signals to be verified. The verification progress includes at least one of the following: the number of verified signals, the total number of at least one signal to be verified, and the number of abnormal signals.

[0113] This application provides a vehicle bus data verification device that automatically filters signals to be verified through keyword matching and automatically generates verification configuration parameters based on the matching results. This reduces manual configuration operations, improves overall verification efficiency, reduces the probability of errors caused by manual configuration, and improves verification accuracy. It efficiently achieves accurate identification of abnormal signals in CAN bus data, ensuring the reliability and security of communication between various electronic control units in the vehicle, and can meet the automated verification needs of bus data during vehicle development and testing.

[0114] It should be noted that the vehicle bus data verification device provided in the above embodiments is only illustrated by the division of the above functional modules when running the application. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the terminal can be divided into different functional modules to complete all or part of the functions described above. In addition, the vehicle bus data verification device and the vehicle bus data verification method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0115] Figure 9 This is a schematic diagram of a terminal according to an embodiment of this application. The terminal 900 can be a portable mobile terminal, such as a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The terminal 900 may also be referred to as a user device, portable terminal, laptop terminal, desktop terminal, or other names.

[0116] Typically, terminal 900 includes a processor 901 and a memory 902.

[0117] Processor 901 may include one or more processing cores, such as a quad-core processor, a nine-core processor, etc. Processor 901 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 901 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, processor 901 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 901 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0118] The memory 902 may include one or more computer-readable storage media, which may be non-transitory. The memory 902 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, the non-transitory computer-readable storage media in the memory 902 are used to store at least one computer program, which is executed by the processor 901 to implement the vehicle bus data verification method provided in the method embodiments of this application.

[0119] In some embodiments, the terminal 900 may also optionally include a peripheral device interface 903 and at least one peripheral device. The processor 901, memory 902, and peripheral device interface 903 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 903 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 904, a display screen 905, a camera assembly 906, an audio circuit 907, and a power supply 908.

[0120] Peripheral device interface 903 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 901 and memory 902. In some embodiments, processor 901, memory 902 and peripheral device interface 903 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 901, memory 902 and peripheral device interface 903 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0121] The radio frequency (RF) circuit 904 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 904 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 904 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. In some embodiments, the RF circuit 904 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 904 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 904 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0122] Display screen 905 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 905 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 901 for processing. In this case, display screen 905 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 905, disposed on the front panel of terminal 900; in other embodiments, there may be at least two display screens 905, disposed on different surfaces of terminal 900 or in a folded design; in other embodiments, display screen 905 may be a flexible display screen, disposed on a curved or folded surface of terminal 900. Furthermore, display screen 905 may be configured as a non-rectangular irregular shape, i.e., a non-rectangular screen. Display screen 905 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0123] The camera assembly 906 is used to acquire images or videos. In some embodiments, the camera assembly 906 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 906 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0124] The audio circuit 907 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting them into electrical signals that are input to the processor 901 for processing, or to the radio frequency circuit 904 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each positioned at a different location on the terminal 900. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 901 or the radio frequency circuit 904 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 907 may also include a headphone jack.

[0125] Power supply 908 is used to power the various components in terminal 900. Power supply 908 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 908 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0126] Those skilled in the art will understand that Figure 9 The structure shown does not constitute a limitation on terminal 900, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0127] Figure 10 This is a schematic diagram of a server structure according to an embodiment of this application. The server 1000 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 1001 and one or more memories 1002. The memory 1002 stores at least one computer program, which is loaded and executed by the processor 1001 to implement the vehicle bus data verification method provided in the above-described method embodiments. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated here.

[0128] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the vehicle bus data verification method in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0129] This application also provides a computer program product, including a computer program that is executed by a processor to implement the vehicle bus data verification method in this application embodiment.

[0130] 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.

[0131] The above description is merely an optional embodiment 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 should be included within the protection scope of this application.

Claims

1. A method for verifying vehicle bus data, characterized in that, The method includes: The bus data is parsed to obtain the parsing result. The bus data is the data transmitted on the vehicle's CAN bus, and the parsing result includes multiple signals. Based on multiple preset keywords, keyword matching is performed on the parsing results to obtain matching results. The matching results include at least one signal to be verified and preset keywords matched by each signal to be verified. Based on the matching results, generate the verification configuration parameters corresponding to each signal to be verified; Based on the verification configuration parameters, the corresponding signals to be verified are verified to obtain verification results. The verification results are used to indicate whether each signal to be verified is an abnormal signal.

2. The method according to claim 1, characterized in that, The step of performing keyword matching on the parsing results based on multiple preset keywords to obtain matching results includes: Based on a preset message type, a target message is determined from multiple messages included in the parsing result. The preset message type includes at least one of a receiving type and a sending type. Each message includes at least one signal. The message type of the target message is the preset message type. Based on the multiple preset keywords, keyword matching is performed on the target message to obtain the matching result.

3. The method according to claim 2, characterized in that, The step of performing keyword matching on the target message based on the plurality of preset keywords to obtain the matching result includes: For any signal, if the signal name includes any preset keyword, the signal is determined as the signal to be verified. If the signal name does not include the multiple preset keywords, the signal is identified as another signal besides the signal to be verified.

4. The method according to claim 1, characterized in that, The verification configuration parameters include the verification type; the generation of verification configuration parameters for each signal to be verified based on the matching result includes: For any signal to be verified, the verification type corresponding to the preset keyword is determined based on the preset keyword matched by the signal to be verified. Each of the preset keywords has its own verification type, and different verification types indicate different verification algorithms.

5. The method according to claim 1, characterized in that, The verification configuration parameters include a verification mode; the generation of verification configuration parameters for each signal to be verified based on the matching result includes: For any signal to be verified, determine the length of the message containing the signal to be verified. If the length of the message is greater than a preset length threshold, a first verification mode is selected. The first verification mode indicates that segmented verification is performed based on the position of the signal to be verified in the message. If the length of the message is not greater than the preset length threshold, a second verification mode is selected, which indicates that the signal to be verified is to be verified.

6. The method according to claim 1, characterized in that, The parsing of bus data to obtain the parsing results includes: The format of the bus data is identified to determine the format type of the bus data. Call the parser corresponding to the specified format type to convert the bus data into bus data in a standard format; The bus data in the standard format is parsed to obtain the parsing result.

7. The method according to claim 1, characterized in that, The method further includes: During the verification process of the corresponding signals to be verified, the verification progress and verification results are displayed. The verification progress includes at least one of the following: the number of verified signals, the total number of the at least one signal to be verified, and the number of abnormal signals.

8. A device for verifying vehicle bus data, characterized in that, The device includes: The parsing module is used to parse the bus data and obtain the parsing result. The bus data is the data transmitted on the vehicle's CAN bus, and the parsing result includes multiple signals. The matching module is used to perform keyword matching on the parsing results based on multiple preset keywords to obtain matching results. The matching results include at least one signal to be verified and preset keywords matched by each signal to be verified. The generation module is used to generate verification configuration parameters for each signal to be verified based on the matching results. The verification module is used to verify the corresponding signals to be verified based on the verification configuration parameters and obtain the verification result. The verification result is used to indicate whether each signal to be verified is an abnormal signal.

9. A computer device, characterized in that, The computer device includes a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded by the processor and executed as the vehicle bus data verification method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program for executing the vehicle bus data verification method according to any one of claims 1 to 7.

Images