Deterministic

A deterministic requirement enforces safety in a system or process by having you follow a defined rule or program rather than produce a calculated number. The cleanest example in functional safety is Route 1S in IEC 61508, the systematic capability path: you work through tables of design techniques and measures, each one rated per SIL as highly recommended, recommended, or not recommended, and you comply with them. Nothing is calculated. Architectural constraints work the same way. Every SIL carries a minimum hardware fault tolerance (HFT), and a SIF that misses it fails verification no matter how good its PFDavg looks. The rules are there because the committee acknowledges that failure rate data and the calculations built on it are never perfect, so a layer of rules sits underneath the math.

The idea is not unique to functional safety. Commercial-grade dedication (CGD) in the US nuclear industry works the same way: a defined program that identifies an item’s critical characteristics and verifies them by inspection, test, or analysis, so an off-the-shelf component can be used in a safety application. No probability is calculated anywhere in it. The process is what earns the confidence.

Key Points

  • Deterministic requirements are met by following a defined rule or program, with no probability calculation involved.
  • Route 1S is the clean case: comply with the per-SIL tables of techniques and measures. Minimum HFT by SIL works the same way.
  • The rules act as a backstop wherever failure rate data or calculation quality cannot carry the whole argument.

Example

A SIL 3 safety instrumented function requires an HFT of at least 1. A 1oo1 architecture has HFT 0, so it fails the deterministic check even when the calculated PFDavg lands comfortably inside the SIL 3 band. The fix is redundancy, a 1oo2 or 2oo3 arrangement, not a better number.

See Also: HFT, probabilistic, PRA

Cited Sources

Part Of: risk terms category