---
title: "Functional Safety in Industrial Automation: How Safety Instrumented Systems Work"
published: false
description: "How safety instrumented systems work: sensors, logic solvers, final elements, SIL targets and PFD maths, explained for engineers building safety logic."
tags: automation, engineering, safety, plc
cover_image: PASTE_UPLOADED_IMAGE_URL_HERE
If you write control software, you have probably written an interlock: "if pressure is above X, close valve Y." In a process plant, some interlocks are different. If they fail, people get hurt. Functional safety in industrial automation is the discipline of making those interlocks dependable enough, and proving it with numbers.
This post walks through how a safety instrumented system (SIS) is built, what a Safety Integrity Level (SIL) actually measures, and how to sanity-check a design with a few lines of code.
Basic control vs. safety function
A basic process control system (BPCS) keeps a process inside its normal operating window. A safety instrumented system does something else: it watches for a hazardous condition and drives the process to a safe state when the BPCS and every other protection layer have not prevented it.
Two ideas matter here:
- Safety instrumented function (SIF): one specific protective action, for example "on very high reactor pressure, close the feed valve."
- Safety instrumented system (SIS): the collection of sensors, logic solvers and final elements that implement one or more SIFs.
The governing standards are IEC 61508 (generic, for developers of safety equipment) and IEC 61511 (for process-industry users who design, integrate and operate SISs). In the US you will also see ISA-84 aligned with IEC 61511.
The anatomy of a SIS
Every SIF is a chain of three parts, and the chain is only as strong as its weakest link:
[ Sensor(s) ] --> [ Logic solver ] --> [ Final element(s) ]
transmitter safety PLC shutdown valve,
switch relay logic trip breaker
- Sensors detect the hazardous condition (pressure, level, temperature, flow, gas).
- The logic solver evaluates the inputs and decides whether to trip. This is often a certified safety PLC, kept separate from the BPCS.
- Final elements act on the process. Valves and their actuators are frequently the least reliable part of the loop.
Most SIFs are de-energise-to-trip: losing power or a signal moves the process to the safe state. A lot of safety design is about making sure the failure you cannot detect is as unlikely as possible.
What SIL actually measures
A Safety Integrity Level is a target for how reliably a safety function performs when it is demanded. For functions that are rarely demanded (low-demand mode), SIL is expressed as the average probability of failure on demand (PFDavg):
| SIL | PFDavg (low demand) | Risk reduction factor |
|---|---|---|
| 1 | 10^-2 to < 10^-1 | 10 to 100 |
| 2 | 10^-3 to < 10^-2 | 100 to 1,000 |
| 3 | 10^-4 to < 10^-3 | 1,000 to 10,000 |
| 4 | 10^-5 to < 10^-4 | 10,000 to 100,000 |
Two common misunderstandings are worth clearing up:
- SIL belongs to a safety function, not to a single device. A "SIL 3 transmitter" is a component that can be used in a SIL 3 function, but the loop's SIL depends on the whole architecture.
- A higher SIL is not automatically better. It means more cost, more testing and more complexity, so the target should come from the risk you actually need to reduce.
Where the target comes from
SIL targets come from a hazard and risk assessment. Layer of protection analysis (LOPA) is a popular method. In simplified form:
required PFD = tolerable event frequency
/ (initiating event frequency x other modifiers)
Say an overpressure scenario has an initiating event frequency of 0.1 per year, a 0.3 probability that the release leads to the consequence of concern, and your company tolerates 10^-5 per year for that consequence. The required PFD for the SIF is:
10^-5 / (0.1 x 0.3) = 3.3 x 10^-4
That lands in the SIL 3 band.
Checking a design with a few lines of code
Once you have a target, you verify the architecture. The sketch below uses the simplified PFDavg equations for 1oo1 and 1oo2 voting with only dangerous undetected failures and a common-cause factor. The numbers are illustrative, not data for any real device, and real SIL verification uses vendor safety data, diagnostics, systematic capability, and the full equations from IEC 61508-6.
lam_du = 1e-6 # dangerous undetected failure rate per hour (illustrative)
ti = 8760 # proof-test interval in hours (one year)
beta = 0.05 # common-cause factor (illustrative)
pfd_1oo1 = lam_du * ti / 2
pfd_1oo2 = (lam_du * ti) ** 2 / 3 + beta * lam_du * ti / 2
print(f"1oo1 PFDavg = {pfd_1oo1:.2e}") # 4.38e-03 -> SIL 2 band
print(f"1oo2 PFDavg = {pfd_1oo2:.2e}") # 2.45e-04 -> SIL 3 band
Against our 3.3 x 10^-4 target, the single channel falls short, while the redundant 1oo2 arrangement meets it. Notice how much the common-cause term contributes in the redundant case: adding a second sensor does not give you the squared benefit you might expect.
Practical considerations
Proof testing matters as much as architecture. PFDavg grows with the proof-test interval. A function that meets its target on paper but is never properly tested will not meet it in the plant.
Systematic failures are not covered by redundancy. Specification mistakes, wrong setpoints and software bugs hit both channels at once. That is why the safety lifecycle stresses a clear safety requirements specification, independent verification, and management of change.
Keep the SIS independent where it counts. Sharing sensors, power or logic between the BPCS and the SIS can create common-cause failures and undermine the independence assumed in your risk assessment.
Bypasses and overrides need governance. A tripped SIS is an operational annoyance, and the pressure to bypass it is real. Procedures and alarms for bypass use belong in the design, not as an afterthought.
Cybersecurity is now part of the picture. Safety logic that can be reached from the corporate network is a safety problem as well as a security problem.
Teams that want independent support with target setting and verification often bring in SIL consultancy services, which is worth considering when the hazard is severe or the in-house team is new to IEC 61511.
Key takeaways
- A SIS is a chain of sensors, a logic solver and final elements; the weakest link sets the result.
- SIL is a target for a safety function's probability of failure on demand, derived from risk, not from the equipment catalogue.
- Architecture, proof-test interval, diagnostics and common-cause failures all move the number.
- Systematic failures need process discipline (specification, verification, change control), not more redundancy.
Conclusion
Functional safety in industrial automation comes down to a simple promise: when the process goes wrong, the protective function works, and you can show why you believe that. If you build or maintain control systems, understanding this chain and the PFD arithmetic behind it makes you a better collaborator with your process safety colleagues. If you work in this field, I would be interested in how you handle proof-test planning and bypass management in practice.
Author Profile
Ram Desai is a Process Safety and Functional Safety professional with a strong interest in industrial risk management, Safety Instrumented Systems (SIS), and Safety Integrity Level (SIL) engineering. He writes about functional safety in the oil and gas industry, process hazard analysis, SIL determination and verification, safety lifecycle management, and IEC 61508 and IEC 61511 standards.
Through his articles, Ram aims to make complex safety engineering concepts easier to understand and apply in real-world industrial environments. He is particularly interested in sharing practical insights, engineering best practices, and knowledge that helps professionals design, assess, and maintain safer industrial systems.
His goal is to promote safety awareness, support continuous learning, and help engineers make informed decisions that protect people, assets, and the environment.
Top comments (0)