Why We’re Technically the Best: Key Takeaways From Our Latest Webinar

In our most recent webinar, I had the pleasure of joining forces with two of my brilliant colleagues, David Wiseman and Rachel Evans, to explore a bold but accurate topic: why our tools stand at the top of the market from a technical perspective.

It’s a big claim, sure. But after years of guiding thousands of evaluations, helping customers compare options, and watching technology evolve, we've developed a deep understanding of what real-world engineering teams need, and how to build software that genuinely supports them.

Below is a recap of the session, including the concepts David demonstrated and answers to some excellent questions we received during the live event.

Experience That Shapes the Tools

Our team has collectively spent decades helping engineers evaluate Fault Tree Plus and our Reliability Workbench suite. Through that work, we've seen just about every scenario, requirement, constraint, and head-scratcher imaginable.

This history gives us something rare:
A wide-angle view of how people are actually doing fault tree analysis, not only how they theoretically should. That perspective directly shapes our features, our UI decisions, and our roadmap. It’s one reason we confidently say our tools are built on deep technical insight, not buzzwords or guesswork.

Highlights From David’s Technical Demonstration

David walked through several advanced capabilities in Fault Tree Plus that help engineers analyze complex systems with flexibility and precision.

1. Partial Analysis – Because Sometimes You Only Want the Essentials

Instead of recalculating an entire fault tree, you can choose specific gates and run analysis only on those. This is especially valuable for massive models where waiting for full-tree calculations feels like waiting for a tax refund.

Engineers can select:

• Two gates

• Ten gates

• Or any custom grouping

…run the partial analysis and get instant insights into just the portions that matter.

2. Sensitivity Analysis – Understanding the Impact of Change

One attendee asked if sensitivity analysis can adjust repair times using fixed numeric values rather than percentages.

• Sensitivity uses multipliers, not absolute increments.

• You can define values (e.g., 5 steps), and the tool applies multipliers such as 0.01, 0.11, 1.01, and so on.

• This applies to failure rates, repair rates, and repair times.

A practical example:
If you're evaluating a safety mechanism that checks for faults every few milliseconds, you can increase or decrease the test interval and instantly see the effect on system availability. This feature also works beautifully for manual inspections in process safety systems.

3. Understanding the Rare Approximation in Importance Analysis

Another great question touched on the difference between the Rare approximation option in custom calculation settings and the “Use Rare Approximation” checkbox under Importance calculations.

Here’s the short version David explained:

• Importance metrics (such as Fussell-Vesely) require calculating the top event probability multiple times.

• Without approximation, the tool might have to perform full fault tree calculations two or three times, which gets costly for large trees.

• The Rare approximation speeds this up by estimating these recalculated results without performing the entire computation again.

For most fault trees, this approximation still delivers highly reliable insight while dramatically cutting computation time.

Your Participation Keeps These Webinars Valuable

We had a big turnout again, thank you to everyone who joined live and asked such thoughtful questions. These sessions have grown in popularity, and we truly appreciate the engagement.

Until next time,
Jeremy

VP America's Business Development

http://www.isograph.com

jeremy.hynek@peakavenue.com

Q&A from the webinar:

How can the following problem be solved: I have a CCF below a modularized gate, but i cannot NOT modularize the gate, because i need the gate multiple times (x20), so I´m using the option "Quantity" (which is only available, if the gate is modularized)	There is no way to have a CCF shared across multiple, modularized gates. However, there could be a workaround if the CCF is sufficient to fail the gate on its own. Place the modularised gate beneath an OR gate along with an event to represent the CCF. This CCF may be copied to other, similar OR gates above the other modularised gets in the tree. Give the CCF event failure parameters consistent with the calculated probability of the CCF model.
Hi, can we say that Fault tree analysis is better than RBD analysis	To some extent it depends on the application, as RBD is often considered more intuitive for system availability analyses, especially where process is concerned. However, FTA does have more comprehensive logic. For example, it is better able to handle sequencing and NOT logic with gates like NOT, XOR and PAND.
How does the Cross Product Calculation differ from Esary-Proschan's Min Cut Upper Bound calculation?	The cross product is a method that is based on the addition law of probability, whereas the Esary Proschan (EP) is based on the product law. In the latter case, the program works out the probability of each cut NOT happening (1-cut set prob) and multiplies the value to get the probablity og no cut sets occuring. This is then subtracted from 1 to get the probability that at least one set happens. However, the key difference is that the cross product includes a step to remove repeated events from the product terms using Boolean algebra, thus accounting for dependency between sets. EP does not have this step, which is why it can drift above the correct answer for trees with events that appear in multiple sets.
Hi ! Is that possible (or do you plan to make it possible) to get a feature to identify in which top level fault tree contributes each basic event (and at which order)? (for example: SELV_JAMMED_CLOSED => TP1_FAULT_TREE (order 1), TP3_FAULT_TREE (order 4), …	This may be covered by the Appearance data. Open the results summary and select a TOP gate. Select the Appearance option in the middle of the dialog. This window will list all the events that contribute to the selected gate, how many sets it appears in, and of what order. This data can be exported to a CSV file for further analysis.
Under the approximation custom options one of the options is the rare approximation as discussed.  On the Calculation tab of the project properties dialog there is a check box labeled “Use rare approximation” under “Importance calculations”.  What is the difference between these?	Many importance measures, such as Fussel Vessely and Birnbaum, require the program to essentially recalculate the gate probability, either using adjusted imports or after concelling some terms. By selecting the Rare approx for importance it speeds up these calculations. Some accuracy is lost, but this is not the priority for importtance. Instead, what matters is the relative value for each event.
Does Isograph perform RBD modeling of software systems distributed in multi-region and multi-AZ deployment patterns? The determination of this will be essential in making the adoption decision of Isograph. Furthermore, could you please organize a workshop on RBD modeling?	We have users who model computer systems and data centres using RBD. We have 2 RBD modelling tools depending on requirements. The RBD tool in Reliability Workbench uses Boolean and probability analysis (similar to FTA) whereas the RBD tool in Availability Workbench uses (Monte Carlo simulation, which is useful for modelling complex maintenance strategies, etc. We can look into providing a similar webinar or workshop for these tools, too!
Can Sensitivity be used to increase the repair times by a number rather than a percentage? I am thinking about the impact that mobilization times may have in the overall availability of a system.	It is not possible to adjust MTTR or repair rate to an absolute value, though it is not adjusted to/by a % either. The adjustment factors are multiplicative, so it should be possible to choose the repair values you want to try by selecting the multiplying factors accordingly.
Can you show how we can have separated subtrees, that we evaluate separately and then add / link to a larger system tree?	Individual gates may be analysed separately of the rest of the tree by checking the partial analysis box in the gate properties and selecting Perform Partial Analysis in the Analysis menu. In Reliability Workbench, it is not possible to feed this result to a tree in a different project file, though it can be appended to another tree using the append facility. However, the PeakAvenue platform will allow users to link one tree to another so that results are passed on for further analysis.
But can we import partial analysis in different larger trees? For instance I might have a upper system, but implementing different version of an equipment, so I would have a FTA for each version of that equipment	See above. Trees can be appended, but for a 'true link' this will be implemented in the PeakAvenue Platform.
Can we import data from FIDES analysis ?	Yes. It is possible to licence the FIDES handbook in the Prediction part of Reliability Workbenh and pass calculated failure rates to a FTA.
FIDES is available in the RWB Prediction module.
Are these .rwb files available to download so we can poke around in them ourselves?	The files used in this webinar are supplied with the Reliability Workbench installation. If you download and install the demo version you will find the FaultTreeReactor.rwb file in the Projects directory.
Was the Fussell-Vesely bar graph created with the Isograph reports tool? Have there been webinars presented on use of the parts library and creation of reports?	The FV plot is from the plot view of Reliability Workbench. Select the Plot button above the diagram. Then, select Importance from the menu to the right of the buttons. Click the Plot Options button and select a gate for the plot then click OK. Future webinars may cover these topics, though I believe there is an instructional video on reports on the Isograph Software YouTube channel.

Terrified of Failures? Simulation Can Help.
By Jeremy Hynek

When engineers hear the word failure, it’s rarely met with enthusiasm—especially when that failure has a price tag attached. In our recent webinar, Terrified of Failures, we explored how simulation tools can help engineers confront—and even embrace—failure by modeling it before it happens.

I was joined by Dr. David Wiseman, who walked us through practical techniques using Isograph’s Availability Workbench, including AVSIM and RCM Cost, to optimize systems with cost and availability in mind. Also supporting the discussion were Rachel Evans from our UK office and Joe Belen from the US.

Why “Terrified of Failures”?
The title was meant to be a fun play on words, but it reflects a real concern in today’s engineering landscape. Rising global costs—from tariffs to inflation and supply chain delays—are forcing teams to rethink how they manage system performance and cost-effectiveness. Gone are the days of simply adding a buffer; now, you need to simulate different paths and choose the smartest one.

Final Thoughts
Failures don’t have to be terrifying—when you’re prepared for them. With the right modeling tools, you can simulate worst-case scenarios, test alternative strategies, and make confident, cost-effective decisions.

Thank you to everyone who attended, and a special thanks to David, Rachel, and Joe. If you have follow-up questions or ideas for future webinars, we’d love to hear from you.

Stay tuned for more insights from Isograph and PeakAvenue. Until next time!

In our latest session, Dr. David Wiseman and I explored the evolving role of AI in fault tree analysis. Unlike past webinars that covered foundational topics, this one dove into advanced modeling techniques—like sequencing, spurious trips, common cause failures, and priority AND gates—and examined how AI can assist (but not replace) the human engineering process.

We argued that while AI can help with review, consistency, and spotting hidden risks, it lacks traceability and engineering context—critical for safety-critical applications. As David put it, building a fault tree is not just a task—it’s a learning process, one that AI should support, not shortcut.

If you have any questions for us, please feel free to contact me.

Jeremy Hynek 

Director Business Development

jeremy.hynek@peakavenue.com 

801 610 0049

Is MTBF Misleading You? Avoid Costly Reliability Mistakes

Mean Time Between Failures (MTBF) is one of the most widely used reliability metrics—but also one of the most misunderstood. It’s often seen as a simple way to assess system reliability, but in reality, it can create false expectations, flawed maintenance strategies, and costly decision-making errors.

Many engineers, managers, and decision-makers rely on MTBF without fully understanding its limitations. While it provides a rough estimate of expected failures over time, it does not predict when failures will occur or how a system will behave in real-world conditions. The result? Misleading reliability assessments, unnecessary maintenance costs, and unexpected downtime.

In this webinar, we’ll break down the biggest misconceptions about MTBF and discuss why using it as the sole reliability indicator can be risky. More importantly, we’ll explore practical alternatives and complementary methods to improve failure predictions and optimize maintenance strategies.

What You’ll Learn:

• The fundamental flaws of MTBF and why it can be misleading
• How relying solely on MTBF can lead to unexpected failures and increased costs
• Real-world examples of MTBF
• How to use MTBF with tools like Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA), and other reliability tools provide more accurate insights

Whether you’re a reliability engineer, maintenance professional, or decision-maker looking to enhance system performance, this webinar will give you the tools and insights needed to move beyond MTBF and make more informed reliability decisions.

Don’t let misleading metrics drive your decisions—register now to gain actionable insights into better reliability analysis!

If you have any questions, I would love to hear from you! Please feel free to contact me.

Jeremy Hynek

Director Business Development

801 610 0049

Mobile: 949 813 1284

jhynek@isograph.com

https://www.peakavenue.com

Cybersecurity through Attack Tree Logic webinar introduction: In an age where digital systems are integral to every facet of our lives—from personal vehicles to national power grids—understanding potential cyber threats is more important than ever. Businesses, governments, and individuals alike need robust frameworks to anticipate and mitigate attacks before they happen. One such framework is Attack Tree Logic, a structured methodology that borrows from the principles of fault tree analysis to model and quantify cybersecurity risks.

List of topics covered in this webinar:

What Is Attack Tree Logic?
Attack Tree Logic is a systematic approach for identifying how malicious actors might achieve their goal of compromising a system. Originally inspired by safety and reliability methods like fault tree analysis, attack trees help break down complex security threats into logical hierarchies. At the top sits the attacker’s ultimate objective—such as gaining unauthorized access to a vehicle’s onboard computer. Beneath that goal lie intermediate objectives, potential vulnerabilities, and specific tactics an attacker might use.

Why Use Attack Trees for Cybersecurity?
While cybersecurity threats differ from traditional reliability or safety failures, the logic-based approach that has long been standard in engineering still applies. Attack trees provide:

1. Clarity and Structure: Rather than viewing a system’s security as an opaque challenge, attack trees map out potential intrusion paths step-by-step, making it easier to see where and how attackers might succeed.
2. Qualitative and Quantitative Insight: Initially, cybersecurity assessments were largely qualitative. Attack Tree Plus, a specialized software tool, extends this by integrating quantitative analysis. This helps security analysts assign probabilities to different attack scenarios and weigh their relative severity.
3. Informed Decision-Making: By ranking threats based on likelihood and impact, organizations can prioritize their security investments. For instance, if one attack path is more likely (due to easier access or lower skill requirements), it becomes the priority for mitigation.

Building an Attack Tree: A Practical Example
Consider a modern vehicle equipped with a sophisticated onboard computer. Researchers have shown that attackers could potentially gain access to vehicle systems through either the in-car entertainment system or an unsecured onboard diagnostic (OBD) dongle. An attack tree for this scenario might look like this:

• Goal (Top Event): Attacker gains unauthorized access to the onboard computer.
  • Objective 1: Access via the entertainment system.
    • Potential Consequence: Unexpected braking or acceleration at low speed (a serious safety issue).
    • Required Conditions:
      • Specialized attack equipment and expertise.
      • A known vulnerability (e.g., an outdated security patch) in the entertainment software.
  • Objective 2: Access via the OBD dongle.
    • Potential Consequence: Malfunctioning or loss of function in lights and wipers (a moderate, but still significant, safety concern).
    • Required Conditions:
      • Availability of an unsecured OBD dongle in the vehicle.
      • A low-complexity attack, such as using a free mobile app to exploit that vulnerability.

By structuring the attack paths this way, security engineers can see both the direct routes (objectives) and the enabling factors (vulnerabilities, needed expertise, available tools) that make these attacks feasible.

Assigning Likelihood and Impact
One of the key advancements introduced by Attack Tree Plus is the ability to assign quantitative likelihoods based on real-world conditions. Instead of asking, “Could someone hack into the system?” analysts ask, “How likely is it given the skills, equipment costs, and time required?” Indicators such as the complexity of required knowledge, the availability of specialized tools, and the time window for the attack help assign a probability to each event.

For instance:

• Attacks requiring months of preparation, expert-level skill, restricted knowledge, and bespoke equipment are likely to have a low probability.
• Attacks that can be carried out quickly with readily available tools are more likely, bumping up their probability and making them more pressing risks.

Measuring Consequences and Risk
Attack trees also categorize outcomes by severity. Using standards such as ISO 21434 (common in the automotive industry), each identified consequence (e.g., loss of braking control) is given a weight indicating its severity. Combined with the attack likelihood, this severity weighting allows for a quantitative measure of risk.

• Major Consequences: Higher severity outcomes (like interfering with vehicle speed) might have stringent thresholds and higher risk scores.
• Moderate Consequences: Less severe, but still disruptive outcomes (like malfunctioning wipers), yield lower risk scores.

With these rankings, organizations can focus their efforts on mitigating the highest-risk attack paths first.

Adhering to Industry Standards
Different industries use various standards for assessing cybersecurity risk. From ISO 21434 in automotive cybersecurity to other frameworks like J3061, the Attack Tree Plus software supports a range of templates, each offering standardized likelihood, severity, and risk assessment scales. Companies can also customize these templates to align with internal security policies or emerging industry guidelines.

Beyond Cybersecurity: A Broader Framework
Though our example focuses on automotive cybersecurity, attack tree logic is flexible. It can be applied to a wide range of security contexts:

• Physical Security: Determining the most probable ways to break into a building, sabotage infrastructure, or steal critical assets.
• Supply Chain Security: Understanding how attackers might interfere with or exploit complex logistics systems.
• Financial Systems: Identifying how intruders might bypass controls in financial institutions.

Conclusion: A Proactive Approach to Security
Attack Tree Logic provides more than just a theoretical framework. By visualizing and quantifying threats, it empowers organizations to anticipate attacks, weigh their risks, and invest wisely in preventive measures. As cybersecurity threats evolve in complexity, tools like Attack Tree Plus serve as essential allies, helping analysts stay one step ahead of would-be attackers and ensuring the resilience and safety of today’s interconnected systems.

Next Steps and Resources
If you’re interested in learning more about Attack Tree Logic, consider exploring:

• Industry Standards: Check out ISO 21434 and J3061 for structured approaches to automotive cybersecurity.
• Software Solutions: Tools like Attack Tree Plus integrate seamlessly with other reliability and quality platforms, offering a complete suite for analyzing complex systems.
• Training and Consultation: Expert-led training sessions can further deepen your understanding, allowing you to build customized attack trees aligned with your organization’s unique risk landscape.
• Free Download: https://www.isograph.com/free-trial/

As we move into an era where cybersecurity and physical security converge, equipping yourself with robust analytical methods like Attack Tree Logic is no longer optional—it’s essential.

For many years we have received countless request for a self paced e learning option for the FaultTree+ course. Please note that although this course has not been completed it is nearing completion.

I am looking for any feedback or questions you might have.

Best Regards, Jeremy

Jhynek@isograph.com

I'm not going to lie I head up sales for Isograph in North America. I often get labelled with some of the tactics sales people use in my industry. The best advice I can give to a prospective client is to try models using your own data and information to see how they turn out. Also, check the calculations and software options to ensure the software product will do what you want it to do not only today but next year when your model has matured. Although I am a sales person and my lips are moving I'm not lying here.

Batch append is one of those points that one should consider in a mature software product. How are you going to combine the work of many individual engineers into a final model you can use for certification or to present to management? If your tool cannot do this run for the hills!

Sometimes, when working on a large system model, you need to share the load, and split up the fault tree development to different people. But then the time comes to combine everyone’s work together. How do we do that? And how do we make sure that our master fault tree contains the most up-to-date information from each engineer’s fault trees?

This excerpt from our in-development online training course gives a quick insight into using the Batch Append feature to automate the linking of fault trees from different user’s projects, and how to keep the linked file up-to-date with the latest changes.

Quick introduction:

Of course CAPEX will effect OPEX, or it should...or will it? The idea makes sense, however, at what point will a piece of equipment cost you more to maintain than it would cost to simply replace that piece of equipment? Should a refurbish be considered? How should a new plant be configured for the highest cost benefit? Not properly designing a system or not being willing to spend the money to replace equipment at the right interval could be costing you. By modelling your system in easy to use tools you can make logical decisions as well as justifying these decisions.

The next version of Reliability Workbench (13.0.2) has now been released. Join us for this special preview webinar to get an early look at the new features that have been added. From changes to the report viewer interface, updated Prediction stands, data linking to the Allocation module, new DLL functions, expanded IEC 61508 calculations for both the Fault Tree and FMECA modules, a new Fault Tree failure model, and a brand-new results dialog for the FMECA module, complete with ISO 26262 functionality, there’s plenty to get excited about.

As always if you have any questions about our software please feel free to contact me.

Best Regards, Jeremy

jhynek@isograph.com