Bow Tie analysis gives safety engineers and stakeholders a single view of a risk scenario: what can trigger the critical event, what can stop it, and what can reduce its consequences. The method becomes much stronger when the two sides of the diagram are not drawn from intuition alone. Fault Tree Analysis (FTA) can define the preventive side, while Event Tree Analysis (ETA) can define the mitigation side. Together, they turn the Bow Tie from a communication diagram into a traceable safety argument.
Why FTA and ETA Belong Together
FTA and ETA look at the same scenario from opposite directions. Fault Tree Analysis starts with an undesired top event and works backward to identify the combinations of basic events, component failures, or functional failures that can cause it. Gates such as AND and OR make the logic explicit, and the tree can support probability calculations, cut set analysis, and single-point-of-failure checks.
Event Tree Analysis moves in the other direction. It starts from the critical event and follows the possible outcomes as barriers succeed or fail. Those barriers may be technical, procedural, operational, or organizational. If mitigation works, the scenario may move toward a controlled outcome. If mitigation fails, the same initiating event may progress toward a severe consequence.
The Bow Tie sits between these two analyses. Its center is the critical event. On the left, the FTA explains how that event can occur. On the right, the ETA explains what happens after it occurs. The Bow Tie view is not a replacement for either tree; it is the map that connects them. It set the focus at the critical event, where the FTA meets the ETA.
The Bow Tie Analysis Core: The Critical Event
The critical event plays a different role depending on the analysis perspective:
- FTA: the critical event is the top event.
- Bow Tie Analysis: the critical event becomes the center of the analysis.
- ETA: the critical event becomes the initiating event.
The name changes with the method, but the modeled scenario should remain the same.
Fault Tree Analysis, the left side of the Bow Tie
A detailed Bow Tie can preserve the FTA logic. In this view, the left side is not a simplified list of causes. It is the causal model that explains how the critical event can occur.
The top event of the FTA is the same event placed at the center of the Bow Tie. Below it, each branch records a causal path that may involve hardware failures, functional failures, software faults, data-processing errors, environmental conditions, or latent design assumptions. The gates matter because they define the difference between alternative causes and combinations of causes. An OR gate says that one downstream event is enough. An AND gate says that the effect only appears when several events occur together.
That structure is what makes the preventive side technically useful. A barrier that looks independent in a shallow Bow Tie may depend on the same power supply, processor, sensor input, or communication path as another barrier. When the FTA remains visible, those dependencies can be reviewed through the tree logic and through the resulting cut sets. Minimum cut sets are especially useful because they show the smallest combinations of failures that can produce the critical event, including potential single points of failure.
Transfer gates and referenced subtrees help keep the analysis manageable without removing detail. A repeated power-supply failure, monitoring function, or shared communication path can be developed once and referenced where it appears in the broader tree. The Bow Tie can therefore remain complete while still being easily navigable.
The important point is that the left side of the Bow Tie should carry the evidence for the critical event, not just name the causes.
Event Tree Analysis, the right side of the Bow Tie
The right side of the Bow Tie is the Event Tree Analysis. It should capture the possible consequence paths after the critical event, including the success or failure of barriers such as detection, annunciation, automatic reconfiguration, crew procedures, containment, isolation, or recovery logic.
Each ETA branch carries a conditional assumption: given that the critical event has occurred, what is the probability that the procedure is applicable, recognized in time, correctly performed, and effective?
Some ETA events can be developed through their own FTAs. If an automatic reconfiguration function depends on sensors, software tasks, processing hardware, communication links, and power supply, that barrier deserves its own internal logic. Treating it as a single independent probability can be misleading once the design is mature.
This is one reason a detailed Bow Tie should preserve the evidence behind each barrier. The diagram can show the barrier name, but the safety argument also needs the FTA, ETA, architectural element, requirement, test case, operational procedure, or safety assessment artifact that justifies it.
Quantitative Integration
The quantitative connection is straightforward in principle. The FTA calculates the probability or rate of the critical event. The ETA then uses that value as the initiating event input. Each outcome branch combines that initiating input with the conditional probabilities of barrier success or failure along the path.
\(\)
\( P(consequence \space path) = P(critical \space event) \cdot P(barrier \space A \space outcome | critical \space event) \)
\( \cdot P(barrier \space B \space outcome | previous \space branch \space state) \cdot … \)
In this expression, P(critical event) comes from the probability of the top event of the Fault Tree.
The important part is not the multiplication itself. It is the conditional wording. Barriers are not automatically independent. A preventive barrier and a mitigation barrier may share a power supply, processor, sensor input, software requirement, maintenance task, or human operator. If those dependencies are ignored, the analysis may hide a common cause failure.
Cut sets on the FTA side and branch assumptions on the ETA side should therefore be reviewed together. If the FTA identifies a shared basic event, the ETA should not assume that a mitigation function depending on the same element remains fully available.
Practical Pitfalls When Building the Bow Tie
The first trap is making the Bow Tie visually clean but technically thin. A complete joint FTA and ETA can produce a large diagram, and that is not automatically a problem. For engineering review, a technically rich Bow Tie supported by SVGs, zoom, tables, and referenced subtrees is often more useful than a compact diagram that hides the logic.
The second trap is generic barriers. Labels such as ‘training’, ‘maintenance’, ‘redundancy’, and ‘procedure’ can look complete even when none of those barriers traces to actual functions, equipment, tasks, or requirements. Safety engineers should be able to ask where the barrier lives in the design and what evidence shows that it works. They should also challenge independence assumptions, especially when several barriers rely on the same enabling resource.
The third trap is treating the analysis as permanently valid. A Bow Tie built from FTA and ETA is still a snapshot. If a port is modified, a redundant channel is removed, a software task moves to a different processor, or a crew procedure is rewritten, the safety team should review the affected barriers. For systems with time-dependent behavior, reconfiguration, repair, or operational state changes, complementary methods such as Markov analysis may also be necessary.
Model-Based Bow Tie Analysis and the Digital Thread
The long-term value of this combined method increases when the Bow Tie, as a combination of the FTA and ETA, is part of a model-based engineering environment. Static diagrams and spreadsheets can be useful, but they often break the connection between architecture, failure logic, requirements, procedures, and verification evidence.
In a model-based workflow, the critical event can be linked to a hazard, failure condition, or hazardous event in the system model. Preventive barriers can trace to physical components, software functions, monitors, redundancies, or design requirements. Mitigation barriers can trace to procedures, displays, alerts, operational modes, or recovery functions.
Anzen’s Model Based Safety Analysis article on ARP4761A argues that a model-based approach can connect safety analysis to the same engineering models that describe structure and behavior. This also applies to Fault Tree Analysis, where analysts can link lower-level failure modes to model elements when evaluating a failure condition.
The implementation mechanism depends on the modeling environment. SysML workflows may use profiles, tables, and plugins. Capella workflows may use viewpoints, add-ons, and metamodel extensions. External analysis services can also connect the model to solvers or reporting pipelines. An example of this can be found in Implementing domain-specific workflows in Cameo, where an MBSE tool is adapted to a specific engineering process.
SysML v2 makes this direction especially relevant because OMG’s formal SysML 2.0 specification includes textual and graphical representations, formal semantics, and a standard API intended to support interoperability across the digital engineering ecosystem. Nevertheless, that does not remove the need for a safety methodology that defines safety concepts and exchange interfaces, so analysts can query FTA and ETA events, failures, requirements, and verification evidence consistently across tools. Without that safety metamodel and governance, SysML v2 is only another modeling format.
Example: A Test-Found Aircraft Fault
Consider a simplified aircraft scenario. During testing, engineers identify an intermittent fault that can produce an erroneous input to a flight-control function. A traditional analysis might calculate the probability of that fault as an FTA top event and stop there. That is useful, but it can miss what happens after the event occurs.
In this case, the critical event is “erroneous input remains active at the flight-control function”. This is the point where the fault has propagated far enough to matter, but before it determines the final aircraft-level consequence.
The ETA would then ask what happens next. Does built-in monitoring detect the erroneous input? Does the system reject the affected channel? Is an alert presented to the crew? Does the Aircraft Flight Manual contain a procedure for this condition? Can the crew execute the procedure within the available time? Does a reversionary mode maintain sufficient controllability?
Each answer creates a branch. The most favorable path may end with no operational effect or a minor workload increase. A less favorable path may lead to degraded operation. The most severe path may require further analysis against the relevant failure condition and safety objective. This joint view recognizes that the probability of the initiating failure is only one part of the risk; detection, rejection, procedure, reconfiguration, and crew response also shape the final consequence.
Final Takeaway
Combining FTA and ETA gives Bow Tie analysis a stronger engineering foundation. The FTA explains how the critical event can occur. The ETA explains how the scenario can evolve after that event. The Bow Tie connects both sides in a format that supports communication, review, and decision-making.
The method works best when it preserves technical completeness rather than forcing the diagram to stay visually minimal. Each cause, barrier, and consequence should point to the artifact that justifies it: a fault tree, event tree, requirement, design element, FMEA item, or procedure. Assumptions about barrier probabilities, independence, human response, and operational states should also stay visible enough to review.
If your team is building Bow Tie analyses from disconnected diagrams and spreadsheets, the next improvement may not be a prettier diagram. It may be a better connection between FTA, ETA, architecture, and safety evidence. Anzen can help evaluate how that connection could work in an MBSE environment and how tools such as ATICA can support model-based safety analysis from the system model to the safety case.
About the author
Samuel García is an aeronautical engineer with experience in Safety and Reliability engineering, focusing in recent years on the model-based safety analysis.
At Anzen, Samuel operates across two main roles: leading or supporting industrial projects as a consultant, and contributing to the digital engineering department by channeling real industrial needs into ATICA development and its broader activities.
