The latest episode (S1E2) of the Kenexis Functional Safety Podcast is now available on Spotify

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E2 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 2: IEC 61511, Clause 1g through 1x (Scope, continued)

—

## Introduction and Episode Overview

Wow, second episode and we're only halfway through the scope. 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.

## Clause 1G: Functional and Integrity Requirements

All right, let's pick up where we left off last time. We were looking at Clause 1 of the IEC 61511 standard, which is the scope, and we are on item G. So Clause 1 has an alphabet all the way up to X of attributes of the scope of the standard. And we'll pick it up on G, which says that this standard, in particular IEC 61511-1, results in the identification of functional requirements and safety integrity requirements for the SIF, taking into account the risk reduction achieved by other methods.

Okay, so Clause G goes in a couple directions. Number one is the difference between integrity requirements and functional requirements. Functional requirements are kind of falling back on that prescriptive approach. So what is the safety instrumented system supposed to do? Functional requirements have been around for a long time, and that's a general description of the hardware, what it's supposed to do.

But what's a little bit different here is the safety integrity requirements. So not only is this standard going to require us to explain what the safety instrumented system is supposed to do, we're also going to explain how well it is supposed to do those things. Those are the integrity requirements. And kind of making a long story short, that's the SIL target, the performance target. But it's more than just that. And as we go through the rest of the standard, we'll delve into that in a little bit more detail.

So we're requiring functional requirements, what does it do, and integrity requirements, how well does it do it.

Now, this clause also says that we're going to define that information, we're going to identify those requirements, taking into account the risk reduction achieved by other methods.

So in the game of process safety, we have hazards that require safeguarding, and we could do that safeguarding in a wide variety of different ways. And right out of the gate, in the scope of the standard, it says that we are going to not put our safety instrumented systems in a vacuum, but we're going to look at how safety instrumented systems fit into the overall scope or the overall landscape of providing risk reduction via different means of engineered controls, administrative controls, and so on.

## Clause 1H: Lifecycle and System Architecture

All right. Clause 1H, the IEC 61511 standard, specifies lifecycle requirements for system architecture and hardware configuration, application programming, and systems integration.

So clause 1H is another expansion on the fact that we're looking at more than just the details of how we're going to implement the hardware. So there's more to design than just implementing hardware. So system architecture is going to be the voting arrangement. What type of redundancy do you have? What kind of fault tolerance do you have? What types of failures are you going to be tolerant to? Hardware configuration is also part of that system architecture.

But beyond the hardware, we're also in clause 12 going to talk about application programming, and we're going to set down some rules for how you need to program and how you need to test your programming, how you need to document your programming.

And then finally, it talks about systems integration. So your safety instrumented system is going to be composed of numerous different pieces. There's field hardware. There are logic solvers. Those logic solvers are going to communicate to other things. So integrating all those pieces together is going to be included in the IEC 61511 standard.

## Clause 1I: Application Programming for Users

Clause 1I states that IEC 61511 specifies requirements for application programming for users and integrators of SIS.

So in the prior clause, we already mentioned that application programming is something that the standard is going to cover. But in clause I, it says that the application programming is limited to users of safety instrumented systems and integrators of safety instrumented systems.

Here again, we're separating the 1508 vendor standard from the 1511 user standard, process industry application user standard.

The rules for programming in IEC 61511 are limited. It's just a few pages as opposed to hundreds, dozens, hundreds of pages contained in the IEC 61508 part 3 standard.

And we want to, you know, again, make it very clear that the limited set of rules for programming that is contained in IEC 61511 is based on the fact that you're going to be using limited variability languages that basically provide a whole bunch of guardrails preventing you from getting yourself in trouble when you're programming your safety PLC as opposed to the more general purpose languages that you can get yourself into more trouble in. And for those, you need more rules. And those rules are contained in IEC 61508. All right.

## Clauses 1J and 1K: Safety vs Asset Protection

Clause 1J says that IEC 61511 applies when functional safety is achieved using one or more SIFs, safety instrumented functions, for the protection of personnel, protection of the general public, or protection of the environment.

So Clause 1J, again, is trying to lay out when, who should be using the standard, and when they should be using it. And basically stating that this standard is applicable to SIFs, safety instrumented functions. And furthermore, safety instrumented functions that are protecting personnel, people, or the environment.

What this specifically skips away from is talking about money. So if you have protective functions that are only there to protect your equipment, to prevent you from losing money, then you can use this standard, obviously, for that design process. But that's not the purpose of why this standard was written. This standard was really written to protect things like people and the environment.

All right.

Clause 1K. IEC 61511 may be applied in non-safety applications, for example, asset protection. Whoa. I think I just said that.

So yet Clause J and K work together with J saying, specifically, we're here for safety of people, safety of the environment. And then K coming back and saying, well, you can use this approach. The approach is contained in this standard in non-safety applications like asset protection, like prevention of business interruption. But that is not ultimately why this standard was written. This standard was written for safety. Okay. Clause 1K states that IEC 61511 may be applied in non-safety applications. Wait. Wait. I just said that. All right. Let's go back.

## Clause 1L: SIF as Part of Overall Safety

And we're going to say, look at Clause 1L. So Clause 1L states that IEC 61511 defines requirements for implementing SIFs as part of an overall arrangement for achieving functional safety. All right. Here in Clause 1L, what we're driving at, what we're really trying to focus on is that the safety instrument and function does not stand alone. The safety instrument and function is not the only means of protecting your plant or preventing a loss of containment.

The safety instrument and function is just one piece in the puzzle. So there are other things that are going to allow us to achieve functional safety, including non-SIS instrumented protective layers. There are conditional modifiers. There are administrative controls. There are designs for inherent safety. There are a lot of aspects to achieving functional safety and safety instrumented functions are just a part of that.

And that'll get driven home when we get to Clause 8 and Clause 9, which talk about risk analysis, hazard analysis, and how safety instrumented functions fit into that process.

## Clause 1M: SIS Safety Lifecycle Overview

Okay. Okay. The next clause, Clause 1M, IEC 61511 uses a SIS safety life cycle, which is going to be shown in Figure 7 of the standard.

So obviously, I can't show that to you on an audio podcast. But if you're sitting at your desk, you can go ahead and grab the standard and look at it. Much, much more on the safety life cycle coming up when we get into Clause 6. So again, uses an SIS safety life cycle and defines a list of activities which are necessary to determine the functional requirements and the safety integrity requirements for the SIS.

So one of the key parts of the IEC 61511 standard is the safety life cycle. The safety life cycle is that flow chart, that list of activities that need to occur, what the inputs to that activity are, what the outputs to that activity are.

We wanted to make sure when we wrote the standard that we provided a comprehensive cradle-to-grave discussion of designing, implementing, maintaining, and managing change of the safety instrumented system and not a narrow discussion of the detailed design of the hardware. All that is fleshed out in the safety life cycle, which we will get into in Clause 6 in detail.

## Clause 1N: Hazard and Risk Analysis Requirement

The next Clause 1N. IEC 61511 specifies that an H&RA, or a Hazard and Risk Analysis, is to be carried out to define the safety functional requirements and safety integrity levels of each SIF.

Okay, so there we have the clause that is leading us down the road of this being a performance-based standard instead of a prescriptive hardware discussion. It states that you're going to analyze the risk of your process, and that risk analysis is going to yield the design target or the safety integrity level of each safety instrumented function.

So we begin by analyzing risk, looking at the gap between the estimated risk and the tolerable risk, and making sure that we can close the gap between those two figures using the safety instrumented function. And the amount of risk reduction that's required to close that gap is going to yield a SIL or a performance target for our safety instrumented function.

Okay, there is a note, note 2, under Clause 1N that says, note 2, figure 9 presents an overview of risk reduction means. Risk reduction, we will get into in a lot more detail in Clause 8, which is Hazard and Risk Analysis, and Clause 9, which is Allocation of Risk Reduction to Different Safety Functions. So a lot more on that coming up.

## Clause 1O: SIL Targets and Operating Modes

Clause 1.0. IEC 61511 establishes numerical targets for average probability of failure on demand in demand mode and average frequency of dangerous failures in demand mode or continuous mode for each SIL.

So what we're saying in Clause 1.0 is that this standard is going to provide the mechanism to establish a numerical target for your safety instrumented functions. Then it kind of muddies things up if you're not familiar with the standard by talking about, well, that performance target might be a probability or that performance target might be a frequency. depending on the mode of operation. So there's going to be a lot more discussion of the mode of operation coming up later in this podcast, probably in Clause 3 when we start going through the definitions of the modes.

But kind of as a precursor to that, safety instrumented functions can operate in two or three modes of operation.

So there's demand mode, which is subdivided into low demand mode and high demand mode. I know, it's a distinction without a difference, which I'll explain a little bit later. Or continuous mode.

So in a demand mode, basically the safety instrumented function is sitting in the background doing nothing, waiting to respond to a challenge. As opposed to continuous mode, where continuous mode, the safety instrumented function is actually a safety critical control loop, where when that control loop fails, you immediately go into the dangerous state or the hazardous condition is generated because that control loop failed.

Now, mathematically speaking, you need to treat these things differently because when you're in a continuous mode, probability doesn't matter. As soon as the failure occurs, you're going to have a consequence. So I'm concerned with how often the failures happen. Whereas when you're only challenging the safety instrumented function sporadically in time, in the demand mode, that's where you can consider the probability that it's going to work when it's challenged.

So 1.0 kind of sets the stage for the fact that we're going to need to sometimes consider probability, sometimes consider frequency, depending on how the function is operated. And we'll talk about that more when we get into the definitions of high demand mode, low demand mode, and continuous mode when we get into clause 3, which has all the definitions.

## Clauses 1P and 1Q: Hardware Fault Tolerance Backstops

All right. Clause 1.p. IEC 61511 specifies minimum requirements for hardware fault tolerance.

Ooh, this is where we deviate from everything that I just said about this being a performance-based standard. Well, it is a performance-based standard, but it is kind of guard railed and backstopped by some prescriptive requirements.

So kind of looking at the big picture, the IEC 61511 standard says you need to do a risk analysis to figure out how good your safety system needs to be with a numerical target and then verify that your design achieves that numerical target. Okay. Well, that's a little bit more complicated than that because we're going to also add some guard rails in because the standards committee members have decided that you might not do your math very well.

You might be using data that's suspicious or just flat out wrong. So we're going to throw in some guard rails to make your design safer even if you make mistakes doing that quantitative analysis. That's what hardware fault tolerance is. So hardware fault tolerance is the ability of your safety instrumented function to perform, to successfully perform its action in the presence of failures.

So how can a failed device still work? And the answer is, well, you use a system of redundant devices to perform that action. So if I have two switches in a de-energized to trip circuit that are wired in series, if one of those switches is welded into the closed position and it won't open, that's a failure. That's a dangerous failure. But if you have a second switch in series and you open that switch, you're still going to be able to achieve your function of de-energizing your circuit.

So that situation that I just described kind of leading into the future is something called one out of two voting. And it has one degree of hardware fault tolerance to a dangerous failure.

So hardware fault tolerance is kind of prescriptive backstop or a guardrail that we're going to apply to the designs regardless of what your quantitative calculations say. And again, that's just the standards committee being extra cautious and making sure that your designs are going to be good, even if you're not the best with performing your math. Okay.

Next clause is 1Q. And that is IEC 61511 specifies measures and techniques required for achieving the specified SIL. Okay.

So Q kind of follows P. P said, well, you know what? We're going to provide some backstops and some guardrails to make sure that your design is good, even if you flub up your math.

Well, 1Q continues that. And there are going to be measures and techniques in my personal favorite clause, which is clause 11, which is the detailed design and the detailed design primarily focused on the hardware. We're going to talk about what you need to think about for manual resets, how you're going to perform bypasses. And these are kind of, again, prescriptive recommendations, prescriptive requirements for how you should be designing the system that go beyond just looking at the numbers.

So I say that the IEC 61511 is a performance-based standard, and it is, but in clause 11, we're going to throw a whole bunch of additional requirements at you that are truly prescriptive, that kind of limit your flexibility to make sure that you don't go completely in the wrong direction when you're designing your safety instrumented function. So much more on that when we get into clause 11.

## Clauses 1R and 1S: SIL 4 Max and SIL 1 Min

Okay, clause 1R. IEC 61511 defines a maximum level of functional safety performance, SIL 4, which can be achieved for a SIF implemented according to IEC 61511 Part 1.

Okay, so this is kind of the first mention of the numbers on the SIL targets. So the best way to think of SILs is that they're orders of magnitude of risk reduction. So a SIL 1 is going to provide you with one order of magnitude of risk reduction. SIL 2, two orders of magnitude and so on. And the orders of magnitude of risk reduction, you're kind of looking at the exponent of the probability of failure on demand. So if your probability of failure on demand is 10 to the minus 1, then you're achieving SIL 1.

Now, SIL 4 is an extremely high level of performance. I have been doing SIS design for my entire career of, we're going on 30 years. And I have only been called on to design a SIL 4 safety function one time. So in 30 years, as an engineer who is specifically focused on designing safety instrumented systems, I've run into a SIL 4 system once. And even then, we didn't design a SIL 4 system. We designed two SIL 2 systems that were independent of each other.

One was electronic logic solver based, and one was kind of a hard piped pneumatic system that were as independent of each other as entirely possible. Because as you will see when you start running calculations and start looking into the details, SIL 4 systems are effectively impossible to design.

A lot more on this when we get into Clause 9, which is kind of the allocation of risk reduction requirements, which there are many requirements that warn you off of trying to implement a SIL 4 safety instrumented system because it is so difficult to achieve the design, let alone maintain that level of performance over the life cycle of the function.

But that is defined in the standard. That is the highest level that's defined in the standard.

Okay, moving on to Clause 1S. IEC 61511 defines a minimum level of functional safety performance, which is SIL 1, below which the IEC 61511 standard does not apply.

So there is SIL 1 is the probability of failure on demand of 0.1 to 0.01. Technically, the borderline, a risk reduction factor of 10, a PFD of 0.1, that border actually sits on the non-SIS or the SIL 0. So a functionality that isn't required to provide even one order of magnitude of risk reduction kind of falls out of the scope of this standard. You have the flexibility to basically implement it how you want.

Now, I will be giving you a lot of guidance. And my guidance to you is that if you have a safety instrumented function, or if you have a function that needs to provide risk reduction, even if it's a risk reduction factor of 2 or 4 or 6, I would still define it as a SIL 1 safety instrumented function and design it in accordance with that standard, as opposed to trying to neglect it and categorize it as something else.

The effort of trying to neglect it or categorize it as something else is generally more trouble and more costly than just putting it into the safety instrumented system and designing it and testing it as SIL 1.

But basically what this clause statement is telling you is that if your hazard and risk analysis says a function has a performance level below SIL 1, then the rules of the standard are not applicable. You do not need to apply them.

## Clause 1T: SIL Is Application Specific

Okay, Clause 1-T. IEC 61511 provides a framework for establishing the SIL, but does not specify the SIL required for specific applications. This information, the SIL required for specific applications, should be established based on knowledge of the particular application and on the overall targeted risk reduction.

So, IEC 61511 provides a framework for determining what the SIL target is. It provides a framework for designing safety instrumented functions that are capable of achieving that SIL target. But it doesn't tell you what SIL targets you're supposed to use.

That's up to you. That is user-specific. That is application-specific. That is installation-specific. You can't get away from the work of having to make the decision of what safety integrity level is appropriate for your specific piece of equipment where it is specifically installed.

So, the idea that a fired heater… So, if you look at a fired heater, there's going to be a safety function that says, if the fuel gas pressure goes low, close the fuel gas valves because you're going to get a flame out. That's going to cause an unburned gas cloud to be developed. It might find a source of ignition which could explode. And so on.

Now, you can't just say, oh, that's SIL 2. Because it depends on how big the gas valves are. What the probability of ignition is. Where is the item located? Is it a boiler in the basement of an elementary school? Or is it on a remote platform that is unoccupied for 364 days out of the year? There are a lot of things that impact the risk.

So, we can't say that a low fuel gas pressure trip on a heater is always SIL 2. It's not. It's a function of the risk. That's why we have a performance-based standard. So, we can't tell you what the SIL is.

You need to make that determination. The best that we can do is maybe provide you a template of things that you should consider while you're making that decision. But it is definitely location, application, and function specific. You have to do the work to select the SIL target. Okay.

## Clause 1U: Full Loop Sensor to Final Element

Clause 1U. IEC 61511 specifies requirements for all parts of the SIS, from sensor to the final element.

All right.

This is really interesting because, well, I go way back. So, in the mid-90s, all of the discussion related to safety instrumented systems was that logic box.

That PLC that sat in the middle, my goodness, is it triple modular redundant? Is it 1 out of 2? Is it 1 out of 2D? What does 1 out of 2D mean? What level of diagnostics do you have? Are diagnostics better than redundancy? So, there was a lot of discussion because a lot of people were making very high-dollar decisions about what logic solver platforms that they were going to implement.

But as soon as you start looking at your calculations, you see what a trivial argument that you're having. So, whether you're looking at a 1 out of 2D logic solver or a 2 out of 3 or a 2 out of 3D logic solver, and they're designed in accordance with IEC 61508, so SIL 3 certified devices, the difference between the logic solvers is vanishingly small and insignificant in terms of safety. Making decisions on PFD for a logic solver is basically crazy.

We'll kind of get into that later. There are a whole lot of things that you should think about when you're selecting what logic solver your organization is going to use. But if you have a SIL 3 certified logic solver drilling down into what PFD, the FMEDA from the certification agency yielded, you are wasting your time.

Because in reality, the probability of failure on demand does not sit in the logic solver. When you run your calculations, you're going to find that the PFD of the logic solver disappears in the insignificant digits when you add in the PFD of the sensor and the PFD of the final elements.

So, if you have an old Bordon tube type pressure switch that is your input, and you have a single valve that hasn't been stroked in 10 years that is your output, it doesn't matter that you have a SIL 3 certified logic solver. You still ain't getting anywhere near SIL 1 because of your field devices.

And the field is where most of your PFD resides, which is why the standard really focuses on the fact that we have a loop from pipe to pipe, from the process tap connections that the sensor is connected to, all the way to the valve that sits in the pipe on the other end. That entire loop is what we're looking at when we're doing our PFD calculations. And it is the scope of the standard when we're doing all of our design, all of our management of change from pipe to pipe, not just the logic solver in the middle.

## Clauses 1V and 1W: Documentation and Human Factors

Okay, item 1V. So, item 1V says, IEC 61511 defines the information that is needed during testing of the SIS safety lifecycle.

Well, it defines the information that's needed during all steps of the SIS safety lifecycle. So, as we go through the standard, there's a lot of documentation requirements.

So, you're going to document your hazard and risk analysis. You're going to document your design. You're going to document your installation, commissioning, and validation. You're going to document your test procedures. You're going to document the results of your testing on an ongoing basis. You're going to document your management of change. So, the SIS safety lifecycle is going to generate a lot of documentation.

Now, this documentation doesn't need to be on paper. As a matter of fact, we strongly recommend that you don't keep it in paper, and instead, you keep it in a relational database. And the best example of the best relational database that you can use for SIS safety lifecycle management is going to be the Vertigo tool from SIS, or from Kenexis, in combination with our OpenPHA tool.

So, between OpenPHA, which documents your HAZOP and your LOPA, clauses 8 and 9, and then the Vertigo tool, which documents your safety requirements specification, clause 10, documents your detailed design, clause 11, documents your programming requirements, clause 12, and then validation testing is something that you should keep track of using something like an open audit tool, and management of change. You can even track that using the forthcoming Intelligent MOC tool from Kenexis.

So, documentation is a big part of the IEC 61511 standard, and, well, as we go through the rest of the safety lifecycle, I'll be talking a little bit about how our tools at Kenexis, Vertigo, OpenPHA, OpenAudit, Intelligent MOC, are going to help you to keep track of all that information and documentation.

All right, clause 1W states that IEC 61511 specifies that the design of the SIS takes into account human factors.

Okay, human factors are an issue, they're a big issue. And it's something that I'm going to talk a lot about as we go through our discussion of the standard. And the reason is that human factors or human mistakes result in a lot of the inability of safety instrumented functions to be able to perform their tasks, whether those are mistakes during design, mistakes during installation, mistakes during maintenance. They can have a very big impact on your ability to achieve your functionality, your functional safety.

So, we need to take into account the human factors. But kind of setting the stage for what you're going to see in the future, we're not really keen on just throwing numbers at the situation, running human probability of failure numbers into our models and thinking we've achieved something. Oh, no.

We're going to deal with human factors in clause 5, which is management. So, we are going to rely on human administrative controls to address human failures.

So, the mechanism that we're going to use to address human factors is not so much running a calculation to say, well, people fail this often, so this is the PFD that I get. That, I will explain to you later when we get to clause 9, is actually counterproductive and it can lead you to make bad decisions.

Instead, we're going to use the tools of management. So, we're going to plan for functional safety, set up policies and procedures that we're going to follow. We are going to have competent people do the work and we're going to define what competency is and track competency in terms of qualifications, training, verification, validation and documentation of that training, all in clause 11.

We're going to use verification. So, when one person performs a task, we're going to have another person check that they did the work correctly. We're going to use validation, which is physical testing of the system after it's been completed, to make sure that what we specified is actually what the system does.

And then further to that, we're going to do functional safety assessments, which are audits. On a portion of the life cycle to make sure that we implemented things properly. We're going to use auditing during the process safety management audit. Generally, that happens once every three years, especially if you're in the United States, to audit your functional safety program. So, there are a lot of tools and techniques of checks and balances and cross-checking to make sure that mistakes don't happen.

And these management systems discussed in clause 5 are going to be the mechanism that we're going to use, as opposed to just throwing some numbers in the calculator and hoping for the best.

## Clause 1X: Roles Not Individuals

And finally, we have approached the end of clause number 1, which is going to be clause X. The last clause says that the IEC 61511 standard does not place any direct requirements on the individual operator or maintenance person.

So, what we're trying to say in clause X is we're not singling out any human being to do a task. When we assign tasks, and much more, much, much more about this when we get into clause 5 on management, we are assigning roles. We're assigning responsibilities to roles.

And multiple human beings might be assigned to fill that role at different times during the operation of the plant. But your maintenance planning shouldn't be calling out a specific person to do something. We're assigning responsibilities and we're assigning tasks to roles, to job descriptions.

And then we're going to assign people to those job descriptions for predefined periods of time. So, not placing requirements on people, placing them on the organization and roles that the organization needs to fill with people eventually.

All right.

So, now we are done with the very, very beginning, which is just defining what the scope of the standard is. In the next edition, we'll talk about clause 2.

And clause 2 is going to be some normative references. This shouldn't take us more than a couple minutes. And we will also, in the next episode, get into the beginning of clause 3, terms, definitions, and abbreviations. I will talk to you then.

## 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 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.