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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E50 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 50: IEC 61511, Clause 12.3 (Application Program Design)

—

## Introduction and Disclaimer

Just to clarify, the standard has a section on application program design and another section on implementation of the design that you created. Sounds a bit much. 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.

## Clause 12.3 Overview: Software History and Structure

Okay, so the topic of discussion for today is going to be clause 12.3. We're slogging through the software bit. And just kind of a little bit of a refresher. This software bit did not exist in the original functional safety standard, the 1996 version of ISA 84. It's something new that was introduced when it was internationalized into IEC 61511 in 2003.

It got simplified in the 2016 version of the standard, and as a committee member, let me tell you, it is getting simplified again when the next version of the standard is released. So, again, we're just laying out some requirements that are specific to how the software needs to be written. And for those of us that kind of did systems integration work, actual implementation work in the past. The software piece of it is just part and parcel of the design. I mean, in a systems integration firm, it's very likely that the person writing the code also wrote the specs.

They were probably pulling wire and labeling wires and putting PLC items into racks. So it's not like a dedicated software company is writing software for your safety PLC. It's just part of your project for the most part. And that's why we're doing a lot of the simplifications as part of the standards committee because what we had in 2003 was just too much. And what we have in 2016 version also just a bit too much. So we're trying to simplify things, make it a little bit more practical for the way things actually get done in industry instead of an equipment vendor idealized.

I've got a group of software people that do nothing but software. So, anyway, let me kind of step back a little bit into what is contained in this clause. So, clause 12, we started out with general requirements, spent a couple weeks talking about 12.2, which is general requirements. Now we're moving into 12.3, which is application program design. Then after that, we're going to go into 12.4 which is application program implementation. And then after that there are going to be requirements for application program verification.

Oh, we're not done yet. 12.6 is requirements for application program methodology and tools. And 12, 3, and 12.4 are a lot of the sticking point because in the real world, forget about the ideal that some of the standards committee members might have had. There is no dedicated software group for whom you need to prepare a specification for what the software is and how the software needs to be written, and then let them do the actual coding and then have someone else go back and do the verification testing and review.

There is no group of people that are just writing the application code on safety PLCs. That's crazy.

## AI Coding Tools and the Future of Full-Stack Engineering

It was crazy talk in the past, but I have not yet tried to get clawed code to do anything with a safety PLC, do anything in ladder logic.

I am certain Claude code will be able to do an excellent job of it. With a little bit of a caveat that the coding large language models work best with plain text, and a lot of the programming techniques that I just discussed that are going to be in the low-vilt variability language are going to fall into the category of visual as opposed to text-based. So that makes it a little bit trickier. But anything that you can draw in a diagram you can describe in text.

So yeah, do I see large language models generating code by kind of having a starting point of generating text and having that text turned into function block diagrams and ladder logic, it's inevitable. It is absolutely inevitable, which is another Another reason that you're backing away from the concept of kind of siloing everything and saying, I've got this programmer silo, I got this specification engineer silo, I got this verification engineer silo, validation engineer. I probably should have said.

And, you know, if I could go on a little bit of a side note here, if there are any younger people that are listening to this podcast, I'm here in my mid-50s, so you know, even so, I think I'm adopting AI tools and techniques faster than Gen Z and definitely the millennials, but if you're on the younger side and you're looking at your career trajectory, becoming full stack is more and more important. Now, what do I mean by full stack? Full stack is something that it's a term that's going to get tossed around out in Silicon Valley, in the venture capital world, in the programming world.

When you are full stack, that means that you can write every piece of the code as opposed to a user interface specialist or a database specialist or a data transfer specialist, an API specialist. Those specialties are going to be subsumed by the large language models and large language model AI agents who are going to do the work.

So, more and more understanding the entire big picture and how one piece fits to the other, and being able to basically start with a cause and effect diagram and end up at visual at finished code is absolutely more essential than it's ever been, and it's going to be more and more essential as we get into the future. So, uh, full stack engineer, and that full stack applies to everything, not just coding. It applies to safety instrumented system design. Being able to go from analyzing the risk of the plant all the way through calculations is going to become more and more important.

And honestly, that's what I've been seeing. So, you know, how Kenexis is highly involved in ISA's training and certification program. And we broke it into pieces for specialties to allow kind of an upfront SIL selection specialty versus a back-end SIL verification specialty. But everybody is getting certified on the whole stack. So that's kind of lending credence even where we're at right now.

Okay, so I kind of went off on a little bit of a tangent here, giving out career advice because the way that the standard was written in 2004 and a lot of it carried over into the 2016 version for software is exactly the opposite of full stack. It is very, very narrow. And this is where 12, 3, 12, 4, 12, 5 are kind of all getting smushed back together by one full stack engineer doing the whole kit instead of breaking things into pieces.

## Application Program Design: Big Picture and Clause 12.3.1

So, before I delve into the requirements of clause 12.3, let me kind of give a big picture of what it is. So in clause 12, we need to write an application program. What does this presuppose and pre-assume?

This presupposes and pre-assumes that the hardware design is already laid out. So we know what the inputs are, we know what the outputs are, we know their rack slot channel, we know what I.O. cards we're using, we know what CPU we're using. And that is almost universally going to translate into what is the maintenance and engineering interface where the application program engineers will be actually writing their code. So we've got all the hardware laid out, we've got our maintenance and engineering interface. We're going to turn it on and write the code.

Now you're probably thinking, well, this is pretty easy. I go back to my safety requirement specifications and I configure all the I/O points. I lay out, you know, rack, slot, channel that the wires land, make sure that matches up with the program. And then I go through the cause and effect diagram. And, you know, if this happens, then that happens. What's the big deal, Ed? Well, the big deal is we've got pages and pages of requirements that you need to meet while you're doing that.

And 12.3 is basically putting together a description of what the program is supposed to do, and then 12.4 is actually doing it. So it's broken down into the two phrases of design and implementation. Hmm, did these need to be split out? Are we going to simplify this dramatically in the next version of the standard? Well, the answers are no and yes, respectively. But we have what we have, so let's go ahead and delve into it. And as we're doing that, we're going to kind of keep our eye on the higher level Level concepts. Okay, so let's go ahead and delve into the design part.

So 12.3 is design. Clause 1231 states: an application program design shall address all SIS logic, including all operating modes for each SIF. Okay, so you need to create a design, and that design needs to include all of the logic being executed by the SIS. Hmm, all the logic, that's kind of tricky because there's stuff that The needs to happen with regards to the SIS. You know, if this level goes high, then close the inlet valve. But there's also handling alarms. There's also first out logic might show up inside your safety PLC there are bypasses. there's handling bad PVs.

There's a lot more to it than just if this, then that. So all of that needs to be included. And not only does all of it need to be included, it needs to be included for every process mode. Now, a lot of you in the big petro cam refining world have basically one mode, the plant is running. But if you're in a more complex plant or if you're in like a batch plant, the safety function might behave differently in step one than it does in step 10 than it does in step 20. So all that needs to be specced out. Alright, so 1231 says we need a design.

Now, at this point in time, I might pause a little bit because the choice of the word design is intentionally vague in order to escape committee meetings. So I know I've told you this before, when multiple people in a committee don't agree on something, the language gets parsed and the wording gets watered down to where everybody can read the statement and believe it means what they want it to believe. Hear me now, believe me later, it's a truth of the standards world.

Now, what is design meaning? Well, design means. Well, we didn't say an application program design specification because that would imply that there needs to be a design specification document. So, this design, I'm going to leave this to you because at the standards committee end, this ultimately is intentionally vague. There is the group that says absolutely, I need a design spec document that's tracked, reviewed, approved, part of all of the verification, validation, bloobity, blobbity, bloobity.

And then there are other people that are like, well, this design is a mental construct that allows me to get from my SRS cause and effect and general requirements and convert that into code. So, design, I will let you meet figure out what that means to you in your own life. I sound kind of like a philosopher here.

## Clauses 12.3.2 and 12.3.3: SRS Input and Functional Safety Assessment

All right, 1232. The input to the application program design shall be the SRS, including the application program requirements. Okay. And then there's a comma here. It refers you back to clause 10. So

I'm going to design in accordance with the SRS. No kidding. And they felt the need to say that the SRS needs to include application program requirements. Well, that's clearly stated in clause 10, but all right, let's keep re-emphasizing things. Again, in these standards committees, people that feel strongly about something want, to put it into like you know, every sentence. Don't get me started on the EMI RMI O or RFI lobby. Hey, it's just a failure mode, it's no more special than any other failure mode. Okay, I digress. I'm getting a little bit off topic here.

Okay, so the input shall be the SRS.

The SRS architecture C clause 11. So we need to know how the SRS is architected, meaning we need to know all the voting arrangements, we need to know the test intervals. We need to know bypasses, resets, all that information. And you know, the SIS architecture in terms of what equipment, what voting arrangements, and such, technically that happens in clause 11, but again, I don't want anyone to get dogmatic about what an SRS is. That information should be part and parcel of the SRS package, regardless of what the standard calls that stage.

There is a package of information that's going to go to the person who's writing the program that's going to include all of the information that was generated during the SIL verification conceptual design part of the package. And if you're using a great, great top-of-the-line tool for managing your SIS safety lifecycle, like Vertigo from Kenexis, or maybe I should drop a little Easter egg to say that in the future it's just going to be called Kenexis SIS. We're going to be dropping the vertigo name, but that's a discussion for another day.

All right, so we need the SIS architecture and we need the means and the tools for developing the application program design. The means and the tools for developing the application program design. Okay, there you get a parenthetical that's going to push you out to 12.6, which I think we're probably going to get to 12.6 still today, but we might not, we might run out of time. I'm just going to press along here. Okay. The last sentence in clause 1232 says the application program design shall be consistent and traceable back to the SRS. Abso freakingly lute.

Everything that you do during the program phase should be able to be traceable back to your safety requirements specifications. Okay. All right.

Let's move on into clause 1233. And clause 1233, one statement, one sentence, says the application program design shall allow an assessment of functional safety to be carried out. Oh, now we're gonna get a little bit tricky. Functional safety assessment is one of the most misinterpreted, misunderstood, yet at the same time ambiguous and ephemeral. You like that? That's put that word in today's word of the day dictionary. Ephemeral. It's one of those things that's kind of a concept that says, well, you need to ensure that functional safety has been achieved. Great.

What the hell does that actually mean? What steps do I need to undertake? Well, you know, we're going to be loose and ambiguous and ephemeral, and just say you need to verify that functional safety has been achieved. So you're responsible for an outcome without me telling you what the steps, tools, and techniques are that are required to get to that outcome. Another thing, I've been doing some thinking about functional safety assessments later. As I mentioned during the functional safety assessment portion of the podcast, I do consider it to be an audit of a project.

So we're going to be doing spot checking of the work that was executed to make sure that it was done in accordance with the requirements, specifically the functional safety planning requirements for that phase of the activity.

So the design, whatever the design ends up, however it ends up looking, that needs to mesh up with how you're doing your functional safety assessment so that when I execute my functional safety assessment protocol, which I highly recommend doing that in the free Kenexis open audit software, where you can download a copy of a functional safety assessment protocol from our website, or is it on our website? I think it's on our website. If you can't find it, email me. You know how to catch me.

## Clause 12.3.4 Overview and Module Decomposition

All right, moving on, the next clause, and I hate to call it a clause because it contains so much information. This is another one of those that is on par with clause 1032 for safety requirement specification because there's a sentence and then there is a gynormous list of bullets, and man, I'm thinking that I should probably number these bullets because there are so many of them, but I'm going to try not doing the numbering yet and come back to that. But all right, let's begin.

All right. So, clause 1234 begins by saying, the application program design and its decomposition into modules, if applicable, shall address how the requirements are to be implemented, including the following as appropriate. And then we start stacking a gigantic pile of bullet points. So the application program shall address how to require implement or how to implement requirements. Okay. Okay, got it. Understood.

We're going to explain how to implement requirements. And a little bit of a interesting high point aside on this is that it talks about the application program, but it also talks about decomposition into modules. So, for those of you that are familiar with software programming, you know that you're going to break an overall software program into a bunch of different subroutines, and those subroutines are going to get called in many different places in the software application.

So we're kind of breaking the overall design into little neat standalone chunks that are going to be easier to write, easier to test, easier to document.

And it's not a bad approach for SIS design, but at the same time, how do you decompose ladder logic into multiple modules. How do you decompose function block diagrams into multiple modules? Well, it just so happens with function block diagrams, depending on who your vendor is of your maintenance and engineering interface. That's not really hard to do. You basically create a module or a subroutine, do all your work in it, and then you can call that subroutine from other modules.

So, just kind of a quick example: you can write your own two out of three voter module and then have the software call that module in multiple locations.

Now, most of the time, there's no reason for you to create modules as an end user because you're equipment vendor, especially if you're dealing with a really high-quality SIL3 certified type PLC, all of the modules that you're going to need to do your SIS design Design have pretty much already been done for you by the equipment vendor. And you're just basically cobbling together the different pieces, parts from the equipment vendor's library of modules. Okay, so that's the difference between the program as a whole and that whole decomposition into modules.

Most of you, you're just going to be writing a program, you're going to be using the equipment vendor subroutines and modules to actually do things like voters and such. Okay, so now let's get into some of the requirements that you need to design.

## Clause 12.3.4 Bullets A-C: Safety Functions, Components, and Timing

All right, bullet point A, and hopefully I'm going to keep track of this. Bullet point A states the functions that enable the process to achieve or maintain a safe state. Okay, so you're going to need to write code that executes your safety functions. If this input triggers, this output triggers. Okay? Seems pretty straightforward. Something that we would have known, pretty obvious. That's the whole point of the safety instrumented system is to put in the functions that allow the process to achieve or maintain a safe state. So we need to create a design by which that is going to happen.

Next bullet point: B: We need the specification of all identified application program components and the description of connections and interactions between the identified components. Hmm. Okay, so this goes back into that subroutine concept. So if you're developing subroutines, you're writing your own one out of two voter. You're writing your own BPCS measurement comparison alarm, and you might want to call that subroutine in multiple locations.

You need to think about what is going to go into separate modules, what's going to be in the main code, how does the module get called from the main code? And if you are putting stuff into separate modules, you do need to do a little bit of thinking as though you were actually a computer programmer. And specifically, what I'm concerned about is the instantiation and value of the local variables that are used in the subroutine? So if you call a two out of three voter for pressure transmitter 101 ABNC on one rung of code.

Then the next rung of code calls a two out of three voter from of a temperature transmitter 102AB and C. You want to make sure that those two calls don't get contaminated by each other. We don't want the pressure transmitter information to be kind of left over and stale when we call that routine again with the temperature transmitter. Okay, so the global variables versus local variables, be very careful about that, but of course, if you're just using the two out of three voter that your equipment vendor created for you, they've already taken care of all this for you.

It's not that big of a deal.

Item C: You need to consider the timing constraints associated with application program functions and their implementation in the program scan time. So, a couple of things to think about here, and we delved into this last episode, maybe a couple episodes back. I'm not sure. But PLC scan times are a big, real issue that you need to think about. You need your program to be able to execute quickly enough to where you never violate the MERT maximum equipment response time. That term is going to be in the next version of the 1511 standard.

Currently, we're saying process safety time with the caveat that you don't really have the entire process safety time for your safety instrumented system to execute, which is why we're moving to MERT. We talked about that a while back. And also, there's a whole Kenexis podcast. I'm sorry, not podcast, web webinar online that you can view if you want to learn more about the MERT concept. Um, Okay, so you need to think about how quickly your program is executing, is it executing within your process safety time?

And are you allowing enough time for your program to execute in considering all of the vagaries in scan time. Scan time is never exactly the same. Sometimes it's shorter, sometimes it's longer, depending on what's going on in the PLC down at the hardware level. So you want to make sure you always have plenty of time to execute. So, that workflow of making sure that you're giving your PLC enough time to scan is going to be part of your design of your application program.

## Clause 12.3.4 Bullets D-G: Library Modules and Global Variables

Next item or D is going to be a detailed description of the standard library modules being used. Hmm. If you're creating your own standard library, you should have a description of what your library is, how it works, that's available for other people in your company that are going to be using the code, using that library. And also, for posterity's sake, if you wrote your own custom modules, they're going to need to be documented for, you know, the proverbial: if you get hit by a bus, somebody's going to need to figure out what you did. So we need to leave documentation on that.

Now, if you're just using the library modules from the equipment vendor, they do an excellent job of providing that type of documentation. All right, ABCDE item E is you need a detailed description of application specific modules being used. Now, for a lot of your safety PLCs, they're kind of on the smaller side, and the module is the module. I've got a module where I'm running my code, and that code may or may not be calling equipment vendor subroutines. So everything's all in one place. Not very uncommon, especially for a smaller PLC, but sometimes you're going to break it into pieces.

So I'm going to have a page of function block diagrams for my heater, a page of function block diagrams for my reactor. So kind of as you're speccing things out, you might want to describe what modules you're using and what they're used for, what their scope is.

Next item up is F. Now, as I give you these letters, these letters are not in the standard. They are all bullet points, so I'm mentally trying to keep track of them. Start with A and go to the end. So, F will be a description of the way memory allocation has been achieved. Come on, dude. Memory allocation is not something that you can tinker with in a limited variability language. That's something that's important. If you're writing your code in C or C sharp or C, maybe not even C sharp. C, definitely.

You need to allocate function blocks of memory that you're going to be using and deallocate them when you're not using them, et cetera etc., etc. This is not an issue for limited variability languages. It just isn't. It needs to get gone.

And in the next version of the standard, I will need to double-check, but I believe that it has been gone. So the reason it doesn't need to be in 1511 is because if you're using a high variability language like C, you can't follow 1511. You need to go to 1508. So, you know, maybe we should replace this with if memory allocation is important, you shouldn't be using the standard in the first place. Okay, uh, next item up, which is G.

So, G. G global. G global. Note to self. The requirement is a list of global variables used and the way in which their integrity is protected. Again, this is something that most of you are not going to get bogged down with, especially if you have good maintenance and engineering interface software from the vendor that provided you software. So a global variable is a variable that can be accessed anywhere in the program including those pesky subroutines that you might be calling. Now your main program is generally going to contain everything. So, let me kind of give a typical use case.

I've got an SIS that is a hydrotreater plant, and that's going to be associated with a couple fired heaters, a reactor system, some pump shutdowns, etc. Now, when I write the logic for that, I might write one sheet of function block diagrams or I might have one sheet of ladder logic. That sheet of ladder logic, the variables that are used on that sheet of ladder logic are basically global, or I need to be very careful.

They're going to be local to that sheet of ladder logic, but then again, that one sheet of ladder logic is where all your logic is, so it might as well be global from your perspective. Anywhere, any rung you use that variable, you can read it or change it. Now, what we don't want to have happen is another subroutine uses the same variable name and now instead of changing the local copy at the subroutine you're changing the global copy and making things happen that you didn't want to have happen.

Most modern safety PLC softwares, you can't get into trouble with this. The equipment vendor pretty much forces the variables that you're using to be local to the place where you're using them. And if you try to use them outside of that location, you need to deliberately pipe that variable in. You need to send that variable to the subroutine so that it knows it's allowed to use it. And the variable names, when you create variable names, it's going to prevent you from stepping on things because it's not going to allow you to create a new variable that's used somewhere else that's global.

So that is global variables. Not that big of a deal, something to keep track of in the back of your mind.

## Clause 12.3.4 Bullets H-I: Non-SIF Isolation and IO Interfaces

Clause H in 1234 or bullet H is the identification of all non-SIF and the interfaces to non-safety-related parts of the application program to ensure they cannot affect proper operation of any SIF. So, this is an area where if you have non-SIF functionality residing in your safety PLC.

This is the point in time where it's a really good idea to have a separate page of application logic, a separate page of function block diagrams, a separate page of ladder logic where you're processing the non-safety stuff so you don't accidentally break something in your safety code when you're didddling around with something that is non-safety related. So keep them separate in separately named pages of logic, and it doesn't hurt to identify the non-safety pages of logic as non-safety and the safety pages of logic as safety critical. Okay, bullet I.

You need to, a definition of the input and output interfaces including tag listings and associated data types. Definition of input and output interfaces. Well, this gets a little bit wild, it gets a little bit hokey, it's getting more and more complicated as we allow more remote I/O, we're doing a lot more digital communication. Back in the day, my I/O. Card was sitting right next to my CPU, and while I'm doing this programming process, I could simply say, yeah, rack one slot one channel five is pressure transmitter 101, and that's done right there in the configuration software.

Well, now what happens when I'm landing my OIO at a remote I/O terminal block, and I'm going to need to communicate the value from the remote I/O block to the CPU. So, knowing where all of your data is coming from and how it what its pathway is from a field device actually into the PLC is going to become important. Old school, it's just what we would call configuration. We're going to configure RIO points, it's part and parcel of the maintenance and engineering interface, but it can be more complicated.

If it's more complicated, it's going to require more documentation to know that this remote I/O cabinet, it's talking, that remote I.O. cabinet, which is landing in this comm card, and that's where my I.O. point is coming from. So that's details of the data exchange. I'm sorry, that's the definition of the input and output interfaces, including tag listings and associated data types.

## Clause 12.3.4 Bullets J-K and BPCS Communication Best Practices

Now, there's two more items after this that we're going to delve into. And I am kind of looking at the clock thinking, man, we are not getting to the end of clause 12.3 here. So these two items are kind of related to what I just talked about. So I'm going to go with it. And I also need to figure out where I'm at. G H I. So input and output interfaces was I. We're going to do J and K, and then we're going to bag it for the day.

All right. So items J and K, bullet points J and K, are talking about details of data exchanged. Details of data exchanged. So I'm going to be exchanging data between my safety PLC and something else. So I need to describe how that communication is going to happen, what modules are being used for the communication, how the communication is configured. Okay, so the first one is details of data exchanged between the SIS application program and the operator interfaces. Okay, so I'm communicating from my safety PLC to my operator interface. Great. What data am I exchanging?

Am I exchanging everything? Am I exchanging a small subset? Do I have read access, write access? These are all things that you're going to be able to configure, hopefully, through your maintenance and engineering interface of your safety PLC. Now, there are other ways to do this. You can have a device that sits on your safety PLC network and it communicates, maybe using something like an API with your CPU, and then that other device now is going to talk external to the network to the operator interface.

So, the cleanest way for this to happen is to have a comms card that is sitting in the back plane with your CPU, and that comms card, the design is basically just the configuration of that comms card. Where am I communicating to? How am I communicating? What devices am I communicating to? What are the protocols? What are the restrictions? All of that is basically just configuration of that component. But as I mentioned, if you're not using something that was purpose-built for you by your equipment vendor, this could get sticky and tricky and complicated.

Okay, the second item, the last bullet point that we're going to discuss today is going to be details of the data exchanged between the SIS application and the BPCS and peripherals such as printers, data storage, etc. Okay, once again, it would be very nice if all of this was done in a comms card and all you have to do is open up your maintenance and engineering interface, and configure that comms card in terms of what gets communicated, how it gets communicated, and what the restrictions to that communication are. But these are computers.

We can hook them up to all kinds of gateways and pathways for communication. And we can even do things like run an RS-232 cable from the CPU to a printer to it allow to allow it to print alarm logs. I'm a little old school, but they're still out there. Also, things like data storage. Now, a lot of this stuff, so the last two bullet points, let me go ahead and give you what the best practice is.

And that best practice would be to communicate from the SIS logic solver to the basic process control system using a comms card provided by the safety PLC equipment vendor and configured in their maintenance and engineering interface.

So you want to set up the communications to go from variables that reside in the SIS to corresponding variables that reside in the basic process control system. Now, all of these other peripherals, you're not going to want the safety PLC CPU to be talking to them. no, no, no, no. That's additional workload, all kinds of opportunities for errors, all kinds of opportunities for a humans interacting with the system poorly. Don't overuse the SIS. Communicate the variables from the SIS to the BPCS and then let the BPCS do the work.

So, if you want data storage, you're on a regular basis communicating variables from the SIS to the BPCS. What you want to do now is have the BPCS communicate its copy of those variables to a historian computer for storage. If you need to do printouts, do them either from the BPCS operator interface or optimally, don't even involve the operator interface, do that from something, an external computer that's connected to the historian. Don't even use the historian for doing that type of stuff.

So, for the like the last three items, if I wanted to summarize a best practice for putting all of this together, you have a safety PLC. Buy a comms card from that same selfsame safety PLC vendors that is intended to talk to their safety PLC CPU inherently tightly integrated, well engineered, well designed.

That once the comms card is available, configure it for what you want to communicate and any restrictions in terms of read, write, read-only, etc. And then you turn it on, and the SIS variables on a periodic basis get communicated into storage or variables, memory locations in the basic process control system. As far as the SIS is concerned, that's where it ends. Now, if you want to do something else with that data, let the BPCS do it, or even better, have the BPCS communicate to a historian and let the historian do it, or have other systems talk to the historian.

And never, never, if you want to report, never travel all the way down to the safety PLC and back out. Talk to the historian. That's what its purpose is: for minimization of human failures, minimization of hardware failures, and minimization of an attack surface for cybersecurity. All right, well that is all that I have on the docket for today. We still have, are you ready for this?

One, two, three, four, five, six, seven, eight, nine, ten more bullet points in clause 12.3.4. So we're going to have to do the next episode where we wrap up clause 10.3 because we just could not get all of it today. So we will finish up the design of your application program in the next installment, but we haven't started doing the program yet because that's in clause 12.4, which we will get to after that. Talk to you then.

## Vertigo Software Overview

Now that you've heard some insights on technical safety, functional safety, and the IEC 61511 standard. Let me tell you a little bit more about how to easily and effectively implement the safety lifecycle using the Kenexis integrated safety suite and our SIS Sfaety Lifecycleage Mmentan 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.