An engineering design method, device and equipment based on general quality characteristic analysis

Abstract

The present invention discloses an engineering design method, device and equipment based on universal quality characteristic analysis, and relates to the field of engineering design technology. First, the task profile and failure mode and impact analysis for realizing business requirements are abstracted and associated to obtain an abstract model of engineering design under failure mode and impact analysis, and then the stakeholders of engineering design at the business layer are determined, and the task requirements corresponding to the stakeholder requirements at the business layer are determined, and then failure mode and impact analysis is performed at the business layer to supplement the task reliability requirements at the business layer, and finally failure mode and impact analysis is performed at the system layer to supplement the system reliability requirements at the system layer. The present invention integrates universal quality characteristic analysis into the entire engineering design process, so that the engineering product is supplemented in reliability at both the business layer and the system layer, thereby improving the overall integration of engineering product design with universal quality characteristic analysis, and improving the overall consistency and reliability of engineering product design.

Description

Technical Field

[0001] The present application relates to the field of engineering design technology, and in particular to an engineering design method, device and equipment based on universal quality characteristic analysis. Background Art

[0002] In general, the analysis and design of general quality characteristics should be an organic part of engineering product design. However, in traditional design, since the six characteristics cannot be directly quantified, it is difficult to directly affect the design of engineering products. Actual engineering often needs to be considered independently and gradually realized by multiple means combining qualitative and quantitative methods. Traditional reliability engineering activities also hope to have a "direct impact" on functional performance design. "Two skins" has always been a problem that six-characteristic engineering practice has been trying to solve, but currently it is mainly promoted through management methods to "indirectly affect" product functional performance design by six-characteristic design, lacking the necessary technical means to cut off the root cause of the "two skins" problem.

[0003] In view of the changes and development of the connotation of modern design, on the one hand, the six-characteristic design must adapt to the changes and extensions of the connotation of performance design, take the path of full-process, parallel, collaborative and integrated, and closely integrate with the forward design process. On the other hand, under the guidance of modern advanced design theories and design methods, and driven by fully digital design methods, it is conducive to further developing and enriching the connotation of "six-characteristic" design, promoting the development of six-characteristic design modeling and digital technology, and making six-characteristic design truly "organic" integrated into product design, which is called the "hard" constraint of design.

[0004] In the existing technology, the application of model-based system engineering (MBSE) in general quality characteristics abroad has been relatively extensive, aiming to combine system design with general quality characteristics analysis, and to affect the engineering activities of general quality characteristics on the functional performance design of the system, so as to propose some solutions and methods to solve the problem of "two skins". At present, the main modeling solutions abroad are carried out from two aspects. On the one hand, the work of general quality characteristics is integrated into the system design stage. In the process of system design modeling, the analysis work of general quality characteristics is introduced at the same time. According to the forward design process, use case analysis, function analysis, and logical architecture are used to lead to failure cases and failure functions, so as to perform redundant design on the system architecture design. On the other hand, with the help of external design analysis tools, the corresponding system design content is output by opening the interface of the system design tool, and the reliability and safety analysis of the system design content is carried out in the professional general quality characteristics tool. After completion, the corresponding content is returned to the system model to form a closed loop. At this stage, there are two types of domestic research. One is to integrate reliability analysis into system modeling. Another research method in China is to integrate the system design model with reliability analysis software.

[0005] However, the current general quality characteristic analysis in the engineering design stage often focuses on the functional modules of engineering products. Although it can partially improve the functional module design of engineering products, the engineering design as a whole is still poorly integrated with the general quality characteristic analysis. Summary of the invention

[0006] Based on this, it is necessary to provide an engineering design method, device and equipment based on general quality characteristic analysis to address the above technical problems.

[0007] This manual adopts the following technical solutions:

[0008] This specification provides an engineering design method based on general quality characteristics analysis, including:

[0009] Build the domain model corresponding to the engineering product based on the business requirements of the engineering design, abstract and associate the task profiles that realize the business requirements with the corresponding failure mode and impact analysis, and obtain the abstract model of the engineering design under the failure mode and impact analysis;

[0010] Based on the domain model corresponding to the engineering product, determine the stakeholders of engineering design at the business level, and determine the task requirements corresponding to the requirements of each stakeholder at the business level; model each task requirement according to the execution process of each task to obtain a task requirement model;

[0011] Based on the abstract model of engineering design under failure mode and effect analysis, failure analysis is performed on the execution process of the task requirement model, and task reliability requirements for coping with task failures are supplemented to the task requirement model;

[0012] The decomposed and supplemented task requirement model is used to obtain the system requirements of the engineering product and form a system requirement model. Failure analysis is performed on the behavioral models of each system of the engineering product, and the system reliability requirements for coping with system failures are supplemented for the system requirement model. The engineering product is designed based on the supplemented system requirement model.

[0013] Optionally, the abstraction and association of the task profile for realizing the business requirements and the failure mode and effect analysis to obtain an abstract model of the engineering design under the failure mode and effect analysis specifically includes:

[0014] defining a task construction type representing a task profile, the construction type describing a system at a certain position at a certain time and state;

[0015] Define context attributes of systems, subsystems and components, and use the context attributes as attributes in the task construction type, wherein the context attributes represent the background context in which the fault occurs;

[0016] Define the fault propagation path attributes for the fault to be chained from the bottom component to the target level, and use the fault propagation path attributes as attributes in the task construction type;

[0017] Define the relevant attributes for associating the functions, activities and states of the components to the task construction type, and use the relevant attributes as attributes in the task construction type;

[0018] Define a failure mode and effects analysis abstract class, define a risk factor in the failure mode and effects analysis abstract class, and define abstract failure modes, abstract failure causes, and abstract failure effects as components in the failure mode and effects analysis abstract class.

[0019] Optionally, modeling the task requirements according to the task execution process to obtain a task requirement model specifically includes:

[0020] By analyzing the requirements of each task, a use case model is constructed according to the execution process of each task, and the task requirement model is obtained by analyzing each task scenario.

[0021] Optionally, the abstract model of engineering design based on the failure mode and effect analysis performs failure analysis on the execution process of the task requirement model, and supplements the task reliability requirements for coping with task failures with respect to the task requirement model, specifically including:

[0022] Conduct failure case analysis on each task execution process, and supplement the task reliability requirements for task failure cases based on the task requirement model;

[0023] Use the behavior model to expand the use case model, perform failure analysis on the behavior model during the execution of each task, obtain the fault behavior and fault status during the execution of each task, and form the task failure mode during the execution of each task;

[0024] A mission failure plan is proposed for the mission failure mode, and the mission failure mode is analyzed based on the abstract model of engineering design under failure mode and effect analysis. The mission reliability requirements for dealing with mission failure behaviors are supplemented for the mission requirement model.

[0025] Optionally, the decomposed and supplemented task requirement model obtains the system requirements of the engineering product and forms a system requirement model, specifically including:

[0026] Decompose the supplemented task requirement model to obtain the system function model and system function indicators of the engineering product;

[0027] Convert the system function model and system function indicators of engineering products into system requirements of engineering products and build a system requirement model.

[0028] Optionally, the failure analysis of the behavior model of each system of the engineering product and the supplementation of the system reliability requirements for coping with system failures with respect to the system requirement model specifically include:

[0029] Use behavioral models to describe the behavioral logic and state transition of each system of the engineering product during the execution of each task, and perform failure analysis on the behavioral model of each system to obtain the fault behavior and fault state of each system during the execution of each task, and form the system failure mode of each system during the execution of each task;

[0030] Analyze the system failure mode, propose system failure plans for the system failure mode, and supplement the system reliability requirements for coping with system failures based on the system requirement model.

[0031] Optionally, the engineering product is a manned lunar spacecraft, and a domain model corresponding to the manned lunar spacecraft is constructed using a system modeling language.

[0032] This specification provides an engineering design device based on general quality characteristic analysis, including:

[0033] The abstract module is used to build the domain model corresponding to the engineering product based on the business requirements of the engineering design, abstract and associate the task profiles that realize the business requirements with the corresponding failure mode and impact analysis, and obtain the abstract model of the engineering design under the failure mode and impact analysis;

[0034] The task requirement determination module is used to determine the stakeholders of engineering design at the business level based on the domain model corresponding to the engineering product, and to determine the task requirements corresponding to the requirements of each stakeholder at the business level; and to model each task requirement according to the execution process of each task to obtain a task requirement model;

[0035] The task analysis module is used to perform failure analysis on the execution process of the task requirement model based on the abstract model of engineering design under the failure mode and effect analysis, and to supplement the task reliability requirements for coping with task failures with respect to the task requirement model;

[0036] The system analysis module is used to decompose the supplemented task requirement model to obtain the system requirements of the engineering product and form a system requirement model, perform failure analysis on the behavioral models of each system of the engineering product, supplement the system reliability requirements for coping with system failures based on the system requirement model, and design the engineering product based on the supplemented system requirement model.

[0037] This specification provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the engineering design method based on general quality characteristic analysis is implemented.

[0038] This specification provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned engineering design method based on general quality characteristic analysis when executing the program.

[0039] At least one of the above technical solutions adopted in this specification can achieve the following beneficial effects:

[0040] First, abstract and associate the task profile and failure mode and effect analysis for realizing business requirements to obtain the abstract model of engineering design under failure mode and effect analysis. Then determine the stakeholders of engineering design at the business layer, and determine the task requirements corresponding to the stakeholder requirements at the business layer. Then, perform failure mode and effect analysis at the business layer to supplement the task reliability requirements at the business layer. Finally, perform failure mode and effect analysis at the system layer to supplement the system reliability requirements at the system layer.

[0041] The present invention integrates the universal quality characteristic analysis into the entire engineering design process, so that the engineering product can be supplemented for reliability at both the business layer and the system layer, thereby improving the overall integration of the engineering product design with the universal quality characteristic analysis, thereby improving the overall consistency and reliability of the engineering product design. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0043] Figure 1 A flow chart of an engineering design method based on general quality characteristic analysis provided for this specification;

[0044] Figure 2 A schematic diagram of a MOF four-layer model system provided in this specification;

[0045] Figure 3 A schematic diagram of a core architecture library provided for this specification;

[0046] Figure 4 A general quality characteristic analysis design schematic diagram based on MBSE provided in this manual;

[0047] Figure 5 A schematic diagram of stakeholders of a manned lunar spacecraft provided for this specification;

[0048] Figure 6 A schematic diagram of the mission requirements of a manned lunar spacecraft provided in this manual;

[0049] Figure 7 A schematic diagram of a FMEA framework model provided for this specification;

[0050] Figure 8 A schematic diagram of an engineering design device based on a general quality characteristic analysis provided for this specification;

[0051] Fig. 9 A schematic diagram of a computer device for implementing an engineering design method based on general quality characteristic analysis is provided in this specification. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solutions and advantages of this specification more clear, the technical solutions of this application will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments in the specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0053] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0054] Figure 1 The following is a flow chart of an engineering design method based on general quality characteristic analysis in this specification, which specifically includes the following steps:

[0055] S101: Build a domain model corresponding to the engineering product based on the business requirements of the engineering design, abstract and associate the task profiles that implement the business requirements and their corresponding failure mode and effect analysis, and obtain an abstract model of the engineering design under the failure mode and effect analysis.

[0056] Generally, when forward designing an engineering product, a general quality characteristic analysis process can be incorporated into the design process to improve the overall reliability of the engineering design.

[0057] Based on this, in one or more embodiments of this specification, the server may first construct a domain model corresponding to the engineering product based on the business requirements of the engineering design. The engineering product mentioned here can be any product, for example, it can be a manned lunar spacecraft. The following description is based on the manned lunar spacecraft as an example, but this specification does not limit what the engineering product is specifically.

[0058] When building the domain model of the manned lunar spacecraft, customization for a specific domain (aerospace domain) can be achieved based on the domain metamodel. For the domain metamodel, the MOF (Meta Object Facility) standard is the main guiding principle for building the domain metamodel. According to the MOF specification in the OMG Model Driven Architecture (MDA) standard, it is sufficient to perform four levels of abstraction on the model, namely meta-metamodel M3, meta-model M2, model M1 and instance M0, such as Figure 2 shown.

[0059] Figure 2 This is a schematic diagram of a MOF four-layer model system in this specification. Figure 2 In the M3 layer, the meta-metamodel is classified into six types of meta-metamodels:

[0060] Property: cannot exist independently, and is attached to other meta-meta-models to represent their characteristics. Different properties or property values ​​are assigned to the other five meta-meta-models to represent their types.

[0061] Port: Usually attached to an object, connecting the object and the role, indicating the connection port.

[0062] Role: At both ends of a relationship, it connects objects and indicates how or in what capacity the objects are connected.

[0063] Object: It is one of the basic elements of the model and the main element in the model. It is used to represent a thing and can exist independently or be linked with other objects.

[0064] Relationship: A relationship connects objects through roles, indicating the relationship between objects or the way they are connected.

[0065] Graph: A graph is composed of the above five elements and describes the system in a box.

[0066] The M2 layer is the metamodel: modeling at the metamodel level is to combine or attach special meanings to meta-metamodels to form a modeling language for a specific domain. For example, attributes are attached to the object meta-metamodel to indicate its type, and examples are displayed through different forms of fixed syntax so that the model can be identified during modeling. Object, relationship, role, and point meta-metamodels add attributes when establishing metamodels, and add attribute values ​​to instantiate when modeling to describe the system to be established. The other five meta-metamodels are needed when establishing graph metamodels. Objects, roles, points, and roles are bound in the graph to define the rules for establishing graph models. The M1 layer is the model: the metamodel is instantiated in the modeling interface to describe the system to be established. When modeling, the model needs to be instantiated and connected according to the modeling rules of the specific domain modeling language. The general steps are to select the object metamodel and add it to the modeling interface, add the corresponding attribute values ​​to instantiate the object; select the corresponding role through the specified relationship to connect the instantiated object, which can be connected to the object itself or through the points attached to the object to represent the system. At the model level, in order to facilitate model identification, the fixed syntax is usually changed according to the type of metamodel. The fixed syntax usually includes the metamodel shape, color, and text color.

[0067] The M0 layer is a model of the real system. It describes the model from a certain perspective of the system through a series of models, making it easier for people with different needs to identify the system.

[0068] The current definition and creation method of domain models commonly used in the field of system design in the aerospace field is based on the System Modeling Language (SysML), using the extended functions of the SysML profile to extend the original metamodel and combine the design content of related concepts in the field with SysML.

[0069] The basis for understanding the domain metamodel is the precise expression of domain knowledge, and for this purpose, it is necessary to introduce theories about semantics. The semantic triangle theory is a general method for describing and interpreting concepts. This method believes that semantics contains three major elements: indicators, descriptive symbols describing indicators, and concepts represented by indicators. If there is a consistent interpretation and understanding of an entity that exists in the real world, it is necessary to have a unified understanding of both the physical concept and the symbolic grammar in a specified context. The expression of semantics and the use of symbolic symbols must be based on unified standards in order to effectively convey complete semantic information.

[0070] Ontology is a model that describes knowledge in a specific domain, that is, ontology is the embodiment of semantic understanding. On the one hand, it is based on description logic and has certain formal characteristics. It uses concepts and relationships in the domain to describe facts, which is close to human thinking habits and easy to understand. On the other hand, it improves the abstract level of fact description and standardizes the expression of multiple facts. It is a meta-theory. Combining ontology with metamodel to form a theoretical system of ontology metamodeling will make the metamodel have stronger modeling and expression capabilities and promote the semantic combinability of simulation modeling resources.

[0071] The steps for building a domain model based on the SysML framework are as follows:

[0072] 1. Collect concepts in the field of manned lunar spacecraft, abstract domain-specific metamodels from conceptual models, and demonstrate the semantic rationality of metamodels based on ontology reasoning capabilities.

[0073] 2. Create a meta-model system and add application-level settings and attributes to it, so that it can be symbolically close to the existing work characteristics in the field.

[0074] 3. Create the M1 layer model based on the domain metamodel to realize the application of the metamodel.

[0075] 4. Implement it in actual work and make iterative changes to the constructed metamodel system.

[0076] Then, the server can build a Failure Mode and Effect Analysis (FMEA) framework. Specifically, in one or more embodiments of this specification, the server can define a task construction type that represents a task profile. The so-called task profile refers to a time-series description of events and environments experienced by a product during the time period of completing a target task. In the field of reliability, any failure occurs on the basis of a certain task profile. Therefore, a core model, namely Situation, is first defined to express the task profile. Other basic concepts are defined on this basis. The Situation construction type is used to describe a system in a given position at a given time and under a given state. It is connected to the Block construction type in SysML through generalization and inherits the relevant properties of Block in SysML. At the same time, three attribute values ​​are defined for the Situation construction type.

[0077] The first attribute value, Context, is of type Block, which defines the context attributes of systems, subsystems, and components. The context attributes are used as attributes in the task construction type. The context attributes represent the background context in which the fault occurs. It is used to associate the Situation with a specific background context. Any fault occurs based on a certain part of the system. And it is customary to use Block to express systems, subsystems, and components when modeling the system.

[0078] The second attribute value, PropertyPath, is of type PartProperty, which defines the fault propagation path attribute of the fault chain from the bottom component to the target level, and uses the fault propagation path attribute as the attribute in the task construction type. It is used to associate some attributes with the Situation. The use of PartProperty here expresses that when performing reliability analysis, the fault of a certain level is analyzed, and the fault itself is a chain structure caused by the failure of the bottom component. Therefore, the introduction of PartProperty is to characterize the fault propagation path under this analysis module.

[0079] The third attribute value RelevantTo, whose type is Element, is defined to associate the function, activity and state of the component with the relevant attributes of the task construction type, and to use the relevant attributes as the attributes of the task construction type. It is used to associate various attributes with the Situation, such as Activity, State, etc. In reliability analysis, a Situation contains elements such as the function and state of some components. Therefore, in order to more clearly describe the relevant information in the fault Situation, RelevantTo is introduced.

[0080] In addition, you can define the Violates construction type, and select Dependency as its Meta class to indicate an association relationship. When performing reliability analysis, modeling is based on requirements. When the function or state of a component violates the relevant reliability requirements, association is performed through customized Violates, thereby forming a traceability mapping of requirements and reliability-related analysis.

[0081] And you can also define the Controlling Action construction type, and its Meta class is set to Dependency, indicating an association relationship. In the field of reliability, it can be used to associate a certain failure mode with a control measure. This lays the foundation for subsequent reliability analysis. Any reliability analysis is to avoid or reduce the occurrence of failures. Therefore, the end of the analysis is to propose corresponding control measures to eliminate or weaken the current failure mode. Therefore, the association relationship is established through ControllingAction to form a mapping and traceability. Define the Gate, Or, and And construction types, and generalize Gate with Or and And. Later in the field of reliability, it is used to describe the concept of gate. Or represents an OR gate, and And represents an AND gate. For example Figure 3 As shown, Figure 3 This is a schematic diagram of a core architecture library in this manual. Figure 3 In the example, AnySituation of the Situation type is established and connected through Association to indicate the relationship from a certain state to any state. Different situations can be associated with each other using causal relationship classes to express the semantic relationship between situations, such as simple causal relationship, conditional causal relationship, and probabilistic relationship. Here, the transition between normal scenario and fault scenario in reliability is indicated.

[0082] The classic FMEA table mainly includes three parts: failure mode, failure cause and failure impact. Therefore, in the reliability modeling analysis based on MBSE, component association is used to take failure mode, failure cause and failure impact as the components of FMEA.

[0083] Based on this, the server can define a failure mode and effects analysis abstract class, define a risk factor in the failure mode and effects analysis abstract class, and define abstract failure modes, abstract failure causes and abstract failure effects as components in the failure mode and effects analysis abstract class.

[0084] For example, an FMEA model abstract class can be constructed, and then the actual FMEA analysis can be modeled through the generalization relationship. First, an abstract FMEAitem can be established, and the RPN value attribute can be defined. At the same time, the abstract failure mode, abstract failure cause, and abstract failure impact can be connected to the AbstractFMEAitem through composition association. Thus, a general model architecture for analyzing FMEA is formed. Then, the abstract FMEA architecture is specialized through specialization to form a special FMEA model analysis architecture in the field of aerospace reliability. In this architecture, some attributes and value attributes inherited from FMEAitem are redefined, and some new attributes related to the field are added. The type of the redefined RPN value attribute is set to Real. At the same time, new value attributes - risk assessment index and new value attribute - Severity are added. The component of the cause of failure contains multiple causes. The component of the failure impact is divided into three types: local impact, higher-level impact, and final impact, and each component contains multiple.

[0085] The server mentioned in this specification can be a server set up on a business platform, or a device such as a desktop computer, a laptop computer, etc. that can execute the solution of this specification. For the convenience of description, the following description is based on the server as the execution subject.

[0086] S102: Based on the domain model corresponding to the engineering product, determine the stakeholders of the engineering design at the business layer, and determine the task requirements corresponding to the requirements of the stakeholders at the business layer; model each task requirement according to the execution process of each task to obtain a task requirement model.

[0087] S103: Based on the abstract model of engineering design under the failure mode and effect analysis, a failure analysis is performed on the execution process of the task requirement model, and the task reliability requirements for coping with task failures are supplemented to the task requirement model.

[0088] After completing the customization of the aerospace domain model to obtain the domain model and FMEA abstract model corresponding to the engineering product, the server can control the entire subsequent design process from the business layer to the system layer. Figure 4 shown.

[0089] Figure 4 This is a general quality characteristic analysis design diagram based on MBSE in this manual. For subsequent instructions, please refer to Figure 4 .

[0090] The server can first be combined with the business layer design analysis and general quality characteristics analysis. The model-based system engineering method is used to carry out forward design of the manned lunar mission.

[0091] Specifically, in one or more embodiments of the present specification, first, the server can analyze the task requirements and build a use case model according to the task execution process to analyze the task scenario to obtain a task requirement model. Perform a failure case analysis on the task execution process to supplement the task reliability requirements for dealing with task failure cases.

[0092] For example, the server can break down task requirements item by item based on the model-based system engineering design approach, starting from stakeholders and core business goals. Figure 5 , Figure 6 As shown, Figure 5 This is a schematic diagram of stakeholders of a manned lunar spacecraft in this manual. Figure 6 This is a schematic diagram of the mission requirements of a manned lunar spacecraft in this manual.

[0093] Then, the mission requirements are analyzed and the requirements for general quality characteristics are initially extracted. The association matrix method is used to associate the mission requirements of the manned lunar spacecraft with the requirements for general quality characteristics, thereby forming a traceability system.

[0094] Then, the task scenario is analyzed through the use case model to describe how external participants and executors in the task participate in the task and how to ensure the smooth completion of the task. Based on this use case analysis, the task process is analyzed using failure case analysis to describe how to deal with a failure in the execution case of the task. Based on the analysis of failure cases, the reliability requirements are further supplemented and improved, and task reliability requirements that meet the current task failure cases are proposed.

[0095] Afterwards, the server can use the behavior model to expand the use case model to describe the behavior logic and state transitions during the task process. Based on this behavior model, the behavior model during the task execution process is analyzed for failure, and the failure behavior and failure state during the task execution process are obtained, thereby forming the task failure mode during the task execution process. A task failure plan is proposed for the task failure mode, and the task failure mode is analyzed based on the abstract model of engineering design under the failure mode and effect analysis. When the behavior failure analysis is completed, the analysis content is refined, and the task reliability requirements for dealing with task failure behaviors are supplemented, and then the engineering design is iterated according to the newly supplemented requirements.

[0096] Finally, the server can perform task architecture modeling. Based on the above analysis, while ensuring that the task objectives are achieved, an architecture model of the task is formed. Based on the reliability requirements obtained from the previous analysis, necessary redundant systems are added to the task architecture to ensure that the task can be completed reliably and efficiently. After completing the architecture analysis, FMEA analysis of the system can be carried out and the corresponding reliability requirements can be supplemented.

[0097] For example, the server can extract stakeholders by communicating with system designers and gradually gaining a deeper understanding of the source and process of tasks, or by searching system-related documents to identify and obtain stakeholders through brainstorming. For the system, stakeholder needs are capabilities or things that one or more stakeholders lack but want or expect the system to have. The purpose of extracting requirements is to clearly obtain the capability requirements of users or other stakeholders for the system. Stakeholder requirements can be obtained by communicating with system designers and analyzing based on needs and mission missions. The needs are described in the form of "<who> wants to do <what> (to what extent) <when> <through what>". Who is the stakeholder, and the stakeholders expect the system to perform tasks in what kind of task environment and with what kind of capabilities.

[0098] The needs of stakeholders can be grouped. After the needs of stakeholders are in the model, they can be grouped according to their nature. They can be divided into combat mission requirements, reliability requirements, etc. After grouping, these itemized requirements will be preceded by corresponding ID numbers. In order to facilitate management and subsequent stakeholders to create other requirements, appropriate prefixes can be added to them.

[0099] Functional user requirements refinement can be achieved by creating a use case element in the use case diagram (UC) to capture the mission scenario. A use case is a service provided by the flight control system through action execution when viewed from the outside of the flight control system, that is, from the perspective of the aircraft as a whole. A use case contains a series of actions for the flight control system to interact with external objects. Compared with user requirements, use cases can tell the expectations of the flight control system more accurately.

[0100] In order to solve the problem of reliability and system design being two separate things, according to the modeling process, after completing the task requirement modeling, it is analyzed and some system requirement analysis is converted into reliability requirements, thereby introducing reliability analysis into the forward design process.

[0101] The need can be described as "<Who> wants <what> to be done <when> <through what> (to what extent)". In this case (to what extent) it is usually described as "XXX does not fail" etc.

[0102] Reliability requirements are also described in a clear, unambiguous, and testable manner, and are statements of necessary or desired system characteristics, features, personalization, or usage.

[0103] The sources for obtaining and analyzing reliability requirements are as follows:

[0104] Derivation of task requirements: Based on the requirements during the task, screen and derive the requirements that meet the description of "XXX does not fail" as reliability requirements.

[0105] Failure use case reasoning: Perform failure analysis on task scenario use cases to infer failure points, then propose failure use cases, and finally convert them into reliability requirements based on the failure use cases.

[0106] Functional failure reasoning: Based on the functional model in the system design, reliability experts conduct functional failure analysis and propose fault prevention plans and control measures when the function fails. They then convert them into reliability requirements to guide system design.

[0107] Iterate reliability requirements: Repeat failure use case reasoning and functional failure reasoning until all involved task profiles are analyzed and reliability requirements are captured and modeled.

[0108] After completing the requirements analysis of the manned lunar spacecraft system, the use case model is used to describe the implementation scenario of its requirements. The use case analysis model can clearly understand how the system is used and how it interacts with stakeholders, and further analyze its functions.

[0109] After describing the execution scenario and functions of the task through the use case model, the reliability expert conducts the use case failure analysis to supplement the reliability requirements and provide support for the subsequent functional analysis. The reliability task profile of the manned lunar spacecraft is described through the use case model extension. Then the "extensionpoints" is used to describe the key points of its failure, and then the use cases that will be executed when the extension point occurs are associated through the "extend" association relationship, indicating that the task will fail due to a failure in a link in the system during the process, and the corresponding use case must be executed to avoid it from happening. As shown, in the launch use case, once the "launch vehicle fails", the escape and rescue use case must be executed to avoid the death of astronauts on the manned spacecraft. At the same time, in the escape and rescue use case process, a reliability requirement for the manned spacecraft will be introduced. This requirement requires it to carry an escape tower subsystem to complete the escape and rescue process. Therefore, in this step, the reliability requirement needs to be iterated and incorporated into the task requirement analysis.

[0110] After completing the task use case scenario analysis, the task process is described in detail by expanding the use case and using the behavioral model. When the requirements analysis results in the use case and sub-use case, the sub-functions are expanded and converted based on the specific product principle, and the initial function is expanded into the functional analysis. In this step, the task process is described based on the state element, and the SysML state machine diagram is used for detailed process analysis. The stages in the task process are enumerated through the SysML state machine diagram, and the transition elements in SysML are used to characterize the state transformation to ensure a complete description of the task execution process.

[0111] The process modeling of the flight mission characterizes the execution stages and processes of the flight mission, and describes the entire flight process, such as from launch to orbiting the Earth, Earth-Moon transfer, near-Moon braking, orbiting the Moon, lunar descent, lunar landing, lunar ascent and rendezvous and docking, lunar orbit transfer, and finally returning to Earth.

[0112] After the state machine diagram of the task is completed, it sorts out the process of normal execution of the task, and does not consider the state of the task being in a faulty state due to task failure. Therefore, task failure modeling is performed based on the task execution process. By analyzing each state stage of the state machine diagram of the task implementation process, the possible fault states are listed and analyzed one by one, so as to obtain the fault state, and finally obtain the fault state machine diagram model of the task process stage.

[0113] Based on the requirements analysis and functional analysis models, the architecture of the manned lunar mission can be constructed. For example, BDD (module definition diagram) can be used to model the mission architecture and describe the component architecture in the manned lunar mission.

[0114] After completing the above modeling process, it is necessary to trace the requirements at the task level. By constructing a traceability matrix, the satisfied and unsatisfied requirements can be expressed in matrix form, so as to clarify whether there are any omissions in the design process, check for omissions and fill in the gaps, and complete the overall design to ensure that all requirements are met.

[0115] S104: Decompose the supplemented task requirement model to obtain the system requirements of the engineering product and form a system requirement model, perform failure analysis on the behavior models of each system of the engineering product, and supplement the system reliability requirements for coping with system failures with respect to the system requirement model, and design the engineering product according to the supplemented system requirement model.

[0116] After combining the general quality characteristic analysis in the business layer of the engineering design as described above, the server can carry out the general quality characteristic analysis in the design process of the system layer.

[0117] Specifically, in one or more embodiments of the present specification, the server may decompose the task requirement model to obtain the system function model and system function indicators of the engineering product, convert the system function model and system function indicators of the engineering product into the system requirements of the engineering product, and construct the system requirement model. The behavioral model is used to describe the behavioral logic and state transition of each system of the engineering product during the task execution process, and the behavioral model of each system is subjected to failure analysis to obtain the fault behavior and fault state of each system during the task execution process, thereby forming the system failure mode of each system during the task execution process. A system failure plan is proposed for the system failure mode, the system failure mode is analyzed, and the task reliability requirements for coping with system failure behavior are supplemented.

[0118] Among them, the server can form the system-level demand input with the functions and indicators of the manned lunar spacecraft obtained by the task-level analysis, thus starting the system-level forward design process. According to the system function model and indicators decomposed at the task level, it is transformed into the system requirements of the manned lunar spacecraft, and the requirements of the general quality characteristics are initially refined. The functional requirements of the manned lunar spacecraft and the requirements of the general quality characteristics are associated and traced by applying the association matrix method.

[0119] Then, the behavioral model is used to describe the behavioral logic and state transition of the manned lunar spacecraft during the mission. Based on this behavioral model, the behavioral model of the manned lunar spacecraft during the mission is analyzed for failure, and the fault behavior and fault state during the mission are generated, thereby forming the failure mode of the spacecraft system. Based on this, a fault plan is proposed and FMEA is used to analyze the fault. When the behavioral fault analysis is completed, the analysis content is refined and the reliability requirements are supplemented.

[0120] Finally, the spacecraft architecture is modeled. Based on the above analysis, the spacecraft architecture model is formed while ensuring that the mission objectives are achieved. Based on the reliability requirements obtained from the previous analysis, necessary redundant subsystems are added to the spacecraft architecture to ensure that the mission can be completed reliably and efficiently.

[0121] At this point, the analysis of the mission level and system level has been completed, and we have a clear fault function model and fault propagation path. Based on these analyses, a fault tree model for manned lunar landing is formed.

[0122] The server can sort out the modeling and analysis process at the system level and subsystem level, and build relevant FMEA models to form a general quality characteristic model library for manned lunar spacecraft. The model library is divided into two levels: system level and subsystem level, mainly including: failure causes, failure modes and failure effects. After completing the sorting and construction of the model library, the model can be reused in subsequent model development tasks, and the model library can also be enriched as a knowledge reserve.

[0123] Figure 7 This is a schematic diagram of an FMEA framework model in this manual. Through structured expression, the failure cause and failure impact of the failure mode are used as components of FMEA. By setting attribute values ​​in the failure cause, failure mode and failure impact, the key information in FMEA is described.

[0124] For example, after completing the modeling work at the mission level, the system level is analyzed, and the requirements for the spacecraft system are refined based on the model experience and mission requirements. At the same time, some reliability requirements proposed at the mission level that will affect the spacecraft architecture are also organized and sorted out in this step. The mission requirement model generated after completing the mission level analysis is used as input to output the requirements of the manned lunar spacecraft system.

[0125] Then, according to the flight mission process, the spacecraft state modeling is carried out. The state of the spacecraft in different mission stages is characterized by the description of the state machine diagram.

[0126] After completing the state machine diagram modeling of the spacecraft during the mission, analyze the possible faults of the spacecraft during the mission, characterize the fault state through the model, and propose corresponding fault plans. Combined with the mission process, after analyzing the system completion state, it is necessary to expand the functions and functional logic of the system in detail.

[0127] After completing the functional analysis of the system, based on the functional characteristics, it is clear which subsystems perform the functions in the system, thus forming the system's composition architecture. Based on the demand analysis and spacecraft status analysis, the manned lunar spacecraft architecture is constructed. The BDD diagram can be used to model the mission architecture and describe the components of the manned lunar spacecraft.

[0128] During the entire mission analysis process, based on the analysis of use cases, mission phases, and spacecraft state machine modeling analysis, some reliability design requirements will be drawn to ensure that the system can complete the mission more reliably or ensure the safety of astronauts during the mission. Therefore, in the system architecture design, redundant architecture design will be introduced to meet the completion of functions or the safety of astronauts. With the goal of ensuring personnel safety and completing missions, based on the proposed reliability requirements, redundant components of the system are added or the system design is improved to form a new system composition architecture.

[0129] In the process of system design and modeling of manned lunar spacecraft, reliability analysis and modeling work is integrated. The reliability content needs to be organized in the form of FMEA, the analysis work is expressed in the form of models, and presented in the form of FMEA tables. Using the FMEA framework in the FMEA library as a template, the FMEA architecture model for a certain fault condition is constructed by redefinition, and the model elements in the system design process are used as the fault state, fault path and fault background in the FMEA model framework.

[0130] After completing the above modeling process, it is necessary to trace the system-level requirements. By constructing a traceability matrix, the satisfied and unsatisfied requirements can be expressed in matrix form, so that it can be clear whether there are any omissions in the design process, and the omissions can be checked and filled to complete the overall design so that all requirements are met.

[0131] based on Figure 1 The engineering design method based on general quality characteristic analysis shown in the figure first abstracts and associates the task profile and failure mode and effect analysis of realizing business requirements to obtain an abstract model of engineering design under failure mode and effect analysis, then determines the stakeholders of engineering design at the business layer, and determines the task requirements corresponding to the stakeholder requirements at the business layer, then performs failure mode and effect analysis at the business layer to supplement the task reliability requirements at the business layer, and finally performs failure mode and effect analysis at the system layer to supplement the system reliability requirements at the system layer.

[0132] The present invention integrates the universal quality characteristic analysis into the entire engineering design process, so that the engineering product can be supplemented for reliability at both the business layer and the system layer, thereby improving the overall integration of the engineering product design with the universal quality characteristic analysis, thereby improving the overall consistency and reliability of the engineering product design.

[0133] When applying the engineering design method based on general quality characteristic analysis provided in this manual, it is not necessary to Figure 1 The steps are executed in the order shown. The specific execution order of the steps can be determined according to needs, and this manual does not limit this.

[0134] The above is an engineering design method based on general quality characteristic analysis provided by one or more embodiments of this specification. Based on the same idea, this specification also provides a corresponding engineering design device based on general quality characteristic analysis, such as Figure 8 shown.

[0135] Figure 8 A schematic diagram of an engineering design device based on general quality characteristic analysis provided for this specification includes:

[0136] Abstraction module 201 is used to construct a domain model corresponding to the engineering product based on the business requirements of the engineering design, abstract and associate the task profiles that realize the business requirements with the corresponding failure mode and impact analysis, and obtain an abstract model of the engineering design under the failure mode and impact analysis;

[0137] The task requirement determination module 202 is used to determine the stakeholders of the engineering design at the business layer based on the domain model corresponding to the engineering product, and determine the task requirements corresponding to the requirements of the stakeholders at the business layer; and to model the task requirements according to the execution process of each task to obtain a task requirement model;

[0138] The task analysis module 203 is used to perform failure analysis on the execution process of the task requirement model based on the abstract model of engineering design under the failure mode and effect analysis, and to supplement the task reliability requirements for coping with task failures with respect to the task requirement model;

[0139] The system analysis module 204 is used to decompose the supplemented task requirement model to obtain the system requirements of the engineering product and form a system requirement model, perform failure analysis on the behavior models of each system of the engineering product, and supplement the system reliability requirements for coping with system failures with respect to the system requirement model, and design the engineering product according to the supplemented system requirement model.

[0140] Optionally, the abstract module 201 defines a task construction type representing a task profile, the construction type describes a system at a certain position at a certain time and state, defines context attributes of systems, subsystems and components, uses the context attributes as attributes in the task construction type, the context attributes represent the background context in which a fault occurs, defines fault propagation path attributes for chain propagation of faults from bottom-level components to target levels, uses the fault propagation path attributes as attributes in the task construction type, defines relevant attributes for associating the functions, activities and states of components with the task construction type, uses the relevant attributes as attributes in the task construction type, defines a failure mode and effects analysis abstract class, defines a risk factor in the failure mode and effects analysis abstract class, and defines abstract failure modes, abstract failure causes and abstract failure effects as components in the failure mode and effects analysis abstract class.

[0141] Optionally, the business layer analysis module 203 analyzes the requirements of each task, constructs a use case model according to each task execution process, and analyzes each task scenario to obtain a task requirement model.

[0142] Optionally, the task analysis module 203 performs failure use case analysis on each task execution process, supplements the task reliability requirements for dealing with task failure use cases with respect to the task requirement model, expands the use case model using a behavior model, performs failure analysis on the behavior model in each task execution process, obtains the fault behavior and fault status in each task execution process, forms a task failure mode in each task execution process, proposes a task failure plan for the task failure mode, analyzes the task failure mode based on the abstract model of engineering design under failure mode and effect analysis, and supplements the task reliability requirements for dealing with task failure behavior with respect to the task requirement model.

[0143] Optionally, the system analysis module 204 decomposes the supplemented task requirement model to obtain a system function model and system function indicators of the engineering product, converts the system function model and system function indicators of the engineering product into system requirements of the engineering product, and constructs a system requirement model.

[0144] Optionally, the system analysis module 204 uses a behavioral model to describe the behavioral logic and state transitions of each system of the engineering product during the execution of each task, and performs failure analysis on the behavioral model of each system to obtain the fault behavior and fault state of each system during the execution of each task, form a system failure mode of each system during the execution of each task, analyze the system failure mode, propose a system failure plan for the system failure mode, and supplement the system reliability requirements for coping with system failures with respect to the system requirement model.

[0145] Optionally, the engineering product is a manned lunar spacecraft, and a domain model corresponding to the manned lunar spacecraft is constructed using a system modeling language.

[0146] For the specific definition of the engineering design device based on the general quality characteristic analysis, please refer to the definition of the engineering design method based on the general quality characteristic analysis in the above text, which will not be repeated here. Each module in the above-mentioned engineering design device based on the general quality characteristic analysis can be implemented in whole or in part by software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0147] This specification also provides a computer-readable storage medium, which stores a computer program, which can be used to execute the above Figure 1 Provides an engineering design method based on general quality characteristics analysis.

[0148] This manual also provides Fig. 9 The structural diagram of the computer device shown in FIG. Fig. 9As mentioned above, at the hardware level, the computer device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other hardware required for the business. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to achieve the above Figure 1 Provides an engineering design method based on general quality characteristics analysis.

[0149] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0150] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. An engineering design method based on general quality characteristic analysis, characterized in that: include: Based on the business requirements of the engineering design, a domain model corresponding to the engineering product is constructed, and the task profile for realizing the business requirements and its corresponding failure mode and impact analysis are abstracted and associated to obtain an abstract model of the engineering design under the failure mode and impact analysis; the engineering product is a manned lunar spacecraft, and a domain model corresponding to the manned lunar spacecraft is constructed using a system modeling language; Based on the domain model corresponding to the engineering product, determine the stakeholders of engineering design at the business level, and determine the task requirements corresponding to the needs of each stakeholder at the business level; Model each task requirement according to the execution process of each task to obtain a task requirement model; Based on the abstract model of engineering design under failure mode and effect analysis, failure analysis is performed on the execution process of the task requirement model, and task reliability requirements for coping with task failures are supplemented to the task requirement model; Decompose the supplemented task requirement model to obtain the system requirements of the engineering product and form a system requirement model, perform failure analysis on the behavior model of each system of the engineering product, and supplement the system reliability requirements for coping with system failures based on the system requirement model, and design the engineering product based on the supplemented system requirement model; The task profiles for realizing business requirements and their corresponding failure modes and effects analysis are abstracted and associated to obtain an abstract model of engineering design under failure modes and effects analysis, specifically including: defining a task construction type representing a task profile, the construction type describing a system at a certain position at a certain time and state; Define context attributes of systems, subsystems and components, and use the context attributes as attributes in the task construction type, wherein the context attributes represent the background context in which the fault occurs; Define the fault propagation path attributes for the fault to be chained from the bottom component to the target level, and use the fault propagation path attributes as attributes in the task construction type; Define the relevant attributes for associating the functions, activities and states of the components to the task construction type, and use the relevant attributes as attributes in the task construction type; Define a failure mode and effects analysis abstract class, define a risk factor in the failure mode and effects analysis abstract class, and define abstract failure modes, abstract failure causes, and abstract failure effects as components in the failure mode and effects analysis abstract class.

2. The engineering design method based on general quality characteristic analysis according to claim 1, characterized in that: The task requirement model is obtained by modeling each task requirement according to the execution process of each task, specifically including: By analyzing the requirements of each task, a use case model is constructed according to the execution process of each task, and the task requirement model is obtained by analyzing each task scenario.

3. The engineering design method based on general quality characteristic analysis according to claim 2, characterized in that: The abstract model of engineering design based on the failure mode and effect analysis performs failure analysis on the execution process of the task requirement model, and supplements the task reliability requirements for coping with task failures with respect to the task requirement model, specifically including: Conduct failure case analysis on each task execution process, and supplement the task reliability requirements for task failure cases based on the task requirement model; Use the behavior model to expand the use case model, perform failure analysis on the behavior model during the execution of each task, obtain the fault behavior and fault status during the execution of each task, and form the task failure mode during the execution of each task; A mission failure plan is proposed for the mission failure mode, and the mission failure mode is analyzed based on the abstract model of engineering design under failure mode and effect analysis. The mission reliability requirements for dealing with mission failure behaviors are supplemented for the mission requirement model.

4. The engineering design method based on general quality characteristic analysis according to claim 1, characterized in that: The decomposed and supplemented task requirement model obtains the system requirements of the engineering product and forms a system requirement model, specifically including: Decompose the supplemented task requirement model to obtain the system function model and system function indicators of the engineering product; Convert the system function model and system function indicators of engineering products into system requirements of engineering products and build a system requirement model.

5. The engineering design method based on general quality characteristic analysis according to claim 1, characterized in that: The failure analysis of the behavior models of each system of the engineering product is performed, and the system reliability requirements for coping with system failures are supplemented according to the system requirement model, specifically including: Use behavioral models to describe the behavioral logic and state transition of each system of the engineering product during the execution of each task, and perform failure analysis on the behavioral model of each system to obtain the fault behavior and fault state of each system during the execution of each task, and form the system failure mode of each system during the execution of each task; Analyze the system failure mode, propose system failure plans for the system failure mode, and supplement the system reliability requirements for coping with system failures based on the system requirement model.

6. An engineering design device based on general quality characteristic analysis, characterized in that: include: An abstract module is used to build a domain model corresponding to the engineering product based on the business requirements of the engineering design, define a task construction type representing a task profile, and the construction type describes that the system is in a certain position at a certain time and state; define context attributes of the system, subsystem, and component, and use the context attributes as attributes in the task construction type, and the context attributes represent the background context of the failure; Define the fault propagation path attributes for the chain propagation of faults from the bottom component to the target level, and use the fault propagation path attributes as attributes in the task construction type; define the related attributes for associating the functions, activities and states of the components to the task construction type, and use the related attributes as attributes in the task construction type; Define a failure mode and effect analysis abstract class, define a risk factor in the failure mode and effect analysis abstract class, and define an abstract failure mode, an abstract failure cause, and an abstract failure effect as components in the failure mode and effect analysis abstract class; An abstract model of engineering design under failure mode and effect analysis is obtained; the engineering product is a manned lunar spacecraft, and the domain model corresponding to the manned lunar spacecraft is constructed using a system modeling language; The task requirement determination module is used to determine the stakeholders of engineering design at the business level based on the domain model corresponding to the engineering product, and to determine the task requirements corresponding to the requirements of each stakeholder at the business level; Model each task requirement according to the execution process of each task to obtain a task requirement model; The task analysis module is used to perform failure analysis on the execution process of the task requirement model based on the abstract model of engineering design under the failure mode and effect analysis, and to supplement the task reliability requirements for coping with task failures with respect to the task requirement model; The system analysis module is used to decompose the supplemented task requirement model to obtain the system requirements of the engineering product and form a system requirement model, perform failure analysis on the behavioral models of each system of the engineering product, supplement the system reliability requirements for coping with system failures based on the system requirement model, and design the engineering product based on the supplemented system requirement model.

7. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

8. A computer device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method described in any one of claims 1 to 5 is implemented.

Images