The latest episode (S1E39) of the Kenexis Functional Safety Podcast is now available on Spotify and Apple Podcasts

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E39 TRANSCRIPT (Markdown)
Cleaned & reflowed for web publication and AI crawlability.

The JSON-LD block below is schema.org structured data. If your CMS lets you
add raw HTML to a post, paste it into the page (or anywhere in the
body — crawlers read it either way). Fill in PLACEHOLDER_EPISODE_PAGE_URL
once the post exists. Everything from the "# Kenexis Functional Safety
Podcast…" heading down is the transcript body — paste it into your post.
–>

"`html

"`

# Kenexis Functional Safety Podcast — Season 1, Episode 39: IEC 61511, Clauses 11.5.4 through 11.5.6 (Programmable Devices by Prior Use)

—

## Introduction, Disclaimer, and Episode Overview

Programmable devices like PLCs don't actually need to be certified. You can install them based on prior use, but meeting the requirements is very difficult.

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.

All right.

## Clause 11.5 Recap and Programmable Device Types

So in today's podcast, we're continuing on in Clause 11.5. So Clause 11.5 is the requirements for selection of devices in general, requirements for selection of devices.

And kind of recapping a couple of weeks ago, we said that you can use a device in a SIS application if it is designed and manufactured in accordance with IEC 61508, which would make it certified. And I kind of explained how certified is a very loose term. It doesn't actually have to be certified. But do you trust the equipment vendor to have done everything if it's not certified? And then there's the other route, which is prior use experience.

Just making sure that, you know, based on how you've applied that piece of equipment in the field, it meets your needs and you understand the failure modes and so on. That's the prior use route.

So when you go down the prior use route, you need to do some justification that we talked about last week. That was Clause 11.5.3. And then beyond that, if you're going to use a programmable device based on prior use experience, there's a whole lot more things that you need to do, hoops that you need to jump through. And those additional hoops that you need to jump through are going to be a function of what type of programmable is it. So going all the way back into the definition section, you'll remember that there were three types of programmable devices. FPL, LVL, and FVL.

And those are going to be in clauses, the requirements for prior use are going to be in clauses 11.5.4 for FPL, fixed programmable language. 11.5.5 for LVL or limited variability language. And then Clause 11.5.6 for FVL or full variability language. So those are the clauses that you meet if you want to use an uncertified device, basically.

Now, the requirements are going to get more and more stringent. The higher the degree of flexibility, so full variability language is going to have more requirements than fixed program language. And the higher the SIL, the more the requirements there are going to be. So right now, let's just go ahead and start in 11.5.4 and go through the requirements there because that's going to be the lowest bar, the lowest rung.

## FPL Device Definition and Configuration Requirements

So 11.5.4 is requirements for selection of FPL programmable devices, e.g. field devices, based on prior use. Now, hmm, FPL programmable devices, field devices, why does it say FPL programmable devices or field devices?

I thought logic solvers were programmable devices. Well, FPL, let's get right to the meat of it, stands for fixed program language, which means that the device has a program running in it, but you didn't write the program. You can't see the program. You can't edit the program. The program is fixed, unchangeable, immutable. The program is fixed. Now, what can you do with a fixed program language device? Well, you can change the parameters that are running in the program. So the archetype example I would give you here is a smart pressure transmitter.

So if you have a smart pressure transmitter, it is running a program, but that program is firmly ensconced in the firmware, and you, the end user, can't look at it, can't change it, can't do anything about it. But what can you do with the program? Well, you could change the parameters. And a lot of these devices, you know, you look at something like a Rosemount 3051, it's going to have hundreds of different parameters that you can modify. So you're not changing how the program executes, but you're changing the data that is going to run different branches.

So some of the things that you can change are outputs. So what is the output that's generated when the device determines that it's in a failed state? You can modify that. That's one of the settings you can change. Some of the easier things to grasp would be what is the zero? What is the span? That kind of going back to the old analog days. So those are the settings that you can change. But the device program is fixed. It's done by the equipment vendor. It's immutable by you. Okay, so that's what a fixed program device is.

And those fixed program devices are generally going to be field devices. Now, it's not out of the realm of possibility that you will have a fixed program device doing something to the effect of a smart relay that might be running in the logic solver subsystem. But most of your FPL devices are actually going to be field devices. Okay, so let's delve into the requirements.

Let's start with 11.5.4.1, 11.541, which states for SIL 1, SIL 2, and SIL 3, the requirements of 11.5.2 and 11.5.3 apply together with the following sub clauses. So basically, 11.5.2 and 11.5.3 were the general information about how to justify something based on prior use. So that's going to apply. It's not obviated because we moved to a new standard. That still applies.

That's good.

And then there are some additional requirements, which are going to be 2, 3, and 4 are the requirements that you're going to need to meet for a fixed program device. So let's start with 11.542. States, all configuration options of the device possibly influencing safety shall be identified and considered. So that's the first sentence of three in this clause. So when you look at all of the variables that you can change, you need to determine what the appropriate settings for all of those configuration options are.

Well, not necessarily all of them, but the ones that can influence safety, you need to determine what they are and specify what the appropriate value is. And you should probably document that in your safety requirement specifications. Okay.

Next clause up says, it is important to check that wherever specific settings are not defined, that the default settings of the device are confirmed to be appropriate. So this goes back to a lot of my functional safety assessment and my functional safety auditing days, where when I ask the team about how a device is configured, they come back and say, well, do you know what the default is? Which immediately tells me that they didn't make any changes. They installed the device out of the box with the hopes that whatever the default is, is appropriate for your application.

Well, it's not okay to just install something and hope that the default settings are appropriate. You need to know what all the settings are and you need to determine which setting is appropriate for you. And in a lot of cases, that is going to be the default. There's nothing wrong with the default in a lot of cases, but don't go into it blind, sight unseen. You need to think about all those parameters and what they should be. And if it is that way by default, hooray, less work for you in the setup. But you need to think it through before you go into the process. Okay.

Last sentence in the clause is, So again, a justification and analysis needs to be done of all of those parameters. And these equipment vendors keep getting requests for more features, which means there are more parameters, which means more work for you, actually, in justifying that those settings are not going to impact safety and you can leave them at whatever the default is. So more settings gives you more flexibility, which is a bonus, but it's also a curse because now you need to understand what all those settings are for and make sure that you have the appropriate choices selected.

And hopefully, they're defaults. All right. Next clause up is 11.543.

## Clause 11.5.4.3 Suitability Evidence Requirements

This clause states that for a specific configuration and operating environment of the device, the evidence of suitability shall consider. So there's going to be four bullet points here that we're going to talk about on this clause. And this kind of points you back to clause 11.543, where you were justifying using something in a prior use experience format in the first place. So you need to make sure that it's suitable. So what are the things that you need to consider to determine whether or not the device is suitable?

Well, number one, first bullet point, is characteristics of input and output signal. Well, that seems pretty brain dead. That seems pretty obvious. You know, if my device is designed to receive a 0 to 50 milliamp signal, but my PLC sends out a 4 to 20 milliamp signal, that's not going to work very well. And I can't really send a 4 to 20 milliamp signal into a dry contact on a switch. That's not going to work. So what are the inputs? What are the outputs to the device?

And just make sure that they're powered appropriately and they mesh up with the other equipment, the other parts or subsystems of the safety instrumented function. Pretty obvious.

Second bullet point, you need to consider the modes of use. So what are all the different ways that the device is going to be used? Maybe you have a batch process where there are different batch steps, where the device is in different kinds of applications. You might want to consider startup. You might want to consider shutdown. These are all things that you need to consider. Now, for most continuous plants in the process industries, there's, well, normal operation, and then there's startup and shutdown, which is kind of a blasé subset of normal operation.

But all the modes of use, they may be few, but they need to be considered.

The third bullet point is that you need to consider the functions and the configurations that are used. So this is a little bit tricky in that if you have prior use experience in a BPCS application, but your SIS application needs you to use different settings that you haven't used before in the basic process control system application, that might give you a little bit of pause to do a little bit of analysis in terms of what configurations you're using, what settings you're using, and what functionality that you're using.

Optimally, we want to have prior use experience with the functions and configurations that we intend to use in the safety application. So we're probably going to want to make sure that that's true.

Okay, next bullet point, final bullet point number four for 11.543 is, we want to have prior use in similar operating environments. Now that's true in 11.543, the clause 11.543. I don't know why we repeated this bullet point. It is clearly stated in 11.543. Nothing new here. When you're claiming prior use, it's got to be in a similar operating environment to what you're planning on doing for your safety instrumented function.

## Clause 11.5.4.4 Additional Requirements for SIL 3

Okay, and that brings us to the last clause in 11.544, which gives some additional considerations, three additional bullet points that you need to think about for SIL 3 applications. So the main text of clause 11.544 states, In addition, for SIL 3 applications, an assessment of the FPL device shall be carried out.

To show that, and then there are three bullet points that you need to make sure that you considered, you documented doing your analysis of the device. Bullet point number one, and bullet point number one is the long one. It's going to say, the FPL device is both able to perform the required functions and that prior use has shown that there is a low enough probability that it will fail in a way which could lead to a hazardous event when used as part of the SIS due to either random hardware failures or systematic faults in hardware and software. Boy, that is a lot of words.

Um, these words are not substantially different from what we talked about last time in clause 11.533.

We want to make sure that the device performs suitably in the application that we're going to be put it in, putting it in, and that it has a low enough probability of failure when used as part of the SIS that it will be suitable. So none of that is actually new. All of that we talked about last time in clause 11.533. Why do they keep repeating themselves?

Well, there is a little bit of an addition here with the last clause of this sentence on this bullet point, which says that we need to think about this for random hardware failures, which is what we, what we always do, what we're always thinking about. But the addition here is that you also need to think about systematic faults in hardware or the software. And that's the kicker here. This is a programmable device.

It has software. And if that software glitches, it's going to glitch in every device that you buy. So systematic failures in the software that's running in an FPL device is a big, big problem. So if there's any hint of any type of systematic failure, it's probably going to get you to exclude this type of device from use in a safety instrumented system.

And that's one of those things that we really focus on when we're doing that systematic capability in a certification process, making sure that the software doesn't have a, what will end up being a common cause failure that is going to weaken or make ineffective every portion of a redundant configuration.

So focus on those systematic faults when you're looking at the historical data that you have for the application of that device. Second bullet point here says that we need the assessment to show that appropriate standards for hardware and software have been applied. So what guarantee do we have that the equipment vendor is doing a good job at the design? There are a variety of standards for the hardware and the software that go beyond functional safety that they should probably be applying. So think that through.

Look at the hardware and software standards that have been applied to similar types of equipment and make sure that the vendor is doing their due diligence in setting what the requirements for their devices are and making sure that those requirements have been achieved.

The last bullet point here on 11.544 states that the FPL device has been used or tested in configurations representative of the intended operational profiles. Well, good golly. This is the same thing that we just talked about a couple minutes ago in clause 11.543. It's exactly the same thing that we talked about last time in 11.543. So, man, they are really beating this operational profiles and operational environments to death, are they not? Just because something worked for you in a clean purchased natural gas does not mean it's going to work in dirty refinery gas.

So make sure that you have experience in the same operating profile.

Okay. So those are the requirements, additional requirements for prior use justification for FPL programmable devices. They're actually pretty benign and kind of restate a lot of what we already talked about in 11.543. So not a whole lot of meat on the bones in 11.544, but a lot of words. So make sure that when you're doing that prior use justification that you've thought all this stuff through.

## LVL Devices and Commercial Off-the-Shelf PLCs

Now, we're going to move on to clause 11.545, which is where things start to get nuts. Because now in 11.545 and 11.546, we're going to be talking about programmable devices that you, the end user, program. So these devices, you, the end user, can screw up the programming and insert failures into your safety instrumented functions. So we need to do a lot of thinking.

Also, these LVL programmable devices are generally cobbled together with a lot of different components, input cards, output cards, com cards, CPUs, power supplies. They all need to be integrated together. And you, the end user, are going to have to do a lot of work to make sure that they are installed properly. The use of…

So not trying to put too fine a point on it here. When we talk about an LVL programmable device, we're generally talking about a commercial off-the-shelf PLC. So that might mean something you bought for $100 from AutomationDirect. Or it could mean something like an Allen Bradley PLC5 or a Modicon 984. Now, granted, those series of logic solvers are definitely well-dated.

But a lot of them are still out in use in process plants. So these are PLCs that were never intended by the manufacturer to be a safety instrumented system. It's just that they are capable of doing the stuff that a safety system does. So people have used them as safety systems. And in a lot of cases, these things were installed prior to the functional safety standards either being written or being popularized or being adopted at your plant. So there's a lot of legacy safety PLCs that you're going to want to justify.

Now, going forward, if you have a new SIS application, I would be very hard-pressed to recommend anything that is not certified. Because the amount of work that you're going to have to do to configure the device, to do safety configuration, to make it suitable for a safety application, far and away exceeds the level of effort there and the cost of doing that is far and away going to exceed the cost of just buying a safety certified device out of the box, right out of the gate.

So most of the time, what we're doing here has nothing to do with new plants where any sane and rational person would be using the certified logic solver. We're generally talking about retrofitting older stuff. So I see a lot of older ControlLogix. Now, ControlLogix is kind of on the fence because it started out as a commercial off-the-shelf PLC. You can buy it in its commercial off-the-shelf form, but you can also buy a safety certified form up to SIL 2. So anyway, let's get into the details.

And remember, what I'm talking about here, commercial off-the-shelf PLC, the vendor made no effort to try to safety certify it. So all of the safety stuff that a certified vendor of a safety PLC would build into the system out of the box, you, the end user, need to think about it, engineer it, program, and install it after the fact. So what is that stuff that you need to do, Ed? Why are you making this sound like it's so difficult? Well, let's get into it.

## Clause 11.5.5 LVL Prior Use Requirements and SIL Limits

All right. Clause 1155 is requirements for selection of LVL, programmable devices based on prior use. And again, LVL, meaning limited variability language. So things like function block diagrams, sequential function charts, structured text, and the big boy of the olden days ladder logic diagram. So the equipment vendor gives you kind of a limited set of what you can do to program this device. You don't have full access. It's not like C sharp where you can allocate memory, deallocate memory, and all that other good stuff.

So there are a lot less ways to get yourself in trouble with ladder logics as opposed to Pascal or JavaScript or something else crazy like that.

So clause 11551 says, the following requirements apply to PE devices which implement SIL 1 or SIL 2 SIFs.

So right out of the gate, we're going to get smacked. If you're thinking you can use a commercial off-the-shelf PLC in a SIL 3 application, think again. You cannot. It is unacceptable. This is only for SIL 1 and SIL 2. And when I get down into the requirements for SIL 2, you're going to see it's only realistically possible for SIL 1 because SIL 2 is going to ask you to do a lot of stuff that you might not actually have the horsepower to be able to do inside your company. So we'll get to what's required for SIL 2 in just a second. But SIL 3 right out of the gate, non-starter, can't do it.

This is only for SIL 1 and SIL 2. If you're in SIL 3, you must get a safety PLC that was designed and manufactured by the equipment vendor in accordance with the SIL 3 requirements of IEC 61508. Period. End of discussion. And also taking a SIL 1 and SIL 1 and SIL 1 and trying to combine them to get to a SIL 3, also not allowable. All right. So that's Clause 11.5.1 limits you to SIL 1 and SIL 2.

Clause 11.552 says the requirements of Clause 11.5.4 apply. So everything you needed to do for fixed programmable devices that I just talked to you about, you also need to do for LVL programmable devices. So if you forgot what that was already, you can just rewind the podcast and go back and listen to those things again.

Next Clause 11.553 states, So again, with these programmable devices, we're really super concerned about systematic failures in the design process. We want to make sure that the programming in the firmware that was done by the manufacturer doesn't have some sort of systematic failure that's going to cause dangerous failures to occur. And here we're really concerned more about what the equipment vendor did with respect to systematic faults.

The application software that the end user is creating has its own set of requirements that we're going to get into when we get to Clause 12, which is still a few weeks away because Clause 11, we still have a long way to go.

Okay.

So the operating environment, what do we mean by the operating environment? This is a PLC. So the actual end process, whether it's a hydrocracker or a electrolysis to create hydrogen or a pharmaceutical manufacturer, that really is not what we're talking about here.

In terms of the operating environment, we're talking about where is the PLC installed? How is it maintained? Who maintains it? So if you have a PLC that's sitting in a control room, air conditioned, lovely environment, and now for your safety application, you want to put it in a NEMA 4 box out in the field, that's kind of a different operating environment. And you might want to think through, do an analysis, do testing. I would recommend testing to make sure that that PLC is going to survive in the field in a NEMA 4 Xbox as opposed to sitting in the control room.

All right.

So that's Clause 11, 5, 5, 4. 11, I'm sorry, 11, 5, 5, 3. 11, 5, 5, 4. The next Clause says, So as you're making that determination of how much operating experience you need to justify the use of the device, the higher the SIL, the more experience you're going to need because you're probably going to need to justify a lower PFD, which requires a lower failure rate, which requires more experience to justify that lower failure rate. So SIL is an attribute and also the complexity of what you're doing.

The more complex the device, the more detailed the programming needs you have. You're going to want to make sure that your device is capable of that. So if your PLC that you're basing your experience on is just like taking an input and converting it to an output, but you need your safety PLC to do an online mass balance, well, the online mass balance is a lot more complicated and requires a lot more math than you have experience with. So make sure that that PLC is capable of doing all these things. And how would you do that? Analysis and testing.

Put the PLC on a test stand. Run those detailed calculations based on a simulator and make sure that it can do the calculations in the required amount of time. Okay, now the next clause is where the rubber meets the road.

## Clause 11.5.5.5 Safety Configuration Techniques for COTS PLCs

It is the detailed stuff that you're going to need to do. And clause 11555 has four bullet points. And each one of these four bullet points requires a lot of detailed engineering and analysis to accomplish them. And I will get into all that detail and all that analysis.

So let's hit the most important clause in 1155, which is 11555, which says, For SIL 1 or SIL 2 applications, a safety configured PE logic solver may be used provided that the additional requirements are met. Okay, provided that all the following additional provisions are met. And there are four bullet points. I'm going to explain to you what they are.

And then I'm going to tell you what you need to do to meet those requirements because this is not a quick, easy throwaway of going check.

*[inaudible]*

That's fine. There's documentation. There's engineering. There's analysis. There's hardware. There's equipment that needs to be installed and tested to make all these things happen. So let's hit them.

And again, this is going to be required even for SIL 1 applications. When we get to clause 11556, which is coming up next, that's the stuff beyond this that you need for SIL 2. So everything that I'm telling you right now, you need to do even for a SIL 1 application. So number one is understanding the unsafe failure modes of this LVL programmable device. And that includes everything in the LVL device.

So what you're going to need to do is you're going to need to put together a kind of like a poor man's FMEA where you list out all the components of your LVL device, which is going to include all the way back to power supplies. So power supplies, CPUs, com cards, input cards, output cards of all the different variations. So for all of that hardware, you need to list off what are the failure modes. And then the next bullet point is going to address those failure modes. So for bullet point one, I need a spreadsheet that's going to go and tell me for every component what can go wrong.

So for instance, power supply, very, very simple. The failure mode you're worried about is that it fails to operate. Open circuit, basically. So if my power supply fails to operate, what is the effect? What's going to happen? Well, then my PLC is going to stop running. And generally, that will mean that you're going to de-energize all your outputs to the field, which is a safe state, which is okay. Now you need to repeat this thought process for every component of your PLC and everything that can go wrong.

So let's move to the CPU. What is the most common failure mode of the CPU? Well, in the Windows world, we call it the blue screen of death. The program hangs up. It just stops executing. So if the program just stops executing, that means that the outputs are going to stay where they're at forever. That's a dangerous failure. So now when the input goes to the unsafe state, well, the output is kind of stuck where it's at because the CPU is stuck where it's at. That's a problem. That's a dangerous failure. I need to do something about that. I can't just go, well, you know, stuff happens.

It's okay. It's probably not going to happen that frequently.

*[inaudible]*

All right.

So after bullet point one, understanding of all the unsafe failure modes, bullet point number two is the use of techniques for safety configuration that address the identified failure modes. Now, what is safety configuration? Safety configuration is adding program code, adding physical equipment that will detect dangerous failures and move you to a safe state upon detection of those dangerous failures.

So you're taking that commercial off the shelf device and you're adding equipment and you're adding program to be able to detect and address those unsafe failure modes that you just listed out in the previous step with your poor man's FMEA of what can go wrong. So now what are some of the techniques for safety configuration? Well, let me give you the big three that you will always have to do for pretty much any PLC, any commercial off the shelf PLC out there.

The first one is the failure mode of your CPU where it hangs up. So what is my safety configuration technique? The use of a watchdog timer. So what you're going to do is you're going to write some program code that every time the program executes, you're going to pulse one of the outputs. That pulsed output needs to be wired to a time delay relay. And when the pulse is received by the time delay relay, it will reset the timer. So every PLC scan, you're resetting the timer and we're just going to happily truck along until the logic solver stops.

When the logic solver stops, you will not pulse the output. The time delay relay will time out. And when it times out, you're going to open some contacts. And basically, you're going to want kind of a safety relay functionality where when that timer times out, you're going to want to open the contacts that's going to disconnect the power to all of the field devices moving everything to the safe state.

That's your watchdog timer. And that is the safety configuration for the failure mode that the CPU locks up and stops programming.

Two more items on safety configuration that you're always going to run into. Number one is my input is stuck. Well, how do you know if your input is stuck or if your input is failed? Well, redundancy. So basically, every input to your safety PLC, you're going to need to wire it into two separate channels. Channel A and channel B. So it's easiest to think about this with a discrete 24-volt on-off input. So you just basically wire that switch to two different channels.

And then you need to write application code that will always compare channel A and channel B and make sure that they're the same. If the system ever determines that channel A and channel B are not the same, you have a detected failure. And you need to write code that when that detected failure occurs, you need to de-energize the associated outputs to bring that safety function. Or you could just de-energize the entire safety PLC, all the field outputs, when that occurs.

The last one, you're probably already speculating, is going to be a stuck output. So I'm sending my PLC output to a device in the field. I might get into the situation where I command the device to de-energize, but it doesn't de-energize. Well, I need to be able to detect this and do something about it.

So how do you do this? Well, I'm going to take my output that's going to the field and I'm going to send it to the field, but I'm either going to wire that output directly back to an input card or I'm going to have another output. No, you can't have another output. We need to wire the output back to the input to make sure that it actually de-energized. Then we're going to need to write application code that says, is the device commanded to be de-energized? If so, is my feedback telling me that it actually is de-energized?

And if I get a mismatch saying I commanded it to be de-energized, but it is not de-energized, that's where I'm going to want to de-energize through some sort of master trip, de-energize all of my power going out to the field and shut my plant down because my safety function did not activate and I need to get the plant to a safe state.

So those are the safety configurations that you, the end user, are going to need to do. Now, all the stuff that I just described for you, if you are using a good safety PLC, specifically a SIL 3 certified safety PLC, your equipment vendor has already done all of that for you. You don't need to think about it. It's done on the circuit board level. It's done in the firmware level. It's prego. It's in there. You don't need to think about it. But if you're going to use something from AutomationDirect, you're going to need to do all this work yourself.

And kind of going back to the beginning of this section, the amount of additional hardware and additional work to do the safety configuration is probably going to greatly exceed the cost of just buying that SIL 3 certified safety PLC in the first place. Okay, but that was only the first two of the four bullets here. The third bullet is that the embedded software has a good history of use for safety applications. Okay, embedded software has a good history of use.

This is going back to clause 1153, making sure that, you know, we're familiar with the device. We know how it works, how it fails, and that there's a good history. The fourth and final bullet item is probably the easiest to achieve, which is protection against unauthorized or unintended modifications, which you're going to need to do even if you have a safety PLC.

That requirement is still going to apply. So make sure that your safety PLC program cannot be tampered with, and you're going to use all the standard controls. You're going to have your maintenance and engineering interface in a room that is secured. It's only accessible through hardware. I'm sorry, a computer that you have to log into. The maintenance and engineering software interface software you need to log into. So lots of layers of protection to keep people away from the program that shouldn't be messing with the program.

Now, finally, there is one note here for clause 11555. The clause states, A safety-configured PE logic solver is a general-purpose, industrial-grade PE logic solver, which is specifically configured by the OEM, a systems engineer, or the end user to be used in safety applications. And I just explained to you all of the work that is actually required, all the additional hardware, all the additional programming that's required to implement that safety configuration.

## SIL 2 Formal Assessment Requirement and Offshore Context

Okay, so everything that I just explained to you is required for a SIL 2 LVL logic solver. It's also required for SIL 1 LVL logic solver. But if you want to get to SIL 2, oh, there's an entire raft of stuff that you need to do beyond what I just talked about to justify use in the SIL 2 application. And when I go through the list of all these additional things that you're going to need to think about to get into SIL 2, you're probably not going to do it.

Now, I have only gone through this formal assessment to get to SIL 2 for one company. Now, actually, I did it for two companies. But one company had a large inventory of assets offshore in the Gulf of Mexico that were based on commercial off-the-shelf PLCs. And if you know anything about the offshore oil and gas industry, take your project cost and multiply it by between 10 and 100 if you want to make hardware changes because of just, you know, where you're at, the difficulty, simultaneous operations. It's just a nightmare to install anything offshore.

So going through this assessment to assure what they already had is suitable for safe to cost them, I assure you, a boatload of money. But it was a whole lot less than trying to change the logic solver for the safety instrumented systems on an offshore platform. And, you know, it would need to be due. It would need to be a hot cutover while the plant's, you know, online and running. Just a freaking nightmare.

Okay, so this assessment for SIL 2 based on prior use, what does it involve? All the requirements are in Clause 11556. They are, a formal assessment of any PE logic solver used in a SIL 2 application shall be carried out to show that. Okay, so that's the clause that, the statement that starts the clause.

The key phrase here is formal assessment. Formal assessment tells me it's documented and it's reviewed and it's approved. That is the formality that we're looking at. So we're going to create a document of an assessment to show two things. Now, the second thing is split into about a dozen sub parts. So it's more than two really.

First, so the bullet points. So bullet point number one says that you need to show that your PE logic solver is both able to perform the required functions and that prior use has shown that there is a low enough probability that it will fail in a way which can lead to a hazardous event when used as part of the SIS due to random hardware failures or systematic faults.

Okay, that's very similar to what we just did for 11555. What's different here? Well, nothing. You need to do the same thing that we just said to do for 11554 and 11555. Hmm. Rather confusing. I guess there's just really a focus on the systematic faults because you do have a programmable device here. But yeah, you need to make sure that the probability of failure is sufficiently low by looking at the historical record of failures with a keen eye on any of those failures that might have been systematic which would kind of scratch you from using this type of device in the first place.

All right. Bullet point number two.

## Eleven Sub-requirements for SIL 2 LVL Formal Assessment

So bullet point number two states that you need a formal assessment on the PE logic solver to show that measures are implemented to detect faults during program execution and initiate appropriate responses. These measures shall include the following. And then bullet point two is going to have one, two, three, four, five, six, seven, eight, nine, ten, eleven. So not quite a dozen. Eleven sub-bullets that need to be executed. Now, didn't we just talk about detecting the faults during program execution and initiating a response in clause 11.555? What's different here?

Well, what's different here is the level of detail that you're looking at. Those things that I told you you need to do for SIL 1 might seem unacceptable and onerous to you, but it's nothing compared to what you need to do for SIL 2. So let's hit the eleven sub-bullet points that you need to do in a formal assessment of to get to SIL 2.

Number one, program sequence monitoring. So you're going to need to make sure not just that the program is running, but the program is running in the correct order. That all of the statements are being executed sequentially in the way that you expect. So you need diagnostics to make sure that all of the rungs are firing in the right order if you're using ladder logic.

If you're using function block diagrams, you need to think about what order all of the blocks and the sub-blocks are executing in and you need to write diagnostics to basically make sure that if something executes out of sequence, it's going to throw up an error flag that's going to allow you to shut down the plant. So there's going to be some code that you can write with a counter and specified counts for steps where you walk through the code, update your counter, and make sure that your counter, it always matches up with the step that you're executing. So, program sequence monitoring.

Bullet point number two, sub-bullet point number two, protection of code against modifications or failure detection by online monitoring. So, you're going to need in your code to make sure that your code isn't changing. So, something in your PLC is going to need to look at something like a CRC check or a file size check to make sure that the code isn't changing between when you installed it and when it is executing. So, some of your safety PLCs will be able to do CRC checks with the built-in code.

You're going to need to make sure that you exercise those routines and check the results of those routines. If those routines fail and something changed about your code, you need to shut down your plant. next item, failure assertion or diverse programming. So, what you're going to need to do in a formal documented approach is you're going

*[inaudible]*

inject failures into your code and make sure that your diagnostics in your code detect that those failures are present and go to the right state.

So, that's failure assertion testing or you can use diverse programming if you have redundancy. So, I've mentioned before back in my days at UOP we had a system which was kind of a one out of two vote with a PLC5 as one channel and a Modicon 984 as another channel and we had different people program the Allen Bradley versus the Modicon. So, that's what we mean by diverse programming.

You have hardware fault tolerance and you're having one person write one set of code with one system and a different person write a different set of code with the other system either which either one of those two systems can independently shut down your plant. That's diverse programming. That's another option if you don't want to or can't do failure assertion testing.

The next thing you're going to need to do is range checking of variables and plausibility checks. So, plausibility checks are going to be associated with variables that can be one of a list or on, off at different points of time. So, basically every variable that you have every variable that you're bringing in from your I.O. cards or you're communicating into your system. You will need to check it.

You'll need to write code to check it to make sure that it's in the proper constraints and if it's not you need to write the code to basically shut down your plant because you failed a plausibility or a range check. Next item you'll need to next item is modular approach. So, you need to write your software so that it's modular. You're going to build things in subroutines.

You're going to thoroughly test the subroutines and you're going to reuse those subroutines and then also for different areas of the plant maybe different groups of safety functions maybe different safety functions you're going to want to create a separate module for each of those so that you minimize common cause failures make testing and editing a lot easier because everything is more compartmentalized. The next bullet point you need to follow appropriate coding standards for the embedded in utility

*[inaudible]*

software. well wait a minute you didn't write the embedded or the utility software down did ya? So you're going to need to go through a long communication process with your equipment vendor to have them explain to you and justify what coding standards they used for their embedded software and their utility software. If you can't get confirmation of this from the equipment vendor well you can't use their hardware in a safety application.

So some vendors you're going to be able to get that information others you're not and if you can't well you shouldn't be using their hardware in a safety application.

Okay next item up next sub bullet point is testing in typical configurations with test cases representative of intended operational profiles. So during your factory acceptance testing of the code that you're writing you're going to need to document all of the typical configurations configurations and do the testing in those configurations and then operational profiles again relates to where am I installing that equipment and test that equipment as installed in whatever the operating environment is. So we kind of already had to do that in the last clause we're repeating it here.

Next sub bullet point is trusted verified software modules and components have been used. So if you have a software subroutine for something like a 2 out of 3 vote that should be a trusted well tested component that you're going to be reusing over and over because you know that it's going to work properly.

The next bullet point is kind of a scary one and it's a really difficult one. It says that the system needs to undergo dynamic analysis and testing dynamic analysis and testing.

So normally when you're doing your FAT or your SAT all of your inputs and outputs are kind of frozen in one state and you're going to manipulate one variable at a time to make sure that the output is working. Well that's not enough here.

So here you're literally going to need to build a test stand that has so like another PLC whose output is setting the inputs to your target and then the outputs of your target need to be wired to inputs of this testing PLC.

we did this at UOP when I was there with a LabVIEW system where we were so the big safety application that we did back at UOP was lock hopper control system and we wrote a program in LabVIEW that would dynamically manipulate all of the inputs and then it would receive feedback from all the outputs to make sure that they're moving to their expected states within the process safety time.

So it's not enough to make sure that everything works you have to make sure everything works while you're dynamically moving everything around. The only way to do that is to basically create a test PLC system which is going to dynamically and quickly manipulate the inputs and make sure that the outputs that are coming back are matching what's expected. That is a boatload of work. Boatload of work. I mean hundreds of man hours to build this type of system.

Okay, next sub-bullet point says the system does not use artificial intelligence or dynamic reconfiguration. Why would your safety PLC be using artificial intelligence or dynamic reconfiguration? Don't dynamically reconfigure your system.

Now, artificial intelligence is something that the IEC committees are going to be delving into more and more in the future. It is something that's going to be more important and it is used for safety. So, if you look at a self-driving car, they are using artificial intelligence to tell them that a small child is behind the vehicle and they shouldn't back up. That's all AI. That's all pattern recognition. So, it is getting used more and more in safety applications. But, in the process industries, we're not there yet. We don't need to be there right now.

We don't need to be there in the short term because our safety functions are a lot more well-defined in terms of how to diagnose that I have a dangerous condition. So, right now, AI is off the table. But, this is going to get another look through in the next decade or so where we'll probably not tell you that you can't do it but set requirements for what you need to do if you do use artificial intelligence. But, that is not today.

Alright, the last sub-bullet point states that you need to do your analysis and confirm that you have documented fault insertion testing that's been performed. So, you need to document the insertion of failures into your software and into your hardware and that when you do those fault insertion tests they are detected and the proper response happens.

So, what does this look like? So, I'm going to need to take a similar PLC to the one that I am trying to implement in the field and I will need to do things like use jumper wires to simulate short circuits and make sure that the system responds as expected.

So, this last bullet point is absolutely insane. You need to be an electronics engineer that understands failure modes and effects of all of your PLC equipment at the circuit board level to be able to implement this task. 99% of control system engineers are not going to be capable of doing this last sub bullet point. So, okay, so, so basically all of the things that I just discussed and that's the last sub bullet point for clause 11-5 5-6 is generally going to take SIL-2 off the table for safety configured commercial off the shelf.

It's just way too much detail, way too much work and requires you to have specialized knowledge at the circuit board level of the equipment vendor's PLC. And if the equipment vendor knew all of this stuff, they would probably just get their device certified for use in safety applications. Take all that with a grain of salt. Think real hard, but I'm going to say that unless you have a very specific situation, SIL-2 is off the table for safety configured commercial off the shelf. SIL-1 is hard to get to. SIL-2, borderline impossible.

## Clause 11.5.6 FVL Devices Must Be Certified

So, that was FPL and FVL. And we've been at this podcast for just a smidge over an hour, yet I am still going to get into what you need to do for FVL programmable devices. How could I possibly do that? Well, Clause 1156 only has one sentence in it.

So,

Clause

1156 says, what are the requirements for selection of FVL programmable devices based on prior use experience? There's only one sentence which says, when the applications are programmed using FVL, the PE device shall be in accordance with IEC 61508 Part 2 and Part 3 2010. Period. End of discussion. It basically says, if you have FVL, you cannot justify it based on prior use experience. It has to be designed and manufactured in accordance with IEC 61508 which means you need a certified device.

## Clause 11.5 Summary and Next Episode Preview

Alright, so with that, that takes us to the end of Clause 11.5. Now we know all of the rules for what equipment am I allowed to use in a safety application? What am I not allowed to use in a safety application? And how do I do my safety configurations for those programmable devices to be able to use something commercial off the shelf in a safety application? Albeit that you're realistically limited to SIL 1 for that application.

Next week, and I'm going to try to make sure that this happens next week. I've been doing a lot of traveling lately, so there's been a little bit of a gap in the podcasts. But next week, we're going to cover clause 11.64 field devices. Trucking on, continuing on in clause 11, so I will talk to you next week.

## 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.