Solutions Spotlight: Take steps to ensure safety system readiness

Howard: All right, so I'm going to start this one. Before we dive into the SIS, the safety instrumentation system, I want to keep a vision of the process safety layer right from the beginning, because if I have an understanding the different layers, it can help us to know what the purpose is of the safety instrumentation system.

So, what we've normally done is we designed the plan based on the inherency and design, and then with that you have a process control layer, such as a DCS, the distribution system, to control the process variable within the normal conditions. And then, there, if necessary that the control layer is going to shut out a process when the process variable is outside the normal condition. So, when the process control layer is not able to shut out the process, this is when what we call the safety layer comes in, such as a SIS system, the safety instrumentation system, to automatically take the process back to the safe state when the specific condition is violated.

So, this is a last layer of protection before the process error occurs. This is why we spend so much resources to make sure that the system is being designed and maintenanced properly. So, an SIS is made up of one or more safety instrumentation functions, SIF, and each SIF consists of a process sensor, a logic solver and a final element.

And so, with that you can say, well, so the...actually the most critical part is having the safety lifecycle, where you design the SIS system from the hardware analysis in the beginning, to design, to implementation, and then to verification. This is a critical loop to make sure that the SIS is designed properly and all the way to operation. They're expanded across the globe, so in the U.S., it's quite commonly used, which is IEC 61511, or the ISA 84 standard that the users are using to develop their SIS systems.

Thomas: Additional to that, the safety instrument system always has something to do with risk reduction. At the end, we said a safety instrument system, SIS, worked 100% function safe if all random systemic failures and common cause failures do not lead to malfunction of the safety system, and have no influence for humans environmental and protection side.

Keith: Well, sensors and valves, obviously, those are the things that actually are in touch with the process, and really, you count on instruments to see when things are going bad, and a valve perhaps to take action, before something hazardous happens. With standard analog instruments, what are some of the things that can go wrong, leading to either spurious trips, that really affect your uptime, or a failure to trip, even worse, when needed. What are some things that can go wrong with standard instruments?

Thomas: For me, a main problem is that you have a problem with the device. It depends on the sensor or the actuator side, and you didn't get any information from the system that something went the wrong way. I'll give you an example. If you have a freeze 4-20 milliamp output, the sensor, as an example, can't get this information out, “something is going wrong with me." So, we have to find a procedure, at the end of the day, that we can detect such types of failures. So, that could be logical if we change the feeling in the process, we have to have change on the 4-20 milliamp output.

Howard: So maybe, I can piggyback to what Thomas has mentioned about the 4-20 milliamp freeze analog output. For the industry today, there are some solutions out there to avoid this freeze analog output signal. One of the solutions is what we call the life signal from the instruments that can be monitored by either the PLC programming or with a dedicated device to make sure that the devices still continue to provide the dynamic signal to your logic software.

Keith: The self-diagnostic capabilities of these smart instruments help to alleviate these issues? How does that work?

Thomas: For example, for a free space radar, we have more than 80 diagnostic methods in the background. So, we are checking internally, our device, if it goes the right way. And if something happens, the internal diagnostic gets an alarm outside to say, "Okay, here is going,” for example, “a temperature too high, we have a problem with the device." And then the customer can use this information and do something specific with that.

Howard: So, I could maybe add one more thing for right here. So, more and more instrumentation are utilized to one of seven recommendations. They're able to provide, like, a basic status of the indication to identify if the device is still functioning, or a different type of error, such as, it can provide you an error of maintenance required, calibration check, out of specification or instrumentation failure.

So, those are what, when the manufacturer designs instrumentation, they have to follow the recommendations, so that as a user you don't always get a different type of error from different manufacturer with different standard. And, like I mentioned earlier, this quite commonly has been utilized by the manufacturer when they design the instruments.

Keith: Yeah, that makes sense. So, these diagnostics can help identify failures, and they can really complement things like loading schemes, where you have multiple instruments, where you're comparing multiple instruments. But these diagnostics makes that even more robust, so that you've got even more predictability and detectability of those kind of issues. Is that fair to say?

Thomas: Yes. The wish list I often heard worldwide is, "Give me a robust system for my application, and I will be sure that devices work, and then if something happens, I get in every point, 24/7, an alarm that this is going the wrong way." But 100% diagnostic coverage, that we can detect all failures, is technically not possible.

So, we said in E+H, "We have, depending on different principles, diagnostic coverage up to 98%." That means we detect a lot of failures that can happen on a sensor side. And you mentioned before that sensors and actuators are the only two things that have direct contact with the process. And at my point of view, it's very important to have a high diagnostic, as much as we can deliver.

Keith: There's also the need to test instruments, and to test valves, you have to make sure the valves are moving properly, but sometimes you have to shut down the process if you're going to do a full stroke of a valve to make sure it's working. Or another practice is to pull the instrument out of the process, take it to a lab, test it, and put it back in place.

But that also can affect your uptime, and can introduce flaws actually — by the time you pull something out and put it back in, you may inadvertently screwed something up. For valves, let's talk about that. Partial stroke testing is one methodology I'm aware of that ensures that the valves function properly or aren't stuck in place. How does that kind of a process get implemented typically in a process plant. How do you determine how often to do that? And just tell us a little bit about what's involved in that.

Thomas: It depends on the user experience, at the end of the day, because with the partial stroke test, you close the valve a little bit, and you hope that when you meet the demand, that it closes tight, at the end of the day. So, you only look [to see] if it's moving, yes or no, and then we say with a high probability it closed when we needed to close it.

And that's a little bit the point on the actuator side, at the end of the day. But the same is valid for the sensor side, because nobody wants to remove a device, from a vessel, as an example, and test it externally. And that's the point that we said, "Okay, we have to be sure that we can offer a kind of test procedure that the customer has a good feeling at the end of the day, that this kind of test procedure work very well, and detect a lot of failures.”

Keith: Can you explain a little bit more how in-situ proof testing works, specifically around the instrumentation side, versus the valves? How does that work?

Howard: Well, the instrumentation, to perform the in-situ proof testing, they have a different method that you can use, such as you can do, like, a single push button on the electronic. Or, you are able to activate or trigger the proof testing, from either using your handheld device or a hard command from the logic software or from your AMS.

So, those are the first steps you can do, and then of course within the function and safety manual from the manufacturer, they provide you with all of the procedures that you can follow through to perform the in-situ proof testing.

The whole purpose of the in-situ proof testing is like what you mentioned earlier, that by removing the device, you may introduce what we call the systematic failure into the system.

So, lots of our customers or users, they are moving to more in-situ proof testing, not only are they able to make sure that the device still functions properly to meet the safety function, but also to avoid the potential systematic failure introduction to the system.

Keith: Yeah, that makes sense. Do you have anything to add to that, Thomas, from your perspective?

Thomas: Now, I want to go with one example a little bit more in detail. When you look at a level switch, for example, and Howard mentioned that we have the chance with a push button to check the functionality of the forks. I speak on the level switch fork, and then we internally simulate the different frequencies, we know exactly if the fork is covered, if we have uncovered, or if we have a failure via simulation. And we also can detect build up or corrosion with the fork. And then you have a much better feeling when you do proof testing with a push button test procedure and you don't have to do the visual inspection so often. I don't want to say you have never to do the visual inspection. At the end of the day, you want to be sure that everything is working very well, but you can extend the procedure for visual for a long time.

Keith: All about reducing risk, and if you can do things non-intrusively more often, you're going end up with a lower risk in the end. Yeah?

Thomas: Yeah, that's right. And then the next thing is for proof testing, we are working on procedures that we are able to get more information from the sensor side outside, because I want to say it's easy...we know the health status of our devices, and we give this information, it depends on the physical principle, yes of course, outside to the DCS system, for example. Then you can use this information to say, without opening or dismounting the device, how the health status is. And that's some of what we are working on. 

Howard: So maybe, I can add another example right here, like a flow meter. So, this is another challenge that the users have with the proof testing. In the past, they have to remove the device manually or within a certain period of time. Based on the calculation, they perform the full proof testing, which is dismounting the flow meter, bringing it to the calibration shop, calibrating it, bringing it back, and reinstalling it.

So, a lot of the time, a wrong setting is being reconfigured on the safety device, and they're no longer meeting the safety function. So, with that, having the institute proof testing, we can check the sensor all the way to the output. So, it's a health check of the device to make sure that we are able to uncover certain percentage of the dangers and detect the failure.

And then on top of that, we are also able to look into the potential systematic failures, such as corrosion or build-up, within a flow meter, because this is something that typically you are not able to find out by just looking into the flow measurement.

Keith: What about automated proof testing, where you maybe have some logic within the SIS that automates these procedures to do this on a prescribed basis? Is that something you're working on? Or is that widely used already, or been tested?

Thomas: Yeah, we use that especially with chemical companies in Europe. We are working on a system that we can do an automatic proof test depending on the actual level, for example, in a vessel, that we say we tested automatically in a way that nothing happened in the process right now, and we can stop for a short period, restart it and externally proof test, and we do it as often as we like to do, and nobody cares because the information of the proof test can be stored outside, and you can have really a look at it.

And a big advantage of an automatic proof test if you reduce the manpower to a minimum, and you do it every time the same way. And therefore, we use, for example, in this case, Howard said it before, the heartbeat information of a flow meter. That means the DCS system gets the request to our sensors, unlocks the device automatically, gets all the information out, locks the device again, and then we'll have all the information that the sensor sees in the process. And that can be done as much as you like.

Howard: Yeah, just to piggyback what Thomas is talking about here, so quite often times when we're proof testing the device, like I mentioned earlier, it's about the systematic failure introduction. So, by having the automated proof testing, so all the procedure is being stored within the logic software, that is going to run through all the function block, to execute those commands. So, there it's going to eliminate the potential for what we call the “human error” that is being introduced during the proof testing, so that we can eliminate those parts of the potential failure.

Keith: In the end that's what it's all about, eliminating those potential failures, right? Well, I think we're kind of wrapping up to the end of our time. Any last comments, Thomas, from your perspective? 

Thomas: We heard a lot of times that it's important to do the right calculation, and Howard mentioned that many times. I heard from a lot of customers around the globe, “yes, calculation is really important, that we know when we have to proof a device." But at the end of the day, customers have to keep in mind that systematical are really the main problem forever for the application, because they are happen over a period, and you don’t know if a device will be working tomorrow, for example, because of build-up or corrosion.

And we want to be sure, the customer has to be sure that he knows exactly the status of devices that he is using in the SIS, at the end of the day. And that's the point. The feedback worldwide is, "Yeah, we did a lot of calculations, and nobody keeps in mind that systematical are really the real problem.”

Howard: But for me it's pretty much similar to what Thomas is talking about. What I want to emphasize right here is really the safety lifecycle. Make sure that you are able to follow through the whole process, because it's critical to have the culture built in within your organization, to have the safety culture to follow through all the steps, because without that, the proper procedure, or proper design, even if you can get a good device from the market, you may not be able to fulfill the safety function that you want to achieve to reduce the risk. So that's what I would like to emphasize right here.

Keith: Great. Well, really, thank you very much Howard. Thank you, Thomas, for joining us, and really appreciate you sharing your insights in this brief podcast today.

For those of you listening, thanks also for joining us today. I'm Keith Larson, and you've been listening to a Control Amplified podcast. Thanks for joining us, and if you've enjoyed this episode, you can subscribe to future episodes at the iTunes store, and at Google Podcasts. Plus, you can find the full archive of past episodes at controlglobal.com. So, once again, Thomas, thank you.

Howard, thank you. And this is Keith Larson signing off until next time. Appreciate you guys joining us.

For more, tune in to Control Amplified: The Process Automation Podcast