Functional Safety Podcast: episode (S1E12) is now available

Introduction, Disclaimer, and Episode Recap

Just having a plan for functional safety is not enough. You need to actually implement the plan and you need to monitor things to make sure it gets done. Welcome to the Kenexis Functional Safety Podcast. I’m your host, Ed Marszal, President and CEO of Kenexis. Kenexis is a technical safety consultancy that helps chemical process industry companies to analyze risk and design engineered safeguards like safety instrumented systems and fire and gas detection systems.

Kenexis also provides the industry-leading suite of software tools, including our best-in-class Vertigo software for SIS safety lifecycle management. In this first season of the podcast, we are going to focus on the IEC 61511 standard, doing a deep dive into the standard, including more depth of information on what the standard means and how to apply it, brought to life with personal war stories and behind-the-scenes discussions of the committee members as we develop the standard in ISA 84 and IEC SC 65.

Before we start, a little disclaimer. I will be providing my opinion on technical and engineering topics. This information is provided on a best-effort basis and is of a general nature. The information presented in this podcast might not be applicable to your specific application. It is the obligation of every engineer to thoroughly analyze any system that they are designing and not blindly rely on any general advice presented in this podcast.

When we last left off, we were looking at functional safety management, 524 specifically. We were looking into some of the details related to safety planning, development plans, developing procedures to make sure that all the steps get done. Not just the execution steps, but also verification, validation, functional safety assessment. So at the end of the planning process, you’re going to have a plan. You’re going to have a piece of paper. But a piece of paper by itself is not sufficient. So we’re going to get into Clause 5.2.5, which is implementation and monitoring.

So sure, we’re going to explain what needs to happen, but we’re also going to make sure that it gets done through implementation processes and monitoring processes to make sure that it’s done and it’s done correctly.

Clause 5.2.5 Implementation and Monitoring Overview

So 5.2.5 is implementation and monitoring. 5.2.5.1 states, procedures shall be implemented to ensure prompt follow-up and satisfactory resolution of recommendations pertaining to the SIS arising from. And then after that, you’re going to get a bullet list of activities that occur that are potentially going to generate recommendations or follow-up activities needing to be done.

So right out of the gate, you are required to implement the procedure that you just wrote. Seems obvious, but, you know, we’re pretty thorough in the development of the standards. So 5.2.5.1 says procedures shall be implemented to ensure that we’re going to follow-up on any safety lifecycle activities, making sure that they are performed out to completion.

So some of the activities that we need to make sure are implemented with prompt follow-up and satisfactory resolution include hazard and risk analysis. So making sure that your PHA process is implemented and considers appropriately the safety instrumented systems is key. Item B, assurance activities. So making sure that basically that’s the whole purpose of implementation and monitoring, making sure that everything that is supposed to be done gets done.

Verification and Validation Distinction

C, verification activities. So what is a verification? How is it different from a validation? A verification is going to be that step-by-step back-checking. Paperwork back-checking is what it is most of the time, where one person performs a task and then someone else verifies. Someone else checks the work to make sure that it was done completely.

Again, that’s a step-by-step deliverable by deliverable activity.

Item D is different, and that’s validation. Validation different from verification. Validation is more of a one-time thing for an SIS as opposed to a step-by-step activity. And it’s necessarily going to be a physical test of the completed device. So verification happens primarily on paperwork, task-by-task, whereas validation is the final physical test on the completed system.

Functional Safety Assessments Explained

Item E, FSAs. We’re going to have a lot more to talk about with regards to FSAs in an upcoming episode. But FSA, it’s your functional safety assessment. It’s not the audit. We’ll get to that next.

A functional safety assessment, the best way, the most convenient way to think about that activity is you can consider it to be an audit for a specific project. So it’s different from an audit in that an audit is going to look at all of the activities in all stages for all of the SIS in the entire plan. Whereas the functional safety assessment, you’re looking at a specific project. But it’s different also from a verification because you’re not doing a detailed check of every deliverable. You already did that in verification.

So with functional safety assessment, we’re doing an audit primarily to make sure that you’re following your functional safety planning. So if you say you’re going to pick your SIL targets using risk graph, I might not like that. I might prefer to use LOPA. But if your procedures say that you’re going to use a risk graph and you don’t, you’re in violation of your procedures and you should redo things to match what your procedures say. Okay, so that’s a functional safety assessment. It’s higher level. It’s spot checking.

It’s looking at procedures and on a project by project basis as opposed to just kind of looking at the overall broad brush of all of the activities.

Functional Safety Audits and OSHA PSM

Now, speaking of the overall broad brush of all the activities, item F here for implementation and monitoring is functional safety audits. So I went into a lot of detail just a few seconds ago describing a functional safety assessment by saying it’s an audit of a particular project.

Well, functional safety audits, they have ramifications related to IEC 61511, but they also have ramifications in regards to process safety management as a whole in the big picture. So audits are one of those things that are primarily going to be driven at a regulatory level. So in the United States, we have OSHA. OSHA has the process safety management rule. And the process safety management rule sets requirements for auditing your process safety management program. Well, it just so happens that your functional safety management program is a part of your process safety management program.

Not the whole thing, not even a really substantial piece. Process safety management is broad. But when you’re looking at how do you comply, when do you comply with functional safety audits, the standard 1511 is going to give you some information. But your primary consideration in terms of timing, style, format is going to be making sure that you’re compliant with your regulator or your authority having jurisdiction that is requiring you to audit your entire safety program, all aspects of it. That’s a little bit different.

So functional safety audits.

It talks about the fact that periodically you need to make sure that the performance of your SIS is compliant with, is consistent with what your assumptions were during the design phase. Now, there isn’t anything that specifically says, this is how we want you to do accident investigations with relation to the functional safety management or the design of the SIS. But again, that’s going to necessarily be part of the process. If you had an incident, if you had an accident, you need to delve down into what all of the root causes are and address those root causes.

And one of those might be something related to the SIS safety lifecycle. So those are the tasks A through G for making sure that you have a procedure to implement the prompt follow-up and satisfactory resolution.

Now, there may be functional safety management procedures. Some of this might be tackled. It might be touched on in your process safety management program, functional safety management program. But in generally, a lot of these items are bigger picture because they affect many more things than just the safety instrumented system. So their documentation, how they’re handled, where they’re treated might be referred to in the functional safety management procedure and standard. But generally, we’re talking about other external different documents for where this information is going to be.

The procedures specifically are going to be contained.

Subcontractor Quality Management Requirements

Okay, moving along, we’re going to get into the next clause, which is 5.2.5.2. Still in implementation and monitoring. Now, this one, there are three paragraphs here. So there’s a lot of text that we’re going to need to get through.

And the text is fairly descriptive, but it’s not really related to people who are at the operating company per se. It’s basically an acknowledgment that an operating company is probably going to outsource a lot of tasks in the SIS safety lifecycle. And, you know, item number one right out of the gate, it’s okay to subcontract work to other people. But when you subcontract work to other people, you need to make sure that it gets done and that it gets done properly. Your management systems are there to ensure that all the work that needs to get done gets done well.

And it’s done in a controlled fashion by competent people. But how do you know that it’s being done well by competent people if it’s not your people that are doing the work? So that’s the purpose of clause 5.2.5.2. It begins with, let me read the first of three paragraphs. Any supplier providing products or services to an organization that has overall responsibility for one or more phases of the SIS safety lifecycle shall deliver products or services as specified by that organization and shall have a quality management system.

Procedures shall be in place to demonstrate the adequacy of the quality management system.

Okay, let’s unpack. So if you’re going to be, if you’re an external organization and you’re going to be supplying SIS services or SIS equipment, so Kenexis is a supplier. Kenexis is probably the best way to get your SIS design basis development completed. But there are a lot of organizations that do it. A lot of people want to do it internally. So you need to make the decision whether you need to have a qualified external consultant be the source of information or whether you’re going to want to do it internally.

So if you’re going to outsource to somebody external, they have requirements that are placed on them. So the first one is that there is a quality management system for that organization.

We at Kenexis have a quality management system. We have documentation. As a matter of fact, our system and our documentation gets audited twice a year. Once for an internal audit. Once for an external audit. We use PRI as our certificate holder. And we use external auditors that are recommended by PRI to maintain our certificate of compliance in good standing.

We have an external certification. That makes it easy for end users. So, you know, the easiest way to verify compliance with 525 is to ask for your vendors third party certification of ISO 9000 compliance. Well, not everybody has that. Not everybody is as good as Kenexis is. Come on. We all know that. But if you’re going to use someone to do work for you, if they don’t have a third party certification of their quality program, guess what? You have to be the auditor now.

You, the operating company, are going to need to obtain the quality program from the company that you’re proposing to have work do for you. And you’re going to need to review the quality program to make sure that it’s consistent with quality principles like ISO 9000. And you should also audit the company yourself, making sure that they can provide examples of how they implement their quality program. The same way that our third party auditor checks to make sure that we’re following a quality program.

Easiest way to deal with the first paragraph of 5252 is to just check your vendors quality programs with third party certificates. If they don’t have third party certification of ISO 9000, maybe you should look elsewhere. Maybe you should go for a higher quality. You like that? Higher quality subcontractor.

Supplier Functional Safety Management Systems

Okay, the next item says, if a supplier makes any functional safety claims for a product or service which are used by the organization to demonstrate compliance with the requirements of IEC 61511, the supplier shall have a functional safety management system. Procedures shall be in place to demonstrate the adequacy of the functional safety management system.

So, how do you do this? Well, for those of us, you know, the sophisticated top tier suppliers, we have all of the functional safety management procedures. And all of these functional safety management procedures, it’s not a single document that says this is our functional safety management plan. We’re a bigger company than that. We’re more sophisticated than that.

So, functional safety management procedures for a sophisticated ISO 9000 compliant company are going to be part of the quality program. So, we have, for instance, a procedure to perform SIL verification calculations. We have a procedure for facilitating LOPA studies. These are very long, elaborate procedures that have all of the document control programs in them. They have all of the review. They have all of the auditing that goes with ISO 9000 compliance. So, to demonstrate the adequacy of a functional safety management system.

Now, just because you have an ISO 9000 certificate doesn’t mean you have a quality functional safety management program. So, what you as the end user are going to need to do to confirm your ability to use a subcontractor is, after you’ve confirmed their ISO 9000 certification, you’re going to then also need to say, please provide to me the functional safety management procedures, your functional safety management system, at a minimum that covers the scope of services that you’re going to be subcontracting to that organization.

And that’s something we at Kenexis are very proud of. If you need copies of those procedures, we are more than happy to provide them to you in the context of a proposal process. The third paragraph states, The functional safety management system shall meet the requirements of the basic safety standard, 61508 Part 1, Clause 6, or the functional safety management requirements of the standard derived from IEC 61508, to which the functional safety claims are made.

So, the Kenexis procedures, for instance, are going to be 1508 Part 1 compliant in terms of how we document our procedures, what’s in our procedures, what our planning entails. 1508, again, is a lot of times referred to as the vendor standard. And even if you’re not a vendor of hardware, if you’re a vendor of services, then necessarily you’re going to need to know and understand what’s going on in the 1508 standard, because you as an equipment vendor have a higher standard of care than just looking at what is contained in 61508.

Clause 5.2.5.2 Summary and Vetting Guidance

All right, so that’s Clause 5252. The big picture, the big gist of 5252, is that if you are going to subcontract services, if you’re going to buy products that allow you to achieve functional safety, you need to look hard at who is supplying those components, who is supplying those services, and make sure that they’ve done their due diligence in terms of functional safety planning.

Mostly by ISO 9000 compliance, and then also by the development of the functional safety management system or procedures by which they are going to be doing their work. If they can’t readily supply that information to you, don’t walk, run, turn around, go somewhere else.

Clause 5.2.5.3 Performance Evaluation Procedures

Okay, item 5.2.5.3. We are still in 525 implementation and monitoring. The third requirement is something that is, it’s a statement with four bullet points, okay, and it all with evaluation.

So 5253 states, procedures shall be implemented to evaluate the performance of the SIS against safety requirements. So we’re going to implement procedures of evaluation of the work process, not just the equipment, but the work process for performing functional safety. The first bullet point says, you need to evaluate the performance to identify and prevent systematic failures, which could jeopardize safety.

So it’s not enough to say our people are competent. You need to have procedures that are going to evaluate how competent they are. evaluate all of the steps, all of the tools that we use to prevent systematic failures. That’s part of the evaluation process. We’re going to need to evaluate the performance so that we can monitor and assess whether reliability parameters of the SIS are in accordance with those assumed during design.

We’re going to come back to this several more times over the course of this podcast series. But when you do your LOPA and you assume the performance of your safety instrumented system is a failure rate of 1 in 10 per year, that’s an assumption. And assumptions can’t live forever. At some point in time, you’re going to need to do some work to validate, to verify, to confirm that what you assumed and what is actually happening in your plant are consistent.

Okay, next item up on the bullet list is define the necessary corrective action to be taken if the failure rates are greater than what was assumed during the design.

So it’s not enough to make sure that your failure rates are consistent with your design. That’s important. But beyond that, you also need to have a written plan for what you’re going to do. So you, at the end of your turnaround, you assess the failure rates that you achieved versus the failure rates you assumed. If your failure rates in actuality are higher than your assumptions in your SIL verification calculations, you’ve got to do something about it and you have to have a written procedure for what exactly it is you’re going to do about it.

Are you going to rerun your SIL calcs? Are you going to replace the component? Are you going to increase your test intervals to confirm proper operation? What is it that you’re going to do? That needs to be in your procedures. So make sure that happens. That’s something that honestly can often get dropped.

Okay, next bullet point. Compare the demand rate of on the SIF during actual operation with assumptions made during risk assessment when the SIL requirements were determined. So you estimated a rate when you were doing your LOPA. Is that assumption, is that assumed rate actually consistent with what is realistically really happening in your plant? If it’s not, that’s a problem. Well, how would you know that? Well, that bullet point said you need to have a procedure to make sure that it gets checked.

So on some periodic, regular basis, you’re going to confirm that everything that you assumed is going to match up with everything that’s happening in reality.

Now, going beyond that or as part of that process, how do you actually do that? Well, you’re going to need to have a program for documenting and tracking activations of the safety instrumented system and all of the initiating event and all the activation of the protection layers. Now, in the oil and gas refining industry, that’s been codified for a while now under API standards. API 754, I believe, is the standard that talks about metrics for process safety and requires you to actually keep track of that type of information.

Now, that being said, that kind of work is something that a lot of companies are only in their infancy in doing.

KISS API Integration for Demand Rate Tracking

So, one of the things that’s available to Kenexis customers, especially if you’re using our Kenexis integrated safety suite platform, is the ability to automatically document those things and track them directly in the KISS software as an activity item.

So, how does that work? For Kenexis KISS, we have an API so you can license use of application programming interfaces. And what you do with these application programming interfaces is that you can use middleware, like MuleSoft, that will read your DCS. So, the most common way to do this is that when your safety function activates or an initiating event activates, you’re going to be generating alarms.

Well, you can look at that alarm log externally. So, let’s say you’re using something like PyFromOSI as a data historian. PyFromOSI is going to have a web interface and allow you to make API calls against the alarm log. So, you can make API calls to grab the alarm log, do some logic to determine whether an alarm is associated with activation of a SIF, activation of initiating events, or activation of a protection layer, and then take that information, make another API call into KISS to push that data in.

And once you have all that information in KISS, you can report out for a particular safety function or for a particular device, what its demand rate is in comparison to the demand rate that we expected for that device. That’s something that more and more companies are spending some time and effort working on because it’s important and, well, it’s required by the standard. So, get it to work. Get it done. And if you don’t have a mechanism to do it, you would be silly not to use the Kenexis KISS platform for doing that kind of thing. All right.

Grandfather Clause for Legacy SIS Compliance

The last item in 5.2.5 implementation and monitoring is the grandfather clause. So, the grandfather clause is something that we in the U.S. had even in the 2003-2004 era of 1511 because we needed it to be consistent with our regulator.

So, OSHA in the Process Safety Management Rule already has language that we refer to as the grandfather clause and we needed to make sure that our functional safety standard was consistent with it. Now that we have a second version, if you will, of the IEC 61511 standard, it also made sense for that kind of language to be included in the IEC 61511 standard.

So, the language is 5.2.5.4 for existing SIS designed and constructed in accordance with the codes, standards, or practices prior to the issue of this standard, the user shall determine that the equipment is designed, maintained, inspected, tested, and operating in a safe manner.

So, basically, what that clause says is if you did work in accordance with an old standard, let’s say the 2003 version of IEC 61511, you don’t need to immediately come up to compliance with all aspects of the new standard as long as you kind of determine and document that what you have is safe.

Let me give you an example. In the 2003 version of the standard, there was really no discussion of never detected failures. You could get away with assuming you had perfect proof test and never have to adjust your calculations for failures that won’t be detected by incomplete testing. Now, the 2016 version of IEC 61511 dealt with that and added that requirement in. Now, with regards to grandfathering, if you have calculations that were done in 2010 for sale verification, they might not have addressed the concept of imperfect testing. What the grandfather clause says is that’s okay.

If you can determine and document you’re safe, you don’t need to come up to compliance with that requirement immediately.

You do eventually, but you don’t immediately. And that kind of clock for getting up to compliance is generally, well, I should be careful. The next reasonable opportunity is what a regulator like OSHA would use. But, well, what is reasonable? That’s kind of subjective, means different things to different people. In the U.S., we kind of hang our hat a lot on that five-year revalidation of the PHA as the trigger that kind of causes you to reassess everything that happens after that.

So, you reassessed your HAZOP, revalidated your HAZOP. Once that’s done, well, let’s go ahead and revalidate the LOPA and then let’s revalidate the SIL Verifications, SRS, and all that other stuff. Okay, so, that is clause 525. implementation and monitoring. That’s where we’re going to wrap it for today. When we come back next time, we’re going to talk about functional safety assessments, clause 5.2.6. But, we’re going to reserve that for next time.

Kenexis Vertigo Software Overview

Now that you’ve heard some insights on technical safety, functional safety, and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our SIS safety life cycle management tool Vertigo. Vertigo is a comprehensive tool set for performing assessment calculations, documenting, and maintaining the design of safety instrumented systems.

Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation. Each safety function can then be analyzed by performing a SIL verification calculation, complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities.

After the SIL verification calculations are defined, you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments. Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries. After the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility.

Kenexis Vertigo is the most integrated, easy-to-use enterprise tool for allowing the development of SIS design-based information. Thank you. you.