Safety PLC

What is a Safety PLC

A safety PLC is a programmable logic controller engineered, tested, and certified so that a fault inside the controller does not cause a dangerous loss of the safety function. It executes the logic of safety functions: stopping a machine when a light curtain is broken, holding a press open until both hands press their buttons, isolating energy when an interlocked guard opens, or shutting down a burner when flame is lost. Standard process variables such as pressure, temperature, and flow are still measured by ordinary field instruments, but the decision to bring the machine to a safe state is the job a safety PLC is licensed to perform.

The defining difference from a standard PLC is not the application program but the device itself. Inside a safety CPU, two diverse processing channels run the same logic and compare results on every cycle, a hardware watchdog supervises program flow, and the firmware continuously tests RAM, flash, and the input and output drivers. When any check disagrees, the controller does not guess: it drives its safe outputs to the de-energized state, which for most machinery is power removed and motion stopped. This behaviour is why the de-energize-to-trip principle is fundamental to safety I/O, and why a broken wire reads as a demand for safety rather than as a silent failure.

Equally important is that the whole signal chain is certified, not just the silicon. The hardware carries a notified-body certificate, typically from TUV Rheinland or TUV SUD, against IEC 61508. The firmware version is fixed and listed in a safety manual. The programming environment runs a separate, protected safety task whose code is signed so that standard logic cannot corrupt it. A standard PLC, however well written its program, provides none of these guarantees and therefore cannot be claimed for a safety function under the harmonized standards.

Programmable safety has a clear industrial history. Through the 1980s, machine safety was built from electromechanical safety relays and contactors wired one function at a time, which was reliable but rigid and bulky. In the 1990s, the first programmable electronic safety systems and configurable safety relays appeared for process and machinery duty. The publication of IEC 61508 in 1998 gave a common quantitative framework for functional safety of electrical, electronic, and programmable electronic systems, and its machinery sector standards IEC 62061 and ISO 13849-1 followed. From the 2000s, integrated controllers that run both standard and fail-safe logic on one CPU and one network, such as the Siemens SIMATIC F and Allen-Bradley GuardLogix families, became the mainstream way to deliver machine safety.

Four engineering attributes determine whether a safety PLC fits an application: the safety integrity it can claim (SIL and Performance Level), its hardware architecture and fault tolerance, its safety response time against the machine process safety time, and the certified safety network it speaks. These four, more than raw scan speed or I/O count, decide both whether the controller is admissible for the function and how it will behave in service.

Types and Standards Landscape

Safety PLCs split into three families by application domain, and each is governed by a different lead standard. Choosing the wrong family is a common and expensive mistake: a compact machinery controller cannot deliver the availability a refinery shutdown loop needs, and a triple-redundant process logic solver is overkill on a packaging line. The table below maps the three families to their governing standards and typical certified ceilings.

IEC 61508 is the umbrella standard, titled functional safety of electrical, electronic, and programmable electronic safety-related systems. It defines four Safety Integrity Levels, SIL 1 to SIL 4, and the quantitative targets behind them. SIL 4 is reserved for sectors such as rail and nuclear; general machine building requires at most SIL 3. The two machinery-sector standards derive from this umbrella: IEC 62061 applies the SIL framework to safety-related electrical control systems on machinery, while ISO 13849-1 uses its own Performance Level scale, PLa to PLe. For process plants, IEC 61511 is the application sector standard for safety instrumented systems.

SIL and Performance Level express the same underlying quantity, the average probability of dangerous failure, but on two scales. The table below gives the SIL targets for low-demand and high-demand operation from IEC 61508, alongside the aligned ISO 13849-1 Performance Level. Machinery safety functions, where a demand can occur many times per day, are almost always high-demand and are judged by PFHd; process protection layers that act rarely are low-demand and judged by PFDavg.

The two machinery methods reach the same answer by different routes. ISO 13849-1 builds a Performance Level from the architectural category (B, 1, 2, 3, 4), the mean time to dangerous failure (MTTFd) of each channel, the average diagnostic coverage (DCavg), and measures against common cause failure. IEC 62061 builds a SIL from the subsystem architecture, the safe failure fraction (SFF), the hardware fault tolerance (HFT), and the calculated PFHd. Most integrated safety PLCs are dual-certified to SIL 3 and PLe so a designer can document the function under whichever standard the machine or market requires.

Within the machinery families, the practical division is between configurable and freely programmable. A configurable small controller such as the Pilz PNOZmulti 2 is set up by selecting logic blocks in a graphical tool with no general-purpose programming, which is fast to validate for a fixed cell. A freely programmable safety PLC such as the SIMATIC S7-1500F or GuardLogix uses certified function blocks inside a full IEC 61131-3 environment, which scales to lines and integrates motion, vision, and standard control in one project.

Redundant Architectures and Voting

The integrity a safety PLC can claim is set first by its hardware architecture, expressed in MooN voting notation: M channels out of N must agree for the system to act or keep running. Architecture controls hardware fault tolerance (HFT), the number of dangerous faults the system survives, and together with the safe failure fraction it caps the SIL a subsystem may claim. The table below compares the three architectures that dominate safety control.

1oo1 is a single processing channel with no hardware fault tolerance. A single dangerous undetected fault can disable the safety function, so under IEC 61508 architectural constraints a Type B element in 1oo1 reaches at most SIL 2, and only when its safe failure fraction is high (above 90 percent for SIL 2, above 99 percent for SIL 3 at HFT 0). Many compact safety controllers and most safety I/O channels run 1oo1 with high diagnostic coverage to reach SIL 2 economically; a single-channel safety output, for example, is commonly rated SIL 2 and PLd.

1oo2 uses two channels, and the function stays available only while both are healthy: either channel that detects a fault or a demand can independently command the safe state. This raises HFT to 1 and supports SIL 3 and PLe, which is why the Allen-Bradley GuardLogix and Compact GuardLogix 5380 reach SIL 3 with a 1oo2 internal architecture while remaining SIL 2 capable in 1oo1. The trade-off is availability: because either channel can trip, 1oo2 is more prone to spurious shutdowns than a single channel, which matters on continuously running plant.

2oo3, the triple modular redundant (TMR) architecture, runs three independent channels and votes by majority. A single channel can fail dangerously or spuriously without either tripping the process or losing the safety function, because the other two outvote it. This gives SIL 3 integrity together with very high availability, which is why TMR is the standard for process safety logic solvers where a spurious emergency shutdown is itself a hazard and a major cost. Schneider Triconex uses a 2oo3 voting structure across all three legs; HIMA offers comparable quad and redundant structures in its HIMatrix and HIMax families.

Two qualitative inputs sit alongside architecture in every calculation. The safe failure fraction (SFF) is the proportion of failures that are either inherently safe or detected by diagnostics; raising SFF through better self-test lets a given architecture claim a higher SIL. Common cause failure, where one root cause defeats redundant channels at once (shared power supply, shared clock, a software defect, an electromagnetic event), is the limit of redundancy, so certified designs use diverse processors, independent watchdogs, and a quantified common-cause (beta) factor. Adding channels never escapes a common cause that is shared across them.

Certification, Networks, and Wiring

A safety PLC is only as trustworthy as its certificate, its safety network, and the way its I/O is wired. Certification means a notified body, commonly TUV Rheinland or TUV SUD, has assessed the hardware, firmware, and development process against IEC 61508 and the relevant sector standards, and issued a certificate naming the exact firmware version and the achievable SIL. The certificate is what lets a machine builder claim the function and pass a CE conformity assessment under the Machinery Regulation. A controller without a current certificate, or running firmware outside the certificate, cannot be used for a safety function.

The safety network is itself certified and is the reason distributed safety I/O is possible. Rather than running a separate hardwired safety circuit to every device, a safety PLC exchanges safe data with remote I/O over a standard fieldbus using a certified safety protocol layered on top. The two protocol carry diagnostic counters, timestamps or sequence numbers, a safety CRC, and a watchdog timeout so that a delayed, duplicated, or corrupted message is treated as a demand for the safe state. The table below summarizes the mainstream safety networks and the controllers that speak them.

Safety wiring follows the de-energize-to-trip principle: the safe state is the de-energized state, so removing power, or a broken wire, results in safety rather than danger. Inputs from contacts use dual channels and often a test-pulse or OSSD scheme, where the controller pulses each channel and watches for the echo, so that a short between channels or to 24 V is detected as a fault. Outputs to final elements switch on two independent paths, frequently a redundant pair of force-guided (mechanically linked) contactors whose auxiliary contacts are read back by the PLC to confirm the main contacts actually opened.

Ingress protection and environment matter because safety I/O often sits at the machine rather than in a clean cabinet. Cabinet-mounted controllers are typically IP20 and rely on the enclosure, while field-mounted safety I/O blocks are offered in IP65 or IP67 for washdown and dusty areas. Operating temperature for industrial safety CPUs is commonly 0 to 60 degrees Celsius, with extended-range variants. Diagnostics close the loop: the controller logs which channel failed and why, so a maintenance technician can replace the right module rather than the whole panel, which is a large part of the operational value over hardwired safety relays.

Key Specification Parameters

Reading a safety PLC datasheet means looking past the headline I/O count to the parameters that decide admissibility and behaviour. The same controller may list dozens of figures, but eight truly drive a selection decision: the certified SIL and PL, the architecture, the PFHd or PFDavg, the safety response time, the safety task cycle, the I/O and node capacity, the safe and standard memory, and the proof test or mission time. Each is explained below.

Certified SIL and Performance Level is the first gate. A function that the risk assessment determines needs SIL 3 and PLe cannot be built on a controller certified only to SIL 2 and PLd, no matter how the program is written. Read the certificate, not the marketing: confirm the rating applies to the specific CPU and I/O modules, and to the firmware revision you will deploy. The Siemens SIMATIC S7-1500F fail-safe modules, for instance, support up to PLe per ISO 13849-1 and SIL 3 per IEC 61508.

Architecture and PFHd or PFDavg together quantify the integrity. The architecture (1oo1, 1oo2, 2oo3) sets the hardware fault tolerance, and the PFHd (high demand) or PFDavg (low demand) is the number the function-level calculation must satisfy. For a SIL 3 high-demand function the controller contribution must keep PFHd below 1E-7 per hour with adequate margin, because field sensors and final elements consume the rest of the budget. Vendors publish these figures per module in the safety manual; they are summed across the loop, not taken from the logic solver alone.

Safety response time and safety task cycle govern whether the controller is fast enough. The safety response time is the worst-case input-to-output delay and must be shorter than the machine process safety time. It is built from the input device and module response, the safety task scan plus its watchdog, the network F-monitoring time, and the output and actuator response. The safety task cycle is configurable: a faster cycle shortens response but raises CPU loading, so it is tuned to the fastest hazard. As a reference scale, a Schneider Modicon M580 Safety CPU contributes roughly 100 to 400 microseconds per safety I/O device to the safe task depending on CPU model.

Capacity parameters size the controller to the plant.

• Safety I/O points and nodes: the number of safe inputs and outputs and the number of safety devices on the network. A Compact GuardLogix 5380, for example, supports up to 180 EtherNet/IP nodes and up to 31 local I/O modules.
• Safe and standard memory: integrated controllers separate the two. Compact GuardLogix 5380 offers standard memory from about 0.6 to 10 MB and safety memory from about 0.3 to 5 MB; the SIMATIC CPU 1518F carries roughly 6 MB program and 20 MB data RAM.
• Integrated motion: machinery controllers increasingly run safe motion (safe torque off, safe stop) over the safety network, up to tens of axes, removing separate safety drives wiring.
• Standard plus safety in one CPU: the ability to run certified safety logic and ordinary control in one protected project on one network, which is the main reason integrated safety PLCs displaced separate safety systems.

Proof test interval and mission time close the lifecycle. High-demand machinery safety PLCs are typically assigned a mission time of around 20 years with no scheduled offline proof test of the logic solver, the diagnostics doing the work in service. Low-demand process logic solvers carry an explicit proof test interval that feeds the PFDavg calculation; a longer interval raises PFDavg and erodes the SIL margin, so for example a SIL 3 loop at PFDavg near 1E-3 with 99 percent diagnostic coverage may require a proof interval of about 6 months for its field elements, while the HIMA logic solver itself can be proof tested at intervals up to 10 years, extendable by analysis.

Selection Decision Factors

To turn the preceding five chapters into a specific model, follow the decision sequence below. Most selection mistakes come not from a single wrong figure but from deciding hardware before the risk assessment fixes the required integrity. These eight steps can serve as a fixed RFQ template for a safety controller.

1. Required integrity from risk assessment: first run the machinery risk assessment to ISO 12100 and derive the target SIL (IEC 62061) or Performance Level (ISO 13849-1) per function. The required SIL or PL, not the controller catalogue, drives everything that follows.
2. Application family: decide configurable small controller, integrated machinery safety PLC, or process safety logic solver (SIS). High-availability continuous process duty points to 2oo3 TMR; reconfigurable factory automation points to an integrated programmable safety PLC.
3. Architecture and availability target: choose 1oo1, 1oo2, or 2oo3 against both the SIL ceiling and the cost of a spurious trip. Where a nuisance shutdown is expensive or hazardous, pay for TMR; where it is merely inconvenient, 1oo2 is usual.
4. Safety response time budget: establish the machine process safety time for the fastest hazard, then confirm the worst-case loop response (input, scan, network, output, actuator) fits inside it with margin. This can eliminate otherwise-suitable controllers.
5. Safety network and integration: match the safety protocol to the plant: PROFIsafe on PROFINET, CIP Safety on EtherNet/IP, FSoE on EtherCAT, openSAFETY, or SafeEthernet. Decide whether standard control, safe motion, and vision must share the CPU and network.
6. Capacity and memory: size safe I/O points, network nodes, axes, and both safety and standard memory to the application with growth headroom, so a line expansion does not force a controller change.
7. Certification and market access: verify a current TUV certificate for the exact CPU, I/O, and firmware, plus the regional and sector approvals you need: CE under the Machinery Regulation, and for process duty IEC 61511 and any local scheme.
8. Total cost of ownership (TCO): purchase price plus engineering and validation effort, spare parts, the cost of training on the safety toolchain, proof testing labour, and the production losses a spurious trip would cause. A cheaper controller that trips the line or that your team cannot validate quickly costs more across its life.

One last commonly overlooked dimension is manufacturer serviceability and toolchain maturity: long-term firmware support and certificate continuity, availability of certified function-block libraries, local spare parts and engineering support, and how cleanly the safety project version-controls and signs. These seem secondary at purchase but determine validation time on every machine change over a 10 to 20 year service life. Siemens, Rockwell Automation (Allen-Bradley), Schneider Electric, Pilz, Phoenix Contact, B&R, Omron, HIMA, and Beckhoff all maintain certified product lines, documentation, and regional support, which makes them defensible choices for projects that must stay certifiable for the life of the asset.