Fault transmission analysis method based on functional physical mapping model

Abstract

The invention provides a fault transmission analysis method based on a functional physical mapping model, and belongs to the technical field of complex system safety analysis, and the method comprises the following steps: S1, carrying out the preparation before modeling; s2, creating a functional physical mapping model of the system; and S3, carrying out security analysis on the functional physical mapping model. By adopting the fault transmission analysis method based on the functional physical mapping model, the problem of repeated modeling work caused by separation of functional modeling and physical modeling is solved, a method for associating a system function with a physical architecture is provided, the efficiency of safety analysis work based on the model is improved, and the method is suitable for popularization and application. And the integrity and accuracy of hardware fault identification are ensured.

Description

Technical Field

[0001] This invention relates to the field of security analysis technology for complex systems, and in particular to a fault propagation analysis method based on a functional physical mapping model. Background Technology

[0002] With the rapid advancement of technology, modern equipment is making great strides towards intelligence. This trend has led to a geometric increase in the complexity of equipment systems, with their internal structures, operating mechanisms, and interactions between components becoming increasingly intricate. Traditional document-based design and analysis methods are gradually revealing their limitations when faced with such complex and highly integrated systems, making it increasingly difficult to meet the stringent security requirements of these products.

[0003] In recent years, Model-Based Systems Engineering (MBSE) has emerged as a leading approach in the forward design and development of complex systems, gaining widespread consensus. Among its methods, the System Modeling Language (SysML) plays a crucial role, enabling formal modeling of systems and highly abstracting their physical laws, functional characteristics, and behavioral logic into quantifiable and analyzable model elements, thus providing strong support for system safety analysis. Mainstream MBSE methods model and analyze systems from four perspectives: requirements, function, logic, and physical. However, existing MBSE tools and methods, including SysML, Simulink, and Rhapsody, face the challenge of a disconnect between functional and physical mapping. Functional failure modes are difficult to automatically and accurately map to specific components in the model; hardware failure mode libraries are isolated from functional models; and control logic failures are difficult to trace back to the failure causes of mechanical structures.

[0004] These problems severely hinder in-depth system security analysis. Therefore, in order to effectively bridge the functional and physical dimensions of the system and provide a solid guarantee for hardware functional failure analysis, it is urgent to explore a scientific and reasonable method for constructing functional-physical mapping relationships. Summary of the Invention

[0005] The purpose of this invention is to provide a fault propagation analysis method based on a functional physical mapping model, which solves the problem of repetitive modeling work caused by the separation of functional modeling and physical modeling. It provides a method for associating system functions with physical architecture, which helps to improve the efficiency of model-based security analysis and ensures the completeness and accuracy of hardware fault identification.

[0006] To achieve the above objectives, this invention provides a fault propagation analysis method based on a functional physical mapping model, comprising the following steps:

[0007] S1. Preparatory work before modeling, including sorting out the system functional hierarchy, sorting out the internal flow relationships of the system, and analyzing the failure mode list of components in the system functions;

[0008] S2. Create a functional physical mapping model for the system, import the flow relationships between physical components of the system and the fault information within the physical modules into the functional physical mapping model, and abstract the failure logic relationships of the system functions.

[0009] S3. Perform security analysis on the functional physical mapping model. Define functional modules and select appropriate functional ports, and generate corresponding fault propagation paths with the failure of functional ports as the consequence. Based on the defined fault propagation model, automatically generate system fault logic relationships. Based on the functional physical mapping relationships within the constructed functional physical mapping model, automatically analyze the output ports of the functions, and analyze the possible failure modes that lead to functional abnormalities and all fault propagation paths.

[0010] Preferably, the system function hierarchy is initially decomposed into indivisible units based on the system-level and subsystem-level hierarchical relationships of the system. That is, if the division is continued, a hardware object will participate in multiple functions at the same time.

[0011] Preferably, the flow relationships within the system are analyzed using formal modeling tools, with behavioral diagrams and time sequence diagrams used to clarify the physical components, transmitted data, and causal relationships between information flow, material flow, and energy flow; the transmission and control relationships are abstracted using information flow, material flow, and energy flow to determine functional operations, timing, and system composition; similar types of flows are transmitted between modules, and flow type conversion is implemented within modules.

[0012] Preferably, the failure mode list of components in the analysis system function is divided into two categories: component failure modes and component output port failure modes. For component failure modes, it is necessary to analyze the impact of each failure mode on the component output port, and the analysis results are further used to supplement the component output port failure modes. The logical relationship between component failure modes and component output port failure modes is many-to-many, and some failure modes of component output ports are not directly caused by the state of the component itself.

[0013] Preferably, the functional physical mapping model includes the functional variable types and fault states of each variable type under the normal operating mode of the system. The fault information imported into the functional physical mapping model includes local fault logic and system fault logic. The local fault logic is defined by manual analysis, and the system fault logic is derived from the model.

[0014] Preferably, the flow relationships between the physical components of the system are modeled, and the system entities are modeled using block modules. Different types of input and output ports are defined on the block modules, and the energy, matter, and information interaction relationships between the modules are abstracted by the directed flow between the ports. The block modules can be opened as white boxes according to actual needs. In this case, the module itself does not perform internal logical relationship modeling, but is associated through input and output ports, and the internal fault logic is modeled by the internal indivisible modules. Modules with built-in modules are called "white box blocks", and those without built-in modules are called "black box blocks". The number and distribution of ports of the white box block are determined by the port information of the built-in black box blocks.

[0015] Preferably, the fault information propagation relationship modeling within the physical module ensures that the module's own variable types and output port variable types meet the fault logic relationship mapping requirements, and that the output port of any module has the same type as the input port of the associated module. Failure status can be transmitted through flow relationships without needing to define variable types for the module's input ports. Specifically, this includes the following steps:

[0016] S21. Define the variable types of the block module itself and its output ports in the model, and set failure modes for all variables according to the failure mode list.

[0017] S22. Within the module, logic gates are used to establish the correlation between failure modes of various variable types, thereby achieving fault logic modeling within the module.

[0018] Preferably, the fault information propagation relationship model is multi-layered and nested, with the failure of lower-level products propagating to the next higher level through the output interface shared with higher-level products.

[0019] Preferably, the functional port definition is represented as a many-to-many permutation and combination relationship between each sub-function and physical component. The same component may correspond to several different functions. By defining functional interfaces, it can be ensured that all components appear only once in the physical configuration of the system.

[0020] Preferably, the safety analysis method of the functional physical mapping model automatically generates system fault logic relationships through the transitive relationships contained in the model itself, which helps to identify severe fault modes and combinations of the system. The fault logic relationships include the impact of a single fault, the impact of multiple fault combinations, and the impact of fault timing combinations. The impact of a single fault should output a functional FMEA list, the impact of multiple fault combinations should derive a fault tree, and the impact of fault timing combinations should use a fault propagation model to obtain the relevant fault sequence.

[0021] Therefore, the present invention employs the above-mentioned fault propagation analysis method based on the functional physical mapping model, and the technical effects are as follows:

[0022] 1. The functional interface concept designed in this invention realizes the association between physical architecture and functional logic by selecting a unique functional interface for a set of physical interfaces (energy, information and matter) of a functional unit, and supports the location of failure modes of physical components from system sub-function anomalies.

[0023] 2. The concepts of functional units and physical units introduced in this invention can support further analysis of the underlying functions in the system functional architecture, while controlling the granularity of the physical modeling module, which helps to guide the efficient development of modeling and analysis work.

[0024] 3. The functional model construction method designed in this invention can clearly and accurately express the relationship between system functions and system behavioral logic, avoid the repeated modeling of the same elements in the functional model and logical model, and reduce the workload of modeling.

[0025] 4. By combining the features of physical models, functional models, and internal logic models, this invention ensures the consistency between the model and the actual working characteristics of the system, thus guaranteeing the accuracy and completeness of model-based security analysis. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the modeling and analysis process of the functional physical mapping model in an example of the present invention;

[0027] Figure 2 This is a schematic diagram illustrating the flow relationship between functions and corresponding physical modules in one embodiment;

[0028] Figure 3 This is a schematic diagram of an internal fault propagation model for a physical unit in an instance.

[0029] Figure 4 A schematic diagram of the function-physical mapping model in an instance;

[0030] Figure 5 This is a schematic diagram of the system functional model in an example;

[0031] Figure 6 A schematic diagram of the fault propagation path generated from feedback signal loss analysis in an example;

[0032] Figure 7 A schematic diagram of the fault propagation path generated from feedback signal distortion analysis in an example;

[0033] Figure 8 This is a schematic diagram of the fault propagation path generated by feedback signal drift analysis in an example. Detailed Implementation

[0034] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0035] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0036] Example 1

[0037] like Figure 1 As shown, this invention provides a fault propagation analysis method based on a functional physical mapping model, specifically including the following steps:

[0038] S1. Analyze the functional hierarchy of the system and construct a functional tree structure to clarify the functional configuration of the system. Define the underlying sub-functions as blocks. At the output port of the "functional block", determine the corresponding functional failure state, such as the functional failure mode of the component, based on the system's fault mode data and the output of the physical blocks representing the system's physical components related to the "functional block".

[0039] S11. Determine the main functions of the system. Based on the different systems within the equipment, clarify the corresponding top-level objectives of the system, and then determine the top-level functions.

[0040] S12. The first-level functions are decomposed step by step, so that the functions are decomposed into the main system of the equipment.

[0041] S13. Obtain the three-level functional tree structure corresponding to "Complete Machine - System - Subsystem". The functional decomposition level is to break down the function into functional units of a specific system, without refining it to specific functional modules at the component / part level. This approach ensures that the smallest functional units in the functional architecture tree structure are independent of each other, avoiding overlap and intersection. Given that components or parts may have "one-to-many, many-to-one, or many-to-many" relationships between physical units and functions, this step should not further subdivide into specific functional modules.

[0042] S2. Using flow relationships, identify physical units related to the target function, construct a function-related physical architecture, and clarify the functional transmission relationships between physical units. Specifically, physical units are represented by modules (blocks), and the functional transmission relationships between modules (blocks) are mapped using energy flow, information flow, and material flow. Based on the functional tree structure obtained in step S1, the work of sorting out the equipment physical architecture and functional relationships is carried out.

[0043] S21. Determine the physical unit corresponding to the lowest level sub-function (i.e., functional unit) of the functional tree structure, and decompose the functional unit to clarify the specific functional module.

[0044] S22. Determine the flow relationships between the physical units involved, thereby clarifying the port information of the corresponding physical architecture and defining the port type, flow direction, and flow information. Specifically:

[0045] S221. Analyze the information flow of each functional unit's implementation process to basically determine the equipment subsystems, accessories, components, or parts involved in that functional unit. The information flow needs to clearly define the direction of the flow, the corresponding ports, and the specific content transmitted. The process and control logic of the function implementation can be analyzed with the help of MBSE activity diagrams and sequence diagrams.

[0046] S222. Analyze the material and energy flows in the implementation process of each functional unit, and further supplement the physical units involved in the functional unit.

[0047] S223. Based on the identified relationships among energy flow, information flow, and material flow, complete the interface modeling of the physical units corresponding to the functional units. On this basis, implement the interface modeling of subsystems and the system as a whole. It should be noted that these three flow relationships are not completely independent; different types of flow transmission relationships exist. For example, energy flows such as electrical energy can "influence" information flows such as control signals, and information flows such as control signals can "influence" material flows such as medium flow rates. When the input flow in an "influence" relationship is interrupted, the output flow in the "influence" relationship will also be interrupted.

[0048] In one specific embodiment, the flow relationship between the guide vane control function and the corresponding physical module is as follows: Figure 2 As shown in the diagram, the functional transfer relationships between modules are represented using material flow, energy flow, and information flow. By analyzing the direction and content of the flows, the temporal relationships of the module behaviors can be determined. Furthermore, during the analysis of flow relationships, it can be determined whether it is necessary to further decompose the modules downwards, i.e., open them up as "white boxes," to ensure that the flow relationships between module blocks can meet the needs of subsequent fault propagation path analysis.

[0049] S3. After determining the corresponding module block information and the flow relationships between modules, the port information of each module block can be determined. The direction and variable type of the ports are defined and constructed as "port variables." The ports connected by the flow relationships between modules must belong to the same type. For example, if the upper-level module outputs an information flow, the output port of the information flow and the input port flowing into the module must have the same port variable type; otherwise, they cannot be associated. For cases where the flow type changes, the association of different port variable types can be completed subsequently within the module.

[0050] The port variable type of the guide vane actuator is as follows: Figure 2As shown, hydraulic oil flows into its input port, which corresponds to the material variable type, and feedback signals flow out of its output port, which corresponds to the information variable type, thus realizing the association between material-type port variables and information-type port variables.

[0051] S4. For all physical units involved in the functional unit, logical modeling of the module's internal structure needs to be carried out one by one. The specific steps are as follows:

[0052] S41. Compile a list of fault modes: Determine the fault modes of each module block and its output ports, and clarify the causal logic between the module's own fault modes and the port fault modes; compile a list of all fault modes corresponding to the functional units. Note that the fault modes of each module can be divided into two types according to their attribution: self-fault modes and output port fault modes; when determining the fault modes of a module itself, it is necessary to clarify which output ports may be affected by this fault mode, providing strong support for the subsequent modeling of fault propagation relationships within the module.

[0053] S42. Constructing the internal fault propagation relationship of the module: Import the obtained fault mode list into the constructed model; use logical symbols such as "AND gate", "OR gate", and "decision gate" to associate the fault modes of the module itself with the fault modes of each output port of the module, thereby forming the internal fault propagation relationship of the module; through the modeling method of "combining the module itself with the output port", the physical and performance logical relationships of the module can be effectively associated, and the fault propagation relationship modeling within the module can be completed.

[0054] After completing the physical architecture construction of each functional unit, clarifying the flow relationship between modules and the fault logic relationship within modules, select a certain output port in the physical architecture and establish it as the corresponding functional port of that functional unit.

[0055] The internal fault propagation model of a servo valve is as follows: Figure 3As shown, by modeling the internal fault logic relationships of a module, performance indicators such as hydraulic oil flow rate and return pressure can be correlated with functional failure states. When determining the internal logic relationships of a module, in addition to the failure modes of the module itself being propagated to its output ports, the failure modes of the module's input ports are also propagated to its output ports. Therefore, when modeling the internal logic relationships of a module, both the failure modes of the input ports and the failure modes of the module itself need to be considered as the bottom-level states of the internal tree structure. If certain input port failure modes trigger the module's own failure modes, the propagation paths of these input failure modes should be consistent with the corresponding failure modes of the module itself. Furthermore, in modeling the internal fault propagation relationships of a module, it is not required that all bottom-level failure modes be associated with output ports. Modeling should strictly follow the actual fault causal relationships. If some input failure modes and output failure modes have no direct causal relationship, it indicates that the fault propagation relationship has been interrupted in the previous module.

[0056] When determining the failure mode list for a module, the failure modes of the module itself and the failure modes of the input ports of the previous level should be determined first, and then the impact on the module's output ports should be analyzed to ensure the completeness of the failure mode categories for the output ports.

[0057] Table 1 shows an example of a failure mode list for a guide vane control system. The failure mode information used to construct the failure propagation model includes, but is not limited to, the failure object category, the failure mode, and the resulting output port failure mode. For failure modes categorized as the module itself, the corresponding output port failure modes need to be clearly defined to support subsequent modeling of failure logic relationships.

[0058] Table 1

[0059]

[0060]

[0061]

[0062]

[0063]

[0064]

[0065]

[0066] S5. Based on the completion of the preliminary functional tree structure construction and physical architecture sorting, carry out the following steps to model the functional flow relationships, construct the logical relationships between functional units and functions at all levels, and determine the functional ports, as detailed below:

[0067] S51. Based on the flow relationships obtained in step S2, perform flow relationship modeling related to functions, and analyze and determine the functional ports.

[0068] S52. Based on the functional tree structure defined in S1, construct the logical relationships between functional units and secondary functions in a modular manner. The modules introduced here to describe the logical relationships between functional units and secondary functions differ from indivisible physical units; their function is to map the hierarchical relationships between functions. The input ports of this module originate from the corresponding physical units selected by different functional units, and the output ports are the functional ports corresponding to the secondary functions. Following the above method of constructing the logical relationships between functional units and secondary functions, the logical relationships between secondary functions and primary functions can be further formed, thus fully presenting the logical connections between functions at each level in the functional tree structure.

[0069] Functional ports are a special type of port, distinct from ports that transmit physical flows (information, energy, matter). Within each set of physical units corresponding to a functional unit, only one physical unit has a corresponding functional port. This port is used to transmit and interact with function-related information between functional levels, enabling the association and collaboration between functions. The functional tree structure only clarifies the hierarchical and inclusion relationships; the specific logical relationships need further determination. Logical relationships within functional modules can take many forms. For example, all functional units must be implemented to ensure the implementation of the next higher-level function; or the implementation of certain functions within a functional unit can ensure the implementation of the previous function. In constructing the logical relationships between functional units and their respective levels, these logical relationships must be accurately determined based on the actual situation to ensure that the functional model accurately reflects the system's functional operation mechanism.

[0070] Once the physical flow relationships between modules and the fault propagation relationships within modules are clear, fault propagation path analysis can be performed with the output port of a specific module as the top event, automatically generating the corresponding fault tree. The hardware fault source of any output port's specific failure mode and the possible failure modes of that source can be obtained. To support functional failure analysis, suitable modules need to be selected from the established system model, and corresponding functional output ports need to be defined, thus supporting fault trees with the failure of a single specific function as the top event. A batch of functional ports can be defined in the above manner. Then, a module representing system-level functions is established, and logical modeling of each functional port is performed within the module, enabling the modeling of the flow relationships between the system's functional modules and system functions.

[0071] In one specific embodiment, a schematic diagram of the functional and physical mapping model of the guide vane control system is shown below. Figure 4As shown in the diagram, the model distinguishes between different port types: blue corresponds to signal ports, used to transmit signal flow, for example, the output port and input port of the speed pulse signal transmitted from the low-pressure speed sensor to the electronic controller are blue; orange corresponds to material ports, used to transmit material flow, for example, the output port and input port of the hydraulic oil transmitted from the guide vane actuator of the servo valve are orange; green corresponds to energy ports, used to transmit energy flow, for example, the output port and input port of the power supply transmitting electrical energy to the electronic controller are green.

[0072] The selection of functional ports should be reasonable. Appropriate outputs should be chosen from the physical flow ports as functional output ports to ensure that the obtained security analysis results reflect reality. By defining functional ports and functional modules, the output analysis results can be clearly presented: the first and second levels represent specific functional failure states, and each functional failure at the second level expands downwards to reveal hardware failure modes and their logical relationships. The integrity of the functional ports of each functional module should be ensured. These functional ports constitute a list of system functional failure states and also represent the top event in the hardware fault tree.

[0073] S6. Based on the completion of the system model construction, conduct security analysis to obtain all fault propagation paths of functional failure modes. The specific steps are as follows:

[0074] S61. Based on the established functional physical mapping model, the output ports of the function are automatically analyzed using the functional physical mapping relationships established within the model.

[0075] S62. With the help of the above automated analysis, comprehensively identify all failure modes that may cause functional abnormalities; based on the identified failure modes, and combined with the functional physical mapping relationship and logical relationship in the model, trace the propagation process of the fault in the system, thereby obtaining all fault propagation paths of the functional failure modes.

[0076] S63. When only the impact of a single fault on the system needs to be considered, a list of functional failure modes and their effects is typically output. This list details each failure mode and the possible system functional anomalies it may cause, providing intuitive fault information for system designers and maintenance personnel, facilitating targeted improvements and maintenance. When the impact of multiple fault combinations on the system needs to be considered, a fault tree should be exported. A fault tree graphically displays the logical relationships between multiple failure events and how they collectively lead to a top-level system failure. Through fault tree analysis, the system's security under complex failure conditions can be more comprehensively assessed, system weaknesses can be identified, and a basis for developing effective security measures can be provided.

[0077] In one specific embodiment, a functional-physical mapping model of the guide vane control system is established. Functional modules are defined and functional ports are selected within the model, automatically generating fault propagation paths for guide vane control function failures. Specifically, the output port of the guide vane actuator module is selected, and a corresponding functional port is defined. The failure mode corresponding to this port is the guide vane actuator "feedback function" failure. Based on this functional port, the safety analysis results of the feedback function module in the guide vane control system can be obtained. Figure 5 , Figure 6 , Figure 7 , Figure 8 This is a schematic diagram illustrating the fault propagation path of a guide vane actuator's "feedback function" failure. Among other things, Figure 6 , Figure 7 , Figure 8 The failure propagation paths of the feedback function module of the guide vane control function are given for three failure modes. A fault tree with feedback signal loss, feedback signal distortion and feedback signal drift as the top events is obtained, which can locate the cause of the functional failure mode to a specific hardware module or a set of failure modes.

[0078] Therefore, this invention adopts the above-mentioned fault propagation analysis method based on the functional physical mapping model, clarifies the modeling and analysis process and method of the functional physical mapping model, and uses a model-based approach to carry out system function-related security analysis, which can effectively support the system's reliability design and security design; it uses a unified modeling language to connect the modeling of the system's fault logic relationship, and uses the model to realize the mapping between system function and physical architecture, so that the analysis process has the advantages of a model-based systems engineering method.

[0079] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A fault propagation analysis method based on a functional physical mapping model, characterized in that, Includes the following steps: S1. Preparatory work before modeling, including sorting out the system functional hierarchy, sorting out the internal flow relationships of the system, and analyzing the failure mode list of components in the system functions; S2. Create a functional physical mapping model for the system, import the flow relationships between physical components of the system and the fault information within the physical modules into the functional physical mapping model, and abstract the failure logic relationships of the system functions. S3. Perform security analysis on the functional physical mapping model. Define functional modules and select appropriate functional ports. Generate corresponding fault propagation paths with the failure of functional ports as the consequence. Automatically generate system fault logic relationships based on the defined fault propagation model. Based on the functional physical mapping relationship within the constructed functional physical mapping model, the output ports of the function are automatically analyzed to identify possible failure modes that lead to functional abnormalities and all fault propagation paths.

2. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, The system functional hierarchy is initially decomposed into indivisible units based on the system-level and subsystem-level hierarchical relationships. That is, if we continue to divide it down, a hardware object will participate in multiple functions at the same time.

3. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, The internal flow relationships of the system are analyzed using formal modeling tools, such as behavioral diagrams and time sequence diagrams, to clarify the physical components of information flow, material flow, energy flow, transmitted data, and causal relationships between components. The transmission and control relationships are abstracted based on information flow, material flow, and energy flow to determine functional operations, timing, and system composition; similar types of flows are transmitted between modules, and flow type conversion is implemented within modules.

4. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, The failure mode list of components in the analysis system is divided into two categories: component failure modes and component output port failure modes. For component failure modes, it is necessary to analyze the impact of each failure mode on the component output port. The analysis results are further used to supplement the component output port failure modes. The logical relationship between component failure modes and component output port failure modes is many-to-many. Some failure modes of component output ports are not directly caused by the state of the component itself.

5. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, The functional physical mapping model includes the functional variable types and fault states of each variable type under the normal operating mode of the system. The fault information imported into the functional physical mapping model includes local fault logic and system fault logic. The local fault logic is defined by manual analysis, while the system fault logic is derived from the model.

6. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, The flow relationships between the physical components of the system are modeled, and the system entities are modeled using block modules. Different types of input and output ports are defined on the block modules, and the energy, matter, and information interaction relationships between the modules are abstracted by the directed flow between the ports. The block modules can be opened as white boxes according to actual needs. In this case, the module itself does not perform internal logic relationship modeling, but is associated through input and output ports, and the internal fault logic is modeled by the internal indivisible modules. Modules with built-in modules are called "white box blocks", and those without built-in modules are called "black box blocks". The number and distribution of ports of white box blocks are determined by the port information of the built-in black box blocks.

7. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, Modeling the propagation relationship of fault information within physical modules, where the variable types of the modules themselves and the variable types of the output ports can meet the mapping requirements of fault logic relationships, and where the output port of any module has the same type as the input port of the associated module, allows the transmission of failure states through flow relationships, eliminating the need to define variable types for the module input ports. The specific steps include: S21. Define the variable types of the block module itself and its output ports in the model, and set failure modes for all variables according to the failure mode list. S22. Within the module, logic gates are used to establish the correlation between failure modes of various variable types, thereby achieving fault logic modeling within the module.

8. The fault propagation analysis method based on the functional physical mapping model according to claim 7, characterized in that, The fault information propagation model is multi-layered and nested. Failures of lower-level products propagate to the next higher level through output interfaces shared with higher-level products.

9. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, Functional port definitions represent a many-to-many permutation and combination relationship between sub-functions and physical components. The same component may correspond to several different functions. By defining functional interfaces, it can be ensured that all components appear only once in the physical configuration of the system.

10. The fault propagation analysis method based on the functional physical mapping model according to claim 1, characterized in that, The safety analysis method of the functional physical mapping model automatically generates system fault logic relationships through the transitive relationships contained in the model itself, which helps to identify severe fault modes and combinations of the system. Fault logic relationships include the impact of a single fault, the impact of multiple fault combinations, and the impact of fault timing combinations. The impact of a single fault should output a functional FMEA list, the impact of multiple fault combinations should derive a fault tree, and the impact of fault timing combinations should obtain the relevant fault sequences using a fault propagation model.

Images