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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E15 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 15: IEC 61511, Clause 6 (Safety Life Cycle Requirements)

—

## Introduction and Episode Overview

The SIS Safety Life Cycle. It explains all of the activities that occur when you're designing safety instrumented systems to achieve functional safety, and it's all defined in Clause 6.

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 Life Cycle 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 6 Objectives and Anti-Flowchart Lesson

I'm going to dig into Clause 6 today. Clause 6 is titled Safety Life Cycle Requirements, and it is where the safety life cycle is defined.

So let me start with the objectives of the SIS Safety Life Cycle as they're presented in Clause 6.1. The objectives of Clause 6 are, first, to define the phases and establish the requirements of the SIS Safety Life Cycle activities. Okay. Seems pretty straightforward. What are the phases? What are the steps? And then in each of those phases or steps, what are the requirements of the activity?

So what are the things that you have to do? What are the criteria that they're supposed to achieve? Okay. The second bullet point under objectives is to define and organize the technical activities into a SIS Safety Life Cycle. So we're going to try to put together a flow chart or a procedure, a process, what activities need to take place. And we're going to put them in what I'm going to refer to as semi-chronological order.

And this is one of the areas that today, especially, I'm going to be talking a lot about the fact that looking at the SIS Safety Life Cycle and treating it as a flow chart is a bad thing to do. Or shall I say, getting dogmatic about it is a bad thing to do. Because depending on what type of project you're talking about, different steps in the life cycle are going to take place at different times.

Where people get really hung up is they expect that since SRS is in the life cycle right after hazard and risk analysis, before design begins, people that are kind of dogmatic, linear thinking people will say, okay, well, I need to write my SRS now.

Well, honestly, you're not going to know the information, the complete set of information that goes into the SRS until literally right before you start your plant up. You're going to be making changes to that SRS all the way through. So there's a lot of recycle. There's a lot of bits and pieces. And just, you know, the big lesson here is don't get hung up about, you know, it being a flow chart. And, you know, okay, well, I have to complete this step before I complete that step. In reality, it doesn't work that way. At the end of the day, we're putting things into phases.

And the phases are a mechanism to allow us to lump requirements together. So for the SRS phase, we're going to document everything that needs to be recorded. But at the same time, we're not going to say that all of this is known at once. And specifically with the SRS, there are different people that are responsible for different pieces of information that go into the safety requirement specification.

So at this point in time, just kind of the big picture lesson is don't get dogmatic about the flow chart. There's going to be recycle activities. You're going to do things out of sequence routinely because that's the reality of project work. All right.

The third bullet item under Clause 6.1 says that an objective is to ensure that adequate planning exists or is developed that makes certain that the SIS meets the safety requirements. So we put together the safety lifecycle to kind of also help you with the planning process.

If you're in Clause 5, if you remember back at Clause 5, the very beginning was planning for who is going to do the safety lifecycle activities, when they're going to be done, what competency they require, etc. And the safety lifecycle itself kind of helps you to think through the flow, think what the activities are, what are the inputs and the outputs required for each phase. And that's kind of a starting point to help do the planning that is appropriate for your organization. And the planning for your organization may or may not match what that safety lifecycle looks like in the standard.

So those are the objectives that you're going to see in the safety lifecycle.

There is a note to Clause 6.1 that says the overall approach of the IEC 61511 series is shown in Figure 7. It can be stressed that this approach is for illustration and is only meant to indicate the typical SIS safety lifecycle activities from initial conception through decommissioning. So right there, right out of the gate in the note for Clause 6.1, it's already saying that, okay, we're kind of illustrating a general workflow here. Different organizations are going to have different workflows. Don't get hung up on the structure of what you see.

You're going to need to customize this for your specific organization.

## Figure 7 Cross-Cutting Safety Lifecycle Phases

Okay, there we move into Clause 7. And this is where an audio podcast is a little bit lacking in comparison to doing a video here. Of course, we do have videos of all this information in the Kenexis SIS or in the Kenexis Process Safety Training Center. Specifically, if you wanted to see this in more detail, you'd want to go to the SIS Overview and Awareness Training class. And there you can see the full SIS Safety Lifecycle in video in all its glory. But I'm just going to go ahead and give you an audio overview of what the SIS Safety Lifecycle contains.

So there are kind of, I would say that the Safety Lifecycle, as shown in Figure 7, is broken into two parts. So there are boxes, kind of phases, steps, that extend all the way across the life cycle. And then there is kind of a step-by-step activity portion of the life cycle that is not occurring on a step-by-step basis, but it's occurring all the way through the life cycle.

So the three phases that go all the way across the safety life cycle include management of functional safety and functional safety assessment and auditing. And then when you look at that box in the diagram, it's going to say Clause 5 because that's where the requirements are. And then there's also going to be a number 10. So the phases are described sequentially from 1 through 11. And this flow chart is going to correspond to a table in the standard that's going to break each of these activities down in a little bit more detail.

So there are two other phases or steps that occur all the way through the safety life cycle, all the way through an entire project.

The second one being Safety Life Cycle Structure and Planning, which is Clause 6.2, which we're going to get to in just a second. That is Step 11. And then there is Verification, which is Clause 7 and 12.5 when you're talking about verification of software.

That's going to be Step 9. So those activities, Verification, Safety Life Cycle Structure and Planning, Management, FSA and Auditing, always exist from the beginning of the life cycle all the way through the end of the life cycle.

## Sequential SIS Lifecycle Phases One Through Eight

Now, in the middle of the drawing, there are phases that are going to occur kind of one at a time, roughly sequentially discussed. And when they're done, you kind of progress to the next, to the next, to the next. And these are kind of the activities that occur on a project-by-project basis.

So we're going to begin with Hazard and Risk Assessment, which is Phase 1. Its requirements are described in Clause 8. After Hazard and Risk Assessment is Allocation of Safety Functions to Protection Layers, which is Phase 2. And it is described in Clause 9. So now, right out of the gate, you have a Clause 8 for Hazard and Risk Assessment, Phase 1. Phase 2, Clause 9 for Allocation.

But in reality, you're going to do your Hazard and Risk Assessment and your Allocation, essentially, effectively at the same time. So when you do your Layer of Protection Analysis, you do things, or you execute requirements from Clause 8, and you'll simultaneously execute requirements for Clause 9. So again, don't get dogmatic about what you see in the life cycle. You need to think about what the requirements are. You need to think about your organization and how you're going to execute those activities in your organization.

Okay, Phase 3 is Safety Requirements Specifications. It is described in Clause 10. And after you get done with Clause 10, you're going to see the description of stages. So these stages are discussed in the Functional Safety Assessment section.

And there are different places where you might want to have a Functional Safety Assessment. So Stage 1 Functional Safety Assessment would be after the Hazard and Risk Analysis is done, and you've defined not necessarily the full set of safety requirements specifications, but at least the subset of safety requirements that come out of the Hazard and Risk Assessment.

Okay, from there, you'll see two phases in parallel with each other. Phase 4 is the Design and Engineering of the SIS that's described in the SIS 11, 12, and 13. 11 for the hardware, 12 for the software, and 13 for factory acceptance testing. In parallel to that, you'll see something in a dashed box. So when you see something in a dashed box, that means that it's primarily controlled by a discipline other than instrumentation and control, and we're not providing complete description of what goes on in that stage because it's really the specialty of another discipline.

So in parallel with design and engineering of the safety instrumented system, you'll see design and development of other means of risk reduction. So if there was the need determined in the Hazard and Risk Analysis for a relief valve, well, we're not designing the relief valve the same way we design in SIS. It's done by other people in accordance with other standards. So you'll see that kind of dashed box around design and development of other means of risk reduction, but you'll also see it around hazard and risk assessment and allocation of protections to safety layers.

Because that's really an HSE hazard management, process hazards analysis, process safety management. That is the discipline that handles those activities as opposed to the instrumentation and control group.

Now, after you get done with clauses 11, 12, and 13, you've done your design and engineering of the safety instrumented system. That's going to be a stage two gate for functional safety assessment. So we're done with the design, but we haven't built anything yet in terms of installing it out in the field, connecting field instruments and so on. Which leads me to phase five, which is installation, commissioning, and validation, where you install it, start it up, do that final validation test, that final physical test of the completed system. That's described in clauses 14 and 15.

Phase six is the operation and maintenance phase, where you have the operators interact with the system while the plant is running. You're going to respond to overt failures or detected failures of your SIS. You're going to perform maintenance activities, and you're going to do your testing.

All that is described in clause 16. And then after clause 16, there's a stage four functional safety assessment that I talked about an episode or two ago, where you're going to make sure that you have all of the activities that are required after the plant's been put in operation are effectively being implemented, and you can check your design assumptions against the actual operation of the plant.

The next phase is called modification. It is phase seven. It's described in clause 17. Modification, as we're going to get into when we talk about clause 17, is better known in the U.S. as management of change, or MOC, and it is a key core requirement of the process safety management standard, the OSHA PSM rule. And, you know, other jurisdictions around the world are going to have very similar requirements for managing change.

So managing change is phase seven. Phase eight, which is described in clause 18, is decommissioning. Now, decommissioning is probably given a little bit more ink than it requires. Decommissioning is actually just a special type of modification. The type of modification is that I'm not going to use this anymore, and I'm going to take it out of service. So I need to make sure when I decommission something that I didn't break what was still in place and in service. So decommissioning clause 18 is a special type of MOC.

Now, there is one clause that doesn't show up in the safety life cycle, and it also shows things that's applicable from beginning to end. So clause 19, the last clause of the standard, is related to documentation. And maybe you can actually say that documentation fits into management of functional safety because you're talking about what you need to document, how you need to document it, how you need to store it, and so on, which is kind of a, you know, you could argue it's a subset of management. So maybe phase 10 should say not just clause 5, but clause 5 and clause 19.

Okay, so that's the figure that describes figure 7. It's titled SIS Safety Lifecycle Phases and FSA Stages. And there is a note to the drawing which says, information in figure 7 may flow from operation and maintenance back to the earlier lifecycle stages to reflect tracking of incidents and failures and to verify engineering assumptions.

So it's even a little bit more than that. You're going to get kind of backward flow. So like, you know, let me give you an example. During the LOPA hazard and risk analysis phase, you might know that you've got the potential to overfill a vessel or maybe overpressure a vessel. But you haven't done the detailed design of the plant, so you don't know what the set point will be. And the set point might not be obvious. The range of the equipment might not be obvious until, you know, at least the middle of stage 4 or clause 11 when you're doing detailed design.

And it might even get changed, you know, right up in the installation, commissioning, and validation phase if something gets caught where what was specced out originally and put into the initial design doesn't really work out. So there's always going to be back and forth. You're going to complete subsets. You're going to move forward. And then you're going to go back and complete other subsets of information.

So, you know, there are a couple notes now where we really lean on you and impress upon you that this is not a systematic, ironclad, immovable flowchart that thou shalt follow. It's kind of guidance. And really, when you're doing your planning for your facility in Clause 5, you're going to break these phases down probably into multiple tasks that are assigned to multiple different people at multiple different times. So it's more to help you do your planning for what you're actually going to do as to be the gold standard for these are the tasks and never shall they change.

## Clause 6.2 SLC Planning Requirements

Okay, continuing on in Clause 6, we come to 6.2, which is titled Requirements.

And Clause 6.2.1 reads, The SIS Safety Life Cycle Incorporating Requirements of the IEC 61511 series shall be defined during safety planning. The safety life cycle shall also address the application programming. So right out of the gate, 6.2.1 says, okay, here is the list of requirements for the standard as a whole. Now, you need to go do your safety life cycle planning and make sure that all these requirements are achieved by however it is that you're going to implement the process.

And it involves a lot of different activities from a lot of different people. So if I could kind of step back a little bit while we're talking about this planning clause, you'll notice that the SIS Safety Life Cycle is an entire life cycle from the conceptual design of the plant all the way back out to the decommissioning of the plant. It includes a lot of activities that are done by other groups like the process safety group, operations, maintenance. It's not just a cookbook for how to design an SIS. And in the early stages of the development of this standard, that's what the intention was.

Get me a cookbook. Do I need two out of three voting or can I get away with one out of one? Do I use switches or do I use transmitters? But as we went through the standards development process, we realized that a lot of the causes of failure of SIS occur in timeframes other than the detailed design of the SIS. So the Standards Committee, even back in the 80s, was really focused on, okay, we need a complete life cycle.

We need to do planning to make sure that everybody involved in the life cycle understands their responsibilities, understands how to do their responsibilities, and how their activities interact and integrate with what everything, everything everyone else is doing for the complete SIS life cycle of the plan.

So that's clause 6.2.1 kind of stresses. We gave you a framework of requirements. Now you need to do the planning for who does what, when, in what organization, in your facility.

## Table 2 Overview Phases One Through Five

Okay. Clause 6.2.2 says, each phase of the SIS safety life cycle shall be defined in terms of its inputs, outputs, and verification activities. See Table 2. And then, of course, directly after that, you're going to have Table 2. Table 2 is titled SIS safety life cycle overview. And there, you're kind of going to get the corollary to what was in the drawing in Figure 7, except it's going to be in table format. Now the table says, what is the box number or the phase number? For instance, box number one is hazard and risk assessment. So there's the box number, there's the title.

Then, for each one of these safety life cycle activities, there are going to be objectives, the location of the requirements, the inputs to the phase, and the outputs to the phase. So let's go through them. First phase, hazard and risk assessment.

The objectives of hazard and risk assessment, to determine the hazard and hazardous events of the process and associated equipment, the sequence of events leading to the hazardous event, the process risks associated with the hazardous event, the requirements for risk reduction, and the safety functions required to achieve the necessary risk reduction.

All basically, a summarization of the handful of requirements that are in Clause 8. So where are the requirements? They're in Clause 8. So inputs to this phase include the process design, process safety information, basically, layout, manning arrangements, safety targets. The outputs include a description of the hazards, the required safety functions, and the associated required risk reduction as a whole.

So remember, or actually, don't remember, I haven't gotten there yet, when we get to hazard and risk assessment, you'll see that Clause 8 determines what the gap is between tolerable risk and expected risk, but it doesn't explain how to close the gap. Closing the gap is Phase 2. So for Phase 2, titled Allocation of Safety Functions to Protection Layers, the objective is allocate safety functions to protection layers for each SIF and assign the associated safety integrity level.

This is described in Clause 9. So the inputs for allocation are a description of the required SIF and associated integrity requirements as a whole, and then the output is a description of the allocation. So you start with the gap, and then you end up with assigning, closing the gap to different independent protection layers. One of them, the critical one for this standard being the safety instrument and function itself.

Okay, Phase 3 is SIS safety requirements. Those requirements are defined in Clause 10, and the phase is required to specify the requirements for each SIS in terms of the required SIF and their associated safety integrity in order to achieve the required functional safety. The inputs for the phase are a description of allocation of safety requirements, and the outputs are SIS safety requirements, application program safety requirements.

So, we kind of start with what does the SIS need to do coming out of the hazard risk assessment, and then at the end we're going to have a full description and definition of the SIS.

Phase 4 is SIS design and engineering. The objective there is to design the SIS to meet the requirements for SIF and their associated safety integrity as we just defined. It's going to be described in Clause 11 and 12. 11 for hardware, 12 for software. The inputs are the SIS safety requirements and the application program safety requirements. Those usually get combined into a safety requirement specification document. The output of this phase is the design of the SIS hardware and the application program, all of this in conformance with the SIS safety requirements.

And also in the design phase, you're planning for the integration test or the factory acceptance test where you integrate the hardware and the software together. Phase 5 is SIS installation, commissioning, and validation. The objective is to integrate and test the SIS, install it, connect everything together, and test it to make sure that it works. To validate and also to validate that the SIS meets all respects of the requirements for safety in terms of the required SIF and their associated safety integrity.

It's described in Clauses 14 and 15. the inputs are the SIS design, the SIS integration test plan, the SIS safety requirements, and the planning for the SIS validation. The output will be a fully functioning, fully tested SIS that is in conformance with the SIS requirements. And you're also going to document the results of SIS integration tests and the results of the validation testing.

## Table 2 Overview Phases Six Through Eleven

Clause, or not clause, phase number six is SIS operation and maintenance. There, the objective is to ensure that the functional safety of the SIS is maintained during operation and maintenance. All done in conformance with clause 16. Inputs to this phase are the SRS, the SIS safety requirements, the SIS design, and the plan for SIS operation and maintenance including all the procedures by which it will be operated and maintained.

The outputs of the phase include the results of the operation and the maintenance activities. So the output of operation and maintenance is operating and maintaining, but also during this phase you're going to be generating documentation of such activities. Phase

7, SIS modification, its objectives are to make corrections, enhancements, or adaptations to the SIS, ensuring that the required SIL is achieved and maintained. This is all described in clause 17. The inputs for this phase are the revised SIS safety requirements as you make modifications or, you know, the intent of the modifications. And the outputs are the results of the modifications.

So kind of your MOC change request is your input and then your modified SIS is your output, but there's also that detailed management of change documentation. Clause 8 is decommissioning or phase 8 decommissioning. The objective is to ensure proper review, sector organization, and ensure that the SIF remains appropriate. You know, bottom line there, I would kind of rewrite the objectives and say when you take something out of service, make sure that taking it out of service didn't negatively impact the equipment that is going to remain in service.

This is described in clause 18. Inputs as built safety requirements and the process safety information. the output of the phase is that a SIF or a SIS is taken out of service.

Phase 9, and now remember phases 9, 10, and 11 go from the beginning of the life cycle all the way to the end. And they're going to include phase 9 SIS verification. verification. The objective there is to test and evaluate the outputs of a given phase to ensure correctness and consistency with respect to the products and standards provided as input to that phase.

Verification is done in accordance with clause 7 and clause 12.5 12.5 being specific to software. The inputs include the plan for verification of the SIS for each phase and the results are the results of the verification. So we're going to have verification planning and then we're going to have results of the verification documentation explaining that the verification was done in any issues or discrepancies that were identified.

Phase 10 is SIS FSA or Safety Instrument System Functional Safety Assessment and the objective there is to investigate and arrive at a judgment on the functional safety achieved by the SIS. All of this is described in clause 5. The inputs for FSA include planning for SIS FSA and the SIS safety requirement specifications. The outputs are the results of the FSA. So remember FSA is kind of like a project by project audit.

So there's going to be a plan or a checklist of things that you're going to review and then you're going to document what you found and any discrepancies any non non conformances that you might have found during that process.

And finally the last phase phase number 11 is safety life cycle structure and planning. The objective there is to establish how the life cycle steps are accomplished. This is described in clause 6.2 where we are right now. it's actually kind of also part and parcel of clause 5 where you're just doing your planning in general. Inputs well not applicable it kind of says but you know some inputs might be other guidance documents maybe other standards like process safety management.

Ultimately the output of this step though is that safety plan your corporate standard or your site plan for how you're going to be achieving functional safety.

## Clause 6.2.3 Five Planning Bullet Points

Clause 6.2 Okay so that is all of table 2 which is SIS safety life cycle overview. The standard then moves on to the next clause. We're still in 6.2. And the clause is 6.2 which states for all SIS safety life cycle phases safety planning shall take place to define the activities criteria techniques measures procedures and responsible organization people to. Okay so this clause is giving a little bit more heft to the planning that was done in clause five. So you were always required to do a safety plan.

And now that we've defined what the safety life cycle is what the requirements are what the inputs and outputs are we're basically adding more oomph adding more definition to what needs to be done in clause five so yes now that we have all the phases now let's create a plan that's specific to your facility or specific to your organization. And there are five bullet points that need to be considered during this planning process. Bullet point number one ensure that the SIS safety requirements are achieved for all relevant modes of the process.

This includes functional and safety integrity requirements. So think about all the modes of operation and make sure that they're covered. And when you're doing your planning you need to think about defining what the SIS does that those are the functional requirements but also how well the the safety system does those requirements. Those are the safety integrity requirements. So that goes back to planning your testing and your design to achieve that safety integrity level target. Second bullet point ensure proper installation and commissioning of the SIS.

So you need to make sure that you have plans in place for how do you do commissioning how do you do validation how do you deal with the discrepancies how do you handle your documentation. The third bullet point is ensure safety integrity of the SIF after installation. So you're not done when the SIS passes its factory acceptance test. You're not done when it passes its validation. You need to think about all of the after installation activities specifically maintenance testing and operation. Have them documented have them planned have spare parts available.

All of that planning needs to be done for everything you're going to do after installation. The fourth bullet point is maintain safety integrity during operations. So in the previous bullet point we talked about the planning and the documentation but you also need to execute it. So you need to do your proof tests and you need to assess the results of the maintenance and the proof testing. You need to do failure analysis to make sure that all of those activities are actually happening and you're following up on the results of those activities.

The fifth bullet point is manage the process hazards during maintenance activities on the SIS. We're going to spend a long time on clause 11.3 when we get there. And clause

11.3 talks about the concept of what we refer to at Kenexis a lot of times as an alternate protection plan. The standards refer to it as compensating measures. So if the plant is online and operating and you have something in bypass it's not okay just to roll the dice and let it ride. You have to replace the out of service equipment with something else either other equipment or other manual activities so manual vigilance operators dedicated operators that are separate from the normal operators looking at what's going on in the process and being prepared to take action.

So a lot more on that coming up when we get to clause 11.3 that talks about what you do when an SIS component is out of service compensating measures. All right that's clause 6.2.3. One more clause in 6.2. So

6.2.4 states if at any stage of the safety life cycle a change is required pertaining to an earlier life cycle phase then that earlier SIS safety life cycle phase and the subsequent phases shall be re-examined altered as required and re-verified. So if something happens after you've completed a safety life cycle phase you need to go back to that phase and redo whatever scope the change is and then also re-examine everything that happens after it to make sure that it was done properly. Let me give you kind of a worst case scenario.

Let's say my corporate standards say that I am going to do a layer of protection analysis to pick my SIL targets but instead I did a risk graph. And I worked everything all the way through. I'm at the validation phase. And I do a stage three functional safety assessment and determine at that point in time wow we didn't follow our procedures. We need to go all the way back to hazard and risk analysis and redo the hazard and risk analysis using ELOPA.

Well you can't just redo the hazard and risk analysis during ELOPA because there's a very good chance that you're going to change things that occurred other places in the SIS safety life cycle. You may need to redo your design. You may need to rewrite your procedures. So you need to go back to whatever the phase was redo that phase but also review everything after that and then also redo the verification redo possibly even the validation testing if you've gotten that phase. So changes are not narrow.

They go all the way back to the first phase that was affected and then requires you to re-examine and re-verify everything that followed it.

## Clause 6.3 Application Program Lifecycle Requirements

Okay the next clause is going to be clause 6.3 which talks about the SIS safety life cycle with respect to application programming at this point in time you probably understand that I am not the world's biggest fan of splitting software from hardware especially since in the process industry SIS life cycle especially if you're using vendor provided limited variability languages there's really no reason to separate the software from the hardware. Everything can get documented in the same SRS. Everything can get executed in the same SIS safety life cycle.

But there was a contingent in the IEC 61511 committee that is very keen on software development very expert in software development especially for high variability languages. And they wanted to make sure that a lot of focus and emphasis was put on application programming. So as I'm going to speed through clause 6.3 I will let you know that a lot of this SIS life cycle for software programming is just going to get included in your functional safety planning the same way as if it was a hardware development.

So we're not going to go to great pains to separate the hardware from the software in our functional safety planning. Okay. Clause 6.3 application program SIS safety life cycle requirements clause 6.3 1 states each phase of the application program safety life cycle see figure eight shall be defined in terms of its elementary activities objectives required input information and output results and verification requirements.

See table three. So we're going to get a figure eight which is the SIS software life cycle and then we're going to get a table three which is the SIS life cycle requirements kind of similar and in parallel to what you saw for the life cycle as a whole so figure eight is titled application program safety life cycle and its relationship to the SIS safety life cycle you can go through figure it basically says we're going to have safety requirement specifications.

And when you're defining your application program you're going to need to define the non programmable hardware which is the hardware that's actually in your SIS that your equipment vendor provided and then you're also going to look at the coding that you're going to do for an application program. And that's going to include the design of the program. It's going to include the tools that you're going to use review and testing and procedures operation and maintenance procedures if they are required. And then this is all going to culminate in the SIS integration test or your FAT.

And then it's also going to perpetuate into clauses 14 and 15 because ultimately when you do your validation testing that's going to need to be done with the software. So looking at some of the application program safety life cycle you're going to need to define the requirements for your software. That is going to be a step described in clause 11.5. You're going to need to do some validation planning for your software.

That's going to be described in clause 15 2.2.5. You're going to develop your application software so you're going to need to write code that's based on the description of what the software does which is usually in the form of an elaborate cause and effect diagram maybe with notes and maybe with general requirements for how you write software.

There is going to be a step for application program design where you're going to look at what software are you're using what library modules are you going to be using and then even some details on how you're going to do have automated test tools that you're going to use to perform that testing. There is an application program implementation where you're going to use your programming tools to coordinate with your system. And there's going to be application programming verification where you actually do your testing.

Most of the time this is just going to be part and parcel of your verification plan that includes your hardware during the FAT and the validation. And then there's going to be the SIS integration testing which is your factory acceptance testing so those are all the requirements that are required to be implemented for your software. And as I mentioned a lot of times your software is simply just an extension of what you're doing in your hardware.

But we did spell out clause 6.3 separately from 6.2 to draw attention to the fact that you cannot ignore your software and make sure that the software activities are part of your safety lifecycle planning okay couple more portions of clause 6.3. There is a clause 6.3. 2 that states methods techniques and tools shall be applied for each lifecycle phase in accordance with 12.6. 2. So methods how you write software techniques what software modules you use and how you're going to implement things like variable naming and so on.

And the tools they're going to apply for various lifecycle phases this is discussed more in clause 12.6. 2 which we will discuss in more detail when we get there. 6.3. 3 each phase of the SIS safety lifecycle for which safety planning has been carried out shall be verified as per clause 7 and the results available as described in clause

19. So the same way that when someone does a SIL verification another independent person needs to check that verification or check that calculation to make sure that it was done properly the same is true for software. So if one person writes a software module and does testing to make sure that it works correctly another independent person will also need to check that code to make sure that it matches the requirements and fits the specification. Okay so that is big picture. That is clause six and we hit clause six all at one fell swoop.

We described what the SIS safety lifecycle is for both hardware and software and then how that relates to your planning document which is going to break down that life cycle into more concrete pieces with descriptions for how you're going to do it at your organization.

And when you do that functional safety planning you need to think about not just the hardware but also the software and make sure all of the aspects of the SIS design are included in your functional safety planning. So that is the SIS safety life cycle clause six next week we're going to check and make sure that we did all our work properly by having an independent person back check our work. That is the subject of clause seven verification that we will get to next.

## Kenexis Vertigo SIS Lifecycle Software

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

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

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

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