An integrated control and safety (ICS) system is a centralized architecture that combines basic process control and safety control measures into one system. Some may argue that safety has always been integrated, since controls engineers used to wire safety relays directly into the feed that provided a machine with control power. What is the No. 1 thing needed to turn a machine on? Control power.

No safety circuit, no control power, no outputs, because the control power relay was in the circuit that sourced the programmable logic controller (PLC) outputs.

More complex systems like burner management systems would have a systems engineer build a duplicate rack and if anything failed in the one rack, it would fail over to the secondary rack. Typical machines did not take it that far, but sometimes the relays for safety were quite complicated just to control power.

Systems progressed to smart relays. Now systems use integrated input output cards and safety PLCs. But how did we get here?

Prior to getting integrated safety I/O, motors and encoders used three cables. Drives did not have safe torque off (STO) feedback. Drives have progressed to safe torque off functions, and encoders for motion systems do not require three cables any longer. Why did we used to require three cables?

There was a cable for motor feedback. There was a cable for encoder feedback. Can you guess the third?

There was a cable for auxiliary or safety feedbacks to include motor thermal sensors, brake control, external limit switches or safety interlocks to prevent overruns. Signals could not be mixed due to noise, response speed, voltage differences and certification restraints. Now, the power cable can be used for power, braking and thermal sensing, to name a few.

The feedback cable may have position feedback, velocity feedback, temperature monitoring, motor nameplate data, diagnostics, safety position and commissioning data. Digital encoder protocols allowed engineers to pack a bunch of things into one cable. But that’s another topic for another time.

The reason for discussing the shift from three cables to two in motion systems is that these technologies also impacted the integrations of safety into one architecture and its inclusion in the PLC platform. Protocols allow cyclic redundancy check (CRC) protection and time-stamped data, meaning that, though safety is included in the architecture of a control system, safety functions have their own path and can be deterministic much the same way when safety functions were wired separately, isolated and verified by external devices. When engineers found they could separate the data and save a cable for motion systems, yet still provide functional safety, then they applied the same ideas to I/O, and PLCs.

Why? CRC protection, sequence checks, timestamp verifications and a safety run time system that is password protected internally on the PLC. This is why, when a safety component is changed on a safety network, then the safety PLC has to “resync,” if you will, with all of the components and register the new device. Thus, each safety component has an individual identification.

Components are on the process network, but logic can be isolated, meaning that a runtime process can be constantly checking safety while the machine goes through process logic, but do so on an integrated architecture.

For functional safety, this means increased response times. This also means that the safety system may be modularized the same as the PLC functionality. Motion functions or robot cells or human machine interface stations all rely on protocol feedback that allows the safety function to be monitored over the machine network. Each function is allowed clear communications.

Get your subscription to Control Design’s daily newsletter.

Integrated safety systems would not be possible except for the motivation to reduce cables in motion systems. Heidenhain’s EnDat 2.2 tracks safe position. Sick’s HiPerFace DSL allows for safe position and safe speed. BiSS-C Safety is an open protocol with SIL 2/SIL 3 extensions. These allow for motion feedback data to be exchanged between drives and controllers for SIL-rated safe limited speed, safe direction, safe position and safe torque off.

Once the encoders could deliver SIL-rated data, then fieldbus safety protocols emerged. This includes fail safe over EtherCAT (FSoE), ProfiSafe and CIP safety. Because of these protocols, controls engineers can run safety on the same networks as process I/O. Safety I/O is CRC checked, sequence verified, time bounded, redundant and certified. What emerged from this is the ability to have a safety PLC that can orchestrate whatever safety configuration is needed for the machine to run. The caveat is that a component cannot be from, say, ACME PLC company.

Safety components are certified by independent, accredited functional safety organizations, not by the manufacturers themselves. These bodies evaluate products against standards such as IEC 61508, ISO 13849, IEC 62061, IEC 61784-3 and IEC 61800-5-2. The most recognized safety body is Technischer Überwachungsverein (TÜV). Safety PLCs, safety terminals, safety encoders and safety drives must be certified to:

• IEC 61508 (SIL 2/SIL 3)
• ISO 13849 (PL d/PL e)
• IEC 62061 (SIL claim limit (CL))
• IEC 61800-5-2 (safe motion functions)
• IEC 61784-3 (safety fieldbus protocols).

The certifying bodies validate:

• hardware architecture
• diagnostic coverage
• failure rates (probability of dangerous failure per hour (PFH) and average probability of failure on demand (PFDavg))
• safe state behavior
• protocol integrity (CRC, sequence counters, watchdogs)
• software development processes
• safety manuals and failure modes, effects and diagnostic analysis (FMEDA) reports.

This is why safety components can legally claim SIL or PL ratings. Engineering a safety architecture on an integrated controls network means the engineer should understand which components are allowed to create a safe system. This is critical when upgrading brownfield systems or doing a retrofit because the safety may be partially hardwired and partially in a safety PLC during integration, until all of the hardwired components can be migrated. If the integrator doesn’t pay attention to the hardwired safety and connect it to the safety PLC, then the system safety may fail. Like all things safety-related, it’s costly and tenacious, but if it were easy, everyone would be a control systems engineer.