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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E22 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 22: IEC 61511, Clause 10.1 to 10.3.2 Bullet 3 (Safety Requirements Specifications)

—

## Introduction and Podcast Overview

Safety, requirements, specifications. Where do I begin? Probably a definition of what a specification is, because the standards writers don't even know.

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

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

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

## SRS Importance and Industry Failures

All right. In this podcast today, we're going to be kicking off, and I mean just kicking off because there's a whole lot to this, the safety requirements specifications section of the standard. And safety requirements specifications, oh man, there's just so much to this. There's so much that needs to be done. There's so much that's currently done just wildly wrong. And this is definitely an area where using the Kenexis Vertigo software as your SIS lifecycle management tool is going to help you and make things a lot easier.

Because a lot of people out there, a lot of very expensive safety lifecycle management tools do a horrible, horrible job of specifications because they were never taught how to write specifications. Definitely not taught how to do them correctly.

So let's go ahead and delve into it.

## Specification Philosophy: Audience and Communication

We are in Clause 10 today. Clause 10 is entitled SIS Safety Requirement Specification, SRS. And right out of the gate, I don't like the title, from the older versions of the standard specifications, used to have an S on it. So this concept of safety requirement specification is going to leave you with the ill-thought-out, erroneous idea that there is one document, one binder, one set of information that contains, that is the safety requirement specification that needs to be compliant with this clause. Nothing can be further from the truth.

What I'm going to tell you is that if you have one document set that contains everything in this standard, you are doing a horrible job. You are a poor engineer that needs to be re-educated on what specifications are. And what you are forgetting if you do this is the audience for the specifications.

Ultimately, in engineering, as with anything else invaluable in life, you have thoughts. You have ideas. Those thoughts need to be communicated to other people to take actions on. And when you do that communication, there is the message, there is the medium, and there is the recipient. And if the recipient of the message does not understand it, it's not their fault. It's your fault. If you write a spec and it's misinterpreted, it's your fault. You're the problem. You're the loser here. So don't blame other people when your specs are misinterpreted. Blame yourself.

Because you need to communicate the message in such a way that you are certain it has been understood by the target audience.

And in the safety life cycle, I will tell you that looking at the safety life cycle, there are far and away more problems, more failures, more junk in the SRS development than in any other portion of the SIS safety life cycle. So we at Kenexis, I mean, we've been writing safety requirement specifications since, you know, 1992. That's when I graduated from college. That's when I took my first job at UOP. And my first job at UOP in the instrumentation and control group, I was writing specifications.

So a specification is going to be a description of an attribute of a piece of equipment or software is something that could be specified also. But it's a description of an attribute. And that description of the attribute is going to inform what device you select, how you set up and configure that device. But it is not going to include other things like operating instructions. So at UOP, there were, and UOP is a company that writes specifications professionally. They invent processes. They license processes.

But in that workflow, in that process, you need to communicate to the end recipient of the license how they need to build the plant in order to make the product. That you have licensed. So in the specification process, you need to convey information about what equipment needs to be purchased, how that equipment needs to be configured, how that equipment needs to be installed. Those are the specifications.

Now, later on down the road, you're going to need to do things like maintenance and testing. But maintenance and testing are not equipment specs. They are operating instructions. So from a communication perspective, when you write specs, you're writing it to the person who's going to buy the equipment, configure it, and install it. If you present operating instructions in that document set, it is not going to get to the person who needs it, who is the maintenance group or the operations group.

So for the maintenance group and the operations group, you need separate communications of information that is going to be procedures, operating procedures. They're very important, but they're not specs. They're procedures. So keeping a delineation of what is a spec and what is a procedure is important.

And Clause 10 just crapped all over that and put all kinds of requirements for operating instructions, and it calls them specifications. So when we get to those, I'm going to call them out and kind of tell you, well, this is kind of the proper way that you should handle it.

## DRY Principle and Relational Database Approach

Now, the other thing that I learned in UOP is the efficient way to write specifications so that you don't repeat yourself. You minimize your work and you don't repeat yourself. Why is it so important not to repeat yourself? Because if you document something in one place, you always know what it is. But if you document something in two places, you're never really sure. Because if you document the same piece of information in two or three or four places, there's a very, very short amount of time before those things don't match. You make a change.

You document it on this spec sheet, but you didn't document it on the SRS. Now nothing matches and you don't know what's right. So that usually happens even before startup. I mean, I'd like to say, well, you know, if the plant is in operation for 50 years, eventually there's going to be documentation discrepancies. No, this is happening even before startup. During commissioning, during validation, you're making changes. And if you're not careful, you're going to get discrepancies.

So we want to write specifications that define equipment. We want to target them at the selection, construction, installation, configuration process. And we want to avoid repeating ourselves. Now, there is a Kenexis way of writing safety instrument system, safety requirements, specifications that hands down is going to be the most effective, most efficient way to do it. It's encapsulated in the Kenexis safety requirements specifications training class that's available on our KISS platform in the Process Safety Training Center. It's one of the training classes.

It's basically a two-day class with no math. Just talks about detailed design attributes and specifications for safety instrument systems. I highly, highly recommend it. And also in our Vertigo tool for SIS lifecycle management, we kind of enforce things.

## Three-Part SRS Structure: Requirements, Data Sheets, Logic

So when I say safety requirement specifications, there's going to be three sets of information that you're going to want to document. The first item is going to be general requirements. And general requirements are basically statements of fact that are applicable to the entire safety instrumented system. Every instrument, every safety function, everything. Okay? So if you're using a de-energize-to-trip system, and that is true for everything, for every input, for every output, for every logic solver, everything is always de-energize-to-trip.

Then you don't need to repeat yourself over and over and say, this sensor is DTT. This sensor is DTT. You could say it one time as a general requirement, and it applies across the board.

So general requirements is your first base starting point. Then you're going to have data sheets. And the data sheets should be limited to safety requirements. So if you look at the training class that I put together for safety instrumented system, safety requirement specifications, I get into a discussion of what's the difference between safety requirements and non-safety requirements. Safety requirements that are things that are only applicable to a safety instrumented system.

So if you think about a sensor being used for basic process control and a sensor being used in a safety instrumented system, if you spec something out for BPCS, it's not a safety requirement. It's a general requirement. So the best example of that might be the electrical area classification. Is the electrical area classification requirement for a transmitter important? Absolutely it's important. Is it a safety requirement? No. Every instrument is going to have an electrical area classification regardless of how it's used.

So we would like to limit our safety requirement specifications to those things that are only SIS related. And then you have a general spec sheet for an instrument that's going to contain the non-safety critical stuff. But regardless, every sensor, every logic solver, every final element is going to have an SRS data sheet that's going to contain the safety critical information for that instrument that is not broadly applicable. Meaning it's not a general requirement. So we're going to have general requirements.

We're going to have data sheets for your SIFs, your sensors, your logic solvers, and your final elements. And the third bit of information is a description of the logic.

And I highly recommend use of cause and effect diagrams because cause and effect diagrams are going to be the most concise way to convey logic requirements. They're kind of universally accepted. They're easy to understand. They're applicable in a large number of scenarios. So there are other ways to define logic. You could do binary logic diagrams. You could write a very long narrative. But in my experience, the most commonly used approach is going to be the cause and effect diagram because it conveys so much information in such a compact format.

So once again, the three parts of your safety requirements specifications are the general requirements, the data sheets, and the logic description, which is going to be the cause and effect diagram.

That information combined is the safety requirements specifications because a lot of times these things will live apart from each other and they won't be part of a single document. But if you're using Vertigo, they're all going to be one relational database.

And I highly, highly recommend using relational databases for tracking your safety requirements specifications because when you make a change in one place, it's going to get carried over everywhere. So if you change your test interval while you're looking at your SRS, that change will also necessarily get carried over to your SIL verification calculations to make sure that everything is still in compliance in that attribute. You only hold that piece of information one place.

And then when you need to report out to different people because the data in the SRS is going to have a lot of different target audiences, you can customize the reporting to an audience without changing the underlying data structure. So relational databases, very effective way to do this.

Now, what you don't want to do, which I have seen far too much of, and there are very wildly expensive pieces of software for doing safety requirements specifications that will prepare an SRS the way that you could foolishly think that the standard implies that it should be written, but that would be foolish of you. And you would only think this if you've never written specifications before you read the standard.

Like I'm pretty sure some software vendors out there that are in the safety lifecycle business have never actually done a basic process control system specification and have really no realistic idea of how to write specifications. That would be the Q&A.

## Q&A Checklist Anti-Pattern and Clause 10 Walkthrough

So basically, we're going to get to Clause 10.3.2 in a second here. And Clause 10.3.2 has about 30 bullet points. So what you could theoretically do is, on a safety function by safety function basis, turn each one of those bullet points into a question and then provide the answer to that question. That is an approach that a regulator or someone who is doing a certification might love because it makes their job easier. But that is an absolute nightmare for people who are trying to purchase equipment, for people who are configuring, people who are programming.

So if you are looking at an SRS that is basically the bullet points in Clause 10.3.2 as questions and then answers, don't walk, run away from that product. It's garbage. And if someone did that for you as a service, hand it back to them and say, no dice, redo this. This is garbage. You probably should take the Kenexis SRS training class and do it the Kenexis way because that's the optimum, ultimate way to get SRS written effectively and efficiently because we do equipment specifications. We don't repeat information. Okay.

So that's the big picture. We want the three-pronged approach. General requirements, data sheets, cause and effect diagrams. So that said, what are all the bits of information that need to be included? Okay.

So I'm going to start at Clause 10.1. It's 10.3.2 where we actually start delving into the individual bullet points, but let's do the forward matter. Clause 10.1 is informative. It's just the objective. It states, the objective of Clause 10 is to specify the requirements for the SIS, including any application programs and the architecture of the SIS. So the safety requirements specifications necessarily includes application programs. I think that the best spec to be used as the basis for programming a safety PLC is the cause and effect diagram. And I really don't…

It's not that I don't contone. I don't recommend having a separate software SRS. I like to have the SRS information all in one place and have it simultaneously convey requirements for the software and the hardware integrated together. Okay.

Clause 10.2 is general requirements. Now, not the way that I was just talking about general requirements, but general requirements for this section. 10.2, general requirements. The safety requirements shall be derived from the allocation of SIF and from those requirements identified during the hazard and risk assessment. Okay. That's the first sentence.

Basically saying that when you're developing your safety requirements specifications, it happens necessarily after you did your hazard and risk assessment, after you did your allocation, so you know what your safety instrumented functions are and what they're supposed to do. There's a lot of the hazard and risk analysis process engineering phase that precede safety requirement specifications because you need to know how the process operates in order to be able to define how the safety instrumented system operates. Okay.

The second sentence states, the SIS requirements shall be expressed and structured in a way that they are, and then there's two bullet points. One, clear, precise, verifiable, maintainable, and feasible.

And the second bullet point is written to aid comprehension and interpretation by those who will utilize the information at any phase of the safety life cycle, which kind of goes back to my preferred approach for writing specs. Because if all you do is make clause 10.3.2 a Q&A, that is not written to aid the comprehension and interpretation of people that are going to write a program, of people that are going to purchase equipment, of people that are going to configure the equipment. Those people are going to want data sheets and a cause and effect diagram, not a Q&A form.

So that whole Q&A of clause 10.3, if you see it, throw it away. It's junk. That's no way to write safety requirements specifications. Also, that first bullet point, clear, precise, verifiable, maintainable, and feasible, that Q&A checklist approach is ultimately not very verifiable. It's not, my God, you're going to repeat the same information like a million times. You know, think about it. If you have a shutoff valve on a fired heater, how many safety functions is that double block and bleed arrangement part of? Five, seven, ten safety instrumented functions?

And if you go sift by sift, you'll be documenting those shutoff valves for every sift that they show up in. That's insane! You can't do that. Horrible. Don't use that approach. Write a data sheet for those valves one time and then it's referred to in every safety instrumented function that utilizes those valves. That's going to make things more precise. Okay, so those are the general requirements for Clause 10.2.

Then in 10.3, we're going to start listing out what the safety requirements are. So, Clause 10.3.1 states that the safety requirements addresses issues that shall be considered when developing the SIS safety requirements. So, this clause is going to tell you what you need to think about when you're writing your safety requirement specifications.

And then Clause 10.3.2, which has about 30 bullet points, but before the bullet points, it starts out with, these requirements shall be sufficient to design the SIS and shall include a description of the intent and approach applied during the development of the SIS requirements as applicable. So, the Clause to 10.3.2 is setting the stage for what are all the requirements, what are all the things that you need to think about when you're developing a safety requirement specification.

Okay, now, for the balance of this episode and for the next three, four, five, six episodes, we're going to hit all of the bullet points. When I hit the bullet points, I'm going to do all of the following. I'm going to talk about the requirements. I'm going to explain whether the requirement is a specification or it's not a specification. It's something else.

I will explain to you the optimal location for that information to be stored. And I may give you a couple of options depending on how you do things. And I will definitely key in on Kenexis Vertigo if you're developing your safety requirement specifications in Vertigo, what's the correct location or some options for the correct location to document this. Okay, so let's go ahead and dive into it.

## Bullet 1: SIF List and Tag Conventions

We're going to have to hit all these bullet points. So we should start out with bullet point number one. And again, these are all things that are required to be documented in your safety requirements specifications. Bullet point number one, a description of all the SIF necessary to achieve the required functional safety. That's the first requirement. You need to document a description of all the SIF necessary necessary to achieve the required functional safety. For example, e.g., a cause and effect diagram or a logic narrative.

Okay, so now right out of the gate, item number one causes me grief, causes me trouble, causes me pain, causes me suffering.

Why is this? because a list of safety instrumented functions versus a logic narrative and a cause and effect diagram, you're not going to get a one-to-one correlation. So long as multiple safety functions can trigger multiple outputs outputs and in some cases the definition of the SIF or the functionality required when you trigger a SIF includes things that aren't critical for safety. So for clause number one, the general location that you're going to document this is going to be a SIF list or an IPF list is what it's usually called in the Kenexis Vertigo software.

Your SIF list is going to include several things. And a printout of your SIF list is something that you would usually include in a printed SRS document or it's generally also going to be part of your SIL verification calculation report but it's something that is easily printable definitely out of Vertigo and any other SIS safety life cycle if it can't print a SIF list for you my god what are you doing? Get rid of the software. Okay so what's going to be included in a SIF list? Number one you're going to have a tag number.

Every safety instrumented function should have a tag number associated with it. That tag number is going to be something that's going to tie your SRS to the piping and instrumentation diagrams. It's going to be a way for you to collect field devices so sensors and final elements and associate them maybe with a safety instrumented function definitely with a group of safety instrumented functions we at Kenexis like to use the concept of an ipf group where you will collect multiple safety instrumented functions that are associated with a single piece of equipment together.

So for instance if I have a fired heater I might have a set of safety instrumented functions associated with it so let's say that we're going to call the group of interlocks 101. That's the number in the tag number. The tag number or the tag itself the description generally you're going to want to use u z c why c because it's a controller. It takes inputs does logic and moves outputs based on the inputs. That's what a controller does. It's a controller. The last letter needs to be a c. U the first variable. Why do we call it a u? U is for multi variable.

So if you look at all the interlocks associated with the fired heater there's going to be a high pressure trip low pressure trip on the gas high and low pressure on the pilot gas. Low air flow might be another interlocked high temperature low flow on the heater tubes. There are multiple variables so you use a u. Now the z in the middle is something that the isa standards committee has defined reserved for safety instrumented systems. Why didn't they use an s for safety? I don't know. I wasn't in the room. I would have used an s. Multivariable safety controller. That makes sense.

But the standards committee i don't know some people have kind of a lock in their skull that says if there's an s in the middle it's a relief valve. So anyway even though z has other uses especially the z axis of a lot of times position switches are labeled with z in this particular case with the z in the middle it's going to be s i s so u z c would be multivariable safety instrumented system controller and then the number 101 would be associated with heater a or the feed heater let's say.

Now the feed heater is going to have a low fuel gas pressure trip a high fuel gas pressure so what i like to do and there's nothing in the standard that says you have to is each one of those would get a letter after it. So the high fuel gas pressure trip would be 101 a the low fuel gas pressure trip would be 101 b and so on so all of these safety functions sometimes they share common pieces of equipment. Sometimes they have a common test plan. A lot of times you're going to want all this equipment to show up on one common cause and effect diagram.

So it makes sense to group these things together and we at Kenexis call these ipf groups so you can group these safety functions together and the equipment associated with these safety functions together into ipf groups in our vertigo software. So tag number for the safety function is the first item then a description will include the major piece of equipment. I like to use the tag number of the piece of equipment the measured variable the deviation of the measured variable and the actions taken when that measured variable deviates outside of its limits. That's a good description.

So if you want to learn the proper way to write a description for a safety instrumented system go to the Kenexis Process Safety Training Center go to the SRS training class and I believe it's going to be section 4 mission 3. There's an entire section dedicated to the best practice for writing a description or a name for a safety instrumented function

## SIF Inputs, Outputs, and Safe State

alright so we had tag we have description then we're going to have inputs outputs and logic solvers. So the inputs it's not every input to the PLC. What we're doing here is we're creating a list of all the sensors that are going to be able to detect the out of control condition that is required to be detected by this. Safety instrumented function. So even though the fired heater has a low airflow measurement a low airflow measurement doesn't tell me that the fuel gas pressure went low.

So only the measurements that will tell me that the fuel gas pressure went low and or that I lost my flame because the fuel gas pressure went low would be the inputs for this function. The outputs for the function are all the outputs that need to move that are the minimum and sufficient criteria to get to a safe state. So the minimum and sufficient actions. So in this case of a fired heater the minimum and sufficient actions would be one out of two of the double block and bleed are required to get to a safe state.

Now opening the bleed valve is a common additional action but opening the bleed valve is not required to get to a safe state. As long as I close my isolation valves I'm not going to create an explosive mixture in the firebox and an explosion in the immediate acute scenario. So only closing the two block valves is required to get me to a safe state. But you might want to document and we kind of recommend this in the notes section of the IPF description that you're also going to open a bleed valve but that's not part of the safety instrumented function. So it might show up in the notes.

It'll definitely show up in the cause and effect diagram but it's not part of the SIF. So what are the measurements that can detect the out of control outputs to get to a safe state? And then where do the wires land? What is the PLC that the inputs and the outputs are going to be wired to. Usually it's just one.

In vertigo we have the ability of using multiple logic solvers because sometimes you will for instance like for a compressor you'll wire your vibration trips into one logic solver the Bentley Nevada and then that logic solver will communicate to your SIS logic solver for the final element. So we do give you the ability to put multiple logic solvers in vertigo because a failure of either one of those two logic solvers is going to prevent you from getting to a safe state with respect to that particular hazard. So that information is the SIF.

We like to see a list that defines what all the safety functions are. And kind of going back to the bullet point a cause and effect diagram really doesn't tell you what the SIF is if there are additional actions.

So a cause and effect diagram will tell you that when the fuel gas pressure goes low you're going to open a bleed valve between the two block valves but that bleed valve is not actually part of the and a logic narrative might not be enough if it doesn't know to say hey it's even though you're going to open the bleed valve it's not actually part of the safety instrumented functions. Just closing the block valves is part of the safety instrumented function. Okay that was just bullet point number one.

So you could see that there's going to be a lot to talk about as we're going through information section but without further ado let's do two more bullet points before we close it out today.

## I/O Device List and Common Cause Failures

So bullet point number two states you are required to document a list of the plant input and output devices related to each SIF which is clearly identified by the plant means of equipment identification e.g. field tag list. So I need a list of the input devices and I need a list of the output devices. Hmm. Well from a perspective of practicality you might have an IO list especially when you need to define how many cards of what type I need when I'm buying my safety PLC equipment? But is an IO list something that you maintain in perpetuity? I would argue it's not.

But hey if you're using a relational database like vertigo you always have the ability to go into vertigo and generate an input list report or an output list report. Now for people that are not going to maintain an input list or an output list in perpetuity your cause and effect diagrams will have all of the inputs and it will have all of the outputs. Those inputs and outputs will be defined by their tag numbers and you will generally have a description at a minimum a description of the service of those field devices.

Depending on your cause and effect diagram you might have a lot more information like ranges and set points and other information. So the cause and effect diagram could be a replacement for having an IO list kind of in perpetuity after you're done with the purchasing process. But in Vertigo it's easy to print that tag list out at any point in time that you would want that type of information. Okay so there is the listing of the input devices and the output devices.

Now also in Vertigo each input device and each output device is not only can you print a list you can print the spec sheets for all those devices !

all for the third item this is the last thing I'm going to talk about today. I'm going to spend a little bit of time talking about it but I'm annoyed already that I have to talk about it because it's not a spec. Okay so the standard says for bullet point three you need to specify requirements to identify and take account of common cause failures. So what do most people do here? For a safety function there's going to be a question that says what requirements what items are required to account for common cause failures? And 99 times out of 100 the answer is going to be no special requirements.

Okay so a lot of documentation for nothing. So think about this for a second. Your safety requirement specifications generally you're going to document by exception. So here if there are requirements for common cause you need to spec out what they are. So for instance if you know that you're in a service that has severe plugging and you want to put in taps or extra equipment to flush your taps out with oil or flush your taps out with air or you need to install the device in a certain configuration to prevent accumulation of solids in your line you need to spec that out.

But you only need to spec it out when you require it. So there are a couple things I'll talk about here. It's not bad to have something on your data sheets for the equipment. Now these common cause requirements don't sit at the IPF level. They sit at the instrument level. So if I've got a pressure transmitter on my fuel gas. And I'm burning refinery gas that has all kinds of particulates and liquids.

I might want to use instrument air to I don't want to use instrument air. I might want to use clean natural gas to blow through my taps on an occasional basis at purging mechanism. If I was going to do that I would spec that out with the instrument not the instrument of protective function because that instrument is going to be used in the high fuel gas pressure trip. It's also going to be used in the low fuel gas pressure trip. So from a data perspective that common cause attribute belongs with the instrument not with the IPF not with the SIS as a whole with the instrument itself.

So either you can have a general requirement that applies to the SIS as a whole that gives you motherhood an apple pie description of your IPL rationalization process where we discussed the common cause and if we didn't specify anything it's because we determined that there are no further design requirements to address common cause failures. So you could write that once in your safety requirement specification section or you can have a common cause requirements for every sensor for every final element and then you would document it separately for each piece of equipment.

What the common cause requirements are that need to be addressed or you could just say none if there are no common cause no special design attributes of the instrument to address potential common cause failures

## Episode Wrap and Vertigo Advertisement

! okay well I think I'm going to wrap at this point in time for this episode of the podcast right there after our discussion of common cause failures. And next week we're going to pick it up on bullet four which is going to talk about safe states which is going to be another long discussion. There's going to be a lot of discussions before we get all through all the way through all 30 odd bullet points that are contained in this section but that's going to be the wrap for today see you next week

now that you've heard some insights on technical safety functional safety and the IEC 61511 standard let me tell you a little bit more about how to easily and effectively implement the safety life cycle ! using the Kenexis integrated and our SIS safety life cycle management tool Vertigo Vertigo is a comprehensive tool set for performing assessment calculations documenting and maintaining the design of safety instrumented systems.

Analysis begins with importing or synchronizing a list of safety instrumented functions with their definitions and associated performance targets from our open PHA tool for HAZOP and LOPA documentation. Each safety function can then be analyzed by performing a SIL verification calculation complete with a collection of tools for optimizing designs and a database of thousands of potential instruments to define failure rates and diagnostic coverage capabilities.

After the SIL verification calculations are defined you can build an SRS by automatically generating a cause and effect diagram from the SIF definitions and other defined instruments. Each SIS instrument will include a customizable data sheet and general requirements that are applicable to the SIS as a whole and can be entered individually or even bulk imported from customizable libraries.

After the design phase you can even use Vertigo to track and document testing throughout the entire life of the facility can can access 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.

Thank you.