Motion Control & Motor Association Logo

Member Since 2006


The Motion Control and Motor Association (MCMA) – the most trusted resource for motion control information, education, and events – has transformed into the Association for Advancing Automation.

Content Filed Under:

Motion Control Component Manufacturing Motion Control Component Manufacturing


Integration Boosts Safety Performance

POSTED 04/20/2017

 | By: Kristin Lewotsky, Contributing Editor

There was a time safety systems were safety systems and machine controls were machine controls, and never the twain shall meet. Today, that philosophy has changed. The metamorphosis began with functional safety, which introduced a systems-level approach to maintaining controlled conditions. It continued with the introduction of intelligent components and communications protocols that made tighter integration of safety and controls not only possible but desirable. In the modern factory, this trend provides new opportunity to both safeguard worker health and boost productivity.

The task of safety equipment is to detect anomalous behavior by human operators or machines and act to bring the equipment to a known safe state until that condition is corrected. In the traditional approach to safety, safety resides in the components. Sensors provide input to hardwired safety relays, contactors, and interlock circuits. Those devices cut the power any time specified conditions are violated.

Traditional safety systems have often had ambiguous associations for operators and technical staff. Their goal is to maintain productivity. Safety measures that require line stoppages impact that productivity in a way that can prompt staff to try to find a workaround. Consider a situation in which a carton falls off of a conveyor belt inside an enclosure. Retrieving it to prevent a jam requires opening the enclosure, which stops the line and cuts production. If this happens often enough, a staff member might be tempted to rewire a relay to prevent line stoppage when the enclosure is opened. The problem is that now engineering falsely believes that area is safe when it is not – and sooner or later, someone is likely to get hurt.

These types of issues particularly arise in today’s manufacturing environment, which is marked by frequent changeovers that require machine access. Cleaning and maintenance steps can also require line shutdowns that can lead to lost productivity or workarounds by well-meaning staffers. These factors contributed to the change in safety philosophy.

“Factories in the past had mostly fixed machines and ran a consistent product,” says Tina Hull, Product Engineer – Safety, Omron Automation Americas (Hoffman Estates, Illinois). “The trend has been to create more flexible environments to meet the need for product variation. When safety hinders the operator’s ability to perform their job, it leads to cases where barriers are removed and never reinstalled. Much of our current safety control technology is the result of industry’s need for easier ways to access the equipment.”

Safe Function
Functional safety arose as a method for ensuring that the overall operation of equipment is both productive and safe. Instead of safety residing in a component like a barrier or a relay, it is implemented in the operation of the system, through the use of safety-enabled drives and controllers. This enables more nuanced functionalities such as Safe Limited Speed (SLS), Safe Direction (SDI), and Safely Limited Increment (SLI; see Sidebar). Safety is no longer a response (cut power) but a process (only move within this envelope, don’t operate above this speed).

Functions like SLI and SDI can enable staff to clean rollers while they are moving, for example, because the rollers are constrained to only move in ways that will not cause injury. In our carton example, opening the enclosure might simply cause the line to slow down to a safe speed while the carton gets retrieved. This can reduce cleaning time by hours. As a result, functional safety doesn’t just protect operators and maintenance technicians, it improves productivity.

This has been the experience of organizations in Europe, where adherence to functional safety standards like IEC/EN 62061 and ISO 13849-1 is mandatory. “They have to have safety,” says Joaquin Ocampo, Product Manager at Bosch Rexroth (Hoffman Estates, Illinois). “What they have noticed is that production actually increases. You have safety for all of the people around the machine and your uptime is greater, your productivity is higher, and your scrap is less. This is where you capture people’s attention.”

Know the Code

A few of the more common functions supported by safety-rated drives and controllers:

  1. Safe Torque Off (STO): Removes power to the motor but leaves the drive energized for fast restart.
  2. Safe Stop 1 (SS1): Active braking for equipment with high kinetic energy; prepares for STO.
  3. Safe Operating Stop (SOS): Drive holds motor at zero speed without removing torque.
  4. Safe Stop 2 (SS2): Controlled braking ramp for equipment with high kinetic energy; prepares for SOS.
  5. Safe Brake Control (SBC): Controls an external holding brake; typically for motors holding loads on vertical axes.
  6. Safely Limited Speed (SLS): Sets a maximum speed.
  7. Safe Direction (SDI): Restricts direction of motion.
  8. Safely Limited Increment (SLI): Limits motion increments to support jog operations.

Key Safety Standards

A variety of safety standards exist, but those listed below define core aspects of functional safety for motion control systems:

  • IEC EN 61508: Primary functional safety standard, defines safety integrity level (SIL) framework.
  • IEC 62061: Machine-based functional safety standard for safety-related electrical, electronic, and programmable electronic control systems. Describes the implementation of IEC 61508 for different application sectors and machine designs.
  • ISO EN 13849-1: ISO version of functional safety standard. Defines safety performance level (PL).

- K.L.

How Safety Systems Work
Safety-enabled components are designed for redundancy and reliability. Drives and controllers feature dual-core processors to have two different ways to process the data. Safety-rated encoders feature both digital absolute and incremental analog sensors in order to record data over two separate channels. When the signals arrive at the master device, whether drive or controller, each will be analyzed by a different core.

Simply having two cores is not necessarily enough, however. If the same microprocessor is used for both channels and it has an interpolation error, this impacts the safety mission. In order to eliminate common-cause failure, the chips themselves need to be different. “You use either dual channels or channels that are looking at different paths,” says Hull. “For instance, the safety controller in the CPU actually has two microprocessors, and not only does it have two microprocessors but each operates in a different way. That way, if there is some type of issue that can cause a failure with one of the microprocessors, the second processor should catch the failure and still stop the machine in a safe state.” Those processors may not only be of a different type but from a different vendor entirely.

Safety controllers include internal checks designed to verify that the equipment in the system is installed and operable. These checksum codes are unique to each program, making it easy to detect changes. Adding permission limits user access by job role. Engineering staff can modify the program while maintenance can only view the troubleshooting screens, for example.

Figure 1: In safety system, the safety controller shares a backplane with the machine controllers/motion controller. This enables the safety controller to communicate over the backplane with the drives via an ethernet-based safety protocol. The individual sensors also use the backplane to get the Safe Inputs/Output to and from the Safety Control Connected to the PLC/Motion control. So in a way it does bypass the motion controller when a safety input is acquired. (Courtesy of Bosch Rexroth).There are nearly as many safety implementations available as there are vendors in the marketplace. To get an idea of how the process works, though, let’s consider a basic system. A general safety system has four elements: sensors, a safety controller, a machine controller/motion controller, and a safety-enabled drive. In normal operation, the machine controllers/motion controller sends commands to the drive to move the motor and the load as programmed (see Figure 1). Meanwhile, the safety sensors (light curtains, barriers, pressure mats, encoders etc.) feed their data to the safety controller. The safety controller logic enables it to process the input from the various sensors and determine an appropriate response. In the event that a condition is violated, the safety controller sends commands to the safety drive to adjust to a safety function mode as required or bring the machine to a known safe state. Those commands supersede the regular machine-control commands. The safety controller continues to monitor the encoder output while it is in a safety mode to ensure compliance.

The safe-motion functions themselves are executed by the drive through its control of the motor. Safety-enabled drives feature integrated functions like Safe Torque Off (STO), SLS, and SDI. Implementations vary widely. Some drives may only offer STO while others may feature more than a dozen options. System-level feedback techniques may vary as well. In some systems, encoder feedback is routed to the safety controller for processing before the safety controller sends commands to the drives. In the case of safety drives designed for distributed safety implementations, the encoder feedback is routed directly to the drive, which uses it to execute the controller commands. At this point, the drives are able to monitor motor operation to ensure compliance. This approach can result in faster operation.

The paragraphs above describe a basic framework but many variations exist. For very simple systems, a safety-enabled drive might be sufficient. In that case, there frequently is no programming involved, just a process of configuring the parameters in the drive. More complex systems with a large number of devices and sensors involved in each decision will require a safety controller to process the logic. Occasionally, the architecture might combine a safety-enabled controller with standard drives, but more frequently they are safety-enabled drives. The safety controllers can take the form of PLCs, programmable automation controllers (PACs), motion controllers, or PCs.

Hard-wired systems suit some applications. For more complex designs, a standalone safety controller may be linked to the machine controller/motion controller and drives on the same fieldbus. This brings us to the topic of integrated controls and safety.

Integrating Controls and Safety
Integration takes place at the communications level, the software level, and, increasingly, the hardware level. The approaches streamline implementation, enhance performance, shrink footprint, and speed troubleshooting.

The lowest level of integration is integrated communication over a shared fieldbus. Whether it involves the machine network or industrial Ethernet, using a common communications channel can pay big dividends. “In both situations, with centralized safety or decentralized safety, the fact that you are using a safety protocol over Ethernet, say for example: CIP Safety over Sercos, allows all of the data to be available to the motion/PLC control,” says Ocampo. “It also reduces your wiring, because all of the safe data is run over one Ethernet channel. This means that the control has access to safe data and non-safe data. This makes it is easier to program, commission and trouble shoot because all the status data is available for the programmer.”

Although there was initially concern about routing safety traffic over the network, all of the primary industrial Ethernet protocols have associated safety solutions designed to prioritize essential communications (see Understanding Motion Control Networks II: Safety).

The safety controls are still separate from the regular motion controls but there are layers of overlap that add to usability. In many offerings, the motion control and safety software share either the same layout or even the same interface. This adds continuity for the OEM and, more important, for the end user.

Higher levels of integration on the software side improve system responsiveness. “One thing we are finding is the more integrated the motion and the safety software get, the higher the performance because now there can be faster communication between them,” says Hull. “They don’t have to go through other networks or couplers and so forth to communicate. Users can get faster response times, which can increase production or reduce the distance for their safeguarding.”

It can also streamline programming. Hull points to variables like the reset button or the start command that need to be mapped to both the motion side and the safety side. If the software package can automatically re-map them to the motion application once they are defined in the safety application, it reduces error and saves time. “One of the biggest efficiencies that I have seen is that we only have to map our variables once,” she says. “Once they are set up on the safety side, those variables can automatically get re-mapped over to the motion side. It’s an easier way to get the system up and running. It also reduces the chance of having variables mislabeled or incorrectly defined.”

These types of errors can significantly impact troubleshooting. “In the past, if you didn’t get them quite right, maybe your HMI wasn’t giving you the best direction on what actually caused a shutdown, the motion system or the safety system,” she says. “Maintenance would go through all the safety stuff to try and figure it out and then would discover it was because the motion side was really just waiting for a command for something simple. Now, since it’s all integrated, when the system goes down, the troubleshooting is on just one screen.”

Integration also takes place on a physical level. Some safety PLCs are designed to share a backplane with the machine controller/motion controller, using the backplane to communicate to the drives via an Ethernet channel like CIPSafety over Sercos or ProfiSafe over ProfiNet (see Figure 1). , or over the same Ethernet channel. In this slide, the I/O is not directly connected to the control, they are decentralized, connected to the control through an Ethernet channel such as: CIP Safety over Sercos or through a fieldbus using ProfiSafe over Profibus. As you could see this would also use the backplane to get the Safe Inputs/Output to and from the Safety Control Connected to the PLC/Motion control. So in a way it does bypass the motion controller when a safety input is acquired.

The next level of integration involves units that combine the safety processor and the controls processor in a single controller. The two are still separate at a chip level but they are available as a single integrated device that meets safety standards. This brings the benefits of reduced footprint, reduced wiring and increased performance as a result of the overall integrated environment.

Although there will always be a place for standalone systems, the trend toward integration only promises to continue. To take advantage of the technology, OEMs and end-users need to plan ahead in order to put the interlocking parts in place. “One misconception is safety is like the icing on the cake and they want to put it on after the machine has been designed, but it has to be considered from the start,” says Ocampo. “That will make everybody’s life so much easier.”