Model-based aerospace component demand definition modeling method

Abstract

The invention discloses an aerospace component demand definition modeling method based on a model, and belongs to the technical field of aerospace component demand engineering. According to the method, the problems of non-uniform data sources, demand omission, repetition, ambiguity, design repeated iteration and the like caused by traditional text-dependent information transmission are solved, the development period is shortened, and the development efficiency is improved. Besides, environmental influence factors, uncertain factors and dysfunction errors can be systematically identified and quantified, combed, refined, supplemented and backtracked top-level demands, design-end demands are defined, demand closed-loop forward movement in the primary stage of design is achieved, and design quality and development efficiency are improved.

Description

Technical Field

[0001] The invention relates to a model-based aerospace component demand definition modeling method, belonging to the technical field of aerospace component demand engineering. Background Art

[0002] At present, the information communication of aerospace component development relies on traditional texts, which has problems such as mismatch between demand and design, large number of technical status controls, and difficulty in ensuring consistency of technical status between documents. Specifically, the following contents are included:

[0003] (1) Mismatch between demand and design

[0004] At present, there are problems such as unclear, repeated, missing, and violation of design constraints on the demand side of aerospace components, which makes it impossible for the design side to obtain accurate research and development input. In the model-based system engineering design method, starting from the demand, functional analysis and simulation research are used to identify loopholes in the demand in advance, "check for gaps" in the top-level demand, and improve the accuracy of the input on the design side.

[0005] (2) Large number of technical status controls

[0006] Document-based engineering design methods. As the development of aerospace components deepens, the complexity of the system gradually increases. The matching and coordination of various interfaces, disciplines, functions, and architectures are difficult to organize and coordinate by manpower. However, model-based system engineering design information, technical expertise, etc. are highly correlated with the model and have a high degree of multi-person collaboration, making it more suitable for the development of complex, multi-person systems.

[0007] (3) It is difficult to ensure the consistency of technical status between documents

[0008] As the complexity of the system increases, the content and quantity of documents increase unprecedentedly, making it difficult to ensure document consistency among different personnel.

[0009] The existing document-based engineering design method can no longer meet the design of future aerospace components. There is an urgent need to establish a new method to establish a complete and sufficient definition demand model to accelerate the iteration of the design system, shorten the development cycle, and improve the development quality. Summary of the invention

[0010] The technical problem solved by the present invention is: to overcome the shortcomings of the prior art and provide a model-based aerospace component requirement definition modeling method, so as to change the problems such as inconsistent data sources, missing, repeated, unclear requirements, repeated design iterations, etc. caused by traditional text-dependent information transmission, shorten the development cycle, and improve development efficiency.

[0011] The technical solution of the present invention is: a model-based aerospace component demand definition modeling method, comprising:

[0012] Constructing a space mission requirement model based on the stakeholder requirements of the top-level tasks. The space mission requirement model is used to collect and record the needs and expectations in the implementation of the tasks, including user requirements, industry standards, procedures, internal guidelines and constraints, and form itemized task requirements for subsequent system modeling and traceability;

[0013] Construct a component system environment model based on the top-level tasks and the aerospace mission requirement model. The component system environment model is used to determine the system environment and the interactions between them, and to establish model elements between them for subsequent system modeling and tracing;

[0014] A system function model is constructed according to the top-level tasks, task requirement model, and system environment model. The system function model is designed in combination with the top-level task profile to determine the task scenario for deriving key activities and forming model elements for capture and identification for subsequent system modeling and tracing;

[0015] Construct an effectiveness measurement model based on the top-level tasks, task requirement model, system environment model, and system function model; the effectiveness measurement model combines the top-level task requirements and the task requirement model to measure the effectiveness of non-functional requirements, capture them as quantifiable features, form a traceability relationship between requirements and parameters, and ensure the integrity of the model; construct a subsystem requirement model, subsystem function model, and subsystem environment model based on the system function model and the granularity requirements of the top-level tasks. The subsystem requirement model, subsystem function model, and subsystem environment model are to refine the top-level task profile, select the preset task granularity for analysis, and capture the results of the itemized requirements and models that can be identified and traced for subsequent system modeling and tracing;

[0016] According to the subsystem requirement model, subsystem function model, subsystem environment model, task requirement model, system environment model and system function model, retrospective modeling is performed, wherein the retrospective modeling is performed between requirements and requirements, and between requirements and functions in combination with the task requirements issued from the top level and the subsystem modeling analysis, so as to form a traceability relationship between the requirements of aerospace components and the design parameter model, and ensure the integrity of the model; the subsystem modeling analysis includes the subsystem requirement model, the subsystem function model and the subsystem environment model;

[0017] According to the aerospace mission requirement model, component system environment model, system function model, effectiveness measurement model, subsystem requirement model, subsystem function model, and subsystem environment model, a complete system model is constructed to simulate the mission logic process and the physical closed-loop simulation of the scheme; based on the function model and product model, the coordination and matching verification of the interfaces between systems are realized, and the verification and evaluation of the system functions and system requirements are completed;

[0018] The itemized requirements obtained through analysis are solidified through the requirement management tool, and the confirmed itemized requirement model document is published to each system.

[0019] Furthermore, the establishment of the aerospace mission requirement model includes:

[0020] Step 1.1, Stakeholder Requirements Model Organization, Establish Stakeholder Requirements Package Structure;

[0021] Step 1.2, capture stakeholder requirements, form itemized task requirements under the directory of the stakeholder requirement package structure based on the identified user requirements, system industry standards, procedures, internal guidelines and constraints, and use the requirement element in the SysMl modeling language to carry and establish a task requirement model;

[0022] Step 1.3, review the established task requirement model, task background and operating environment. If there are any preset problems with the task requirement model, repeat steps 1.2 to 1.3.

[0023] Furthermore, the establishing of the component system environment model includes:

[0024] Step 2.1, analyze the component system environment, create an ibd diagram in the SysMl modeling language to describe the system environment, and capture the participants of the system environment;

[0025] Step 2.2, capturing the interaction between the system environment and the participants;

[0026] Step 2.3, review the system environment according to the task context to ensure that the system environment and participants are captured completely. If there are any preset problems in the system environment modeling, repeat steps 2.1 to 2.3.

[0027] Furthermore, the establishment of the component system functional model includes:

[0028] Step 3.1, establish the use case package structure of aerospace components;

[0029] Step 3.2, construct the UC diagram in the SysMl modeling language under the use case package structure directory, use the Block or Actor element to capture the system environment use case, and use the association element to build the association relationship between the system context and the participants, which is used to define the relationship between the aerospace component system context and the participants, and the association is used for subsequent tracing;

[0030] Step 3.3, create a use case scenario view, use the act diagram swim lane in the SysMl modeling language to display the system environment participants, build the allocation relationship between the model structure part and the behavior part, define the matching relationship between the environment and the participants, and determine the activities between them, so as to realize the construction of the use case model for subsequent tracing; use the call behavior action element to represent the transmission of the signal on the connector, use the contorl flow and merge mode elements to establish the logical order of signal transmission, and establish the component system functional model;

[0031] Step 3.4, review the component system function model according to the task operation background to ensure that the system function is captured completely. If preset problems occur, repeat steps 3.2 to 3.4.

[0032] Furthermore, the effectiveness measurement modeling is used to capture non-functional requirements in top-level user requirements and define them as quantifiable parameters, forming a matching relationship between parameters and requirements to ensure the integrity of system modeling, including:

[0033] Step 4.1, create a module to capture the effectiveness quality indicators, and use the generalization element in the SysMl modeling language to carry the association between the MoEs module and the development system;

[0034] Step 4.2, specify the value type for the MoEs module, and use the storage module ISO 80000 unit library to specify the module value type;

[0035] Step 4.3, review the MoEs indicator analysis in the SysMl modeling language according to the top-level tasks and the aerospace mission requirement model. If any preset problems occur, repeat steps 4.1 to 4.3.

[0036] Furthermore, the step 4.2 includes MoEs in the SysMl modeling language as evaluation criteria for preliminary simulation analysis, and the blocks of the MoE serve as model elements that carry relevant system design inputs.

[0037] Furthermore, the model granularity is refined, including:

[0038] Step 5.1, based on steps 1 to 3, add and refine the itemized requirements of the granularity required for the demand side and design side of aerospace components;

[0039] Step 5.2, establish the demand refinement model package;

[0040] Step 5.3, under the directory of the requirement refinement model package, establish a req diagram in the SysMl modeling language, use the requirement element to carry the newly added itemized requirements, and include the relationship to carry the association between the top-level requirements and the newly added requirements;

[0041] Step 5.4: Ensure that the newly added requirements meet the preset requirements based on the top-level tasks and component system environment model. If any preset problems occur, repeat step 5.3.

[0042] Step 5.5, refine the target system subsystems and divide the subsystem structure according to the task granularity;

[0043] Step 5.6, capture the subsystem behavior by the divided subsystem structure, use the act diagram in the SysMl modeling language to present the refined analysis system, use contorl flow and merge mode to establish the logical order of the refined subsystem behavior, and establish the subsystem model;

[0044] Step 5.7: Analyze the relationship between requirements and parameters, requirements and functions according to the top-level tasks and new requirements, and review the subsystem model. If any preset problems occur, repeat steps 5.5 to 5.7.

[0045] Furthermore, the backtracking modeling includes:

[0046] Step 6.1, create a detailed requirement matrix, with the column elements being the stakeholder requirements and the row element types being the activities and MoEs analysis modules;

[0047] Step 6.2, establish the derived relationship between the requirement row and the activity column, the user determines the association between the requirement and the activity, ensures the integrity of the system modeling and the correspondence between the requirement and the parameter, and the requirement and the function;

[0048] Step 6.3: According to the top-level tasks and detailed requirements matrix, ensure that all the required requirements and parameters, requirements and functions at this granularity are captured. If there are any preset problems, repeat steps 6.1 to 6.3;

[0049] In step 6.4, refine the granularity again according to the granularity requirements to avoid keeping the same analysis granularity as the model granularity refinement in step 5 to avoid omissions and duplications.

[0050] Furthermore, the simulation analysis and verification includes:

[0051] Step 7.1, using the system behavior model established in the system requirement modeling process, conduct task logic process simulation to verify the coordination of work sequence and system interaction, the correctness of functional design, the effectiveness of fault countermeasures, and the coverage of functional activities by requirements, and decide whether to iterate steps 5.5 to 5.6 based on the analysis results;

[0052] Step 7.2, for the key performance requirements proposed in the system requirement modeling, use the BBD diagram, PAR diagram and call external analysis and calculation tools to establish relevant simulation analysis models, conduct correlation simulation analysis on the key performance requirements and design constraints, verify the matching of requirements and constraints, and decide whether to iterate steps 5.5 to 5.6 based on the analysis results.

[0053] Furthermore, the requirement definition includes:

[0054] Step 8.1, establish the demand summary package structure;

[0055] Step 8.2, establish traceability and coverage relationships under the directory of the requirements summary package structure, and confirm the traceability between requirements and between requirements and activities;

[0056] Step 8.3, export demand data, export the data in the demand table to the demand management tool;

[0057] Step 8.4, publish the component requirement document and publish the confirmed itemized requirement model to the system or unit.

[0058] The advantages of the present invention compared with the prior art are:

[0059] (1) The present invention can systematically identify and quantify environmental influencing factors, uncertain factors, and functional disorder errors, sort out, refine, supplement, and trace back top-level requirements, define design-end requirements, realize the closed-loop forward movement of requirements in the early stages of design, and improve design quality and development efficiency.

[0060] (2) The present invention can solve the transmission consistency problem between documents, realize the efficiency and accuracy of information transmission under the conditions of multiple personnel and multiple devices, and improve the communication efficiency between the demand side and the design side of aerospace components.

[0061] (3) The present invention can solve the simulation analysis on the demand side and the design side, avoid system design loopholes in advance, and solve the problem that traditional paper documents cannot be linked with the simulation system. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0063] Figure 1 This is the aerospace mission requirement modeling process of the present invention (model process diagram);

[0064] Figure 2 It is the component system environment modeling process of the present invention (model process diagram);

[0065] Figure 3 It is the functional modeling process of the component system of the present invention (model process diagram);

[0066] Figure 4 It is the effectiveness measurement modeling process of the present invention (model process diagram);

[0067] Figure 5 This is the model granularity refinement modeling process of the present invention (model process diagram);

[0068] Figure 6 It is the retrospective modeling process of the present invention (model process diagram);

[0069] Figure 7 It is the simulation analysis and verification modeling process of the present invention (model process diagram);

[0070] Figure 8 It is the component requirement definition modeling process of the present invention (model process diagram);

[0071] Fig. 9 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0072] In order to better understand the above technical scheme, the technical scheme of the present invention is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical scheme of the present invention, rather than limitations on the technical scheme of the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0073] The following is a further detailed description of a model-based aerospace component requirement definition modeling method provided by an embodiment of the present invention in conjunction with the accompanying drawings. Fig. 9 , the specific implementation methods may include:

[0074] Step 1, such as Figure 1 , aerospace mission requirements modeling, including:

[0075] Step 1.1, Stakeholder Requirements Model Organization, Establish Stakeholder Requirements Package Structure;

[0076] Step 1.2, under the Stakeholder Requirements Package Structure Directory, capture stakeholder requirements, form itemized task requirements based on identified user requirements, system-related industry standards, procedures, internal guidelines, and other clear constraints, and use the requirement element in the SysMl modeling language to carry them;

[0077] Step 1.3, review the established task requirement model, task background and operating environment. If the task requirement model has unclear, repeated or missing requirements, repeat step 1.2;

[0078] The aerospace mission requirement model is used to collect and record the needs and expectations of various stakeholders in mission implementation, including user requirements, system-related industry standards, procedures, internal guidelines and other constraints, to form itemized mission requirements for subsequent system modeling and traceability.

[0079] Step 2, such as Figure 2 , component system environment modeling; including:

[0080] Step 2.1, system environment analysis, create an ibd diagram in the SysMl modeling language to describe the system environment and capture the participants of the system environment (using Block or Actor elements);

[0081] Step 2.2, capture the interaction between the system environment and the participants (connector and project flow);

[0082] Step 2.3: Review the system environment according to the task background to ensure that the system environment and participants are captured completely. If there are any missing or repeated problems in the system environment modeling, repeat steps 2.1 to 2.3:

[0083] The component system environment model is used to determine the system environment and the interactions between them, and to establish model elements therebetween, so as to facilitate subsequent system modeling and tracing.

[0084] Step 3, such as Figure 3 , component system functional modeling, including:

[0085] Step 3.1, organize the use case model and establish the use case package structure;

[0086] Step 3.2, under the use case package structure directory, construct the UC diagram in the SysMl modeling language, use the Block or Actor element to capture the system environment use case, and use the association element to build the association relationship between the system context and the actor;

[0087] Step 3.3, create a use case scenario view, use the act diagram swim lane in the SysMl modeling language to display the system environment participants, build the allocation relationship between the model structure part and the behavior part, use the call behavior action element to represent the transmission of the signal on the connector, and use the contorl flow and merge mode elements to establish the logical order of high-speed signal transmission;

[0088] Step 3.4: Review the system function model according to the task operation background to ensure that the system functions are fully captured. If there are missing or repeated functions, repeat steps 3.2 to 3.3.

[0089] The system functional model is designed in conjunction with the top-level task profile to determine the task scenario, which is used to derive key activities and form model elements for capture and identification for subsequent system modeling and tracing.

[0090] Step 4, such as Figure 4 , effectiveness measurement modeling, including:

[0091] Step 4.1, create a module to capture the effectiveness quality indicators (MoEs in SysMl modeling language), and use the generalization element to carry the association between the MoEs module and the development system (System of Interast, SoI);

[0092] Step 4.2, specify the value type for the MoEs module, and use the storage module ISO 80000 unit library to specify the module value type;

[0093] Step 4.3: Model the task background and requirements and review the MoEs indicator analysis. If there are any ambiguities, omissions, duplications, etc., repeat steps 4.1 to 4.2.

[0094] The effectiveness measurement model combines the top-level task requirements with the task requirement model to measure the effectiveness of non-functional requirements and capture them as quantifiable features in order to form a traceability relationship between requirements and parameters and ensure the integrity of the model; according to the system function model and the granularity requirements of the top-level tasks, the subsystem requirement model, subsystem function model, and subsystem environment model are constructed. The subsystem requirement model, subsystem function model, and subsystem environment model are used to refine the top-level task profile, select the preset task granularity for analysis, and capture the results of the itemized requirements and models that can be identified and traced for subsequent system modeling and tracing.

[0095] Step 5, such as Figure 5 , model granularity refinement, including:

[0096] Step 5.1, demand refinement model, add refined itemized requirements according to steps 1 to 3;

[0097] Step 5.2, establish the demand refinement model package;

[0098] Step 5.3 uses the requirement element in the SysMl modeling language to carry the newly added requirements, and contains the relationship to carry the association between the top-level requirements and the newly added requirements;

[0099] Step 5.4: Based on the task background and the analysis in step 2, ensure that the new requirements are reasonable. If there are any ambiguities, duplications, or omissions, repeat step 5.3.

[0100] Step 5.5, refine the SoI subsystem according to the task granularity and divide the subsystem structure;

[0101] Step 5.6, from step 5.5, capture the subsystem behavior, use the act diagram to present the refined analysis system, and use the contorl flow and merge mode in the SysMl modeling language to establish the logical order of the refined subsystem behavior;

[0102] Step 5.7: Review the subsystem model based on the task background and analysis modeling. If there are any missing or duplicated problems, repeat steps 5.5 to 5.6.

[0103] Step 6, such as Figure 6 , backtracking modeling, including:

[0104] Step 6.1, create a detailed requirement matrix, with the column elements being the stakeholder requirements and the row element types being the activities and MoEs analysis modules;

[0105] Step 6.2, establish the derived relationship between the requirement row and the activity column;

[0106] Step 6.3: Ensure that all optimization relationships are captured according to the task background and analysis. If there are any missing or repeated problems, repeat steps 6.1 to 6.2.

[0107] Step 6.4, refine the retrospective modeling according to the granularity of step 5, avoid keeping the same analysis granularity as step 5, and avoid missing or duplication;

[0108] The retrospective modeling is to combine the top-level task requirements with subsystem modeling analysis, and perform retrospective modeling between requirements and requirements, and requirements and functions, so as to form a traceability relationship between aerospace component requirements and design parameter models to ensure the integrity of the model.

[0109] Step 7, such as Figure 7 , simulation analysis and verification, including:

[0110] Step 7.1, using the system behavior model established in the system requirements analysis process, conduct mission logic process simulation to verify the coordination of flight sequence and system interaction, the correctness of functional design, the effectiveness of fault countermeasures, and the coverage of functional activities by requirements, and decide whether to iterate steps 5.5 to 5.6 based on the analysis results;

[0111] Step 7.2, for the key performance requirements proposed in the system requirement modeling, use the bbd diagram and par diagram in the SysMl modeling language and call external analysis and calculation tools to establish relevant simulation analysis models, conduct correlation simulation analysis on key performance requirements and design constraints, verify the matching of requirements and constraints, and decide whether to iterate steps 5.5 to 5.6 based on the analysis results;

[0112] Build a complete system model to simulate the task logic process and the physical closed-loop simulation of the solution; realize the coordination and matching verification of the interfaces between systems based on the functional model and product model, and complete the verification and evaluation of the system functions and system requirements.

[0113] Step 8, such as Figure 8 , component requirements definition, including:

[0114] Step 8.1, establish the demand summary package structure;

[0115] Step 8.2, establish traceability and coverage relationships, and confirm the traceability between requirements and between requirements and activities;

[0116] Step 8.3, export demand data, export the data in the demand table to the demand management tool;

[0117] Step 8.4, release the requirement document, and release the confirmed itemized requirement model to the system or unit.

[0118] In the solution provided in the embodiment of the present invention, the Model-Based Systems Engineering (MBSE) method is adopted to connect digital technology in series between the front-end task requirements and the design end. Through the structured definition and application of the model, the top-level requirements are sorted out, refined, supplemented, and traced back, and the design end requirements are defined to achieve the closed-loop shift of the requirements in the early stage of design, thereby improving the design quality and development efficiency. Establishing a digital requirement model based on MBSE also provides a unified and unambiguous design information exchange tool for designers from all parties due to the uniqueness of the model. The specific solution is as follows:

[0119] The MBSE-based requirement analysis and system design process is divided into eight basic steps: task requirement modeling, system environment modeling, system function modeling, effectiveness measurement modeling, model granularity refinement, retrospective modeling, simulation analysis and verification, and requirement definition.

[0120] 1) Task requirement modeling design methods and content

[0121] Comprehensively collect and record the needs and expectations of all stakeholders in task implementation, including user requirements, system-related industry standards, procedures, internal guidelines and other clear constraints, etc., to form itemized task requirements for subsequent system modeling and traceability.

[0122] Input: Top-level assignments (usually in the form of text or task-related instructions given in a formal setting).

[0123] Output: Space mission requirement model. (Including itemized requirements of user requirements, industry standards and other constraints)

[0124] SysML diagram / table: req diagram, req table.

[0125] SysML model elements: package, requirement.

[0126] The modeling process is divided into the following three steps: Figure 1 shown.

[0127] Step-1, Stakeholder demand model organization, establish stakeholder demand package structure;

[0128] Step-2, capture stakeholder requirements, form itemized task requirements based on identified user requirements, system-related industry standards, procedures, internal guidelines and other clear constraints, and use requirement elements to carry them;

[0129] Step-3, review the established task requirement model, task background and operating environment. If the task requirement model has unclear, repeated or missing requirements, repeat Step-2.

[0130] 2) Component system environment modeling design methods and contents

[0131] Through user demand and system environment analysis, the system environment and its interactions are determined, and model elements are established to facilitate subsequent system modeling and tracing.

[0132] Input: Top-level tasks and task requirement model.

[0133] Output: System environment model (task scenario).

[0134] The modeling process is divided into the following three steps: Figure 2 Shown

[0135] SysML diagrams / tables: bdd diagram, ibd diagram, etc.

[0136] SysML model elements: package, actor, generalization, block, dependency, include, association, etc.

[0137] Step-1, system environment analysis, create ibd to describe the system environment, and capture the participants of the system environment (using Block or Actor elements);

[0138] Step-2, capturing the interaction between the system environment and the participants (connector and project flow);

[0139] Step-3, review the system environment according to the task background to ensure that the system environment and participants are captured completely. If there are any missing or duplicate problems in the system environment modeling, repeat Step-1 to 2.

[0140] 3) Design methods and contents of component system functional modeling

[0141] Carry out design in combination with the task profile, refine the task scenario, derive key activities, and form clear model elements that can be captured and identified to facilitate subsequent system modeling and tracing.

[0142] Input: top-level tasks, task requirement model, and system environment model.

[0143] Output: System functional model.

[0144] SysML diagrams / tables: bdd diagram, ibd diagram, act diagram, stm diagram, etc.

[0145] SysML model elements: call behavior action, refine, block, directedcomposition, control flow, merge node, decision node, join node, fork node, initialnode, activity final, allocated activity partition, package, etc.

[0146] The modeling process is divided into the following four steps: Figure 3 Shown

[0147] Step-1, organize the use case model and establish the use case package structure;

[0148] Step-2, use case capture, build UC diagram, use Block or Actor elements to capture system environment use cases, and use association elements to build the association relationship between system context and participants;

[0149] Step-3, create a use case scenario view, use the act diagram swim lane to display the system environment participants, build the allocation relationship between the model structure part and the behavior part, use the call behavior action element to represent the transmission of the signal on the connector, and use the contorl flow and merge mode elements to establish the logical order of high-speed signal transmission;

[0150] Step-4, review the system function model according to the task operation background to ensure that the system functions are captured completely. If there are missing or duplicate functions, repeat Step-2 to 3.

[0151] 4) Effectiveness measurement modeling design methods and content

[0152] Combined with task requirements, the effectiveness of non-functional requirements is measured and captured as quantifiable characteristics of SOI to ensure the completeness of modeling at this granularity.

[0153] Input: top-level tasks, task requirement model, system environment model, and system function model.

[0154] Output: Effectiveness measurement model.

[0155] SysML diagram / table: bdd diagram, etc.

[0156] SysML model elements: block, generalization, etc.

[0157] The modeling process is divided into the following three steps: Figure 4 Shown

[0158] Step-1, create modules that capture effectiveness quality indicators (MoEs), and use generalization elements to carry the association between MoEs modules and the development system (System of Interast, SoI);

[0159] Step-2, specify the value type for the MoEs module, and use the storage module ISO 80000 unit library to specify the module value type;

[0160] Step-3, model based on task background and demand analysis, review MoEs indicator analysis, and repeat Step-1 to 2 if there are any ambiguities, omissions, duplications, etc.

[0161] 5) Model granularity refinement design methods and contents

[0162] Refine the task profile, select the appropriate task granularity for analysis, and capture the requirements and models as identifiable and traceable items to facilitate subsequent system modeling and tracing.

[0163] Input: system functional model, granular requirements engineering model.

[0164] Output: subsystem requirement model, subsystem function model, subsystem environment model.

[0165] SysML diagrams / tables: bdd diagram, ibd diagram, act diagram, stm diagram, etc.

[0166] SysML model elements: package, generalization, block, dependency, include, association, call behavior action, control flow, merge node, decision node, etc.

[0167] The modeling process is divided into the following 7 steps: Figure 5 Shown

[0168] Step-1, demand refinement model, according to 1) to 3), add detailed itemized requirements;

[0169] Step-2, establish a demand refinement model package;

[0170] Step-3 Use the requirement element to carry the newly added requirements, and the containment relationship to carry the association between the top-level requirements and the newly added requirements;

[0171] Step-4: Based on the task background and the analysis in Step-2, ensure that the new requirements are reasonable. If there are any ambiguities, duplications, or omissions, repeat Step-3.

[0172] Step-5, refine the SoI subsystem according to the task granularity and divide the subsystem structure;

[0173] Step-6, based on Step-5, capture the subsystem behavior, use the act diagram to present the refined analysis system, and use the controller flow and merge mode to establish the logical order of the refined subsystem behavior;

[0174] Step-7, based on the task background and analysis modeling, review the subsystem model. If there are any missing or duplicate problems, repeat Step-5 to 6.

[0175] 6) Retrospective modeling design methods and content

[0176] Combined with task requirements and subsystem modeling analysis, retrospective modeling is performed between requirements and requirements, and between requirements and functions, and captured as quantifiable and traceable models to ensure the integrity of system modeling.

[0177] Input: subsystem requirement model, subsystem function model, subsystem environment model, task requirement model, system environment model, system function model.

[0178] Output: Backtracking model.

[0179] SysML diagrams / tables: bdd diagram, ibd diagram, etc.

[0180] SysML model elements: block, generalization, etc.

[0181] The modeling process is divided into the following four steps: Figure 6 Shown

[0182] Step-1, create a detailed requirement matrix, where the column elements are stakeholder requirements and the row element types are activities and MoEs analysis modules;

[0183] Step-2, establish the derived relationship between the demand row and the activity column;

[0184] Step-3, according to the task background and analysis, ensure that all optimization relationships are captured. If there are missing or repeated problems, repeat Step-1 to 2;

[0185] Step-4, refine the retrospective modeling according to the granularity of the model granularity in 5), and keep the same analysis granularity as 5) to avoid missing or duplication;

[0186] 7) Simulation analysis and verification design methods and contents

[0187] The completed system model is combined with the task plan to simulate the task logic process and the physical closed-loop simulation of the plan; based on the functional model and product model, the interface coordination and matching verification between systems are realized, and the verification and evaluation of system functions and system requirements are completed to ensure the accuracy of system modeling.

[0188] Input: complete system model, engineering model.

[0189] Output: simulation analysis model.

[0190] Use graphs / charts: PAR graph, IBD graph, ACT graph, STM graph, simulation analysis graph, etc.

[0191] The modeling process is divided into the following two steps: Figure 7 Shown

[0192] Step-1, using the system behavior model established in the system requirements analysis process, conduct mission logic process simulation to verify the coordination of flight timing and system interaction, the correctness of functional design, the effectiveness of fault countermeasures, and the coverage of functional activities by requirements, and decide whether to iterate Step-5 to Step-6 in 5) based on the analysis results;

[0193] Step-2, for the key performance requirements proposed in the system requirement modeling, use the BBD diagram, PAR diagram and call external analysis and calculation tools to establish relevant simulation analysis models, conduct correlation simulation analysis on key performance requirements and design constraints, verify the matching of requirements and constraints, and decide whether to iterate Step-5 to 6 in 5) based on the analysis results;

[0194] 8) Component requirements definition design method and content

[0195] The itemized requirements obtained through analysis are solidified through the requirement management tool, and the confirmed itemized requirement model and other documents are published to various systems.

[0196] Input: task requirement model, system requirement model, subsystem requirement model, etc.

[0197] Output: Requirements document.

[0198] SysML diagrams / tables: requirement table, satisfaction requirement matrix, dependency matrix, refinerequirement matrix, Doors table.

[0199] SysML model element: package.

[0200] The modeling process is divided into the following four steps: Figure 8 Shown

[0201] Step-1, establish the demand summary package structure;

[0202] Step-2, establish traceability and coverage relationships, and confirm the traceability between requirements and between requirements and activities;

[0203] Step-3, export demand data, export the data in the demand table to the demand management tool;

[0204] Step-4, release the requirement document, and release the confirmed itemized requirement model to the system or unit.

[0205] This paper proposes a method and workflow for defining aerospace component requirements based on MBSE. Focusing on the requirements modeling and analysis process, a basic method for system architecture design, functional analysis, and simulation analysis is proposed, and the specific steps of modeling, input-output relationships, and SysML diagram / table usage specifications are clarified. The purpose is to achieve consistency between the requirements of aerospace components and the indicators in the design stage, ensure that the design indicators cover the requirements comprehensively, and the design is rigorous and accurate, laying the foundation for the subsequent development of digital design and technical management processes covering the entire mission cycle.

[0206] The present invention is based on the design task of aerospace components, integrates the existing model engineering design method (text-based) and the model-based system engineering design method, and proposes a demand analysis and system design method for aerospace components, which fills the gaps in the existing text-based development methods, including: no effective demand analysis and management means, demand management and traceability on the demand side and the design side; there are many technical status controls, and it is difficult to ensure the consistency of technical status between documents; it is difficult to conduct comprehensive integrated simulation and verification of system solutions at all stages of engineering development.

[0207] The present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and when the computer instructions are executed on a computer, the computer executes Figure 1 The method described.

[0208] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) containing computer-usable program code.

[0209] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0210] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0211] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0212] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

[0213] The contents not described in detail in the specification of the present invention belong to the common knowledge of those skilled in the art.

Claims

1. A model-based aerospace component requirement definition modeling method, characterized in that: include: Constructing a space mission requirement model based on the stakeholder requirements of the top-level tasks. The space mission requirement model is used to collect and record the needs and expectations in the implementation of the tasks, including user requirements, industry standards, procedures, internal guidelines and constraints, and form itemized task requirements for subsequent system modeling and traceability; Construct a component system environment model based on the top-level tasks and the aerospace mission requirement model. The component system environment model is used to determine the system environment and the interactions between them, and to establish model elements between them for subsequent system modeling and tracing; A system function model is constructed according to the top-level tasks, task requirement model, and system environment model. The system function model is designed in combination with the top-level task profile to determine the task scenario for deriving key activities and forming model elements for capture and identification for subsequent system modeling and tracing; Construct an effectiveness measurement model based on the top-level tasks, task requirement model, system environment model, and system function model; the effectiveness measurement model combines the top-level task requirements and the task requirement model to measure the effectiveness of non-functional requirements, capture them as quantifiable features, form a traceability relationship between requirements and parameters, and ensure the integrity of the model; construct a subsystem requirement model, subsystem function model, and subsystem environment model based on the system function model and the granularity requirements of the top-level tasks. The subsystem requirement model, subsystem function model, and subsystem environment model are to refine the top-level task profile, select the preset task granularity for analysis, and capture the results of the itemized requirements and models that can be identified and traced for subsequent system modeling and tracing; According to the subsystem requirement model, subsystem function model, subsystem environment model, task requirement model, system environment model and system function model, retrospective modeling is performed, wherein the retrospective modeling is performed between requirements and requirements, and between requirements and functions in combination with the task requirements issued from the top level and the subsystem modeling analysis, so as to form a traceability relationship between the requirements of aerospace components and the design parameter model, and ensure the integrity of the model; the subsystem modeling analysis includes the subsystem requirement model, the subsystem function model and the subsystem environment model; According to the aerospace mission requirement model, component system environment model, system function model, effectiveness measurement model, subsystem requirement model, subsystem function model, and subsystem environment model, a complete system model is constructed to simulate the mission logic process and the physical closed-loop simulation of the scheme; based on the function model and product model, the coordination and matching verification of the interfaces between systems are realized, and the verification and evaluation of the system functions and system requirements are completed; The itemized requirements obtained through analysis are solidified through the requirement management tool, and the confirmed itemized requirement model document is published to each system.

2. A model-based aerospace component requirement definition modeling method according to claim 1, characterized in that: The establishment of the aerospace mission requirement model comprises: Step 1.1, Stakeholder Requirements Model Organization, Establish Stakeholder Requirements Package Structure; Step 1.2, capture stakeholder requirements, form itemized task requirements under the directory of the stakeholder requirement package structure based on the identified user requirements, system industry standards, procedures, internal guidelines and constraints, and use the requirement element in the SysMl modeling language to carry and establish a task requirement model; Step 1.3, review the established task requirement model, task background and operating environment. If there are any preset problems with the task requirement model, repeat steps 1.2 to 1.

3.

3. A model-based aerospace component requirement definition modeling method according to claim 1, characterized in that: The establishing of the component system environment model comprises: Step 2.1, analyze the component system environment, create an ibd diagram in the SysMl modeling language to describe the system environment, and capture the participants of the system environment; Step 2.2, capturing the interaction between the system environment and the participants; Step 2.3, review the system environment according to the task context to ensure that the system environment and participants are captured completely. If there are any preset problems in the system environment modeling, repeat steps 2.1 to 2.

3.

4. A model-based aerospace component requirement definition modeling method according to claim 1, characterized in that: The establishing of the component system functional model comprises: Step 3.1, establish the use case package structure of aerospace components; Step 3.2, construct the UC diagram in the SysMl modeling language under the use case package structure directory, use the Block or Actor element to capture the system environment use case, and use the association element to build the association relationship between the system context and the participants, which is used to define the relationship between the aerospace component system context and the participants, and the association is used for subsequent tracing; Step 3.3, create a use case scenario view, use the act diagram swim lane in the SysMl modeling language to display the system environment participants, build the allocation relationship between the model structure part and the behavior part, define the matching relationship between the environment and the participants, and determine the activities between them, so as to realize the construction of the use case model for subsequent tracing; use the callbehavior action element to represent the transmission of the signal on the connector, use the contorl flow and merge mode elements to establish the logical order of signal transmission, and establish the component system functional model; Step 3.4, review the component system function model according to the task operation background to ensure that the system function is captured completely. If preset problems occur, repeat steps 3.2 to 3.

4.

5. A model-based aerospace component requirement definition modeling method according to claim 1, characterized in that: The effectiveness measurement modeling is used to capture the non-functional requirements in the top-level user requirements and define them as quantifiable parameters, forming a matching relationship between parameters and requirements to ensure the integrity of system modeling, including: Step 4.1, create a module to capture the effectiveness quality indicators, and use the generalization element in the SysMl modeling language to carry the association between the MoEs module and the development system; Step 4.2, specify the value type for the MoEs module, and use the storage module ISO 80000 unit library to specify the module value type; Step 4.3, review the MoEs indicator analysis in the SysMl modeling language according to the top-level tasks and the aerospace mission requirement model. If any preset problems occur, repeat steps 4.1 to 4.

3.

6. A model-based aerospace component requirement definition modeling method according to claim 5, characterized in that: The step 4.2 includes MoEs in the SysMl modeling language as evaluation criteria for preliminary simulation analysis, and MoE blocks as model elements that carry relevant system design inputs.

7. A model-based aerospace component requirement definition modeling method according to claim 1, characterized in that: The model granularity refinement includes: Step 5.1, based on steps 1 to 3, add and refine the itemized requirements of the granularity required for the demand side and design side of aerospace components; Step 5.2, establish the demand refinement model package; Step 5.3, under the directory of the requirement refinement model package, establish a req diagram in the SysMl modeling language, use the requirement element to carry the newly added itemized requirements, and include the relationship to carry the association between the top-level requirements and the newly added requirements; Step 5.4: Ensure that the newly added requirements meet the preset requirements based on the top-level tasks and component system environment model. If any preset problems occur, repeat step 5.

3. Step 5.5, refine the target system subsystems and divide the subsystem structure according to the task granularity; Step 5.6, capture the subsystem behavior by the divided subsystem structure, use the act diagram in the SysMl modeling language to present the refined analysis system, use contorl flow and merge mode to establish the logical order of the refined subsystem behavior, and establish the subsystem model; Step 5.7: Analyze the relationship between requirements and parameters, requirements and functions according to the top-level tasks and new requirements, and review the subsystem model. If any preset problems occur, repeat steps 5.5 to 5.

7.

8. A model-based aerospace component requirement definition modeling method according to claim 7, characterized in that: The backtracking modeling includes: Step 6.1, create a detailed requirement matrix, with the column elements being the stakeholder requirements and the row element types being the activities and MoEs analysis modules; Step 6.2, establish the derived relationship between the requirement row and the activity column, the user determines the association between the requirement and the activity, ensures the integrity of the system modeling and the correspondence between the requirement and the parameter, and the requirement and the function; Step 6.3: According to the top-level tasks and detailed requirements matrix, ensure that all the required requirements and parameters, requirements and functions at this granularity are captured. If there are any preset problems, repeat steps 6.1 to 6.3; In step 6.4, refine the granularity again according to the granularity requirements to avoid keeping the same analysis granularity as the model granularity refinement in step 5 to avoid omissions and duplications.

9. A model-based aerospace component requirement definition modeling method according to claim 7, characterized in that: The simulation analysis and verification include: Step 7.1, using the system behavior model established in the system requirement modeling process, conduct task logic process simulation to verify the coordination of work sequence and system interaction, the correctness of functional design, the effectiveness of fault countermeasures, and the coverage of functional activities by requirements, and decide whether to iterate steps 5.5 to 5.6 based on the analysis results; Step 7.2, for the key performance requirements proposed in the system requirement modeling, use the BBD diagram, PAR diagram and call external analysis and calculation tools to establish relevant simulation analysis models, conduct correlation simulation analysis on the key performance requirements and design constraints, verify the matching of requirements and constraints, and decide whether to iterate steps 5.5 to 5.6 based on the analysis results.

10. The model-based aerospace component requirement definition modeling method according to claim 1, characterized in that: The requirement definition includes: Step 8.1, establish the demand summary package structure; Step 8.2, establish traceability and coverage relationships under the directory of the requirements summary package structure, and confirm the traceability between requirements and between requirements and activities; Step 8.3, export demand data, export the data in the demand table to the demand management tool; Step 8.4, publish the component requirement document and publish the confirmed itemized requirement model to the system or unit.

Images