Before you can calculate how reliable a safety function is, you have to agree on where it starts and where it stops. That line - which components belong to the function and which do not - is the safety function boundary, and getting it right is not a formality. Every component inside the boundary counts toward the reliability calculation and must be proof-tested; every component wrongly left outside is a hidden gap. This guide explains how the boundary of a safety function is drawn from sensor to final element, why the boundary determines what counts, the components people wrongly exclude, and how the function interfaces with the basic control system.
Safety Function Boundary in one line: A safety function boundary is the defined scope of a safety instrumented function - the set of components that make up the function, drawn from the sensing element, through the logic solver, to the final element and the supporting supplies that let it act. Everything inside the boundary counts toward the function's probability of failure on demand and must be included in proof testing. Drawing the boundary correctly matters because anything mistakenly excluded is left out of the reliability calculation and the test programme.
A safety instrumented function is a complete path from detecting a hazard to acting on it, and its boundary encloses that entire path. It begins at the sensing element - the transmitter or switch that detects the process condition - runs through the logic solver that decides, and ends at the final element that takes action, typically a valve with its actuator. But the boundary does not stop at the obvious devices. It extends to include the things without which those devices cannot act: the solenoid that vents the actuator, the instrument air or hydraulic supply that strokes the valve, and the power and signal paths the function depends on.
The guiding principle is function, not hardware category. If a component's failure could prevent the safety function from detecting a hazard or reaching its safe state, that component is inside the boundary regardless of what it is called or which department owns it. A shutdown valve that cannot close because its air supply failed has failed the safety function just as surely as if the valve itself seized - so the air supply is part of the function's scope. The boundary is defined by what the function needs to work, drawn around the complete chain rather than a convenient subset of it.
This is why boundary definition is a deliberate, documented step and not an afterthought. Two engineers can draw the boundary of the same function differently, and the difference changes the reliability number and the test scope. Agreeing explicitly on where the boundary lies - and recording it - is what makes the later calculations and test procedures mean the same thing to everyone who relies on them.
The boundary matters because it is the rule that says which components are counted. A safety function's probability of failure on demand is the sum of the failure contributions of the components inside its boundary - no more and no less. If a component that the function genuinely depends on is left outside the boundary, its failures are simply not in the calculation, and the reliability figure is optimistic by exactly the contribution that was omitted. The number looks fine on paper while the real function is less reliable than claimed.
The same boundary defines the proof-test scope. A proof test is meant to reveal the dangerous undetected failures that could stop the function working, and it can only do that for components that were recognised as part of the function. A solenoid, an impulse line, or a power supply that fell outside the boundary is one that no one thought to include in the test procedure, so its hidden failures go unrevealed test after test. The boundary and the test programme have to agree, because a component that is out of scope for the boundary is out of scope for testing.
So the boundary is doing double duty: it determines both what the reliability calculation adds up and what the proof test exercises. A boundary drawn too narrowly produces an overstated reliability figure and an incomplete test, and both errors point the same way - the function is less safe than the documentation says. This is precisely why correct boundary definition is treated as foundational to the whole analysis rather than a labelling exercise.
The classic boundary errors all involve leaving out a dependency that does not look like part of the function. Solenoid valves are a frequent omission - the valve gets counted but the solenoid that actually vents it does not, even though a stuck solenoid stops the valve closing. Impulse lines and process connections to transmitters are another: a plugged impulse line makes a perfectly good transmitter read a false steady value, so it belongs inside the boundary. Power supplies, instrument air, and hydraulic supplies are perhaps the most commonly overlooked of all, despite the function being unable to act without them.
The interface to the basic process control system needs equal care, because it defines where the safety function ends and the everyday control system begins. Where a device is shared between control and safety, or where a signal crosses between the two systems, the boundary has to state clearly which side owns the safety function. A shared sensor or a shared final element can create a subtle dependency in which a control-system failure undermines the safety function, so the boundary and the independence between the two systems have to be considered together rather than assumed.
In a SCADA context, being clear about the boundary also clarifies which components a cloud platform is monitoring and which it must never be trusted to perform. A platform such as Merobix reads the status, diagnostics, and proof-test records of the devices inside the safety function boundary - transmitter health, valve position, solenoid state, supply pressures - and presents them in a browser so an engineer can see the whole function's condition in one place. The safety function itself is executed by the logic solver and its field devices within that boundary; the monitoring layer makes the state of everything inside the boundary visible without ever becoming part of the function it is watching.
It starts at the sensing element that detects the hazard, runs through the logic solver that decides, and ends at the final element that acts - but it also includes the supporting parts the function depends on, such as the solenoid, the instrument air or hydraulic supply, and the power and signal paths. The rule is functional: if a component's failure could stop the function detecting a hazard or reaching its safe state, it is inside the boundary.
The boundary decides which components count in the probability-of-failure calculation and which must be proof-tested. A component wrongly left outside the boundary has its failures omitted from the reliability figure and is skipped in the test procedure, so its hidden faults go unrevealed. A boundary drawn too narrowly makes the function look more reliable than it is and leaves real gaps, which is why boundary definition is treated as foundational.
The most common omissions are dependencies that do not look like part of the function: solenoid valves that actually vent the actuator, impulse lines and process connections that can plug and give a transmitter a false reading, and power, instrument air, and hydraulic supplies without which the function cannot act. Each of these can defeat the safety function, so each belongs inside the boundary and in the proof-test scope.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.