Why Forces Are a GMP Issue
In standard automation practice, the PLC Force Table is a commissioning and debugging tool. You force a digital input to simulate a sensor feedback, force an analog input to a specific value to test a PID loop, verify interlock logic without wiring a test signal. Engineers use it constantly during commissioning and it's invisible to QA because it leaves no record by default.
On a pharma project, that invisibility is the problem. A Factory Acceptance Test uses the Force Table to simulate all field I/O — the system cannot be connected to live instruments at the supplier's facility. Every conductivity reading, every temperature, every pump feedback, every valve position is forced or injected during the FAT. If those forces are not methodically tracked and cleared, you end up with a system that passed its FAT with artificial inputs still active — and has no GMP evidence to prove it was tested in its natural, unforced state.
An active force in the PLC Force Table at the point of FAT sign-off is a blocking deviation. The system cannot be released for shipment until the Force Table is 100% empty and that fact is witnessed and signed. This is not a minor documentation gap — it means the validated software baseline was established with artificial inputs active, which invalidates the FAT evidence for every test case that used those forces.
Two Simulation Methods — Different Rules for Each
During a pharma FAT, there are two distinct simulation mechanisms and each has different documentation requirements:
Signal Generator — Analog Input Simulation
A calibrated signal generator connected directly to an analog input channel produces a controlled 4–20 mA (or voltage) signal to simulate a physical instrument. This is the preferred method for analog inputs on pharma FATs because it simulates the actual signal path — the PLC receives a real analog signal, processes it through its EU conversion, and the alarm evaluation logic runs against a genuine reading.
Signal generators must be logged in the Force Log with the channel address, the tag, and the test values applied at each step. At the end of testing, the signal generator must be physically disconnected and the AI channel confirmed as returning to its natural open-circuit or connected-calibration-resistor state. This disconnection is part of the Force Audit checklist — a signal generator that is left connected but turned off is not the same as confirmed disconnected, and the Force Audit checks for this explicitly.
PLC Force Table — Digital I/O and Override Forcing
The Force Table in TIA Portal (or equivalent in Studio 5000, Codesys, etc.) allows individual I/O bits and memory locations to be held at a defined value regardless of the actual hardware state. For digital inputs — pump run feedbacks, valve position feedbacks, ESD status — this is the standard simulation method during FAT. For F-CPU safety inputs, a separate Force Table or safety test mechanism applies depending on the platform.
The critical difference from signal generators is that Force Table entries persist across PLC power cycles and programme downloads if not explicitly cleared. A force that was applied during test step 12.3 and never unforced will still be active when the FAT tester signs the final acceptance — unless someone specifically checks. This is exactly the scenario the Force Audit is designed to prevent.
The Force Log — What Must Be Recorded
The Force Log is the controlled document that tracks every simulation applied during the FAT. It is not optional and it is not something you fill in retrospectively at the end of testing. Every force must be logged at the time it is applied and initialled at the time it is removed. The Force Log is part of the FAT execution record and is subject to the same GDocP rules as the test cases themselves.
Force Log Disciplines — What Catches People Out
One Force ID per I/O Point
Assign a unique Force ID (FL-001, FL-002, etc.) to every I/O point that will be forced during the FAT. The Force Log is built before testing begins — it is populated from the I/O list, not created during testing. Every I/O point that the FAT protocol requires to be simulated gets a Force ID. If a point needs to be forced to multiple values across different test cases, the same Force ID covers all uses — the Test Values column captures the range, the Used In Tests column lists all test cases.
F-CPU Forces Are a Separate Checklist Item
The safety programme on an F-CPU has its own Force Table or safety test mechanism, and it must be checked independently from the standard PLC Force Table during the Force Audit. Engineers sometimes clear the standard Force Table completely and forget the F-CPU safety inputs that were forced for the safety interlock tests. The Force Audit checklist must explicitly include an F-CPU Force Table check as a separate line item — not assumed to be covered by the main Force Table audit.
SCADA Simulation Tags — Not in the PLC Force Table but Still Tracked
In addition to PLC forces, SCADA platforms use internal simulation tags (SIM_xxxx in InTouch, simulation mode in Ignition, etc.) to feed test values directly into the SCADA logic without going through the PLC I/O. These do not appear in the PLC Force Table. They must be tracked in the Force Log as a distinct simulation method, and they must be verified as inactive during the Force Audit — a separate check from the PLC Force Table inspection.
The Force Audit — The Phase Gate That Matters
The Force Audit is the formal verification step that confirms the system is in its natural, unforced state before FAT sign-off. In the QLean Framework FAT template, it is Section 11 — a critical phase gate that must be signed by both the Lead Tester and the QA Witness before the Final Acceptance (Section 13) can be completed. The phase gate is explicit: the Final Acceptance signature page cannot be signed if the Force Audit is incomplete.
The Force Audit is a five-item physical checklist:
- PLC Force Table is empty — zero active forces on any DI, DO, AI, or AO point (verified by opening the Force Table in the engineering software with both tester and QA witness present)
- SCADA simulation tags are all inactive / FALSE — confirmed by inspection of the simulation tag database
- Analog signal generators have been physically disconnected from all AI channels — not just turned off, physically disconnected
- AI channels are in their natural open-circuit or connected-calibration-resistor state — not showing the previous signal generator output
- F-CPU Force Table is empty — zero forced safety inputs or outputs on the failsafe CPU
The Force Audit Certification — the signed statement that all five conditions are confirmed — is also the point at which the software hash is verified. The hash documented in the FAT represents the software state at Force Audit completion. This is the baseline that travels with the system to site, and it must match what is loaded in the controller at SAT software hash verification.
Post-FAT Forces — The Ongoing Discipline
Force table discipline does not end at the FAT. The SAT verifies the system with live field connections — no forces should be needed for the majority of SAT activities, which are loop checks and live process verification. If any force is applied during SAT (for example, to simulate a missing instrument or to bypass a failed loop pending repair), it must be logged and cleared using the same Force Log discipline as the FAT.
During commissioning between SAT and IQ, forces are a necessary part of work. The IQ prerequisite check must verify that the Force Table is empty before IQ activities begin. The IQ protocol includes a software and configuration verification step — this is where the Force Table state is confirmed as part of the pre-IQ checklist, alongside the PLC programme version and hardware configuration.
The most common force-related finding on first pharma projects is not a force that was forgotten — it is a force that was removed but not initialled in the Force Log at the time of removal. The tester clears the force during testing, moves on to the next test case, and at Force Audit the Force Log row shows no Unforced By entry. The force is genuinely gone, but there is no documented evidence of when it was removed and by whom. That is an ALCOA+ failure — the record is not contemporaneous, attributable, and complete. The fix is not to backfill the entry; it is to write it at the time, every time, without exception.
The FAT template (FAT-SYS-001) includes Section 5 as a pre-populated Force Log table with a Force ID for every I/O point in the system — analog inputs, digital inputs, and safety F-CPU inputs listed separately. Each row has Forced By and Unforced By initials/date columns. Section 11 contains the five-item Force Audit checklist (FA-001 through FA-005) with a pass/fail tick box and witness initial column for each item. Section 11.2 is the Force Audit Certification — a separate signed statement by the Lead Tester and QA Witness confirming the Force Table is empty and the software hash represents the shipped baseline. This certification is explicitly listed as a prerequisite in Section 13 (Final Acceptance) phase gate criteria, so it cannot be bypassed.