Requirement System, Construction Method and Analysis Synchronization Method of Aircraft System Oriented to Axiomatic Design

Abstract

The invention relates to a requirement system, construction method and analysis synchronization method for an aircraft system oriented to axiomatic design, and relates to the technical field of system engineering. The invention solves the problem that the requirement model constructed based on natural language in the prior art has inaccuracies that affect the planning schedule and cost. The invention provides a method for constructing a requirement system, which obtains a glossary based on the terms and corresponding explanations of various fields and terms with mathematical relationships and corresponding mathematical explanations; obtains optional conditions based on universal requirements, event-driven requirements, state-driven requirements, undesirable requirements, optional feature requirements and conditional keywords; obtains a requirement main sentence based on the requirement subject, requirement modality, functional requirements or design constraints; obtains an optional requirement reason based on an obscure requirement reason; obtains a structured requirement template based on the optional conditions, requirement main sentence and requirement reason; and obtains a requirement system based on the glossary and the structured requirement template. The invention is applicable to the field of system engineering.

Description

Technical Field

[0001] The present invention relates to the technical field of system engineering. Background Art

[0002] Space vehicles are becoming increasingly integrated, with subsystems becoming more tightly coupled and their internal interactions becoming increasingly complex. Due to the multidisciplinary nature of space missions, space vehicle design requires greater collaboration between system designers and domain designers, resulting in highly complex requirements, design, and management, including requirements, data, and interfaces.

[0003] Model-Based Systems Engineering (MBSE) is being adopted by more aerospace organizations, including NASA, Boeing, and China's Fifth Academy of Aerospace. MBSE provides technologies to assist in the development of complex systems, using design models as the sole data source to reduce design errors, minimize late-stage errors and lower costs, and conduct early trade-off studies to improve system performance. Because spacecraft designs often fail to meet all requirements, requirements frequently change, often leading to system design errors.

[0004] Systems engineering typically begins with a requirements baseline, translating user requirements into system requirements. The requirements model primarily consists of a requirement name, ID, and text, based on natural language (NL). Natural language introduces imprecision. During the system design process, issues with upper-level requirements can propagate to lower levels, causing unnecessary volatility and risk, impacting schedules and costs. Due to the incompleteness of natural language, it cannot accurately express the definer's intent, resulting in ambiguity and misinterpretation. This incompleteness manifests itself primarily in two ways: incomplete linguistic notation and incomplete semantic reference. Conventional requirements sets are often based on natural language, which can lead to misunderstandings among different designers. While non-textual symbolization of requirements offers certainty, it requires translation of user requirements, a process often associated with error and negotiation.

[0005] In summary, the demand model constructed based on natural language has inaccuracies that will affect the planning schedule and cost. At the same time, the incompleteness of natural language will bring about information ambiguity and misunderstanding. Summary of the Invention

[0006] The present invention solves the problem in the prior art that demand models constructed based on natural language have inaccuracies that affect planning progress and costs.

[0007] To achieve the above object, the present invention provides the following solutions:

[0008] The present invention provides a method for constructing a demand system for an aircraft system based on the axiomatic design principle. The method comprises:

[0009] S1. Obtain a glossary based on the terms and corresponding explanations in various fields and the terms with mathematical relationships and their corresponding mathematical explanations;

[0010] S2. Define aircraft requirements according to the glossary to obtain a requirements template, wherein the requirements template includes at least: universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, non-obvious requirements reasons, conditional keywords, requirement subjects, requirement modalities, functional requirements, and design constraints;

[0011] S3. Obtain optional conditions based on the universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, and conditional keywords of each requirement;

[0012] S4. The main clause of the requirement is obtained in two ways:

[0013] Method 1: Obtain the main sentence of the requirement according to the requirement subject, requirement modality and functional requirement;

[0014] Method 2: Obtain the main sentence of the requirement according to the requirement subject, requirement modality and design constraints;

[0015] S5. Obtaining optional demand reasons based on the non-obvious demand reasons;

[0016] S6. Obtain a structured requirement template based on the optional conditions, the requirement main clause, and the requirement reason;

[0017] S7. Obtain a demand system according to the term list and the structured demand template.

[0018] Furthermore, in another preferred embodiment, the glossary in the above step S1 includes system knowledge terms and condition terms.

[0019] Furthermore, in another preferred embodiment, the universal demand in step S2 above has no preset conditions, indicating a demand that is always met;

[0020] The event-driven requirement refers to a requirement initiated by a triggering event. The sentence structure of the event-driven requirement is: WHEN+precondition+trigger;

[0021] The state-driven requirement refers to a requirement that is satisfied in a certain state. The sentence structure of the state-driven requirement is: WHILE+subject+under specific conditions;

[0022] The unexpected requirement refers to a requirement that expresses an unexpected situation, and the sentence structure of the unexpected requirement is: IF+precondition+trigger;

[0023] The optional feature requirement represents a requirement that needs to be met when certain optional features appear. The sentence structure of the optional feature requirement is: WHERE + include a feature.

[0024] Furthermore, in another preferred embodiment, the functional requirements in step S2 include SHALL, WILL and SHOULD;

[0025] The SHALL requirement means that it must be implemented and verified.

[0026] The requirement indicated by WILL does not require verification;

[0027] The requirement represented by SHOULD is a goal that must be solved.

[0028] Furthermore, in another preferred embodiment, the optional demand reason in the above step S5 has a sentence structure of: SOTHAT+demand reason.

[0029] The present invention provides an analysis and synchronization method for aircraft requirements of an axiomatically designed aircraft system. The analysis and synchronization method is implemented using a requirements system, which is obtained by using any of the above-mentioned requirements system construction methods for an axiomatically designed aircraft system. The analysis and synchronization method comprises:

[0030] A1. Obtaining a requirements table based on the functional requirements and design constraints during the aircraft axiomatic design process according to the term list and the structured requirements template;

[0031] A2. Calculate the requirement table based on the condition keywords of each requirement to obtain optional conditions, requirement main clauses, and optional requirement reasons;

[0032] A3. Analyze the main clause of the requirement using conditional terms to determine whether it has constraints, and obtain functional requirements and design constraints;

[0033] A4. Synchronize the requirement table with the functional requirements and the design constraints.

[0034] Furthermore, in another preferred embodiment, the synchronization method of the above requirement table and the functional requirement is:

[0035] B1. Analyze the functional requirements to obtain the requirement subject and requirement predicate;

[0036] B2. Obtain a module table according to the demand subject;

[0037] B3. Obtain a use case table based on the requirement predicate;

[0038] B4. Classify the requirement table to obtain a conceptual design stereotype, other custom stereotypes, and a design constraint stereotype;

[0039] B5. Synchronize the conceptual design stereotype to the use case table, and synchronize the other custom stereotypes to the module table;

[0040] The synchronization method of the requirement table and the design constraints is:

[0041] C1. Analyze the design constraints to obtain a design constraint table;

[0042] C2. Synchronize the design constraint stereotype to the design constraint table.

[0043] The present invention provides a requirements system for an aircraft system oriented to axiomatic design, the system comprising:

[0044] A storage device for obtaining a glossary based on terms and corresponding explanations in various fields and terms with mathematical relationships and corresponding mathematical explanations;

[0045] a storage device for analyzing aircraft requirements according to the term list to obtain a requirement term list, wherein the storage device of the requirement term list includes at least: universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, non-obvious requirement reasons, conditional keywords, requirement subjects, requirement modalities, functional requirements, and design constraints;

[0046] a storage device for obtaining optional conditions based on the universal requirements, event-driven requirements, state-driven requirements, undesirable requirements, optional feature requirements, and condition keywords of each requirement;

[0047] A storage device for obtaining a main sentence of a requirement according to the requirement subject, the requirement modality and the functional requirement;

[0048] A storage device for obtaining a main sentence of a requirement according to the requirement subject, the requirement modality and the design constraint;

[0049] a storage device for obtaining optional demand reasons based on non-obvious demand reasons;

[0050] A storage device for obtaining a structured requirement template according to the optional conditions, the requirement main clause and the requirement reason;

[0051] A storage device for obtaining a requirement system based on the term list and the structured requirements.

[0052] The present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program executes any one of the above-mentioned methods for constructing a requirement system for an axiomatically designed aircraft system or any one of the above-mentioned methods for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system.

[0053] The present invention provides a computer device, which includes a memory and a processor, wherein a computer program is stored in the memory. When the processor runs the computer program stored in the memory, the processor executes any one of the above-mentioned methods for constructing a requirement system for an axiomatically designed aircraft system or any one of the above-mentioned methods for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system.

[0054] The beneficial effects of the present invention are:

[0055] The present invention provides a method for constructing a demand system for an aircraft system oriented to axiomatic design, which solves the problem that the demand model constructed based on natural language in the prior art has inaccuracies that affect the planning schedule and cost.

[0056] At the same time, the following advantages are generated:

[0057] 1. The present invention provides a method for constructing a requirements system for an aircraft system based on axiomatic design, which uses a glossary to standardize the format of the requirements text, making the conditions, importance, type and reason of the requirements clearer and reducing ambiguity in requirements.

[0058] 2. The present invention provides a method for constructing a requirement system for an aircraft system oriented to axiomatic design, which uses structured requirements to clarify the conditions and reasons for the requirements and avoid misunderstandings of the requirements content.

[0059] 3. The present invention provides an analysis and synchronization method for aircraft requirements of an aircraft system oriented to axiomatic design, which analyzes and synchronizes the main clauses of the requirements in the requirements system, reduces the workload of each level of requirement modeling generated by the axiomatic design, and when there are changes in the requirements of the axiomatic design, synchronization is used to quickly determine the changes and additions and deletions in the requirements.

[0060] 4. The present invention provides an analysis and synchronization method for aircraft requirements of an axiomatically designed aircraft system, which performs automatic analysis on the main clauses of the requirements in the requirements system, increases the requirements allocation relationship, and ensures the traceability of the requirements and system model elements.

[0061] The present invention is applicable to the field of system engineering. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1is a flowchart of a method for constructing a requirements system for an aircraft system oriented to axiomatic design according to the first embodiment;

[0063] Figure 2 is a flow chart of the structured requirements described in Implementation Method 3;

[0064] Figure 3 This is a flowchart of importing an external demand form and performing analysis and synchronization as described in Implementation Method 6;

[0065] Figure 4 This is an enlarged view of the synchronization to use case table described in Implementation Method 6;

[0066] Figure 5 is an enlarged view of the synchronization to module table described in Implementation Method 6;

[0067] Figure 6 is an enlarged diagram of synchronization to the design constraint table described in the sixth embodiment;

[0068] Figure 7 This is a module diagram for performing requirement analysis and element synchronization in a modeling language SymL environment according to the sixth embodiment;

[0069] Figure 8 The original demand table described in Implementation Method 6;

[0070] Figure 9 The output requirement table described in the sixth embodiment;

[0071] Figure 10 This is the use case table described in Implementation Method 7;

[0072] Figure 11 The module table described in Embodiment 7;

[0073] Figure 12 It is a diagram of all elements after analyzing the original demand table described in the seventh implementation mode. DETAILED DESCRIPTION

[0074] Implementation method 1. See Figure 1 This embodiment describes a method for constructing a requirements system for an aircraft system oriented to axiomatic design. The method comprises:

[0075] S1. Obtain a glossary based on the terms and corresponding explanations in various fields and the terms with mathematical relationships and their corresponding mathematical explanations;

[0076] S2. Define aircraft requirements according to the glossary to obtain a requirements template, wherein the requirements template includes at least: universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, non-obvious requirements reasons, conditional keywords, requirement subjects, requirement modalities, functional requirements, and design constraints;

[0077] S3. Obtain optional conditions based on the universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, and conditional keywords of each requirement;

[0078] S4. The main clause of the requirement is obtained in two ways:

[0079] Method 1: Obtain the main sentence of the requirement according to the requirement subject, requirement modality and functional requirement;

[0080] Method 2: Obtain the main sentence of the requirement according to the requirement subject, requirement modality and design constraints;

[0081] S5. Obtaining optional demand reasons based on the non-obvious demand reasons;

[0082] S6. Obtaining a structured requirement based on the optional conditions, the requirement main clause, and the requirement reason;

[0083] S7. Obtain a requirement system based on the term list and the structured requirements.

[0084] In practical application, this implementation utilizes the systems modeling language SysML, integrating axiomatic design principles into the MBSE process to achieve model-based axiomatic design. This reduces system functional loops and increases the stability of aircraft system design. A requirements terminology list is generated based on domain terminology and corresponding interpretations, as well as terms with mathematical relationships and their corresponding mathematical interpretations. When applied, terminology related to aircraft-related fields is selected, such as those for overall aircraft design and subsystem design. For example, the term "inertia matrix" is ambiguous, referring to either the entire aircraft's moment of inertia matrix or the flywheel's moment of inertia matrix. This standardizes terminology across all designers to avoid communication ambiguity. Mathematical value comparison relationships, such as greater than, less than, and not exceeding, are defined as >, <, and ≤, respectively. These terms can be automatically converted into mathematical constraints by SysML modeling language tools. For example, if a requirement is defined as "mass not exceeding 1 ton," and a satisfying relationship is established with a parameter, the parameter can be automatically assigned the mathematical constraint "mass (numeric name, unit: 'ton') ≤ 1." This serves as a basis for the subsequent automated modeling of design constraints with comparative relationships. A requirements glossary is built into the MBSE modeling tool to support automated checking and synchronization with external terminology tables. The requirements glossary standardizes the format of requirement text, making the conditions, importance, type, and reasons for requirements clearer and reducing ambiguity. Structured requirements are derived based on optional conditions, requirement clauses, and requirement reasons. The requirement clauses represent the various conditions that must be met by the system's components. The sentence structure of the requirement clause is: requirement subject + requirement modality + functional requirements or design constraints. The requirement clause is derived based on the requirement subject, requirement modality, and functional requirements. The requirement clause is determined by the clause containing the requirement modality. A requirement clause must have a requirement modality, which determines its position. The clause preceding the requirement modality contains the requirement subject, followed by the functional requirements or design constraints, depending on whether there are defined "mathematical relationships" between the terminology keywords. The requirement subject is the subject of the requirement execution and can be a component of the system or a parameter of the system. In SysML modeling, it refers to a system module or attribute. The clear requirement format and requirement glossary minimize the inaccuracy of requirements, so that all parties can understand the requirements according to their meaning during requirement transmission. At the same time, they can quickly determine the elements used in system modeling and increase the accuracy of modeling.

[0085] The existing technology is a demand model constructed based on natural language. Natural language brings inaccuracy. During the system design process, problems in the upper-level requirements will be propagated to lower levels, which will cause unnecessary fluctuations and risks, affecting the plan schedule and cost. Due to the incompleteness of natural language, it cannot express the speaker's intentions with absolute accuracy, resulting in fuzziness and ambiguity of information. This embodiment provides a demand system construction method for an aircraft system based on the axiomatic design principle, which uses a demand terminology table to standardize the demand text format, making the conditions, importance, type and reasons of the requirements clearer and reducing demand ambiguity. At the same time, structured requirements are used to clarify the conditions and reasons for the requirements to avoid misunderstandings in the content of the requirements. This solves the problem that the demand model constructed based on natural language in the existing technology has inaccuracies that affect the plan schedule and cost.

[0086] Implementation method 2. This implementation method is to illustrate the glossary in step S1 of the method for constructing a requirement system of an aircraft system oriented to axiomatic design described in implementation method 1, and the glossary includes system knowledge terms and condition terms.

[0087] In practical applications, this implementation derives system knowledge terms from domain terminology and their corresponding interpretations, thereby avoiding miscommunication between system designers and domain professionals. Conditional terms are derived from mathematically related terms and their corresponding mathematical interpretations, such as the term "not greater than" and its corresponding interpretation "≤." Conditional terms are used in some supported MBSE tools to automatically verify requirements.

[0088] Implementation method three. See Figure 2 This embodiment is described by taking as examples the universal requirements, event-driven requirements, state-driven requirements, undesirable requirements, optional feature requirements, and conditional keywords in step S2 of the method for constructing a requirements system for an aircraft system oriented to axiomatic design described in embodiment 1.

[0089] The universal demand has no preconditions and represents a demand that is always satisfied;

[0090] The event-driven requirement refers to a requirement initiated by a triggering event. The sentence structure of the event-driven requirement is: WHEN+precondition+trigger;

[0091] The state-driven requirement refers to a requirement that is satisfied in a certain state. The sentence structure of the state-driven requirement is: WHILE+subject+under specific conditions;

[0092] The unexpected requirement refers to a requirement that expresses an unexpected situation, and the sentence structure of the unexpected requirement is: IF+precondition+trigger;

[0093] The optional feature requirement represents a requirement that needs to be met when certain optional features appear. The sentence structure of the optional feature requirement is: WHERE + include a feature.

[0094] In practical applications of this embodiment, universal requirements have no pre-set conditions and are used for requirements that are always met. Event-driven requirements begin with WHEN and are used for requirements initiated by a triggering event. The sentence structure is WHEN + precondition + trigger. This type of requirement is only met when the condition is triggered. State-driven requirements begin with WHILE and are used to express requirements that are met under a certain state. The basic sentence structure is WHILE + subject + under a specific condition. This type of requirement is only met when the subject of the condition is under the specific condition. Unexpected requirements begin with IF and are used to express requirements under unexpected circumstances. The basic sentence structure is IF + precondition + trigger. This type of requirement is used for failure mode requirements and other requirements to increase system stability and adaptability. Optional feature requirements begin with WHERE and are used for requirements that need to be met when certain optional features are present. The basic sentence structure is WHERE + includes a feature, indicating that the requirement is met only when the system has a certain feature. Conditional keywords can also be used in multiple groups simultaneously to describe requirements with more complex conditions. Each conditional sentence should be separated by commas for increased clarity. In the MBSE language, these requirements have corresponding SysML model semantics. Event-driven requirements leverage the signaling capabilities of activity diagrams to trigger behavior. State-driven and unexpected requirements utilize state machines to construct behavioral requirements. Optional feature requirements are related to other requirements and are modeled specifically through traceability relationships within the requirements model. Using these keywords or combinations thereof, you can describe the system's requirement set conditions.

[0095] Implementation 4. This implementation is an example of the functional requirements in step S2 of the axiomatic design-oriented aircraft system demand system construction method described in Implementation 1, where the functional requirements include SHAALL, WILL, and SHOULD;

[0096] The SHALL requirement means that it must be implemented and verified.

[0097] The requirement indicated by WILL does not require verification;

[0098] The requirement represented by SHOULD is a goal that must be solved.

[0099] When this embodiment is actually applied, SHAALL is a requirement symbol with strong constraints, which represents a requirement that must be implemented and its implementation must be verified; WILL is a statement symbol for facts or purposes, which represents a requirement that is not subject to verification; SHOULD is a non-mandatory requirement symbol, which represents a goal that must be solved by the design team but has not yet been formally verified. The function of a functional requirement is to respond to a requirement. In SysML, it often points to a use case or sequence. As the design progresses, the activities are refined. The subsequent functional requirements will be a link in a functional process and will be refined to a white box, pointing to an activity in SysML. When this embodiment is actually applied, the only mode of design constraints is SHAALL, and its statement is the condition that a certain parameter must meet. The conditional item is a conditional term, such as not greater than, etc., which indicates the indicator that a certain parameter of the system should have and is verifiable. The design constraint includes a mathematical conditional item and a value. This value can be a specific numerical value or other system parameters. In SysML, it points to a constraint attribute.

[0100] Implementation method 5. This implementation method is to illustrate the optional demand reason sentence structure of step S5 in the demand system construction method of an aircraft system oriented to axiomatic design described in implementation method 1. The optional demand reason sentence structure is: SO THAT+demand reason.

[0101] In practical applications of this implementation, the optional requirement reason begins with the "SO THAT" clause. This optional requirement reason is not obvious and might be lost if not documented when the requirement is constructed. This reason refers to a constraint or operational concept. The reason does not need to be written in a strict format; stating the reason facilitates understanding of the requirement when it is communicated.

[0102] Implementation method six. See Figures 3 to 9 This embodiment describes an analysis and synchronization method for aircraft requirements of an axiomatically designed aircraft system. The analysis and synchronization method is implemented using a requirements system, which is obtained by the method for constructing an aircraft system requirements system based on the axiomatic design principle described in any one of Embodiments 1 to 5. The analysis and synchronization method is as follows:

[0103] A1. Obtaining a requirements table based on the functional requirements and design constraints during the aircraft axiomatic design process according to the term list and the structured requirements template;

[0104] A2. Calculate the requirement table based on the condition keywords of each requirement to obtain optional conditions, requirement main clauses, and optional requirement reasons;

[0105] A3. Analyze the main clause of the requirement using conditional terms to determine whether it has constraints, and obtain functional requirements and design constraints;

[0106] A4. Synchronize the requirement table with the functional requirements and the design constraints.

[0107] In actual application, this embodiment automatically infers and imports the external requirement table into the modeling language SysML, such as Figure 3 As shown. External functions are analyzed by languages written in non-SysML languages and integrated into SysML tools. Requirement analysis and element synchronization are performed in the modeling language SysML environment through the system engineering MBSE tool call. Figure 7 The module that performs the function is input into the MBSE system engineering with the requirement text, ID and title. Figure 8 As shown. From the requirement text, identify optional conditions, requirement main clauses and optional requirement reasons based on keywords. From the requirement main clause, analyze whether there are constraint terms to identify the requirement type as functional requirement or design constraint. Place the structural functional requirement (functionalRequirement) and design constraint (designConstraint) under the corresponding structural column of the output requirement table. The requirement output table includes the initial input content, the requirement structural type and "assign to". The requirement table synchronized in the modeling language SysML environment is as follows: Figure 9 As shown in the figure, updated elements, new elements, deleted elements, and unchanged elements are represented in different colors. This analysis allows us to automatically build associations between requirements, use cases, and modules when axiomatic design requirements and design parameters change, and to determine the additions, deletions, and modifications to elements in the model, thus avoiding design errors caused by forgetting to delete certain requirements.

[0108] Implementation VII. This implementation is an example of synchronizing the requirements table and the functional requirements in the analysis and synchronization method for an aircraft system for axiomatic design of an aircraft requirement described in Implementation VI.

[0109] The synchronization method of the requirement table and the functional requirement is:

[0110] B1. Analyze the functional requirements to obtain the requirement subject and requirement predicate;

[0111] B2. Obtain a module table according to the demand subject;

[0112] B3. Obtain a use case table based on the requirement predicate;

[0113] B4. Classify the requirement table to obtain a conceptual design stereotype, other custom stereotypes, and a design constraint stereotype;

[0114] B5. Synchronize the conceptual design stereotype to the use case table, and synchronize the other custom stereotypes to the module table;

[0115] The synchronization method of the requirement table and the design constraints is:

[0116] C1. Analyze the design constraints to obtain a design constraint table;

[0117] C2. Synchronize the design constraint stereotype to the design constraint table.

[0118] In actual application, this embodiment identifies the subject, mode and function of the main sentence of the functional requirement; constructs a use case table and a module table, the use case table includes the use case name, storage location, conceptual design structure type (FR) and "assigned to", and the module table includes the module name, storage location and other custom structure type (DP); the identified requirement function is stored as the use case corresponding to the requirement in the use case table, the structure type is (FR) to distinguish the conceptual design use case, and the "assigned to" of the requirement table is selected as the use case name, and the use case table is as follows: Figure 10 As shown in the following example, the subject of the requirement is used as the name of the module, the stereotype is (DP) or other custom stereotypes, and the use case is assigned to the module. Figure 11 As shown. The analysis results are requirement tables, use case tables, and design parameter tables. MBSE tools are used to synchronize elements and tables in the corresponding packages, and synchronize analysis results to generate corresponding models, including the allocation relationship between models. When there is a change in the requirements of the axiomatic design, the requirements can be redesigned in the requirement diagram or requirement table, and resynchronized after automatic reasoning. The model elements that have been added, deleted, and modified can be quickly located to avoid difficult-to-track changes caused by a large number of requirements, while ensuring the traceability of the requirements. The original requirement table analysis results of all elements are shown in the figure below. Figure 12 As shown, the traceability relationship between all elements is guaranteed, and a behavior analysis diagram can be constructed under the use case and a design matrix from the use case to the DP can be constructed, saving workload.

[0119] Embodiment 8. This embodiment provides a demand system for an aircraft system oriented to axiomatic design, the system comprising:

[0120] A storage device for obtaining a glossary based on terms and corresponding explanations in various fields and terms with mathematical relationships and corresponding mathematical explanations;

[0121] a storage device for analyzing aircraft requirements according to the term list to obtain a requirement term list, wherein the storage device of the requirement term list includes at least: universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, non-obvious requirement reasons, conditional keywords, requirement subjects, requirement modalities, functional requirements, and design constraints;

[0122] a storage device for obtaining optional conditions based on the universal requirements, event-driven requirements, state-driven requirements, undesirable requirements, optional feature requirements, and condition keywords of each requirement;

[0123] A storage device for obtaining a main sentence of a requirement according to the requirement subject, the requirement modality and the functional requirement;

[0124] A storage device for obtaining a main sentence of a requirement according to the requirement subject, the requirement modality and the design constraint;

[0125] a storage device for obtaining optional demand reasons based on non-obvious demand reasons;

[0126] A storage device for obtaining a structured requirement based on the optional conditions, the main requirement clause and the reason for the requirement;

[0127] A storage device for obtaining a requirement system based on the term list and the structured requirements.

[0128] Implementation method nine. This implementation method provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for constructing a requirement system for an aircraft system oriented to axiomatic design as described in any one of implementation methods one to five or the method for analyzing and synchronizing aircraft requirements for an aircraft system oriented to axiomatic design as described in any one of implementation methods six to seven is executed.

[0129] Implementation 10. This implementation provides a computer device, which includes a memory and a processor, wherein a computer program is stored in the memory. When the processor runs the computer program stored in the memory, the processor executes the method for constructing a requirement system for an axiomatically designed aircraft system described in any one of Implementation 1 to Implementation 5 or the method for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system described in any one of Implementation 6 to Implementation 7.

[0130] The foregoing description is merely an embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be within the scope of the claims.

Claims

1. A method for constructing a requirements system for an aircraft system based on axiomatic design, characterized in that: The construction method is: S1. Obtain a glossary based on the terms and corresponding explanations in various fields and the terms with mathematical relationships and their corresponding mathematical explanations; S2. Define aircraft requirements according to the glossary to obtain a requirements template, wherein the requirements template includes at least: universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, non-obvious requirements reasons, conditional keywords, requirement subjects, requirement modalities, functional requirements, and design constraints; The universal demand in step S2 has no preset conditions and represents a demand that is always met; The event-driven requirement refers to a requirement initiated by a triggering event. The sentence structure of the event-driven requirement is: WHEN+precondition+trigger; The state-driven requirement refers to a requirement that is satisfied in a certain state. The sentence structure of the state-driven requirement is: WHILE+subject+under specific conditions; The unexpected requirement refers to a requirement that expresses an unexpected situation, and the sentence structure of the unexpected requirement is: IF+precondition+trigger; The optional feature requirement represents the requirement that needs to be met when certain optional features appear. The sentence structure of the optional feature requirement is: WHERE + include a feature; S3. Obtain optional conditions based on the universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, and conditional keywords of each requirement; S4. The main clause of the requirement is obtained in two ways: Method 1: Obtain the main sentence of the requirement according to the requirement subject, requirement modality and functional requirement; Method 2: Obtain the main sentence of the requirement according to the requirement subject, requirement modality and design constraints; S5. Obtaining optional demand reasons based on the non-obvious demand reasons; S6. Obtain a structured requirement template based on the optional conditions, the requirement main clause, and the requirement reason; S7. Obtain a demand system according to the term list and the structured demand template.

2. The method for constructing a requirements system for an aircraft system based on axiomatic design according to claim 1, characterized in that: The term list in step S1 includes system knowledge terms and condition terms.

3. The method for constructing a requirements system for an aircraft system based on axiomatic design according to claim 1, characterized in that: The functional requirements in step S2 include SHALL, WILL and SHOULD; The SHALL requirement means that it must be implemented and verified. The requirement indicated by WILL does not require verification; The requirement represented by SHOULD is a goal that must be solved.

4. The method for constructing a requirements system for an aircraft system based on axiomatic design according to claim 1, characterized in that: The optional sentence structure of the demand reason in step S5 is: SO THAT+demand reason.

5. A method for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system, characterized in that: The analysis and synchronization method is applied to the demand system according to any one of claims 1 to 4, and the analysis and synchronization method is: A1. Obtaining a requirements table based on the functional requirements and design constraints during the aircraft axiomatic design process according to the term list and the structured requirements template; A2. Calculate the requirement table based on the condition keywords of each requirement to obtain optional conditions, requirement main clauses, and optional requirement reasons; A3. Analyze the main clause of the requirement using conditional terms to determine whether it has constraints, and obtain functional requirements and design constraints; A4. Synchronize the requirement table with the functional requirements and the design constraints.

6. The method for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system according to claim 5, characterized in that: The synchronization method of the requirement table and the functional requirement is: B1. Analyze the functional requirements to obtain the requirement subject and requirement predicate; B2. Obtain a module table according to the demand subject; B3. Obtain a use case table based on the requirement predicate; B4. Classify the requirement table to obtain a conceptual design stereotype, other custom stereotypes, and a design constraint stereotype; B5. Synchronize the conceptual design stereotype to the use case table, and synchronize the other custom stereotypes to the module table; The synchronization method of the requirement table and the design constraints is: C1. Analyze the design constraints to obtain a design constraint table; C2. Synchronize the design constraint stereotype to the design constraint table.

7. A requirement system for aircraft systems oriented to axiomatic design, characterized by: The system comprises: A storage device for obtaining a glossary based on terms and corresponding explanations in various fields and terms with mathematical relationships and corresponding mathematical explanations; a storage device for analyzing aircraft requirements according to the term list to obtain a requirement term list, wherein the storage device of the requirement term list includes at least: universal requirements, event-driven requirements, state-driven requirements, unexpected requirements, optional feature requirements, non-obvious requirement reasons, conditional keywords, requirement subjects, requirement modalities, functional requirements, and design constraints; The universal demand has no preconditions and represents a demand that is always satisfied; The event-driven requirement refers to a requirement initiated by a triggering event. The sentence structure of the event-driven requirement is: WHEN+precondition+trigger; The state-driven requirement refers to a requirement that is satisfied in a certain state. The sentence structure of the state-driven requirement is: WHILE+subject+under specific conditions; The unexpected requirement refers to a requirement that expresses an unexpected situation, and the sentence structure of the unexpected requirement is: IF+precondition+trigger; The optional feature requirement represents the requirement that needs to be met when certain optional features appear. The sentence structure of the optional feature requirement is: WHERE + include a feature; a storage device for obtaining optional conditions based on the universal requirements, event-driven requirements, state-driven requirements, undesirable requirements, optional feature requirements, and condition keywords of each requirement; A storage device for obtaining a main sentence of a requirement according to the requirement subject, the requirement modality and the functional requirement; A storage device for obtaining a main sentence of a requirement according to the requirement subject, the requirement modality and the design constraint; a storage device for obtaining optional demand reasons based on non-obvious demand reasons; A storage device for obtaining a structured requirement template according to the optional conditions, the requirement main clause and the requirement reason; A storage device for obtaining a demand system based on the term list and the structured demand template.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, executes a method for constructing a requirement system for an axiomatically designed aircraft system as described in any one of claims 1-4 or a method for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system as described in any one of claims 5-6.

9. A computer device, characterized in that: The device includes a memory and a processor, wherein a computer program is stored in the memory. When the processor runs the computer program stored in the memory, the processor executes a method for constructing a requirement system for an axiomatically designed aircraft system as described in any one of claims 1-4 or a method for analyzing and synchronizing aircraft requirements for an axiomatically designed aircraft system as described in any one of claims 5-6.

Images