Method and system for converting can communication configuration table to dbc and c code based on large language model

Abstract

The application is suitable for the field of automobile electronics and industrial control, and provides a CAN communication configuration table to DBC and C code method and system based on a large language model. The method reads and preprocesses a CAN communication configuration table file. Through the natural language understanding capability of the large language model, a non-standard table header is intelligently identified and mapped to a DBC standard field. Based on the mapping relationship, data is standardized converted, node and signal attribute are parsed, and a standard DBC file is automatically generated. The DBC file is parsed, and embedded C language header files and source files containing signal structure bodies, macro definitions and bit-level encoding and decoding functions are automatically generated. Through the introduction of the semantic mapping technology of the large language model, automatic compatibility and parsing of multi-format configuration tables are realized, and an end-to-end automatic generation closed loop from the original configuration table to the DBC file and then to the C code is constructed, effectively solving the problems of low manual configuration efficiency, easy errors and inconsistency between protocol description and implementation, and improving the efficiency, accuracy and maintainability of CAN communication system development.

Description

Technical Field

[0001] This invention belongs to the field of automotive electronics and industrial control, and in particular relates to a method and system for converting CAN communication configuration tables to DBC and C code based on a large language model. Background Technology

[0002] In existing CAN bus communication development processes, the definition, maintenance, and implementation of communication data typically rely on manual or semi-automatic methods. Engineers need to manually configure CAN message identifiers, data lengths, signal start bits, and physical quantity conversion parameters based on communication matrices or design documents, and generate communication description files or write corresponding program code accordingly. When the number of communication messages is large or the protocol changes frequently, the manual configuration process is tedious, involves a large amount of repetitive work, and is prone to problems such as configuration omissions, parameter errors, or version inconsistencies, affecting the development efficiency and reliability of the CAN communication system.

[0003] Furthermore, communication configuration tables used in different projects, by different suppliers, or at different development stages often differ in field naming and header format. For example, the same communication parameter may use different naming methods or writing rules. Existing technologies typically have strict requirements for configuration table formats and lack the ability to handle differences in field naming. This necessitates manual organization or reconstruction of configuration tables before use, increasing the barrier to entry and maintenance costs, and making it difficult to adapt to the actual engineering needs of multi-source communication data.

[0004] Furthermore, in existing technologies, there is typically a lack of effective linkage between CAN communication description files and program code. Even if a communication description file has been generated or maintained, engineers still need to manually write the corresponding C language structures, macro definitions, and encoding / decoding functions based on the description file. When the communication protocol is adjusted, both the description file and the program code need to be modified separately, which can easily lead to inconsistencies between the two, increase the difficulty of system debugging, and adversely affect the correctness of communication.

[0005] Existing CAN communication development tools generally suffer from fragmented functionality. Communication matrix editing, communication description file generation, and program code writing often rely on different software tools or scripts, lacking a unified data processing workflow. The collaborative use of multiple tools not only increases the complexity of the engineering process but also hinders centralized management and rapid iteration of communication data, making it difficult to meet the efficiency and standardization requirements of engineering practice.

[0006] Furthermore, the management of CAN node information, signal reception relationships, signal annotations, and value descriptions in existing technologies is relatively fragmented, lacking a mechanism for centralized description and unified generation from a single data source. This leads to inconvenience in the maintenance and reuse of communication protocols and is not conducive to the overall consistency management of the system. Summary of the Invention

[0007] The purpose of this invention is to provide a method for converting CAN communication configuration tables to DBC and C code based on a large language model, aiming to solve the technical problems existing in the prior art as identified in the background art.

[0008] The present invention is implemented as follows: a method for converting CAN communication configuration table to DBC and C code based on a large language model, including the following steps: reading the CAN communication configuration table file, cleaning the original table header, and obtaining the preprocessed table header data and table content.

[0009] The preprocessed header data is compared with a pre-defined list of standard DBC fields to identify missing standard fields. A large language model is then used to intelligently identify and map these missing fields, obtaining standardized header mapping relationships. Based on the table content and the standardized header mapping relationships, the data undergoes standardization transformation, format validation, node information extraction, message grouping, and signal attribute parsing, assembling to generate a DBC file. The generated DBC file is parsed to extract message and signal information, generating a C language header file and source file. The encoding function in the source file converts the physical value to the original value according to the formula `original value = (physical value - offset) / factor` and writes it to the byte stream. The decoding function extracts the original value from the byte stream and converts it back to the physical value according to the formula `physical value = original value * factor + offset`. The DBC file and C language file are then output.

[0010] Specifically, the process of calling the large language model for intelligent recognition and mapping includes: constructing structured prompt words for missing fields, wherein the prompt words contain rules for ignoring format differences, processing only missing fields, and outputting JSON key-value pairs; calling the large language model interface and parsing the returned JSON results to obtain the mapping relationship generated by the LLM; and merging the mapping relationship generated by the LLM with the preset default mapping relationship according to priority to obtain the final standardized header mapping relationship.

[0011] The assembly and generation of DBC files specifically includes: extracting sending and receiving node information from the data to form a node set; grouping the data using message ID, message name, and data length as a combined primary key; creating a message object for each message group and adding a signal object to it; assembling the node objects and message objects into the Database instance according to the hierarchical relationship of "Database→Message→Signal" and outputting it as a DBC file.

[0012] Specifically, generating the C language file includes: generating a frame ID macro and a data length macro for each message in the header file, defining a signal structure and declaring encoding and decoding functions; implementing the encoding and decoding functions in the source file, wherein the encoding function writes the original signal value to the byte stream through bitwise operations, and the decoding function extracts the original value from the byte stream through bitwise operations.

[0013] The present invention also provides a system for implementing the above method, the system comprising:

[0014] The human-computer interaction module is used to receive user input and feedback results;

[0015] The Excel data parsing module is used to perform the steps of reading and preprocessing the configuration table;

[0016] The LLM header intelligent recognition and mapping module is used to perform the header intelligent recognition and mapping steps;

[0017] The DBC file generation module is used to perform the steps of generating DBC files;

[0018] The C code conversion module is used to perform the steps of generating C language code.

[0019] The beneficial effects of this invention are:

[0020] This invention, by introducing the natural language understanding and semantic mapping capabilities of a large language model, can automatically identify and accommodate various non-standard field naming and format variations used in communication configuration tables from different projects and vendors. For example, it automatically maps different expressions such as "MessageID," "Message ID," and "Message Number" to the standard field "Message_ID." This eliminates the need for manual preprocessing, enabling direct parsing of multi-source, non-standard configuration tables, greatly improving the tool's versatility and flexibility, and reducing the barrier to entry and maintenance costs. This invention constructs a fully automated closed-loop generation process from the original Excel configuration table to a standard DBC file, and finally to C language encoding / decoding code directly usable for embedded development. Driven by a single data source, configuration table parsing, DBC generation, and code generation, it completely eliminates the tedious steps of manually compiling configuration tables and switching between multiple tools in traditional development. This not only significantly reduces repetitive manual workload but, more importantly, ensures strict consistency between the communication protocol description and code implementation, effectively avoiding the risk of version inconsistencies caused by separate manual maintenance. Meanwhile, the generated C code possesses complete signal structures, macro definitions, and precise bit-level encoding and decoding functions, allowing direct integration into vehicle controllers or industrial control equipment, thus improving development efficiency and code standardization. Furthermore, the system employs a multi-threaded design to ensure smooth human-machine interaction, and utilizes fault-tolerance mechanisms such as multi-mapping fusion and mandatory checks of key fields to guarantee the reliability and robustness of the conversion process. Ultimately, this achieves efficient, accurate, and integrated CAN communication data definition, maintenance, and implementation. Attached Figure Description

[0021] Figure 1 A flowchart illustrating the system workflow for converting CAN communication configuration tables to DBC and C code, provided in this embodiment of the invention.

[0022] Figure 2 A flowchart for automatic header recognition provided in an embodiment of the present invention;

[0023] Figure 3 This is a flowchart of the EXCEL→DBC generation process provided in an embodiment of the present invention;

[0024] Figure 4 The flowchart for DBC→C code generation provided in the embodiments of the present invention is shown. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0026] This invention aims to provide an automated tool for converting Excel data to DBC based on LLM (Large Language Model), such as... Figure 1 As shown, this solution addresses the low mapping efficiency and high error rate caused by non-standardized Excel headers (such as inconsistent capitalization, format variations, and abbreviations) in traditional conversion processes. The technical solution achieves fully automated conversion from non-standardized Excel spreadsheets to DBC files and corresponding C code through the collaborative work of an Excel data parsing module, an LLM header intelligent recognition and mapping module, a DBC file generation module, a C code conversion module, and a human-computer interaction module. The automatic LLM header recognition is the core component, using natural language understanding to solve the problem of accurate mapping between non-standard headers and standard DBC fields, combined with multiple fault-tolerance mechanisms to ensure conversion reliability.

[0027] This invention provides a system for converting CAN communication configuration tables to DBC and C code based on a large language model. Its overall workflow is as follows: Figure 1 As shown.

[0028] The system mainly includes a human-computer interaction module, an Excel data parsing module, an LLM header intelligent recognition and mapping module, a DBC file generation module, and a C code conversion module. These modules form a closed-loop process through data interaction. The specific data flow is as follows: the user inputs the Excel file path and output path through the human-computer interaction module → the Excel data parsing module reads and preprocesses the table data → the LLM header intelligent recognition and mapping module completes the standardized mapping of the headers → the DBC file generation module generates a DBC file based on the mapped data → the C code conversion module converts the DBC file into C language code → the result is fed back to the user through the human-computer interaction module.

[0029] The system adopts a multi-threaded design and uses QThread to separate the conversion task from the UI interaction, avoiding interface lag caused by long-term tasks and improving the user experience.

[0030] Excel Data Parsing Module

[0031] This module is responsible for reading Excel files and performing preliminary preprocessing to provide standardized input for subsequent header recognition.

[0032] In practice, the pandas library combined with the openpyxl engine is used to read .xlsx format files, supporting tabular data containing CAN messages and signal information. The original Excel headers are cleaned, removing leading and trailing spaces while preserving original case, and a lowercase header list is generated for subsequent case-insensitive matching logic. This module also performs preliminary data validation, recording the number of valid data rows and the original header set, providing foundational data for the header recognition module.

[0033] LLM Header Intelligent Recognition and Mapping Module

[0034] This module is the core of solving the non-standard header mapping problem. It achieves intelligent mapping through LLM's natural language understanding capabilities and ensures reliability by combining default mapping with a mandatory checking mechanism. Its processing flow is as follows: Figure 2 As shown, the specific steps are as follows:

[0035] Standard field definitions: A list of standard fields required for generating DBC files is preset, including but not limited to 16 necessary fields such as Message_ID, Message_Name, DLC, Signal_Name, Start_Bit, Length, Factor, and Offset, which serve as the target basis for the header mapping.

[0036] Missing field location: The preprocessed Excel header is compared with the standard field list to filter out "missing standard fields" (i.e., standard fields that do not appear directly in the Excel file). For example, if the Excel header contains "MessageID" but not "Message_ID", then "Message_ID" is marked as a missing field.

[0037] LLM prompt word construction: For missing fields, generate structured prompt words and define mapping rules to constrain LLM output.

[0038] Rule 1: Ignore format differences (such as spaces, capitalization, underscores, for example, "StartBit" should be mapped to "Start_Bit");

[0039] Rule 2: Only process missing standard fields, and do not remap already matched fields;

[0040] Rule 3: The output format is JSON key-value pairs (the key is the actual Excel header, and the value is the corresponding standard field).

[0041] LLM Call and Result Parsing: The Ollama platform's qwen2.5:3b model was selected and called via an HTTP interface. `stream=False` (non-streaming output) and `temperature=0` (deterministic output) were configured to ensure result stability. A POST request was sent using the `requests` library, carrying prompts and model parameters, with a timeout of 15 seconds to avoid infinite waiting. The text returned by the LLM was validated using JSON format, filtering out invalid mappings and retaining valid ones.

[0042] Multiple mapping fusion: Preset default mapping relationships between common header variants and standard fields (e.g., "msgid" → "Message_ID", "signalname" → "Signal_Name"). When LLM does not return a valid mapping, the default mapping is automatically enabled. The mapping generated by LLM has higher priority than the default mapping, ensuring that the intelligent recognition results take effect first, while the default mapping covers common variants that LLM may miss.

[0043] Forced checking of critical fields: Perform secondary validation on core fields. If they are still missing after the above steps, traverse all Excel headers and manually map them by keyword matching to ensure that the necessary fields generated by DBC are not missing.

[0044] DBC file generation module

[0045] This module, based on mapped standardized Excel data, generates DBC files conforming to the CAN bus protocol specification through structured parsing and calls to the cantools library interface. The generation process is as follows: Figure 3 As shown, the specific steps are as follows:

[0046] Data preprocessing and format validation: Decimal or hexadecimal message IDs that may exist in Excel are converted to integer types using the `convert_msg_id` function. Missing non-critical fields are completed, and numeric fields undergo type validation, filtering out invalid characters or non-numeric content.

[0047] Node information construction: Extract all unique node names from the Node_Sender and Node_Receivers fields to form a node set. If the Node_Address field exists, associate the node name with the address; if the address is invalid, log a warning and ignore the address information. Create node objects using the cantools.database.Node class, store the address information in the node's comment property, and add all node objects to the nodes list of the Database instance.

[0048] Message grouping and basic attribute parsing: Grouping Excel data using pandas.groupby with Message_ID, Message_Name, and DLC as a composite primary key.

[0049] Assign basic attributes to each message group: frame_id is taken from the integer converted from Message_ID; name is taken from Message_Name, and will be automatically generated if empty; length is taken from the DLC field, and will be set to 8 if empty; senders is taken from Node_Sender, and will use the default sending node preset by the project if empty; is_extended_frame is always set to True, supporting extended frame formats.

[0050] Signal attribute parsing and object creation: Extract and transform signal attributes for the signal lines within each message packet.

[0051] The core attributes include:

[0052] name is taken from Signal_Name, and is automatically generated when it is empty;

[0053] start is taken from Start_Bit, which defaults to 0;

[0054] length is taken from Length, with a default value of 8;

[0055] byte_order is fixed to "little";

[0056] is_signed is always set to False.

[0057] Extended attributes include:

[0058] The default values ​​for factor and offset are 1.0 and 0.0, respectively.

[0059] The default value for minimum / maximum is 0.

[0060] unit is taken from the Unit field;

[0061] The comment is taken from the Signal_Comment field;

[0062] The `value_descriptions` function parses the `Value_Descriptions` field and converts it into a dictionary.

[0063] Extract the list of receiving nodes from the Node_Receivers field and associate it with the signal receivers property.

[0064] Database object assembly and DBC file output: Signal objects are added to the signals list of their respective messages, and message objects are added to the messages list of the Database instance, forming a hierarchical structure of "Database→Message→Signal". The `cantools.database.dump_file` method is called to write the Database object to the specified path, generating a DBC file.

[0065] C code conversion module

[0066] This module automatically generates C language encoding / decoding code, including header and source files, based on the generated DBC file. The generation process is as follows: Figure 4 As shown, the specific steps are as follows:

[0067] DBC file parsing and information extraction: Load the DBC file using cantools.database.load_file, parse and extract core information, including message information and signal information.

[0068] Header file generation: The header file contains macro definitions, signal structures, and function declarations. The macro definition section generates frame ID macros and DLC macros for each message. The structure definition section defines signal structures grouped by message, with structure members representing all signals under that message. Member types are automatically matched based on signal length, and comments are added. The function declaration section declares encoding and decoding functions for each message.

[0069] Source file generation: The source file implements encoding and decoding functions.

[0070] The implementation logic of the encoding function is as follows: input parameter verification; clearing the byte stream buffer using memset; for each signal, converting the physical value in the structure to the original value according to the formula original value = (physical value - offset) / factor; traversing each bit of the original value of the signal, calculating the byte index and bit position of the bit in the byte stream, and writing the original value to the byte stream through bitwise operations.

[0071] The decoding function is implemented as follows: input parameter verification; traversing each bit of the signal, extracting the value of the corresponding bit from the byte stream, and concatenating them into the original value; converting the original value into a physical value according to the formula physical value = original value * factor + offset, and assigning it to the structure member.

[0072] Code formatting and error handling: Use a consistent comment format and indentation to ensure readability. Check for null pointers during encoding / decoding to prevent program crashes; do not perform extra handling for bit operations exceeding the byte stream length.

[0073] Human-computer interaction module

[0074] This module uses PyQt5 to build a graphical user interface (GUI) for user operation and workflow control. The interface layout includes two functional areas: "Excel to DBC" and "DBC to C Code," providing file path selection, conversion buttons, and a log display area, respectively. The conversion process and error messages are displayed in real-time through log feedback, and log transmission between threads is achieved through a signal-slot mechanism. For workflow control, the conversion thread is triggered by button clicks, the conversion button is disabled to prevent duplicate operations, and the button state is restored and a pop-up window displays the result after the thread ends.

[0075] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

[0076] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0077] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

[0078] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for converting CAN communication configuration tables to DBC and C code based on a large language model, characterized in that, The method includes: S1: Read the CAN communication configuration table file, clean the original header, and obtain the pre-processed header data and table content; S2: Compare the preprocessed header data with the preset DBC standard field list, filter out the missing standard fields, call the large language model to intelligently identify and map the missing fields, and obtain the standardized header mapping relationship; S3: Based on the table content and standardized header mapping relationship, perform data standardization conversion, format verification, node information extraction, message grouping, signal attribute parsing, and assemble to generate DBC file; S4: Parse the DBC file, extract message and signal information, generate C language header and source files, convert physical values ​​into raw values ​​and write them into the byte stream using the encoding function in the source file, and extract the raw values ​​from the byte stream and convert them back into physical values ​​using the decoding function. S5: Output the DBC file and C language file.

2. The method according to claim 1, characterized in that, The method described in S2 for calling a large language model to intelligently identify and map missing fields specifically includes: A structured suggestion word is constructed for the missing field, and the suggestion word includes rules for ignoring format differences, processing only the missing field, and outputting JSON key-value pairs; Call the large language model interface and parse the returned JSON result to obtain the mapping relationship generated by LLM; The mapping relationship generated by the LLM is merged with the preset default mapping relationship according to priority to obtain the final standardized header mapping relationship.

3. The method according to claim 2, characterized in that, The specific steps for calling the large language model interface are as follows: The local large language model of the Ollam platform is invoked via an HTTP POST request, configuring non-streaming and deterministic output parameters.

4. The method according to claim 1, characterized in that, The assembly and generation of DBC files described in S3 specifically includes: Extract sending and receiving node information from the data to form a node set; group the data using message ID, message name, and data length as a combined primary key; Create a message object for each message group and add a signal object to it. The signal object includes start bit, length, coefficient, offset, unit, comment and receiver node attributes. Assemble node objects and message objects into a Database instance according to their hierarchical relationship, and output them as a DBC file.

5. The method according to claim 1, characterized in that, The generation of C language header files as described in S4 specifically includes: Generate a frame ID macro and a data length macro for each message; define a signal structure for each message, with structure members corresponding to all signals under the message, and add comments to the members containing signal descriptions and units; Declare the encoding and decoding functions for each message.

6. The method according to claim 1 or 5, characterized in that, The generation of C language source files as described in S4 specifically includes: Implement an encoding function that fills each bit of the original signal value into a byte stream buffer through bitwise operations; Implement a decoding function that extracts each bit from the byte stream buffer through bitwise operations and concatenates them into the original value.

7. The method according to claim 1, characterized in that, Steps S1, S2, S3, and S4 are executed using a multi-threaded approach to separate the conversion task from the human-computer interaction.

8. A system for converting CAN communication configuration tables to DBC and C code based on a large language model, characterized in that, The system includes: The human-computer interaction module is used to receive user input and feedback results; The Excel data parsing module is used to read the CAN communication configuration table file, clean the original header, and obtain the pre-processed header data and table content. The LLM header intelligent recognition and mapping module is used to compare the preprocessed header data with the preset DBC standard field list, filter out the missing standard fields, call the large language model to intelligently recognize and map the missing fields, and obtain the standardized header mapping relationship. The DBC file generation module is used to perform standardized conversion, format verification, node information extraction, message grouping, signal attribute parsing, and assembly of data based on table content and standardized header mapping relationships, and to generate DBC files. The C code conversion module is used to parse DBC files, extract message and signal information, generate C language header files and source files, convert physical values ​​into raw values ​​and write them into byte streams through the encoding function in the source file, and the decoding function extracts raw values ​​from the byte stream and converts them back into physical values.

Images