Professional Documents
Culture Documents
U R T For A Supervisory Control and Data Acquisition (SCADA) Process Control System
U R T For A Supervisory Control and Data Acquisition (SCADA) Process Control System
for a
Supervisory Control and Data Acquisition (SCADA)
Process Control System
USER REQUIREMENTS Page 2 of 65
JETT SPECIFICATION <PCS Identifier> URS, Rev.0
Process Control System December 7, 2002
NOTES for use of the User Requirements Template:
Upon completion of the template, delete this page prior to updating the Table of Contents and printing.
1. Many areas of this template have selections or tables that have been prepared for guidance and
ease of template completion. Text in italics is intended to be used as notes to the User and
should be deleted prior to printing. Any options and/or examples that are not applicable to the
specific document being created should be deleted as well.
2. To update the final Table of Contents, place the cursor inside the shaded area, press the Right
mouse key, and select Update Field.
4. Where possible, the User should identify the source (e.g. studies, standards, etc.) for the
acceptable ranges of variables or other critical requirements that have been derived.
REVISION HISTORY
Document No.:
Insert the Document Identification Number and Revision.
PCS Identifier:
Insert description of system, e.g. Process Control System for Sterile Manufacturing Area.
I.0 INTRODUCTION
I.1. Purpose
This User Requirements Specification (URS) defines the purpose of the <PCS
Identifier>. It identifies the functions to be carried out, the data on which the system
will operate, and the operating environment. It also defines any non-functional
requirements, constraints such as time and costs, and what deliverables are to be
supplied.
I.3. Scope
This document begins to define the process control system requirements for:
• Hardware and software platforms
• Network communication
• Equipment control
• Automated process area sequencing
• Process equipment modeling for Batch management
• Human Machine Interface (HMI)
• Electronic data and record storage
The key objective is to provide a process control system with the required functionality
and flexibility while simultaneously meeting the requirements of ISPE GAMP 4, cGMP,
FDA’s 21 CFR Part 11, ISA S88.01, and <User Company> policies and procedures.
The benefit of meeting or exceeding these key objectives is a profitable manufacturing
facility offering flexibility to meet market demand.
II.0 OVERVIEW
II.1. Background
M a t e r ia l H a n d lin g
R e c e iv in g
U t i li t i e s
W a r e h o u s e
P r e w e ig h H ig h P u r ity S t e a m
W F I C h il l e d W a t e r
B u f f e r P r e p In s t r u m e n t A ir
S h ip p in g W a s t e H a n d lin g
M a n u f a c t u r Mi n a g n u C f a e c lt lu Ar i n g C e ll B
R e a c t o r R e a c to r P a c k a g in g A r e a A
R 1 0 0 R 2 0 0
C e n t r if u g e C e n tr if u g e B o t t le P r e p A
C 1 0 0 C 2 0 0
B o t t lin g L in e A
W a s h T a n kW a s h T a n k
T 1 0 0 T 2 0 0
B o t t lin g L in e B
R e c e iv in g TR a e nc ek i v i n g T a n k
T 1 0 1 T 2 0 1 C a r t o n in g
E x i s t i n g N e w M o d i f i e d
R e g u la t e d S y s t e m s
C o r e S y s t e m s M a t e r i a l H a n dP l ri no g c e s s A u t o m a t io n S y s t e m s
S y s t e m s
M R P S y s t e m W a r e h o u s e M a n a gM e a m n e u nf at c t u r i n g
S y s t e m P r o c e s s C o n t r o l
D o c u m e n t M a n a g eP mr e e w n e t i g h M E S
S y s t e m B u ff e r P r e p
a t c B h in g S t a tio n s
L IM S B u il d i n g M a n a g e m e n t
S y s t e m M a n u f a c t u r in g C e ll A
P r o c e s s C o n t r o l S y s t e m
P r o c e s s H is t o r ia n
M a n u f a c t u r in g C e ll B
P r o c e s s C o n t r o l S y s t e m
U t ilit ie s
P r o c e s s C o n t r o l
H ig h P u r ity S t e a m
S k id C o n t r o lle r
C h il l e d W a t e r
S k id C o n t r o lle r
W F I
P r o c e s s C o n t r o l S y s t e m
E x i s t i n g N e w M o d i f i e d
In lieu of PCS implementation, SOP driven, manual paper system(s), are used to perform
the following functions:
• Tracking process equipment “fitness for use” for a specific function (such as
“Clean”, “Sterile”, “Full”, “Empty”, etc.), as well as equipment sterility
expiration. When a PCS phase/procedure is initiated by an operator, it is the
operator’s responsibility, supported via manual paper systems, to ensure the
subject process equipment is suitable for the PCS phase or procedure
application. The PCS ensures that the subject process equipment is available
and not currently in-use by another phase/procedure. The PCS equipment
model only maintains process unit statuses of “In-Use” or “Available”.
Additional statuses or states pertaining to a unit’s fitness for use are not
required.
• Material tracking, including all batch/lot material and intermediate product
genealogy tracking.
• Batch/lot tracking, including batch/lot reporting. PCS-generated “electronic
tickets” and automated batch reports are not required. Additionally, PCS is
not required to maintain or track unique batch identifiers. Lot Identifiers and
Product Codes are manually input to the PCS at appropriate process intervals
and utilized for historical data record retention as key fields.
Data from other sources (user inputs, recipes, tunable parameters, intelligent devices,
etc.) are combined with process data into a single logical database that defines, in real
time, the known state of the process. Control strategy algorithms produce process
control outputs that are also combined into the logical database to complete the process
state definition.
Design of PCS data collection features shall consider all of the following:
Factor Description
Response time for value display and alarming, historical data
Required
collection frequency, and control processing requirements should
immediacy
dictate the minimum acceptable data collection and transfer rates.
Insignificant digits should not be presented to users, historically
Required precision
collected, or considered in data processing.
In some component systems, communication delays may introduce
transient and/or scan-based differences in data values. Data
collection design must prevent inconsistent display, control
response, and historical collection of alarm and other threshold
Data consistency
events. The design must also avoid other data collection and
communication mechanisms that could result in sustained
inaccuracies between display data, historical data, and control
processing data.
Future expansion Hardware, software, and communications design should provide
and/or capacity for future expansion and potential changes to control and/or
enhancement display strategies.
Factor Description
The PCS must be designed to prevent any individual failure from
jeopardizing personnel safety and/or product quality. Where PCS
Fault tolerance features are instrumental in protecting personnel and/or product
quality and/or major processing equipment, a Failure Modes and
Effects Analysis (or comparable risk assessment) is required.
III.1.3.1. Concept
Basic control consists of algorithms performed on monitored data values (including
process control inputs, user inputs, tunable parameters, and constants) to determine the
state of process control outputs. Included in basic control are normal control module
algorithms (valve control, pump control, feedback loop control, etc.) and interlocking.
Basic control is intended to be completely independent of the intended use of the process
equipment. This provides the flexibility to permit manual operations that may:
• Not have been anticipated during the process and/or control system design,
• Require some level of operator protection (alarms, interlocks, etc.),
• Require documented evidence of what was done, and/or
• Require some level of automation (input scaling, closed-loop control, etc.).
Factor Description
Control modules should be designed to seamlessly accept, and
respond appropriately to, mode, state, and setpoint requests from:
• User interface(s) (including local control stations),
• Supervisory processes (e.g., phases), and
Control request
• Interlocks.
management
Control module interfaces should, where possible, clearly identify
the current state, the current mode, and the source of active control.
Invalid user inputs should, where possible, produce a message
identifying the reason the input will not be processed.
Control module mode changes should not cause an immediate
Bumpless transfer
corresponding change in control module state, setpoint, or output.
Every unexpected combination of I/O states (and/or values) should
Fault annunciation result in a specific failure alarm (e.g., “valve uuu-XV-iiii failed to
and response open”). Control module fault response should be designed to
mitigate risk to personnel, product, and equipment.
Control modules may be subordinate to supervisory objects
including complex modules (e.g., header or dispensing system) and
phases. Mode changes and faults in subordinate control modules
Harmony with shall either:
supervisory control • Propagate the mode or fault to the supervisory object, or
• Override the subordinate mode and/or fault monitoring and
comprehensively replace it with mode and/or fault
monitoring by the supervisory object.
All relevant data (I/O, user requests, parameters, etc.) shall be
appropriately considered by the control module algorithms. For
Data utilization example, if a block valve includes both an Open limit switch and a
Closed limit switch, the state of both switches should be considered
in determining the actual state of the valve.
Where applicable and possible, installed simulation activation and
Harmony with
I/O forcing shall be obvious from all impacted user interfaces and
simulation
reports.
III.1.3.3. Interlocks
Interlocks modify control module states in response to process conditions in order to
protect personnel, process equipment, and/or product. Design of PCS interlocks shall
consider all of the following:
Factor Description
Interlock functionality should not consider current product
Product processing requirements. In general, interlocks should only be
independence applied for personnel protection, equipment protection, and/or
prevention of product contamination.
Control modules may be subordinate to supervisory objects
including complex modules (e.g., header or dispensing system) and
phases. Interlocks in subordinate control modules shall either:
Harmony with • Propagate the interlock to the supervisory object, or
supervisory control • Disable (fault) the supervisory object, or
• Override the subordinate interlock and replace it with a
complimentary interlock and/or fault monitoring by the
supervisory object.
The ability to manually override interlocks, if available, shall be
Overrides
reserved for engineering and maintenance users.
Control module interfaces should, where possible, clearly identify
whether or not a control module interlock is active. The specific
Display cause of the interlock should be either displayed as part of the
control module interface and/or readily accessible from the control
module interface.
Historical data collection must include a record of interlock-related
Record of interlock
events (activation, clearing, overrides, etc.). Reports that include a
events
list of alarms and events should include interlock-related events.
Factor Description
All complex modules should be instantiated from a limited number
Commonality and of complex module classes. Uncommon complex module attributes
consistency (e.g., extra routing valves) should be transparent to PCS users where
appropriate.
Each complex module class should have a specific and well-defined
set of attributes. Typical attributes include:
• Setpoint (Vxxxx-Vyyyy, charge, jacket control, etc.),
Class attributes • State (Vxxxx-Vyyyy, charge, jacket control, etc.),
• Requested Mode (manual, automatic, etc.)
• Mode (manual, automatic, etc.), and
• Fault (failed to start, deviation from setpoint, etc.).
Complex modules should be designed to seamlessly accept, and
respond appropriately to, mode, state, and setpoint requests from:
• User interface(s) (including local control stations),
• Supervisory processes (e.g., phases), and
Control request
• Interlocks.
management
Complex module interfaces should, where possible, clearly identify
the current state, the current mode, and the source of active control.
Invalid user inputs should, where possible, produce a message
identifying the reason the input will not be processed.
Complex module mode changes should not cause an immediate
Bumpless transfer
corresponding change in complex module state, setpoint, or output.
Every unexpected combination of control module states (and/or
values) should result in a specific failure alarm (e.g., “valve uuu-
Fault annunciation
XV-iiii failed to open”). Complex module fault response should be
and response
designed to mitigate risk to personnel, product quality, and process
equipment.
Mode changes and faults in complex modules that are subordinate to
a phase shall either:
Harmony with • Propagate the mode or fault to the phase, or
supervisory phases • Override the subordinate mode and/or fault monitoring and
comprehensively replace it with mode and/or fault
monitoring at the phase level.
Where applicable and possible, installed simulation activation and
Harmony with
I/O forcing shall be obvious from all impacted user interfaces and
simulation
reports.
III.1.4.1. Concept
Equipment phases provide all of the recipe-driven processing functionality of the PCS.
Each equipment phase provides a strategic combination of regulatory and sequential
control intended to exploit a specific processing capability of the equipment. The
following principles should guide the identification of equipment phases:
• Equipment phases should be based on process equipment capability and
should in no way be product-specific,
• Equipment phases should operate autonomously, except as necessary to
coordinate material transfers or other multi-unit activities,
• Equipment phases should not share control modules with other equipment
phases except where necessitated by process equipment design, and
• Shared equipment phases and shared control modules should not
unnecessarily restrict or otherwise interfere with parallel activities.
The focus of this PCS is the Process Control activities defined by the S88 Standard. This
section defines the interface requirements for the PCS to the Unit Supervision, Process
Management and Recipe Management activities implemented by the Batch Management
System as well as the required operator interfaces to these control activities. The Batch
Manager Interface (BMI) is required to:
• Provide an operator interface for manual control of batch state transitions
• Report status for equipment procedural logic elements used as a part of recipe
execution
• Provide download and upload capability for recipe parameters
• Provide for PCS ad hoc event reporting to the Batch Manager.
III.1.8.1. Startup
System documentation shall include detailed procedures for starting the PCS (in total)
and for starting individual PCS components, as appropriate. On startup, the PCS shall
maintain controlled process equipment in its pre-defined safe (typically de-energized)
state until specific user commands are applied to begin process control.
To the extent possible, PCS event log(s) shall record events indicating the startup of PCS
components. The ability to restart the PCS components after an abnormal shutdown
(e.g., power interruptions) shall, in general, be available to any user with a valid PCS
user account.
III.1.8.2. Shutdown
System documentation shall include a detailed procedure for performing a controlled and
complete shutdown of the PCS. PCS shutdown shall cause controlled process equipment
to revert to a pre-defined safe (typically de-energized) state.
The ability to shutdown the PCS shall be restricted to Supervisors, System
Administrators, Engineering, and Maintenance personnel. PCS event log(s) and/or alarm
log(s) shall indicate the normal shutdown of any PCS component. Where possible, PCS
event log(s) and/or alarm log(s) shall indicate abnormal PCS component shutdowns (e.g.,
power interruptions).
III.1.11. Security
All PCS components and networks shall be designed to protect against deliberate and/or
accidental activities that could potentially compromise personnel, product, equipment,
and electronic records. Physical controls should include protection of all PCS
components (through locking individual enclosures and/or through isolation in protected
areas such as locked rooms) from reasonable attempts to disrupt or modify the
component. Logical controls should include user authentication for any process control
or PCS modification activity. Refer to the User Interfaces section for additional
descriptions related to logical PCS controls.
III.2. Data
Feature Capacity
At least 10% installed spare capacity should be provided for each
I/O type (discrete inputs, discrete outputs, analog inputs, analog
outputs, etc.). At least 25% total spare space should be available
Process Inputs and for installation of additional I/O (i.e., additional wiring, terminals,
Outputs and I/O modules) without the need for additional conduits or
cabinets. Theoretical ability to expand the scope of the PCS by at
least 50% (e.g., through addition of cabinets, processors, etc.)
should be provided.
No more than 50% of the processing capacity of PCS components
Processing Power should be required to provide normal processing and display
functionality with satisfactory performance.
No more than 50% of the installed physical memory in PCS
Memory components should be required to provide normal processing and
display functionality.
Local Electronic No more than 50% of the installed hard disk capacity in PCS
Storage components should be consumed by installed software.
Historical data storage capacity should allow for online retrieval of
Historical and at least 30 days of any historical data. Archive data storage should
Archive Storage be adequate to fulfill current electronic record retention
requirements with at least 25% spare capacity.
The PCS should have the ability to expand user interfaces
User Interfaces (workstations and/or displays) by at least 25% without deviating
from the fundamental PCS architecture.
Online user interfaces to PCS historical data includes all of the following:
• Time-sequenced trending of analog values,
• Query-driven display of alarm, event, and batch records, and
• Pre-configured reports.
Access to online (i.e., not yet archived) historical data should be optimized for efficient
retrieval. However, no specific access speed specification is applicable due to the diverse
nature of potential queries. Instead, the following interface guidelines are recommended:
• For data retrieval that could take more than ten (10) seconds, an on-screen “in
progress” indication should be provided.
• For data retrieval that could take more than twenty (20) seconds, an ability to
cancel the query should be provided.
• For data retrieval that could take more than thirty (30) seconds, a rough
progress indicator (e.g., percent complete bar graph) should be provided.
III.3.1. General
Task Description
Features that allow users to manipulate process control elements
Process Control: (e.g., by changing control module modes, states, etc.). Process
Detailed control is commonly provided as part of the process monitoring
detail interface features.
Features that provide for monitoring and control of recipe
Process Control: execution. Batch management features typically include screens
Batch Management for batch initiation, resource arbitration, batch monitoring, user
prompts/responses, individual phase control, alarms, and reports.
Features, protected from operator access, designed to provide
extraordinary process and batch management controls. Protected
Supervisory
supervisory capabilities may include overriding interlocks,
Functions
modifying batch execution, temporarily modifying engineering
parameters, workstation shutdown, etc.
Features designed to notify user of monitored alarms, allow
Alarm Management acknowledgement of those alarms, provide a record of alarm-
related events, and display summaries and histories of alarms.
Features designed to display the status of the Process Control
PCS Analysis
System components.
Features designed to select and display/print written summaries of
Reports
historical production data.
Features provided to allow for future modification of application
configuration and/or source code. These typically include access to
Programming and
the primary operating system interface(s) and employ strict user
Configuration
access controls to help enforce adherence to change control
procedures.
Features provided to allow for creation, modification, and deletion
Recipe Management
of process recipes.
Navigation Attribute
Process detail displays (i.e., faceplates) should provide single
keystroke/click navigation to real-time and/or historical trend display(s).
Process displays should provide single keystroke/click navigation to batch
management display(s).
Batch management displays should provide single keystroke/click
navigation to associated process display(s).
Display navigation (excluding login) should not require keyboard
keystrokes (i.e., pointing device motion and clicks should be sufficient for
navigation).
Display navigation should not require use of a pointing device (i.e.,
keyboard keystrokes should be sufficient for navigation).
The PCS must be capable of capturing and printing a “live color snapshot” of all process
monitoring displays.
The alarm summary shall provide the following real-time information for each alarm:
• Alarm tag
• Value of the alarm setting being transgressed
• Time and date of last alarm activation
• Alarm severity
• Critical alarm category
• Area / Cell / Unit in which the alarm was generated
• Alarm state and severity
• Lot # (if appropriate)
As a default, all system alarms should be presented to the operator on a priority basis
defined as ‘oldest, highest priority, non-acknowledge alarm’ first. The PCS shall provide
for filtering and display of the alarm list in the following ways:
• Alarm severity
• Critical alarm category
• Process Area / Cell / Unit
Report Description
Disabled Alarm Report A report listing all current disabled alarms
Annunciated PCSThese events and errors are to be treated as electronic records (i.e., not
maintained exclusively in text files).
III.3.8. Reports
PCS user interfaces should provide the features needed to request, display, and print
reports. A comprehensive batch end report that includes all values and events needed to
evaluate production quality. These include, at least, the following:
• Record of all employed recipes and/or procedures,
• Record of all alarms and acknowledgements,
• Record of all important events (processing steps, manual actions, etc.), and
• Record of key process measurements (temperatures, pressures, sample results,
etc.).
III.6. Environment
III.6.1. Layout
The following draft floor plan(s) indicates the physical location of the process and related
equipment:
{Insert preliminary facility floor plan(s) for the process area(s), control locations, and
server rooms}
Classification Description
Refers to the minimum protection provided by enclosures located in the
area. Type 12 enclosures are intended for indoor use primarily to
NEMA12
provide a degree of protection against dust, falling dirt, and dripping
noncorrosive liquids.
Class I locations are defined by the National Electric Code as those
locations in which flammable gas or vapor may be present in the air in
NEC Class I quantities sufficient to produce explosive or ignitable mixtures. All
NEC classes may be subdivided as Division 1 (Normally Hazardous) or
Division 2 (Not Normally Hazardous).
Class II locations are defined by the National Electric Code as those
locations that are hazardous due to the presence of combustible dusts.
NEC Class II
All NEC classes may be subdivided as Division 1 (Normally Hazardous)
or Division 2 (Not Normally Hazardous).
United States Federal Standard for clean room air classification
US FS 209D characterized by airborne particulates (> 5 microns) less than 100
Class 100 particles per cubic foot (equivalent to US FS 209E class M 3.5 and to
ISO EN 14644-1 class 5).
United States Federal Standard for clean room air classification
US FS 209D characterized by airborne particulates (> 5 microns) less than 1,000
Class 1000 particles per cubic foot (equivalent to US FS 209E class M 4.5 and to
ISO EN 14644-1 class 6).
United States Federal Standard for clean room air classification
US FS 209D characterized by airborne particulates (> 5 microns) less than 10,000
Class 10,000 particles per cubic foot (equivalent to US FS 209E class M 5.5 and to
ISO EN 14644-1 class 7).
United States Federal Standard for clean room air classification
US FS 209D characterized by airborne particulates (> 5 microns) less than 100,000
Class 100,000 particles per cubic foot (equivalent to US FS 209E class M 6.5 and to
ISO EN 14644-1 class 8).
IV.0 CONSTRAINTS
IV.1. Project Constraints
IV.1.1. Schedule
{Insert project schedule and/or key milestones}
IV.2. Compatibility
{This section identifies corporate and/or site and/or process area and/or project standards applicable to
the Process Control System (PCS). The arrangement and subdivision of standards is unimportant (e.g.,
PCS Configuration, User Interface, and Coding Standards may be identified in separate or combined
standards), however, all standards identified in this section should be addressed by the URS.
IMPORTANT: In the interest of project efficiency, standards attached to the URS should specifically
identify the constraints applicable to the subject PCS (not general one-size-fits-all standards). A
checklist showing exactly which standards will be verified is recommended.}
{Complete the above table. Clearly indicate which roles are, and are not, applicable to
the current project.}
Solutions based on other hardware may be acceptable, but must be identified, justified,
and approved at the earliest possible point within the project. Conformance to project
standards is verified as part of Design Qualification and/or Acceptance Testing and/or
Installation Qualification.
{Complete the above table. Clearly indicate which roles are, and are not, applicable to
the current project.}
Solutions based on other COTS software may be acceptable, but must be identified,
justified, and approved at the earliest possible point within the project. Conformance to
project standards is verified as part of Design Qualification and/or Acceptance Testing
and/or Installation Qualification.
IV.3. Maintenance
V.0 LIFE-CYCLE
V.1. Development
If S88 is to be applied to the equipment being acquired, it should be referenced in this
section of the document.
The Supplier shall provide a Quality and Project Plan as part of their proposal. The
Supplier shall have a quality system in place. Internal quality procedures shall be available
for the User’s review.
The Supplier shall provide a Project Manager for the project to provide a single
communication point with the User.
The project shall utilize the GAMP methodology when developing the system and
documentation.
V.2. Testing
Describe the Supplier testing requirements. Reference the Validation Test Plan, Factory
Acceptance Test, special tests, etc. This section should also include required amount of
demonstrated run time, any special materials necessary to complete testing, integration
testing, etc.
In order to verify system performance, the User shall witness the execution of the Factory
Acceptance Test procedures. The Supplier shall notify the User _______ weeks in
advance of the start of this test.
The Factory Acceptance Test Specification shall be submitted to the User for review and
approval prior to execution. A minimum of _______ weeks shall be allowed for the User
to review and to comment and/or approve the Factory Acceptance Test Specification.
Refer to the Equipment Validation Plan for applicable procedures.
V.3. Delivery
The [equipment/system], with all options, equipment, and the documentation listed below,
shall be delivered to the User’s receiving dock.
V.3.1.Documentation
Installation, operation, and maintenance instruction documentation for the system
shall be developed to a level that is comprehensible to a high school graduate.
The Supplier shall use the formats described in the GAMP Supplier Guide, Current
Version, to produce the documentation. The Supplier shall provide the
V.4. Support
Describe what support activities are required after acceptance. The paragraphs outlined
below provide some areas for consideration.
VI.0 GLOSSARY
VI.1. Terminology
{If necessary, attach a glossary of terms that may be unfamiliar to the Supplier (or other
document readers) and/or terms that may have meanings specific to entries in this User
Requirements Specification. For example (example list is not intended to be complete):}
Term Definition
Alarm Log A listing that is a permanent record of alarm activities within a defined
period. The listing is a replica of sequential alarm events, normally
including the activation and acknowledgement activities.
Alarm Summary A listing of alarms that are currently in active and/or have been yet been
acknowledged. The listing is not a permanent record alarm-related events.
Basic Control Control that is dedicated to establishing and maintaining a specific state of
equipment.
Batch The material that is being produced or that has been produced by a single
execution of a batch process.
Batch Process A process that produces a specific quantity of product by subjecting
specific quantities of raw materials to a defined order of discontinuous
processing actions over a period of time using one or more pieces of
equipment.
Control Module A regulating device, a state-oriented device, or a combination of regulating
and state oriented devices that are controlled as a single device.
Control Recipe A type of recipe, which, through its execution, defines the manufacture of
a single batch of a specific product. The control recipe contains the
specific processing requirements for the actual batch, raw materials, and
product. It is a copy of a master recipe made unique through the
assignment of a lot number.
Coordination Control A type of control that directs, initiates, and/or modifies the execution of
procedural control and the utilization of equipment entities.
Equipment Control The equipment specific functionality that provides the actual control
capability for an equipment entity, including procedural, basic and
coordination control, which is not part of the recipe.
Equipment Module A functional group of subordinate equipment modules and/or control
modules that can carry out a specific minor processing activity such as
producing individual CIP fluids.
Life-Cycle A series of stages through which a system passes during its lifetime.
Lot Number An alphanumeric set of characters that uniquely identify and specify the
product that is produced at a specific unit operation.
Master Recipe A type of recipe that accounts for equipment capabilities and may include
process cell-specific information. The master recipe is used as a template
for creation of a control recipe.
VI.2. Acronyms
{If necessary, attach a list of acronyms that may be unfamiliar to the Supplier (or other
document readers) and/or acronyms that may have meanings specific to entries in this User
Requirements Specification. For example (example list is not intended to be complete):}
Acronym Full Spelling Definition
ANSI American National An organization that produces standards, practices, and
Standards Institute codes related to pharmaceutical manufacturing.
degC Celsius (centigrade) A unit of temperature measurement.
CFR Code of Federal Regulations Written version of the national laws of the United
States of America.
cGMP current Good A set of regulations governing the manufacture of
Manufacturing Practices pharmaceutical products.
CPG Compliance Policy Guide US FDA Publications that supplement and/or explain
and/or interpret specific requirements from the Code
of Federal Regulations(CFR)
DCS Distributed Control System A proprietary automation solution providing I/O
monitoring and control equipment with a tightly
integrated HMI and ancillary applications (trending,
redundancy, etc.).
EBR Electronic Batch Record A collection of production data stored in secure
electronic (digital) form.
EPA Environmental Protection A United States agency responsible for environmental
Agency protection.
degF Fahrenheit A unit of measure for temperature.
FDA Food and Drug A United States agency responsible for consumer
Administration safety related to drugs and drug products.
Good Automated A methodology for implementing and documenting
GAMP
Manufacturing Practices automated systems.
GUI Graphical User Interface An application resident on an Operator Interface that
provides a pictorial interface for process monitoring
and control.
HMI Human-Machine Interface A PC-based graphical user interface used for
monitoring and controlling an industrial process.
I/O Input/Output The hardware required to convert field signals to/from
a computer-usable form.
IEEE Institute of Electrical and An organization that produces standards related to
Electronics Engineers electrical and electronic components, including
networking.
IQ Installation Qualification Approved documented verification that an object or
system is installed according to written and approved
specifications and drawings.
IS Intrinsically Safe Standards related to equipment and wiring installation
in explosive or potentially explosive environments.