PLC Programming for Industrial Safety Systems: Getting It Right
Safety PLC programming is not standard PLC programming with a different CPU. The hardware is different, the software tools are different, the validation requirements are different, and the consequences of getting it wrong are in a different category entirely.
We programme safety systems on both Siemens (F-CPUs in TIA Portal) and Allen-Bradley (GuardLogix in Studio 5000) platforms. The principles are the same regardless of the hardware, but the implementation details vary enough that experience on both matters.
What Makes Safety Programming Different
A standard PLC programme might have a fault that causes a machine to behave unexpectedly. Annoying, possibly expensive, but usually fixable. A fault in a safety programme can mean a guard interlock does not function, a light curtain is bypassed, or an emergency stop does not stop anything.
Safety PLCs are designed to fail to a safe state. The programming must support this by being deterministic, testable, and structured in a way that a third party can verify. This is not optional. It is a requirement under IEC 62061 and IEC 13849-1, depending on the architecture.
SIL Ratings and What They Mean in Practice
Safety Integrity Levels (SIL 1 through SIL 3 for most industrial applications) define the required probability of dangerous failure. The higher the SIL rating, the more rigorous the hardware architecture and software development process.
For SIL 2 and above, you are typically looking at redundant hardware (1oo2 or 2oo3 architectures), diagnostic coverage requirements, and proof test intervals. The software must be written using restricted language subsets, and function blocks need to be certified or validated through structured testing.
On the Siemens side, TIA Portal provides certified F-blocks for common safety functions: emergency stop monitoring, guard door monitoring, two-hand control, muting. Allen-Bradley's approach through GuardLogix and Studio 5000 safety tasks is similar, with AOIs (Add-On Instructions) for standard safety functions.
Common Pitfalls
Mixing safety and standard logic. Safety functions must execute in the safety task with safety-rated I/O. We have seen installations where standard I/O was wired to safety functions, which completely undermines the safety architecture.
Overcomplicated logic. Safety programmes should be simple and readable. If a safety function block requires a flowchart to explain, it is probably too complex. Simplicity aids verification and reduces the chance of latent faults.
Inadequate documentation. Every safety function needs a clear description of what it does, what inputs it monitors, what outputs it controls, and what the safe state is. This is not just good practice. It is required for validation and audit.
Skipping the validation. A safety programme must be formally validated before the machine is put into service. This means structured testing against the safety requirement specification, with documented evidence. Pressing the e-stop once and declaring it working is not validation.
Why Structure Matters
We use a consistent programme structure for all safety projects: clearly separated safety function blocks, standardised naming conventions, and a one-to-one mapping between the safety requirement specification and the programme structure. This makes the code auditable and makes future modifications traceable.
When a machine is in production for ten years and someone needs to modify a safety function, they need to understand what is there and why. Well-structured code with proper documentation makes that possible. Poorly structured code makes it dangerous.
Safety programming is one area where doing it properly the first time is not just preferable. It is the only responsible approach.