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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E53 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 53: IEC 61511, Clause 12.4.3 and 12.4.4 (Library Functions and Program Structure)

—

## Introduction and Disclaimer

The best way and safest way to write software is to break things down into tested reusable modules. Welcome to the Kenexis Functional Safety Podcast.

I'm your host, Ed Marszal, President and CEO of Kenexis. Kenexis is a technical safety consultancy that helps chemical process industry companies to analyze risk and design engineered safeguards like safety instrumented systems and fire and gas detection systems. Kenexis also provides the industry-leading suite of software tools, including our best-in-class Vertigo software for SIS safety lifecycle management. In this first season of the podcast, we are going to focus on the IEC 61511 standard, doing a deep dive into the standard, including more depth of information on what the standard means and how to apply it, brought to life with personal war stories and behind-the-scenes discussions of the committee members as we develop the standard in ISA 84 and IEC SC 65.

Before we start, a little disclaimer: I will be providing my opinion on technical and engineering topics. This information is provided on a best effort basis and is of a general nature. The information presented in this podcast might not be applicable to your specific application. It is the obligation of every engineer to thoroughly analyze any system that they are designing and not blindly rely on any general advice presented in this podcast.

## Episode Overview: Clauses 12.4.3 and 12.4.4

All right, in today's episode, we're going to take another crack at the software portion of the standard.

So, we're still in clause 12 talking about software. We're not going to get done today. We're going to take a smaller chunk today and we're going to look at clause 12.4.3 and clause 12.4.4. And this is still, so we're still in clause 12.4, which is application program implementation. So, how do you actually implement the software? In clause 12.3, we designed it, kind of wrote specs for what it's supposed to do, then in clause 4 we actually do the programming.

Last week we talked about clauses 12.4.1 and 12.4.2. And now we're in clause 12.4.3. Okay, um clause 12.4.3 and 12.4.4 are discussing structuring of the code and application program libraries and who does the testing? What is the provenance of the libraries that you're using? Are they open source? Have they been developed by the equipment vendor? Have they been developed by people internal to your organization? Have they been tested? How have they been tested? All of this is relevant to what we're going to be doing in the process industries, when we're writing code for our safety instrumented systems. So let's begin.

## IEC 61508 Compliance for Full Variability Language Libraries

12.4.3 states: if previously developed application program library functions are to be used as part of the design, their suitability shall be justified based upon. Okay? That's the stem, and then we have three bullet points. So there are three things that we're going to justify and base the suitability of using library functions on all right, item number one: uh, you justify based upon compliance to IEC 61508. If proven in use evaluation for full variability language in compliance to IEC 61508 Part 3 2010 is undertaken. The programmable devices on which the application program library functions execute shall also be evaluated as proven in use in accordance with IEC 61508 Part 2. Okay, so that's one of the options.

These three bullet points are kind of pick and choose, decide what you want to do, etc. So for bullet point one, we've got kind of an odd case. We have a subroutine that's written in a full variability language that is being called by our application, which is written in a limited variability language. So somehow our function block diagram is calling a C routine, or our ladder logic is calling some JavaScript. We're kind of getting out there. I don't even, off the top of my head, know any systems that would allow you to do such a thing, but it's in there, and basically, what it's saying is: so, let's say I wanted to call a subroutine that does a real-time energy balance for my reactor. And I wrote that real-time energy balance in C sharp. Can I call that routine if it's even physically possible from my safety PLC? Well, the answer is yes, but the subroutine itself would need to be written in compliance with IEC 61508 Part 3. So even if you're just calling a single subroutine in a full variability language, that subroutine needs to be written and tested in accordance with the IEC 61508 rules for software development. Okay. That makes sense if you're going to do that. It's kind of an odd case. Don't see it very often, but there you go.

Now, the second half of it talks about the device that the application program is running on. So now we're not even splitting this up so that not only is am I using a full variability language, I'm running it literally from different hardware. So the programmable device on which the application program is executed also needs to be evaluated as a proven in-use device. So, this would be as though, well, you know, actually, let me kind of give you an example. A lot of you are familiar with APIs or application program interfaces. And this is where you Make you curl, you make a curl statement, and that's going to send a command to a remote computer to execute some code and return the result to you. So, if somehow, some way, for some reason, your safety instrumented system is able to make API calls, and I don't know off the top of my head any safety PLC in a limited variability language that will allow you need to make an API call. But let's say it's possible the code that executes that API response.

So you're going to get the curl command, which is going to ask for a subroutine to be run. It's going to give you an argument list, and then it's going to expect you to return a response. Not only does that subroutine need to be written in accordance with IEC 61508 Part 3 programming rules, the machine that receives the command and executes the code also needs to be compliant with IEC 61508.

Now How would you do that? I mean, maybe you're going to get a certified device, but most of the time when we're doing these weird API calls, we're not doing it on a purpose-built, certified, safety PLC. So we're just kind of, we've got a Windows machine, maybe somewhere. And what you're going to need to do is you're going to need to determine that that device is suitable based on proven in use. So, proven in use is a term equivalent to prior use. Prior use is used in the 61511 standard proven in use is used in the 61508 standard and the rules are a little bit more complicated a little bit more onerous, but they are there. So if you're calling an external device to run some code that's part of your safety function through something like an API call, you can do it, but your code has to be 61508 compliant on the remote machine, and the remote machine also has to be IEC 61508 compliant, whether that is a traditional compliance or kind of a proven in use compliance. So, hopefully, bullet point one, we are going way, way, way the heck out there, and you will never run into that situation. But if you run into that situation, there you go. That's those are what the rules are, and that's how to make it allowable, shall we say, in accordance with the standards?

## IEC 61511 Prior Use for FPL and LVL Libraries

Okay, bullet point number two: their suitability shall be justified based on compliance to IEC 61511 prior use requirements when using FPL or LVL. Okay, so I've got subroutines that were written in 1511 in FPL or LVL. So FPL is kind of again, FPL fixed program language is something that we generally like sit on a transmitter. There's a program, the transmitter is running. You could change parameters, but you can't change the program. That's kind of not really what we're talking about here. The main case would be LVL. So let's go with ladder logic this time. So if I want to use a library function in ladder logic. So I have built a subroutine and that subroutine is a device, a contact. It's a function block that I could put in the middle of a ladder logic rung.

If your software allows you to create custom functions. You can use those custom functions, you can reuse those custom functions, but you need to comply with IEC 61511 with regards to that code. So I would say the code itself is going to need to be conformant here with clause 12, but it also talks about 61511 prior use requirements. So prior use requirements are going to be the things that we talked about in clause 11.5. So you need to make sure that the failures are understood, the failures are low. The code that you're using in the new application matches the code in the old application. You have a quality management system for that code. So, if you used a two out of three voter in one PLC, you can copy that code and use it in another PLC, but you're going to need to follow and comply with your proven in use requirements for the code as it exists and as it is written, as it was tested in the other application.

## Unused Function Impact on Application Program

All right. Third bullet point is suitability shall be justified and based upon, and the last bullet item is in all cases, demonstrating that any unused functions do not adversely impact the application program.

Now, in a lot of cases, subroutines that reside inside a library might have a lot of functionality that you don't use. So if you have a two out of three voter and you have a library item that contains that two out of three voter, there might be a deviation alarm that is one of the outputs that that subroutine might have, and you might not use that two out of three vote for anything. I'm sorry, you might not use the deviation alarm of the two out of three vote for anything. It's okay that that extra code is sitting in there, but it's important to understand and know that that code is not going to be detrimental. It's not going to cause a failure and it's not going to have a negative impact. So if the fact that you didn't wire that deviation alarm out causes that subroutine to freeze up because it's expecting to send the deviation alarm output somewhere and it stops because the output isn't wired to anything. That's not okay.

So make sure that if there is any functionality in those subroutines that you're not using, make sure that it doesn't impact what is being used. And this is all part of that, you know, the testing process on your software, especially during the validation, during the FAT phase, where we make sure not only that the system does what it's supposed to, but we also make sure that the system doesn't do what it's not supposed to do by manipulating things that are really not even part of the program, like that deviation alarm that you're not using.

Okay, so all of that talks about that, this is all 12.4.3, and 12.4.3 again gets triggered if we're using library functions. So we're taking a function out of an other PLC or another application and using it in a new application. And that older, other code was previously used, and now we want to use it in a new application. So that's the purpose of clause 12.4.3.

## 12.4.4 Overview and Modular Decomposition

Next up, we've got clause 12.4.4 and 12.4.4 has five bullet points to it, which we will address one at a time as we always do.

12.4.4 states: the application program shall be produced in a structured way so as to achieve. So, the stem here, before we get to the five bullet points, is stating that there's a certain structure, a method to the madness that we're looking for when we're building an application program. So the sky is not the limit. Well, it shouldn't be the limit in how you're developing your program, you're not starting with a clean sheet of paper. There's expectations for how we're going to structure things. And that methodology for how you structure things is going to be defined in your corporate standards. So there's kind of corporate preferences, but there's also a lot of this that falls back to who your equipment vendor is and, how do I make their equipment work? Okay, so let's hit the bullet points.

The application program shall be produced in a structured way so as to achieve bullet point one, modular decomposition of the functionality. So we want to break the overall functionality in the SIS into smaller, more self-contained, more easily testable, more easily understandable, more easily documented components. So I might have a two out of three vote that's going to close two valves that are in series with each other. I could write one piece of code to do the whole thing all on one sheet. As a matter of fact, I could use one sheet to write all of the code for every safety function in a plant that has 100 safety functions. But that gets unwieldy, hard to read, hard to understand. So you start doing things like breaking your program into separate sheets, one per safety instrumented function. And then at the safety instrumented function, you might take the input processing like a two out of three vote and separate it into its own separate sheet of logic, and that's something that you could probably reuse for a lot of different functions. You might want to take your one out of two output vote. Maybe it has alarms that compare position switches against the commands of valves and put all that into its own routine, which again is reusable. And once you test it and prove it once, it's going to be applicable for a lot of different places throughout your program. So, that kind of modular decomposition.

So, we have the program as a whole that gets broken down into individual functions. For individual functions. The input processing for each instrument group is separate. Every output group is separate, and then you have the logic that connects the inputs to the outputs. So that kind of modular step-by-step decomposition is, well, it's not just a good practice, it's a requirement there now, isn't it?

## Complexity Minimization and Testability

Okay, next bullet point down states that you're going to structure so as to achieve, you're going to keep the complexity of SIF application program to a minimum consistent with that of the complexity of the required SIF. So we're always going to keep it simple. KISS, keep it simple. Don't overcomplicate. Don't over-program. Don't put in all kinds of additional functionality that shouldn't be in the safety instrument system. So complexity: the absolute minimum that you need to have to do the job that you're trying to accomplish.

Bullet point number three, structured so as to achieve testability of the functionality, including fault tolerant features and the internal structure of the application program. So, we want to write the program so that we can test it, and if something fails, we have the hooks and the flags and the features to know what specific thing failed. So, if I have a two out of three vote, if one of those three disagrees, I want to know that it disagrees. I don't want to pass the test because two out of the three devices worked. I want the test to fail because one of the three devices didn't work, and I have a mismatched voting arrangement. So, write the program, structure the program so that you can view a smaller subset of things when you're doing your test. So if you're testing safety function one, I don't want to have all the data for safety function three, four, and five on the screen at the same time. Minimize what you're looking at and then make sure you have visibility in all of the parameters. So all of the variables from the beginning to the end you should be able to see when you're troubleshooting and testing your safety instrumented system functionality, whether that's just a software test or the full physical function test, site acceptance test that includes the field instrumentation.

## Traceability of Application Functions

Bullet point number four states that program structured so as to achieve traceability to and explanation of application functions and associated constraints. Traceability is a big item.

So if you're using a subroutine, you need to kind of trace back what subroutine am I using, who wrote it, how was it tested. If I'm using a global variable, I need to know where did that variable come from, how was it set? So, first off, we're modularizing things to keep everything that's important in one place, but beyond that, if you're sending data outside of your envelope, you're bringing data inside the envelope. I need provenance. Where did the data come from? How do I know that it's correct? How that I know that it was set properly? How do I know programmatically that it is going to do what I need it to do?

## One-to-One Hardware and Application Mapping

All right, finally, we have our last bullet point in clause 12.4.4, which states: again, the application program shall be structured to achieve one-to-one mapping between the hardware architecture and the application program architecture. what what the heck exactly does that mean?

That means that I need my virtual devices, which are simply variables. So if I've got pressure transmitter 101. There is one physical device that is pressure transmitter 101, and I am going to do an A to D conversion to convert the output or the electrical signal into a digital representation of that signal. So let's say it's 50% is my digital representation of 12 milliamps. I've got it. It's at 50%. That's what the safety PLC says.

Well, in a program, it's really easy to make a lot of different variables that store the same information. So I could have pt101, I could have pt-101, I could have PT underscore 101 that all got their data from the same starting point but are used in different applications for different reasons, and you probably want to avoid that. Now, the reason that you want to avoid that goes all the way back to my discussion of safety requirement specifications. If you write a value down in one place, you always know exactly what it is. If you write it down in two places or in three places, eventually they're gonna disagree with each other, and you never know which one's correct.

So don't have multiple virtual copies of a physical instrument in the field. Try to keep everything in one place so that you don't have mismatches because PT-101 is 50%, but PT-101 is 55%, and PT underscore 101 is 75 psi. Let's keep everything together. Let's keep everything consistent. That is the one-to-one mapping between your hardware architecture and your application program architecture.

## Clause 12.4 Wrap-Up and Preview of Clause 12.5

All right, so today's episode was short and sweet. Clauses 12.4.3 and 12.4.4. We didn't get into clause 12.5 because clause 12.5 is its own full one-hour episode. So I didn't want to jump into it prematurely without being able to finish it. And the subject of clause 12.5 is a very good a very interesting a very important thing and that is well basically testing the name of clause 12.5 is requirements for application program verification and then parenthetically review and testing. So I'm going to write my code. How do I know that it has been, that it does what it was supposed to do. How do I perform the tests? Do I just look at the code and that's fine? Do I run simulations? Do I talk to the fine folks over at Prolytics and have them build me an automated system that's going to automatically change variables, read the outputs, and make sure that the outputs are correct and basically completely automate this testing process with a full automation routine.

So, a lot of those things you need to think through, you know what? Maybe I should get somebody from Prolytics to sit in on clause 12.5 when we're talking about verification of application program requirements. That might be make for an interesting little discussion.

So all of this though, there's clause 12.5 covers basically an entire page. It starts on page 66, moves on to page 67, and has six subclauses. The six subclauses have up to one, two, three, four, five, six, seven, eight, nine bullet points in those subclauses. So, yeah, there's a lot.

So, we're going to talk next week about testing software, which is also part and parcel of testing your SIS logic solver. So I'm going to have a heart-to-heart detailed discussion with you next week. And we're really going to do some soul searching about end-to-end testing versus testing in parts and the real practical value, the ROI of doing testing in parts, but still making sure that even though you tested in parts, there's going to be so much overlap between the tests that no single failure of any failure mode of any component is going to be able to escape from the testing. All of that is going to sit in clause 12.5, which we will talk about next week. See you then.

## Episode Sign-Off and Vertigo Product 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 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.