Functional Safety Podcast: episode (S1E14) is now available

Introduction and Episode Overview

Functional safety assessments and functional safety audits are different. Audits cover the entire operation of the facility at all times. Functional safety assessments are for a project.

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.

Last episode, we talked about the functional safety assessment. We’re still in Clause 5, by the way, which is the kind of big-picture management of the safety lifecycle as a whole. So in 5.2.6.1, we talked about functional safety assessments, which are essentially audits of work that has been done but limited to a specific project.

Audit vs FSA and PSM Governance

And now we’re getting into Clause 5.2.62, which is functional safety auditing and revision. So auditing and functional safety assessments can be very confusing. But there’s no need that they actually should be confusing because one serves the purposes of process safety management as a whole and is really regulated directly under the process safety management standards in the U.S. That’ll be the OSHA-PSM rule. And the other one is part of the SIS design lifecycle.

So when we start talking about auditing, we’re going to look at program quality and verification. So PSM states that you need to audit your process safety management processes. And the SIS safety lifecycle is just one of many process safety management items that need to be assessed and addressed and considered during an audit.

And the rules for the audit are going to be coming directly from the OSHA-PSM standard as opposed to the IEC 61511 standard. So things like who is involved, when does the audit happen, the IEC 61511 standard says that you need to do them, but most of the heavy lifting and most of the details of the requirements are going to be based out of PSM, not the IEC 61511 standard. So your company is going to have policies and procedures for how process safety management tasks happen, or how process safety management considers auditing.

And those are the ones that you’re going to need to follow for your SIS safety lifecycle.

So what is an audit? An audit is different from a verification. You’re not actually going to check work to see if it was done correctly. You’re not back-checking someone’s work from a previous phase in the lifecycle. It’s not a verification activity. What’s happening in audits is to make sure that the requirements of some standard are being achieved. And with regards to PSM, you’re really verifying that the requirements of the PSM rule from OSHA in the U.S. are actually being implemented.

PQV Framework Explained with BPCS Example

So the process for doing an audit goes by the acronym PQV, Program, Quality, and Verification. So when you look at a requirement in a standard, the first thing that you look at in the audit is, is there a program for how this requirement is being met? And when we say program, it’s not computer software. By program, we mean some sort of systematic process, some sort of systematic set of procedures and set of tools to ensure that the work activities that will fulfill the requirement are actually being achieved.

So program, most of the time, is going to be documented in written procedures and written policy documents. So when I’m going through the audit, I’m going to try to determine and gather evidence for what is the program that is ensuring that a requirement is being achieved. So let me kind of skip forward in the standard a little bit and kind of get into a little bit of the meat of it. And I’m going to go into clause, let’s say, something fairly straightforward.

So if you look at clause 932, the standard in allocation, the allocation clause says that the risk reduction claim for BPCS protection layer shall be less than or equal to 10. So that is a requirement that needs to be met. When I’m auditing, I want to find a program that tells me that the BPCS protection layer credit is always going to be less than or equal to 10%. So I’m going to look for corporate standards. I’m going to look for corporate policy statements. I’m going to look for data.

In this case, the typical place that you would find evidence or basically where would the program reside, it would typically be in a layer of protection analysis procedure. And that layer of protection analysis procedure will have a statement that says when a BPCS is used as a protection layer, credit shall not be greater than a risk reduction factor of 10. Or maybe you’ll find it in a table of credit that you can claim for different protection layers where you will see that 10 would be a limitation on the credit that you could take.

So finding that document that says, what is my program to meet this requirement? And that document then becomes evidence in the auditing process.

Okay, so that’s kind of step number one. What is the program? Number two is what is the quality of the program? So how well are you actually achieving that requirement? Now, let’s say instead of having a corporate standard that limits you to a risk reduction factor of 10 for a BPCS protection layer, let’s instead say, well, I was auditing the company and they told me that, well, all our facilitators have been trained that that’s what they’re supposed to do. Or our facilitators follow the Lopa Blue Book for independent protection layers and initiating events.

Well, that the quality of the program of saying, oh, my people are trained that and this is the source of training. That’s a lower quality than having a corporate standard that says this is the limit. So the quality is an assessment of how likely is that rule to be followed given that it is a rule. So there’s some sort of guidance, some sort of program indicating that this requirement will be met. And then there’s kind of a judgment as to the quality or how well will it be met. So I look for my program, document my evidence of the program. I make an assessment on the quality of the program.

And again, there’s going to be evidence and there’s probably going to be some sort of judgment as to the quality.

And then finally is the V in PQV, which is verification. Okay, so my organization has a standard that says that I’m not allowed to take credit greater than risk reduction factor of 10 for my BPCS protection layer. For verification, what I’m going to do is I’m going to go look at project documentation to verify that a credit of greater than 10 is not being taken for BPCS protection layers. So I might ask to see the most recent versions of LOPA studies and scan through the LOPA studies to see what credit is being taken for BPCSs and see if there’s any violation against the guidance.

See if I can find any instances where a greater than a risk reduction factor of 10 credit is being taken for the BPCS protection layer.

Now, this is not going to be a comprehensive analysis all the way across the board. It’s a spot check. That’s really the best that you can do when you’re doing an audit. You can’t look at every instance. And the purpose of an audit is not to redo the verification. It’s just to spot check to make sure that you have a program, the program is good, and that the program is actually being followed in practice. So that’s the process that’s going on for an audit.

Audit Scope and Real-Time Plant Coverage

And I just brought up one clause of the standard. The audit needs to be checking every clause of the standard. Now, what’s also important to know for the audit is that the audit is real time of the plant in operation. So there are a lot of old projects. There are a lot of projects that are in progress. There are a lot of projects that are in the planning phase. And there’s a large portion of the facility that doesn’t have any projects going on.

So when you’re doing an audit, you’re kind of doing a timestamp of all of the pieces of equipment, all of the operations in the facility at that point in time.

Whereas when you’re doing a functional safety assessment, you’re doing largely the same thing as an audit, except you’re looking at a certain gate in a certain project. Okay. So that’s kind of the, or really actually detailed discussion of what it means to audit something. I mean, I think I’m a good 10 minutes into the podcast at this point in time, and I haven’t done anything other than tell you what you’re doing when you’re auditing. And then that’s also a good discussion of the difference between a functional safety assessment and an audit, because you need to do both.

You need to do functional safety assessments to be in conformance with the standard, and you need to do audits to be in conformance with the standard, but you also need to do the audits to be in conformance with the process safety management regulation that is in force in your territory, wherever that is in the United States. That’s going to be the OSHA process safety management rule.

Clauses 5.2.6.2.1 and 5.2.6.2.2 Requirements

Okay. Now that we know what auditing is and how it’s different from functional safety assessment, let’s go ahead and look at the requirements. So functional safety audit and revision is 5262. Let’s look at clause 52621, which says the purpose of the audit is to review information documents and records to determine whether the functional safety management system is in place, up to date, and being followed. Where gaps are identified, recommendations for improvement are made. Okay.

So that’s mostly true. So, well, it is definitely all true, but it’s incomplete in reality because it says we’re going to review documents, we’re going to review records to make sure that our functional safety management system is in place, it’s up to date, it’s being followed. But we’re not only going to review information and records, we are also going to interview the people who were involved in the safety life cycle.

So I would include in there that you’re going to be interviewing the personnel that are involved in functional safety management and implementing the functional safety management system.

Clause 52622 says, all procedures identified as necessary resulting from all safety life cycle activities shall be subject to safety audit. Well, of course. So all of the procedures that you’re following are part of your audit. They’re necessary. As you remember when I was describing what a audit is, there’s the P, the program. So those procedures for safety life cycle activities, that is the program and that becomes evidence that you need to document when you’re doing your audit.

So absolutely, you need those procedures. They are your program. You need to list them as documentation and review them for their quality.

Independence Requirement and Audit Procedures

Clause 5.2.6.2.3 states, functional safety audit shall be performed by an independent person not undertaking work on the SIS to be audited. Procedures shall be defined and executed for auditing compliance with requirements including. Okay, before I go into the bullet points of clause 5.2.6.2.3, it states that the functional safety audit shall be performed by an independent person. This is true of, it’s the same statement, same requirement in the OSHA process safety management rule.

And I am certain that all of your auditing procedures are going to state clearly that the audit needs to be done by people that are independent. And it’s probably going to need to be an independent organization. So team members from another site, team members from corporate, people from independent third-party companies who specialize in doing audits.

And these requirements and the procedures for doing audits, again, they’re not something that’s controlled by the instrumentation and control group. This is done by the process safety management group at a higher level. Auditing is a bigger picture item, much bigger than just instrumentation and controls. Okay, so independence is required.

So what are the requirements? Number one, the procedures for doing audits need to include the frequency of the functional safety audit activities. This in the United States is going to be a slam dunk because OSHA requires that audits be done once every three years. And those audits necessarily require you to look at your safety instrumented systems. Now that might change in other jurisdictions. Other countries might have different rules where it’s more frequent or less frequent. But that’s essentially going to be dictated by the process safety management regulations.

Two, the degree of independence between the persons, departments, organizations, or other units carrying out the work and those carrying out functional safety auditing activities. So for those items, so we’re going to list out what the activities are and we’re also going to, in our documentation, again, controlled by the PSM group, define exactly what we mean by independence.

Whether somebody at the site that’s independent can do it, maybe they’re a different unit, or whether you’re going to get somebody from corporate or somebody from a peer facility, sister facility, that needs to be defined in the procedures.

And the third bullet item is that the procedures are going to explain what the recording and follow-up activities. So what type of report needs to be generated, who is going to follow up on it, how are they going to follow up on it, and so on.

Management of Change in Clause 5.2.6.2.4

Okay, moving on to the next clause, which is 5.2.6.2.4. The clause states, management of change procedures shall be in place to initiate, document, review, implement, and approve changes to the SIS other than replacement in kind. For example, like for like, an exact duplicate of an element or approved substitution that does not require modification to the SIS as installed.

This clause, 5.2.6.2.4, is actually really, really out of place. The IEC 61511 standard has an entire separate section dedicated to management of change. So, yeah, we’re going to get a whole clause later on in the standard discussion when we talk about management of change. So, why they felt the need to put a requirement for management of change in the auditing section is a little bit curious to me.

But management of change, making sure that you have management of change procedures, is something that’s required in the OSHA PSM rule and whatever other process safety management regulation is in place in your country or your jurisdiction.

So, yes, it’s something that needs to be done. It’s something that we have an entire section of this standard dedicated to. Unnecessary repetition in my estimation, but it is what it is. It doesn’t hurt, I guess, to mention it again. Okay.

Clause 5.2.6.2.5 and MOC Audit Obligations

Flogging MOC a little bit is the last part of the 5.2.6 section, which also talks about management of change. And that is 5.2.6.2.5, which states management of change procedures shall be in place that identifies changes that will affect the requirements on the SIS. For example, redesign of a basic process control system, changes to manning in a certain area. There are a lot of things that will trigger management of change procedures, and we need to audit not the SIS program, but the management of change program to make sure that changes related to the SIS are actually happening.

So, we’re not just going to look at the activities of the instrumentation and control group. we’re actually going to look through those management of change tickets and search for tickets that are related to the safety instrumented system and make sure that MOC is actually happening for all changes that are going to impact an SIS that are not replacement in kind. Because if you know management of change, you know that replacement in kind, exact like-for-like changes, do not require the management of change procedure to be executed.

Alright, so those are some of the rules related to functional safety audit and revision. 5.2.6.2 is the clause in the standard. Pretty succinct, only five requirements that should be fairly easy to implement. And as I mentioned, the frequency at which these things occur, if you’re in the US, the OSHA PSM rule requires this to be done every three years. And it’s usually not its own activity. It’s something that’s going to occur as part of the grand process safety management audit, which is going to include everything PSM related.

And safety instrumented systems is just a relatively small portion of the larger activity of the audit as a whole.

Clause 5.2.7 SIS Configuration Management Intro

All right, let’s move on now to the last clause in section 5. And the last clause in section 5 is 5.2.7 SIS configuration management. Now, I’ve always thought that this clause is rather oddly placed. It probably belongs in clause 12 where we do the deep dive into application programming of the SIS. But I guess at a management level, at a higher level program level, you need to write down what is the program for how we’re going to manage our software, how we’re going to manage the configuration of the safety instrumented system.

And configuration is going to go across the board to a lot more things than you would think.

Because as you remember from early discussions, there are application programs, which are generally written in limited variability language, but there’s also fixed program language. So the configuration of a pressure transmitter is a configuration. It’s something that you need to manage and it’s something you need to track.

Now, the bad news is, yeah, there’s a lot of stuff that you need to keep track of revisions, upload dates, download dates, the contents of configuration rev A versus rev B versus rev C and so on. But the good news with respect to these things is that in general, your equipment vendors and their asset management systems and their maintenance and engineering interface effectively do all of this work for you automatically so that you don’t actually even need to think about it. When you make changes, it will track what was as found, as left, who made the change and when the change was made.

All right, so with that said, let’s go into what the requirements are and just double check and make sure that what we’re doing in our programs is going to meet those requirements.

Clause 5.2.7.1 Configuration Management Procedures

So 5271 states, procedures for configuration management of the SIS during any SIS safety lifecycle phase shall be available. Okay, so right out of the gate, and this is a tricky one, it says that you need to have procedures for how you’re doing your configuration management. You need to write down who’s tracking revision numbers, when they’re tracking revision numbers, how they’re tracking the revision numbers, where the data is being stored, where are you storing old versions. That is all part of your SIS procedure, it’s part of what you would call your functional safety management plan.

This stuff needs to be documented as to how you’re going to do it. Now, the note with respect to the standards requirement is, note, in particular, the following can be specified, and there are three bullet items. bullet item number one, the stage at which formal configuration management is to be implemented.

So, what that means is there’s kind of an early development phase where you don’t necessarily need to keep track of what you’re doing because everything is kind of high volume changes in flux, your requirements are still kind of ambiguous, and you’re just kind of putting stuff together, but there’s a point in time where you need to start keeping track of your revisions.

Bullet item two, the procedures to be used for uniquely identifying all components of a SIS or SIS subsystems, for example, devices or application programming. So, how do you list what are all the components that have configurations that you need to track what their configurations are?

So, that’s, I mean, definitely, as you’re going through your workflow, your SIF list is going to contain a list of all of your systems and subsystems, and some of those systems and subsystems need configurations and application programs, some of them don’t, so you need to keep track of that, and honestly, for subsystems like sensors and final elements, asset management systems are where you would typically track that.

For your application program, your maintenance and engineering interface is where you would typically track that, but if your systems that are provided by your equipment vendors aren’t sophisticated enough to track that, you need to have a program for how you’re going to track that type of information yourself. Okay, bullet number three of 5271 states, the procedures for preventing unauthorized devices from entering service.

Ah, so how do you make sure that management of change is being appropriately considered? How do you make sure that you don’t add a device and don’t create the documentation for it? Don’t create the configuration, don’t save the configuration and do that kind of configuration management.

So once again, this is something that really needs to be in your functional safety management program and also this is going to be part and parcel of that management of change system. the management of change needs to give you cues and ticklers to let you know that when a change to a safety instrumented system is the addition or modification of a safety instrumented function by addition, removal, change of a component that there are software configuration and application program ramifications to that change.

Okay, so that’s 5271 says you need to have in your functional safety management program some sort of instructions and procedures for how you’re going to deal with those pieces of software and how you’re going to track them in terms of revisions and saving old versions of configurations and application programs.

Clause 5.2.7.2 Revision Control Requirements

5272 states the SIS software, hardware, and procedures used to develop and execute the application program shall be subject to configuration management and shall be maintained under revision control. So, yeah, you need to control, you need to maintain old revisions, every revision that’s created needs to be reviewed, tested, checked, 5271 said you need to have a procedure for doing that and 5272 says, well, that you need to do that.

So, revision control for your application software and even the configuration of fixed programming language needs to be done.

Again, if your software vendor takes care of all that for you, that is spectacular, particular, but sometimes they don’t. So, if they don’t, every revision of your software needs to be maintained, it needs to have who made the change, who reviewed the change, who approved the change, the date when it was uploaded, and so on. So, that’s critical to have that configuration management system for your application software and for your other software items.

Now, there is a note to 5272, and that note states, SIS software includes the application program, for example, the programs running in Logic Solvers. It includes embedded software, such as the software running on the firmware of sensors, running on the firmware of Logic Solvers, and Final Elements. Generally, that’s going to be controlled and maintained by the equipment vendors. And then there’s also utility software, which is your maintenance and engineering interface.

So, the embedded in the utility software are generally going to be tracked by your equipment vendor, if you have a certified set of equipment, that’s definitely going to be done by your equipment vendor. So, generally, what we’re talking about here is configuration of FPL devices and the application software that is running in your safety PLC.

Section 5 Wrap-Up and Clause 6 Preview

Okay, so with that, we have gotten all the way through 5.2.7, which is SIS configuration management, and now we are done with Section 5 as a whole. 5 being a very critical one where you define your program for how you’re going to achieve functional safety.

So, this is all in Section 5. The name of Section 5 as a whole is Management of Functional Safety, and we covered a lot in this section. It’s a critical, essential starting point that often gets ignored. A lot of people want to jump into project work without really doing your safety planning for how you’re actually going to make sure that all the work gets done. And it’s critical to do the planning because it’s not just the instrumentation and control group that’s responsible for doing the activities that prepare you for overall functional safety. Okay, so that was Clause 5.

In the next installment of this podcast, we’re going to cover Clause 6. Probably we’re going to slam all the way through Clause 6 because Clause 6 just contains a lot of figures. It contains a lot of tables. It’s one of those that’s not particularly good for the podcast format because there’s a lot of visual things. But Clause 6 is called Safety Lifecycle Requirements.

So we will talk about what the safety life cycle is, what’s included in the safety life cycle, and other neat definitions, some of the tables that include things like inputs, outputs, of the different phases, what the phases are in the safety life cycle. So a lot of good stuff coming up in Clause 6, but Clause 6 is going to be what we’re going to talk about 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 Lifecycle 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 CIL 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 CIL 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 basis information more efficiently and effectively than any other software application.