Signal matching code generation method and system based on large language model workflow

Abstract

The invention provides a signal matching code generation method and system based on large language model workflow, and relates to the technical field of code generation and vehicle-mounted network communication.The method comprises the steps that original communication matrix data are analyzed, and a target signal set containing the mapping relation between application layer signals and bus signals is extracted; judging the mapping type of each signal by using a multi-model collaborative large language model workflow, calculating a corresponding signal conversion parameter, and generating a corresponding code snippet; and finally, integrating into a complete target code file according to a preset source code format. According to the method, the technical problems of low signal matching efficiency, high error rate and poor quality controllability are solved, and the technical effect of improving the development efficiency and reliability is achieved.

Description

Technical Field

[0001] This invention relates to the fields of code generation and vehicle network communication technology, and more specifically, to a signal matching code generation method and system based on a large language model workflow. Background Technology

[0002] In the field of automotive electronic control system development, especially in software development based on the Automotive Open System Architecture (AUTOSAR) standard, COM signal matching is of great significance. Currently, COM signal matching mainly relies on basic software engineers manually comparing the requirements document (such as an Excel-formatted requirements sheet) line by line with the signal input matrix provided by the customer, and manually writing and generating the corresponding C language source files (.c) and header files (.h). This process is not only time-consuming and labor-intensive, but also inefficient, and can easily become a bottleneck in the rapid iteration process of the entire vehicle and its components.

[0003] Furthermore, since the formulation and implementation of mapping rules rely on manual processes, there is a high risk of errors in handling key technical parameters such as data type definition, signal scaling, resolution setting, offset calculation, and the effective range of output signals. These errors are often difficult to detect during the compilation phase and typically only surface during subsequent bench testing or calibration, leading to repeated verification and corrections, significantly increasing project development time and costs. Statistics show that the additional processing time caused by such issues in a single project can exceed 200 person-hours.

[0004] In summary, existing COM signal matching methods rely heavily on manual intervention, resulting in problems such as low matching efficiency, high error rate, and poor quality control, which seriously affect development progress and software quality. There is an urgent need to optimize and replace these methods through standardization and automation to improve development efficiency and software reliability. Summary of the Invention

[0005] The purpose of this invention is to provide a signal matching code generation method and system based on a large language model workflow, so as to solve the technical problems of low signal matching efficiency, high error rate and poor quality control in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a signal matching code generation method based on a large language model workflow. The method includes: performing field filtering and structured extraction on pre-acquired raw communication matrix data to generate a target signal set; wherein the raw communication matrix data includes mapping relationship requirement information between application layer signals and communication bus signals; the target signal set contains multiple target signals, each including application layer signal data fields and communication bus signal data fields; inputting the target signal set into a workflow system composed of multiple heterogeneous large language models; determining the signal mapping type corresponding to each target signal through the workflow system; calculating corresponding signal conversion parameters based on the determined mapping type; and generating code fragments corresponding to each target signal; merging and processing the generated multiple code fragments according to a predefined project source code file format to generate a target code file.

[0007] In some optional implementations, the application layer signal data fields mentioned above include the application layer signal name, precision, offset, physical unit, and signal type; the communication bus signal data fields mentioned above include the communication bus signal name, precision, offset, physical unit, signal type, and special mapping relationship.

[0008] In some optional implementations, the above method further includes: dividing the target signal set into multiple signal subsets, each signal subset containing no more than a preset number of target signals.

[0009] In some optional implementations, the criteria for determining the above signal mapping type include: the precision difference, offset, unit consistency, and whether there is a special mapping relationship between the application layer signal and the communication bus signal; the above signal mapping type includes at least one of the following: direct mapping type, fixed output type, precision conversion type, and lookup table mapping type.

[0010] In some optional implementations, when determining the signal mapping type corresponding to each of the above target signals through the above workflow system, a parallel multi-round inference and result consistency comparison mechanism is adopted. The final signal type is determined if the results of at least two rounds of independent inference are consistent; otherwise, the inference is returned to be repeated.

[0011] In some optional implementations, the calculation process of the above signal conversion parameters adopts a two-stage heterogeneous model collaborative verification mechanism, including: the first language model generates an initial total precision factor and total offset based on the precision, offset, and physical unit information of the input and output signals; the second language model recalculates the total precision factor and total offset based on the above initial total precision factor and total offset as context input; when the two calculation results are consistent, the current parameters are used for code generation; otherwise, the calculation is re-executed in the first stage.

[0012] In some optional implementations, signal matching includes signal matching in the transmission direction and signal matching in the reception direction; the signal matching in the transmission direction includes mapping the source signal in the application layer to the target signal in the communication bus; for the signal matching in the transmission direction, the total offset is equal to the negative ratio of the communication bus-side signal offset to the communication bus-side signal precision; wherein the communication bus-side signal is the target signal in the transmission direction; the signal matching in the reception direction includes mapping the source signal in the communication bus to the target signal in the application layer; for the signal matching in the reception direction, the total offset is equal to the ratio of the communication bus-side signal offset to the application layer-side signal precision, wherein the communication bus-side signal is the source signal in the reception direction, and the application layer-side signal is the target signal in the reception direction.

[0013] Secondly, embodiments of the present invention provide a signal matching code generation system based on a large language model workflow, comprising: a signal generation module, used to perform field filtering and structured extraction on pre-acquired original communication matrix data to generate a target signal set; wherein the original communication matrix data includes mapping relationship requirement information between application layer signals and communication bus signals; the target signal set contains multiple target signals, and the target signals include application layer signal data fields and communication bus signal data fields; a signal conversion module, used to input the target signal set into a workflow system composed of multiple heterogeneous large language models, determine the signal mapping type corresponding to each of the target signals through the workflow system, calculate the corresponding signal conversion parameters according to the determined mapping type, and generate code fragments corresponding to each of the target signals; and a code generation module, used to merge and process the generated multiple code fragments according to a predefined project source code file format to generate a target code file.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to perform the method described in any of the first aspects above.

[0016] This invention provides a signal matching code generation method and system based on a large language model workflow. The method extracts a target signal set containing the mapping relationship between application layer signals and bus signals by parsing the original communication matrix data; it uses a multi-model collaborative large language model workflow to determine the mapping type of each signal and calculates the corresponding signal conversion parameters to generate corresponding code snippets; finally, it integrates them into a complete target code file according to a preset source code format. This solves the technical problems of low signal matching efficiency, high error rate, and poor quality control in existing technologies, and achieves the technical effect of improving development efficiency and reliability. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a signal matching code generation method based on a large language model workflow, provided for an embodiment of the present invention; Figure 2 A schematic diagram of the structure of a signal matching code generation system based on a large language model workflow provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another signal matching code generation method based on a large language model workflow provided in this embodiment of the invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] "COM signal matching" is a core component of automotive electronic control system development, particularly important in software development adhering to the AUTOSAR standard. COM stands for Communication, and in the AUTOSAR architecture, it typically refers to the Communication Management Module (COM Module), responsible for handling data interaction between the application software (ASW) and the underlying communication stack (such as CAN, LIN, or other bus protocol stacks). Signal matching refers to the logical mapping and conversion between the signals used in the application software (ASW signals) and the actual transmitted message signals in the vehicle communication network (e.g., CAN signals defined in the DBC file). Therefore, in this invention, COM signal matching essentially refers to establishing the correct data mapping relationship between application-layer variables (such as `VehicleSpeed`) and specific bit-field signals in the communication message (such as bits 8-15 `VehSpd` in CAN message 0x201) within the automotive electronic control unit (ECU) software, and generating corresponding code to implement this mapping.

[0021] Existing COM signal matching primarily relies on engineers in the basic software field manually comparing line by line and manually writing the corresponding code files. This method suffers from low matching efficiency, high error rates, and poor quality control, severely impacting development progress and quality. Therefore, this invention provides a signal matching code generation method and system based on a large language model workflow to address the problems existing in the prior art.

[0022] To facilitate understanding of this embodiment, a detailed description of the signal matching code generation method based on a large language model workflow disclosed in this embodiment of the invention will be provided first. (See [link to relevant documentation]). Figure 1 The diagram shows a signal matching code generation method based on a large language model workflow. This method can be executed by an electronic device and mainly includes the following steps S102 to S106: Step S102: Perform field filtering and structured extraction on the pre-acquired raw communication matrix data to generate a target signal set; The original communication matrix data includes the mapping relationship requirement information between application layer signals and communication bus signals; the target signal set contains multiple target signals, which include application layer signal data fields and communication bus signal data fields.

[0023] Prior to step S102 above, raw communication matrix data containing the mapping requirements between application layer signals and communication bus signals can be obtained in advance. Typically, this raw communication matrix data is stored in Excel (.xlsx format) format on the project development server or local project directory, recording the mapping requirements between application layer software signals (ASW signals) and communication bus signals (DBC signals) in the vehicle or component project. Each record can contain a pair of signal information for which a mapping relationship needs to be established, including fields such as function description, signal name, precision, offset, physical unit, signal type, and special mapping relationship.

[0024] In this embodiment, the application layer signal can be a functional variable defined by the application layer software module in the automotive electronic control unit (ECU) to characterize the vehicle state, control logic, or sensor fusion results, such as vehicle speed calculation value, estimated remaining battery charge value, driving mode selection status, fault diagnosis flag bit, etc.

[0025] Communication bus signals can be specific signal fields in messages transmitted through vehicle communication networks (such as CAN, LIN, etc.). According to the DBC (Database CAN) file definition, they have fixed start bits, length (bit), byte order (Intel / Motorola), original value range, resolution precision (factor), offset, and physical units. They are used to transmit real-time status or control commands between different ECUs, such as "VehicleSpeed_CAN", "BatterySOC_CAN", "DriveModeReq", etc.

[0026] The mapping relationship requirement between application layer signals and communication bus signals can be the technical parameters and logical rules required for the process of converting the physical values ​​of application layer signals into the original values ​​of communication bus signals according to specific rules, or restoring the original values ​​of communication bus signals to physical values ​​usable by the application layer. For example: whether linear scaling (based on accuracy and offset) is required, whether unit conversion is involved, whether a lookup table-based nonlinear mapping is used, whether a fixed preset value is output, and whether different mapping paths are switched according to the operating mode.

[0027] Furthermore, in one embodiment, the field filtering and structured extraction in step S102 above may include: parsing the multi-row, multi-column grid information in the original communication matrix data using an automated script, filtering out valid signal entries belonging to the current development target stage according to a preset requirement stage identifier, and removing irrelevant signals, redundant comment lines, or historical legacy fields; subsequently, performing column mapping and structured reorganization on the relevant attribute fields of the application layer signals and communication bus signals involved in each retained target signal, transforming them into standardized data structure units, forming a set of target signals that can be called by subsequent processing modules.

[0028] In one embodiment, the application layer signal data field may include the application layer signal name, precision, offset, physical unit, and signal type; the communication bus signal data field may include the communication bus signal name, precision, offset, physical unit, signal type, and special mapping relationship.

[0029] Preferably, the fields retained through the field filtering process may include at least: message ID, application layer signal function name, application layer signal precision, offset, physical unit, signal type, communication bus signal name, communication bus signal type, communication bus signal precision, offset, minimum value, maximum value, physical unit, and special correspondence fields indicating nonlinear mapping or fixed output behavior. These fields collectively constitute the core input information set required for subsequent signal classification, parameter calculation, and code generation using the Large Language Model (LLM) workflow, ensuring that the automated reasoning process has complete and accurate technical support.

[0030] Furthermore, in order to adapt to the limitation on the number of iterations per batch when processing batch tasks in large language model workflows, and to ensure the stability and contextual integrity of the model inference process, the above method may also include: dividing the target signal set into multiple signal subsets, each signal subset containing no more than a preset number of target signals.

[0031] The preset number can be set based on the maximum parallel processing capability or the upper limit of a single iteration supported by the large language model workflow. The specific value can be a positive integer between 1 and 50. In a preferred embodiment, the preset number is 25. This value can be determined based on the actual performance test results of the LLM workflow engine used, in order to avoid context overflow, task execution failure, or a decrease in inference accuracy due to excessively long input data.

[0032] For example, when the total number of target signals to be processed in the original communication matrix is ​​80, it can be divided into 4 signal subsets (25, 25, 25, and 5 respectively) according to the principle that each group contains a maximum of 25 signals. Each subset is then encapsulated into an independent .xlsx intermediate file as the input unit for subsequent calls to the LLM workflow API. Each signal subset can be sent to the LLM workflow for type identification and code generation, thereby realizing the segmented automated processing of large-scale signal matching tasks.

[0033] Step S104: Input the target signal set into the workflow system composed of multiple heterogeneous large language models. The workflow system determines the signal mapping type corresponding to each target signal, calculates the corresponding signal conversion parameters based on the determined mapping type, and generates code snippets corresponding to each target signal.

[0034] In step S104 above, for each subset of signals, a workflow system composed of multiple heterogeneous large language models can be invoked to perform the following operations on each target signal: determine the signal mapping type to which the target signal belongs; calculate the corresponding signal conversion parameters based on the determination result; and generate a code snippet for implementing signal value conversion.

[0035] The workflow system, comprised of multiple heterogeneous large language models, can be an automated reasoning platform integrating large language model (LLM) nodes with various functional roles. This platform orchestrates LLM instances with different specialized capabilities to achieve phased processing and cross-validation of complex software engineering tasks. The system can be deployed on local or cloud servers, has API call capabilities, and supports the sequential execution of functional modules such as structured data input, multi-round logical reasoning, code generation, and consistency verification.

[0036] This workflow system can automatically complete the transformation process from natural language / semi-structured requirements to precise mapping rules without human intervention. Specifically, it includes: classification of signal mapping types, calculation of mapping parameters, semantic parsing of nonlinear relationships, and two-stage self-verification of key parameters, thereby solving the signal distortion problem caused by human misjudgment and other factors in traditional methods.

[0037] In one embodiment, the workflow system described above may include, but is not limited to, the following heterogeneous large language model components: Master-controlled large language model: used to receive structured signal data and prompt words, dominate the overall reasoning process, perform preliminary determination of signal mapping type and final code style control, such as the qwen-235b-a22b model (temperature set to 2), which is good at context understanding and program template imitation; Dedicated mathematical computation-oriented large language model: used to perform high-precision numerical calculation tasks, such as the derivation and calculation of total precision and total offset, especially in complex scenarios with inconsistent units and multi-level scaling chains, for formula modeling and lossless integerization. For example, the mistralai / mathstral-7b-v0.1 model is used, which is trained with mathematical expressions and physical dimensions and has strong symbolic reasoning capabilities.

[0038] The aforementioned models can be invoked collaboratively in a preset order within the workflow, forming a two-stage closed-loop mechanism from decision-making to verification, to ensure the accuracy of the output results and the usability of the project.

[0039] In one embodiment, the criteria for determining the above signal mapping type may include: the precision difference, offset, unit consistency, and whether there is a special mapping relationship between the application layer signal and the communication bus signal.

[0040] In this embodiment, the criteria for determining the signal mapping type may include semantic parsing and numerical logic analysis of the corresponding fields in the original communication matrix. Specifically, the following multi-level discrimination steps can be executed sequentially through the large language model workflow: (S241) First, a preliminary identification is made based on the content of the "Special Correspondence" field: if the field is clearly marked as "Fixed Output XX", "Constantly Set to YY" or contains a mapping rule in the form of key-value pairs, then it is determined that the signal has nonlinear or preset output behavior; (S242) Further mathematical condition judgment is made by combining the accuracy and offset parameters: If the ratio of the application layer signal precision to the communication bus signal resolution precision is equal to 1, and the communication bus offset is 0, and there are no special mapping requirements, then it is determined that it can be directly mapped. If the ratio of the application layer signal precision to the communication bus signal resolution precision is not 1 or the offset is not zero, scaling and compensation processing is required, which is a precision-based conversion type. (S243) Check unit consistency: When the physical units of the application layer signal and the communication bus signal are different, even if other parameters match, a unit conversion factor must be introduced, classified as a precision conversion type, and the calculation formula adjusted. (S244) Finally, all field information is combined for exclusive classification to ensure that each signal falls into only one optimal mapping type category.

[0041] In one embodiment, the signal mapping type may include at least one of the following: direct mapping, fixed output, precision conversion, and lookup table mapping.

[0042] Direct mapping refers to a direct one-to-one correspondence between the physical value of an application layer signal and its corresponding original value on the communication bus without any mathematical transformation. The criteria are: the ASW signal precision equals the DBC signal precision, the DBC signal offset is 0, the physical units are consistent, and the "special correspondence" field is empty, marked with " / ", or "one-to-one correspondence". For example, a status flag bit ASW_Signal_Status (precision 1, offset 0) is directly assigned to the CAN signal Status_CAN (factor=1, offset=0), generating the code `can_tx.Status_CAN = asw.Status;`.

[0043] Fixed output refers to a communication bus signal that always outputs a preset constant value regardless of changes in the application layer input. The condition for this is that the "Special Correspondence" field explicitly indicates semantic expressions such as "Fixed Output X" or "Always Send Y". In this case, the LLM will extract this fixed value and generate a hard-coded assignment statement, such as `can_tx.Enable_Flag = 0x01;`.

[0044] Precision-based conversion refers to a linear mapping relationship between application layer signals and communication bus signals, requiring the calculation of the total scaling factor and total offset based on precision and offset. The criteria for this type of conversion are: no direct mapping exists, and there is no lookup table mapping relationship.

[0045] Furthermore, different processing is required for mapping different signal matching directions. Specifically, in this invention, signal matching covers two directions: the transmitting direction (Tx) and the receiving direction (Rx).

[0046] Signal matching in the transmission direction involves mapping the source signal in the application layer to the target signal in the communication bus. For signal matching in the transmission direction, the total offset is equal to the negative ratio of the communication bus-side signal offset to the communication bus-side signal precision; where the communication bus-side signal is the target signal in the transmission direction.

[0047] Signal matching in the receiving direction involves mapping the source signal in the communication bus to the target signal in the application layer. For signal matching in the receiving direction, the total offset is equal to the ratio of the signal offset on the communication bus side to the signal accuracy on the application layer side; where the communication bus side signal is the source signal in the receiving direction, and the application layer side signal is the target signal in the receiving direction.

[0048] The aforementioned differentiated processing mechanism ensures the correctness and consistency of bidirectional signal conversion in mathematical logic, avoiding data distortion caused by directional confusion.

[0049] For example: In the Tx direction (from ASW to CAN), the total accuracy is the ratio of the ASW signal accuracy to the DBC signal accuracy multiplied by the physical unit conversion factor for converting the physical units of the ASW input signal to the physical units of the DBC output signal; the total offset is the negative of the ratio of the DBC signal offset to the DBC signal accuracy. In the Rx direction (from CAN to ASW), the total accuracy is the ratio of the DBC signal accuracy to the ASW signal accuracy multiplied by the physical unit conversion factor for converting the physical units of the DBC input signal to the physical units of the ASW output signal; the total offset is the ratio of the DBC signal offset to the ASW signal accuracy. The above output results can be forcibly converted to integer operations to avoid floating-point overhead, and are suitable for continuous signals such as temperature, pressure, and speed.

[0050] Lookup table mapping (or "fixed special mapping") refers to a non-linear, discrete mapping between application layer signals and communication bus signals. It typically exists in the form of enumerated values ​​or status codes and requires conditional branching to achieve many-to-one or one-to-many conversions. The condition is that the "special correspondence" field contains multiple explicit input-output pairs, such as "DBC→ASW: DBC2→ASW0, DBC0→ASW1, DBC1→ASW2". This mapping can be used for subsequent LLM parsing and generation of structured C language selection statements.

[0051] Furthermore, in scenarios with multiple conflicting conditions or ambiguous descriptions, a priority-based judgment mechanism can be employed, such as: special mapping relationships > fixed output > unit consistency > precision / offset matching, to ensure stable and reliable classification results. In actual testing, in a large-scale project with over 150 signals, the accuracy of this classification mechanism is greater than 98%, and can reach over 99.96% when combined with a subsequent two-stage self-verification mechanism.

[0052] To prevent classification errors due to single-inference bias, in one embodiment, a parallel multi-round inference and result consistency comparison mechanism can be employed when the workflow system determines the signal mapping type corresponding to each target signal. Specifically, when determining the mapping type for each target signal, the workflow system initiates at least two independent inference processes. The final signal mapping type is determined only when the output results of all rounds are completely consistent; otherwise, the system will trigger a re-inference process until the result converges or the maximum number of retries is reached. This mechanism can effectively improve the robustness and fault tolerance of classification decisions.

[0053] Based on the determined signal mapping type, the system further calculates the signal transformation parameters used to generate the code snippet. For the "precision-based transformation" type involving linear transformation, the core parameters include the total precision factor and the total offset. In one embodiment, the calculation process of these signal transformation parameters can employ a two-stage heterogeneous model collaborative verification mechanism, specifically including: In the first stage, the first major language model (such as a master-controlled LLM) generates the initial total precision factor and total offset based on the precision, offset, and physical unit information of the input and output signals. In the second stage, the initial parameters output from the first stage are passed as context input to the second large language model (such as a dedicated mathematical computational LLM), which recalculates the above parameters (total precision factor and total offset) based on the same original data. If the two calculations are consistent, the current parameters are used for subsequent code generation; if the results are inconsistent, the calculation is re-executed in the first stage until a consensus is reached or the exception handling process is terminated.

[0054] The aforementioned two-stage heterogeneous model collaborative verification mechanism leverages the complementary capabilities of different models, significantly reducing the risk of miscalculation by a single model and ensuring the accuracy of key parameters.

[0055] Furthermore, the code snippet generation process can include: inputting the determined mapping type, signal conversion parameters, and variable type information as contextual prompts into the large language model, guiding it to generate assignment statements or conditional branch statements that conform to predetermined programming specifications. In other words, based on obtaining the mapping type and conversion parameters through the above steps, prompts are used to guide the large language model to generate C language code snippets. For example, prompts can include: explicit task instructions (such as: "Please generate assignment statements conforming to industry coding standards based on the following parameters"), example input / output pairs, variable naming rules, function encapsulation requirements, comment format templates, etc.

[0056] Each code snippet corresponding to the signal generated through the above steps can be cached in a string array, forming a temporary "code pool". After all signal subsets in the target signal set have been processed, the code snippets generated in each batch are collected and subjected to a unified merging and formatting process, namely: Step S106: The generated multiple code snippets are merged and processed according to the predefined project source code file format to generate the target code file.

[0057] The predefined project source code file format can be a standardized file organization form that conforms to specific programming language specifications and project engineering structure requirements.

[0058] Merging and processing multiple code snippets can include: grouping and aggregating based on the fields (such as message ID) filtered in step S102 above; encapsulating multiple signal matching logics under the same message into a function body; adding standard header file references and memory segment declarations; inserting automatically generated comment blocks to indicate the signal source, mapping type, generation timestamp, and other metadata; the final output is a single `.c` source file (i.e., the object code file), which can be directly imported into AUTOSAR or other embedded software projects for use.

[0059] In another embodiment, the above method may further include: monitoring the response status of the large language model LLM workflow in real time throughout the entire process, recording the number of signals for completed code snippet generation tasks, dynamically calculating and updating the processing progress percentage based on the preset total number of tasks, and outputting the current progress in a visual form on the console to provide developers with clear execution feedback.

[0060] If a code generation request fails to produce stable, grammatically compliant, and type-mapped code output after a predefined number of retries (e.g., a three-retry mechanism), for example, if there are ambiguous parameter types (e.g., it is unclear whether `param` should be `String` or `Integer`), incomplete function signatures, unexpected return values, or ambiguous placeholders (e.g., `TODO`, `FIXME`, etc. are not filled), the task will be judged as an "abnormal generation instance," and the system will automatically mark it as "pending manual review."

[0061] In another embodiment, the following operations may be further performed on the aforementioned items to be reviewed: Extract the original input context (such as natural language requirement descriptions, API interface specifications, call context dependency graphs, etc.); retain the historical versions generated by LLM multiple times and their error information (such as JSON parsing failures, AST construction interruptions, type validation errors); package the above information into a structured log file (such as JSON format log entries) or a dedicated audit queue database, including fields such as timestamp, task ID, failure reason category, and suggested repair direction; at the same time, generate a to-do notification in the user interface or management backend, prompting developers to intervene and evaluate whether manual code completion, correction of input commands, or adjustment of prompt engineering strategies are needed.

[0062] The aforementioned mechanism not only enhances the robustness and observability of the entire automatic code generation system, but also ensures the consistency of the quality and engineering usability of the final generated target code file through a human-machine collaborative closed loop. This is particularly suitable for application environments with stringent requirements for code correctness in high-reliability software scenarios. Furthermore, the accumulated "pending human review" cases can be used in reverse to optimize training data and fine-tune LLM, continuously improving the model's generation stability in complex contexts.

[0063] In summary, the signal matching code generation method based on a large language model workflow provided by this invention extracts a target signal set containing the mapping relationship between application layer signals and bus signals by parsing the original communication matrix data; it uses a multi-model collaborative large language model workflow to determine the mapping type of each signal and calculates the corresponding signal conversion parameters to generate corresponding code snippets; finally, it integrates them into a complete target code file according to a preset source code format, solving the technical problems of low signal matching efficiency, high error rate, and poor quality controllability in the prior art, and achieving the technical effect of improving development efficiency and reliability.

[0064] Based on the same inventive concept, this invention also provides a signal matching code generation system based on a large language model workflow, see [link to relevant documentation]. Figure 2 As shown, the system mainly includes the following parts: The signal generation module 210 is used to perform field filtering and structured extraction on the pre-acquired raw communication matrix data to generate a target signal set; wherein, the raw communication matrix data includes the mapping relationship requirement information between application layer signals and communication bus signals; the target signal set contains multiple target signals, and the target signals include application layer signal data fields and communication bus signal data fields; The signal conversion module 220 is used to input the target signal set into the workflow system composed of multiple heterogeneous large language models, determine the signal mapping type corresponding to each target signal through the workflow system, calculate the corresponding signal conversion parameters according to the determined mapping type, and generate code snippets corresponding to each target signal. The code generation module 230 is used to merge and process multiple generated code snippets according to a predefined project source code file format to generate an object code file.

[0065] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0066] To facilitate understanding, this embodiment of the invention also provides an application example of a signal matching code generation method based on a large language model workflow, see [link to example]. Figure 3The diagram shows a flowchart of a signal matching code generation method based on a large language model workflow. The method mainly includes the following steps S301 to S310: Step S301: Obtain the original communication matrix file; The communication matrix file is in spreadsheet format and contains information on the mapping requirements between application layer signals and bus communication signals.

[0067] Step S302: The spreadsheet is cleaned and fields are extracted using a preprocessing script to generate a standardized input file; Field extraction includes: retained message ID, ASW signal function name, precision, physical unit, signal type, DBC signal name, type, precision, offset, minimum value, maximum value, physical unit, and special correspondence fields.

[0068] Step S303: Determine whether the number of input signals exceeds the upper limit of a single workflow processing; if so, divide the standardized input file into multiple sub-files. Each subfile contains no more than a preset number of signal entries.

[0069] Step S304: Call the backend service API of the large language model workflow, and pass in each sub-file and direction identifier (Tx or Rx) in sequence. Step S305: Within the large language model workflow, perform the following operations: parse the spreadsheet data into a structured text sequence; perform iterative processing on each signal data item; In each iteration: The signal type is determined based on the content of the "Special Correspondence" field. The types include: direct mapping type, fixed output type, precision offset mapping type, and special mapping type. If there are multiple possible types, a parallel redundancy judgment mechanism is activated, employing multiple rounds of independent reasoning and comparing the consistency of the results; Select the appropriate parameter calculation path based on the signal type; The total precision and total offset are calculated by calling a mathematical large language model, and the numerical correctness is ensured by cross-validation of a two-stage heterogeneous model. A C language assignment statement code snippet that generates the corresponding signal.

[0070] Step S306: Cache the code snippets corresponding to all signals to a temporary code pool; Step S307: After all signal processing is completed, the aggregated large language model is called to perform syntactic integration and formatting reconstruction of the code fragments in the code pool, generating a complete C source code file that conforms to the AUTOSAR standard; Step S308: Output the generated target C source code file to the specified project path, and record the execution log and progress feedback.

[0071] This embodiment demonstrates the application of the signal matching code generation method based on the large language model workflow described above. It achieves end-to-end automated generation from raw communication matrix data to target C source code files conforming to the AUTOSAR standard, thereby realizing a high degree of automation, standardization, and intelligence in the signal matching code generation process. This effectively solves the problems of low efficiency, error-proneness, and unstable quality in traditional manual methods, achieving the technical effects of improving development efficiency, reducing labor costs, and enhancing software reliability and consistency. It has good engineering applicability and industrialization promotion value.

[0072] Based on the same inventive concept, embodiments of the present invention also provide an electronic device, specifically, the electronic device includes a processor and a storage device; the storage device stores a computer program, and the computer program, when run by the processor, executes the method described in any of the above embodiments.

[0073] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 400 includes: a processor 410, a memory 420, a communication interface 430, and a bus 440. The memory 420 stores machine-readable instructions that can be executed by the processor 410. When the electronic device is running, the processor 410 communicates with the memory 420 through the bus 440. The processor 410 executes the machine-readable instructions to perform the steps of the method described above.

[0074] Specifically, the memory 420 and processor 410 can be general-purpose memory and processor, without any specific limitations. When the processor 410 runs the computer program stored in the memory 420, it can execute the above method.

[0075] Processor 410 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 410 or by instructions in software form. The processor 410 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 420, and processor 410 reads the information from memory 420 and, in conjunction with its hardware, completes the steps of the above method.

[0076] Corresponding to the above method, this embodiment of the invention also provides a computer-readable storage medium storing machine-executable instructions. When the machine-executable instructions are called and run by a processor, the machine-executable instructions cause the processor to perform the steps of the above method.

[0077] The system provided in this embodiment of the invention can be specific hardware on a device or software or firmware installed on the device. The system provided in this embodiment of the invention has the same implementation principle and technical effects as the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the system embodiments can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0078] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0079] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0080] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] In addition, the functional units in the embodiments provided by the present invention 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.

[0082] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0083] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0084] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this invention is in use. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention. In addition, the terms "first," "second," "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0085] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0086] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. All should be covered within the scope of protection of the present invention.

Claims

1. A signal matching code generation method based on a large language model workflow, characterized in that, include: Field filtering and structure extraction are performed on the pre-acquired raw communication matrix data to generate a target signal set; wherein, the raw communication matrix data includes the mapping relationship requirement information between application layer signals and communication bus signals; the target signal set contains multiple target signals, and the target signals include application layer signal data fields and communication bus signal data fields; The target signal set is input into a workflow system composed of multiple heterogeneous large language models. The workflow system determines the signal mapping type corresponding to each target signal, calculates the corresponding signal conversion parameters based on the determined mapping type, and generates code snippets corresponding to each target signal. The generated code snippets are merged and processed according to a predefined project source code file format to generate an object code file.

2. The method according to claim 1, characterized in that, The application layer signal data field includes the application layer signal name, precision, offset, physical unit, and signal type; the communication bus signal data field includes the communication bus signal name, precision, offset, physical unit, signal type, and special mapping relationship.

3. The method according to claim 2, characterized in that, The method further includes: dividing the target signal set into multiple signal subsets, each signal subset containing no more than a preset number of target signals.

4. The method according to claim 2, characterized in that, The criteria for determining the signal mapping type include: the precision difference, offset, unit consistency, and whether there is a special mapping relationship between the application layer signal and the communication bus signal; The signal mapping types include at least one of the following: direct mapping, fixed output, precision conversion, and lookup table mapping.

5. The method according to claim 4, characterized in that, When determining the signal mapping type corresponding to each target signal through the workflow system, a parallel multi-round reasoning and result consistency comparison mechanism is adopted. The final signal type is determined if the results of at least two rounds of independent reasoning are consistent; otherwise, the reasoning is returned to start over.

6. The method according to claim 2, characterized in that, The calculation process of the signal conversion parameters adopts a two-stage heterogeneous model collaborative verification mechanism, including: The first major language model generates an initial total precision factor and total offset based on the precision, offset, and physical unit information of the input and output signals; The second language model recalculates the total precision factor and total offset based on the initial total precision factor and total offset as context input; If the two calculations are consistent, the current parameters are used for code generation; otherwise, the calculation is re-executed in the first stage.

7. The method according to claim 6, characterized in that, The signal matching includes signal matching in the transmitting direction and signal matching in the receiving direction; The signal matching in the transmission direction includes mapping the source signal in the application layer to the target signal in the communication bus; for the signal matching in the transmission direction, the total offset is equal to the negative ratio of the communication bus-side signal offset to the communication bus-side signal precision; wherein, the communication bus-side signal is the target signal in the transmission direction; The signal matching in the receiving direction includes mapping the source signal in the communication bus to the target signal in the application layer; for the signal matching in the receiving direction, the total offset is equal to the ratio of the signal offset on the communication bus side to the signal accuracy on the application layer side, wherein the signal on the communication bus side is the source signal in the receiving direction, and the signal on the application layer side is the target signal in the receiving direction.

8. A signal matching code generation system based on a large language model workflow, characterized in that, include: The signal generation module is used to perform field filtering and structured extraction on the pre-acquired raw communication matrix data to generate a target signal set; wherein, the raw communication matrix data includes the mapping relationship requirement information between application layer signals and communication bus signals; the target signal set contains multiple target signals, and the target signals include application layer signal data fields and communication bus signal data fields; The signal conversion module is used to input the target signal set into a workflow system composed of multiple heterogeneous large language models, determine the signal mapping type corresponding to each target signal through the workflow system, calculate the corresponding signal conversion parameters according to the determined mapping type, and generate code snippets corresponding to each target signal. The code generation module is used to merge and process multiple generated code snippets according to a predefined project source code file format to generate an object code file.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images