How to Structure a PLC Project
for Pharma Validation

Why Structure Is a Validation Issue, Not Just a Style Issue

Most automation engineers have a preferred way to organise a PLC project. On a non-pharma project, that's fine — if it works and your team can maintain it, the structure is good enough. On a pharma project, structure becomes a compliance matter. The way you've organised your programme determines whether your FAT protocol can reference specific function blocks, whether your code review can actually verify GxP-critical logic is isolated correctly, and whether a change five years from now can be made through change control without risk of unintended impacts.

Under GAMP 5, a PLC running process control logic on a pharmaceutical system is Category 5 — custom software. The implication is that the software design must be documented, the code must be reviewed, and the design must be traceable back to the Functional Design Specification. A poorly structured programme doesn't make that impossible, but it makes it significantly harder, and QA reviewers who understand automation will notice.

Organisation Block Structure — Where GxP Logic Lives

The most important structural decision in a pharma PLC project is which Organisation Block (OB) each piece of logic sits in. This applies directly to TIA Portal on Siemens S7 platforms — the equivalent concept exists on all major platforms. In Studio 5000 on Allen-Bradley PLCs, this maps to tasks and programs; in Codesys-based controllers, to tasks and POUs. The principle is platform-agnostic even when the terminology differs.

The rule is simple: GxP-critical logic must run in a deterministic, fixed-interval interrupt OB — not the free-running main cycle. For Siemens S7, that means OB30 (cyclic interrupt, typically 100ms) or OB35 (cyclic interrupt, typically 10ms for fast loops) rather than OB1. The reason matters more than the rule: OB1 execution time varies with programme size. An OB1 scan that runs every 12ms under normal load might stretch to 80ms under fault conditions. A PID control loop or a critical interlock should not be subject to that variability.

The Function Block Library — Your Standard Building Blocks

A pharma PLC project is built from a library of reusable Function Blocks, not from one-off ladder rungs. The FB library is the unit under test during code review, the reference that the FAT test cases are written against, and the thing that needs to be validated once and reused consistently. Three categories of FBs matter for GxP:

Equipment FBs — One Per Physical Equipment Type

Every motor, pump, valve, and actuator in the system gets its own Equipment FB. FB_Pump_GxP handles all pump logic — start permissives, run feedback, fault detection, command logging. FB_Valve_GxP handles all valve logic. The equipment FB is the single point of control for that device type. This is not optional for pharma: the "one output written from one location" rule means no physics output should be driven from more than one place in the programme. If a pump start can be triggered from OB1 and from OB35 and from the safety shutdown, you have three locations of truth and a code review finding.

Control FBs — PID, Sequencers, and State Machines

Process control logic — PID loops, batch sequencers, interlocks — lives in dedicated control FBs. The critical rule here applies to the sequencer logic that matters most in pharma: never use Set/Reset (SR/RS latch) instructions to manage critical process states. Latches are hard to trace, hard to test, and create state persistence that is difficult to verify during code review. Use seal-in logic with explicit conditions for entry and exit. A state machine with defined states, transitions, and transition conditions is testable. An SR latch that carries a "sterilisation complete" bit is not.

Service FBs — Audit Trail, Analog Processing, and Diagnostics

The service FBs are the ones that are often missing on first pharma projects. FB_AuditTrail_GxP must be called every time a GxP parameter changes — setpoint modification, mode change, recipe activation, user command. It takes the parameter name, old value, new value, user ID, and timestamp, and writes a structured record. FB_AnalogInput_GxP wraps every raw analog input and adds simulation bit, forced bit, EU conversion, and range checking. These two FBs are what make your system verifiable in the OQ.

User Defined Types — The Data Architecture

User Defined Types (UDTs) define the data structure for each equipment type and process variable. Every analog input in a GxP system should use the same UDT — so every raw AI value, EU-converted value, simulation bit, forced bit, out-of-range flag, and alarm status is consistently structured and consistently accessible. The UDT for an analog input in TIA Portal typically looks like this:

The simulation bit and forced bit are non-negotiable in pharma. During IQ execution, you will need to simulate sensor inputs to verify the control logic without live process conditions. The simulation bit must be a structured element of the UDT — not a separate tag named TT101_SIM that may or may not exist for every instrument. It needs to be trackable, logged, and clearable at IQ completion.

Naming Conventions — The IQ Documentation Anchor

Tag naming conventions in a pharma PLC project are not aesthetic — they are the link between the programme, the FDS, the Engineering Lists (I/O list, instrument list, historian tag list), and the IQ documentation. A tag named TT_101_PV in the PLC must match the same instrument designation in the P&ID, the I/O list, the FDS alarm table, the historian configuration, and the OQ test case. Any inconsistency across those documents is a traceability gap that QA will find.

The standard convention for a GxP PLC uses instrument designation as the base: [InstrumentType]_[Area]_[Number]_[Signal]. The instrument type follows ISA-5.1 notation (TT for temperature transmitter, PT for pressure, FT for flow, LT for level). The signal suffix distinguishes between process variable (PV), setpoint (SP), output (OUT), high alarm (HAL), high-high alarm (HHHAL), low alarm (LAL), status (STS), and mode (MOD).

Function block instances and data blocks use a separate convention: FB_[PascalCase function] for function blocks, DB_[Purpose] for data blocks. The critical rule is that the FB name in the SDS matches the FB name in the TIA Portal project exactly. Code review verifies this. If the SDS says FB_ConductivityControl and the project has FB_ConductCtrl, that is a nonconformance in the code review.

Version Tagging — The Change Control Evidence Trail

Every committed version of the PLC programme must be tagged with enough information to reconstruct exactly what was in the controller at any point in time. The standard tag format combines a semantic version number, a date, and a change control reference:

The version recorded in the Validation Summary Report must match the version that was in the controller when the OQ was executed. Any discrepancy is a validation deviation. This is why version tagging must be done at every commit, not retrospectively — reconstructing what was in the controller at OQ from memory or file timestamps is not acceptable evidence.

For teams using Git or a formal version control system for PLC code, the tag in the version control system is the audit trail. For teams using the TIA Portal project archive method (which is still common), the archive file name must include the version tag and the archive must be stored in a controlled location — not on a local hard drive.

The Code Review — What It's Actually Checking

A GAMP 5 Category 5 PLC programme requires a formal code review before FAT execution. QA will expect to see a code review record with a defined checklist, signed by a reviewer who did not author the primary code, and witnessed or reviewed by QA. The code review is not a walkthrough — it is a structured verification activity, and the output is a controlled document.

The checklist items that matter most in a pharma code review are not the usual "is it readable" checks. They are the GxP-specific structural verifications:

• Every GxP-critical function (PID loops, interlocks, alarm evaluation) is in a fixed-interval OB, not OB1
• No Set/Reset (latch) instructions for critical process states — verified rung by rung in affected FBs
• Every physical output is driven from exactly one location (one write instruction per DQ address)
• FB_AuditTrail is called for every GxP parameter change — cross-referenced against the FDS audit trail requirements
• Every analog input uses the UDT_AnalogInput_GxP with simulation bit and forced bit present
• Every FB name matches the SDS Function Block Library exactly
• Version tag in the archive matches the version referenced in the FAT protocol
• Interlock register (Appendix C of the SDS) is complete and matches the implemented logic

Traceability From URS to Code

The full traceability chain for a pharma PLC runs: URS requirement → FDS function description → SDS function block design → PLC code block → FAT test case → OQ test case. Each link in that chain must be explicit, not implied. The FDS references the URS requirement ID. The SDS references the FDS function ID. The FAT test case references the FDS function and the SDS design element.

In practice, the traceability matrix is the document that makes this chain navigable. But the chain only works if the source documents are consistent. If the URS says URS-FUN-007 (temperature control), the FDS says FUNC-TMP-001 (temperature control loop — TIC-101), and the SDS says the function is implemented in FB_PID_GxP instance DB_TIC101, then the traceability matrix can link them. If any of those references is missing or inconsistent, the traceability matrix entry for that requirement is incomplete and the protocol test case has no verified design basis.

The most common break in the chain happens between the SDS and the code. Engineers update the code but not the SDS. The SDS says a function is in FB_ConductivityControl but the final programme moved it into FB_ProcessControl as a section. The code review catches this — but only if the reviewer is checking FB names against the SDS, not just reading the code.

How Programme Structure Maps to Your Validation Documents

The decisions made in PLC project structure directly drive what ends up in the validation documents. Understanding this mapping before you start programming avoids the most common documentation failures on pharma projects.

The document that captures the programme structure decisions in full is the Software Design Specification. The SDS is the bridge between the FDS (which says what the system does) and the code (which implements it). The SDS says exactly how the implementation is structured — which FB does what, which OB it runs in, what the UDT looks like, what the naming convention is. A well-written SDS makes the code review faster and the FAT protocol easier to write. A missing or thin SDS means all of those structure decisions exist only in the code, and the reviewer has to reverse-engineer them.