A method and system for detecting mode transition requirement conflicts in onboard software based on LLMs

Abstract

The application discloses a kind of based on LLM's airborne software mode conversion demand conflict detection method and system, its method first constructs mode conversion demand description meta-model;Then prompt word based on meta-model preset is used to guide LLM to automatically extract mode conversion demand element from natural language requirement and constructs mode conversion graph and demand dependency graph;On the basis of the dependency graph, intermediate variable in the conversion condition is replaced with input variable, and an input condition tree is constructed, and multiple demand scenarios are obtained by traversing the tree;Finally, based on the demand scenario, a system of constraint equations is generated, and a constraint solver is called to solve the constraints to detect conflicts.The application realizes end-to-end automated processing from fine-grained natural language requirements to formalized conflict detection, which can effectively discover implicit mode conversion demand conflicts and provide technical support for deep demand conflict detection in high safety systems such as avionics.

Description

Technical Field

[0001] This invention relates to the field of requirements engineering technology, and more specifically, to a method and system for detecting requirements conflicts in airborne software schema transformation based on Large Language Model (LLM). Background Technology

[0002] As a typical safety-critical control software, airborne software's mode-switching requirements describe the behavioral logic of the system switching from one operating mode to another under specific conditions, and are core to ensuring the safe operation of the system. In industrial practice, such requirements usually exist in the form of large-scale, fine-grained natural language documents, and their conflict detection is directly related to the software's security and reliability. Currently, conflict detection for mode-switching requirements mainly relies on manual review or semi-automated rule matching methods, which are labor-intensive, inefficient, and prone to omissions due to human error.

[0003] However, existing methods have significant technical shortcomings when addressing the requirements of industrial-grade airborne software. First, the schema transformation logic is scattered across numerous requirement items, lacking an explicit, structured behavioral model, making it difficult to automatically and accurately extract schema transformation semantics and complex nested conditions from natural language text. Second, schema transformation conditions often involve long-range requirement dependency chains, with intermediate variables defined by other requirements and potentially further dependent on upstream variables. Existing technologies struggle to automatically uncover such implicit dependencies, preventing the automatic and complete construction of the constraint system required for verification. Third, while LLM has shown potential in the field of natural language processing, general models lack deep integration and structured guidance of airborne software domain knowledge, making it difficult to accurately identify schema transformation semantics and understand complex dependencies and time constraints between requirements, resulting in incomplete extraction results or semantic biases.

[0004] Therefore, there is an urgent need for an automated method that can deeply integrate knowledge from the airborne software domain, automatically mine implicit dependencies between requirements, and effectively guide large language models to perform structured semantic extraction. This method would address the core pain points of high human involvement and difficulty in capturing implicit dependencies in current mode conversion requirement verification, and achieve efficient, accurate, and automated conflict detection for airborne software mode conversion requirements. Summary of the Invention

[0005] In view of this, the purpose of this invention is to address the problems of high manual involvement, low efficiency, difficulty in automatically capturing implicit dependencies, and incomplete constraint system construction in existing pattern transformation requirement verification processes. This invention proposes an LLM-based method and system for detecting conflicts in airborne software pattern transformation requirements, achieving efficient, accurate, and automated transformation from fine-grained natural language requirements to verifiable constraint systems. While existing technologies attempt to introduce LLM for requirement semantic extraction, they generally lack deep integration and structured guidance of airborne software domain knowledge, resulting in inaccurate pattern transformation semantic recognition, incomplete long-range dependency mining, and omissions in the generated constraint systems, failing to meet the stringent requirements of consistency, completeness, and traceability for safety-critical software. This invention introduces a domain-specific pattern transformation requirement description meta-model, explicitly providing LLM with structured domain knowledge related to airborne software. It systematically guides LLM in extracting pattern transformation requirement elements, identifying requirement dependencies, generating requirement scenarios, and generating and solving constraint equations. This solves the problems of long processing times, low accuracy, and insufficient logical consistency associated with traditional manual review, providing a high-quality technical path for the automated verification of airborne software pattern transformation requirements.

[0006] The specific technical solution for achieving the objective of this invention is as follows:

[0007] A method for detecting airborne software schema conversion requirement conflicts based on LLM (Large Language Model) includes the following steps:

[0008] Step 1: Construct a meta-model describing the requirements for airborne software mode conversion:

[0009] This paper summarizes and describes the components of airborne software mode conversion requirements, extracts the core concepts of airborne software mode conversion requirements, defines the relationships between the core concepts, and forms a meta-model for the mode conversion requirements description.

[0010] Step 2: Construct a meta-model-driven schema transformation graph:

[0011] Based on the core concepts of the meta-model and the relationships between the core concepts, prompt words are designed. LLM is used to identify modes, mode transitions, and transition conditions from the airborne software mode transition requirements, and a mode transition diagram is constructed.

[0012] Step 3: Identify requirement dependencies:

[0013] Based on the aforementioned pattern transformation graph, LLM is used to extract the assignment variables of the action part, the reference variables of the condition and action part, and the variable assignment expressions from the requirement text, and to construct a requirement dependency graph with variables as nodes and dependencies as edges, revealing the dependencies between requirements.

[0014] Step 4: Generate requirement scenarios:

[0015] Based on the aforementioned demand dependency graph, the intermediate variables contained in the transformation conditions are equivalently replaced with input variables to generate an input condition tree with the input variable conditions as leaf nodes; the input condition tree is traversed and a set of demand scenarios is generated accordingly.

[0016] Step 5: Scenario-based generation of constraint equations and conflict detection:

[0017] For each requirement scenario, the input conditions and their included time constraints are uniformly encoded into a set of constraint equations, and the constraint solver is called to determine the satisfiability. If the set of constraint equations is not satisfiable, it is determined that there is a mode conversion requirement conflict in the scenario. Finally, the requirement scenarios with mode conversion requirement conflicts are recorded and input into the feedback document.

[0018] Furthermore, the core concepts mentioned in the first step specifically include: pattern transformation requirements, intra-pattern requirements, inter-pattern requirements, conditions, conditional time constraints, actions, action time constraints, patterns, pattern transformation, transformation conditions, pattern transformation diagrams, assignment variables, and reference variables. The relationships between these core concepts specifically include: the generalization relationship between pattern transformation requirements and intra-pattern and inter-pattern requirements; the combination relationship between pattern transformation requirements and conditions and actions; the inclusion relationship between conditions and conditional time constraints, and between actions and action time constraints; the relationships between inter-pattern requirements, patterns, pattern transformation, transformation conditions, and pattern transformation diagrams; and the relationships between intra-pattern requirements, assignment variables, and reference variables.

[0019] Furthermore, the second step specifically includes: based on the prompt word template preset by the meta-model, the template includes role definition, task specifications, recognition rules and structured output mode definition; guiding the LLM to identify inter-mode requirements from natural language requirements based on the prompt word template, and extracting mode conversion elements including modes, mode conversion and conversion conditions, and constructing the conversion conditions into a condition tree, and finally constructing a mode conversion graph with modes as nodes and conversion relationships containing conversion conditions as edges.

[0020] Furthermore, the fourth step specifically includes: based on the demand dependency graph, equivalently replacing the intermediate variables contained in the mode conversion conditions with input variables to generate an input condition tree with input variable conditions as leaf nodes, wherein the equivalent replacement includes a replacement strategy for single intermediate variable condition expressions and a replacement strategy for multiple intermediate variable condition expressions; traversing the input condition tree, collecting the union of subtree scenarios for OR nodes, calculating the Cartesian product of subtree scenarios for AND nodes, and finally obtaining all feasible demand scenarios.

[0021] Furthermore, in the fifth step, the input variable conditions and their included time constraints in each scenario are uniformly encoded into a set of constraint equations. The encoding methods specifically include five types: basic logical constraint encoding, condition duration constraint encoding, action execution time constraint encoding, action causal time constraint encoding, and condition-action comprehensive time constraint encoding.

[0022] An airborne software mode switching requirement conflict detection system based on the above method includes:

[0023] The requirement element extraction module is used to classify mode transformation requirements into intra-mode requirements and inter-mode requirements based on the meta-model using LLM, and extract mode transformation requirement elements from them.

[0024] The model building module is used to organize the information extracted using LLM into schema transformation diagrams and demand dependency diagrams.

[0025] The requirement scenario generation module is used to generate an input condition tree and extract requirement scenarios;

[0026] The constraint equation generation and conflict detection module is used to encode the constraints of various requirement scenarios into constraint equations, call the solver to perform conflict detection, and generate the final feedback document.

[0027] Compared with the prior art, the present invention has significant beneficial effects.

[0028] This invention enables LLM (Limited Language Modeling) to more accurately identify the schema transformation requirements and their complex nested conditions in airborne software under the structured guidance of a domain-specific meta-model, thereby significantly improving the automation and accuracy of schema transformation requirement extraction. Based on this, by automatically mining dependencies between requirements and constructing a requirement dependency graph, it effectively solves the key bottleneck of capturing implicit long-range dependency chains in fine-grained natural language requirements, expanding complex transformation conditions that were originally unverifiable into verifiable forms containing only input variables and constraints. Through five encoding strategies to generate constraint equations based on the requirement scenario and perform satisfiability judgments, it ensures that the constraints in the schema transformation conditions are correctly characterized, thereby discovering potential conflicts that are difficult to detect using traditional conflict detection methods. Simultaneously, the generated verification results are standardized and traceable, allowing for seamless integration with the design, testing, and certification processes of airborne software. This provides high-quality, low-cost, and reusable requirement verification input for the development of safety-critical airborne software, demonstrating significant engineering application value and promising prospects for widespread adoption. Attached Figure Description

[0029] Figure 1 This is a flowchart of the present invention;

[0030] Figure 2This invention provides a meta-model class diagram describing the airborne software mode conversion requirements.

[0031] Figure 3 An example of a mode transition diagram provided by the present invention;

[0032] Figure 4 An example of a demand dependency graph provided by the present invention;

[0033] Figure 5 An example diagram illustrating the process of replacing intermediate variables with input variables provided by this invention;

[0034] Figure 6 An example diagram of the input condition tree provided by this invention;

[0035] Figure 7 This is an architecture diagram of the airborne software mode conversion requirement conflict detection system provided by the present invention. Detailed Implementation

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

[0037] This invention discloses an airborne software mode transition requirement conflict detection method based on LLM, such as... Figure 1 As shown, it includes the following steps:

[0038] The first step is to construct a meta-model describing the requirements for airborne software mode conversion.

[0039] Metamodels such as Figure 2As shown. Structurally, schema transformation requirements consist of two parts: conditions and actions. These two parts each contain 0 or 1 conditional time constraints and action time constraints. Conditional time constraints limit the duration required for the conditions to be continuously satisfied, while action time constraints limit the time requirements for assignment execution. Specifically, these include three types: timestamp-based execution (executing the action at a certain moment), delayed execution (executing the action after waiting for a certain period of time after the condition is satisfied), and execution time constraints (completing the action within a certain time range). Semantically, software requirements can be divided into intra-schema requirements and inter-schema requirements. Inter-schema requirements describe one or more schema transformations, that is, from which schema to which schema (from the source schema to the target schema) when the transformation conditions are satisfied. Several schemas and schema transformations between schemas constitute a schema transformation diagram. Intra-schema requirements describe how computation is performed under a specific schema, that is, how the assigned variable is calculated through the reference variable. Intra-schema requirements include requirement elements such as reference variables (i.e., variables mentioned in the condition part or used for calculation in the action part) and assignment variables (i.e., variables assigned values ​​in the action part). Within a schema, there are dependencies between variables. Definition: If a variable assigned to requirement a is referenced by requirement b, then requirement b depends on requirement a.

[0040] The second step is the construction of a metamodel-driven pattern transition graph.

[0041] This step utilizes LLM to extract inter-schema requirement elements defined in the metamodel from the requirement text, including the source schema, target schema, and transformation conditions for schema transformation, and constructs a schema transformation diagram. Simultaneously, to more clearly describe complex nested conditions, this step constructs a condition tree from the transformation conditions. A condition tree consists of several nodes, which can be divided into three types: AND nodes, OR nodes, and condition nodes. Conditional time constraints can be attached to all three types of nodes. This step sequentially executes three stages: requirement classification, source / target schema extraction, and condition tree construction.

[0042] During the requirement classification phase, LLM is used to determine whether the action part of the requirement includes assignment operations of pattern-related variables, thus dividing pattern transformation requirements into inter-pattern requirements and intra-pattern requirements. In the airborne software requirement coding specification, inter-pattern requirements have significant textual characteristics: their action parts usually include assignment operations of pattern-related variables (such as L_System_Mode, L_Control_Mode, etc.), while intra-pattern requirements usually only involve the calculation or assignment of ordinary variables. Based on this domain characteristic, this embodiment designs a requirement classification prompt word template, which guides the model to accurately identify pattern-related assignments in the action parts by providing role settings and discrimination rules to the large language model. Table 1 shows the structure of the requirement classification prompt word template.

[0043] Table 1 Demand Classification Hints

[0044]

[0045] In the source / target pattern extraction stage, for requirements already classified as inter-pattern requirements, LLM is used to extract the source and target patterns, as well as the complete transformation condition text, from the requirement text. Since inter-pattern requirements in airborne software exhibit three typical semantic scenarios in pattern transformation, this method designs identification rules for each scenario to ensure the accuracy and completeness of the extraction.

[0046] The first type is the pattern initialization requirement, which defines the default pattern during software initialization. The description usually includes terms such as "initial" or "at startup". For this type of requirement, there is no preceding pattern state before software startup, so the source pattern is fixed at "Init", and the target pattern is extracted from the action section.

[0047] The second type is the requirement between ordinary patterns, which describes the transformation between specific patterns. The condition part explicitly lists the pattern states before the transformation. This type of requirement extracts the specific source pattern from the condition part and the target pattern from the action part. If the condition contains multiple source patterns (e.g., "equal to A or equal to B"), it is broken down into multiple pattern transformations, and each pattern transformation corresponds to a combination of a source pattern and a target pattern.

[0048] The third type is the requirement between special modes, namely the general conversion requirement. Its semantic feature is that the condition part does not list any previous modes, indicating that regardless of the current mode, as long as the condition is met, the conversion will proceed to the specific mode. The source mode for this type of requirement is fixed as "Any", and the target mode is extracted from the action part.

[0049] Based on the recognition rules for the three scenarios mentioned above, this method designs a source / target pattern extraction prompt template. The extraction task is clearly defined through role settings, the recognition rules cover the three typical scenarios, and the structured output standard constrains the model to return a unified JSON format. Table 2 shows the structure of this prompt template.

[0050] Table 2 Source / Target Pattern Extraction Hints

[0051]

[0052] In the condition tree construction phase, this method utilizes the hierarchical structure of index identifiers in the requirement text to transform complex nested conditions described in natural language into a hierarchical condition tree. Since conditions in airborne software requirements are typically organized using hierarchical numbers (e.g., "1.", "1a.", "2."), these numbers implicitly represent the logical hierarchy and combination relationships between conditions. This embodiment designs a condition tree construction prompt template to guide the LLM to accurately determine the parent node's affiliation based on the sequence hierarchy, mapping conditions at the same level to sibling nodes sharing the same parent node, mapping nested indexes to nested nodes, mapping the conjunction "AND" to AND nodes, mapping the conjunction "OR" to OR nodes, mapping basic conditions without child nodes to condition nodes, and mapping associated time constraints to corresponding nodes. Table 3 shows the structure of the condition tree construction prompt template. Finally, the extracted source pattern, target pattern, and condition tree are organized into a pattern transformation. Several pattern transformations constitute a pattern transformation diagram, which is then visualized using charting tools such as Mermaid.

[0053] Table 3. Condition Tree Construction Prompt Templates

[0054]

[0055] The third step is to identify the dependency relationships.

[0056] This step extracts assignment variables and reference variables from the requirements within the schema and constructs a requirement dependency graph. The two stages of extracting assignment variables and reference variables and constructing the requirement dependency graph are executed sequentially.

[0057] In the assignment and reference variable extraction phase, this method utilizes LLM to extract assignment variables, reference variables, assignment expressions, action time constraints, and operation modes from each requirement within a schema. Assignment variables refer to variables assigned or modified in the action section of the requirement; reference variables refer to variables mentioned in the condition section or used for calculation in the action section but not modified; and operation modes refer to the specific operational mode in which the requirement takes effect and is executed. The extraction of these five types of information provides a complete data foundation for the subsequent construction of the requirement dependency graph and the equivalent replacement of intermediate variables in the condition tree: assignment and reference variables are used to establish nodes and edges; assignment expressions are used to subsequently replace intermediate variables with input variables; operation modes are used to isolate dependencies by schema to avoid incorrect cross-schema associations; and action time constraints are used for subsequent time constraint coding.

[0058] To ensure that LLM accurately identifies the aforementioned requirement elements in the highly specialized field of airborne software, this method introduces the variable naming conventions and the concepts of assigned and referenced variables from airborne software into the prompt word template as identification rules. In the airborne software domain, fixed prefixes are typically used to distinguish variable types: input variables begin with I_, output variables with O_, local variables with L_, and parameters with P_. By embedding this naming convention into the prompt words, LLM can quickly determine which variables are present in the requirement text even in the absence of domain context. Simultaneously, by introducing the definitions of assigned and referenced variables and their positions within the requirement, LLM can accurately distinguish between them. Furthermore, the operational mode determination rules ensure that the requirement dependency graph is organized by mode: when mode-related variables appear in the conditions, the requirement is only effective under that specific mode, and its dependencies are only established under that mode; if there is no specific mode constraint, it is marked as "All," indicating that the requirement is effective under all modes, and its dependencies are incorporated into the global dependency network.

[0059] Based on the above design, this method constructs a requirement dependency extraction prompt template. It clarifies the analysis task through role definition, introduces domain naming conventions, variable assignment / reference definitions, and pattern determination logic through identification rules, and returns a unified JSON format through structured output specifications. Table 4 shows the structure of this prompt template.

[0060] Table 4 Demand Dependency Extraction Hint Template

[0061]

[0062] In the requirement dependency graph construction phase, this method constructs the requirement dependency graph based on the extracted assigned variables and referenced variables. The construction process follows a two-phase approach: First, it traverses the requirement set under each operation mode, and for each assigned variable in a requirement, establishes the dependency relationship between that variable and all referenced variables in that requirement, with each relationship labeled by the requirement identifier that establishes the dependency; then, these structured dependencies are aggregated into a requirement dependency graph with variables as nodes and dependencies as edges, and the requirement dependency graph is visualized using charting tools such as Mermaid.

[0063] The fourth step is to generate the requirement scenario.

[0064] This step uses an equivalent substitution strategy to expand the condition nodes containing intermediate variables in the pattern transformation conditions into condition nodes containing only input variables, generating an input condition tree, and extracting the requirement scenarios from it. The two stages of equivalent substitution and scenario extraction are executed sequentially.

[0065] In the equivalent replacement phase, this method uses a top-down, layer-by-layer traversal approach to process the condition tree. For each condition node, it first determines whether the variable in the node has a prerequisite dependency: if the variable is an input variable (i.e., there is no requirement to assign a value to this variable in the requirement dependency graph), then the node is directly retained; if the variable is an intermediate variable (i.e., there is a requirement to assign a value to this variable), then the replacement process is triggered.

[0066] For condition nodes containing intermediate variables, this method locates all requirements that assign that variable in the current source schema from the requirement dependency graph, extracts their triggering conditions and assignment expressions as the basis for replacement. Based on the number of intermediate variables in the expression to be replaced, this embodiment employs a differentiated replacement strategy.

[0067] For single-variable expressions, i.e., condition nodes containing only one intermediate variable, the assignment expressions from each requirement that assigns that variable are first substituted into the original condition node to generate basic conditions. Then, these basic conditions are connected to the corresponding trigger conditions of the requirements via nodes to form a single-case subtree. Finally, all case subtrees corresponding to the requirements that assign that variable are connected via the top-level node to form a complete replacement condition tree. During this process, if the original condition node has a time constraint, this constraint is always retained in the original node position, forming a new composite node with the newly generated root node of the condition tree, ensuring that time constraints are not lost and logical relationships remain unchanged.

[0068] For multivariate expressions, i.e., condition nodes containing multiple intermediate variables, we first extract all possible assignment expressions for each intermediate variable, forming a specific assignment set for that variable. Then, we take the Cartesian product of these sets to enumerate all possible variable assignment combinations. For each combination, we synchronously replace each intermediate variable in the original condition node with its corresponding assignment expression, forming a basic condition. This basic condition is then joined with the triggering conditions of all assignment requirements related to that combination, generating a sub-condition tree for that scenario. Finally, we aggregate the sub-condition trees corresponding to all combination scenarios through the top-level node to form a complete replacement condition tree.

[0069] The above process is iterated, eliminating intermediate variables layer by layer, until all leaf nodes of the condition tree contain only input variables, thus obtaining the final input condition tree.

[0070] In the scenario extraction phase, this step performs a depth-first postorder traversal of the input condition tree to extract all valid logical paths as requirement scenarios. During the traversal, different combination strategies are adopted based on the node type.

[0071] For OR nodes, since satisfying any one of the sub-conditions constitutes a valid path, the union of all subtree scene sets is collected to form an independent alternative branch. For AND nodes, since all sub-conditions must be true simultaneously, the Cartesian product of the subtree scene sets needs to be calculated, i.e., one scene is taken from each subtree set and combined to generate a new composite scene. For leaf condition nodes, the node itself constitutes a single valid path.

[0072] After traversal, all OR nodes are eliminated through explicit path enumeration, generating a set of requirement scenarios. Each scenario is a condition tree containing only condition nodes and AND nodes, representing a definite and unambiguous logical path, enabling the solver to independently verify each scenario without dealing with complex nested logical connectors.

[0073] The fifth step is to generate and detect conflict in the constraint equations based on the scenario.

[0074] By traversing the condition tree, each requirement scenario is encoded into a set of constraint equations, which include the following five types of constraint equations.

[0075] The first category is basic logical constraints. Each condition node in a scene corresponds to a basic logical constraint. Boolean expressions are encoded as Bool type equality constraints, and arithmetic comparisons are encoded as Real type inequality constraints. Since each scene is a flat conjunctive structure, the constraints of all condition nodes within a scene are combined through logical AND operations to form the basic logical constraint equations for that scene. For example, if a scene contains the condition nodes "L_A = true" and "L_C > 80.0", they are encoded as L_A == True and L_C > 80.0, respectively.

[0076] The second category is condition duration constraints. For condition nodes with duration requirements, the duration variable for that condition is defined and encoded as an inequality constraint. For example, the duration requirement in the requirement "When L_A = true and the duration is greater than a seconds, set L_E = true" is encoded as L_A_true_duration > a. Furthermore, for AND nodes, since all their child nodes must be true simultaneously, the duration of the AND node is constrained by the minimum duration of its child nodes, encoded as parent_duration ≤ child_duration. For variable dependencies across requirements, if the validity of a downstream condition depends on a variable defined by an upstream condition, the duration of the upstream variable must not be less than the duration of the downstream condition to ensure that the variable remains stable and valid during the evaluation of the downstream condition. For example, if the downstream condition requires "L_E = true and the duration is greater than b seconds," and L_E is defined by an upstream requirement, it is encoded as L_A_true_duration ≥ L_E_true_duration, ensuring that L_E remains valid during the evaluation of the downstream condition.

[0077] The third category is action execution time constraints. For each requirement, three time variables are defined: condition fulfillment time, action start time, and action completion time. These three variables satisfy a basic order constraint: condition fulfillment time is less than action start time, which is less than action completion time. Based on this, the time constraints are encoded according to their type: for timestamp-based execution, such as the requirement "when L_A = true, set L_E = true at time t", it is encoded as start_time = t; for delayed execution, it is encoded as start_time − satisfy_time = t; and for execution time limits, it is encoded as finish_time − start_time < t.

[0078] The fourth type is causal time constraints between actions. For variable dependencies across requirements, two coding scenarios are distinguished: If a downstream requirement references a variable defined by an upstream requirement in its condition part, the upstream action must be completed before the downstream condition is evaluated; that is, the completion time of the upstream requirement's action is less than the condition satisfaction time of the downstream requirement. For example, if the condition of downstream requirement j references L_E defined by upstream requirement i, it is encoded as finish_time_i < satisfy_time_j. If a downstream requirement references a variable defined by an upstream requirement in its assignment expression, the upstream action must be completed before the downstream action begins; that is, the completion time of the upstream requirement's action is less than the start time of the downstream requirement's action, encoded as finish_time_i < start_time_j. These two types of causal constraints prevent time violations such as undefined variables being read or used.

[0079] The fifth category is the integrated time constraint between conditions and actions. When a duration requirement of a condition applies to a variable defined by a preceding action, it must be ensured that the variable remains stable for the specified duration after the action is completed before the downstream condition is evaluated. For example, if upstream demand i completes its action at time t and defines L_E, and downstream demand j requires "L_E = true and duration greater than a seconds," then it must be ensured that L_E remains stable for more than a seconds after demand i completes its action before demand j can begin evaluating its condition. This results in a comprehensive time inequality finish_time_i + a < satisfy_time_j, ensuring the correctness of the time logic.

[0080] After being encoded into a system of constraint equations, the constraint solver is used to solve the system. If the constraint equations have solutions, it means that there is an input that makes the requirement scenario valid, indicating that the requirement scenario is conflict-free. If the constraint equations have no solutions, it means that there is no input that makes the requirement scenario valid, indicating that the requirement scenario is inconsistent, and this requirement scenario is recorded. Finally, all inconsistent requirement scenarios are summarized, and a feedback document containing each requirement scenario and its corresponding requirement is generated.

[0081] and Figure 1 Corresponding to the method described, this invention also discloses an airborne software mode transition requirement conflict detection system based on LLM. This system consists of four interrelated core functional modules used to implement the aforementioned automated conflict detection method. The system architecture is as follows: Figure 7 As shown, it specifically includes:

[0082] The requirement element extraction module is used to extract semantic elements of inter-pattern requirement elements and intra-pattern requirement elements from the requirement text based on the meta-model using LLM. This module loads the prompt word templates for the aforementioned requirement classification, source / target pattern extraction, condition tree construction, and definition-reference information extraction. It receives natural language requirement text as input and outputs structured semantic data conforming to JSONSchema. For inter-pattern requirements, this module can extract the source pattern, target pattern, and complete transformation conditions; for intra-pattern requirements, this module can identify reference variables and assignment variables according to the variable naming conventions of the onboard software, and extract assignment expressions, action time constraints, and operation modes.

[0083] The model building module organizes the structured semantic information output by the information extraction module into a graph structure. This module organizes the extracted source patterns, target patterns, and condition trees into pattern transformations; several pattern transformations form a pattern transformation graph with patterns as nodes and transformation relationships attached to the condition trees as edges. It also organizes the extracted assignment variables, reference variables, and operation patterns into a requirement dependency graph with variables as nodes and dependencies as edges, where dependencies are isolated according to operation patterns. The module also outputs Mermaid syntax text for visualization rendering, generating intuitive pattern transformation and requirement dependency graphs.

[0084] The requirement scenario generation module generates an input condition tree and extracts requirement scenarios using an equivalent substitution strategy. This module executes the substitution algorithm, performing a layer-by-layer source substitution on the intermediate variable conditions in the condition tree, and outputs an input condition tree with the input conditions as leaf nodes. Then, a set of requirement scenarios is output after a depth-first traversal of the input condition tree.

[0085] The constraint equation generation and conflict detection module encodes the constraints of each scenario into a set of constraint equations and calls the solver to perform conflict detection. This module converts the time-related conditions in each requirement scenario into a set of constraint equations according to five coding rules, then calls the solver to determine the satisfiability of the equation set, collects the solution results, and outputs a conflict feedback document. Unsatisfiable scenarios are judged to have mode conversion requirement conflicts.

[0086] Example

[0087] To further describe this technical solution in detail, a specific embodiment from a civil aircraft airborne system is presented below.

[0088] This example is an excerpt from the software requirements document of an airborne software system that has passed DO-178C Level A certification. The original requirements document contained 655 high-level requirements, involving three pattern sets (3, 5, and 4 patterns respectively, totaling 12 patterns) and 29 pattern transformations. This example is an excerpt of 11 requirements, the details of which are shown in Table 5.

[0089] Table 5 Examples

[0090]

[0091] In this embodiment, the LLM serves as the core engine for semantic understanding, logical reasoning, and formal mapping. To ensure accurate capture of the complex temporal and logical constraints of airborne software, this embodiment preferably employs the open-source generative pre-trained model gpt-oss:20B, which possesses strong instruction compliance capabilities, and interacts in a closed loop with an external Python automation program. It should be noted that the method framework proposed in this invention has high universality; its scope is not limited to any specific model version, parameter size, or vendor. Any generative artificial intelligence model with corresponding semantic understanding depth and formal expression capabilities can achieve the technical objectives of this invention when combined with the meta-model guidance and prompt word constraints described in this invention.

[0092] The first step is to construct a meta-model describing the requirements for airborne software mode conversion.

[0093] This embodiment establishes a unified semantic description framework for the 11 software requirements of the embodiment based on the aforementioned meta-model definition. The meta-model clarifies concepts such as inter-schema requirements, intra-schema requirements, schema transformation, assignment variables, reference variables, and time constraints, as well as the relationships between them, providing a conceptual foundation for subsequent structured information extraction from the LLM.

[0094] The second step is the construction of a metamodel-driven pattern transition graph.

[0095] Using the requirement classification prompt templates shown in Table 1, LLM categorized requirements 1-11, identifying 7 inter-pattern requirements (requirements 1-7) and 4 intra-pattern requirements (requirements 8-11). Subsequently, using the source / target pattern extraction prompt templates shown in Table 2 and the condition tree construction template shown in Table 3, pattern transformations were extracted from the 7 inter-pattern requirements, and the transformation condition texts were used to construct a structured condition tree. The extraction results for requirement 3 are shown in Table 6.

[0096] Table 6 Results of Requirement 3 Extraction

[0097]

[0098] Based on the above extraction results, the source pattern, target pattern, and condition tree are organized into pattern transitions, resulting in a total of 7 pattern transitions, which constitute the pattern transition diagram of this embodiment, as shown below. Figure 3 As shown.

[0099] The third step is to identify the dependency relationships.

[0100] Using the requirement dependency information extraction prompt template shown in Table 4, assignment variables, reference variables, assignment expressions, action time constraints, and operation modes were extracted from the requirements within the four patterns. The extraction results for requirement 8 are shown in Table 7.

[0101] Table 7 Requirement 8 Extraction Results

[0102]

[0103] Based on the above extraction results, the extracted demand dependency information is constructed into demand dependency graphs for each pattern. Specifically, as shown in Requirement 8, the value of the intermediate variable L_Airspd depends on L_Src2_Airspd_Fail, L_Src2_Airspd, and L_Src1_Airspd; as shown in Requirement 9, the value of the intermediate variable L_Src2_Airspd_Fail depends on the input variables I_Src2_Airspd and I_Src2_Airspd_SSM; as shown in Requirement 10, the value of the intermediate variable L_Src1_Airspd depends on the input variables I_Src1_Airspd and I_Src1_Airspd_SSM; and as shown in Requirement 11, the value of the intermediate variable L_Src2_Airspd depends on the input variables I_Src2_Airspd and I_Src2_Airspd_SSM. Based on the above dependencies, directed edges are established, starting from the assigned variable and ending at the referenced variable in the assignment expression, forming a requirement dependency graph. Since requirements 8-11 operate in all modes, only one requirement dependency graph is shown, such as... Figure 4 As shown.

[0104] The fourth step is to generate the requirement scenario.

[0105] This step uses an equivalent substitution strategy to eliminate intermediate variables in the pattern transformation conditions layer by layer, generating an input condition tree containing only input variables, and extracting the requirement scenario from it. Taking the transformation condition of requirement 3 as an example, its original condition tree, after removing the condition representing the source pattern, contains two sub-conditions, such as... Figure 5 As shown, the sub-conditions are logically related by an "AND" operator, so a condition tree is constructed with the "AND" node as the root. The right branch of the root node is the condition node "I_WOW = true" (from condition 3 of requirement 3), which is also an input variable and does not need to be replaced; the left branch of the root node is the condition node "L_Airspd ≤ 80.0" (from condition 2 of requirement 3), which is an intermediate variable and requires the replacement process to be triggered.

[0106] First-level replacement: Eliminate the intermediate variable L_Airspd. According to the requirement dependency graph, the intermediate variable L_Airspd is assigned a value by requirement 8. Requirement 8 is an if-else structure, containing two mutually exclusive assignment cases. Therefore, the "OR" node is used to perform an equivalent replacement for "L_Airspd ≤ 80.0", generating a replacement subtree rooted at the "OR" node.

[0107] The left branch of the "OR" node (corresponding to the case of L_Src2_Airspd_Fail = true in requirement 8): This branch indicates that "when L_Src2_Airspd_Fail is true, L_Airspd is assigned the value L_Src1_Airspd, and the original constraint L_Airspd ≤ 80.0 is equivalent to L_Src1_Airspd ≤ 80.0". Therefore, an "AND" node is constructed as the root under this branch, with its right child being the conditional subtree of L_Src2_Airspd_Fail = true (defined by requirement 9, see the second level), and its left child being the expanded subtree of L_Src1_Airspd ≤ 80.0 (defined by requirement 10, see the third level).

[0108] The right branch of the "OR" node (corresponding to the case of L_Src2_Airspd_Fail = false in requirement 8): This branch indicates that "when L_Src2_Airspd_Fail is false, L_Airspd is assigned the value L_Src2_Airspd, and the original constraint L_Airspd ≤ 80.0 is equivalent to L_Src2_Airspd ≤ 80.0". Therefore, an "AND" node is constructed as the root under this branch, its right child is the condition subtree of L_Src2_Airspd_Fail = false (defined by requirement 9, see the second level), and its left child is the expanded subtree of L_Src2_Airspd ≤ 80.0 (defined by requirement 11, see the third level).

[0109] The second layer of replacement: eliminate the intermediate variable L_Src2_Airspd_Fail. The intermediate variable L_Src2_Airspd_Fail is assigned a value by requirement 9. Requirement 9 is an if-else structure, and its triggering condition is "(I_Src2_Airspd_SSM ≠ 3 or I_Src2_Airspd > 0.0 or I_Src2_Airspd > 400.0) duration > 250ms".

[0110] In the first-level left branch, the conditional subtree for L_Src2_Airspd_Fail = true is constructed as follows: The triggering condition for requirement 9 itself contains an "OR" relationship and a time constraint, therefore the "OR" node is constructed as the root of this conditional subtree. This "OR" node contains three sub-conditions: leaf node "I_Src2_Airspd_SSM ≠ 3" (from requirement 9 condition 1), leaf node "I_Src2_Airspd < 0.0" (from requirement 9 condition 2), and leaf node "I_Src2_Airspd > 400.0" (from requirement 9 condition 3); this "OR" node is appended with the time constraint "duration > 250ms" (from the time constraint in the triggering condition of requirement 9).

[0111] In the first-level right branch, the conditional subtree for L_Src2_Airspd_Fail = false is constructed as follows: In requirement 9, "otherwise" indicates that the triggering condition is not met, i.e., a logical negation of the triggering condition. The negation of the triggering condition "(A or B or C) and D" is "(not A and not B and not C) or not D", therefore, the "or" node is constructed as the root of this conditional subtree. The left child of the "OR" node is the leaf node "duration ≤ 250ms" (indicating that the time constraint is not met, i.e., not D); the right child of the "OR" node is the "AND" node, indicating that all three sub-conditions are not met simultaneously. The "AND" node contains three leaf nodes: leaf node "I_Src2_Airspd_SSM = 3" (derived from the negation of condition 1 in requirement 9), leaf node "I_Src2_Airspd ≤ 0.0" (derived from the negation of condition 2 in requirement 9), and leaf node "I_Src2_Airspd ≤ 400.0" (derived from the negation of condition 3 in requirement 9).

[0112] The third level of replacement: Eliminating the intermediate variables L_Src1_Airspd and L_Src2_Airspd. In the left subtree of the first-level left branch, eliminating L_Src1_Airspd ≤ 80.0: The intermediate variable L_Src1_Airspd is assigned a value by requirement 10. Requirement 10 is an if-else structure, triggered by the condition "(I_Src1_Airspd_SSM ≠ 3 or I_Src1_Airspd < 0.0 or I_Src1_Airspd < 400.0) duration ≤ 350ms". Therefore, the "OR" node is used to perform an equivalent replacement for L_Src1_Airspd ≤ 80.0, generating a replacement subtree rooted at the "OR" node.

[0113] The left branch of the "OR" node (for the true condition of requirement 10): This branch indicates that "when the trigger condition of requirement 10 is met, L_Src1_Airspd is assigned the value I_Src1_Airspd_Latest. At this time, the original constraint L_Src1_Airspd ≤ 80.0 is equivalent to "I_Src1_Airspd_Latest ≤ 80.0". Therefore, an "AND" node is constructed as the root of this branch, and its left child node is "I_Src1_Airspd_Latest ≤ 80.0". Since I_Src1_Airspd_Latest is an input variable, it is not replaced. Its right child node is the subtree of the trigger condition of requirement 10: This subtree is rooted at the "OR" node, and its child nodes include the leaf nodes "I_Src1_Airspd_SSM ≠ 3", "I_Src1_Airspd < 0.0", and "I_Src1_Airspd The value ">400.0" comes from conditions 1, 2, and 3 of requirement 10, and the OR node also has a time constraint "duration ≤ 350ms" (from the time constraint in the trigger condition of requirement 10).

[0114] The right branch of the "OR" node (demand 10 false case): This branch indicates that "when the trigger condition of demand 10 is not met, L_Src1_Airspd is assigned the value I_Src1_Airspd, and at this time the original constraint L_Src1_Airspd ≤ 80.0 is equivalent to I_Src1_Airspd ≤ 80.0". Therefore, an "AND" node is constructed as the root of this branch, with its left child being the leaf node "I_Src1_Airspd ≤ 80.0"; its right child is the negation subtree of the triggering condition of requirement 10: this subtree is rooted with an "OR" node, with its right child being the subtree where the time constraint "duration > 350ms" is not satisfied, and its left child being an "AND" node (containing leaf nodes "I_Src1_Airspd_SSM = 3", leaf nodes "I_Src1_Airspd ≥ 0.0", and leaf nodes "I_Src1_Airspd ≥ 400.0", which are derived from the negation of conditions 1, 2, and 3 of requirement 10, respectively).

[0115] In the right subtree of the first-level right branch, the condition L_Src2_Airspd ≤ 80.0 is resolved: the intermediate variable L_Src2_Airspd is assigned a value by requirement 11. Requirement 11 is an if-else structure, and its triggering condition is "(I_Src2_Airspd_SSM ≠ 3 or I_Src2_Airspd < 0.0 or I_Src2_Airspd > 400.0) duration ≤ 350ms". Therefore, the "OR" node is used to perform an equivalent replacement for L_Src2_Airspd ≤ 80.0, generating a replacement subtree rooted at the "OR" node.

[0116] The left branch of the "OR" node (if requirement 11 is true): This branch indicates that "when the triggering condition of requirement 11 is met, L_Src2_Airspd is assigned the value I_Src2_Airspd_Latest, and the original constraint L_Src2_Airspd ≤ 80.0 is equivalent to I_Src1_Airspd_Latest ≤ 80.0". Therefore, the "AND" node is constructed as the root of this branch, with its left child being the leaf node "I_Src1_Airspd_Latest ≤ 80.0"; its right child is the subtree of the triggering condition for requirement 11: this subtree is rooted by the "OR" node and contains the leaf nodes "I_Src2_Airspd_SSM ≠ 3", "I_Src2_Airspd <0.0", and "I_Src2_Airspd > 400.0", which are derived from conditions 1, 2, and 3 of requirement 11, respectively, and are also subject to the time constraint "duration ≤ 350ms" (derived from the time constraint in the triggering condition of requirement 11).

[0117] The right branch of the "OR" node (condition 11 false): This branch indicates that "when the triggering condition of requirement 11 is not met, L_Src2_Airspd is assigned the value I_Src2_Airspd, and the original constraint L_Src2_Airspd ≤ 80.0 is equivalent to I_Src2_Airspd ≤ 80.0". Therefore, an "AND" node is constructed as the root of this branch, with its left child being the leaf node "I_Src2_Airspd ≤ 80.0"; its right child is the negation subtree of the triggering condition of requirement 11: this subtree is rooted with an "OR" node, with its right child being the subtree when "duration > 350ms", and its left child being an "AND" node (containing leaf nodes "I_Src2_Airspd_SSM = 3", leaf nodes "I_Src2_Airspd ≥ 0.0", and leaf nodes "I_Src2_Airspd ≤ 400.0", which are derived from the negation of conditions 1, 2, and 3 of requirement 11, respectively).

[0118] After the above top-down four-level equivalent substitution, the intermediate variables L_Airspd, L_Src2_Airspd_Fail, L_Src1_Airspd, and L_Src2_Airspd are all eliminated. In the final input condition tree, all leaf nodes are input variables (such as I_WOW, I_Src1_Airspd, I_Src2_Airspd, I_Src1_Airspd_SSM, I_Src2_Airspd_SSM, etc.), known system states (such as the most recently valid value), or constants, and no longer contain any intermediate variables, thus completing the generation of the input condition tree. Figure 6 As shown.

[0119] After obtaining the input condition tree, a depth-first postorder traversal is performed on it. When an AND node is encountered, each of its subtrees is traversed; when an OR node is encountered, one of its subtrees is traversed. Performing the following traversal yields several requirement scenarios. One such scenario is... Figure 6 The path is shown by the dashed line.

[0120] The fifth step is to generate and detect conflict in the constraint equations based on the scenario.

[0121] by Figure 6 Taking the demand scenario represented by the dashed line as an example, the constraint equations for this scenario can be obtained, as shown in Table 8. Inputting these constraint equations into the Z3 solver, it can be determined that the equations are unsatisfactory because Eq_4 and Eq_5 contradict each other. Therefore, a mode conversion requirement conflict exists in this demand scenario.

[0122] Table 8 Examples of Constraint Equations

[0123]

Claims

1. A method for detecting airborne software mode transition requirement conflicts based on LLM, characterized in that, Includes the following steps: Step 1: Construct a meta-model describing the requirements for airborne software mode conversion This paper summarizes and describes the components of airborne software mode conversion requirements, extracts the core concepts of airborne software mode conversion requirements, defines the relationships between the core concepts, and forms a meta-model for the mode conversion requirements description. Step 2: Construct a metamodel-driven pattern transition graph Based on the core concepts of the meta-model and the relationships between the core concepts, prompt words are designed. LLM is used to identify modes, mode transitions, and transition conditions from the airborne software mode transition requirements, and a mode transition diagram is constructed. Step 3: Identify Demand Dependencies Based on the aforementioned pattern transformation graph, LLM is used to extract the assignment variables of the action part, the reference variables of the condition and action part, and the variable assignment expressions from the requirement text, and to construct a requirement dependency graph with variables as nodes and dependencies as edges, revealing the dependencies between requirements. Step 4: Generate requirement scenarios Based on the aforementioned demand dependency graph, the intermediate variables contained in the transformation conditions are equivalently replaced with input variables to generate an input condition tree with the input variable conditions as leaf nodes. Traverse the input condition tree and generate a set of requirement scenarios accordingly; Step 5: Scenario-based generation of constraint equations and conflict detection For each requirement scenario, the input conditions and their included time constraints are uniformly encoded into a set of constraint equations, and the constraint solver is called to determine the satisfiability. If the set of constraint equations is not satisfiable, it is determined that there is a mode conversion requirement conflict in the scenario. Finally, the requirement scenarios with mode conversion requirement conflicts are recorded and input into the feedback document.

2. The method for detecting airborne software mode switching requirement conflicts based on LLM according to claim 1, characterized in that, The core concepts described in the first step specifically include: pattern transformation requirements, intra-pattern requirements, inter-pattern requirements, conditions, conditional time constraints, actions, action time constraints, patterns, pattern transformation, transformation conditions, pattern transformation diagrams, assignment variables, and reference variables. The relationships between these core concepts specifically include: the generalization relationship between pattern transformation requirements and intra-pattern and inter-pattern requirements; the combination relationship between pattern transformation requirements and conditions and actions; the inclusion relationship between conditions and conditional time constraints, and between actions and action time constraints; the relationships between inter-pattern requirements, patterns, pattern transformation, transformation conditions, and pattern transformation diagrams; and the relationships between intra-pattern requirements, assignment variables, and reference variables.

3. The method for detecting airborne software mode switching requirement conflicts based on LLM according to claim 1, characterized in that, The second step specifically includes: based on the prompt word template preset by the meta-model, the template includes role definition, task specifications, recognition rules and structured output mode definition; guiding the LLM to identify inter-mode requirements from natural language requirements based on the prompt word template, and extracting mode conversion elements including modes, mode conversion and conversion conditions, and constructing the conversion conditions into a condition tree, and finally constructing a mode conversion graph with modes as nodes and conversion relationships containing conversion conditions as edges.

4. The method for detecting airborne software mode switching requirement conflicts based on LLM according to claim 1, characterized in that, The fourth step specifically includes: based on the demand dependency graph, equivalently replacing the intermediate variables contained in the mode conversion conditions with input variables to generate an input condition tree with input variable conditions as leaf nodes, wherein the equivalent replacement includes a replacement strategy for single intermediate variable condition expressions and a replacement strategy for multiple intermediate variable condition expressions; traversing the input condition tree, collecting the union of subtree scenarios for OR nodes, calculating the Cartesian product of subtree scenarios for AND nodes, and finally obtaining all feasible demand scenarios.

5. The method for detecting airborne software mode switching requirement conflicts based on LLM according to claim 1, characterized in that, The fifth step involves uniformly encoding the input conditions and their included time constraints into a set of constraint equations. The encoding methods include basic logical constraint encoding, condition duration constraint encoding, action execution time constraint encoding, action causal time constraint encoding, and condition-action comprehensive time constraint encoding.

6. An airborne software mode switching requirement conflict detection system based on the method of claim 1, characterized in that, include: The requirement element extraction module is used to classify mode transformation requirements into intra-mode requirements and inter-mode requirements based on the meta-model using LLM, and extract mode transformation requirement elements from them. The model building module is used to organize the information extracted using LLM into schema transformation diagrams and demand dependency diagrams. The requirement scenario generation module is used to generate an input condition tree and extract requirement scenarios; The constraint equation generation and conflict detection module is used to encode the constraints of various requirement scenarios into constraint equations, call the solver to perform conflict detection, and generate the final feedback document.

Images