Space embedded software business logic error inference method and system

Abstract

The application provides a spaceflight embedded software business logic error inference method and system, and belongs to the technical field of spaceflight software quality guarantee. The method first forms a history defect business logic safety semantic vector library; generates a safety semantic vector of the code to be audited; then constructs a similarity matrix of the safety semantic vector to be audited and the safety semantic vector library; screens the history safety semantic vector with a similarity value greater than or equal to a preset threshold from the similarity matrix; infers the defect possibility level and risk level of the code to be audited based on the history defect information associated with the screened history safety semantic vector; and generates an audit report containing defect positioning, matching information, risk description and repair suggestions. The application also provides an error inference system. The application not only reuses history defect experience, but also breaks through the limitation of traditional tools that only detect general technical defects, and realizes automatic positioning and risk inference for business logic type errors.

Description

Technical Field

[0001] This invention belongs to the field of aerospace software quality assurance technology, and relates to a method and system for inferring business logic errors in aerospace embedded software based on semantically similar code and historical defect patterns. Background Technology

[0002] In existing technologies, code auditing tools mostly analyze code snippets without associating them with defect metadata.

[0003] The software code defect detection method and system based on program code feature fusion (CN120256273A) uses a software code defect detection method based on program code feature fusion to discover defects or vulnerabilities in the code; the code vulnerability detection method, device, medium and equipment (CN110363004B) discovers vulnerabilities by acquiring the program code to be detected and the preset taint data rules; the method, device, equipment and storage medium for establishing a code defect audit model (CN117454931A) discovers defects by comparing vector similarity based on the Siamese network model.

[0004] While the aforementioned patents have made some progress in areas such as general vulnerability detection and efficiency improvement, they still have significant shortcomings: 1. High false positive rate: In scenarios where "code structures are similar but defects are different", relying solely on code vectors will lead to a high false positive rate. 2. Inability to reuse historical defect experience: Key information such as the "risk level" and "remediation plan" of historical defects are not bound to code vectors, so even if similar code is matched, the defect risk cannot be directly inferred; 3. Not suitable for aerospace scenarios: The security features of aerospace software, such as "redundant design" and "multi-level verification", need to be combined with business semantic understanding. Relying solely on code structure vectors cannot capture the unique defects of scenarios such as "lack of redundancy verification".

[0005] In addition, existing aerospace software code auditing technologies suffer from two major bottlenecks: First, they rely on manual line-by-line inspection, which is inefficient; manually reviewing 125,000 lines of code would take approximately 12 working days. Second, they lack a mechanism for reusing historical defects—each new project audit requires re-annotating known problematic code, making it impossible to leverage experience with similar defects from past projects, leading to repetitive work, and the risk of missed detections increases with the number of projects. While semi-automated tools can handle syntax vulnerabilities, they lack a historical business defect-code vector library, making it impossible to match similar defects at the business logic level, resulting in a significant amount of work being spent on false positive elimination. Summary of the Invention

[0006] The technical problem solved by this invention is to overcome the shortcomings of the prior art and propose a method and system for inferring business logic errors in aerospace embedded software based on semantically similar codes and historical defect patterns.

[0007] The solution of the present invention is: Methods for inferring business logic errors in aerospace embedded software include: Collect known data on "business logic defects" from multiple historical aerospace projects, generate a business logic security semantic vector for each data point, and construct a business logic security semantic vector library; Extract code snippets from the aerospace software to be audited and generate a business logic security semantic vector for the aerospace software code to be audited. Calculate the similarity between the business logic security semantic vector of the code to be audited and all historical business logic security semantic vectors in the business logic security semantic vector library, and construct a similarity matrix between the vector to be audited and the historical vectors; Filter historical business logic security semantic vectors with similarity values ​​≥ a preset threshold from the similarity matrix; Based on the historical defect information associated with the selected historical business logic security semantic vectors, the defect probability level and risk level of the code to be audited are inferred, and an audit report containing defect location, matching information, risk description and remediation suggestions is generated.

[0008] The preferred method for constructing a business logic security semantic vector library is as follows: 1.1 Collect known data on "business logic defects" from multiple historical aerospace projects. The known data includes defect metadata and corresponding code snippets. 1.2 The defect metadata and corresponding code snippets are jointly embedded to generate a business logic security semantic vector for each known data. The generation process is as follows: 1.2.1 The "defect name + defect level + defect description + potential risk + aerospace business characteristics" in the defect metadata are fused to obtain natural language text, which is then input into the GraphCodeBERT model along with the standardized code snippet to obtain the basic semantic vector; 1.2.2 Generate code structure feature vectors. The generation method is as follows: a) For the function containing the defective code, generate a normalized function control flow graph and extract the critical path features of the defect; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 1.2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector; 1.3 Associate the business logic security semantic vector with the corresponding defect metadata and store it in the vector database to form a business logic security semantic vector library.

[0009] Preferably, the code snippets of the aerospace software to be audited are extracted, and a business logic security semantic vector of the code to be audited is generated. The process is as follows: 2.1 Extract code snippets from the aerospace software to be audited, extract aerospace business features from the code snippets and code snippet comments, add general security verification rules, generate business logic security vector defect metadata information, input into the GraphCodeBERT model, and obtain an 896-dimensional basic semantic vector; 2.2 Generate code structure feature vectors. The generation method is as follows: a) Generate a normalized function control flow graph for the function containing the code; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector.

[0010] Preferably, in step b), The existence characteristics of nodes are encoded using 5-dimensional integers to represent the existence status of core control nodes in aerospace software. The node type sequence features are extracted according to the execution order to extract the node types of the core path, using 10-dimensional integer encoding + position encoding, with zeros padded if the length is insufficient; The path branch features are encoded using one-dimensional integers to represent the branch logic type of the critical path; The data flow dependency features are encoded in 4-dimensional binary code, corresponding to the main sensor interface dependency, redundant sensor interface dependency, calibration reference value dependency, and bus communication data dependency, respectively. Each dimension is represented by "0 / 1" to indicate "no / yes" dependency.

[0011] Preferably, the defect metadata includes at least the fields of defect name, defect level, defect description, potential risk, aerospace business characteristics, file path where the defect is located, function name, and line number; the corresponding code snippet is a complete code segment that implements the business logic associated with the defect.

[0012] Preferably, the similarity between the business logic security semantic vector of the code to be audited and all historical business logic security semantic vectors in the business logic security semantic vector library is calculated using the following method: 3.1 Normalize the business logic security semantic vector of the code to be audited and all business logic security semantic vectors in the business logic security semantic vector library, and map the vector dimension values ​​to the [0,1] interval; 3.2 The cosine similarity algorithm is used to calculate the similarity of the normalized vectors.

[0013] Preferably, the probability of defects in the code to be audited is divided into three levels: high, medium, and low. When the similarity value is greater than or equal to 0.85, it is marked as high probability; when the similarity value is greater than or equal to 0.6 and less than 0.85, it is marked as medium probability; and when the similarity value is less than 0.6, it is marked as low probability.

[0014] The aerospace embedded software business logic error inference system includes a semantic embedding module, a security semantic vector generation module, a similarity calculation module, a candidate defect screening module, a risk inference module, and an audit report generation module. Semantic Embedding Module: Collects known data on "business logic defects" from multiple historical aerospace projects, generates a business logic security semantic vector for each data point, and constructs a business logic security semantic vector library; Security semantic vector generation module: Extracts code snippets from aerospace software and generates business logic security semantic vectors for the code; Similarity calculation module: Calculates the similarity between the business logic security semantic vector of the code to be audited and all historical business logic security semantic vectors in the business logic security semantic vector library, and constructs a similarity matrix between the vector to be audited and the historical vectors; Candidate defect screening module: Screens historical security semantic vectors with similarity values ​​≥ preset thresholds from the similarity matrix; The risk inference module infers the probability level and risk level of defects in the code to be audited based on historical defect information associated with the selected historical business logic security semantic vectors. Audit report generation module: Generates audit reports containing defect location, matching information, risk descriptions, and remediation suggestions.

[0015] The preferred implementation method for the semantic embedding module is as follows: 1.1 Collect known data on "business logic defects" from multiple historical aerospace projects. The known data includes defect metadata and corresponding code snippets. 1.2 The defect metadata and corresponding code snippets are jointly embedded to generate a business logic security semantic vector for each known data. The generation process is as follows: 1.2.1 The "defect name + defect description + potential risks + aerospace business characteristics" in the defect metadata are fused to obtain natural language text, which is then input into the GraphCodeBERT model along with the standardized code snippet to obtain the basic semantic vector; 1.2.2 Generate code structure feature vectors. The generation method is as follows: a) For the function containing the defective code, generate a normalized function control flow graph and extract the critical path features of the defect; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 1.2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector; 1.3 Associate the business logic security semantic vector with the corresponding defect metadata and store it in the vector database to form a business logic security semantic vector library.

[0016] The preferred implementation method for the secure semantic vector generation module is as follows: 2.1 Extract code snippets from the aerospace software to be audited, extract aerospace business features from the code snippets and code snippet comments, add general security verification rules, generate business logic security vector defect metadata information, input into the GraphCodeBERT model, and obtain an 896-dimensional basic semantic vector; 2.2 Generate code structure feature vectors. The generation method is as follows: a) Generate a normalized function control flow graph for the function containing the code; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector.

[0017] The advantages of this invention compared to the prior art are: (1) This invention effectively solves the problem of high false positives caused by the single semantic fusion dimension of existing technologies, which rely solely on code structure or syntactic features, leading to "similar codes but different defects." This invention uses dual-modal semantic fusion of code structure and defect metadata to effectively address the issue of high false positives caused by the single semantic fusion dimension of existing technologies, which rely solely on code structure or syntactic features. This invention co-encodes defect descriptions, risk levels, aerospace business characteristics, aerospace compliance clauses, and code logic to generate a unified semantic vector. This distinguishes code segments with similar structures but different business essences from the source of features, significantly reducing the false positive rate of business logic defects and improving the accuracy and reliability of auditing.

[0018] (2) This invention overcomes the problems of insufficient adaptability, inability to identify deep-seated business defects unique to aerospace, and insufficient reuse of historical experience in existing technologies by deeply adapting to the aerospace field and reusing historical defect experience in a closed loop. This invention incorporates aerospace-specific business characteristics such as "redundant design, multi-level verification, and multi-source data comparison," and adopts scenario-based dynamic thresholds and an iteratively updatable defect-code vector library to achieve accurate positioning of business logic defects, automatic inference of risk levels, and intelligent recommendation of repair solutions. This significantly improves audit efficiency, reduces labor costs, and truly meets the engineering requirements of high reliability, high security, and strong business constraints for aerospace embedded software. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the various modules of the present invention; Figure 2 This is a semantic similarity comparison diagram of the rocket propellant refueling module code in the embodiment. Detailed Implementation

[0020] The invention will now be further described with reference to the accompanying drawings.

[0021] This invention constructs a dual-modal business logic security semantic vector library of "historical business defects-code", and combines code logic structure with scenario-based dynamic threshold matching to achieve audit scenarios for automatic location and risk inference of business logic type errors.

[0022] This invention achieves automated inference of business logic errors through similarity matching of the business logic security semantic vector library of the project to be audited, specifically solving the following two technical problems: 1. This technology addresses the technical problem that traditional code auditing tools can only detect general technical defects and cannot accurately and automatically infer "business logic errors" in special fields such as aerospace. It overcomes the limitation of general tools being insufficiently adapted to business scenarios and achieves targeted identification of domain-specific business logic errors through semantic deep matching between the code to be audited and the historical business defect-code vector library.

[0023] 2. To address the technical problem that existing technologies lack a complete technical process of "construction of business logic security semantic vector library → generation of code vector to be audited → similarity matching → inference of similar defects", which makes it difficult to effectively reuse historical defect experience and accurately identify business logic defects across projects, a new method for identifying cross-project business logic defects is established by deeply integrating the reuse of historical experience with similarity analysis.

[0024] This invention is based on the core logic that "codes with similar business logic are prone to containing similar errors," and combines it with code semantic embedding technology incorporating aerospace safety knowledge to construct an automated auditing system for aerospace software business logic errors, with a "business logic security semantic vector library" at its core (its module relationships are as follows). Figure 1 This forms a fully automated system encompassing "vector library construction → auditable code processing → library-level matching → risk inference → report output," which both reuses historical defect experience and overcomes the limitations of traditional tools that only detect general technical defects. Figure 1 As shown, the method of the present invention is as follows: First, collect known data on "business logic defects" from multiple historical aerospace projects, generate a security semantic vector for each data point, and form a business logic security semantic vector library.

[0025] The specific steps are as follows: 1. Targeted collection of historical operational defect data in aerospace scenarios The known data on "business logic defects" in multiple historical aerospace projects includes defect metadata and corresponding code snippets.

[0026] 2. Basic semantic vector generation The natural language text generated by fusing "defect name + defect description + potential risks + aerospace business characteristics" from the defect metadata is input into the GraphCodeBERT model along with the standardized code snippets to generate 896-dimensional basic semantic vectors in batches.

[0027] 3. Extraction of code structure feature vectors a) For the function containing the defective code, a normalized function control flow graph (CFG) is generated using the LLVM tool, and the critical path features are extracted using a three-step method of "core variable tracking - critical path concatenation - aerospace business rule matching". b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from CFG: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively: Node Existence Characteristics: 5-dimensional integer encoding, representing the existence status of core control nodes in aerospace software (such as redundancy check nodes and threshold judgment nodes); Node type sequence features: 10-dimensional integer encoding + position encoding, extracting the node types of the core path according to the execution order, and padding with 0 if the length is insufficient; Path branch characteristics: 1-dimensional integer encoding, representing the branch logic type of the critical path; Data flow dependency characteristics: 4-dimensional binary encoding, corresponding to main sensor interface dependency, redundant sensor interface dependency, calibration reference value dependency, and bus communication data dependency respectively. Each dimension is represented by "0 / 1" to indicate "no / yes" dependency. c) Concatenate the above four types of structural features to generate a 20-dimensional code structure feature vector.

[0028] 4. Vector Fusion The 896-dimensional basic semantic vector and the 20-dimensional code structure feature vector are weighted and merged (the core defect feature dimension has a weight ratio of ≥40%) to generate a 916-dimensional business logic security semantic vector.

[0029] 5. Vector library storage The 916-dimensional business logic security semantic vectors are associated with the corresponding defect metadata and stored in the vector database to form a business logic security semantic vector library, which provides a targeted and reusable benchmark library for library-level similarity matching of code to be audited in the future.

[0030] Second, extract the code snippets and aerospace business characteristics of the aerospace software to be audited, and generate a security semantic vector of the code to be audited by combining general security verification rules.

[0031] 1. Extract code snippets and aerospace business characteristics of the aerospace software to be audited, add general security verification rules, input them into the GraphCodeBERT model, and obtain basic semantic vectors; 2. Generate code structure feature vectors. The generation method is as follows: a) Generate a normalized function control flow graph for the function containing the code; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 3. The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector.

[0032] 3. Calculate the similarity between the security semantic vector of the code to be audited and all historical security semantic vectors in the business logic security semantic vector library, and construct a similarity matrix between the vector to be audited and the historical vectors.

[0033] The specific steps are as follows: 1. Vector normalization For the business logic security semantic vector of the code to be audited and all business logic security semantic vectors in the business logic security semantic vector library, the Min-Max normalization method is used to map the vector dimension values ​​to the [0,1] interval to eliminate the numerical scale difference of different feature dimensions. 2. Similarity Calculation The cosine similarity algorithm is used to calculate the similarity of normalized vectors; the core aerospace safety feature dimensions such as "redundancy verification" and "safety threshold judgment" are assigned a weight of 1.5 times, and the auxiliary feature dimensions are assigned a weight of 0.8 times, in order to enhance the matching accuracy of aerospace business logic defects.

[0034] IV. Select historical security semantic vectors from the similarity matrix whose similarity value is greater than or equal to a preset threshold.

[0035] 5. Based on the historical defect information associated with the selected historical security semantic vectors, infer the defect probability level and risk level of the code to be audited, and generate an audit report containing defect location, matching information, risk description and remediation suggestions.

[0036] The probability of defects in the code to be audited is divided into three levels: high, medium, and low. When the similarity value is greater than or equal to 0.85, it is marked as high probability; when the similarity value is greater than or equal to 0.6 and less than 0.85, it is marked as medium probability; and when the similarity value is less than the preset threshold of 0.6, it is marked as low probability.

[0037] The system of the present invention includes a semantic embedding module, a security semantic vector generation module, a similarity calculation module, a candidate defect screening module, a risk inference module, and an audit report generation module.

[0038] I. Semantic Embedding Module: Based on the collection of historical defect data and its corresponding code segments, this module generates a multi-feature fusion business logic security semantic vector by generating basic semantic vectors and code structure feature vectors. This vector vector is then stored in a vector database as a business logic security semantic vector library, serving as the benchmark library for the similarity calculation module.

[0039] II. Security Semantic Vector Generation Module: Extracts code snippets from aerospace software and generates security semantic vectors for the business logic of the code.

[0040] III. Similarity Calculation Module The similarity calculation between the aerospace software to be audited and the business logic security semantic vector library is performed to form a similarity matrix between the vector to be audited and historical vectors. The specific steps are as follows: 1. Vector normalization For the business logic security semantic vector of the code to be audited and all business logic security semantic vectors in the business logic security semantic vector library, the Min-Max normalization method is used to map the vector dimension values ​​to the [0,1] interval to eliminate the numerical scale difference of different feature dimensions. 2. Similarity Calculation The cosine similarity algorithm is used to calculate the similarity of normalized vectors; the core aerospace safety feature dimensions such as "redundancy verification" and "safety threshold judgment" are assigned a weight of 1.5 times, and the auxiliary feature dimensions are assigned a weight of 0.8 times, in order to enhance the matching accuracy of aerospace business logic defects.

[0041] IV. Candidate Defect Screening Module: Based on historical aerospace project defect data, dynamic grading thresholds are set according to business importance; historical vectors that meet the similarity criteria are selected from the similarity matrix as "candidate defect vectors", and the segments in the code to be audited that correspond to the business logic of the candidate vectors are locked at the same time, so as to "accurately locate the code area where there may be similar business logic errors" and avoid the waste of efficiency caused by indiscriminate screening.

[0042] V. Risk Assessment Module Based on the dual dimensions of "weighted cosine similarity value + inherent risk attribute of historical defects", a risk level judgment system as shown in Table 1 is constructed to achieve accurate quantitative classification of business logic defects in aerospace embedded software. The classification threshold can be dynamically adjusted according to business needs. Table 1 is a judgment table for one of the classification threshold values ​​(0.60-0.85).

[0043] Table 1. Two-Dimensional Judgment Table for Risk Level of Codes to be Audited

[0044] Risk superposition: By using the inherent risk attributes of historical defects associated with candidate vectors and the risk level of the code to be audited obtained by weighted cosine similarity, the scope of risk impact is supplemented and marked, such as "affecting the safety of core stage propellant loading", so as to achieve accurate quantification of "level + impact" and avoid the one-sided judgment based solely on similarity.

[0045] VI. Audit Report Generation Module: A comprehensive output module for aerospace compliance, generating structured audit reports that meet standard requirements. Core content includes: Defect localization: The module path and line number range of the code to be audited; Matching information: similarity value, associated historical defect vector ID, and historical project background; Risk Description: Risk level, potential impact on aerospace safety, and compliance deviations; Repair suggestion: Implementable technical solutions, such as "supplementing the verification logic for the difference between the main / redundant sensors ≤ 0.05MPa, and adding a fault alarm branch when the difference exceeds the limit".

[0046] Example: This embodiment takes "a medium-sized launch vehicle launch control system version V4.2" as the audit object, and describes the execution process of the technical solution of the present invention for the known safety-level business logic error "propellant overpressure protection not triggered redundancy verification".

[0047] Implementation prerequisites: The target system is the "Propellant Loading Control Subsystem" of the launch control system for a carrier rocket. It is programmed in C language, with 125,000 lines of code. The core modules include three main control modules: "Core Stage Propellant Loading," "Booster Propellant Loading," and "Upper Stage Propellant Loading," as well as two auxiliary modules: "Pressure Sensor Data Acquisition" and "Valve Drive Control." The critical business logic requirement is that during propellant loading, when the pipeline pressure reaches the 1.2 MPa overpressure threshold, the system must first call the main pressure sensor interface (GetMainPressure()) and the redundant pressure sensor interface (GetRedundantPressure()) to acquire dual-channel data. Only after verifying that the difference is ≤0.05 MPa (the allowable sensor error range) can the "emergency valve closure" action be executed to prevent accidental or missed valve closure due to a single sensor failure.

[0048] This execution process aligns with the code review workflow of a launch vehicle's launch control system, proceeding step-by-step according to the logic of "library construction → audit processing → matching calculation → screening and inference → report generation," such as... Figure 2 As shown, the details are as follows: Step 1: Build a business logic security semantic vector library Based on the core innovation of "reusing historical experience", a vector library dedicated to aerospace scenarios is built to provide benchmark data for subsequent matching.

[0049] 1. Targeted Data Collection We collected historical defect data from over 500 aerospace projects over the past five years, totaling more than 2,000 valid records. 2. Data format standardization processing (1) Code snippet normalization Remove blank lines and comment lines, standardize the format, and retain the core execution logic; Based on an accumulated list of software business meanings, dictionary matching is used to replace code elements customized by developers, ensuring that semantics focus on business logic rather than coding style differences between different development teams.

[0050] (2) Structured encapsulation of defect information The following explanation uses a known business logic error message from a historical project, "Version V3.0 of a certain launch vehicle control system," as an example.

[0051] The error code originates from the "Core Stage Propellant Loading" module of the historical project "V3.0 Version of Launch Control System for a Certain Launch Vehicle". The module encapsulates its business defect metadata, including defect name, defect level, defect description, potential risks, and repair solutions, into a JSON structure. The defectKeyFeature field is added to store enhanced aerospace business characteristics. This field is used to extract embedded code feature vectors.

[0052] 3. Batch semantic vector generation (1) Input features: filter “core semantic fields + aerospace business features” in JSON and generate natural language text. The core semantic fields, such as defect name, missing code level, defect description, potential risks, repair plan, and aerospace business features, are concatenated and combined with standardized code fragments as input to GraphCodeBERT.

[0053] (2) Semantic vector generation: Batch generation of 896-dimensional semantic vectors, each vector is bound with a unique number, and the core defect feature dimension weight accounts for ≥40%. The semantic vector is obtained by merging the normalized code snippet above with the natural language text generated by "defect name + defect description + potential risk + aerospace business features" through calculation.

[0054] (3) CFG feature extraction: The LLVM tool is used to generate a normalized function CFG for the function containing the defective code. The critical path features related to the defect are extracted from the function-level CFG through a three-step method of "core variable tracking → critical path concatenation → business rule matching".

[0055] (4) Structural feature extraction: Based on program analysis, rule engine and aerospace business dictionary, CFG analysis is used to obtain core structural features and categories, and key path features are extracted.

[0056] (5) Structural feature numerical encoding: Convert the above features into numerical values ​​that the model can recognize. The encoding rules need to be fixed and adapted to the aerospace scenario. Convert the extracted key path features into a structural feature vector.

[0057] (6) Node type sequence features: Integer encoding + position encoding is used to define the core node type mapping of aerospace control flow. The node type sequence of the core path is extracted according to the execution order. The sequence has a length of 10, and if the length is insufficient, it is filled with 0.

[0058] (7) Extract path branch features: Extract path branches and encode them using a method similar to that used for extracting critical paths.

[0059] (8) Data flow dependency features: The binary encoded data flow dependency features are fixed in 4 dimensions, corresponding to the main sensor interface dependency, redundant sensor interface dependency, calibration benchmark value dependency, and bus communication data dependency respectively. Each dimension is represented by binary encoding to ensure coverage of the business scenario of multi-source data verification of aerospace software, while keeping the structural feature vector dimension fixed to adapt to the model input and vector library storage requirements.

[0060] (9) Structural feature vector normalization and splicing: Node existence (5-dimensional), node type sequence (10-dimensional), path branch (1-dimensional), data flow dependency (4-dimensional), splicing all encoded features to form a 20-dimensional structural feature vector.

[0061] (10) Business logic security semantic vector generation: The structural feature vector and the semantic vector are weighted and merged to form the final business logic security semantic vector of 916 dimensions.

[0062] 4. Vector library maintenance Set up an automatic project update mechanism: When new historical project defect data is added, the standardization process is automatically triggered → vector generation → manual review → vector storage.

[0063] Step 2: Generate the vector of the code to be audited Taking the propellant loading control subsystem of "V4.2 launch control system of a certain launch vehicle" as an example, the goal is to generate audit vectors that can be directly compared with the historical vector library.

[0064] 1. Extract the core business modules from the audited code, using independent functional units as the basic units. 2. Code standardization and normalization rule reuse: Adopt the same standardization strategy as the historical defect vector library to ensure consistent representation of the same logical code.

[0065] 3. Extract aerospace business characteristics from the code, such as keywords like propellant loading, redundant sensors, pressure threshold judgment, and dual-channel data comparison.

[0066] like Figure 2As shown, in step 2, during the generation of the auditable code vector, after extracting aerospace business features (such as propellant loading, redundant sensors, pressure threshold judgment, etc.) from the auditable code, security verification rules and general redundancy verification logic for aerospace embedded software are added accordingly. This operation serves as a key enhancement between the standardization processing of the auditable code and vector generation, ensuring that the semantic representation of the auditable code not only includes its own inherent business features but also incorporates general safety redundancy requirements in the aerospace field. This ensures that the generated 916-dimensional business logic security semantic vector can accurately match the defect features related to redundancy verification in the historical defect vector library, effectively avoiding defect omissions due to the code not explicitly reflecting redundancy verification logic. This further enhances the aerospace scenario adaptability and defect detection accuracy of the present invention. Figure 2 The process of extracting aerospace business features and generating auditable vectors in step 2 forms a complete technical closed loop.

[0067] 4. Generate the vectors to be audited using the enhanced GraphCodeBERT model that is completely identical to the historical vector library, with the same parameter configuration.

[0068] Step 3: Library-level similarity calculation Based on the business logic security semantic vector library generated from code and defects, a full similarity match is performed on the vectors to be audited to locate potential common defects.

[0069] 1. Global vector normalization ensures consistent scaling. The processing logic adopts "global Min-Max normalization", which scales the vectors to be audited uniformly based on the global minimum and maximum values ​​of the historical vector library, avoiding scale offset caused by individual normalization of the audited items.

[0070] 2. The weighted cosine similarity algorithm is used to calculate the similarity between the code vector to be audited and the historical defect vectors. The specific calculation method is as follows: a) Feature weight assignment: assign 1.5 times weight to core aerospace safety features in the vector, such as “redundancy check”, “safety threshold judgment”, and “dual-path data comparison”, and assign 0.8 times weight to non-core features; b) Weighted matching degree calculation: Multiply the values ​​of the corresponding dimensions of the two vectors by the weights of that dimension, and then sum the results of multiplying all dimensions to obtain the weighted matching degree; c) Weighted length calculation: Multiply the values ​​of each dimension of each vector by the corresponding weight, then calculate the sum of squares, and finally take the square root to obtain the weighted length of the two vectors; d) Similarity calculation: Divide the weighted matching degree by the product of the weighted lengths of the two vectors to obtain the weighted cosine similarity value; the closer the value is to 1, the higher the semantic similarity between the two vectors, and the closer it is to 0, the lower the similarity.

[0071] Step 4: Candidate Defect Screening 1. Threshold setting basis: Based on historical experience from multiple aerospace project audits, dynamic tiered thresholds are set according to business importance.

[0072] 2. Filtering results: Select qualified vectors from the similarity matrix and find vectors that meet the threshold requirements. The corresponding function is "high-risk candidate code fragment", which contains business logic errors similar to the missing redundancy verification of historical vector overpressure protection.

[0073] Step 5: Risk Assessment A dual-dimensional judgment method combining "similarity probability + aerospace safety risk" is employed to accurately quantify the defect risk of candidate segments, aligning with the "zero-tolerance" safety requirements of aerospace. By combining similarity values ​​with aerospace safety risks, the risk level of candidate segments is determined. 1. The core judgment logic is based on the "similarity between the vector to be audited and the historical defect vectors", superimposed with the "aerospace safety level of the historical defects", and finally outputs a two-dimensional conclusion of "error probability + safety risk level" to avoid risk misjudgment caused by single-dimensional judgment.

[0074] 2. Risk level classification criteria: Based on similarity and overlapping dimensions, a final judgment is made on the level of defects.

[0075] 3. Risk Impact Analysis: Based on the historical defect metadata related to reuse, and combined with the scenario of this embodiment, a risk impact analysis is provided.

[0076] Step 6: Report Generation Generate structured reports that meet the requirements of GJB 8114 and CAST 2024 aerospace specifications.

[0077] The contents not described in detail in this specification are common knowledge to those skilled in the art.

Claims

1. A method for inferring errors in the business logic of aerospace embedded software, characterized in that, include: Collect known data on "business logic defects" from multiple historical aerospace projects, generate a business logic security semantic vector for each data point, and construct a business logic security semantic vector library; Extract code snippets from the aerospace software to be audited and generate a business logic security semantic vector for the aerospace software code to be audited. Calculate the similarity between the business logic security semantic vector of the code to be audited and all historical business logic security semantic vectors in the business logic security semantic vector library, and construct a similarity matrix between the vector to be audited and the historical vectors; Filter historical business logic security semantic vectors with similarity values ​​≥ a preset threshold from the similarity matrix; Based on the historical defect information associated with the selected historical business logic security semantic vectors, the defect probability level and risk level of the code to be audited are inferred, and an audit report containing defect location, matching information, risk description and remediation suggestions is generated.

2. The aerospace embedded software business logic error inference method according to claim 1, characterized in that, The method for constructing a business logic security semantic vector library is as follows: 1.1 Collect known data on "business logic defects" from multiple historical aerospace projects. The known data includes defect metadata and corresponding code snippets. 1.2 The defect metadata and corresponding code snippets are jointly embedded to generate a business logic security semantic vector for each known data. The generation process is as follows: 1.2.1 The "defect name + defect level + defect description + potential risk + aerospace business characteristics" in the defect metadata are fused to obtain natural language text, which is then input into the GraphCodeBERT model along with the standardized code snippet to obtain the basic semantic vector; 1.2.2 Generate code structure feature vectors. The generation method is as follows: a) For the function containing the defective code, generate a normalized function control flow graph and extract the critical path features of the defect; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 1.2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector; 1.3 Associate the business logic security semantic vector with the corresponding defect metadata and store it in the vector database to form a business logic security semantic vector library.

3. The aerospace embedded software business logic error inference method according to claim 2, characterized in that, The process of extracting code snippets from the aerospace software to be audited and generating business logic security semantic vectors for the audited code is as follows: 2.1 Extract code snippets from the aerospace software to be audited, extract aerospace business features from the code snippets and code snippet comments, add general security verification rules, generate business logic security vector defect metadata information, input into the GraphCodeBERT model, and obtain an 896-dimensional basic semantic vector; 2.2 Generate code structure feature vectors. The generation method is as follows: a) Generate a normalized function control flow graph for the function containing the code; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector.

4. The aerospace embedded software business logic error inference method according to claim 2 or 3, characterized in that, In step b), The existence characteristics of nodes are encoded using 5-dimensional integers to represent the existence status of core control nodes in aerospace software. The node type sequence features are extracted according to the execution order to extract the node types of the core path, using 10-dimensional integer encoding + position encoding, with zeros padded if the length is insufficient; The path branch features are encoded using one-dimensional integers to represent the branch logic type of the critical path; The data flow dependency features are encoded in 4-dimensional binary code, corresponding to the main sensor interface dependency, redundant sensor interface dependency, calibration reference value dependency, and bus communication data dependency, respectively. Each dimension is represented by "0 / 1" to indicate "no / yes" dependency.

5. The aerospace embedded software business logic error inference method according to claim 2, characterized in that, The defect metadata includes at least the fields of defect name, defect level, defect description, potential risk, aerospace business characteristics, file path where the defect is located, function name, and line number; the corresponding code snippet is the complete code segment that implements the business logic associated with the defect.

6. The method for inferring errors in aerospace embedded software business logic according to claim 1, characterized in that, The similarity between the business logic security semantic vector of the code to be audited and all historical business logic security semantic vectors in the business logic security semantic vector library is calculated as follows: 3.1 Normalize the business logic security semantic vector of the code to be audited and all business logic security semantic vectors in the business logic security semantic vector library, and map the vector dimension values ​​to the [0,1] interval; 3.2 The cosine similarity algorithm is used to calculate the similarity of the normalized vectors.

7. The method for inferring errors in aerospace embedded software business logic according to claim 1, characterized in that, The probability of defects in the code to be audited is divided into three levels: high, medium, and low. When the similarity value is greater than or equal to 0.85, it is marked as high probability; when the similarity value is greater than or equal to 0.6 and less than 0.85, it is marked as medium probability; and when the similarity value is less than 0.6, it is marked as low probability.

8. An aerospace embedded software business logic error inference system, characterized in that, It includes a semantic embedding module, a security semantic vector generation module, a similarity calculation module, a candidate defect screening module, a risk inference module, and an audit report generation module; Semantic Embedding Module: Collects known data on "business logic defects" from multiple historical aerospace projects, generates a business logic security semantic vector for each data point, and constructs a business logic security semantic vector library; Security semantic vector generation module: Extracts code snippets from aerospace software and generates business logic security semantic vectors for the code; Similarity calculation module: Calculates the similarity between the business logic security semantic vector of the code to be audited and all historical business logic security semantic vectors in the business logic security semantic vector library, and constructs a similarity matrix between the vector to be audited and the historical vectors; Candidate defect screening module: Screens historical security semantic vectors with similarity values ​​≥ preset thresholds from the similarity matrix; The risk inference module infers the probability level and risk level of defects in the code to be audited based on historical defect information associated with the selected historical business logic security semantic vectors. Audit report generation module: Generates audit reports containing defect location, matching information, risk descriptions, and remediation suggestions.

9. The aerospace embedded software business logic error inference system according to claim 8, characterized in that, The semantic embedding module is implemented as follows: 1.1 Collect known data on "business logic defects" from multiple historical aerospace projects. The known data includes defect metadata and corresponding code snippets. 1.2 The defect metadata and corresponding code snippets are jointly embedded to generate a business logic security semantic vector for each known data. The generation process is as follows: 1.2.1 The "defect name + defect description + potential risks + aerospace business characteristics" in the defect metadata are fused to obtain natural language text, which is then input into the GraphCodeBERT model along with the standardized code snippet to obtain the basic semantic vector; 1.2.2 Generate code structure feature vectors. The generation method is as follows: a) For the function containing the defective code, generate a normalized function control flow graph and extract the critical path features of the defect; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 1.2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector; 1.3 Associate the business logic security semantic vector with the corresponding defect metadata and store it in the vector database to form a business logic security semantic vector library.

10. The aerospace embedded software business logic error inference system according to claim 8, characterized in that, The security semantic vector generation module is implemented as follows: 2.1 Extract code snippets from the aerospace software to be audited, extract aerospace business features from the code snippets and code snippet comments, add general security verification rules, generate business logic security vector defect metadata information, input into the GraphCodeBERT model, and obtain an 896-dimensional basic semantic vector; 2.2 Generate code structure feature vectors. The generation method is as follows: a) Generate a normalized function control flow graph for the function containing the code; b) Based on program analysis, rule engine, and aerospace business dictionary, extract four types of structural features from the function control flow graph: node existence, node type sequence, path branch, and data flow dependency, and encode them respectively; c) Concatenate the above four types of structural features to generate a code structure feature vector; 2.3 The basic semantic vector and the code structure feature vector are weighted and concatenated to generate a business logic security semantic vector.

Images