In the field of process safety and instrumented system design, one common question often surfaces:
“If a safety function has an achieved SIL (SILa) of SIL0, do we still need to retain that SIL rating in the interlock logic?”
At first glance, the answer may seem obvious—SIL0 means “no required safety integrity,” so we can just remove it, right?
But in reality, the answer depends on how the function was evaluated, its historical purpose, and its role in the current protection layers.
🔍 Understanding the Terminology
SILr (SIL required): The target Safety Integrity Level determined from a risk assessment (e.g., LOPA).
SILa (SIL achieved): The actual SIL that a function or loop has been designed and validated to meet.
SIL0: A designation that indicates no Safety Instrumented Function (SIF) is required; the risk can be adequately reduced without a SIS.
🎯 Key Principle:
If the Target SIL (SILr) is SIL0, the function does not need to be retained in the SIS or managed under SIL requirements.
This means:
No need for formal proof testing according to IEC 61511.
No need to keep safety lifecycle documentation or SIL verification reports.
The function can be reclassified as a non-SIS interlock or simply part of the basic process control system (BPCS).
📉 So Why Do SIL0 Functions Still Exist?
There are several possible reasons:
Historical Overdesign: Originally evaluated with high risk → later reevaluated with improved safeguards (e.g., pressure relief valves, operator actions).
Design Reuse: The same hardware is reused in multiple SIFs, some of which may still require SIL rating.
Conservatism: Teams may hesitate to fully remove a SIL tag in case the function may be upgraded later.
📌 Decision-Making Flowchart
Use a structured approach to determine whether the SIL0 function should remain in your SIS logic. This involves checking:
Is the current SILr = SIL0?
Are there other protection layers already effective?
Is the function still useful operationally, even if not safety-critical?
📝 Declassification Recommendation Table
To support your decision, consider using a Function Declassification Table, which evaluates the hardware, safety role, documentation, testing needs, and operational impact.
📄 Instrument Function Declassification Recommendation Table
| Item | Description | Recommendation | Remarks |
|---|---|---|---|
| 1 | Function Target SIL (SILr) | SIL0 | No further SIL management required |
| 2 | Risk Reduction Required | Achieved through other protection layers (e.g., BPCS, alarm + operator action) | Declassify from SIS |
| 3 | Hardware Capability (SIL Capability) | Hardware may support SIL1 or higher | Maintain as non-SIS, optional reuse in future SIL upgrade |
| 4 | Design Documentation Status | Originally designed as SIL-compliant | Archive documentation, update logic classification |
| 5 | Current Testing & Maintenance Requirements | Based on SIL periodic proof testing | Shift to standard maintenance regime |
| 6 | Safety Lifecycle Impact | No impact on overall SIF if declassified | Document through formal MOC (Management of Change) |
| 7 | Functional Role in Process Safety | No longer critical for safety, or acts as backup only | Retain as operator interlock or logic bypass |
| 8 | System Revalidation Required | Not needed for SIL0 | Confirm with safety authority/HAZOP/LOPA update |
| 9 | Alarm or Indication Requirements | Still provides useful indication or alarm | Retain under BPCS or operator monitoring system |
| 10 | Operator Training and Procedures | May require updates | Update SOPs and training if logic changes |
✅ Best Practice: Document and Communicate
Even if the function is removed from the SIL framework, ensure:
Proper Management of Change (MoC) process is followed.
Operators are trained if the logic or alarms change.
Safety documentation reflects the current risk profile.
🧠 Final Thought
Not all interlocks need to be SIL-rated—but all interlocks should be justified.
In a dynamic process plant environment, where processes evolve and new hazards may emerge, periodically reviewing and validating interlock logic—even those with SIL0—remains a best practice in instrumentation safety management.