Functional Safety Podcast: latest episode (S1E55) is now available

“`html “` # Kenexis Functional Safety Podcast — Season 1, Episode 55: IEC 61511, Clause 13 (Factory Acceptance Testing) — ## Introduction and Disclaimer Once everything has been built, now we need to test it to make sure that it works, and that is often going to start at the factory. 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. All right, we are now done with the design. ## Clause 13 Scope: Purpose of Factory Acceptance Testing And actually, we’re done with building at least the SIS logic solver. Now, what do I mean by that? Well, in the standard, we’re in clause 13. So we’ve done all of our design. We’ve done all of our programming. Now we need to go build it, and that’s technically part of clauses 11-12: the actual selection of equipment, configuration of equipment, putting that packaging that equipment up and putting it into a package that’s going to get delivered to the site. And specifically, we’re really interested here in the SIS logic solver. Now, this clause 13, I have a little bit of heartburn about. So, the title of clause 13 is Factory Acceptance Test. And it is a very common thing for some subsystems of the SIS, but not others. So, for instance, your SIS might include a pressure transmitter. You’re not going to do a factory acceptance test for the pressure transmitter. You’re just going to buy one off the shelf at your local distributor or have the vendor send it to you. You’re not going to fly to the facility, test it to make sure that it works. So, factory acceptance test is basically going to be the domain of the SIS logic solver because there’s a lot of customization, shall we say. It is an engineered product, and you want the engineering that they do specifically for you. You need to make sure that that was done properly, and you want to do that before you actually physically receive the piece of equipment. You don’t want to pay for it, if it’s not what you wanted, which is why the factory acceptance clause is usually put in place. So, the typical workflow is you’re going to write your safety requirement specifications, you’re going to do this in sufficient detail so that the equipment vendor can actually do their work. And now on FAT, I’m going to say this right now, and you just need to remember it for the duration. I’m talking about the SIS logic solver, and it will usually be a PES programmable electronic system logic solver. A PLC programmable logic controller is typically what we’re talking about here. So that’s the scope. I’m not talking about the field equipment. I’m not talking about what’s going on at site because obviously it’s not going on at site, it’s going on in the factory. So typically we’re going to hand over our SRS to the equipment vendor or sometimes to a systems integrator and all of what’s going on in the factory acceptance testing isn’t actually occurring in the factory where the logic solver was built, it’s occurring in the shop where the system integrator assembles. So it might be at the factory, it might be at a panel shop, but it is not at your facility. And I’ll come back to that because sometimes it is at your facility. So, the systems integrator or the equipment vendor has your documentation package, that SRS that they are going to use to actually build this thing, build, configure, make sure that the system works. Now they go and they build it. ## Building and Assembling the Logic Solver So, what does that mean? They’re going to collect all of the components that the Logic Solver subsystem is made of. Now, this is going to include the CPU, but it’s going to include I.O. cards. It’s also going to include power supplies, power conditioning. It’s going to include terminal strips. It’s going to include back planes and cabinets. There’s a whole raft of things that need to get assembled and put together for that final SIS logic solver system that is going to get installed at your site. So they, the equipment vendor, are going to start with your SRS and then they’re going to build out probably other more detailed drawings, things like wiring lists, cabinet layout diagrams, I.O. sheets that map the rack slot and channel of where the I.O. points are going to land, etc. They’re also going to do the programming of the SIS. All of this, the SRS is a starting point, but then there’s going to be intermediate detailed design documents that were created based on that. Now, once all of their effort is done, they’ve got the cabinet built, they have the program written, they upload the program into the logic solver theoretically. You should be able to just drop this in at your plant and go. But we understand that humans make errors. Things are misinterpreted. Things don’t go the way we expect them to. So before we take ownership as the operating company, before we take ownership of this piece of equipment, we want to do a preliminary test to make sure that small scope of equipment, not the entire SIS, just the SIS logic solver, is in conformance with our expectations, and those expectations were documented in the safety requirement specification. So, all of that is the reason, all of that is the purpose for factory acceptance testing. ## FAT Location: Factory, Panel Shop, or Stick-Build And again, it might be literally at the factory if you have the equipment vendor do it, and they’re an equipment vendor with a very large facility where they can actually do this at the factory. It might be at a systems integrator’s panel shop where they do all of the assembly and programming work. The key is a lot of customers, most customers want to confirm that all of the work that they’ve subcontracted, all the systems integration work that they’ve subcontracted whether they subcontracted it to a dedicated systems integrator or to the equipment vendor was done properly and this is this is a financial thing. It’s the test drive of the car before you bring it home. You don’t want to actually pay for it until you know that it is exactly what you want and works the way that you want. Now, I do have some customers that the terminology I will use is stick build. Stick build means I’m going to actually assemble everything right there in situ on site in the place where it will live in eternity. So instead of building my panel in the panel shop, I’m going to build my panel in the marshalling room at the oil refinery so once it’s built it never actually moves. I have many customers who stick build things. So while the concept of a factory acceptance test doesn’t actually apply to something that is stick built, you still need to do those activities. The people doing the activities, the reason for doing the activities may have changed, but all the activities need to basically occur, which is a pre-test of just the SIS, I’m sorry, SIS logic solver portion of the SIS prior to the The subsequent stages in the life cycle. So, after the FAT is done, whether it’s factory-built or stick-built, only after that do you start connecting field equipment and do the subsequent commissioning and site acceptance test, or in the language of the standard you would call that, the validation, which is coming up a couple clauses from now. I believe it’s clause 15, which we will get to in a few weeks from now. Okay, so all of the requirements for the Um FAT are going to be listed out in clause 13. And again, clause 13’s title is factory acceptance test FAT. Now, um we have a clause, so let’s kind of go ahead and hit it and hit the clauses, see how far we get today. I was thinking we were gonna get all the way through, but it is only like a little bit more than a page of requirements. But there are a lot of notes, there are a lot of bullet points. So maybe we might only get halfway through this bad boy today. We’ll take a look. ## Clause 13.1: Objective and Notes Alright, so we’ll start with clause 13.1, which is the objective. Now, the objective is always a weirdo clause because objectives, by their very nature, are informative. They’re telling you goals. They’re not technically setting requirements. So 13.1, kind of a little bit of a throwaway because it’s informative, just kind of letting you know in the big picture, what we’re trying to achieve with the requirements, and the requirements start in clause 13.2. So, the objective, clause 13.1 is the objective of clause 13 is to test the devices of the SIS to ensure that the requirements defined in the SRS are met. This is interesting, it doesn’t say the SIS logic solver, it says the devices. Now, there may be other things that you want to do a factory acceptance test on. Maybe you have a very expensive pump system as part of your plant that has its own You know, variable frequency drive controller. So you might actually do an FAT on that piece of equipment. It’s not limited to just the SIS logic solver. That’s the way that the objective is written. But 99 times out of 100, when we say FAT, the scope that we’re talking about is limited to specifically just the SIS logic solver. Okay, that objective, for some reason, has three notes associated with it. So let’s go talk about the notes a little bit. Note one says by testing the logic solver associated software and hardware prior to installation, errors can be readily identified and corrected. So, note one, we immediately drop back into the what we actually think is going to happen, which is the SIS logic solvers, most of the case. And we’re driving here with kind of a purpose of why you do that. So we’re going to identify any errors early before it’s shipped before we wire things up when it’s more inexpensive to do those modifications than after the validation testing when everything’s been wired up. so we want to catch errors early and correct them when it is most cost cost efficient to do so. Note two states the FAT is sometimes referred to as an integration test or can be part of the validation. Okay. Integration test. Honestly, I’ve never heard anyone call it an integration test, but that’s really telling you what we’re trying to achieve. It is an integration. The equipment vendor, even from the equipment vendor perspective, they have the CPU, the power supply, the communication card, the rack, the input cards, the output cards. Each one of those is an individual product. So, what we’re testing here is how the products were assembled or integrated to make sure it achieves the overall purpose, and that’s something that’s custom for you know every individual application. All right, note three under objectives: testing of field elements together with the logic solver can be recommended when there needs to be a high confidence in operation prior to field installation. For example, subsea applications. So again, before we take the device, before we pay for the device and take ownership of the device, especially if the installation, you know, after installation, it’s hard to make changes, even when you’re on shore. But if you’re offshore, it’s much harder to make changes. If you’re offshore and underwater, it’s even harder to make changes. So, we want to make sure that everything works properly before it’s installed. And the more remote the installation, the more important this becomes. Okay, so all that falls under clause 13.1, which is the objective. ## Clause 13.2: The Requirements Typo Then, starting at clause 13.2, we are actually going to have the requirements. Now, clause 13.2 is titled Recommendations, which I find to be a very weird name. In fact, it is probably incorrect. Because when you go through the rest of the standard, the point one clause is always the objective, and the point two clause is always the requirement. So we have a long-running, very blatant typo in that 13.2 says recommendations, but it very obviously should have said requirements. So we’re going to proceed on with clause 13.2 under the assumption that the correct thing for it to have said would have been requirements. So let’s go ahead and nail that down as requirements and go through them. The requirements section is going to contain one, two, three, four, five, six, seven subclauses. So 13.2.1 through 13.2.7 that describe the requirements. What are the things that you need to do? ## Clause 13.2.1: FAT Planning Requirement All right, we’ll start with clause 13.2.1, which states the need for a FAT shall be specified during the safety planning for a project. So, this clause right out of the gate concedes that you might not actually have to do an FAT, especially you guys that are stick-building things, you’re definitely not going to call it an FAT. You might roll these requirements together with the SAT or the site acceptance testing, the validation task, but ultimately, don’t turn this off even if you’re a stick builder because you’re still going to need to meet these requirements. It’s just that you might be meeting these requirements in a different location. Okay, now the need for FAT to be specified during safety planning for a project, you know, we’re putting together a project plan uh and when you put the together the project plan obviously um you would want to do that uh to include the fAT if you need to do it. A lot of times, this type of planning is defined, and we talked about this when we were back in clause five. It’s defined during the functional safety planning for the site as a whole because generally you’re going to do your projects the same way all the time and not do individual plans for individual projects. I digress a little bit. You do need to do some planning. Now, how important is the planning? Well, there are four notes that talk about the planning that you need to do. So let’s go ahead and hit these four notes one at a time for the need to do an FAT needs to be in the safety planning. Note one states: close cooperation between the logic solver supplier and design contractor can be required in order to develop the integration tests. So it’s warning you, and this is very common to outsource not not just to outsource this work but to outsource it to multiple different groups that need to communicate with each other. Okay, that makes things additionally complicated. So, how does this typically flow? So, the most common approach, especially for a big company, would be to have an equipment vendor that is on their uh approved vendor list. So let’s just assume that that vendor is only supplying the equipment. You’re going to give them a purchase order that contains a bill of materials for all the I/O cards and input cards and power supplies, blah blah blah, etc. Okay, so you have the equipment vendor. Now, there may be an engineering company who’s building the plant as a whole that is responsible for the construction of a plant. Now, that engineering company might do the work of assembly and configuration and programming. They might outsource that to a systems integrator, which is a dedicated firm who is just going to assemble the components and do the programming. So there could be this gigantic cascade of the equipment vendor needs has input, the engineering company has input, the systems integrator has input, and obviously you, the end customer, if you are the end customer, is also going to have input into this process. So, coordinating between all those different groups is something that is important and needs to be thought through. Okay, Um let’s carry on to note two, which states: the activities follow the design and development phases and proceed installation and commissioning. So, okay, thanks. Thank you for telling me what I already know. That’s a quote from Wall Street, the movie. Anyway, I digress. Yeah, obviously, you can’t test something until after it’s been built. But the more important of this is you want to do all this testing to make sure that it was integrated properly before you install it, before you commission it, before you wire it up, especially if you’re going to commission and wire it up a mile underwater. Note three. Note three states the activities are applicable to the SIS subsystems with or without programmable electronics. And now you’re going to need to use a little bit, ever so slight, tiny amount of judgment as to whether or not the SIS system or component deserves a factory acceptance test. I’m not going to do a factory acceptance test for a pressure transmitter, but I will do one for an SIS logic solver because, well, it actually needs to be integrated. As a matter of fact, that’s probably a good litmus test to determine whether or not you need an FAT. Is it an off-the-shelf component or is it an engineered system where multiple off-the-shelf components need to be connected together and assembled? That’s kind of a flag that says, Yeah, I probably want to do an FAT before I bring it on site. The next note states the activities or applications I already said that. And the back end of note three is this is true whether it is programmable or not. So if I have a giant panel that contains a couple thousand relays, I probably want to do an FAT on that before receiving it just the same as if it were a PLC. All right, note four. Note four states: it is usual for the FAT to take place in a factory environment prior to installation and commissioning in the plant. So wherever the cabinet was assembled is where you’re going to want to do the testing before you move it because it is at that location of assembly where it is easiest to do modifications. All right, let’s keep on clicking through here. ## Clause 13.2.2: Planning List and Test Types The next item is, so that’s all with clause 13.2.1. Now we’re going to move on to clause 13.2.2, which has a boatload of bullet points. The stem is short. The stem says, planning for a FAT shall specify the following. So clause 13.2.2 is going to contain a large bullet list of all of the things, the points that need to be considered when you’re planning your FAT. So, huh, that probably should tell you that you need to have a plan for how you execute the FAT. This plan probably needs to be written. Now, whether you write it on paper or a markdown file or database entries, Word document, what have you, there are a lot of ways to create the document, but a document for how you’re going to be doing the testing needs to exist. And as you’re putting that together, there are bullet points you need to consider. There are one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, twelve, count on twelve bullet points related to the planning and the first bullet point has four notes, the last bullet point has one note. They’re five notes all together, so let’s hit them. All right, first bullet point is the longest one. So FAT planning shall specify the types of tests to be performed including black box system functionality tests. Now realistically the first bullet point is actually let me count them out. One, two, three, four, five, six, seven, eight, nine ten bullet points in and of itself that are separated by semicolons so um let’s let’s let’s go ahead and hit each one of these things one at a time. So you need to specify types of tests to be performed. And what are the things that need to be tested? What are these types of tests? So, the first one they talk about is black box system functionality tests. What is an example of a black box? Well, it’s another system, a collection of equipment that is part of the safety instrumented system. So let me give you the most common example of a black box in an SIS. That would be a motor starter. A motor starter for a pump is a, or a pump or a compressor, is in and of itself a complex collection of equipment. There are relays, there are latching mechanisms, there are current monitor relays, there are alarms, a motor starter is a complex collection of equipment. But we are not going to test every nook and cranny inside that during our SIS testing. So we’re going to send a signal to the motor starter and make sure that it does the right thing when it receives the signal and then it does the right thing when the signal is removed, without delving into the details. Another black box system that might sit in the middle of your SIS is that there might be another PLC. So let’s say I have a PLC that controls a compressor and an SIS in addition to that. So I need to think about how that compressor PLC fits into the system and make sure that that black box responds properly to signal on, signal off from the SIS. So black box functionality testing. Performance tests is the next item. So, just does the system perform as it’s supposed to and to the degrees that it’s supposed to. So, degrees would be things like timing, how quick things respond, and so on. Next item is you need to test the internal checks. So you need to check that your internal diagnostics are going to fire properly. That’s part of this factory acceptance testing is to exercise the internal diagnostics. And then we have another typo in the FAT section because it says performance tests, internal checks, performance tests. So we have another repeated words typo. So clause 13, man, typo is all over the place. Sorry about it. I’ll make sure that when the next version is released, those typos get cleaned up. Next one is environmental tests. So exposing a system to radio frequency interference, electromagnetic interference, and checking the response is something that should be part of the FAT. Interface testing. This is very interesting because most of your safety instrumented systems are going to talk to other systems. At a minimum, they’re going to talk to your BPCS logic solver to communicate information back and forth. You’re going to want to make sure during the FAT that all the equipment, all the systems, all the programming to do those communications is in place and functional. Next item up, testing in degraded or faulted conditions. So there’s going to be a lot of programming for error handling for when things fail, you need to test every combination and permutation of those failures. Gee, seems like we should have some sort of automated system to help us do this testing so, we can run all of these tests quickly and automatically document it. Hmm, check last week. ProLyTx. Okay, next item up is going to be testing for safe reaction in case of power failure, including restart after power restored. This is a big item. Don’t forget this testing. Power it off. Cut the power. See what happens. Cut one power supply. See what happens. Cut total power. See what happens. Then, when the system gets powered back on, does it power up to a known and safe state, or does it try to pick up where it left off and throw a whole bunch of field devices wide open. That type of testing of what happens when the power gets pulled and when it cold restarts is critical and we did specify we talked about in the safety requirement specification sections that you need to document what behavior we expect and now we’re testing to make sure that the behavior that we expect is the behavior that we actually receive. So that’s testing testing for safe reaction in power failure, including restart after power restored. I actually skipped one of the little items, which is called exception testing. So, again, in your testing, now this is kind of might be part and parcel of degraded and faulted conditions. I kind of mentally put them together in my head, but they are separated by semicolon, so they are separate thoughts in the standard. Exception testing: there are the things that commonly happen, but there are special unique cases or exceptions that you need to make sure are handled properly. And then one last item would be that you need to make sure that you have testing to ensure the application of the SIS maintenance and operating manuals. So, as you’re doing the FAT, have those safety manuals with you. Have those maintenance manuals with you and think about how you’re going to do your testing and make sure that your SIS has been designed to conform with the safety manual of from the vendor, but also it’s going to conform with the way that you’re going to need to do testing in the field. ## Clause 13.2.2: Test-Type Notes and Details Okay, so that all was simply the first bullet point. We have a ways to go, but before we can even get to the second bullet point, we’ve got four notes on the types of testing that you need to accomplish. So let’s hit number one. Note number one goes back to the first item, which is black box functionality testing. And note 1 states that black box functionality testing is a test design method that treats a system as a black box. So, it does not explicitly use knowledge of the internal structure. Go back to what I was talking about with a kind of like a motor starter. We don’t assume any knowledge of what’s going on inside the motor starter, we’re going to send it a signal and see how it responds. We’re going to remove that signal and see how it responds. It is a black box to us. We have no explicit knowledge of the internals of it as we’re doing our testing. Okay, the note’s not done yet. Next sentence in the note: black box test design is usually described as focusing on testing function requirements and yet one more paragraph here, or one more sentence. Synonyms for black box include behavioral, functional, opaque box, and closed box. I’ve never heard of of any those. The only one of those that I’ve ever heard is black box testing, but I digress. So that’s a little bit of a more discussion of what we mean by a black box. I think my examples nailed it down a little bit better than the note, but hey, that’s what happens when you could do a more elaborate freeform discussion than just putting something into a standard that 75 people need to agree with, and you need to get a design by committee. Okay, I digress. Note number two for bullet point number one states: performance tests determine whether the system meets timing, reliability and availability, integrity, safety targets, and constraints. Okay, so the testing needs to be comprehensive and think about everything, not just the cause and effect diagram. There are timing constraints, there are sequencing constraints. All of that needs to be considered as you’re going through this process, as you’re going through this workflow. Note number three: environmental tests. I’m telling you, before I get back to the note, EMC must have had a lobbyist in here. There are a bunch of failure modes, there are a bunch of environmental stressors, but EMC always gets documented in the list. Okay, back to the note. Environmental tests include EMC, life, and stress testing. Okay. Yeah. Test the environment to make sure the equipment is capable of operating in the environment in which it was stalled. No four internal data flow checks can be carried out to that so that another typo the SIS is processing input data and generating output response as specified. Well, I’m going to have to give that the no crap. No kidding. Thank you for telling me what I already know. Thank you for telling me what is patently obvious. Yes, you need to check the flow of data to make sure that whatever you input flows to the correct output. So if that wasn’t obvious to you. After reading note four, that should be pretty darn obvious. All right, let’s carry on and we’re gonna hit another bullet point. The next bullet point here on the list is going to be test cases, test description, and test data. So, when we’re putting together our plan, we need to define all of the test cases that we’re going to do. We might need to do multiple test cases for instance for different modes of operation. Most big continuous chemical plants only have one case. But if you’re running a batch plant, or even crazier, if you’re running something like a tolling facility where you’re going to, you know, do different, you’re gonna make different products in the same line. You’re gonna have multiple different test cases that you’re gonna need to go through for different products that you’re putting through that line. So, a test case for each product, a test cage case for each batch recipe of each product. Um, for each test case, you’re gonna have a test description. So, what are we doing with this test? And then test data. So, what are the inputs I am putting in, and what are the outputs that I expect to achieve? All of this needs to be part of your test plan. And gee, wouldn’t it be helpful if we can automate a lot of this stuff? What the test data is, the test description. Seems like something we could get automatically generated. Okay, next bullet point: we need in our planning to understand the dependencies on other systems and other interfaces. So, when we need to interface to a motor starter that might not be available during the FAT, we need to consider that. We might need to communicate information to the BPCS logic solver operator interface. So that might not be available during the FAT. We need to think about the dependencies and plan for them and make sure that we have tested them as much as we need to before we take ownership of the physical piece of equipment. Next item, which is going to be one, two, three, four. Bullet point number four: what is the test environment and what are the tools that we are going to need? So if I need to inject a 20 milliamp signal, I might need a tool that is capable of injecting a 20 milliamp signal. What are all of the tools that I’m going to need? They need to be enumerated, and where is this test actually going to be performed? The next item: bullet point number five, is: well, I need the logic solver, sensor, and final element configuration. Well, darn it, I should have had that all the way back in the SRS phase. But But that information needs to get carried over into the test planning. Next item: bullet point six: test criteria on which the completion of the test shall be judged. So I need to know what inputs I’m going to put into the machine and what outputs I expect to get out of it based on the inputs. Should be straightforward should totally make sense okay next item up is the procedures for corrective actions on failure of a test. So you need to think through if a failure occurs during the FAT, it doesn’t work as expected. We ran a test and the output is not what we expected, not what we wanted. How are we going to deal with that? Number one, you’re gonna document it, absolutely. But the next question is: am I going to fix it on the spot and rerun the test on the spot? Am I going to create a punch list and then run through the whole test? Give the systems integrator a day to fix it and come back and test all of the corrections all at one time. Think through how you’re going to do this and document it as part of your planning. Okay, next bullet point is one, two, three, four, five, six, seven, eight. ## Clause 13.2.2: Personnel, Location, and Documentation Item number eight, test personnel competencies. This is part and parcel of clause five. Should have been talked about in clause five in your overall functional safety planning. Who is competent to perform an FAT? How do you know that they’re competent? Did you check to make sure that they’re competent? Next bullet point is that you need to specify the physical location. Hmm. Physical location, test environment. Physical location, test environment. So what is the address that you’re going to drive to. That’s going to be the physical location. How that is different from the test environment is the test environment is also a little bit more information about what’s inside the building, how is the test laid out, you know, who sits where, who’s going to run the test. That’s the difference there in what we mean by test environment and physical location. Physical location, you should be able to drop into Google Maps. Next bullet point up is hazards posed by the testing, especially dealing with stored energy. Just like any other job, you need to do a job safety assessment before you execute the job that talks about what you’re going to do, what the hazards are, do you have the proper PPE? So, back when I was working at UOP and I was doing a lot of FATs for our lock hopper control system, for our adsorbent chamber control system for the Parex, I did a lot of FATs. I did a lot of FAT planning. I did a lot of risk assessment work for those FATs. Honestly, that was kind of built into the ISO quality procedures that we did not need hard hats because there wasn’t going to be any lifting happening during the FAT. But everyone did need to wear steel-toe shoes, just in case, just for bumps, and if something fell over. and also safety glasses just in case anything popped out of the test assembly. So doing that job safety assessment, you know, I would recommend using a tool like OpenPHA and just filling out a job safety assessment checklist. You might put that job safety assessment checklist into a workflow management system, like maybe a Kenexis MOC, to handle all these things. But yeah, definitely a good job safety assessment checklist in OpenPHA is going to meet your requirements for the hazards posed. And then, obviously, before you start your test, you’re going to walk through that checklist again and make sure that everything is true, that you’re compliant with everything. Second to last bullet point says, I want a clear diagram of the test setup. Honestly, I have done a boatload of FATs and I have never had a diagram of the test setup, so shame on me. I don’t know how valuable a clear diagram of the test setup is um, There are a lot of diagrams that were created during the engineering process that will, uh, you know, something like uh the cabinet layout diagrams, the wiring diagrams, all of that should be pretty obvious. That wasn’t part of the FAT planning. That was just part of the engineering design process. I think generally that meets the requirements, but you might want to do a little plan view of this is where the cabinet is, this is where the power supplies are, this is where the interface device is, this is where the maintenance and engineering interfaces. Here’s a screen that the customers are going to see what’s going on on the maintenance and engineering interface. Maybe they’re not in the same room, so you’re going to communicate the signal that’s on the maintenance and engineering interface over to a different location if you’re doing something, you know, very hazardous. I’ve never done that, but you know, anything’s possible. Okay, so that’s a clear diagram of the test setup, and then the last, the final bullet point for clause 13.2.1 is recording of tests conducted, data, results, and observations while the tests are being conducted. Now, it’s alluding to the fact that you’re going to need to document the data, the results, the observations while the test is being conducted. So you need to think through before you start, how you are going to do that. Are these going to be notes and check marks on a paper document? Do you have something like an open PHA checklist where you’re going to use the Open PHA checklist as your procedure and fill out the, you know, yes or no, did it pass? And, you know put the notes in if anything fails and now you have everything in electronic format Kenexis open audit is another tool for doing this type of assessment and auditing. It’s a much more elegant tool that’s going to allow you then to communicate out to other business systems. It’s going to allow you to A dashboard, and you know, it lives in the KISS framework. So, consider using OpenPHA checklists or open audit. Audit protocols, assessment protocols as a tool for doing these types of activities. You can print them out and have everything on paper, or, you know, today, why are we doing anything on paper? You know, you could just run it on your laptop, you could run it on a tablet, you could run it on a phone and kind of walk through, document your results, and those results are going to be available to a wide group of people simultaneously. So, think about using Kenexis Open Audit as a tool to be tracking these factory acceptance tests, site acceptance tests, and so on. It’s easy to build standard protocols and then execute those standard protocols as you go on. ## Clause 13.2.3: Defined Version and Wrap-Up All right, so that is clause 13.2.2. We have a bunch more clauses to get to, so let’s keep going. Honestly, I’m going to give you one more clause and then we’re going to wrap it for today. And then we’ll get to the balance of this in the next episode. So, the last clause that we’re going to talk about today is going to be clause 13.2.3, which is only one brief sentence. And that is, the FAT shall take place on a defined version of the logic solver. That’s it. A defined version of the logic solver. Now, immediately you’re going to think that that means The I have a revision number of the software that the logic solver is running. And that’s, for the most part, that’s 90% of the battle, but you also need to remember that that version of the logic solver code is tied to physical equipment. So there should be a revision of all of the physical drawings that define that logic solver as part of that document record, so this is the logic solver version of the application program, which included this version of the layout diagram, this version of the wiring diagram, blah, blah, blah, blah, blah. All these things get tied together. Okay, so that is 13.2.3. We still have 0.4, 0.5, 0.6, 0.7 in factory acceptance testing. I couldn’t get through it in one day. I don’t want to keep you here for another hour. So let’s put a pin in it and I’ll talk to you about the balance of FATs in next week’s episode. ## Vertigo and Kenexis Software Overview 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.