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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E23 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 23: IEC 61511, Clause 10.3.2 Bullets 4–8 (Safe States, Demand Rates, and Proof Tests)

—

## Episode Teaser and Podcast Introduction

Continuing on in section 10.3.2, we're only at bullet point D, number four. There's a long way to go still.

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.

## Safety Requirements Specifications Episode Setup

So let's pick up where we left off. Specifically, we're going to be in bullet point D of Clause 10.3.2. We are talking about safety requirements specifications. And what we're going to learn is that a lot of them aren't specifications.

In our last episode, we talked about what it means to be a specification. We're looking at something that defines attributes of a physical piece of equipment. And we really kind of stress the fact that you shouldn't be listing operating instructions or calculation parameters as specifications. They're not. They're not specs. Now, that doesn't mean that you shouldn't be documenting them.

But putting those pieces of information into a piece of paper, if you will, that is intended to go to an equipment vendor to describe the product that they are supposed to supply, that's generally not the best location for that information.

So as we go through this section on safety requirements specifications, we're going to hit each bullet point. We're going to talk about what it is, why it's important, how to develop the information. We're also going to explain what it is. Is it truly a spec or not? And then we're going to give you some best practices for where you should be documenting this information. So without further ado, the fourth bullet point, the bullet point number four is where we are at at this point in time. So let's go ahead and read it off.

Now, as we read these bullet points, let's remember that there's kind of a prefix to them. So it says the requirement. So it's an inclusion of a requirement. So what is that requirement? So requirement number four is a definition of the safe state of the process for each identified SIF such that a stable state has been achieved and the specified hazardous event has been avoided or sufficiently mitigated. All right.

## Bullet 4: Defining the Safe State per SIF

This one, believe it or not, is much more difficult than you would think. All right.

Let me start out by explaining where this should be documented. So a definition of the safe state for each SIF should be listed in a SIF list. Okay. Okay. But it's going to occur in a couple places in a SIF list. And that would be in the list of outputs. And it will also be in the description of the SIF. So if you go into the Kenexis Vertigo software and you're developing your SIF list, you're going to be asked to provide a description of what the safety instrumented function does. And that's going to be, you know, all the way back up to bullet point one in this section, a description.

And a well-written description, well, you're going to need to go to the Kenexis Process Safety Training Center. You're going to need to go into the SRS training class where there's an entire section that describes how to write a good description of a safety instrumented function. But in terms of outputs, we want to know what action the SIF needs to take.

And the reason that I say this is more complicated than one would initially think is that most of the time, a lot of the time, when you're looking at a large cause and effect diagram for a plant, almost every input is going to trigger almost every output. And it's important to remember that that's not the safety function. So if you have a cause and effect diagram and you look at any sensor or any input, you're going to usually see not one, but three, four, 10, 20, 100 actions being taken. As a result of those inputs. Now, are all those actions part of the SIF? No. Very few of them are.

As a matter of fact, if you're defining your safety instrumented function, if you're required to take more than one or two, three on the outside actions, you're never going to be able to achieve your SIL target. So when you're defining your safety instrumented function, you need to think minimum and sufficient.

Minimum and sufficient. So for a hazard that that sensor is detecting, for that hazard, what is the minimum set of actions that is sufficient to get you to a safe state with respect to that specific hazard? Okay, so that's kind of a tricky distinction, a tricky definition, and it's something that requires a lot of thinking.

Because what we're really worried about is what are those actions that are going to prevent a consequence from occurring? Now, for practicality's sake, there are going to be a lot of other actions that are going to happen at the same time. And those additional actions, we sometimes will call them additional actions. We will call them auxiliary actions. We will call them sympathetic actions.

And whatever name they go by, we realize that once we start to shut a plant down, we need to shut it down all the way to get it to a state where it is stable, at rest, and ready to be restarted. So those actions might not necessarily be required to prevent the consequence of the hazard that that SIF is intended to protect against. But those actions will need to be taken in order to perform an orderly shutdown of the plant. So once again, I talked about this in the last episode. If you're shutting down a fired heater, you'll probably have a double block and bleed.

So you're going to close two block valves and then open one bleed valve. Well, closing the two block valves is a critical step to achieve a safe state. But opening the bleed valve is not. Opening the bleed valve is not part of the safety instrumented function. And that's because opening the bleed valve doesn't protect against a consequence that will result in an explosion, for instance, in the fired heater.

So a definition of the safe state. Definitely, you're going to have a list of what are the outputs and what position do they need to go to. So a valve needs to be closed. A pump needs to be stopped. A blower needs to be started. Whatever the actions are that are going to get you to a safe state. Those are going to be listed out, each action individually, in the output list or the final element list for that individual safety instrumented function. But a description of what those actions are is typically also going to be documented in that description.

Okay, so all these things are part of the SIF list. It's part of the definition of the SIF. And in the Kenexis Vertigo software, when you print out a data sheet for a safety instrumented function, that same exact description that was in the SIF list is going to show up in the SIF data sheets. Again, trying to avoid having different things or the same information show up differently in different places throughout the plant or throughout the safety requirement specifications, the design of the plant.

Now, the safe state is also technically described in the cause and effect diagram. But I think, you know, what this bullet point number four is really trying to get at is this information needs to be clearly defined for each safety instrumented function. And then that is going to get carried through to the SIL verification calculations, where you definitely do not want to include the PFD of all those sympathetic additional auxiliary actions that get you to a known shutdown state, but are not required to prevent the hazard from occurring.

Okay, so definition is a safe state. You're definitely going to have it in your SIF list as part of the description and also as part of the outputs. But it'll probably also show up in your data sheet for your safety instrumented function.

## Bullet 5: Concurrently Occurring Safe States

Okay, bullet point number five. You need to document a definition of any individually safe process states, which, when occurring concurrently, create a separate hazard.

So what do we mean there? All right, so that's the statement. And then the bullet point itself has, you know, parenthetically a couple of examples of this. So overload of emergency storage. So a lot of times at a oil and gas production facility, if you start to, if you close off one section of the plant, you're going to want to send the material to emergency storage. So kind of an entry point into an oil and gas production facility would be a, something like a knockout drum or a vapor liquid separator.

And if that entry point separator has a high level, you're going to want to stop putting material into that separator, but you have to do something with it. So you'll send it to a emergency storage tank. Well, there's only so much inventory that you have in the emergency storage tank. And eventually, as those items also start to overfill, you're going to need to stop oil from coming in by other means.

So that's an example. Also, another example will be multiple relief to a flare system. So you may be able to send one vessel or two vessels to a relief header. But if you have too many things trying to relieve to that header simultaneously, you are going to create a high back pressure situation, which might prevent one of the vessels that you're trying to get to the flare header from being able to get to the flare header. And then that piece of equipment will overpressure and rupture and cause a large consequence right there at that piece of equipment.

So this is really tricky to get at this information because it's something that you generally don't think about. When you're doing your layer of protection analysis, you have one scenario on your mind, and you're kind of taking that scenario from the beginning to the end. You don't want to clutter your mind with having everything happen simultaneously.

So determination of individually safe states that when they occur currently create a separate hazard is something that is often done during that validation study, or it'll actually typically be done during the PHA study, but separately via separate guide words or via a separate checklist. So trying to identify these situations and when they occur is something that you're going to want your HAZOP team, your PHA team involved in, and it's going to get documented honestly in that location.

So that analysis to determine if there are new hazards created by multiple safety functions activating simultaneously, you want to discuss, you want to document in your PHA, and if there aren't any of these situations, there's really no need to repeat that analysis in your safety requirement specifications.

So this is a place where you're probably going to want to have a general requirement or maybe a specific requirement that says that this item, this concept of individual safe states occurring concurrently resulting in a new hazard, you'll want to refer the reader of the SRS general requirements back to the PHA where that was discussed, especially if nothing came of it. But if something did come of it, that means that you need to design for it.

So whereas, and I'll go back to the example that I started at, so I have a separator that's bringing crude oil in from a field, if that first separator becomes overloaded, I'm going to close the valve that's going to allow material to get into the separator, and I'm going to start sending material to emergency storage. But that's not enough. So if the emergency storage becomes overfilled, now I'm going to want to take other actions upstream to close in wells to prevent the material from coming downstream.

Similarly, if there are situations where you have multiple relieves and your relief system can't handle it, you're going to need to perform additional design actions in order to address that.

And the logic of those additional actions are going to need to be defined in your safety instrumented system. And that's usually going to be new safety instrumented functions that handle these odd cases are going to need to be created and included in the design of the safety instrumented system in your SRS. All right. So that's bullet points four and bullet points five. Now, five was a little bit tricky because sometimes you have a general requirement that points you back to where we discuss this information in your HAZOP, in your PHA study, and you're not really documenting it in the PHA.

The only time that you would, or in your SRS, the only time you would document this in your SRS is if it's actually present. And if it's actually present, you're going to define it in the discussion of the logic for those new safety instrumented functions or the functionality that addresses this.

## Bullet 6: Assumed Demand Sources and Rates

Now, when we get to bullet six, bullet six is a case where I'm like, I cannot even believe that the standards writers put this in as something that should be documented in the SRS. And furthermore, it talks about documenting this for each SIF. So if you think back to the last episode where I admonished anyone using a section 10.3.2 fill in the blank, this is another one of those cases where this information has no business being documented in an SRS and you're repeating information that is shown in other places unnecessarily.

So, what is bullet point six that I am so unhappy with the standards writers about?

It says, you shall document the assumed sources of demand and the demand rate on each SIF. Okay. Now, is that information important? Absolutely. It was critical in clause eight, where we did our hazard and risk assessment. It was critical in, well, it was informed clause nine, shall we say, where we did our allocation. But, if you think from the perspective of, I'm creating a document to hand to a systems integrator or a vendor to build me a safety instrumented system. Do they need to know, do they care about the assumed sources of demand and demand rate on each SIF? No, they don't.

So, where did this information actually get documented originally? What was the first point in time where we wrote down the assumed sources of demand and demand rate on each SIF?

That's right. While we were doing our hazard and risk analysis. And, that information got documented in our hazard and risk analysis report. So, it's in that report. It was documented. It was discussed. It was talked through. Do we need to take that information, copy it, and put it into another document? Absolutely not.

Should you make a copy of it? Absolutely not. Why? You're asking for trouble. You're asking for information to change in one place and not get updated in another place. You're spending extra time for no reason. You're sending superfluous information to systems integrators and equipment vendors that they don't know what to do with. They're only going to ask questions to you about why they have this information and what the hell they're supposed to do with it. All right.

So, I think we could say for bullet six, do not include it in your SRS. Even though it says to include it in your SRS, I'm telling you, don't include it in your SRS. But, Ed, in order to be compliant with the standard, I have to document it. Okay. So, what we're going to do is we're going to have one general requirement. So, remember, general requirements, data sheets, cause and effect diagrams. That's what we consider our SRS. So, in the general requirements, you will clearly explain where your SIL targets came from and where that documentation can be found.

So, you will point back to a report that contains your SIL selection. You know, these days, that's usually in the form of a layer of protection analysis. And you will say, the SIL targets were selected based on a layer of protection analysis that is documented in report XYZ version Q dated on this date.

Okay. So, that's one way, one of the ways to do it. And there, you know, it really doesn't matter where you did your layer of protection analysis, what tool you used. So, you're going to reference where your SIL selection was and then you were going to say that for each safety instrumented function, the assumed sources of demand for each SIF were documented along with the rate at which those sources of demand occur. and further information on assumed sources of demand and demand rate can be found in that report. So, you're not going to copy the information over again in this location.

You're simply going to point the end user back to where that information exists and is properly documented.

Now, you don't necessarily need to always, you know, go with a specific version of a report, especially if you're using a sophisticated software package like the Kenexis Integrated Safety Suite where the Vertigo tool for SIS lifecycle management allows you to link back to the Open PHA study. So, a safeguard in the Open PHA study is linked to a safeguard in the Vertigo study. You can click back and forth between applications to see it in Open PHA, to see it in Vertigo. And, when you make changes one place or the other, you can synchronize, you can view both of the sources of data

*[inaudible]*

to make sure that they're correct and consistent with each other.

So, you actually have a software link in the database that will take you back to your LOPA scenario. Even so, we at Kenexis would still have a one sentence in the general requirements stating that the assumed sources of demand and the demand rate for each SIF are contained in the Open PHA study linked to this Vertigo study. Each individual SIF has a link back to the Safeguard as it is shown and used in the layer of protection analysis for SIL selection.

So, that is how we deal with bullet number six, the assumed sources of demand and demand rate on each SIF. One last time, I will warn you again, do not use a Section 10.3.2 Q&A form. And goodness sakes, do not repeat that information in multiple places. You're wasting time, you're wasting money and creating confusion. Nothing good will come of it. Okay, let's continue on with a couple more items.

## Bullet 7: Proof Test Interval Requirements

Bullet point seven and bullet point eight are also items items that you have no business documenting in your SRS package. And once again, when I tell you that you shouldn't be documenting something in your SRS package, what that means is that you should be telling people where that information lives, where it is properly documented, and not repeating it. So, items seven and items eight kind of live together because they're related to proof tests.

Now, we all know that proof testing is an absolutely essential part of the SIS safety life cycle, and I would go out on a limb and say most accidents, or a lot of accidents, not most, a lot of accidents related to safety instrumented systems are a result of not properly maintaining and testing the safety instrumented functions that we have, leaving them in a state of disrepair so that when they are called to act, they do not, and then a catastrophe ensues. All right, so what are these two bullet points, seven and eight, that require us to talk about proof testing?

Bullet point number seven states that we need to document requirements relating to proof test intervals, and bullet point eight states that we need to document requirements relating to proof test implementation. So seven and eight are both related to proof tests, but there's a little bit of a different spin on them.

All right, so what should you not do? You should not have a 10.3.2 checklist, and when you come to bullet point seven, you fill in what the proof test interval for the SIF is. There are a number of reasons that that's a bad idea. number one, the SIF itself might not have a proof test interval. You might have a different proof test interval for the sensor, from the valve, from the logic solver. So putting a fill in the blank field for proof test interval for the SIF might not be accurate.

It might not work because your subsystems are where the test intervals actually reside, not the SIF as a whole. Sometimes there's consistency, and the whole safety function is tested at one time, but not always.

So from a database computer science perspective, the attribute of proof test interval belongs on a component, not on the SIF itself. Now, furthermore, where should these intervals be documented?

Well, I'm going to hedge my bets because there are a couple places that are equally appropriate for this kind of documentation. Number one, generally before you issue an SRS document set, you're going to do SIL verification calculations, and when you do your SIL verification calculations, it is necessary to specify what the proof test intervals are for all the subsystems because that's part of your calculations. So you know that the test intervals are going to be in the SIL verification report.

why would you document them again if you don't have to? So one very good, very good, very solid option for documentation of required proof test intervals is to simply have one general requirement that says the proof test intervals of all safety instrumented functions functions and or the individual subsystems that those safety instrumented functions are built out of can be found in the SIL verification report and give the title, give the revision number, give the revision date, so on, whatever you're going to have to do.

So that is going to point the user to the one source of the truth, the only location that's important, for this piece of information.

Okay, that's a handy way to do it, but another place that you might want to document these proof test intervals is on the data sheets for the instruments, or if you are testing the whole SIF one at a time, you might also want to document the test interval at the SIF data sheet. What you don't want to do though, again, is have a SIF by SIF 10.3.2 checklist where you're filling in the blank. That's definitely a bad idea.

Repetitive information for no good reason. Now, the reason I say that you might want to include that test interval on the data sheets is, once again, if you are using a sophisticated tool like Kenexis Vertigo, then you're using a relational database, so that test interval is only meant at one time. It is an attribute of a sensor or a logic solver or a final element, but your sophisticated database tool is going to allow you to print out different reports. So you print out a report for SIL verification, you print out a report for your sensor data sheet or your final element data sheet.

Those data sheets can contain those information items, but ultimately there is one source of the truth, and that is the one field in the database that contains the test interval for that subsystem, for that component. Alright, you would think that I'm done. I mean, with this one bullet point, you'd think that I'm done, but I'm not, because as we're going through the SIS safety lifecycle, it turns out we're going to need to document that proof test interval in yet another location, and that other location falls out of the specification world, and falls into the operating instruction world.

Yes, that is right. Somewhere in your maintenance organization, you're going

*[inaudible]*

have documentation of how often devices get tested, so that you could do your scheduling testing, and your resource assignments to perform these periodic function tests. So, those proof test intervals are also going to live in your computerized maintenance management system. Well, maybe you have a computerized maintenance management system. now, maybe you're doing something a little bit less sophisticated.

So, you know, in terms of computerized maintenance management systems, you're probably with the things like SAPPM or Maximo. There are a lot of tools out there that are very sophisticated to help to plan and execute maintenance activities and keep track of the results.

It just so happens though, that in the Kenexis Integrated Safety Suite, that Vertigo module for SIS Lifecycle Tracking also has a portion of the module where you can track your testing. So, it's kind of a best-in-class answer because once again, there's only one location that contains that test interval.

It's just that that one data point in the relational database can be used for SIL verification, it can be used for SRS, and it can also be used for online data tracking.

Now, if you're going to use a more sophisticated tool like a computerized maintenance management system, you're going to want to make sure that what's in your SRS and what's in your CMMS are consistent with each other. One good way of doing that is having those systems talk to each other.

So, if you're using, again, really good software like Vertigo, we also have application programming interfaces, APIs, where the KISS software can communicate with your Maximo and pass information about how frequently devices need to be tested back and forth, either in a one-time push or a continuously scheduled handshaking between the systems to make sure that the data is the same between them.

But then again, I mean, you know, other people kind of use less sophisticated methods. So, the least sophisticated method, I will have to give credit to my brother John, who at one point in time ran a field in southern Colorado for an oil and gas production company.

And his maintenance management system, being the maintenance manager and making sure that everything needed to be tested, was a whiteboard. That's right. For every sensor and every final element, he had whiteboards that had tag names and what was the date the item was last tested, when is the time, the due date for when the next test needs to occur, and whenever he would go into his office, he would look at the whiteboard and figure out what work needed to be done that day or that week and schedule it accordingly.

So, things can be really different for different operating organizations. So, requirements related to proof test intervals for one person might live in three different databases. For another person, they might exist on a whiteboard in their office. But,

*[inaudible]*

they're documented and the program for making sure that the testing gets done is good, everything is going to meet the requirements of the standard.

## Bullet 8: Proof Test Implementation Requirements

All right, next item, bullet point eight, which is still part of proof tests, is the requirements related to proof test implementation. implementation. What, what, what, what? What does that mean? How is this different from bullet point number seven? So, for bullet point seven, we're talking about a test interval. How long can we go in between tests of a component of the SIS? Bullet point eight is actually talking about how the test needs to be performed.

So, while SIL verification calculations are going to talk about how often a test needs to be performed because that goes into the calculation, they don't go into the details of how the testing is performed.

Now, in terms of how the testing is performed, why? does this stuff belong in an SRS? Does it belong in an SRS? For the most part, the answer I'm going to give you is no. And what is the place where we're definitely not going to put it? We're not going to have a SIF by SIF 10.3.2 checklist where we're going to describe how to perform a test for an individual safety instrumented function.

All right, where does this information belong? Well, let me tell you where most of the description of how the test needs to be performed, where does that belong? It belongs in the test procedure. And test procedures are not specifications, they are operating instructions. They explain how you are supposed to operate and maintain the plant. So, requirements related to proof test implementation for sure are going to exist in your written proof testing procedures.

But, we may want to specify a little bit more than that, especially during the early stages of the safety life cycle. We might want to write some rules, some admonishments about how thorough the testing needs to be because we made assumptions during the design process on things like proof test coverage that went into our CIL verification calculations that are going to be impacted by the thoroughness or the coverage of that manual proof test.

So, what I would recommend is a general requirement. So, a general requirement that describes the degree of rigor that needs, that the test needs to be performed in, and then describes the fact or conveys the fact that this level of rigor needs to be included when the test procedures for the components of the safety instrumented function are written. So, one general requirement is something that I'm going to want to have documented. It's definitely not something

*[inaudible]*

you're going document SIF by SIF. That makes no sense. You definitely don't want to do it on individual equipment data sheets. So, kind of a general requirement is kind of the sweet spot for saying the level of detail that needs to be included in your test procedures.

Kind of a motherhood and apple pie statement. But at the end of the day, where the rubber meets the road is going to be those test procedures, which we're not going to get to until clause 16 of the standard. And when we get to clause 16, oh boy, do I have a lot to talk about when it comes to test procedures. But we'll leave that for another episode.

Now, before we leave this bullet point, bullet point number 8, that states you need to document requirements related to proof test implementation. One thing that I will tell you that needs to occur during the SRS time frame is a consideration of how tests need to be performed performed and specification of equipment that's required to implement a proof test, especially if that additional equipment needs to be part of the design of the safety instrumented function or the design of the plant itself.

So, let me give you some examples. If I need to perform a full stroke test of a valve once per year in order to achieve my SIL target, but the plant is not going to be shut down but once every five years for a turnaround, then one needs to ensure that the plant is designed to be able to do a full stroke test of a valve while the plant is online and running, that means isolation valves, that means bypass valves, that may mean additional equipment on the bypass valve to inform the operator that the valve is not in the closed position, which means that the safety function is bypassed.

That might mean we need to include that bypass valve on our car seal system. There's a whole lot that goes into this. And determining that all this equipment is required the day after you start the plant, oh that's a no-go. That's not going to work. I need to know all of this. I need to design for all of this before the plant is started.

So think about how you're going to perform your tests during the design phase, during the SRS. and if I need design attributes like full-sized bypass valves around shut-off valves, if I need to be able to put sensors into bypass, I need to think about how I'm going to do that, whether I'm going to have physical bypasses in the field or logical bypasses in the control room.

So those attributes need to be thought through. Now, does that mean I'm going to have a field in my document that says requirements for proof test implementation? No. No. That's not where you're going to document this. If you have that field, get rid of it. It's kind of dumb. So there is the general requirement about, you know, the thought process of proof test implementation, but if you need to design a bypass, that needs to be discussed in the bypass section.

If you need to have a full flow valve, that should probably show up in the piping specs, show up in the piping and instrumentation diagrams. There are correct locations for that information. And a clause 10.3.2 checklist on a SIF by SIF basis is not only not the best place for it. It's a stupid place for it. That's a bad, bad. Don't do that. That's not how you should be documenting your safety requirements.

## Episode Wrap-Up and Next Episode Preview

Okay, so that gets us all the way out through bullet point eight. In our next podcast, we're going to pick things up with bullet point nine because bullet point nine talks about response time requirements. and that bullet point alone is going to require a lot of discussion. Is it going to be one full episode, one bullet point in clause 10.3.2?

Maybe. Probably not, but maybe. So we will get to response time requirement and how they are related to process safety time and the new item, MERT, that's going to show up in the next version of the IEC 61511 standard. All of that we will get to next week.

## Kenexis Vertigo Software Overview

Now that you've heard some insights on technical safety, functional safety, and the IEC 61511 standard, let me tell you a little bit more about how to easily and effectively implement the safety life cycle using the Kenexis integrated safety suite and our SIS safety life cycle management tool, Vertigo. Vertigo is a comprehensive tool set for performing assessment calculations, documenting, and maintaining the design of safety instrumented systems.

Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation.

Each safety function can then be analyzed by performing a SIL verification calculation, complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities.

After the SIL verification calculations are defined, you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments.

each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries. After the design phase, you can even use Vertigo to track and document testing throughout the entire life of the facility. Kenexis Vertigo is the most integrated, easy-to-use enterprise tool for allowing the development of SIS design basis information more efficiently and effectively than any other software application.