Skip to the content

Benefits of a Database Driven Safety Integrity Level (SIL) Calculation Engine

To highlight why a database driven SIL Calculation Engine in my opinion is mandatory, let me present a use case.

  • Global chemical manufacturer
  • Rolling out IEC 61511 across all of their 15 sites
  • Each site has on average of 500 SIFs
  • Thus a total of 500 SIFs x 15 sites = 7,500 SIFs corporate wide
  • Generic failure rate data used in initial SIL Calculations

So, if one uses a stand-alone non-database driven SIL Calculation engine, you’ll need to initially complete 7,500 SIL Calculations.  This task by itself might sound like a large effort, but is not insurmountable and could be readily accomplished by competent staff.  However as functional testing is executed and real world failure data is collected over the next several years, maintaining stand-alone SIL Calculations will truly become unmanageable.  Again, let’s build upon the above use case:

  • Of the 7,500 SIFs,  – 500 SIFs use a pressure transmitter as a sensor in some type of voting scheme (1oo1, 1oo2, 2oo3, etc.)
  • The functional test interval is 12 months for these 500 pressure transmitter based SIFs
  • 3 years of failure rate data has been collected
  • 3 yrs x 8760 hrs / yr x 95% process unit online = 24,966 hrs time in service for each pressure transmitter
  • 24,966 hrs x 500 pressure transmitters = 12,483,000 hours in service for all pressure transmitters

So, I’ve collected a lot of failure rate data, done a great job at classifying failures (safe, dangerous, process fluid, installation detail, etc.), and calculated some potential new failure rates that I wish to incorporate as mandated by IEC 61511 back into to my SIL calculations.  So, let’s think through how this would play out:

  • Step 1 – Insert new proposed failure rates for my real world pressure transmitter into SIL Calculation tool
  • Step 2 – Run 500 SIL Calcs with the new proposed failure rates.  For simplicity, let’s say 400 SIFs pass (exceed SIF Risk Reduction Factor target) and 100 SIFs fail (do not meet SIF Risk Reduction Factor target)
  • Step 3 – For the 400 SIFs that passed, run additional iterative calculations to determine what the maximum test interval could be and still meet SIF Risk Reduction Factor target
  • Step 4 – For the 100 SIFs that failed, run additional calculations to determine if the test interval could be reduced to allow it to meet SIF Risk Reduction Factor target
  • Step 5 – Further analyze your failure rate data looking for bad actors. Are all pressure transmitters equal?  Do you have some smaller set of devices in plugging service, poor installation details, etc. that are actually driving your failure rates higher?  Do you need to break out multiple taxonomies for different pressure transmitters – make / model, process fluid, installation detail, etc?
  • Step 6 – Repeat steps 2 – 4 for each new class of pressure transmitter failure rate data potentially desired
  • Step 7 – Analyze overall SIL Calculation results and develop a MoC to update your failure rate library and issue updated SIL Calculations according to your new selected failure rates and classes of pressure transmitters

So, the project we initially saw to complete 7,500 SIL Calculations with a static stand-alone tool has now ballooned into completion of what could ultimately become an excess of 100,000 iterations of SIL Calculations when one attempts to analyze real world failure rate data and incorporate these results into your reliability models. 

Most end users don’t have the staff on hand to deal with the above level of effort.  Thus, utilization of a database driven SIL Calculation engine that can allow an end user to quickly analyze use of new real world failure rate data by:

  • Simply running a report for steps 2, 3 and 4 that does the initial SIL Calculation and all sensitivity analysis for all 500 SIF SIL Calcs in an automated fashion
  • Allows one to quickly and efficiently further analyze the data per step 5 and 6 and re-run a report for steps 2, 3 and 4 for each class of transmitter desired
  • Supports the MoC process of managing failure rate libraries for use by all end users at the 15 sites

The overall goal of the safety lifecycle is to cost effectively remove risk from the business.  One of the key components of this is fully understanding how your instrumentation in your process conditions with your maintenance practices are performing compared to the assumptions made in your risk analysis.  So, with this end goal in mind, that’s why I made the aggressive statement above that a database driven SIL Calculation engine is mandatory.  The safety lifecycle needs to be simple or end users won’t truly get the full benefit of its implementation.


comments powered by Disqus