Classifying Tags: GMP-Critical vs Non-GMP
The first decision in designing a GMP historian is classification: which tags are GMP-critical and which are not. This is not an arbitrary choice — it flows directly from the risk assessment. A tag is GMP-critical if its value affects product quality, patient safety, regulatory compliance, or the integrity of the validation evidence. Every GMP-critical tag carries the full set of historian requirements: defined recording interval, time-based storage, write-once architecture, and full retention period. Non-GMP tags can use whatever storage configuration is convenient — they are outside the validated scope.
The classification must be documented. The Engineering Lists (EL-SYS-001) historian tag list is where this lives — a table listing every historian tag with its GMP-critical status, storage type, recording interval, deadband (if applicable), and retention period. The FDS references the Engineering Lists for the full tag inventory; the FDS itself defines the recording intervals by parameter category. QA will look at both documents during design review, and an IQ checklist item requires the Engineering Lists to be at an approved revision before IQ execution can begin.
The practical classification for a continuous process SCADA is straightforward: all process quality parameters (conductivity, temperature, TOC, pressure at GMP-relevant points) are GMP-critical. All alarm events and audit trail events are GMP-critical. Sanitization sequence state and phase data are GMP-critical. Setpoints and their changes are GMP-critical via the audit trail. Equipment run status tags — pump running, valve open/closed — are typically non-GMP unless they directly affect product quality. Flow totaliser data sits in between: if it feeds a quality calculation it is GMP-critical, if it is only used for operational monitoring it is not.
Storage Modes — Why Exception-Based Is Not Appropriate for GMP
Most industrial historians support three storage modes: time-based (a record is written at every defined interval regardless of whether the value changed), exception-based (a record is written only when the value changes by more than a defined deadband), and on-change (a record is written every time the value changes at all, regardless of magnitude). Each mode has a legitimate use — but for GMP-critical process parameters, only time-based storage satisfies the ALCOA+ Complete requirement.
The problem with exception-based storage for GMP process values is precisely that it performs well when the process is behaving. A stable conductivity reading within specification generates no historian records under exception-based storage — because nothing changed. If an auditor asks to verify that conductivity was in specification for the entire production run, the answer "there are no records because nothing changed" is not a compliant response. The historian must prove compliance, not merely the absence of excursions.
On-change storage is appropriate for discrete and state tags: alarm state transitions, setpoint changes, system mode changes, equipment status bits. These are event-driven by nature — a setpoint does not change on a schedule, it changes when an operator acts. Recording on-change for these tags produces a complete and non-padded record of every relevant event.
Some engineers configure time-based storage for GMP tags but also set a deadband — meaning a record is written every 60 seconds only if the value has changed by more than X. This is functionally identical to exception-based storage with a time-based flush interval. GMP process value tags must use time-based storage with no deadband. The record must be written at every interval regardless of whether the value changed. This is what the SDS historian tag configuration must specify explicitly — and what the IQ must verify by reviewing the actual historian tag configuration file against the SDS.
Recording Intervals — What the FDS Must Specify
The FDS must define the recording interval for each GMP-critical parameter. "Every 60 seconds" is not a default that can be left to the engineer's discretion — it is a design specification that becomes an OQ acceptance criterion. If the FDS says conductivity is recorded every 60 seconds and the historian is configured for 120 seconds, that is a design non-conformance that must be raised as a deviation and resolved before OQ sign-off.
The intervals are driven by process requirements: how fast can the parameter change, and how long is the allowable response window? A parameter that can go from in-specification to out-of-specification in 30 seconds needs a shorter recording interval than one that changes over hours. The risk assessment should inform the interval — not personal preference or database storage cost.
Typical intervals for a continuous process SCADA are: quality parameters (conductivity, temperature, pressure) at 60 seconds; slower-moving parameters (TOC, level) at 300 and 120 seconds respectively; alarm events and operator actions at real-time (on-change); sanitization sequence phase events in real-time during the active cycle. These are not universal rules — they are design decisions that must be documented and justified.
The Tag Name Freeze — Why It Matters for Trending
Historian tags are identified by name. Every query, every report, every trend, and every OQ test protocol that references a historian tag uses the tag name as the key. If a tag is renamed after the FAT baseline, every historical query that used the old name stops working. The historical data does not migrate — it stays under the old name while new data accumulates under the new name. The result is a broken audit trail: a trend from before the rename shows one tag, the trend from after shows a different tag, and there is no automated way to reconcile them without manual intervention that itself requires change control documentation.
This is why the tag naming convention must be defined in the SDS before development, approved before FAT, and treated as a configuration baseline. Tag name changes after FAT are change control events requiring OQ retesting of any historian reports and queries that reference the renamed tag. In practice, a tag rename after go-live is extremely disruptive — far more so than it appears during development. The SCADA project structure article covers the naming convention design.
Trend Viewer Design — What Validation Requires
The SCADA trend viewer is a GMP interface for accessing historical process data. Its design requirements must be specified in the FDS and verified at OQ. The key requirements are not aesthetic — they are functional specifications with testable acceptance criteria.
- Alarm limit lines: GMP-critical process parameter trends must display the current alarm setpoints as horizontal reference lines on the trend. An operator looking at a conductivity trend must be able to see at a glance where the advisory, action, and critical setpoints are. A trend without reference lines forces the operator to mentally compare the process value against a number they must remember.
- Engineering units on Y-axis: The Y-axis must be labelled with the engineering unit, not a raw value. A trend displaying "0.87" with no unit label is not a compliant GMP record — it cannot be interpreted without additional context. The unit label is a ALCOA+ Legible requirement.
- Time range configurability: The trend must support at minimum a configurable time range from 1 hour to 7 days. Operators managing a continuous process need different time windows for different purposes — a 1-hour view for active monitoring, a 24-hour view for shift handover review, a 7-day view for periodic quality checks.
- Multi-parameter simultaneous display: The FDS must specify the minimum number of parameters that can be displayed simultaneously. Four is typical — conductivity, temperature, pressure, and one configurable parameter.
- Export from trend screen: The ability to export the displayed trend data as a CSV — including all displayed parameters for the selected time range — must be part of the trend viewer design. This is the mechanism operators use to pull data for investigation without requiring a separate report generation workflow.
Retention, Archiving, and Accessible History
Retention for GMP historian data is typically structured in two tiers: online retention (data accessible via the standard query interface on the primary historian server) and archive retention (data accessible via a secondary query interface on archived media). For most pharmaceutical applications the online window is two years and the total retention period is seven years — meaning years three through seven are in archive but must remain queryable and exportable with the same certified copy capability as online data.
The archiving mechanism must be validated — not just the online historian. If archived data is stored on a separate SQL instance, the transition from online to archive must be tested to confirm that no records are lost, that timestamps are preserved, and that the export function produces the same certified copy format for archived data as for online data. This is an area where many pharma SCADA implementations have gaps: the online historian is validated thoroughly and the archive is treated as a backup rather than as the second tier of a validated record-keeping system.
The practical test: four years after commissioning, an inspector asks for a certified copy export of conductivity data from a specific 24-hour period three years ago. Can the system produce it? In the correct format? With the correct certified copy header including checksum? If the answer is anything other than a straightforward yes, the archiving design needs review. See the SCADA historian configuration article for the full two-tier design.
The FDS-SYS-001 FUNC-DATA-001 specifies the recording intervals for each GMP-critical parameter: conductivity (both sensors and processed value) every 60 seconds, temperature at all monitoring points every 60 seconds, TOC every 300 seconds, distribution pressure every 60 seconds, tank level every 120 seconds, alarm events in real-time on state change, and operator actions in real-time on execution. FUNC-DATA-002 defines the two-tier retention: 2-year online with full query capability, 7-year total retention with consistent query interface across both windows, and immutable records with no UPDATE or DELETE on any GMP record after initial write. The SDS-SYS-001 Section 7 documents the historian tag configuration: time-based storage for all GMP process value tags, no exception-based storage, no deadband on GMP PV tags, storage intervals matching FUNC-DATA-001, and all GxP tags with engineering units in the descriptor field. The ELSYS001 Engineering Lists (Sheet 4, Historian Tag List) contains 44 tags with 28 classified GMP-critical, covering storage types, scan rates, deadbands, and retention per tag. The FDS Section 5 FUNC-HMI-003 specifies the trend viewer: 8-hour default with configurable range from 1 hour to 7 days, minimum 4 simultaneous parameters, alarm limit reference lines, engineering unit labels on Y-axis, and CSV export from trend screen.