How to Structure a SCADA Project
for Pharma Validation

Why Structure Matters More Than Functionality

A SCADA developer who has not worked on pharma projects before will approach the build in a familiar way: start with the main overview screen, add process areas as they go, name tags based on what feels logical at the time, and clean it all up later. That approach produces systems that work perfectly but fail qualification because the documentation cannot describe them.

On a pharma project, the SCADA structure — screen hierarchy, tag naming, graphic standards, alarm configuration, version control — must be defined in the SDS before development begins. The FAT protocol then tests the system against that specification. If what was built does not match what the SDS says, that is a deviation in the FAT record, not a configuration issue to fix in production.

The SDS is the engineering contract between the developer and QA. Every element of SCADA structure described in this article belongs in the SDS, must be reviewed and approved before development starts, and must be traceable back to the FDS functional descriptions it implements.

Screen Hierarchy — Define It Before You Build It

The screen hierarchy defines every screen in the application, its level in the navigation structure, its purpose, and how it is accessed. It must be complete before development begins. Adding screens during build because "the client asked for it" without updating the SDS is an undocumented design change — it creates a gap between the approved design and the built system that the FAT then has to navigate.

The screen hierarchy table must include at minimum: the level (0 to 4), the screen name, its purpose in plain language, how it is navigated to, and the FDS functional description reference it satisfies. Access restrictions go in the same table — a screen visible only to Supervisor and above must say so here, not just be configured silently in the security server.

Level 0 is always the login screen — it loads automatically at workstation start. Level 1 is the Main Overview: always visible, always accessible from any other screen, showing the top-level process status and alarm count. Level 2 screens are process area views navigated from the Main Overview. Level 3 screens are detail popups and utility views (trend viewer, reports) accessed from Level 2. Level 4 screens are restricted administration functions — Maintenance (Supervisor and above) and Security Administration (Administrator only).

Tag Naming Convention — The Rule That Everything Else Depends On

The tag naming convention is the most consequential structural decision on a SCADA project. Every test protocol reference, every historian query, every audit trail entry, every alarm tag in the FDS alarm table — all of them depend on tag names being consistent. Inconsistency between tag names in the SDS and tag names in the test protocol is a test authoring error that generates protocol deviations at FAT.

The convention must be defined in the SDS and frozen before development begins. It must cover every tag type: process values, setpoints, commands, status, alarm bits, configuration parameters. A workable format for a pharma SCADA follows a four-segment structure: [SYSTEM]_[AREA]_[DESCRIPTION]_[TYPE].

For a purified water system, worked examples look like this: PWS_QAL_Conductivity_PV (conductivity processed value), PWS_QAL_Conductivity_SP_Critical (conductivity critical alarm setpoint), PWS_DST_Pump001_STS_Run (pump P-001 run status), PWS_STO_Sanit_STS_Phase (sanitization sequence phase state), PWS_SEC_Session_STS_ActiveUser (authenticated user name tag for audit trail attribution).

The SDS must include a worked example table — not just the format rule, but examples covering every tag type and every process area. During FAT, the test protocol author populates the exact tag names they will verify. If the convention was defined clearly with examples, the protocol author picks the right tag. If it was defined vaguely, the protocol author guesses — and the guess may not match what was actually built.

ISA-101 Colour Standards — Not a Style Preference

ISA-101 (Human Machine Interfaces for Process Automation Systems) defines colour conventions for HMI displays. On a pharma project, following ISA-101 is not optional — it is a documented design standard that QA will review and FAT will verify. Inconsistent colour usage creates ambiguity for operators: if grey sometimes means off and sometimes means an unknown state, the display is unreliable as an operational tool.

The mandatory colour assignments for a GMP SCADA are: grey for off, inactive, or unknown state; green for running, normal, or in-specification; yellow for advisory or medium alarm; orange for high alarm; red for critical alarm or trip; blue for manual mode or manual override active; purple for out-of-service or maintenance mode. These assignments apply to every equipment symbol, every status indicator, and every alarm indicator across every screen in the application. No deviations without engineering change.

The ISA-101 high-performance HMI philosophy also specifies a grey background for process screens — this is important because it provides maximum contrast for the status colour indicators. A dark process screen background makes it harder to see the grey off-state of equipment, which is the most common state. FAT will verify colour compliance on representative screens from each process area.

The colour standard belongs in the SDS graphic display standards section, not just in a style guide that the developer may or may not have read. It must be reviewable and approvable as part of the SDS sign-off.

Configuration Management — The Three Items That Need Version Control

Three SCADA configuration items must be under version control, each managed differently:

• The SCADA application itself — in InTouch, the Galaxy Application Server maintains object versions. An application snapshot is taken at FAT baseline and archived per the validated configuration archive procedure. The SHA-256 hash of the FAT baseline is the anchor of the hash chain that flows through SAT, IQ, OQ, and PQ. Every subsequent change goes through change control and generates a new hash.
• The historian tag configuration — the export of which tags are being historised, at what scan rates, with what deadbands, and for what retention period. This is not automatically captured in the SCADA application snapshot on all platforms. It must be explicitly exported and version-dated as a separate archive item. If the tag configuration drifts from the validated baseline — because someone added a tag without change control — historian queries will return results for tags that were never validated.
• The SDS document itself — any software configuration change that is not reflected in the SDS is an undocumented design change. The SDS revision history must track every design change, and the revision must be approved before the change is implemented. "Updated the SDS to reflect what was actually built" is an audit red flag; "implemented the design described in the approved SDS revision" is the correct sequence.

Scripting Standards and Code Review

SCADA scripts — QuickScripts in InTouch, VBScript in WinCC, Python scripts in Ignition — are software. On a GAMP Category 4 or 5 system, scripts that implement GMP-critical functions must be reviewed before FAT. This is not optional and it is not the same as testing the function in a FAT test case.

The code review is a peer technical review: someone other than the script author reviews the script against defined criteria. The review record is signed by the reviewer and QA-witnessed. The criteria must be defined in the SDS — what the reviewer will check: script has a header comment with purpose and version, script handles database write errors without silent failure, audit trail write calls are present for every GMP action, no hardcoded setpoints or credentials in script logic.

The code review output is a record that can be presented as evidence at qualification — not a memory that "someone looked at it." If the FAT begins without a completed code review record, the FAT has started without a pre-condition being met. That is a phase gate failure.

GAMP Category and What It Means for Structure

SCADA platforms like InTouch, WinCC, Ignition, and FactoryTalk View are GAMP Category 4: configured commercial off-the-shelf software. The platform itself is not validated by you — the supplier does that. What you validate is your configuration of it. This distinction is important for scoping the design documentation and the FAT.

Category 4 means: you do not need to validate that InTouch correctly processes OPC-DA data (the supplier has done that). You do need to validate that your tag database is correct, your historian configuration captures the right parameters at the right rates, your alarm database matches the FDS alarm table, and your access control configuration matches the FDS user role matrix. The SDS describes your configuration decisions. The FAT tests that those decisions are correctly implemented.

If your project adds significant scripted logic — custom data export routines, complex alarm suppression scripts, e-signature workflows — those scripts elevate the configuration toward Category 5 territory. The SDS must identify which scripts contain GMP-critical logic, and those scripts require the full code review and pre-FAT verification treatment described above.