Reliability Formulas: Quick Reference

These describe one block, not the whole system. The book’s glossary uses MTBDE/MDT for the system; the same shape of arithmetic applies one level down, with different names in wider reliability practice:

Availability says how good the system is. An importance measure says which block to spend money on. IEC 61078 Annex D defines them as derivatives of the system function; RAPTOR Studio has no analytical function to differentiate, so it estimates the same quantities by re-simulation: it runs the model once with one block made unable to fail, and once with that block dead, and compares the results with the ordinary batch.

Write \$A\$ for the chosen measure’s mean across runs (availability by default; reliability and dependability are selectable), \$A_0\$ for the ordinary run and \$u = 1 - A\$ for the corresponding unavailability.

"Perfect" means the block’s failure law cannot fire inside the run; "failed" means it fails at the first instant and is never repaired. Neither is a property you can set on the model: they are variants the analysis builds, and the model file is untouched.

Importance is ranked per block. A hierarchy is not yet an element of this analysis: to judge a subsystem, read the blocks inside it, or run the hierarchy on its own (raptor extract) and take its importance there.

Which one ranks the list. Vesely–Fussell, by default — not Birnbaum. In a series system, making any one block unable to fail takes the system to about 1 and making it dead takes the system to about 0, so Birnbaum comes out near 1 for every block and ranks nothing. Vesely–Fussell divides that same movement by the downtime actually observed, so it separates them, and RRW agrees with it. The Importance tab and the report rank by the first available of Vesely–Fussell, RRW, Birnbaum, RAW and say which they used; Birnbaum stays in the table as a column.

When the ranking means nothing. If the ordinary run was almost never down, every ratio is a ratio of noise: RAW divides by a number near zero, and RRW can come back below 1, which reads as "fixing this block would make things worse". The tab and the report say so explicitly when the baseline was above 99.9% available. Raise the trials or lengthen the run.

The analysis is opt-in because it costs batches, not seconds: one extra batch per block, or two when Birnbaum is included (it needs both variants), each the size of the batch you asked for. A 17-block model at 1,000 trials runs 35,000 replications. Use the Cores setting; a single batch is a small share of that total. The extra batches record no event logs and no plots.

The hazard function \$h(t)\$ is the instantaneous risk of failure right now, given the part has survived to age \$t\$. It is not the same as the failure probability density — it is the density divided by the survival probability so far:

Three shapes, one curve, three life stages:

Stack the three and you get the classic bathtub curve: high, falling risk in infancy; a long flat floor; rising risk at the end of life. Burn-in testing exists to walk a part past the infant-mortality knee before it ships. Preventive maintenance (see the preventive maintenance chapter) exists to replace a wear-out part before the rising edge, by resetting its clock to zero on a schedule shorter than where the curve turns up.

Mean and the shape knob, for every distribution the engine implements. Match the family to the physics, not to whichever one is already selected:

A design that must hit 99.99% availability is really asking the simulator to estimate a probability near \$10^(-4)\$. The normal-approximation SEM formula above still applies, but the number of trials needed grows fast as the target tightens:

Rule of thumb: \$n ~~ (p(1-p)) / ("SEM")^2\$, so for the same relative precision, halving the target unavailability roughly doubles the trials needed to pin it down. This is a property of Monte Carlo estimation, not a limitation of this simulator — closed-form or variance-reduction methods (common random numbers, see the chapter on trials; antithetic variates) buy back some of this cost but never repeal the square-root law.

IEC 61078 collects the closed-form results that apply when blocks are independent and have a constant probability of being up. For a series structure, every block must work:

For a parallel structure, the system is down only when every block is down:

For an m-out-of-n structure with identical blocks of availability \$A\$, the system is up when at least \$m\$ blocks are up:

These are steady-state availability forms. The corresponding reliability forms use \$R_i(t)\$ instead of \$A_i\$.

RAPTOR Studio does not evaluate these formulae directly. It simulates the same logical structures, so the results converge to them when the model matches the assumptions (independent blocks, constant rates, enough trials, no truncation).

The simulator does not implement the standard’s minimal cut/tie sets, Boolean truth tables, Karnaugh maps, BDDs, analytical importance factors, criticality and DIM importance, PFD_avg, Vesely conditional failure intensity, or unconditional failure intensity. It also does not represent repeated/common blocks, multi-port transfer gates, non-coherent blocks, PAND/SEQ gates or a common-cause beta factor. The User Guide appendix states the scope.

The simulator can estimate the Annex D importance measures by re-simulation — see Importance measures and the Importance results tab — it does not compute their analytical derivatives, and it reports an explicit sampling error with them.

For the core summary metrics RAPTOR reports, the equations in the sections above are the authority. Those measures and their cross-run statistics appear in the run’s Final Results (Summary and Logistics), which is also where Raptor 7 prints them; this page is not duplicated into the application.