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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E10 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 10: IEC 61511, Clauses 3.2.77-4 (Definitions Conclusion and Conformance)

—

## Podcast Introduction and Disclaimer

One last push and we'll be able to get through the definition section. 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.

I picked back up in section 3.2.77. And hopefully today we're going to be able to go all the way through to the end of the definitions. There have been a lot of definitions, a lot of good conversation and discussion. But, wow, a lot of time spent here.

## Application Programming Lifecycle Definition 3.2.77

All right, 3.2.77 talks about the application programming lifecycle. The definition is for application programming lifecycle. Activities occurring during a period of time that starts when the application program is conceived and ends when the application program is permanently disused. Yeah, that's right. Somehow, somewhere, someway, we determined that we need an entirely separate lifecycle just for writing the software. A little bit of an overreach most of the time. It's kind of minimal in the 1511 standard as opposed to the 1508 standard where teams are dedicated to just writing software.

But, again, we have a definition. But at the end of the day, for the purposes of safety instrumented systems in the process industries, the software development is just part and parcel of the overall development of the SIS as a whole.

Okay, there are a couple notes to the entry. Note 1 says an application program lifecycle typically includes a requirements phase, development phase, test phase, implementation phase, installation phase, and modification phase. Okay, so, yes, there are multiple phases just as there are for the overall SIS safety lifecycle.

Note 2 to the entry says software, including application program, cannot be maintained. Rather, it is modified. Okay, so, yeah, a little real kind of pedantic tightening up on meanings of things. You can't maintain software. You can only modify it. All right, I don't know if anyone found any value in that, but there you go. There it is. That's what we have.

## SIS Subsystem Definition 3.2.78

Clause 3.2.78 up next is for SIS subsystem. The definition is independent part of a SIS whose disabling dangerous failure results in disabling dangerous failure of the SIS. Yes, wow, that's kind of an interesting way to describe a subsystem.

We use the term subsystem a lot, and typically what we're trying to distinguish when we're talking about the subsystem is that there's a subsystem of the sense that a hazardous condition is present. There's a subsystem that does logic, and there's a subsystem that takes action on what the logic solver determines. And we typically analyze those separately, both in terms of PFD and then also in terms of hardware fault tolerance. An independent part of the SIS is fine.

The back end of the disabling dangerous failure results in disabling dangerous failure of the SIS, I guess, is true. That's why when you're running your SIL verification calculations, you'll do probability addition because we have an OR gate. A failure of the sensor subsystem or the logic solver subsystem or the final element subsystem will cause the entire SIS to fail. But that is also true, oddly enough, for spurious trips. But anyway, the concept of SIS subsystem is something that we use quite frequently. It's an important part of our discussion of SIS.

Not a huge fan of the way that the definition is written, but it is what it is.

A couple of notes to the entry. Note 1, figure 6 illustrates SIS made out of three SIS subsystems. Yeah, that's going to be your sensor logic solver and final element. Not a whole lot of value there.

Note 2 to the entry states that from the cut set approach point of view, and then it refers you to IEC 61025, which is going to be anytime you hear cut set, that means we're talking about fault tree analysis. And the logic that fault tree analysis uses to calculate top event frequency or top event unavailability. So from the cut set point of view, a minimal cut set of SIS subsystem is also a minimal cut set of the whole SIS. Therefore, the SIS subsystems are entirely dependent on the SIS subsystems of the SIS. I.e., when a subsystem fails, the related SIS also fail.

Okay, I think that's the same thing that I just said, but I think my description was a little bit more informative and made a little more sense to the average reader of the document. But there you go, SIS subsystem. SIS subsystem. We had a note that someone had to go ahead and pull fault tree analysis into it because, you know, they wanted to make sure that you knew that they knew about fault trees. Let's move on.

## System Definition 3.2.79

6.2.79 is the definition of system. A system is a set of devices which interact according to a specification. Okay, number one, did you really need a definition for system? And number two, a set of devices. Yep, that's a system which interact according to a specification.

It's a very muddying clarification. So if you were intending to clarify the definition with that clause, I think that you failed. But, you know, well, if you use the specification to define your system, then I suppose that's true. Anyway, I don't know if I needed a definition of system in the first place. Just the knowledge of the English language is probably going to be good enough for me.

Now, we've got some very entertaining notes to the entry. Note one to the entry is that a person can be part of a system. So the lobby for trying to include human beings into your safety instrumented systems has shown up again in the definition. Or at least in the note to the definition. Note two to the entry. This definition deviates from the definition of IEC 61508 to reflect differences in process sector terminology. And I'm sure the definition in IEC 61508 is even more backward and tortured than this one. Okay, moving on.

## Systematic Capability Definition 3.2.80

The next definition is very interesting to a lot of people. It's very uninteresting to a lot of other people. And that's the concept of systematic capability. So the definition for systematic capability is in clause 3.2.80.

IEC 61508 makes a lot of definition and reference and use out of the systematic capability term. IEC 61511 does not. IEC 61511 has very, very little mention of systematic capability. And it's truly something that's more in the equipment vendor realm of concern.

All right.

So definition. What is the definition of systematic capability? Okay. It is a measure expressed on a scale of SC1 to SC4 of the confidence that the systematic safety integrity of a device meets the requirements of the specified. SIL in respect of the specified safety function. When the device is applied in accordance with the instructions specified in the device safety manual.

So ultimately, from an equipment vendor perspective and a certification agency perspective, it's a communication to you, the end user, of what the chances that the equipment vendor has generated a systematic failure that they are selling to you as part of their hardware. So kind of also in loose terms, that systematic capability sets a boundary for the safety integrity level that you're allowed to install a device into.

So if you have a logic solver that only has a systematic capability of one, SIL one is the maximum that you can use that logic solver for. And remember, systematic failures go across all kinds of failures, or shall I say, they kind of spread across the redundancy spectrum. So when you have systematic failures, redundancy doesn't help you. So adding a second SC1 logic solver in parallel didn't fix your problem. You're still stuck at SC1.

So this is something that the certified equipment vendors are going to be providing to you. And it does set a limitation on the types of applications that you can install equipment in. You're going to be limited by that systematic capability presented by the equipment vendor. And that's basically what we're going to find when we get into clause 11. There's only one clause that says what the end users in the process industry need to do it in terms of systematic capability. And it's basically a clause that says, well, if the vendor gives it to you, you might want to use it.

Now, obviously, I'm paraphrasing, but there's not a lot of stress in the 1511 standard and the process industries related to systematic capability, especially as it's concerned with prior use devices.

There are three notes to the entry. So let's go ahead and dig through those three notes. Note one to the entry is systematic capability is determined with reference to the requirements for the avoidance and control of systematic faults in IEC 650.08.2 and 3, which are the parts for hardware and software, respectively.

So yes, equipment vendors are going to determine this for the equipment that they supply.

Note two to the entry, the systematic failure mechanism depends on the nature of the device. For a device comprised solely of hardware, only hardware failure mechanisms are considered. For a device comprised of hardware and software, it is necessary to consider the interactions between hardware and software failure mechanisms. So yeah, systematic failures can occur in the hardware. They can also occur in the software. And again, this is something that the equipment vendors are going to be determining for you when they supply a piece of equipment to you.

Final note, note three for the definition of systematic capability is a systematic capability of SCN, meaning, you know, N is the number on the SC. A systematic capability of SCN for a device means that the systematic safety integrity of SCN has been met when the device is applied in accordance with the instructions specified in the device safety manual for SCN.

When we get to clause 11, we're going to talk a lot more about the safety manual and all of the constraints and requirements that it pushes on to the end user off of the equipment vendor. So that's going to be a full discussion, even though it's a short clause. We might spend an entire webinar just talking about what's in the safety manual horror stories of what people have found in their safety manuals and what you're going to need to do about it.

So note three basically says if you have a systematic capability of three, you can apply that device in a SCN 3 application. If you have a systematic capability of one, you can apply that in a SCN 1 application. But as always, you need to follow all of the rules and requirements that are in the safety manual in order for that to be true.

## Systematic Failure and Safety Integrity 3.2.81-82

Next definition is 3.2.81. It is a systematic failure. All right. Good deal. We just talked about systematic capability. We might as well talk about the type of failure that systematic capability is intended to describe for certified pieces of equipment. Okay. Okay. This is a pretty long definition and there's going to be not one, two, three, but four notes to this entry. So let's do our dig.

The definition of systematic failure is a failure related to a pre-existing fault which consistently occurs under particular conditions and which can only be eliminated by removing the fault by a modification of the design, manufacturing process, operating procedures, documentation, or other relevant factors.

So basically, this is a fault. Something is wrong with your component in the design, in the manufacturer. It's something that not only is wrong, but it's going to be wrong all the time. It's going to be wrong consistently. So if you program the device that when it gets to 20 milliamps, it bursts into flame and it does that every time you get to 20 milliamps, that's a systematic failure.

So maybe that might be because you undersized a component and it's going to burst into flames when you get to a certain level of voltage or level of current through the device.

Also, when we're talking about software, there could be a piece of software or a line in the software that every time it fires, it gives you an incorrect result. But then again, that line of code is only going to fire under certain conditions. So it's something that the system is built with and it's something that's going to consistently give you a failure when it occurs.

In order to get rid of it, you can't recalibrate the device. You can't reinstall it. It's kind of an attribute of the device. So you're going to need to modify the design, the manufacturing process. Whatever generated that fault needs to be done, redone in order to prevent it from recurring.

Now, I talked a lot about it happening at the manufacturing, but you can also generate a systematic failure by the way you installed something. If your technicians install or have an erroneous procedure by which they're installing things that's causing them to erroneously install it every time that they install it.

So systematic failure. Let's talk about the notes to that entry, all five of them.

Note one, the cause of systematic failures in the software may be known as bugs. Okay. All right. Yep. Sure. Sure is. Don't need to push on that one any further.

Note two, correct without modification would usually not eliminate the failure cause, which involves the failure under particular conditions. So maintenance, testing, calibration, we don't expect that to be able to clear a systematic failure.

Note three to the entry. A systematic failure can be reproduced by deliberately applying the same conditions, although not all reproducible failures are systematic. So when you place a device with a systematic failure into a certain set of conditions, it will fail all the time when those conditions are present.

Note four to the entry. Examples of faults leading to systematic failure include human failure or human error that originates in either the SRS, the design, the manufacturer, the installation, the operation, maintenance of the hardware, the design or implementation of the software, including the application program. So there are a lot of places you can generate a systematic failure.

Note five to the entry. Similar devices designed, installed, operated, implemented, or maintained in the same way are likely to contain the same faults. Therefore, they are subject to common cause failures when the particular conditions occur.

And as we're going to discuss, I think the big point of this is going to show up in clause 11.9 for calculations. And it's going to show up all the way through clause five because the way that the standard is written and the intention of the standards authors, particularly me, I'm a big proponent of this, is that there's very little benefit in trying to quantify systematic failures and put numbers on them. That's not going to help you to design and implement a safe system. And that's why you'll see in clause 11.9, there's a lot of discussion and focus on random failures.

And there's going to be a lot of discussion in clause five on administrative controls to reduce human failures and systematic failures.

So we're going to try to get out of systematic failures using the techniques in clause five of verification, validation, and auditing, as opposed to just pencil whipping it with some calculations and saying it looks good because I did a calculation and it said that it's good. So much more on that to come in clause five, which is actually going to be where we're going to kick off the next podcast in clause 11.9.

Okay, next definition is going to be 3.8.2 systematic safety integrity, which is kind of closely related to the clause that we just discussed, 3.2.80 systematic capability. Let's discuss. So the definition is systematic safety and part of the safety integrity of the SIS relating to systematic failures in a dangerous mode of failure.

So that's the SC number is the systematic safety integrity. It basically tells you what SIL a device is capable for based on just analyzing the systematic failures that are possible to occur in the equipment design and manufacture process.

Note one to the entry, systematic safety integrity cannot usually be quantified as distinct from hardware safety integrity. Read enforced again in clause 11.9 where we're going to tell you crunch numbers based on random hardware failures and not systematic failures.

Note two to the entry is going to point us back to 3.2.26 because we've already discussed this in the definition section. Next definition.

## Target Failure Measure and Tolerable Risk 3.2.83-85

Next definition. We're finally going to get moved away from systematic stuff and go to 3.2.83 target failure measure, which is performance required from the SIF and specified in terms of either average probability of failure to perform the SIF on demand for demand mode or of operation, or the average frequency of a dangerous failure for continuous mode of operation.

So a target failure measure is that quantitative target that the SIF is supposed to achieve. So average probability of failure on demand when you're doing demand mode. If you're not in demand mode, you're going to be looking at frequency of failure.

More on that coming up when we get into clause 9, when we're actually defining the safety integrity levels and what those numbers mean and how they've been selected.

There is a note to this entry, 3.2.84. I'm sorry. Before we get to 3.2.84, note one to 3.2.83 is the relationship between target failure measures and SIL. All are given in tables 4 and 5, which are going to reside in clause 9.

Okay, next clause 3.2.84 is tolerable risk. Tolerable risk is the level of risk which is accepted in a given context based on current values of society. We talk a lot about tolerable risk when we're picking safety integrity level targets.

After all, your safety instrumented system is intended to be designed to be able to achieve a tolerable level of risk. If you want a really, really good discussion of tolerable risk going all the way back down to its philosophical underpinnings, moving on into quantification based on benchmarking, I'm going to highly recommend to you reading my first book, which is systematic safety integrity level selection with layer of protection analysis, which is sold by ISA.

So that's going to be the best discussion that I've seen of tolerable risk up to this date until I write my next book on picking SIL targets, which is going to be included in a book I'm writing right now called Unified Hazard Assessment, which is going to cover not only LOPA, but also HAZOP, bow tie diagrams, and even kind of leads into quantitative risk analysis. But you're going to have to wait a little bit for that one.

Next definition, 3.2.85 is a triple definition. It is the definition of undetected, the definition of unrevealed, and the definition of covert. Those terms mean something that is not detected or not revealed or not overt. Wow, what horrible definitions. Something that is undetected is not detected.

Okay, let me delve into this a little bit deeper, but before I do, let me read note one to the entry.

Note one to the entry is in IEC 61511, and except when the context suggests another meaning, the term dangerous undetected failures faults is related to dangerous failures faults not detected by the diagnostics.

Okay, ultimately, a covert failure is something that hides, something that you don't know about. The failure happens, but you don't know that the failure has happened, and as a result, the only way to know that that failure has happened is to either test the device or challenge the device. Now, if you test the device, you can detect it and then repair out of it, but if you don't and you challenge it, you're going to have the hazardous event that the safety instrumented system is intended to protect against.

So for covert, undetected, unrevealed, those are failures that are going to be dangerous in nature because they prevent your safety function from doing what it's intended to do, and you don't know they're there until you perform a test.

## Validation and Verification Definitions 3.2.86-87

All right, 86 and 87, those definitions are for validation and verification. Really super important because these are two key terms.

We're going to discuss these in a lot more detail. Verification has its own clause, clause 7. Validation has its own clause, which is going to be clause 15. So we obviously are going to be discussing these terms in a lot more detail, but let's hit the definitions because that's where we're at at the moment.

3.2.86, validation. Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled. Yeah, clear as mud.

So a couple of terms here that are…

Well, actually, let me hit the note first before I clarify the definition. That's right, clarify the definition.

Note 1 to the entry in the IEC 61511 series. This means demonstrating that the SIFs and SIS after installation meet the SRS in all respects. Wow, the note is shockingly good.

Okay, so in terms of validation, looking at some of the key wording in there, it's confirmation by examination. So we're not just looking at the paperwork to make sure that the calculations are run. We're examining, we're looking at the device. We're also provisioning objective evidence that the intended use cases are fulfilled. That's kind of blurry, and the note doesn't help. But ultimately, what we're doing here is we're actually performing a physical test of the system to ensure that the system is physically doing what we intended it to. And how do we know what we intended it to do?

Well, we wrote that down in the SRS, hence the reference to the SRS in the notes.

So that validation, if I could restate it a different way, is a final physical test on the completed system to confirm that it operates as desired, as required, as intended. And the intention, of course, is going to come from the SRS. So final physical test.

Validation in the U.S., we're generally going to refer to that as the SAT, or the site acceptance test.

3.2.87 is completely different, but often confused. It is verification. What is verification?

Verification is confirmation by examination and provision of objective evidence that the requirements have been fulfilled. My goodness. Confirmation by examination and provision of objective evidence that the requirements, that the particular requirements for a specific…

Wow! I don't know how the definitions of verification and validation could be closer to each other, and how they almost provide no differentiation.

Validation says particular requirements. Verification just says requirements. And verification says fulfilled. And validation says for a specific intended user fulfilled. These definitions are horrible. They're horrible. They're almost worse than nothing. They're completely confusing. You would think verification and validation are pretty much exactly the same thing if all you did was read the definitions. But, you know, we're going to do more than that.

We're going to go beyond that. Because there's more to verification than what is in the definition. Let's go ahead and read the notes, and then I'll provide a discussion of verification that's going to be a little bit more helpful.

Luckily, the standard has an entire clause, clause 7, that talks about verification, which is going to make it much more clear than this horrible, horrible definition.

Okay.

Note 1 to the entry. In the IEC 61511 series, this is the activity of demonstrating for each phase of the relevant SIS safety lifecycle by analysis and or tests that for specific inputs, the outputs meet in all respects the objectives and requirements set for the specific phase. Okay. Note.

Phase by phase analysis of the outputs of the phase to make sure that it meets the objectives and requirements of the phase. So basically, it's something we're doing step by step throughout the safety lifecycle. Good. All right. Note 2 to the entry.

Example verification activities include, one, reviews on outputs, documents from all phases of the safety lifecycle to ensure compliance with the objectives and requirements of the phase, taking into account the specific inputs. Okay. Two, design reviews. Three, tests performed on the design product to ensure they perform according to their specification. Four, integration tests performed where different parts of a system are put together in a step-by-step manner and by the performance of environmental tests to ensure that all parts work together in the specified manner. All right.

So now the notes did clarify things.

So let me kind of combine the definition in the notes to give you a clearer understanding of verification. Verification is something that happens step by step throughout the entire safety lifecycle. So throughout the entire safety lifecycle, you're doing tasks like a SIL verification calculation. That task is going to have inputs. That task is going to have procedures and requirements by which you perform the step. And then that step is going to have an output.

So the verification is going to be done by someone other than the person who performed the task. And that verification is going to review the inputs to the task in comparison to the outputs and the requirements and procedures for performing that step in correlation to the outputs. And make sure that the outputs match what we expected based on the inputs, the requirements, and the procedures for performing the steps.

Back when I was an engineer at UOP, we would call this back checking. One person does a calc, hands it over to somebody else who back checks it to make sure that it was done correctly.

So if you want to try to make things a little bit more simple, verification is back checking of work. And validation is a final site acceptance test or a final test of the physical device. All right. Last definition.

## Watchdog Timers Definition 3.2.88

3.2.88 is watchdog, which we're going to talk a lot more about watchdog timers when we get into clause 11.5, when we're talking about safety configuration of commercial off-the-shelf PLCs.

Now, certified PLCs actually also use watchdogs, but you, the end user, don't really need to worry about that. The equipment vendor needs to worry about it. The only time that you need to worry about watchdog timers is when you are the person doing the safety configuration.

So what is a watchdog? It's a combination of diagnostics and an output device, typically a switch, for monitoring the correct operation of a programmable electronic device, PE device, and taking action upon detection of an incorrect operation.

Couple notes. Note one to the entry. The watchdog confirms that the software system is operating correctly by regularly resetting the external device, e.g. hardware electronic watchdog timer, by an output device controlled by the software.

Note two to the entry. A watchdog can be used to de-energize a group of safety outputs when dangerous failures are detected in order to achieve or maintain a safe state of the process with respect to the hazardous event. The watchdog timer is used to increase the online diagnostic coverage of the PE logic solver. See definitions 3213 and 3215.

So we will come back to this concept again and probably spend, there's probably going to be an entire webinar episode that's just dedicated to safety configuration of PE logic solvers because there is so much to doing that. There's such a large amount of detail that goes into it.

But one of the key things you need to do when you're safety configuring a PE logic solver that is not certified, so the equipment vendor didn't do it for you, is detecting one of the primary failure modes of a PE logic solver is that the logic, the program, the hardware, the software just hangs up. You just get frozen in place and your outputs get frozen in the energized position.

What a watchdog timer does is it's an external device that basically every PLC scan, you're going to reset that timer. Constantly resetting the timer.

If the program stops firing, the resets stop. When the resets stop, the timer starts timing. Eventually, the timer is going to time out.

When the timer times out, you're going to open a set of contacts. The most common thing to do is using that open set of contacts to basically remove all of the power going out to the field to the final elements, which if you are de-energized to trip, will cause every final element in the field to go to the safe state, which is a pretty severe thing to happen.

You might cause a lot of flaring, a lot of concern, because everything slams shut simultaneously. But that is what a watchdog timer does, because at that point in time, you know your safety PLC is not working. You need to get yourself to a safe state. Okay, that was our last definition.

## Clause 3.3 Abbreviations and Clause 4 Overview

The next thing in the standard is Clause 3.3, which is abbreviations. We went through some abbreviations that were contained in the definitions themselves, but there is also another page. So it's only one page, not that many. Table 1 is a page of definitions of things that you're going to run into, like SIL, SIF, SRS, and even other things that aren't mentioned that frequently, like CCPS is the Center for Chemical Process Safety of the AICHE, which is also defined as the American Institute of Chemical Engineers. So if you need to know an acronym, they are in Clause 3.3.

And this is going to take us to the last clause that we're going to talk about today. Next time we do a podcast, we're going to start with Clause 5, Management of Functional Safety.

But before that, we're going to have to discuss Clause 4, which is only one sentence. The title to Clause 4 is Conformance to the IEC 61511-1 Standard, 2016 version.

The clause states, To conform to the IEC 61511-2016, it shall be shown that each of the requirements outlined in Clause 5 through Clause 19 has been satisfied to the defined criteria, and therefore the clause's objectives have been met.

Okay, so why is this clause even here? Now we're going to go back again one more time and talk about the concept of normative and informative.

In the standards worlds, there are clauses that are normative, which means this is a requirement. You have to do this. You don't have an option. You must do what this clause says in order to be compliant with the standard. And when people are auditing, they're going to ask if you met that clause. And if you didn't meet that clause, you're going to be non-compliant. But what is normative and what is informative?

Well, what Clause 4 is telling you is that everything that you just read in Clause 1, Clause 2, in Clause 3, the definitions, that's right, the definitions are not normative. You're not required to follow them. They are informative. So informative things are additional information, best practices, reference, background, history, things that help you to understand the standard, but are not requirements in and of themselves. So everything in Clause 4 and earlier is informative.

Everything from Clause 5 to the end is normative, meaning you have to do it. You have to follow it, except for the notes. So Clause 5 through 19, those are the rules that you have to follow. And the rule is the rule, but when you see a note after that, that's going to be, again, informative, additional information, background, history, best practices, additional discussion.

So with that being said, next time we talk in the next podcast, that's the first time that you're going to actually have a requirement that you're required to follow. All right, we'll begin Clause 5, Management of Functional Safety, next time.

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.