Functional Safety Podcast: episode (S1E7) is now available

Episode Introduction and Non-Programmable Systems

Safety systems come in programmable options and non-programmable options. Why don’t we start right there?

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.

Let’s pick things back up at 3.2.43. We are still in the definition section, still in the meat of it. Long way to go.

3.2.43 is non-programmable system or NP system, which is going to be defined as a system based on non-computer technologies. For example, a system not based on programmable electronics or software. And there is a note to the entry that says examples would include hardwired electrical or electronic systems, mechanical, hydraulic, or pneumatic systems.

Now, there are a wide variety of options used out there in industry and a very large amount of safety instrumented systems are actually non-programmable. There are still a lot of old hardwired relay panels that are used for safety applications, and they generally work very well. The probability of failure on demand is relatively low.

Spurious trip rates can become an issue, especially as these systems age. But those systems are out there, and they’re something that you’re going to need to encounter. Did we need a definition? Probably not, but you got one anyway.

Operating Environment and Operating Mode Definitions

3.244 is operating environment.

This is going to become important at the very end of Clause 10 when we’re looking at safety requirement specifications where we need to define the operating environment in which your safety instrumented system is going to reside so that your equipment vendor is capable of presenting you with the correct equipment given the extremes that it’s expected to operate in.

So it’s something that we’re always going to want to document, and there are ways to do it better. There are ways to do it worse.

First, I recommend a BEDQ or a BED basic engineering design document that is going to include all this information, and you can reuse it for all of your projects.

So operating environment, the definition is conditions inherent to the installation of a device that potentially affects its functionality and safety integrity, such as, and we have a list of bullet points, that are going to include the external environment, for example, winterization needs, hazardous area classification, process operating conditions.

So the extremes in temperature, the extremes in pressure, the extremes in vibration. Back in my UOP days, we would call this the service description. Process composition.

Let me start over on that one.

Integration within the overall plant maintenance and operating management systems. Next is communication throughput, i.e. electromagnetic interference, and utility quality. So what types of steam do I have available? What’s the quality of the steam? What are the different voltage levels and types of electrical power? Where am I getting my hydraulics? What is my instrument air pressure? All of those things are going to factor into what type of instruments are appropriate to be supplied to your plant.

So it’s best to give this type of information to your engineering companies, to your equipment vendors, to make sure that they select the correct stuff.

Note one to that entry, some process applications may have special operating environment requirements necessary to survive a major accident. For example, some equipment requires special enclosures, purging, or fire protection. This, again, is going to come up in the safety requirements specification section of the standard.

And it’s one of those things that, I don’t want to say it gets ignored, but routinely, it fails to get considered during the design process. So if you need an instrument to continue operating after your plant has blown up, It is probably a good idea to factor that into your design.

3245 is operating mode or process operating mode.

Knowing what the modes that your plant is going to operate in and how the safety instrument system needs to behave differently depending on what the mode is, is another one of those items that is going to be critical to document in the SRS. So far, everything we’ve talked about today is related to that SRS.

So the definition for operating mode is any planned state of process operation, including modes such as startup after emergency shutdown, normal startup operation and shutdown, temporary operations, and emergency operation and shutdown.

Now, a lot of times your SIS is going to behave exactly the same way no matter what mode you’re in. But other times, the safety instrumented system might behave differently.

So, for instance, for an individual instrument like a gas detector, you might have a mode of operation where you’re calibrating the gas detector. And while the gas detector is being calibrated, you probably don’t want that to trigger a shutdown of the plant. So that’s something that you’re going to need to watch out for. Now, that’s an operating mode of the instrument, but an operating mode of the plant.

Think about a typical refinery. You’re often going to have a process unit called a coker. The purpose of the coker is to take a heavy oil and thermally crack it. So we’re going to heat it up until the molecules fall apart. And often that’s going to generate some lighter hydrocarbon liquids and some hydrocarbon gases. And it’ll also generate coke, which is going to be a solid. It’s going to be a powder. And that tends to plug things up a little bit.

So one of the modes of operation for your average coker is going to be something called spalling. So in the process heater that allows the thermal cracking to occur, you’re going to generally start coating the tubes in that heater relatively early and relatively, I don’t want to say relatively quickly, but it does tend to develop over time. And in order to get good operation out of your coker unit, you’re going to want to do something to clean the coke out of the tubes. Sometimes this is going to be referred to as spalling.

So we’re going to take one tube, for instance, out of operation and blow steam through it or, you know, a variety of different options that you would have to actually clean some of the coke out while the plant is still in operation.

Now, those of you that are in the know about fired heaters know that we’re generally going to have a low pass flow shutdown that is going to prevent the heater tubes from overheating, rupturing, and releasing whatever material that is in the tubes into the firebox, which is generally a bad thing. But if you’re spalling, you might be sending some material countercurrent to the direction where it’s normally going.

You’re not going to be getting a flow signal, not a valid flow signal. So during that operation, you’re going to want to make sure that that low pass flow shutdown has been disabled.

So think about all of the different modes of operation, all the different maintenance activities that might have to occur in the plant, and make sure that you’re set up to handle them elegantly without people having to do last minute bypasses with jumper wires. Okay, so operating modes.

Operator Interface and HMI Definition

Next item up. Wow, we’re going to talk about SRS one more time. There is a note one to the entry that says the operator interface is sometimes referred to as the human machine interface, HMI.

Back at one point in time early in my career, some people would refer to it as the MMI or the man machine interface, but we have learned that we’re not allowed to do that anymore.

So operator interface or human machine interface is the mechanism that the operator uses to interact with the SIS and get feedback on what’s going on.

Sometimes it is relatively simple, just some lights and buttons. Sometimes you’ll have some gauges.

In other cases, you have a full-fledged dedicated computer system communicating with the SIS that has a visual screen showing the status of the plant and all of the information that is wired into the SIS. Sometimes that’s part of the operator interface that’s used for the DCS for the plant. So basically all of the operator interface functionality gets dumped into one location. Some people will have a dedicated operator interface that’s just used for safety instrumented system purposes. So there’s a variety of different ways that this can be tackled.

All of that is going to be discussed in the detailed design section, section 11. When we get there, we’ll talk about all of the different options that are available to you. A lot of good stuff.

And we’ll also talk about operator interface in Clause 10 for SRS because the SRS clearly states that you must define how the operator is going to interact with the SIS.

So that’s the operator interface is a key aspect of the description of what the safety system does as documented in the SRS, Safety Requirements Specifications section.

Output Function, Performance, and Phase Definitions

3247 is an output function.

Probably another one of those things that didn’t really require a definition. But we’re going to give you one anyway, and that definition is a function which controls the process and its associated equipment according to output information from the logic function.

So it’s a function that defines what an output does.

Most safety instrumented systems, most safety instrumented functions, this is simply turning an output off.

Sometimes you turn the output on. But then again, an output function might be complex in that you might create a sequence of actions that occur at different points of time. Regardless, output function defines the control actions that are being taken by the safety instrumented function.

3248 is performance. Why? Why do we have a definition for performance? Performance in accordance with IEC 61511 is accomplishment of a given action or task measured against the specification and the IEC 61511 series. Wow.

IEC 61511 wants to include the title of their standard in the definition of the word performance. All right. I don’t even know where to go with this. Why are we defining performance?

Well, we’re kind of defining performance because IEC 61511 is a performance-based standard as opposed to a prescriptive standard. So I suppose a little bit of a discussion of what performance means in the context of performance-based standards in general and this standard specifically.

I’ve said many times, including earlier in this podcast, that a performance-based standard is basically allowing you, the end user, to select a target that you’re going to achieve and then verify that you’re able to achieve that target. And in IEC 61511, we’re going to verify that we achieve that target using quantitative calculations that we will begin to talk about in Clause 11.9 when we get there.

Next definition up is for phase. And we talk about phases in Clause 6 where we define the safety life cycle and break the safety life cycle into different phases. So 3249 phase is period within the SIS safety life cycle where activities described in the IEC 61511 series take place.

So it’s a section in time. It’s a section of a flow chart, a section of a workflow where certain activities occur.

Again, I mean, you know, today’s episode, we are kind of really hitting the wall on words that have definitions that probably didn’t need them.

Prevention vs. Mitigation in Safety Functions

All right. 3-250 is prevention.

Prevention is an action that reduces the likelihood of occurrence of a hazardous event.

Prevention actually is going to be important. It might not seem so. But when we get to the risk analysis in Clause 8, when we’re calculating the performance that we’re achieving in Clause 11, when we’re allocating the amount of risk reduction that we need in Clause 9, there is an assumption that sometimes the authors of the standard make, sometimes the users of the standard kind of make a tacit implied assumption that safety instrumented functions are preventive.

And that basically means if the safety instrumented function works, there is no consequence. There’s no release. There’s no loss of containment. You prevented the harm from occurring. And most safety instrumented functions are preventive in nature.

We’re going to juxtapose this against mitigative functions, which don’t prevent the loss of containment. The loss of containment can occur, and then they take an action to make the consequence smaller or mitigate the degree of harm that occurs as a result of an event.

Mitigation functions are actually wildly complex. And, you know, there’s probably going to be another series of podcasts where I discuss the ISA 8407 technical report on fire and gas systems. And there I will get into the deep dive nitty gritty of how to handle mitigative systems.

But for what you’re going to typically see in typical SIS design looking at probability of failure on demand, typical layer of protection analysis, there is an underlying assumption that your safety functionality is preventive.

And if it’s not, your math actually isn’t going to work out and you need more hardcore methods. So a definition of prevention is warranted. And that’s going to get juxtaposed against mitigation.

Prior Use vs. Proven in Use

Next item up is prior use. It’s clause 3.2.51.

We are going to talk about prior use experience a lot when we get to clause 11.5.

There are two ways to justify using a device in a safety application. You can’t just use whatever you want.

One of them is what I shortcut call certified, meaning that the equipment vendor has designed and manufactured that component in compliance with the IEC 61508 standard.

The other method is prior use experience. So what is prior use experience?

Prior use. A documented assessment by a user that a device is suitable for use in an SIS and can meet the required functional and safety integrity requirements based on previous operating experience in similar operating environments.

So kind of making a long story short there, we have experience with the device. We’ve used the device in a similar operating profile. And we believe we understand the failure modes. We’re comfortable with how to address those failure modes with our configuration. And our probability of failure, our frequency of failure is low enough that we’re willing to accept it.

So that’s the second methodology. A lot more time is going to get spent on this when we talk about prior use in clause 11.5. There are two notes to the entry. Note 1 says, to qualify SIS on the basis of prior use, the user can document that the device has achieved satisfactory performance in a similar operating environment. Understanding how the equipment behaves in the operating environment is necessary to achieve a high degree of certainty that the planned design, inspection, testing, maintenance, and operational practices are sufficient. We’re going to go over that.

And at Kenexis, we have basically a spreadsheet that you can fill out that asks you a bunch of questions about the use of that component that you can use for documenting appropriate prior use experience. You can download that from our website, www.kenexis.com, in the resources section.

Note 2 to the entry states, Proven in use is based on the manufacturer’s design process, including temperature limits, vibration limits, corrosion limits, desired maintenance support for the device. Prior use deals with device’s installed performance within a process sector application in a specific operating environment, which is often different from the manufacturer’s design basis.

Okay, this is a little bit tricky, this second note, because it uses two terms that on their face seem very similar, if not identical, to each other, but they are not.

So the first term, Proven in Use, comes from the IEC-61508 standard. And it’s something that’s kind of dealt with by equipment vendors to justify components that are going to be used in the devices that they are selling to you. Whereas, and that’s more of a academic assessment with kind of predefined limits of what environment this component should be exposed to.

Whereas, prior use is different. It’s what is defined in the IEC 61511 standard for use by end users to justify their decision of taking a complete component and using it in a safety application.

So don’t confuse Proven in Use, which is a 61508 concept, and Prior Use, which is a IEC 61511 concept. You, as an end user, need to focus on prior use. Once again, we’re going to do a deep dive on that in one of these episodes, and that’s going to be Clause 11.5.

Process Risk Definition and IEC 61511 Part 3 Commentary

3252 is the definition of process risk, and all four of its notes to entry.

Process risk, risk in general, is a good definition to know, a good definition to understand. So what is it?

Process risk is risk arising from the process conditions caused by abnormal events, including BPCS function.

Why they singled out that one initiating event, BPCS malfunction, well, I do know. It’s the IEC, International Electrotechnician. They’re all about controls. But BPCS malfunctions are only a small subset of all of the abnormal events, things that can go wrong, that are going to generate process risk.

All right, notes to the entry. Note one, the risk in this context is that associated with a specific hazardous event in which SIS are to be used to provide the necessary risk reduction. For example, the risk associated with functional safety. Okay. Process risk. All right.

All right.

So when you look at this note, they’re kind of defining a specific hazardous event. And this is going to kind of lead you into LOPA. This is going to lead you into safety instrumented functions.

When you’re designing a safety instrumented function, there is a specific hazard that you are targeting. And what note one says is that when we say process risk, we’re generally talking about a specific hazardous event that an SIS is trying to protect against.

That’s kind of narrowing the definition of process risk. Narrows it a little bit more than I would like to see it narrowed. But, well, it is what it is. Note two to the entry.

Process risk analysis is described in IEC 61511 Part 3, 2016. The main purpose of determining the process risk is to establish a reference point for the risk without taking into account the protection layers. All right. So note two is kind of getting you into risk analysis.

It’s kind of getting you into layer of protection analysis and other methods that are used to pick SIL targets.

What note number two is trying to describe is that there is a certain level of risk that’s inherent to the process based on the operating conditions, based on the location of the plant, the temperatures, the pressures, the compositions. And that risk has a certain degree of magnitude before you start considering what are the protection layers, what are the safeguards that are available to reduce risk.

So typically when you’re saying process risk, you mean what is the risk before I start looking at safeguards. This is going to be described a little bit more in Part 3 of the IEC 61511 Standard.

Those of you that know me know that I am not a fan of Part 3, even though, you know, I came into the Standards Committee because of my knowledge of process and because of my knowledge of risk analysis.

Part 3, if you go back into the history of how it was put together, the Standards Committee writers wanted to provide some additional guidance on picking SIL targets, but they realized that the activity of picking SIL targets is really outside the scope of what the International Electrotechnical Commission does.

It’s not a safety instrumented system. It’s not an instrumentation and control problem. So they realized that instead of writing detailed rules for how to execute something like a layer of protection analysis, they put together what is effectively a technical report because everything in Part 3 is non-normative. You’re not required to do any of it. You’re only required what’s in Clause 8 and 9 of the IEC 61511 Standard, which is only a handful of pages.

So in order to put together this guidance, instead of, you know, writing a good guidance document that kind of is cohesive and explanatory, they basically collected examples of procedures from a wide variety of people.

Some were from chemical companies. Some were from oil and gas companies. Some were actually from standards bodies who did a lot of risk analysis, not necessarily for the process industries, but for the machine industries. You know, things like punch presses and conveyor systems and welding robots. And that’s honestly where a lot of the risk graph stuff came from.

And, you know, a lot of you that have tried to apply risk graph have come to realize that, wow, that’s a crappy way to do risk analysis for a chemical process. Definitely pounding a square peg into a round hole.

But so, yeah, Part 3 basically took together a lot of different methods for picking SIL targets from a lot of different industries, some of which are not the process industries, which is supposed to be the focus, and anonymized them and said, hey, end user, here’s a collection of what people out there do. Maybe you might want to do some of these things.

Today, I would never recommend using that technical report as a place to learn how to do risk analysis.

I, of course, would recommend my book, Safety Integrity Levels Selection with Layer of Protection Analysis. That’s available from ISA. You can go check it out on Amazon.com. I would also recommend the books from the American Institute of Chemical Engineers Center for Chemical Process Safety, or CCPS, that talk about LOPA specifically.

So, really, really good, cohesive, well-written books that help you through this workflow, which kind of, you know, if I had my druther, I would not even publish Part 3 anymore and just push people back to AICHE and other reference sources that describe it a little bit better.

Okay, wow, I kind of got off on a little tangent, but come on, let’s be honest. That’s why you guys are here. If you wanted to just read the standard, you could read it yourself. I’m here for color commentary and complaining about some of the people that I worked with and some of what was generated.

Okay, continuing on, note three to the definition of process risk is assessment of this risk can include associated human factor issues. Oh, boy, does it.

Human interaction with chemical process is a cause of scenarios, so it’s an initiating event. It’s also a potential independent protection layer, so humans can cause the problems, they can fix the problems, and everything in between.

Human factor analysis is a discipline unto itself. We will talk about humans and how they interact with processes almost everywhere through the standards, starting in Clause 5 with Management System and Competency. We’ll talk about how they factor into SIL verification calculations in Clause 11. We’ll talk about how they factor in risk analysis in Clause 8 and 9. A lot more on that to come.

Note four to the entry. This term equates to EUC risk in IEC 61508 Part 4.

So EUC is the term that’s commonly used in the 6508 Standard, which again is the overall big umbrella standard that covers everything from toasters to trains to self-driving automobiles to process plants. And when they say EUC, that means equipment under control. In the process industries, it’s the process that is the equipment under control. All right, let’s keep cooking along.

Process Safety Time Definition and Response Time

Clause 3 to 52.1. Again, 52.1 has nothing to do with 52. It’s just the next available slot where we needed to insert something. And 3 to 52.1 is process safety time.

Process safety time is the time period between a failure occurring in the process or the basic process control system with the potential to give rise to a hazardous event and the occurrence of the hazardous event if the SIF is not performed.

So process safety time actually is an extremely complex analysis that includes a lot of factors. So there’s a lot of things to think about, a lot of things to consider when you’re defining process safety time.

And the process safety time definition may be a little bit misleading in terms of what you actually want when you’re implementing things. So I’m going to give you a much longer and elaborate discussion of process safety time.

The next place where it shows up in the standard, which is in the SRS section, Clause 10, because you’re going to need to define process safety time for every safety instrumented function. But I would also refer you to the Kenexis Process Safety Training Center.

We have an SRS training course. And there’s an entire section of the training course dedicated to discussing what process safety time is, how you calculate it, what all the factors are.

So if you look purely at the definition and then actually let me go ahead and read out note one to the entry, which states process safety time, this is a property of the process only.

It’s not an attribute of the SIF. Okay. Continuing on with the note, the SIF has to detect the failure and complete its action soon enough to prevent the hazardous event taking into account any process lags. For example, cooling of a vessel.

So process safety time, there’s a lot of things to consider. And the definition itself gives it kind of a short attention span amount of information. And even when we get into the SRS section, it’s barely going to scratch the surface.

So think about, you know, in terms of process safety time, number one, why do we need to know process safety time?

And the answer for why we need to know process safety time is, well, at the end of the day, ultimately, the SIS needs to be able to turn around a signal faster than you can get into trouble.

So if it takes 10 seconds for you to get into trouble, your SIS needs to be able to get you out of that trouble in less than 10 seconds. Okay. Okay.

So when we’re defining the SIS response time, the SIS response time has to be less than the process safety time. But what is that process safety time composed of?

So let’s consider a high temperature scenario in a reactor. If the temperature goes high, maybe the temperature goes high because a runaway reaction is occurring. I fed too much reactant into my reactor.

The temperature is starting to go up and I am going to need to inject a killing agent to stop the reaction. Or I need to flood the reactor with cooling water to cool the reaction down or stop the reaction.

So how much time do I have to respond?

So the process safety time definition talks about a failure occurring in the process. So that failure might be, well, maybe my reactant valve failed and went to the wide open position. Now I’m overfeeding the reactor. So what’s the amount of time that elapses between when that valve failed to the open position and when I have the hazardous event?

So the hazardous event would be that the runaway reaction occurs. You over your pressure, your vessel, because the reaction happens so quickly and it ruptures. It explodes, releasing the material in the process. Maybe we have an attendant fire explosion, what have you. So the process safety time is the time between when the failure occurred and when you actually had that loss of containment accident.

Now that right there is actually not a good definition, to be honest. Because when the initial failure that occurs happens, you might not know about it. And you might not have that full time duration for your safety instrumented function to take its action.

So let’s make this a little bit trickier and say that the high temperature occurs because some internal maldistribution through the catalyst. So maybe something happens internally to the reactor where the catalyst slumps and creates a preferential path that generates a hot spot that starts generating the high temperature.

Well, I don’t really care when the slump occurred. What I care about is when I actually know that that failure is present. And if we’re measuring with temperature, I don’t know that that failure has occurred until I can actually measure that the temperature has gone high.

So there’s going to be a time lag between when you get that catalyst slump, when the reaction rate starts to increase, and when I actually see a high temperature. So when you can actually measure that that initiating failure occurred is a better determinant of how much time you have to actually take action.

Making things even worse, and I brought temperature up as one of the measured variable of interest, you have to heat your thermal well up before your thermocouple knows that the temperature went high. So there’s kind of a measurement lag between what is the temperature in the process and what is the temperature that the thermocouple is measuring.

Even making things crazier, you need to think about, well, even though I know that the temperature has gone high, well, if I do something like inject a kill agent, it might not work immediately. And there may be a time lag between when I activate my final element and when the temperature actually starts to come back down.

And how long did the temperature continue to spike up after you injected the kill agent before it actually took action and was able to do something? So more on this coming up in Clause 10. And I highly recommend looking at that section of our SRS training that talks about process safety time and response time when you’re defining your safety requirement specifications.

Programmable Electronics and PES Definitions

All right. Well, let’s keep moving along with a couple more definitions before we wrap it up for today.

We’re going to start with three or the next one we’re going to do. Obviously, we’re not just starting is process safety time or we just did process safety time.

Programmable electronics, PE, which is 3253.

Programmable electronics include items based on computer technology, which may be comprised of hardware, software, and of input and or output devices.

Note 1 to the entry says, the term covers microelectronic devices based on one or more central processing units, CPUs, together with associated memory.

Examples of process sector programmable electronics include smart sensors. So it could be a transmitter, smart sensors and smart final elements, programmable electronic logic solvers that include programmable controllers, programmable logic controllers, and loop controllers.

So there are a lot of things that you can change parameters. You can write code. And, you know, the first item in the bullet list is something written in fixed programming language where you can’t actually change the code.

So programmable might not necessarily mean that you can program it, but that somebody can program it. So it’s got a chip on it running a program, whether or not you’re the person who wrote that program. And this standard, 61511, applies to programmable electronics.

It also applies to PES. What is PES? That’s the entire system. Programmable electronic system is Clause 3.2.54.

And that is a system for control, protection, or monitoring based on one or more programmable electronic devices, including all devices of the system, such as power supplies, sensors, and other input devices, data highways, and other communication paths, actuators, and other output devices.

So for a system, we’re generally looking at more like something like a PLC. It’s a collection of equipment as opposed to a single component.

And if you want to bust out your copy of the standard, there is a drawing that shows this, figure five, programmable electronic system structure and terminology, where it kind of draws a boundary around your system as a whole and lets you know that there are going to be A to D converters on the input side. There’s going to be communications. There are going to be communications. There are going to be programmable electronics. There are going to be CPUs. There are going to be D to A converters. And this entire structure is what we mean when we’re referring to a PES.

Programmable electronic systems are going to employ programming or coding. And that is definition 3.2.55.

Programming coding is the process of designing, writing, and testing a set of instructions for solving a problem or processing data.

Note one to that entry is in the IEC 61511 series, programming is typically associated with a PE, programmable electronics.

All right, so we had a lot of definitions related to programming.

Proof Test Definition and Failure Mode Philosophy

Let’s completely flip the script with clause 3.256, which is the definition of proof test.

Proof test, function test, slightly different activities.

And we’ll get into that more when we get into the testing section, maintenance and testing section of the standard when we get there. And we’ll also talk about it a little bit when we’re talking about the design of testing facilities in clause 11.

So a proof test is a periodic test performed to detect dangerous hidden faults in an SIS so that if necessary, a repair can restore the system to an as new condition or as close as practical to this condition.

You’re going to hear me say something now that I’m going to repeat over and over and over and over. And it’s a very important mindset when you’re designing safety instrumented systems.

A proof test is not, the intention of a proof test is not to make sure something works.

A lot of people would define that as a function test. The objective of a proof test is to make sure that failures aren’t present. You might be talking to yourself saying, what the heck is the difference between making sure something works and making sure it’s not failed?

Trust me, hear me now and believe me later. We’re going to hit this point several more times over the duration of the podcast.

They are not the same thing. So making sure that something works kind of limits your thought process and limits the activities, whereas making sure that a failure mode isn’t present is a different thought process and a different activity, especially when you have fault-tolerant systems.

So a fault-tolerant system can work in the presence of a failure. And even though it works, we would want to identify that that failure is present. So that’s why we go with proof test.

That’s why when we’re talking about testing, we always say the purpose is to identify failures as opposed to make sure that something is working.

And once we get a little bit more into the definitions, when we’re talking about proof testing, we’re going to lay out a thought process that says when you’re writing a test plan, you need to think about, well, what are all the failure modes?

What are all of the ways that this device can fail from the component itself to the piping that connects the component to the process?

What are all of the things that can go wrong? And do I have steps in my testing procedure that would identify whether or not that failure mode exists?

So a lot more good stuff on proof tests coming up. It’s an area that is so critically important to the implementation of safety instrumented systems. So that was 3256.

I am going to pick things up at 3257 next time when we start talking about protection layers and a little bit more about risk analysis in next week’s podcast. So I will leave it off right there and see you 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 lifecycle 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 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. Thank you.