InfiniSynapse
What is fault tree analysis?什么是故障树分析？
For the full topic map and the neighboring methods that support this workflow, continue with the anomaly detection and root cause analysis guide.
如需查看完整主题结构以及支撑本流程的相邻方法，请继续阅读异常检测与根因分析指南。
Fault tree analysis (FTA) is a top-down, deductive method that starts with one clearly defined undesired event and maps the combinations of lower-level events that can produce it through Boolean logic gates. Teams use the resulting tree to find vulnerable paths, test whether safeguards are sufficient, prioritize evidence, and—when probability data are credible—estimate the likelihood of the top event.
故障树分析（Fault Tree Analysis，FTA）是一种自上而下的演绎方法：先定义一个明确的不期望顶事件，再用布尔逻辑门分解可能导致该事件的低层事件组合。团队可用故障树识别脆弱路径、检验保护措施是否充分、确定证据优先级；当概率数据可靠时，还能估算顶事件发生概率。
FTA answers “how could this specific outcome occur?” It is most useful when a system has interacting components, redundant controls, multiple failure paths, or safety consequences. It is less useful for an open-ended brainstorming session with no defined outcome, and it cannot replace physical testing, qualified engineering judgment, or incident evidence.
FTA 回答的是“这个特定结果可能如何发生”。当系统包含相互作用的部件、冗余控制、多条失效路径或安全后果时，它最有价值。若问题没有明确结果、只是开放式头脑风暴，FTA 并不合适；它也不能替代物理试验、合格的工程判断或事故证据。
When fault tree analysis fits—and when it does not故障树分析的适用与不适用场景
A safety hazard, service outage, quality escape, loss of function, or control failure has a precise boundary and several possible causal combinations.
安全危害、服务中断、质量逃逸、功能丧失或控制失效具有明确边界，并存在多种可能的原因组合。
The team is still discovering what the problem is, needs to survey broad cause categories, or lacks enough system knowledge to define immediate causes.
团队仍在确认问题本身，需要广泛探索原因类别，或缺少足够系统知识，无法定义直接原因。
Use FTA prospectively during design or risk assessment, and retrospectively during incident investigation. In design work, the branches are hypotheses about credible failure mechanisms. In an investigation, branches are candidate explanations that must be accepted, rejected, or marked unresolved against evidence. Do not silently mix these two purposes: a prospective model may include paths that did not occur in the incident.
FTA 既可前瞻性用于设计和风险评估，也可回顾性用于事故调查。设计阶段的分支是假设性的可信失效机制；调查阶段的分支则是候选解释，必须结合证据接受、排除或标为未决。两种目的不能悄然混用，因为前瞻模型可能包含本次事件并未发生的路径。
Prepare the top event, boundaries, and evidence准备顶事件、系统边界与证据
Before drawing gates, write the top event as an observable state with an object, condition, context, and time window. “Pump failure” is vague; “Cooling pump cannot deliver minimum required flow during the 30-minute emergency mission” is testable. Record what counts as success and failure, the operating mode, system boundary, assumptions, exclusions, and analysis date.
绘制逻辑门前，应把顶事件写成可观察状态，包含对象、条件、上下文和时间窗口。“泵故障”过于模糊；“冷却泵在 30 分钟应急任务期间无法提供最低所需流量”才可检验。还要记录成功与失效判据、运行模式、系统边界、假设、排除项和分析日期。
- Architecture: schematics, interfaces, dependencies, redundancies, barriers, and operating procedures.架构资料：原理图、接口、依赖、冗余、屏障和操作程序。
- Evidence: logs, alarms, maintenance history, tests, inspections, configuration changes, and environmental measurements.证据：日志、告警、维护历史、试验、检查、配置变更和环境测量。
- Probability inputs: component failure rates, demand failure probabilities, exposure or mission time, repair assumptions, and data provenance.概率输入：部件失效率、按需失效概率、暴露或任务时间、修复假设以及数据来源。
- Review roles: system owner, operator, reliability or safety specialist, evidence owner, and an independent challenger.复核角色：系统负责人、操作人员、可靠性或安全专家、证据负责人和独立质疑者。
Fault tree events and AND/OR gate logic故障树事件与 AND/OR 逻辑门
| Element元素 | Meaning含义 | Review question复核问题 |
|---|---|---|
| Top event顶事件 | The single undesired outcome under analysis本次分析的单一不期望结果 | Is it observable, bounded, and unambiguous?是否可观察、有边界且无歧义？ |
| Intermediate event中间事件 | An output that still needs decomposition仍需继续分解的输出事件 | Are its immediate necessary and sufficient causes shown?是否列出其直接、必要且充分的原因？ |
| Basic event基本事件 | A lowest-level event not developed further不再继续展开的最低层事件 | Is the stopping rule documented and data available?是否记录停止规则且有数据支持？ |
| OR | Any one input can produce the output任一输入即可产生输出 | Would each branch alone be sufficient?每个分支单独发生是否足够？ |
| AND | All inputs must occur together for the output所有输入必须共同发生才产生输出 | Does losing one input prevent the output?缺少任一输入是否会阻止输出？ |
| Undeveloped or transfer event未展开或转移事件 | A deliberate stop or link to another tree有意停止或链接到另一棵树 | Is the reason, owner, and referenced tree explicit?原因、负责人和引用树是否明确？ |
Logic discipline: gates connect events, not components. “Valve A AND operator” is not a complete statement; “Valve A fails closed” and “manual bypass is not initiated within five minutes” are events that can be tested.
逻辑纪律：逻辑门连接的是事件，而不是部件名称。“阀门 A AND 操作员”并非完整陈述；“阀门 A 卡在关闭位”和“人工旁路未在五分钟内启动”才是可检验事件。
How to perform fault tree analysis step by step如何逐步执行故障树分析
- Define one top event.定义一个顶事件。Write its threshold, operating state, time window, and system boundary. Agree on the wording before decomposition.写明阈值、运行状态、时间窗口和系统边界，并在分解前统一表述。
- Identify immediate causes.识别直接原因。Ask what events immediately and sufficiently produce the parent event. Avoid jumping straight to remote root causes.询问哪些事件能够直接且充分地产生父事件，不要直接跳到遥远的根因。
- Choose the gate from system behavior.根据系统行为选择逻辑门。Use OR when one input is sufficient; use AND when inputs must coexist. Write a short rationale for every non-obvious gate.单个输入足够时用 OR，多个输入必须共存时用 AND；对每个不明显的门写下理由。
- Develop each branch consistently.一致地展开各分支。Stop at a documented resolution such as replaceable component, testable human action, external event, or available data item.在可更换部件、可检验人员行为、外部事件或可获得数据等已记录层级停止。
- Find minimal cut sets.求最小割集。Reduce the logic to the smallest event combinations sufficient for the top event. Look for single-point failures and repeated events.把逻辑化简为足以导致顶事件的最小事件组合，并查找单点失效和重复事件。
- Quantify only with defensible inputs.仅用可辩护输入进行定量化。Align units and mission time, distinguish rates from probabilities, model dependence, and keep uncertainty visible.统一单位和任务时间，区分失效率与概率，处理依赖关系，并明确展示不确定性。
- Validate and act.验证并采取措施。Review logic, compare with evidence, test sensitivity, choose controls, assign owners, and define post-change measures before approval.复核逻辑、对照证据、进行敏感性测试、选择控制措施、分配负责人，并在批准前定义变更后指标。
Fault tree analysis example: loss of emergency cooling故障树分析示例：应急冷却功能丧失
Consider a hypothetical system whose top event is “required cooling flow is unavailable during a 30-minute emergency demand.” This is a teaching example, not data from a real installation. Suppose cooling fails if either the supply path fails or flow is blocked. The supply path fails only when both duty pumps are unavailable, so that branch uses an AND gate. Flow blockage can be caused by either a closed isolation valve or a blocked intake, so that branch uses an OR gate.
设想一个假设系统，其顶事件为“在 30 分钟应急需求期间无法获得所需冷却流量”。这是教学示例，并非来自真实设施。假定当供给路径失效或流路被阻断时，冷却功能丧失。只有两台工作泵都不可用时供给路径才失效，因此该分支使用 AND 门；隔离阀关闭或入口堵塞中的任一事件都可阻断流量，因此该分支使用 OR 门。
| Event事件 | Symbol符号 | Example probability示例概率 | Evidence needed所需证据 |
|---|---|---|---|
| Pump A unavailable泵 A 不可用 | A | 0.01 | Demand tests and maintenance records需求试验与维护记录 |
| Pump B unavailable泵 B 不可用 | B | 0.02 | Demand tests and maintenance records需求试验与维护记录 |
| Isolation valve closed隔离阀关闭 | C | 0.003 | Position indication and inspection位置指示与检查 |
| Intake blocked入口堵塞 | D | 0.004 | Differential pressure and inspection差压与检查 |
Assuming independence only for illustration, the dual-pump AND branch is P(A∩B)=0.01×0.02=0.0002. The blockage OR branch is P(C∪D)=1−(1−0.003)(1−0.004)=0.006988. Combining those two branches with an OR gate gives 1−(1−0.0002)(1−0.006988)=0.0071866, or about 0.719% per demand.
仅为演示而假定各事件独立，则双泵 AND 分支为 P(A∩B)=0.01×0.02=0.0002；阻断 OR 分支为 P(C∪D)=1−(1−0.003)(1−0.004)=0.006988。再用 OR 门组合两个分支，得到 1−(1−0.0002)(1−0.006988)=0.0071866，即每次需求约 0.719%。
Interpretation, not a real risk estimate: the blockage branch dominates this simplified example, so checking valve alignment and intake controls may deserve priority. But a shared power supply, common maintenance error, flood, or incorrect independence assumption could make the dual-pump branch much larger. Real decisions require validated data and common-cause modeling.
这只是解释，并非真实风险估计：在简化示例中，阻断分支占主导，因此阀位确认和入口控制可能应优先检查。但共同电源、共同维护错误、洪水或错误的独立性假设都可能显著放大双泵分支。真实决策必须使用验证数据并建模共同原因。
Calculate probability and read minimal cut sets carefully谨慎计算概率并解读最小割集
For statistically independent inputs A and B, an AND gate uses P(A∩B)=P(A)P(B). An OR gate uses P(A∪B)=1−[1−P(A)][1−P(B)]. For rare, mutually small inputs, adding probabilities can approximate an OR gate, but the approximation should be labeled and checked. Do not add failure rates and probabilities, or combine values defined over different mission times.
对统计独立的输入 A 和 B，AND 门使用 P(A∩B)=P(A)P(B)；OR 门使用 P(A∪B)=1−[1−P(A)][1−P(B)]。当输入事件稀少且概率很小时，相加可近似 OR 门，但必须标注并检查近似。不要把失效率与概率相加，也不要组合不同任务时间定义的数值。
A minimal cut set is the smallest combination of basic events sufficient to cause the top event. A single-event cut set reveals a single point of failure. A repeated event in many cut sets may indicate leverage, but importance is not the same as probability: structural importance, probability importance, uncertainty, severity, detectability, and control feasibility can point to different priorities.
最小割集是足以导致顶事件的最小基本事件组合。单事件割集暴露单点失效；在多个割集中重复出现的事件可能具有杠杆作用。但重要度不等于概率：结构重要度、概率重要度、不确定性、严重度、可检测性和控制可行性可能指向不同优先级。
Build the qualitative tree first. Freeze the event definitions and logic before loading numbers. For every probability, record its source, population, operating mode, mission time, unit, confidence interval, and treatment of censored data. Then run sensitivity cases rather than hiding weak evidence behind one precise-looking total.
先建立定性故障树。在填入数字之前，应先冻结事件定义和逻辑。每个概率都要记录其来源、参考总体、运行模式、任务时间、单位、置信区间以及删失数据处理方式。随后进行敏感性情景分析，不要用一个看似精确的总概率掩盖薄弱证据。
Model dependencies, common causes, and sequence explicitly显式建模依赖、共因与事件顺序
Independence is often the most consequential assumption in a quantitative fault tree. Two redundant pumps may share power, cooling, suction piping, software, configuration data, maintenance crews, test procedures, or environmental exposure. Multiplying their individual failure probabilities as if they were independent can therefore understate risk. During each review, ask what could defeat several branches at once and add that common cause as an explicit basic or intermediate event. Repeated events should use the same identifier and source data wherever they appear so that cut-set calculations do not count them as unrelated failures.
独立性通常是定量故障树中影响最大的假设。两台冗余泵可能共用电源、冷却、吸入管道、软件、配置数据、维护人员、测试程序或环境暴露。因此，若把它们当作独立事件并直接相乘，可能低估风险。每次复核都应追问哪些因素能同时击穿多个分支，并把该共因显式添加为基本事件或中间事件。重复事件无论出现在哪里，都应使用相同标识符和来源数据，避免割集计算把它们误当作互不相关的失效。
A beta-factor or conditional-probability model can represent dependency only when its parameter has a defensible basis. If evidence is sparse, show a bounded scenario range and identify which observation would narrow it. Do not silently choose a generic common-cause factor. Document whether the estimate comes from fleet experience, a reliability database, testing, expert elicitation, or a conservative engineering assumption. Preserve that provenance beside the model rather than only in a separate calculation workbook.
只有参数依据充分时，才能用 β 因子或条件概率模型表示依赖关系。证据稀少时，应给出有边界的情景范围，并说明哪项观测能够缩小范围；不要默默套用通用共因系数。应记录估计值究竟来自机群经验、可靠性数据库、测试、专家判断，还是保守工程假设，并把该溯源信息保存在模型旁，而不是只留在独立计算表中。
Static AND and OR gates also lose information when order, timing, standby behavior, repair, or recovery changes the outcome. For example, “sensor fails before demand” differs from “sensor fails after the operator has already isolated the train.” Represent such cases with sequence-enforcing gates only when the selected method supports them, or link the fault tree to an event tree, Markov model, or dynamic FTA. State which behaviors the chosen model omits. A simpler transparent tree with explicit limitations is safer than a complex diagram whose semantics reviewers cannot verify.
当事件顺序、时间、备用状态、维修或恢复会改变结果时，静态 AND 和 OR 门也会丢失信息。例如，“传感器在需求前失效”与“操作员已隔离列车后传感器失效”并不相同。仅在所选方法支持时使用顺序约束门，否则应将故障树与事件树、马尔可夫模型或动态 FTA 关联，并明确所选模型忽略了哪些行为。一个限制说明清楚的简单模型，比语义无法复核的复杂图更安全。
Treat model boundaries as another dependency decision. External utilities, upstream commands, downstream relief paths, and operator response are not safely excluded merely because a different team owns them. Mark every boundary interface, identify the assumed state on the other side, and assign an owner to verify it. If an interface is represented by one summary event, maintain a linked decomposition or evidence record so reviewers can see what that event contains. During change control, compare event identifiers and interfaces—not just the drawing—because a renamed component, revised test interval, or new software dependency can invalidate several branches at once. Finally, keep qualitative and quantitative approvals distinct: an engineer may accept the causal logic while rejecting the probability data. Recording those two decisions separately makes later updates targeted, auditable, and less likely to preserve an outdated numerical conclusion.
还应把模型边界视为一种依赖决策。外部公用工程、上游命令、下游泄压路径和操作员响应，不能仅因归属其他团队就被安全排除。应标记每个边界接口，说明另一侧的假定状态，并指定负责人验证。若用一个汇总事件表示接口，应维护关联的分解模型或证据记录，使复核者能看清其包含内容。变更控制时应比较事件标识符和接口，而不只是图形；部件改名、测试周期调整或新增软件依赖都可能同时使多个分支失效。最后，把定性和定量批准分开：工程师可能接受因果逻辑，却不接受概率数据。分别记录两项决定，能让后续更新更有针对性、更可审计，也不易保留过时的数值结论。
What resources, commands, locations, people, procedures, or data are shared? Can one initiating condition create several basic events? Does detection or recovery depend on the same resource that failed?
哪些资源、命令、位置、人员、程序或数据被共用？一个始发条件能否产生多个基本事件？检测或恢复是否依赖已经失效的同一资源？
Which inputs dominate the result range? Would a plausible alternative reverse the control priority? Record low, base, and high cases, then direct new testing toward assumptions that could change the decision.
哪些输入主导结果范围？合理的替代值是否会反转控制优先级？记录低、基准和高情景，并把新增测试投向可能改变决策的假设。
Fault tree analysis vs FMEA, fishbone, and event trees故障树分析与 FMEA、鱼骨图、事件树的区别
| Method方法 | Direction方向 | Best question最适合的问题 | Main limitation主要局限 |
|---|---|---|---|
| FTA | Top-down, deductive自上而下、演绎 | What combinations can cause this top event?哪些组合会导致这个顶事件？ | Coverage depends on model completeness and assumptions覆盖度依赖模型完整性与假设 |
| FMEA | Bottom-up, inductive自下而上、归纳 | What effects follow from each failure mode?每个失效模式会产生什么后果？ | Complex combinations may be difficult to expose难以揭示复杂事件组合 |
| Fishbone鱼骨图 | Category-based exploration按类别探索 | What plausible causes should we investigate?应调查哪些可能原因？ | Brainstormed branches do not prove causal logic头脑风暴分支不能证明因果逻辑 |
| Event tree事件树 | Forward from an initiating event从初始事件向前 | What outcomes follow as safeguards succeed or fail?保护措施成功或失败后会产生什么结果？ | Needs a defined initiating event and branch probabilities需要明确初始事件与分支概率 |
The methods are complementary. FMEA can supply component failure modes to an FTA; FTA can reveal combinations that an FMEA table obscures. A fishbone diagram can widen hypothesis generation before an evidence-focused fault tree. An event tree can begin where a fault tree ends, exploring consequences after the initiating event.
这些方法可以互补。FMEA 可向 FTA 提供部件失效模式，FTA 则能揭示 FMEA 表格难以呈现的组合。鱼骨图可在证据导向的故障树之前拓宽候选原因；事件树可从故障树结束处继续，分析初始事件发生后的后果。
Analyze the evidence behind your fault tree分析故障树背后的关联证据
Before opening a workspace, prepare the top-event statement, event IDs, branch assumptions, equipment or process records, timestamps, logs, measurements, inspection documents, and questions that would confirm or reject each branch. InfiniSynapse supports AI-assisted analysis across connected databases, files, documents, audio, and video. It is not presented here as dedicated FTA modeling or certified safety software; use it to explore relationships and assemble supporting evidence, then create and approve the formal fault tree in your governed engineering process.
打开工作区前，请准备顶事件陈述、事件 ID、分支假设、设备或流程记录、时间戳、日志、测量、检查文档，以及可确认或排除各分支的问题。InfiniSynapse 支持跨关联数据库、文件、文档、音频和视频的 AI 辅助分析。本页不把它描述为专用 FTA 建模工具或经过认证的安全软件；可用它探索关系并整理支持证据，再在受治理的工程流程中创建和批准正式故障树。
Analyze connected FTA evidence in InfiniSynapse在 InfiniSynapse 中分析关联 FTA 证据Common fault tree analysis mistakes and limitations故障树分析的常见错误与局限
- Vague top event: different reviewers build different trees because the threshold, operating state, or time window is missing.顶事件模糊：缺少阈值、运行状态或时间窗口，导致不同复核者构建不同的树。
- Gate-by-appearance: analysts choose AND or OR to shape the diagram rather than reflect necessary and sufficient system logic.按外观选门：分析者为了图形形状选择 AND 或 OR，而非反映系统的必要与充分逻辑。
- False independence: redundant components may share power, environment, software, maintenance, suppliers, or human actions.错误独立假设：冗余部件可能共享电源、环境、软件、维护、供应商或人员操作。
- Stopping at labels: “human error,” “software,” or “equipment failure” is not a useful basic event without a testable state and stopping rationale.停在标签：若没有可检验状态和停止理由，“人为错误”“软件”或“设备故障”都不是有用的基本事件。
- Precision without evidence: long decimal results do not compensate for sparse data, incompatible units, uncertain mission time, or omitted branches.无证据的精确：再长的小数也无法弥补数据稀疏、单位不一致、任务时间不确定或分支遗漏。
- Model treated as proof: a logically valid tree can still be factually wrong. Incident branches require corroboration and counterevidence.把模型当证据：逻辑有效的树仍可能事实错误，事故分支必须有佐证与反证检查。
Validate the fault tree before using its result使用结果前验证故障树
- Logic review: read every gate as a sentence; confirm that inputs are immediate causes and collectively explain the output.逻辑复核：把每个逻辑门读成一句话，确认输入是直接原因且共同解释输出。
- Boundary review: check interfaces, support systems, external events, maintenance states, software, and human actions.边界复核：检查接口、支持系统、外部事件、维护状态、软件和人员操作。
- Data review: trace each input to its source, units, population, mission time, confidence interval, and applicability.数据复核：追溯每项输入的来源、单位、总体、任务时间、置信区间和适用性。
- Dependence review: search for common-cause, conditional, sequential, and mutually exclusive relationships before using simple formulas.依赖复核：使用简单公式前查找共同原因、条件、顺序和互斥关系。
- Sensitivity review: vary uncertain probabilities and modeling choices; report which assumptions change priorities.敏感性复核：改变不确定概率和建模选择，并报告哪些假设会改变优先级。
- Outcome verification: after controls change, monitor the top event, precursors, tests, bypasses, and unintended consequences.结果验证：控制措施变更后，监测顶事件、前兆、试验、旁路和非预期后果。
NASA describes FTA as starting with a postulated undesired end event and examining events that can lead to it. For deeper construction and validation guidance, consult the NASA Fault Tree Handbook with Aerospace Applications and the NASA procedural description of Fault Tree Analysis. Apply the standards and qualified review required by your own industry and jurisdiction.
NASA 将 FTA 描述为从假定的不期望终止事件出发，检查可能导致该状态的事件。若需深入了解构建与验证，可查阅 NASA《航空航天应用故障树手册》和 NASA 关于故障树分析的程序说明。实际项目仍应遵循所属行业和司法辖区要求的标准与合格复核。
Frequently asked questions about fault tree analysis故障树分析常见问题
What is fault tree analysis used for?故障树分析用于什么？
Fault tree analysis is used to explain how combinations of component failures, human actions, environmental conditions, or control failures can produce one defined undesired top event. It supports qualitative path analysis and, when credible probability data and assumptions are available, quantitative risk estimation.
故障树分析用于解释部件失效、人员行为、环境条件或控制失效的组合如何产生一个已定义的不期望顶事件。它支持定性路径分析；当概率数据和假设可信时，也支持定量风险估计。
What is the difference between an AND gate and an OR gate in FTA?FTA 中 AND 门与 OR 门有何区别？
An AND gate means every input event must occur for the output event to occur. An OR gate means any one input is sufficient. The choice must describe the real system logic, not simply make the tree look balanced.
AND 门表示所有输入事件都必须发生，输出事件才发生；OR 门表示任一输入发生就足够。选择必须描述真实系统逻辑，不能只是为了让树看起来平衡。
How do you calculate fault tree probability?如何计算故障树概率？
For independent inputs, an AND gate multiplies input probabilities, while an OR gate uses one minus the product of each input's complement. Rare-event sums may approximate an OR gate, but exact equations, shared causes, dependence, mission time, and data uncertainty must be reviewed.
对独立输入，AND 门将输入概率相乘；OR 门使用一减去各输入补集概率的乘积。稀有事件求和可近似 OR 门，但仍须复核精确公式、共同原因、依赖、任务时间和数据不确定性。
How is fault tree analysis different from FMEA?故障树分析与 FMEA 有何不同？
FTA is deductive and starts with one top event, then works backward through combinations that can cause it. FMEA is inductive and starts with component or process failure modes, then evaluates their effects. The methods are complementary and can cross-check coverage.
FTA 是演绎方法，从一个顶事件开始，向后分析可能导致它的事件组合；FMEA 是归纳方法，从部件或流程失效模式开始，再评估其影响。二者互补，可相互检查覆盖范围。
Can fault tree analysis prove the root cause of an incident?故障树分析能证明事故根因吗？
No. A fault tree is a structured causal model, not proof. Incident investigators must test branches against logs, measurements, inspections, interviews, change records, and counterevidence, then verify that corrective controls reduce recurrence without unacceptable side effects.
不能。故障树是结构化因果模型，不是证据本身。调查人员必须用日志、测量、检查、访谈、变更记录和反证检验分支，并验证纠正控制能否降低复发且不产生不可接受的副作用。
Best practices and next steps最佳实践与下一步
Keep a versioned model with named owners, source references, open assumptions, rejected branches, and review dates. Separate the qualitative tree from the quantitative calculation so reviewers can challenge logic without being distracted by decimals. Use independent review for consequential decisions, and reopen the model when the architecture, operating mode, evidence, or event history changes.
应保存带版本的模型，记录负责人、来源引用、待决假设、已排除分支和复核日期。把定性故障树与定量计算分开，使复核者能专注质疑逻辑，而不被小数结果干扰。重要决策应采用独立复核；当架构、运行模式、证据或事件历史变化时，应重新打开模型。
For broader method selection, compare the InfiniSynapse tools directory and the InfiniSynapse data and analytics blog. Choose a dedicated, validated FTA application when you need formal diagram notation, cut-set solvers, importance measures, change control, or regulated reporting; use connected-data analysis to support the evidence workflow, not to substitute for governed engineering approval.
如需更广泛的方法选择，可查看 InfiniSynapse 工具目录与 InfiniSynapse 数据与分析博客。当项目需要正式图形符号、割集求解、重要度计算、变更控制或受监管报告时，应选择经过验证的专用 FTA 应用；关联数据分析用于支持证据流程，不能替代受治理的工程批准。
Official sources and verification notes官方来源与验证说明
These sources support the method definitions, gate logic, and review discipline described here. Before operational use, revalidate notation, data, independence assumptions, mission time, acceptance criteria, and reporting obligations against the standards and procedures governing your industry and site.
这些来源支持本文的方法定义、逻辑门规则与复核纪律。投入实际使用前，仍须依据所在行业和现场适用的标准与程序，重新验证符号、数据、独立性假设、任务时间、验收准则与报告义务。