Method, device and storage medium for automatically generating embedded code

Abstract

The embodiment of the application provides a kind of embedded code automatic generation method, equipment and storage medium, the method comprises: obtaining the code requirement description for indicating the modification demand of reference embedded code;Code requirement description is parsed based on predefined atomic function pool, and structured requirement description document is generated;The reference embedded code is parsed, and code entity is extracted;The bidirectional mapping relationship between atomic function in atomic function pool and code entity is established, and code capability mapping table is generated based on bidirectional mapping relationship;The atomic function in structured requirement description document is matched with the code entity in code capability mapping table, and modification operation is executed according to the matching result on reference embedded code, and target embedded code is obtained.The machine understandable mapping of requirement to code is realized by constructing code capability mapping table, and the automation degree and security of embedded code modification are improved.

Description

Technical Field

[0001] This application relates to the field of embedded software development technology, and in particular to an embedded code automatic generation method, device and storage medium. Background Technology

[0002] In the development of embedded devices such as smart meters, automotive electronics, and industrial control systems, firmware code needs to adapt to the differentiated requirements of different customers and application scenarios. Traditional solutions require maintaining a separate code branch for each customer, and the version maintenance cost increases exponentially as the number of customers increases. Existing technologies employ a macro-switching approach based on conditional compilation, using predefined macro branches to achieve differentiated configurations for different customer versions. However, this approach generates exponential compilation combinations from N differences, and new customer requirements still require manual addition of macro branches. Furthermore, the difference knowledge is embedded within the code rather than externalized in a structured description, making automatic machine understanding and modification impossible. Another approach uses configuration file parameterization, reading parameter values ​​from the configuration file at runtime. However, this approach is limited by runtime boundary constraints and cannot guarantee the safety and determinism of modifications. Therefore, bridging the semantic gap between customer requirements and code implementation, and achieving safe, controllable, and automated differentiated modifications to existing baseline code, has become a pressing technical problem. Summary of the Invention

[0003] This application provides an embedded code automatic generation method, device, and storage medium, which can improve the efficiency and reliability of embedded code generation.

[0004] In a first aspect, embodiments of this application provide an automatic embedded code generation method, including: Obtain the code requirement description, which indicates the modification requirements for the baseline embedded code; Based on a predefined atomic function pool, the code requirement description is parsed to generate a structured requirement description document; wherein, the structured requirement description document corresponds to at least one atomic function in the atomic function pool; The benchmark embedded code is parsed to extract code entities from it; A bidirectional mapping relationship is established between the atomic functions in the atomic function pool and the code entities, and a code capability mapping table is generated based on the bidirectional mapping relationship; at least one code entity in the code capability mapping table is marked with a mutability attribute; the mutability attribute includes mutable points and invariable points; the mutable points indicate code entities that can be modified, and the invariable points indicate code entities that cannot be modified; The atomic functions in the structured requirements description document are matched with the code entities in the code capability mapping table to obtain the matching results; Based on the matching result, the code entities in the baseline embedded code are modified to obtain the target embedded code that conforms to the code requirement description.

[0005] Secondly, embodiments of this application provide a computer device, including a processor and a memory, wherein the memory is used to store computer programs; the processor is used to execute the programs stored in the memory to implement the embedded code automatic generation method described in any embodiment of the first aspect above.

[0006] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the embedded code automatic generation method described in any of the embodiments of the first aspect above. Attached Figure Description

[0007] Figure 1 This is a flowchart of an embedded code automatic generation method provided in an embodiment of this application; Figure 2 yes Figure 1 A flowchart of step S102; Figure 3 yes Figure 1 A flowchart of step S105; Figure 4 yes Figure 1 A flowchart of step S106; Figure 5 yes Figure 4 A flowchart of step S401; Figure 6 yes Figure 4 A flowchart of step S402; Figure 7 yes Figure 1 A flowchart of step S106; Figure 8 This is a schematic diagram of the structure of a computer device according to one embodiment of this application. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0009] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0010] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0011] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0012] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0013] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] This application provides an automatic embedded code generation method. This method can be applied to a computer device (hereinafter referred to as "device") equipped with an embedded development environment and capable of accessing baseline embedded code. The device modifies the baseline embedded code based on the above method to generate target embedded code.

[0016] This application provides an embodiment of an automatic embedded code generation method, such as... Figure 1 As shown, the method includes: S101: Obtain the code requirements description, which indicates the modification requirements for the baseline embedded code; S102: Based on a predefined atomic function pool, parse the code requirement description and generate a structured requirement description document; wherein, the structured requirement description document corresponds to at least one atomic function in the atomic function pool; S103: Parse the benchmark embedded code and extract the code entities from the benchmark embedded code; S104: Establish a bidirectional mapping relationship between atomic functions and code entities in the atomic function pool, and generate a code capability mapping table based on the bidirectional mapping relationship; at least one code entity in the code capability mapping table is marked with a mutability attribute; the mutability attribute includes mutable points and immutable points; mutable points indicate code entities that can be modified, and immutable points indicate code entities that cannot be modified; S105: Match the atomic functions in the structured requirements description document with the code entities in the code capability mapping table to obtain the matching results; S106: Based on the matching results, perform modification operations on the code entities in the baseline embedded code to obtain the target embedded code that meets the code requirement description.

[0017] The code requirements description refers to the modification requests made by the customer or developers to the baseline embedded code. These requirements descriptions can take various forms, including but not limited to natural language text, structured parameter tables, or user input through a visual configuration interface. The baseline embedded code refers to the original version of the embedded code that serves as the starting point for any modifications.

[0018] As an example, in step S101, the device acquires the code requirement description input by the user. For instance, if the user inputs "Demand cycle requirement is configurable, ranging from 1 to 60 minutes, default value changed to 10 minutes," the device receives this natural language text as a code requirement description. Alternatively, if the user selects "Demand cycle is configurable" through a visual configuration interface and fills in "Minimum value 1, Maximum value 60, Default value 10," the device converts the interface input into a unified code requirement description format. Those skilled in the art can choose an appropriate requirement input method based on actual deployment needs; this embodiment does not impose specific limitations on this.

[0019] The predefined atomic function pool refers to a data set containing multiple atomic functions, each of which is a configurable functional item. The structured requirements description document is a structured data file generated after parsing the code requirements description, used to record the atomic functions corresponding to the code requirements description and their modification requirements.

[0020] As an example, in step S102, the device parses the code requirement description based on a predefined atomic function pool to generate a structured requirement description document. For example, the atomic function pool contains multiple atomic functions such as demand cycle, communication protocol type, and encryption algorithm, each of which is a configurable function item. When the user inputs "demand cycle requirement is configurable, range 1 to 60 minutes, default value changed to 10 minutes", the device matches this requirement with the demand cycle atomic function in the atomic function pool. If the match is successful, the corresponding structured requirement description document is generated, recording the identifier, name, attributes, data type, value range, unit, and target value of the atomic function.

[0021] Here, code entities refer to operable program elements extracted from the benchmark embedded code, including but not limited to macro definitions, global variables, function pointers, conditional compilation branches, and data structures.

[0022] As an example, in step S103, the device performs static parsing of the benchmark embedded code using an abstract syntax tree to extract code entities. For instance, the benchmark embedded code contains program elements such as macro definitions corresponding to demand cycles, function pointers corresponding to encryption algorithms, and function implementations corresponding to the core metering algorithm. Through abstract syntax tree parsing, the device extracts code entity information such as demand cycle macro definitions and their default values, encryption algorithm function pointers and their currently pointed-to function names, and core metering algorithm functions and their implementations. Those skilled in the art can employ appropriate parsing strategies to extract code entities based on the actual code type and structure; this embodiment does not impose specific limitations on this.

[0023] The bidirectional mapping relationship refers to the correspondence between atomic functions and code entities, used to enable forward lookup from atomic functions to code entities and reverse tracing from code entities to atomic functions. The code capability mapping table is a data structure generated based on the bidirectional mapping relationship, containing the correspondence between atomic functions and code entities and their associated information. This associated information includes the type, position, current value, constraints, and variability attributes of the code entity.

[0024] As an example, in step S104, the device establishes a bidirectional mapping relationship between atomic functions in the atomic function pool and code entities, and generates a code capability mapping table based on the bidirectional mapping relationship. Specifically, the device establishes a bidirectional mapping relationship between the demand cycle atomic functions in the atomic function pool and the demand cycle macro definitions extracted in step S103, establishes a bidirectional mapping relationship between the encryption algorithm atomic functions and the encryption algorithm function pointers, and establishes a bidirectional mapping relationship between the metering core algorithm atomic functions and the metering core algorithm functions. Based on the above bidirectional mapping relationships, the device generates a code capability mapping table, which records the association information between each atomic function and its corresponding code entity. At the same time, the device marks the demand cycle macro definitions and encryption algorithm function pointers as variable points, and marks the metering core algorithm functions as immutable points. For example, after the demand cycle macro definition is marked as a variable point, its value is allowed to be modified in subsequent modification operations; after the metering core algorithm function is marked as an immutable point, its code implementation is prohibited from being modified in subsequent modification operations.

[0025] As an example, in step S105, the device matches the demand cycle atomic functions in the structured requirements description document generated in step S102 with the code entities in the code capability mapping table generated in step S104 to obtain a matching result. For example, the device matches the demand cycle atomic functions with the atomic function identifiers of each mapping item in the code capability mapping table to determine that the code entity corresponding to the demand cycle atomic function is a demand cycle macro definition.

[0026] The target embedded code refers to the embedded code obtained after performing modification operations on the baseline embedded code, which conforms to the modification requirements in the code requirement description, and is the output product of the modification operation.

[0027] As an example, in step S106, the device performs modification operations on the code entities in the baseline embedded code based on the matching result of step S105. For example, if the matching result indicates that the code entity corresponding to the demand cycle atomic function is a demand cycle macro definition, and the modification requirement is to change the demand cycle from 15 minutes to 10 minutes, the device replaces the value of the demand cycle macro definition from 15 to 10. As another example, if the matching result indicates that the code entity corresponding to the encryption algorithm atomic function is an encryption algorithm function pointer, and the modification requirement is to replace the encryption algorithm from SM2 to AES-128, the device changes the pointer to the encryption algorithm function from the SM2 encryption function to the AES-128 encryption function. After completing all modification operations, the device obtains the target embedded code that conforms to the code requirement description. Those skilled in the art can perform modification operations on the code entities using applicable modification methods based on the matching results and modification requirements; this embodiment does not specifically limit this.

[0028] In this embodiment, the requirement description is parsed through an atomic function pool to generate a structured requirement description document, realizing the conversion from unstructured requirements to structured data. Code entities are identified by parsing the baseline embedded code. A bidirectional mapping relationship is established between atomic functions and code entities, and variability attributes are marked to achieve rapid code location and security boundary definition. By matching the atomic functions in the structured requirement description document with the code entities in the code capability mapping table, and automatically executing modification operations based on the matching results, a fully automated closed loop from requirement input to code output is achieved, improving the efficiency and reliability of embedded code generation while ensuring modification security.

[0029] In one embodiment, such as Figure 2 As shown, step S102, which involves parsing the code requirement description based on a predefined atomic function pool to generate a structured requirement description document, includes: S201: Use the first neural network model to parse the code requirement description and identify the functional entities in the code requirement description; S202: Match the functional entity with the atomic functions in the predefined atomic function pool to determine the atomic function corresponding to the functional entity; S203: Generate a structured requirements description document based on the atomic functions corresponding to the functional entities.

[0030] Here, the first neural network model refers to a pre-trained semantic parsing model used for semantic parsing of the code requirement description. A functional entity refers to a functional item identified from the code requirement description, used to match it with atomic functions in the atomic function pool.

[0031] As an example, in step S201, the device inputs the code requirement description obtained in step S101 into the first neural network model for parsing, identifying the functional entities in the code requirement description. For example, if the user inputs a code requirement description of "configurable demand cycle, ranging from 1 to 60 minutes, default value changed to 10 minutes", the first neural network model performs semantic parsing on the text, identifying the functional entity corresponding to the requirement as "demand cycle", and simultaneously identifying the attribute corresponding to the requirement as "configurable", the constraint condition as "range from 1 to 60 minutes", and the target value as "10". Those skilled in the art can choose the appropriate neural network model structure and training method according to actual needs, and this embodiment does not specifically limit this.

[0032] As an example, in step S202, the device matches the functional entity identified in step S201 with the atomic functions in the predefined atomic function pool. For instance, if the functional entity identified in step S201 is "demand cycle," the device matches this functional entity with each atomic function in the atomic function pool, determines that there exists a demand cycle atomic function in the atomic function pool corresponding to "demand cycle," and the match is successful. The device then identifies this demand cycle atomic function as the atomic function corresponding to the functional entity.

[0033] As an example, in step S203, the device generates a structured requirements description document based on the atomic functions corresponding to the functional entities determined in step S202. For instance, based on the matched demand cycle atomic functions and the attributes "configurable," constraints "range 1 to 60 minutes," and target value "10" identified in step S201, the device generates a structured requirements description document corresponding to the demand cycle. This document records the identifier, name, attribute (configurable), data type (integer), value range (1 to 60), unit (minutes), and target value (10) of the demand cycle atomic functions. The device uses the generated structured requirements description document as input for subsequent steps.

[0034] In this embodiment, a first neural network model performs semantic parsing on the code requirement description, transforming unstructured natural language requirements into a structured description. By matching functional entities with atomic functions in the atomic function pool, automatic mapping from requirements to functional items is achieved. A structured requirement description document is generated, providing machine-readable input for subsequent code location and modification. These steps work together to achieve automatic conversion from natural language requirements to structured functional description documents, eliminating the need for manual parsing and input, improving the efficiency and accuracy of requirement processing, and bridging the semantic gap between requirement description and code implementation.

[0035] In one embodiment, step S104, establishing a bidirectional mapping relationship between atomic functions in the atomic function pool and code entities, includes: Establish a bidirectional mapping relationship based on the comment markers in the baseline embedded code; Alternatively, a bidirectional mapping relationship can be established based on the similarity between the identifier name of the code entity and the name of the atomic function in the atomic function pool; Alternatively, a second neural network model can be used to calculate the semantic similarity between code entities and atomic functions, and a bidirectional mapping relationship can be established based on semantic similarity.

[0036] As an example, the device establishes a bidirectional mapping relationship based on comment markers in the baseline embedded code. For instance, in the baseline embedded code, the comments above the demand cycle macro definition contain markers with a specific format, such as comments containing the atomic function identifier "DEMAND_PERIOD". By parsing these comment markers, the device identifies the correspondence between the macro definition and the demand cycle atomic function, and establishes a bidirectional mapping relationship accordingly.

[0037] As another example, the device establishes a bidirectional mapping relationship based on the similarity between the identifier name of the code entity and the name of the atomic function in the atomic function pool. For example, if the code entity identifier "DEMAND_PERIOD_MINUTES" contains the atomic function name "DEMAND_PERIOD", the device establishes the mapping relationship accordingly.

[0038] The second neural network refers to a pre-trained semantic matching model used to calculate the semantic similarity between code entities and atomic functions.

[0039] As another example, the device uses a second neural network model to calculate the semantic similarity between code entities and atomic functions. When the similarity exceeds a preset threshold, a mapping relationship is established. For example, there may be no name similarity between the code entity "g_protocol_handler" and the atomic function "communication protocol type," but a mapping relationship can be established through semantic similarity calculation. It should be noted that the first and second neural network models described above can use the same or different neural network architectures. For example, both can use a Transformer-based pre-trained language model architecture, but they are trained independently for different training tasks. That is, the first neural network model is fine-tuned based on code requirement descriptions and functional entity annotation data to identify functional entities from natural language requirements; the second neural network model is fine-tuned based on code entity and atomic function pairing data to calculate the semantic similarity between the two. Those skilled in the art can flexibly choose the specific architecture of the first and second neural network models according to actual application scenarios and technical requirements; this embodiment does not specifically limit this.

[0040] In this embodiment, a bidirectional mapping relationship between atomic functions and code entities is established through three methods: annotation tagging, name similarity matching, and semantic similarity calculation. This improves the coverage and flexibility of the mapping. For code entities that already contain explicit annotation tags, mappings can be established directly through the annotation tags. For code entities with consistent naming conventions, mappings can be automatically established through name similarity matching. For code entities with mismatched names but related semantics, mappings can be established by calculating semantic similarity through a second neural network model. These three methods complement each other, making the construction of the code capability mapping table more complete and accurate.

[0041] In one embodiment, such as Figure 3 As shown, step S105 involves matching the atomic functions in the structured requirements description document with the code entities in the code capability mapping table to obtain the matching results, including: S301: Match the atomic functions in the structured requirements description document with the code entities in the code capability mapping table to determine the first matching result; S302: If the first matching result fails, calculate the semantic similarity of the code entities in the atomic function and code capability mapping table in the structured requirements description document, perform similarity matching based on the semantic similarity, and determine the second matching result; S303: If the second matching result fails, mark it as pending confirmation and generate a prompt message.

[0042] In this context, identifier matching refers to the complete matching of atomic function identifiers in the structured requirements description document with the atomic function identifiers of each mapping item in the code capability mapping table. The first matching result refers to the indication information obtained after the identifier matching, indicating whether the matching was successful or unsuccessful.

[0043] As an example, in step S301, the device performs identifier matching between the atomic functions in the structured requirements description document and the code entities in the code capability mapping table to determine the first matching result. For example, the device compares the identifier of the demand cycle atomic function with the atomic function identifier of each mapping item in the code capability mapping table one by one. If there is a completely matching identifier, the first matching result is a successful match, and the code entity corresponding to the demand cycle atomic function is determined to be the demand cycle macro definition; if there is no completely matching identifier, the first matching result is a failed match.

[0044] Here, similarity matching refers to calculating the semantic similarity between atomic functions in the structured requirements description document and each code entity in the code capability mapping table using a semantic similarity model when the first matching result fails. The second matching result refers to the indication information obtained after the similarity matching, indicating whether the matching was successful or unsuccessful.

[0045] As an example, in step S302, when the first matching result fails, the device calculates the semantic similarity of each code entity in the atomic function and code capability mapping table in the structured requirements description document, performs similarity matching based on the semantic similarity, and determines the second matching result. For example, the device calculates the similarity of the semantic vectors of each code entity in the demand cycle atomic function and code capability mapping table. If the semantic similarity between the demand cycle atomic function and a certain code entity exceeds a preset threshold, the second matching result is a successful match, and the correspondence between the atomic function and the code entity is established; if the semantic similarity between the demand cycle atomic function and all code entities does not exceed the preset threshold, the second matching result is a failed match.

[0046] The notification message refers to the feedback information used to notify relevant personnel to manually confirm the matching failure.

[0047] As an example, in step S303, if the second matching result fails, the device marks the corresponding atomic function as pending confirmation and generates a prompt message. For instance, if the semantic similarity matching of the demand cycle atomic function still fails, it means that there is no corresponding code entity for the atomic function in the code capability mapping table. The device marks the atomic function as pending confirmation and generates a prompt message to notify relevant personnel to manually confirm whether the requirement involves a new functional module.

[0048] In this embodiment, the identifier matching first performs a fast full match, and when the match fails, a fuzzy match is performed by calculating semantic similarity. The two-level matching makes the process clear and controllable, taking into account both efficiency and fault tolerance. When all matches fail, the system marks the case as pending confirmation and generates prompt information to ensure that cases that cannot be automatically matched can be manually confirmed, thereby improving the reliability of the matching.

[0049] In one embodiment, such as Figure 4 As shown, step S106, which involves modifying the code entities in the baseline embedded code based on the matching results to obtain the target embedded code that conforms to the code requirements description, includes: S401: Determine the difference level based on the matching results. The difference level includes parameter-level difference, logic-level difference, and structural-level difference. S402: Based on the difference level, the code entity of the baseline embedded code is modified using the modification strategy corresponding to the difference level to obtain the target embedded code that meets the code requirement description.

[0050] The difference level refers to the hierarchical classification of differences between atomic functions in the structured requirements description document and their corresponding code entities in the baseline embedded code, determined based on the matching results. This includes parameter-level differences, logical-level differences, and structural-level differences. Parameter-level differences refer to differences involving only numerical parameter modifications. Logical-level differences refer to differences involving algorithm or strategy replacements. Structural-level differences refer to differences involving the addition or deletion of functional modules.

[0051] As an example, in step S401, the device determines the level to which the difference corresponding to each atomic function belongs based on the matching results. Specifically, the device performs a difference level determination on each matching result and classifies it into the corresponding level among parameter-level difference, logic-level difference, or structural-level difference.

[0052] The modification strategy refers to the method or rule used to perform modification operations on code entities in the baseline embedded code, corresponding to the difference level. Different difference levels correspond to different modification strategies.

[0053] As an example, in step S402, the device performs a modification operation corresponding to the difference level determined in step S401 on the corresponding code entity, thereby completing the modification of the code entities that need to be modified in the baseline embedded code. After the device completes the modification, it obtains the target embedded code that conforms to the code requirement description.

[0054] In this embodiment, by dividing the differences into three levels—parameter level, logic level, and structure level—and adopting different modification strategies for different levels, differentiated processing of differences is achieved, striking a balance between efficiency and security, and avoiding the inefficiency or security risks caused by a "one-size-fits-all" approach of handling all manual or fully automated processes.

[0055] In one embodiment, such as Figure 5 As shown, in step S401, the difference level is determined based on the matching results, including: S501: If the code entity corresponding to the atomic function in the matching result is a macro definition or a constant, it is determined to be a parameter-level difference; S502: If the code entity corresponding to the atomic function in the matching result is a function pointer or a conditional compilation branch, it is determined to be a logical-level difference; S503: If the atomic function in the matching result has no corresponding code entity in the code capability mapping table, it is determined to be a structural difference.

[0056] Macros refer to identifiers and their replacement values ​​defined through preprocessor directives, while constants refer to fixed values ​​defined directly in the code. Both are criteria for determining parameter-level differences.

[0057] As an example, in step S501, the device determines the difference level based on the code entity type corresponding to the atomic function in the matching result. If the code entity corresponding to the atomic function is a macro definition or a constant, the difference is determined to be a parameter-level difference. For example, if the code entity corresponding to the demand cycle atomic function in the matching result is a macro definition, the device determines that the difference corresponding to the demand cycle is a parameter-level difference.

[0058] In this context, a function pointer is a pointer variable that points to a function and stores the function's entry address. Different functions can be dynamically called through function pointers. Conditional compilation branches are compilation branches controlled by preprocessor directives, used to select different code segments for compilation based on different macro definitions during compilation. Both are criteria for determining logical-level differences.

[0059] As an example, in step S502, the device determines the difference level based on the code entity type corresponding to the atomic function in the matching result. If the code entity corresponding to the atomic function is a function pointer or a conditional compilation branch, the difference is determined to be a logical-level difference. For example, if the code entity corresponding to the atomic function of the encryption algorithm in the matching result is a function pointer, the device determines that the difference corresponding to the encryption algorithm is a logical-level difference.

[0060] Among them, structural-level differences refer to differences in which the atomic functions in the matching results have no corresponding code entities in the code capability mapping table, involving the addition or deletion of functional modules.

[0061] As an example, in step S503, the device determines the difference level based on whether the atomic function in the matching result has a corresponding code entity in the code capability mapping table. If the atomic function does not have a corresponding code entity in the code capability mapping table, the difference is determined to be a structural-level difference. For example, if a certain atomic function in the matching result does not have a corresponding code entity in the code capability mapping table, the device determines that the difference corresponding to the atomic function is a structural-level difference.

[0062] In this embodiment, by setting three judgment rules—that macro definitions or constants are judged as parameter-level differences, function pointers or conditional compilation branches are judged as logical-level differences, and atomic functions without corresponding entities in the code capability mapping table are judged as structural-level differences—automatic classification of difference levels is achieved, thereby improving the degree of automation and classification accuracy.

[0063] In one embodiment, such as Figure 6 As shown, step S402, which involves modifying the code entities of the baseline embedded code according to the difference level using a modification strategy corresponding to the difference level, includes: S601: If the difference level is parameter level difference, then directly replace the macro definition value or constant initialization value corresponding to the atomic function in the matching result; S602: If the difference level is a logical difference, then the function pointers corresponding to the atomic functions in the matching results are assigned values, or the code blocks are replaced in the conditional compilation branches corresponding to the atomic functions in the matching results, and the compilation verification is performed after the replacement. S603: If the difference level is structural, the code skeleton of the new functional module is generated through the code template engine and marked as to be supplemented.

[0064] As an example, in step S601, when the difference level is a parameter-level difference, the device directly replaces the macro definition value or constant initialization value corresponding to the atomic function in the matching result, that is, it modifies the original macro definition value or constant initialization value to the target value. For example, if the difference corresponding to the demand cycle is determined to be a parameter-level difference, the device directly replaces the value of the demand cycle macro definition from 15 to 10.

[0065] As an example, in step S602, when the difference level is a logical difference, the device performs function pointer assignment on the function pointer corresponding to the atomic function in the matching result, modifying the pointer's target function; or, it performs code block replacement on the conditional compilation branch corresponding to the atomic function in the matching result, replacing the original conditional compilation branch code segment with the target code segment, and then calls the compiler to compile the modified code to verify its correctness. For example, if the difference corresponding to the encryption algorithm is determined to be a logical difference, the device changes the pointer of the encryption algorithm function from the SM2 encryption function to the AES-128 encryption function, and then calls the cross-compiler to compile and verify the code after the replacement, ensuring that the modified code can be compiled correctly.

[0066] As an example, in step S603, when the difference level is a structural difference, the device generates a code skeleton for the new functional module through the code template engine. This code skeleton contains the basic structure and interface definition of the module and is marked as needing to be supplemented, to prompt relevant personnel to supplement the specific implementation details of the module later. For example, if a certain atomic function has no corresponding code entity in the code capability mapping table, it is determined to be a structural difference. The device generates a code skeleton for the new functional module through the code template engine and marks it as needing to be supplemented, to prompt relevant personnel to supplement the specific implementation of the module later.

[0067] In this embodiment, by adopting different modification execution methods for different difference levels, differentiated processing of difference modifications is achieved. While ensuring modification efficiency, the security and correctness of the modifications are ensured through compilation verification and manual intervention.

[0068] In one embodiment, such as Figure 7 As shown, in step S106, before performing modification operations on the code entities in the baseline embedded code, the embedded code automatic generation method further includes: S701: Determine the differences based on the matching results; S702: Generate an initial modification operation sequence based on the differences; the initial modification operation sequence contains at least one atomic modification operation; S703: Generate a directed acyclic graph structure based on the dependencies between atomic modification operations in the initial modification operation sequence; S704: Determine the execution order of each atom modification operation based on the directed acyclic graph structure to obtain the target modification operation sequence.

[0069] Here, the difference item refers to the difference information between the atomic function that needs to be modified and the corresponding code entity, as determined by the matching result.

[0070] As an example, in step S701, the device determines the difference item based on the matching result. For instance, if the matching result indicates that the code entity corresponding to the demand cycle atomic function is a demand cycle macro definition, and the modification requirement is to change the demand cycle from 15 minutes to 10 minutes, the device determines this macro definition and its values ​​before and after the modification as a difference item.

[0071] An atomic modification operation is the smallest indivisible unit of modification, comprising the operation type, target file, target code entity, value before modification, and value after modification. An initial sequence of modification operations refers to a set of operations consisting of at least one atomic modification operation.

[0072] As an example, in step S702, the device generates an initial modification operation sequence based on the differences. For instance, the device converts the differences in the demand period macro definition into an atomic modification operation. This atomic modification operation is of type "modification," indicating that the operation changes the value of an existing code entity. The target file is the header file containing the demand period macro definition, indicating the location where the modification operation is applied. The target code entity is the demand period macro definition itself, indicating the specific code element being modified. The value before modification is the current value of the macro definition, i.e., the original configuration value of the demand period in the baseline embedded code. The value after modification is the target value to which the macro definition needs to be changed, i.e., the demand period value specified in the code requirement description.

[0073] A directed acyclic graph (DAG) is a graph structure with atomic modification operations as nodes and the dependencies between atomic modification operations as directed edges, used to determine the execution order of atomic modification operations.

[0074] As an example, in step S703, the device generates a directed acyclic graph structure based on the dependencies between the atomic modification operations in the initial modification operation sequence. For instance, if modification operation A involves modifying a macro definition, and modification operation B involves modifying the code segment that references that macro definition, then modification operation A must be executed before modification operation B. The device establishes dependencies and generates a directed acyclic graph accordingly to determine the execution order of the atomic modification operations.

[0075] The target modification operation sequence refers to the atomic modification operation sequence with execution order obtained by sorting the atomic modification operations in the initial modification operation sequence according to the execution order of each atomic modification operation determined by the directed acyclic graph structure.

[0076] As an example, in step S704, the device determines the execution order of each atomic modification operation based on the directed acyclic graph structure to obtain the target modification operation sequence. For example, the device traverses the directed acyclic graph structure, outputs each atomic modification operation in topological order, arranges the earlier atomic modification operations as priority operations, and arranges the later atomic modification operations as subsequent operations, thereby forming the target modification operation sequence.

[0077] In this embodiment, the differences are first determined based on the matching results, providing a specific basis for the modification operations. Then, an initial sequence of modification operations is generated based on the differences, and it is broken down into the smallest indivisible modification units. Next, a directed acyclic graph structure is generated based on the dependencies between the atomic modification operations to clarify the dependency constraints between the operations. Finally, the execution order of each atomic modification operation is determined based on the directed acyclic graph structure to obtain the target sequence of modification operations. This avoids compilation errors or logical conflicts caused by improper modification order and ensures the correctness and stability of the modification execution.

[0078] In one embodiment, after modifying the code entities in the baseline embedded code, the embedded code automatic generation method further includes: Store the target modification operation sequence as a structured patch; The structured patch is associated with and stored with the baseline embedded code to generate the target version.

[0079] Among them, a structured patch refers to a reusable modification description file containing complete information about each atomic modification operation obtained by storing the target modification operation sequence in a structured manner.

[0080] As an example, the device stores the target modification operation sequence as a structured patch. For instance, the device stores information such as the operation type, target file, target code entity, pre-modification value, and post-modification value of the atomic modification operation defined by the demand period macro in a patch file in JSON format.

[0081] As an example, the device associates and stores a structured patch with a baseline embedded code to generate a target version. For instance, the device associates and stores the structured patch with the baseline embedded code to form a target version of the baseline embedded code. When it is necessary to restore or view the complete code of this version, the structured patch can be applied over the baseline embedded code. The device outputs the generated target version as the customized code.

[0082] In this embodiment, by storing the target modification operation sequence as a structured patch, the complete information of each modification is persistently saved, which facilitates subsequent traceability and reuse. By associating the structured patch with the baseline embedded code to generate the target version, each target version is composed of the baseline code and the patch. There is no need to maintain a complete code copy for each customer separately. When the baseline version is upgraded, the structured patch can automatically attempt to merge into the new version, thereby reducing the maintenance cost of multiple versions from linear growth to an approximately constant value.

[0083] In one embodiment, after modifying the code entities in the baseline embedded code to obtain the target embedded code that conforms to the code requirements description, the automatic embedded code generation method further includes: Perform verification on the target embedded code, including at least one of the following: compilation verification, scope verification, and dependency verification; If the verification fails, the system will roll back to the state before the modification and output a failure reason report.

[0084] Among these, compilation verification refers to calling the compiler to compile the modified code and verifying whether the modified code can be compiled successfully. Range verification refers to verifying whether the modified values ​​are within a valid range based on the constraints recorded in the code capability mapping table. Dependency verification refers to checking whether the modification violates the interface agreement between modules. Rollback refers to restoring the modified code to its state before the modification operation was performed.

[0085] As an example, the device performs at least one of the following on the modified target embedded code: compilation verification, scope verification, and dependency verification. For instance, the device calls a cross-compiler to perform compilation verification on the modified target embedded code to verify whether the modified code can be compiled successfully; at the same time, it performs scope verification based on the constraints recorded in the code capability mapping table; and it performs dependency verification on the modified target embedded code to check whether the interface agreements between modules are violated.

[0086] As an example, if any of the compilation verification, scope verification, or dependency verification fails, the device automatically rolls back the modified code to the state before the modification was performed and outputs a failure reason report to inform the user of the specific reason and location of the verification failure.

[0087] The modified code is verified through compilation verification, range verification, and dependency verification to ensure that the code can be compiled successfully, the modified values ​​are within the legal range, and the interface agreements between modules are not violated. When the verification fails, the code is automatically rolled back to the state before the modification and a failure reason report is output, which avoids the generation and propagation of erroneous code and improves the security and reliability of code generation.

[0088] As can be seen from the above, the embedded code automatic generation method provided in this application first transforms unstructured requirement descriptions into structured data through an atomic function pool, bridging the semantic gap between requirements and code. Then, by parsing the baseline embedded code to extract code entities, and combining the bidirectional mapping relationship between atomic functions and code entities with variability markers, a code capability mapping table is generated, providing basic data for subsequent matching and modification. Based on this, a two-level matching strategy achieves accurate positioning from requirements to code, and the differences are divided into three levels according to the matching results. Different modification strategies are adopted for different levels, achieving differentiated automatic modification. During the modification process, the correctness of the modification order is ensured by generating a directed acyclic graph structure, low-cost version management is achieved through a structured patch mechanism, and the security and correctness of the modified code are guaranteed through triple verification. These steps work together to form a fully automated closed loop from requirement input to code output, improving the efficiency and reliability of embedded code generation while ensuring modification security.

[0089] In one embodiment, a computer device is provided, the internal structure of which can be shown as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the functions or steps of an embedded code automatic generation method.

[0090] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the code requirements description, which indicates the modification requirements for the baseline embedded code; Based on a predefined atomic function pool, the code requirement description is parsed to generate a structured requirement description document; wherein, the structured requirement description document corresponds to at least one atomic function in the atomic function pool; The benchmark embedded code is parsed to extract code entities from it. Establish a bidirectional mapping relationship between atomic functions and code entities in the atomic function pool, and generate a code capability mapping table based on the bidirectional mapping relationship; at least one code entity in the code capability mapping table is marked with a mutability attribute; the mutability attribute includes mutable points and immutable points; mutable points indicate code entities that can be modified, and immutable points indicate code entities that cannot be modified; The atomic functions in the structured requirements description document are matched with the code entities in the code capability mapping table to obtain the matching results; Based on the matching results, modification operations are performed on the code entities in the baseline embedded code to obtain the target embedded code that meets the code requirement description.

[0091] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, performs the following steps: Obtain the code requirements description, which indicates the modification requirements for the baseline embedded code; Based on a predefined atomic function pool, the code requirement description is parsed to generate a structured requirement description document; wherein, the structured requirement description document corresponds to at least one atomic function in the atomic function pool; The benchmark embedded code is parsed to extract code entities from it. Establish a bidirectional mapping relationship between atomic functions and code entities in the atomic function pool, and generate a code capability mapping table based on the bidirectional mapping relationship; at least one code entity in the code capability mapping table is marked with a mutability attribute; the mutability attribute includes mutable points and immutable points; mutable points indicate code entities that can be modified, and immutable points indicate code entities that cannot be modified; The atomic functions in the structured requirements description document are matched with the code entities in the code capability mapping table to obtain the matching results; Based on the matching results, modification operations are performed on the code entities in the baseline embedded code to obtain the target embedded code that meets the code requirement description.

[0092] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0093] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0094] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0095] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications 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 this application, and should all be included within the protection scope of this application.

[0096] It should be noted that when the above embodiments of this application are applied to specific products or technologies, and user-related data is involved, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A method for automatically generating embedded code, characterized in that, include: Obtain the code requirement description, which indicates the modification requirements for the baseline embedded code; Based on a predefined atomic function pool, the code requirement description is parsed to generate a structured requirement description document; wherein, the structured requirement description document corresponds to at least one atomic function in the atomic function pool; The benchmark embedded code is parsed to extract code entities from it; A bidirectional mapping relationship is established between the atomic functions in the atomic function pool and the code entities, and a code capability mapping table is generated based on the bidirectional mapping relationship; at least one code entity in the code capability mapping table is marked with a mutability attribute; the mutability attribute includes mutable points and invariable points; the mutable points indicate code entities that can be modified, and the invariable points indicate code entities that cannot be modified; The atomic functions in the structured requirements description document are matched with the code entities in the code capability mapping table to obtain the matching results; The difference level is determined based on the matching result, and the difference level includes parameter-level difference, logic-level difference, and structural-level difference. If the difference level is a parameter-level difference, then the macro definition value or constant initialization value corresponding to the atomic function in the matching result is directly replaced; if the difference level is a logical-level difference, then the function pointer corresponding to the atomic function in the matching result is assigned a function pointer value, or the conditional compilation branch corresponding to the atomic function in the matching result is replaced with a code block, and compilation verification is performed after replacement; if the difference level is a structural-level difference, then the code skeleton of the new functional module is generated through the code template engine and marked as to be supplemented.

2. The embedded code automatic generation method as described in claim 1, characterized in that, The predefined atomic function pool is used to parse the code requirement description and generate a structured requirement description document, including: The code requirement description is parsed using a first neural network model to identify the functional entities in the code requirement description; The functional entity is matched with the atomic functions in the predefined atomic function pool to determine the atomic function corresponding to the functional entity; Based on the atomic functions corresponding to the functional entities, a structured requirements description document is generated.

3. The embedded code automatic generation method as described in claim 1, characterized in that, The establishment of a bidirectional mapping relationship between atomic functions in the atomic function pool and the code entities includes: The bidirectional mapping relationship is established based on the comment markers in the baseline embedded code; Alternatively, the bidirectional mapping relationship can be established based on the similarity between the identifier name of the code entity and the name of the atomic function in the atomic function pool; Alternatively, a second neural network model can be used to calculate the semantic similarity between the code entity and the atomic function, and the bidirectional mapping relationship can be established based on the semantic similarity.

4. The embedded code automatic generation method as described in claim 1, characterized in that, The step of matching the atomic functions in the structured requirements description document with the code entities in the code capability mapping table to obtain the matching results includes: The atomic functions in the structured requirements description document are matched with the code entities in the code capability mapping table to determine the first matching result; If the first matching result fails, the semantic similarity between the atomic functions in the structured requirements description document and the code entities in the code capability mapping table is calculated, and similarity matching is performed based on the semantic similarity to determine the second matching result. If the second matching result fails, it is marked as pending confirmation, and a prompt message is generated.

5. The embedded code automatic generation method as described in claim 1, characterized in that, Determining the difference level based on the matching result includes: If the code entity corresponding to the atomic function in the matching result is a macro definition or a constant, it is determined to be a parameter-level difference; If the code entity corresponding to the atomic function in the matching result is a function pointer or a conditional compilation branch, it is determined to be a logical-level difference; If the atomic function in the matching result has no corresponding code entity in the code capability mapping table, it is determined to be a structural difference.

6. The embedded code automatic generation method as described in claim 1, characterized in that, Before performing modification operations on the code entities in the baseline embedded code, the automatic embedded code generation method further includes: Based on the matching results, determine the differences; Based on the differences, an initial modification operation sequence is generated; the initial modification operation sequence contains at least one atomic modification operation. Based on the dependencies between the atomic modification operations in the initial modification operation sequence, a directed acyclic graph structure is generated; The execution order of each atom modification operation is determined based on the directed acyclic graph structure, thus obtaining the target modification operation sequence.

7. The embedded code automatic generation method as described in claim 6, characterized in that, After modifying the code entities in the baseline embedded code, the automatic embedded code generation method further includes: The target modification operation sequence is stored as a structured patch; The structured patch is associated with and stored with the baseline embedded code to generate the target version.

8. The embedded code automatic generation method as described in claim 1, characterized in that, After modifying the code entities in the baseline embedded code to obtain the target embedded code that conforms to the code requirement description, the automatic embedded code generation method further includes: The target embedded code is validated, and the validation includes at least one of the following: compilation validation, scope validation, and dependency validation; If the verification fails, the system will roll back to the state before modification and output a failure reason report.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the embedded code automatic generation method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the embedded code automatic generation method as described in any one of claims 1 to 8.

Images