System Architecture Model and Construction Method for Axiomatic Design of Aircraft Based on MBSE

Abstract

System architecture model and construction method for axiomatic design of aircraft based on MBSE, which relates to the field of systems engineering technology. It solves the problems of high error rate and low efficiency existing in existing aerospace vehicle systems. The construction method of the system architecture model is as follows: determine customer requirements, then construct an operating concept to obtain top-level requirements; classify the top-level requirements to obtain functional requirements and design parameters; according to the functional requirements, obtain functional use cases, allocate the functional requirements to the functional use cases, and allocate the functional use cases to the design parameters; refine the process of the functional use cases to obtain sub-behaviors, allocate the sub-behaviors to the design parameters in the form of swimlanes, create an allocation matrix, and then decouple it. If it is a non-coupled matrix, construct new functional requirements and new design parameters possessed by the design parameters. If not, redesign the functional requirements and the design parameters, and then obtain the system architecture model. The present invention is applicable to the overall design field of complex spacecraft.

Description

Technical Field

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

[0002] Spacecraft are complex systems with high risks, having tightly coupled subsystems and complex interactions. Due to the multidisciplinary nature of space missions, they exhibit high complexity in terms of requirements, design, etc., and are difficult to manage, which is related to the high cost of spacecraft and the low mission success rate.

[0003] In a spacecraft, the system is characterized by the tight integration of a large number of subsystems, including multiple fields such as mechanical, electrical, control, and software, etc., making the spacecraft system highly complex. There are a large number of subsystem integrations in the spacecraft system, and the functional coupling between subsystems will affect the system design process and thus the design results.

[0004] Existing document-based spacecraft systems are traditional systems engineering. Since spacecraft involve multiple disciplines, they often require the collaboration of multiple departments for design and then aggregation to the overall department. Current systems engineering usually uses computer-aided design within each department, such as finite element analysis for structure and matlab analysis for control. And communication between departments is usually carried out by transferring files, such as interface files, specification files, requirement files, etc., and the number of final files will be huge. This brings inconsistencies or omissions in transfer. The impact caused by the modification of one content needs to be searched in each file, which is error-prone and time-consuming to modify or find errors as it needs to be searched in each file, resulting in low efficiency.

[0005] Therefore, in summary, the existing spacecraft systems have the problems of high error rate and low efficiency. Summary of the Invention

[0006] The present invention solves the problems of high error rate and low efficiency existing in the existing spacecraft systems.

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

[0008] The present invention provides a method for constructing a system architecture model for axiomatic design of an aircraft based on MBSE, and the method is as follows:

[0009] S1. Determine customer requirements and construct an operating concept for the entire mission according to the customer requirements;

[0010] S2. Obtain the top-level requirements for completing the mission according to the operating concept;

[0011] S3. Use the modeling language SysML to perform stereotype classification on the top-level requirements to obtain functional requirements FR and design parameters DP;

[0012] S4. Obtain functional use cases based on the functional requirement FR, allocate the functional requirement FR to the functional use cases, and at the same time allocate a main design parameter DP to the functional use cases;

[0013] S5. Refine the process of the functional use cases to obtain the sub - behaviors of the functional use cases, allocate the sub - behaviors to the design parameter DP in the form of swimlanes, and obtain the design parameter containing sub - behaviors;

[0014] S6. Create an allocation matrix based on the design parameter containing sub - behaviors, and obtain the allocation matrix from the functional use cases to the design parameter DP according to the allocation matrix;

[0015] S7. Decouple the allocation matrix from the functional use cases to the design parameter DP, confirm whether the matrix after decoupling is a non - coupled matrix. If so, construct the new functional requirements and new design parameters of the design parameter DP in sequence, and make the functional use cases of the new functional requirements correspond to the new functional requirements. If not, redesign the functional requirement FR and the design parameter DP;

[0016] S8. Repeat steps S3 to S7 until the functional requirement FR and the design parameter DP cannot be further decomposed, and obtain the system architecture model.

[0017] Furthermore, there is also a preferred embodiment. Specifically, step S1 is as follows:

[0018] The modeling language SysML uses a module definition diagram, an internal block diagram, and a use - case diagram to model the user requirements and obtain the operational concept.

[0019] Furthermore, there is also a preferred embodiment. The top - level requirements in step S2 include system metrics, system functions, task constraints, and design boundaries.

[0020] Furthermore, there is also a preferred embodiment. Specifically, step S3 is as follows:

[0021] The modeling language SysML obtains the functional requirement FR according to the ID, text, and phrases representing functions of the top - level requirements;

[0022] Obtain the design parameter DP according to the module definition diagram of the modeling language SysML.

[0023] Furthermore, there is also a preferred embodiment. Specifically, step S5 is as follows:

[0024] The modeling language SysML constructs an activity diagram corresponding to each of the functional use cases, refines the process of the functional use case according to the activity diagram to obtain the sub-behaviors possessed by the functional use case, and allocates the design parameter DP in the form of swimlanes for the sub-behaviors to obtain the design parameters containing sub-behaviors.

[0025] Further, there is also a preferred embodiment. The above step S6 is specifically as follows:

[0026] The modeling language SysML creates an allocation matrix of the activity allocation module according to the design parameters containing sub-behaviors. Vertically select the activities of the package where the functional use case is located, and horizontally select the modules with the design parameter DP. Fold all the activities of the functional use cases to obtain the allocation matrix from the functional use cases to the design parameter DP.

[0027] Further, there is also a preferred embodiment. The above step S7 is specifically as follows:

[0028] Decouple the allocation matrix from the functional use cases to the design parameter DP. If it is a diagonal matrix or a triangular matrix, then construct the new functional requirements and new design parameters possessed by the design parameter DP in sequence. According to the new functional requirements, obtain new functional use cases, and allocate the new functional requirements to the new functional use cases. If not, then redesign the functional requirements FR and the design parameter DP.

[0029] The present invention provides a system architecture model for axiomatic design of an aircraft based on MBSE. The model includes:

[0030] Unit 1: A storage device for determining customer requirements and constructing an operating concept of the entire mission according to the customer requirements;

[0031] Unit 2: A storage device for obtaining the top-level requirements for completing the mission according to the operating concept;

[0032] Unit 3: A storage device for classifying the top-level requirements by stereotype using the modeling language SysML to obtain functional requirements FR and design parameters DP;

[0033] Unit 4: A storage device for obtaining functional use cases according to the functional requirements FR, allocating the functional requirements FR to the functional use cases, and at the same time allocating a main design parameter DP to the functional use cases;

[0034] Unit 5: A storage device for refining the process of the functional use case to obtain the sub-behaviors possessed by the functional use case, and allocating the design parameter DP in the form of swimlanes for the sub-behaviors;

[0035] Unit 6: A storage device for allocating the design parameter DP in the form of swimlanes according to the sub-behaviors, creating an allocation matrix, and obtaining the allocation matrix of the functional use cases to the design parameter DP according to the allocation matrix;

[0036] Unit 7: For decoupling the allocation matrix of the functional use cases to the design parameter DP, confirming whether the matrix after decoupling is a non-coupled matrix. If so, construct the new functional requirements and new design parameters that the design parameter DP has in sequence, and correspond the functional use cases of the new functional requirements to the new functional requirements. If not, redesign the storage device of the functional requirements FR and the design parameter DP;

[0037] Unit 8: A storage device for repeating Unit 3 to Unit 7 until the functional requirements FR and the design parameter DP cannot be further decomposed to obtain a system architecture model.

[0038] The present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, the computer program executes the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in any one of the above.

[0039] The present invention provides a computer device, in which a computer program is stored. When the processor runs the computer program stored in the memory, the processor executes the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in any one of the above.

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

[0041] Compared with the prior art, the present invention has the following advantages:

[0042] 1. Existing aerospace aircraft adopt document-based systems engineering. Usually, files are transferred between different departments for communication, such as interface files, specification files, requirement files, etc., and the number of final files will be huge. This brings inconsistencies or omissions in transmission. The impact caused by the modification of one content needs to be searched in each file, which is error-prone and time-consuming to modify or search for errors, resulting in low efficiency. The present invention provides a method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE, adopting model-based systems engineering, taking the model as the only true source. The content transferred between different departments is the system model, and the modification of model elements is traceable, which can quickly determine the scope of influence, solve the problems of error-proneness and time-consuming and low-efficiency caused by the existing document-based systems engineering of aerospace aircraft, and improve system quality and project performance.

[0043] 2. The systems of existing space vehicles have tightly coupled subsystems and complex interactions. Due to the multidisciplinary nature of space missions, they exhibit high complexity in terms of requirements, design, etc., and are difficult to manage. Therefore, the cost of space vehicles is high and the mission success rate is low. The present invention provides a method for constructing a system architecture model for axiomatic design of a vehicle based on MBSE. By adopting model-based systems engineering, design errors are reduced through a single model data source, and costs are reduced and the mission success rate is increased by preventing expensive rework, thus solving the problems of high cost and low mission success rate of existing space vehicles.

[0044] 3. There are a large number of subsystem integrations in the systems of existing space vehicles. The functional coupling between subsystems will affect the system design process and thus the design results. The present invention provides a method for constructing a system architecture model for axiomatic design of a vehicle based on MBSE. The axiomatic design principle is used to provide a basis for the systems of space vehicles. Axiomatic design reduces functional loops by using a design matrix that satisfies independent axioms. This minimizes or unidirectionally affects the impact of design element modifications on other functions, reduces design coupling, and at the same time provides a decoupled system design sequence, solving the problem that the functional coupling between subsystems in existing space vehicle systems affects the system design process and thus the design results. It can also guide and evaluate the advantages and disadvantages of space vehicle system design.

[0045] The present invention is applicable to the overall design field of complex spacecraft. Description of the Drawings

[0046] Figure 1 is a flowchart of a method for constructing a system architecture model for axiomatic design of a vehicle based on MBSE according to Embodiment 1;

[0047] wherein, MBSE is model-based systems engineering and SysML is a modeling language;

[0048] Figure 2 is a schematic diagram of a stage according to Embodiment 1;

[0049] Figure 3 is Figure 2 an enlarged view of creating a Conops capture requirements baseline in the schematic diagram of the stage;

[0050] Figure 4 is Figure 2 an enlarged view of the requirements diagram in the schematic diagram of the stage;

[0051] Figure 5 is Figure 2 an enlarged view of the activity diagram in the schematic diagram of the stage;

[0052] Figure 6 is Figure 2 an enlarged view of the module definition diagram in the schematic diagram of the stage;

[0053] Figure 7 is Figure 2 an enlarged view of the internal module diagram in the schematic diagram of the stage;

[0054] Figure 8 is a schematic diagram of the package diagram definition stereotype of the modeling language SysML described in Embodiment 1;

[0055] Figure 9 is a schematic diagram of the propulsion subsystem described in Embodiment 1;

[0056] Figure 10 is a parameter diagram of data downlink described in Embodiment 1;

[0057] Figure 11 is a simulation result diagram of data downlink described in Embodiment 1;

[0058] Figure 12 is a refined activity diagram of the orbital control function requirements described in Embodiment 5;

[0059] Figure 13 is the decoupled allocation matrix described in Embodiment 7. Specific Embodiment

[0060] Embodiment 1. Refer to Figures 1 to 11 To illustrate this embodiment, this embodiment provides a method for constructing a system architecture model of axiomatic design of an aircraft based on MBSE. The construction method is as follows:

[0061] S1. Determine customer requirements and construct an operation concept for the entire mission according to the customer requirements;

[0062] S2. Obtain the top-level requirements for completing the mission according to the operation concept;

[0063] S3. Classify the top-level requirements by stereotype using the modeling language SysML to obtain functional requirements FR and design parameters DP;

[0064] S4. Obtain functional use cases according to the functional requirements FR, allocate the functional requirements FR to the functional use cases, and at the same time allocate a main design parameter DP to the functional use cases;

[0065] S5. Refine the process of the functional use cases to obtain the sub-behaviors possessed by the functional use cases, and allocate the sub-behaviors to the design parameters DP in the form of swimlanes to obtain design parameters containing sub-behaviors;

[0066] S6. Create an allocation matrix based on the design parameters containing sub - behaviors, and obtain the allocation matrix from the functional use cases to the design parameter DP according to the allocation matrix;

[0067] S7. Decouple the allocation matrix from the functional use cases to the design parameter DP, and confirm whether the matrix after decoupling is a non - coupled matrix. If so, construct the new functional requirements and new design parameters that the design parameter DP has in sequence, and map the functional use cases of the new functional requirements to the new functional requirements. If not, redesign the functional requirement FR and the design parameter DP;

[0068] S8. Repeat steps S3 to S7 until the functional requirement FR and the design parameter DP cannot be further decomposed, and obtain the system architecture model.

[0069] In actual application of this embodiment, the modeling language is selected as SysML. As Figure 1 and Figure 2 shown, determine the customer requirements, construct the operating concept of the entire task according to the customer requirements, and obtain the top - level requirements, other requirements, and constraints for completing the task. The modeling language SysML captures the top - level requirements from the customer requirements and classifies the top - level requirements in stereotypes, corresponding to the mapping from the user domain to the functional domain of axiomatic design. The modeling language SysML classifies the top - level requirements in stereotypes to obtain the functional requirement FR and the design parameter DP. The modeling language also provides an extension ability to expand the SysML semantics. These extensions, called "profile", are defined by some stereotypes, constraints, and tags applied to the metaclass of specific model elements, such as classes, attributes, operations, and activities. As Figure 8 shown, the package diagram definition stereotype schematic diagram of the modeling language SysML includes functional requirements in the requirement category, design parameters of modules, horizontal mapping, and vertical mapping. Allocate the functional requirement FR to the functional use cases, and allocate the functional use cases to a main design parameter DP to realize the mapping from the functional domain to the physical domain. The functional use case is added as a transition in the modeling language SysML. As Figure 9As shown, the use of the association construction function requires the allocation of functional use cases. The functional use cases are allocated design parameters to realize the traceability and verification relationship of requirements in systems engineering, as well as the mapping from the functional requirements of axiomatic design to the main design parameters. This enables a traceability relationship between the functional requirements FR and the design parameters DP at the model level. When the functional requirement FR is modified, it is still possible to quickly trace back to the corresponding design parameter DP. Refine the process of the functional use case to obtain the sub-behaviors of the functional use case, and allocate the design parameter DP in the form of swimlanes for the sub-behaviors. Create an allocation matrix, and obtain the allocation matrix from the functional use case to the design parameter DP according to the allocation matrix; decouple the allocation matrix, and confirm whether the matrix after decoupling is a non-coupled matrix. If so, construct the new functional requirements and design parameters of the design parameter DP in sequence, and correspond the functional use case of the new functional requirement to the new functional requirement. If not, re-design the functional requirement FR and the design parameter DP; The modeling language SysML uses the activity diagram corresponding to the functional requirement FR to construct an IBD diagram describing the interaction between DPs to describe the interaction interface relationship between systems as process variables (PV), and defines the transfer type between the interface and the flow. This corresponds to the mapping from the physical domain to the process domain of axiomatic design. Subsequently, it is possible to select and define the parameters of the system and the module, such as Figure 10 As shown, appropriate assignment simulations are carried out as needed to verify the satisfaction of the time constraint for data download. Such as Figure 11 As shown, if the simulation results meet the indicators, a solution correction is required. It solves the drawback that axiomatic design only relies on the design matrix to evaluate the design scheme, uses early verification to quantitatively evaluate the design results from the indicators, and at the same time, trade-off analysis can be carried out to optimize the system performance.

[0070] Existing space vehicles adopt document-based systems engineering. Usually, files are transferred between different departments for communication, such as interface files, specification files, requirement files, etc., and the final number of files will be huge. This brings inconsistencies or omissions in transfer. The impact caused by the modification of one content needs to be searched in each file, resulting in error-prone and time-consuming and inefficient modification or search for errors. This embodiment provides a method for constructing a system architecture model for axiomatic design of an aircraft based on MBSE. It adopts model-based systems engineering, takes the model as the only true source, and the content transferred between different departments is the system model. At the same time, the modification of model elements is traceable, and the scope of influence can be quickly determined, solving the problem of error-prone and time-consuming and inefficient modification or search for errors caused by the existing document-based systems engineering of space vehicles, and improving system quality and project performance.

[0071] The systems of existing space vehicles have tightly coupled subsystems and complex interactions. Due to the multidisciplinary nature of space missions, they exhibit high complexity in terms of requirements, design, etc., and are difficult to manage. As a result, the cost of space vehicles is high and the mission success rate is relatively low. This embodiment provides a method for constructing a system architecture model for the axiomatic design of a vehicle based on MBSE. By adopting model-based systems engineering, it reduces design errors through a single model data source, reduces costs and improves the mission success rate by preventing expensive rework, and solves the problems of high cost and low mission success rate of existing space vehicles.

[0072] There are a large number of subsystem integrations in the systems of existing space vehicles. The functional coupling between subsystems will affect the system design process and thus the design results. This embodiment provides a method for constructing a system architecture model for the axiomatic design of a vehicle based on MBSE. It uses the principles of axiomatic design to provide a basis for the systems of space vehicles. Axiomatic design reduces functional loops by using a design matrix that satisfies independent axioms. This minimizes or unidirectionally affects the impact of design element modifications on other functions, reduces design coupling, and at the same time provides a decoupled system design sequence, solving the problem that the functional coupling between subsystems in existing space vehicle systems affects the system design process and thus the design results. It can also guide and evaluate the advantages and disadvantages of the design of space vehicle systems.

[0073] Embodiment 2. This embodiment gives an example of step S1 in the method for constructing a system architecture model for the axiomatic design of a vehicle based on MBSE described in Embodiment 1. The specific content of step S1 is as follows:

[0074] The modeling language SysML uses a block definition diagram, an internal block diagram, and a use case diagram to model the user requirements and obtain the operational concept.

[0075] In actual application of this embodiment, the operational concept capture needs to model the mission execution domain. It uses the block definition diagram (BDD), internal block diagram (IBD), and use case diagram (UC) in the modeling language SysML for modeling. At the same time, it also needs to pay attention to the interactions between the system itself and the external environment, systems, and personnel, etc., as well as the task process, and uses the activity diagram and sequence diagram in the modeling language SysML for modeling to obtain the operational concept.

[0076] Embodiment 3. This embodiment gives an example of the top-level requirements of step S2 in the method for constructing a system architecture model for the axiomatic design of a vehicle based on MBSE described in Embodiment 1. The top-level requirements include system metrics, system functions, mission constraints, and design boundaries.

[0077] In actual application of this embodiment, according to the operation concept, the top-level requirements for task completion are fulfilled. The top-level requirements include system metrics, system functions, task constraints, and design boundaries for utilizing existing resources.

[0078] Embodiment 4. This embodiment gives an example of step S3 in the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in Embodiment 1. The specific step S3 is as follows:

[0079] The modeling language SysML obtains the functional requirement FR based on the ID, text, and phrases representing functions of the top-level requirements.

[0080] The design parameter DP is obtained according to the module definition diagram of the modeling language SysML.

[0081] In actual application of this embodiment, the functional requirement FR is jointly specified according to the user requirements of use cases with ID, text, and phrases representing functions. The design parameter DP is defined according to the module under the module definition diagram of the modeling language SysML.

[0082] Embodiment 5. Refer to Figure 12 To illustrate this embodiment, this embodiment gives an example of step S5 in the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in Embodiment 1. The specific step S5 is as follows:

[0083] The modeling language SysML constructs an activity diagram corresponding to each functional use case, refines the process of the functional use case according to the activity diagram to obtain the sub-behaviors possessed by the functional use case, and allocates the sub-behaviors to the design parameter DP in the form of swimlanes to obtain the design parameter containing sub-behaviors.

[0084] In actual application of this embodiment, the modeling language SysML constructs an activity diagram corresponding to each functional use case, refines the process of the functional use case according to the activity diagram to obtain the sub-behaviors possessed by the functional use case, describes its sequence in terms of control flow, describes activity interactions in terms of project flow, and allocates the sub-behaviors to the design parameter DP in the form of swimlanes. The rationality of the design is verified by simulating the activity diagram. The activities of the modeling language SysML directly construct the allocation relationship from activities to modules in the form of swimlanes. Therefore, an activity diagram is constructed for the main activity corresponding to the functional use case to define the activity sequence, and the internal sub-behaviors (actions) are also defined as activities and allocated to swimlanes to construct the activity process. Among them, the sub-behavior is the constituent unit of each activity. For the activity process with non-direct but flow interactions, it is defined according to the project flow semantics in the SysML modeling manner. As Figure 12 shown, Figure 12It is a refined activity diagram for the orbital control function requirements. The dashed line represents the control flow and connects the behavior processes. The solid line with squares is the project flow, indicating the relationship of the transfer flow. For example, the propulsion system needs the power supply module and the propellant supply to work. Although providing power is not part of a direct functional process, the component can only work under the condition of the existence of power. Power is a kind of project flow, representing the transfer of interaction. The project flow can appear in the non-direct activity flow sequence and emphasizes the flow relationship between activities. The introduction of the activity diagram enables the functional analysis of axiomatic design to be carried out in the model rather than relying on documents. The introduction of the project flow enables the functional analysis of axiomatic design to consider more interactions. This is the ability lacking in traditional axiomatic design.

[0085] Embodiment 6. This embodiment gives an example of step S6 in the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in Embodiment 1. The specific content of step S6 is as follows:

[0086] The modeling language SysML creates an allocation matrix for the activity allocation module according to the design parameters containing sub-behaviors. Select the activities in the package where the functional use case is located in the vertical row, and select the module with the design parameter DP in the horizontal row. Fold all the activities of the functional use cases to obtain the allocation matrix from the functional use case to the design parameter DP.

[0087] In the actual application of this embodiment, the modeling language SysML creates an allocation matrix for the activity allocation to the module. Select the activities in the package where the FR use case is located in the vertical row, and select the module with the DP stereotype in the horizontal row. Since the activities in the row are within the functional use case where they are located, the allocation matrix will be in the form of an expandable class folder. Therefore, fold all the activities under the functional use cases to obtain the allocation matrix from the functional use case to the design parameter DP. Due to the model nature of the modeling language SysML, the allocation relationship matrix is automatically generated, and any modification to the functional requirements or the design parameter DP will be automatically synchronized and changed, reducing the iterative workload and ensuring that the data is consistent without errors such as omissions.

[0088] Embodiment 7. Refer to Figure 13 This embodiment is described. This embodiment gives an example of step S7 in the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in Embodiment 1. The specific content of step S7 is as follows:

[0089] Decouple the allocation matrix from the functional use case to the design parameter DP. If it is a diagonal matrix or a triangular matrix, construct the new functional requirements and new design parameters that the design parameter DP has in sequence. According to the new functional requirements, obtain the new functional use cases, and allocate the new functional requirements to the new functional use cases. If not, re-design the functional requirements FR and the design parameter DP.

[0090] In actual application, the allocation matrix is decoupled and transformed into a diagonal matrix or a triangular matrix. If it cannot be transformed into a triangular matrix, it means that the design scheme does not meet the independence axiom, and the functional requirements FR and design parameters DP need to be redesigned until they are satisfied. Figure 13 is the allocation matrix after decoupling, where the numbers in the matrix are the number of activities under it allocated to the DP.

[0091] Embodiment VIII. This embodiment provides a system architecture model for axiomatic design of an aircraft based on MBSE. The model includes:

[0092] Unit 1: A storage device for determining customer requirements and constructing an operating concept for the entire mission according to the customer requirements;

[0093] Unit 2: A storage device for obtaining the top-level requirements for completing the mission according to the operating concept;

[0094] Unit 3: A storage device for classifying the top-level requirements by stereotype using the modeling language SysML to obtain functional requirements FR and design parameters DP;

[0095] Unit 4: A storage device for obtaining functional use cases according to the functional requirements FR, allocating the functional requirements FR to the functional use cases, and at the same time allocating a main design parameter DP to the functional use cases;

[0096] Unit 5: A storage device for refining the process of the functional use cases to obtain the sub-behaviors possessed by the functional use cases, and allocating the sub-behaviors to the design parameters DP in the form of swimlanes;

[0097] Unit 6: A storage device for creating an allocation matrix by allocating the design parameters DP in the form of swimlanes according to the sub-behaviors, and obtaining the allocation matrix from the functional use cases to the design parameters DP according to the allocation matrix;

[0098] Unit 7: A storage device for decoupling the allocation matrix from the functional use cases to the design parameters DP, confirming whether the matrix after decoupling is a non-coupled matrix. If so, sequentially construct the new functional requirements and new design parameters possessed by the design parameters DP, and correspond the functional use cases of the new functional requirements to the new functional requirements. If not, redesign the functional requirements FR and the design parameters DP;

[0099] Unit 8: A storage device for repeating Unit 3 to Unit 7 until the functional requirements FR and design parameters DP cannot be further decomposed to obtain the system architecture model.

[0100] Embodiment Nine. This embodiment provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it executes the method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE described in any one of Embodiments One to Seven.

[0101] Embodiment Ten. This embodiment provides a computer device, which includes a memory and a processor. 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 system architecture model of an axiomatic design of an aircraft based on MBSE described in any one of Embodiments One to Seven.

[0102] The above are only the embodiments of the present invention and do not limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the scope of the claims of the present invention.

Claims

1. A construction method for a system architecture model of aircraft axiomatic design based on MBSE, characterized in that, The method is as follows: S1. Determine the customer requirements and construct the operation concept of the entire task according to the customer requirements; S2. Obtain the top-level requirements for completing the task according to the operation concept; S3. Use the modeling language SysML to perform stereotype classification on the top-level requirements to obtain functional requirements FR and design parameters DP; Specifically, S3 is as follows: The modeling language SysML obtains the functional requirements FR according to the ID, text, and phrases representing functions of the top-level requirements; The design parameters DP are obtained according to the module definition diagram of the modeling language SysML; S4. Obtain functional use cases according to the functional requirements FR, assign the functional requirements FR to the functional use cases, and at the same time assign a main design parameter DP to the functional use cases; S5. Refine the process of the functional use cases to obtain the sub-behaviors possessed by the functional use cases, and assign the sub-behaviors to the design parameters DP in the form of swimlanes to obtain design parameters containing sub-behaviors; S6. Create an allocation matrix according to the design parameters containing sub-behaviors, and obtain the allocation matrix from the functional use cases to the design parameters DP according to the allocation matrix; Specifically, S6 is as follows: The modeling language SysML creates an allocation matrix of the activity allocation module according to the design parameters containing sub-behaviors, selects the activities of the package where the functional use cases are located in the vertical row, selects the modules with the design parameters DP in the horizontal row, and folds the activities of all functional use cases to obtain the allocation matrix from the functional use cases to the design parameters DP; S7. Decouple the allocation matrix from the functional use cases to the design parameters DP, and confirm whether the matrix after decoupling is a non-coupled matrix. If so, construct new functional requirements and new design parameters possessed by the design parameters DP in sequence, and make the functional use cases corresponding to the new functional requirements. If not, redesign the functional requirements FR and the design parameters DP; Specifically, S7 is as follows: Decouple the allocation matrix from the functional use cases to the design parameters DP. If it is a diagonal matrix or a triangular matrix, construct new functional requirements and new design parameters possessed by the design parameters DP in sequence. According to the new functional requirements, obtain new functional use cases, and assign the new functional requirements to the new functional use cases. If not, redesign the functional requirements FR and the design parameters DP; S8. Repeat steps S3 to S7 until the functional requirements FR and the design parameters DP cannot be further decomposed to obtain the system architecture model.

2. The construction method for a system architecture model of aircraft axiomatic design based on MBSE according to claim 1, characterized in that, Specifically, step S1 is as follows: The modeling language SysML uses the module definition diagram, internal module diagram, and use case diagram to model the customer requirements to obtain the operation concept.

3. The construction method for a system architecture model of aircraft axiomatic design based on MBSE according to claim 1, characterized in that, The top-level requirements in step S2 include system indicators, system functions, task constraints, and design boundaries.

4. The construction method for a system architecture model of aircraft axiomatic design based on MBSE according to claim 1, characterized in that, Specifically, step S5 is as follows: The modeling language SysML constructs an activity diagram corresponding to each functional use case, refines the process of the functional use case according to the activity diagram to obtain the sub-behaviors possessed by the functional use case, and assigns the sub-behaviors to the design parameters DP in the form of swimlanes to obtain design parameters containing sub-behaviors.

5. A system architecture model of aircraft axiomatic design based on MBSE, characterized in that, The model includes a storage device, which is used to execute the method and steps described in claim 1.

6. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is run by a processor, it executes a method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE according to any one of claims 1-4.

7. A computer device, characterized in that, The device includes a memory and a processor. A computer program is stored in the memory, and when the processor runs the computer program stored in the memory, the processor executes a method for constructing a system architecture model of an axiomatic design of an aircraft based on MBSE according to any one of claims 1-4.

Images