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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E24 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 24: IEC 61511, Clause 10.3.2, Bullets 9–11 (Response Time, SIL Target, and Sensor Measurements)

—

## Introduction and Episode Overview

Process safety time is one of the most confusing things in the IEC 61511 standard, which is why we're going to change it to MERT.

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.

## Process Safety Time Confusion and MERT

Okay, from my dry intro, I have already alluded to the fact that we will be talking about process safety time today. Process safety time is a difficult concept. It's a confusing concept. Different people use it in different ways. A lot of times it's used wrong, which is why we have to go to so much trouble to clarify what we mean when we talk about process safety time.

And ultimately, it's so confusing that we had to create a new term. So, as you know, I'm on the IEC 61511 committee. And as I sit here on the 20th of January in 2025, we are in the process of updating the standard for a subsequent release. Hopefully, not later this year, but I think next year we'll be able to get that out the door.

And one of the topics that we've gotten into is a discussion, a serious discussion of process safety time. Because if you look at the definition of process safety time, it's not really very helpful, or it's only partially helpful in developing response time requirements for equipment.

So, we went so far as to, in the cleanup process, defining a new term called MERT, M-E-R-T, which would be Maximum Equipment Response Time. So, this Maximum Equipment Response Time concept is used in a lot of other standards. It's used in the Machinery Standard from IEC. And it's more of a tight and direct correlation to what we're really interested in when we're determining what the response time requirements for the safety instrumented function are.

## Bullet 9 Requirement and SRS Structure Critique

So, let's go back and look at the standard. As you know, we are still in Clause 10.3.2. We are on bullet number 9 out of 29 bullets total. And each one of these bullet items takes a lot of discussion to really delve into them and get to the core of what's important. Now, bullet point number 9 is the bullet point that tells you that you have to write down, you have to define how quickly your safety instrumented function needs to operate.

But the terminology that was used, the way things were defined, it really doesn't work out that well to the point where we had to abandon process safety time and replace it with MERT. But actually, we're not going to get rid of process safety time because so many people are using it. So, this was a big topic of discussion in a meeting that the IEC 61511 committee had in November. Was it November or was it December? I think it was November of last year, 2024, in Houston. But we're going to be delving into it in more detail. So, there's going to be a lot more on this topic to come.

But without belaboring the topic, let's go to the standard and read the requirements. So, this is 10.3.2 bullet 9. Which states that you need to define the response time requirements for each SIF to bring the process to a safe state within the process safety time.

So, that's the requirement. One more time. Response time requirements for each SIF to bring the process to a safe state within the process safety time. Now, in addition to the definition, there is also an informative note. That informative note states, note, CIEC 61511 Part 2, 2016, for further discussion of process safety time. So, even in the Part 2 of the standard, which is all informative information supplementing the normative core requirements that are in Part 1, there's already a lot written about the ambiguous, misused term of process safety time.

To where we really needed to discuss it in a little bit more detail. So, a note is going to point you to the Part 2, informative information. That informative information is going to be expanded in the next version of the standard when it comes out. But you'll see that there is a key definition in here. Well, a couple definitions. Response time requirements and process safety time.

And it furthermore states that you need to define the response time requirements for each SIF. Wrong answer. No. No, you don't. Response time requirements are not an attribute of the SIF. They should not be an attribute of the SIF. They belong at the subsystem or the component level, not at the SIF level. So, right out of the gate, that whole concept, again, I'm going to keep hammering it home. You're going to keep hearing me say that if you have a SIF by SIF checklist of all 29 bullet items in Clause 10.3.2, and that's your SRS, that is junk. Stop it. Don't do that.

That's a horrible, horrible way to write safety requirements specifications. They're going to be misleading to the people who are trying to design your system. You're going to end up buying the wrong equipment. They're going to go out of date. It takes way too long to prepare stuff this way. And the result is junk.

So, we're going to follow the Kenexis approach, which is general requirements, data sheets, and a cause and effect diagram logic description. So, where I'm going to end up telling you to document this information is in the data sheets for the sensors, the data sheets for the final element, and the data sheets for the logic solvers.

So, that's where these response time requirements need to be documented. But, it doesn't hurt to sum all of those up for the SIF. And then, at the SIF level, also document what we now call the process safety time and what we are going to, in the future, refer to as a MERT. So, the key to this bullet point is it's trying to stress and impress upon you that when you're defining how quickly your components in your safety instrumented system need to operate, the primary thing that you need to think about is how quickly are you going to get into trouble.

Because, ultimately, the key requirement is that your safety instrumented function needs to operate fast enough to where you don't get into trouble. What we're trying to avoid is the situation where your safety instrumented system closed the shutoff valve after your plant exploded. So, we want to be able to operate quickly enough to avoid the consequence from occurring.

So, if we think about that, we need to know how quickly can we get into trouble. That's our process safety time. More on that coming up. And then, set the response time for the components or subsystems of the SIF such that the totality for the whole SIF is less than the process safety time.

## Process Safety Time Definition and MERT Rationale

So, let's go back. I've got a copy of the standard open on my desk. I'm going to go back to bullet point, or I'm sorry, clause three. And I'm going to try to find a definition of process safety time, which is then going to allow us to further discuss why process safety time is such a horrible term. And that it really doesn't help you when you're defining your response time of your SIS component. So, way back weeks ago in the definition section, we talked about clause 3.2.52.1, which is the definition of process safety time.

That definition, again, is process safety time. Time period between a failure occurring in the process or the basic process control system with potential to give rise to a hazardous event and the occurrence of that hazardous event if the SIF is not performed. So, that's the definition.

There is also a note to this definition. That note says, note one to entry. This is a property of the process only. The SIF has to detect the failure and complete its action soon enough to prevent the hazardous event taking into account any process lag. For instance, cooling of a vessel. Okay, so the process safety time is actually going to be a lot longer than the MERT, the maximum equipment response time.

And that's because there's going to be lags that will be included. It will add time to the process safety time. But there is a portion of that process safety time that is not available to you. It's not available to the safety instrumented function because it occurs before the safety function, shall we say, knows that it has to activate.

So, the maximum equipment response time, the MERT that we're going to define and should be the basis of that safety requirement specification requirement is going to basically be, this is the time that you have available for your safety instrumented function to be able to activate. Considering the dynamics of the process and the set point of the safety instrumented function and when the safety instrumented function is going to know that it has to activate.

## Reactor Example Comparing PST to MERT

So, let me give you an example of why the process safety time is not the metric we want to hang our hat on in that SRS definition and why we want to use MERT instead. Think about this. Think about this.

And as the temperature rises, I might get to a self-accelerating decomposition temperature or I can detect that a runaway reaction is beginning and I'm going to want to take some sort of action. Maybe I'm going to inject a kill agent into the reactor to stop that reaction from occurring. or maybe I might want to just close the inlet valves that are feeding the reactor. There are a lot of different reactions that you could take. Now let's take a look at the process safety time.

So the process safety time doesn't care about the SIS, the equipment that you're using for the measurement. It's all inherent to the process. So in the definition I say the time period between a failure occurring in the process or the basic process control system with the potential to give rise to the hazardous event and the occurrence of the hazardous event if the SIS is not performed.

So if I had no safety instrumented function, I'm not taking any other mitigative action using other IPLs, what is the event that or the failure in the process that started the chain of events? That's the initiating event in your LOPA, if you will, your layer of protection analysis. Well, in this case, that would be failure of the pump. So the pump failure starts the clock. Then the pump failure means that I lose my coolant. So there's going to be a time lag between when the pump fails and when the coolant stops flowing. Okay, there's going to be some momentum.

Things are going to flow for a little while. Maybe there's some gravity. And then there's also going to be another time lag that says, okay, well, I lost my coolant. Now I'm not taking the heat out of the reaction. So the heat of reaction is going to stay in the reactor. And after some period of time, that heat of reaction staying in the reactor is going to cause the temperature of the reactor to increase. But you're operating that reactor inside a normal operating range.

So it's going to take some time before that temperature actually gets outside of the normal operating range to a temperature that is abnormal. And then it's going to take even more time before that temperature actually gets above an appropriate set point for the safety function to activate, to perform its action.

Huh? Well, that could have been a long time. That could have been minutes between when the pump failed and the temperature got up to the set point where my safety function is going to activate. Now the safety function could be a temperature measurement, a logic solver action, and a valve moving to an open position to inject kill agent. So there's three components that each need to have a spec on how quick they operate. There's the sensor. So how quickly can the sensor turn around a measurement?

Now, don't forget there could be some time lag between the temperature in the vessel and the temperature that's measured in the, by the thermocouple because the process temperature needs to heat up the thermal well in order for that temperature to get transferred to that thermocouple. So there's another time lag that's affecting our process safety time. Ultimately, the time that your safety function has available, the maximum equipment response time, the MERT, actually is when the temperature in the thermal well is high enough to activate the safety function.

That's the real starting point on the clock. And then from the point in time when the temperature in the thermal well is above the trip point, from there, how much time do we have before the explosion occurs? Because if the temperature continues to rise, you're going to initiate a self-accelerating decomposition. The temperature is going to arise. That's going to cause probably a pressure rise, which is going to exceed the maximum allowable working pressure, which is going to cause the vessel to rupture.

So your MERT, the actual amount of time that that safety function has available, should only include the time when the temperature inside the thermal well is high enough to activate the safety function and when that vessel exceeds the maximum allowable working pressure and causes the rupture, the explosion, the loss of containment. That MERT is substantially shorter than the process safety time, because the process safety time included started, the timer started when the pump failed.

So there's a chunk of time between when the pump fails and when the temperature in the thermocouple is high enough to activate the safety function. All of that time is not available for the safety instrumented function. You need to throw that away. So that's why when we look at that definition, let's go back to the definition again in clause 10.3.2. Bear with me for a second while I scroll back through. That definition says that the response time requirement for the SIF to bring to the process safety, bring the process to a safe state within the process safety time. That's no good.

So that's why in the next version of the standard, the phrase process safety time is going to be replaced with MERT maximum equipment response time to tell you that you need to think about how much time you have available and it is actually going to be shorter than the process safety time.

## Response Time Requirements at Component Level

So now once I know what the MERT is, the maximum equipment response time, I just need to make sure that my SIF is going to be able to respond faster than that. But I need to allocate that total among the components. So right now it's a horrible idea going back to that approach that I've been trashing of saying, okay, well, um, if the MERT or the process safety time is 20 seconds, then I need my safety instrument function to respond in 10 seconds or 20 seconds.

You know, there are some people that are kind of using a version of the Nyquist sampling theorem that says, uh, that I should respond in half the time. In reality, you don't have to respond in half the time. Uh, you just need to make sure that your safety function as a whole responds faster than your MERT. But if you spec out a total number for the whole SIF, you've not done your job. You have failed.

Maybe you're in compliance with the words of the standard, but the equipment vendor for the valve needs to know how quickly the valve needs to move. Not the safety function as a whole, the valve. The person programming the safety PLC needs to know what the maximum amount of time that they are allowed to execute the code running in the safety PLC. The vendor of the sensor needs to know what kind of sample time, what kind of cycle time that their equipment is allowed to have. So putting one spec on the entire collection of equipment is a failure of instrumentation and control engineering.

Because you haven't given the information to the people who need the information. You're going to be buying a final element. The vendor of that final element needs to know how much time they have. How much time is available for the whole SIF is irrelevant to them. They need to know what chunk of that total amount of time that they have. Same with the logic solver vendor, same with the sensor vendor. Which is why it is essential when you're writing your response time requirements that it is done at the component level, not at the SIF level.

Now, if you want to collect together the components into a total and make sure that is less than the maximum equipment response time, that's fine. As a matter of fact, you might want to use your relational database to sum up your numbers for the individual components so that you could see what they are. Maybe you might want to do that manually. Okay, so we know definitively we want response time at each component. When we say we want a response time at each component, that might tell you that you want to spec this out at the component level for each component.

Which means that you're going to have a field on the sensor data sheet, a field on the logic solver data sheet, and a field on the final element data sheet to contain this information. Which is a completely valid way to do this. But yet, at Kenexis, we don't recommend that. Why is that the case? And the reason is, it's going to be really, really repetitive. Now, in general, your safety instrumented functions are going to be able to activate way, way, way faster than the MERTs or the process safety times of your individual safety instrumented functions.

So, to save time during the design plot process, we will generally use boilerplate.

So, we will say, in a general requirement, as opposed to an individual data sheet, we will say that the general requirement is that each safety instrumented function will activate in less than 10 seconds. And that SIF of 10 seconds, the response time of 10 seconds, shall be broken down such that the sensor shall activate in less than one second. The logic solver shall activate in less than one second. And the final element shall activate in less than eight seconds. Why did we give the final element eight seconds when we gave everything else one second? Because valves move more slowly.

So, using a general rule of thumb, a valve is going to move about one inch per second. So, a six inch valve will take usually about six seconds to close. Whereas, your standard smart transmitter is probably going to execute its program in about 100 to 300 milliseconds. Logic solver is typically going to go 100 to 300 milliseconds. So, if you spec out a one second for each of those, you're giving kind of more time than the worst case scenario.

Whereas, with valves, if you have a 10 inch valve or a 12 inch valve, your boilerplate statement of eight seconds might conflict with what that valve is actually capable of providing.

## Boilerplate Response Time Approach and Exceptions

So, in the workflow for writing out the response time requirements, and I'm going to give you a homework assignment if you have access to the process safety training center in the Kenexis integrated safety suite. And if you don't, seriously, why don't you? There's so much good information there. But in the safety requirements specifications training classes, there's an entire section on defining response time requirements for pieces of equipment. It talks about MERT. It talks about process safety time.

But what we say is that your workflow should be number one to define your boilerplate. And have that boilerplate apply across the board. But, you, during the engineering phase, need to confirm the boilerplate.

Meaning, you need to confirm on a sift-by-sift basis that all of the subsystems are capable of performing as quickly as your boilerplate said. And if they're not, let's say I have a 30 inch valve I need to close, it might not be practical to close that valve in less than 30 seconds.

So, if that's the case, you might want to put an exception to your general requirement and a note on the valve data sheet saying, for this valve, it's okay for it to close in 30 seconds. And that's also going to require for you to confirm that the process safety time or the MERT is sufficiently large to allow that valve 30 seconds. And your safety function as a whole then, 32 seconds.

So, we're going to, in our engineering process, again, define the boilerplate. Confirm that the equipment can execute in the boilerplate. If there's an exception, document it and make sure that it's acceptable. And the second part of that is then to also go to every safety function and verify that the MERT is longer than the boilerplate time duration.

If the MERT is not as long as the boilerplate, so let's say I've got a compressor overspeed, 10 seconds is not acceptable for a compressor overspeed. I'm going to need that safety function to execute in a second or two, maybe even less. So, you're going to need to do that confirmation. And then our documentation is going to be by exception as opposed to calculated for each component and every SIF.

And that MERT, or the process safety time, is something that you're going to want to document again in that one boilerplate note. But if you need to take an exception, take that exception at the SIF data sheet level. So, in general, I have 10 seconds, but for this SIF, I only have two seconds. And then that two seconds, remember that two seconds is all you have. So, you need to make sure that the instruments are capable of activating within those two seconds. So, a lot of discussion for one bullet point, but this one bullet point does bear a lot of discussion.

And it's even got one entire section dedicated to it in the Kenexis SRS training class. So, kind of recapping things here. The requirement was that you need to document the response time requirements for each SIF to bring the process to a safe state within the process safety time. So, my recommendation is a general requirement for the boilerplate. One second sensor, one second logic solver, eight seconds final element. But remembering that you do need to provide a spec for each subsystem, not the SIF as a whole.

Once you have the boilerplate spec of equipment response time and process safety time, during your engineering process, you will be confirming that those boilerplates are correct, are sufficient to achieve the safety objectives of the safety instrumented system. And if they are not, you will document by exception, by noting the exceptions in the general requirement, and or documenting those exceptions on the individual item data sheets. Okay. Okay. That is bullet point nine, and we have gone over a half hour on that one bullet point.

I am going to do two more bullet points before I wrap it up for the day, because these next two bullet points are relatively straightforward.

## Bullet 10: SIL Target and Mode of Operation

So, bullet point number 10 states that the SRS shall document the required SIL and mode of operation, whether that's demand mode or continuous mode, for each safety instrumented function. All right. What do you think I'm going to say about the required SIL? What do you think I'm going to say? What do you think I'm going to say? Don't document it in the SRS.

Don't. It's inappropriate. The safety integrity levels of the safety instrumented functions belong in the SIL verification. So, what you're going to want to do is put in a general requirement that says the safety integrity levels of each safety instrumented function were determined and documented during the SIL selection process. Go see the SIL selection report for the details, including the selected SIL. Stop repeating yourself in multiple documents.

You're wasting time. You're wasting money. You're generating crappy documentation, causing confusion. So, don't document that SIL in multiple locations. Now, that being said, if you look at a Kenexis SRS, you're going to see the SIL in the SIF list.

You're going to see the SIL in the data sheets for the SRS. You're going to see it in the LOPA. That being said, we're only realistically storing that information in one location in that Vertigo database. And then, depending on what you're printing out, that number might be included.

So, even though in Vertigo there's only one place to put the SIL target for a safety instrumented function, that number might show up when you print out the SIF list. It might show up when you print out the SIF data sheets and so on. So, you know, that's the beauty of the relational databases. There is one field that is the source of the truth, but it'll show up in multiple reports if that's what you want.

Now, as I mentioned in the last episode, that SIL can be linked back to the OpenPHA database where you did your SIL selection, where you did your LOPA study. So, there's going to be a linkage and the ability to view both of those in the same place to make sure that you have consistency. You can also cascade your numbers from your SIL selection into your SIL verification database inside that OpenPHA tool. So, that SIL, try to limit the number of places that you're going to repeat it.

If you're kind of an old school manual SRS, try to push the reader back with a general note saying that that information is included in the SIL selection report. But if you have a relational database, nothing wrong with having it show up in the SIF list and in the SIF data sheets.

I should further specify a little bit. It says the required SIL, but really what the clause should say is the required target failure measure, which could be more sophisticated than just the SIL. So, if you're doing your LOPA using an explicit LOPA and you're calculating a required risk reduction factor, you're probably going to want to document both of these things wherever you document the SIL.

So, if your LOPA says that you have a risk reduction factor target of 200, you will want to say that your SIL is SIL 2 with a minimum risk reduction factor of 200. So, in Vertigo, you have a field for SIL target, you have a field for risk reduction factor as a target failure measure that is separate. So, you can document both of those items.

Okay.

So, target failure measure might be SIL, might be risk reduction factor, probably both if you're using that more sophisticated, explicit version of layer of protection analysis. And, of course, if you're using the Kenexis suite of products, that risk reduction factor that's in Vertigo is also getting tied back to that OpenPHA database where you did your LOPA to come up with that target in the first place.

Okay.

That is SIL, but I didn't talk about mode of operation, continuous mode or demand mode.

Now, that continuous mode versus demand mode thing that you had to think about during your SIL selection when you were picking the SIL targets, you needed to think about it when you were doing your SIL verification calculations because the way you do your calcs is different between continuous mode and demand mode. So, it's something you probably would have documented during those phases of the project.

So, it's not inappropriate to document it in your SRS, but you can get away with pointing back to a prior document. So, you can definitely put together a general requirement that says all of the safety instrumented functions in this safety instrumented system operate in the demand mode. So, do it once in the general requirements, you're done. And most of the time, your safety instrumented functions will be operating in the demand mode.

I've been this for a long time, and I can count on one hand the number of safety instrumented functions that were in high demand or continuous mode. And when I ran into them, I usually had the control system and the process redesigned so that the safety function returned to low demand mode of operation.

Now, if in Vertigo, for instance, any other safety lifecycle tool worth its salt, there's going to be a drop-down box that allows you to select what mode of operation that that safety instrumented function operates in. And with these relational database type tools, you can print that information out on any report you want. So, if you look at a SIL verification calculation coming out of Vertigo, it's going to have the mode of operation. If you look at a SIF data sheet, it's also going to have the mode of operation for each SIF. So, general requirement is a perfectly valid way to do it.

Putting that information on the SIF data sheet, also a perfectly valid way to do it. And if you're using the relational database, that makes life easier for you.

## Bullet 11: Sensor Measurements and Trip Points

Okay, last item that I'm going to talk about today is going to be bullet number 11. Bullet number 11 states that the SRS shall document a description of the SIS process measurements, range, accuracy, and trip points. So, what are your inputs? What are the attributes of your trip points? Now, where do most people document this information?

Well, number one, I don't want to document it at the SIF level. So, once again, anyone who's using the tool that has a 29-slot checklist on a SIF-by-SIF basis, let me reiterate what a horrible idea that is. So, the sensor information does not belong at the SIF level. It belongs at the component level.

So, the information of range, accuracy, and trip point is an attribute of a component, not an attribute of a SIF. Furthermore, each SIF can have multiple sensors, multiple measurements that it's based on, and a single measurement can be used in multiple SIFs. So, if you do it at the SIF level, you're probably repeating documentation, which can get changed at different points in time. You're wasting a lot of time, and you're creating confusing documentation.

Document sensor-related information at the sensor level on the sensor data sheet. That is where it belongs. And here is, I mean, you can't even use a general requirement. This belongs on a sensor data sheet, period, end of discussion. Okay. But, maybe we might want to put it in additional places. So, again, the other location that I see a lot of sensor information like ranges, accuracy, and trip points is on cause and effect diagrams.

So, if you're using a relational database tool that generates your data sheets and also generates your cause and effect diagrams, which, honestly, I can't think of a SIS, Safety Lifecycle Management tool, that generates cause and effect diagrams elegantly, other than the Kenexis KISS, if you have that functionality, then that same information that you put in the record for the sensor is available for display when you print out your cause and effect diagram. So, the sensor row,

*[inaudible]*

on the cause and effect diagram, can have EU low, EU high, trip point, accuracy.

All that can be documented in the cause and effect diagram. If you're using KISS, it's just a matter of turning those features on and showing them in both locations. So, that's pretty handy.

Now, what you probably don't want to do is have something like an input list or an output list as its own separate spreadsheet document. If you're using a relational database tool like Vertigo, if you want a list of all the sensors and all their attributes, you can simply print that list out for use for whatever you're going to use it for, but having it as a separate tracked deliverable probably not a good idea.

You're going to want to leave that information on the sensor data sheet and if you're going to print out an input list, leave that as an uncontrolled document, good for day, that you can use for whatever purpose you're using, but not something you're going to want to have kind of as a long-term controlled part of your SRS.

## Preview, Sign-Off, and Vertigo Software

Okay, with that, that wraps up bullet point 11. Bullet point 12, let me give you a preview of next week.

Bullet point 12, you're going to get the same discussion that we just had about sensors for final elements, but final elements include something a lot more complicated called the criteria for successful operation such as leakage rate for valves, and that whole leakage rate for valves is worthy of a good 20 to 30 minute discussion in and of itself because it's one of the things that is done horrifically. I've seen it done wrongly, poorly, more times than I've seen it done right, and a lot of people will do something cute like say tight shut off, which is worse than saying nothing.

Shame on you if you've ever written tight shut off for a final element. Don't worry, I know I just shamed you there, but I will come back and tell you the right way to do this next week, and if you just can't wait, go into KISS, go into the Process Safety Training Center. There's a leak rate determination section in that training class that I'm going to talk about next week, but with that, I'm wrapping it up.

Next week, we're going to talk about leak rates of valves and a few more bullet items from the safety requirements specifications section. 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.