DBC file analysis method and device, vehicle and storage medium

Abstract

The invention relates to a DBC file analysis method and device, a vehicle and a storage medium, relates to the technical field of vehicles, is used for improving the fault-tolerant capability of DBC file analysis, and comprises the steps of obtaining a to-be-analyzed DBC file; determining a plurality of data units in the DBC file based on the line feed in the DBC file; for each data unit, determining an analysis type of the data unit according to the character identifier included in the data unit; the character identifier comprises a starting identifier and an inter-row mark, and the inter-row mark comprises an inter-row starting mark and an inter-row ending mark; and according to the data type corresponding to the data unit, calling an analysis function corresponding to the data type to analyze the data unit to obtain an analysis result.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, in particular to a DBC file parsing method and device, a vehicle and a storage medium. BACKGROUND

[0002] In an automotive electronic system, a Controller Area Network (CAN) communication protocol is widely used for communication between various Electronic Control Units (ECUs). An Automotive Communication Database File (DBC) file is a standard file format for describing the CAN network communication protocol, which realizes standardized description of the CAN bus. It is not only a communication protocol specification for ECU development, but also a configuration input for bus simulation tools (such as CANoe and CANalyzer), and a decoding basis for post-data analysis (such as log analysis and fault diagnosis). Without a DBC file, binary data on the CAN bus is just random code that cannot be interpreted, and ECUs cannot communicate with each other.

[0003] In related technologies, mainstream DBC parsing tools (such as built-in functions of CANoe / CANalyzer, Vector CANdb++, Python cantools library, etc.) can meet basic parsing needs in a standard format. However, in complex actual scenarios of automotive electronics engineering, due to problems such as format deviations caused by manual editing, field redundancy caused by fusion of multiple versions of protocols, non-standard extended fields defined by different ECU manufacturers, and incomplete data type labeling, these DBC parsing tools have low fault tolerance, and may have problems such as parsing interruption, data loss, and information distortion when parsing a DBC file, resulting in that the DBC file cannot be normally loaded and used.

[0004] Therefore, how to improve the fault tolerance of parsing a DBC file is a problem to be solved at present. SUMMARY

[0005] The present application provides a DBC file parsing method and device, a vehicle and a storage medium to solve the problem of low fault tolerance of parsing a DBC file in the prior art.

[0006] In order to achieve the above-mentioned purpose, the technical solutions adopted by the present application are as follows: In a first aspect, a DBC file parsing method is provided, including: obtaining a DBC file to be parsed; determining a plurality of data units in the DBC file based on line breaks in the DBC file; for each data unit, determining a parsing type of the data unit according to character identifiers included in the data unit; the character identifiers include a start identifier and a cross-line marker, the cross-line marker includes a cross-line start marker and a cross-line end marker; the parsing type includes at least one of a standard parsing type, a cross-line start parsing type, and a cross-line continuation parsing type; the standard parsing type is used to indicate that the data unit is a complete data unit; the cross-line start parsing type is used to indicate that the data unit includes the start identifier and the cross-line start marker, and does not include the cross-line end marker; the cross-line continuation parsing type is used to indicate that data of the data unit is a continuation of a previous data unit; a parsing function corresponding to a data type of the data unit is called to parse the data unit according to the data type of the data unit, to obtain a parsing result; the data type of the standard parsing type and / or the cross-line start parsing type is determined based on the start identifier of the data unit; the data type of the cross-line continuation parsing type is determined based on a data type of another data unit that is in a same closed cross-line marker as the data unit.

[0007] According to the above technical means, by determining a plurality of data units in the DBC file based on line breaks in the DBC file, determining a parsing type of the data unit according to character identifiers included in the data unit, and then determining a data type of the data unit according to the parsing type, calling a parsing function corresponding to the data type to parse the data unit, and obtaining a parsing result, when there is data across lines, the parsing of the data unit is performed based on the cross-line start parsing type and the cross-line continuation parsing type, which can effectively avoid the interruption of parsing caused by cross-line data, ensure the parsing continuity and data integrity of non-complete data units, allow the common cross-line non-standard data unit in the vehicle field to be completely parsed without interrupting the overall parsing process, reduce the probability of parsing failure caused by cross-line data, and thus improve the fault tolerance of DBC file parsing.

[0008] Further, the data type corresponding to the data unit is determined in the following manner: in a case where the start identifier of the data unit is VERSION, it is determined that the data type of the data unit is version definition; or, in a case where the start identifier of the data unit is BU, it is determined that the data type of the data unit is node list definition; or, in a case where the start identifier of the data unit is BO, it is determined that the data type of the data unit is message definition; or, in a case where the start identifier of the data unit is SG, it is determined that the data type of the data unit is signal definition; or, in a case where the start identifier of the data unit is CM and the parsing type of the data unit is standard parsing type and / or cross-line start parsing type, it is determined that the data type of the data unit is annotation definition; or, in a case where the start identifier of the other data unit under the same closed cross-line mark is CM and the parsing type of the data unit is cross-line continuation parsing type, it is determined that the data type of the data unit is cross-line annotation definition; or, in a case where the start identifier of the data unit is VAL and the parsing type of the data unit is standard parsing type and / or cross-line start parsing type, it is determined that the data type of the data unit is enumeration value definition; or, in a case where the start identifier of the other data unit under the same closed cross-line mark is VAL and the parsing type of the data unit is cross-line continuation parsing type, it is determined that the data type of the data unit is cross-line enumeration value definition; or, in a case where the data unit contains the attribute of the object of the DBC file definition, it is determined that the data type of the data unit is attribute definition.

[0009] According to the above technical means, the DBC file contains multiple core elements such as version, node, message, signal, annotation, enumeration value, and attribute, and the syntax of some elements is similar. By identifying the start identifier of each data unit, the data type of the data unit can be accurately determined.

[0010] Further, in a case where the parsing type is standard parsing type, according to the data type corresponding to the data unit, a parsing function corresponding to the data type is called to parse the data unit to obtain a parsing result, including: based on the data type corresponding to the data unit, a corresponding parsing function is called; based on the parsing function, the content of the data unit is extracted to obtain parsed data; the object corresponding to the parsed data and the memory address of the object are determined; the memory address of the object is an address in the pre-allocated memory block; the parsed data is filled into the object to obtain the parsing result of the data unit.

[0011] According to the above technical means, a corresponding parsing function is called according to the data type of the data unit. Each parsing function focuses on only one type of syntax rule, ensuring that the extracted parameters are completely matched with the semantics of the data type, and avoiding the cross interference of syntax rules between different data types.

[0012] Furthermore, when the parsing type is cross-line start parsing, the parsing function corresponding to the data type is called to parse the data unit according to the data type corresponding to the data unit, and the parsing result is obtained. This includes: when the data type corresponding to the data unit is a comment or an enumeration value, the parsing function corresponding to the comment or enumeration value is called to parse the data unit and obtain the parsed data of the data unit; a buffer is constructed and the parsed data of the data unit is saved to the buffer.

[0013] Based on the above technical means, when the parsing type is cross-line start parsing type, by constructing a buffer, the cross-line data that has not been parsed yet (such as unclosed descriptive text fragments, incompletely extracted enumeration values) can be temporarily stored, providing a context connection point for subsequent cross-line continuation parsing type data units.

[0014] Furthermore, when the parsing type is a cross-line continuation parsing type, the parsing function corresponding to the data type is called to parse the data unit according to the data type corresponding to the data unit, and the parsing result is obtained. This includes: when the data type corresponding to the data unit is a comment or an enumeration value, for each subsequent data unit within the same closed cross-line marker, the content of each subsequent data unit is added to the buffer until a terminating quote is detected, thus obtaining the parsed data of multiple data units within the same closed cross-line marker; the parsed data is associated with the data unit object to obtain the parsing result of multiple data units within the same closed cross-line marker.

[0015] Based on the above technical means, when the parsing type is the cross-line continuation parsing type, by adding the content of each subsequent data unit of the starting data unit within the same closed cross-line marker to the buffer, the parser can directly continue processing based on these contexts, ensuring the continuity of the cross-line parsing logic and avoiding data breakage or content loss caused by line breaks. When the closing marker is detected, the complete data accumulated in the buffer can be converted into the parsing result at once.

[0016] Furthermore, the parsing process for cross-line comments includes: when the starting identifier of the data unit is identified as CM_, determining the type of comment; the types of comments include: message, node, and signal; when the type of comment is signal, determining the starting quotation mark of the comment text and starting the accumulation of comment text; if no closing quotation mark is detected at the end of the line of the starting data unit of the parsed comment text, saving the parsed data of the starting data unit of the comment text, and appending the parsed content of subsequent data units to the accumulated comment text until the closing quotation mark of the comment text is detected, obtaining the comment text after parsing the data unit; determining the target object corresponding to the comment text and the memory address of the target object; associating the parsed comment text with the memory address of the target object to obtain the cross-line comment parsing result.

[0017] Based on the above technical means, by identifying the starting identifier of the data unit, the annotation text accumulation begins when the starting quotation mark is detected. When the ending quotation mark is not detected, the parsing context is saved and the text is appended until the ending quotation mark is detected. Even if the annotation text is distributed in multiple data units, it can be aggregated into complete content, avoiding the complete interruption of parsing caused by cross-line structure.

[0018] Furthermore, the parsing process for cross-line enumeration values ​​includes: when the starting identifier of a data unit is identified as VAL_, determining the target object of the data unit; parsing the content of the starting data unit of the enumeration value to obtain a value-description pair, and starting to accumulate data-description pairs; if no closing quotation mark is detected at the end of the line of the starting data unit of the enumeration value, saving the parsed data of the starting data unit of the enumeration value, and appending the parsed content of subsequent data units to the accumulated data-description pairs until a closing quotation mark is detected; sorting the value-description pairs in the accumulated data-description text according to the numerical values ​​from smallest to largest, associating the sorted value-description pairs with the target object, and obtaining the cross-line enumeration value parsing result.

[0019] Based on the aforementioned technical means, in DBC files, the description text of enumeration values ​​is often stored across multiple lines due to its excessive length. By monitoring the presence of closing quotation marks and using a mechanism for accumulating data-description pairs, cross-line enumeration value parsing can completely aggregate description text that spans multiple lines, ensuring that data loss caused by format splitting is prevented.

[0020] Furthermore, the above method also includes: classifying errors according to their severity in response to errors occurring during the parsing of DBC files; the error categories include: recoverable errors, partially recoverable errors, and unrecoverable errors; executing corresponding error recovery strategies according to the error category; and generating an error report if the error cannot be recovered; the error report includes: error location, error description, and repair suggestions.

[0021] Based on the above technical means, if an error occurs when parsing a DBC file, the corresponding recovery strategy can be called to repair it by determining the type of error. This can prevent the complete interruption of parsing due to local format abnormalities, preserve the parsing results of subsequent normal data, and ensure the continuity of the parsing process. In the case of unrecoverable errors, an error report can be generated, which can provide accurate error location, clear error nature description and repair suggestions, and significantly reduce the time cost of troubleshooting and DBC file correction.

[0022] Secondly, a DBC file parsing device is proposed, comprising: an acquisition unit and a processing unit; the acquisition unit is used to acquire the DBC file to be parsed; the processing unit is used to determine multiple data units in the DBC file based on newline characters in the DBC file; for each data unit, the parsing type of the data unit is determined according to the character identifiers included in the data unit; the character identifiers include: a start identifier and a cross-line marker, and the cross-line markers include: a cross-line start marker and a cross-line end marker; the parsing type includes at least one of the following: a standard parsing type, a cross-line start parsing type, and a cross-line continuation parsing type; wherein, the standard parsing type is used to indicate data A data unit is a complete data unit; the cross-line start parsing type indicates that the data unit includes a start marker and a cross-line start marker, but does not include a cross-line end marker; the cross-line continuation parsing type indicates that the data in the data unit is a continuation of the previous data unit; according to the data type corresponding to the data unit, the parsing function corresponding to the data type is called to parse the data unit and obtain the parsing result; among them, the data type of the standard parsing type and / or the cross-line start parsing type is determined based on the start marker of the data unit; the data type of the cross-line continuation parsing type is determined based on the data type of other data units that are in the same closed cross-line marker as the data unit.

[0023] Thirdly, an electronic device is provided, comprising: a processor and a memory; the memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the DBC file parsing method of the first aspect and any possible implementation thereof.

[0024] Fourthly, a vehicle is proposed, including the aforementioned electronic equipment.

[0025] Fifthly, a computer-readable storage medium is provided, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the DBC file parsing method described in the first aspect and any possible implementation thereof.

[0026] In a sixth aspect, a computer program product is provided, comprising computer instructions that, when executed on an electronic device, cause the electronic device to perform the DBC file parsing method described in the first aspect and any possible implementation thereof.

[0027] The beneficial effects of this application are: (1) By identifying multiple data units in the DBC file based on the newline character in the DBC file, the parsing type of the data unit is determined according to the character identifier included in the data unit, and then the data type of the data unit is determined according to the parsing type. The parsing function corresponding to the data type is called to parse the data unit and obtain the parsing result. This can effectively avoid the complete interruption of parsing caused by cross-line data, ensure the parsing continuity and data integrity of incomplete data units, and enable the complete parsing of non-standard cross-line data units commonly used in the vehicle field without interrupting the overall parsing process. This reduces the probability of parsing failure caused by cross-line data and improves the fault tolerance capability of DBC file parsing.

[0028] (2) DBC files contain a variety of core elements such as version, node, message, signal, comment, enumeration value, and attribute. Some elements have similar syntax. By identifying the starting identifier of each data unit, the data type of the data unit can be accurately determined.

[0029] (3) Call the corresponding parsing function according to the data type of the data unit. Each parsing function focuses on the syntax rules of only one type, ensuring that the extracted parameters are completely matched with the semantics of the data type, and avoiding cross interference of syntax rules between different data types.

[0030] (4) When the parsing type is cross-line start parsing type, a buffer can be built to temporarily store the cross-line data that has not been parsed yet (such as unclosed descriptive text fragments and incompletely extracted enumeration values), providing a context connection point for subsequent cross-line continuation parsing type data units.

[0031] (5) When the parsing type is the cross-line continuation parsing type, by adding the content of each subsequent data unit of the starting data unit within the same closed cross-line marker to the buffer, the parser can directly continue processing based on these contexts, ensuring the continuity of the cross-line parsing logic and avoiding data breakage or content loss due to line breaks. When the closed marker is detected, the complete data accumulated in the buffer can be converted into the parsing result at once.

[0032] (6) By recognizing the starting identifier of the data unit, the annotation text accumulation begins when the starting quotation mark is detected. When the ending quotation mark is not detected, the text is appended to the logic of detecting the ending quotation mark by saving the parsing context. Even if the annotation text is distributed in multiple data units, it can be aggregated into complete content, avoiding the complete interruption of parsing caused by cross-line structure.

[0033] (7) In DBC files, the description text of enumeration values ​​is often stored across multiple lines due to its length. Cross-line enumeration value parsing can completely aggregate description text across multiple lines by monitoring the presence of closing quotes and the mechanism of accumulating data-description pairs, thus ensuring that data loss caused by format splitting is prevented.

[0034] (8) When parsing a DBC file, if an error occurs, the corresponding recovery strategy can be called to repair it by determining the type of error. This can prevent the parsing from being completely interrupted due to local format abnormalities, preserve the parsing results of subsequent normal data, and ensure the continuity of the parsing process. In the case of no recovery, an error report can be generated, which can provide accurate error location, clear error nature description and repair suggestions, and greatly reduce the time cost of troubleshooting and DBC file correction. Attached Figure Description

[0035] Figure 1 This application provides a schematic diagram of the process of a DBC file parsing system for processing DBC files. Figure 2 A flowchart illustrating the operation of a DBC file parsing system provided in this application embodiment; Figure 3 A flowchart (I) illustrating a DBC file parsing method provided in this application embodiment; Figure 4 A flowchart (II) illustrating a DBC file parsing method provided in this application embodiment; Figure 5 A schematic diagram illustrating a cross-line comment parsing process provided for an embodiment of this application; Figure 6 A flowchart (III) illustrating a DBC file parsing method provided in this application embodiment; Figure 7 A flowchart illustrating a cross-row enumeration value parsing method provided in this application embodiment; Figure 8 A flowchart (IV) illustrating a DBC file parsing method provided in this application embodiment; Figure 9 This application provides a schematic flowchart for DBC file error handling in an embodiment of the present application. Figure 10 A schematic diagram of the structure of a DBC file parsing device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0037] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0038] In automotive electronic systems, the Controller Area Network (CAN) communication protocol is widely used for communication between various Electronic Control Units (ECUs). The Automotive Communication Database File (DBC) is a standard file format describing the CAN network communication protocol. It provides a standardized description of the CAN bus and serves as the communication protocol specification during ECU development, the configuration input for bus simulation tools (such as CANoe and CANalyzer), and the decoding basis for subsequent data parsing (such as log analysis and fault diagnosis). Without a DBC file, the binary data on the CAN bus is unreadable gibberish, and ECUs cannot achieve cooperative communication.

[0039] In related technologies, mainstream DBC parsing tools (such as CANoe / CANalyzer built-in functions, Vector CANdb++, Python cantools library, etc.) can handle basic parsing needs under standardized formats. However, in the complex real-world scenarios of automotive electronics engineering, due to the existence of non-standard DBC file formats (such as format deviations left over from manual editing, field redundancy caused by the fusion of multiple version protocols, non-standard extended fields defined by different ECU manufacturers, incomplete data type annotations, etc.), these DBC parsing tools have low fault tolerance. When parsing DBC files, there may be problems such as parsing interruption, data loss, and information distortion, which will cause the DBC file to fail to load and be used normally.

[0040] Firstly, due to multi-team collaborative editing, cross-tool format conversion, and manual input errors, DBC files often have non-standard issues such as missing fields, redundant symbols, and syntax deviations. However, existing parsing tools generally adopt a "strict format verification + error-based interruption" logic: once a format abnormality is detected (such as a missing terminator in a signal descriptor or an incompatible message ID), the entire parsing process is immediately terminated, and there is no remedial mechanism for error location, partial repair, and continued parsing. If an error occurs during the parsing process, the entire DBC file will become completely unusable, which is out of step with the actual needs of projects to prioritize obtaining usable data and then gradually repairing abnormalities, significantly increasing debugging time and costs.

[0041] Secondly, as automotive electronics upgrade towards intelligence and connectivity, DBC files have evolved from the basic Vector version to an extended version supporting the Autosar specification, adding core extended fields such as minimum / maximum signal values, environmental variable correlation, functional safety level labeling, and diagnostic signal classification (supporting high-precision control, fault tracing, and functional safety compliance). However, existing tools have significant limitations in supporting these features. Version compatibility limitations: Some tools are only compatible with the Vector basic format and directly determine that they do not support DBC files in the Autosar extended format, causing the files to fail to load. Incomplete field parsing: Even tools that support extended versions (such as CANdb++) may miss key fields (such as environment variable association fields). These fields are the core basis for the linkage between intelligent driving system signals and vehicle control logic. Missing fields result in parsing results that cannot support control strategy development, leading to partial parsing failure. Transitional version blind spots: Many transitional DBC files in the industry (such as those with manually added extended fields in the basic version) do not conform to the strict definitions of any standard version, and DBC parsing tools cannot properly parse these transitional DBC files.

[0042] In some embodiments, the information of each module in the DBC file can be parsed based on the line header information and then converted into JSON format for storage and use. However, this method does not solve the problem of poor fault tolerance. When a format error occurs, the parsing will be interrupted, and it cannot handle the non-standard DBC files commonly found in actual projects.

[0043] In other embodiments, regular expressions can be used to parse the module information in the DBC file before storage. However, this approach fails to effectively address compatibility issues with different historical versions of DBC files, leading to parsing failures when different historical versions of DBC files are required.

[0044] Therefore, improving the fault tolerance capability of parsing DBC files is an urgent problem to be solved.

[0045] Based on this, this application proposes a DBC file parsing method, device, vehicle, and storage medium, comprising: acquiring a DBC file to be parsed; determining multiple data units in the DBC file based on newline characters in the DBC file; for each data unit, determining the parsing type of the data unit according to the character identifiers included in the data unit; the character identifiers include: a start identifier and a crossover marker, the crossover markers include: a crossover start marker and a crossover end marker; the parsing type includes at least one of the following: a standard parsing type, a crossover start parsing type, and a crossover continuation parsing type; wherein, the standard parsing type is used to indicate that the data unit is a complete data unit; the crossover start parsing type is used to indicate that the data unit includes a start marker and a crossover start marker, but does not include a crossover end marker; the crossover continuation parsing type is used to indicate that the data of the data unit is a continuation of the previous data unit; according to the data type corresponding to the data unit, calling the parsing function corresponding to the data type to parse the data unit and obtain the parsing result; wherein, the data type of the standard parsing type and / or the crossover start parsing type is determined based on the start identifier of the data unit; the data type of the crossover continuation parsing type is determined based on the data type of other data units that are in the same closed crossover marker as the data unit. By identifying multiple data units within a DBC file based on newline characters, determining the parsing type of each data unit based on its character identifiers, and then determining its data type based on the parsing type, the corresponding parsing function is called to parse the data unit and obtain the parsing result. This effectively avoids complete parsing interruptions caused by cross-line data, ensuring the parsing continuity and data integrity of incomplete data units. It allows for the complete parsing of common non-standard cross-line data units in the vehicle industry without interrupting the overall parsing process, reducing the probability of parsing failures caused by cross-line data and thus improving the fault tolerance of DBC file parsing.

[0046] The following description, in conjunction with the accompanying drawings, introduces the DBC file parsing method, equipment, vehicle, and storage medium of this application.

[0047] like Figure 1 As shown, this application proposes a flowchart of a DBC file parsing system for processing DBC files. The DBC file parsing system includes: a file loading module 101, a status parsing engine 102, a main control module 103, and a memory management pool 104.

[0048] In this system, the hardware carrier of the DBC file parsing system is equivalent to a processor, such as a microprocessor (MCU) or a central processing unit (CPU), which provides computing resources and hardware control support for the operation of the entire parsing system.

[0049] In some embodiments, the file loading module 101 uses memory mapping technology, which can directly map the DBC file stored on the disk to the system's memory address space, establish a direct mapping relationship between the virtual address and the DBC file content, completely avoid the overhead of copying data between the disk and memory, and significantly improve file reading efficiency.

[0050] In some instances, the state parsing engine 102 defines several different parsing states, including the start state, version information parsing state, node list parsing state, message definition parsing state, signal definition parsing state, comment parsing state, cross-line comment parsing state, enumeration value table parsing state, cross-line enumeration value parsing state, attribute definition parsing state, and error state. Each state encapsulates specific parsing logic and behavioral rules, and state transitions are performed based on preset parsing trigger conditions (such as recognizing a specific keyword, reading a field end marker, etc.).

[0051] The state parsing engine 102 is implemented using the state design pattern, decoupling the behavioral logic of each parsing state from the state transition logic. This design not only ensures the efficiency of state transitions but also completely preserves the context information during the parsing process (such as the current parsing position and the field data already read). Even if an interruption occurs during cross-line parsing (such as cross-line comment or cross-line enumeration value parsing), the system can accurately restore the parsing state based on the saved context information and continue to complete subsequent parsing work.

[0052] In some instances, the main control module 103 includes a line parser component and a SIMD acceleration engine. The line parser component includes a line parser, a message parser, a signal parser, a comment parser, a cross-line comment parser, an enumeration value parser, and a cross-line enumeration value parser, etc. The line parser is responsible for the initial processing and classification of lines. During parsing, the line parser component sends a prefix parsing instruction to the SIMD acceleration engine. The SIMD acceleration engine uses a fast classification algorithm based on prefix matching and leverages Single Instruction Multiple Data Stream (SIMD) technology to accelerate the identification and matching process of line prefixes, enabling rapid identification of key prefixes such as BO_, SG_, CM_, and VAL_. After identifying the line prefixes, the corresponding parser is called to parse the DBC file and obtain the parsing results.

[0053] Specifically, when the key prefix is ​​BO_, the message parser is invoked; when the key prefix is ​​SG_, the signal parser is invoked; when the key prefix is ​​CM_, the comment parser is invoked; and when the key prefix is ​​VAL_, the enumeration value parser is invoked.

[0054] In some instances, message parsers can implement intelligent row caching mechanisms, reducing memory access latency through prefetching and caching optimizations. Simultaneously, during parsing, the specific line number position of each parsed element (such as a message or signal) in the DBC source file is recorded in real time, providing detailed location information for error reporting and debugging. For cross-line data parsing scenarios, cross-line comment parsers and cross-line enumeration value parsers handle cross-line logic specifically, ensuring the integrity and parsing continuity of cross-line data.

[0055] In some instances, memory management pool 104 is used to store objects created during DBC parsing (such as message objects, signal objects, node objects, annotation objects, enumeration value objects, etc.). After the DBC file is parsed, the parsing results are associated with the objects in memory management pool 104 to generate a CAN network model.

[0056] In some embodiments, such as Figure 2 As shown, the workflow of each module in the DBC file parsing system includes: Phase 1: Initialization and Data Loading (Loading the DBC File). First, the main control module sends a data loading request for the specified dataset file (DBC) to the file loading module. The file loading module uses memory mapping technology to directly map the DBC file in the storage medium to the process's virtual address space and returns the starting pointer of that memory region. This mechanism avoids the overhead of copying data from kernel mode to user mode in traditional I / O operations, achieving zero-copy loading and laying the foundation for subsequent high-speed processing.

[0057] Secondly, standardized preprocessing is performed automatically after the DBC file is loaded, including uniform conversion of newline characters (converting the \r\n format to \n) and encoding format recognition (such as UTF-8 encoding verification).

[0058] Finally, the main control module initializes and configures the state parsing engine (initializes the state machine). The state parsing engine resets its internal states to their initial states (e.g., ParseState::Start) and clears all cross-line processing context information (e.g., commentState and valTableState annotations), preparing for the processing of the first logical unit. During this stage, the memory management pool simultaneously performs warm-up operations, pre-allocating initial memory blocks to improve the efficiency of subsequent object creation.

[0059] Phase Two: Streaming Parsing Loop. First, the state parsing engine begins parsing line by line. The main control module uses a SIMD-optimized positioning algorithm to quickly identify the newline character "\n", achieving efficient data unit segmentation. It then submits the start and end pointer ranges of each unit in the memory-mapped area to the state parsing engine. The submission process only passes pointer references, not data copies, maintaining zero-copy characteristics (the content of the submitted line).

[0060] Secondly, after receiving the data unit, the state resolution engine determines one of the following three processing paths (resolution types) based on the current resolution state: Path A: Standard unit processing (standard resolution type), currently in the initial state.

[0061] Path B: Cross-line start processing (cross-line start parsing type), currently in the initial state, but an unclosed cross-line marker was detected in the parsing of this data unit.

[0062] Path C: Cross-line continuation processing (cross-line continuation parsing type), currently in a cross-line state.

[0063] Path A: Standard Unit (Standard Row) Processing Flow. 1) Real-time Parsing: The state parsing engine identifies the unit start identifier (e.g., BO_, SG_, CM_, VAL_) and calls the corresponding parsing function. These functions use efficient pointer arithmetic and finite state machines to extract tokens, including key information such as message identifier, signal name, and start bit, avoiding inefficient matching mechanisms such as regular expressions throughout the process; 2) Object Creation and Instantiation (State Parsing Engine → Memory Management Pool): After completing the extraction of key data, the state parsing engine requests the allocation of corresponding objects (e.g., message object Message, signal object Signal) from the memory management pool. The memory management pool directly returns the object pointer from the pre-allocated memory block, avoiding the performance overhead of system-level memory allocation. Subsequently, the state parsing engine fills the parsed data into the object instance and uses a string pool to internalize string constants, ensuring global uniqueness.

[0064] Path B: Cross-line Initiation (Cross-line Start) Processing Flow. 1) Cross-line State Activation (Internal Operation of State Parsing Engine): During the parsing of standard units (CM_ or VAL_ type), if an unclosed quotation mark is detected at the end of a line, the system immediately saves the current parsing context (including target identifier, signal name, partial parsing value, etc.) to a dedicated state structure and switches the global state to the corresponding cross-line mode; 2) Initialize Buffer (State Parsing Engine → Memory Management Pool): The state parsing engine requests a dynamically expandable dedicated buffer from the memory management pool to accumulate cross-line text fragments.

[0065] Path C: Cross-line continuation (Cross-line continuation) processing flow. Accumulated text and escape sequences processing (internal operation of the state resolution engine): For each data unit in a cross-line state, the state resolution engine directly appends its content to the allocated buffer without re-performing type recognition. During this process, the system processes escape sequences in real time (e.g., converting \n to a newline character and " to a quotation mark), and continuously monitors for the appearance of terminating quotation marks, achieving incremental construction of text fragments.

[0066] Phase Three: Model Generation and Result Return. Generating the CAN network model (State Resolution Engine → Main Control Module): Once all data units have been processed, the State Resolution Engine sends a resolution completion signal to the main control module. At this point, the resolution result is constructed in memory as a complete structured CAN network model. The CAN network model is formed by various objects (Message, Signal, ValueDescription, etc.) allocated from the memory management pool, linked by pointers to form an organic whole. The main control module finally returns the root object of the CAN network model (usually a container containing all messages, nodes, and metadata) to the caller.

[0067] Phase Four: Resource Management. The main control module or caller is ultimately responsible for destroying the memory management pool and releasing all mapped file memory and pre-allocated object memory.

[0068] In some embodiments, the execution subject of the DBC file parsing method provided in this application can be a DBC file parsing device. The DBC file parsing device can be deployed in an electronic device. The electronic device can be a server cluster composed of multiple servers, a single server, a computer, or any device or device with DBC file parsing function, such as a processor or processing chip in a server or computer. This application does not limit this.

[0069] like Figure 3 As shown, the DBC file parsing method of this application includes the following steps: S301. Obtain the DBC file to be parsed.

[0070] As one possible implementation, the main control module sends a data loading request to the file loading module. The data loading request carries the file path information (including the file name) of the DBC file to be parsed. The file loading module uses memory mapping technology to directly map the DBC file to be parsed in the storage medium (such as a disk) to the virtual address space (memory address) of the process. It returns the starting pointer and address range of the virtual address space of the DBC file to the main control module. Since a direct mapping relationship has been established between the virtual address and the content of the DBC file, the main control module can directly access and operate the DBC file data in memory by obtaining the starting pointer and address range without additional copying, thus efficiently obtaining the DBC file to be parsed.

[0071] S302. Based on the newline characters in the DBC file, determine multiple data units in the DBC file.

[0072] One possible implementation is to divide the DBC file into multiple data units (i.e., a line of data in the DBC file) using the identified newline character \n as the delimiter. The boundary of each data unit is marked by a "memory start pointer + memory end pointer" (no data copying is required, only the address range is recorded). The main control module submits the pointer range of each data unit to the status resolution engine, passing only addresses throughout the process to ensure that each segmented data unit can be directly processed by subsequent steps.

[0073] S303. For each data unit, determine the parsing type of the data unit based on the character identifiers included in the data unit.

[0074] The character identifiers include a start identifier and a line break marker. The line break marker includes a line break start marker and a line break end marker. The start identifier is a prefix in the DBC file that marks the data unit type (e.g., BO_ (message), SG_ (signal), CM_ (comment), VAL_ (enumeration value)), identified by the state parsing engine when parsing the beginning of a data unit. The line break markers include a line break start marker (e.g., an unclosed quotation mark " in a CM_ comment, or an unclosed bracket { in a VAL_ enumeration value)) and a line break end marker (e.g., a closed quotation mark ", or a closed bracket}), detected by the state parsing engine when parsing the end or middle of a data unit.

[0075] The parsing type includes at least one of the following: standard parsing type, cross-line start parsing type, and cross-line continuation parsing type; wherein, the standard parsing type is used to indicate that the data unit is a complete data unit; the cross-line start parsing type is used to indicate that the data unit includes a start marker and a cross-line start marker, but does not include a cross-line end marker; and the cross-line continuation parsing type is used to indicate that the data in the data unit is a continuation of the previous data unit.

[0076] As one possible implementation, the parsing type of a data unit can be determined as follows: if the current state of the state parsing engine is the initial state (ParseState::Start), and the data unit contains a complete start identifier (such as BO_) and has no unclosed start markers for cross-line transitions (i.e., the data unit is complete and does not require continuation by subsequent units), then the parsing type of the data unit can be determined to be the standard parsing type.

[0077] The current state of the state parsing engine is the initial state. The data unit contains a start identifier (CM_ or VAL_), and a cross-line start marker (such as an unclosed "" at the end of the line) is detected. There is no cross-line end marker (i.e., the "" is not closed, and the data needs to be continued by subsequent units). It can be determined that the parsing type of the data unit is the cross-line start parsing type.

[0078] The current state of the state parsing engine is a cross-line state (such as the multi-line comment state CommentMultiLine). The data unit has no new start identifier and is only a continuation of the content of the previous data unit (cross-line start type) (which needs to be associated with the cross-line mark of the previous unit). It can be determined that the parsing type of the data unit is a cross-line continuation parsing type.

[0079] For example, a DBC file contains three consecutive rows of data units: CM_SG_100 Speed ​​"Vehicle speed signal, unit km / h"; / / Data unit 1 CM_SG_101 Accel "Vehicle acceleration signal, used to determine rapid acceleration / deceleration status, sampling frequency is 10Hz, / / Data unit 2" "Needs to be linked with braking signals to determine driving safety"; / / Data Unit 3 For data unit 1, the starting identifier CM_SG_ of the annotation is included, which clearly indicates that the data type is a signal annotation. The annotation content is enclosed in "complete (starting " + ending "). The data unit itself is complete annotation information and does not need to be continued in subsequent units.

[0080] For data unit 2, the starting identifier CM_SG_ of the comment indicates that the data type is signal comment. The line ends with only a start marker for the start of a new line (the beginning of the comment content, but without an end marker), indicating that the comment is incomplete and needs to be continued in subsequent units.

[0081] For data unit 3, there are no new start markers (such as CM_ / BO_ / SG_), and the current parsing state is already in the cross-line comment state (triggered by data unit 2). The data content is a continuation of the comment in data unit 2 and contains a cross-line end marker (the end of the comment content "), indicating that it is a complete comment belonging to the "same closed cross-line marker" as data unit 2.

[0082] S304. Based on the data type corresponding to the data unit, call the parsing function corresponding to the data type to parse the data unit and obtain the parsing result.

[0083] The data types of standard parsing types and / or cross-line start parsing types are determined based on the starting identifier of the data unit; the data types of cross-line continuation parsing types are determined based on the data types of other data units that are in the same closed cross-line marker as the data unit.

[0084] As one possible implementation, the data type corresponding to a data unit is determined in the following ways: If the starting identifier of the data unit is VERSION, the data type is determined to be a version definition; or, if the starting identifier of the data unit is BU, the data type is determined to be a node list definition; or, if the starting identifier of the data unit is BO, the data type is determined to be a message definition; or, if the starting identifier of the data unit is SG, the data type is determined to be a signal definition; or, if the starting identifier of the data unit is CM, and the parsing type of the data unit is a standard parsing type and / or a cross-line start parsing type, the data type is determined to be an annotation definition; or... If the starting identifier of other data units within the same closed crossover marker is CM, and the data unit's resolution type is a crossover continuation resolution type, then the data unit's data type is determined to be a crossover comment definition; or, if the starting identifier of a data unit is VAL, and the data unit's resolution type is a standard resolution type and / or a crossover initiation resolution type, then the data unit's data type is determined to be an enumeration value definition; or, if the starting identifier of other data units within the same closed crossover marker is VAL, and the data unit's resolution type is a crossover continuation resolution type, then the data unit's data type is determined to be a crossover enumeration value definition; or, if the data unit contains attributes of objects defined in a DBC file, then the data unit's data type is determined to be an attribute definition.

[0085] As one possible implementation, when the parsing type is a standard parsing type, the parsing function corresponding to the data type of the data unit is called to parse the data unit and obtain the parsing result. This can be implemented as follows: based on the data type of the data unit, the corresponding parsing function is called; based on the parsing function, the content of the data unit is extracted to obtain the parsed data; the object corresponding to the parsed data and the memory address of the object are determined; the memory address of the object is the address in the pre-allocated memory block; the parsed data is filled into the object to obtain the parsing result of the data unit.

[0086] As one possible implementation, when the parsing type is cross-line start parsing, the parsing function corresponding to the data type of the data unit is called to parse the data unit and obtain the parsing result, including: when the data type of the data unit is a comment or an enumeration value, the parsing function corresponding to the comment or enumeration value is called to parse the data unit and obtain the parsed data of the data unit; a buffer is constructed and the parsed data of the data unit is saved to the buffer.

[0087] As one possible implementation, when the parsing type is a cross-line continuation parsing type, the parsing function corresponding to the data type of the data unit is called to parse the data unit and obtain the parsing result. This includes: when the data type corresponding to the data unit is a comment or an enumeration value, for each subsequent data unit within the same closed cross-line marker, the content of each subsequent data unit is added to the buffer until a terminating quote is detected, thus obtaining the parsed data of multiple data units within the same closed cross-line marker; the parsed data is then associated with the data unit object to obtain the parsing result of multiple data units within the same closed cross-line marker.

[0088] For example, taking the three consecutive data units in the DBC file in the example above as an example, for data unit 1, the main control module calls the annotation parsing function to directly extract the signal ID (101) and the annotation content ("vehicle driving speed signal, unit km / h"), and generate a complete annotation parsing result.

[0089] For data unit 2, the annotation parsing function is called to first extract the signal ID (101) and the partially entered annotation text ("Vehicle acceleration signal, used to determine rapid acceleration / deceleration state, sampling frequency is 10Hz,"), save the current parsing context (signal ID, partially annotation text), switch the parsing state to cross-line annotation state, apply for a dynamic buffer, temporarily store the incomplete annotation text, and wait for subsequent units to supplement it.

[0090] For data unit 3, there is no need to call the annotation parsing function again. Instead, the cross-line annotation function is called directly to append the text of data unit 3 ("Needs to be linked with the braking signal to determine driving safety") to the dynamic buffer. This is then concatenated with a portion of the annotation from data unit 2. After detecting the end " (cross-line end marker), aggregation stops, and a complete annotation ("Vehicle acceleration signal, used to determine rapid acceleration / deceleration state, sampling frequency is 10Hz, needs to be linked with the braking signal to determine driving safety") is generated. The system then switches back to the initial state.

[0091] Therefore, by identifying multiple data units in a DBC file based on newline characters, determining the parsing type of the data unit based on the character identifiers included in the data unit, and then determining the data type of the data unit based on the parsing type, the corresponding parsing function is called to parse the data unit and obtain the parsing result. When there is data spanning multiple lines, parsing the data unit based on the cross-line start parsing type and cross-line continuation parsing type can effectively avoid the complete interruption of parsing caused by cross-line data, ensuring the parsing continuity and data integrity of incomplete data units. This allows non-standard data units with cross-line data, which are common in the vehicle field, to be parsed completely without interrupting the overall parsing process, reducing the probability of parsing failure caused by cross-line data, and thus improving the fault tolerance of DBC file parsing.

[0092] In some embodiments, cross-line comment parsing can be achieved through state machine control and buffer collaboration to fully extract comment text across multiple lines, such as... Figure 4 As shown, the parsing process for the above cross-line comment includes: S401. If the starting identifier of the data unit is identified as CM_, determine the type of annotation.

[0093] The types of annotations include: messages, nodes, and signals.

[0094] As one possible implementation, when the starting character of a data unit is CM_ (a distinctive prefix for comments), the book type of the data unit is determined to be a comment definition. The comment type is determined by using a prefix matching algorithm, combined with the subsequent characters (BO_ / SG_ / BU_) after CM_. CM_BO_ corresponds to a message comment, CM_SG_ corresponds to a signal comment, and CM_BU_ corresponds to a node comment.

[0095] In one possible implementation, a Deterministic Finite Automaton (DFA) can be used to determine the type of the annotation. The principle of a DFA is to match a unique path in the input string using predefined states and strict state transition rules. For the syntax rules of DBC annotations, the DFA predefines a series of states; for example, CM_BO_ corresponds to the message annotation state. Type determination is performed by scanning character by character to advance the state transition. Starting from the initial state, when the character C→M→_ (a complete match of the CM_ prefix) is encountered, the system automatically enters the waiting state for the type identifier. In this state, subsequent characters are scanned one by one, triggering a unique transition according to the character sequence matching rules. If the input character is B and the following character is O_, then the system uniquely transitions to the message annotation state.

[0096] Understandably, in DBC annotation parsing, deterministic finite automata ensure the accuracy of annotation type judgment and parameter extraction by predefined state-corresponding annotation formats and strict transition rules to eliminate ambiguity. At the same time, with its linear scanning, no backtracking, parameter extraction and state synchronization characteristics, it is adapted to the needs of automotive electronics scenarios for accurate and error-free parsing of DBC files and fast response, avoiding the misjudgment or inefficiency problems that may occur in traditional methods (such as complex regular expressions and multi-layer if-else statements).

[0097] S402. When the annotation type is signal, determine the starting quotation mark of the annotation text and begin accumulating the annotation text.

[0098] Understandably, in the CAN network defined by the DBC file, a signal (SG_) is the smallest data unit that carries actual physical meaning (such as "vehicle speed signal" or "engine speed signal"). The annotation text of a signal is not simply descriptive text; it usually contains the functional logic of the signal, and this information directly determines the ECU's signal processing strategy.

[0099] As one possible implementation, the parser locates the starting quotation mark (in English, "; in DBC syntax, the comment text must be enclosed in quotation marks) of the comment text in the signal comment line. Once found, it immediately starts the text accumulation mechanism, taking the characters after the starting quotation mark as the beginning part of the comment text and storing it in a temporary buffer.

[0100] It should be understood that this step is the starting point for text parsing, providing initial text fragments for subsequent escaping and cross-line accumulation.

[0101] S403. If no closing quotation mark is detected at the end of the line of the starting data unit of the parsed comment text, save the parsed data of the starting data unit of the comment text, and append the parsed content of subsequent data units to the accumulated comment text until the closing quotation mark of the comment text is detected, and obtain the comment text after the data unit is parsed.

[0102] As one possible implementation, when parsing the starting data unit (the line containing the signal comment), if no closing quotation mark is detected at the end of the line (i.e., the comment text is not closed), it is determined to be a cross-line comment. Key parsed data of the starting data unit is saved, including the comment type (signal comment), the associated signal identifier (such as the signal ID), the accumulated partial text, the current escape processing status (such as whether it is in escape mode), and the starting line number, ensuring traceability of the parsing process. Subsequent data units (cross-line lines) skip the regular parsing process and directly append the content to a temporary buffer, while simultaneously processing escape sequences in real time (such as converting \n to a newline character and \" to a quotation mark); accumulation stops when a closing quotation mark is detected, and the complete content in the buffer is used as the parsed comment text.

[0103] It should be understood that the processing of escape sequences is a key step in ensuring the accurate restoration of text content. By precisely switching between "normal state → escape state → normal state", normal characters and escape characters can be distinguished, and special symbols (such as quotation marks and backslashes) can be avoided from being misjudged as comment end marks.

[0104] In one possible implementation, the normal state, escape state, and end state are determined according to the comment text syntax rules of the DBC file. In the normal state, characters in the comment text are parsed normally, and all characters are assumed to be unescaped. In the escape state, characters are only entered after a backslash is encountered; in this state, the next character is considered part of the escape sequence. In the quotation mark state, the comment text is marked as ended, and subsequent characters are no longer treated as text. In the escape state, encountering a backslash \: converts \\ to a literal backslash \ and switches back to the normal state; encountering a quotation mark ": converts \" to a literal quotation mark " and switches back to the normal state; encountering n: converts \n to a newline character (\n) and switches back to the normal state; encountering t: converts \t to a tab character (\t) and switches back to the normal state; encountering other characters (such as unrecognizable sequences like x, a, etc.): a conservative strategy is adopted, preserving the original character (e.g., \x is directly preserved as text), and switching back to the normal state.

[0105] S404. Determine the target object corresponding to the comment text and the memory address of the target object.

[0106] As one possible implementation, the target object corresponding to the signal annotation is determined based on the type of the signal annotation, that is, the specific signal associated in S402 (which can be located by the signal identifier, such as signal ID or name). The parser queries the memory address of the signal object from the memory management pool (because the signal object has been instantiated and allocated memory in the early stage of parsing) to ensure that subsequent association operations can directly access the target object.

[0107] S405. Associate the parsed comment text with the memory address of the target object to obtain the cross-line comment parsing result.

[0108] As one possible implementation, the parsed comment text is internalized through a string table (only one copy of the same text is stored, reducing memory usage). The parser binds the processed comment text to the memory address of the target signal object obtained by S404, and writes the text address into the comment field of the signal object. After binding, a multi-line comment parsing result (containing the signal object, the complete comment text, and the associated relationships) is generated.

[0109] like Figure 5 As shown below, an example illustrates the parsing process of multi-line comments.

[0110] The parser begins parsing the CM_ line, then precisely identifies the comment type based on subsequent characters: BO_ indicates a message comment, SG_ indicates a signal comment, and BU_ indicates a node comment. For message comments, the parser parses the message ID; for node comments, it parses the node name; and for signal comments, it parses the message identifier (message ID) and signal name. The message identifier is a 32-bit unsigned integer, while the signal name is a variable-length string. This process is implemented using a deterministic finite automaton (a mathematical model for accurately identifying and processing string patterns, which efficiently and unambiguously determines the comment type and extracts key parameters through predefined state transition rules), ensuring accuracy and efficiency in the identification process.

[0111] The second stage of text accumulation and escaping processing employs a state machine-based streaming approach (starting the parsing of comment text). The parser first locates the initial quotation mark character in the comment text and then initiates the text accumulation process. During this second stage, the parser needs to handle various escape sequences in real time: a backslash followed by another backslash represents a literal backslash character, a backslash followed by a quotation mark represents a literal quotation mark character, a backslash followed by 'n' represents a newline character, and a backslash followed by 't' represents a tab character. For unrecognized escape sequences, the parser adopts a conservative strategy, preserving the original character. The entire processing is implemented through a state transition mechanism, precisely switching between normal, escape, and quotation mark states based on the input character.

[0112] The third stage, cross-line state management, handles cases where comment text spans multiple lines. When the parser detects that the comment text is not yet closed (i.e., no closing quotation mark is encountered) at the end of the current line, it automatically enters multi-line mode and reads the next line. In multi-line mode, the parser saves the complete parsing context, including the comment type, target object identifier, accumulated text content, escape processing status, and starting line number, until it encounters a closing quotation mark. Upon encountering a closing quotation mark, it searches for a semicolon terminator. If a semicolon is found, the comment analysis is completed; otherwise, it attempts to complete the analysis.

[0113] The fourth stage, annotation object creation, completes the final annotation processing. The parser first allocates annotation objects from a dedicated memory pool, then processes the accumulated text content using escape sequences, converting these sequences into actual character representations. The processed text strings are then fed into a string table for internalization, ensuring that strings with identical content are stored only once. Finally, the parser associates the annotation objects with the target message, signal, or node object, completing the entire annotation parsing process.

[0114] Therefore, by identifying the starting identifier of the data unit, the annotation text accumulation begins when the starting quotation mark is detected. If the ending quotation mark is not detected, the text is appended until the ending quotation mark is detected by saving the parsing context. Even if the annotation text is distributed in multiple data units, it can be aggregated into complete content, avoiding the complete interruption of parsing caused by cross-line structure.

[0115] In some embodiments, cross-row enumeration value parsing can be achieved through a five-state automaton controlled in cooperation with a buffer, enabling complete extraction of enumeration values ​​across multiple rows, such as... Figure 6 As shown, the parsing process for cross-row enumeration values ​​includes: S601. If the starting identifier of the data unit is identified as VAL_, determine the target object of the data unit.

[0116] As one possible implementation, when the parser detects that a data unit begins with VAL_ (the starting identifier of the enumeration value), it automatically starts the enumeration value parsing process, extracts the message identifier and signal name, identifies the numeric sequence after VAL_ (such as 201 in VAL_201 FaultCode), performs base conversion (ensuring it is decimal) and range checks (conforming to the 32-bit unsigned integer specification) to avoid invalid IDs, identifies the string after the message identifier (such as FaultCode), verifies whether it conforms to the DBC naming convention (such as no special characters, not exceeding the length limit), and ensures that the signal identifier is unique.

[0117] The parser first finds the corresponding message object in the parsed message set by using the message identifier; then, in the signal list of the message object, it locates the specific target signal object (i.e., the signal that the enumeration value is associated with) by using the signal name.

[0118] S602. Parse the contents of the starting data unit of the enumeration value to obtain the value-description pair, and start accumulating the data-description pair.

[0119] As one possible implementation, a five-state automaton is used to parse the value-description pairs (such as 1-"sensor failure") of the enumeration in the initial data unit and start the accumulation mechanism. Specifically, the automaton can be implemented by switching between five states to parse the enumeration values ​​based on the syntax characteristics (value + description text) of the enumeration values ​​in the VAL_ initial data unit.

[0120] In one possible implementation, the five-state switching process for parsing enumerated values ​​can be implemented as follows: Waiting for a value state: the initial state, only expecting numbers or positive / negative signs (e.g., 1 or -5). Upon detection, it switches to the parsing value state. Parsing value state: handles various numerical formats (integer 2, floating-point 3.5, scientific notation 1e4), supporting positive / negative signs, decimal points, and exponent markers (e / E). After parsing, it switches to the waiting for a description state. Waiting for a description state: only expects the opening quotation mark (") of the description text. Upon detection, it switches to the parsing description state. Parsing description state: extracts the text within the quotation marks (e.g., sensor malfunction). After processing, it switches back to the waiting for a value state, preparing to parse the next pair of enumerated values. After each pair of "value (e.g., 1) + description text (e.g., sensor malfunction)" is parsed, the parser stores this value-description pair in a temporary buffer, initiating data-description text accumulation to prepare for possible subsequent cross-line processing or final sorting.

[0121] S603. If no closing quotation mark is detected at the end of the line of the enumeration value starting data unit, save the parsed data of the enumeration value starting data unit and append the parsed content of subsequent data units to the accumulated data-description pair until a closing quotation mark is detected.

[0122] As one possible implementation, when parsing the end of the line of the starting data unit, if no closing quotation mark (") of the description text is detected, it is determined to be a cross-line description, and the cross-line parsing mode is automatically entered. In order to avoid information loss after the parsing is interrupted, the system saves the complete context: including message identifier, signal name, accumulated value-description pairs, the value currently being processed, the accumulated partial description text, and the current parsing state of the automaton.

[0123] For each subsequent line of data read, skipping the regular VAL_ prefix recognition and parameter extraction process, the parser appends the descriptive text fragment in the new line to a temporary buffer, continuing to append until the closing quotation mark (") of the descriptive text is detected.

[0124] S604. Sort the accumulated data-description pairs in the data-description text according to the numerical values ​​from smallest to largest, associate the sorted data-description pairs with the target object, and obtain the cross-line enumeration value parsing result.

[0125] As one possible implementation, all the value-description pairs accumulated by the parser are sorted according to the rules of ascending values ​​(e.g., 1-"sensor fault" → 2-"communication interruption" → 3-"power supply abnormality"), which facilitates the ECU or testing tools to quickly find the description of the corresponding value. The parser establishes an association between the sorted set of value-description pairs and the target signal object (e.g., FaultCode signal) determined by S601 (e.g., writing the memory address of the set into the enumeration value field of the signal object). After the association is completed, a cross-line enumeration value parsing result is generated (containing the target signal object, the sorted set of value-description pairs, and the parsing status).

[0126] In one possible implementation, the description text can be internalized as a string before sorting, storing the same description text only once and reducing memory usage by reusing reference addresses.

[0127] like Figure 7 As shown, the parsing of cross-row enumeration values ​​employs a fine-grained processing flow based on a state machine. In the first stage, parsing of the `VAL_` row begins, determining if it is the first row. If so, the message identifier (message ID) and signal name are parsed; otherwise, parsing continues. The message identifier is a sequence of numbers, and the parser performs base conversion and range checks. The signal name is an identifier string that must conform to the naming conventions of the DBC file. After extracting the parameters, the parser searches for the corresponding message object in the already parsed message set, and then searches for the target signal object in the signal list of the message object.

[0128] The second stage, the value pair parsing stage, employs a five-state automaton for fine-grained control. First, the numerical values ​​are parsed, then the descriptions. The waiting-for-numerical-values ​​state anticipates the appearance of numeric or symbolic characters; once these characters are detected, the state transitions to parsing-numerical-values. This state handles various numerical formats, including integers, floating-point numbers, and scientific notation, supporting syntax elements such as plus / minus signs, decimal points, and exponent markers. After parsing the numerical values, the state transitions to the waiting-for-description-values ​​state, awaiting the opening quotation mark of the description text. Upon encountering the quotation mark, the state enters the parsing-for-description-values ​​state to begin processing the description text. After processing the description text, the state returns to the waiting-for-numerical-values ​​state, ready to process the next value pair.

[0129] The third stage checks for closed quotation marks. If a closed quotation mark is encountered, the value description is saved. If not, multi-line mode is entered, and context information is saved, including the message identifier, signal name, set of parsed value description pairs, currently processed value, currently accumulated description text, and parsing status. The next line is then read until a closed quotation mark in the description text is detected. A semicolon is then checked. If a semicolon is encountered, VAL_ parsing is completed. If not, value parsing continues.

[0130] The fourth stage, value description optimization and association, completes the final data processing. The parser first sorts all value description pairs in ascending order of value for easier searching and use later. Then, it internalizes the description text for each value description, ensuring that identical description text is stored only once. Finally, the parser establishes an association between the optimized set of value descriptions and the target signal object, completing the entire enumeration value parsing process.

[0131] Therefore, in DBC files, the description text of enumeration values ​​is often stored across multiple lines due to its excessive length. By monitoring the presence of closing quotes and using a mechanism for accumulating data-description pairs, cross-line enumeration value parsing can completely aggregate description text across multiple lines, ensuring that data loss caused by format splitting is prevented.

[0132] In some embodiments, errors may occur during the parsing process. Real-time detection and recovery strategies can be used to improve the fault tolerance and problem traceability of the parsing process, such as... Figure 8 As shown, the above method also includes: S801. In response to an error occurring during the parsing of a DBC file, classify the errors according to their severity.

[0133] The error categories include: recoverable errors, partially recoverable errors, and unrecoverable errors.

[0134] Recoverable errors: These are surface formatting issues that do not affect the core parsing logic, such as missing quotation marks (the description text is not closed) or missing semicolons (the statement is not terminated). These errors can be automatically repaired or skipped by the system.

[0135] Partially recoverable errors: These are semantic-level issues that affect local parsing results but do not interrupt the overall process, such as numerical format errors or identifier conflicts (the same signal name is defined repeatedly). These errors can be partially handled (e.g., by replacing them with default values) and parsing can continue.

[0136] Unrecoverable errors: These are system-level or structural problems that can cause the parsing logic to be completely interrupted, such as file structure corruption or insufficient memory. Such errors require termination of the parsing process.

[0137] As one possible implementation, the parser may encounter parsing errors at key stages such as character input, structure parsing, state transitions, and processing long, multi-line text. The parser employs a parsing-and-detection model, triggering error checks at critical points. During character input: Each character read (e.g., quotation marks, numbers, escape characters) is immediately checked for compliance with the current syntax context (e.g., encountering unescaped quotation marks in a string). During structure parsing: When extracting key parameters (e.g., message ID, signal bit length), the format validity is checked (e.g., whether the message ID is a 32-bit unsigned integer). During state transitions: Based on the transition rules of the DFA state machine, a format error is triggered when the input character does not conform to the expected state (e.g., BO_ / SG_ / BU_ does not appear after the CM_ prefix). During processing long, multi-line text: For multi-line comments (e.g., unterminated descriptive text), continuation rules are checked at line breaks (e.g., whether it ends with an escape character).

[0138] S802. Execute the corresponding error recovery strategy according to the type of error.

[0139] As one possible implementation, error recovery is possible for: Missing quotes: By analyzing the context (such as newline positions and subsequent syntax markers), the appropriate position of the quotes is intelligently inferred, and virtual quotes are inserted to close the text, ensuring that cross-line text parsing can continue. Missing semicolons: The position of the semicolon is inferred by searching for the end of the current line or the prefix of the next line (such as CM_ / VAL_, etc.), and virtual semicolons are automatically inserted to terminate the current statement. Invalid escape sequences: A conservative strategy is adopted to preserve the original characters (such as \x, which is preserved as is), while recording warnings and not interrupting text accumulation.

[0140] Partially recoverable errors: Numerical format error: Replace invalid numerical values ​​with preset default values ​​(such as message ID default value 0), record error information (such as "numerical value -123 does not conform to the 32-bit unsigned integer specification, has been replaced with 0"), and continue parsing subsequent content. Identifier conflict: Retain the identifier parsed initially, mark subsequent conflicting items as duplicate definitions, and do not affect the parsing of other non-conflicting items.

[0141] Syntax errors (e.g., recoverable errors): Limit the error to the current data unit (row) and avoid affecting the parsing of other rows through virtual repair (e.g., completing quotation marks). Semantic errors (e.g., partially recoverable errors): Store the error information in a temporary data structure and process it uniformly after parsing is completed, without interrupting the real-time parsing process.

[0142] S803. In the event that the error cannot be recovered, generate an error report.

[0143] The error report includes: error location, error description, and repair suggestions.

[0144] As a possible implementation, for unrecoverable errors that cannot be resolved through recovery strategies, the parsing process is terminated and report generation is initiated. The core report content includes: error location, error description, and remediation suggestions. Error location: Precise location information down to the filename, line number, and column number. Error description: A description of the error's nature and cause in natural language (e.g., corrupted file structure: line 5 is missing the message definition keyword BO_, causing subsequent signal parsing to lack an associated object). Remediation suggestions: Specific modification solutions are provided (e.g., checking if BO_ is missing from line 5, ensuring the message definition format is 'BO_Message ID Message Name: Sending Node') and best practices (e.g., referring to the message definition format in Section 3 of the DBC specification). Error statistics (e.g., 1 unrecoverable error detected, 0 recoverable errors) are included to form a complete quality assessment report, helping users fully understand the file issues.

[0145] like Figure 9 As shown, during DBC file parsing, error handling and recovery mechanisms need to cover the entire process from character-level to structure-level detection, and design targeted handling strategies for different types of errors to ensure that the parser can accurately locate the problem, provide effective feedback, and continue parsing subsequent content as much as possible when encountering exceptions. The following is the error handling process: During the parsing process, the parser adopts a parsing-and-detecting mode, triggering error checks in real time at key nodes, specifically including: syntax checking and semantic verification. Syntax checking includes surface errors such as token format, delimiter usage, and quotation mark matching; semantic verification includes deeper errors such as identifier uniqueness, numerical range, and signal length.

[0146] If a parsing error occurs, the error category is determined. Error categories include recoverable errors and unrecoverable errors. Recoverable errors include surface formatting issues such as missing quotes, missing semicolons, and invalid escape sequences, which the system can automatically repair or skip. Partially recoverable errors include semantic issues such as numeric format errors and identifier conflicts, which the system can partially handle and continue running. Unrecoverable errors include system-level problems such as corrupted file structure and insufficient memory, requiring the parsing process to terminate.

[0147] For recoverable errors, attempt automatic repair. Error recovery strategies include at least one of the following: Missing quotation marks: automatically add; Missing semicolons: intelligent inference; Illegal escape sequences: replacement handling; Error format: skip recovery. For unrecoverable errors, log the critical error and terminate parsing. Attempt automatic repair, determine if the repair was successful, and if so, continue parsing. If not, log the error, skip the erroneous segment, and continue parsing.

[0148] Therefore, when parsing DBC files, if an error occurs, by determining the type of error and calling the corresponding recovery strategy for repair, it is possible to avoid a complete interruption of parsing due to local format abnormalities, preserve the parsing results of subsequent normal data, and ensure the continuity of the parsing process. In the case of unrecoverable errors, an error report is generated, which can provide accurate error location, clear error nature description and repair suggestions, and significantly reduce the time cost of troubleshooting and DBC file correction.

[0149] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the DBC file parsing device or electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0150] This application embodiment can, based on the above method, exemplarily divide a DBC file parsing device or electronic device into functional modules. For example, the DBC file parsing device or electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0151] In some embodiments, refer to Figure 10 The DBC file parsing device 1000 provided in this application embodiment includes: an acquisition unit 1001 and a processing unit 1002.

[0152] Unit 1001 is used to obtain the DBC file to be parsed.

[0153] Processing unit 1002 is used to determine multiple data units in a DBC file based on newline characters in the DBC file; for each data unit, it determines the parsing type of the data unit according to the character identifiers included in the data unit; the character identifiers include: a start identifier and a crossover marker, and the crossover markers include: a crossover start marker and a crossover end marker; the parsing type includes at least one of the following: standard parsing type, crossover start parsing type, and crossover continuation parsing type; wherein, the standard parsing type is used to indicate that the data unit is a complete data unit; the crossover start parsing type is used to indicate that the data unit includes a start marker and a crossover start marker, but does not include a crossover end marker; the crossover continuation parsing type is used to indicate that the data of the data unit is a continuation of the previous data unit; according to the data type corresponding to the data unit, it calls the parsing function corresponding to the data type to parse the data unit and obtain the parsing result; wherein, the data type of the standard parsing type and / or the crossover start parsing type is determined based on the start identifier of the data unit; the data type of the crossover continuation parsing type is determined based on the data type of other data units that are in the same closed crossover marker as the data unit.

[0154] In some embodiments, the data type corresponding to a data unit is determined in the following ways: If the starting identifier of the data unit is VERSION, the data type is determined to be a version definition; or, if the starting identifier of the data unit is BU, the data type is determined to be a node list definition; or, if the starting identifier of the data unit is BO, the data type is determined to be a message definition; or, if the starting identifier of the data unit is SG, the data type is determined to be a signal definition; or, if the starting identifier of the data unit is CM, and the parsing type of the data unit is a standard parsing type and / or a cross-line start parsing type, the data type is determined to be an annotation definition; or, in the case of... If the starting identifier of other data units within the same closed cross-line marker is CM, and the data unit's parsing type is a cross-line continuation parsing type, then the data unit's data type is determined to be a cross-line comment definition; or, if the starting identifier of a data unit is VAL, and the data unit's parsing type is a standard parsing type and / or a cross-line initiation parsing type, then the data unit's data type is determined to be an enumeration value definition; or, if the starting identifier of other data units within the same closed cross-line marker is VAL, and the data unit's parsing type is a cross-line continuation parsing type, then the data unit's data type is determined to be a cross-line enumeration value definition; or, if the data unit contains attributes of objects defined in a DBC file, then the data unit's data type is determined to be an attribute definition.

[0155] In some embodiments, when the parsing type is a standard parsing type, the processing unit 1002 is specifically used to call the corresponding parsing function based on the data type corresponding to the data unit; extract the content of the data unit based on the parsing function to obtain parsed data; determine the object corresponding to the parsed data and the memory address of the object; the memory address of the object is the address in the pre-allocated memory block; and fill the parsed data into the object to obtain the parsing result of the data unit.

[0156] In some embodiments, when the parsing type is a cross-line start parsing type, the processing unit 1002 is specifically used to call the parsing function corresponding to the comment or enumeration value to parse the data unit when the data type corresponding to the data unit is a comment or an enumeration value, to obtain the parsed data of the data unit; construct a buffer and save the parsed data of the data unit to the buffer.

[0157] In some embodiments, when the parsing type is a cross-line continuation parsing type, the processing unit 1002 is specifically used to, when the data type corresponding to the data unit is a comment or an enumeration value, add the content of each subsequent data unit to the buffer for each subsequent data unit within the same closed cross-line marker until a terminating quotation mark is detected, thereby obtaining parsed data of multiple data units within the same closed cross-line marker; and associate the parsed data with the object of the data unit to obtain the parsing result of multiple data units within the same closed cross-line marker.

[0158] In some embodiments, the processing unit 1002 is specifically configured to: determine the type of annotation when the starting identifier of the data unit is identified as CM_; the annotation type includes: message, node, and signal; when the annotation type is signal, determine the starting quotation mark of the annotation text and start accumulating the annotation text; if no ending quotation mark is detected at the end of the line of the parsed annotation text starting data unit, save the parsed data of the annotation text starting data unit, and append the parsed content of subsequent data units to the accumulated annotation text until the ending quotation mark of the annotation text is detected, thereby obtaining the annotation text after parsing the data unit; determine the target object corresponding to the annotation text and the memory address of the target object; associate the parsed annotation text with the memory address of the target object to obtain the cross-line annotation parsing result.

[0159] In some embodiments, the processing unit 1002 is specifically configured to: determine the target object of the data unit when the starting identifier of the data unit is identified as VAL_; parse the content of the starting data unit of the enumeration value to obtain a value-description pair and start accumulating the data-description pair; save the parsed data of the starting data unit of the enumeration value when no closing quotation mark is detected at the end of the line of the starting data unit of the enumeration value, and append the parsed content of subsequent data units to the accumulated data-description pair until a closing quotation mark is detected; sort the value-description pairs in the accumulated data-description text according to the numerical values ​​from smallest to largest, associate the sorted value-description pairs with the target object, and obtain the cross-line enumeration value parsing result.

[0160] In some embodiments, the processing unit 1002 is further configured to classify errors according to their severity in response to errors occurring during the parsing of DBC files; the error categories include: recoverable errors, partially recoverable errors, and unrecoverable errors; execute corresponding error recovery strategies according to the error categories; and generate an error report if the error cannot be recovered; the error report includes: error location, error description, and repair suggestions.

[0161] like Figure 11 As shown, the electronic device 1100 provided in this application embodiment includes, but is not limited to, a processor 1101 and a memory 1102.

[0162] The memory 1102 described above is used to store the executable instructions of the processor 1101. It is understood that the processor 1101 is configured to execute instructions to implement the methods in the above embodiments.

[0163] It should be noted that those skilled in the art will understand that Figure 11 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 11 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0164] Processor 1101 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 memory 1102, and by calling data stored in memory 1102, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 1101 may include one or more processing units. Optionally, processor 1101 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 processor 1101.

[0165] The memory 1102 can be used to store software programs and various data. The memory 1102 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 1102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0166] In an exemplary embodiment, a vehicle is also provided, including the electronic equipment described above, for implementing the methods described above.

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

[0168] In actual implementation, Figure 10 The functions of the acquisition unit 1001 and the processing unit 1002 can both be provided by Figure 11 The processor 1101 calls the computer program stored in the memory 1102 to implement the process. The specific execution process can be found in the method section of the previous embodiment, and will not be repeated here.

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

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

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

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

[0173] 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 apparatus, 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 apparatuses or units may be electrical, mechanical, or other forms.

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

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

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

[0177] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A method for parsing DBC files, characterized in that, The method includes: Obtain the DBC file to be parsed; Based on the newline characters in the DBC file, multiple data units in the DBC file are determined; For each data unit, the parsing type of the data unit is determined based on the character identifiers included in the data unit; the character identifiers include: a start identifier and a line break marker, the line break markers include: a line break start marker and a line break end marker; the parsing type includes at least one of the following: a standard parsing type, a line break start parsing type, and a line break continuation parsing type; wherein, the standard parsing type is used to indicate that the data unit is a complete data unit; the line break start parsing type is used to indicate that the data unit includes the start marker and the line break start marker, but does not include the line break end marker; the line break continuation parsing type is used to indicate that the data in the data unit is a continuation of the previous data unit; Based on the data type corresponding to the data unit, the parsing function corresponding to the data type is called to parse the data unit and obtain the parsing result; wherein, the data type of the standard parsing type and / or the cross-line start parsing type is determined based on the start identifier of the data unit; the data type of the cross-line continuation parsing type is determined based on the data type of other data units that are in the same closed cross-line marker as the data unit.

2. The DBC file parsing method according to claim 1, characterized in that, The data type corresponding to the data unit is determined in the following way: If the starting identifier of the data unit is VERSION, then the data type of the data unit is determined to be a version definition; or, If the starting identifier of the data unit is BU, then the data type of the data unit is determined to be a node list definition; or, If the starting identifier of the data unit is BO, then the data type of the data unit is determined to be a message definition; or, If the starting identifier of the data unit is SG, then the data type of the data unit is determined to be a signal definition; or, If the starting identifier of the data unit is CM, and the parsing type of the data unit is the standard parsing type and / or the cross-line start parsing type, then the data type of the data unit is determined to be an annotation definition; or, If the starting identifier of other data units within the same closed cross-line marker is CM, and the parsing type of the data unit is the cross-line continuation parsing type, then the data type of the data unit is determined to be a cross-line comment definition; or, If the starting identifier of the data unit is VAL, and the parsing type of the data unit is the standard parsing type and / or the cross-line start parsing type, then the data type of the data unit is determined to be an enumerated value definition; or, If the starting identifier of other data units within the same closed cross-line marker is VAL, and the parsing type of the data unit is the cross-line continuation parsing type, then the data type of the data unit is determined to be a cross-line enumeration value definition; or, If the data unit contains attributes of an object defined in the DBC file, the data type of the data unit is determined to be an attribute definition.

3. The DBC file parsing method according to claim 1, characterized in that, When the parsing type is a standard parsing type, the step of calling the parsing function corresponding to the data type to parse the data unit and obtain the parsing result includes: Based on the data type corresponding to the data unit, the corresponding parsing function is called; Based on the parsing function, the content of the data unit is extracted to obtain parsed data; Determine the object corresponding to the parsed data, and the memory address of the object; the memory address of the object is an address in a pre-allocated memory block; The parsed data is filled into the object to obtain the parsing result of the data unit.

4. The DBC file parsing method according to claim 1, characterized in that, When the parsing type is a cross-line start parsing type, the step of calling the parsing function corresponding to the data type to parse the data unit and obtain the parsing result includes: If the data type corresponding to the data unit is a comment or an enumeration value, the parsing function corresponding to the comment or the enumeration value is called to parse the data unit and obtain the parsed data of the data unit. Construct a buffer and save the parsed data of the data unit to the buffer.

5. The DBC file parsing method according to claim 4, characterized in that, When the parsing type is a cross-line continuation parsing type, the step of calling the parsing function corresponding to the data type to parse the data unit and obtain the parsing result includes: When the data type corresponding to the data unit is a comment or an enumeration value, for each subsequent data unit within the same closed cross-line marker, the content of each subsequent data unit is added to the buffer until a terminating quotation mark is detected, thus obtaining the parsed data of multiple data units within the same closed cross-line marker. The parsed data is associated with the object of the data unit to obtain the parsing results of multiple data units that are in the same closed cross-line marker.

6. The DBC file parsing method according to claim 2, characterized in that, The parsing process for the cross-line comment includes: If the starting identifier of the data unit is identified as CM_, the type of annotation is determined; the annotation types include: message, node, and signal; When the type of the annotation is the signal, the starting quotation mark of the annotation text is determined, and the annotation text accumulation begins; If no closing quotation mark is detected at the end of the line of the starting data unit of the parsed comment text, the parsed data of the starting data unit of the comment text is saved, and the parsed content of subsequent data units is appended to the accumulated comment text until the closing quotation mark of the comment text is detected, thus obtaining the comment text after parsing the data unit. Determine the target object corresponding to the annotation text and the memory address of the target object; The parsed comment text is associated with the memory address of the target object to obtain the cross-line comment parsing result.

7. The DBC file parsing method according to claim 2, characterized in that, The parsing process of the cross-row enumeration value includes: If the starting identifier of the data unit is identified as VAL_, the target object of the data unit is determined; Parse the contents of the starting data unit of the enumeration value to obtain the value-description pair, and begin accumulating the data-description pair; If no closing quotation mark is detected at the end of the line of the enumeration value starting data unit, the parsed data of the enumeration value starting data unit is saved, and the parsed content of subsequent data units is appended to the accumulated data-description pair until a closing quotation mark is detected. The accumulated data-description text pairs are sorted from smallest to largest numerical value. The sorted numerical-description pairs are then associated with the target object to obtain the cross-line enumeration value parsing result.

8. The DBC file parsing method according to claim 1, characterized in that, The method further includes: In response to errors occurring during the parsing of the DBC file, the errors are categorized according to their severity; the error categories include: recoverable errors, partially recoverable errors, and unrecoverable errors. Execute the corresponding error recovery strategy according to the category of the error; If the error cannot be recovered, an error report is generated; the error report includes: error location, error description, and repair suggestions.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the DBC file parsing method as described in any one of claims 1-8.

10. A vehicle, characterized in that, include: The electronic device according to claim 9.

11. A computer-readable storage medium, characterized in that, When the computer-executable instructions stored in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is capable of performing the DBC file parsing method as described in any one of claims 1-8.

12. A computer program product, the computer program product comprising computer instructions, characterized in that, When the computer instructions are executed on the processor of the device, the device is able to perform the DBC file parsing method as described in any one of claims 1-8.

Images