What Are Architectural Constraints in SIL Verification?

A Second Gate Beyond the PFD Math

SIL verification has two independent hurdles a subsystem must clear, and passing one does not excuse the other. The first is the quantitative hurdle: the calculated probability of failure - PFDavg for low-demand functions or PFH for high-demand ones - must fall within the band required by the target SIL. The second, entirely separate, is the architectural constraint, which caps the SIL a subsystem may claim based on its structure alone. A subsystem must satisfy both, and it can only claim the lower of the two SILs they allow.

This means a subsystem can compute a beautiful PFD that would suggest, say, SIL 3, and still be limited to a lower SIL because its architecture does not meet the constraint for that level. The probability math and the architectural constraint answer different questions - one asks how reliable the numbers say it is, the other asks whether its physical redundancy is robust enough to be trusted with that claim. A design that passes the math but fails the constraint has not earned the higher SIL; the constraint wins, and the claim is capped.

The two inputs to the architectural constraint are hardware fault tolerance and safe failure fraction, both of which have their own definitions. Hardware fault tolerance is how many dangerous faults a subsystem can suffer and still perform its safety function - a fault tolerance of zero means a single fault can defeat it, while one means it survives a single fault. Safe failure fraction is the proportion of a subsystem's failures that are not dangerous-and-undetected. The architectural constraint combines these two into a maximum claimable SIL, so they matter not only in the PFD calculation but as gatekeepers of the SIL claim itself.

The HFT-and-SFF Lookup and Device Type

The constraint is applied through a lookup table that takes hardware fault tolerance and safe failure fraction as inputs and returns the maximum SIL a subsystem may claim. Read it and the pattern is clear: for a given safe failure fraction, adding hardware fault tolerance - more redundancy - raises the SIL ceiling, and for a given fault tolerance, a higher safe failure fraction also raises it. To claim a high SIL a subsystem generally needs either substantial redundancy or a high safe failure fraction, or some combination, because the table refuses a high claim to a bare single channel with modest diagnostics.

The table further depends on whether a device is classified Type A or Type B. Type A elements are simple, well-understood devices whose failure modes are all well defined and whose behavior under fault is well established - think of straightforward mechanical or electrical components. Type B elements are complex, typically containing microprocessors or firmware, where the failure modes are not all fully known. Because there is more uncertainty about how a Type B device fails, the table imposes stricter requirements on it: a Type B element needs a higher safe failure fraction or more fault tolerance than a Type A element to claim the same SIL.

This different treatment is deliberate and points at the constraint's purpose. The more complex and less fully understood a device is, the less the analysts are willing to trust its bare numbers, so the table demands more architectural robustness before letting it claim a high integrity level. A simple, transparent Type A device is trusted with a higher SIL at a given architecture than a complex Type B one, precisely because its failure behavior is better characterized and carries less hidden risk.

Why the Constraint Exists and What It Forces

The architectural constraint exists to guard against a weakness in the quantitative approach: the PFD calculation is only as trustworthy as the failure-rate data fed into it, and that data always carries uncertainty. Failure rates are estimates drawn from historical experience and analysis, not perfect truths, so a subsystem's calculated PFD could look excellent yet be wrong because the underlying rates were optimistic. Relying on the math alone would let a design claim a high SIL on the strength of numbers that might not hold, which is a dangerous place to put trust for a safety function.

The constraint answers this by requiring a minimum level of physical robustness - a minimum hardware fault tolerance for a given claim - regardless of what the numbers say. Redundancy provides a margin that does not depend on the precise accuracy of any single failure rate: even if one channel's real reliability is worse than estimated, a redundant partner still stands behind it. So the architectural constraint can force a designer to add a second channel even when the PFD math already passes, buying a structural safety margin against the possibility that the failure data was too optimistic.

This is where the constraint reshapes real designs, and where the connection to operations comes in. Merobix is a cloud SCADA platform that reads live tags from field devices over Modbus, DNP3, OPC UA, and MQTT, and while architectural constraints are a design-time rule rather than a live measurement, the redundancy they mandate becomes something to monitor in service. When the constraint forces a redundant sensor or valve arrangement, keeping that redundancy healthy matters - a failed channel in a redundant pair silently erodes the very fault tolerance the constraint required. Surfacing the state of each channel as monitored tags lets operations see when a redundant element has degraded and restore it before the subsystem is quietly reduced to the single-channel robustness the architectural constraint was designed to forbid.

Frequently Asked Questions