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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E43 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 43: IEC 61511, Clause 11.7.3 (Maintenance and Engineering Interface Requirements)

—

## Episode Teaser: Maintenance Interface Restrictions

Many users of generic off-the-shelf PLC logic solvers for safety instrumented systems are shocked to find out that they're not allowed to have their maintenance and engineering interface plugged in while their process is in service.

## Introduction, Disclaimer, and Topic Overview

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.

## Defining the Maintenance and Engineering Interface

So the topic for today is we're continuing on in interfaces. So we're still in Clause 11.7 of the standard. And 11.7 is interfaces. We talked about general information. We talked about communication interfaces, which is general information. Those were clauses 11.71 and 11.74, respectively. And last time we had a discussion, we talked about operator interface requirements. That is 11.7.2. And now we are moving into the last section in Clause 11.7 that we want to discuss. And that is going to be maintenance and engineering interface requirements.

So 11.7.3, maintenance engineering interface requirements. So right out of the gate, let's start out by kind of explaining what exactly is it that we mean by a maintenance and engineering interface.

Now, most of the time, this is going to be another computer. And industry has evolved over the decades as to what this computer looks like, where it resides, who's allowed to use it, how you're allowed to use it, what do you do with it. So kind of, you know, getting into this. And I talked about this a little bit in the past couple episodes. I'm going to try not to belabor it too much.

But we're basically talking about another computer, usually a Windows computer, Windows operating system that is going to run a piece of software that will communicate with the SIS logic solver, allowing you to do a wide variety of tasks. But the primary one of them is the ability to write the code that the safety PLC is going to run and to upload that code and download that code and generally allow you to view what's going on in the SIS logic solver and do various configuration, with configuration being kind of a subset of programming, but not exactly the same.

So now I say that this is usually a PC. It's usually another computer, another personal computer. But that's not always the case, especially with older systems. With older systems, you're going to actually have hardware devices that are referred to as programming panels. So back in the day, you used to have kind of a hardwired device that you write your program in, and then you upload and download the program from that device. And that device, it is not a general purpose PC.

It's a purpose-built piece of electronics that is dedicated to the function of being the maintenance and engineering interface. That's all that it does. That's all the functionality that it has. And the graphic displays on these things are kind of rough and ready, but just kind of an old-school panel that allows you to program stuff.

But those are few and far between. I think I haven't seen a programming panel probably in a good 20 years, so probably not worth discussing. But they are out there. You may run into them. Now, most of the time, you're going to be on a Windows operating PC.

## Future of Windows and Mobile Operating Systems

You know, here in Kenexis, you know, Sean Cunningham, the Director of Software Development, and I have a lot of discussions about the future of desktop computers and the future of Microsoft. I am a strong proponent of Microsoft on the one hand. Their Office 365 cloud-based system, so, you know, the Office productivity apps and all the associated communication tools, I don't see being displaced by Google. I don't see them being displaced entirely, anyway. I mean, there are different ecosystems. But they're positioned very well in that market.

And for those of you that don't know, so, Kenexis Integrated Safety Suite, our software suite, is built on the Microsoft Azure platform. So, cloud-based computing infrastructure, Microsoft, in our opinion, is head and shoulders above everyone else.

But where things get a little bit sticky is what is the future of Windows? Now, most people have trouble peering too far into the future. But at this point in time, I think, and I'm going to, you know, make a weird prediction here, I think that Microsoft has lost the game, lost the battle for the user experience. So, Microsoft has, for the longest time, been the primary operating system that you're going to use to run your desktop computers and your laptop computers. But they kind of slipped and fell in the mobile market.

And what I think, I can get some agreement with kind of the high-tech guys at Kenexis, is that mobile operating systems are going to become the only operating systems in the near future. So, I am, I'm on my iPad right now doing my work. I do the great preponderance of my work on an iPhone or an iPad and only bust out a Windows machine, or honestly, I'll probably end up using the Mac OS for most purposes. But those kind of traditional desktop operating systems, I only use every once in a while when I have a use case that can't be done on mobile. And that is shrinking more and more and more.

So, boy, I went kind of way out on a weird topic. But I am expecting that the maintenance and engineering interfaces for your safety PLCs are going to more and more show up on Android. Maybe Mac OS, but Mac OS is not. It's more of a pure consumer play. Whereas Android is the Windows of the mobile market in that it is open and more configurable, more usable for a lot of different applications.

So, we are Christmas week in 2025. And Ed Marszal is making a prediction that five years from now, all of your maintenance and engineering interfaces are going to run on a mobile environment and probably going to be Android. And Windows desktop is going to get relegated further and further into the past as an archaic way of doing things, especially now that Google has made kind of some pretty big inroads into creating…

I mean, they've had Chromebook for a long time, but just an Android desktop and Android laptop operating system where you're just going to basically start and finish everything in Android and there's no reason for another environment. And, you know, with the advent of the foldable phones, even right now, when I'm in the office, most of the time I just take my iPad and I'll plug it into a large Apple Studio monitor and do all my work on there. So, I got, you know, keyboard, mouse, big giant monitor, but I'm kind of basically plugged into a phone, a big phone, at the end of the day.

So, that's where I see the maintenance and engineering interfaces going.

## PLC Configuration and Programming Languages

But today, you're, for the most part, going to be in a Windows PC environment.

Now, what is running on that Windows PC? Well, there's going to be an application that is the maintenance and engineering interface. So, what are we going to do in this maintenance and engineering interface? We are, number one, going to configure the PLC, the PES, Programmable Electronic System Logic Solver. And that configuration is basically defining what the landscape is, defining what the size and shape and attributes of the system are. So, how many CPUs do I have? What communication cards do I have? What I.O. points do I have? And for all those I.O. points, what type of I.O. is it?

What instrument is going to land in that rack slot channel?

Is a very common term that you'll hear for configuration. Depending on what the device that you have is, that configuration process could also include things like converting from your 8-bit, 10-bit, 12-bit, 16-bit A to D conversion into engineering units. Whereas, some software, some maintenance and engineering interfaces require you to do the conversion from counts to engineering units in the application program. I think the more sophisticated ones are actually doing that as part of the configuration process. So, kind of a big picture configuration is kind of laying out your I.O.

Then, once you have your I.O., you're going to write your application program. Most equipment vendors are following the IEC 1131, or is it a 1311? Boy, I probably should have done some research on that before I started this. I think it's 1131. Anyway, that is the standard that defines programming languages for industrial control processes, for programmable logic solvers.

And those languages are ladder logic, which is kind of becoming a little bit of a dinosaur. I hate to say that because it was the new up-and-coming technique when I graduated from college back there in 92. But it's kind of mimicking what you would do in a hardwired system, which, when you were replacing hardwired systems, made a lot of sense. But more and more, it's kind of an archaic way of doing things. It's, you know, it's like writing in cursive. It's kind of cool that you know how to do it, but it's really kind of societally obsolete. But it will be with us for the long haul.

No reason to get rid of it. The most popular programming technique, hands down, is going to be function block diagrams, where you're basically chasing a signal through a system, and then there are blocks that do different logical tasks to those inputs and outputs. You're going to do logic blocks. There are going to be math blocks. You can write your own custom blocks. So it's pretty simple, and a lot of the equipment vendors have developed a lot of their own blocks.

So you can have some, you can, like, wire in three analog inputs, and they will have a two-out-of-three voter block that does, handles all the bad PVs, all the bypasses, all the degradation, depending on what state you're in. So the function block diagrams, again, far and away the most common these days.

Now, for those of you that are doing a lot of batch work, even if it's something as simple as starting up a fired heater, the best way to get that done in the 1131 paradigm is going to be with sequential function charts, which just kind of have logic gates that allow you to step from sequence to sequence to sequence. And inside each step, it has different representations for what the status of variables are and what actions are going on in that step, sequential function charts.

The last one is going to be more of a traditional programming language, and that would be structured text. Structured text is going to work pretty much, you know, the first programming I ever did was in QBasic in early, no, I take that back. The Basic, I had a TI-99-4A. That was my first computer. So whatever version of Basic TI was running back then, very kind of simple, close to English, sequential execution. But it allows you to do a lot of things.

But at the same time, all of the languages that I just discussed are your limited variability languages. They don't allow you to do a lot with the computer. They don't allow you to allocate memory, deallocate memory. They do, technically structured text would allow you to get yourself into an infinite loop. But the equipment vendors kind of know all the things that you can do wrong, like getting yourself into an infinite loop, and will automatically break it for you.

Or throw up error message, and or throw up error messages saying that you've entered into a loop that you're not going to come out of or you've timed out. And it will kind of stop execution of the loop and go into the next PLC scan. And that would be a dangerous detected failure that it would flag and possibly even shut your plant down if you got into those situations. So you're going to configure your system.

## Connecting to the PLC and Upload Download Activities

You're going to write your program. Then you're going to connect to the device itself. So when you're connecting to the device itself, that is going to be with some sort of electronic connection.

Now, I've done, you know, back in the 90s, man, I've done PLCs where we connected the PC to the PLC with a big, you know, one and a half inch thick RS-232 ribbon cable. Then we kind of improved to RS-485, which, you know, at least we had kind of more of a tighter multi-pin connection, a little bit better engineered. The communication was better. And honestly, RS-485 was the thing for a long time, a decade, decade and a half. But what you're doing is you're taking your computer out to the field or wherever the PLC is, and you're literally plugging it in.

So I think I mentioned a couple weeks ago a portable computer, which is where I started at UOP, which is something that kind of had a handle on it, and you can unfold it into a computer. But you don't want to set this bad boy on your lap. It's hot. It's heavy. It is not a laptop. It's definitely not a notebook. And it's certainly not an Android phone. But you physically connect it, and then you can do a few things.

You can upload a program into the PLC. You can download the program that's running in the PLC back to your maintenance and engineering interface. And you can do maintenance activities, including forcing the program into certain states. So if you think about ladder logic, you've got coils and you've got contacts. So a contact is basically just kind of super oversimplify it, and a contact would be an input. A coil would be an output. And you can kind of freeze the status of a coil so that it's always energized or always de-energized.

So that's like kind of forcing an output to be true or false, or you could force an input to be true or false, and you can kind of troubleshoot what you're doing by manipulating things in the program, by forcing them.

And then there's also the ability to kind of look at the diagnostics. What scan time are we getting? How much of my RAM is being used? How much of my fixed memory is being consumed by the program that's running in the application? And just a variety of diagnostics, even up to, you know, what temperature is the CPU running at? So there's a lot of functionality in that maintenance and engineering interface.

## Cybersecurity Risk: Man-in-the-Middle Attack Case Study

And honestly, as we kind of, as we start going into what the standard says about these devices, it's actually a very critical piece of equipment because if it does something wrong, you can have a lot, you could basically generate a lot of dangerous failures through the maintenance and engineering interface.

So we need to be really careful about how they're engineered, how they're installed, how they're designed, so that we can't inject failures into the safety instrumented system through the maintenance and engineering interface.

And also, many of you are familiar with an exploit of a triple redundant safety PLC. It happened in the Middle East, I'm going to say early 2020s, where some malware was injected into a safety PLC through the maintenance and engineering interface.

So how this hack worked was that there was a program that was running on the same computer as the maintenance and engineering interface, and it learned what was being uploaded and downloaded to the safety PLC, and it worked as the man in the middle.

So in the man in the middle attack, you basically, the maintenance and engineering interface thinks it's talking to the safety PLC, the safety PLC thinks it's talking to the maintenance and engineering interface, but really both of them are talking to the man in the middle, and in the beginning, the man in the middle is just basically taking the data and passing it forward.

But eventually, what it has the ability to do is learn what's being transferred, and then, with the help of our, you know, nefarious hackers, they can kind of insert extra code in the middle that will, you know, have a negative effect on the system. So basically, the maintenance and engineering interface was trying to upload to the safety PLC, but it was uploading to the man in the middle. In the man in the middle stage, some additional code was being injected, which was supposed to cause a dangerous state, a hacked state of the process.

But of course, this is a very sophisticated PLC, so it did its checksum analysis, and at the safety PLC, it's like, okay, the data that I received doesn't match what the safety PLC sent me. And this is only because it was a very sophisticated SIL 3 certified device where the logic solver vendor went to a lot of trouble to make sure that a failure in the maintenance and engineering interface or a failure in the communications between the maintenance and engineering interface and the safety PLC cannot result in a dangerous failure.

And this has to do a lot with the diagnostics of the upload process, making sure that what we intended to upload is in fact what we uploaded. Okay.

And your good SIL 3 rated safety PLCs are all probably going to have this handled very well. But what if you're using a general purpose off the shelf PLC, are they certified? Do you know for sure that they can't inject a failure into your safety PLC? What if it's a SIL 1 rated PLC? Well, you don't see many of those, but you do see a lot of SIL 2 rated PLCs.

## Clause 11.7.3.1: MEI Failure Shall Not Affect SIFs

Okay. With that, now we're finally, after about 20 minutes, going to get into the first clause of the standard, of this section of the standard, 11.7.3.1 states, first sentence, the design of the SIS maintenance engineering interface shall ensure that any failure of this device shall not adversely affect the ability of the SIS to carry out the required SIFs. Boom. Okay. And most of your, you know, really high quality SIL 3 rated PLCs are going to meet this requirement out of the box.

You know this by looking at the safety manual for the product and the safety manual will tell you when and how you're allowed to use the device. And a lot of these safety manuals will specifically tell you that you are allowed to leave your maintenance and engineering interface plugged in and you're allowed to use the software. And in some cases you might even be allowed to upload and download software while the plant is online and running. So if you are not sure, go into your safety manual and confirm that.

If you can't find it in your safety manual, make sure to talk to your equipment vendor but get everything on paper.

Now there are some certified devices that don't allow you to do this. So if, so, so, what do I do? So if I'm using a general purpose off the shelf PLC and I don't know whether an upload download is guaranteed not to inject a dangerous failure, what do I do? Well, that is in sentence two of clause 11731 which states, this may require disconnecting of maintenance and engineering interfaces such as programming panels during normal SIS operation. So there's the hammer. There is the ugly statement that nobody wants to think about, nobody wants to know about. It gets disregarded all the time.

People are ignoring it and hoping for the best, hoping nothing bad happens, hoping that no hacker has put a man in the middle attack onto their maintenance and engineering interface.

Basically, what this clause is saying is if my equipment vendor didn't guarantee that I can't inject a failure into my SIS, then basically I'm not allowed to have it plugged in while the plant is online and running. Now, that is all that the standard says. I think practically speaking, it's even more onerous and even more cumbersome than that. So, how do I know that the process of uploading a program into my safety PLC did not inject a dangerous failure into the PLC? Well, the only way to know that for sure is to test it.

So, think about all the things that your safety PLC is supposed to do. Think about that pre-startup acceptance test. Think about that site acceptance test. What you really need to do after every change of your software, after every time you plug that maintenance and engineering interface in, you should test your PLC like it's an SAT, like it's a PSAT, with the maintenance and engineering interface disconnected, you now need to basically put that PLC through its paces and make sure that it does what it's supposed to do.

This is really the only way to guarantee that you didn't inject a failure during that process when you uploaded the new program.

So, that said, when you upload a new program, you should be testing it anyway. There's no excuse for not testing the application code as it lands in the hardware. But what you're probably hoping for is that the testing would be limited to just the little bits of code that you changed, which is what most people do. I mean, it's universal. If you don't, that's kind of really you're not committing to all your responsibilities if you don't do that. But in this case, you theoretically should be testing everything. Maybe with a small PLC with a few functions, that's a reasonable thing.

But if you've got a PLC that's got a few hundred IO points, difficult.

This is also why for the more sophisticated operating companies that are out there, you're going to want to do this using a simulator. So the more sophisticated operating companies will have a test PLC that they can load the software into. And not only do they have a test PLC hardware, they're going to have testing software that's going to basically create an array of inputs. And it's going to read an array of outputs to make sure that the program is doing what it's supposed to be doing.

So there, well, you know, at least you've tested the program as exported, but you're testing it in the test environment as opposed to the live environment. So big deal there. So clause

11731, this kind of, you know, this does really make a very big case for using that SIL3 certified safety PLC to make sure that you don't have to disconnect the maintenance and engineering interface when the process isn't in use. Now, you might think, well, you know, I've got a SIL2 certified PLC. It's probably going to be okay, right? Right? Don't be so sure. My warning right out of the gate to you is always read the safety manual because the safety manual is going to tell you what you need to know about this topic.

And there are a lot of the big name SIL2 rated safety PLCs that if you dig into the safety manual, it will clearly tell you, it will say in no uncertain terms, do not leave the maintenance and engineering interface plugged in while your process under control, the equipment under control is in service. So check for that line. It's basically just a quick review of your safety manual to determine whether or not you're going to be allowed to do this. And once again, I've already talked about this earlier in clause 11.2, read those safety manuals before you buy the product.

Because at this point in time, if you've bought the PLC and programmed it and installed it, and now you realize that you're not allowed to leave the maintenance and engineering interface plugged in, this is a bad time to find out about this, my friend. This is something we wanted to know a long time ago, so read those safety manuals.

## Clause 11.7.3.2: Required MEI Functions and Access Security

All right, now clause 11.732 is written in a very strange way, and there's going to be five bullet points, but the first sentence of the clause says 11.732, the maintenance engineering interface shall provide the following functions with access security protection to each.

So the way this kind of reads when you read the first sentence is, okay, this is the stuff that needs access security. Well, no. Actually, how this clause is written is this clause is telling you the stuff that the maintenance and engineering interface is supposed to do, period. Period. And oh, by the way, if you're going into the maintenance and engineering interface, you should have access security to access the maintenance and engineering interface. It's not like some stuff in the interface requires security, some stuff doesn't. It all requires security.

And I talked about what that security looks like last week when I talked about the operator interface. You know, it's, you know, programming is going to be in that same place. So you're going to need your badge to get in the facility, your badge to get in the room, your Azure AD password to get on the computer, the maintenance and engineering interface password to get into the program. And now you can communicate with the PLC, with the logic solver CPUs over a network, over a control network that is secured.

Usually you're going to be running TCP IP Ethernet from that room back out to the machine. So it's secured. Now what are the five things that the standard tells you need to do?

Bullet point one, SIS mode of operation, program, data, means of disabling alarm communication, test, bypass, maintenance. So basically you're going to communicate with the safety PLC, CPU, and do a variety of testing and bypassing and maintenance activity through that device. And also you need to know to be able to communicate the mode of operation. And it says program and data in there. So what is the program that's going to be run? What is the data that the program is going to use?

Bullet point number two, you need to provide access or provide the following functions, SIS diagnostics, voting, and fault handling services. So any failures that are detected, that kind of showing what those failures are is something that you should be able to see from the maintenance and engineering interface. And you should see the status of voting. So if I've got a two out of three vote and one is voting for, two are voting against, I've got a mismatch. That type of comparison diagnostic is something I'm going to want to see.

And I'm going to want to be able to see that through the maintenance and engineering interface.

Alright, bullet point three, you are going to need it to be able to add, delete, or modify application program. So change the program, upload a new program, delete the program that's running on the machine, add a new one, download, upload, all that stuff needs to be done by maintenance and engineering interface.

Bullet point four, you need to have data necessary to troubleshoot the SIS. So, again, this is kind of a corollary to point one and two, basically. You know, fault handling services, knowing what the status of all the inputs is, what all the status of all the outputs are, whether signals are out of range, whether detected failures are present, all that information needs to show up in the maintenance and engineering interface.

And then, finally, bullet point number five of 11732 is where bypasses are required. They should be installed such that alarms and manual shutdown facilities are not disabled. This is a truly, truly bizarre location for this bit of information.

So, let me unpack what the clause is telling you first. So, if I can put my transmitter into bypass to where when it goes into the alarm state, it will not shut down the plant, the fact that you put it into the alarms shouldn't cause you to go into, or it shouldn't prevent the alarms from being enunciated. and that's definitely a topic of contention with other committees, specifically the alarm rationalization people.

When you say that you're going to enunciate an alarm for a device that's in bypass, you can actually see their hair catch on fire. So, that's, you know, kind of like the epitome of a nuisance alarm. We're saying yeah, we definitely want those.

So, don't let the bypasses affect the alarms, and don't let bypasses affect manual shutdown switches. So, if I bypass an output in the safety PLC, well, when I hit my manual switch, the shutdown should still actually work, even though I have my output and bypass. bypasses, so those, it's kind of a weird location to have that related to maintenance and engineering interface, because it's a bigger picture deal.

It should probably be in operating procedures and maintenance procedures and test procedures where that information resides, where we talk about how to perform testing and how to perform bypasses, kind of clause 15 area, is where I believe that that information should reside, and the information is kind of controversial, because the alarm people are going to go ballistic when they find out that we are enunciating alarms that the operator is not supposed to respond to.

So,

I'm just going to leave that where it is, let it simmer, think about it for a while. You can decide what you want to do with that, but what we all have to acknowledge is that that clause is here in the standard and we're going

*[inaudible]*

resolve it in our design processes.

## Clause 11.7.3.3: MEI Must Not Be Operator Interface

Okay, two more clauses in this section. 11-7-3-3 states, the maintenance engineering interface shall not be used as the operator interface. Hmm, you would think this would go without saying.

I've seen it done. I have seen a small plant in rural, I think it was either rural South Carolina or rural Georgia, somewhere on the South Carolina-Georgia border up toward the mountains, you know, maybe the chemical plant used to be an old moonshine still, that part of the country, but in this batch production process, in order to go from step one to step two, their procedure was to open the maintenance and engineering interface and force one of the contacts in a rung of ladder logic into the true state in order to move from step one to step two.

this is very, very, very bad form. That kind of stuff should, optimally, we should program the PLC so that the operator doesn't need to push any buttons. If you remember the discussion from last week, that's definitely the objective. But if they actually, absolutely, unequivocally, do need to push buttons, maybe they should be hardwired buttons. Maybe at a minimum they should be in the operator interface.

using the approved methods of communicating data from the operator interface into the maintenance interface. So those are all things to consider.

Bottom line here, you're not allowed to use the maintenance and engineering interface as the operating interface. And if you think people won't do it, you're wrong because I've seen it. So keep your eye out for this. Now, hopefully you won't run into it. I've been doing this for a long time with a varied client-based so I have seen a variety of things that I hope none of you ever have to see.

## Clause 11.7.4.3: Read-Write Access Control Requirements

All right, finally, last clause in section 11.7 that we're going to talk about is 11.7.4.3, which states, enabling and disabling read-write access shall be carried out only by a configuration management process using the maintenance and engineering interface with appropriate documentation and security measures such as authentication and user secure channels.

That's a lot. Now, enabling and disabling read-write access. So, what do we mean by that? You can basically set your safety PLC to be read-only, which means that the safety PLC will only send data out but not allow data to come in. Now, the most common example of this is some PLCs have a physical switch on them that has kind of several settings. There will be a run setting, a program setting, a standby setting, and maybe an off setting. So, in the standby setting, the PLC isn't running at all.

In the program setting, that's when you're allowed to upload and download information, and then there's a run setting for when it's actually running. And when you're in the run setting, if you try to upload or download software, it simply won't let you do it. It'll force you to go back into the program mode to be able to upload or download information into the PLC.

So, what are the strengths and limitations of this? Well, number one, there's an extra guard against that cyber attack that basically says, okay, only when the switch is in this position am I going to allow uploads and downloads, and I'm only going to allow that when the plants shut down for a turnaround and I'm doing an upload.

well, there's also a downside to this. Now, if you're in a plant where you can walk over the PLC, this might not be as big of a deal, but what if I have 100 PLCs in an oil and gas production field, and I need to get into a truck and drive an hour to get to that PLC to put it into a, the switch into a position where I can upload and download software. Okay, and a lot of these PLCs, when they're in the program mode, they're still running. It's not that they stopped running. It's just that that's the position you need to be in to be allowed to upload and download information.

So, what if it's really onerous to get out there?

Now, also, for one of these remote fields that I'm familiar with, the gas is that they're pulling out of the ground. They're pulling out of the ground natural gas with a little bit of hydrogen sulfide. Let's say 10 to 20% hydrogen sulfide. Hydrogen sulfide, which is immediately dangerous to life and health at 100 parts per million. They're taking 10 to 20% by volume out of the ground.

So, basically, to send someone out to the field to flip a switch, you are risking them being exposed to massive quantities of toxic gases. So, somebody's got to do a little bit of a risk analysis game to say, is there a higher risk associated with sending someone physically out to the field versus leaving things potentially open to cyber attack? And my experience has been more and more, the thing that we are most worried about is sending people out to the field.

And also, there are other ways to secure that read-write access. Remember how many barriers that a person had to get through to be able to get to that maintenance and engineering interface in the first place. Making sure that that programming network is secure. It's not the same network that's used for other purposes. So, there are a lot of ways to secure that read-write access other than forcing someone to go out to the field.

But then again, if you have a relatively benign plant, it's a small plant, walking from your office to the PLC takes you about 45 seconds, well, you might want to just make the decision to always leave things in the run position instead of the program position.

## Wrap-Up and Clause 11.8 Preview

Alright, with that, we have now gone over interface devices to our heart's content. Well, to my heart's content. Maybe you want to hear more about it, let me know. Feel free to send me an email at any time. But I think everybody is ready to move on to the next topic.

Now, the next topic we're going to discuss, well, we've been discussing it a lot, but we're going to discuss it in Clause 11. We're also going to discuss it in several more clauses, primarily Clause 15, and that's going to be maintenance and testing. Now,

Clause 11 is all about the design of the plant as opposed to actually operating it or maintaining it. but what we're going to learn next week when we get into Clause 11. Now, can I talk? Yeah, I should probably be able to bang out Clause 11.8 all in one sitting. Let's slate that for being on the agenda for next week, although it is Christmas week here. And, well, you know what? I might actually bang this one out before I leave for vacation. But Clause 11.8 is going to be about how do I design my plant and design my SIS. That's right, design my plant. It might be more than just the SIS.

You might need to actually include piping and valving to allow you to properly test your SIS, especially if you want to do it online. And we're going to have a lot more discussion of that when we get to Clause 11.8 next week. Talk to you then.

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

*[inaudible]*

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.