PLC Naming Conventions and
Code Documentation for GMP

Why Naming Is a Traceability Issue

The traceability chain for a pharma PLC runs from URS requirement to FDS function to PLC code to test case. Every link in that chain references tags by name. The URS says "temperature shall be monitored at TT-101." The FDS alarm table lists "TT_R01_101_PV" with its setpoints. The OQ test case says "verify that ALM_TT_R01_101_HH activates when TT_R01_101_PV exceeds 85°C." The historian tag list records "TT_R01_101_PV" at 1-second scan rate. If any of those names are inconsistent — if the historian uses "TT101_Value" and the OQ protocol uses "TT_R01_101_PV" — the reviewer cannot confirm that the historian is recording the same signal that the OQ tested.

This is why naming conventions must be defined before engineering begins, documented in the SDS, and locked at FAT. Post-FAT tag name changes are change control events — they invalidate historian queries, corrupt audit trail records, and require protocol amendments. The cost of changing a tag name after FAT is high enough that getting the convention right at the start is always worth the investment.

Instrument Tag Convention — PLC and SCADA

The ISA-5.1 instrument designation is the foundation. The instrument tag format used on a pharma PLC extends the P&ID designation with signal suffixes that distinguish between process variable, setpoint, alarm limits, command, and status signals for the same physical instrument.

The signal suffix is the element most often handled inconsistently between teams. One engineer uses _PV, another uses _VAL, another uses _Value. Within a single project, any variation is a traceability gap. The convention must specify every suffix type — PV, SP, CMD, FBK, RUN, FLT, STS, HAL, HHAL, LAL, LLAL, MOD — and that specification belongs in the SDS, referenced by every document that creates tags.

PLC Block Naming — Function Blocks and Data Blocks

Function block naming in a pharma PLC follows a different convention from instrument tags. The critical rule is that the block name in the TIA Portal project must match the name in the SDS Function Block Library table exactly. Code review verifies this — any discrepancy between the SDS and the project is a finding.

The data type prefix (b_ for BOOL, r_ for REAL, i_ for INT, s_ for STRING, dt_ for DATE_AND_TIME, w_ for WORD) is not just a readability convention — it makes mismatches visible in the code and in the SDS. When a code reviewer sees r_BatchComplete, the r_ prefix immediately signals that this is a REAL — which is wrong for a completion flag. The naming convention catches type errors that would otherwise require running the programme to discover.

Code Commenting Standard

The GMP code commenting standard has three levels, each with a different purpose in the validation evidence chain.

FB Header Comment

Every function block must have a header comment that makes the block self-documenting for code review. The minimum required fields are purpose, FDS reference, URS reference, author, and revision history. The revision history in the header must track with the version control tags — if CCR-007 changed the block, both the header and the version archive must reflect that. A discrepancy between the two is a code review finding.

Interlock Reference Comments

Every interlock condition in the code must be commented with its interlock register reference. The format is consistent: // IL_004 — Pump start permissive. Ref: CP-SYS-001 Section 4.2, URS-SAF-003. The IL reference links the code to the interlock register in Appendix C of the SDS, which is the document that QA reviews to verify every interlock is implemented and tested. A rung with no IL reference either has a missing interlock register entry (gap) or is not a formally recognised interlock (which should be documented as a design decision).

Audit Trail Call Comments

Every FB_AuditTrail call must be preceded by a comment identifying the GxP parameter being logged and the FDS requirement that mandates the logging. This comment is what allows the code review to verify completeness of audit trail coverage — the reviewer can cross-reference every FDS FUNC-DI requirement against the audit trail call comments in the code and confirm coverage. Without these comments, the review becomes a search problem rather than a verification exercise.

Where the Convention Lives — The SDS

All naming conventions and coding standards are documented in the SDS. For a Category 5 PLC project, this is mandatory — the SDS is the controlled document that the code review checks against. For a Category 4 configured SCADA, the tag naming convention lives in the SDS even if the SDS is abbreviated, because it is the document that links SCADA configuration to the FDS alarm table and historian configuration.

The critical point about the SDS is that its contents must be stable before FAT begins. If the naming convention in the SDS says the process value suffix is _PV and the engineer who built the SCADA used _Value, that is a nonconformance discovered at FAT — not something to fix in the SDS retrospectively. The SDS is the specification the code was built against. If it differs from what was built, either the code is wrong or the SDS was never actually used to guide development.