Industrial machine safety is, I think we will all agree, a complex subject, and rightly so, as any subject that deals with life and limb should be. Anyone who has designed the safety portion of an industrial machine quickly realizes that it can be a confusing ocean of rules, regulations, specifications and international standards, not to mention corporate rules.
This was probably why, at least in my first-hand experience, safety systems on prototype manufacturing equipment were typically defined and designed last. I always equated this to what I envisioned was being an exhaust designer on a new car. “Here’s the undercarriage of our finished car design; please route your exhaust stuff around it as best you can.”
The typical safety systems of the not-so-distant past, and many present-day installations, were made up of a sea of hardwired single-purpose safety relays, electromechanical interlocks, e-stop buttons, light curtains and safety mats, all connected with seemingly miles of point-to-point 12-gauge wiring.
The resultant number of terminations to the required relays and devices made troubleshooting wiring issues a difficult and time-consuming task, both on the startup of new equipment and when maintaining running equipment. This is especially true on multi-zone safety implementations with layers of safety relays and associated wiring.
Additionally, the actual cause of any e-stop condition to the automation controller, and therefore communicated to the operator, could only be made through auxiliary contacts from the hardware devices, and there were not many of these built into the hardware safety devices. Determining the cause of the e-stop on a machine or production line could be a guessing game at best. Safety trumps system uptime every time.
In response, the early 2000s saw modifications to standards such as IEC 615081 and NFPA 792, which help to enable allowable safety networking requirements. As a result, multiple automation companies have introduced their own safety networking products that communicate safety data through standard fieldbus infrastructure.
Similar to how fieldbuses originally replaced home-run wiring for control signals, safety networks also reduce a significant amount of the wiring complexity of a machine safety system.
Oversimplifying somewhat, the “secret sauce” to transmitting safety data over a standard fieldbus comes down to a black-channel approach. The safety data is segregated in its own container within the standard fieldbus communication telegram. The underlying packet of safety data does not rely on the physical or protocol layers of the fieldbus to be valid. The three ingredients for this approach are the following:
1. additional cyclic-redundancy checks (CRCs) in the safety data packet to detect corruption of safety data
2. data packet counters to detect missing packets of data
3. watchdog timers in the networked devices that are reset with each telegram.
These three mechanisms allow the creation of the black channel, allowing safe data to be transmitted over the same network as other non-safe traffic. Additionally, no modifications are needed to the upper-level network, and the safety packet can be passed from protocol to protocol, as long as the above three error-detecting parameters are satisfied.
The hardware benefits are immediately evident: less wiring means fewer terminations, which both result in cost savings. Fewer terminations result in easier troubleshooting. Safety devices now have a standard, simple fieldbus connection, and, internally, each device can service safety data into the black channel, while also copying the same or similar information for the automation controller to be made aware of individual safety inputs. Instead of just knowing that the machine has an e-stop button depressed somewhere, now the controller can indicate which e-stop is depressed.
One additional major benefit is in the area of drives for rotating equipment, robotics and linear actuators. In 2006, IEC 61804-1 introduced a number of safe motion functions for drives. For example, instead of just dropping mains power to a motor on e-stop and having it coast to a stop, now a drive and motor can be commanded to safely stop, go into a predefined safe-torque mode or move at a predetermined safe speed. Not only do these safe commands happen as the result of an e-stop, but they can be part of normal operations.
Now, for instance, a human can enter a robotic enclosure without having to power down the robot. The axis drives can operate in a safe-torque mode which prevents injury to the person in the enclosure, but the robot can still perform its function.
Initially, each of these commands was assigned to an individual hardwired input to the drive. This, again, required additional wiring, terminations and points of failure into the safety system. The market was quick to respond with drives that are themselves safety devices and can use the black-channel data to receive these safe commands via the same fieldbus connection that it receives motion data on. These same safety commands are being designed into additional devices such as stepper motors and variable-frequency drives (VFDs).
Because the same fieldbus, I/O, drives and safety devices can communicate on our same chosen fieldbus, the definition of the safety schemes and selection of the safety devices can occur earlier in the design phase of a new machine line. Okay, maybe that’s theoretical. At the worst, the safety team doesn’t have to be the last in line in the design cycle, trying to figure out how to shoehorn in a safety system into a finished design.
