Kenexis announces new Functional Safety Podcast now available on Spotify

Please join Ed Marszal, President and CEO of Kenexis, for the first episode of the inaugural season of our new Functional Safety Podcast on Spotify where he begins his discussion of the IEC 61511 standard.  As a Principal Engineer (PE) himself with decades of experience in safety instrumented systems, Ed brings a unique perspective to this podcast, having actively contributed to the ISA 84 committee since 1994.

In this inaugural season, Ed will delve into the IEC 61511 standard, examining each word’s significance. He provides detailed insights into the standard’s interpretation and application, complemented by personal stories from his career and committee discussions.

Welcome and Host Background

Let’s start at the beginning. Welcome to the Kenexis Functional Safety Podcast. I’m your host, Ed Marszal, President and CEO of Kenexis. Kenexis is a technical safety consultancy. We help chemical process industry companies by helping to facilitate process hazards analysis studies like HAZOP and LOPA, and then use the results and recommendations of those studies to design engineered safeguards like safety instrumented systems and fire and gas detection systems.

We assist in the performance of every step in the safety lifecycle, including the selection of SIL targets, calculations to verify the achievement of those targets, development of SRS or safety requirement specifications, assistance in oversight of commissioning and validation, and the development of test plans. In addition to performing consulting services, Kenexis also provides the industry-leading suite of software tools to assist in the performance and documentation of technical safety tasks, including our best-in-class Vertigo software for SIS safety lifecycle management.

Kenexis has decades of experience in implementing safety instrumented systems, but more important to this broadcast, I personally have unique experience not only in the design and implementation of safety instrumented systems, but an inside knowledge of the standards that define SIS. While still working in my first position out of college at UOP in 1994, I was elected to join the ISA 84 committee to provide chemical process and risk analysis expertise to a group that was primarily staffed with experts in reliability engineering of electronics.

My participation in the committee made a mark even in the first version of the functional safety standard, which was the ISA 84 1996 version.

I have been on the IEC 61511 standard, actively participating, and in addition to that, I am also actively participating in the IEC-SC-65, which is the committee that is currently overseeing the maintenance of the IEC 61511 standard that the IEC 61511 standard evolved into.

In this first season of the podcast, we’re going to focus on the IEC 61511 standard, functional safety, safety instrumented systems for the process industry sector. Doing a deep dive into every word of the content of the standard, in addition to the content of the standard, I will also be providing a lot more depth of information on what the standard means, what it says, and how to apply it.

All this information is going to be brought to life with my own personal war stories of applying the standard over the course of a few decades, and some of the stories of the behind-the-scenes discussions of the committee members and the personalities that make the standard what it is today.

Before we start, though, 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’s 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 or any other location.

Clause 1 Scope and Safety Lifecycle Origins

So, as the title of the session implies, we’re going to start at the beginning of the functional safety standard. Section 1, Clause 1, which is the scope of the standard, which kind of defines, you know, what are we trying to accomplish in this standard? I think most everyone that’s listening to this podcast knows that this standard has to do with safety instrumented systems, but that can encompass a lot of different things.

So start out, Clause 1 is titled Scope, And it states, this part of the IEC 61511 gives requirements for the specification, design, installation, operation, and maintenance of a safety instrumented system, SIS, so that it can be confidently entrusted to achieve or maintain a safe state of the process. IEC 61511-1 has been developed as a process sector implementation of IEC 61508-2010.

Okay, so that’s kind of the lead-in paragraph. Seems pretty straightforward, but it’s a little bit loaded, and there are a few additional things that we should kind of supplement you with. Number one, it says that it’s going to give requirements related to specification, design, installation, operation, and maintenance. That’s a big scope.

This is where we first get into that whole concept of the SIS safety lifecycle. You’ll notice that this is not a narrow standard that’s only applicable to the design process. And let me tell you, from the earliest days of my involvement in the committee, that’s where a lot of the committee members were actually headed. So a little bit of inside information right out of the gate.

The ISA 84 standard, which was the precursor to IEC 61511, the reason that it’s called ISA 84 is because it was written by Standards Panel 84. Well, why is Standards Panel 84 called SP Standards Panel 84? And the answer is that it was commissioned in 1984. So let that sink in for a second. The Standards Committee was impaneled in 1984, but nothing was delivered until 1996. You got to ask yourself, what the heck was the committee doing for that long?

It took them 12 years to deliver the first version of the standard, which compared to the current version of the standard is actually even shorter. Not that the 1511 standard is long by any stretch of the imagination, but it was originally shorter. So what took them 12 years? Well, the environment when the committee was impaneled was the early to mid-1980s.

This is after kind of a large spate of accidents that had happened in the chemical process industries. We’re talking about things like Bhopal. We’re talking about the Pemex explosion that was all of the blevies of the LPG.

Phillips, the Phillips Pasadena chemical complex accident was one of the big drivers in the United States that really got a lot of governments and a lot of regulatory agencies around the world interested and worked up and writing regulations to make sure that the chemical industries were taking care of business because that run of accidents in the early 80s kind of implied to the world that, well, maybe the chemical industry is not taking care of business in the way that it should.

So a lot of regulatory work was taking place to make sure that the chemical process industry started taking care of business. And at the same time, a lot of industry groups, including ISA, decided to kind of start front running things and start putting together standards because they knew that the regulatory agencies like OSHA were going to be writing regulations. So it would be better to have OSHA point at existing regulations rather than try to write their own requirements. So that’s kind of the environment.

Now, when the committee was first developed, there were a lot of people on the committee, as you can imagine.

And in the ISA committees, there is a wide range of people from academics to equipment vendors, to operating company people, to consultants, engineering company people and so on and the first impulse at this point in time was to write a prescriptive standard because prior to this point in time that’s how most standards were written the 80s and 90s were the time period where there was a transition to move from prescriptive standards which is essentially a cookbook of the things that you need to do

and transition into a performance-based standard, which gives the implementers of the standards more flexibility on how they do things, but with the caveat that they’re going to need to quantitatively assess the performance of what they’re doing and verify that it achieves a certain performance target.

Prescriptive vs Performance-Based Standards Debate

So even in the 90s when I entered the committee, there was still a strong contingent of people who wanted a SIS design cookbook. But that kind of failed because in the committee discussions, there were many, many discussions of where the prescriptive cookbook fails.

So one equipment vendor might say, well, everything will be better if you use double block and bleed valves instead of a single block valve. And then there would be some companies with energetic chemicals that would say, no, I can’t put in a double block valve because if I trap the material that I’m making in between two closed block valves and it warms up and I cross over the self-accelerating decomposition temperature line, I’ve just basically created a bomb. So I can’t double block things. I need to get safety using a different approach.

And then there were other vendors that would say, well, if I use switches instead of transmitters, everything will be okay. The transmitter vendors would say the exact opposite thing. Then the logic solver vendors get in the room and everybody’s basically kind of lobbying for their hardware solution to be prescribed as the official way of doing things.

that was like literally six to ten years of arguments of the committee eventually the committee came around to the process that they’re going to need to develop a standard that’s performance-based allowing the end users the operating companies to make decisions that are appropriate for their application but then there’s also the additional step of verifying that they’ve achieve the performance target. And we’ll get into a lot of that as we go through this podcast. But right now we’re still in the first sentence of scope, which basically says that we’re not doing a cookbook just for the design.

We’re looking at the entire safety life cycle, including things that aren’t traditional instrumentation and control engineering.

The reason for that is that there were studies, the most famous study was called Out of Control. It was done by the health and safety executive in the early 80s that came to the conclusion that simply providing a cookbook for design of the safety instrumented systems will not solve the great preponderance of the reasons that safety instrumented systems fail.

So that report, that out of control report from HSC, they determined that actually the preponderance, or not the preponderance, most of the failures, the highest percentage of failures of safety instrumented systems are related to specifications. So basically, the designers designed exactly what the specifiers said to do, but it didn’t achieve the objective that they were trying to achieve. So specification needs to be part of the process.

They also determined that a great deal of the failures of safety instrumented systems are related to improper installation, improper commissioning, changes after modifications, failures to properly maintain the system. So if the standards committee only developed a standard that focused on the design and created a cookbook of the design, then we would only be addressing a small portion of all of the causes of failures of safety instrumented systems.

So right out of the gate, in the first sentence of the scope, we lay down that we are talking about the entire life cycle from the conceptual design of the process, not the safety system, but the process, all the way to the final decommissioning of the system.

IEC 61508 Relationship and Normative vs Informative

Now, the second sentence says that this standard is developed as a process sector application of IEC 61508. We’re going to talk a lot about IEC 61508 as we go through this podcast series.

So IEC 61508, sometimes referred to as the equipment vendor standard. And for those of you in the process industries that are dealing with IEC 61511, calling the 1508 standard the vendor standard is probably a very good, comfortable thing to do.

Because in the process industries, you’re going to want to focus on what’s in IEC 61511 as opposed to what’s in IEC 61508. because 1508 is going to have a lot of additional information that is completely irrelevant to people who are applying safety systems and only relevant to manufacturers of the equipment that implement those safety instrumented functions. So 1511 part one is the standard that kind of narrows things down and provides the information specific to practitioners of the safety instrumented systems in the process industries.

Now, another key thing in this loaded second sentence is that it is IEC 61511 part one. There are actually three parts to the IEC 61511 standard. The important one is part one.

So now I’m going to give you a little bit of an explanation of the difference between normative and informative. IEC 61511 part one contains the normative requirements. A normative requirement is something that you have to do, something that you have to implement. It’s not a suggestion. It’s not an option. It’s not informative information. It is the rules.

So the normative parts of the standard are the rules, which then are supplemented by the informative parts, which give you options for how to comply, give you background information, give you best practices, but anyone who is checking to make sure that you have followed the standard is not going to enforce those informative requirements because they realize that they only provide additional background and they’re not in and of themselves rules.

So the IEC 61511 standard part one contains all the normative requirements or all the rules whereas part two is completely informative. It’s going to be kind of structured in the same way. So for instance, A1 in part two is going to talk about clause one in part one. It’s going to give you the informative guidance or the informative information related to clause one.

Part three of the IEC 61511 standard is something that, boy, I’ll talk a little bit about it. I’m not a big fan of part three. I was there to see how the sausage was made and it was not pretty. The sausage making was happening in the late 90s and the early 2000s when a lot of companies didn’t have SIL selection processes yet. And it’s basically a kludge collection of a bunch of different approaches that a bunch of different companies used to pick SIL targets.

So it’s kind of inconsistent, provides a lot of maybe even potentially conflicting information. There are two different risk graphs that are completely different from each other. And LOPA really wasn’t even fleshed out that well. And LOPA is definitely the preferred approach that people are using these days to pick SIL targets. So I don’t know. I kind of consider part three a relic from the past. If you want to know how to do a LOPA, you can read my book. Now that book, it is also over 20 years old at this point in time. I definitely need to update that.

You can also look at the two really good books on layer of protection analysis from the Center for Chemical Process Safety. Appendix A of the part three is okay, but kind of going back to where I was before I got sidetracked, part three is also informative.

informative. So only part one contains the rules and part one is really the only part that we’re going to be talking about in this podcast or at least the first season of this podcast. Okay, so that is those two sentences and we’re still, you know, we’re about 20 minutes in and we’re still talking about the first two sentences of scope. So after that clause one, it says in particular IEC 61511 part one, and then you’re going to get a bullet list that begins with A and goes all the way to X. No, does it continue on from there?

Yeah, it goes all the way to X and with different bullet points that talks about what particularly IEC 61511 talks about.

Clause 1A and 1B: Scope Application and Responsibility

All right, so let’s hit bullet point A. So in particular, 1511 specifies the requirements for achieving functional safety, but does not specify who is responsible for implementing the requirements. So whether that be designers, suppliers, owners, operating companies, or contractors, this responsibility will be assigned to different parties according to safety planning, project planning and management, and national regulations.

Okay, so Clause 1A basically lays out the fact that we’re specking out a big safety life cycle. And there are a lot of different people in a lot of different organizations that might be responsible for performing those tasks. So the hazard and risk assessment might be commissioned by the HSE group, but outsourced to a third party HAZOP and LOPA facilitator. The detailed design of the SIS might be done by an equipment vendor. The commissioning and installation might be done by an electrical contractor and so on.

so what clause a is telling you it or 1a is telling you is that this standard is going to give you all the requirements and but it’s not telling you who is responsible for actually implementing those requirements that is going to happen in clause five though where you have to talk about the safety planning so safety planning we’re going to get to in clause five is going to lay down for a specific project or for an operating company who does what, and especially if you’re subcontracting some of these tasks out to an outside organization, what you need to think about.

So we will come back to this when we get to Clause 5. Clause 1b.

In particular, IEC 61511 applies when devices that meets the requirements of IEC 61508 series published in 2010 or IEC 61511-1-2016 is integrated into an overall system that is to be used for a process sector application. It does not apply to manufacturers wishing to claim that devices are suitable for use in SISs for the process sector. See IEC 61508 Part 2 and IEC 61508 Part 3.

Okay, so what are we getting at in Clause 1b? What we’re getting at in Clause 1B is this is for end users that are applying equipment into a process sector application. It’s an application standard, not an equipment design standard.

So it’s basically saying that if you’re an equipment manufacturer, you need to follow the rules in IEC 61508 Part 2 and Part 3 for the manufacture of your equipment. If you’re a manufacturer, don’t go claiming that you’re 61511 compliant. That’s not appropriate.

1511 is not for manufacturers. It’s for end users who are applying equipment as opposed to manufacturers who are manufacturing the equipment. And the manufacturers follow 61508.

Clause 1C: Relationship Between 61508 and 61511

Clause 1c. So clause 1c says, in particular, IEC 61508 defines the relationship between IEC 61511 and IEC 61508.

And then, parenthetically, it says to see figures 2 and 3. So the standard in Clause 1c is kind of laying out. It knows that there are two different standards. There’s a 1508 and a 1511. They’re different from each other. Sometimes you use one. Sometimes you use the other.

And the relationship is further defined in figures, which obviously in a podcast, I can’t show you the figures, but I will tell you about them a little bit. So figure two basically has three boxes in it. Well, a circle and two boxes.

And it basically says that there are standards that are relevant to the process sector related to safety instrumented systems. One of them is IEC-61508, and that’s applicable to the manufacturers and suppliers of devices. The other standard is IEC-61511, which is for safety instrumented system designers, integrators, and users. So a gigantic picture, which basically boils down to saying 1508 is for manufacturers, and 1511 is for implementers and users.

Figure 3 is a little bit more complex because it goes to a little bit of detail of kind of further clarifying what was in figure 2.

So it basically says, okay, well, there are standards, 1511 and 1508 that are applicable to different tasks. It then breaks this down into hardware and software. So basically it says, if with relation to hardware, if you’re using devices that are designed in accordance with 6508 that you purchased, you can use 1511. If you’re using devices that you have prior use experience with, and oh, we will talk about prior use experience a lot, but that’s not until we get into clause 11.5. So there’s some time before we get there.

If you’re using prior use experience devices, you can also use IEC 61511. But even if you’re an end user, if you are manufacturing a hardware device, you’re going to need to follow the rules in IEC 61508.

So for some bizarre reason, you’re basically manufacturing your own device. Even though you’re an end user, you still need to follow 6508.

Programming Language Categories and Software Rules

Now, on the software side, programming is an issue. Clause 12 is dedicated to programming. We’re going to talk a lot more about programming when we get to Clause 12. But basically, when you look at the 6508 standard and the 1511 standard, there are three types of programming languages. Fixed programming languages, limited variability languages, and full variability languages. So fixed program languages are things like the code that’s running in a smart transmitter. So if you have a smart transmitter, it’s running a program, but you can’t change the program. You can’t edit the program.

All you could do is change parameters like zero and span. So the program is fixed. It was written by the equipment vendor and put on that chip and you can’t change it. Limited variability language is what most of you are going to be using to program your safety PLCs. So a limited variability language is going to be something like ladder logic or function block diagrams. These are languages that your equipment vendor provides you with a maintenance and engineering application where you can write code in those limited languages to make the safety PLC do what it’s supposed to do.

But the equipment vendor basically makes it extremely difficult for you to mess things up. And that limited variability allows you to continue to program using a safety PLC and using the rules in IEC 61511. Now, the last one is the full variability language. And the full variability language is the complex one. So full variability languages are things like C, C++, C Sharp, Lisp, Python, Java, JavaScript. Full variability languages let you take control of the entire computer, including all the memory, all the processing, all the peripherals.

And full variability languages have lots of pitfalls of things that can go wrong. So you can make mistakes Like you can lose pointers to where your memory is located.

You can generate a leak that will fill the memory up. In JavaScript, the commands can actually execute out of order. So there are a lot of potentially dangerous failures that you can generate programming in these full variability languages.

which then requires you to do a lot of testing, a lot of specifications to make sure that your program doesn’t contain any of those errors. And that are those kinds of rules for making sure that full variability languages don’t result in failures when you program them is the subject of hundreds of pages in the IEC 61508 standard part three, which is different from the handful of pages in clause 12 of the 61511 standard. So my advice is actually, if you’re an end user, just use limited variability languages. There’s almost nothing you can’t do in the limited variability languages.

Avoid using full variability languages. But if you do, if you want to go down that road, you basically need to follow all the hundreds of pages of rules in IEC 61508, the same ones that the hardware manufacturers are supposed to follow.

Okay, so that is 1C.

Clause 1D: Embedded Software and Full Variability Languages

Let’s move on to the next item, which is 1D. 1D says IEC 61511 part one in particular applies when the application programs are developed for systems having limited variability language or when using fixed programming language devices, but does not apply to manufacturers, SIS designers, integrators, and users that developed embedded software or use full variability languages.

Okay, so I just explained part three, and clause 1D here actually is the text that references figure three, even though figure three is referenced in clause 1C. Bottom line here, 1511 is limited variability language, fixed programming language.

If you want to use full variability language or if you want to develop embedded software that resides on a chip in a safety PLC, you’re a manufacturer essentially and you need to follow the full set of rules in IEC 61508 part three to develop your software.

Clause 1E: Process Sector Industries and Adoption

All right, Clause 1.E. In particular, IEC 61511 Part 1 applies to a wide variety of industries within the process sector. For example, chemicals, oil and gas, pulp and paper, pharmaceuticals, food and beverage, and non-nuclear power generation. Okay, so that’s what the Clause of the Standard says.

basically what we’re doing in Clause 1E here is we are trying to explain what the process industries are if you didn’t already know what the process sectors are. So the process sectors are effectively the wet chemical industries, but there’s a little bit more beyond that. Now, in Clause 1E, this is the first time that a note shows up. So you’ll see also that beneath 1E’s text, there’s more text that says Note 1. Within the process sector, some applications may have additional requirements that have to be satisfied.

Okay, so when you see these informative notes, you have to remember that they are informative. So I spend a lot of time talking about normative clauses versus informative clauses. Anytime you see something that begins with a note, you are not obligated to follow those requirements. Anything with a note is informative, meaning they’re providing additional background and additional information, but not setting an additional requirement.

Okay, so let’s unpack this a little bit. Clause 1e talks about the process sector. So chemicals, oil and gas, pulp and paper, pharmaceuticals, food and beverage, and non-nuclear power generation. And in that list, you think of the traditional wet chemical industries. We’re basically pumping chemicals around, having chemical reactions. This is going to happen in fine chemicals, specialty chemicals, bulk chemicals, petrochemicals, oil and gas, whether you’re upstream or downstream.

Now, those industries, and it’s been a long time since 1996 when the first version of this standard was kicked out, but those industries have incredibly good adoption of this standard and the approaches in this standard.

But some of the other industries have not. So pulp and paper, there’s a lot less adoption of this standard. And I will come back and explain why in just a second. Pharmaceuticals has implemented it to some degree. Food and beverage, again, to some degree. Not as much as the core chemical industries. and non-nuclear power generation, depending on where you are in the world, sometimes it’s completely ignored.

Now, why do some industries apply it and other industries don’t apply it?

Well, this is an argument that I had in the Standards Committee with one of the Standards Committee members who shall remain nameless. and ultimately what we’re concerned about with or I shouldn’t even say that if you go back and you kind of look at who has the authority to make you do things and who doesn’t have the authority to make you do things the standards committee themselves can make rules and complain you know about whether or not you’re doing them night and day, but they have no authority to actually make you do anything. There’s a phrase that we’re going to run into a lot.

I’m going to talk about a lot, and it’s something that you’ll hear more in the U.S. because a lot of our regulations and legislation is written this way. But there’s something called the authority having jurisdiction.

So that could be a regulator like OSHA, the Occupational Safety and Health Administration, who comes into your plant and checks the working conditions and enforces rules. It might be something like a fire marshal who is going to kind of at a local level be present at facilities to make sure that they’re following all the rules related to fire safety.

So if you kind of look at the IEC 61511 standard or the ISA 61511 standard in the U.S., who actually is the authority having jurisdiction that would enforce that you do this? Well, in a lot of cases, it would be OSHA, especially if you’re a chemical plant that is covered by the process safety management rule. But if your chemical plant, your process plant, is not covered by the process safety management rule, then OSHA might not have jurisdiction, at least not under the PSM rule. So there might not be an authority that’s actually checking or cares that you’re actually implementing this.

okay so that’s the kind of the starting point is you have to know what your industry is what the authority having jurisdiction is and what they want you to do and even when an authority having jurisdiction knows about the isa IEC 61511 standard they still might not care whether or not you’re implementing it because especially and again now i’m going to kind of more narrowly focus things, if you’re talking about OSHA, if you’re talking about process industry applications that are covered by the OSHA process safety management rule, there is a concept contained

in that regulation called recognized and generally accepted good engineering practice. So the ultimate driver of implementation of the ISA IEC 61511 standard in the USA is that a lot of companies that are regulated by OSHA under the process safety management rule need to comply with Clause J, or the mechanical integrity section of the process safety management standard, that says that they need to design their equipment and test their equipment in accordance with recognized and generally accepted good engineering practices.

And it just so happens that an OSHA-approved, recognized, and generally accepted good engineering practice for how to design safety instrumented systems is, is, well, at the time, it was ISA 84, which is now IEC ISA 61511. So if you comply with the IEC 61511 standard, you’re going to be compliant with the mechanical integrity requirements of the OSHA PSM rule for safety instrumented systems.

But what OSHA is very careful not to do is to say that the ISA IEC 61511 standard is the only way to do it. So the operating companies, in accordance with the PSM rule, are able to select whatever recognized and generally accepted good engineering practice they want.

They can choose to say, well, I don’t want to follow the IEC 61511 standard. Instead, I’m going to follow Ed Marszal’s 20 Awesome Rules for SIS Design, and that’s going to be my basis for how I design my safety systems. Now, in case you’re wondering, no, I don’t have a standard called Ed Marszal’s 20 Awesome Rules for Designing Safety Systems. But there are other competitive or competing approaches for designing safety instrumented systems, and that’s the subject of note one, where there are process sector applications.

Now, note one again says within the process sector, some applications may have additional requirements. They have to be satisfied.

NFPA 85 and Boiler Burner Management Systems

The biggest one of those is going to be the process sector application of fired heaters, especially if your fired heater starts with water and makes steam, which means it’s called a boiler. So if you have a boiler in the United States, there is a very good chance that you are going to be obligated very strongly by more organizations than just OSHA and more regulations than the process safety management rule to design your boilers in accordance with a specific application standard called NFPA.

the National Fire Protection Association Standard 85, which explains the design of boilers and specifically the burner management systems for boilers. And we know that the burner management system of a boiler is going to be a specific instance or a specific application of a safety instrumented system.

But when you read through the NFPA 85 standard, it goes into a lot of detail on what you need to measure, how you need to measure it, what actions you need to take, what are the attributes of the logic solver system that accepts the inputs and generates the outputs, what type of devices do you use, how often do you test them. It’s all specified in a very great amount of detail in the NFPA 85 standard. Now, where does this leave us with respect to 1E?

Well, some operating companies that are running chemical plants that have a boiler in their chemical plant will choose to follow the rules of both standards. They’ll say, well, I’m going to follow IEC ISA 61511 for all of my safety instrumented system, including boiler burner management systems. But for boiler burner management systems, I’m also going to follow the rules of NFPA 85 in addition to the rules of IEC ISA 61511.

Non-Nuclear Power Generation and Standard Compliance

But now here’s the rub. Some industries don’t follow the rules of ISA IEC 61511. And the last item of Clause 1E, non-nuclear power generation, is a case in point. So in the US, a lot of power generation that is not done in accordance with the nuclear industries is done with gas-fired boilers. so you will combust natural gas to generate the energy that will eventually turn a turbine to make electricity and the intermediate for that process is going to be steam and the steam is going to be generated by a boiler that’s going to work in accordance with the NFPA 85 standard

So most companies that the only safety instrumented system that they have is a boiler that is designed in accordance with NFPA 85 will basically only follow NFPA 85 and they will ignore IEC 61511 entirely.

Now, that’s in the U.S., and the authorities having jurisdiction over these facilities are completely fine that these companies only follow NFPA 85 and don’t follow the ISA IEC 61511 standard.

So again, I’m going to have to go back and say when you’re looking at 1E, yes, the standards writers said all the process industries other than nuclear power generation, nuclear power generation was singled out and separated out because they have their own completely large and comprehensive list of rules to where we just kind of left them alone and said, okay, we’re not even going to try to tell you anything about how to do nuclear power generation. But even non-nuclear power generation in the U.S. is not following the IEC 61511 standard.

But if you go outside the country, I believe, and in my experience, that in the U.K. and in Australia, you will see implementation of the IEC 61511 standard even for non-nuclear power generation.

So the key to 1E is know thyself and know your industry. Know your authority having jurisdiction, what they are willing to accept, what they’re not willing to accept, and actually what they demand. So clause 1E, yeah, that’s great. But ultimately, the authority having jurisdiction makes the decisions on whether or not this standard applies to you.

Clause 1F: Safety vs Other Instrumented Functions

All right, let me do one last clause before I end the session today. And that’s going to be clause 1F. So 1F says that the, in particular, the IEC 61511 standard part one is going to outline the relationship between safety instrumented functions and other instrumented functions. Now, this is an area where there’s actually a lot of discussion in the IEC 61511 standards

Committee, which is SC65. Today is the 26th of December, 2023, and we just had a committee meeting the first week of December where this was probably the topic of two days of discussion because there’s a lot of arguments between different groups defining what is a safety function, what is not a safety function. There’s a lot of activity in the ISA 84 committee that is writing a standard that’s setting requirements for safety functions, safety functionality, instrumented functionality that performs a safety purpose but is not a safety instrumented function.

Things like basic process control system interlocks and safety critical alarms and so on. So we’re going to hear a lot more about this in the coming episodes and in the next version of the standard when it comes out. But for the moment, there is a figure four that talks about the relationship between safety functions and non-safety functions. So you begin looking at clause four. It’s kind of a flow chart that says, okay, first off, we’re going to distinguish between instrumented functions and non-instrumented functions.

If it’s a not an instrumented function, let’s say a relief valve would be considered non-instrumented. That’s, if you disagree with that, that’s an argument for another day. But the standard doesn’t consider that to be an instrumented function, but it is a safety function. So we would consider that in other means of risk reduction, which is kind of outside of the scope of this standard.

But we do mention it because it’s something that we kind of need to keep track of in the overall safety life cycle. And if it’s non-instrumented and non-safety, it’s not relevant. We don’t care. Okay.

For instrumented functions, are they safety critical or not? If they are not a safety instrumented function, then it might be an other instrumented means of risk reduction, like those BPCS interlocks and safety critical alarms that I talked about. They are not subject to this standard, but the ISA 84 committee is working on a standard that they are going to be subject to.

Finally, for safety instrumented functions, uh figure four is the first place we’re going to distinguish between low demand mode safety functions and continuous mode safety functions so low demand mode when you’re thinking of a safety function that’s what you’re actually thinking of continuous mode safety functions are more like control loops where if that control loop failures fails it will immediately result in a consequence

So that is the kind of the outline of figure four. And figure four is referenced in clause 1F.

Kenexis Vertigo Software Outro

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. Thank you.