Functional Safety Podcast: episode (S1E25) is now available

Introduction and Episode Overview

When commanded to close, a shutoff valve needs to move, but that’s just the beginning. There are a lot of other things to consider.

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.

SRS Bullet 12: Documenting SIF Output Actions

Okay, so we are still sitting in Clause 10.3.2, which is Safety Requirement Specifications, that long list of bullet items of things that need to be documented in your SRS. We are currently at bullet point number 12, which is going to talk about output actions. So bullet point number 12 says that you need to document a description of SIF process output actions and the criteria for successful operation, e.g. leakage rates for valves.

Now, where do we describe the output actions of a safety instrumented system? Description of the locations of, or where you document the output actions is going to be, number one, on a SIF by SIF basis, you will be describing the output actions in the SIF description. Okay, so that’s going to sit in the safety instrumented function list, the IPF list, and also in the description of the safety instrumented function itself.

Now, on a grander scale, all of the outputs are going to get documented in the logic description, which is usually in the form of a cause and effect diagram. So you’re going to have a list of what all those outputs look like.

Now, beyond that, you are also going to have descriptions of the output actions in the final element data sheets. Again, that’s going with the Kenexis process for doing safety requirement specifications as implemented in our Vertigo tool for SIS lifecycle management.

Now, for the output actions, you’re going to get a description of what action is actually being taken. So there are a lot of different things that could potentially be documented, because if you look at your SIF description, it’s going to say something relatively general, like this valve needs to close. Or in some cases, I’ve seen some, shall we say, poorly written safety instrumented safety requirement specifications that simply say what valve is being closed. So I’m going to take a look at a sample plant.

And if you look in terms of output action, I’ve got an output action that could be as simple as, in terms of a SIF description, you could have something like, the high pressure separator low level closes the liquid outlet valve. Okay.

That’s telling you which valve needs to move. That could be in an IPF description. In the final element, you’re going to want to put the tag numbers of the device. So SDV-102. And then usually, or best practice, shall we say, when you’re describing a final element, would be to describe where it’s going to go. So SDV-102 close could be an action for your safety instrumented system. Okay.

And I apologize for the coughing I’m doing on this episode, because, well, I just, I’m coming off of a cold that I picked up when I was out in the Middle East a few weeks ago, doing some webinars, or doing some seminars and some sessions at trade shows. So I apologize for that, but I am going to press on.

Okay.

So basically, in the description of the IPF, and in the IPF list, you know, kind of the process service of the final element, and you know, generally, what is required for success, and that would be for it to close. But now you’re going to want a little bit more information than that.

Cause and Effect Diagram Output Detail

And again, if we’re looking at Vertigo, you’re going to have cause and effect diagrams. So if you look at a cause and effect diagram, in Vertigo, we’ve got the ability to show that in the compact view, or in the detailed view. And if you just look at the compact view, it’s going to tell you all the final elements in terms of tag numbers, and their service description. But if you expand into the detailed view, you’re going to get a lot more information about that final element, including the device itself, any interface devices.

So shutdown valve 101B is going to have an interface device that is a solenoid valve or something. That’s going to be listed out. And you’re also going to have a description of what action is taken by that. So shutdown valve 101B is going to be activated through interface device XY101B. And then the action that’s taken is to close.

So that’s a little bit more elaborate of a discussion. But there are other factors that need to be considered. And one of the key other factors that needs to be considered is the one that gets all of the press.

Leakage Rates and Their Importance

It gets all of the attention because it’s actually listed in the standards. And that is leakage rates for valves.

Now, that’s not the only one. It’s the one that gets all of the press because it was listed out. And people will, you know, people with less experience, people that have read the standard but haven’t really done a lot of SIS engineering, are going to be wholly reliant on what’s written in the standard to do their work because they don’t have a lot of work experience to fall back on.

But there are other things that you are going to need to consider in the performance of your safety instrumented functions. And specifically, we’re looking at the final element subsystems. So what are the factors? So when you’re closing a valve, and I’ll just go closing the valve right now because it is far and away the most popular final element subsystem, what impacts the ability of that valve to actually achieve a safe state? Well, number one, the valve has to move. So it has to go to the closed position if it’s a shutoff valve.

It has to go to the open position if that’s what’s required to get to a safe state, such as a depressuring valve for a segment of process equipment. So number one, it needs to go to its position. Number two is it needs to go all the way to its position. So, you know, the degree to which something needs to be open to achieve a safe state is something that could be specified, but generally the expectation is that we’re going to want to go 100% open in order to achieve a safe position for a valve that has to go open to get to a safe state.

To get to a safe state when you’re closing a valve, it has to get all the way closed. And the question then is, well, what happens if it doesn’t get all the way closed? What happens if there’s leakage? Well, leakage is a topic that is so misunderstood that I have done at least three webinars on the topic, and there’s an entire section of a Kenexis training class dedicated to the topic of assessing leakage through a closed shutoff valve.

So before I get into that, so to get more information, you could go to the Kenexis Process Safety Training Center in KISS and go to the Safety Requirements Specifications Training Class and go to the section about leakage rates of shutoff valve. So there’s an entire section on that topic. Also in KISS, you could view our webinars or you could go to the Kenexis website, look under Recorded Webinars, and find one of the recorded webinars that discusses the determination of leak rates.

Analyzing Required Valve Leakage Class

Now, I go into this in a lot more detail in the webinars and training classes, but the importance of tight shutoff is overstated, and requiring tight shutoff is something that lazy, weak-minded engineers who have read the standards but don’t understand the practicalities of actual tight shutoff will put into their specs. So it’s not uncommon for every shutoff valve to have an engineer just write, it needs to be tight shutoff without really thinking through what that means to the people that are maintaining the equipment and whether or not it’s really required.

When you’re making the determination as to whether or not something requires leak tightness, you need to think about, well, what if it doesn’t close? Or more importantly, what if it leaks? How much leakage will result in the safety function that you’re trying to prevent still happening? So most of the time, the preponderance of the time, you can still achieve a safe state even with 1% leakage, 2% leakage, 3% leakage through that closed shutoff valve.

So in the SRS training class and in the webinars, I spend like an hour and a half to two hours going over an approach that you would use to look at every valve and say, what if this amount of leakage went through the valve after it had gotten to the closed position? Would that prevent you from achieving the safe state against the hazard that the safety instrumented function is intended to protect against? And most of the time, you’re going to get to a specification that says, class 1 shutoff is adequate for this application.

So class 1 shutoff, you’re going to need to go to some other ANSI standards that describe shutoff leakage classes of control valves to make that determination. But if class 1 shutoff is okay, then leak testing of valves every time you do a turnaround is not going to be required because leak testing is not required for a class 1 shutoff. You just have to realize that when the valve’s in the closed position, there may be a decent amount of leakage, but you don’t expect that decent amount of leakage to be able to result in an unsafe state.

Why Tight Shutoff Is Rarely Needed

Now, the reason that most safety instrumented functions don’t require tight shutoff or SIS valves don’t require tight shutoff is because when tight shutoff is required, it’s more of an issue that things have leaked through and that’s going to complicate my restart as opposed to preventing the hazard that the safety instrumented function is intended to protect against.

Nevertheless, if you do require tight shutoff and some applications do require tight shutoff, then you are essentially never going to use a single valve. You’d be crazy to use a single valve if you actually absolutely did require tight shutoff. So if you absolutely unequivocally do require tight shutoff, you’re not going to rely on a single valve. You’re going to use a double block and bleed or a double block and pressure depending on what direction of leakage you’re trying to prevent.

So a double block and bleed means you’re going to close two block valves and you’re going to drain the cavity in between the two block valves to a safe location. That is going to give you absolutely positive shutoff.

Double Block and Bleed Arrangements

And what’s kind of interesting is that in a double block and bleed arrangement, the two valves actually don’t need to have like a class five or class six tight shutoff to prevent the leak through because you have that wide open cavity draining. So you could get a 1% leakage through that first valve. It’s not going to go through the second valve because you have an easy path to drain the cavity. So the other complement to that would be something called the double block and pressure.

So instead of having a cavity that gets drained out to allow any leakage of either the two valves to drain to a safe location, the double block and pressure does the opposite. The two block valves are going to close, but then you’re going to apply pressure. So maybe you’ll, in the cavity between the two block valves, you will pressure it up with hydrogen. I’m sorry, not hydrogen, nitrogen, something that is inert. You’ll pressure it up with an inert and the pressure in the cavity would need to be higher than the process pressure on either side of the double block.

So that way, if any leakage occurs, it’s going to be the inert material going through the leaking valves into the process instead of the process fluids being able to cross contaminate each other.

So I’m going to tell you and you can think it through and please feel free to send me an email if you disagree with me, but there is virtually never a situation where you actually need a class five, class six, tight shut off for a safety instrumented function because most safety functions are going to tolerate a good degree of leakage to get to, you know, class one, class two type shut off. Class four for sure is going to be adequate for 99.99999% of applications out there. And if you truly do need tight shut off, no leakage is acceptable. You would be insane to use a single valve to do that.

You’re going to use a double block and bleed and a double block and pressure to make sure that you don’t get any cross contamination.

And when you have the double block and bleed or the double block and pressure, well, guess what? You can have leakage through the valves. It’s going to be safe. It’s just that that leakage can’t cause cross contamination. That leakage has to go to a safe location. Okay, so that’s a discussion of parameter number one. Does the valve go all the way to the fully open or the fully closed position? Is there any leakage? How much leakage can we tolerate? That’s usually where everyone stops because that’s all that they can think of.

Response Time and Valve Performance Criteria

Now, the other one that’s a slam dunk is that the valve needs to go to its closed position in a relatively short amount of time. And that short amount of time needs to be specified.

It needs to be documented. Now, you’ll get a little bit of a pass because there’s a whole separate other bullet item that talks about the speed at which SIF elements need to operate. So, it is on the one hand part of a process output action, but then again, response time requirements was bullet nine. We already talked about that, so no need to repeat it again. But now, in terms of leakage classes and response times, there’s another factor in terms of response time that doesn’t get a whole lot of press.

And that is that sometimes you don’t want a valve to close too fast. because if the valve closes too fast, you’re going to create something called a hydraulic hammer. Or there are other things that could happen when you close a valve too quickly. So, a maximum response time on a valve is something that definitely everyone thinks about and is going to document. but a minimum response time might be something that also you might not want to violate because you could create water hammer.

So, you could close a valve too slow. You could also close a valve too fast. So, response time requirements, leakage rate requirements, those are the things that you’re going to want to look at in terms of performance requirements. and those items are not comprehensive.

So, it’s incumbent upon you, the SIS engineer, to look at all of your final elements and figure out, do that kind of failure modes and effects analysis on that final element subsystem to figure out if there’s something that you need to specify about the system that will define its performance and it will impact the equipment that you purchased for your safety instrumented function but it will also impact the testing that you do.

So, maximum response time, minimum response time, leakage rates, if they are important, if they are specified, well, guess what? Every time you test the safety instrumented function, you don’t know whether or not the safety instrumented function was successful unless those requirements are met.

Testing Implications of Leakage Class Specification

and that’s why tight shutoff on a valve is a very onerous requirement. Well, first off, what does tight shutoff mean? Who knows? Class 6, we do know what that means because there’s a specification. So, if you require class 6 shutoff, guess what? Every time you test that valve, you need to confirm tight shutoff. And if you don’t achieve tight shutoff, you need to rebuild the valve. That could be a multi-million dollar every year decision that is not necessary.

So, when you’re adding these requirements, think them through. Now, where are you going to put these requirements? In your final element subsystem data sheet. So, if you go into Vertigo and you’re looking at a final element subsystem, you can click on it to get the final element subsystem data sheet. There’s going to be a section called tight shutoff and you can fill out fields that include target leakage class, target leakage required to achieve a safe state, kind of yes or no, and tight shutoff notes. You know, because here’s the other thing that’s interesting about tight shutoff.

which I’m glad on my screen I popped up the SRS data sheet because in reality, you might specify a target leakage class, but that target leakage class is not required to achieve a safe state. Let me give you an example. Fired heaters. A lot of industry standards and a lot of corporate standards will require a class 4 shutoff shutoff for fuel gas shutoff valves. Some will require a class 6 shutoff valve. So the corporate standard is trying to get at the equipment that you select.

But even though you selected that equipment, if you’ve got a double block and bleed, you’re not actually required to achieve that level of performance to get to a state. state.

So we in our data sheets in Vertigo, we give you some flexibility to say, yes, I am going to buy a class 4, class 5, or class 6 valve because that’s what my corporate standard requires. But that leakage class is not required to achieve a safe state. and if that leakage class is not required to achieve a safe state, then you’re not going to need to include the leakage test in your periodic function tests or at least not on as frequent of a basis as you would if it were required to achieve a safe state.

So make your life a little easier, make your technician’s life a little bit easier, and think real hard about leakage requirements. And response time requirements, both maximum and minimum.

Okay, so that was bullet point number 12. It requires a good bit of discussion, and I do encourage you to go look at those webinars and training class items because this is very misunderstood and really poorly done in industry, costing millions of dollars in unnecessary rebuilds and testing. testing. And that’s for a single plant.

SRS Bullet 13: Functional Logic Descriptions

Okay, the next bullet item is bullet number 13, and it is a relatively big dog. Bullet item number 13 states that you need to document the functional relationship between process inputs and process outputs, including logic, mathematical functions, and any required permissives for each SIF.

So bullet item 13 is I need a logic description. So some sort of way to tell the person who’s programming the PLC, some way to convey the information to operations of what the safety instrumented system does. basically the description of the functional logic of the safety instrumented system is one of the most critical things that you’re describing in the SRS.

Now how do you do it? How are you going to document this? Well, there are a lot of different ways, and I’ve seen all of these different ways in application at different operating facilities.

they have strengths, they have limitations. So let’s start out with the easiest one, and that’s going to be a narrative. You simply write a story, write a description, and that narrative could be, let me pull up my documentation here, it says, if the pressure in the high pressure separator as measured by level transmitter 101B exceeds the set point, then you are going

close the inlet valve to the high pressure separator SDV 101B by de-energizing the signal to its associated solenoid valve XY 101B. Okay, that’s a text description, that’s a narrative.

Narrative Approach to Logic Documentation

The strength of this approach is that you don’t require any specialized knowledge to develop this representation or to implement this representation. The downside is it’s extremely time-consuming to write, it’s extremely time-consuming to read it and do something with it. So if you’re programming a PLC, writing a program based on a narrative is probably the most complicated way to do things. Also, because it’s so unstructured, people will forget things. So it’s also the approach that is the most prone to human error because it is so unstructured.

There’s no mental cues to remind you to do things, which is a weakness.

So I do see a lot of narratives. A lot of times narratives don’t stand alone. They’re kind of a supplement to other ways of describing logic. But a narrative by itself is a completely valid way of describing logic.

Boolean Logic Diagrams for SIF Design

The next approach is kind of the most rigorous, the most scientific, which is going to be the Boolean logic diagram. So in a Boolean logic diagram, and you could go to the ISA standards to get a description of the standardized approach for creating Boolean logic diagrams.

But you have symbols that represent your input devices. You have symbols that represent your output devices. And you have a positive or negative, true or false logic, the system. And you have blocks that are going to describe things like switches, OR gates, AND gates, and also kind of the equivalent of an analog to digital conversion of your transmitter signals into Boolean logic.

So the strength of this approach is that it is very descriptive. interactive. It goes into a lot of detail on the instrumentation. There’s a lot of numeric values. And it’s really easy to program off of once it’s done because the program essentially looks virtually exactly the same as the Boolean logic diagram. If you use something like the IEC 1131 languages for programming. Some of those languages look exactly like the Boolean logic diagrams, especially the function block diagram approach that’s described in IEC 1131.

So that’s good, but on the other hand, it’s very time consuming. And if the program that you end up with and the Boolean logic diagram are almost identical to each other, seems like a whole lot of work for nothing. Which is why we’re going to get on to the third method for describing logic, which is far and away the most common approach.

Cause and Effect Diagrams: Benefits and Structure

I’m going to go out on a limb and say greater than 95% of the time, the approach that the process industries use to describe the logic is going to be a cause and effect diagram.

So what are the benefits of a cause and effect diagram? Number one, it’s very compact. So you’re providing a lot of information in a very small amount of space. A very few pages of paper are required to describe a lot of logic.

Number two, they can be developed very quickly, very easily, and don’t require a whole lot of training. I’ve got my causes are my SIS inputs are the rows. My SIS outputs, my effects are going to be the columns. And then the intersections are going to be the logic. so if this input is true, make the output true. So if I activate this sensor, then you need to activate this output, this final element.

So it’s easy to use. It’s very compact. It can be created very quickly. Also, it is very highly structured, so it actually has a very much lower probability of human failure than any of the other techniques, because you’re going to start out with a template that tells you the things you need to think about.

So for every input, there’s going to be a series of columns that you need to fill out that describe what that input is and how it affects the logic. Similarly, every column for an effect or a final element is going to have rows that will define the attributes of that final element. So a lot of information in a compact space.

And then also, you have the matrix grid where you compare every input to every output to decide what needs to be done with this output when this input is activated. And in those cause and effect interfaces or the matrix, the intersections between the causes and the effects, you can either put a simple X that says when this is activated, that gets activated, but you could put more descriptive information like close, open, information. You can even put in references to notes if the logic is more complicated.

So if an input, you know, let’s do something crazy and say that an input will activate an output only, you know, after five o’clock on a Tuesday, you can describe that in a note that is included as part of the cause and effect diagram. Now, in terms of the limitations of cause and effect diagrams, the intersection approach is really geared toward very simple logic.

When this is active, make that active. if you’re doing something very complex, so for instance, the most complex types of safety instrumented functions that I’ve designed are things that will do a real-time mass and energy balance. So let’s say I have a chemical reactor. I can measure the enthalpy in versus the enthalpy out, the flow rate of reactant in versus those enthalpies to determine how much unreacted material I have in the reactor. And based on the potential energy of unreacted material in the reactor, I might decide I’m in a hazardous situation and cause a shutdown.

Okay, that real-time energy balance is not really something that you’re going to be able to describe in a cause and effect diagram. And yet, I would still use a cause and effect diagram for the logic description for this. It’s just that I would supplement the cause and effect diagram with notes.

Supplementing C and E Diagrams with Notes

So those notes, if you go into the Kenexis Vertigo software tool, we list the notes under general requirements. So general requirements and specific notes all fall under one category in the software application. They’re just basically labeled differently. And you can create an extensive verbal description in those notes.

Now, going even further to this, you can put notes into a cause and effect diagram intersections. You can assign notes to inputs. You can assign notes to outputs. So between the cause and effect diagram structure and the ability to put in really lengthy, effusive notes for inputs, outputs, and intersections, that is the most effective, the most common way to create logic descriptions for safety instrumented systems.

And basically, I would highly, highly, highly recommend that approach to anyone that is new to the process of safety requirement specifications. And also, it is what we have for the most part ensconced in our Vertigo software. Now, that’s not to say that you can’t use the Vertigo software using other approaches for describing your logic. It’s just really optimized to this methodology because, hey, that’s what we’re all about at Kenexis.

We eat our own dog food, we use our own software, and efficiency, accuracy, prevention of human errors is what we focus on when we’re developing our specs, and that’s what you’re going to get in a cause and effect diagram approach, specifically the cause and effect diagram approach that is contained in Vertigo. All right, so that is bullet item number 13. Let me go on to bullet item number 14 before we wrap things up for today’s episode.

SRS Bullet 14: Manual Shutdown Requirements

So, bullet item number 14 states that you need to document in your safety requirement specifications the requirements for manual shutdown for each SIF.

Okay, so what the SRS is telling you is that for every safety instrumented function, you need to explain how to restart the plant after a trip has occurred. And right here, I’m going to go ahead and I am going to disagree, for the most part I’m going to disagree, with the standard, on the level of abstraction or where in the data hierarchy do you need to describe this.

Because the standard says you need to describe manual shutdown for each SIF. But I would argue that what you need to do is describe the manual shutdown for each final element.

Now, when we get into clause 11, we’re going to talk about manual shutdown. We’re going to talk about it in a lot more detail, so I’m not going to talk about it here. Because that manual shutdown, I actually did a webinar, so go to the Kenexis website, look for recorded webinars, there’s one on manual shutdown. So I spent well over an hour talking about manual shutdowns, when you need them, when you don’t need them.

But in terms of SRS, you need to be describing functionally how it happens. So the risk assessment to determine whether or not you need it, and what quality, is required. We’ll get to that in clause 11. Here I’m just telling you that you need to describe it.

So you might have a two position selector switch for every final element, where when you move that selector switch into the off position, you’re going to de-energize that final element out in the field. And if you do that, you’re probably going to want a double pull, double throw setup, with one set of contacts disconnecting power to that final element out on the field, and the other set of contacts sending power back to an input to say that that switch has been moved to the position that causes that valve

the closed position, or whatever position it is, a safe state. So that’s the most expensive, most comprehensive way of doing things.

Another choice that you have would be one single knife switch in the cabinet for the safety instrumented system that would be in the control room or in a remote instrument enclosure, where when you open up that knife switch, you’re going to de-energize all the power going out to the field all in one fell swoop. That’s a really powerful approach. It’s really cheap, can be done very cost effectively, but if you activate it, you’re rocking and rolling your plant.

I mean, it’s going to be moving all over the place because every valve out in the field just slammed shut, or as I said before, went to its safe state, which is usually slamming shut. It’s an option. Another option that you can have is just a DCS target that you can push that DCS target to communicate digitally to the SIS and perform the shutdown.

Another option that you can have is not to put any manual shutdowns at all because there’s no reason for it. The process moves so quickly, I couldn’t get to a safe state manually if I wanted to. Or I might have other basic process control valves in the line that I could use to do the same thing as the shutoff valve if the shutoff valve didn’t do its job.

Or I can hardwire a push button to the SIS logic solver and then have the SIS logic solver activate. So making the decision on which of those is appropriate because a little secret for you, all of those might be adequate. The only thing that the standard says to do is document the requirements for the manual shutdown and it doesn’t really specify what they need to be.

You need to make that determination based on your own risk analysis of what happens if my shutdown activates but the valve doesn’t move to its safe state. The final element doesn’t move to its safe state. What are the consequences? Is there anything I can do about it? And what’s the probability of it occurring? But like I said, we’ll get to this longer discussion when we get to clause

11.

For right now, whatever you decided, write it down. Because as the standard is written today, if you don’t write anything down, you still need to follow the standard which says, unless otherwise specified in the SRS, you need something that will de-energize or activate the SIF final element independent of the logic solver, which is going back to those switches that are physically disconnecting power from the field, which can be very, very expensive. So make sure to think it through and document what you need to do.

Wrap-Up and Vertigo Tool Overview

So with that, I’m going to wrap it up for the week. We knocked out another three bullet points. There’s, how many bullet points are there? There’s 29 bullet points that we need to get through. We just finished up 14. So as you can imagine, we’re going to be talking about this section for a little while. So I will catch up with you next week.

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.