Category Archives: Reliability Workbench

Friday the 13th Webinar: Reliability Workbench Upgrades 13.0.2

Although some might have superstitious feelings about Friday the 13th. We have chosen to hold a webinar to get you away from all the coffee talk. For Friday the 13th we have come up with a special preview of our next version of Reliability Workbench which is also version 13 (specifically 13.0.2). Join us for this special webinar, on Friday October 13th at 12 PM Eastern Time, to get an early look at the new features that have been added. We have added significant 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.

Please register by clicking: HERE

As always if you have any questions, comments or feedback please let me know.

Best Regards, Jeremy 

Best Kept Secret in Isograph’s software

Secret might be the wrong word to use here, it could be a matter of just asking myself or technical support the right questions. Even if you’ve been using Reliability Workbench, Availability Workbench, AttackTree+, or Network Availability Prediction for years, you’re probably still finding new features and tips and tricks to help you out in the software. Maybe one day you discovered a time-saver and thought to your self “what else can this software do to make my day easier?”

While there are plenty of helpful features in Isograph’s software to make your day easier, perhaps none is so powerful, incredibly useful, and so under-utilized as Plugins and the DLL. These features allow you to extend the power of Reliability Workbench, Availability Workbench, Attack Tree, and NAP tools to absurd heights. From creating macros for accomplishing tedious tasks, to automating fault tree construction, and even adding new features to the software that we haven’t even thought about, the Plugins and DLL can do it.

As always if you have any questions or need additional information on our products please feel free to contact me

Jeremy Hynek
Isograph, Inc.
801 610 0045

How To Use Your Settings in Reliability Workbench (FaultTree+)

We have collected commonly asked questions by our 1000’s of users. Some of the questions that we’ll answer along the way include:
Why do my cut sets show gate names with an asterisk next to them?
OK, so I enter a “failure rate.” Is that failures per… hour? Year? Geological epoch? What are the units?
This fault tree takes ages to calculate. Can I speed it up?
Fault tree uses approximation methods for solving the tree? Do I have any control over that?
My computer crashed and I lost 3 hours of work! Can I create automatic backups of my project?
What if I want to see MTTF on my fault tree, instead of Q?
I have a plotter. How do I print the whole tree on one piece of paper?
Can I force scientific notation in the results?
What if I don’t want to delete the inputs to a gate when I delete the gate?
I really love the font Comic Sans. Can I use that in my fault tree?
Also, chartreuse is my favorite color. How do I set that as default?
How do I set default options, so I don’t have to reset these every time I start a new project?

We’ll also look at the useful and often-overlooked Report Options. Did you know that you can force the diagram to be black & white for printouts? Or make the fault tree symbols bigger? Or change the order of the pages?

Reliability Workbench Version 13… What’s New

As a follow up to our Webinar: What’s New in Reliability Workbench 13 Webinar I have included a recording of the meeting.

In addition to some minor visual upgrades the significant new features in Reliability Workbench 13.0 are:

  • The FIDES Prediction standard has been added to the Prediction Module.
  • 217Plus has been upgraded to version 2015.
  • The NPRD library has been upgraded to NPRD-2016.
  • The FMD 2016 failure modes library has been added to the NPRD parts library. FMECA blocks created from the NPRD library will now also have their failure modes automatically created where appropriate.
  • The SN29500 prediction standard has been updated to edition 2015-04.
  • IEC 61508 failure models have been extended to allow for high demand system frequencies (PFH values) to exclude detected failures.
  • Fault tree modularization has been made more efficient for projects that contain disconnected fault trees.
  • Sensitivity calculations may now be performed for IEC 61508 dormancy averaging. This applies when the dormant failure model is set to IEC 61508 in the project options dialog.



Linking Fault Tree and Event Tree

Event Tree Analysis (ETA) complementing your Fault Tree Analysis (FTA) is like putting salt on your popcorn. Event tree diagrams provide an excellent way of showing the possible outcomes of a hazardous event (often modelled in a FTA study). An ETA diagram is a simple, logical and easy to read diagram that breaks down data to show the possible consequences of failures in an FTA study.Event trees provide an inductive approach to reliability and risk assessment and are constructed using forward logic.

FaultTree+ in Reliability Workbench includes integrated event tree analysis. The event tree model may be linked to the fault tree model by using fault tree gate results as the source of event tree probabilities. FYI, if you already have a copy of FaultTree+ the Event Tree Software is included!

Please register for this educational Webinar: Linking FaultTree+ and Event Tree Analysis on Jun 2, 2016 11:00 AM MDT at: CLICK HERE

Flow Regulator ET

We appreciate your support of Isograph. If you have any general questions or comments please feel free to contact me.


Jeremy Hynek
Isograph, Inc.
Director North American Operations
801 610 0045


Upcoming training……

As many of you know we don’t exactly get our of the office every week to offer public training courses. Please don’t miss your opportunity to attended one of Isograph’s training sessions to be held in Park City, Utah the week of June 27th, 2016. We will be offering training on Isograph’s Reliability Workbench, FaultTree+ and Availability Workbench Software. In addition to the training in Park City will also be offering training in Houston this September, which will include our IEC 61508 training. For a complete list of dates please check our website: .

The upcoming training in Park City offers an ideal location. Just 40 minutes from SLC international airport, Park City was home to the 2002 Winter Olympics and offers many lodging options and is well know for it outdoor/night-life activities. .

New this year we will begin to offer self paced web training. For more information please contact myself or Joe Belland: .
On a different note, for those Reliability Workbench users don’t miss our “What’s New” webinar this Wednesday at 12pm EST. In this Webinar we will go over the upgrades added to Reliability Workbench Version 13.

Please register here: Registration Click HERE
We appreciate your support of Isograph. If you have any general questions or comments please feel free to contact me.


Jeremy Hynek
Isograph, Inc.
Director North American Operations
801 610 0045

Is your modeling logic…logical?

When modeling (or modelling for those of you in the UK) your system in a Fault Tree or Reliability Block Diagram do you ever wonder if your logic is covering all possible failures or properly accounting for redundancy in your system?

Try your hand at modelling the included schematic in a Fault Tree or Reliability Block Diagram (RBD) then join us on a Webniar, Friday at 10am PST, to see if your model matches up with the model one of our support experts comes up with. If you do not have access Fault Tree Analysis or RBD software please let me know and I will lend you software to use during this meeting.


The safety system is designed to operate as follows: should a runaway reaction begin, the temperature sensor (TS1) and pressure sensor (PS1) will detect the increase in temperature and pressure and start the safe shutdown process. The provision of two sensors is for redundancy; only a single sensor needs to register the unsafe reactor conditions to engage the safety system. Should either TS1 or PS1 detect a runaway reaction, two things will occur: 1) a signal will be sent to the controller (CON), which will close the electric valves in each reactor input (EV1 and EV2), and 2) the alarm (ALARM) will sound, signaling the operator (OP) to close the manual valve in each reactor input (MV1 and MV2). In order to stop the runaway reaction, BOTH inputs must be shut down. However, only one valve on each input needs to be shut. So only MV1 or EV1 must be shut to stop input 1, but at least one valve on input 1 and at least one valve on input 2 must close to stop the inputs to the runaway reaction. Note that EV1 and EV2 (and only these components) are powered by the electrical grid; all other components have independent battery backups or power supplies.



Registration URL:


Tech Tuesday: Reliability Workbench 12

Howdy, folks! Isograph has recently launched Reliability Workbench 12, the latest incarnation of our flagship reliability analysis product. There are a number of new features and improvements, and today I’ll be talking about a couple big changes.

The first and biggest change is the addition of a new Safety Assessment module. This new module allows users to perform Functional Hazard Analysis, PSSA analysis, and other safety assessments in accordance with SAE ARP 4761 and other similar standards.

The System Safety Assessment (SSA) module allows users to construct a functional failure mode hierarchy, similar to the FMECA module of Reliability Workbench, or the RCMCost module of Availability Workbench. This functional hierarchy will list the functional requirements of the system, and the functional failures that could inhibit the system’s ability to perform the functional requirements. So for instance, an aircraft braking system could have several functional requirements, such as control thrust, control aircraft on the ground, and decelerate aircraft on the ground. The “decelerate aircraft on the ground” function could fail if there is a loss of deceleration capability.

An example failure mode hierarchy.

An example failure mode hierarchy.

Each failure can produce an effect. In our aircraft braking example, effects of failure of the braking system could be runway overrun, in which the aircraft is not able to completely decelerate the aircraft before the end of the runway. Then, each effect can have a user-defined classification, such as minor, major, or catastrophic. You can further define phases and conditions and tell the program that the effect only occurs during a particular phase or phases, and under specified conditions. For instance, the effect of a failure mode on an aircraft may only occur during take-off and landing, or in icy or wet conditions.

So far, so good. This isn’t too different from what many users already use FMECA or RCMCost for. But what differentiates the SSA module is its ability to link to analyses in other modules, to provide justification that any safety or reliability targets have been met. Each effect classification in the SSA can have an assigned probability requirement associated with it. Then each failure mode can be linked to another analysis, either a Fault Tree, RBD, FMECA, Markov, or Prediction. The SSA module will then compare the probability requirement of the effect classification with the calculated probability from the other analysis to determine if the probability requirement is being met.

SSA verification

For example, in our aircraft overrun scenario, this effect is assigned a classification of catastrophic. The Powers That Be have decreed that catastrophic failure modes should not have a probability of greater than 1E-9 per hour. We can enter this information into the SSA module. Next, we can link the loss of deceleration capability failure mode to another analysis, perhaps a Fault Tree analysis, that calculates the probability of the failure mode’s occurrence. The SSA module will then tell us if we’re meeting our reliability target for the failure mode, based on the reliability analysis we’ve done.

While users have been building Fault Trees, RBDs, Markov models to verify a reliability target for years, the power of the System Safety Assessment module is that it can link all these analyses into a functional failure mode hierarchy. Previously, a user might have one Fault Tree to examine one critical system, then a Markov model to analyze another, with no organization or relation between the two. The power of the SSA module is that it allows users to combine all their reliability analyses into a single master project, showing all the failure modes of the system, and providing documented verification that reliability targets are being met. You can then print out reports showing the reliability targets and the reliability verified via quantitative analysis.

SSA Verification 2

The other major new feature I want to talk about is User Columns in reports. User columns allow you to take the outputs from a report, then write simple code, either in Visual Basic or C# style, to create a new column in the report. Mostly, this is used to create conditional formatting, such that the font color, size, or style of a field in the report can be changed based on the value of that field, or of another field in the same row. But it can also be used to create more advanced columns, such as mathematical expressions, or logical conditions, that change the data displayed in a column. This could be used to change the units of a column, or combine multiple columns into one to, for instance, show either failure rate or characteristic life in a column, depending on whether the Rate or Weibull failure model is used.

Conditional formatting

An example of conditional formatting using User Columns that highlights first-order cut sets in red.


Conditional formatting code

The code used to generate the conditional formatting.


There are numerous other modifications and improvements that have been made in the latest release. You can read a summary of all the changes here. Customers with a current maintenance contract can upgrade for free, although you should contact us for a new license. Others can download a trial version to test it out. If you’re interested in more information, or would like to upgrade, please give us a call or send us an email.

Performing a LOPA using FaultTree+

On Friday April 4th at 9am PST to learn more about applications of our FaultTree+ software. During this demonstration we will introduce our fault tree analysis software FaultTree+ and as an added bonus we will be discussing how to tie a fault tree to an event tree and perform a LOPA study. Layer of Protection Analysis, or LOPA, is a study developed to identify risk. By performing a LOPA on a system you can create a method for identify the actions available to mitigate the potential consequences of a particular risk. To do this we will start with likelihood of a particular hazard occurring, analyze the system using quantitative methods, and identify the mitigation measures against the hazards that have been identified.

Once the mitigating actions have been identified the probability of those hazards occurring can be reduced by implementing safeguards that bring the hazard into an acceptable level. An event tree is an excellent way to determine the consequences of successful, or the failure of, safeguards.

Basically, a LOPA is performed to identify the weakest points of a system and evaluate the safeguards in place to mitigate the consequences of that hazard.

To join this webinar: Register Here