EMS vs Standard Process SCADA — What's Different
A standard process SCADA monitors and controls a process. A cleanroom EMS monitors an environment — the controlled space that surrounds the process. The instruments are passive (sensors only, no actuators in most configurations). The data is continuous. The alarm strategy is two-tiered. And the records generated by the EMS are used to release product — which means the data integrity requirements are as high as any GMP process record.
The key regulatory driver for a GMP cleanroom EMS is EU GMP Annex 1 (Manufacture of Sterile Medicinal Products), which defines the environmental monitoring requirements for clean areas. Annex 1 requires continuous or frequent monitoring of critical environmental parameters, defined alert limits and action limits for each parameter and each room, a documented response procedure for limit exceedances, and records retained for the required period. The SCADA configuration must implement all of these — not as nice-to-have features but as validated functions with OQ test cases.
The distinction between alert limits and action limits is the most important design decision for an EMS SCADA configuration, and the one most commonly collapsed into a single alarm level by engineers who haven't worked on EMS projects before.
Alert Limits and Action Limits — Two Separate Alarm Levels
Annex 1 defines two separate limit types for environmental parameters. Alert limits indicate that something may be drifting out of control — they trigger investigation and increased monitoring, not immediate production stop. Action limits indicate that the environment has exceeded the acceptable operating range — they trigger immediate action including potential product quarantine. The SCADA must implement these as two distinct alarm levels with different priority settings, different required responses, and different audit trail entries.
In the SCADA configuration, alert limits must be configured as Medium priority alarms — they require acknowledgement and investigation but do not stop production. Action limits must be configured as High priority alarms — they require immediate response, and the standard operating procedure linked to the alarm must define the product quarantine decision criteria. The acknowledgement of an action limit alarm must include a mandatory reason field — the operator must document what action was taken, not just click acknowledge.
Both limit types must be stored in the historian as configuration parameters with their own audit trail — any change to an alert or action limit is a GMP configuration change that requires change control, impacts the validated state, and must be audit-trailed with old value, new value, user, timestamp, and reason. A site that updates alert and action limits without change control every time a cleaning validation baseline is established is accumulating undocumented changes to a validated configuration.
Parameters, Recording Intervals, and Data Gap Prevention
The standard parameter set for a GMP cleanroom EMS is temperature, relative humidity, and differential pressure. Sterile manufacturing facilities add particle counts (viable and non-viable). Each parameter has different monitoring requirements under Annex 1, and each requires a separate historian tag configuration.
- Temperature: Continuous monitoring at 60-second recording interval. Alert and action limits specified per room classification (typically ±2°C for alert, ±3°C for action from operating setpoint). Time-based storage — no deadband. Annex 1 requires evidence of continuous monitoring throughout manufacturing operations.
- Relative humidity: Continuous monitoring at 60-second recording interval. Alert and action limits specified per room. Typical limits differ between product-contact areas and corridor areas. Same storage requirements as temperature.
- Differential pressure: Continuous monitoring at 60-second recording interval. Differential pressure between adjacent cleanroom grades must be positive in the specified direction (higher grade to lower grade). A differential pressure reversal — even momentary — is an action limit exceedance. The recording interval must be short enough to capture transient reversals. 60 seconds may not be sufficient for high-traffic door zones — 10-second intervals are common for critical pressure differentials.
- Particle counts: Not typically continuous in a SCADA EMS configuration — particle counters are usually sampled on a schedule (during operations, at defined frequencies per ISO 14644-1). The SCADA may integrate with particle counters via OPC or serial interface and log the sample results as scheduled events rather than continuous data.
Data gap prevention is an Annex 1 requirement. The EMS must not have gaps in the environmental record during manufacturing operations. The SCADA configuration must include a data gap detection alarm — if a sensor tag has not updated within a defined staleness threshold (typically 5 times the normal recording interval), an alarm is generated. This mirrors the data gap detection approach in a process SCADA historian, but the consequence in an EMS context is more significant: a gap in the environmental record during sterile operations must be investigated and documented as a potential environmental excursion, even if the sensor was simply disconnected for maintenance. See the SCADA historian configuration article for the technical data gap detection implementation.
Most first-project EMS configurations set a simple low alarm on differential pressure (e.g., alarm if dP < 10 Pa). This misses the transient reversal case: dP drops to -2 Pa for 8 seconds when a door is opened, then recovers. At a 60-second recording interval, this reversal may produce no alarm if the measurement happens to fall between the two 60-second samples. For critical differential pressure monitoring, the recording interval must be short enough to capture transients, and the alarm must be configured with a minimal deadband — any reading below the alert limit must trigger an alarm regardless of duration. The OQ must adversarially test this by simulating a brief pressure drop and verifying the alarm fires.
The Excursion Response Workflow
When an action limit is breached, the EMS SCADA must not just annunciate an alarm — it must support the excursion response workflow. This is the sequence of steps from alarm acknowledgement through to deviation record closure. The SCADA does not perform the QA investigation, but it must capture the evidence that the investigation requires.
At minimum, the SCADA excursion workflow must: generate the alarm with the correct priority and mandatory reason field on acknowledgement, create an automatic excursion report that captures the parameter, location, time of exceedance, duration, peak value, area classification, and the products potentially exposed during the excursion window, and retain this report as an unalterable GMP record linked to the alarm event. The excursion report is the primary evidence for the QA investigation. If it can be modified, deleted, or regenerated after the fact, it fails as a GMP record.
The SCADA can also support the deviation management workflow by generating a pre-populated deviation record form or integrating with the site's electronic deviation management system via an OPC-UA or database interface. This integration, if implemented, must itself be validated — the data flowing from the EMS SCADA to the deviation system must be verified to be accurate and complete in the OQ.
Historian Configuration for EMS Data
The historian configuration for an EMS follows the same principles as for any GMP process SCADA, with a few EMS-specific additions. The core requirements — time-based storage, no deadband for continuous parameters, write-once architecture, 7-year retention — are identical. See the historisation article for the full historian design.
The EMS-specific additions are: each monitoring location must be a distinct historian tag (not a shared tag with a location field), the room classification must be stored as a descriptor field on each tag (ISO 14644 grade or EU GMP classification), and the alert and action limits must be stored as configuration parameters in the historian rather than only in the alarm database. Storing limits in both places ensures that a historical excursion analysis can determine what the limits were at the time of the exceedance — not just what they are today. If limits have changed since an exceedance occurred, the historian must be able to show which limits were in force at the time.
Validation Approach for a SCADA EMS
A SCADA-based EMS is a GAMP Category 4 computerised system — configured COTS software — and is validated using the same V-model approach as any other SCADA. The specific validation considerations for an EMS are as follows.
URS
The URS must specify all monitored parameters, the room classification for each monitoring location, the alert and action limits (or reference to the environmental monitoring specification that defines them), the recording interval per parameter, the data gap detection requirement, the excursion report content, and the retention period. Annex 1 does not specify exact limit values — the URS must reference the site's environmental monitoring specification, which is the document that defines the limits for each cleanroom grade based on the facility qualification data.
OQ Test Cases
The EMS OQ requires specific test cases that differ from a standard process SCADA. Beyond the standard historian completeness and data integrity tests, the EMS OQ must include: alert limit alarm activation with verification that the alarm priority is Medium (not High), action limit alarm activation with verification that priority is High and mandatory reason is enforced, differential pressure reversal test (adversarial — brief reversal must fire the alarm), data gap alarm test (disconnect a sensor, verify alarm fires within the configured staleness window), excursion report content verification (all required fields present and correct), and excursion report unalterability test (attempt to modify the excursion report after generation — must be rejected).
The QLean GAMP 5 Framework is built around a Purified Water distribution system — a continuous process system, not a cleanroom EMS. The framework does not contain EMS-specific templates (no room classification tables, no Annex 1 alert/action limit structures, no excursion report templates). What the framework provides that directly applies to an EMS project: the historian configuration design (FUNC-DATA-001/002, SDS Section 7) — time-based storage, no deadband, write-once architecture, and data gap detection — is the same architecture an EMS historian must use. The two-tier alarm strategy (FUNC-ALM-001/002 in FDS, FB_AlarmManager in SDS) covers the same Medium/High priority split that EMS alert/action limits require. The auto-generated report pattern (FUNC-REP-002) — triggered by a system event, fixed content, unalterable after generation — is the same design pattern an EMS excursion report must follow. The audit trail UDT (typ_AuditEntry_GxP) with 8 required fields covers configuration changes to alert and action limits with the same attribution and write-once architecture. These are the validated design patterns to adapt for an EMS project — the EMS-specific content (room classifications, parameter limits, Annex 1 requirements) is layered on top of these foundations.