Functional Safety Podcast: episode (S1E17) is now available

Podcast Introduction and Season Overview

Well, now that we’re 18 episodes in, we can finally begin the process safety life cycle with hazard and risk analysis.

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 life cycle 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.

So, as I mentioned, we are now just starting the safety life cycle. So, for the past 17 episodes, we have been kind of getting ourselves into the position where we’ll be able to start doing a project. We started with scope. Then we went and we talked about what documents are included, definitions. We talked about management systems. So, what are all the steps that are included in the safety life cycle and planning, creating a planning document, a functional safety management plan. Then we talked about all of the administrative controls. We talked about competency. We talked about auditing.

We talked about functional safety assessments. And then we just, in the last episode, talked about verification, which is your step-by-step back checking of all the activities that occur in the SIS safety life cycle.

So, all of that was planning for how to execute a project. And now we’re going to talk about the details, finally, of how we execute the project.

Conceptual Design Context Before Clause 8

So, it isn’t until Clause 8 that you get into the activities that you’re actually going to be performing on a project-by-project basis in order to achieve functional safety. So, prior to the SIS safety life cycle beginning in earnest, we would have had to have had some sort of conceptual design of the plant to begin with. So, we recognize that we’re not starting from a blank sheet of paper. There’s going to be some sort of template design. There’s going to be some analysis that was performed. There’s going to be some sort of set of P&IDs, process flow diagrams, heat and weight balances.

We have designed a plant that we expect to do the safety life cycle on.

Now, the way that the standard is written, it kind of assumes that we didn’t do anything with regards to risk analysis during the conceptual design phase. So, coming into process hazard and risk analysis, the standard sets up the requirements as though we have never even considered risk in any way, shape or form prior to getting into this part of the standard, which is absolutely not true.

For existing plants that have been designed, for instance, by licensing companies, there is generally a lot of information that’s already shown on the P&IDs with respect to the safety instrumented systems, the safety instrumented functions that we expect to exist in the facility.

So, the whole concept of starting from scratch is not realistic. But then again, from the perspective of the standards writers, this is something that you realistically have to assume because you can’t assume that a lot of this preliminary work has already been done. So, keep that in mind as you’re reading the standard that the standard is really there to set overall large-scale requirements without understanding what your specific workflow, what your specific processes are, whether you’re starting from a new plant or starting at a new plant or you’re starting from a template.

Clause 8.1 Objectives for Hazard and Risk Analysis

So, let’s go through clause 8.1, which is going to be the objectives. The objectives, as usual, every section begins with a set of objectives.

Those objectives are informative. They tell you what’s trying to be accomplished. And then the second clause of each section is where the requirements are actually going to begin. So, let’s start with the objectives.

The objectives of the requirements of clause 8 are to determine. And then you’re going to get a series of six bullet points. We’ll hit each point one at a time. So, first bullet point, the hazards and hazardous events of the process and associated equipment. So, the process hazard and risk analysis is intended to determine what can go wrong that can put us into a dangerous state that we might need a safety instrumented function to protect us against.

Bullet point number two, the sequence of events leading to the hazardous event. So, what you’ll see a little bit later on in the standard is this sequence of events leading to a hazardous event. For those of you that practice layer of protection analysis or LOPA, that would be a LOPA scenario. It begins with an initiating event. It goes through the failure of one or more safeguards or independent protection layer and then leads to a consequence.

So, we need the hazard and risk assessment to be able to inform us on the entire sequence of events, not just the frequency on how often we expect things to explode. So, we need causes. We need safeguards. We need consequences. Third bullet point, the process risks associated with the hazardous event. So, if there is a hazardous event, so what? What is the consequence? How often would we expect that consequence to occur if the safeguard were not in place? So, that, you know, kind of going back to the definition of risk there, what can go wrong?

What are the consequences if something goes wrong? And how often do we expect that to occur? That’s going to tell us what the level of risk is.

Fourth bullet item, any requirements for risk reduction. And that’s an interesting thing to note because the way that the standard splits things up, it actually takes what we would generally do in a HAZOP or a LOPA analysis and break it into multiple pieces between Clause 8 and Clause 9. So, in Clause 9, it states that we need to identify any requirements for risk reduction. So, that means for any of those scenarios, any of those sequence of events where the risk is not tolerable, the risk is higher than we want it to be, we need to determine what are the requirements for risk reduction.

In other words, what is the gap between the risk that we have now and the risk that is tolerable? Now, we don’t need to make recommendations to close that gap in Clause 8. Closing that gap is going to happen in Clause 9, even though most of you that have been through a layer of protection analysis study know that these things kind of happen at the same time. We identify what our gap is and then we make recommendations to close the gap, including assigning a SIL target.

But remember, with respect to the way that the standards are laid out and the recommendations or the requirements are laid out in the standard, in Clause 8, we’re determining what the hazards are and if there’s a gap. And the size of the gap is kind of the output from Clause 8 into Clause 9, where we determine what safeguards are we going to use to close that gap.

So, item 4 was any requirements for risk reduction. Item number 5, we need to determine the safety functions required to achieve the necessary risk reduction. So, this one kind of conflicts with Clause 8 because we’re saying that we don’t know how we’re going to close the gap yet. But some sort of functionality that’s required to reduce the risk needs to be defined here. So, we’re going to need to know what the gap is. We’re going to need to know what the risk is. And that’s going to tell us about what options we have to be able to close that gap.

So, a safety function in Clause 8 is just some sort of action that’s going to be required to get us to a safe state.

But what’s not defined in Clause 8 is whether that’s going to be a basic process. Control interlock, operator intervention based on alarm, safety instrumented functions. We’re going to have a lot of ways to achieve that safety function. But we need to know what the functions are. And then finally, bullet point number 6 of Clause 1 is that we need to determine if any of the functions are safety instrumented functions. Now, I know in the back of your mind you’re thinking, well, isn’t that allocation? Kind of is.

But at the same time, you need to remember that when you’re going into your hazard and risk analysis study, you’re generally not going in with a blank sheet of paper. And a lot of times, you’re showing safety instrumented functions on the P&ID. So, you know they’re there. You know that the equipment is there. It’s expected to be used. So, that’s a situation where you’re going to make a note of, well, we have a safety instrumented function shown on the P&IDs. We’re expecting to be able to use that in the allocation process in order to get our risk to a tolerable level.

Okay.

So, those are the objectives. Kind of summarizing, we need to analyze all the hazards of the equipment. Determine a sequence of events for all those hazardous events that we’re concerned about. Determine whether or not we have a gap between tolerable risk and what the estimated risk is of the plant design as is. And then we’re going to define safety functions that are required to get us to a safe state. And we will also define whether or not we expect any of those functions to be safety instrumented functions.

Multidisciplinary Teams and Inherently Safe Design

Now, Clause 1 is going to have three notes associated with it. So, note number one is Clause 8 addresses process engineers, hazard and risk specialists, safety managers, as well as instrument engineers. Its purpose is to recognize the multidisciplinary approach typically required for the determination of a SIF or of SIF, plural.

Now, that’s really interesting because this is an area where the standard actually looks at the process and recognizes hazard and risk analysis is not actually something that is in the purview. Or in the scope of your typical instrumentation and control engineer. Now, remember, the standard is written by the International Electrotechnical Commission. And it’s generally geared toward instrumentation and control engineers and defining the work tasks and responsibilities of instrumentation and control engineers, the electrotechnical people.

But hazard and risk analysis is a process safety responsibility. It’s a process engineering responsibility. It’s something that’s generally outside of the knowledge set of an instrumentation and control engineer. Although I will make a strong argument by the end of today’s discussion that the instrumentation and control engineers need to be intimately involved in this process. Because if you’re not intimately involved in this process, you’re going to end up with a lot of baggage coming out of that PHA study that will make your life difficult as an instrumentation and control engineer.

We will get into that before we finish the discussion of this section for sure. But what Clause 8 is recognizing is that hazard and risk analysis is necessarily a multidisciplinary activity. Furthermore, if you look at the standards, if you look at the regulations from the industry groups, from the regulatory bodies like OSHA in the United States about hazard and risk analysis, it will tell you unequivocally it is a multidisciplinary team that requires many different people. At a minimum, you need to have the people that are on the floor operating the plant involved in this discussion.

So it’s something that an instrumentation and control engineer cannot do by themselves, even if they wanted to, if they were required to, because that would be honestly illegal or at least in violation of the regulation, which is there to protect the workers who are down on the plant floor. So they need to be involved in this hazard and risk analysis process.

So note one is going to be consistent with what you’re typically going to see for your national and international standards on how to do hazard and risk analysis. Okay, note number two to Clause 8.1 states, where reasonably practicable, processes can be designed to be inherently safe. When this is not practicable, other layers of protection, C figure 9 of the standard, can be required. In some applications, industry standards can specify the use of particular protection layers.

All right, so note number two is once again going far afield of the typical workflow, the typical work processes of the instrumentation and control engineer and providing opinions, providing requirements, providing guidance on the job of the process safety engineer, who is generally not obligated or cognizant of a lot of the electrotechnical standards, which is why you see it kind of in an informative note as opposed to a requirement, because we know it’s someone other than the instrumentation and control engineer’s job to get these types of things done.

So note number two is talking about other safer means of keeping a plant safe, which is inherently safe design. So if you’re using a toxic chemical as a cleaning agent for your pharmaceutical facility during a cleaning step, if you can replace that toxic chemical with a non-toxic chemical, you’ve completely removed that hazard. So that inherently safer approach is always going to be stronger, always going to be more effective than any passive or active safeguards that you can put in place to prevent that toxic material from escaping.

So just a note to remind engineers, specifically that process safety group, that you might want to consider things other than safety instrumented systems to make the plant safe. And if you can remove a hazard, you’re way better off than if you’re putting in measures to try to control that hazard.

Independent Protection Layer Attributes and LOPA

The last note in Clause 8.1, Note 3 states, the risk reduction can be accomplished using several layers of protection, and the layers can be independent, sufficient, dependable, and auditable. So a couple things here.

Note 3 is really kind of starting you down the road of layer of protection analysis because it’s using a lot of the terminology from the LOPA books that are out there, most specifically my LOPA book, which would be systematic safety integrity level selection using layer of protection analysis, available through ISA. I highly, highly recommend my book.

But I also would recommend other books on layer of protection analysis, specifically the guidelines for layer of protection analysis from the Center for Chemical Process Safety of the American Institute of Chemical Engineers, also affectionately known as the Purple Book. So both of those books kind of lay out the foundation of layer of protection analysis.

They were released at roughly the same time. My book would have come out first if somebody at a former company didn’t convince me to let somebody else put their name on my book, which is a mistake I regret to this day in letting that guy put his name on my book. But anyway, I digress. I really shouldn’t be bitter. It was like almost 25 years ago now, but somehow I still am bitter. I do owe you, the listeners, the readers, a new version of that book. It will be coming out within the next couple years. I’m hard at work right now, actually in the bow tie section of that book.

So I’m going to combine all of the risk analysis methods together, including PHA, including hazard, including LOPA, including risk registers, including bow tie analysis, all into one book called Unified Hazard Assessment, because these methodologies truly do need to be unified instead of having the processes, procedures, nomenclature, and data structure all separated, which is hindering the process safety community from actually making good use of all that data that’s available.

But I just went off on a little bit of a side tangent, didn’t I? Okay. Note three. It’s really stressing that you can and should use multiple independent protection layers. So we don’t want to put all of our eggs in one basket. We don’t want to try to design one safeguard that is capable of doing everything, because if that one safeguard fails, we can have a catastrophic failure of the entire system. So we’re not putting all our eggs in one basket. We’re not creating a plant where one failure is going to be able to create a catastrophe.

We’re trying actually very vigorously to avoid that situation from being possible. So, yes, there’s a note that says when you’re doing your hazard and risk analysis, our preference is for there to be multiple protection layers and for those protection layers to be independent of each other, which is kind of the second part of the note says that protection layers need to be independent, independent, sufficient, dependable, and auditable.

So if you go into the ISA training on layer of protection analysis, and you go into my book, you will see that there is an acronym called CDAP, S-I-D-A, for the four attributes, the four old school attributes of an independent protection layer. So every protection layer needs to be independent from the other protection layers and also from the cause. It needs to be sufficient or specific is the word that I would prefer to use. It needs to be specifically designed and sufficient to mitigate or protect or prevent the scenario that you’re looking at in that layer of protection analysis.

It needs to be dependable. You need to be able to count on it being able to do its job to a given degree of reliability. And it also needs to be auditable. We need to make sure that that protection layer is always there, it’s always in place, and it’s going to work when we need it to work. And that process is the auditable aspect.

So sometimes we might want to use a different word. We might want to say testable or tested instead of auditable. But we also kind of have to acknowledge that there are some safeguards out there that might not be testable. So if you look at a rupture disk, for instance, if you test it, you’ve destroyed it, and you’re going to need to replace it with a new one. So we don’t test rupture disks. We audit them to make sure that they’re in place, to make sure that there’s no visible signs of wear and tear, to make sure that it’s installed correctly in the correct direction, and so on.

So that is the auditability aspect.

So those are the four OG original parts or attributes of an independent protection layer. In the 2016 book of Layer of Protection Analysis, the extension of the purple book that talks about initiating events and protection layer and tries to put some values around those numbers, they increase the attributes up to seven. And they do that by breaking the dependable into two different pieces, kind of reliability and availability. It’s a little bit more complicated than that. I will get into that a little bit later.

But also, management of change becomes a requirement, and also security is another requirement, which is going to get you up to seven.

Okay, so here we go. We’ve gotten through Clause 8.1, which is simply the objectives that we’re trying to accomplish with our hazard and risk analysis, with the acknowledgement that, well, you know what, this hazard and risk analysis is actually probably going to be done by other people than the instrumentation and control group. So we’re not really defining what the workflow needs to be in a whole lot of detail. We’re not telling the PSM people how to do their job. What we’re doing instead is we are basically stating what are the requirements from their work product.

So we’re telling the PSM group what we as instrumentation and control engineers are going to need to do our work to complete the rest of the safety life cycle for the safety instrumented functions that are identified in the hazard and risk analysis process. So let’s get into that.

Clause 8.2 Hazard Analysis Required Outputs

There’s going to be a Clause 8.2 here that we, again, it’s a long list of bullet points and there is a significant amount of discussion of each bullet point. So I’m not going to read through the whole clause. I’m going to pause after each bullet point to go into the bullet point in more detail.

So Clause 8.2.1 states an HNRA, a hazard and risk analysis shall be carried out on the materials, process, and equipment. So we’re not going, I mean, that clause seems like a throwaway, but in reality, it’s basically drawing the line that says, I am not going to implement a safety instrumented system unless you, the process group, have done a risk analysis to tell me what the hazards are and explain to me what the performance levels that I’m going to need out of these pieces of equipment is.

So you, the PSM group, must do a hazard and risk analysis on the equipment under control before I, the instrumentation and control engineer, can do my job and design that equipment.

Okay. So HNRA shall be carried out on the materials, process, and equipment. It shall result in, and then there are seven bullet points of items that need to be an outcome of the hazard and risk analysis. So item number one that is a required output of hazard and risk analysis is a description of each identified hazardous event and the factors that contribute to it. So when you’re doing your hazard and risk analysis, you’re going to identify hazardous events.

So for instance, if you’re using a HAZOP style hazard and risk analysis, you’re going to look at a guide word like high level or low pressure and then you’re going to identify a cause. And once you’ve identified the cause, you kind of have a scenario that you’re going to go through. So we need a description of each one of those hazardous events.

Now in reality, you’re going to have that description for every hazardous event that can occur in the equipment under control that you have. But with respect to safety instrumented system design, we’re really only concerned about those scenarios where we might want to use a safety instrumented function as a safeguard to protect against that scenario. Okay, so that is bullet number one. I need a description of each hazardous event.

I need you, the PSM group, to tell me a story about what situation led to this loss of containment of chemicals or energy that’s presenting a hazard that I need to protect against with my safety instrumented system. This then will lead us to bullet number two.

So for bullet item number two, it states that we need our HNRA to result in a description of the likelihood and consequence of each hazardous event. So just because a hazardous event is possible doesn’t mean it’s something that is significant enough for us to actually care about. So for instance, there are some events where the consequence is negligible. We need to restart the plant. I don’t need a safety instrumented function for something where I just need to restart the plant. Or maybe the frequency is so low that the risk is inherently acceptable.

So I need to understand the entire risk of each scenario to determine whether it’s tolerable and how much safeguarding is required.

In order to understand risk, I need to know the two attributes of risk, which are likelihood, how often is it going to happen, and consequence. If it does happen, how bad is it going to be? Now that’s generally going to come out of our process hazards analyses through risk ranking. So you’ll pick a likelihood category of the event, and you’ll pick a consequence category, high, medium, low, or whatever criteria that your organization uses.

So that’s, again, important information coming out of the hazard and risk analysis that I’m going to use subsequently to do that allocation task that will result in the SIL target.

Okay, so once I know my event, it’s likelihood my consequence, I’m going to go on to bullet three, where I know that the H&RA shall result in consideration of process operating modes such as normal operation, startup, shutdown, maintenance, process upset, and emergency shutdown. So this is a reminder to that hazard and risk assessment team that there are modes of operation beyond steady state. And honestly, when you’re doing a hazard and risk analysis, most people are kind of locked in. They’re in the mindset of my plant is in the normal operating state.

So you’re looking at steady state as your starting point and you’re deviating from steady state. But in reality, there are a lot of other modes of operation and every plant is going to have, at a minimum, a startup and a shutdown where the hazards might be different. There might be hazards that are accentuated or they may only be present in a certain mode of operation. So bullet point number three is an admonishment.

It’s a warning to say, hey, we understand that you’re going to be focused on the normal operating condition of the plant, but don’t forget to do an assessment to look at the different modes of operation. Are you creating new hazards during startup and shutdown? Are you creating a new hazard when you shut down your plant through an emergency shutdown? Are there maintenance activities that need to occur while the plant’s in operation? And with a specific focus on how do those modes of operation affect how the plant is going to operate?

Operating Modes, Safeguards, and SIF Documentation

Okay, bullet point number four, the HNRSA shall result in a description of or references information on the measures taken to reduce or remove hazards and risk. So it’s not enough to know that without a safety system, the plant is going to blow up once every thousand years. We need a little bit more granularity on that, and this kind of leads into layer of protection analysis.

So a likelihood category in a HAZOP study is built up of a lot of things. It considers the frequency of initiating events, but it also considers the effectiveness of the safeguards and rolls all that stuff into one number. But when we’re doing layer of protection analysis or other more sophisticated SIL selection techniques, we want to break that likelihood down into the individual pieces so we can look at each piece one at a time and decide whether or not it’s effective and how much credit to give it.

So we need for the PHA, the hazard and risk assessment, HAZOP studies, what if studies, whatever you’re using, they need to include a list of what all of the safeguards are at a minimum.

So, just saying, well, the plant blows up once every thousand years isn’t enough. I need to know what safeguards are present and whether or not you considered them when you were determining that likelihood category that the risk coming out of the process hazard and risk analysis is based on.

All right, next item up. and I think we’re at item number six at this point in time. The HNRA shall result in a detailed description of the assumptions made during the analysis of the risks, including demand rates on the protection layers and the average frequency of dangerous failures of initiating sources, and any credit taken for operational constraints or human intervention.

So again, we’re loading up the information that we’re going make a determination of whether or not risk is tolerable, and we’re kind of looking at clues for how the hazard and risk analysis team made its decision as to whether risk was tolerable. And here, again, we’re looking at the scenario in a little bit more detail.

So demand rates on the protection layers is also known as what are the causes of going into an unsafe state? So what are the causes of going into the unsafe state? And how often are we going to go into those unsafe states as a result of the causes? So anything that’s in the PHA that has that, we need to know about it.

Then we’re going to look at any credit for operational constraints or human intervention. So if I’m taking credit for administrative controls like lack of occupancy, I need to know that that needs to be fully and thoroughly documented in the PHA because it’s going to impact how I do my SIS design and how I do my allocation.

Okay, now we are at the seventh and final bullet point of 8.2.1. And 8.2.1 again, a list of things that shall be developed while the PSM group is developing their hazard and risk analysis. And this last bullet point is identification of those safety functions applied as safety instrumented functions.

So any type of functionality that is shown on the P&IDs, that’s shown on the cause and effect diagram, we know that there is an expectation just based from the conceptual design, that this functionality is going to get executed as part of a safety instrumented function. We need that to be documented in the PHA output, the HAZOP report, the hazard and risk analysis.

Common Cause Failures and IPL Independence

Okay, so those are the requirements of the hazard and risk analysis. Now let’s go in and look at a note. So long clause already, well actually not a long clause but just absolutely packed full of requirements, you know, one sentence at a time and each one of those sentences require a lot of discussion. So let’s read note one. Note one is a very long note.

Okay, so looking at the note, it says note one, in determining the safety integrity requirements, a count can be taken of the effect of common cause between systems that create demands on the protection layers that are designed to respond to those demands. Okay, that’s the first sentence in note one that basically says, hey, you might want to think about common cause failures because a common cause stressor might disable multiple protection layers or it might simultaneously trigger an initiating event but then prevent a protection layer from actually doing what it’s supposed to do.

So that’s tricky. a lot of this should be baked into your LOPA procedures at a minimum but it does need to be considered even during the HAZOP before you get into the LOPA stage to make sure that if you’re taking credit for things you probably don’t want to take credit for things where there’s a lot of common cause between protection layers.

Okay, so that’s kind of the going point going in point for LOPA it’s called independent protection layers for a reason they need to be independent so look at the causes common cause sources and make sure that they are controlled. Alright, the second sentence says an example of this would be where demands can arise through BPCS failure and the equipment used within the protective layers is similar or identical to the equipment used in the basic process control system.

So let me give you an example of that. Let’s say I’m trying to detect low pass flow through a fired heater. Very common safety instrumented function. If your flow through the fired heater goes low you can overheat the tubes cause them to burst. And then if they burst then you’re going to have loss of containment potential big consequences. I want to be able to detect low flow. Your LOPA scenario for this might say my cause of low flow is that my flow controller failed to the low position. It failed such that the valve went closed. That’s my initiating event.

and you might want to say well you know in terms of protection layers I’ve got a low flow alarm. So if the flow goes low my operator can respond to the alarm. Well what’s the problem there? The problem there is the flow transmitter failure can cause the flow to go low.

If it fails above the set point that’s going to drive the flow rate down to cause a low flow. And if you’re relying on that same failed transmitter to be the device that tells the operator that there’s a problem well that one failure that single point of failure created an initiating event and also simultaneously disabled your protection layer. That’s something that you’re really going to want to watch out for in your layer of protection analysis. And again that is an absolutely clear cut violation of independence in our independent protection layers. Okay next sentence in note one.

In such cases a demand caused by a failure of BPCS equipment may not be responded to effectively if a common cause has rendered similar equipment in the protection layer to be ineffective. So I think the example I gave you is a perfect example of that being the case. Next sentence it may not be possible to recognize common cause problems during the initial hazard identification and risk analysis because at such an early stage in the design process the protection layers will not necessarily have been completed.

So something that needs to be reviewed revalidated as the process design goes through the different stages of the safety life cycle but hopefully your layer of protection analysis process will have this nailed down. Next sentence in note one in such cases it can be necessary to reconsider the safety integrity requirements and SIF once the design of the SIS and other protection layers has been completed.

So if alarm rationalization took away my extra alarm that I was counting on as an independent protection layer and I only have the alarm that’s part of that flow control loop which is not independent of the cause well guess what? That might result in the safety integrity level of the safety function you’re looking at being bumped up by one. Okay. And then the last sentence in note one is in determining whether the overall design of process and protection layers meets requirements common cause failures need to be considered.

So kind of summing up note one when we’re doing our risk analysis failures that cause multiple protection layers to fail at the same time for the same reason or will cause the initiating event and prevent protection layers from operating need to be rooted out they need to be designed out they need to be driven to their root cause to make sure that they are not going to negatively impact safety.

And that should be part and parcel of a good SIL selection process and most of you out there are using layer protection analysis for that SIL selection process which should have this nailed down pretty thoroughly.

IEC 61511 Part 3 and SIL Selection Resources

All right. And then finally note two states examples of techniques that can be used to establish the required SILs of SIFs are illustrated in IEC 61511 part three. So I mentioned early on there are three parts to the 61511 standard. I am only going through part one which is the rules. Part two contains additional informative guidance kind of best practices background information and so on. Part three was written early on to help people pick SIL targets. So there’s a lot of information on risk analysis. There’s a lot of information on how to pick SIL targets.

One of these days in this podcast I will get to that. But I am not going to get to that because as you know I am part of the IEC 61511 committee and we are all talking about doing a serious refresh and rewrite of part three of the standard to bring it up to current practices because it is a little bit dated. But there is a whole lot of information on hazard and risk analysis and picking SIL targets in part three of the standard. Give it a look but understand that it is a little bit dated.

And my book on SIL selection AIC’s book on layer AICHE’s book on layer protection analysis are probably much better sources of information on that topic.

Episode Wrap-Up and Next Episode Preview

All right so all of that is only clause 8.2.1 of hazard and risk analysis but we’re kind of running out of time for this episode of the webinar. So what we’re going to do is next week we’re going to pick back up where we left off. So we’ll refresh our memory on 8.2.1 in a matter of a minute or two refreshing our memory on what we need to come out of the PHA. And then we will talk about some specific rules related to how you deal with basic process control systems how you do your documentation.

And then we will talk about cyber security and its role in hazard and risk analysis because that’s going to be clause 8.2.4. But all of that stuff is going to happen in next week’s episode.

Kenexis Vertigo Software Overview

See you then. 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 basis information more efficiently and effectively than any other software application.