Applying Safety Integrity Levels to Process Control Software

Applying Safety Integrity Levels (SIL) to process control software ensures that safety functions perform reliably enough to reduce risk to a tolerable level. This guide walks you through the systematic process—from hazard analysis to verification—so you can assign and implement appropriate SILs for your safety instrumented functions (SIFs). You’ll need a basic understanding of risk assessment and functional safety standards like IEC 61511.

What You’ll Need

Process hazard analysis (PHA) or HAZOP study results
Risk matrix or risk graph (company-specific or from a standard)
Safety requirement specification (SRS) template
Access to IEC 61511 (or IEC 61508 for software development)
Software development lifecycle documentation (if developing custom software)
Reliability data for components (failure rates, proof test intervals)

Step-by-Step

Identify safety functions. From your PHA/HAZOP, list all safety instrumented functions (SIFs) that are required to bring the process to a safe state. Each SIF is a loop consisting of sensors, logic solver, and final elements.
Conduct a risk assessment. For each SIF, determine the risk reduction needed. Use your company’s risk matrix or a risk graph method. The difference between the existing risk and the tolerable risk defines the required risk reduction.
Assign the SIL level. Map the required risk reduction to a SIL level using the table in IEC 61511 (e.g., SIL 1 = risk reduction 10-100, SIL 2 = 100-1000, SIL 3 = 1000-10000). If the risk reduction exceeds 10000, you may need multiple SIFs or a SIL 4 (rare in process industries).
Document the Safety Requirements Specification (SRS). For each SIF, write down the SIL, the safe state, the response time, the proof test interval, and any diagnostics requirements. This document is the basis for software design.
Design software architecture. If you’re using a certified logic solver (e.g., a safety PLC), the software is often pre-certified. For custom software, follow IEC 61508-3. Choose an architecture that meets the SIL: for SIL 1, simple measures; for SIL 2/3, more rigorous measures like redundancy, diverse programming, or formal methods.
Implement software according to the SRS. Write code using safe programming practices: avoid dynamic memory allocation, use defensive programming, and ensure all variables are initialized. Use a certified compiler if possible.
Perform verification and validation. Test the software against the SRS. Include fault injection tests, boundary value tests, and integration testing. For SIL 2 and above, use independent verification (someone other than the original programmer).
Assess the achieved SIL. Calculate the probability of failure on demand (PFD) for the entire SIF using reliability data. For software, the SIL is often determined by the hardware and the systematic capability of the software. Ensure the PFD is within the SIL range.
Document everything. Keep records of the risk assessment, SRS, design decisions, test results, and any deviations. This is required for audit and future modifications.

Common Mistakes

Assigning SIL based on consequence only. SIL is about risk reduction, not just severity. Always consider likelihood and the existing protection layers.
Forgetting the proof test interval. A longer proof test interval increases the PFD, so you may need a higher SIL. Always include the interval in your calculation.
Ignoring systematic failures. Software can fail systematically due to bugs. Even if the PFD is low, a single bug can defeat the safety function. Follow the software lifecycle rigorously.
Using non-certified components for SIL 2+. For higher SILs, use components with proven-in-use or certified to IEC 61508. Check the safety manual for constraints.
Not updating the SRS when changes are made. Any change in the process or software must be reviewed for SIL impact.

Tips

Involve the safety team early. SIL assignment should be a team effort including process engineers, control engineers, and safety specialists.
Use a SIL verification tool. Software like exida or SIS-TECH can help calculate PFD, but always verify the inputs.
Keep software simple. The simpler the software, the easier to verify and maintain. Avoid complex algorithms unless absolutely necessary.
Plan for diagnostics. The SRS should specify diagnostic coverage for sensors and final elements. Automatic diagnostics can reduce the proof test frequency.
Document assumptions. If you assume a certain failure rate, write it down. This makes the SIL claim auditable.

Troubleshooting

PFD calculation is too high. If the calculated PFD is above the SIL limit, consider: reducing the proof test interval, adding redundancy (e.g., 1oo2 sensors), or improving diagnostics. Recalculate after each change.
Software fails a test. If the software doesn’t meet a requirement, go back to the SRS. Is the requirement clear? If not, update the SRS. Fix the code and rerun the full test suite.
Audit finding: missing documentation. Keep a single repository for all SIL-related documents. During the project, regularly review that all steps are documented.
Disagreement on SIL level. If team members disagree on the risk assessment, use a facilitated session with a risk matrix. If still stuck, consider a more conservative SIL (higher) but note the cost implications.

Frequently Asked Questions

What is the difference between SIL and PL?

SIL (Safety Integrity Level) is used in process industries (IEC 61511) and machinery (IEC 62061). PL (Performance Level) is from ISO 13849 and is used for machinery safety. They are not directly equivalent, but there are tables to approximate.

Can I use a standard PLC for SIL 2?

Yes, if the PLC is certified for SIL 2 and you follow the safety manual. However, you must also ensure the entire SIF meets the PFD requirements.

How often should I proof test?

The proof test interval is determined by the PFD calculation. Typically, it’s annually, but it can be more frequent for SIL 3 or if the PFD is close to the limit.

What is systematic capability?

Systematic capability (SC) measures the robustness of the design process against systematic faults. It is rated SC 1 to SC 4. For SIL 2, you typically need SC 2, and for SIL 3, SC 3.

Is SIL 4 ever used in process control?

Rarely. SIL 4 is for extreme risks, such as nuclear or offshore. In most process industries, SIL 3 is the maximum, and multiple SIFs are used instead.

Do I need a certified compiler?

If you’re using a certified logic solver, the compiler is usually certified. For custom software, a certified compiler helps reduce systematic errors, but it’s not mandatory if other measures are in place.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →