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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E41 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 41: IEC 61511, Clause 11.7.1 and 11.7.4 (Communication Interface Requirements)

—

## Cold Open and Podcast Introduction

You're allowed to communicate data in and out of the safety instrumented system, but when you do, you need to make sure that you don't bring a failure from the outside in.

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.

## Episode Overview and Clause 11.7 Structure

All right. Well, in today's episode, we're going to run a little bit of an abbreviated episode because we're going to start into interfaces. So communicating with other systems, other pieces of equipment, to get data out of the safety instrumented system to other users, and also bring data into the safety instrumented system. And there are a few places where you really need to bring data into the safety instrumented system from the outside world. And that's an opportunity. It's a giant opportunity to get things wrong.

And we'll talk about today one of the main reasons why these communications fail, and it is cosmic rays from outer space. Yeah, you heard me correctly. Cosmic rays from outer space. Cosmic rays, that reminds me that the family is going to Disney World over Christmas break here coming up not about a month from now. And we will probably be visiting Cosmic rays, which is one of the restaurants there in the Magic Kingdom in Tomorrowland. But now I have gone completely off the reservation.

Okay, so we're introducing the topic today of interfaces. And interfaces is the topic of all of clause 11.7 in the standard. And 11.7 is broken into three pieces, even though there are four clauses. The first clause just basically says what the three pieces are going to be. So I'm going to include clause 11.71 with clause 11.74. And I'm going to cover those in today's episode. And then I'm going to go into 11.72 and 11.7.3. One each probably because there's a lot of information for each of those individually in a couple of separate installments of the podcast.

So today's podcast is just kind of general information about interface devices. What do we mean by them? How can they fail? How can a failure in an external system get moved into the safety instrumented system? And ultimately, what we're really concerned about is that external devices, external interfaces are not designed with the same degree of rigor and fault tolerance as the safety instrumented system. And we can't just assume that a piece of data from the outside is good because you don't have the error checking mechanisms on the outside that you do inside the safety instrumented system.

And that's a perfect opportunity for bad data to work its way into the safety instrumented system because we brought it in from a system that's not cared for as thoroughly as other systems.

So let's begin. Again, clause 11.7 was interfaces. Clause 11.7.1 is general. So that's the title of the clause, obviously, general for interfaces. And it's a really 11.7.1 is a really brief clause that basically says interfaces to the SIS can include but are not limited to. And then it gives the three bullet points. Those three bullet points are going to be operator interfaces, maintenance and engineering interfaces, and communication interfaces. And realistically, there are two general types of devices that we interface to.

That's going to be the operator interface and the maintenance and engineering interface. The clause on communication interfaces basically talks more about the hardware and the mechanics of communications in general and what the requirements are, what you need to think about when you're communicating with external devices. So clause 11.72, operator interface requirements, is going to contain a lot of information on how do you communicate information to external users, whether that be operators, maintenance technicians, and so on.

What are the hardware choices, etc. We'll probably pick that up next week. And then clause 11.7.3 is going to talk about maintenance and engineering interfaces. And those are the devices and computers and programs that you're going to use to maintain and engineer the safety PLC. So that's where you're going to be writing your code. It's where you're going to upload code. You're going to download code. You're going to look at diagnostics and so on. So between operator interfaces and maintenance and engineering interfaces, that is the bulk of what you're going to worry about.

But you are also going to communicate for other reasons. You might want to communicate data to your basic process control system for comparison purposes. You might need to push data to external users outside your plant, outside your facility, SCADA systems. So in clause 11.74, we're going to talk a little bit more about the mechanics of how you do the communication without doing a lot of thinking about what is the end user using that data for. Whereas in clause 11.72 and 11.73, we're going to think about that quite a bit. All right. So let's get into it.

So the two clauses for today, 11.71 and 11.74, this is going to be a rather brief session. But it's kind of hard to break this up. I thought maybe that I would just kind of cruise through it, 11.71, 11.72. But really, I think what we need to do in this episode is we need to level set the details, the mechanics of the communication, which is going to be 7.1 and 7.4. And then we'll get into the specific applications for communications, being operator interface and maintenance and engineering, in two separate episodes that we'll get to in the coming weeks.

I'll try to record them because it is Thanksgiving week here in the United States. So I will probably have a little bit of time over the long weekend to get some of this in the can, get a couple more episodes ready to go. But then again, for those of you that know, I am a graduate of the Ohio State University. And Thanksgiving weekend also means that on Saturday we're going to be playing Michigan. So, you know, it's almost like, you know, a divine day here in Columbus, Ohio, when Ohio State plays Michigan. You know, you have to drop everything.

It is the real holiday of the Thanksgiving weekend, not Thanksgiving itself.

## Clause 11.7.1: Interface Types Overview

Okay, so Clause 11.71. I've already read it to you, but let's read it one more time. The title of the clause is General. The content of the clause is interfaces to the SIS can include but are not limited to operator interfaces, maintenance and engineering interfaces, and communication interfaces. That's it. That's all that the clause says is it basically lists out three types of interfaces.

But in reality, that third bullet item, communication interfaces, is a clause that's going to talk more about the mechanics of how you communicate the signal and potentially what can go wrong as opposed to details, which when we talk about operator interface and maintenance and engineering interface, we're going to talk about, well, what do you communicate, how you communicate it, who do you communicate it to, how you make it safe, and so on. All right, so that was Clause 11.71.

## Clause 11.7.4.1 and Cosmic Ray Bit-Flips

Now let's move on to Clause 11.74, where we're going to get into a lot of detail about what can go wrong. And I'm going to kind of go into a little bit of theory. I'm going to talk a little bit about transistors. I'm going to talk a little bit about chips, things that can go wrong and get communicated into the SIS. Now, when you look at Clause 11.7.4, its title is Communication Interface Requirements. Okay, no biggie. What are the requirements for the communication interface?

And specifically, they're talking a lot about what are the hardware requirements, but also addressing the hardware requirements to some degree also requires addressing the software requirements in order to detect and communicate failures. Now, Clause 11.74 has four clauses in it. And each of these four clauses are one sentence only. So we're not talking about a massive undertaking in the amount of information that we're going to be talking about today by any stretch of the imagination.

As a matter of fact, when I teach training classes, whether it's the ISA EC50 class that we just started another virtual session of that last week. And oh, if you're listening to this right now, the second week of December, I'm going to be teaching the EC50 virtual class. I will be teaching it. I'm sorry. I take that back. AK is going to be teaching the EC50, but I will be teaching the EC52 and EC54 class. So AK, Arthur Pierce, I'll be teaching the kind of the introductory EC50 and I'll be teaching the advanced classes. EC52 is for LOPA, basically two days of LOPA.

And then EC54 is two days of advanced SIL verification calculations and safety requirement specification details. Okay, man, did I get off topic there. But I was saying when I teach these classes, I will always say that clause one, two, and three in 1174 say exactly the same thing. But there is a different constituency involved. And finally, 11744 says something a little bit different, gets into some of the details of the mechanics of how the communication happens. All right, let's drill down. 11741 states, and this is the kicker. This is the key.

This tells you all you need to know about communication interface requirements.

It says, The design of any SIS communication interface shall ensure that any failure of the communication interface shall not adversely affect the ability of the SIS to achieve or maintain a safe state of the process. Okay, that is one very simple sentence, but it's also one very loaded sentence. Also, I would kind of expand this sentence also to say that you're worried about not just failures of the communication interface itself, but also failures of the equipment that your communication interface is connected to.

So the kicker here, what we absolutely unequivocally want to prevent is any failure on the outside getting communicated into the safety instrumented system and having that failure that was communicated in cause a dangerous failure of the SIS. And I'll give you a big example, the primary example of how that happens and what mechanisms we're going to be using to prevent that from impacting our safety instrumented system.

Because we do have all kinds of great diagnostics, especially in the communication interface device itself. Okay, so number one, you need to think about what is getting communicated between the SIS and the outside world.

Well, number one, you're going to want to communicate the status of your safety instrumented system to the outside world. If the safety instrumented system is sick, if it has failed, if it's too hot, if it's too cold, if it's too sweaty, aka the humidity is too high, You are going to want to let someone know so we can prevent the failure or repair the failure. Also, if my shutdown system caused my plant to trip, I should probably let somebody know that. So communication of information of how the SIS is running to the outside world, that's usually going to be the operator interface.

That's what we're going to talk about next week. That's going to be the discussion in Clause 11.7.2.

## Bypasses and Data Integrity from External Systems

Now, sometimes you also want to communicate information into the safety instrumented system from the outside world. The two big things, the two primary bits of information that come from the outside in are going to include bypasses and resets. So now it's possible to perform your bypass completely inside the SIS. You can hardwire a key lock switch. And all of that equipment resides in the SIS. So you don't need to do any communications with the outside world. But hardwired switches for bypasses are a pain in the butt. They're expensive.

And, you know, generally operators want to do stuff on the computer. I want to do everything on the computer. You know, if I could just sit here at my computer and run the world without leaving, other than, you know, heading to the kitchen. But then again, you know, I probably could put a refrigerator right here. So, all right. Again, getting a little bit off topic here. There's a lot of reasons to trigger bypasses from the operator interface and communicate them into the SIS. And we want to make sure that bad data doesn't get communicated into the safety instrumented system.

So that's one thing that we want to do. Now, other things get communicated into the SIS from the basic process control system and other systems that are interconnected on that process control network. A good example would be something like, what batch step are we in? So the basic process control system for a batch process is going to keep track of what step you're in. And in different steps, you're going to be running different temperatures, pressures, compositions, etc. And a hazard might be present in step two that's not present in step three.

So in step two, you might want to activate a safety instrumented function when the temperature goes high. But in step three, you might not want to do that. So communicating what the plant status is, what step you're in, is something that you're routinely going to want to do. So there are things that are going to come into the safety instrumented system from the outside world.

Now, data. How can data get compromised? So you might be saying, well, if the SIS or if the basic process control system says to put something in bypass and the basic process control system thinks you're in bypass, isn't that good enough? Well, no.

So let's talk about the primary failure mode of memory. And this is kind of relevant because just a couple weeks ago, it might have been last week, I'm talking to you on November 24th, 2025, just in case people are kind of going offline here. In the past preceding couple of weeks, there has been a massive, massive solar flare causing a massive electromagnetic event in the sun. Why do we care about that?

Well, when the sun belches out a whole lot of electromagnetic radiation and it works its way to the earth, part of it is beautiful because you're going to get the aurora borealis, the northern lights, where those particles interact with the atmosphere at night and you see green and blue, all kinds of colors in the sky and it's really rather pretty. But those same particles can damage electrical equipment. So when you look at memory in a computer, it's a bunch of transistors. So a transistor, you're going to have a doped piece of silicon, usually silicon.

Selenium was the original transistors, but now we're primarily looking at silicon. And when you apply a current to the gate or a voltage to the gate, you can flip the state from positive to negative.

Well, it just so happens that electromagnetic radiation, cosmic rays from outer space, also have enough energy that if they hit the circuit board, they can flip the state of a bit in memory. Now, for a safety instrumented system, this is no biggie because our SIL 3 certified safety instrumented systems that are built really, really well have all kinds of diagnostics where once a scan, you're going to take your memory map, you're going to invert your memory map, and you're going to make sure that the inversions are perfect copies of each other.

And if they're not perfect copies of each other, they're going to reset the data bits so that they are perfect copies of each other. And so you're going to be able to check that everything is actually in its correct commanded state, and that the memory bits are going to freely flip from one state to another state. And safety PLCs do this every scan. So this type of cosmic ray from outer space is going to be caught by diagnostics for good safety PLCs. Now, do we have those same diagnostics in your basic process control system? No, you don't.

So when the cosmic ray from outer space flips a bit in your basic process control system, it's not going to change states. So until the next time you set that bit in memory, it's going to be wrong. Yowch. That's no good. Now, what if that cosmic ray from outer space hit the bit that holds the status of your bypass command? Well, your communication interface is going to faithfully copy that bit of memory from your basic process control system into your safety instrumented system. And guess what? That communication just caused a dangerous failure of your safety instrumented function.

That's the kind of stuff that we want to prevent from happening. So now, how do you actually do that? Well, what we're going to do is we're going to limit when we actually communicate stuff from the SIS or from the outside world to the SIS. And we're going to have error checking algorithms for what we communicate. So let me start with the most modern, newest approach to making sure that these communications happen safely.

## Digital Ping-Pong Protocol for Safe Bypasses

I like to call it digital ping pong. So if you want to bypass something and you're at the operator interface of the basic process control system, you could go to your safety instrumented function. You could go to your sensor. And on the sensor faceplate, you can click the bypass button. And as far as you know, as the process operator, when you click the bypass button, it goes into bypass. But under the hood, a lot of stuff is going on.

And this stuff that I'm going to describe under the hood, if you're working with a completely integrated system, so you're buying your operator interface, your basic process control system, and your safety instrumented system from the same vendor, they're usually going to do all this work for you without you needing to think about it. So what the digital ping pong looks like is when the operator presses the bypass button, the operator interface is going to go through the DCS to communicate a signal to the SIS that says, I would like to put this transmitter into bypass.

The SIS is then going to respond with, I received a message saying that you would like to put this transmitter into bypass. Is that correct? And then the BPCS is going to respond that, yes, that is correct. I would like to put that device into bypass. And only when those three transactions that are actually sending data back and forth between the systems happens, only when you do that three-step process, will you actually change the bit in memory in the safety instrumented system.

So in the basic process control system, just a flip of a bit in memory is not going to trigger all this, and it definitely won't complete the sequence. So a single point of failure is not going to cause a dangerous failure in the SIS. So that's the mechanism that's being used to address this.

Now, again, it's important to remember that this is different than just having the operator interface code pop up a window that says, are you sure? We're actually moving data back and forth between the systems multiple times and looking at different bits in memory on the different computers. Another older mechanism that people used to use to do this, now it's still out there, but it's kind of going the way of the dinosaur, is to use the bypass enable switch.

So basically you have a hardwired physical switch in the safety instrumented system that basically the SIS would be programmed to ignore bypasses unless the bypass enable switch is in the enable position. Well, the problem with that is a lot of people, you know, when they were commissioning their safety instrumented system back in 1985, put that bypass enable switch into the enable position, and you go out there and look at the control board today, and that bypass enable switch is still in the enable position. So that doesn't do a whole lot.

A little bit better would be to use a spring return or, aka a dead man switch, but, you know, a paperweight.

And, you know, there are a lot of ways to get around that. You know, I think I've brought up before that back when I was at UOP as a field service engineer, I used to carry a wire with a couple alligator clips on the end around, and I used to tell everybody, I have the master key. So a lot of ways to bypass that kind of stuff, whereas the digital ping pong that's built in to your operator interface system is not as easily defeated. And it's generally easier to use also.

Now, before I kind of leave that digital ping pong topic, if you are using something like a Modicon 984 talking to Wonderware that's talking to a TDC-2000 DCS, yeah, the Wonderware doesn't have this built in, nor does the TDC-2000, nor does the Modicon 984. So if you're running older equipment or general purpose PLC equipment, guess what you got to do going back to last week? You got a safety configure. So all of this code that's built into the more modern integrated systems, you're going to need to write yourself.

You're going to need to write code on the DCS side, you're going to need to write code on the SIS side, and you're going to need to write code in the operator interface software to take care of all this for you. It's not impossible. Again, it's just a little bit of work. And another reason why you understand why people spend a little bit of extra money to buy that certified integrated system instead of trying to cobble together stuff out of AutomationDirect, etc. Not that there's anything wrong with AutomationDirect.

It's just that they didn't build their stuff specifically for safety instrumented systems. Okay, so that is Clause 11.741.

## Communication Reliability and the Wharf Phone Story

And you know what? I didn't really finish the discussion because I just talked about how failures in the communication between the SIS and the other external stuff can fail and what you need to do about it. What I didn't talk about is the fact that you really shouldn't rely on your communication interface to be working for your safety instrumented system to work. What do I mean by that? So there are a lot of points and times when I have been in an operating plant and everything goes dark. So you're in the control room. Everyone is eating microwave popcorn.

Looking at all the gigantic TV screens that are telling you the status of the planet. And then all of a sudden, everything goes black. The lights go out. The screens go dark. And you know, this is not a comfortable situation for most people. But at the same time, you know that the DCS is still running. The SIS is still running. And you should be able to go for some significant period of time without actually seeing what's going on. And everything will be okay. Now, if you're relying on communications between the outside world and your SIS to do its job, that might not be the case.

So let me give you an example.

The actual operating company shall remain nameless, but I will tell you that it was an oil refining company. I'll just leave it at that. I'm not even going to tell you what part of the world that they were in. But basically, if they had a wharf area, so they had an oil movements area where they generally stored all their oil and all their crude oil and all their products. And then there was a wharf area where they pumped material from oil movements to the wharf so that there was a tank closer to the wharf to fill ships with.

They were also filling rail cars and tank trucks and a lot of other things. And the wharf and the oil movements area are about, oh, I'm going to say, I'm going to go metric here and say they're about a half kilometer apart. You like that? For those of you in the U.S., that's about five football fields. Go Bucs! All right. Beat Michigan. So five football fields apart. They didn't want to run wiring.

And there was a safety function that basically said, when the tank at the wharf, if the level gets high, I'm going to want to stop the pump that's over in the oil movements area, half a kilometer or five football fields away. So how do I do this? Well, typically you would take the level measurement and you would wire it out to the safety PLC that's in the oil movements area that's going to stop the pump.

Well, you know, copper is expensive. That's a lot of wire. We didn't have fiber optics. This is late 90s, early 2000s. So not as sophisticated as we are today. So how did this signal get from the wharf over the oil movements area? A telephone. That's right. A telephone. They were relying on, well, you see, I was about ready to tell you who the phone company was, but that'd be giving you too much information.

So basically the control system would basically, they had a SCADA system where if the high level alarm occurred, that would trigger a phone call to the phone in the oil movements control room. And then that phone would trigger a signal to the shutdown system to stop the pump.

So in the middle of my safety function, I am literally making a phone call to cause the shutdown system to work. Crazy, but true. So that's the kind of thing that you, basically, a failure of that phone call is a real problem. And what we're saying in clause 11.7.4.1 is that if that phone call doesn't work, we shouldn't be relying on that as part of our safety instrumented function. So what, how we design our systems today is that we kind of divorce ourself from the medium, whether it's a phone call, whether it's a copper wire, whether it's fiber optics, whether it's smoke signals.

We need to be able to run diagnostics on that signal to know whether or not our communication channel has been compromised. And if our communication channel has been compromised, we need to shut down the safety, basically activate the safety instrumented function, shut down the plant in less than the process safety time. And the process safety time for filling up the, or overfilling the storage tank at the wharf is, you know, it's big. We've got ourselves a few minutes to deal with this. We don't need to shut down if we lose one packet of data. But it's something that you need to think about.

So don't rely on, I mean, the best thing to do is not rely on external communications for your safety instrumented system to work. Period. But if you do, you need to make sure that you have diagnostics that are going to reliably detect that you've lost your communications and shut down, activate your safety instrumented function if you know that communications are lost. So we're going to talk about this a lot more next week when we're talking about the operator interface and there are more detailed clauses on these communications.

## Clauses 11.7.4.2 and 11.7.4.3: BPCS, Peripherals, and EMI

Okay. So 11742 and 4.3 are basically going to say the same thing but there's going to be a specific constituency. So Clause 11742 states, when the SIS is able to communicate with the BPCS and peripherals, the communication interface BPCS or peripherals shall not adversely impact any of the SIFs within the SIS. So in Clause 11741 we said any communication shall not impact the SIS. And 11742 isn't really different. All that it does is specifically call out some common things that you communicate with. you commonly communicate with the BPCS.

You commonly communicate with peripherals like maybe a printer that you're printing the alarms to. So in those cases failure of the BPCS failure of the communication interface or failure of the peripherals shall not adversely impact the SIFs. How do you do that? I just spent a half hour telling you how you do that. So 11742 is exactly the same as 1141 it just specifically lists out some of the more common equipment that you communicate to.

Okay so let's move on to 11743. 11743 states the communication interface shall be sufficiently robust to withstand electromagnetic interference EMI including power surges without causing a dangerous failure of the SIS. Okay in clause 11743 did we say anything different than 11741? Failure of the communication interface shall not cause a dangerous failure of the SIS.

Again

11743 is a subset of 11741 because the EMI lobby has a lot of pull in the 61508 61511 committee and we basically called out one specific failure mode of the communication interface which would be electromagnetic interference. You know kind of old school going into your old PLC cabinet and clicking your radio causing everything to go haywire kind of good stuff that's that's the EMI that we're talking about. So yeah 11743 is not significantly different from 11741. It just talks about a specific failure mode that that communication interface can fail.

Does that mean you could ignore all the other failure modes? Absolutely not. We just drew special attention to EMI because somebody wanted to draw special attention to EMI.

## Clause 11.7.4.4: Grounding and Fiber Optics

All right. Finally the last clause in this section 11744. Again we're talking about communication interfaces. And it says the communication interface shall be suitable for communication between devices referenced to different electrical ground potentials. Okay now we have some meat. This is a hardcore hardware detailed design requirement that you need to think about. So I am by no means an expert in electrical design. As you know I am a chemical engineer not an electrical engineer. I know enough electrical engineering to be dangerous. I've been in industry for a long long time.

So you know what I learned in college is pretty much irrelevant to what I do today. And I have been in control system engineering since the get go. So I do know me some 4-20 milliamp DC let me tell you what and when you're designing not just a safety instrumented system but any electrical system any control system. Grounding is a really important thing especially as we go down the road of making our control signals very low power very low voltage. The lower power the lower voltage of the signal the more susceptible you are to signal failures signal noise caused by external effects.

Now one of the things that can cause signal errors and signal noise is something called the ground loop so your 4-20 milliamp signal your 24-volt DC signal is usually going to be carried on a couple thin pieces of wire. 18 gauge is very common. Some people are trying to get even a thinner strand of copper than that to communicate the signal back and forth between the house and the PLC.

Now those two wires are usually twisted together to minimize well let's go back to high school physics and you know that when electrons flow in a straight line they're going to create a magnetic field a circular magnetic field around them. So when we twist our wires together that's going to kind of negate the field a little bit because you're you've got electrons going in one direction on one wire the other direction in the other wire and we're hoping to cancel everything out. Now around that twisted pair you're going to have a kind of a braided copper blanket the shield.

And again this is further going to take any kind of magnetism that's going to move electrons around and we're going to move electrons in this sheath instead of allowing that signal to communicate further. Well you can kind of induce a little bit of a current in this sheath. So we want to go to ground. Now when you're going to ground you only want to ground in one place so ground a lot of people are going to and this sheath goes all the way through the wire. So for any segment you're going to want to ground your sheath at one end or the other end.

You generally don't want to ground in both places. Because if you ground in both places you can create something called a ground loop. And ground is not ground. What do I mean by that? Well the ground itself depending on how you do your grounding can have a potential. And if you're grounding a few hundred meters apart or a few football fields apart the ground at one place and the ground at the other place can have different potentials.

And if the ground has different potentials you are going to cause a current to flow through that grounding sheath from where you ground it in one place to where you ground it in another place. And as you're flowing your current through that shield guess what you're going to do? You're going to create a magnetic field which is going to cause a current in your signal loop. Now it might not be big but it can be changing and it can cause bad signals to occur. So when you're designing your systems think hard about how and where you're doing your grounding to minimize any ground potentials.

Now this clause has a note an informative note that says an alternate medium for example fiber optics might be required to do this. So the beautiful thing about fiber optics is it's light and light is not going to be impacted by shielding. So instead of our signal being moved with electrons our signals are being moved with photons. And photons are much more resilient to electromagnetic radiation electromagnetic noise. So that's something to consider.

It's a little bit more difficult to work with fiber optics than it is to work with copper wire but for a lot of big home run signals we're generally going to collect things in the fiber optics instead of sticking with copper which copper is at this point in time for newly designed systems going to be relegated to single signals single 4-20 milliamp signals from the field as soon as we're doing even remote IO we're starting to move to fiber to get those signals from one place to another instead of using copper wire which is susceptible to all these electromagnetic radiation anomalies including cosmic rays from outer space.

All right

## Episode Sign-Off and Vertigo Software Overview

with that who knew that I could talk for bloviate I think I think this is going to move into the territory of bloviating for so long on such a mundane topic. Next week we're going to talk about operator interfaces. The week after that maintenance and engineering interfaces. I will talk to you then.

Now that you've heard some insights on technical safety functional safety and the IEC 61511 standard let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our sis safety life cycle management tool vertigo vertigo is a comprehensive tool set for performing assessment calculations documenting and maintaining the design of safety instrumented systems.

Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation. Each safety function can then be analyzed by performing a SIL verification calculation complete with a collection of tools for optimizing ! designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities.

After the SIL verification calculations are defined you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments. Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries.

After the design phase you can even use Vertigo to track and document testing throughout the entire life of the facility Kenexis Vertigo is the most integrated easy to use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application.