Functional Safety Podcast: episode (S1E3) is now available

Introduction, Host Background, and Disclaimer

Normative means that you have to do it. Informative, on the other hand, is best practices, background information, and ultimately, you don’t have to do it. 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 2: Normative References Explained

In this episode of the podcast, we’re going to start by talking about Clause 2 of the IEC 61511 standard. And that’s not going to take a long time. It’s really short. Two sentences and then three reference documents. And then immediately after that, we’re going to get into definitions, which are actually more exciting than you would think. And I will get into that because as a Standards Committee member, let me assure you, the Standards Committee spends more time arguing about definitions than absolutely anything else that goes on in the Standards Committee meetings.

Clause 2 starts with two sentences that kind of set things up. And they are. The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the reference document, including any amendments, applies.

Okay, so that’s kind of the setup. And then after that, you’re going to get a list of the documents that are applicable, that are normative. Now, when we say something is normative, that means that it is the basis for the rules. It is something that is not optional. It’s not a suggestion. It’s not a best practice. It is a rule. It is a requirement that you must follow to be in compliance with the standard.

Okay, that differs from informative. Informative means we are providing best practices, general guidance, background information. And if something is informative, you don’t have to follow it. You don’t have to comply with it to be compliant with the standard as a whole. So the difference between normative and informative is critical when you’re in any activity where you’re having to comply or follow standards.

And with respect to IEC 61511, a lot of the standard is normative, specifically clauses 5 through 19. And some of the clauses are informative. And some of the parts are informative. So part 1 of IEC 61511 contains all the normative requirements, whereas part 2 and part 3 are informative. You don’t have to follow them. They’re giving you additional background information and best practices to follow.

And also, it’s critical to remember when you see something in the text of the standard, even in the normative part, if it begins with the word note, that immediately transfers you to the status of being informative as opposed to normative.

Okay, so what did the committee members think was so important when they were writing the 1511 standard that they decided to incorporate entire documents to be normative? And the answer is that there are three documents, and they are all other IEC documents.

They are all parts of the IEC 61508 standard. And those are going to be the first three parts of seven parts. So let me read them off to you. The first one is IEC 61508 Part 1, 2010 edition, Functional Safety of Electrical, Electronic, Programmable, Electronic Safety Related Systems, Part 1, General Requirements. The second document is Part 2 of the 6508 Standard. And Part 2 is entitled Requirements for Electrical, Electronic, Programmable, Electronic Safety Related Systems. Okay, that’s the title. And for those of us that are in the know, Part 2 of 6508 is actually the hardware part.

The normative requirements in 1508 sit in Parts 2 and 3. Part 2 is going to be the hardware requirements. And Part 3, the title of Part 3 is what it is, which is software requirements. So you’re obligated to follow 6508 Parts 1, 2, and 3 because they are incorporated by reference. They are normative references to the IEC 61511 Standard. So everything that is discussed in the general requirements, everything for hardware, everything for software, it is a normative reference.

It’s something that you can’t ignore. And that’s, you know, basically what the Standards Committee decided was going to be important. Now, those are the normative references. If you scroll down through the standard and try to find informative references, you are not going to find any. So all we have in terms of normative references is the 3 IEC 61508 Standard. And you will note as we go through this discussion that the information out of 6508 is going to come back at you. There are areas where 1508 points to 1508 as an alternate method to completing some of the techniques.

The one that sticks out in my mind would be hardware fault tolerance. You can follow the rules in 65011 or you can follow the rules in 6508. So the Standards are fairly tightly tied together. They reference each other. So that’s why they are listed as normative reference and the standard has no informative references.

So that’s it. That’s all of Clause 2. Shouldn’t take you more than 30 seconds to read because, well, I read it to you and it took less than 30 seconds. All right.

Clause 3 Terms and Definitions Overview

With that, let’s go ahead and move on to the next section of the standard, which is going to be Section 3, Clause 3, Terms, Definitions, and Abbreviations. Okay. Clause 1 is a very, or Clause 3.1 is very brief and it’s called Terms. And it says terms are listed alphabetically in Clause 3.2. And Clause 3.2 is called Terms and Definitions. I really don’t understand why Clause 3.1 is there. It just refers to Clause 3.2. But anyway, I digress. Let’s get into it.

3.2 talks about terms and definitions. And it’s going to define words that are used in the standard with the specific context of how that term is used in the standard.

This section, believe it or not, to most people it seems like a throwaway. When you’re going and you’re reading a standard to understand the content, understand the purpose to be able to deploy that standard, it’s not really common that you will read the definitions first. Generally, you’ll go into the requirements. And then when you hit a word that you don’t understand how it’s being used or you want to understand more about the context, then you’ll back up into the definition.

So as a consumer of the standard, the definition section is kind of a throwaway. I’ll look at it if I need to look at it. But if you’re on the standards committee, let me assure you that it is absolutely different.

There is nothing more important than definitions to many of the standards committee members. Therefore, you will have arguments for days on end on what a definition of a term means. And, you know, this is one of my pet peeves of the standard is that as time progresses, the definitions get more circular. They get more vague. They get more internally contradictory.

Now, let me explain why that happens. Because, you know, you’re talking to a 30-year veteran of the standards committee. So I know exactly why these definitions end up getting so obtuse and difficult to understand. And it’s because there’s disagreements on what the term means. So if you have a couple of different people on the standards committee that have diametrically opposed views on what the standards should present. And they are on opposite sides of what a term should mean in the standard. The fight will ensue where person A argues for one interpretation.

Person B argues for another interpretation. And they come to an impasse. So the wording gets muddled.

Words get added. Words get changed. And the fight continues. The words continue to get muddled and changed. And the fight continues. And the fight will continue until two people with diametrically opposed views can read the definition. Definitions sometimes get muddy because people with different opinions want to read the same words. But be able to come to different conclusions on what those words mean.

All right. I’ll try to unpack a lot of this for you as we’re going through the definitions. But let me start with Clause 3.2. There is one normative sentence which says, For purposes of this document, the following definitions apply.

There is more in Clause 3.2. And it’s kind of weird because I would expect to see the word note making it non-normative, informative. But it doesn’t have the word note in front of it. But it does have the smaller font size to imply that it’s a note. So take that with a grain of salt. Maybe it’s a note, informative note. Maybe it’s not. But here we go. This is the additional language in Clause 3.2. In some cases, these definitions differ from the definitions of the same terms in IEC 61508 Part 4. In some cases, this is due to the terminology used in the process sector.

In other cases, these definitions have been aligned with other relevant definitive references, such as IEC 60050, the International Electrotechnical Vocabulary. That’s going to be ISO, IEC Guide 51, dated 2013. However, unless otherwise stated, there is no difference in the technical meaning between these definitions and the definitions have the same terms, the definitions of the same terms in IEC 61508 Part 4.

So 1508 Part 4 is the definitions section of IEC 61508. And sometimes we use different terms in the process industries than you’re going to find in the equipment vendor standard that is IEC 61508. So that’s kind of drawing out the highlight that there may be different terminology between the two.

Okay, so moving on. Now we’re going to actually hit the definitions themselves.

Definitions: Architecture Configuration and Asset Protection

So I’m going to kind of punch through these when the definition is obvious and not very controversial. But in a lot of cases, I’m going to pause and delve into the definition a little bit more deeply.

Okay, 3.2.1 is architecture configuration. Okay. All right, I’ll come back to that in just a second because this is very interesting. The definition is specific configuration of hardware and software components in a system. That’s the definition of architecture configuration. And then there’s an informative note, note 1 to entry. In the IEC 61511 series, this can mean, for example, arrangement of SIS subsystems, the internal structure of a SIS subsystem, or the internal structure of SIS application programs.

Okay, right out of the chute. We’ve got all kinds of confusion and definitions that are, shall we say, not necessarily helpful, a little bit vague. Okay, first item. I, when I’m teaching training classes, will always say that the clause 3 is semi-alphabetical. And that’s because sometimes words are grouped together when they mean the same thing. So architecture is the first word. It begins with an A. But architecture and configuration generally mean the same thing or can be implied to mean the same thing in a certain context. So architecture with A and configuration with C are the first entry.

And there are a lot of other words that come before configuration that are way earlier in the chain. So that’s why I say it’s semi-alphabetical. So yeah, sometimes the definitions, there are multiple words that are used for the same concept. And they’ll all be listed out.

Now, look at this definition. Specific configuration of hardware and software components in a system. Normally, when you think architecture, you’re thinking, well, what is the voting arrangement? Is it one out of two? Two out of two? Two out of three? Two out of four? Three out of four? One out of one? That’s generally what we mean by architecture. But there is no reference of this whatsoever in the definition. It is, I mean, one out of two is the specific configuration of hardware.

But then when you tack on configuration, configuration means something different to a software developer than it does to a hardware developer.

And here we have our first case of different people being able to read a clause or read a definition and say, yup, that means what I think that it means, even though they are holding diametrically opposed views in their mind. Okay. And also, you know, I gave you that note to the entry. Remember, notes are not normative. They are informative. Okay. Okay. So hold on because, you know, this type of confusion and multiple meanings and adding notes to the normative part is going to continue.

All right. The next definition, 322, is asset protection. And the definition is function allocated to a system and designed for the purpose of preventing loss or damage to assets. So the standards committee needed to define the difference between instrumented functionality that is there for safety or an environmental protective purposes, which is covered by the standard. And then those instrumented functions that are there to prevent you from losing money, which technically are not covered by the standard, but you can use the methods in the standard to apply them. Okay.

Definition 3.2.3: Basic Process Control System

So even speaking, people will say BPCS instead of basic process control system. The definition is system which responds to input signals from the process, its associated equipment, other programmable systems, and or operators and generates output signals causing the process and its associated equipment to operate in the desired manner, but which does not perform any SIF.

Okay. Okay. You would think that the BPCS is a very standard and very simple concept. I will tell you that it is not.

All right. Today is January 4th, 2024. It’s when I’m recording this. The podcast probably won’t be available for another couple of weeks, but I attended in the beginning of January. The IEC 65C committee. So IEC 65C is the committee that publishes the 65… standards. And I’m specifically involved in IEC 61511, 61511.

Now, in this committee meeting, we argued for two entire days. Well, the committee argued for two entire days. The committee meeting was being held in Osaka, Japan. I was at the Purdue Process Safety and Assurance Center Conference in West Lafayette, Indiana. So the committee meeting started at 6 p.m., went to about 4 a.m. And obviously, I kind of fell asleep around midnight most days. But two days of this committee meeting were dedicated to the concept of what do we call an instrumented function that resides in the SIS hardware.

So let’s say… And, you know, I’ll throw out some brand names. I’m going to be throwing out some brand names over the duration of this podcast. Don’t take my examples to be any kind of endorsement. But let’s say I’ve got a function that’s residing in my Triconic system. I got a Tricon V9 Safety PLC. Everyone will say, yeah, that’s a safety instrumented system. That collection of hardware components is a safety instrumented system. And let’s say that I have a function that is in that hardware set.

But it is not SIL 1 because the risk reduction requirement is only a risk reduction factor of 2 or a risk reduction factor of 3. One order of magnitude of risk reduction is not required for that function. So the operating company decided to call that… Let’s just say they called it SIL 0. That function is not a SIF in accordance with the standard. That function coming out of a LOPA would be called a BPCS function. I know if that makes your head hurt, it makes my head hurt too.

But the designation of whether it’s a BPCS function or not, you would think that that would be based on what collection of hardware that function is going to reside in when in fact it does not. It simply means that the functionality is done in some sort of instrumented control system. And I’m not claiming a risk reduction factor of greater than 10 for that. So if you were under the impression that a BPCS meant that it was in your Honeywell DCS and everything that was in the Tricon safety PLC was an SIS, well, I have some bad news for you.

Because in the parlance of the standard, technically, a function that is not required to achieve SIL 1, even though it resides in your safety PLC, is still a BPCS function. In the eyes of the standards committee. Now, the standards committee has to do this. And after listening to two days of arguments, I could probably spend a good half hour here telling you why the decision of the standard committee makes sense, that we can’t call something a SIF unless it’s required to achieve a risk reduction factor greater than 10. But you as an operating company have flexibility.

So routinely in my consulting work, I will document functionality as SIL A or SIL 0 to imply that this functionality is going to reside in that safety PLC, in the Triconics or in the Safety Manager or whatever safety PLC you’re using. But it does not need to achieve SIL 1. And a company, an operating company, is completely at liberty to set up rules beyond what the IEC 61511 standard requires. So you can define a SIL A and you can define how you’re going to design and test a SIL A. As long as you’re not in conflict with IEC 61511 and you’re adding additional rules, that’s perfectly fine.

But for a variety of reasons and kind of going forward, the next edition, IEC 61511, don’t expect to see SIL 0 or SIL A as something that the standard has accepted and defined. If it’s not SIL 1 or greater, it is not a safety instrumented function, which defaults it to being a BPCS function, even if it resides in the safety PLC.

But then again, now most of the time you have to remember that when we say BPCS, what we actually mean is something that resides in your distributed control system, in your DCS. The same controller that controls everything else in the process and is not dedicated to safety purposes. Okay, there are a couple notes on the definition.

Note 1 to the definition is that a BPCS includes all the devices necessary to ensure that the process operates in the desired manner. Note 1 is loaded. And Note 1 is going to be critical when we start doing layer of protection analysis and kind of the process of grouping or chunking equipment together into functions. So what Note 1 says is all the devices are part of the BPCS. So the BPCS is, again, it’s not just the logic solver in the middle. It’s the sensors that bring data in. It’s the final elements that are activated by the DCS. And it’s also the human interaction of operators.

All that stuff is considered to be part of the basic process control system.

When we get into the risk analysis that is going to yield our safety instrumented functions, you’re going to see that when we say that there’s a BPCS failure, we don’t mean the CPU of the logic solver. We mean the entire loop. Maybe the failure was tap plugging even before the transmitter. Maybe the failure was that someone removed the instrument air tubing from the valve and it went to the closed state. That entire group of equipment is put together when we say something is a BPCS function when we are doing layer of protection analysis. So more on that when we get to clauses 8 and 9.

Okay, note two to the entry. A BPCS typically may implement various functions such as process control functions, monitoring, and alarms. So BPCS means more than just control loops. It’s the indicators. It’s the alarms. The BPCS does a lot other than just execute control loops. Okay, so yeah, we spent some time on that definition.

And again, this kind of goes into the background, the discussions in the committee, and understanding that I would probably say 90% of the politics, the equipment vendor versus end user kind of intrigue that happens in the standards committees. It all boils down to the definitions. The definitions are critical for that type of thing. So yeah, hey, SIL 0, SIL A, even though you use it, it’s not in the standard now. It’s not going to be in the standard in the next edition, but that doesn’t mean you can’t use it as long as you don’t conflict with the standard.

Definition 3.2.4: Bypass and Override Types

Okay, 3.2.4 is the definition for bypass. A bypass is an action or facility to prevent all or parts of the SIS functionality from being executed. Okay, that’s the definition. It’s an action or facility, might be equipment, might be something that an operator’s doing, that is going to prevent all or parts of the SIS functionality from being executed.

The word all in there scares me to death. It scares me to death the concept that you would have a single switch that you can flip that will bypass all of the functionality of an entire safety instrumented system. So a safety instrumented system, you’re thinking is going to have hundreds of inputs, hundreds of outputs, and with one action to be able to bypass all of them is so powerful. Why would anyone do that? No, you’re kidding me, Ed. No one would actually do that. I hate to tell you this, but I have seen it.

I have seen it at multiple relatively large oil refineries that their safety PLCs have a wiring system that will allow you to flip a switch that is going to directly put power on all of the outputs of the SIS bypassing the logic solver entirely.

So, hey, the more time you spend in the industry, the more crazy things you will see. Some of these systems are actually still in service today. So I don’t recommend being able to bypass all of a safety instrumented system, but apparently the standard recognizes that it does happen.

Okay, now, in terms of bypass, there are two notes, and the notes are very long. So let’s start with note one to entry. Examples of bypassing include, and it’s going to give you four examples of what a bypass is. Number one is the input signal is blocked from the trip logic while still presenting the input parameters and alarm to the operator. Okay. Two, the output signal from the trip logic to a final element is held in the normal state preventing final element operation. Okay.

So we’re bypassing the input in part one. We’re bypassing the output in part two. We at Kenexis recommend bypassing inputs only. That’s our recommendation. It’s the weakest form of bypass. We don’t recommend bypassing the output signal because there are many inputs which might want to trigger a single output. So that’s kind of generally too strong. And you need to think about all the inputs that you’re bypassing that can activate a single output. Okay. Third item, a physical bypass line is provided around the final element.

So if you have a shutoff valve, you might put in block valves around the shutoff valve and a bypass valve in the piping around that valve.

Back when I worked at UOP, we call that an E-assembly, which is the collection of valves that are going to allow you to take a valve out of service while the plant is continuing to run. And that configuration is actually becoming more and more common, especially as large petrochemical facilities and refineries want to push their turnarounds out to seven years, making it impossible to achieve even SIL 1, SIL 2 at those extended test intervals.

So you need to put in the ability to not just do a partial stroke test, but to do a full functional test of a valve, maybe even do maintenance on that valve while the plant is continuing to be in operation and to run. So that’s item three, physical bypass around the final element. And the fourth example is a pre-selected input state on or off of an input is set. Or forced, set to force by means of an engineering tool, for example, in the application program.

So we’re going to talk more later on in clause 11 and in clause 15 when we start talking about testing in a little bit more detail about the pros and cons of forcing logic in a PLC as a means of bypass either for operational or for testing purposes. I’m hot and cold on it. I will save my comments for that later. It’s not the end of the world if you’re doing it, but do you really want to do it?

Okay, note two to bypass is other terms are also used to refer to bypassing. These terms include override, defeat, disable, force, inhibit, muting.

So we want to make sure that when we start talking about bypasses in the standard and we set rules for bypassing, that we let people know that, well, something that you’re not calling a bypass is actually a bypass. And the requirements that we’re setting for bypass are going to apply to that action also. So we made sure to list out a bunch of other things that you might be calling a bypass so that you don’t try to skate on the definitions and the requirements that we set up for you later on in clause 11 in clause 15.

Definition 3.2.5: Channel and Voting Architecture

Okay, next definition is 3.2.5, which is channel. Channel is a device or group of devices that independently perform a specified function.

Channel is an important concept when you’re doing your SIL verification calculations. So if you look at the Kenexis Vertigo software tool, which I cannot recommend more, it is definitely the best way to do your SIL verification calculations and document the SIS safety life cycle.

You will notice when you look at the definition of a sensor that we don’t just have the failure rate for a sensor. we have, we basically allow you to build a channel. So for a sensor, a channel could include multiple things. It might include a process connection. So there may be taps to connect a pressure transmitter to the process. There may be manifolding that might have dangerous failure modes that you might want to consider. The device itself is part of the channel.

And then there might also be things like intrinsic safety barriers that can have dangerous failure modes that are part of the channel for that sensor. And maybe you might even want to include the input card channel. Or if you’re using something like Emerson’s Delta V CSLS safety PLC, which is the charms version of their safety PLC, then the charm, which does your analog to digital conversion on the input, would actually be part of the sensor channel.

Now, once you build the channel, you add all the failure rates together because you have a logical or. So the channel can fail because the taps plugged or because the transmitter doesn’t work or because the barrier failed in a dangerous state or because the charm failed. So you add all those failure rates together because it’s a logical or. And then if you have a two out of three vote, you’re doing math on two out of three channels as opposed to two out of three sensors.

So keep that concept of a channel in mind as you’re doing your SIL verification calculations, as you’re doing your studies. It’s very important to include everything in a channel before you do, before you plug those failure rates into your equations.

Now, the definition of channel is going to have four notes to it. Those four notes are number one, the devices within a channel can include IO devices, logic solvers, sensors, and final elements.

Okay, so a channel, I talked about channel in my definition when I referred to the Vertigo software tool for a channel for inputs, a channel for outputs, but you could basically make an entire sensor to final element channel. It’s not out of the realm of possibility that you could have a safety function that is going through two completely separate logic solvers. Okay, with separate inputs and separate outputs.

All right, note two to the entry, a dual channel, i.e. a two channel configuration is one with two channels that independently perform the safety function. Channels may be identical or diverse. So if you have a two channel system, they do the same thing and they might be doing the same thing with the same hardware. They might be doing the same thing with diverse hardware.

So back in my early days at UOP, so let’s say the 93 to 95 time frame, I was responsible for building the safety PLC called the Lockhopper Control System, which is, it’s a safety critical controller at the end of the day with some shutdown functionality, but I digress. And our early versions of the Lockhopper Control System were two diverse channels. So basically we ran the logic through a Modicon PLC, and then we also ran the same logic through an Allen Bradley PLC5 PLC system and then voted the results.

So that’s a dual channel system using diverse hardware, but if we would have used PLC5 for channel A and channel B, it’s still a two channel system. It’s just that both channels are identical in terms of the hardware that they use.

Note three to the entry, the term can be used to describe a complete system or a portion of a system. Okay? For example, sensors are final elements, which is what I discussed being built into our Vertigo tool. You define channels for sensors and you define channels for final elements.

And note four to the entry, a channel describes SIS hardware architectural features often used to meet hardware fault tolerance requirements. So, we’ll come back to hardware fault tolerance when we get to clause 11, where it is described in detail. But the use of redundant channels to achieve an objective is the key for achieving higher levels of hardware fault tolerance. if one channel fails, the other channel will still be able to bring you to a safe state.

Episode Wrap-Up and Vertigo Software Overview

All right, so with that, that ends episode three of the podcast. We have just dipped our toe into the definition section and you would think that, you know, we could have just prattled through all those definitions really quickly. But as I warned you, there’s a lot of information and a lot of politicking that went into these definitions and I need to lay it all out on the line for you to not only explain what the definition is, I will also explain why it was confused.

I’m not going to tell you who confused it, maybe I might hint around at it, and what your real options are and what the real definition is as opposed to maybe some of the gobbledygook that you see. So kind of a more practical definition as opposed to the academic definition that’s contained in the standard.

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.