Fault tree analysis method and device, equipment and medium

Abstract

The invention relates to the technical field of quality management, and discloses a fault tree analysis method and device, equipment and a medium, and the method comprises the steps: extracting hierarchical architecture information which comprises the function description of each hierarchical component, a non-functional failure factor and a superior-subordinate dependency relationship; determining a top event based on the hierarchical architecture information, and mapping the hierarchical architecture information into a tree analysis hierarchy; screening components related to the top event according to the function description, and identifying a bottom event from the non-functional failure factors according to a preset guide word; and determining a logic gate type between the top event and the bottom event according to the superior-subordinate dependency relationship, and upwards connecting the bottom event to the top event according to the logic gate type and the mapped tree-shaped analysis hierarchy to obtain a target fault tree containing a failure propagation path so as to obtain a fault tree analysis result according to the target fault tree. According to the technical scheme provided by the invention, the accuracy and efficiency of function security analysis can be improved.

Description

Technical Field

[0001] This application relates to the field of quality management technology, and in particular to a fault tree analysis method, apparatus, equipment and medium. Background Technology

[0002] With the increasing complexity of motor controllers and the proliferation of hardware components in new energy vehicles, the risk of system failure has risen, making functional safety a crucial design factor. ISO 26262, as an international standard, details the safety requirements for electric vehicle systems and uses a safety level classification (A-D) for risk management. Fault Tree Analysis (FTA) is a commonly used tool for identifying potential failure paths to the top event of a system, but it also has limitations in practice. Since FTA is typically performed early in the system development process, the analysis relies on a rough system architecture design and lacks sufficient consideration of complex hardware and software interactions, potentially leading to overlooked risks. Furthermore, FTA analysis often depends on expert experience and may be influenced by subjective judgment, affecting the comprehensiveness and accuracy of the analysis.

[0003] Therefore, how to improve the accuracy and efficiency of functional safety analysis through more in-depth and comprehensive FTA analysis methods is an urgent technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a fault tree analysis method, apparatus, equipment, and medium, which achieves the technical effect of improving the accuracy and efficiency of functional safety analysis through a more in-depth and comprehensive FTA analysis method.

[0005] To achieve the above objectives, the main technical solutions adopted in this application include: In a first aspect, embodiments of this application provide a fault tree analysis method, the method comprising: Based on several components in the hardware architecture design specification, hierarchical architecture information is extracted, wherein the hierarchical architecture information includes the functional description of each level component, non-functional failure factors, and hierarchical dependencies. The top event is determined based on the hierarchical architecture information, and the hierarchical architecture information is mapped to a tree-like analysis hierarchy; Components related to the top event are filtered according to the functional description, and bottom events are identified from the non-functional failure factors according to the preset guiding words; Based on the hierarchical dependency relationship, the logic gate type between the top event and the bottom event is determined, and the bottom event is connected upwards to the top event according to the mapped tree analysis hierarchy based on the logic gate type, so as to obtain the target fault tree containing the failure propagation path, and the fault tree analysis result is obtained based on the target fault tree.

[0006] This embodiment provides a fault tree analysis method that extracts hierarchical architecture information based on hardware architecture design specifications and combines it with functional descriptions of components at each level, non-functional failure factors, and hierarchical dependencies to systematically construct an accurate fault tree. First, the top event is identified, and the hierarchical architecture information is mapped to a tree-like analysis hierarchy, laying the foundation for subsequent failure propagation path construction. Next, by filtering components related to the top event, bottom events are identified, and relevant non-functional failure factors are extracted based on preset guiding words. Finally, by determining the logic gate types between the top and bottom events, the bottom events are connected upwards in a tree-like hierarchy, ultimately forming a complete target fault tree. Based on the target fault tree, each independent failure propagation path can be analyzed, identifying design flaws such as single-point failures, and proposing targeted optimization measures (increasing redundancy and independence, strengthening derating design, and optimizing EMC protection). This transforms the target fault tree into a concrete fault tree analysis result that can guide hardware design iteration, verify the effectiveness of safety mechanisms, and support functional safety certification. This method can effectively improve the accuracy and efficiency of fault tree generation, reduce the possibility of human intervention and errors, and help designers identify and resolve potential functional safety risks more quickly, thereby optimizing the safety design of the system.

[0007] In one implementation, determining the top event based on the hierarchical architecture information includes: Obtain the functional description of the top-level component from the hierarchical architecture information; Obtain the corresponding top-level failure mode based on the functional description of the top-level component, and determine the top event based on the top-level failure mode.

[0008] This embodiment helps analysts clearly understand the functions of each component and its potential failure risks by extracting functional descriptions of top-level components from hierarchical architecture information. By extracting the corresponding top-level failure modes based on the functional descriptions and identifying the top event, a reliable basis is provided for further fault tree analysis. In this way, failure mode identification becomes more comprehensive and accurate, allowing analysts to more accurately identify critical failure modes affecting system security, while avoiding omissions and redundancies in traditional analysis methods.

[0009] In one implementation, mapping the hierarchical architecture information to a tree-like analysis hierarchy includes: The system, module, and sub-module in the hierarchical architecture information are transformed into event nodes of the fault tree level by level, and the top event is determined as the root node; According to the hierarchical depth of the hierarchical architecture information, the event nodes of the lower level are connected to the parent nodes of the upper level to form a tree-like analysis hierarchy.

[0010] This embodiment transforms the system, modules, and sub-modules in the hierarchical architecture information into event nodes of a fault tree, and identifies the top event as the root node. This process clearly displays the failure modes at each level, helping analysts comprehensively identify potential risks, avoid overlooking important failure points, and thus improve the accuracy of the analysis. By connecting the event nodes of lower levels to the parent nodes of higher levels, a tree-like analysis structure is formed. This hierarchical relationship clearly shows the causal dependencies between events, improving the accuracy of risk identification. At the same time, the tree structure makes the construction of the fault tree more systematic, allowing analysts to efficiently focus on the critical path, avoid redundant work, and thus improve analysis efficiency. Therefore, a more in-depth and comprehensive fault tree analysis method can effectively improve the accuracy and efficiency of functional safety analysis.

[0011] In one implementation, the step of filtering components related to the top event based on the functional description and identifying bottom events from the non-functional failure factors based on preset guiding words includes: Based on the functional description, the components in the hierarchical architecture information are initially screened, and all components that implement the top event are extracted to obtain a candidate set of top event components; The candidate set of top event components is further filtered to extract components that have a direct hierarchical dependency relationship with the top event, thus obtaining the target top event component; For the target top event component, potential failure modes are generated from the non-functional failure factors using preset guide words, and the potential failure modes that cause the top event to fail are identified as bottom events.

[0012] This embodiment performs preliminary screening of components in the hierarchical architecture information, accurately extracting components related to the top event and avoiding redundant analysis. Further screening identifies components with direct hierarchical dependencies on the top event, ensuring the analysis focuses more on critical security risks. Generating potential failure modes using guiding words and identifying underlying events that could lead to the failure of the top event refines the failure mode analysis, enhancing the comprehensiveness and depth of fault tree analysis. This refined screening and analysis significantly improves efficiency while maintaining comprehensiveness, accurately locating potential risks and security weaknesses in the system, thus providing more reliable protection for functional safety.

[0013] In one implementation, determining the logic gate type between the top event and the bottom event based on the hierarchical dependency relationship includes: The characteristics of component failure are determined based on the hierarchical dependency relationship, and the logic gate type between the top event and the bottom event is determined based on the determination result.

[0014] In one implementation, the step of connecting the bottom events upwards according to the mapped tree-like analysis hierarchy based on the logic gate type until the top event, to obtain a target fault tree containing the failure propagation path, includes: Starting from the bottom event, determine the intermediate events of the current layer according to the logic gate type, and use the aggregated path between the bottom event and the intermediate events of the current layer as the initial failure propagation path; Using the intermediate event of the current layer as a new starting point, the initial failure propagation path is extended upwards according to the tree-like analysis hierarchy until the top event is connected, generating a target fault tree containing the failure propagation path.

[0015] This embodiment starts from the bottom event, determines the intermediate events of the current layer based on the logic gate type, and uses the aggregated path from the bottom event to the intermediate event as the initial failure propagation path. This process ensures that the connection relationship between the bottom event and the intermediate event conforms to the failure propagation mechanism in the actual system, thereby improving the accuracy of the analysis. Next, the failure propagation path is recursively expanded layer by layer upwards until the top event is connected, ultimately generating a complete fault tree. This recursive expansion method not only improves the efficiency of path construction but also reduces analysis time. By simplifying the path and eliminating redundant propagation paths, a concise and accurate fault tree structure is obtained. Therefore, this method improves the accuracy and efficiency of functional safety analysis, helping designers better identify potential risks in the system and optimize safety design.

[0016] In one implementation, the logic gate type includes an OR gate or an AND gate.

[0017] Secondly, embodiments of this application provide a fault tree analysis apparatus, the apparatus comprising: The hierarchical architecture extraction unit is used to extract hierarchical architecture information based on several components in the hardware architecture design specification. The hierarchical architecture information includes the functional description of each level component, non-functional failure factors, and hierarchical dependencies. The analysis hierarchy mapping unit is used to determine the top event based on the hierarchical architecture information and map the hierarchical architecture information into a tree-like analysis hierarchy; The bottom event identification unit is used to filter components related to the top event according to the functional description, and to identify bottom events from the non-functional failure factors according to preset guiding words; The fault analysis unit is used to determine the logic gate type between the top event and the bottom event according to the hierarchical dependency relationship, and connect the bottom event upwards according to the logic gate type according to the mapped tree analysis hierarchy until the top event, so as to obtain a target fault tree containing the failure propagation path, and obtain the fault tree analysis result based on the target fault tree.

[0018] Thirdly, embodiments of this application provide a computer device, including: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the fault tree analysis method described above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the fault tree analysis method described above. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 A flowchart of a fault tree analysis method provided in an embodiment of this application; Figure 2 A flowchart for determining the top event based on hierarchical architecture information provided in this application embodiment; Figure 3 A flowchart illustrating the mapping of hierarchical architecture information to a tree-like analysis hierarchy is provided for embodiments of this application. Figure 4 A flowchart of step S5 provided in an embodiment of this application; Figure 5 A flowchart of step S7 provided in an embodiment of this application; Figure 6 A block diagram of a fault tree analysis device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In the rapid development of new energy vehicles, the increasing complexity of motor controller functions and the growing number of hardware components in the system have led to a gradual rise in system failure risks. To ensure the safe and stable operation of vehicles under various conditions, functional safety has become a crucial factor that cannot be ignored in design and development. ISO 26262, as an internationally standardized functional safety standard for automobiles, provides detailed safety requirements for the design and development of electric vehicles and related systems. This standard classifies system safety risks into safety levels A through D and adopts different safety measures according to different safety level requirements. This safety risk assessment-based approach provides standardized guidance for ensuring the functional safety of systems.

[0024] In this process, FTA (Fault Tree Analysis) plays a crucial role as an important analytical method. By constructing a fault tree, FTA can visually demonstrate the various potential paths that lead to the system's top event (i.e., a safety incident or failure event). These paths are displayed graphically, helping engineers identify and analyze the root causes of failures and make targeted design improvements.

[0025] However, existing FTA techniques also have some limitations in practical application. First, since FTAs ​​are usually conducted in the early stages of system development, when the system's hardware and software design is not yet fully determined, their analysis relies primarily on the system's preliminary architecture design and module partitioning. Because the system architecture in the early stages is often only a rough outline, FTA analyses using such architecture designs often only cover the initial framework of the system, lacking sufficient consideration for complex hardware and software interactions. Consequently, the definition of basic events in the fault tree often requires brainstorming or expert meetings, which not only increases the subjectivity of the analysis but may also lead to the omission of some potential risks.

[0026] Secondly, FTA analyses based on preliminary designs are typically limited in scope and depth. Specifically, due to the limitations of early system architectures, the constructed fault trees often fail to encompass the complex interactions between various sub-modules of the system. In such cases, the accuracy and comprehensiveness of the analysis are significantly affected, especially when dealing with complex coupling relationships between system hardware and software, which may prevent the full identification of potential security risks.

[0027] Furthermore, while FTAs ​​play a crucial role in functional safety analysis, existing FTA techniques often rely on human experience and expert knowledge during the analysis process. Although expert judgment is irreplaceable in certain situations, this approach depends on subjective experience and may be affected by personal biases, knowledge gaps, or lack of experience, thus impacting the comprehensiveness and accuracy of the analysis results.

[0028] Therefore, how to improve the accuracy and efficiency of functional safety analysis through more in-depth and comprehensive FTA analysis methods is an urgent technical problem that needs to be solved.

[0029] To address the aforementioned technical problems, an embodiment of the fault tree analysis method is provided according to the present application. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] This embodiment provides a fault tree analysis method. Figure 1 A flowchart of a fault tree analysis method provided in this application embodiment is shown below. Figure 1 As shown, the process includes the following steps: Step S1: Based on several components in the hardware architecture design specification, extract hierarchical architecture information, which includes functional descriptions of each level of components, non-functional failure factors, and hierarchical dependencies.

[0031] Specifically, in hardware architecture design specifications, especially in functional safety development projects, the design of the hardware system is crucial. According to the V-flow (or V-Model) development logic, the hardware architecture design specification is an important deliverable in project development. It defines the overall structure of the hardware system, the functions of each component, and their interrelationships, providing a foundation for subsequent verification and validation. A hardware system typically consists of multiple components. In this embodiment, the hardware architecture design specification can represent the hardware system using a physical block diagram.

[0032] This embodiment, when designing hardware architecture, involves acquiring hardware design requirements, performance metrics, and cost budgets. All possible hardware architecture design schemes are listed. Each scheme is evaluated, including performance, cost, reliability, and scalability. The optimal scheme is selected, and the reasons for the selection are recorded. Finally, after comparison, the user selects the optimal scheme based on the final results, thus obtaining the final hardware architecture design specification.

[0033] Optional Architecture Evaluation Example The optional architecture evaluation example lists the control methods, reliability, and cost comparisons of the low-voltage side ASC scheme and the high-voltage side ASC scheme, and clarifies the final selected scheme based on the comparison results.

[0034] The physical block diagrams in the hardware architecture design specifications (usually stored in Visio, SystemWeaver, or PDF format) include first-level system architecture, second-level sub-circuits, and final-level component-level drawings. A top-down reverse engineering approach is used to analyze each block diagram. First, the system functional components in the first-level architecture (such as power management units and signal acquisition units) are identified, and their physical interfaces (connectors, buses, signal lines) and interface attributes (voltage range, communication protocol, load capacity) are labeled. Then, the second-level block diagrams are broken down into sub-circuit units (e.g., the power management unit is broken down into DC-DC converter circuits and LDO regulator circuits), identifying the signal flow and number of interfaces between sub-circuits. Finally, the final-level schematic diagram is decomposed to identify the key components constituting the sub-circuits (such as LDO chip model, power inductor parameters, and filter capacitor values), and the component pin connections are labeled. A hierarchical architecture information (Excel / database format) is generated, including fields such as: component ID, component name, level, parent component ID, list of child elements, functional description, non-functional failure factors, and hierarchical dependencies, etc.

[0035] Examples of non-functional failure factors are as follows: Step S3: Determine the top event based on the hierarchical architecture information and map the hierarchical architecture information into a tree-like analysis hierarchy.

[0036] Specifically, based on the top-level component functional descriptions and non-functional failure factors in the hierarchical architecture information, the system safety objectives are transformed into specific failure modes, and the top event is identified and defined. Subsequently, a rigid mapping rule is established between the hierarchical architecture information and the tree-like analysis hierarchy of the FTA, mapping the first-level system modules, second-level sub-circuits, and final-level key components to the first, second, and bottom-level event nodes of the fault tree, forming a progressive analysis framework that cannot jump across layers. Finally, an executable tree-like analysis hierarchy is output, ensuring that subsequent FTA analysis strictly follows the hardware physical decomposition structure, realizing physical traceability from the top event to specific components and interfaces, thereby improving analysis efficiency and meeting the stringent requirements of functional safety standards for structured and bidirectional traceability.

[0037] Step S5: Filter components related to the top event according to the functional description, and identify the bottom event from non-functional failure factors according to the preset guiding words.

[0038] Specifically, based on functional descriptions, a coarse screening of functional relevance is performed on all components in the hierarchical architecture information. Components directly related to the implementation, support, and information provision of the top event are extracted through keyword matching and functional semantic analysis, forming a coarse-grained candidate set. Then, a fine screening of signal dependency is performed on the candidate set using hierarchical dependencies. Starting with the top-level components associated with the top event, a breadth-first search is conducted, retaining only components with direct hierarchical signal flows and critical path dependencies, while eliminating noisy components that are indirectly related but lack causal chains, resulting in a highly focused target top event component set. Finally, for the target component set... By cross-combining a pre-set guide dictionary and a list of non-functional failure factors, potential failure modes covering deviations from environmental stress and operating conditions are generated in batches. Then, through a dual mechanism of automatic rule screening and expert review, the failure modes that directly lead to the top event are retained as bottom events. A rigid traceability chain is established from the bottom events to specific components, interfaces and stress parameters in the hardware specifications. This refines the initial dozens to hundreds of components into a single-digit number of key components and generates an accurate list of bottom events, significantly improving the efficiency and causal accuracy of FTA analysis and meeting the stringent requirements of functional safety standards for the structured and traceable nature of failure analysis.

[0039] Step S7: Determine the logic gate type between the top event and the bottom event based on the hierarchical dependency relationship, and connect the bottom events upwards according to the mapped tree analysis hierarchy until the top event based on the logic gate type to obtain the target fault tree containing the failure propagation path, so as to obtain the fault tree analysis result based on the target fault tree.

[0040] Specifically, based on the hierarchical dependencies parsed from the hierarchical architecture information, the set of bottom events is grouped by parent component, and the logic gate type is determined according to the redundancy characteristics of the upper and lower level signal flows—if the failure of any one of multiple lower-level paths can independently cause a higher-level event, it is marked as an OR gate; if all paths must fail simultaneously to cause a higher-level event, it is marked as an AND gate. Simultaneously, a common-cause failure check is performed on the paths marked as AND gates to ensure independence. Then, a depth-first recursive aggregation algorithm is used, starting from the bottom event and connecting upwards layer by layer according to the hierarchical depth. The corresponding OR or AND gates are used to aggregate bottom events of the same level into intermediate events and record the initial failure propagation path. This intermediate event is then used as a new input node to recursively push upwards, repeatedly applying the logic. The gate completes the connection from intermediate events to the next higher-level intermediate events and expands the failure propagation path. After aggregation at each level, it calculates the minimum cut set in real time to eliminate redundant paths. Finally, when connected to the root node of the top event, it integrates all minimum cut set sequences to generate a target fault tree containing the complete failure propagation path. This fault tree not only graphically displays the causal chain from the bottom event through intermediate events to the top event, but also outputs a minimum failure propagation path library that can be traced back to specific chapters, component interfaces, and stress parameters in the hardware architecture specification. Each path represents the simplest failure scenario leading to the top event, thereby supporting the design team to accurately locate hardware weaknesses, optimize redundant architectures, and verify the effectiveness of safety mechanisms, meeting the stringent requirements of functional safety standards for the structured, traceable, and quantitative assessment of failure analysis.

[0041] In a preferred embodiment, the characteristics of component failure are determined based on the hierarchical dependency relationship, and the logic gate type between the top event and the bottom event is determined based on the determination result.

[0042] Specifically, for the upper-level component (such as the "power management unit"), extract the input / output signals of all its lower-level components (LDO1, LDO2, monitoring circuit). If the output signals of the lower-level components are combined within the parent component through a diode OR gate or multiplexer → OR gate; if the output signals are connected in series (such as LDO1 output as LDO2 input) or need to be enabled simultaneously → AND gate.

[0043] This embodiment provides a fault tree analysis method that extracts hierarchical architecture information based on hardware architecture design specifications and combines it with functional descriptions of components at each level, non-functional failure factors, and hierarchical dependencies to systematically construct an accurate fault tree. First, the top event is identified, and the hierarchical architecture information is mapped to a tree-like analysis hierarchy, laying the foundation for subsequent failure propagation path construction. Next, by filtering components related to the top event, bottom events are identified, and relevant non-functional failure factors are extracted based on preset guiding words. Finally, by determining the logic gate types between the top and bottom events, the bottom events are connected upwards in a tree-like hierarchy, ultimately forming a complete target fault tree. Based on the target fault tree, each independent failure propagation path can be analyzed, identifying design flaws such as single-point failures, and proposing targeted optimization measures (increasing redundancy and independence, strengthening derating design, and optimizing EMC protection). This transforms the target fault tree into a concrete fault tree analysis result that can guide hardware design iteration, verify the effectiveness of safety mechanisms, and support functional safety certification. This method can effectively improve the accuracy and efficiency of fault tree generation, reduce the possibility of human intervention and errors, and help designers identify and resolve potential functional safety risks more quickly, thereby optimizing the safety design of the system.

[0044] Figure 2 The flowchart for determining the top event based on hierarchical architecture information provided in this application embodiment may include the following steps: Step S311: Obtain the functional description of the top-level component from the hierarchical architecture information.

[0045] Specifically, all components identified as "Level 1" are selected from the hierarchical architecture information. These components constitute the system's top-level architecture (e.g., the "signal acquisition unit," "power supply management unit," "logic control unit," and "drive execution unit" of a motor control system), and are defined as the top-level component set. Then, the function traceability table is traversed to extract all function entries for each component in this set, focusing on operational functions directly related to system safety objectives (e.g., the "outputting precise PWM drive signal to the motor" function of the "drive execution unit") and detection functions (e.g., the "real-time monitoring of motor speed and feedback to the controller" function of the "signal acquisition unit"), forming a list containing the function descriptions of the top-level components. For example, the function description of the power management module is as follows: 1. Competitive power input, which supplies power to the entire board module through power conversion; 2. It has an active power-off function for input power, which reduces the static power consumption of the single board; 3. Equipped with overvoltage / undervoltage detection function for each output power supply; 4. Equipped with MCU monitoring function, capable of resetting the MCU; 5. Equipped with SPI communication and protection functions; 6. The SBC chip has over-temperature protection. 7. It has a fault register flag function; 8. It has MCU safety unit monitoring function, which can output safety signals to put the system into a safe state.

[0046] Step S313: Obtain the corresponding top-level failure mode based on the functional description of the top-level component, and determine the top event based on the top-level failure mode.

[0047] Specifically, for the functional descriptions of top-level components, a function-failure transition rule is applied: active verbs in the functional descriptions are converted into negative forms (e.g., "output precise PWM signal" is converted to "PWM signal output loss," "PWM signal output deviation is too large," "PWM signal output timing error"), forming a preliminary candidate set of failure modes. For operational functions, three types of deviations are considered: complete loss, performance deviation, and timing error; for detection functions, detection failure (failure to detect a real fault), false detection (false alarm), and detection delay are considered; for response functions, no response, response error, and response delay are considered. All candidate failure modes are correlated with system safety objectives and scored (e.g., using a 5-point scale: 5 - directly leads to system danger, 1 - no safety impact). Failure modes with a score ≥3 are selected to constitute the top-level failure modes, and the top-level failure modes are determined as the top event (e.g., "motor drive signal output loss"), and their failure criteria are clearly defined (e.g., PWM duty cycle deviation > 10% for > 100ms).

[0048] This embodiment helps analysts clearly understand the functions of each component and its potential failure risks by extracting functional descriptions of top-level components from hierarchical architecture information. By extracting the corresponding top-level failure modes based on the functional descriptions and identifying the top event, a reliable basis is provided for further fault tree analysis. In this way, failure mode identification becomes more comprehensive and accurate, allowing analysts to more accurately identify critical failure modes affecting system security, while avoiding omissions and redundancies in traditional analysis methods.

[0049] Figure 3 The flowchart provided in this application for mapping hierarchical architecture information to a tree-like analysis hierarchy may include the following steps: Step S331: Transform the systems, modules, and sub-modules in the hierarchical architecture information into event nodes of the fault tree, and determine the top event as the root node.

[0050] Specifically, starting from the system level, each system-level component (e.g., "motor control system") is first converted into a fault event node, along with its failure mode (e.g., "motor control system functional failure"). Next, for module-level components (e.g., "drive module"), a failure event node is generated, named "drive module functional failure". Then, nodes are generated for more granular sub-modules (e.g., "MOSFET drive circuit"), named "MOSFET drive circuit failure". For the lowest-level components (e.g., "power MOSFET"), failure event nodes such as "power MOSFET breakdown failure" are generated. Each node's naming must follow a consistent format: "component name + failure mode". This ensures clear node naming for easy subsequent analysis and traceability.

[0051] Each node needs to inherit the hierarchical attributes of its corresponding component and indicate in the node's metadata which level it belongs to (e.g., Level1 / Level2 / Level3) and the ID traceability code of the corresponding component. This design allows for reverse tracing of the fault tree nodes against the hardware architecture design specifications in subsequent analysis, ensuring design consistency.

[0052] Extract the selected top event (e.g., "motor malfunction") and define it as the root node of the fault tree. The top event, as the starting point of the fault tree, does not inherit any component properties but needs to be associated with a safety target ID for safety assessment in subsequent analysis. Store all generated event nodes (including the root node) in the fault tree's event node database, and record the potential parent-child relationships between nodes using a pre-assignment table. The pre-assignment table is generated based on the parent-child relationship structure in the hierarchical component list, but logical connections are not established at this stage.

[0053] Step S333: According to the hierarchical depth of the hierarchical architecture information, connect the event nodes of the lower level to the parent nodes of the upper level to form a tree-like analysis hierarchy.

[0054] Specifically, nodes are sorted according to hierarchical depth, from the bottom layer (e.g., the lowest-level component nodes) to the top layer (e.g., system-level nodes). This ensures that connections are always made from bottom to top, connecting lower-level nodes first and then progressively connecting to higher-level nodes. Each layer of nodes is traversed, searching for its parent node. Parent node lookup is based on a previously generated pre-assignment table. When searching for a parent node, the direct parent node of each node is found according to the hierarchical relationship (e.g., the parent node of the "MOSFET driver circuit failure" node is "MOSFET driver circuit"). The logic gate type (e.g., AND gate, OR gate) is determined based on the relationship between parent and child nodes. The configuration of logic gate types is determined by the physical characteristics and dependencies of the failure events. For example, if the failure of a parent node depends on the simultaneous failure of multiple child nodes, an AND gate might be used; if the failure of any one of the child nodes would cause the parent node to fail, an OR gate would be used.

[0055] For each parent-child node pair, perform a connection operation. If using an OR gate, connect the child and parent nodes using the OR gate symbol; if using an AND gate, connect using the AND gate symbol. When connecting, the dependencies of the logic gates must be labeled. For example, there may be specific dependencies such as "independent power supply path" or "competitive power supply condition." These labels clearly show the dependencies and triggering conditions of each failure mode. During node connection, the minimum cut set of each parent node needs to be calculated in real time. The minimum cut set represents the minimum combination of events that causes the parent node to fail. For example, when two child nodes are connected to the parent node via an OR gate, the minimum cut set of the parent node is the union of the two child nodes. Real-time calculation of the minimum cut set helps analysts quickly identify potential critical failure paths. Repeat the above process until all nodes are correctly connected. Finally, system-level nodes (such as "motor control system malfunction failure") will be connected to the root node (such as "motor runaway") via OR or AND gates. Once all connections are completed, a complete tree-like analysis hierarchy will be formed, recording information such as the IDs of parent and child nodes, logic gate types, connection criteria, and minimum cut set expressions.

[0056] This embodiment transforms the system, modules, and sub-modules in the hierarchical architecture information into event nodes of a fault tree, and identifies the top event as the root node. This process clearly displays the failure modes at each level, helping analysts comprehensively identify potential risks, avoid overlooking important failure points, and thus improve the accuracy of the analysis. By connecting the event nodes of lower levels to the parent nodes of higher levels, a tree-like analysis structure is formed. This hierarchical relationship clearly shows the causal dependencies between events, improving the accuracy of risk identification. At the same time, the tree structure makes the construction of the fault tree more systematic, allowing analysts to efficiently focus on the critical path, avoid redundant work, and thus improve analysis efficiency. Therefore, a more in-depth and comprehensive fault tree analysis method can effectively improve the accuracy and efficiency of functional safety analysis.

[0057] Figure 4 The flowchart for step S5 provided in the embodiments of this application may include the following steps: Step S51: Based on the functional description, perform preliminary screening of the components in the hierarchical architecture information, extract all components that implement the top event, and obtain a candidate set of top event components.

[0058] Specifically, a dual mechanism of keyword matching and functional semantic analysis is employed. First, the description text of the top event is segmented and parsed to extract core functional verbs and their objects of action (e.g., extracting keywords "protection," "overcharge," and "battery" from the top event "battery overcharge protection function failure"). Then, the functional descriptions are traversed, and fuzzy matching is performed on each component's functional description: if the functional description contains keywords such as "protection," "charging control," or "voltage monitoring," or if the functional semantics belong to the direct implementer of the top event's function (e.g., the "charging control module" directly executes charging on / off), the supporting implementer (e.g., the "power supply module" provides working power for charging control), or the information provider (e.g., the "voltage sampling module" provides battery voltage data), then the component is included in the candidate set. For redundant designs (e.g., dual-channel voltage sampling), both sets of redundant components are included in the candidate set. After the candidate set of top event components is generated, deduplication and normalization are performed to ensure that only one record is retained when the same physical component is repeatedly screened due to multiple lines of functional description.

[0059] Step S53: Perform a second screening on the candidate set of top event components, extract components that have a direct hierarchical dependency relationship with the top event, and obtain the target top event component.

[0060] Specifically, a directed dependency graph (nodes represent components, edges represent signal flows) is constructed based on hierarchical dependencies. Then, starting from the top-level component associated with the top event (e.g., the "charging control module"), a breadth-first search (BFS) is performed, tracing upstream to the input signal source component and downstream to the output signal target component. The search depth is limited to level 1 (i.e., only directly connected components are retained). During the search, the dependency strength of each dependency edge is evaluated: if the signal type is a control signal (e.g., charging enable signal) or a safety-critical data signal (e.g., battery voltage sampling value), it is marked as a strong dependency and retained; if it is an auxiliary signal (e.g., temperature compensation signal) or a monitoring signal (e.g., heartbeat signal), it is marked as a weak dependency and discarded. Furthermore, for redundant architectures (e.g., dual-path CAN communication), if both redundant paths depend on the top event component, both are retained; if only one path is related, redundant and irrelevant paths are discarded. The final output is the target top event component.

[0061] Step S55: For the target top event component, generate potential failure modes from non-functional failure factors using preset guide words, and identify the potential failure modes that cause the top event to fail as bottom events.

[0062] Specifically, a cross-combination generation method using guiding words is employed. For each target component, its corresponding functional description and non-functional failure factors are first extracted. Then, a double-loop generation process is executed: the outer loop iterates through guiding words (such as blank, excessive, reduced, etc.), while the inner loop iterates through failure factors (such as temperature stress, EMI interference), generating cross-combined failure modes. For example, "no + temperature cycle stress" generates "temperature cycle causes open circuit at solder joint, no output of sampled value," and "excessive + EMI interference" generates "EMI causes sampled value to be too large." During the generation process, the failure mechanism (stress → physical effect → functional deviation) and impact level (this level / upper level / system) are labeled for each potential failure mode. After generation, a two-level screening process is performed: The first level is automatic rule screening, which eliminates failure modes that obviously do not lead to the top event based on predefined exclusion rules (such as "sampled value is too large" if it does not exceed the overcharge protection threshold). The second level is expert review screening, in which hardware engineers and security analysts conduct failure scenario reproduction analysis on the remaining modes to determine whether they may actually lead to the top event (such as "EMI of the voltage sampling module causes the sampled value to be too large. If the value exceeds the overcharge threshold, the main controller will misjudge that the battery is not overcharged and will not cut off the charging circuit, resulting in the top event 'overcharge protection failure'"). Modes that pass the review are retained as bottom events.

[0063] Examples of introductory words for different functional failures:

[0064] This embodiment performs preliminary screening of components in the hierarchical architecture information, accurately extracting components related to the top event and avoiding redundant analysis. Further screening identifies components with direct hierarchical dependencies on the top event, ensuring the analysis focuses more on critical security risks. Generating potential failure modes using guiding words and identifying underlying events that could lead to the failure of the top event refines the failure mode analysis, enhancing the comprehensiveness and depth of fault tree analysis. This refined screening and analysis significantly improves efficiency while maintaining comprehensiveness, accurately locating potential risks and security weaknesses in the system, thus providing more reliable protection for functional safety.

[0065] Figure 5 The flowchart for step S7 provided in the embodiments of this application may include the following steps: Step S71: Starting from the bottom event, determine the intermediate events of the current layer according to the logic gate type, and use the aggregated path between the bottom event and the intermediate events of the current layer as the initial failure propagation path.

[0066] Specifically, identify all bottom events whose "component ID" field points to the same parent component (e.g., the parent component of both bottom events "MOSFET Q1 breakdown failure" and "MOSFET Q2 breakdown failure" is "driver module"). Next, for each group of bottom events, obtain the logic gate type corresponding to the parent component (e.g., "driver module" corresponds to an OR gate). Then, perform an aggregation operation: create an intermediate event node (named "driver module failure") corresponding to the parent component in the FTA tool, and connect all bottom events within the group to the intermediate event node through this logic gate, completing the first upward aggregation from bottom events to intermediate events. Simultaneously with aggregation, generate initial failure propagation path records: each record is a triple (bottom event ID → logic gate type → intermediate event ID), with a timing marker attached (if the bottom event is "sampling output loss," the intermediate event is "signal acquisition failure"). For AND gate aggregation (e.g., two redundant sensors need to fail simultaneously), a common cause identifier must be marked in the path record to indicate subsequent common cause failure analysis. All path records are stored in the initial failure propagation path library.

[0067] Step S73: Take the intermediate event of the current layer as the new starting point, and recursively push upwards according to the tree analysis hierarchy to expand the initial failure propagation path until the top event is connected, thereby generating a target fault tree containing the failure propagation path.

[0068] Specifically, all generated intermediate event nodes are enqueued in ascending order of level depth (e.g., Level 2 intermediate events are enqueued first, followed by Level 3). Next, the parent component of the lowest-level intermediate event node in the queue is retrieved (e.g., the parent of "Driver Module Failure" is "Motor Control System"). The logic gate type between this parent and child levels is then determined (usually an OR gate). Then, a higher-level intermediate event is created (e.g., "Motor Control System Failure"), and the current intermediate event is connected to this higher-level intermediate event via a logic gate. Simultaneously, the initial failure propagation path is extended upwards, and the new failure propagation path is recorded. If a higher-level intermediate event already exists in the initial failure propagation path, multiple child nodes under the same parent node are merged. This process is repeated until the parent of an intermediate event becomes the root node (top event). At this point, no new intermediate events are created; instead, the event is directly connected to the top event, completing the path closure. Finally, the complete path library is simplified by removing redundant paths that are logically contained within other paths (e.g., path A: BE1→OR→IE1→OR→TE and path B: BE1→OR→IE1→AND→IE2→OR→TE; if IE1 and IE2 are ORed, then path B is contained within path A, and B is removed). The simplified set yields the minimum set of failure propagation paths, where each path represents an independent failure scenario leading to the top event.

[0069] This embodiment starts from the bottom event, determines the intermediate events of the current layer based on the logic gate type, and uses the aggregated path from the bottom event to the intermediate event as the initial failure propagation path. This process ensures that the connection relationship between the bottom event and the intermediate event conforms to the failure propagation mechanism in the actual system, thereby improving the accuracy of the analysis. Next, the failure propagation path is recursively expanded layer by layer upwards until the top event is connected, ultimately generating a complete fault tree. This recursive expansion method not only improves the efficiency of path construction but also reduces analysis time. By simplifying the path and eliminating redundant propagation paths, a concise and accurate fault tree structure is obtained. Therefore, this method improves the accuracy and efficiency of functional safety analysis, helping designers better identify potential risks in the system and optimize safety design.

[0070] Accordingly, please refer to Figure 6 A block diagram of a fault tree analysis apparatus provided in this application embodiment, the apparatus comprising: The hierarchical architecture extraction unit 101 is used to extract hierarchical architecture information based on several components in the hardware architecture design specification. The hierarchical architecture information includes the functional description of each level component, non-functional failure factors, and hierarchical dependencies. The analysis hierarchy mapping unit 103 is used to determine the top event based on the hierarchical architecture information and map the hierarchical architecture information into a tree-like analysis hierarchy; The bottom event identification unit 105 is used to filter components related to the top event according to the functional description, and to identify the bottom event from non-functional failure factors according to the preset guiding words. The fault analysis unit 107 is used to determine the logic gate type between the top event and the bottom event according to the hierarchical dependency relationship, and connect the bottom event upwards according to the mapped tree analysis hierarchy until the top event, so as to obtain the target fault tree containing the failure propagation path, and obtain the fault tree analysis result based on the target fault tree.

[0071] In some alternative implementations, the top event is determined based on hierarchical architecture information, including: Obtain the functional description of the top-level component from the hierarchical architecture information; Obtain the corresponding top-level failure mode based on the functional description of the top-level component, and determine the top event based on the top-level failure mode.

[0072] In some alternative implementations, the hierarchical architecture information is mapped to a tree-like analysis hierarchy, including: The hierarchical architecture information is transformed into event nodes of the fault tree level by level, and the top event is determined as the root node. Based on the hierarchical depth of the information in the hierarchical architecture, the event nodes of the lower level are connected to the parent nodes of the upper level to form a tree-like analysis hierarchy.

[0073] In some optional implementations, components related to the top event are filtered based on functional descriptions, and bottom events are identified from non-functional failure factors based on preset guiding words, including: Based on the functional description, the components in the hierarchical architecture information are initially screened, and all components that implement the top event are extracted to obtain a candidate set of top event components; The candidate set of top event components is further filtered to extract components that have a direct hierarchical dependency relationship with the top event, thus obtaining the target top event component; For the target top event component, potential failure modes are generated from non-functional failure factors using preset guide words, and the potential failure modes that cause the top event to fail are identified as bottom events.

[0074] In some optional implementations, the logic gate type between the top event and the bottom event is determined based on the hierarchical dependency relationship, including: The characteristics of component failure are determined based on the hierarchical dependency relationship, and the logic gate type between the top event and the bottom event is determined based on the judgment result.

[0075] In some optional implementations, the bottom events are connected upwards according to the mapped tree analysis hierarchy based on the logic gate type until the top event, resulting in a target fault tree containing the failure propagation path, including: Starting from the bottom event, determine the intermediate events of the current layer according to the logic gate type, and use the aggregated path between the bottom event and the intermediate events of the current layer as the initial failure propagation path; Using the intermediate events of the current layer as a new starting point, the initial failure propagation path is extended upwards according to the tree-like analysis hierarchy until the top event is connected, generating a target fault tree containing the failure propagation path.

[0076] In some alternative implementations, the logic gate types include OR gates or AND gates.

[0077] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0078] In this embodiment, a fault tree analysis device is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0079] Please see Figure 7 , Figure 7 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 7 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 7 Take a processor 10 as an example.

[0080] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0081] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0082] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0083] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0084] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0085] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0086] The apparatus and units described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0087] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0088] Those skilled in the art will understand that the embodiments of this application can be provided as methods or apparatus. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, and devices according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0090] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0091] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0092] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0093] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0094] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0095] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A fault tree analysis method, characterized in that, The method includes: Based on several components in the hardware architecture design specification, hierarchical architecture information is extracted, wherein the hierarchical architecture information includes the functional description of each level component, non-functional failure factors, and hierarchical dependencies. The top event is determined based on the hierarchical architecture information, and the hierarchical architecture information is mapped to a tree-like analysis hierarchy; Components related to the top event are filtered according to the functional description, and bottom events are identified from the non-functional failure factors according to the preset guiding words; Based on the hierarchical dependency relationship, the logic gate type between the top event and the bottom event is determined, and the bottom event is connected upwards to the top event according to the mapped tree analysis hierarchy based on the logic gate type, so as to obtain the target fault tree containing the failure propagation path, and the fault tree analysis result is obtained based on the target fault tree.

2. The method according to claim 1, characterized in that, The determination of the top event based on the hierarchical architecture information includes: Obtain the functional description of the top-level component from the hierarchical architecture information; Obtain the corresponding top-level failure mode based on the functional description of the top-level component, and determine the top event based on the top-level failure mode.

3. The method according to claim 1, characterized in that, The step of mapping the hierarchical architecture information to a tree-like analysis hierarchy includes: The system, module, and sub-module in the hierarchical architecture information are transformed into event nodes of the fault tree level by level, and the top event is determined as the root node; According to the hierarchical depth of the hierarchical architecture information, the event nodes of the lower level are connected to the parent nodes of the upper level to form a tree-like analysis hierarchy.

4. The method according to claim 1, characterized in that, The step of filtering components related to the top event based on the functional description and identifying bottom events from the non-functional failure factors based on preset guiding words includes: Based on the functional description, the components in the hierarchical architecture information are initially screened, and all components that implement the top event are extracted to obtain a candidate set of top event components; The candidate set of top event components is further filtered to extract components that have a direct hierarchical dependency relationship with the top event, thus obtaining the target top event component; For the target top event component, potential failure modes are generated from the non-functional failure factors using preset guide words, and the potential failure modes that cause the top event to fail are identified as bottom events.

5. The method according to claim 1, characterized in that, Determining the logic gate type between the top event and the bottom event based on the hierarchical dependency relationship includes: The characteristics of component failure are determined based on the hierarchical dependency relationship, and the logic gate type between the top event and the bottom event is determined based on the determination result.

6. The method according to claim 1, characterized in that, The step of connecting the bottom events upwards according to the mapped tree-like analysis hierarchy based on the logic gate type until the top event, to obtain the target fault tree containing the failure propagation path, includes: Starting from the bottom event, determine the intermediate events of the current layer according to the logic gate type, and use the aggregated path between the bottom event and the intermediate events of the current layer as the initial failure propagation path; Using the intermediate event of the current layer as a new starting point, the initial failure propagation path is extended upwards according to the tree-like analysis hierarchy until the top event is connected, generating a target fault tree containing the failure propagation path.

7. The method according to claim 1, characterized in that, The logic gate types include OR gates and AND gates.

8. A fault tree analysis device, characterized in that, The device includes: The hierarchical architecture extraction unit is used to extract hierarchical architecture information based on several components in the hardware architecture design specification. The hierarchical architecture information includes the functional description of each level component, non-functional failure factors, and hierarchical dependencies. The analysis hierarchy mapping unit is used to determine the top event based on the hierarchical architecture information and map the hierarchical architecture information into a tree-like analysis hierarchy; The bottom event identification unit is used to filter components related to the top event according to the functional description, and to identify bottom events from the non-functional failure factors according to preset guiding words; The fault analysis unit is used to determine the logic gate type between the top event and the bottom event according to the hierarchical dependency relationship, and connect the bottom event upwards according to the logic gate type according to the mapped tree analysis hierarchy until the top event, so as to obtain a target fault tree containing the failure propagation path, and obtain the fault tree analysis result based on the target fault tree.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the fault tree analysis method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the fault tree analysis method according to any one of claims 1 to 7.

Images