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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E33 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 33: IEC 61511, Clauses 11.2.9–11.2.10 (SIS/BPCS Separation and Device Sharing)

—

## Episode Teaser and Podcast Introduction

A device that's used by the SIS shall not be used by the BPCS unless that's what you really, really, really want to do.

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.

All right, welcome back to the podcast. We are recording here in the Marszal backyard again. I'm hanging out with Sammy the dog, who, if you follow our LinkedIn feed, you're going to know Sammy the dog. Me and him are sitting in the backyard, soaking up the sun and recording some podcasts. So enjoy some of the ambient noise in the background. I hear the birds chirping and the crickets are going to town. Just another artifact of the show today.

## Episode Overview: SIS and BPCS Separation

So today is, if we can get past Clause 11.2.10, that would be surprising. We're going to start at Clause 11.2.9, but the big topic of today's installment is going to be separation. Separation between the basic process control system and the safety instrumented system. We're going to dig into the Clause and try to tell you what it means. And then the Clause is just going to muddy the waters and make things even more confusing. Because it says, you can't do stuff. And then it says, well, yeah, you actually can. But if you do, then you got to be really, really sure.

And what does it mean to be really, really sure? Well, you know, that's what we're going to be getting into today.

So Clause 11.2.9 and 11.2.10 are going to be the big hitters. Let's go ahead and just jump right into the discussion with Clause 11.2.9.

## Clause 11.2.9: Independence and Dependency Defined

Again, one sentence. Technically, two sentences is all we're going to talk about in today's entire episode. Clause 11.2.9 is one sentence. Clause 11.2.10 is one sentence. And, yeah, well, let's get into it. So Clause 11.2.9 says, The design of the SIS shall take into consideration all aspects of independence and dependency between the SIS and BPCS and the SIS and other protection layers. So one quick sentence. And the key phrase there is independence and dependency. So it's not, with Clause 11.2.9, this is not where we're trying to forbid the use of combined equipment or shared equipment.

We're basically saying in this clause that you need to think about it. So it's more of a warning for doing your design process than actually a design requirement.

So when you're designing SIS, you need to think about all of the things that you might be connected to, all of the things that might cause the SIS to fail at the same time and for the same reason as other things that you're relying on to make your plants safe. So you need to consider all aspects of independence.

Now, going on to the topic of layer of protection analysis, which everybody knows is near and dear to my heart. I wrote that book way back in the year 2000. It was actually 1999 is when I started writing that book on layer of protection analysis. And when you're doing that type of layer of protection analysis, looking at your system design, what you're really telling yourself is that I am concerned about making sure that everything is independent. I have independent protection layers.

Because that's the only way that the math works, is that there is no situation where there's commonality between protection layers, between the protection layers and the SIS, between the protection layers and the initiating event.

So we desire to have 100% pure independence, but 100% pure independence is never possible. It's in the same plant. It's in the same physical location. The same people are going to be maintaining it. The same people are going to be installing it. You might have bought hardware from the same vendor. So independence is a goal. There's practical independence that is going to address the lion's share of the issues. But it's something that needs to be thought through during the design process from beginning to end. So we need to consider all aspects of independence.

And we need to consider all aspects of dependency. So right there in the first clause in 11.2.9, we're already conceding that there's going to be some dependency. There is going to be connections, linkages between your protection layers, between your causes and your protection layers, between your SIS and those protection layers and causes. And it doesn't say that you have to get rid of them. It just says that you need to think about it.

So think about the fact that the same technician that's calibrating your basic process control instruments is also calibrating your two out of three voting transmitters for your SIS. They're probably also calibrating all three of those transmitters. And all of those, that's a dependency. If that person is not doing the wrong thing or not doing the right thing, they're going to do it across the board, not just on one device that you're looking at. So you need to consider all aspects of the independence and all aspects of the dependency when you're designing the SIS.

And furthermore, this clause really makes it clear that you need to consider both the dependency and independence between the SIS and the basic process control system, which is going to be the lion's share of your initiating events. And it's also going to be a very large part of a lot of independent protection layers. And you also need to consider the interdependence, the independence and the dependency between the SIS and other protection layers, even if they're not in the basic process control system.

And then also consider, you know, the unsaid statement in 11.2.8 is that you need to consider commonality between initiating events and the SIS where those initiating events don't originate in the basic process control system.

So I've talked about this for going on eight minutes now already. This one clause, what does it really mean? What is it telling you to do? What is my takeaway? What action do I take from here? If I was doing a functional safety assessment, how would I verify that this requirement has actually been met? And ultimately, there is a requirement that your workflows, your design processes, your process hazards analysis processes are all going to understand that there is dependency. Even when we call things independent protection layers.

And we need to make sure that our design of our safety instrumented systems is going to pick those things up, is going to correctly address them, is going to correctly understand them.

So, 11.2.9 is the starting point where everything is laid out. And, you know, we threw down and we said, yeah, independence is a goal. It is an assumption of layer protection analysis, but it is not real. And there is going to be independence. There is going to be dependency. We need to think about to what extent there is dependency and does that extent of dependency change our design and change our calculations. Okay, so that's Clause 11.2.9.

## Clause 11.2.10: Device Sharing Prohibition and Exceptions

Now we're going to dig into Clause 11.2.10. And Clause 11.2.10 is probably one of the most talked about, one of the most important standards in the entire document. It is the source and the answer to maybe even the lion's share of discussions of independent protection layer designs in relation to the safety instrumented system. So, let's go ahead and do a deep dive into Clause 11.2.10, beginning with a discussion of what does the clause actually say? And then, once we know what the clause actually says, does that change how we're going to be doing our design, what our design practices are?

And, you know, more importantly even, what are the risk analysis practices that are part of the design process?

So, let's start with Clause 11.2.10, which says, a device used by the BPCS shall not be used by the SIS, period. Period! Oh, wait a minute. That's not exactly true. There's no period in the clause. There's a comma. Or is there even a comma? Well, actually, it doesn't stop there. So, right out of the gate, you know that there is no strict, hard and fast requirement that says that if a device is used by the basic process control system, it can't be used by the SIS. Right out of the gate, we're already doing some sharing because we didn't put the period after SIS.

So, let me read up to the comma, or I'm not even going to read up to the comma because there's, like, every word in this clause is loaded with meaning. So, let's start over. A device used by the BPCS shall not be used by the SIS where a failure of that device may result in both a demand on the SIF and a dangerous failure of the SIF.

Okay, so there's our… Oh, no, no. There's just a comma after SIF there. There's not a period. So, we're going to get a little bit deeper into this. But, so, with the second part of that first clause, what did we just add into the discussion that wasn't in the discussion originally? And that extra bit that you need to think about is how is that shared component used? Is that shared component part of a safety instrumented function? Okay, if it's not part of a safety instrumented function, we've already got other clauses to address that.

So, what we're really worried about is shared components that are actually part of a SIF. And then, furthermore, even if it is part of a SIF, now we need to think about what is actually the scenario that we're using that shared component in.

Or, if you think about it, I'm going to kind of go make things a little bit easy. Think about the LOPA scenario. So, a LOPA scenario has a cause. It has independent protection layers. Maybe enabling events, maybe conditional modifiers, all that other good stuff. But, when you look at the core of the LOPA scenario, you're going to have your initiating event, and you're going to have your independent protection layers.

So, in this first clause of the sentence in 11.2.10, it's basically stating that we're looking at sharing between, sharing a component in the BPCS and the SIS when that shared component shows up in multiple places in the same LOPA scenario. And, kind of, you know, nailing it down even more, that shared component shows up as both the initiating event and as part of a protection layer.

So, what do I mean by that? Well, let me go back and read the clause again to give you a little bit more background here. So, what we're saying is what we're worried about is failure where, a failure of a single device, a failure of a single component, can place a demand on the SIF. So, that means that that component has to be part of the initiating event for its failure to place a demand on the SIF. Okay? It's part of the cause.

Now, it also, that same exact component, has to prevent you from getting to a safe state, or in the words of the standard, has to cause a dangerous failure of the SIF. So, I'm using a component as part of the control loop that is the initiating event in the BPCS, and I'm using that same exact component as part of a safety instrumented function that's supposed to bring me back to a safe state in the same LOPA scenario. That's key. It's got to be one LOPA scenario that has that component in the initiating event and as a protection layer as part of the SIF. That's what we're worried about.

## Fired Heater Flow Transmitter Sharing Example

So, let me give you a couple of specific scenarios of what I'm talking about here. So, the first one would be a scenario, think about that fired heater again. Okay? So, in the fired heater scenario, there's that low pass flow shutdown. So, if the flow into my fired heater goes low, I'm going to lose flow through the tubes. The tubes can overheat. They melt. They pop open. They spill flammable material in the firebox, etc., etc. So, in order to prevent that tube rupture due to overheat scenario, let's say that I am going to put in a low flow shutdown that's going to stop firing the heater.

But let's say I was cheap and I wanted to save a buck. I'm a plant manager and I said, hey, I've already got a flow transmitter on that line. So, why don't you just use that flow transmitter that you're using for the control loop for the shutdown loop? Okay. Well, now we have just violated that clause. Because let's say that the flow measurement fails high. It fails off-scale high for some reason. And let's just assume we don't have diagnostics. So, the flow measurement fails above the set point of the controller. What does the controller do?

In response, the controller is going to try to reduce the flow by ramping the flow down. It's going to take that control valve and move it toward the control to the closed position in order to get the flow back down to a safe state. Well, the flow measurement has failed. So, it's going to ramp that valve all the way closed and that transmitter is still going to be showing a high flow. Well, that should be just fine because, you know, if the… I have a low flow shutdown. For this scenario. So, the shutdown will bring me to a safe state.

Well, not if it's the same failed transmitter that got you into this position in the first place.

So, that failure of the transmitter high created the low flow situation and also prevented the low flow shutdown from working. Ow! Okay. So, now I understand that sharing is not completely forbidden. It's this one scenario where a single component failure happens that creates the hazardous situation and simultaneously prevents my shutdown system from being able to do anything about the hazardous situation. That's what I'm truly worried about and that's what I want to forbid. Forbid. That's a strong word. You know what?

The standard didn't forbid it because there's a comma after SIF not a period.

## Analysis Requirement for Shared Components

So, let's start again and try this one more time. This time, I promise, I'm going to get all the way through the entire clause. A device used by the BPCS shall not be used by the SIS where a failure of that device may result in both a demand on the SIF and a dangerous failure of the SIF unless an analysis has been carried out to confirm that the overall risk is acceptable. So, you know, if I can kind of paraphrase ISA's statement here or IEC's statement here, don't share between the BPCS and the SIS unless you want to. Hmm. Okay. No, it's not that loose.

And once we get into the notes, we're going to see that it's a lot more quantitative and analytical than you would think to make this justification, this analysis. So, what did we add? Well, it turns out that even if a single component failure can create an unsafe state and prevent you, your safety instrumented system from working, that can still be okay if an analysis has been performed to confirm that the overall risk is acceptable.

So, I guess the big question then is what the heck is this analysis that I'm required to do to confirm that the overall risk is acceptable when I share a component? Um, well, hmm, what's the easy way to do this? Well, me and Bubba and Jethro, we're going to get together in the lunchroom or we're just going to get together in the break room, we're going to pour ourselves a cup of that extra thick chewy coffee and we're going to sit down and say, okay, we're going to share the flow transmitter between the SIS and the BPCS because I think that's okay. Bubba, what do you think?

Well, I think that's okay too. Seems pretty reasonable. We don't see a whole lot of failures. Jethro, what do you think? Well, I think that's probably going to be pretty okay as long as we make sure that that flow transmitter is really, really good. We should be just fine. All right. Well, we did an analysis and we confirmed that the overall risk is acceptable. Was that good?

Well, no. No. No, no, no, no, no, no, no, no, no, no, no, no, number one, anytime you're deliberately violating, I don't want to say deliberately violating your standard because it gives you an out right there, but if the standard is requiring you to do an analysis of something, you should probably document it.

So if I got back to my office and I sent a text message to Jethro and Bubba saying, hey, we agreed that sharing that flow transmitter between the BPC and the SIS is okay, right? And then I took a screenshot of that. Now we're good, right? Yeah, no. No. turns out that that analysis is going to necessarily be quantitative. So we're going to actually have to run some numbers. How do I know that we're going to need to run some numbers? Well, it's not specifically in the normative part of the statement. It's in the informative note afterward.

And the informative note afterward is a lot more complex, contains a lot more words, contains a lot more discussion than the actual clause. So let's dig into the note that talks about the details of how we're going to do this justification that using that flow measurement for both the BPCS and the SIS is going to be okay.

## Note Text: New Risk and Quantitative Analysis

All right. The note says, first sentence of the note, when a part of the SIS is also used for control purposes and a dangerous failure of the common equipment would cause a demand on the function performed by the SIS, then a new risk is introduced. All right.

So the first sentence in the note is teeing up that when we share a component between the initiating event and the SIS IPL, we created a brand new type of hazard. And that brand new type of hazard is something that your traditional layer of protection analysis is not going to be able to understand, it's not going to be able to handle, so we're going to need to come up with a new approach for how to actually assess the risk of this situation.

because at the end of the day, that flow transmitter is a single point of failure. It's a single point of failure that's going to cause the consequence by itself. That one failure by itself of that flow transmitter causes the consequence. Lopa just got thrown out the window. It's useless to analysis this case or to analyze this case. We need to do something different. But, before I explain what that is, let's dig into this note a little bit more reading the second statement, or the second sentence, which I don't think I'm actually going to be able to get all the way through.

It's a long sentence. Let's read the first clause of the second sentence, which says, the additional risk is dependent on the dangerous failure rate of the shared device. Okay, I didn't even finish. the additional risk is dependent on the dangerous failure rate of the shared device.

So, now, we specifically need to look at the dangerous failure rate of the shared device. The dangerous failure rate of the shared device is a very important consideration in this case. And, when I say dangerous failure rate, now I'm looking at doing things quantitatively. This is not a gut feel in the break room kind of analysis. This is a quantitative analysis that necessarily requires you to look at the frequency at which that device is going to fail. Well, why am I worried about the frequency at which the device is going to fail? Okay, let me continue.

Okay, the additional risk is dependent on the dangerous failure rate of the shared device because if the shared device fails, a demand will be created immediately to which the SIS may not be capable of responding. So, now, we're back to the same consequence or the same concept that we've been talking about for a little while now, which is the concept that I have a single point of failure that's going to result in the consequence because that single component was my cause and it also caused my protection layer to fail.

So, if a cause occurs and that same situation caused the protection layer to fail, single point of failure causes the consequence.

So, what happens when a failure immediately causes the consequence? Well, my protection layer, all that PFD math with my protection layer is pretty much useless. I have now gone into the continuous mode of operation in terms of mathematics. PFD of the protection layer doesn't matter anymore. The only thing that matters is the failure rate of the cause or putting a little bit more of a fine point on it, it's the failure rate of that component that is only a portion of the cause.

But failure rate of that component is going to cause my SIS to fail which means when that failure occurs by itself I have a consequence. consequence. So now I need to make sure that the frequency at which that failure occurs is tolerable.

Okay, so let's go on to the next sentence which says for that reason additional analysis can be necessary in these cases to ensure that the dangerous failure rates of the shared devices are sufficiently low. Boom! So now me and Bubba and Jethro talking in the break room is not the analysis we're talking about. The analysis that we're talking about is looking at the frequency of the shared components failure and making sure that that frequency is tolerably low. Well, what does it mean for a frequency to be tolerably low? Okay, I'll get to that in just a second.

Let me give you the last sentence in the note which is kind of a throw away which basically says sensors and valves are examples where sharing of equipment with the BPCS is often considered. Okay, throw away or don't throw away that last sentence but yeah it's just kind of saying yeah this is typically what we're going to try to do.

## Tolerability Criteria and TMEL Application

Okay, let me step back. Step back to that sentence in the note where it says that the dangerous value rate of the shared devices are sufficiently low. So how do we know if a failure rate is sufficiently low? Well, seems to me that we should be able to get out of our risk tolerance criteria some sort of assessment or some sort of judgment as to whether or not the risk is tolerably low, don't you think? Hmm, as a matter of fact isn't there a specific name? excuse me, for the frequency at which something is tolerably low.

I believe that's the target maximum event likelihood. Or some of you call it the target mitigated event likelihood. Or the target maximum frequency. Or the target risk frequency.

It goes by a lot of names, T-M-E-L being the most popular one, but that is the frequency not of a failure but the frequency at which we are willing to tolerate a consequence. So, we have in our corporate risk criteria numbers that tell us how frequently we'd be willing to tolerate a consequence.

Well, if we're sharing a component between the initiating event and a protection layer and failure of that component causes the initiating event and prevents the protection layer from working, then the failure of that component will cause the consequence associated with that scenario. And we know how frequently we're willing to tolerate that consequence. So it just stands to reason doesn't it that the tolerable failure rate of that frequency is roughly the target maximum event likelihood of the consequence that that scenario is intended to protect against or of that scenario.

Now you're generally going to want to back off a little bit because okay there are things that can cause this scenario to occur other than failure that shared component but ultimately we're in this kind of high demand mode continuous mode of operation with that shared component and we need to make sure that its failure is going to be at a lower frequency with some comfort margin of error for the other scenarios that are possible that will make sure that I'm not going to violate that target maximum event likelihood.

So let's go back to the low pass flow scenario where we're sharing the flow transmitter. We just basically said that we can share that flow transmitter as long as we do an analysis to show that the risk is acceptable. Okay so let's say that the consequence of a tube rupture is a serious injury. So we're going to assume that we're going to spill out a bunch of hydrocarbon into the fire box it's going to catch on fire. That's going to spill to the ground. I'm going to get a pool fire. And you know if you're an operator in the area you're probably going to suffer third degree burns

> *

*

all we have to do to verify that this scenario is okay is you know do my quick and dirty risk assessment to show that the failure frequency of the transmitter is going to be less than once every thousand years. So let's go into our failure rate database and prove that this flow transmitter is going to fail less than once every thousand years. Wait a minute. For a single valve and a single transmitter if the consequence is a serious injury even let alone a fatality there is no single component in the history of mankind that has a failure rate of less than a one in a thousand chance per year.

Forget about it. I mean you're not getting there. So yeah. So I mean if I go all the way back to where I started here the standard giveth and then really really really taketh away. How? It says I'm allowed to do the sharing but in reality for a single component I can't share unless the TMEL is like a one in ten chance per year which means you know if the initiating event occurs and the protection layer fails I stubbed my toe I don't even know if I want to stub my toe once every ten years so

## Redundant Subsystems and Justifying Shared Components

why is this clause here? Well it turns out that you share between the BPCS and SIS a lot more than you would think and there are even some situations where the sharing between the SIS and the BPCS is a standard approach that's used by a lot of operating companies for all situations where the potential to share happens. Huh. Well Ed you're confusing me. You just told me that there's no situation where I'll be able to do this sharing but then you're telling me that it happens all the time.

Well it does if you think about a measurement not as a single device but as a subsystem that has advanced diagnostics and redundancy instead of being a single component failure. So now what if instead of a single flow measurement I was using a two out of three voting system with comparison diagnostics between the transmitters and advanced diagnostics built into the transmitters themselves? Now is it possible for me to justify that a dangerous undetected failure is going to occur at less than a 1 in 1,000 per year rate? Yeah you probably can.

Go ahead and use your ISA EC50 training course equations. We also have equations in the Kenexis Process Safety Training Center training course on safety instrumented system SIL verification calculations or if you want to go all guns blazing you can go ahead and run this in an Arbor fault tree analysis study to show that the failure rate of that two out of three voting system is going to be lower than 1 in 1,000 so now

I can quantitatively prove that it's okay for me to use that two out of three vote as my sensor. So I'm going to use a middle of three.

So I'm going to wire my three transmitters into the SIS logic solver do a middle of three and then output that value back to the basic process control system and use it as my control loop and you're going to show easily that the frequency of failure considering the two out of three voting transmitters and also hopefully your SIL three certified logic solver is going to be less than one in one thousand probably going to be less than one in ten thousand might be approaching one in one hundred thousand if you've got really good diagnostics and really good equipment.

And then that same two out of three is being used as your shutdown signal. So that's kind of you know by a lot of people that's considered a best practice because we're going to reduce the frequency of failure of the basic process control system but you know we're probably not going to try to take credit for it. We're still going to say our BPCS is a one in ten chance of failure but we've also justified the sharing of the systems.

So that's I mean a very very long discussion of why the standard is written the way that it is because it tells you that you don't want to share unless you really really think it through. We started in clause 11.2.9. You need to think about all the independence and the dependency and really really think it through. We want to make things independent to the greatest degree possible if we can if it's prudent.

But at the end of the day there are situations where there's a lot of serious additional benefit that's going to be derived by sharing components between the BPCS and the SIS taking advantage of those advanced transmitters the advanced redundancy the advanced diagnostics to improve your basic process control system. But you can't just do it without thinking about it. You can't do it based on gut feel. A conversation around the coffee pot with your buddies is not the analysis that we're looking for.

We're looking for a serious quantitative analysis that is going to be looking at the frequency at which these failures occur. So that's the type of analysis that we need for clause 11.2.10. But of course if you don't share any hardware that makes that justification of independence for your LOPA a lot easier. Because if you don't have that independence now we're talking a little bit more sophisticated of an assessment process that might require you to delve into the focused QRA which we here at Kenexis are the unparalleled experts in the focused QRA.

So if your protection layers are not independent and you have some sharing you're going to want to do a deeper dive into those shared components using a tool like Arbor from Kenexis in the Kenexis integrated safety suite that will allow you to do a sophisticated fault tree analysis to understand the dependencies and make sure that the sharing is still going to allow you to achieve your tolerable risk levels so definitely take a look at the fault tree analysis training that we have in the Kenexis process safety training center we actually also have a webinar.

So go to the website and look for webinars on shared components and justification of shared components using focused QRA and fault tree analysis. I know that I spent a couple hours talking about that on a podcast and it's recorded out there available on our YouTube channel and our commercial website. And it's also available in the process safety training center.

## Episode Wrap-Up and Next Episode Preview

All right we were able to power through two clauses. In the next episode we're probably gonna do a little bit more but then again we might not because clause 11.211 is another big dog where you know what I'm probably just gonna do that one clause next week because it talks about energize to trip versus de-energize to trip and I'll talk about well does that apply to pneumatics? Does that apply to hydraulics? I would argue that it does but you could very easily make an argument that it doesn't but you know from for prudent sake please apply those techniques and concepts.

And then also if you're going to do energize to trip are you allowed to? Is it forbidden? Do we need to do extra stuff if we do energize trip all that coming up next week. Talk to you then.

## Kenexis Vertigo Software Advertisement

Now that you've heard some insights on technical safety functional safety and the IEC 61511 standard let me tell you a little bit more about how to easily and effectively implement the safety 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.