A process skid can pass its factory demonstration and still be unsuitable for the manufacturing site. The controller runs the sequence, but a network interruption leaves the batch record incomplete; an operator can change a parameter without a traceable reason; a replacement server cannot restore the approved recipe. These are requirements failures before they become validation findings. An automation user requirements specification, or URS, must describe the manufacturing outcome, the conditions under which it must remain reliable, and the evidence needed to accept it.
This article addresses the engineering URS for PLC, DCS, SCADA, historian, MES and their interfaces. It does not prescribe a universal architecture or replace a site validation procedure. Its purpose is to help process engineering, operations, automation, quality and IT/OT agree what the system must accomplish before a supplier fixes the design.
Start with intended use and the automation boundary
Describe the product family, process stages, operating modes and decisions supported by the system. A controller that regulates vessel temperature has a different intended use from a historian used to investigate excursions, even when both handle the same measurement. Identify whether a function controls the process, informs an operator, creates a required record, authorises an activity or transfers information to another system. Those purposes determine the necessary controls and acceptance evidence.
Draw physical and logical boundaries separately. The physical boundary includes instruments, remote I/O, controllers, workstations, servers, network components and supporting infrastructure. The logical boundary includes recipes, calculations, permissions, interfaces, data transformations and ownership. An externally managed identity service may sit outside the supplier's delivery scope while remaining a dependency of the qualified system. Record that dependency explicitly, including who supplies, configures, tests and maintains it.
List exclusions with their receiving owner. “MES integration excluded” is incomplete if the skid cannot release a batch without a MES response. Identify the approved operating behaviour before that interface exists and the conditions for its later introduction.
Separate user outcomes from design choices
A URS statement should tell the designer what is needed without disguising an unexamined preference as a requirement. “Use redundant servers” names a solution. “Maintain the defined supervisory functions during the identified single-server failure without losing committed batch records” describes an outcome that can be analysed. Redundancy may be the chosen solution, but its boundary, failover behaviour and remaining failure modes still need justification.
Some technical constraints are legitimate: a supported site platform, an approved network architecture, an existing equipment protocol or a required maintenance skill set. Label these as constraints and explain their origin. Distinguish mandatory requirements from preferences and future options. Otherwise suppliers may price desirable features as compulsory while overlooking a critical data dependency hidden in narrative text.
Give every requirement a stable identifier, owner and acceptance route. Avoid combining unrelated obligations in a single sentence. A requirement covering access control, backup, electronic signatures and alarm management cannot be meaningfully accepted by one unchecked “compliant” response.
Define control functions and abnormal operation
Specify the controlled variables, manipulated outputs, operating ranges, process states and transitions. The URS need not contain every line of PLC code, but it must identify critical behaviours: how a sequence starts, pauses, holds, aborts, restarts and ends; how equipment availability is determined; and how an interrupted operation is reconciled. Define who may request each transition and which conditions the controller must confirm before acting.
Distinguish a permissive that allows an action, an interlock that prevents or changes an action, and an alarm that requires an operator response. An alarm is not automatically a protective function. Likewise, an HMI confirmation is not proof that a physical valve moved. For critical commands, specify feedback, mismatch handling and the record required to explain the actual outcome.
Describe manual and degraded modes deliberately. Identify retained protections, restricted functions and additional operating controls. A blanket instruction to switch to manual after communication loss is unsafe as a design assumption: the acceptable response depends on the process state, equipment and hazards. Define the response to loss of power, instrument quality, communications and supporting services individually.
Assign recipes, parameters and approval responsibilities
Separate an approved master recipe from the control recipe instantiated for a particular batch. A formula or parameter set supplies values; it is not necessarily the entire recipe, which also includes procedural and equipment requirements. Decide where each element is authored, approved, downloaded and executed. A MES may coordinate workflow while a controller executes phases, but that allocation must be explicit.
Specify permitted parameter ranges, authority to change them, effective version and treatment of batches already in progress. Include the behaviour when a downloaded recipe is incomplete, incompatible with equipment configuration or older than the approved version. Define whether a change requires reapproval, a new batch instance or documented exception handling. Values must come from process knowledge and the approved control strategy, not from the automation supplier's default library.
For CIP and SIP applications, distinguish cycle execution from the evidence that the cycle met its acceptance criteria. The automation must preserve the information needed for that evaluation without claiming that a successful sequence alone proves cleaning or sterilisation effectiveness.
Identify records before selecting storage
Create a data inventory linking each data class to its use and owner. Include raw measurements, quality flags, timestamps, units, batch identifiers, recipe versions, operator actions, exceptions, calculations and review decisions. A displayed value may be transient. A GMP record requires the context necessary to reconstruct the relevant activity. Decide which system holds the authoritative record and how other copies are identified.
Specify historian collection and compression according to the events the record must resolve. Fast controller execution does not guarantee equivalent historian resolution. Challenge whether collection, aggregation or deadband can conceal a short excursion or remove evidence of a state change. Define treatment of missing, delayed, invalid and backfilled values. Do not invent a universal sampling interval or retention duration.
Distinguish an audit trail from an event log and an alarm log. The URS should identify relevant changes and deletions, associated identity, chronology, reason where required, review access and export needs. A generic “audit trail enabled” statement does not establish that recipe approvals, configuration changes or privileged actions are captured adequately.
Make interfaces accountable for the business transaction
For every interface, record the sending and receiving owners, object identifiers, field meanings, units, version rules, timestamps and transaction states. A network acknowledgement may confirm delivery to a service without confirming that a material issue, batch instruction or result was accepted by the receiving application. Define the business confirmation and the action taken when it is missing or negative.
Specify retry and duplicate handling together. After a connection failure, the sender may not know whether its first message was applied. Repeating the message without a stable transaction identity can duplicate consumption or initiate an unintended operation. State how reconciliation detects omissions, duplicates and conflicting states, and who can resolve them. Test recovery across the complete equipment–supervisory–execution path.
OPC UA, APIs and middleware are implementation options, not evidence of semantic correctness. Define the required security configuration and data contract independently of a supplier's claim that a standard protocol is supported.
Build a traceable requirement-to-evidence matrix
The following original engineering examples illustrate the structure. They are not universal specifications. Replace the operating conditions and acceptance details with the approved process and risk assessment.
| Requirement | Rationale | GMP impact | Risk | Acceptance criterion | Verification | Evidence |
|---|---|---|---|---|---|---|
| Use the approved recipe version for the batch | Prevent unintended parameter sets | Process consistency | Obsolete recipe executes | Only an eligible approved version can start; actual version remains linked to the batch | Challenge approved, obsolete and incompatible versions | Configuration baseline, execution record and exception results |
| Preserve interface transaction identity through retry | Avoid duplicate application | Material and batch genealogy | Repeated message changes quantity twice | Repeated delivery has one intended effect; conflicts are visible for reconciliation | Interrupt response after receiver commitment | Sender/receiver records and reconciliation result |
| Recover the defined batch record | Maintain reconstructability | Review and retention | Restored application lacks metadata | Approved recovery set yields readable, complete, correctly associated records | Restore into the authorised recovery environment | Recovery log, comparison and reviewer acceptance |
A traceability matrix is useful only when its links point to actual evidence. Distinguish verification by review, inspection, analysis and testing. Where one test supports several requirements, explain its coverage rather than multiplying identical scripts. Where a requirement remains unverified, retain the gap visibly through release decisions.
Specify access, chronology and OT security together
Define roles from real tasks: operation, recipe authoring, approval, maintenance, administration and record review. Identify incompatible privileges and controlled emergency access. Vendor remote access needs a separate lifecycle: request, authorisation, connection, supervision where appropriate, recording and closure. A normal operator account is not an adequate model for an external integrator with configuration privileges.
Describe the time source, synchronisation dependencies, time-zone representation and behaviour after loss of synchronisation. Technical timestamps need interpretation to support GMP chronology. Specify how the system distinguishes occurrence time from receipt time and retains that distinction during buffering and replay.
Use the OT asset inventory and risk assessment to define segmentation, permitted communications, secure configuration, patch evaluation and recovery requirements. IT security controls require evaluation against process availability and equipment constraints. Conversely, validation status does not justify leaving an identified vulnerability unmanaged.
Define availability, recovery and the lifecycle handover
Availability describes continued service; recovery describes restoration after disruption. Neither is established merely by buying redundant hardware. Identify common dependencies such as shared power, storage, authentication and networks. Define the process consequences of losing each service, including whether manufacturing can continue, hold safely or requires a controlled stop.
Separate backup from archive and from disaster recovery. A backup supports restoration; an archive preserves retrievable records over their required life; disaster recovery coordinates applications, infrastructure, data, people and restart decisions. Derive recovery time and acceptable data-loss objectives from process and business continuity needs. Include configuration, certificates, licenses, recipes and dependencies in the recovery scope.
Require a maintainable handover: approved source and configuration baselines, access to engineering tools, supplier support boundaries, supported versions, obsolescence information, spare hardware strategy and change procedures. Define evidence for restoration and upgrades before the original project team disappears.
Set a proportionate assurance and acceptance strategy
[REGULATORY REQUIREMENT] For applicable EU GMP activities, Annex 11 connects user requirements to GMP impact, documented risk and lifecycle traceability. Annex 15 addresses qualification and validation. These obligations should be translated into relevant engineering evidence, not a predetermined document count. Their current operative texts remain distinct from the 2025 consultation drafts, checked on 23 September 2026.
[GUIDANCE] GAMP 5 second edition supports a risk-based approach. FDA's final February 2026 CSA guidance concerns medical-device production and quality management system software; it is not a blanket replacement for pharmaceutical CSV. [STANDARD] ASTM E2500-25 provides a science- and risk-based manufacturing-system verification framework. Select applicable methods and document the rationale without treating voluntary guidance as legislation.
[GUIDEGXP RECOMMENDATION] Agree before procurement which supplier evidence may be reused, the conditions for accepting it, and the site-specific gaps to close. FAT can demonstrate configured functions; SAT can examine installation and site interfaces. Neither label alone establishes qualification. Release should identify the accepted configuration, resolved defects, justified residual risks, trained owners and remaining actions with explicit disposition.
Review the URS with a realistic failure scenario
Consider a batch vessel whose controller continues running while the historian connection fails. Operations wants continuity, quality needs complete batch evidence, and IT proposes automatic retry. Walk through the interruption from measurement to final review. Determine what is buffered, where capacity is monitored, how timestamps and quality are retained, what happens when buffering is exhausted, and how the recovered dataset is reconciled.
The useful result is a set of linked requirements and acceptance scenarios. A single sentence saying “no data loss” leaves the design unresolved. The same walkthrough should show whether stopping the process, continuing with approved alternative records or holding at a defined state is justified. That decision belongs to the site process and risk assessment, with supplier input.
- Can every critical requirement be connected to a manufacturing or record need?
- Are normal, abnormal, manual and recovery behaviours defined?
- Do interfaces confirm the intended transaction, not only communication?
- Can the site obtain, review, restore and retain the necessary evidence?
- Are ownership, acceptance and lifecycle support responsibilities unambiguous?
Use the broader Automation & Digital Systems decision areas to develop the architecture and assurance strategy. The URS is ready for approval when the team can explain both the required outcome and how it will know that outcome has been achieved.
References and status
- European Commission, EudraLex Volume 4: current Annex 11, Chapter 4 and Annex 15.
- European Commission, 2025 consultation: draft revisions, distinct from current requirements.
- ISPE GAMP 5, second edition, July 2022: industry guidance.
- FDA CSA guidance, February 2026: final, medical-device scope.
- ASTM E2500-25: active engineering standard; publisher scope reviewed.
- NIST SP 800-82r3: final OT security guidance; revision 4 remains a draft.
