Safety PLC vs Standard PLC in Pharma
— When SIL Matters

Two Frameworks Running in Parallel

The fundamental thing to understand about a pharma system with an F-CPU is that two separate compliance frameworks apply simultaneously, and they do not replace each other. GAMP 5 governs the standard PLC programme — the process control logic, audit trail, alarm management, and SCADA configuration. IEC 61508 / IEC 61511 (or IEC 62061 for machinery) governs the safety functions on the F-CPU — the emergency stops, safety interlocks, and protective shutdowns.

These frameworks have different evidence requirements, different lifecycle phases, and different validation approaches. The GAMP 5 validation does not validate the safety functions. The functional safety lifecycle does not validate the process control programme. Both must be completed, and the HDS must document both layers clearly so that QA, the safety engineer, and the site know which evidence package covers which hardware and functions.

What SIL Actually Means in This Context

Safety Integrity Level (SIL) is a discrete measure of the risk reduction provided by a Safety Instrumented Function (SIF). SIL 1 provides a risk reduction factor of 10 to 100. SIL 2 provides 100 to 1,000. Most safety functions on pharmaceutical process equipment — emergency shutdowns, overpressure protection, high-temperature trips — are SIL 1 requirements. SIL 2 appears on more hazardous processes. SIL 3 and above are rare in pharma and typically appear only on chemical synthesis or highly flammable environments.

The SIL target for a specific safety function is determined by a hazard and risk assessment — not by the engineer's judgment on a project, and not by what hardware is available. The hazard assessment (typically a HAZOP or LOPA) produces a required risk reduction, which translates to a SIL target. The safety function is then designed to achieve that SIL target. Assigning a SIL target without a formal hazard assessment is not acceptable — it is guesswork applied to safety-critical design.

Typical Safety Functions on Pharma Equipment

On a typical pharmaceutical process system — a bioreactor, water system, CIP skid, or fill-and-finish line — the safety functions that require F-CPU or safety relay implementation are well-defined. The SIL 1 target is most commonly applied to:

• Emergency stop (ESD) — all ESD pushbuttons wired in series to an F-DI module, triggering controlled shutdown of pumps and heaters. Category 4 / PLd per IEC 62061 or IEC 13849 is typically required for machinery applications.
• High-temperature trip — a dedicated F-channel temperature input (separate from the process temperature transmitter used for PID control) that triggers heater shutdown at a defined safety limit. The safety limit is set above the process alarm limit with a defined margin.
• Overpressure protection — a pressure safety input that trips the distribution pump VFD enable on high-pressure condition, protecting pipework and vessel integrity.
• Low-level pump protection — prevents pump start and trips running pumps when tank level falls below the minimum safe operating level, protecting against dry-running damage.

The key design principle for all of these is hardware independence: the F-CPU safety inputs must be physically separate from the standard PLC process inputs. A temperature transmitter with a single 4–20 mA output driving both the PID control loop and the safety trip is a common design error. The safety function must have its own sensor channel — a dedicated F-channel input — so that a failure of the process transmitter does not simultaneously disable the safety trip. This is a fundamental IEC 61511 requirement and is typically the first item a functional safety engineer checks in design review.

The F-CPU in the GAMP 5 Validation

Although the F-CPU safety programme requires its own functional safety lifecycle evidence, it still appears in the GAMP 5 Validation Plan and documentation. The HDS must document the F-CPU hardware, the F-DI and F-DO modules, and the safety functions with their preliminary SIL targets. The IQ must verify that the F-CPU hardware matches the HDS, that the F-CPU Force Table is empty at IQ completion, and that the F-CPU firmware version is recorded. The OQ can include functional tests that verify the safety trip activates from the process control perspective — but with the explicit note that these tests do not constitute the SIL verification.

The SDS must note that the F-CPU programme is developed to TIA Portal Safety programming guidelines and that F-CPU code review is subject to IEC 62061 requirements — separate from the standard PLC code review checklist. The code reviewer for the F-CPU must be a qualified functional safety engineer, not the same automation engineer who reviewed the standard programme.

Separate Evidence — What the F-CPU Needs

The functional safety evidence package for the F-CPU is distinct from the GAMP 5 validation package. It includes:

• Hazard and risk assessment (HAZOP or LOPA) — identifies hazardous events, consequence severity, and required risk reduction for each safety function
• Safety Requirements Specification (SRS) — defines the safety function, the SIL target, the safe state, the response time, and the proof-test interval
• SIL verification calculation — PFD (Probability of Failure on Demand) calculation demonstrating the safety function achieves the required SIL target, using failure rate data for each hardware component
• F-CPU programme design review — code review by a qualified functional safety engineer against IEC 62061 or IEC 61511 requirements
• Factory acceptance testing of safety functions — functional tests demonstrating each safety function operates correctly, with separate test cases from the standard FAT
• Proof-test procedure — documented procedure for periodic testing of each safety function at the required proof-test interval (typically 1–2 years for SIL 1)
• Functional Safety Assessment (FSA) — independent assessment confirming the functional safety lifecycle was correctly executed

How This Affects the Validation Plan

The Validation Plan must explicitly address the boundary between the GAMP 5 validation scope and the functional safety lifecycle scope. A VP that describes the standard PLC validation without acknowledging the F-CPU and its separate evidence requirements creates ambiguity about what the validation covers. QA reviewers who understand automation will ask: "What covers the safety functions?" The VP must have a clear answer — typically a reference to the separate functional safety lifecycle documentation maintained by the functional safety engineer or the safety engineer of record.

The GAMP 5 risk assessment also interacts with the functional safety assessment. The risk assessment identifies GxP-critical functions for test coverage. The safety functions — ESD, high-temperature trip — will appear in the risk assessment as high-severity items. The GAMP 5 risk assessment ensures these functions are tested from a process control perspective. The functional safety assessment ensures the safety hardware achieves the required probability of failure performance. Both are needed; neither substitutes for the other.