Integrated Safety: Has its Time Arrived?

LINKS

Control Engineering hosts two Twitter feeds at: https://twitter.com/controlengtips and https://twitter.com/djgreenfield

Sidebars: Editor’s note on user-generated content

The first discussion topic from our social media groups that we have chosen to feature in the pages of Control Engineering is a heated one—integrated safety. For years now this has been an ongoing discussion among the engineering community as more and more automation functionality is integrated into control devices and control devices are integrated into automation (e.g., mechatronics). While most such integrations clearly improved functionality and have been largely welcomed by the industry, the issue of safety integration on a controller has received a different reception.

Very quickly, separate camps evolved around this issue—and they formed nearly along the same lines as such camps tend to around a political issue or party. One camp is clearly for the idea of integration, while another camp is clearly against it. The third camp—we’ll call them the moderates—think the idea of safety integration has potential, but often seeks to clarify the term “integration” or defers to standards to guide their safety implementations.

The discussion that frames this article began on Control Engineering’s social media groups after a link was posted to a blog posting by Charlie Fialkowski of Siemens on Safetybase.com . Here’s what Charlie said in his blog:

“I believe that one day it will only take one control system to automate your critical process. That’s right, there will be a day where it is commonly accepted that a single platform can and will provide both control and safety shutdown operations. The system themselves will be able to provide the logical separation necessary to comply.

“However, before this comes to fruition, it will take much work on system manufactures to provide a hardened platform that is both capable and reliable to take on this responsibility, and even more importantly plant owner/operators to have the diligence to instill complete safety lifecycle procedures at their facilities. Some manufactures may argue they’re already there.”

Comments were quickly posted to our groups clearly in favor of the integration idea.

Ed Diehl, Concept Systems

“I agree with Charlie’s basic premise. Smart safety is where things are going,” said Ed Diehl , co-founder and executive director of Concept Systems Inc. Clarifying his position, Diehl noted that “smart safety” refers to “high integrity, programmable safety systems that also minimize downtime and production losses. Integrated platforms are a great way to provide this capability.”

Mark Sutton, Stamping Support

Mark Sutton , president at Stamping Support Inc., mentioned that the ANSI B11.1-2001 standard addresses the topic of what is needed in a single control in “Annex D-Design considerations for power press controls, and in Annex E-Design considerations for micoprocessor based clutch/brake controls.”

“I would love to see them integrated some day,” said Sanoj James , senior technical manager, SBG Applied Materials India. “It’s hard to design a line with the safety PLC handling safety functions and the regular PLCs handling the rest. Though many manufacturers provide safety components that can sit on the rack with the regular PLC components, the biggest issue I have come across is the safety field bus. It does not allow you to write to a safety component over the safety bus because it allows only a read action. For example, if I were to use a safety-rated ASi bus along with a safety PLC and power supplies, the inputs can be read over the bus but we cannot write to the outputs over the same bus.”

S. Hamza Habeeb, an engineer on the Facebook group added, “One of the refineries I’m working on in Pakistan as a system integrator has chosen to integrate safety and control on a Honeywell distributed control system. Habeeb notes that while he initially had reservations on keeping emergency shutdown and control in one system “since this was not the traditional approach,” he says that the client thinks otherwise and they are deploying the system in an integrated fashion. Though he is onboard with the decision, he remains a bit cautious. “Let’s see how it goes, but for my part, I’m not convinced until I see an actual system running with this configuration,” he added.

Against the concept

Though some members of the social media groups clearly see integration of safety and control as a feasible, if not inevitable goal, others were just as decidedly against the concept.

James Loar, Ciba Specialty Chemicals

James Loar , application support and business process management at Ciba Specialty Chemicals, said, “While functionally it [safety and control integration] is technically feasible, I thought the idea was to avoid a situation for a single/common point of failure. This should not only include the hardware, but also the software development as well.”

By keeping them separate, “you are not dependent upon one programmer’s style (logic process methodology in a system) that may be flawed in a way that causes a failure (for example, program branching methods),” Loar noted. “The same concept is applied to redundant instruments; you don’t put in two of the same kind of level sensors for tank overflow; so both are not affected equally by an external influence (like cold weather).”

Craig Dickson, AGR Automation

Craig Dickson operations manager at AGR Automation Ltd., concurs with Loar’s concern about programming. “You cannot rely on programmers’ logic to ensure safety,” he said. Based on his experience in the industry, Dickson says that “safety PLCs, like all programmable logic, can be circumvented.”

“In real terms, safety of machinery and EN directives used to require the safety system to be separate and autonomous from the main control system,” added Dickson, who noted that this separation was required because it simply is safer. “Smart, programmable safety monitoring does have many benefits as an addition to a separate autonomous safety system, but not as a replacement,” he said.

Vendor influence?

Most of Control Engineering’s social media group members who disagreed with the idea of integrated safety did so on a general technology and/or safety basis. Some members, however, weighed in with their opinion that this issue is being driven by vendors pushing new technologies, rather than arising from a genuine industry need.

“What is the advantage to single platform [for safety and control]?” asks Victoria Woosley , senior project engineer at Patheon. “A purpose-built device or controller, specially designed for safety protection, can be more functional and less costly than integrating that same functionality into the general purpose automation controller. Interoperability, intercommunication, and lots of redundancy is more functional, safer, and cheaper for those of us who are customers.”

Woosley contends that the arguments in favor of safety and control integration are “no more than an extension of the arguments that all the big automation vendors have made for the last 15-20 years in order to lock customers into their platforms and lock the competition out.”

Ashok Johnson, consulting automation and control engineer

Ashok Johnson , P.Eng., TÜV FS Eng., and consulting automation and control engineer, agrees that this is a vendor-led discussion. “This discussion is strictly of vendor interest,” he said. “If a customer wants to go with a ‘proven in use’ system for their safety system, we cannot blame them. The common platform also increases the possibility of common cause failures.”

Two questions users should ask themselves when it comes to integrated safety, according to Woosley, are: “Do you really want every new feature you need for high-speed control held up for months or years while proper testing ensures that it won’t compromise the safety features? Or do you want to give up needed new features because you can’t be sure the new software/hardware won’t harm the safety functions?”

Who’s right?

Though arguments over the concept of integrated safety have been raging for years, has any sort of consensus been reached that would helpful to end users? Unfortunately no—not at least from an apparently unbiased source.

Thus the debate rages on. Despite this tension, several nuggets of wisdom from the moderate side of the discussion appeared frequently on the social media groups to help users better develop their own opinion on the issue.

According to Koen Verschueren , owner of integrator firm 2B@SiX, “EN directives don’t allow you to integrate safety in a control system. You can use a safety PLC from Siemens or other supplier where you can mix standard I/O and safety I/O, but a separate program still controls the safety functions.”

In essence, since the hardware platform is the same, Vershueren says that the ability to use signals from the safety program in your control system makes for easier monitoring and alarming. He also points out that using a separate safety system, but housing it in the same hardware as the controllers, requires dedicated data communication. “Beckhoff has safety blocks that can be integrated with their control I/O,” he says. “But those I/O blocks are controlled by a separate safety program with functions tested and approved for safety applications.”

Other group members suggests a close review of IEC 61511 volume 1, chapters 10 and 11, for instances where integrated safety can work up to SIL 1 or 2 levels, if the control system is specifically designed for safety functions. In this area of discussion around IEC 61511, it was pointed out that total safety integration is not possible if you also take into consideration security requirements.

Simon Gibson, SGA

“Introducing the PLC as a means of safety monitoring and control should be treated with caution,” said Simon Gibson , president at SGA. “The logic blocks and the hardware also have to be proven and approved. My approach is to use the PLC to monitor the safety circuit to provide information for control purposes. But the safety circuit should be implemented with a proven safety relay system. Each emergency stop actuator can provide an additional signal to the PLC. I keep the safety circuit schematics on a separate page so trouble shooting is easier; especially when many safety points are being monitored. Furthermore, integration into neighboring systems should be carefully considered and using proven, readily available safety control relays makes this task much easier at installation stages.”

Two vendor representatives also weighed in on the moderate side of the debate. After first noting that being the DeltaV SIS product manager at Emerson Process Management makes him feel as if he’s “jumping into a hot pot of oil” by joining this discussion, Mike Boudreaux proceeded to offer the following helpful advice:

“An integrated control and safety (ICSS) platform that uses common hardware and software components is very

different from an ICSS that has components that provide physical separation, diverse components, and independent SIS logic solver hardware,” Boudreaux said. “Most of the [integrated safety] debate has focused on the extreme case of commonality, without proper attention to the concept of an integrated platform that also provides separation. An integrated platform (per the ARC definition delivered in its ‘Business Issues Driving Safety System Integration’ whitepaper ( https://is.gd/1rbXU ) is somewhere between the stand-alone and common platforms, providing the best of both worlds.”

Boudreaux explained how this is handled in Emerson’s Delta V controller. “DeltaV SIS has an entirely different hardware design from the DeltaV hardware used for control. DeltaV SIS logic solvers use the Green Hills Integrity operating system, which is different from the DeltaV controller operating system. Therefore, the DeltaV SIS function blocks are different from those used by DeltaV for control. SIS communications are on a physically separate bus. The integration of DeltaV and DeltaV SIS is at the operation, engineering, and maintenance layer. Physical separation, diversity, independence, and common cause concerns are addressed with the integrated yet separate architecture of DeltaV SIS.”

David Arens, Bosch Rexroth

Agreeing that an integrated approach could achieve project goals designed after a risk analysis, David Arens , an applications engineering at Bosch Rexroth, adds that he has heard of so many companies coming out with their own ideas of a safety fieldbus that, as a person responsible for integrating safety into automation projects, he’s more than a little concerned.

“To sleep at night, I have to know that all the components of my safety system will work together to achieve SIL 3 safety,” Arens said. “[Ultimately,] the solution must provide the ease of integration and validation of the risk assessment and safety to everyone that may come in contact with the machine.”

Arens added, “A PLC will not stop shrapnel from going through a light curtain, and the PLC is not the actuator to the gate, but it may monitor the safety condition and respond. The motion actuation devices themselves need the intelligence to handle unsafe conditions and be designed in such a way that, regardless of fieldbus, PLC or manufacturer, they all function in a safe manner.”

Safety networks provide integrated industrial connectivity

Information about intelligent safety networks follow. Also, search “safety networks” atop www.controleng.com for related articles.

Source : Control Engineering

AS-Interface Safety at Work (ASIsafe)
https://as-interface.net/System/Safety

CIP Safety
www.odva.com

Interbus Safety
www.interbusclub.com

PROFIsafe
www.profibus.com/technology/functional-safety

SafetyBUS p Pilz
www.safetybus.com

Author Information

David Greenfield is editorial director of Control Engineering. Reach him at david.greenfield@reedbusiness.com , or via Facebook or LinkedIn.

Editor’s note on user-generated content

Control Engineering has experienced an unexpected success in attracting industry professionals to its social media groups on Facebook and LinkedIn. Nearly 6,000 members have joined the groups in just their first several months of existence. The high level of interactivity by the groups’ members has led to a continuous stream of spirited discussions across the sites.

While regularly reviewing the discussions taking place on the group sites, we found that the keen insights and opinions shared in the course of topic discussions were not only informative, but often entertaining. That’s why we are extending the discussions from our social media groups to Control Engineering ’s printed page and our Website—so that all members of our audience can view these discussions and weigh in on them.

Starting in January 2010, we will feature selected discussions from our social media groups every other month in the print issue and online at www.controleng.com .

If you have not visited our online social media groups before and would like to see what they’re all about, follow these links:

Automation & Control group on Facebook https://budurl.com/CEFacebook

Automation & Control Engineering group on LinkedIn https://budurl.com/CELinkedIn

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.