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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E38 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 38: IEC 61511, Clause 11.5.1 through 11.5.3 (Device Selection, Certification, and Prior Use)

—

## Introduction and Episode Overview

The devices you use in your safety instrumented system do not have to be certified. Period. End of discussion.

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.

Well, obviously, the discussion isn't over. The podcast has just started, so the discussion has just gotten started.

## Clause 11.5 Overview and Fixed Program Language

But as I kind of preluded to, what we're going to be talking about today is certification, prior use. Proven in use is a term that comes from the 1508 standard. And just basically, what are you allowed to use in a safety instrumented system in terms of devices and what are you not allowed to use?

So, Clause 11.5 is what covers this. And Clause 11.5 is titled, Requirements for Selection of Devices. So, basically, these are the requirements for when you select what devices your safety instrumented system is going to be comprised of.

Now, we're going to break the discussion into two podcasts. Today, I'm going to be talking about prior use. And basically, making a long story short, I'm going to talk about field devices, where I see not a complete lack of value in certification, but definitely it is minimal at best. And then, in the next podcast, I'm going to talk about logic solvers, and specifically the topic of safety configuration of general purpose PLCs to be used as logic solvers in safety critical applications. But that's next week. This week, we're going to talk about prior use.

And that's going to be Clause 11.5.3 when we get there, which is Requirements for Selection of Devices Based on Prior Use. Then, when we get to 11.5.4, then we're going to start talking about Programmable Devices.

Technically, 11.5.4 fits into today's discussion. Maybe we'll get to it. Maybe we won't, because 5.4 is FPL Programmable Devices. So, that's Fixed Program Language. What is a Fixed Program Language? It's one of the three types of languages that the IEC 61508 and 65011 standard recognize, where with FPL, or Fixed Program Language, that means your device is programmable. There's a program running on a microchip on your device. But it's fixed. But it's fixed. The manufacturer created it. And you, the end user, have no ability to change it. But you can change parameters associated with it.

So, take your typical smart pressure transmitter. It is running a program. Believe me. It is running a program. There are a series of microchips that are running programs. But you, the end user, have no ability to change the program. But you have the ability to change parameters run in the program, like the zero and the span are things that you can modify. You know, back in the old days, we used to use these little micro screwdrivers to twist these little tiny screws and potentiometers to make those settings. But now everything is digital, and I am unnecessarily dating myself.

## Clause 11.5.1 Device Selection Objectives

Let's go ahead and start up at the top with requirements for selection of devices. And we're going to begin with Clause 11.5.1, which is the objectives.

So, the objectives, again, anytime you see objectives, they are non-normative. They're informative. They are aspirational. This is what we hope to achieve. The requirements, the things you actually have to comply with, start in the point two or the general requirements section.

But anyway, in Clause 11.5, it says that the objectives related to requirements of selection of devices, there are three. The first requirement is to specify the requirements for the selection of devices, which are to be used as part of the SIS. So, bullet point number one basically says we're going to tell you what you're allowed to use in a safety instrumented system. And, well, you know, a little foreshadowing here. Not everything. There are things, believe it or not, you're not allowed to use in your safety instrumented system. So, I mean, there's two camps out there.

There's one camp that believes I can use absolutely anything in a safety instrumented system, which is not true. There's the other camp that says I need to have a third-party certified, SIL-certified device. Both of those camps are wrong. The truth, as usual, lies somewhere in the middle.

Second bullet point under objectives is specify the requirements to enable a device to be integrated in the architecture of an SIS. So, on bullet point number two, this is where we're going to start talking about safety configuration. Safety configuration is the process of you, the end user, engineering extra stuff on top of what was supplied to you by the equipment vendor to make something suitable for safety applications. So, general purpose off-the-shelf PLC is going to be usable in a safety application.

Theoretically, we talked last week about that 60% safe failure fraction limitation that is going to be hard to confirm if the vendor doesn't help you. So, there are extra things that you will need to do outside of what was supplied to you out of the box. So, that's kind of the bullet point number two. That's going to be next week when we start talking about safety configuration and programmable devices.

Bullet point number three says that we're going to specify acceptance criteria for devices in terms of the associated SIF and safety integrity requirements. So, what you're allowed to use is a function of the SIF that you're applying it in and what the safety integrity requirements are. So, a little foreshadowing in the next week.

While you are allowed to use a safety configured logic solver, not basic process control system, a safety configured PLC as your SIS logic solver, you can't do it for SIL 3. You can't do it SIL, definitely can't do it for SIL 4. You cannot straight up do it for SIL 3. SIL 2. You can, but there are so many requirements that you probably don't want to unless you have a large inventory sunk cost type of thing that you're dealing with.

Okay.

So, those are the objectives. Again, aspirational statements. Nothing there that you need to actually meet. If we were doing an audit, we wouldn't be auditing against these requirements because they're not requirements. They're just aspirational statements of what we're trying to achieve.

## Clause 11.5.2 Certification and Prior Use Paths

Now, let's get into the requirements. The things that you actually have to comply with. So, Clause 11.5.2 is general requirements.

It just says general requirements, but it's general requirements for selection of devices. Clause 11.521 states, devices selected for use as part of a SIS with a specified SIL shall be in accordance with IEC 61508 Part 2 and IEC 61508 Part 3 and or 11.5.3 through 11.5.6 of this standard as appropriate.

So, that clause, which has a note, which I will get to in a second, gives you two options. The device can be compliant with 1508 or you will comply with clauses 11.5.3 through 11.5.6, which we haven't gotten to yet, which are also colloquially known as the prior use clauses. So, looking at the big picture, the kind of improper, slightly improper terminology is that if you're going to use a device in a safety application, it either needs to be certified or you need to have prior use experience with it.

Now, I use the term certified colloquially because it never, ever, ever, ever, ever has to be certified. Third-party certification is never, never, underlined, bold, never a requirement. What did the standard specifically say? That the device needs to be in accordance with 61508 Part 2 and 61508 Part 3. For those of you that are not super familiar with the 1508 standard, the vendor standard, Part 2 is the design of the hardware, and Part 3 is the design of the software. So, the hardware and the software need to be in accordance with 61508.

Okay, so let me get to the note before I expand on this a little bit more. The note says, devices assessed against 1508.2, 1508.3 can be applied in accordance with the requirements for systematic capability in 61508 Part 2. Okay, wow. Let's come back to this note a little bit later. Systematic capability is a big deal for equipment vendors to be able to achieve their certification for higher SIL levels. But at the end of the day, if you are an end user and you are looking at IEC 61511, you are under no obligation to consider systematic capability whatsoever.

Systematic capability only shows up in the standard twice and in informative notes, not in the requirements text. So, I'll come back to systematic capability in just a minute because I don't want to get thrown off.

So, what 11.521 says is that it needs to be in compliance with 61508, the device, like a pressure transmitter or a valve or an actuator or a positioner. Or you have to have prior use experience with it. Meaning, I have, you know, used this transmitter in basic process control for the last 20 years. I know it's failure modes. I know it's failure rate. I know when it's telling me that it's sick. I understand this device. This is the devil that I know. That is completely allowable. No certification required whatsoever.

And we'll get into 11.5.3, 11.5.6, where there's a little bit more meat on what it means to be proven in use.

Now, in compliance with 1508 Part 2 and Part 3 means that the equipment vendor used a quality process. They prepared all the proper paperwork. They did all the proper analysis. They applied all of the hardware requirements, all the software requirements that are in the standard. It just says that the vendor has to do that.

Now, why is certification so popular? Why is the compliant with 6508 almost synonymous with certified? Well, the reason is the equipment vendor can tell you they're compliant. But do you trust them? So, if an equipment vendor says, yes, my stuff is compliant and you choose to trust them, then you're going to be in compliance with this clause.

But most people don't trust the equipment vendors because they're trying to make money from you. They have a great incentive to over-inflate the capabilities of their device or flat-out lie for financial reasons. Which is why a lot of people say, yeah, I don't believe you. I want an independent third party to verify that you've designed your device in accordance with 650108, both in terms of the hardware and in terms of the software. So, yeah, that's the big reason for certification is, well, how do you trust the equipment vendor if a third party isn't vouching for them?

So, that's why. And I am just as guilty as anyone else of using the shorthand of certified instead of saying the vendor complied with IEC 61508. Because certified is one word and the vendor complied with 6508 is a lot more than one. All right, so that's the basic premise. Any device is either certified or prior use experience.

## Prohibited Devices and Thermal Dispersion War Story

So, what is not allowed in a safety instrumented system? And I'm focusing on field devices here. We will get a little bit deeper into logic solvers, FVL or LVL programmable devices next week.

Um, but you're also not allowed to use devices where the, uh, you don't have experience with the device. Now, the experience doesn't necessarily need to be in a safety application. Uh, but you need to have experience with the device.

So, war story. I am working with this plant in, uh, northern Ohio. We will leave it at that. This company is making uber dangerous stuff. Um, they are making highly, highly reactive chemicals on purpose.

And the, their customers buy their chemicals because they are highly reactive. And they need highly reactive chemicals to get things going, shall we say. Uh, so, uh, it, it, they need these chemicals. Reactive chemicals to start other reactions. Okay. This facility is kind of on the dangerous side. So much so that the original old school design of the plant had the control room on one side of a blast wall. And the process on the other side of the blast wall. And while the batch is running, you're not allowed in the process area. Furthermore, they had frangible walls.

I don't know if any of you are familiar with the concept of frangible walls. But basically, one of the walls is engineered to be weak. So that, not if, but when the plant blows up, that wall is going to collapse. And you're going to shoot your process out into a lake that is behind the plant. And behind the lake is a big earthen berm to basically catch all the shrapnel and prevent it from traveling out to Lake Erie. Well, technically, it would be traveling west and Lake Erie would be north. But I digress. Not really relevant here.

Now, this company, um, they are pumping their reactive chemicals. And the reactive chemicals undergo something called a self-accelerating decomposition. So, self-accelerating decomposition means as soon as I make an unstable chemical, it starts falling apart. You know, I make many moles of the chemical. But one at a time, they start cracking back into the lower reactivity building block starting points. Now, every time one of these molecules cracks down into the lower energy components, it releases energy, which causes the remainder to get hot. Or, not hot, but hotter.

And then, as the material gets hotter, it cracks faster. And you get to a self-accelerating decomposition temperature where, basically, you have started a vicious cycle where you're going to constantly increase the rate and the temperature is going to go up.

You're going to increase the rate until you get a violent explosion where everything basically decomposes at the same time. Now, if you keep these chemicals cool, then, you know, one or two molecules here and there popping off, the heat will get transferred to the atmosphere and you're not going to increase the bulk temperature. But once you're able to start increasing the bulk temperature, that's very, very bad.

Okay, now, what causes things to get hot? Well, this material needs to get pumped around. So, when we're pumping our material around, we're, I mean, this is going to be shocking to you, we're using a pump. And here's the downside of the pump. If you, when you're pumping, the action of pumping is putting heat into the material that you are pumping. Not a whole lot. And it's traveling through the pump, but it's no big deal. When does it become a big deal? Well, it becomes a big deal when you block your discharge. There, you're putting the energy, and I'm talking about a centrifugal pump here.

You're putting the energy of pumping into the fluid, but the fluid isn't moving, so it starts to get hot. Well, if you're deadheading a material that has a self-accelerating decomposition temperature that isn't sky high, and you're adding heat into it, it's not going to be a long period of time before you reach that self-accelerating decomposition temperature and blow all kinds of stuff up.

So, this particular outfit had a high SIL. Let's call it a SIL 2. Let's call it a SIL 3. Something around there. Doesn't really matter. Low flow shutdown. And historically, they were having a lot of trouble with the flow measurement that they were using, which was really kind of an archaic mechanical flow measurement, and they wanted to replace it because, you know, we're doing this upgrade of our SRS. Let's put in some new flow transmitters.

So, what did they decide on to measure the flow going through the pump? A thermal dispersion flow switch. Now, I don't know if any of you are familiar with the thermal dispersion flow switch, but you're basically measuring the temperature at a couple of different points in the flow path, and you've got a couple of reference measurements, and you're basically taking the difference in temperature between upstream and downstream and using that to estimate what the flow is. I know what you're thinking. Ed, that sounds a little bit sketch. I got that from my kids.

I know, sketch is not something that a 50-plus person should be saying, but I do have kids. So, measuring with a thermal dispersion flow switch is officially sketch. Okay.

But, you know, I'm here to follow the standard. And I said, okay, well, who is the vendor that you're buying this from? And they said, well, it's vendor XYZ. So, I call up vendor XYZ, and I say, hey, you know, what's your design process? Are you IEC 61508 compliant? Do you have third-party certification? And, of course, their response was, IEC what? So, they never heard of IEC 61508. So, obviously, it's not compliant with 1508 parts 2 and 3. So, I say, okay, well, route number one to accept this device for use in a safety application is off the table.

Let's go to prior use experience. Do you, the end-user company, use these flow meters anywhere in your plant? And what is your experience with them? And their answer is, no, this is the first time we would ever use this device. All right. There you go. If I had my gong here instead of back at the office, I'm working from the home office today, if that's relevant. But there is your case where, no, you cannot use that device in a safety application.

If you do want to use that device in a safety application, put it in as an indicator, maybe as an alarm, kind of as a backup device. See how it works. Gain some experience. Collect some failure rates. Do some calibration. You know, give it a couple years and, you know, maybe we can consider it. But today, the answer is no. You're going to have to go find something else. So, there is an example of the situation that you're not allowed to have.

Now, they came back and said, well, you know what? The equipment vendor says that other people have had good experience. And other people with processes that are similar to ours have had good experience. No. No. You need to have that experience. I mean, is the vendor not incentivized to tell you that other people have had good experience with their device? That's not a criteria for justifying use of a device in a safety application. Come on. All right. All right. So, instead of, you know, taking someone's word for it, you're going to need experience in your application.

Now, short of that, if you have a sister plant on the Gulf Coast, which this company did, and they had experience with that device in the same application, now it's a little bit easier to make a prior use case. Or, if you're like, let's say, out in the Houston Ship Channel with chemical plants all along the channel three deep, maybe you have some neighbors that have that device in a similar application. And you could go look at it and you can ask them questions. You know, maybe we can make a case for prior use there. But just the equipment vendor saying, oh, don't worry.

I've got customers who use it successfully. No. No. Okay. Let's continue on.

## Systematic Capability and SIL Limits

We're still in 11.521. And I just shouted out the note. Let me get back to systematic capability a little bit. So, systematic capability is something that you, an end user, a person that is trying to comply with IEC 61511, you are not obligated to give a crap about systematic capability at all. It is perfectly acceptable for it not to matter to you one whit.

And that's what the note says. Devices that are 1508 compliant can be applied in accordance with the requirements for systematic capability. You'll notice that they didn't put the comma, but they don't have to. But that's implied. Obviously, there are enough equipment vendors on the 1511 committee to where they would not want you to be able to say that. Or equipment vendors and purveyors of certification services that don't want you to, you know, denigrate what they do. But what is systematic capability?

Now, when you're talking about systematic capability, if you go into 61508, there are rules that you need to follow to prevent systematic common cause failures in your design.

And the strictness with which you need to follow these rules are going to give you different safety integrity levels. So, where the rubber meets the road, what we are really concerned about is programmable devices that have a low SIL number.

So, if I have a PLC that is certified for SIL 1 systematic capability, you should only apply that device in a SIL 1 loop period. And this is the area where redundancy doesn't help you. So, if your systematic capability limits your logic solver to SIL 1, you can't say, oh, well, I took my two logic solvers and made a one out of two vote. And now I'm at SIL 2. No, no, you're not. You're still at SIL 1. Because there is systematic potential failures. And systematic failures destroy common cause. Which is why redundancy doesn't help you with respect to systematic failures.

Because if one of the devices is failed, they are all failed for the same reason. Common cause is 100% with systematic failures.

So, what we're trying to prevent you from doing is saying, I have a SIL 1, let's say I have a single device logic solver. And they're out there. So, I've got something that's going to read my pressure transmitter and it's going to de-energize the signal going to the valve. And let's say that that device is programmable and it has a systematic capability of one. Well, if I do a two out of three vote where that SIL 1 capable device is the logic solver on all three legs of that two out of three vote, guess what?

You're still SIL 1. Because the expectation is that there is a high enough propensity for a common cause failure of all three of those devices that you can't use it in SIL 2 or SIL 3.

So, I'm not going to poo-poo on systematic capability too much. I understand what its value is. But at the same time, it generally gets wildly overblown. And most devices that are certified out there are going to be certified the systematic capability three anyway. So, something, know about it, understand it. Don't get too over the top with systematic capability. Because at the end of the day, what the standard says is you can consider it, but you don't have to. All right, let's move on.

## Clause 11.5.2.2 Device Suitability and Environment

So, now we're going to go into Clause 11.522. Which states, there's a couple sentences here. All devices shall be suitable for the operating environment as determined through consideration of the manufacturer's documentation, the constraints within the SRS, and the reliability parameters assumed in respect to 11.9. That's the SIL verification calculation clause. Suitability of the selected devices shall always be considered in the context of the operating environment.

All right, so what Clause 11.522 is telling you is, yeah, maybe the device is certified. But the vendor of the certified device, at the end of the day, doesn't know where you're installing your device. So, you cannot obviate. You cannot get rid of your responsibilities as an instrumentation and control engineer and just close your eyes and say, oh, it's certified, so I'm going to throw it in there. You need to think about the technology that that device is using and whether that technology is compatible with the application that you're going to install your equipment in.

We're going to come back to this again in Clause 11.6 when we start talking about field devices.

But, hey, you're an instrumentation and control engineer. You need to make sure that your device is suitable for the application. And you know what? In order to be suitable for the application, you necessarily need to have prior use experience. So, you know, a lot of the equipment vendors, a lot of the certification bodies are going to trumpet up and down. Certification is the way to go. You need to buy a certified device. But I will tell you, even if your device is certified, you still need to have prior use experience with it. Otherwise, you've got no business putting it in your application.

Because how do you know that it's compatible with the process service? Example.

More war stories. Back in the early days, this was the early 2000s. I have a vendor or a customer that is in refining. And we are looking at the acid gas knockout drum in a sulfur recovery unit. So acid gas knockout drum, nasty, nasty, nasty service. All kinds of particulates, all kinds of solids, rusts, junk. It's acidic, as implied by the acid gas name. So it's corroding everything. And it's mostly hydrogen sulfide, which is wildly toxic at very low concentrations. This is a nasty service.

And historically, they had used displacer transmitters. This is the early 90s. I mean, the guided wave radars that are all the rage today didn't really exist at this point in time. So we were still using displacers for the most part. And this was the devil that they know. Was this measurement perfect? Absolutely not. It failed all the time. But they knew when it failed by looking at the trace. They knew how to repair it. They knew how long it was going to be before it failed. And they had a pretty good preventative maintenance program. So not the best measurement, but the devil that you know.

So when they were putting in a new safety instrumented system, what did they decide that they were going to do? They decided that they were going to put in a certified device. But there were no certified displacers. So they changed from the devil they know of the displacer to the devil that they don't know of a differential pressure measurement. But hey, it's still too certified. So it's got to be better. Right? Right? Oh, no. No, it doesn't have to be better. It's certified, but it was dramatically worse. Now, how do you mess up a differential pressure measurement?

Well, as I mentioned, there are all kinds of salts and junk in this process. As a result, you don't want to just use an impulse pipe that's connected to the process because it will be full of junk in minutes after startup. So you're going to use a remote seal. So you're going to have an element in the vessel that is going to basically increase or decrease the pressure of the hydraulic fluid in the line. Now, the problem is that even though we have this seal, the remote seal, the process is nasty enough to cake completely over the diaphragm.

And that's exactly what happened. And the operators who were given no credit for operator intervention because operators are no good. They're not going to respond to the alarm 90% of the time. No, it was the operators who were looking at the level trace of the safety transmitters going, there is no way that can be right. Because I had noise on my measurement when I started. I have no noise now and my measurement isn't moving. So the diagnostics were performed by those operators that they didn't want to take credit for who diagnosed that the device had failed.

And now, whereas repairing the maintenance that they did on the displacer was relatively easy. All they had to do was isolate the displacer from the process and then basically flush the displacer out until all the crap was gone and then bring it back into service. For their new certified devices, they had to shut down the entire plant.

Shut down the entire refinery because this is the sulfur recovery unit. If you can't get rid of your H2S, you can't make H2S. And you can't make any product in a refinery without making H2S. So gigantic cost to shut down the plant so that they could go clean off the remote seals. And guess what they also did? They put their displacers back in service because, well, the new certified device is incompatible with the process because, well, there's no way to clean off the diaphragms while the plant is online and running. So we're kind of at a non-starter there.

## Process Connection Failure Rates and Diagnostics

So, yeah, that's 11.522. You're an instrumentation control engineer. You need to think about the technology you're applying. You're going to need to think about prior use. And hear me now and believe me later, even if it is certified, you still need prior use experience.

Period. Well, I guess that's my opinion. Maybe I should get off my soapbox. I'm kind of dumping a little bit of cold water on certification, especially for field devices. I know this. But I don't want you to be lulled into complacency by equipment vendor and certification body promises that might not actually match up with reality. Believe it or not.

Okay.

There is a note on Clause 11.522, which states, Devices may exhibit different failure rates depending on the operating environment and mode of operation. Duh. That's what I was just talking about. Failure rate data available from manufacturers may not be valid in all applications. I would go even further and say it's not valid in any application unless you specifically, separately, deliberately consider the failure rates associated with the process connection, which are not included in the failure rates that your equipment vendor provided to you in the certification report.

So if you go to a really good SIL verification tool like Vertigo, the best, you'll see that when you're building out a subsystem for a sensor, there's going to be a specific slot where you need to put in the failure rate associated with the process connection. And also, maybe another interesting topic for another day, are there diagnostics that we could take credit for on the failure rate of the process connection?

Turns out there are. In this case, the operations team was able to diagnose that the device had failed. And that was early 2000s. Now we've got a lot of equipment that has a lot of built-in tap plugging detection or just, you know, failure detection. Now, from what I've heard, and this has come up recently with one particular refinery that has done a lot of work with Kenexis in quantifying failure rates associated with tap plugging, is that they're getting better than 90% diagnostic coverage of plug taps.

But it's not generally the tap plugging algorithm that's built into the transmitters, which we have found give an absolutely insane amount of false alarms. I mean, the false alarm to real alarm is probably, it's more than 10 to 1, probably approaching 20 or 30 to 1 in terms of false alarms versus actual plug taps. But other things like temperatures in the impulse line and so on.

So, all right, I'm starting to go off on a little bit of tangent there. Finishing off the note, the next sentence, for example, the failure rate and failure mode distribution can be different for a valve that is frequently exercised versus one that stands still for long periods of time. So, that's an example where the failure rate is different for a device depending on how it is used.

## Clause 11.5.3 Prior Use Evidence Criteria

Okay, let's go on now to clause 11.5.3, which is where I am going to wrap up for the day. But there's a lot to this, so let's kind of power through it.

11.5.3 is the bottom line for the requirements for selection of devices based on prior use. So, if you don't have a certified device, you're going to use a device that you have experience with. That's okay, but there are rules to determine whether or not you can take credit for that device as actually having prior use experience.

And that is going to be listed out here in clause 11.5.3. So, clause 11.5.3.1 says, appropriate evidence shall be available that the devices are suitable for use in the SIS.

So, evidence shall be available. So, you need to put together, well, you don't need to put together documentation. It doesn't say that appropriate evidence shall be created and documented. It just says it shall be available. So, you need to know that if you had to provide documentation, make a case, you would be able to do so.

Which is kind of a notch below you put together the case a priori. You don't have to put together the case a priori. The evidence just has to be available. You need not, ahead of time, turn it into a documented case. Now, we recommend that you do, I don't know, recommend might be a bit of a stretch. It's not a bad idea if you want to do that.

Now, if you want to put together documentation of prior use, go to the Kenexis website, www.Kenexis.com. You are going to see a drop-down menu for tools. And under tools, there is going to be a spreadsheet that you can download. Don't remember off the top of my head what it's called. Something like prior use justification, which gives you a good spreadsheet where if you could fill out the information on the spreadsheet, that is making your official case for prior use experience. Now, there are four notes under this one sentence requirements.

Note one states,

Okay, so prior use experience, we want to make sure that we don't have dangerous failures at an excessively high level. We definitely want to make sure we don't have systematic failures. Note two says the level of detail of the evidence can be in accordance with the complexity of the considered device.

So more simple devices require less explanation of why they are suitable for use. Note three states a prior use evaluation involves gathering documentation concerning a device in a similar operating profile. Now, prior use demonstrates the functionality and integrity of the installed device, including the process interfaces. My, wouldn't it be nice if vendor certifications required integrity, including process interfaces? But they don't. Also requires full device boundary communications and utilities, everything associated with it.

The main intent of the prior use evaluation is to gather evidence that the dangerous systematic faults have been reduced to a sufficiently low level compared to the required safety integrity. All right. Note four. Prior use data can contribute to a database for the calculation of hardware failure rates as described in 1193.

So note four is saying, hey, if you have prior use data where you've collected and vetted the failure rates, that's awesome. And maybe you should probably even be using those types of things in your calculations. 1193 is coming up in a few weeks. We'll get there. Or 11.9 is the full clause. Okay. Let's move on now.

So 11.531 says evidence has to be available. Okay. 11.532 explains what the evidence that you need is.

And there are four things that you need. Four items. Four bullet points. Let me summarize them. Number one, quality program of the manufacturer. Number two, adequate identification. Item three, demonstration in a similar operating environment. And four, sufficient volume of operating experience. So volume of experience in the same application, adequately divine device with a vendor that has a quality program. All right.

Let's drill down into these in a little bit more detail. So item number one stated that we need consideration of the manufacturer's quality, management, and configuration management system. So is your vendor ISO 9000 certified? And ISO 9000 certification, if your vendor is not ISO 9000 certified, I question why you are buying anything. Kenexis. We're a consulting company. We provide software. We are ISO 9000 certified. Why would you consider buying anything from someone who isn't getting a third-party certification of the way that they do their work?

Making sure that their work processes are verified, are documented, and are consistent.

Now, why is this clause here? Well, if I have model ABC of vendor X out in the field, and I like how it performs, I want to make sure that when I buy a new model ABC, I'm getting the same thing that I have out in the field right now. And that's what the ISO 9000 process gives you.

So a little example, not in the process industries. As a consultant, lecturer, educator, I travel an insane, insane amount. I have been, I turned gold on, you know, I turned a million miler on United. And I would, if you added up all my miles on other airlines, I would probably be close to a million miles there too. So I travel a lot. So I brutalize my luggage.

Now, I bought a Samsonite luggage that worked spectacularly early in my career. When it finally gave out, I bought another Samsonite and it failed like on the second or third trip. It was horrible. Well, what happened? After I did a little bit of digging, which I should have done maybe before I bought it, I found out that the makers of Samsonite were bought out by private equity. Okay, another lesson.

Any of your equipment vendors, if they are owned by a private equity company, let me tell you what private equity does. Private equity buys a profitable company and cuts costs everywhere, fires people, gets rid of customer service to jack up the profitability and then either spins it back out into the public markets or sells it to somebody else. So they will basically take a great company and destroy it so that it temporarily looks profitable. And then they spin it off to somebody else. So check all of your equipment vendors.

And if they have recently been purchased by private equity, run for the doors. Okay, yeah. Let's see here. Kenexis has competitors in the software arena. Are any of those competitors owned by a private equity company? Hmm. Hmm. Maybe some of you guys should do your research. All right. Okay, I'm going off on a tangent.

Bullet point number two in 11.532 states adequate identification and specification of the device. So basically, going and saying I want exactly the same serial number might be a bit much. But then collecting data for an Emerson displacer level transmitter and then saying, oh, we have luck with that Emerson displacer level transmitter. Let's buy one of their guided wave radars and put it in based on prior use. That's a bridge too far. Let's get a little bit reasonable there. Bullet point three.

A demonstration of the performance of the devices in similar operating environments. So just because I have a transmitter that works great in purchased clean natural gas from a utility does not mean that device will work in the nasty, dirty refinery gas application or a sulfuric acid or a hydrofluoric acid application. So the applications need to be similar.

Again, use your judgment. It doesn't need to be exactly the same, but let's not get crazy. There is a note to bullet point three, which is note one. In the case of field devices, for example, sensors and final elements fulfilling a given specification, the behavior of the device in the operating environment is usually identical in safety and non-safety applications. Therefore, evidence of performance of similar devices in non-safety applications can be used to satisfy this requirement.

So it's perfectly acceptable to use data from an indicator to say that this device is suitable for use as part of a safety instrumented function because they're going to suffer the same failure modes because they're in the same process service.

## Volume of Operating Experience and Prior Use Shortcut

Finally, the last item here is the volume of operating experience. And this here is where I'm going to tell you not to trust the certification bodies. And I'm going to tell you not to trust the equipment vendors when they tell you how much experience you need because it's in their best interest to make you think you need millions of years of operating data so that you just buy the devices that put money in their pockets.

Let me boil this down. You do need a certain amount of experience to justify use in a safety application. And I'm going to give you a shortcut. But before I give you the shortcut, let me read the notes to you.

Note number two says, for field devices, information relating to operation experience is mainly recorded in the user's list of approved equipment for use in their facilities based on extensive history of successful performance in safety and non-safety applications. And on the elimination of equipment not performing in a satisfactory manner, this list of devices can be used to support claims of experience in operation, provided that the list is updated and monitored regularly.

The field devices are only added when sufficient operating experience has been obtained. Field devices are removed when they show a history of not performing in a satisfactory manner. And the operating environment is included in the list where relevant. That's a whole lot of words. But what those whole lot of words are putting forward is that you should have an approved vendor list. And you should use devices off that approved vendor list. And specifically, not just the vendor as a whole, but the specific devices for that vendor.

So if I need a shutoff valve, my approved vendors are A and B, model X and Y. Okay. And obviously, you should be able to collect data for those standardized pieces of equipment that you're using in your facility. All right.

Note three, device performance is highly affected by the operating environment. It is generally recommended that selection of devices can be based on adequate performance of an installed sufficient number of devices in multiple installations, sufficient for a long operating time or a sufficient operating time. The gained experience can allow time to reveal early failures, such as those related to specs handling, installation, and commissioning. Okay. So, yeah. Failure rates are going to depend on where you put the devices.

And you're going to want devices in different applications to be considered. And you're going to want to have sufficient operating time to make sure that failures have happened.

Item four, note four. The amount of operational experience to gain credible statistical reliability data is typically much higher compared to the operational experience necessary to get evidence of prior use. I disagree. I disagree with that note. I'm a standard on the standards committee. I disagree with that note. And I guess it really depends on what you mean by operational experience.

So, let me cut down to the chase. How much experience do you need? Well, it depends on what you're claiming. So, if I'm running SIL verification calculations, and I might be basing those SIL verification calculations based on generic data from industry. And let's say I am claiming a mean time to fail dangerous, mean time to fail, one over the failure rate, of 100 years. Well, then it would seem that if I'm making that claim in my calculations, I should be able to back it up with the data from the plan. So, does that mean I need 100 calendar years of data?

I'm not going to live that long. This is stupid. No, but why are we ever going to?

*[inaudible]*

It's not calendar time. It's going to be equipment time. So, if you only have one device, yeah, you need 100 years of experience, and your device is going to fail after 30 years.

So, that's not even realistic. But if I have two devices, well, I only need 50 years each, which is still unreasonable. But if I have 10 devices, I only need 10 years of experience. If I have 100 devices, I could get 100 equipment years of experience of that device in one year. So, basically, your experience with the device should be commensurate, the same or higher, than the mean time to fail you're dangerous that you're using in your calculations. That's Ed's shortcut. It's not in a standard anywhere, but it's a really good benchmark for you to follow when you're doing these types of things.

All right, one more clause in 11.5.3.

## Management of Change and Episode Wrap-Up

All devices selected based on prior use shall be identified by a specific revision number and shall be under the control of a management of change procedure. In the case of a change being made to the device, the continued validity of the evidence of prior use shall be justified by evaluating the significance of the change made.

Well, following clause 11.5.3.3 is kind of inherent in a good MOC process. If you're going to take a device that's in the SIS and change it, replace it with something else, change how it's installed, you should be filling out all of your MOC paperwork.

And boy, speaking of MOC, Kenexis Integrated Safety Suite, we're going to be launching the Intelligent MOC module in the not-too-distant future. It's popular demand. Lots of our customers really want the MOC module because of the tight integration with the OpenPHA risk analysis processes and checklists. And then also all of our application programming interfaces to allow you to power BI effectively everything that's in KISS. But I digress. But bottom line here is if you have a good MOC process, this will be part and parcel of it.

And if you don't have a good MOC process, well, maybe you need to upgrade your MOC process to make sure that if you're making changes to SIS equipment, whether it's certified or not, you need to follow MOC procedures to make sure that what changes you're doing are going to be done safely. And with that, I have used up almost an hour of time here, so I am going to have to back out and save the rest of Clause 11.5 for next week, where we're going to go into logic solvers and talk about safety configuration. I will see you then.

## Vertigo SIS Lifecycle Tool 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.

*[inaudible]*

Thank you.