Calculation methods and validation

What First Out AI calculates, which published method each result uses, where the approximations stop being valid, and how the code is tested. Written so a reviewer can decide whether to trust a result.

1. The three requirements behind a SIL claim

A safety instrumented function meets its target SIL only when three separate requirements are met. First Out AI checks all three and reports each one separately, because a function can pass one and fail another.

  1. Random hardware failures: the average probability of failure on demand (PFDavg) for low-demand functions, or the average frequency of dangerous failure per hour (PFH) for high-demand and continuous functions, must fall inside the target SIL band.
  2. Architectural constraints: each subsystem must have enough hardware fault tolerance for the target SIL.
  3. Systematic capability: every element must be suitable, by certification or prior use, for the target SIL.

2. Failure rate inputs

Each element is described by its dangerous undetected rate λDU, dangerous detected rate λDD, and safe rates λSU and λSD, in failures per hour. Every value carries a source field: certificate, FMEDA report, operating data or engineering estimate. First Out AI ships with no third-party reliability data.

Other inputs per element group: proof test interval T1, proof test coverage PTC, renewal interval MT (when failures that no test reveals are cleared by replacement or overhaul; by default the function's mission time), mean repair time MRT and mean time to restoration MTTR, common cause factors β and βD, and, for valves, partial stroke test interval and coverage.

3. PFDavg for low-demand functions

The function's mission time is the averaging horizon for PFDavg. Each group's renewal interval can be shorter, for example a valve overhauled every 10 years in a function assessed over 20.

First Out AI computes the probability of failure of the whole function as it changes over time, PFD(t), and averages it over the mission time. Each voted group's channels fail independently at (1 − β)·λDU, the group as a whole fails by common cause at β·λDU, and each part of λDU is cleared only by the test that can reveal it. Groups are combined in series. This handles imperfect proof tests, partial stroke tests and mission time without further approximation.

The average uses the midpoint rule with 400 points per shortest test interval, capped at 40,000 points over the mission time; the cap changes no published result at the precision shown. The mission time must be at least the longest proof test interval and at most 50 years. Each group's share of the total is computed on the same grid.

Every result is cross-checked against the simplified equations published in IEC 61508-6, Annex B, which assume a perfect proof test. Both values are shown in the report. For a single channel (1oo1) with a perfect proof test:

PFDavg = λDU · (T1/2 + MRT) + λDD · MTTR

For redundant voting, the equations add the probability that all required channels fail together within the proof test interval, plus the common cause term. For 1oo2:

PFDavg = 2 · ((1−βD)·λDD + (1−β)·λDU)² · tCE · tGE + βD · λDD · MTTR + β · λDU · (T1/2 + MRT) where tCE = λDU/λD · (T1/2 + MRT) + λDD/λD · MTTR tGE = λDU/λD · (T1/3 + MRT) + λDD/λD · MTTR

The same family covers 2oo2, 2oo3 and 1oo3. For other voting (3oo3, 1oo4, 2oo4, 3oo4, 4oo4) there is no simplified equation in the report, and the time-domain value stands alone.

Two differences between the two values are expected. The simplified equation for 2oo2 has no common cause term, while the time-domain model applies β to every redundant group, so for NooN voting the time-domain result can be up to about β/2 lower. And a group can be given an internal fault tolerance (for example a logic solver with redundant processors inside one certified device); that raises the group's HFT for the architectural check but does not change its probability.

Imperfect proof testing

A proof test rarely reveals every dangerous undetected failure. The fraction it reveals, PTC, is tested at interval T1. The rest stays hidden until the element is replaced or overhauled, so it accumulates over the mission time MT. First Out AI splits λDU into these two parts and applies the equations to each with its own interval. A partial stroke test adds a third part with its own interval and coverage.

Where the simplified equations stop being valid

The simplified equations assume constant failure rates and that λ·T is small. When λDU·T1 or λDU·MT exceeds about 0.1 they overestimate the result, and the time-domain value is the one to use. The calculation still assumes constant failure rates, so wear-out is handled through the mission time, not modelled directly.

4. PFH for high-demand and continuous functions

PFH uses the corresponding IEC 61508-6 equations for the average frequency of dangerous failure, for 1oo1, 1oo2, 2oo2, 1oo3 and 2oo3, with the channel down time based on the effective test interval (PTC − PSTC)·T1 + PSTC·TPST + (1 − PTC)·MT, so imperfect proof tests and partial stroke tests raise the PFH as they should. For a single channel it is λDU, plus λDD when a detected failure does not trip the function. Redundant voting adds the rate at which the remaining channels fail while one is already failed, plus the common cause rate. For other voting First Out AI does not report a PFH and says so, rather than extrapolate.

5. Architectural constraints

For each subsystem, First Out AI computes the hardware fault tolerance from the voting (for example, 1oo2 and 2oo3 tolerate one fault; 2oo2 tolerates none) and reports three views:

  • IEC 61511-1, clause 11.4: minimum hardware fault tolerance by SIL and demand mode. On paid plans this is the architectural requirement used for the achieved SIL.
  • IEC 61508-2, Route 1H: maximum SIL from hardware fault tolerance, safe failure fraction and element type (A or B), with the safe failure fraction computed from the four failure rates. Shown for information on paid plans; on the Free plan it is the only architectural check.
  • IEC 61508-2, Route 2H: the minimum fault tolerance for the target SIL, listed per group for reference.

6. Systematic capability

Each element records its systematic capability (SC 1 to SC 4). The function's systematic capability is taken as that of its weakest element, and the function fails this check if any element is below the target SIL. The IEC 61508-2 rule that allows a higher capability from diverse elements combined is not applied; if you rely on it, document it outside the tool.

7. Spurious trip rate

The spurious trip rate is reported for each subsystem and the whole function, from safe failures and from dangerous detected failures that cause a trip, with common cause included. For MooN voting with independent repair, the independent part is N! / ((M−1)!·(N−M)!) · λM · MTTRM−1, which gives 2λ for 1oo2, 6λ²·MTTR for 2oo3 and 12λ³·MTTR² for 3oo4. It is shown as a rate and as a mean time to spurious trip, so availability can be weighed against safety when choosing the voting.

8. SIL determination

LOPA computes the mitigated event frequency from the initiating event frequency, the probability of failure on demand of each independent protection layer and any enabling conditions, then the risk reduction the safety function must provide against your tolerable frequency. Risk matrices and risk graphs use your company's own calibration, entered once and stored with the project.

9. How the code is tested

Every method is implemented in First Out AI's own code and covered by tests. The reference engine (Python, v0.3.0) passes 33 unit tests, among them:

  • 1oo1 with a perfect test against λDU·T/2, within 1 %.
  • 1oo2, 2oo3 and 1oo3 with common cause, repair and detected failures against the IEC 61508-6 simplified equations, within 3 %.
  • Imperfect proof testing and partial stroke testing against hand calculations, within 2 %.
  • PFH, safe failure fraction, Route 1H, IEC 61511 minimum fault tolerance, spurious trip rates and LOPA arithmetic against hand calculations.

The server engine that answers in the app is a separate JavaScript build. Before each release it must reproduce the reference engine on 300 randomly generated functions (one to four groups, any voting up to four channels, imperfect proof tests, partial stroke tests, common cause, low and high demand), 40 LOPA cases and the 84 calculations behind the seven functional safety case studies, to a relative difference of 10−9. Values that fall exactly on a band limit (PFD, PFH, risk reduction, safe failure fraction, required PFD) are rounded to ten significant digits first, so 0.1 × 0.1 ÷ 10−5 counts as a risk reduction of 1,000, not slightly above it. Before release, a second implementation, written separately from the engine, recomputed 26 cases with closed-form calculations; all agreed within 3 %.

Download the test set (inputs and expected results, JSON, 0.6 MB) to check your own spreadsheet or tool against it.

10. Version history

VersionDateNotes
0.3.028.10.2026First public release, with the methods described on this page. Before release the engine was checked against a separately written set of closed-form calculations; that check changed the PFH treatment of proof test coverage and partial stroke tests, the spurious trip formula for M of 3 or more, and the rounding at band limits.

Any later change to a calculation method will be listed here with its date and the reason.

First Out AI supports engineering judgement and does not replace it. Results must be checked by a competent functional safety engineer before they are used. First Out AI is not certified software.

Check one of your own calculations against First Out AI.