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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E5 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 5: IEC 61511, Clauses 3.2.17 through 3.2.34 (Error through Instrumented System)

—

## Podcast Introduction and Disclaimer

Diversity, error, and all kinds of faults and failures. More definitions coming up.

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.

## Error, Failure, and Failure Mode Definitions

We're going to pick up where we left off last time. We're still in clause three, which is the definitions, and we're picking it up at 3.2.17, which is error. And error is E, which is before F, which is going to kick off failures. And there's a lot to talk about when we're talking about failures. I guess there's a lot of failure in the world that we need to deal with.

An error, 3.2.17, is a discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.

So error is going to come into play when we start talking about safety requirements specifications. And it's part of the process of selecting and defining performance requirements for instruments, especially measurement devices. Not a whole lot else to dig into at that point in time.

Next item up is failure 3.2.18. Failure is a loss of ability to perform as required.

So I've said before in training classes kind of earlier in my career that a failure is actually a lack of success. So when you are unable to succeed, if a component is unable to successfully perform its action over the course of mission, it is said to have failed. And failures are what we're all about in safety engineering. We're pessimists. We're negative. We don't look at success trees. We look at fault trees. How do things break and what happens when things break? So failure is kind of the beginning point of a lot of what we do.

And we're going to break failure down into a lot of pieces. But let's look at the notes to the entry before we dig into more detail.

On failures. So note one to the entry is a failure of a device is an event that results in a fault state of that device. Wow. Kind of circular there. A failure is a failure. We're going to actually discuss the difference between a failure and a fault in just a second. So a failure of a device is an event that results in a fault state.

Note two. When the loss of ability is caused by a latent fault, the failure occurs when a particular set of circumstances is encountered. So a latent fault or an incipient failure is kind of a precondition to the failure. And then when the circumstances arise, the failure actually occurs.

Note three. Performance of required functions necessarily excludes certain behavior. And some functions may be specified in terms of behavior to be avoided. The occurrence of such behavior is a failure. So three is starting to get a little bit esoteric, a little bit out in the weeds, talking about what is success and behaviors that indicate that success is no longer present. Again, yeah, just notes.

And finally, the last note, failures are either random or systematic. Now, we're going to talk a lot more about random failures and systematic failures.

And, you know, just to bring things up to kind of give you my philosophy before we get a whole lot deeper in here. The SIL verification calculations that we do and we're going to be talking about are basically looking at the probability of failure on demand due to random hardware faults. Systematic failures are things that are going to occur every time because, well, they're systematic. They're built into the system. And using your PFD math to look at systematic failures is a fool's errand. It will be inaccurate. It will lead you to make bad decisions.

So when we're talking about math of PFD, we're going to handle that or we're going to handle random failures that way. Systematic failures, we're going to use our management systems, clause five, clause six, and clause seven to address systematic failures.

Okay, so that's failure. And then we're going to get a subdefinition of failure mode.

So things can break in lots of different ways. And the way that something breaks is important. And it's important because the mode or manner in which a component or a device or a system fails is going to lead to the effect or what is the consequence of that failure.

And different failure modes can have different failure effects. And with regards to safety instrumented systems, we're going to focus on things called the safe failure mode and the dangerous failure mode. Where the safe failure mode means that you got a spurious trip. The safety function shut down when you didn't want it to as opposed to a dangerous failure mode, which is one that is covert. It's hidden. The device has failed. You don't know that it's failed. And when you call on that device to perform its action, it's not going to.

So failure in the beginning and then we split that to say, well, we're also concerned about specific failure modes.

## Fault Definition and Fault Exclusion

Okay, as I alluded to, we're going to talk about fault. So there's a definition for failure and there's a definition of fault in 3.2.19.

Fault is the inability to perform as required due to an internal state. Hmm. Inability to perform as required as opposed to loss of ability to perform as required.

So we're kind of setting things up as a failure is kind of the verb, kind of the action that resulted in a fault. And the fault itself being more of a noun, more of a state that the component now will no longer work. So a failure results in a fault. And, you know, kind of the second half of that definition would be due to an internal state. That's just a condition of the device that is basically causing it to be non-functioning.

Let's look at the notes to fault, the definition of fault.

Note one is a fault of an item results from a failure, either of the item itself or from a deficiency in an earlier stage in the life cycle, such as specification, design, manufacture, or maintenance. So kind of normally when you think of failure, you're thinking something worked and then there was an action, something happened, and now it doesn't work anymore. Whereas a fault, actually in the note, we're extending that to even the more systematic attributes of specification, design, and so on.

Note two, a fault of a device results in a failure when a particular set of circumstances is encountered. So we had a similar note to failure that kind of basically says that there are stressors, a certain set of circumstances that can result in a failure, and a failure results in a fault condition.

I got to be honest, I don't get too worked up about fault versus failure. If you're a practitioner, it's really not something that's generally going to come up. It's more of an item that you're going to seem more of an equipment vendor type person get worked up about as opposed to a practitioner who's implementing stuff in the field. But there are two different definitions. I would hazard a guess to say that most people are going to use these terms interchangeably. But be aware that they do have separate definitions.

There are no notes to this definition, and I really have nothing further to say.

It seems pretty self-evident. I'm not sure I understand.

3.2.20.1 is a definition of fault exclusion. So once again, we started with fault avoidance, faults, and then we're kind of starting to break fault avoidance into multiple different pieces.

And the multiple different pieces of fault avoidance are going to be a little bit more interesting.

So 3.2.20.1 is the definition of fault exclusion. So fault exclusion is the elimination from further consideration of faults due to improbable failure modes. Okay.

So we're going to ignore it when we start doing our calculations for a device, especially when we're talking about fault tolerance. So more about fault tolerance and fault exclusion in Clause 11.4. However, there are requirements in the standard that will allow you to kind of ignore your fault tolerance requirements if you can exclude certain failure modes.

Okay.

There are a couple notes to this entry. It is pretty elaborate. The first note says, further information about fault exclusion can be found in ISO 13849 part 1 and ISO 13849 part 2. So that was 13849 parts 1 and part 2.

After those standards, fault exclusion can be based on three things. The first one is the technical improbability of occurrence of some faults. Two, generally accepted technical experience independent of the considered application. And three, technical requirements related to the application of the specific hazard. So note 1 is pointing you back to ISO 13849 for a further discussion of when and why and where I might want to exclude faults from my analysis of a design.

Note 2 says failure modes identified in the devices performing the safety function can be excluded because their related dangerous failure rates are very low compared to the target failure measure for the safety function under consideration. That is, the sum of dangerous failure rates of all serial devices on which fault exclusion is being claimed generally cannot exceed more than 1% of the target failure measure.

So that note is kind of starting to put some numbers around saying, well, you know, if a failure mode is like less than 1% of the target failure measure, it's not really relevant to what we're doing. And kind of, if you look at the math, it's not going to be relevant to what we're doing.

But I should warn you, though, the clauses that talk about fault exclusion might be something that's a little bit more relevant to equipment vendors. But for us people that are out in the field, out in the chemical plants, actually implementing this standard, implementing hardware that has been designed and manufactured for safety purposes, I've never seen — I personally have never used fault exclusion. I don't know of anyone that has used fault exclusion.

And there's a very good chance that you should never use fault exclusion to monkey around with the minimum hardware fault tolerance requirements that you're applying to your designs.

## Fault Tolerance and Final Element Concepts

Okay, so let's go to the next definition, which is relevant to what we're doing here, and it is the discussion of fault tolerance. It is 3.2.21. What is fault tolerance?

Fault tolerance is the ability of a functional item to continue to perform a required function in the presence of faults or errors. So I have a functional item, which is usually a redundant subsystem, that's going to be able to continue to perform its required function in the presence of faults or errors.

So generally we're talking about redundancy. So if you have a one out of two voting system, which for a de-energized to trip circuit could be like two switches in series. If one of those switches has its contacts welded and can't open, well, the other switch in the redundant set can open and bring you to a safe state. So even though we had a fault present in that first switch, the second switch worked. So that system, the one out of two voting system, has the ability to tolerate one failure.

Specifically, it has the ability to tolerate one dangerous failure. Fault tolerance is another attribute of SIS design that is going to be dependent on the mode of failure. And when we're looking at the standard, we're looking at the definitions of the standard and we're talking about fault tolerance, we are specifically definitively talking about tolerance to dangerous failures.

The standard does not care if you can tolerate safe failures and not have a spurious shutdown. So whenever you see fault tolerance, it's going to be tolerance to dangerous failure modes as opposed to tolerance to safe failure modes.

A lot more on this coming up in Clause 11.4, where I am certain we will have a very long discussion of the fault tolerance tables contained in this standard and also in the IEC 61508 standard. Because it is a very important aspect of the design of safety instrumented systems. And it's an aspect of the design of safety instrumented systems that a lot of times gets people into trouble.

3.2.22 is the definition for final element. Wow, another definition that probably doesn't need to be defined. But final element is part of the BPCS or SIS that implements the physical action necessary to achieve or maintain a safe state.

Note one to the entry. Examples are valves, switchgear, and motors, including their auxiliary elements, such as solenoid valves and actuators used to operate the valve. Okay, final element.

Again, another one of those items that I'm kind of looking at going, did we really need a definition for this? But it is the back end of the SIS function, the safety instrumented function. It's the part of the function that actually acts on the process. Most of the time, it's a valve. A little bit of the time, it's a switchgear, but most of the time, it's going to be a valve.

All right, 3.2.23, interestingly enough, gives you a definition that comes right out of the title. So 3.2.23 is the definition of functional safety. So what is functional safety? Functional safety is part of the overall safety relating to the process and the BPCS, which depends on the correct functioning of the SIS and other protection layers.

So functional safety is a subset of safety. Safety is a very big topic, which encompasses everything from slips, trips, and falls to training to process safety information. So it makes sense to kind of say, well, what specific type of safety are you talking about?

And functional safety is a term of art that generally means we're talking about automatic control functions and how they keep a plant safe and how they detect that you've gone out of control and bring you to a safe state. Generally, when we talk about functional safety, we mean safety instrumented systems and those tools and techniques and thought processes that help us to design safety instrumented systems.

## Functional Safety Assessment vs Audit

3.2.24 is functional safety assessment.

So we just defined what functional safety assessment is or functional safety is. Now we're going to talk about functional safety assessment. We're going to spend a lot of time talking about functional safety assessment in Clause 5. It's one of those management activities that's going to keep your process safe. And most of the time it will go by the FSA acronym, especially in documentation.

But when we're just talking, we'll usually say functional safety assessment because it doesn't take a whole lot longer than just saying FSA.

Okay, so what is a functional safety assessment? It's the investigation based on evidence to judge the functional safety achieved by one or more safety instrumented systems and or other protection layers. Now that's kind of a vague definition.

And what are we actually saying? We're going to investigate and make a judgment on whether or not something is functionally safe. That really doesn't tell you what you're doing.

That investigation is effectively an audit. So there's going to be more on this later. But it's not an audit like you're going to see in literally the next definition. It's more of an audit on a specific project.

So for a specific project, I'm going to look at the requirements. I'm going to look at the activities that were performed and determine whether or not those activities were performed as they were specified to be performed. Generally, at a spot checking level of assessment.

So a functional safety assessment, I'm going to want to differentiate from a verification, which is kind of a paperwork back check. And I'm also going to differentiate it from a functional safety audit, which is a larger scope. So the functional safety assessment is kind of a mini audit for a specific project, whereas a functional safety audit, which is the next definition, is a grander scope that applies to entire facilities and all activities that are occurring in an entire facility.

So let's hit that definition. 3.2.25 is functional safety audit. The definition is systematic and independent examination to determine whether the procedures specific to the functional safety requirements comply with planned arrangements are implemented effectively and are suitable to achieve the specified safety objectives.

Note 1 to the entry says a functional safety audit may be carried out as part of an FSA. Okay, whoever wrote Note 1 is not very familiar with our good friends at OSHA, who would probably want to disagree with that.

Generally, the authority having jurisdiction, which if you're in the U.S. and you're at a plant that's covered by the process safety management rule, OSHA 1910.119, that regulation from OSHA requires you to do an audit of all of your safety activities once every three years. And functional safety is just part of process safety. And most operating companies are going to include a functional safety audit as just a set of questions, a worksheet in their overall process safety audit.

The key is we're looking at the big picture, the entire plant, all of the installed equipment, all of the operating equipment. And we're going to be looking at the policies. We're going to be looking at the procedures. We're going to be looking at actual implementation to make sure that you have documented what you should be doing. What you should be doing matches up with the requirements in the standards and other recognized and generally accepted good engineering practice. And that you're actually doing what you said you were going to be doing.

So I think this kind of should draw a highlight on the difference between a functional safety assessment and a functional safety audit with an audit more being a big picture overall assessment. Whereas that functional safety assessment, you're looking at a specific project and implementation of a specific project when you're doing that activity. Okay, let's keep moving along.

## Hardware Safety Integrity and Failure Measures

3.2.26 is hardware safety integrity.

So for hardware safety integrity, the definition is part of the safety integrity of the SIS relating to random hardware failures in a dangerous mode of failure.

Okay, integrity and safety integrity are, we're breaking down the concept of integrity into multiple different pieces. So you're going to become very familiar with the concept of the safety integrity level. But that safety integrity level has different attributes to it. There's hardware, there's hardware, there's software, there is systematic, there are hardware fault tolerance requirements. So safety integrity is built up of a lot of pieces that you need to consider and confirm during your design process.

The hardware is one portion of it. So a couple of notes to the hardware safety integrity. Note one to the entry says two failure measures that are relevant in this context are the average frequency of dangerous failure and the average probability of failure on demand.

So there we're looking at random hardware failures and the probability that a failure exists or the frequency at which a failure will exist depending on what mode of operation you're in.

Note two says to see 3.2.82. And off the top of my head, I don't know what 3.2.82 is. So let me scroll all the way out to 3.2.82 to get this definition. And that's going to be 3.2.82 is systematic safety integrity. So systematic safety integrity is being referred to from the hardware safety integrity. And note two to 3.2.82 points you back to where we just were, which is 3.2.26.

So in the note, a reference to say, well, we've got hardware and we've got systematic integrity. Hardware is kind of a probability of failure on demand thing, whereas systematic, we will find out later on, is not. The third note to the entry for hardware safety integrity is this definition deviates from the definition in IEC 61508 to reflect differences in process sector terminology.

So 1508 is going to talk about hardware and systematic safety integrity a little bit differently. But for us people that are working out in the process industries, we have a different set of terms that we like to use. So we're going with hardware safety integrity.

All right, let's pause for a second. We've been talking a lot about faults and failures in hardware. Once we get to 3.2.27, we're going to be switching back over to kind of the front end of the safety life cycle or our risk analysis concepts.

## Harm, Hazard, and Hazardous Events

3.2.27, very important definition, and it is of harm.

Harm is injury or damage to the health of people or damage to property or to the environment.

Now, that definition is going to be consistent with another source document, which is the ISO IEC Guide 51. And in that guide, harm will be definition 3.1 is what the 1511 standard is pointing to.

So harm is why we have safety instrumented systems or actually the avoidance of harm. Safety instrumented systems have been designed in order for people to not be harmed. Or also, as we see in the definitions, it's also concerned with environmental harm or property harm. So harm is something that we're going to discuss when we're doing risk analysis to pick performance targets for safety instrumented systems.

Another term that would get thrown around here would be consequence, which is kind of more of a measure of the magnitude of the harm. And that's one of the factors that we use to calculate the risk that we're going to compare against tolerable risk to basically set those SIL targets or performance targets for our safety instrumented systems.

Subdefinition of harm, 3.2.27.1 is a harmful event. And that would be the event which has caused the harm. And that, again, when we're doing our performance target selection, your harmful event is what you are going to quantify with your risk analysis, which is usually a LOPA analysis.

So we are going to do a layer of protection analysis or a LOPA on a harmful event to determine whether the safeguards are appropriate and whether or not a safety instrumented function is either required. And if it is required, what performance target you need.

Note one to the entry of harmful event is whether or not a hazardous event results in harm depends on whether people, property, or the environment are exposed to the hazardous situation. And in the case of harm to people, whether any such exposed people can escape the consequences of the event after it has occurred. A hazardous event which has caused harm may be termed a harmful event. All right.

Let's kind of stick in with this theme. Harm is, you know, kind of the consequence. Something bad happened. But the precursor to that, which is the starting point for our risk analysis, is 3.2.28. And that's hazard.

A hazard is a potential source of harm.

So a hazard doesn't mean anything bad has happened. It doesn't mean any harm has occurred. It doesn't mean life has been lost or equipment has been damaged. It just means there's something bad can happen because of what I have present in my process area.

Note one to the entry of hazard is the term includes danger to persons arising within a short time scale. For example, fire explosion. And also those that have long-term effects on a person's health, such as release of toxic substance or radioactivity.

So note one is saying that when we say hazard, the term of art that we would use in quantitative risk analysis would be the harm on a short time scale would be an acute hazard. So it's something that is intense and fast. As opposed to the other type of effect that they call a long-term effect that we would call a chronic hazard. So if you're exposed to low levels of benzene for a long period of time, that chemical can build up in your body. It can be carcinogenic.

And over the long term, you could suffer potentially getting cancers or succumbing to some other mutagenic effects of that particular chemical.

So normally when we're doing safety instrumented systems, we're actually most concerned about acute hazards as opposed to chronic hazards. But the definition of hazard covers both. And also there is another part of the note that says that hazard is also defined in that ISO IEC guide 51 in clause 3.2.

So harm had harmful events and hazard has hazardous events. So 3.2.28.1, a hazardous event is an event that can cause harm.

Aha! A hazardous event and a harmful event are slightly different from each other. And harmful event, I mean, and why they need to go into this level of detail in these definitions is completely beyond me. Potentially a lot of overkill, unnecessary.

But harmful event is they're basically saying something already happened that has caused harm. Whereas a hazardous event means that there's an event that can cause harm, but it didn't necessarily happen yet.

Note one to the entry, whether or not a hazardous event results in harm depends on whether people, property, or the environment are exposed to the hazardous situation. And in the case of harm to people, whether any such exposed people can escape the consequences of the event after it has occurred.

So a lot of talk about harm and hazard. And we're not done with hazard. We have another sub-definition of hazard, which is 3.2.28.2 or hazardous situation, which is a circumstance in which people, property, or the environment are exposed to one or more hazards.

Okay. Okay. So if you're in the proximity of a hazard, that is a hazardous situation. More specifically, when people talk about a hazardous situation, what they really mean is a postulation of a sequence of events that could result in loss of containment of that hazard, which will then result in harm. And that hazardous situation, that postulated sequence of events, that's, again, that's what your risk analysis, your LOPA scenario is going to be based on. Okay. Moving on.

## Human Error and Management of Change Terms

3.2.29 is the definition of human error.

Human error does come into play in the design of safety instrumented systems, as I have mentioned many times now. We're going to deal with human error in Clause 5 in Management Systems and also in Clause 7 in Verification.

The definition for human error is intended or unintended human action or inaction that produces an inappropriate result.

Note 1 to the entry, mistakes, slips, and lapses are examples of human error. Okay.

Note 2. This excludes malicious action. So if somebody deliberately opens a sample valve and runs away and allows the plant to de-inventory, that's not a human error. That is a deliberate malicious action. And they should not be confused for each other in the analysis and design process. Okay.

Okay. We are just plowing through some definitions. Let's keep going through these definitions. And now we're on 3.2.30, which is an impact analysis.

Impact analysis, we're going to discuss when we get to Clause 16, I think. Now I can't remember off the top of my head. It's more of a management of change issue.

We know that the design of safety instrumented systems or safety instrumented systems themselves have succumbed to failure very frequently because they were changed improperly. So when you're changing things, you're going to need to perform an impact analysis regarding the change.

So what is the definition of impact analysis? Activity of determining the effect that a change to a function or component will have to other functions or components in the system as well as in other systems.

So when I'm changing one thing, what impact is that going to have to the rest of the system, to the process as a whole, society in general? What impact does a change have and is that impact compromising safety? Management of change section. We will get there.

3.2.31, independent organization. Independent organization is a definition that's going to become important in Clause 5 when we talk about functional safety assessment.

Because when we're doing functional safety assessments, basically we want to make sure that whoever made the mistake isn't responsible for checking to make sure that the mistake is there. We want someone who is not involved doing these assessments.

So an independent organization is an organization that is separate and distinct by management and other resources from the organizations responsible for the activities that take place during the specific phase of the SIS safety lifecycle that is subject to FSA or validation. Okay, independent organization.

Or maybe you'll bring in someone from the HSC department. Or maybe you'll bring in someone from one of your sister plants who has the same job but was not involved in the project.

So independent organization, the key is really different management and other resources but management. So we don't want your boss telling your co-worker to check your work. That's not really an independent organization.

And that's an area where a lot of people see a lot of value and obtain a lot of value from using a third-party organization like a certification body or a consultant. But it's not necessary and it's not in the definition of independent organization.

## Independent Person, Input Function, and Instrument

3.2.32 very similarly talks about an independent person.

That definition is a person who is separate and distinct from the activities which take place during the specific phase of the SIS safety lifecycle that is subject to the FSA or validation and does not have direct responsibility for those activities. So now in this case, if your boss has you and another person in your department, if you did work, the other person in your department is probably going to be an independent person unless they helped you.

So independent organization is a higher level of independence from an independent person, which can be in the same organization.

3.2.33. 3.3. Input function. All right. Input function is a function which monitors the process and its associated equipment in order to provide input information for the logic solver.

Note 1. Note 1 to that entry is an input function could be a manual function. So input versus output versus sensor versus final elements. We're defining everything.

An input is generally going to be a sensor function. It is providing a measurement or a state or information on the situation of the plant and brings that to the logic solver. An input can be manual. So you can have a hand switch or a push button as an input just as well as a pressure transmitter or a temperature transmitter.

3.2.34 is the definition of an instrument, which is apparatus used in performing an action, typically found in instrumented systems. Okay. Apparatus used in performing an action. And definitely, if I was going to vote on a definition that didn't need to be in here, it's going to be the definition for instrument.

But there you go. The reason probably that the definition of an instrument is in here because, well, safety instrumented systems is kind of in the title of the standard. So maybe we might want to have a little bit of precision as to what we mean by an instrument. Especially since the next definition is a sub of instrument. It's 3.2.34.1, which is instrumented system.

So an instrumented system is a system composed of sensors, logic solvers, and final elements.

Oh, I kind of like that. That's kind of a nice throwback to the definition of safety instrumented system that used to be contained in the first version of the functional safety standard, which was the 1996 version of ISA84. Now, sensors are also, for example, pressure flow temperature transmitters.

That's in the definition. Logic solvers, for example, are programmable controllers, distributed control systems, and district controllers. That is also in the definition. And the examples for final elements from the definition will include control valves and motor control circuits. Now, the note to the entry is, note one to the entry, instrumented systems perform instrumented functions, including control, monitoring, alarm, and protective functions.

Instrumented systems can be SIS, which is going to be defined in 3.2.67, or BPCS, which we already talked about in Clause 3.2.3.

Now, there are a couple interesting things that I want to take away from this, and there's a lot of subtlety in this definition. So, first off, the IEC 61511 standard has a lot of very long, unnecessarily complex definitions.

And they take definitions and they spread them out over multiple different areas. So, we couldn't just define safety instrumented systems. We had to define instrument first. Then we had to define instrumented system. And then later on, 3.2.67, we're going to define safety instrumented system. Why all the confusion?

Well, breaking the definitions into littler pieces helps us to be more precise in what we're talking about. But it's also kind of an area where different people can look at the definition and take away different things from it.

## Alarm-as-SIS Scope Debate

Now, one of the big areas of consternation, confusion, argumentation in the standards, one of those areas where people have argued, is what is a safety instrumented system specifically? Think about this.

If I have a safety critical alarm, and when that safety critical alarm comes in, I, the operator, see the light on my control board, and based on seeing that light on the control board, I look at a measurement device. And if that measurement is above some certain number, for instance, I may press a push button that will cause a valve to close. Is that a safety instrumented function? Is that safety critical alarm a safety instrumented function? Is that push button closing the valve of safety instrumented function?

Now, this is one of the areas where if you go to a standards committee meeting or a national committee meeting that feeds into SC65, you are going to get so many arguments. Because, again, everyone's reading this, reading into this, what they want to see, what they want to hear.

Now, I take solace in the definition saying that an instrumented system has sensors, logic solvers, and, and final elements. It is a complete automatic loop. You sense something and you automatically take an action. And my opinion is a safety instrumented system, in order to be covered under this standard, must be a complete loop.

There was an end here in the definition of instrumented system. Not everybody agrees with me. Although 99% of implementation practitioners will agree, yes, the IEC 61511 standard applies to complete automatic loops from sensor through final elements.

But if you go into this definition, you'll see that an instrumented system could include alarms and monitoring. So, one can make the argument that, oh, that transmitter that you were looking at to decide whether or not to push that button. That is a safety instrumented function that needs to be designed in accordance with this standard.

And that's an area where a lot of people are going to fight. A lot of people are going to argue. My personal opinion, which is consistent with the vast preponderance of practitioners of safety instrumented systems, will say no.

So, an alarm that is responded to by an operator to take an action, that alarm is not covered under IEC 61511. That set of equipment needs to be covered by the alarm standard. So, in the US, in Canada, in a lot of regions of the world, that alarm standard is going to be, the ISA 18 series defines how to design and maintain and manage alarm systems.

And that kind of throws 1511 out the window off the table, which makes a lot of people very angry because you will find, you know, there are equipment vendors out there that will sell you a SIL rated alarm enunciation panel. And from my perspective, looking at regulations and rules the way I look at them, there's no reason that you would ever need a SIL rated enunciator because the pure alarm portions of safeguarding schemes, they're covered under ISA 18, not IEC 61511.

But let me assure you, I will get a lot of people who will want to argue with me on that issue. So, that's one of those things where stake your ground, redo your reading, make your judgment for yourself as to what you believe and be prepared to fight for it because that's an area where you're definitely going to see a lot of people with differing opinions.

All right. So, with that, I've been talking for almost an hour now and we are about half, maybe not even halfway through the definitions yet. There's a long way to go, but that's all I have time for this week. We will pick it up with logic functions when I talk to you next time.

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.