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

KENEXIS FUNCTIONAL SAFETY PODCAST — S1E16 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 16: IEC 61511, Clause 7 (Verification)

—

## Episode Opener and Podcast Introduction

One more time, validation is a final physical test on the completed system, but verification is the step-by-step back-checking of each individual activity.

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

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

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

## Clause 7 Overview: Verification and Human Error

Okay, so today we're going to be talking about Clause 7. Clause 7 is the verification clause in the standard. So at this point in time, I've mentioned several times that the standard, the standards committee, engineers who do safety instrumented system design understand that human beings are the cause of a lot of errors.

Human error, things go wrong. People make mistakes and we need to somehow address that. And the absolute wrong way to address human error, in my opinion, and basically the committee's opinion, if you read through the standard and see what it says about the topic, is that we're not just going to try to run some calculations and calculate, well, what's the probability a human messes things up and then go along. We're going to put in administrative controls. We're going to put in management systems to help address human failure and make sure that it doesn't happen.

And if it does happen, we want to catch it so that we can fix it.

The first part, the first step in catching human error to make sure that it doesn't propagate out into the design and operation of a safety instrumented system is verification.

Verification is, back when I was at UOP, we would call it back checking. A junior engineer would run some numbers, do some calculations on a calculator back then, of all things. And then someone more senior would get out the orange highlighter, because the orange highlighter is for back checking, and make sure that the calculations were done properly. So it's something that's happening phase by phase, step by step, deliverable by deliverable. One person does the work, someone else checks the work to make sure that it was done properly. Okay, so all of this is discussed in Clause 7.

## Clause 7.1: Verification Objective and Safety Lifecycle

So let's start out by Clause 7.1 is objective. So what does Clause 7.1 say? The objective of Clause 7 is to demonstrate by review, analysis, and or testing that the required outputs satisfy the defined requirements for the appropriate phase, and that's shown in Figure 7, as identified by the verification planning. So a couple things there, kind of some loaded information. Okay, so first off, let's go backwards to what is Figure 7. Figure 7 was the drawing of the safety life cycle. It's basically the safety life cycle flowchart.

So if you're wondering what the clause referred to, that is indeed what it referred to.

So we're basically, in kind of standards terminology, we're looking at each block in the flowchart as a task that needs to be completed. And you're basically going to make sure that what was generated is appropriate based on what the inputs were. Okay, that's a little bit of tortured language in my opinion, but then again, I guess we don't want to go all the way to the informal level of saying something like back-checking.

So we're reviewing, analyzing, some cases testing, especially if we're talking about something like software programming, maybe even some of the wiring that's being done when you're assembling things. So it can be physical in addition to just kind of a paperwork back-check. But we're just basically doing some analysis to make sure that what was delivered matches what our expectations were based on the input data.

## Clause 7.2.1: Verification Planning Requirements

Okay, Clause 7.2 is going to jump into the requirements for verification. All right, Clause 7.2.1 is the first clause in requirements, and it's going to have a boatload of bullet points. So let's look at the front part first, and then we'll go over all the individual bullet points. 7.2.1 states that verification planning shall be carried out throughout the SIS safety lifecycle and shall define all activities required for the appropriate phase, again, pointing you back to figure seven, of the safety lifecycle, including the application program.

So always, you know how much we're stressing application programming as part of the safety lifecycle that you need to make sure has been done properly. Verification planning shall conform to the IEC 61511 series by addressing the following activities. Okay, now is where you're going to run into your bullet point list.

So we need to do verification planning. So what does that mean? Your functional safety plan, your corporate standards, your documentation that we discussed in Clause 5, not only does it need to describe who is doing what, when they're doing it, how do we know they're competent, but we're also going to include in that list of activities this verification. So who's going to do the work, but also who's going to check the work? How are they going to check it? When are they going to check it? All of that needs to be included in the verification planning.

So number one, we need to plan what are the verification activities. That's bullet point number one. Bullet point number two, the procedures, measures, and techniques used for verification, including implementation and resolution of the resulting recommendations. So what, how is this verification going to take place? So who's doing, what activities are happening? How are these activities going to take place is going to be part of that.

A little bit more critical to document this type of thing when we're talking about physical testing, as opposed to, well, I'm going to have the senior guy back check the junior guy's work. Okay.

Third bullet point. When will these activities take place? So where in the life cycle, when is it going to happen after what and before what? So kind of a critical item here is making sure that the verification activities happen quickly enough before the next life cycle stage. So you don't carry bad stuff from one phase into the other.

Next bullet point. You're going to need to address the persons, departments, and organizations responsible for these activities, including levels of independence. So who is senior, who is independent enough to perform these activities? The next bullet item states you need to plan for the identification of items to be verified. So how does the person doing the verification know what they're supposed to be verifying?

Next bullet point is identification of the information against which the verification is going to be carried out. So what documentation did the engineer who performed the activity use to perform the activity? That information is probably also going to be necessary for the person doing the verification to make sure that the activity was carried out properly. So knowing what are the inputs that the verification, the person responsible for verification is going to need.

Next bullet item is the adequacy of the outputs against the requirements for that phase. So adequacy of the outputs, we're usually looking at tolerances. Now for calculations, tolerances usually don't come into play. So this is going to be more of, again, one of those physical testing things that are basically going to say, okay, well, did the code execute in under 100 milliseconds? Because that was the requirement for how quickly we needed to be able to perform the logic in the logic solver as an example of a criteria that you would be checking.

And that's something that would happen in the verification phase early on. You don't want, if your program is taking too long to execute, you don't want to find that out at the FAT, let alone at the site acceptance test. So some of those things need to get addressed earlier in the lifecycle here during verification.

The next bullet item you need to consider is the correctness of the data. So what was the data that was generated? Is it correct? The next item in terms of planning is the process for handling non-conformances. So again, I mean, a lot of this falls into general corporate standards, maybe even ISO 9000 procedures of how you do your workflow. Your back checker is going to identify failures, and then they need to send them back to the engineer to redo the calculation, reissue the documents, and it will get reviewed again until all of the failures have been resolved.

So that's an example of how you'd handle non-conformances. And you're going to do that different ways depending on what the activity is that you are performing your verification for.

Okay, tools and supporting analysis is the next bullet item. So if you need tools to perform the studies and any kind of additional support that would be required to perform verification tasks. Again, kind of on the complex side. But it's definitely something you need to consider in your planning if it is necessary. Next bullet item says the completeness of the SIS implementation and the traceability of the requirements. Traceability is a big issue that we're always talking about in SIS design. So when you perform a calculation, when you do an activity, where did the data come from?

And is that data valid? Is that where you want your data? The optimal for both a PLC programmer and an auditor. So push different buttons to generate different reports out of the same data. Kenexis Vertigo. Definitely a good way to do that.

Okay, and then finally, the last thing that we're going to be looking at, last bullet point under clause 7.2.1, is the testability of the design. So when I perform the activity, the results, am I going to be able to test the system when it's completed, whether that's validation, FAT, to make sure that it's going to do what it was specified to do.

## Clause 7.2.2: Testing Verification Planning

All right, let's move on into clause 7.2.2. There's only six sub clauses in section 7.2, and that's it for verification. So not a whole lot of information in clause 7. I'd say total, it's about two pages, if you kind of lump everything together. Not even two pages, page and a half. Of information. But just jam-packed with bullet points, which is a great way to condense information.

Okay, next item up, clause 7.2.2. Clause 7.2.2 states, where the verification includes testing, the verification planning shall also address the following. So testing, some degree of physical testing is going to be required during verification. And it's going to be during the design, the construction, the programming activities for the most part.

So as you're constructing your PLC, you're going to want to make sure that you landed your wires correctly between your marshalling rack and the I.O. cards. That's going to be a physical test. You're going to want to test to make sure that your two out of three voter that you programmed has been programmed correctly. That's going to be a test. So those are the types of tests that we're talking about during the verification phase.

All right, bullet point number one for considerations for verification testing. Number one, the strategy for integration of application program and hardware and field devices, including the integration of subsystems that comply with other standards, such as machinery or burner. So this is kind of borderline because a lot of these integration activities are what the FAT, the factory acceptance test is for. But honestly, you don't want to find out all of your mistakes during the FAT.

So you're generally going to do some verification testing of this type of integration before you even go into your FAT. So you need to think about before you get into FAT, how did you integrate your application hardware and software and field devices together?

The second item you need to think about, second bullet point is the test scope. Describes the test setup, what type of test is to be performed, including the hardware application programming and programming devices. So what kind of testing am I going to be doing? Third bullet item, the test cases and the test data. These will be specific scenarios associated with the associated data. So if you're doing something, you know, on the more complex side, so let's say you have timers that need to time out. Let's say you need your safety instrumented system to perform a more complex calculation.

You're going to need test data and a description of what the test is before you perform it.

Next bullet item, types of tests to be performed. Pretty self-explanatory. Just kind of a listing of what are the tests that you're going to be doing when you're in this process. The next bullet item says the test environment, including tools, hardware, all software, and required configurations. Again, pretty straightforward. Make a list of what you're going to need during your testing. Next bullet item, text criteria, e.g., pass, fail criteria, on which the results of the test will be evaluated.

Okay, so as you're going through your procedure, you need to have documented what our expected outcome is to make sure that's what's going to happen.

Next bullet item, procedures for corrective actions. That kind of goes back to what we were talking about in the last clause. If something goes wrong, we need to have a process for resolving it. Usually, that's probably going to show up in your ISO 9000 certified workflow for how you perform your designs in general.

Next item, physical locations. So, where is the test going to be performed? You do a test differently if you're doing it on the bench or in the factory versus on site. or maybe even in a lay down yard before it actually gets installed. Next item, next bullet point, dependence on external functionality. So, if your SIS requires input, it's taking input from something, you're going to probably need to be able to simulate that when you're doing your testing. Something to think about as you're developing your testing process.

Next bullet item, who are the appropriate personnel? Pretty straightforward. Again, you're thinking about seniority, you're thinking about expertise, you're thinking about independence from the project when you're doing this. Next item, management of change is something that you may need to consider depending on where the break point is between the rapid prototyping and you're going to perform during the design phase versus when do I want to actually start tracking changes afterward.

And even in the design phase, if you realize that something was wrong in your specifications, that's going to require an MOC process to go back and change those specifications. And finally, the last item is non-conformances, which is kind of a subset of corrective actions. If something goes wrong, we need to document it, we need to resolve it before we move on to the next phase.

## Clauses 7.2.3 through 7.2.5: Non-Interference and Modifications

Okay, next item up is non- Okay, so RADA clause 7.2.2, which is a bunch of bullet points related to physical testing. Four more clauses in this section. 7.2.3 states, non-safety functions integrated with safety functions shall be verified for non-interference with the safety functions. Huh, it's kind of an interesting activity. You're going to need to verify that if you're doing something that's not safety related in your SIS, that it's not going to interfere with the things that are safety related.

That's something that can easily be overlooked in your verification process if you don't think about it.

7.2.4 states, verification shall be performed according to the verification planning. Pretty straightforward but again, a key is there needs to be some sort of verification planning.

So, make sure to do a quick review of that functional safety management plan or corporate standard that is the basis for how you execute your SIS lifecycle and make sure that those verification activities are included in that functional safety management plan. 7.2.5 states, duration testing, any modification shall be subjected to an impact analysis which shall determine all SIS components and impacted and the necessary re-verification activities.

Now, my brain just went a little bit soft and I said, duration testing. Ignore that. Duration test, it's during testing. So, let me come back at that again.

As I'm reading through the standard, sometimes my mind is deceiving me. So, basically, we have talked in clause 7.2.1 in 7.2.2 about the fact that you're going to run into issues that you didn't expect during the testing process. And those issues are going to need to be resolved before you can proceed forward from the verification testing.

So, when you're making modifications during testing, you can't just do what we call an undocumented repair. when you're doing your testing, you need to document or your verification, you need to document that something was wrong. You need to redo whatever was wrong and then you need to make sure that it currently works.

And you're also going to need to be doing some degree, whether it's formal or informal, of impact analysis to trace out from the error you found any other things that could be impacted by that error and make sure that all those items are fixed and that re-verification for all of those items occurs.

## Clause 7.2.6: Documenting Verification Results

Okay, 7.2.5. Wait, no, we just did 7.2.5. Last item in Clause 7 verification is Clause 7.2.6. There's a sentence that compromises the clause, but then there's also a couple of notes that we're going to get into before we leave it for this section. So Clause 7.2.5 states, during testing, any modifications shall be come on Ed, 7.2.6. That was, I keep, I'm loving on 7.2.5 apparently. 7.2.6, the results of the verification process shall be available, C Clause 19, including whether the objective and criteria of the tests have been met.

So, we need, when we're doing our verification, we need to document that verification, and make that verification available, and maintain it as required in Clause 19. We'll get to Clause 19 at the very bitter end of this podcast series.

So, it's not enough to do an undocumented test. We're going to want documentation of what happened during the testing, and we're going hold on to that.

Okay, note 1 to Clause 7.2.6 states, selection of techniques and measures for the verification process and the degree of independence depends on a number of factors, including the degree of complexity, novelty of design, novelty of technology, and the required SIL. So, as we are doing verification, the more complex the process, degree of risk associated with the process, that's going to impact how thorough your testing and the degree of independence that you need in the people that are going to be performing that testing.

Finally, note 2 to Clause 7 states, examples of some verification activities include design reviews, use of tools and techniques, including software verification tools, and computer based design analysis tools.

## Verification Tools and KISS AI Capabilities

So, verification, yes, there are human beings that are going to be involved, that are going to do that paperwork back check, but we're also going to be running your design through tools.

So, consider Kenexis Vertigo as an SIS design basis tool. When you perform a set of SIL verification, you do your conceptual design review SIL verification task, there's a button with a big old check mark on it that when you click on that button, it is going to do an automatic check of all of your calculations. It's going to determine whether appropriate data was used, whether all of the required items were filled out, if there are any errors being thrown in your calculation process.

So, even Kenexis Vertigo today has tools that are available and artificial intelligence is coming. In the Kenexis integrated safety suite, it is a short amount of time before we're going to have automatic verification tools that are not intended to replace a human expert, but to support a human expert by reviewing your design and checking to see if anything seems out of the ordinary in how you performed your calculations. So, keep an eye out for KISS AI. It's coming soon.

And then, especially those automatic techniques are going to be critical when you're doing your software verification. Automated software testing is something that we know about, we're very familiar with that connects us because we are a top-tier software design and development company. So, getting those cases and automated tools to put all of your logic through its paces and make sure that errors don't exist is something that's going to be critical.

## Bridge to Clause 8: Process Hazard and Risk Analysis

Okay. Hey, for the past couple of podcasts, we've been able to do an entire section in one podcast. And right now, we're at the cusp of change in our podcast series. So, everything that led up to Clause 7 or even included Clause 7 is something that is not part of the normal workflow. It's kind of the backlog, the things that you need to think about and develop before you even did your first project. We're kind of looking at our management systems to make sure that we're equipped to execute a project.

Well, when we get into Clause 8, we're going to start doing projects. So, step number one in executing projects after you've achieved your conceptual design is a process hazard and risk analysis. So, now that we're done with the baseline stuff, we're going to be doing step-by-step project-by-project activities, starting with Clause 8, Process, Hazard, and Risk Analysis.

Now, the hazard and risk analysis clause in the standard is only a page and a half. But even though it's only a page and a half, there's a very good chance that we might not be able to get all the way through it in one podcast segment. Because when we get into the detailed design, there's a lot more discussion that goes into all of these activities. So, we will at least get you the first half of hazard and risk assessment when we get together again next week.

## Kenexis Vertigo 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 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.