Tech Tuesday: Reliability Workbench 12

Joe Belland

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.

Tech Tuesday: The Grid Control

Jeremy Hynek

Howdy, folks. This will be the first installment of what we hope will become a regular feature around here. Each Tuesday, look for an article highlighting a technical aspect of our software. This may be a demonstration of a feature, an explanation of the mathematics that power the tools, or some comments on technical support questions that we’re frequently asked.

Today, I’ll be talking about the Grid Control feature of our Availability Workbench and Reliability Workbench tools. If you’ve used our AvSim or FaultTree+ software, you know the power of the tool, and the usefulness of the diagram view to be able to create and edit intricate Fault Tree or Reliability Block Diagrams (RBDs). However, sometimes you may find that you have to do some task, such as text entry, or finding and replacing some information, that can be cumbersome to perform in the diagram view.

For instance, suppose you’ve created a large, multi-page Fault Tree, and now you want to add unique IDs and descriptions to all the gates and events, so you can identify what each one represents. To do this in the diagram view, you’d need to locate each item individually, double-click to open the Properties dialog for the gate or event, set the ID and description, click “OK” to close the dialog, find the next item, rinse, and repeat. There’s a lot of back-and-forth between mouse and keyboard, and hunting through the diagram for the items you want.

Properties
The Event Properties dialog from FaultTree+

 

The Grid control helps with this by providing a tabular format for editing data, similar to what you’d see in Microsoft’s Excel or Access products. Each gate or event appears on one line of the grid, and you can use the cursor keys, or the tab key, to navigate the records and fields. To edit some text, simply highlight a field with the mouse or keyboard and start typing, or press Enter on your keyboard.

Grid
The Grid view in FaultTree+

From the grid view, you can use the table selector to choose which data you want to display. This might be the Gates, Events, or Failure Models table in FaultTree+ , or the RBD Blocks or Failure Models table in AvSim.

TableSelector
Grid Table selector

With a given table selected, you can refine which records should be displayed by using the “Filter Grid by Tree Control Selection” option, found in the Grid menu. This mouthful-of-a-name simply means that data will only be displayed in the Grid if it’s relevant to the selection in the tree control on the left hand side. For instance, selecting a particular gate in the Fault Tree hierarchy will only show events under that gate, or selecting a Failure Model group in the AvSim project will only display failure models in that group.

FilterByTreeControlSelection
“Filter by Tree Selection” turned on; note how only events logically dependent on the selection on the left are displayed in the grid.

There are plenty more options in the Grid view that allow you to choose what data is displayed. You can use the Grid Layout options to choose what columns should be displayed, and what their order should be; the Grid Filter provides further methods of filtering records; and the Grid Sort allows you to choose how the records are sorted. And any custom grid layout, filtering, or sorting you’ve created can be saved, so you can share it with your colleagues or transfer it to a new computer. You can even copy and paste data directly from the Grid view to a spreadsheet application like Microsoft Excel.

GridOptions
The options under the Grid menu. Layout Options, Filter, and Sort are all near the top. Options to import and export grid layouts are near the bottom.

There’s even a Find & Replace feature, for when you need it. The cool part is, when you use Find & Replace, it will only apply to the currently-displayed records. If you use a filter to hide certain rows, they won’t be included in the replacement.

FindandReplace
The Find & Replace dialog. This works exactly like you’d expect.

And for those times when you want the Properties dialog, you can just double-click the grey space to the left of a grid row to open the Properties dialog for the item.

Why don’t you take a look at the Grid control, and try it out? I’ve found it to be a great tool to use when quickly building or editing a project.