Functional Safety Podcast: episode (S1E51) is now available

Episode Introduction and Disclaimer

Designing your software is what you do before you actually write your software. We’re still designing and we will be for a little bit still. 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.

Recap and Item L: Diagnostic Processing and Logging

All right, we are continuing on. We’re still in clause 12.3.4. This is the application program design and decomposition into modules. So we’re putting together a plan effectively for what we’re going to do when we actually write our software. So we’re designing how the software is going to be written. Now, clause 12.3.4 gives a very long laundry list of all of the sub-items that need to be considered while you’re doing this design process.

We got all the way through L. I think we’re on item L. So there’s a whole bunch of bullet points under 12.3.4. So I’ve been giving them all letters: A, B, C, D-E-F-G-H-I-J-K is the last one that we did. And now we’re on L. So going as we go through these bullet points, and there’s 10 more, I believe still that we need to get through. As we’re going through these bullet points, remember that the application program shall address how these requirements are to be implemented. So, what are the requirements that need to be implemented, and how are we going to design them into our workflow?

Not program them, but write the design upon which the program is going to be written. Who This is going to get simplified a lot in the next version of the software, but or in the next version of the standard.

But let let”ss continue on. So, bullet item L says there’s a requirement for how to or how external and internal diagnostic information will be processed and logged. This is actually relatively important because diagnostics occur in different locations at different speeds for different pieces of equipment, and who is doing which part of the process and how information is getting communicated from one place to another is actually quite important. And we already talked about this pretty extensively in clause 10.3.2. But once again, you need to write the software to do what you decided.

So, just some examples. If I’m doing diagnostics on the transmitter side, and let’s just say I have a pressure transmitter, and the pressure transmitter self-diagnoses that it’s in the failed state. Well, you need to specify what the transmitter is going to do. And that’s going to be a configuration of the field device. Once you decide what it’s supposed to do, now, you also need to program the safety PLC to respond to what’s happening. Now, just as an example, let’s say it’s a high-pressure shutdown. You can configure your transmitter to go off-scale high.

Just push that current as high as you can go. And that will trigger a trip effectively. So, you really, at that point in time, don’t need to do anything in the safety PLC to make the safety function activate. But the most common default setting is for the output of the transmitter to go to a safe known value, like 3.7 milliamps is a very common safe known value. Well, if all you do is set your output to 3.7 and you don’t configure your logic solver to do something about it, that’s a problem because you’re basically going to put it into a safe position.

I mean, a position that is not going to cause a trip and it’s stuck there. So setting the output to 3.7 on a detected failure of the sensor is actually creating a dangerous condition, unless you program the safety PLC to do something about it, which would be to detect that you’re below the saturation range of the transmitter, which on a 4 to 20 milliamp transmitter, usually they can give you a valid signal down to maybe fillier 3.9 milliamps. So if it’s below that, there’s something wrong with the transmitter.

And the safety PLC needs to be configured to know that that is a signal which indicates that the transmitter has failed. You also need to program the safety PLC to do something upon that failure. Okay, this is all kind of par for the core standard stuff for just the input blocks that you’ll get from your equipment vendors in a either function block diagrams or ladder logic, but it’s something you need to think through, something you need to spec out, something you need to make sure is being done properly.

Now, another way to detect that a sensor has failed would be a deviation alarm between the SIS and the BPCS if you’re measuring the same location. Well, you’ve got signals coming into two different machines, so you need to decide whether you’re going to do that comparison in the DCS, you’re going to do that comparison in the SIS, how you’re going to enunciate that deviation. So, all of that kind of goes into the philosophy of what you’re going to do because there are a lot of different options for doing this.

Now, in the logic solver, you’re going to the logic solvers are going to self-diagnose a lot of failures. Well, how do you get insight into that? Do you communicate that information to the DCS? That’s an option. Do you simply put up a kind of a common trouble alarm saying that there’s something wrong in the safety PLC?

You need to go to the maintenance and engineering interface to dig into it and find more details on what’s actually gone wrong. That’s another very common approach. Those are what this requirement is referring to as internal diagnostics. But, well, what if an external watchdog timer times out. Those are external diagnostics, and once again, you need to do something about that. Now, watchdog timers timing out is generally, not a program issue.

That’s something where you’re going to want to just externally de-energize power going out to the field as the mechanism for responding to that diagnostic. But as you’ll see, there are a lot of different options that you have, and you need to specify which option you’re going to use.

Now, I would argue that you’ve already documented all of this in your safety requirement specifications as per clause 10.3.2 required you to do all of this, but okay. So, if we say that we need to document it twice, then hopefully there’s double the chance that you’ll document it, maybe. Anyway, so that’s kind of the design of how your diagnostics are going to be processed. So, how are they going to be executed? Which components are doing what? How is the signal going to be communicated and viewed?

Item M: Operation and Maintenance Interfaces

All right. Next bullet point in 12.3.4 is M, bullet point M after L. And that is going to be you have a requirement for a detailed description of how operation and maintenance engineering interfaces are implemented, including the way in which alarms are prioritized, indicated, and accepted. So, yeah, I’m pretty sure that we needed to discuss what our operation interface was back in clause 10.3.2. But alas, it’s one of those general requirements.

I would put it in the general requirements section if you’re using Kenexis SIS, which is the new name for the Vertigo software, which is going to be, well, actually, it just got announced, but August 1st, the Kenexis Integrated Safety Suite is going through a dramatic upgrade in its user interface. So the look and feel is going to change, and we’re taking that opportunity to rename some of the existing modules. So the name Vertigo is going to be a relic of history. It will simply be Kenexis SIS in the future.

So this is a great place for a general requirement in those safety requirements specifications to indicate what are you doing for operation interface, which you already specced out as per clause 10.3.2. The details of maintenance interfaces were not required for you to spec out in 10.3.2, but it’s kind of part and parcel of the same thing. And so, that, you know, having a general requirement for how you’re going to do that is great. And these requirements include the way in which alarms are prioritized, indicated, and accepted. So, what priority do different alarms get? How are they indicated?

How are they accepted? Now, those last bullet items, the way in which alarms are prioritized, indicated, and accepted. Now we’re kind of sticking our feet directly into the alarm rationalization process and the ISA

18.2 workflow for alarm management. Basically alarms that say that the safety instrumented system has failed. So let’s say we have a common trouble alarm coming from the logic solver indicating that maybe the temperature in the CPU is too high. That’s an alarm that needs to be prioritized. Okay, you’ve got an alarm rationalization process to do that. It needs to be indicated. And, well, we’ve got an alarm design process okay. So we know where we’re going to indicate it and how we’re going to indicate it and how it’s accepted. That’s part of the standard workflow of design.

So there’s the diagnostics that get generated in the safety PLC are going to or can generate an alarm and once you know you have an alarm, now you need to switch gears to your alarm rationalization, your alarm prioritization workflow to figure out what priority you’re putting on that, and so on.

Item N: Application-Level Diagnostics for SIL

Okay, next bullet item is N. And again, I’m giving these bullet items letters because that’s the way I have it up on my screen. I kind of scribble them in virtual pencil. They are only bullet points. So if you kind of got lost in what I’m saying here, take your copy of 61511. Maybe you’re going to use your Apple pencil like I did on my iPad, or you know, you’re gonna type some stuff up on the screen, but just put a letter next to each bullet point.

So, if you did that, we are now on bullet point N, L M N. So this next requirement is a detailed description of any application level diagnostics that may be implemented as external watchdogs, application data integrity checking, sensor validation to meet the required SIL. Okay, I’m gonna go back out there and say we did this already in clause 10.3.2. So, what we’re going to do in terms of the diagnostics to make sure that we are capable of achieving our performance targets is something that definitely needs to be specified.

Going back to clause 11.5, we talked about safety configuration and that safety configuration process should have resulted in the requirement for a lot of diagnostics, like wiring outputs to inputs. Using multiple inputs with comparison diagnostics, watchdog timers. Everything that you do in that respect needs to be documented. Now that might be something that sits in a general requirement. That might be something that sits in a logic solver data sheet. Typically, we would attach a little diagnostic spec to the data sheet of a logic solver device.

Or general requirements are another good location to put this type of information because logic solvers tend to, the requirements for logic solvers tend to spill over to all of the equipment in the safety instrument system as a whole. So, by definition, anything discussing general operation of the logic solver is a general requirement.

Item O: System Configuration Checks

All right, L M N and then O is the next bullet item. So for bullet item O, there is a requirement for system configuration checks, including the existence and accessibility accessibility of the expected hardware devices and software modules. What do you need to do with regards to the design? Hopefully, nothing. This is something where you’re kind of expecting your logic solver vendor to be able to do all of this automatically based on your configuration. So, when you’re in the maintenance and engineering interface for your Logic Solver device, you’re doing your programming.

Well, before you even do your programming, you’re kind of gonna set up a configuration of what does all of your equipment look like. And in that there’s going to be what are the CPUs, what are the communication cards, what are the I/O. Cards, what rack slot and channel do those cards sit in? What I/O. Points are going to land in which channels on which cards. So, that kind of configuration is essentially the starting point for your safety PLC configuration.

Now, what this clause is telling you is that if you inserted an output card where the configuration says an input card is supposed to reside.

Your system should check this, your system should know this. And if your system doesn’t do this, by goodness gracious, get a different system. You know, these are table stakes for even the cheapest PLC. Okay.

Item P: Minimizing Application Program Complexity

Next item up is item P, and it is a requirement, so we’re going to define a requirement for how the complexity in the application program design is minimized through the use of modular design and simple functionality. This one rubs me significantly the wrong way. So this is kind of a design philosophy that you might want to put into your corporate design standard, but on a project-by-project basis, writing a statement for this is what I’m gonna do to make sure that my software is as simple as possible, the complexity is minimized. I’m sorry, but that’s that.

That is a step too far. That’s a little bit on the ridiculous side. So, yes, we absolutely want to minimize the complexity of the software that we’re developing. Keep it simple. Very, you know, keep it simple, stupid. Kenexis Integrated Safety

Suite, KISS. It’s a, you know, you really shouldn’t design your plant without KISS. How about that? Um, but this you know, keeping it simple is a philosophy, it’s a training issue, it’s a competency issue, it’s not something that changes or gets documented on a project-by-project basis. So, absolutely, in your safety requirement specifications, you’re going to be referring to external documents.

One of those external documents is going to be a corporate or a site philosophy on how software is developed, how tags are chosen, etc., etc. That is the place that this type of information should be residing. All right, that was LMNOP.

Item Q: Fault Detection and Enunciation

Now we are on bullet item Q. Bullet item Q, which is a requirement for functions related to the detection, enunciation, and management of faults in SIS sub systems. Okay, so we need to manage, enunciate, and detect faults in the SIS subsystems. And kind of the overarching theme here is what I talked about when we first started this episode with item L in terms of internal and external diagnostics, diagnostics can happen in a sensor. We need to communicate those diagnostics into the safety PLC so that the safety PLC is capable of appropriately responding to what those diagnostics are.

Okay, so that type of functionality needs to be incorporated in the safety instrumented system and it needs to be documented in your specifications, in your design, in your plan. So, as I again, as I mentioned in item L, a lot of this got documented because of 10.3.2.

These are generally general requirements, so use that Kenexis SIS portion of the database for general requirements to write down how you’re going to do this because it’s probably going to be done consistently. So the way you communicate a diagnostic and hold the information about that diagnostic and enunciate alarms related to that diagnostic are going to be consistent for pretty much every input device. It’s going to be consistent for every output device where you have diagnostics. The mechanism for the communication is generally going to be consistent.

So it’s just a matter of writing that information down so that it gets done consistently in the software development. And again, good news: more sophisticated SIL 3 certified logic solvers. Your equipment vendor has already thought all this through, and it’s part of their library modules that you’re going to be able to use. Okay. Um, the next item up, so L M N O P Q R.

Items R and S: Online and Offline Periodic Testing

Okay, so we are at the R subsection, and let’s do R and S together. R is a requirement for functions related to periodic testing of the SIF offline, and S is a requirement for functions related to the periodic testing of the SIF offline. So R is online, S is offline. If you need the logic solver to participate because of functional, you know, special requirements in the testing process, you need to program those testing capabilities into the safety PLC.

So, this could be something as simple as the ability to do a bypass. This might be something where you have a toggle where you can decrease the time requirement for a timer to make, you know, a four-hour timer condensed down to four seconds. So you’re not spending four hours trying to execute a test plan because of some sort of time delay in the system. Whatever information you need, or whatever actions you need the SIS to be able to take that are special, that are simply a requirement of the testing process, you need to write them down so that people are going to be able to code them out.

Now, honestly, most of the time, this is just that standard bypass functionality is all you would need to allow testing to occur either online or offline, but sometimes you might need something a little bit weird. Sometimes you might want to change how the system behaves ever so slightly during a test process. So, now, of course, we might be violating the complexity clause there. Something to think about. But yeah, RNS, if you need special behavior out of the SIS program in order for tests to occur. Obviously, you need to write that code in. All right, item T.

Item T: Simplifying SIS Maintenance

So, well, there’s a whole lot of functionality there, a whole lot of bullet points here. T is a requirement for functions that allow maintenance of the SIS to be carried out simply. Okay, let’s do an example of this. If you have a gas detector as part of a safety instrumented function.

Now, every once in a while, you can run into a situation where a gas detector is part of a safety instrumented function. So, let’s say I have a room that may have toxic chemicals in it and if the toxic chemical concentration in the room goes high, I’m going to lock the door so that people can’t wander into the room when the toxic concentration is excessively high. That device is going to need to go undergo very frequent maintenance.

So, on a quarterly basis, let’s say we’re using a combustible, I have a combustible gas detector with a catalytic bead, so, I’m going to need to calibrate that quarterly. Well, sometimes I might want to do that automatically. So, I might have the transmitter communicate to the SIS, that it is going into calibration mode. When it goes into calibration mode, the SIS should ignore the signal until the calibration is done. So you send a signal that you’re going into calibration mode, you do your calibration. After the calibration is done, you take it out of calibration mode.

So that’s an example of functionality that is going to allow the maintenance to occur. Now, did we need to do all that extra fancy schmancy programming in safety PLC and make it more complicated? Probably not. You can just as easily use the pre-existing bypass functionality to put the device in bypass and execute the calibration manually. But, you know, if you want things, especially things that happen at a high frequency, and you’re capable of automating them, it makes sense to do that. And if you do, you need to write some extra code for that automation.

Final Bullet: Referencing Design Basis Documents

All right, the last, the final bullet point in clause 12.3.4 is you need to specify requirements to document requirements for references to documents on which the application program design specification is based. Now, again, that design specification might simply be an extension of the information that sits in your safety requirement specification that optimally would exist in the Kenexis SIS software. And part of what we do in the general requirements is going to be incorporation by reference of external documents.

So if you have a site standard for how you’re supposed to name your variables in an application program, you in your SSR, generally you put this in the SRS general requirements. You have that incorporation by reference section, and you refer to that external document, there, just saying that you know, all of the programming needs to be done in accordance with the site programming standard, blah, blah, blah.

Also, in the new version of Kenexis SIS that is going to go live on August 1st of this year, you will simply be able to drag and drop a copy of that standard directly into your Kenexis SIS database so that it can actually reside in there as one of the reference documents. So, a lot of good things coming up in the Kenexis Integrated Safety Suite world, including not just incorporating documents by reference, but actually being able to keep a copy of that document directly in the database, if that’s what you want to do.

Alright, so that, with that, we have worked our way all the way through clause 12.3.4. You would think at this point in time we’ve made sure that we’ve specified everything that we need to specify before we write our program. My argument, my argument, getting up on my soapbox, all of this should be in a single safety requirement specification. And if you do that in the Connexys SRS software, you’re going to be head and shoulders above everybody else.

But um you’d think that we’re ready to write our program yet but we’re not um and you would think that the episode is over but it’s not because there’s still another clause, another subclause in 12.3.

Clause 12.3.5: Application Program Design Assurance

So for the final subclause in 12.3, we have 12.3.5, which in and of itself has four bullet points beneath it. So let’s dive in. So clause 12.3.5 states that the application program design shall ensure so the design, the specification, what you’re writing down, what you’re documenting with regards to how the code needs to be written, how the code needs to be executed, where the code needs to reside, that’s all part of the application program design. That design shall ensure four things.

The first thing that it needs to ensure, first bullet point, the completeness with respect to the SRS and its intended purpose. So the design needs to be a complete representation of the application program and it needs to mesh up with the SRS and the intended purpose of the SRS, the intended purpose of the application. Now, it’s really easy for your application program design to mesh up with the SRS if it is contained in the SRS. Part and parcel, no reason to separate for most of you out there. Okay, bullet point number two.

It needs to the design needs to ensure correctness with respect to the SRS and its intended purpose. So, the design of the SRS needs to be complete, it needs to include all the functionality, and it also needs to be accurate. No kidding, it needs to be complete and it needs to be accurate. I would have never thought of that myself. Okay, all right. I’m going off on a tangent. All right, let’s keep going.

Next bullet point: bullet point number three: the application program design shall ensure freedom from ambiguity, i.e., id est, it is clear to those who will utilize and document at any stage of the SIS life cycle. All right, bullet point number three here. I’m breaking into a few pieces and kind of talking it through. So um, we need to, you know, be free from ambiguity. What you’re saying and how to implement needs to be clear to anyone who’s using this document at any stage of the life cycle.

And continuing on, this includes the use of terminology and descriptions which are unambiguous and understood by plant operators and system maintainers as well as the application programmers. So that’s kind of interesting. In this freedom from ambiguity, what they’re basically saying is that your application program design, you should be able to hand it to a maintenance technician and they should be able to understand what’s happening. So we’re not writing jargon for programmers.

We’re specifying things in a way that an operator or a maintenance technician will be able to understand what the design is and what the system is supposed to do. But it also needs to be thorough, comprehensive, and complete and correct enough for the application programmer to actually write the application code. And item four: it needs freedom from design faults. Okay, so in bullet point two, we said it had to be correct. And that’s not enough. We said in bullet point four that it has to be free from false. It has to be correct and free from faults.

Oh, well, I was going to make it correct, but I was going to leave the faults in there. Come on, people. Let’s we are sharpening the pencil in the next version of the IEC 61511 standard and taking out some of this motherhood and apple pie duplicative information, saying the same thing in multiple different locations, trying to keep things a little bit simple and more easy to implement.

Wrap-Up of Clause 12.3 and Preview of 12.4

All right, with that, we have gotten ourselves all the way through clause 12.3 in the standard. We’re getting ready to move on to what is next, which is going to be clause 12.4 of the standard. So, 12.3, we designed the application program, specking things out, making sure all the information’s there. We got all the way to bullet point you in a list. So that is a long list of things that we need to make sure get documented. Most of them were already documented because of what we said in 10.3.2, but it’s still there, and we’re continuing on.

But now we have a complete design, we are ready to start code in. So we’re not at the stage yet where we’re gonna be able to hand the SRS over to Claude and let Claude code generate the code for us. Not yet, maybe. I wonder if it could probably write the program better than the person that you’re having write the program now and do it for, I don’t know, 10-15 bucks worth of tokens.

But I digress. But I digress. We’re going to talk more about the application program implementation next week. And I’m going to, when I talk about application program design, I’m going to do this is through the filter of a human being actually doing the design, which is where we are at today. But the time is nigh when that Claude Code instance, Claude Code co-work instance is going to be able to generate this code for you. But alas, we’re going to kind of go old school and still assume that a human is going to be actually doing the programming.

So that’s going to be clause 12.4. I am hoping we’re going to be able to get all the way through clause 10.4 in one installment that is not gonna happen next week. I’m gonna be teaching a training class on Kenexis Open PHA and Kenexis SIS at a new customer. New customer site.

Actually, they’re kind of uh, we’re going to the corporate headquarters because there’s 20 plants that are all migrating their data out of the stuff that they used to use into KISS, and I will be teaching them all about it, but the week after that, I will get you a brand new podcast that talks all the way through clause 12.4. If I can get it done, there’s a lot of information in that clause, so I might have to split it into two pieces, but I will not know until I start. So enjoy the podcast, and well, it’s over now, so I hope you enjoyed the podcast. I will catch you on the next one.

Kenexis Vertigo Software Overview

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

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

After the SILF 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.