For a long time, functional safety maintained its priority over control to stop operations in the event of a fault or safety issue. Disconnected machines and systems, proprietary, closed protocols and brand-dependent systems kept control and safety separate, but increased computing power and data analytics have made system response times faster and allowed them to coexist on the same network.
The evolution of ICS
“Safety and non-safety are converging,” says Christopher Woller, safety product manager at Beckhoff Automation. “Automation portfolios are evolving such that all functionalities are integrated into the overall control system—from HMI to measurement technology, IoT, vision, PLC and motion through to safety. Integrated control and safety (ICS) effectively end the historically strict separation of safety and non-safety technologies.”
The United States has been on the slower side to embrace safety PLCs and safety fieldbuses, Woller says. First released in 1997, the National Fire Protection Association (NFPA) 79 standard restricted machine safety to electromechanical devices, and, in 2002, when NFPA 79 incorporated International Electrotechnical Commission (IEC) 61508, safety PLCs were permitted. “Only in 2007 did NFPA 79 allow variable-frequency and servo drives as the final switching device in safety functions,” Woller says.
Safety systems have evolved from individual devices to centralized safety networks (Figure 1). “Modern safety technology therefore covers a very broad range of tasks, with appropriate safety solutions required in all areas of automation,” Woller says. “Most recently, safety technology has evolved beyond standalone architectures and even centralized safety control with distributed I/O and functions, to incorporating logic into all components in a system. This allows simple applications to preprocess data and specialized safety functions, reducing the complexity of the central safety application.”
While an ICS system is all about connecting safety and control, Michael Warren, product manager of safety components and safety controllers at Omron, notes, safety still requires some separation from control. “Although safety is in the same platform, it requires a separate safety CPU, communication modules and I/O cards,” he cautions. A common software platform allows operators to switch between safety and control. “It’s together but separate,” he explains.
Advances in processors and processing power are, in part, what makes integrated control and safety possible. “We now have processors that are failsafe PLCs rather than safety processors and PLCs,” says Mark Russell, tech application support manager at Allied Electronics & Automation. Early CPUs had some failsafe memory but generally weren’t for safety, other than recovering from faults. “Now, we have failsafe PLCs that really allow you to program the actual safety code on top of the PLC,” Russell says. A separate processor within the same unit processes safety code, so it maintains priority.
What is ICS?
“ICS components work together to ensure that the machine, process and operators are protected in the event of a machine or process having a safety fault,” says Noah Greene, product specialist for safety at Phoenix Contact.
Before safety networks, hardwired safety relays used simplified logic for basic safety functions. “The inputs and outputs are wired directly to the safety system and processed. This method works well within a smaller machine footprint or when there is not a large variety or amount of safety inputs,” Greene says.
Figure 2: Hard-wired safety solutions require many wires, and a single wire is employed with a safety network. (Source: PI North America)
Now, via Ethernet or another industrial communication protocol, a safety network can connect various safety components. “This allows for reduced wiring overall by placing the I/O modules closer to what is being monitored,” Greene says. “The safety logic takes over only when there is a safety fault, such as a guard door being opened during normal operations or a motor going out of its allowed speed range.”
Code designers simplify how the system will handle faults from the identified risks in the process and write code to perform the appropriate safety function. “Within the IEC 61131 standard, generic function blocks could be written and shared across many machines where similar safety risks are likely to occur,” Greene adds.
A safety network provides a cost savings from the large reduction in needed hardware, Michael Bowne, executive director at PI North America (Figure 2). “Safety-by-wire solutions require many wires being ‘homerun’ from the field to a cabinet. Terminal strips and marshalling racks are then often needed. Finally, the solution is implemented via many relays to perform safety mechanisms. In safety networks however, a single wire is employed, fewer, if any, terminal blocks or marshalling racks are needed, and instead of performing safety via relays, the safety is done in logic, in other words, in a Programmable Logic Controller (F-PLC),” he adds.
An integrated control and safety system bridges safety and operations systems, says Rudy de Anda, head of strategic alliances at Stratus. “However, the safety components—controllers and sensors—need to continue operating independently of the control systems to ensure that, if a machine needs to be stopped, an operator can step in to do so,” de Anda says (Figure 3).
Figure 3: An integrated control and safety system bridges safety and operations systems. (Source: Stratus)
The move from analog wire relays to digital systems, or networks, for communicating between field devices and logic controllers helped to eliminate some wired applications that were cost-prohibitive and made systems easier to troubleshoot or integrate with the control system when there were issues. “With digital networks, companies can network their safety and control systems so that operations shut off if safety systems are out of place,” de Anda says.
Bowne of PI North America outlines the four basic components of an ICS: the safety input, for example, an e-stop button or a light curtain; the safety network that ensures the safety message gets back to the controller; the controller, typically an F-PLC; and a device that may need to act in response to safety messages, typically a robot or drive.
Functional-safety protocols use a technique known as the black channel principle, Bowne says, meaning the protocol is solely responsible for ensuring safety messages get from one end of the network to the other (Figure 4). “The underlying transport or physical layers are unimportant. The only thing that matters is that the safety message sent by the light curtain is received by the F-PLC, for example,” Bowne says.
Figure 4: The black channel principle for functional-safety protocols is responsible for ensuring safety messages get from one end of the network to the other. (Source: PI North America)
