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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E26 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 26: IEC 61511, Clause 10.3.2, Bullets 15-18 (Energize-to-Trip, Reset, Spurious Trip Rate, Failure Modes)

—

## Introduction and Podcast Overview

Fail safe is a very common term that makes people feel really good. Fail safe. Why wouldn't you want to fail safe? Obviously you want to fail safe, but you really can't guarantee that anything is actually going to fail safe.

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.

## Energize-to-Trip Concept and Valve Design

We're continuing on in the safety requirements specifications section with a discussion of failing safe, which we don't really mean fail safe because we don't know whether or not that's possible.

What we're actually talking about is energized to trip or de-energize to trip. And that is going to be bullet point number 15 in clause 10.3.2. So getting into it. Let's start with the actual requirement out of the standard says that in the safety requirements specifications, you need to document requirements relating to energize or de-energize to trip for each SIF.

Now, while we would love that if everything always failed to the safe state, failed safe, what do we actually mean? Well, when we say failure, as you know, from the design practice of safety instrumented systems, that all pieces of equipment have modes that are safe.

There are modes that are dangerous. So for a valve, if that valve just springs to the closed position when you didn't want it to, that's a spurious trip, but that's a safe failure because the shutoff valve closed, bringing you to a safe state.

But that same valve is going to have dangerous failure modes where you command it to go to the closed position, but it doesn't go to the closed position.

So you could say that a shutoff valve is fail safe when you design it such that when it is de-energized, it will go to the safe state. So if you look at a typical control valve or shutoff valve, you could design it such that it has an actuator.

And let's just go with a piston actuator for the moment, where you need air to push the piston one direction, and then a spring is going to push it back to the other direction. Now, the direction that the spring is pushing it to would be the de-energized state because the energy, in this case, in the form of pneumatic power, when that pneumatic power goes away, the spring is going to return the valve to the shutdown position or the safe state.

Similarly, you can design the electrical portion of that circuit to be de-energized to trip such that you would have a three-way solenoid valve.

And in the energized position, the solenoid valve would connect the air supply to the actuator driving the valve to be open.

But in the de-energized position, the solenoid valve would connect the actuator to atmosphere to just basically to vent it, to dump the air out to get you to a safe state.

But now, all of these pieces of equipment, the valve itself, the actuator, the solenoid valve, they are going to have dangerous failure modes, even if they are designed such that when you remove energy, you go to the preferred state, which would be the one where the shutoff valve is closed. So, all of these ambiguities between what is safe, what is not safe, and the fact that, well, every design is going to have both safe failures and dangerous failures.

In the standards, we don't say fail safe because fail safe really doesn't mean anything. It's hopeful at best, but it's not an engineering specification.

The engineering specification is energized to trip or de-energized to trip. Now, the energize the trip, de-energize the trip kind of makes you think that it's mostly related to an electrical circuit.

You have energy or you don't have energy. But in reality, the concepts of energized to trip or de-energize the trip are going to apply to all components in the safety instrumented function, whether they are electrical, mechanical, pneumatic, or hydraulic. So, basically, you have two choices, and that's not fail safe or non-fail safe. The choices are energized to trip or de-energize the trip.

And furthermore, those decisions actually occur at the component level, not even at the subsystem level, but at the component level because you can do mixing and matching.

So, for instance, if I have a valve that is, I need it to go open to achieve a safe state. So, I'm thinking right here about something like in a hydrocracker, there's going to be a depressuring valve. So, if the reaction starts to run away, I need to vent the reaction to decrease the reaction rate through the depressuring valve. So, I need the valve to go open. Now, when you pick your actuator, you can use the spring to either drive you closed or drive you open.

And actually, most of the time, you will design this function in an energized to trip fashion, at least at the valve and actuator subsystem level.

Because for a hydrocracker, opening that depressuring valve is a very bad thing to do. I mean, you're damaging equipment when you're depressuring the reactor very rapidly. You're sending a lot of flammable material to the flare. You're going to be able to see that the flare go off from a long distance away. We joke that you could see the flare go off from outer space when a hydrocracker depressures. So, that's not something we do lightly. And if a spurious trip is a problem, which by chance we're actually going to get to in bullet point 17 here before we get to the end of this episode.

So, if the spurious activation of a safety instrument function has significant consequences, you really need to think hard about whether just blithely de-energizing trip is the right thing to do.

So, a lot of hydrocrackers are going to use their spring to go to the closed position. The closed position is the dangerous position. It's the normal operating position. So, that is not failing safe, if you will. That is energizing to trip.

So, in a typical hydrocracker design, when I apply air to my actuator, that's going to cause the valve to go open. And that's what's going to drive you to the same state. So, you need to supply the pneumatic energy in order to get to the safe state. So, that's an energize to trip action.

So, and it's completely fine to have energize to trip function. So, you'll see that the requirement out of the standard says that you need to specify whether something is going to be energize to trip or de-energize to trip.

And by saying that you need to specify which way it is, you're actually stating, you're actually implying that either one is going to be acceptable. You just need to decide which one you're going to do and document it that way.

## Energize-to-Trip Documentation and Standard Critique

So, energize to trip is okay. De-energize to trip is okay. You just need to document what you're going to do.

And what we'll realize when we get to clause 11 is that not only do you need to document that it's energized to trip, energized to trip requires some additional actions. So, let's go back to this hydrocracker depressuring valve and talk that through a little bit more.

So, I said that if we need to apply air to the valve to make it go to the open position and the open position is the safe state. Now, in the terminology of the ISA standards, this would be a fail closed valve. So, we're putting a fail closed valve, air to open valve in a safety function where you need it to open to get to a safe state. So, that's energized to trip. Now, the solenoid valve needs to shift position so that it will send instrument air to the actuator to get to the safe state when the safety system activates.

But, the solenoid valve can work as de-energize to trip when the valve itself is energized to trip. And that actually is a very common configuration.

So, in this case, if the solenoid works in a de-energized to trip state, what that means is when the solenoid is energized, the valve is venting. So, you're connecting the actuator to air, to the vent, to atmosphere. And then, when you de-energize it, it lines up the instrument air to the valve.

So, that's why I say that the choice for energized to trip or de-energize to trip can go down into the subcomponent level. So, we've got the actuator working as energized to trip, but the solenoid valve working as de-energize to trip. And, believe it or not, this is a very common application, a very common design. So, the key when we're hearing clause 10.3.2 is that you need to describe energized to trip versus de-energize to trip. Now, the clause of the standard says that you need to say energize to trip or de-energize to trip for each SIF.

Honestly, I think that that is a horrible way to describe it in the standard. Maybe we should look at rewriting the standard because the standard basically says that this is a decision that's made on each SIF. And it is not. It's definitely going to be at the subsystem level.

It might be at the component level. It might even be at the subcomponent level. So, when you're setting up your database, you don't want this documentation to be at the SIF level. That's just flat wrong. I'm going to go out on a limb and say that that's flat wrong. That's a dumb way to do it. You need to make that decision at the component level or at the subcomponent level. So, talking about a valve or talking about the subsystem.

And furthermore, this is something that often is going to go down to the data sheet level for your sensors and for your final elements. And again, for a final element, I just described a final element that has a difference between the solenoid valve and the actuator on how it's employed. So, we would generally recommend that if you're doing any kind of significant energized trip that you will want to document this decision on the data sheet for the final element or for the sensor for that case level.

But, there are a lot of design. But, there are a lot of designs out there where the entire plant, the entire unit operation, maybe even the entire facility has absolutely no energized to trip aspect to it. Absolutely everything is designed as de-energized to trip. And, if that is the case, that is a perfect situation to use the concept of the general requirement and then document the energized to trip aspects by exception.

So, you put in a general requirement that says everything, every subsystem, every component, every subcomponent is designed such that when you remove energy from it, it will go to a safe state.

Now, you might also want to go and have multiple general requirements based on equipment type. So, a description of de-energized to trip for a solenoid valve is going to be different from de-energized to trip for a valve. And, it might be different from de-energized to trip description for a switch coming in as a sensor.

So, one or more clauses in your general requirements to describe what de-energized to trip means. Apply it across the board. And, then if you run into energized to trip situations, you might want to take exceptions right there in the general requirements. And, also at the data sheets of the specific devices.

Now, we're going to learn more about the decision-making process for energized to trip or de-energized to trip when we get into clause 11 and we discuss this in more detail. But, if you decide that you're going to go energized to trip, you'll see that the standard is going to require extra stuff. So, that extra stuff is going to be basically the detection of an open circuit. Because, an open circuit is not going to cause a shutdown anymore if you're energized to trip. So, you're going to need to be able to detect that you've got an open circuit in your signaling circuit somewhere.

You're also going to be able to need to detect and alarm, for both of these, detect and alarm, that your motive force is not available. So, if your motive force is electricity, you need to know if you lost power. If your motive force is pneumatic air, you're going to need to know that you lost pressure. And, there's also a note that says you should probably also consider some sort of backup means of motive force in those situations. But, more on that when we get to clause 11. And, for the moment, we just know that we need to document energized to trip versus de-energized to trip.

Most everything is going to be de-energized to trip. So, it's very efficient to use general requirements to describe that. Describe energized to trip generally by exception. Either as sub-notes in the general requirements and or notes in a final element or sensor subsystem data sheet. And, you can either make data fields available or you can put them in the notes section.

So, there are definitely fields available in that premier software for documenting safety requirements specifications. Kenexis Vertigo, of course, is what I would be talking about. All right.

## SIF Reset Requirements and Design Philosophy

That's clause number or sub-clause bullet point 15. Let's move on to bullet point 16.

Bullet point 16 is the requirements for resetting each SIF. And, again, when I see SIF there, it definitely rubs me the wrong way. Okay. Requirements for resetting each SIF after a shutdown. For example, requirements for manual, semi-automatic, or automatic final element resets after trips. All right. That's what the clause says that you need to document.

So, you need to document the way that you reset a safety instrumented function after a shutdown. Why would you have to reset a safety instrumented function after a shutdown?

And, the answer is because when you detect you've gone out of control, a variable has gone out of control, you're going to take an action to get to a safe state. When that process variable comes back to the normal operating range, you don't want the plant to automatically restart and fire up again. That could actually cause new hazards.

That's generally a very bad thing. We want the operations team to manually figure out what happened, verify that we're in a safe state, and manually restart the plant.

Now, it says in the standard that these requirements are at the SIF level. And, I've got to be extremely honest, they are almost never at the SIF level. So, if you document this at the SIF level, that's a horrible design practice. Most of the time, when we are defining resets, we're going to define a reset at the final element subsystem level.

So, if a safety instrumented function activates, let's say that it activates two outputs as part of the core safety instrumented function, and 10 additional actions, you don't want to press one button and have all 12 of those valves fly to the normal operating state simultaneously. That's way too much power, way too much stuff going on simultaneously. You will generally want to do this one item at a time. So, you're going to open this valve first, then this valve, then this valve, then this valve, as per your operating procedure.

And, your safety instrumented system needs to be designed for those resets to occur one at a time.

Now, there's more to a reset than just pushing a button. Well, probably it is going to fall back to pushing a button. But, where is the button located? How is it connected to the safety instrumented system? So, there are push buttons that could be hardwired into the SIS.

There could be basic process control system operator interface targets on the screens that you push. And, those screens might reside out in the field by the piece of operating equipment. Those screens might be in the control room available to the board operator. Also, sometimes there are hardwired switches that exist out in the field right next to the piece of equipment that you're trying to restart.

So, it's very common, for instance, if you want to restart a pump that's been shut down by the safety instrumented system, you will need to go out into the field right next to that pump and physically press a hardwired start button out in the field. So, there's hardwired start-stop buttons for final elements out in the field.

And, solenoid valves for shutoff valves often has something called a manual reset latch. Where, when you activate the manual reset will go to the deactive position and it will stay in the deactive position regardless of what the electrical signal is back to the solenoid. And, only when you go out to the field and actually physically lift up the reset latch will it return to that active state, the non-safe active processes in its normal condition state. Now, there's a whole lot of options.

And, each operating company needs to really think hard about what mechanisms it's going to use to activate its resets.

So, are we resetting on a function as a whole, a piece of equipment as a whole? Am I doing it through the local operator interface? Am I doing it through the board operator interface? Am I doing it out in the field? And, out in the field, again, it's getting less and less favorable because people need to go out to the field to do that.

And, the most dangerous place is out in the field because that's where all the plant hazards are. So, maybe we don't want to send someone out to the field to do these resets and we're going to want to be a mile away in the control room. So, all this discussion brings up the point that there are a lot of different ways to do the reset. We talked about different physical pieces of equipment in the field or in the control room. We talked about doing it manually through electrical switching. And, we talked about doing it logically through operator interfaces and communication.

The last decision that you make is whether the reset is manual or automatic. And, when we get into this clause in clause 11. So, in clause 11, when we see the design phase reset requirements, we're going to discuss this topic a whole lot more. And, there I'm going to get into a discussion about whether or not you want this to actually be automatic. So, kind of a preview. I'm not going to get into it now. But, there are situations where you may want to do your reset automatically.

And, kind of giving you a preview. You would want to do your reset automatically if leaving a final element in the safe state for a long period of time could actually generate a new hazard that needs to be prevented. In those cases, you might want to do an automatic reset. So, you've got a lot of options for equipment, for philosophy.

What bullet point 16 is actually telling you here is, well, you need to document that. And, where are you going to document that? Well, if you do all your resets exactly the same way, you might be able to get away with documenting that in the general requirements section. So, I reset one final element at a time. And, I do that with a BPCS target. You could probably get away with doing that as a general requirement.

If not, you're going to want to put it at the final element subsystem. So, the outputs, the final element data sheets. And, again, Vertigo is going to give you the option to do it either way. You can expose the field in the final element data sheet that allows you to document how reset actions are occurring. Okay. So, that is bullet point number 16.

## Maximum Allowable Spurious Trip Rate

Let's go on and move on to bullet point number 17. Which, oddly, is kind of related a little bit to bullet point 15. Because, we're talking about spurious trip rates. So, bullet point number 17 says that in your SRS, you need to document the maximum allowable spurious trip rate for each SIF.

Now, once again, a little bit of heartburn on this discussion. Ultimately, SIF might not be the best place to document this. Even though most software that's been available for, you know, 10, 20 years documents things on the SIF level. So, they'll calculate a spurious trip rate on the SIF level. I mean, honestly, Vertigo does also calculate a spurious trip rate on the SIF level because it's so common. But, does that really make sense? Maybe. Maybe not. Because, in reality, final elements are often shared by multiple different safety instrumented functions.

And, I really… There's… The plant is going to suffer a spurious trip because of more than just one SIF. It's going to suffer a spurious trip because of any component in the safety instrumented system causing a spurious trip in that plant. So, any SIS component in the entire plant can trip the whole plant out. Well, depending on voting arrangements, you know what I'm talking about. So, maybe it makes a lot more sense to look at the spurious trip rate of a plant as a whole as opposed to a specific safety instrumented function.

Or, maybe it actually makes more sense to look at a final element subsystem or a specific component in the SIS. Now, the standard says what it says. So, we kind of have to deal with what the standard says, even if it's stupid.

So, it says you need to document the maximum allowable spurious trip rate for each SIF. Now, for a lot of plants, if a spurious trip rate does not present any hazard and does not even present any significant nuisance, why are we documenting this? That's a whole lot of busy work make work for no good reason whatsoever.

It's a dumb idea. So, here's a little trip or a little trick, a little pro trick for you. A little tip from your Uncle Ed. Sometimes, the maximum allowable spurious trip rate is infinity. Basically, any spurious trip rate is allowable for this plant. You can document that and basically tell the whole world that the spurious trip rate doesn't freaking matter. I'm not going to calculate it because I don't care. I've got a batch plant that when it trips out, I can restart it in, you know, five minutes.

And I'm not going to worry about redundancy or other attributes to try to address spurious trip rates when they just don't matter to me. That's a completely valid thing to do. So, saying that you don't care, completely valid. Now, when do you care?

Well, sometimes a spurious trip is going to actually physically damage your plant. Or, it's going to create a new hazard. So, I might open up a depressuring valve that's going to overwhelm the flare system and potentially cause my flare system to release material where it shouldn't. I might have a very large flare that might be capable of causing injuries to people on site. So, does activation of my safety instrumented system present a new hazard that needs to be limited down to tolerable risk?

So, in those situations where activation of your safety instrumented system actually presents a new hazard, you might want to quantify the frequency at which we expect that activation to occur.

And put a limitation on it and design redundancy and testing in to prevent those spurious trips. Completely valid, completely possible. Going back to that hydrocracker example. If I depressure my hydrocracker, I'm going to set off a massive flare. I might put liquids into the flare system that cause damage in other ways. I might actually delaminate the precious metal or the exotic metal coating of my reactor vessel. And damage the reactor vessel. Which could have safety ramifications if that damage to the vessel causes internal corroding.

Which could result in a loss of containment. So, maximum spurious trip rate is something that you need to think about. What are the consequences of spurious trips? It could just be a financial consequence. We also know that generally starting up and shutting down the plant are the most dangerous modes of operation. So, putting in blanket requirements for once every five years, once every ten years is not an unreasonable thing to do.

But, look at specific hazards that might get you to a particularly dangerous unsafe state. And those are the ones that you're going to really want to document. Now, Clause 17 or Bullet Point 17 in Clause 10.3.2 says you need to document the maximum allowable spurious trip rate. Often, a lot of the time, you're going to do this once in a general requirement and not spec it out at the SIF level.

Honestly, specing it out at the SIF level, once again, kind of dumb. But, okay. The other thing that you could do is, now going back to that hydrocracker, specifying the spurious trip rate on the SIF level there is kind of dumb. Because there are a lot of different initiating events, a lot of different measurements, a lot of different SIFs that can cause that valve to depressure.

And what we're really concerned about is how often that valve depressures. Not the each safety function that activates that valve alone, but the end result of that valve. Which might require a more complex calculation that looks at everything that can trigger that valve. Which is going to address multiple different safety instrumented functions, multiple different hazards. So, don't… On the one hand, saying that you need to put requirements for allowable spurious trip rate on each SIF. On the one hand, it unnecessarily overcomplicates it when there's no consequences to a spurious trip.

And it also dumbs it down dangerously if multiple safety instrumented functions activate the same final element. And activation of that final element can create a new safety hazard. So, I don't like the way that this is written. I think I've kind of talked a whole lot about that at this period of time. And so, when you're going through this, when you're going through your workflow for maximum allowable spurious trip rate, give it some serious thought.

And really look at your final elements and ask yourself, when this final element activates, is that going to create a new safety hazard? If so, how… To what degree do I need to limit it? What mechanisms am I going to use to limit it? And document that all in your SIS, whether it's in general requirements or in the final element subsystem data sheets.

## SIF Failure Mode Detection and Response

Okay. Last item that we're going to talk about in today's session is going to be bullet point number 18, which is failure modes for each SIF. Okay. Let me start over.

The SRS is required to document failure modes for each SIF and desired response of the SIS. For example, what are the alarms and what is the automatic shutdown and whether or not that automatic shutdown occurs. Okay.

So, immediately, I'm going to jump right back up on my soapbox again and say the SIF is a horrible, a stupid place to document this. This information belongs on the sensor where the detection occurs or actually on the component whose failure just occurred.

So, if I'm measuring flow and my flow measurement fails, I want to document for that transmitter that's measuring the flow, how do I detect that it's failed and what action am I going to take when that failure occurs? Because the spec is going to be an attribute of a subsystem. So, why don't we document it at the SIF level?

Because what you need to do about it, the actual true specification is going to be different for the final element than it is for the sensor, than it is for the logic solver. So, on the highest level, for each component of the system, you need to think about what failure modes are possible and what your diagnostics are.

And if your diagnostics detect a failure, what action can you take and how are you going to signal that information to the safety instrumented system? Now, there's a lot more of this coming up in Clause 11. So, I'm not going to belabor it more than I'm already belaboring it today. But, so, let's look at a flow transmitter. So, let's say I have low flow through my heater tubes is going to cut off the fuel gas to my fired heater.

That's a very common safety instrumented function. And what we're learning very recently, so, I'm recording this on March 24th of 2025. Very recently, a lot of reports just came out of the U.S. Chemical Safety Board. And there's a lot of accidents that are occurring due to loss of flow through heater tubes causing explosions or just basically massive damage to fired equipment. So, I can do a lot of diagnostics to know that my flow measurement has failed. So, just because I know that my flow measurement has failed is not enough.

So, you might simplistically take credit for your diagnostics when you're doing your SIL verification. But, how do we know that those diagnostics are effective? So, just because the transmitter knows that the device has failed doesn't mean someone's coming out to repair it. And it doesn't mean that my safety instrumented function is going to go to a safe state. That needs to be thought through by the SIS design engineer. It needs to be documented. It needs to be verified. It needs to be tested on a regular basis.

So, the first part of the process is documenting at the sensor level, what does the sensor do when it detects a dangerous failure? Does it set its value off-scale high?

Does it set it off-scale low? And maybe the equipment vendor has a range outside of 4 to 20 that indicates that the device is not operating. It's in a failed state. So, historically, there's been a NAMUR spec that says when this happens, you should set your device to 3.75 milliamps. Because, you know, you can always go down-scale. You can't always go up-scale. So, dangerous setting is one attribute. Or, you know, you might fling it off-scale in whichever direction will cause a trip. So, what does your device do?

Then, you also need to have programming in your PLC to recognize that your transmitter is trying to tell you it has a problem. So, you might need to actually write the code that says, if the output from the transmitter is between 3.7 milliamps but less than 3.8 milliamps, the device is in the failed state. That's not the true measurement. That's just the transmitter trying to tell me that it's in the failed state. And when I get that bad PV or failed state, what do I actually do about it?

Do I just set an alarm and allow the operator to go out and fix the device while the plant's still in operation? Or, do I consider that a vote to trip in a redundant system? Or, if I have a one-out-of-one system or even a redundant system, does that failure trigger the final elements for its associated safety instrument and function to activate?

Well, the answer is that all of what I just described to you is allowable. You could do any of those things. You just need to make sure that your calculations reflect what you're actually doing and that your SRS elegantly documents what you're going to do. And you can see that there are requirements placed on sensors which are different from the requirements that are placed on the logic solver, which are different from the requirements that are going to be placed on final elements.

So, saying that you need to document it at the SIF level, kind of a dumb thing to do, to be honest. Because each component of the safety instrumented function has its own special requirements for what it needs to do when this situation occurs. So, now, that being said, you might do exactly the same thing for every piece of equipment in your plant. At which point in time, you're perfectly okay to write it down one time as a general requirement.

But, you might also want to put it on the data sheet, especially if brand X level transmitters, you do this. Brand Y pressure transmitters, you do that. There might be different things done for different pieces of equipment. And there you go into Vertigo. You expose the data sheet fields that talk about response and what you do to respond to a failure of a component.

And you could document it at the component level. Oddly enough, the worst plan… There's almost no reason that you would want to actually document this at the SIF level. So, what the standard says is probably the dumbest way to actually do this. Do it at the top general requirement level or do it at the component level or the subsystem level. You would virtually never want to document this at the SIF level.

All right, which again… Oh, yeah. The Kenexis way of documenting safety requirements is definitely the easiest to comprehend, the easiest to design against, and it's all embedded in that Vertigo software tool.

## Episode Summary and Next Episode Preview

All right, so that was bullet point 18 of the Safety Requirement Specification Clause 10.3.2. We're not anywhere near done. We need to go all the way to bullet point number 29. So, a lot of work still to do. But that's going to wrap it up for today.

So, when we come back with next week's installment, we're going to hit bullet point 19 where we talk about startups and restarts. Then we're going to talk about interfaces. We're going to talk about modes of operation. And we might even start dabbling in software safety requirements. But we are going to leave all that for next time.

## Kenexis Vertigo Software Advertisement

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.