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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E29 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 29: IEC 61511, Clauses 10.3.3 to 10.3.6 (Application Program Safety Requirements)

—

## Podcast Introduction and Disclaimer

We've spent a few weeks talking about safety requirement specifications. Now we're going to talk about safety requirement specifications, but this time for the application software. 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.

## Software vs Hardware Requirements History

Okay, so we did a lot of work over the past few weeks going through Clause 10.3.2. And back in the 90s, when we were working on the ISA 84 document, which is the precursor to the IEC 61511 document, when we said safety requirements, what we actually were talking about were, well, safety requirements, all the safety requirements.

And from an instrumentation and control engineer perspective, the concept of splitting the software requirements from the hardware requirements is something that really never even crossed our minds that, you know, there's a software discipline, there's a hardware discipline. No, everything was all put together. And when you write your specification, it's going to include attributes of the software, it's going to include attributes of the hardware. And honestly, that is an excellent frame of mind, an excellent frame of reference.

We at Kenexis generally use it. But then again, we generally partake in and recommend limited variability language, LVL. We're generally not in the business of trying to design using JavaScript, which has all kinds of issues associated with it. So if you're using very complex languages that have full control of the entire computer, you could do a whole bunch of very bad things that can result in dangerous failures.

But if you're using ladder logic or function block diagram, sequential function charts, your equipment vendor is generally going to keep you out of trouble and prevent you from doing really weird things. So, I mean, just an example. I do a lot of programming in JavaScript. So everybody here knows the Kenexis integrated safety suite, the absolute 100% best-in-class tool for safety lifecycle management of safety instrumented systems and other instrumented systems. You don't need to just limit yourself to safety instrumented systems when you're using Vertigo. But there's a lot of JavaScript.

Because it's a web-based application, we use a lot of JavaScript for the user interface. So, you know, there's a backend that's related to SQL Server and JSON objects. And anyway, I'm getting too far into the weeds.

But one of the weird things that I learned is that when you write an algorithm in JavaScript to perform some actions such as, you know, show this variable in this text box. Let me step back and kind of give you the sequence that I wrote. So I said go into the database and return a JavaScript object or JSON object. And then I'm going to want to show on the form a calculation based on the data in that object. So let's say we had the test interval and the failure rate and we want to show the PFD.

Well, we'll calculate the PFD on the fly so that you can, when you're making changes, you could see how those changes impact what the answers are. And then when we're done, we'll write the final answer back to the database. But what I saw was that I would write the code that says grab the data out of the database, grab the variables that we're going to be using, run the calculation to calculate the PFD, show the PFD in the form. And, you know, what could possibly go wrong? And I kept seeing the calculation return weird numbers. It would return errors. It would return all kinds of things.

Because what I didn't know, what I didn't appreciate is that in JavaScript, you're basically firing out a bunch of commands. And those commands are getting executed asynchronously. So basically, whichever the next line of code that's available for the processor to process, it will process. So because it takes longer to perform a calculation than to just display a variable, it would display the results of the calculation before the calculation was done.

And, you know, now I know that sequence control, when you're writing in JavaScript, is very important because you cannot rely on things happening sequentially. Whereas if you go into your favorite ladder logic diagram, you can be very well assured that rung number one is going to execute before rung number two because the equipment vendor wrote a lot of code to make sure that that's exactly what happens. Also, you know, a lot of these programming languages are purpose-built to make sure that you don't get into these kinds of situations.

So, you know, while I understand the programming community's desire to put in a lot of requirements for how you write the program, because you can't get yourself into a lot of trouble if you're not using kind of the certified programming products that came from your equipment vendor, you could get yourself into a lot of trouble. But at the same time, most of us are using those.

And a lot of what we're being asked to do is, I don't want to call it wasted effort, but, well, you could get your project done a lot quicker and for a lot more money if you didn't go to the trouble of having that safety, special separate safety requirement specification written for software, which I don't actually recommend. You're going to see that I'm going to talk about putting that safety requirement specification into the same place where all of your other requirements sit.

So that means general requirements, data sheets, cause and effect diagrams are going to contain not just the hardware SRS, but also the software SRS.

Okay, let's start delving into some of the issues here.

## Clause 10.3.3: Application Program Safety Requirements

And we're going to talk right now about clause 10.3.3. So we finished 10.3.2. We're going to move on to 10.3.3. And from here to the end of clause 10, we're going to be talking exclusively about software safety requirements. So there is a paragraph and there are three bullet points in this clause. It starts out by saying, the application program safety requirements shall be derived from the SRS and chosen architecture, parenthetically, arrangement and internal structure of the SIS.

So first sentence basically says that the, what you do in the application program is going to be derived from the SRS. And now the way it's written, it would kind of imply again that you're going to have a separate document for your software safety requirements. I don't necessarily believe that that is necessary. I don't recommend having a separate document unless your software application is going to be extremely complex and you're going to be using funky languages to do it.

Now there's nothing wrong with a separate document, but you know, more paper, more opportunities for errors, more things to become inconsistent in the future, yada, yada, yada.

That's how we got to this point. Okay. Moving on. The application program safety requirements may be located in the SRS or in a separate document. For example, application program requirement specification. Da, da, da. So right there, it specifically says that your software requirements can be in that single unified SRS. That's what we recommend at Kenexis. Again, general requirements, data sheets, and cause and effect diagram can easily contain all the information that you need to write your application program.

Having another separate document, unless you really need it because your programming is that complex, I tend to want to stay away from it. Keep it simple. KISS, another use of the acronym KISS besides Kenexis Integrated Safety Suite.

Okay. Okay. Moving on. It says, the input to the application program safety requirements for each SIS subsystem shall include. Okay. Now, language here is a little bit tricky. So, we need to provide inputs to the application program safety requirements. So, we need to describe the safety requirements. And we're going to do this description for each SIS subsystem. Now, we can go back to Clause 3 and talk about the definition of a subsystem, but we know that a SIS will contain many SIFs. So, a safety instrumented system will contain many safety instrumented functions.

Safety instrumented functions are comprised of subsystems. So, sensors, logic solvers, final elements. And those subsystems may have subsystems. And the subsystems and subsystems of subsystems may be comprised of components. So, don't get wrapped around the axle. Don't get too overly concerned about the nomenclature and the details. all right. So, kind of going back to this, your requirements are going to be down to the subsystem level.

Which, again, lends a lot of credence to the Kenexis approach of general requirements and data sheets and cause and effect diagram with cause and effect diagram notes.

So, if a software requirement applies to the SIS as a whole, it's a general requirement. But if it only applies to a specific subsystem, that's something that you would document on a data sheet. Efficiency, ease of use, ease of interpretation. It's lovely. Okay. So, number one item, the specified safety requirements of each SIF, including sensor voting, et cetera. My goodness, I already spec'd that out. I'm not doing it again. So, if you did an SRS for the hardware, all of this stuff is already there. So, you know, it'll, it'll serve dual purposes.

B, the requirements resulting from the SIS architecture and the safety manual, such as limitations and constraints of the hardware and embedded software. Ooh, that sounds like a general requirement to me.

So, depending on what the architecture is, depending on what the safety manual of the PLC or the, the logic solver, the programmable electronic system that you're using, if there are limitations to how that device can be used that are spec'd out in the safety manual, you need to convey that information to the people that are going to be designing the system, purchasing the system, implementing the system, programming the system. Sounds like a general requirement if there ever was one, but it might go down to the data sheet level. Maybe. I'd steer away from it.

All right.

And then item C for clause 10.3.3 says, any requirements of safety planning arising from clause 5.2.4. Okay. So, guess what? I'm going to need to back us up to clause 5.2.4 to read what it says. But while I'm going to clause 5.2.4, it talks about planning. So, we thought that we had left planning a long time ago, back in clause 5.2.4, but I'm going to backtrack a little bit so we can see what it says.

So, again, safety planning shall take place to define activities that are required to be carried out along with who is going to do these activities, when they are going to do these activities. The planning shall be updated as necessary, blah, blah, blah. So, your safety planning needs to consider what type of software you're using, who's going to be doing the programming, and so on. So, you know, I don't want to get on my soapbox.

You know, between the 8401 standard and the first version of IEC 61511, a lot of stuff got piled into the software, where the software kind of, they wanted to treat it as its own entity. So, yeah, when you're doing planning, you need to plan for how you're going to do your software. No kidding. Did you need to say it again? Well, apparently you did. So, hey, if you're going to be writing programming, you need to plan for the programming that you're going to write. So, all that is in Clause 10.3.3. Let's continue to move on.

## Clause 10.3.4: Programmable SIS Device Coverage

We're going to look at Clause 10.3.4, which states that the application program safety requirements shall be specified for each programmable SIS device necessary to implement the required SIF consistent with the architecture of the SIS. Huh. So, you need to define what the software requirements are, and you need to define those requirements for everything, for each programmable SIS device. All right, kind of, coming into this, most people, myself included, look at this clause and say, well, what do you mean? The, the, the PLC is the programmable device.

Well, there may be more programming going on than just a, just a safety instrumented, or, or, or just the PLC.

So, as an example, if you want to do some complex stuff in the field, oh, let's not, let's not make it too complex. let's say I'm using some sort of smart multiple input device that can, let's say, take three thermocouple signals in, and do a two out of three vote, and then output the result. So, like, more industries, you know, no, we're not sponsored by more industries, I'm just giving you an example, um, uh, has devices like this. And that device, you might need to program it to do what it does.

And, well, if you're going to program something, you need a description of what the program needs to be. You need to explain what a two out of three vote is. You need to explain how to handle errors. You need to know what the trick points are. And that programming is not sitting in your logic solver, the big PLC. It's in a little mini, specialty PLC out in the field.

So, there are situations where you have multiple programmable devices in a safety instrumented system. And, well, guess what? You need to write specs for all of them. Probably shouldn't come as a shock to anyone, but, you know, there we go. Uh, it's something to think about.

## Clause 10.3.5: Software Requirement Specification Elements

Okay, moving on, we're going to hit clause 10.3.5 and clause 10.3.5 has a boat load of bullet points to where I'm kind of kicking myself, thinking maybe I should have put letters on these bullet points, uh, so that I could refer to them individually. But it's, it's too late now. I'm in the middle of my podcast, so I'm going to keep slamming through it.

All right, clause 10.3.5 says, the application program safety requirement specification shall be sufficiently detailed to allow the design and implementation to achieve the required functional safety and allow a functional safety assessment to be carried out.

The following shall be considered.

Well, guess what? This kind of is like clause 10.3.2, but whereas clause 10.3.2 was talking about the requirements for the safety instrumented system as a whole, this clause is talking about requirements for the application program. So let's hit them. The first bullet point says, the SIFs supported by the application program and their SIL. Well, guess what? If you have a single document, all that information has already been defined in the SIF list. Okay, very good.

Two, the real-time performance parameters such as CPU capacity, network bandwidth, acceptable time performance, presence of faults. All trip signals are received within a special specified time period. So, some of the required performance parameters of your programmable system.

I know that, you know, one of the first application programs that I wrote back in the early 90s, it was for, it was in, uh, the south side of Puerto Rico. Oh my God. It was, it was the best job that I ever had. Uh, we basically redid a control system for the, uh, fractionation section of a UOP pair X unit. And, uh, yeah. So, it went so smoothly that the project manager would generally take us golfing after lunch because there was nothing for us to do because we had planned everything so, so thoroughly that the technicians were knocking out the hot cut over. But I digress.

My point is, when I first wrote the application program, I just kind of didn't consider writing code that ran efficiently. And after I wrote the application program for that distillation section, it was taking about three seconds to execute, which at UOP is a big no-no. Uh, we want fast execution. So, I rewrote a lot of the code, cut out a lot of stuff that didn't need to be there. And the program execution time got down to about a quarter of a second instead of a full second. Or instead of three seconds where, where we kind of started.

So, knowing what's, what is your cap on scan time is one of these things.

Now, where does this stuff all belong? Hmm. Sounds like a general requirement, doesn't it? Yeah, there we go. Just another item on your general requirements list.

Uh, item three is program sequencing and time delays if applicable. So, time delays, generally you're going to associate with every input and every output. Program sequencing, um, when you need to do it, you're generally going to want to describe that in a note. Uh, most safety instrumented systems are a whole lot of if this, then that, little bits of time delays. All that, you could shove basically into a cause and effect diagram. But, if you're going to say, okay, do this, wait for this to happen, then do that.

Now, we're kind of pushing the boundaries on what a cause and effect diagram is capable of and we're going to want to, uh, do something a little bit more robust, written with a little bit more text.

Or maybe, there you might want to switch to a description in a sequential function chart. Uh, item four, for equipment and operator interfaces and their operability. I don't think there's anything special here that's different from what we did in Clause 10.3.2 to be completely honest. Yes, we need to spec out how the operator is going to interact with the safety instrumented system, whether it's completely hardwired or it's completely programmable. There may be some special things that you need to say about the software, but, eh, it's generally already been covered.

All, uh, next bullet point, so, one, two, three, four, five, all relevant modes of operation of the process as specified in the SRS. No kidding. So, we've already spec'd that out. Action to be taken on bad process variables such as sensor value out of range, excessive range of change, uh, frozen values, et cetera, et cetera, et cetera. Well, guess what? We already spec'd this out. I already talked about this when we were talking about SRSs, but again, it's very important when someone is writing the program that they have that information available to them.

So, uh, general requirements territory generally for this kind of stuff, you might have some special things that you're going to want to put in a data sheet. next item is functions enabling proof testing and automatic diagnostic tests of external devices performed in the application program.

So, if you're going to wire an output back to an input and compare the actual output value with the commanded output value, if they disagree, you need to use your master field power de-energized

*[inaudible]*

relay a safe state. that's a diagnostic and you need to explain how that diagnostic is going to be performed. Now, most of the time, if you're using a SIL 3 certified PLC, your equipment vendor should have taken care of all of this for you. But a lot of times, if you're using a SIL 2 certified device, even, if you look at the safety manual, you're going to be required to do this by yourself.

So, if you're required to do this by yourself, you're going to need a description of what needs to be done. Okay, next item up, application program self-monitoring. And some of the examples of the information about self-monitoring is, what do you do with watchdog timers? And what do you do with data range validation? So, again, very top-notch SIL 3 certified PLCs have done all the watchdog stuff for you. You don't need to worry about it. You don't need to spec it out.

Data range validation is something that you might want to consider, especially if people are typing things in to make sure that, you know, if your value for an amount that you could transfer a tank is always going to be less than 5,000, you want to make sure if somebody types in 50,000, the software catches it and doesn't let them continue on. So, those are the application program self-monitoring.

The next bullet point says monitoring of other devices within the SIS. So, yes, guess what? Your SIS is connected to sensors. It's connected to final elements. The application program needs to be written to monitor those devices. Whew. Did that really need to be said? Okay.

Okay, so we're going to make sure that we spec out how we respond, things like the ranges and trip point. Oh, wait a minute. Didn't we already say we were going to document that back in 10.3.2? Hmm. Whew. Seems like if you write your own separate SRS document for application software, you're going to do an insane amount of repetition for absolutely no good reason. You might want to think hard about that before you actually do it.

All right, next item, any requirements related to periodic testing of the SIF when the process is operational? Online testing of safety instrumented functions and making sure that your equipment, your hardware software is programmed to be able to allow that type of testing to happen. Again, just an extension of what you needed to document anyway. So let's cut out the middleman and keep these things together instead of writing separate documents so you don't have to keep saying the same thing over and over and over.

Okay, next item is references to the input documents. So this is something that in the Kenexis boilerplate SRS general requirements, we have a section for documents that are incorporated by reference in the safety requirements specifications. So yeah, there's going to be a list of them. The sample list that's given in the standard says specification of the SIF, configuration or architecture of the SIS, hardware safety integrity requirements of the SIS.

We generally want to incorporate other things like cause and effect diagrams, piping and instrumentation diagrams, SIL verification calculation reports, layer of protection analysis reports that set targets. So yeah, there's going to be a whole bunch of things that you're going to reference, so you don't need to duplicate the information in your SRS document, minimizing the amount of time that it takes to do things and minimizing the opportunity for errors.

Okay, next item up, the requirements for communication interfaces, including measures to limit their use and the validity of data and commands both received and transmitted. So yeah, you need to document the equipment that is going to communicate with your SIS and you need to set specs for how that communication is going to get limited. And you might even put in some specifications for error checking.

So once again, this is going to be just another general requirement on the general requirement pile. of course, you know, if you have something special in this area for specific measurements, it might show up on a data sheet, but often general requirements are where we're going to stop.

Next item up, process dangerous states. For example, closure of two isolation gas valves at the same time that could lead to a pressure fluctuation, thus leading to a dangerous state. Generated by the application program shall be identified and avoided. We have already talked about this in Clause 10.3.2. You need to analyze all the outputs that your safety instrumented system can take and look for combinations that will result in bad things. We already talked about that in Clause 10.3.2 and if you have one of those, you need to specify what to do.

Which, if you're using a software based system, is going to require you to write software to do it. No kidding. And finally, the last bullet point in Clause 10.3.5 says we need the definitions of process variable validation criteria for each SIF. So how do I know if I have a valid process variable?

variable. So depending on what type of logic solver system you're using, you might be bringing in a 4, or you're going to be bringing in a 4 to 20 milliamp signal, let's say. Now, your hardware might convert that into counts of an 8-bit, counts of a 16-bit, counts of a 10-bit. It might generate a 0 to 100% floating point variable. and you need to figure out, well, how do I know that the signal that I have is valid? Or is it a bad PV? Unless your hardware does that for you. And a lot of hardware out there does do that for you.

So, kind of definitions of if I'm between this many counts and that many counts, I've got a valid signal. If I'm between this count and that count, my transmitter is trying to tell me that it's in the failed state. If it's outside that range, something is completely gone screwy. So, let's call it a bad PV or different variations of bad PV. And you know what? I think we already talked about a lot of this in clause 10.3.2!

So, there's a strong case that I make for keeping this all in one SRS document and just adding some additional general requirements as necessary as opposed to creating your own whole separate document. Unless you're doing some weird programming in a very powerful high variability language.

## Clause 10.3.6: SRS Structure and Traceability

Alright, finally, we're up in clause 10.3.6. When we get through this clause, it is going to be the end of clause 10 and we'll be able to get into clause 11. So, let's hammer it home in this extended podcast. 10.3.6 says, the application program safety requirement specification shall be expressed in a structured way that they okay, so there are going to be four bullet points for this clause that talks about how you need to structure your safety requirement specification to make sure that it is easy to read.

So, the first bullet point says that you need to describe the intent and approach underpinning the application program safety requirements. What? Okay, so I need to describe how I'm going to describe things. Basically, you need to start your safety requirement specification with a and it connects us in our boilerplate. It's a general requirement that explains how your safety requirements are laid out, where to look for different things, how are things interconnected. connected.

So, we need to explain to the user or to the reader how they're going to be able to use the safety requirement specification, keep them out of trouble, and make their life a little bit easier to let them know where things are, to save them a little bit of time instead of having to page through everything.

The second bullet point is that the requirements need to be clear and understandable to those who will utilize the document at any phase of the SIS safety life cycle. This includes the use of terminology and descriptions which are unambiguous and understood by all users. For example, plant operations, maintenance personnel, application programmers.

Okay, clear and understandable. I like the fact that the Standards Committee really highlighted that there are different use cases for this information. An operator is going to use a logic description one way, a programmer is going to use it a different way, an OSHA inspector who's come to your plant to look at your equipment is going to look at it in still a different way. So making sure that you're presenting information in a format that

*[inaudible]*

information is going to be able to understand and work with is very important.

Hmm, sounds like somebody should have some really good SIS safety lifecycle software that has a whole bunch of different reporting outputs from a single unified database that will allow you to present different things in different ways to different users all while having one unchanging database under the hood to prevent different documents from containing different things. Yeah, that's right. Kenexis integrated safety suite and our Vertigo application does exactly that. All right.

Third bullet point. The application program requirements need to be verifiable, testable, and modifiable. Do I need to talk any further on that? I don't think so. I'm not going to. Requirements, verifiable, testable, and modifiable. And the last bullet point here says that the requirements need to be traceable back through all deliverables including the detailed design documents, the SRS, and the hazard and risk assessment that identifies the required SIF and SIL.

Oh! Okay. So when your software safety requirement says that a function is SIL 2, that should be traceable back to the original SRS if you did the thing I don't like and create a separate application SRS. And that SIL also needs to go back to a layer of protection analysis. All those things should match each other. Hmm. Seems like someone should build an application that does all this automatically. Yes, I know. I got to stop doing this, but I just can't help myself.

So in Kenexis integrated safety suite, if you decided to print out software requirements, they're going to contain the same data that traces its lineage through tight linking and embedding all the way back to a layer of protection analysis document that you did in OpenPHA to start things off when you migrated everything into the Vertigo application with a single click of the button. And now everything is all inextricably linked together. And there are all kinds of checking mechanisms and restrictions to make sure that you don't mess things up as you go through the safety life cycle.

So a good SIS lifecycle management tool will keep all those things linked together while also keeping them separated so someone can do a LOPA on their laptop computer in an airplane and then still be able to get everything synchronized and linked when they get back to their office and push stuff back up into the cloud. All right.

## Clause 10 Wrap-Up and Vertigo Overview

So with that we are done with Clause 10. We talked about safety requirements specifications to death. We spent a lot of time doing it as we should because in general this is the part of the safety life cycle that is absolute garbage most of the time that I see it and people need to spend a lot more time working on this.

A little bit more information in the Kenexis integrated safety suite in our process safety training center. One of our premium classes is safety requirement specifications. So if you want approximately two days of me lecturing on best practices for safety requirement specifications you can go ahead and pick up a license to the process safety training suite and check that stuff out. But until then let me pause it until we pick things back up again next week.

When we pick things back up again next week we're going to be hitting my favorite clause in the entire standard. Which is SIS design and engineering.

So we said that this is a performance based standard but you know what? It's a little bit prescriptive too. And all those prescriptive details of things you need to think about when you're programming, when you're selecting equipment, when you're installing and configuring the equipment. That's all going to be clause in 11 and we're going to start into that next week.

Now that you've heard some insights on technical safety, functional safety, and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our SIS safety life cycle management tool Vertigo.

Vertigo is a comprehensive tool set for performing assessment calculations, documenting, and maintaining the design of safety instrumented systems. Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation.

Each safety function can then be analyzed by performing a SIL verification calculation, complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities. After the SIL verification calculations are defined, you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments.

Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries. After the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility. Kenexis Vertigo is the most integrated, easy-to-use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application.

> *

*