The latest episode (S1E54) of the Kenexis Functional Safety Podcast is now available

“`html “` # Kenexis Functional Safety Podcast — Season 1, Episode 54: IEC 61511, Clause 12.5 and 12.6 (Application Program Testing and Tools) — ## Introduction and Disclaimer Testing of your safety instrumented systems is one of the most important things that you will do, and that includes your software. 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. ## Episode Overview: Clause 12.5 and 12.6 All right. Today is the day where we are going to wrap up the software section. And honestly, I’m surprised at how long I went in the software section. There are a lot of requirements, but not nearly as much as the rest of the standard. And, you know, I have tended to always give a little bit of, shall we say, lack of attention to the software side of the fence, but it is really important because software development does result in a lot of failures. Of course, the reason is generally that the specification for what the software is supposed to do is incorrect, as opposed to the software itself being incorrect. Okay, we are going into the back end of the clause, which clause 12 is where we’ve been for a few weeks now, and we’re going to be looking today at clause 12.5 and 12.6. Now, clause 12.5 is requirements for application program verification, review, and testing. Excuse me. And then clause number 12.6 is going to be requirements for application program methodology testing or program methodology and tools. Let me say that one more time. Requirements for application program methodology and tools. So we’re going to get through those today. There are a lot of bullet points in these clauses. So, even though we’re talking about a page of text, there’s a lot of concepts that we’re going to need to cover. ## AI-Assisted Software Testing Trends And one of the ones that I’ve been giving a lot of thought to recently is testing. How does testing get done? What portions of a safety instrumented function get tested in each test. What types of tests are being performed? And honestly, the driver for a lot of my thinking on this is my personal and our company’s extended use of artificial intelligence tools to do work. And if you’re looking at a codex work, a ChatGPT work, or a Claude co-work, which is the one that I spend most of my time in, Claude Code and Claude Cowork. You’ll see that what the tools do in a kind of a software generation mode is that they’ll write a spec for what the software is supposed to do. They’ll write a plan for what the software is supposed to do. And then they’ll write a plan for testing the software to make sure that it works in accordance with the spec, and they will automate that testing through the use of scripts. And automating testing through the use of scripts is something that is really underutilized today. And I expect it’s an area where we’re going to see a lot of growth in activity because automated tests are actually going to do a lot better than humans because machines, the computers don’t get bored, they don’t get lazy, they don’t skip things. And when you’re doing something monotonous like software testing, having some automation, it’s just better. And now, a lot of people get scared when I bring up those two infamous letters AI, but the AI isn’t what’s doing the testing. The AI simply wrote a script, it basically wrote some code, often in Python, that will deterministically actually execute the test. And that is code that you can check. So, now in the future, and even today, a lot of you are doing this today, you can use software from a company like ProLyTx to actually do some of this testing automation. And that testing automation is valuable because ultimately you know what the it for a given set of inputs to a safety instrument, its system, you know what the outputs should be. So you can automate that testing to the greatest degree possible. So, as we’re going over these requirements for clause 12.5. I’m probably going to be talking about thinking and mentioning the different ways that some of these tasks can be automated, and how we might even be looking at some tools to help us automatically generate, even automatically generate the testing scripts based on the contents of an SRS, especially if that SRS is in a well-defined relational data structure like, oh, I don’t know, Kenexis SIS. ## Kenexis SIS Rebrand and Automated Test Generation Oh, and it is officially Kenexis SIS. We’re going to phase out using the Vertigo application name because now it is August 4th when I am recording this. August 1st, Kenexis Kiss Next Generation went live so it is Kenexis SIS now so being able to basically automate the test procedures based on the contents of the SRS, and then even automate those test procedures to a great degree. Now, testing the application code is something that is highly automatable. But you know, if you look at the capabilities of something like ProLyTx software, they can actually go out to the field to some degree, so you can use your asset management system capabilities to manipulate the output of an SIS transmitter and even get feedback on the positions of final elements. But with this kind of automation, there’s still kind of the last mile of like even the connection of the transmitter to the process. That’s something that we’re going to always have a really hard time trying to automate that type of testing to a reasonable degree of coverage. So, you know, in the short term, though, I expect a lot more automation in testing and I expect a lot more automation in the the development of what those test plans are by simply reading out of an open, published, well-known structured data structure that contains your SRS, which is that’s Kenexis SIS. That’s what the software is there for. That’s the large advantage of the way we do things over the way the other guys do their work. ## Clause 12.5.1 and 12.5.2: Verification Planning and Review All right, so let’s start diving into the clause. 12.5 is requirements for application program verification, then parenthetically review and testing. Clause 12.5.1 states: verification planning shall be carried out in accordance with clause 7. So clause 7, if you go all the way back there, that’s the verification clause. So we need to verify that the program does what it does, and that verification needs to be thought through and planned out. Clause 7 is where, in this standard, we talk about verification activities. So, we need to make a plan for how we’re going to do our verification testing, review, and testing. Very good. 12.5.2 states: the application program, including its documentation. Shall be reviewed by a competent person not involved in the original development. So that’s kind of a rule with everything verification related. You cannot 100% rely on the person who wrote the code to identify problems that are caused by that code. So we’re going to want competency. We want competency in everything we do, and we want a little bit of independence. So don’t ask the verification to be done by the person who wrote the code. So somebody’s going to review the code and they’re going to review not just the application program but its associated documentation. So, specifications, build plans. notes what have you in the application program the approach is used for the review and the review results shall be documented. Okay, so a competent person needs to review the code and the documentation associated with the code. It doesn’t say that they can’t be helped by automation, that the automation can generate a first pass workflow. And the competent person may be using tools to execute that review. That would all be part of the planning. ## Clause 12.5.3: Scope of Verification and Unintended Functions Okay, clause 12.5.3, it specifically states, and 12.5.3 is the meat. It’s going to have 1, 2, 3, 4, 5, 6, 7, 8, 9 bullet points in addition to the stem, which the stem is a few sentences to begin with. So let’s dive deep. The application program, including its decomposition into modules, if appropriate, shall be reviewed or shall be verified to review, analyze, simulate, and testing techniques. So shall be verified through review, analysis, simulation, and testing techniques using written procedures and test specifications. That shall be carried out to confirm that the application program functions meet the SRS and that unintended functions are not executed. Okay, so I’m not even done with this sentence, but there’s a whole lot to unpack here. So we’re going to do review, analysis, simulation, and testing. And that simulation is necessarily requires tools. So we’re not leaving tools as part of this testing process out of the thinking process. It’s still very important. Um And ultimately, this review is going to verify that we met the SRS. And as with all good testing, we check to make sure that it does what it’s supposed to do, but we also look through plausible things that it might try to do that it’s not supposed to do and make sure that those things don’t happen. Okay, so make sure that it meets the SRS and doesn’t do things that it’s not expected to do, not supposed to do. Also, as part of that unintended functions, it says that you know you need to make sure that it and that no that there are no unintended side effects with respect to the SIF. So here is a little bit of blue sky thinking, a little bit of creativity, kind of trying to come up with a thought process, a skill, if you’re an AI aficionado that will go and generate scenarios of how might unintended functions happen, how might unintended side effects happen. Okay, all of that shall be addressed. So the following bullet items, and there are nine following bullet items that need to be addressed by this testing process that includes review, analysis, simulation, and testing. ## Bullets 1-3: Conformance, Coverage, and Data Range Testing Bullet point one: conformance to the application program design spec, the defined means and procedures and the requirements of safety validation and test planning. So basically, your test needs to conform to the design, which is the SRS. It needs to conform to the procedures that you wrote, that you developed for the testing, and the requirements for safety validation and test planning. So you need to do what you you said were going to do in terms of this testing process. Bullet point number two, the testing, the review needs to exercise all parts of the application program. Now, this again, when the standard is written, and this is something also that I’ve been giving a whole lot of thought to recently, the standard is written from the perspective that you start the SIS design from a blank sheet of paper. When you’re doing a change to an application program, you need to thoroughly test everything that was impacted by the change, but you are not necessarily required to test everything. Now, if you automate the testing process from beginning to end using software tools. It’s really no trouble to turn the machine on, go home, and come back the next morning and check the test results and have it test everything from beginning to end. One more reason that you’re going to want to look at automating Uh at least the testing of the software itself beginning to end. And this is also going to be greatly facilitated if you have a test bed in your laboratories in your offices where you can run on hardware that is similar to what’s in the field without actually having to use the field equipment, which is obviously, already in use if the plant is online and running. Okay, next bullet point: the testing needs to exercise a representative range of data conditions. So that’s the third um the third bullet point here. Once again, strong case for automating the testing because if you are manually doing the testing um you’re gonna be testing kind of the scope of the testing can only be what a human can hold in their mind at one time, which means you’re gonna limit the manipulation of data to what you’re actually looking at and what you’re testing. Whereas an automated testing system through scripts can basically load up all of the variables at the same time and manipulate variables in real time so much more comprehensive testing but you need to test a representative range of data conditions. Again, with automation, testing a whole bunch of different conditions to make sure that the results are always correct is a whole lot easier than having a human. So for instance, it’s very common to do a five-point calibration or a three-point calibration when you’re calibrating a transmitter manually. You know, some people even, you know, even a five-point calibration, you know, that’s time that expensive human beings are manipulating the equipment. Well, if you’re automating the process, well, I don’t know, I could do a 75-point calibration, and the code is just going to slam through it in milliseconds. So you’re definitely going to be able to exercise that range of conditions more thoroughly. ## Bullets 4-5: Failure Conditions and Timing Tests Okay, bullet point number four is you need to test for failure conditions, and then you get the parenthetical IE negative testing. So you’re going to need to, as part of your testing process, inject failures in and make sure that your system responds properly. So give it a A milliamp setting of zero and see what happens in the system. Make sure that it detects that measurement signals outside of the range and see that it does what it’s supposed to do, which may be different than what the response you would expect if it was at 4 milliamps instead of 0 milliamps. Bullet point number five is that you need to make sure that your testing will test the timing and sequence of execution. So many of your safety instrumented systems, keeping it simple, are just input, output with no sequencing and no timing related to it. If you are executing things in sequences, if you have timers, you need to make sure that those things actually work. And I know I’m starting to sound like a broken record here but automation of testing allows you to do things that you wouldn’t want humans to do. so let’s say I’ve got a 30-minute purge timer on a fired heater startup sequence. You can thoroughly test that with an automated system by letting the program, letting the test run overnight, letting it run for a couple days, whatever it needs to do, because it’s off by itself just executing code, and it’s going to print out the results when the tests are complete. Whereas, if I’ve got five people being paid a lot of money, having them sit and wait for a 30 minute, 60 minute, 90 minute timer to time out is wildly expensive and unproductive. So it’s something that you might not want to do with the human beings. And I’m not saying that human beings can be cut out of testing altogether. But there are things that the machines and deterministic systematic scripts can do better, faster, and cheaper, and you should probably leverage that. Okay, next item up is going to be bullet. I think we’re on bullet six. One, two, three, four, five, six. ## Bullets 6-9: Communications, Logic Solver, and Third-Party Integration Yes. You need to make sure during the software testing that the communications to and from the SIS are functional, that they work, that they work as intended. So, software testing, a test bed that will communicate signals among multiple different components is a very valuable thing there is a note to this bullet point which says note wherever feasible the communication overload condition can be verified and tested. So one of the failure modes of communications is that they get overloaded. There’s a lot of data that needs to go really fast. So, you know, putting stress testing and overloaded communication condition is something that you would also want to consider during your testing. It’s something that it is a lot more easy, maybe only reasonable to do when you automate that testing with some tools, bullet point number seven is that the testing needs to include integration of the offline application program with the logic solver hardware and the underlying PE. So PE programmable electronic, and that’s Logic Solver. So testing is best when the code is being executed on the logic solver hardware itself. So download the program into the logic solver and execute the test as the software is being run in the logic solver. Now, you might not want to always do that, especially in the early debugging stages when you’re just kind of doing first passes of things, maybe just leaving it in the maintenance and engineering interface is good there. Ultimately, we’re going to need to do a full factory acceptance test and site acceptance test. But the quicker you could get out into the logic solver running the code, the better, because your testing is going to be more comprehensive and it’s going to occur in the ultimate intended application environment. Bullet point number eight: the testing is going to want to include internal data flow checks to confirm that the logic solver is not just apparently working but working as expected. Data flow, so here is again another situation when you’re looking at a longer sequence of events, a longer set of calculations, your data might come in as a bit count, which needs to get translated into engineering units, which needs to be compared against a set point, which might trigger a flag. So your testing of each step along the way and making sure that an input triggers all the way out to its output with all steps in the middle. That data flow from step one to step two, from rung one to rung two, etc., is important in your testing processes. Alright, finally, bullet point number nine states: when possible, integration of the application, program, and third-party devices. So if your application program is talking to a third-party device, let’s say you want to talk directly from your SIS logic solver to a smart drive for a pump. You would like to be able to test that. You would even want to do that during software testing. Now, obviously, it’s essential during SAT, but even at this stage in the game, when you’re just testing the software by itself, making sure that the communication pathways are correct is very very helpful and it will save time during FAT it will definitely save time during validation or SAT okay so that’s clause 12.5.3. ## Clause 12.5.4: I/O Data Mapping Verification Let’s continue on To through the next clause, where in the next clause, it’s just one sentence, but it’s critical to the testing process because it’s an area where things, in my experience, a lot of problems occur during commissioning, which we’ll get to commissioning, we’ll get to field testing, we’ll get to SAT, it’s all coming up. So, right now, we haven’t installed the equipment in the field, but in clause 12.5.4, we state that the mapping of the I/O data to the application program, including the data type and range shall be verified. So at this stage in the game, we should know rack slot and channel of where IO points are landing. We should know whether they’re digital or they’re analog. If they’re analog, we should know what their ranges are: the zero, the span, the trip point. So that kind of configuration should be tested. And if you have the capability of testing the I/O cards as part of this testing process, it’s going to, you know, minimize the amount of failures that happen after things are installed in the field when things take a lot longer to rectify any anomalies or failures during this process. ## Clause 12.5.5: Impact Analysis for Test Modifications Okay, clause 12.5.5 has a stem and two pull two bullet points. And they are during testing, modifications to the application program shall be subject to an impact analysis in order to determine, and there are two bullet points. So, what is the STEM getting at? During testing modifications to the application program. So when you run your testing, it’s very common that you will run into a failure and you want to fix the failure that you found during the testing. Of course, you’re going to document that the failure occurred. And if you’re using an automatic testing tool, it will create that test result document for you. But that type of testing, so when you end up with that list of things that are wrong, you’re going to want to fix them. Before you fix them, do an impact analysis. So, before you just implement a change, you need to think through what else could this change impact? Am I changing something in the SRS? You gotta return back in the life cycle to the first place where that data or that thought process showed up and work it all the way through. So, just testing the code by itself or fixing the code by itself might not be enough, and you need to think through what you might mess up by making this change. So, impact analysis for all changes before you execute the change. Okay, so um That impact analysis is going to include two things. Those are the two bullet points. Bullet point number one states that you need to consider all application program parts that are impacted. So, all subroutines, all rungs of logic, all function block diagrams that are impacted by the change. You need to think that through as part of the impact analysis. And you need to think about what type of redesign. So, kind of going back in the life cycle and changing the design to match what you had to do because you’re testing evidence and error. And then re-verification activities. Now, I know I’m being repetitive, but it sounds like it would be nice to push a button and have a machine automatically redo the test for me from beginning to end after I make the change. But if you’re back in the old days and running this testing manually, then you’ll need to think about whether I need to run the entire test from beginning to end or just kind of retest small portions of it that have to do with the changes that I was specifically looking at. Okay, that was clause 12.5.5. ## Clause 12.5.6: Test Documentation Requirements The last subclause of 12.5 where we’re talking about testing is going to be clause 12.5.6 and clause 12.5.6 states that the results of application program testing shall be documented and shall include. So you need to document the results of your testing. Okay, to the degree you automate the testing, your tool can automate the generation of the test documentation, which saving time, saving money, better results. But okay, so the application program documentation needs to include, and we have a short bullet list of one, two, three, four, five, six, seven items. So, item number one: the testing and documentation, or the documentation shall include the versions of the application program and its supporting documentation. So, what’s the revision of the code? What’s the revision of the SRS? Bullet point number two. What are you need to document the versions of the supporting software and test tools? So, supporting software might be something like the maintenance and engineering interface and the test tools. Oh, that’s going to be a variety of things, but it might be automatic software, like software from ProLyTx, where you would actually write your test procedure and have that tool automatically execute the procedure. Bullet point number three: the names of the persons who perform the tests and reviews and the dates. So, document who is doing the testing as part of the documentation. Pretty straightforward there. Bullet point number four: descriptions of the tests, reviews, and dates performed. So, what was the test? Now, granted, you have a procedure that is executing, so you would have a procedure that defines the testing. In a lot of cases, that’s perfectly fine. But again, with our automatic tools, not very difficult to generate a kind of a play-by-play explanation of what test was executed and what the result was. Bullet point number five: one, two, three, four, five is the test results. Seems pretty obvious, but don’t just don’t document by exception. So document successful tests in addition to failed tests. A test result set that only includes what failed, suboptimal, and basically the standard says no good. Bullet point number six: you need to document whether the objective and criteria of the tests have been met. Is that any different than the test results? I would kind of argue no, it’s not. What were the results of the test? Did the test pass? Did I meet the objectives? Did I meet the criteria? Very good. And finally, the last bullet point says that you need to document if there was a failure during the test, the reasons why the failure occurred, an analysis of the failure, and records of its correction and retest requirements. So, what failed? So, it don’t do the undocumented fix. How many times do I have to say this. If something fails, document that it failed, what failed, why it failed, what you need to do to fix it, and then document that you retested it and that it worked after the retest. And you might want to have that retesting be a completely separate work order. It depends on where in the life cycle you’re at here. We’re in clause 12, so we’re still, you know, kind of just looking at the software by itself. So you might do that as part of the workflow, but always document failures. It’s going to help you make things better in the future. All right. So that’s all for clause 12.5. ## Clause 12.6: Application Program Methodology and Tools We’ve been going at it for a while, but 12.6 is only a quarter page, and I want to get to the end of programming so that we could start next week fresh. So 12.6 is the clause title: is requirements for application program methodology and tools. It begins with clause 12.6.1, which states the application program development shall comply with the constraints in the applicable safety manuals. I was expecting it to talk about the SRS, but no, when your developing your program, you must follow the safety manual of the logic solver of the maintenance and engineering interface that you are implementing your software onto. Because some software maintenance and engineering interfaces, some logic solvers have weird quirks that allow them to achieve their safety integrity levels. And those quirks might not be obvious. And if you don’t comply with those quirks, you’re not going to be hitting your SIL targets. Okay, there is a note for this clause, a subclause 12.6.1, and that note is: the safety manuals can be reviewed and if required for a specific application, additional procedures for and or constraints on the use of methodologies and tools can be implemented. So, what the notes are telling you is what you read in the safety manual might make you change your test plan because the vendor is warning you about something that could go wrong that you need to test for that might not have been obvious to the casual programmer or user of the device. Alright, last subclause in clause 12 is 1262. 1262 is a stem and bullet points. The stem reads: methods, techniques, and tools shall be selected and applied for each life cycle phase, so as to, and then there are going to be five bullet points. So, methods, techniques, and tools: what do we need methods, techniques, and tools for in the application program development? So, bullet point one says, I need methods, techniques, and tools to minimize the risk of introducing faults into the application program. Huh. We’re always, always, always worried about systematic failures, human failures. We always, always, always want to minimize the probability that human beings are going to introduce failures into the methods, techniques, and tools. I’m sorry, into the application program. We’re going to use methods, techniques, and tools to prevent it. So methods are going to include things like standards, standard libraries, standard subroutines, programming tools, programming preferences, variable naming conventions. All of these are intended to minimize human failures. Minima, and also a lot of the tools are going to be provided to you by your equipment vendor. So, your equipment vendor should have a lot of automation inside their tools that are going to prevent you from using a variable name that doesn’t exist, for instance, by giving you drop-downs of variables that have been defined, preventing you from trying to wire an analog output into a digital output in terms of mismatched variables. So, a lot of that is going to be provided at the vendor side of the fence. Okay, second bullet point: we need methods, techniques, and tools to reveal and remove faults that already exist in the application program. Interesting stuff. So, some of the uh uh advanced functionality that we at Kenexis are looking at are tools that leverage large language models and large language skills to do reviews. So inside Kenexis SRS, we already know what the application program logic is supposed to do to a great degree. We can write some tools that will basically look at our SRS and look at the code, and well, in the language of programming, we can diff and reconcile. So we can look at the application program and determine if the application program doesn’t match what the SRS says, and just put up some warning flags to let the programmer know: hey, I don’t think what you did matches up with what the SRS said. So, those are some examples of some tools Tools that might be possible. But then there are also methods and techniques for manual back checks on these types of things. Bullet point number three: we want methods, techniques, and tools to ensure as far as practicable that any faults in the program will not lead to unacceptable results this bullet point really really really rubs me the wrong way. The idea that you’re gonna know that there’s a fault in your program, but you’re not gonna fix it, you’re just gonna make sure that it doesn’t mess anything else up is ludicrous to me, but well, it is what it is. That’s what the standard says. So if something’s broken and you don’t plan on fixing it, make sure that it’s not going to result in unsafe, unacceptable results. Bullet point number four: we need methods, techniques, and tools to enhance the means of managing modifications of the application throughout the lifetime of the SIS, change tracking tools, GitHub for your SIS. We want to pull code, we want to push code, we want to be able to diff code. Those tools are going to be available to you from your maintenance and engineering interface software vendor, and it is going to be supplemented with your own internal standards and processes for managing your code, item number five, and the last bullet point here: we want methods, techniques, and tools that will provide evidence that the application program has the required quality. And why don’t I end with the drum I’ve been beating for the entire session here is that man, it’s kind of nice to have automated tools like you could get from ProLyTx that are going to run this test automatically for you and generate a report and generate an assessment of the report to make sure that you have the required quality with traceability all the way back to the SRS, which is, if you know what you’re doing, probably going to be contained in the Kenexis SIS software and ported out to other tools as required to generate these procedures. ## Episode Wrap-Up and Next Week Preview Okay, so that’s what I have for you here in this next episode of, or this current. I guess we’re about ready to put it in the can episode where we closed out the software development section of the 61511 standard by talking through clause 12, this episode was clause 12, 5, and 12, 6, that talked about testing and it talked about methodology and tools. So, at this point in time, we’ve told you what you need to do to write good code. We’ve told you what you need to do to test that code to make sure that it works before we go on into the next step. So, what is the next step? Well, obviously, it’s going to be clause 13. And believe it or not, I have some customers that never do anything in clause 13. Well, they do, but it’s not really, is it a factory acceptance test if it doesn’t happen in the factory? There’s some philosophy for you to think through. So, I do have customers that do not do factory acceptance testing because they stick build everything. So, stick build factory, what’s the purpose? All that. We’re going to get into it next week. I doubt I will be able to get that. You know what? I might be able to get all the way through FAT in one episode. It is about a page and a half. So we’ll talk through FAT, we’ll do the standards requirements, but there’s going to be a whole lot of discussion outside the standards requirements, a whole lot of war stories, a whole lot of discussion of options of the way different people do different things. Some people stick builds, some people have the vendors build. Some people have systems integrators build. Some people buy stuff that other people gave to them. Boy, that’s always a fun one. Anyway, clause 13 factory acceptance test is up on deck. We will talk about it next week. See you then. ## Vertigo Product Advertisement 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.