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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E9 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 9: IEC 61511, Clauses 3.2.65 to 3.2.76 (Safety Function, SIL, and Programming Languages)

—

## Introduction and Episode Overview

How many definitions does it take to actually define what a safety instrumented function is? Surprisingly, it's more than you would think.

Welcome to the Kenexis Functional Safety Podcast. I'm your host, Ed Marszal, President and CEO of Kenexis. Kenexis is a technical safety consultancy that helps chemical process industry companies to analyze risk and design engineered safeguards like safety instrumented systems and fire and gas detection systems. Kenexis also provides the industry-leading suite of software tools, including our best-in-class Vertigo software for SIS safety lifecycle management.

In this first season of the podcast, we are going to focus on the IEC 61511 standard, doing a deep dive into the standard, including more depth of information on what the standard means and how to apply it, brought to life with personal war stories and behind-the-scenes discussions of the committee members as we develop the standard in ISA 84 and IEC SC 65.

Before we start, a little disclaimer. I will be providing my opinion on technical and engineering topics. This information is provided on a best-effort basis and is of a general nature. The information presented in this podcast might not be applicable to your specific application. It is the obligation of every engineer to thoroughly analyze any system that they are designing and not blindly rely on any general advice presented in this podcast.

## Safety Function Definition

Continuing in definitions with Clause 3.2.65, which is the definition of a safety function. Now, this is the definition of a safety function, not a safety instrumented function, which is going to come up next.

Why the difference? Well, you know, in the standards world, we try to be very precise with our definitions. And we also need to consider that some things can be used in different contexts and in different ways. So we're going to build our way up to safety instrumented function by starting with safety function and then going from there. So all these things are kind of close together in the standards. So that's kind of handy. It's going to make it easier to talk about them.

So 3.2.65 is the definition of safety function, which is a function to be implemented by one or more protection layers, which is intended to achieve or maintain a safe state for the process with respect to a specific hazardous event. Okay. Not a bad definition. A little bit confusing, but some good stuff in here.

So first off, a safety function at this point in time is not limited to instrumentation. So the core definition of safety function is basically anything that is going to make you safer. So how is it going to make you safer? So a safety function is going to achieve or maintain a safe state for the process. That's what it does. And it also in the definition says that it's going to be with respect to a specific hazardous event.

So just because something exists doesn't mean that it is a safety function or a safety instrumented function in all instances across the board. When you're talking about a safety function, you have to be thinking specifically about what type of hazardous event that function is intended to protect against.

It starts out by saying that a safety function is a function. Thanks once again. But the kind of a little bit of confusion here starts out by saying that it is a function that is implemented by one or more protection layers. So a function can be distributed across multiple protection layers in accordance with this definition. That's kind of an odd way to define things. I don't know if I really like the idea of a function being provided by multiple protection layers. You would think that everything associated with that function would be provided in one protection layer.

But the Standards Committee, for better or worse, decided that they wanted to allow one function to spread across multiple protection layers. So it is what it is.

At the end of the day, a safety function is some sort of functionality that's going to reduce risk by getting you to a safe state based on a specific event that you're trying to prevent. Okay. So we have a core definition of safety function, which is not limited to instrumentation, let alone a safety instrumented system.

## Safety Instrumented Function and SIS Definitions

So now in Clause 3.2.66, we're going to define safety instrumented function or a SIF, S-I-F. Now, a safety instrumented function is a safety function to be implemented by a safety instrumented system. Okay. So we're referring to other definitions all over the place. We just talked about the definition of a safety function. And it just so happens that the definition for a safety instrumented system is going to be coming up next in Clause 3.2.67.

There is a note to the definition for safety instrumented function. That note says, note one to entry, a SIF is designed to achieve a required SIL, which is determined in relationship with other protection layers participating to the reduction of the same risk. So we're kind of getting into layer of protection analysis territory. But yeah, so we have a SIF. That SIF is designed to achieve a certain performance target, which is usually going to be defined as a safety integrity level.

And that's just one of the independent protection layers for any particular function that's able or allows you to achieve the risk levels that you're shooting for. Okay. Safety instrumented function, a safety function to be implemented by a safety instrumented system.

So what is a safety instrumented system or an SIS? That is Clause 3.2.67. And it says that a safety instrumented system or an SIS is an instrumented system used to implement one or more SIFs. Okay. So a SIF is something that's implemented by a SIS and a SIS is something that implements one or more SIFs. Thanks for clarifying things. Well, it is what it is. Those are the definitions. Three notes to the entry for safety instrumented system though.

Note one to the entry. SIS is composed of any combination of sensors, logic solvers, and final elements. It also includes communication and ancillary equipment. For example, cables, tubing, power supply, impulse lines, and heat tracing. So this note says that a safety instrumented system is a combination of equipment that achieves the safety objective. So it's not one device or one component in and of itself. It's a collection that performs the function.

Note two to the entry says that a SIS may include software. So that's nodding to the fact that a lot of safety instrumented systems are in programmable systems. And the SIS itself is going to include the software that makes things happen in addition to the equipment that is part of the function. Note three to the function or note three to the entry says a SIS may include human action as part of a SIF. CISA technical report 84.00.04.2015 part one.

This is an area that causes a lot of people to scream and be angry. And it's difficult. So I'm going to try to step back away from my own personal opinion on these topics. But at the end of the day, it's probably not the best choice to include a human action and call it a SIF. That complicates things unnecessarily. But there are those groups out there that want to do it. They want to look at this loop, if you will. So they will say, I have a measurement that triggers a safety critical alarm. Based on that safety critical alarm, there is a human being that's going to decide to press a button.

And when that button is pressed, it will cause a valve to go to the closed state.

Now, 99.9% of practitioners would not call that a safety instrumented function. But the standard doesn't disallow it. Some people choose to make that decision to call that a safety instrumented function. And if you did call that collection of people and equipment a safety instrumented function and assigned a SILT target to it, you need to include that human being as part of the loop. Now, normally, you're not going to consider that a safety instrumented function. You're going to consider that as a non-SIS independent protection layer.

Most of the time, that equipment is not going to reside in the SIS hardware. It's going to generally reside in the DCS or the Basic Process Control System hardware. But again, the Standards Committee has to make lots of people who do things lots of different ways happy. So if you're in the camp, and I am most certainly not in the camp, that would include a human activation and call that a safety instrumented function.

If you're going to do that, well, your human is part of the safety function, and you need to account for their probability of failure, etc. Okay, let's move on now to Clause 3.2.68.

## Safety Integrity Definition and Notes

3.2.68 is the definition of safety integrity. Now, safety integrity is going to have a lot of notes associated with it, and it's a precursor to the next definition, which is going to be safety integrity level. So before we can define a safety integrity level, apparently we need to begin by defining safety integrity. So what is safety integrity? Safety integrity is the ability of the SIS to perform the required SIF as and when required.

Okay, so safety integrity, right out of the gate, they limit, or at least in this standard, they limit the definition to the SIS, which is not necessarily the best choice. You could talk about the integrity of operator intervention. You could talk about the integrity of relief valves. Those are not going to be considered safety instrumented systems, but they are going to have an integrity. So I don't know why the Standards Committee focused on the SIS. I would have instead said it's the ability of a protection layer or a barrier or a safeguard to perform its functionality as and when required.

But again, we, at the end of the day, are writing a standard for safety instrumented systems, so limiting our discussion to that is probably not unreasonable.

All right, note one. There's four notes to this entry. So note one. This definition is equivalent to the dependability of the SIS with regard to the required SIF. Dependability being often understood as an economical rather than safety concept has not been used to avoid confusion.

This is something that back in the day in 2000, when I was one of the co-founders of Exida. So Exida, the DA in Exida is dependable automation. So it started out as excellence in dependable automation. And actually, you know, a couple days prior to starting the company, it was going to be dependableautomation.com. So that word dependable is actually kind of loaded, and it actually comes from the translation from German.

So when you see something described as dependable in the context of safety instrumented systems, it's a common translation of a German word that has not just dependability aspects or economical aspects or safety aspects. It's kind of the whole package of dependable being good. But yeah, I was very relieved to see that the company got renamed with the acronym that included dependable automation as opposed to dependableautomation.com. But anyway, here in this note, we're kind of nodding to that dependability concept.

It's just the confidence that it's going to work would be a better, more English way of describing it. All right, note two to the entry says ability includes both the functional response, for example, closing a specified valve within a specified period of time, and the likelihood that the SIS will act as required. So again, the confidence that the objective is going to be achieved with a high degree of confidence.

Note three to the entry, and it's a long one. All right, here we go. In determining safety integrity, all causes of random hardware and systematic failures which lead to an unsafe state can be included. For example, hardware failures, software-induced failures, and failures due to electrical interferences. All right, so kind of let's unpack this one sentence at a time because we're just one sentence into a very long definition or note to the entry.

So basically, safety integrity is something we're going to need to determine. We're already alluding to the fact that we're going to be running calculations, and when you do that, you're going to want to think about random hardware failures. You're going to want to think about systematic failures, but as we will learn when we get to clause 11.9, when we run our calculations, we are going to run them for random hardware failures. Next sentence.

Some of these types of failures, in particular random hardware failures, may be quantified using such measures as the average dangerous failure frequency or the probability of failure on demand. So we're already talking about how we're going to put a number on or quantify this safety integrity. And we're already alluding to the random hardware failure piece.

The next sentence, though, says, However, safety integrity also depends on many systematic factors which cannot be accurately quantified and are often considered qualitatively throughout the safety lifecycle. So that's kind of a nod to what we're going to discuss when we get into clause 5, the management systems, the verification, validation, auditing, and functional safety assessments that are going to help us to address systematic failures. Last sentence in the note says, So we're going to look at systematic failures through hardware fault tolerance.

And then it refers you to clause 11.4 for other methods and techniques. So we're going to look at systematic failures through hardware fault tolerance. We're going to look at it through a number of other techniques. So lots of stuff coming up discussing systematic failures. It is an issue, but we're not going to address it by some numerical hand-waving. We are not going to pencil whip systematic failures. We're going to address it with management systems.

Note 4, final note for the definition of safety integrity, says, Safety integrity comprises hardware safety integrity and systematic safety integrity. But complex failures caused by the conjunction of both hardware and systematic interaction can also be considered. So we already talked about hardware safety integrity. We're going to talk about systematic safety integrity when we get to definition 82. And yeah, there are failure modes or failure pathways that is going to be a combination of the systematic and the hardware failure. All of that needs to be addressed.

And we will talk about all of that when we get into the calculations in clause 11.9.

## Safety Integrity Level Definition

3.2.69 is the next definition. Now that we know what safety integrity is, now we can define safety integrity level or SIL. And that is a discrete level, one out of four, allocated to the SIF for specifying the safety integrity requirements to be achieved by the SIS. So once we get in a little bit further into the standard, we're going to define more specifically what the safety integrity level is.

And kind of unpacking the definition, it says that it's a discrete level. So saying that something has a SIL of 1 is good. A SIL of 2 is good. But a SIL of 1.5 is no good. That's something that you're not allowed to do because the SIL is a discrete level. It has both numerical connotations and also qualitative connotations.

So a little bit later on, and if you've gone through my training on safety instrumented systems, my training on layer of protection analysis, you'll know that I often recommend a dual specification where you specify the SIL, but you also specify something like a maximum PFD or a minimum risk reduction factor to be achieved if you need a little bit more precision than just the orders of magnitude that the SIL provides.

So it is a discrete level, and it's going to help you to specify the safety integrity requirements based on some numbers that we're going to talk about when we get into the notes.

And there are four notes to this entry. So let's go ahead and hit them one at a time. Note one to entry. The higher the SIL, the lower the expected PFD average for demand mode or the lower the average frequency of a dangerous failure causing a hazardous event for continuous mode. All right. So in this definition or in this note, we're already telling you that that SIL is going to be related to a quantitative performance metric.

And in the low demand mode of operation, which is what we're dealing with 99% of the time or better, that's going to be a probability of failure or the average probability that the SIF doesn't work. When you're in the high demand mode or continuous demand mode, probability of failure doesn't make any sense. So we deal directly with the frequency at which the failure occurs. So we're going to define PFD two different ways depending on the mode of operation that you're in.

And when we get out to the clauses where these definitions occur later on in the podcast series, you will see the numerical correlation.

All right.

Note two to the entry. The relationship between target failure measure and the SIL is specified in tables four and five. So those are the tables that you're going to go to. We're going to talk about later when we get to that clause that have kind of the ranges of the numbers that fit into the different SILs. Note three to the entry. SIL four is related to the highest level of safety integrity. SIL one is the lowest. So SIL one provides a low degree of safety or just kind of alluding to where we're going to go into the future.

SIL one provides you basically one order of magnitude of risk reduction. Whereas SIL four provides you four orders of magnitude of risk reduction. The higher the SIL, the more safety it provides. Note four to the entry says this definition differs from the definition of NIEC 61508 to reflect differences in process sector terminology. So the definition of SIL here and the definition of SIL in the 1508 mothership umbrella standard, the equipment vendor standard are going to be different. When we're talking about process industry applications, we will use the definitions in IEC 61511.

All right.

Now we have a subdefinition. So 3.2.69 has an appendage, 3.2.69.1. And that is a definition for safety integrity requirements. So what are safety integrity requirements? The definition is set of the IEC 61511 requirements, which shall be satisfied by a SIS to claim a given SIL for a SIF implemented by this SIS. Wow. That's a lot of SIS, SIFs, and SILs. Let's now give you the note to that entry, which states the safety integrity requirements are strengthened when the related SIL increases.

So safety integrity requirements are basically a description of what are the attributes that need to be true in order to achieve a given SIL. Those requirements are going to include potentially PFD. They're going to potentially include failure frequency. But they will also include other requirements like minimum hardware fault tolerance. So we have a definition for safety integrity requirements. Did we require this definition of requirements? Probably not. I could have definitely gone by without it, but it is there. So now you know.

## SIS Safety Lifecycle and Safety Manual

All right. Moving along. 3.2.70 is a discussion of the SIS safety life cycle. What do I mean discussion? It's the definition of the SIS safety life cycle. We've already talked about the life cycle in the overview clause, clause one, where we're just kind of defining the scope and introducing the topic. And we're going to talk about the life cycle in an absurd amount of detail when we get to clause six, which is dedicated to the safety life cycle.

So what is the definition of SIS safety life cycle? It is necessary activities involved in the implementation of SIF occurring during a period of time that starts at the concept phase of a project and finishes when all the SIF are no longer available for use. So we're defining that cradle to grave concept of trying to figure out what safety functions we need through hazard and risk analysis and then going all the way to finally taking them out of service through the decommissioning.

We're going to define that entire life cycle and all the requirements in that life cycle when we get to clause six.

Note one to the entry states the term functional safety life cycle is strictly more accurate, but the adjective functional is not considered necessary in this case within the context of the IEC 61511 series. Sounds to me like during the standards committee meetings, somebody desperately wanted the term functional to kick off SIS safety life cycle, but they were voted down. But someone wanted to make them happy and gave them a note that says, yeah, functional safety life cycle is more accurate.

Standards committee work. The things we have to do to get the product out the door and try to make everyone at least happy enough not to vote no. All right. There is a second note to the entry, which says the SIS safety life cycle model used in IEC 61511 is shown in figure seven. We will get to that figure when we get to clause six. But alas, we are still in the heat of clause three. Let's continue.

The next definition is 3.2.71. It is the definition for safety manual, and it is also the definition for functional safety manual. Somebody really likes to use the word functional in front of safety. Okay. The definition is information that defines how a SIS device subsystem or system can be safely applied. We'll talk about safety manuals more when we get to clause 11. There's a little bit more detailed discussion. But, yeah, you need a document for your devices that you're going to use in safety applications that provides specific information for how to use that device in safety applications.

We'll probably spend most of an entire episode when we get into clause 11 talking about this concept and what's involved.

Most of the time, it's going to be your equipment vendor that's going to provide this document to you. Sometimes, in prior use applications, you're going to need to develop your own safety manual because, well, somebody's got to do it. And if the vendor didn't do it, it's up to you. Four notes on the definition for safety manual. Note one states that the safety manual may include inputs from the manufacturer as well as from the user. Note two, for IEC 61508 compliant devices, the manufacturer's input is the safety manual.

So, 6508 compliant devices, part of the process is that the vendor has to put that information together. Note three, it can be a stand-alone document or a collection of documents. Okay, that seems a little bit obvious, but it is what it is.

We don't want to run afoul of anyone who demands that it be a single document by, you know, we'll just put in the notes that it doesn't have to be. Note four to the entry. This definition deviates from the definition of 6508 to reflect differences in the process sector terminology. And once again, the vendor standard is going to be a little bit different from the process sector end user standard, and that's okay. Those of us that are in the end user camp really appreciate being able to use terminology that's more applicable to what we actually do.

## Safety Requirements Specification, Sensor, and Software

Clause 3.2.72 states safety requirements or is the definition for safety requirements specification. In this case, it is singular. It used to be plural. Plural is much more accurate. And we don't have all the neat notes in here about it not being needing to be a stand-alone document, which if you have a single stand-alone document for your SRS that documents everything in Clause 10, that's bad. I mean, that's just — that's not a best practice. That's a horrible practice. Your SRS should be broken up in and separated in multiple different areas.

So, I mean, Kenexis in our Process Safety Training Center, we have an entire — effectively a two-day training course on how to develop safety requirements specifications where we do get into best practices. And putting everything into one document is most certainly not a best practice. It's actually a very bad practice. But a lot of people still do it. More on this coming up in Clause 10 and in the Process Safety Training Center, there is elaborate discussions of how to do a — do best practices for SRS development.

So, what is the definition of SRS? Specification — should be specifications in my opinion — containing the functional requirements for the SIFs and their associated safety integrity levels. Well, thank you for the definition, but there's an entire clause of many pages, Clause 10, that's going to go into more detail on what safety requirements specifications are. And we will talk more about them then.

Clause 3273 is the definition for sensor. A sensor is part of the BPCS or SIS that measures or detects a process condition. Note 1 to the entry. Examples are transmitters, transducers, process switches, and position switches. Okay. Hey, I don't need to belabor that. You know what a sensor is. It's something that measures or detects what's going on in the process. Should be pretty obvious.

Clause 3.2.74 is the definition for software. Software — and we're going to get into software and application programming languages is how we're going to round out this episode. So software — the definition is programs, procedures, data, rules, and any associated documentation pertaining to the operation of a data processing system. So if you needed a definition for software, there it is. I hope you found it helpful. You know, I've been writing software since I was 8 years old on my TI-99 4A back actually in the 70s. But if you needed a definition, there you go.

There are two notes to this definition. Number one, software is independent of the medium on which it is recorded. So whether it's on a CD, whether it's in an EEPROM, whether it is in a RAM, ROM, you name it, wherever it is, it's still software. And note two to the entry for examples of different types of software, C3275 and C3276. So let's keep moving on and I will tell you that C3275 is application programming languages, whereas C3276 is going to be software and program types.

## Application Programming Languages

Okay. So this discussion I'm going to not go into too much detail on because we've already gone over this way back in Clause 1 when we talked about kind of the delineation between what is 1508, what is 1511, and what type of program language you're going to use kind of defines when you need to use 61508 versus when you're allowed to use 61511. So the three types of application programming languages are fixed program language, limited variability language, and full variability language. We've already told you what they are. Let's go to the definitions.

32751 is the definition of fixed program language or FPL, which is a language in which the user is limited to adjustment of a few predefined and fixed set of parameters. So a pressure transmitter is running a program, but you can't change it. You can just change parameters like the zero or the span. Note one to the entry kind of amplifies that.

It says, typical examples of device applications with FPL are smart sensors, for example, pressure transmitters without control algorithms, smart final elements, such as valves without control algorithms, sequence of events recorders, set points for a dedicated smart alarm box.

Ew, somebody has to go and shiv me right in the definitions and start throwing that alarms being SIL rated, which absolutely, if you know me, drives me crazy. But there is a contingent who wants to put sills on your alarms. I am not one of those people. I will fight those people every chance that I get. But hey, they are there and they've been able to get their statements into the standard.

Limited variability language is 32752 LVL. Limited variability language is programming language for commercial and industrial programmable electronic controllers. With a range of capabilities limited to their application as defined by the associated safety manual. The notation of this language may be textual or graphical or have characteristics of both. My goodness, a long definition that told me pretty close to nothing.

Limited variability language is going to be things like function block diagrams and ladder logics that your equipment vendor provides to you simply to configure what their device is capable to do. It doesn't allow you to take full control of the machine. It's very limited in what you can do. And those limitations are going to be defined by the equipment vendor. So think ladder logic. Think function block diagrams. Think sequential function charts. That is LVL. Note one to the entry.

Says this type of language is designed to be easily understood by process sector users. And provides the capability to combine predefined application specific library functions to implement the SRS. LVL provides close functional correspondence with the functions required to achieve the application. So still clear as mud based on the definitions. But a little bit more. It's something that's easier to use than programming in C. Note two to the entry. IEC 61511 assumes that the constraints necessary to achieve safety properties are achieved by a combination of the safety manual.

The closeness of the language notations to the functions the application programmer needs to define the process control algorithms. And the compile time and the compile time and runtime checks which the logic solver provider embeds into the logic solver system program and the logic solver development environment or the maintenance and engineering interface. We will call it later. The constraints identified in the certification report and safety manual can ensure the relevant requirements of 6508 are satisfied.

Clause two is — or the note two here is very dense and verbose and unnecessarily confusing. I don't even want to call it confusing. It just doesn't tell me a whole lot. If I could boil that down. Limited variability languages, the equipment vendors make it easy for you to program. But they also are going to prevent you through doing compile time checks and just the nature of how the language is written. They're going to prevent you from creating dangerous failures. The type of failures that you will be able to create in a limited variability language.

And so things like an infinite loop, you're not going to be able to create it in an LVL where you would be able to do that in an FVL, full variability language. Note three, LVL is the most commonly used language when the IEC 61511 series refers to application program. So the great — the grand preponderance of application programs are written in limited variability languages.

Last definition of application programming languages is full variability language, 3275.3, FVL. The definition is language designed to be comprehensible to computer programmers and that provides the capability to implement a wide variety of functions and applications. So an FVL is something that's going to allow you to take complete control of the entire computer, everything about the computer, and all of its peripherals. So let's go through the notes.

Note one, a typical example of systems using FVL are general purpose computers, like the one that I am looking at right now, my Windows 11 machine. Note two to the entry, in the process sector, FVL is found in embedded software and rarely used in application programming. So it's exceedingly rare that you would use full variability language to actually write the logic of your shutdowns. Note three to the entry, FVL examples include Ada, C, Pascal, instruction list, assembler languages, C++, Java, SQL.

And you can add to that list all day long. So, but again, these are languages that give you full control of the machine and allow you to make a whole bunch of mistakes, like infinite loops, like losing the pointer to where your memory is located, like creating a memory leak so you run out of memory or overwrite memory. There are a lot of bad things you can do when you have total control of the machine. And your equipment vendor will prevent you from doing those things when you use LVL.

So use LVL, avoid FVL, because if you use full variability languages, you must use the rules, the hundred plus pages of rules in IEC 61508. All right.

## Software and Program Types

3.2.76 is where we're going to wrap today. You would think that it is a definition, but it is not. It is three definitions. So 3.276 simply is titled software and program types. And those three types are 3.276.1 is application program. So an application program is a program specific to the user application containing in general logic sequences, permissives, limits, and expressions that control the input output calculations and decisions necessary to meet SIS functional safety requirements.

3.276.2 is embedded software. So embedded software, so you wrote the application software to explain how the shutdown system works or tell the shutdown system what it's supposed to do. Embedded software, you are not going to write. That is what is going to be provided by your vendors. So the definition of embedded software is software that is part of the system supplied by the manufacturer and is not accessible for modification by the end user. It's embedded. You can't change it.

Note one to this entry states embedded software is also referred to as firmware or system software. And then it refers back to 3.275.3, which we just talked about, which is the definition of a full variability language. The final sub definition is 3.276.3, which is the definition of utility software, which is software tools for the creation, modification, and documentation of application programs. The utility software is going to be part of what we're going to call later in clause 11, the maintenance and engineering interface.

Note one to this entry states that these software tools are not required for the operation of the SIS. All right.

## Wrap-Up and Vertigo Software Sponsor

That's going to make it a wrap for this week's episode. I realize that I've been a little bit remiss and I've missed a few weeks because the Global Congress on Process Safety came up. And, well, you know, things had to be done. But we will pick this up again next week starting at clause 3277. And we will keep plugging along through these definitions. There's a lot of them. But I expect that we will be able to get all the way through definitions in the next episode.

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.