Safety PLC introduction: SIL, certified hardware, basics

Safety PLC introduction is the part of the controls discipline where the rules stop being suggestions and start being legal. A non-safety PLC running an E-stop circuit will pass a FAT, satisfy a production manager, and kill somebody three years later when a single short-circuit on a digital input keeps the contactor energised after the operator has slammed the red button. The certified safety PLC exists because that single failure mode — and a hundred similar ones — needs to be detected and acted on inside one scan. This tutorial walks the difference between non-safety logic and safety logic on the simulator's S7-1500 with safety I/O variant, with specific SIL 2 versus SIL 3 examples and the proof-test interval that keeps your claim valid past month twelve.

Why this matters on real plants

Safety functions on SA plants have a long tail of bad implementations because the difference between a working E-stop and a certified safety function is invisible to anyone who is not looking for it. Both wire to a red mushroom button. Both drop a contactor when pressed. Both pass the production manager's "press the button, see the motor stop" test on commissioning day. The certified safety function continues to detect that the E-stop wiring has been short-circuited, that one of the two channels has stuck welded closed, that the cross-monitoring delay has drifted, and that the diagnostic coverage has dropped below the SIL claim — and shuts the machine down before the next start command. The non-safety function does none of that. The two look identical on the day of commissioning. They diverge the first time a wire chafes through and shorts to 24 V on the field side.

The cost of a bad safety implementation is not measured in product variation. It is measured in the Department of Employment and Labour Section 24 incident report, the Compensation Fund claim, and the criminal liability that can attach to the responsible person if the investigation finds that the safety function did not meet the documented SIL claim. The Occupational Health and Safety Act places duties on the employer and on the responsible engineer. A safety function specified at SIL 2 and installed on non-safety hardware does not meet SIL 2. The paperwork says it does. The actual hardware says it does not. The first time an inspector or an investigator looks closely, the gap is found.

The third reason it matters more on SA plants than in textbook examples: the local installed base is heavily mixed. A petrochem refinery commissioned in the early 90s has Honeywell DCS plus Siemens S5 plus Allen-Bradley PLC-5 plus newer islands of S7-1500 — and the safety functions are often layered on whatever was available at the time, with newer SIL-rated hardware only on the islands that have been refurbished in the last decade. An engineer walking onto a brownfield site needs to read what is actually installed, not what the design document says was installed, before deciding whether the safety claim is currently valid.

The mental model

A safety function is a closed-loop chain — sensor, logic solver, actuator — where every link in the chain has a quantified probability of dangerous failure per hour, and the sum of those probabilities determines the Safety Integrity Level (SIL) of the whole function. SIL 1 is roughly one dangerous failure per ten thousand hours of demand; SIL 2 is one in one hundred thousand; SIL 3 is one in one million; SIL 4 is one in ten million and almost never used outside nuclear and rail. Most industrial machinery safety functions sit at SIL 2 (process safety, common machine guarding) or SIL 3 (high-energy press, robotic cell with no other physical guard, gas burner management).

The mental shift from a non-safety PLC to a safety PLC is that single-point failures must be detected. A non-safety digital input that reads "1" gives the program a 1, regardless of whether the wire is intact, the field device is working, or the input channel itself has welded the bit high. A safety digital input pair, configured as a dual-channel input with cross-monitoring, gives the safety program an SAFE signal only if both channels agree (one normally-closed, one normally-open, swapped through the field device), if they switched within a configured cross-monitoring window (typically 100 to 500 milliseconds), and if the diagnostic test pulses on each channel returned the expected response within the test interval. Any of those conditions failing puts the safety program into a SAFE state — the actuator drops out — and raises a fault that requires manual reset.

The hardware difference between a safety PLC and a non-safety PLC is mostly invisible from the outside. The safety PLC has a redundant CPU pair with cycle-by-cycle comparison, dual-channel I/O modules with diagnostic test pulses, and a certified runtime that has been independently audited against IEC 61508. The price difference is roughly 2 to 3x for the CPU and 1.5 to 2x per I/O channel. The Siemens S7-1500F (the F suffix marks the safety variant) and the Rockwell GuardLogix are the two most common platforms on SA process plants; smaller machines often use Pilz PNOZ or Schmersal safety controllers as standalone islands. If you're still weighing up whether a given function needs the certified hardware at all, the safety PLC vs non-safety PLC comparison walks that decision — and the cost premium — in more depth.

The proof-test interval is the most-overlooked rule in the standard. A SIL claim is only valid if the safety function is proof-tested at the interval declared in the safety calculation — typically twelve months for SIL 2, six months for SIL 3. The proof test is not a smoke test ("press the button, see the motor stop"); it is a structured test that exercises every single failure mode the SIL calculation assumed would be detected, with a documented pass/fail record signed by a competent person. Skip the proof test by twelve months and the SIL claim is no longer valid — the function is not certified, the paperwork is not enforceable, and the responsible engineer carries the liability personally.

Worked example

Open the simulator. Drop an S7-1500F CPU on the rack with a safety DI16 module, a safety DO16 module, and a standard AI8 for non-safety analog inputs. The safety DI16 is the variant called out in the architecture diagram — externally identical to a standard DI16 but internally dual-channelled per pair of terminals, with a yellow housing colour code that the Siemens documentation uses to distinguish F-modules from standard modules. Wire a dual-channel E-stop across DI0 and DI1: one normally-closed contact and one normally-open contact in the same E-stop button assembly, with the NO contact wired across the second pair so the two channels report opposite polarity to the safety logic.

The non-safety PLC version of this E-stop, written as a single rung, looks like this:

(* Non-safety E-stop — DO NOT USE for any real safety function *)
(* Single XIC of E-stop input, single XIC of motor run command,    *)
(* output to motor contactor coil. Fails dangerously on any       *)
(* short-circuit between input terminal and 24 V supply.          *)

XIC( I:0/0 )           (* E-stop NC, reads 1 when not pressed *)
XIC( Run_Cmd )         (* operator run command latch         *)
OTE( O:0/0 );          (* motor contactor coil               *)

The safety PLC version of the same function, generated from the simulator's safety editor, looks like this:

(* Safety E-stop — dual-channel, cross-monitored, SIL 2/3 claim *)
(* Channel A on DI0 (NC), Channel B on DI1 (NO swapped).         *)
(* Cross-monitoring window 200 ms. Diagnostic test pulses on    *)
(* every cycle. Reset latch on RESET_BTN rising edge.            *)

ESTOP_FB(
    EN          := TRUE,
    CH_A        := DI_F:0.0,        (* NC channel, safe = 1     *)
    CH_B_INV    := DI_F:0.1,        (* NO channel, safe = 1     *)
    XMON_TIME   := T#200ms,         (* cross-monitor window     *)
    RESET       := R_TRIG(RESET_BTN),
    AUTO_RESET  := FALSE,           (* manual reset required    *)
    RUN_PERMIT  => RUN_PERMIT,      (* TRUE = safe to run        *)
    FAULT       => ESTOP_FAULT,     (* TRUE on diagnostic fail  *)
    SIL_VALID   => SIL_OK           (* TRUE while proof-test current *)
);

(* Motor contactor coil — both run command AND run permit needed *)
RUN_CMD AND RUN_PERMIT => DO_F:0.0;

The behavioural difference between the two versions, exercised on the simulator's fault-injection panel, is sharp. Inject a short-circuit between DI0 and the 24 V rail on the non-safety version — the input now reads 1 permanently, regardless of whether the E-stop is pressed, and the motor stays running when the red button is hit. The non-safety version has just failed dangerously and there is no diagnostic to flag it. Inject the same short-circuit on the safety version — the diagnostic test pulse fails on Channel A within the next scan, the cross-monitoring detects that Channel A and Channel B no longer report opposite polarity, the RUN_PERMIT drops to FALSE, the contactor opens, and the FAULT output goes high requiring a manual reset after the wiring is repaired. The safety version detected the single-point failure within one scan and put the machine in a safe state.

The SIL level decision for this E-stop function depends on the machine. A small conveyor with a person-loading station, where the residual risk after the E-stop is a bruise, sits at SIL 2 — single-channel field device in a dual-channel wiring arrangement, twelve-month proof test, IEC 61508 SIL 2 rated logic solver. A 200-tonne hydraulic press, where the residual risk after the E-stop is amputation, sits at SIL 3 — dual-channel field device (two physically independent E-stop button modules in the same housing), six-month proof test, IEC 61508 SIL 3 rated logic solver, and additional measures such as muting protection and contactor feedback monitoring. The safety calculation that justifies the SIL claim is a separate document, signed by a competent person, and revisited every time the machine is modified.

Common mistakes

• Running a safety function on a non-safety PLC because "the logic is simple". A safety function is not defined by the complexity of the logic. It is defined by the consequence of failure and the diagnostic coverage required to detect the failure modes. A two-input AND gate that drops a contactor on E-stop press is logically simple and a SIL 2 or SIL 3 safety function depending on the machine. Always run safety functions on certified safety hardware — the cost premium is small relative to the liability.

• Reusing safety I/O bits in non-safety logic. A safety input bit read by the non-safety program is contamination — the non-safety code can mask, latch, or override the bit in ways that break the SIL claim. The Siemens TIA Portal and the Rockwell Studio 5000 both enforce a separation between the safety task and the standard task; safety bits crossing into the standard task only via a documented one-way handshake. Always honour that separation; never write safety logic that depends on a non-safety bit being correct.

• Bypassing dual-channel monitoring during commissioning and forgetting to re-enable it. Commissioning often requires temporarily forcing the cross-monitoring window to zero or disabling diagnostic test pulses to get a stubborn field device to settle. The trap is that the bypass survives into production because nobody removes it. Always document every bypass in a commissioning log, set a calendar reminder to re-enable on the day production starts, and verify the safety function with a structured test before the first real operator hits the button.

• No maintenance test interval scheduled — SIL claim invalid after 12 months. The proof-test interval is part of the SIL calculation. Skip it and the claim lapses. Always book the proof test into the maintenance calendar as a recurring task at the interval declared in the safety document, with a competent person assigned, a structured test sheet, and a signed pass record filed against the equipment number. If the test cannot be completed on time, the safety function is no longer SIL-rated until the test is done.

• Using auto-reset on safety functions without explicit risk assessment. Auto-reset means that the safety output re-enables automatically when the trigger condition clears — the E-stop is released, the gate is closed, the light curtain is unbroken — without a human pressing a reset button. That is dangerous on most machines because it allows the machine to restart without a person confirming that the reason for the safety event has been understood. Always default to manual reset; only allow auto-reset where a documented risk assessment justifies it (typically only for high-cycle automated cells with no person access).

• Treating the safety PLC as a normal PLC for backup and version control. Safety PLC programs require a separate signed-and-dated archive at every release, with checksums recorded in the safety case document. A safety program restored from an unverified backup is no longer SIL-rated until the checksum is verified against the safety case. Always keep the safety project under stricter version control than the standard project, with the checksum and the date of last competent-person review as part of every commit.

How to practise this in the simulator

The simulator's safety variant ships with the S7-1500F runtime, a fault-injection panel for the safety I/O modules, and a built-in proof-test wizard that walks through the structured test sequence for the worked-example E-stop. Open the safety project, hit the "inject single-channel fault" button, and watch the cross-monitoring detect the fault and drop the run permit within one scan. Try the press-and-hold E-stop reset sequence with manual reset configured, then with auto-reset configured, and feel the difference in operator workflow. Run the proof-test wizard and watch which failure modes it exercises — short-circuit to 24 V, short-circuit to ground, channel cross-talk, diagnostic test pulse failure — and how it logs the pass/fail record to the project file. Twenty minutes on the simulator's safety variant teaches more about the difference between safety and non-safety PLC logic than a year of reading the standard.

Vendor reference

The cross-vendor reference for SIL classification and the underlying functional safety framework is the Wikipedia: Safety integrity level article, which tabulates SIL 1 through SIL 4 against the probability-of-failure-per-hour bands and references the IEC 61508 and IEC 61511 standards that define the calculation methodology. The iec.ch functional safety overview page hosts the canonical IEC 61508 series for purchase and links to the application-specific standards (IEC 61511 for process, IEC 62061 for machinery). The Siemens S7-1500F documentation in TIA Portal and the Rockwell GuardLogix documentation in Studio 5000 both include worked-example safety projects with SIL 2 and SIL 3 reference architectures; reading one before designing your own saves a significant amount of avoidable mistakes.

What we don't claim

This site is not SAQA-registered, not MerSETA-accredited, and not an NQF-registered qualification provider. Our completion certificates are course-level only — they describe what you covered, not an NQF Level X qualification. The CCST cert from ISA is the portable industry credential we recommend; we are not an ISA cert delivery partner either, but our cert packs are CCST-aligned. Functional safety design is a regulated discipline that requires a competent person sign-off on every safety calculation — the simulator gives you the practice ground for the implementation patterns, but the SIL calculation and the proof-test schedule for your real machine still need a qualified functional safety engineer.