Weird Things We’ve Modeled in AvSim

A while back, I was talking with David Wiseman from our UK office about one of the more unusual customer projects we’d seen: using Monte Carlo Simulation (AvSim) to track the availability of penguin trackers. That conversation turned into a much bigger discussion about all the strange, unexpected, and surprisingly creative things people have modeled in AvSim.

This got me thinking... I started wondering whether we could model the college football playoffs closely enough to predict actual game outcomes. At first, it sounded doable. Then we started listing everything we’d have to include:

• injuries
• player positions
• weather
• momentum swings
• fatigue
• coaching adjustments
• emotional factors
• live game updates

And somewhere in the middle of that conversation we both realized:
“Okay… this thing may never stop simulating.”

Oddly enough, it became a really good example of what AvSim is — and what it isn’t.

AvSim is incredibly powerful at modeling defined systems and reliability behavior. But trying to model a continuously evolving real-time system like a live football game introduces an entirely different level of complexity.

That discussion eventually became the inspiration for this webinar. But the webinar wasn’t really about penguins or us giving up on modeling the football playoffs. What we actually wanted to show was something much more useful: how engineers can think outside the box when modeling systems that don’t appear to fit neatly into the software.

One of the biggest lessons from years of reliability modeling was: Just because there isn’t a button for something doesn’t mean the software can’t do it.

Sometimes the best solutions come from understanding the logic of the system rather than looking for a specific feature.

Thinking Outside the Box

Just because there isn’t a built-in feature for something doesn’t mean it can’t be modeled. In this webinar David Wiseman demonstrates several examples where standard AvSim features can be combined in unconventional ways to create surprisingly advanced behaviors.

Our webinar focuses on four particularly interesting examples.

1. Modeling Complex Maintenance Cycles

Most reliability engineers are familiar with simple recurring maintenance:

• every 6 months
• every year
• every 5 years

But what happens when the maintenance strategy changes throughout the life of the system?

The webinar demonstrated how offsets, repeated maintenance tasks, rules, and phases can be combined to model evolving maintenance schedules such as:

• PM1 during years 1–3
• PM2 during year 4
• PM1 again during years 5–7
• PM3 later in the lifecycle

Instead of forcing the software into a rigid maintenance pattern, the model used cleverly staggered intervals and rules to create dynamic maintenance behavior over time.

The result:
A highly flexible maintenance strategy without requiring any new software functionality.

2. Changing Capacity Targets Without a Rule

One particularly interesting challenge involved changing a system’s production target depending on the phase of the system lifecycle.

The issue?
AvSim does not include a direct rule for changing capacity targets dynamically.

To achieve this capability, the webinar demonstrated a creative use of logic:
multiple output nodes with different capacity targets were selectively enabled or disabled using logic-state dummy blocks and phase rules.

In practice, this allowed the model to simulate:

• lower production targets during early years
• increasing demand during peak years
• ramp-down behavior later in life

It was a perfect example of modeling creativity:
using existing logic features in unexpected ways to achieve the desired system behavior.

3. Using Buffers as a “Clock”

Perhaps the most technically creative example involved ramp times.

The challenge:
How do you increase ramp-up time depending on how long the original outage lasted?

For example:

• outages under 8 hours → 1.5-hour ramp time
• outages between 8–48 hours → 3-hour ramp time
• outages over 48 hours → 6-hour ramp time

Since AvSim does not directly support conditional ramp times, the solution used buffers as timing mechanisms.

As outages progressed:

• buffers slowly emptied
• empty buffers triggered additional logic states
• additional failures introduced longer repair delays

In effect, the buffers acted like internal clocks measuring outage duration. The result was a sophisticated dynamic ramp-time model built entirely from existing software features.

It was also one of the clearest demonstrations of how system modeling often becomes a form of engineering problem-solving creativity.

4. Modeling Network Loops with RBDs

The final example explored how Reliability Block Diagrams (RBDs) can model network-style systems with multiple routing paths.

One key lesson stood out:

An RBD is not a physical drawing of the system.
It is a representation of reliability logic.

This distinction becomes extremely important when modeling looped systems such as:

• power grids
• communication networks
• water distribution systems
• process routing networks

Instead of drawing the physical architecture directly, the model represented all possible logical paths product could take through the network. The webinar shows how adding a loop dramatically improved redundancy and reduced lost production costs.

In one comparison:

• the non-looped design resulted in roughly $12 million in losses
• the looped design reduced losses to roughly $200,000

A powerful reminder that small architectural changes can produce massive reliability improvements.

The Bigger Lesson

Although the webinar covered several highly specific examples, the underlying message applied broadly to reliability engineering:

The best models often come from understanding system logic, not simply following default software workflows.

Many advanced behaviors become possible when engineers:

• combine features creatively
• think in terms of system logic
• separate physical architecture from modeling the logical behavior
• test assumptions visually using simulation tools

As David Wiseman explains during the webinar, AvSim cannot possibly include a dedicated feature for every imaginable system behavior. But with the right modeling approach, engineers can often achieve the behavior they need anyway.

Final Thoughts

The webinar was a reminder that RAMS engineering is part mathematics, part systems thinking, and occasionally… part creativity experiment.

Whether modeling:

• maintenance evolution
• changing production targets
• dynamic ramp times
• looped networks
• or even hypothetical football simulations

…the same principle applies:

When you understand the logic of the system first. The software is often capable of far more than it initially appears.

If you missed the webinar or would like help solving a challenging modeling problem, the Isograph (PeakAvenue) teams are always happy to discuss unusual systems, advanced logic strategies, and creative approaches to RAM analysis. Please feel free to contact me:

Best Regards,

Jeremy Hynek

VP Business Development

 www.isograph.com 

Isograph Inc. | a PeakAvenue Company

375 S Main St, Alpine, UT 84004

Phone: 801 610 0049 | Mobile: 949 813 1284

Jeremy.Hynek@peakavenue.com | Website | LinkedIn

Getting stuck chasing perfect failure rate data is one of the biggest obstacles to building effective system-level reliability models. Too often, engineers feel they can’t begin an FTA, FMECA, FMEDA, FMEA, or system reliability analysis until every component has precise, manufacturer-verified failure rates.

The reality? You don’t need perfect data to get meaningful results.

In this webinar, we take a practical, real-world look at how failure rate data actually impacts system-level models—and why its influence is usually much smaller than most engineers expect.

Using concrete examples, we explore:

-Why system architecture and design choices drive risk far more than small differences in component failure rates

-How “imperfect” or estimated data can still be highly valuable in early modeling

-Why your first model is only a starting point, not a final answer

-How waiting for perfect data can delay critical design decisions that improve reliability and safety

-Why system-level results often change far less than expected as data matures over time

You’ll walk away with a more confident, practical approach to reliability modeling—one that helps you move forward sooner, learn faster, and avoid data perfectionism. Ideal for reliability engineers, safety engineers, system designers, and anyone working with FTA, FMEA, FMEDA, MCS, RBD or system reliability models.

We look forward to your feedback!!

 

Best regards,

Jeremy Hynek

VP Business Development

 www.isograph.com 

Isograph Inc. | a PeakAvenue Company

375 S Main St, Alpine, UT 84004

Phone: 801 610 0049 | Mobile: 949 813 1284

Jeremy.Hynek@peakavenue.com | Website | LinkedIn

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: