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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E48 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 48: IEC 61511, Clause 12.1 to 12.2.5 (SIS Application Program Development)

—

## Introduction and Podcast Disclaimer

The first technical safety standard, ISA 84, didn't talk about programming it at all, so we decided when we added it, we would wildly overcomplicate the situation.

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

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

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

## Clause 12 Overview and Application Software Definition

All right, so we just wrapped up clause 11, which I told you is definitely my favorite clause because it goes into the detail, design, the nuts, and the bolts of the safety instrumented system. Now we're going to go into clause 12, which is my least favorite clause because I don't know, I find it to be very administrative, wordy, unnecessarily complicated, a variety of other things, but anyway, we do need to talk about it. It's clause 12.12 is SIS application program development. So, programming, software development for your safety instrumented system.

Apparently, write the software in accordance with the SRS is not enough.

So we've got clause 12, which begins on page 63 of my version of the standard and extends all the way out to just page 67, it covers the entire page. So 68 is going to be factory acceptance testing. So we're talking about a lot of pages, but then again, it is very few pages in comparison with the rules for developing software that are contained in 61508, which you will need to follow if you use a full variability language, or if you are trying to achieve a SIL4 target, that we discussed all the way back in section one, the scope section.

And we're going to revisit some of these concepts as we go over the standard.

So, today we're just going to begin our dive in the clause 12. We're going to talk about objectives and we're going to start into general requirements. So, clause 12.2 is going to be general requirements. We're going to start into them, but there are a lot of them, so we're not even going to get through all the general requirements. But hey, let's get into it. So, clause 12 is SIS application program development. Clause 12.1, objective. And the objective, all of one sentence says the objective of clause 12 is to define the requirements for the development of the application program.

Okay, pretty straightforward. We're going to define what are the requirements, what are the things that you have to do, what are the things that need to be true for your application software.

So now we should maybe step back a little bit and talk about what application software is because there's a lot of software going on in the SIS environment. Most of that software is outside of your scope because you're going to leave it to your equipment vendor to handle some of the other software. So we have operating systems, we have disk management systems, we have firmware, we have maintenance and engineering interface software. That's all software that's part of the SIS journey, but we're going to leave that to the equipment vendor. What we're talking about is the application software.

So somehow in memory in my computer, I get the values of inputs. And I am able to set the value of outputs based on the value of the inputs. That is the application program. What, how does my safety instrumented system respond to the inputs and generate outputs. Now, in terms of the application program, we are going to use another piece of software called the maintenance and engineering interface software to create the application program.

Now, the PLC itself has an operating system, if you will, that it's running, it has firmware that's running on the chip level to do things like process inputs and process outputs. We're not talking about any of that embedded software utility software. We're only talking in clause 12 about what you, the end user, are going to write, which is going to translate the value of inputs to the values that you will assign for the outputs.

Okay, so that's what the objective is. We're going to set what the requirements are, and then we're going to, well, that's the objective. Now let's talk about what the requirements are. There are a series of clauses in Section 12. 12.2 is general requirements. It applies to the application program across the board. 12.3 talks about the design of the application program.

## Critique of Separating Programming from Hardware Design

Now, that's kind of where I get a little bit crossways with the standards because the design of the application program and the design of the hardware are kind of part and parcel and put together. The definition of safety functions, the safety requirement specifications. This is all tight and integral. And the concept of splitting the programming piece off as its own separate entity, I think it is counterproductive. I don't think it's a good idea. I think that the documentation of the program should be part and parcel with the app, the description of the hardware itself.

I don't really feel that it makes that there's a really strong case to separate the two. A lot of times, the engineer that's involved in configuring the hardware will also be writing the software. And honestly, if you use a limited variability language that is provided by your equipment vendor, it's not really that hard to write the program, and it's really kind of hard to screw things up.

Okay, so application program design is 12.3. 12.4 is going to be application program implementation. And clause 12.5 is requirements for application program verification. 12.6 is the last, and it is requirements for application program methodology and tools.

So there are general requirements, but then in the balance of the clause, it's basically saying, Well, I'm going to need to design my application program, which I would argue was done during the SRS phase. Everything you need to do to program, to design the program, was part of the design of the SIS hardware. I don't understand why you would ever want to separate those things from each other. 12.4 is kind of coming in and saying, okay, I've got a design of the software spec.

Now I'm going to actually execute that specification by writing the software itself, which honestly, I mean, let's get down to brass tacks here. How does programming happen? Usually, you're going to hand the application engineer, maybe you're going to hand a systems integrator, an equipment vendor. Well, you're going to hand them the SRS, which is primarily a cause and effect diagram. And that's what they're going to use to execute the programming.

In a not too distant future, I expect programs to be completely automatically generated from the SRS. So, kind of this whole specification and implementation of the program, you won't be able to separate it because it's all part of the SIS software. This is definitely the direction we're going with our Vertigo software in the Kenexis integrated safety suite in KISS. We're already standardizing the format that the safety requirement specifications are held in, and one of the long-term goals of that is to be able to automatically generate code on a target PLC. But

I digress. The standard says we're going to design it, then we're going to implement the program, then we are going to do Um, testing of the application program. So there's a verification of the application program. Now, yes, you're testing your program as you're developing it, a separate verification that stands outside of the FAT, that stands outside of the verification of the SIS as a whole. I don't know if I see a lot of value in formal verification. The formal verification happens after we've hooked up all the field hardware. And until that point, you really don't know anything.

But 12.5 verification, goody, goody, goody. And then finally, our last clause here is going to be 12.6, which is requirements for application program methodology and tools, which that will

## Clause 12.2.1: Application Program Safety Requirements

probably be its own little section on what tools, what methods, what techniques. How do you write that program? But that's a couple weeks from now. Let's roll it back to 12.2, which are the general requirements. This is kind of, you know, in general, what is required to be implemented to be executed during that software development phase.

Okay, first clause 12.2.1. One whole sentence. It says: the application program of the SIS shall be in accordance with the application program safety requirements. Then with a little parenthetical C 10.3.3 and all the requirements of this clause for SIL up to and including SIL 3. They did a little interesting machination there. They didn't say SIL 1 to SIL 3. They said SIL up to and including three, which kind of puts on the table, if you will, anything residing in the SIS that doesn't actually need to even be SIL 1. So that's kind of how the standard's written. Was that deliberate?

I don't know. But hey, okay. The application program shall be in accordance with the program safety requirements. And once again, I'm going to get up on my soapbox and say that I want those requirements contained either in the SRS or in some cases, you will refer to other external documents that might have some of the peculiarities of how you write your programs, like what tools you use, where do you store your information? H doow you keep track of revisions? How do you name your variables? That type of stuff, that type of standardization is good.

It's either going to be at a corporate or a site level. The site level is where I typically, see those kinds of naming policies and procedures. And there's no reason to write all that out in an SRS. You can refer to an external document that contains that information. But hey, if you want to write that out in the SRS, I mean, feel free, especially now. A little bit of look into the future. Vertigo, the Kenexis SIS software, we are updating our general requirements tool to not be so clause-based, not be so database-based, but instead it's basically going to be like working with a Word document.

So you're going to have a Word document style editor inside your safety requirement specifications where you could just kind of freeform the text. So if you want to freeform the text, add the text for your software development procedures, you want to put that into a documentation that resides in the general requirements section, have at it. It's going to be an ultimate tool for this type of thing, especially since once you get done with that, you could put that type of information into a library. All right, next item.

So, in clause point one, you're gonna write your program in accordance with the safety requirements that you wrote down that are essentially part of your safety requirement specifications. Clause 12.2.2 states.

## Clause 12.2.2: Reviewing SRS for Completeness

This one's a little bit longer of a clause. The application programmer shall review the information in the SRS and the application program safety requirements to ensure that the requirements are comprehensive, unambiguous, understandable and consistent. Well, that's the first sentence here. There's going to be more.

This gets a little bit tricky now because now we're kind of violating the cardinal rules of spec writing, which is H here there's a requirement that is going to not be a spec, but it's a requirement that goes into your procedures or your functional safety plan that says, yeah, when someone is writing code, step number one, review the SRS and application program safety requirements to make sure that they have enough information to do their job. Now, my argument, my best practice, is that the application program safety requirements are part and parcel of the SRS.

So you're just reviewing the SRS to make sure that you have enough information to write the code without having to do any guesses, without having to do any assumptions.

Okay, second sentence of clause 12.2.2 states: Any deficiency in the application program safety requirements shall be identified, resolved, and if changes are made to the application program safety requirements and impact analysis shall be carried out. Okay, so what is this saying? If your SRS did not provide enough detail for the person writing the program to actually write the program, well, you need to fix it. Add that information in. And if you added information in, you changed your SRS.

So we need to do an impact analysis to make sure that the new information that I just added into the SRS doesn't change things, doesn't modify things, doesn't make me return to earlier stages in the safety life cycle. I doubt that they would. I don't I can't even envision what a change like that would be, what it would look like. But it's not outside of the realm of possibility. Okay, let's continue on to clause 12.2.3.

## Clause 12.2.3: Limited vs Full Variability Languages

12.2.3, again, we've got a handful, three sentences in this clause. First sentence: The IEC 61511 series addresses programming in limited variability languages. And the use of devices using fixed program language, period. Okay, so right now we're saying if you're using this standard, LVL is what you're writing your application programs in.

LVL, again, limited variability language is going to be things like ladder logic, function block diagrams, sequential function charts, and maybe structured text if there is a structured text editor that is built into your equipment vendor's maintenance and engineering interface. So, those are limited variability languages. We give a little bit more flexibility in using those types of tools because it's hard for you to create a dangerous failure in ladder logic. It's a lot harder. Whereas if you're using full variability languages like C, JavaScript, Lisp, whatever, COBOL.

That's a blast from the past. If you're using one of those languages, you can create infinite loops, which cause your PLC to hang up. That is a dangerous failure. You cannot do that in a limited variability language because your equipment vendor won't allow that to happen. So that's why the rules are a little bit easier for limited variability languages, my recommendation to you is just do not use anything other than an LVL. They are quite powerful, definitely powerful enough for anything I have ever seen happen in a safety PLC.

Okay, that first sentence references fixed programming languages, but you don't program something that is in a fixed program language. It's got fixed right in the name. It's like that pressure transmitter that's running a program, but you can't change the program. You can change settings, zero, span, so on. So we don't need to talk about programming fixed program language devices because you can't change the program. The program's been set, it came to you from the vendor, they are the only ones that can manipulate it.

All right, the next sentence here in clause 12.2.3 states: the IEC 61511 series does not address full variability language and the IEC 61511 series does not address SIL for application programming. So if you want to use JavaScript, you might want to go to the doctor and you know, check yourself out because that's crazy. It's crazy, crazy.

But if you do, you need to follow 61508. If you're SIL 4, you're gonna need to follow IEC 61508. And I mentioned here that we've got about five pages of rules for writing application software in IEC 61511. The 61508 standard has an entire separate part, part three, dedicated to all the rules, policies, and procedures that you need to follow if you're going to be compliant with 61508. We don't put all those requirements on the 61511 programming because in LVL there's a small fraction of the things that can go wrong in comparison to full variability language programming.

So we don't need to do as much work as you do if you want to use a programming language that can take control of the whole computer.

## Function Blocks Written in Full Variability Language

All right, the last sentence here in clause 12.2.3, or the last, yeah, last sentence says, where function blocks are written in an FVL, then these shall be developed and modified under IEC 61508 Part 3 2010. Okay, so function blocks. Function blocks are probably the most common today method to program a safety PLC. You kind of wire inputs in and then you use kind of logic gates, if you will, inside the function block diagram to execute code. And those, what the function block does is pre-programmed. Now you can create your own function blocks.

Your equipment vendor, a lot of time, provides function blocks for you. What this last sentence is saying is that if you create a function block, but you do it in a full variability language, so you're using function block diagrams, but the function block diagram will call like a C-sharp routine. Well, that function block needs to be written in accordance with 1508. Now, I am not aware of any equipment vendor that will allow you to build custom function blocks in a full variability language.

Most of the time, when you're developing your own custom function blocks, you'll do it using the equipment Equipment vendors primitive function blocks. So you create a page of function block diagram logic and essentially, for lack of a better word, compile it down into a subroutine that now you have a series of inputs that generate a series of outputs, and you've created your own function block diagram.

So, kind of making this a little bit more tangible, for instance. It's very common to put a two out of three vote into a custom function block where you wire in the sensor one, sensor two, sensor three process variable, and you might also wire in a sensor one, sensor two, sensor three bypass that allows you to bypass one of those sensors one at a time. And then the output will just be the either a vote-to-trip or not vote-to-trip. Now inside, you're going to do an AND gate for A and B, ORD with an AND gate for B and C, ORD with a AND gate for A and C.

And then for each of the A, B, and C, you're going to have gates that make it true if the bypass is in the bypass state. You will also make a true based on some sort of either ascending or descending comparison against the process variable that kind of converts that analog measurement into a yes or no. Are we in the trip state or not? So you're going to have a lot of two out of three voting.

So it makes sense to build your own custom function block for a two out of three vote, and then use that, you know, repeatedly. So, in that last sentence, here, you're like, well, if you're going to program that two out of three vote in C sharp or in JavaScript, then you need to follow the requirements. Now, in a lot of cases, your equipment vendor did write that function block, the underlying code for that function block in a full variability language.

And if they did that, they probably followed IEC 61508. They probably got their function block certified as part of their overall equipment certification process. So that kind of, if you roll your own function block diagrams, kind of hanging out there, but I don't even think, I can't name an example of any equipment vendor that would let you write a function block diagram in a full variability language. Usually they just let you create a more complex function block diagram sheet with the basic or primitive function block diagram functionality.

Okay, so all of that was clause 12.2.3. Let's move on to clause 12.2.4.

## Clause 12.2.4: Mixing Safety and Non-Safety Functions

Again, this one contains a lot of words, but it is only one sentence. So, I'm probably gonna break this sentence up in terms of discussion when I hit the commas that show up. So, there's gonna be four pieces of this sentence that I'll kind of discuss separately from each other. All right. So clause 12.2.4 states: where the application program of the SIS is to implement both safety and non-safety functions.

All right, so now we're kind of already, that's we hit the first comma, and we're saying that I'm writing an application program and this application program does stuff that's part of a SIF, but it also does stuff that is not part of a SIF. So I might wire my limit switches on my shutoff valves back into the safety PLC, and I might generate an alarm or turn on a light if the valve doesn't go to the safe state when it's commanded. Well, that alarm is not part of the safety instrumented function. So that's just one example of non-safety functionality being wired into safe into a safety PLC.

Alright, so I've got code that is safety related, I've got code that is not safety related. Okay, continuing on with the clause. Then, all of the application program shall be treated as part of the SIS and shall comply with this standard. And in addition, well, before I get to what's in addition. Any code that you generate in the safety PLC lives in the safety PLC, which kind of de facto makes it safety critical because it is in the safety PLC.

That means anytime you want to edit it, you're going to need to pull a management of change ticket to do your authorizations, to do your approvals, to do your risk assessment of changes. You can't just go, oh, well, the change I want to make isn't related to safety, so I'm going to go do it. Changing code in the safety PLC is going to need to have a one-to-one correspondence with management of change tickets. You're going to need to want them authorized and risk analyzed regardless of what you're doing in the safety PLC.

All right, so that's just one aspect of treating it as part of the SIS. So now, in addition to treating all the code as though it's part of the SIS, it shall be shown through assessment and test that the non-safety functions cannot interfere with the safety functions. Assessment and test. What do we mean? So I've got code that's going to take my limit switch input and it's going to compare my limit switch input against the safety PLC's command of where that valve should be.

And if there's a deviation between what is commanded and what is the actual position of the valve, after some sort of time delay, then I'm going to want to enunciate alarm. Now, all of that code: so there's a comparison block, there is a timer block, and there's an output to a non-safety critical alarm. All of that code, you need to show that any failure in that code will not cause any of my safety instrumented functions to fail. So that would mean you need to run some sort of assessment to fail that logic, if you will.

So kind of what if I did instead of an AND gate, an OR gate, when I'm determining whether or not I have a mismatch, and let's say my time delay was beyond the process safety time. Okay, none of those should actually impact the SIS functionality. So assessment and/or testing. Oh, wait a minute, let me double-check on that. no, no, no. Assessment and testing. Assessment and testing to make sure that that functionality, the safety functionality, is not impacted by. non-safety functionality.

A great thing to remember on this is it makes a whole lot of sense to write your non-safety code on separate function block diagram sheets, keeping things separate to the eye and kind of in separate containers, even in memory as the program is running. That way, it's a lot easier to kind of demonstrate that, well, if I just kind of turn all this code off, it's not going to impact any of the functioning code that is actually executing the SIS.

## Clause 12.2.5: Safe State and Power Loss Requirements

Okay, let us continue on for just a little bit longer, we'll go ahead and run through clause 12.2.5. Probably wrap it up for the day so, that we can do the balance of clause 12.2 in the next installment. All right, so last clause I want to talk about today is 12.2.5, which also comes with two informative notes. Okay, the clause itself is one of those run-on sentences with all kinds of commas in it. So I'll kind of be stopping halfway through as I go through this discussion of this clause.

So 12.2.5 states: the application program shall be designed in such a way as to ensure that once the SIS has placed the process in a safe state, the process remains in the safe state, including under loss of power conditions and on power restoration, until a reset has been initiated unless otherwise directed by the SRS. Okay, so right out of the gate, we are unnecessarily repeating work here. This sounds very familiar, does it not? We talked about this in clause 11.2. Let's go see exactly what we said in 11.2 related to the hardware.

So in clause 11.2 related to the hardware, let's see if I can find it. I think, is it four? You know, it might not. Oh, there it is. It's clause 11.2.7 stated: the SIS shall be designed in such a way that once it has placed the process in a safe state, the process shall remain in the safe state until a reset has been initiated, unless otherwise directed by the SRS. So, my question to you is: how can you program the SIS to remain in the safe state if you didn't write the program such that it would do that?

Okay, so that clause 12.2.5 is already 100% contained in clause 11.2.7. It's just, well, I'm gonna promise not to go on a soapbox about how all this crap happened in the first place in the overstatement of the requirements. But basically, clause 12.2.5 is just a portion of the already existing clause 11.2.7. It basically reiterates that when you put something into the safe state, it needs to stay in the safe state until you reset it. And you're going to need to write the software. If it's a software-based logic solver, you're going to need to write the software to do that. No kidding.

I don't know how you could read clause 1127 and not think that, oh, this just applies to the hardware, it doesn't apply to the software. Of course, it has to apply to the software. So, 1225, right out of the gate, didn't need to repeat this. It was true. I mean, if it's true in clause 1127, it necessarily is going to be true here. Otherwise, if it's not true for software, it's not true for 1127. But I digress.

Now, there are some interesting additional statements and clauses in here that aren't in 1127. So it, and basically, it talks about loss of power conditions and under and power restoration. Now, this is kind of interesting. So, if your SIS logic solver loses power, everything is going to go to the safe state if you have an energized trip plant. If you have, or I'm sorry, if you have a de-energized trip plant, got to be very careful with that. So, if you're de-energized to trip, you lose power to your logic solver. That should cause all of your outputs to go to their safe state.

Which snow power. If you're energized to trip, it's a little bit more complicated than that. Did your logic solver power and your field power go out? Can your output devices hold a certain state even though they lost communication with the logic solver, it can get really complicated. But generally, lose power to the SIS logic solver, you're going to go to the safe state.

## Power Restoration, Reset Behavior, and Clause Notes

Now, when you power back up, this is kind of an interesting thought process. Most of the time when you power down your PLC and you power it back up, your plant is shut down. Now, with a safety PLC, if you shut the if you put the PLC into its safe state, I'm having a hard time working through my brain how the plant can continue to run after I put everything to the safe state because my logic solver lost power.

But basically, what this statement is kind of saying, and it is a little bit of an additional thing that would go toward software programming is if you're coming up cold, cold reboot, maybe even a warm reboot, but if you shut down your plant when you're restarting your PLC, everything should be in the tripped state, which means that if everything is in the tripped state to begin with, then when you power up, all of your safety-critical, all of your SIS logic solvers should be in their safe state, and they will not go into the normal operating position until you do that manual reset.

So, basically, the only additional information in this clause that is useful is that you need to remember to configure your PLC, and it's usually a configuration thing that when you're booting up from a black plant, so power' outs, all the lights are off, is where that terminology comes from. Then everything should be in the safe state. And when you do your power up, you should not be automatically resetting anything. You should be putting, you know, powering everything up, but all the final elements are in their safe state until you do that manual reset.

Now, just like clause 1127, 12.2.5 has that last little bit that says unless otherwise directed by the SRS. So you can write your logic any way you want if you have a good reason to do so. So, if you wanted to do an automatic reset, and we talked, go back to the clause 1127 discussion a few weeks back. There are some reasons that you might want to automatically reset a safety instrument and function. It's fine, but you need to explain why you need to do the automatic reset and explain how to do the automatic reset in your safety requirement specifications.

Now, before I leave this little topic, there are two notes on clause 11 to 5. Note one states: if the SIF does not have a reset, then there can be a documented engineering argument as to why it is acceptable to reinstate the process without requiring the safe delay a reset would impose. Okay, wow, that note is what I just talked about. Go back, if you don't remember, go back to the webinar where we talked about clause 1127. I give a concrete example of why you would want to do an automatic reset. It's not very common, but it does happen.

Basically, if you leave something in the safe state for long enough, it becomes dangerous is Is what that what you're gonna what you're going to hear when you go back to that webinar. So, also, what Note One is saying here is that not only do you want to spec it out, but you might want to explain why you're choosing to do that, lest someone decide that your decision was bad because you didn't, because they don't know why. All right, the last item is note two. And guess what? Note two says, I love this. I love it. Note 2 says, more information can be found in 1127. No kidding.

There was no reason for this clause to exist separate from 1127, other than, well, let's just say there's some people in the 61511 committee at one point in time who basically felt that software needed to be its own complete separate thing. And more and more, as the years and days roll on, we're kind of really wanting to push those two things back together again. The software and the hardware really are inseparable, and that's kind of my uh me preaching on my soapbox here for what the best practices are.

## Episode Wrap-Up and Vertigo Software Overview

Alright, so that's clause 12.2.5. There's still a lot more to do in clause 12.2. So next time we're going to do clause 12.2.6 through clause 12.2.9. Probably not going to get to 12.3 in the next episode. Make these things a little bit more manageable chunks of your time. So we will do the balance of clause 12.2, the general requirements for application software development.

Next time, see you then. 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.