USER REQUIREMENTS TEMPLATE For A Supervisory Control and Data Acquisition (SCADA) Process Control System

USER REQUIREMENTS TEMPLATE
for a
Supervisory Control and Data Acquisition (SCADA)
Process Control System

JETT
USER REQUIREMENTS
SPECIFICATION
Page 2 of 66
<PCS Identifier> URS, Rev.0 <PCS Identifier> URS, Rev.0
December 7, 2002

JOINT EQUIPMENT TRANSITION TEAM

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.

3. Items that can be directly tested are identified with a !.

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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 3 of 66
December 7, 2002


TABLE OF CONTENTS
REVISION HISTORY ............................................................................................................................. 5
1.0 INTRODUCTION ........................................................................................................................ 6
1.1. PURPOSE ...................................................................................................................................... 6
1.2. ORIGIN AND CONTEXT ................................................................................................................. 6
1.3. SCOPE .......................................................................................................................................... 7
1.4. DOCUMENT ORGANIZATION ........................................................................................................ 8
2.0 OVERVIEW .................................................................................................................................. 9
2.1. BACKGROUND .............................................................................................................................. 9
2.1.1. Project Overview ................................................................................................................ 9
2.1.2. Facility Overview .............................................................................................................. 10
2.1.3. Automation Overview ........................................................................................................ 12
2.2. GENERAL SYSTEM FUNCTIONS .................................................................................................. 14
2.3. SIMULATION SYSTEM ................................................................................................................. 14
2.4. EXCLUSIONS AND FUTURE CONSIDERATIONS ............................................................................ 14
3.0 OPERATIONAL REQUIREMENTS ....................................................................................... 16
3.1. FUNCTIONS ................................................................................................................................ 16
3.1.1. Process Monitoring ........................................................................................................... 16
3.1.2. Alarm Management ........................................................................................................... 17
3.1.3. Basic Control .................................................................................................................... 19
3.1.4. Equipment Phase Control ................................................................................................. 23
3.1.5. Batch Management ........................................................................................................... 24
3.1.6. Historical Data Collection and Retention ........................................................................ 25
3.1.7. Other Monitoring and Control Features .......................................................................... 26
3.1.8. Modes of Operation .......................................................................................................... 26
3.1.9. Performance and Timing .................................................................................................. 28
3.1.10. Response to Failures ......................................................................................................... 29
3.1.11. Security ............................................................................................................................. 30
3.1.12. Safety ................................................................................................................................. 30
3.2. DATA ......................................................................................................................................... 31
3.2.1. Preliminary Data Definitions ........................................................................................... 31
3.2.2. Capacity Requirements ..................................................................................................... 32
3.2.3. Access Speed ..................................................................................................................... 33
3.2.4. Archive Requirements ....................................................................................................... 34
3.2.5. Data Security and Integrity ............................................................................................... 34
3.3. USER INTERFACES ...................................................................................................................... 36
3.3.1. General ............................................................................................................................. 36
3.3.2. Process Monitoring ........................................................................................................... 40
3.3.3. Batch Management Interfaces .......................................................................................... 44
3.3.4. Alarm Management Interfaces .......................................................................................... 45
3.3.5. PCS Status Interface ......................................................................................................... 48
3.3.6. Programming and Configuration Interfaces .................................................................... 49
3.3.7. Recipe Management Interface .......................................................................................... 49
MacBook Pro 8/22/14 4:46 PM
Deleted: 45
Deleted: 46
JETT
USER REQUIREMENTS
SPECIFICATION
Page 4 of 66
December 7, 2002


3.3.8. Reports .............................................................................................................................. 49
3.4. REMOTE PCS ACCESS ................................................................................................................ 50
3.5. INTERFACES WITH OTHER SYSTEMS ........................................................................................... 50
3.5.1. Intelligent Process Interfaces ........................................................................................... 50
3.5.2. Other Process Control Systems ........................................................................................ 50
3.5.3. Other Computerized Systems ............................................................................................ 50
3.5.4. Shared Resources .............................................................................................................. 50
3.6. ENVIRONMENT ........................................................................................................................... 51
3.6.1. Layout ............................................................................................................................... 51
3.6.2. Physical Conditions .......................................................................................................... 51
4.0 CONSTRAINTS .......................................................................................................................... 53
4.1. PROJECT CONSTRAINTS ............................................................................................................. 53
4.1.1. Schedule ............................................................................................................................ 53
4.1.2. Procedural Constraints ..................................................................................................... 53
4.2. COMPATIBILITY ......................................................................................................................... 54
4.2.1. Hardware Standards and Preferences .............................................................................. 54
4.2.2. COTS Software Standards and Preferences ..................................................................... 55
4.2.3. PCS Configuration and Integration Standards ................................................................ 56
4.2.4. PCS User Interface Standards .......................................................................................... 57
4.2.5. PCS Programming Standards ........................................................................................... 58
4.3. MAINTENANCE ........................................................................................................................... 59
5.0 LIFE-CYCLE .............................................................................................................................. 59
5.1. DEVELOPMENT ........................................................................................................................... 59
5.2. TESTING ..................................................................................................................................... 59
5.3. DELIVERY .................................................................................................................................. 59
5.3.1. Documentation .................................................................................................................. 59
5.4. SUPPORT .................................................................................................................................... 61
5.4.1. Start-up Support (list available options) ........................................................................... 61
5.4.2. Post Start-up Support (list post-startup support available) .............................................. 61
6.0 GLOSSARY ................................................................................................................................ 62
6.1. TERMINOLOGY ........................................................................................................................... 62
6.2. ACRONYMS ................................................................................................................................ 64
Deleted: 50
Deleted: 51
Deleted: 51
Deleted: 51
Deleted: 52
Deleted: 54
Deleted: 54
Deleted: 54
Deleted: 54
Deleted: 55
Deleted: 55
Deleted: 56
Deleted: 57
Deleted: 58
Deleted: 59
Deleted: 60
Deleted: 60
Deleted: 60
Deleted: 60
Deleted: 60
Deleted: 60
Deleted: 62
Deleted: 62
Deleted: 62
Deleted: 63
Deleted: 63
Deleted: 65
JETT
USER REQUIREMENTS
SPECIFICATION
Page 5 of 66
December 7, 2002


REVISION HISTORY

Rev. Date Approval REVISION SUMMARY
A1 11/05/02 Initial document creation by Mark Tuepker
A2 12/07/02 Modifications to more accurately reflect JETT format and
content
A3 6/1/03 Content Review by Chris Roerig, Paul Coury, Steve Smith,
John Liebenthal
A4 6/14/04 Content Review by Chris Roerig, Pat Cashman, Andre Powell,
Sarah Powell, Michelle Ubele

JETT
USER REQUIREMENTS
SPECIFICATION
Page 6 of 66
December 7, 2002


Project No.:
Insert the unique project number associated with this particular URS.

Document No.:
Insert the Document Identification Number and Revision.

PCS Identifier:
Insert description of system, e.g. Process Control System for Sterile Manufacturing Area.
1.0 INTRODUCTION
1.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.
1.2. Origin and Context
<Supplier Company> has been contracted by <User Company> to develop the URS for
the <PCS Identifier>, to be located in <PCS Location>. The format and content of this
URS are based on the Good Automated Manufacturing Practices (GAMP) Guide
available through the International Society for Pharmaceutical Engineering (ISPE).
The project role and significance of this document is identified in:
! <PCS Validation Plan Reference>
Once approved, this document will provide a foundation for the development of
functional specifications, design specifications, and Performance Qualification testing
protocols. Modifications to, and/or deviations from, the specifications in an approved
URS are subject to formal change control procedures.
The following documents are related to the <PCS Identifier> URS:
# Reference Contains
1 Project Scope and Charter
2 Process design
3 Applicable automation standards

JETT
USER REQUIREMENTS
SPECIFICATION
Page 7 of 66
December 7, 2002


1.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

This document does not cover:
Non-GMP Building Management System (BMS)
GMP BMS
Programmable Logic Controllers Hardware and Software
Raw Material Information System
Industrial Technologies (IT) systems hardware and software

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,
FDAs 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.

JETT
USER REQUIREMENTS
SPECIFICATION
Page 8 of 66
December 7, 2002


1.4. Document Organization
In accordance with the GAMP Guide description of URS contents, the remainder of this
document includes the following sections:
# Section Sub-Section Contains
2 Overview Background Facility Overview, Project Overview, and
Automation Overview
Key objectives and benefits General statement of automation constraints.
Main functions and interfaces Description of the process control system role.
Applicable GxP Requirements Specific identification of constraining regulatory
requirements
Other Applicable Regulations Specific identification of other constraining
regulatory requirements
3 Operational
Requirements
Functions Functions required, calculations, modes of
operation, performance and timing requirements,
action required in case of failure, safety, security
Data Definition of data, capacity requirements, access
speed requirements, archive requirements, data
security and integrity
Interfaces: User Interfaces User roles/functions and the interface provisions
Interfaces: System Interfaces Interface with other automated or computerized
systems
Interfaces: Equipment Interfaces Interface to sensors and actuators
Environment: Layout Space(s) provided for automation equipment
Environment: Physical Conditions Physical conditions prevalent in space(s) provided
for automation equipment
4 Constraints Project Constraints Timescales and milestones, procedural constraints
Compatibility Existing systems, automation strategies, and
automation policies
Maintenance Availability, ease of maintenance, expansion
capability, likely enhancements, expected lifetime,
and long term support
5 Life Cycle Development Methodologies, project management, and quality
assurance
Testing Testing strategies, special requirements, and
simulations
Delivery Information related to required supplier deliverables
Support Support required after system acceptance
6 Glossary Terminology List of document terms and their meanings
Acronyms List of abbreviations and their meanings
JETT
USER REQUIREMENTS
SPECIFICATION
Page 9 of 66
December 7, 2002


2.0 OVERVIEW
2.1. Background
2.1.1. Project Overview
2.1.1.1. Project Summary
The <PCS Identifier> will be developed/modified as part of {Describe, in broad terms,
the project of which the PCS development is a part. Include specific project identifiers,
like project number(s), products, and key processing technologies.}
2.1.1.2. Key Objectives
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,
FDAs 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.
2.1.1.3. Anticipated Benefits
The following is a list of the major benefits anticipated from the project:
Benefit Explanation
Increased Capacity
Manufacturing Process Change
Reduced Product Losses
Increased Flexibility
Improved Regulatory Compliance
Reduced Maintenance
Technology Upgrade

JETT
USER REQUIREMENTS
SPECIFICATION
Page 10 of 66
<PCS Identifier> URS, Rev.0
December 7, 2002


2.1.2. Facility Overview
The <Facility Identifier> is a manufacturing facility located in <location> designed to
produce <Facility Product Description>. The following model identifies site equipment
pertinent to this project:
{The diagram below is provided as a sample to indicate the appropriate level of detail for
the facility overview. Replace with diagrams and/or information specific to your
facility.}

Receiving
Warehouse
Preweigh
WFI
Buffer Prep
Shipping
Material Handling
High Purity Steam
Chilled Water
Instrument Air
Waste Handling
Utilities

Reactor
R100
Centrifuge
C100
Wash Tank
T100
Receiving Tank
T101
Manufacturing Cell A
Reactor
R200
Centrifuge
C200
Wash Tank
T200
Receiving Tank
T201
Manufacturing Cell B
Bottle Prep A
Bottling Line A
Bottling Line B
Cartoning
Packaging Area A

Existing New Modified

JETT
USER REQUIREMENTS
SPECIFICATION
Page 11 of 66
December 7, 2002


2.1.2.1. Existing Facilities and Equipment
<Overview Description of Relevant Existing Facilities and Equipment>
2.1.2.2. New Facilities and Equipment
<Overview Description of New Facilities and Equipment>
2.1.2.3. Modifications to Existing Facilities and Equipment
<Overview Description of Modifications to Existing Facilities and Equipment>

JETT
USER REQUIREMENTS
SPECIFICATION
Page 12 of 66
December 7, 2002


2.1.3. Automation Overview
The following diagram identifies site automation systems pertinent to this project:
{The diagram below is provided as a sample to indicate the appropriate level of detail for
the automation overview. Replace with diagrams and/or information specific to your
facility.}

MRP System
Document Management
System
LIMS
Process Historian
Core Systems
Warehouse Management
System
Preweigh MES
Building Management
System
Material Handling
Systems
Buffer Prep
Batching Stations
Manufacturing Cell A
Manufacturing Cell B
Manufacturing
Process Control
High Purity Steam
Skid Controller
Chilled Water
Skid Controller
WFI
Utilities
Process Control
Process Automation Systems
Regulated Systems

Existing New Modified

JETT
USER REQUIREMENTS
SPECIFICATION
Page 13 of 66
December 7, 2002


2.1.3.1. Existing Systems
<Overview Description of Relevant Existing Systems>
2.1.3.2. New Systems
<Overview Description of New Systems>
2.1.3.3. Modifications to Existing Systems
<Overview Description of Modifications to Existing Systems>

JETT
USER REQUIREMENTS
SPECIFICATION
Page 14 of 66
December 7, 2002


2.2. General System Functions
The PCS maintains a secure environment in accordance with cGMP, GAMP, and FDA
21CFR Part 11 requirements using S88.01 standards. The PCS monitors and controls the
cGMP portion of the <Project Title> to:
Provide an interactive illustration of the <Project Title> process for operator
information and process control
Provide equipment status and monitoring functionality
Provide sequential process control via control modules, phases and/or
procedures
Acquire process data for real-time and historical analysis
Tailor procedural control of the process via parameter modification
2.3. Simulation System
The PCS vendor scope includes the hardware and packaged software necessary to
configure and support an independent Simulation System. The Simulation System shall
be initially installed at the vendor site and utilized for the development and factory testing
of the <Project Title> application software. When the <Project Title> application
software is ready for installation at the <User Company> <building name> facility, it
will be transferred from the Simulation System to the facility PCS hardware platform.
Subsequently, the Simulation System hardware and packaged software will also be
moved to the <User Company> site, and utilized for PCS application maintenance and
enhancement activities.
2.4. Exclusions and Future Considerations
The S88.01 standard and the utilized hardware/software platform provide extensive
capabilities within a batch environment. <User Company> has elected to limit the initial
implementation of select batch capabilities, favoring a high level of manual process
interaction by operating personnel, supported by Standard Operation Procedure (SOP)
driven paper system(s). This initial operating philosophy does not imply that future
enhancement(s) will not take greater advantage of the capabilities provided by the PCS,
but does significantly impact functions commonly associated with a S88.01 batch facility.
The PCS functionality is limited as follows:
Implemented procedures pertain exclusively to CIP and SIP functions. All
other sequential functionality required is implemented at the unit phase level.
Manufacturing operations will be performed by manually initiating equipment
phases as required. Additionally, prior to initiating a phase, the operator may
be required to manually perform any set-up required such as:
verifying/placing all process unit valves in automatic mode, verifying/placing
all control modules are in automatic mode, etc.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 15 of 66
December 7, 2002


It is <User Company>s intent to continue development of various facility
procedures, beyond those initially provided at PCS startup. It is the intent that
phases developed for the <Project Title> project be suitable for use in these
future procedure development activities. Where feasible, procedures and
operations are designed and implemented as a library of phase building
blocks, even though a given phase may not be utilized in a procedure at the
time of PCS startup. It is understood that the phase library at PCS startup,
may not include all phases necessary to support continued procedure
development, without the need for development of additional phases.

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
operators 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 units 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.

JETT
USER REQUIREMENTS
SPECIFICATION
Page 16 of 66
December 7, 2002


3.0 OPERATIONAL REQUIREMENTS
3.1. Functions
3.1.1. Process Monitoring
3.1.1.1. Real-Time Data Collection and Dissemination
The <PCS Identifier> collects process data, as transmitted from process instrumentation,
and makes the process data available for any or all of the following:
Basic Data Processing (i.e., conversion to digital data in engineering units),
Process Alarm Detection and Alarm Management,
Processing to accomplish control strategies,
Display to PCS users, and
Historical data collection.

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
Required
immediacy
Response time for value display and alarming, historical data
collection frequency, and control processing requirements should
dictate the minimum acceptable data collection and transfer rates.
Required precision
Insignificant digits should not be presented to users, historically
collected, or considered in data processing.
Data consistency
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
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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 17 of 66
December 7, 2002


Factor Description
Future expansion
and/or
enhancement
Hardware, software, and communications design should provide
capacity for future expansion and potential changes to control
and/or display strategies.
Fault tolerance
The PCS must be designed to prevent any individual failure from
jeopardizing personnel safety and/or product quality. Where PCS
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.

3.1.1.2. Basic Data Processing
All data monitored by the PCS shall be immediately converted to standard engineering
units prior to use in any comparison or control logic. This conversion should also include
normalization of discrete data values (e.g., so that 1 always represents the alarm state
for a discrete input alarm and the open state for a valve). Process control outputs
should undergo similar conversions immediately prior to transmittal.
3.1.1.3. Process Alarm Detection
Process alarm detection functionality compares data values against range and alarm
limits. Range errors and alarms should be propagated, as appropriate, to subsequent data
processing logic. All non-discrete dynamic system inputs automatically monitored by the
PCS should be subjected to both range checking and appropriate alarm checking.
All non-discrete manual system inputs should also be subjected to range checking. Out-
of-range manual data entries should be rejected (with an appropriate message explaining
why the value was rejected) and/or treated as a process alarm (i.e., annunciated and
subjected to alarm management functions), as appropriate. All manual entries, including
rejected entries, should be recorded in PCS event logs, if practicable.
3.1.2. Alarm Management
3.1.2.1. Alarm Configuration
The PCS must provide for configuration of alarms to detect unexpected process
excursions for operator notification and /or response. Two basic types of alarms must be
supported by the PCS, process alarms and equipment alarms. Process alarms differ from
equipment alarms in that their parameters such as, setpoint, time delay, deadband, etc
must be modifiable during progression of a batch process on a per step basis from the
phase logic. Equipment alarm parameters are tuned to meet the specific equipment
requirements and once set, are only modified if physical changes occur to the equipment.
Both types are subjected to the alarm management requirements described in this section.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 18 of 66
December 7, 2002


The Locally Controlled Packaged Equipment section discusses the operator interface
with vendor provided control system(s) on packaged equipment. Alarms originating
within these vendor provided control system(s), but displayed on PCS screens, are also
subject to the alarm management requirements as described within this section.
The system shall provide for process alarm priorities, a minimum of five levels, which
are selectable during configuration. At least one of the priority levels will represent
alarms that affect the quality of the batch (GMP alarm level). Other alarm priorities will
be assigned to equipment protection, personnel safety and operator information.
The S88 concept of process units, grouped in plant cells and areas will allow for alarm
enable/disable of those groupings (e.g. during maintenance, shutdown etc.). Additionally,
it will also be possible to suppress temporarily (override), with proper authority, an
individual alarm caused by a defective device. Operator alarm override actions will be
recorded by the system and will automatically be reset at the beginning of each controller
resident phase.
The system shall support the following configuration parameters for each alarm
Type of Alarm Absolute alarm, Offset from Setpoint, Percent Offset from
Setpoint.
Alarm Setpoints for low-low, low, high and high-high severity levels
Alarm Priority minimum of five levels definable during configuration
Alarm Delay - time delay of alarm conditions to eliminate alarms associated
with momentary measurement spikes (e.g., an alarm condition must exist for 5
seconds before activating an alarm).
Alarm Deadband the ability to configure an alarm to turn on at one value
and clear at another Ramp setpoints and configure alarms as setpoint +/-
tolerance. This helps minimize nuisance alarms associated with normal
control loop setpoint changes.
Pause Enable Configurable ability for alarm activation to cause running
batch logic to pause. Note alarm point must be directly associated with a
process unit.
3.1.2.2. Alarm Acknowledgement
Operators must be logged on to the PCS and have the proper authority as enforced by
PCS security to acknowledge alarms. The PCS shall record in the operator action log all
acknowledgement activities. The operators electronic signature, the action taken, date
and time must be recorded with each acknowledgement. The PCS shall support two
means for operators to acknowledge alarms, on an individual basis, and on a group basis.
The group shall be all current unacknowledged alarms displayed on the alarm list. Note
that group acknowledgement shall result in an entry in the operator action log for each
individual alarm.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 19 of 66
December 7, 2002


3.1.2.3. Alarm Output devices
The system shall support the following output devices. System configuration shall allow
for changes in alarm states to activate any combination of the devices:
Console screen (visual)
Console screen (audible)
Control room or plant floor flashing light and/or horn
Alarm printer
Annunciator panels
3.1.3. Basic Control
3.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.).
3.1.3.2. Control Modules
A control module is a regulating device, a state-oriented device, or a combination of
regulating and state oriented devices that is operated as a single device. Examples of
control modules include block valves, modulating valves, PID controllers, fixed-speed
motors, and variable speed motors. Design of PCS control modules shall consider all of
the following:
Factor Description
Commonality and
consistency
All control modules should be instantiated from a limited number of
control module classes. Uncommon control module attributes (e.g.,
reverse-acting limit switch) should be transparent to PCS users
where appropriate.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 20 of 66
December 7, 2002


Factor Description
Class attributes
Each control module class should have a specific and well-defined
set of attributes. Typical attributes include:
Setpoint (open, close, 50%, etc.),
State (open, closed, etc.),
Requested Mode (manual, automatic, etc.)
Mode (manual, automatic, etc.), and
Fault (failed to start, deviation from setpoint, etc.).
Control request
management
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
Interlocks.
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.
Bumpless transfer
Control module mode changes should not cause an immediate
corresponding change in control module state, setpoint, or output.
Fault annunciation
and response
Every unexpected combination of I/O states (and/or values) should
result in a specific failure alarm (e.g., valve uuu-XV-iiii failed to
open). Control module fault response should be designed to
mitigate risk to personnel, product, and equipment.
Harmony with
supervisory control
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
shall either:
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.
Data utilization
All relevant data (I/O, user requests, parameters, etc.) shall be
appropriately considered by the control module algorithms. For
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.
Harmony with
simulation
Where applicable and possible, installed simulation activation and
I/O forcing shall be obvious from all impacted user interfaces and
reports.

JETT
USER REQUIREMENTS
SPECIFICATION
Page 21 of 66
December 7, 2002


3.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
Product
independence
Interlock functionality should not consider current product
processing requirements. In general, interlocks should only be
applied for personnel protection, equipment protection, and/or
prevention of product contamination.
Harmony with
supervisory control
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:
Propagate the interlock to the supervisory object, or
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.
Overrides
The ability to manually override interlocks, if available, shall be
reserved for engineering and maintenance users.
Display
Control module interfaces should, where possible, clearly identify
whether or not a control module interlock is active. The specific
cause of the interlock should be either displayed as part of the
control module interface and/or readily accessible from the control
module interface.
Record of interlock
events
Historical data collection must include a record of interlock-related
events (activation, clearing, overrides, etc.). Reports that include a
list of alarms and events should include interlock-related events.

3.1.3.4. Complex Modules
Complex modules include control modules with subordinate control modules and
equipment modules with subordinate equipment modules and/or control modules.
Common complex modules include:
Header valve groups (where the complex module setpoint identifies a transfer
source, a transfer destination, or a source-destination pair)
Batch dispense stations (including a flow control valve, a totalizer, and one or
more block valves)
Temperature control module (where media routing valves are controlled based
on a desired vessel jacket state or temperature setpoint)
JETT
USER REQUIREMENTS
SPECIFICATION
Page 22 of 66
December 7, 2002


NOTE: Complex Modules are differentiated from Equipment Phases which are
controlled through the Batch Manager interface. A complex module is an independent
object that can be utilized with and/or without the Batch Manager. PCS design need only
include complex modules if routine non-automatic production is anticipated and manual
equipment phase control is too cumbersome for this routine non-automatic production.
Design of PCS complex modules shall consider all of the following:
Factor Description
Commonality and
consistency
All complex modules should be instantiated from a limited number
of complex module classes. Uncommon complex module attributes
(e.g., extra routing valves) should be transparent to PCS users where
appropriate.
Class attributes
Each complex module class should have a specific and well-defined
set of attributes. Typical attributes include:
Setpoint (Vxxxx-Vyyyy, charge, jacket control, etc.),
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.).
Control request
management
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
Interlocks.
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.
Bumpless transfer
Complex module mode changes should not cause an immediate
corresponding change in complex module state, setpoint, or output.
Fault annunciation
and response
Every unexpected combination of control module states (and/or
values) should result in a specific failure alarm (e.g., valve uuu-
XV-iiii failed to open). Complex module fault response should be
designed to mitigate risk to personnel, product quality, and process
equipment.
Harmony with
supervisory phases
Mode changes and faults in complex modules that are subordinate to
a phase shall either:
Propagate the mode or fault to the phase, or
Override the subordinate mode and/or fault monitoring and
comprehensively replace it with mode and/or fault
monitoring at the phase level.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 23 of 66
December 7, 2002


Factor Description
Harmony with
simulation
Where applicable and possible, installed simulation activation and
I/O forcing shall be obvious from all impacted user interfaces and
reports.

3.1.4. Equipment Phase Control
3.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.
3.1.4.2. Normal Operation
Once initiated, an equipment phase typically initiates appropriate monitoring (e.g., fault
detection) and proceeds through an orderly sequence of steps. The quantity and identity
of steps should be sufficient to clearly distinguish the equipment phase progress and to
support orderly restart logic.
If general, successful equipment phase operation should not be contingent upon:
The execution of previous equipment phases, or
The execution of parallel equipment phases (except as needed for product
transfers), or
The execution of subsequent equipment phases, or
The anticipated state or status of uncontrolled equipment.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 24 of 66
December 7, 2002


3.1.4.3. Exception Handling
Equipment phase exception handling should respond, as appropriate, to controlled
equipment alarms, interlocks, and faults, unexpected process deviations, invalid
parameter values, communication faults, and user intervention commands. Exception
handling should be sufficiently exception-specific in order to provide the least intrusive
response that still provides adequate personnel, equipment, and product protection. For
example, a product temperature deviation should not necessarily disable automatic
temperature control.
Equipment phase exception handling should be sufficiently robust that:
Direct and immediate actions are taken to ameliorate any condition that
jeopardizes personnel, equipment, or product,
Exception handling actions are appropriate to both the type of exception and
the progress of the equipment phase sequence at the time of the exception,
Equipment phase execution is not interrupted by minor anomalies that are
unlikely to jeopardize personnel, equipment, or product (though operator
notification of all anomalies is generally required),
The response of concurrently executing equipment phases is appropriately
impacted to preserve the integrity of a Unit Operation,
The equipment phase, and associated Unit Operation, can be restarted by an
operator with a minimum of extraordinary manual restart preparations (e.g.,
by simply commanding the Unit Operation to restart), and
Restarting an equipment phase, and associated Unit Operation, should
automatically resume manufacturing operations without unnecessarily
repeating steps or extending execution times (e.g., by unnecessarily resetting
totalizers, counters and timers).

3.1.5. Batch Management
The <Project Title> automation solution includes both the PCS and a batch management
system. The PCS shall be implemented within the framework of the Instrument Society
of America (ISA) standards S88.01, Standard for Batch Models and Terminology, and
draft standard dS95.01, Standard for Enterprise Control System Integration Models and
Terminology. The use of these standards supports application of industry standard
software packages and provides for flexibility and modularity required by the business
and automation objectives. The S88.01 control activity model defines the following
activities
Production Planning and Scheduling
Information Management
Recipe Management
Process Management.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 25 of 66
December 7, 2002


Unit Supervision and
Process Control

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.
3.1.6. Historical Data Collection and Retention
3.1.6.1. Historical Data Values
Key process and production data values shall be collected and retained in a historical
database. Since these data are important electronic records, the PCS should employ
appropriate provisions for secure data collection and retention (e.g., automatic daily
backup, disaster recover provisions, long-term data archiving and restoration procedures,
etc). Existing site database facilities, capabilities, and procedures should be exploited, if
possible. Historical data shall be accessible for display in historical trends and, as
applicable, reports.
3.1.6.2. Alarms and Events
Process alarm and event data shall be accumulated in a historical database. Each record
shall include a date/time stamp, Batch/Lot identifier and the source process unit as the
primary keys for data retrieval. Since these data are important electronic records, the
PCS should employ appropriate provisions for secure data collection and retention (e.g.,
automatic daily backup, disaster recover provisions, long-term data archiving and
restoration procedures, etc). Existing site database facilities, capabilities, and procedures
should be exploited, if possible. Historical alarm and event data shall be accessible for
inclusion in onscreen displays and, as applicable, reports.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 26 of 66
December 7, 2002


3.1.7. Other Monitoring and Control Features
3.1.7.1. Locally Controlled Packaged Equipment
Select process equipment is packaged in a stand-alone configuration that includes
sufficient local control capability to perform the intended functionality. These packaged
systems are designed to include the necessary interface capability to permit
communication with the PCS. It is the responsibility of the System Integrator to
coordinate with the packaged equipment vendor(s) to determine the appropriate PCS
control strategy, general interface requirements, etc. Where practicable, PCS interface to
packaged equipment should follow S88 paradigms (e.g., by treating the packaged
equipment operation as an equipment phase).
3.1.7.2. Resource Management
Modes, states, statuses, and other attributes of all process resources (including process
units, bulk material supplies, logical modules such as totalizers, etc.) should be clearly
defined and appropriately managed. User interfaces to these process resources should
provide for attribute monitoring and, with appropriate security, manual adjustment.
Managed resource attributes (e.g., bulk material supply Ready status and process unit
Clean status) should be considered in Basic Control interlocks and Equipment Phase
exception handling, as appropriate.
3.1.7.3. Engineering Parameters
In general, hard-coded values related to both Basic Control and Equipment Phase Control
should be scrupulously avoided. Instead, tunable variables and/or constants should be
identified, initialized, and used throughout the control logic. Examples of tunable
variables and/or constants, referred to generally as Engineering Parameters, include:
Scaling constants and alarm limits,
Deadbands and delays,
Controller tuning constants,
Dispensing pre-action limits and tolerances, and
Conversion constants (e.g., material specific gravity).
3.1.8. Modes of Operation
3.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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 27 of 66
December 7, 2002


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.
3.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).
3.1.8.3. Normal Operation
On PCS restart according to the PCS startup procedure(s), normal operation shall be
enabled. System documentation shall include detailed procedures for normal PCS
operation (e.g., display elements and navigation, starting batches, using control modules,
etc.). The ability to perform normal PCS operations shall be based on privileges
associated with the users account.
3.1.8.4. Simulation
The PCS shall include process simulation capability including:
The ability to temporarily force any discrete or analog input to any valid
value, and
The ability to set individual control modules feedback simulation to auto-
respond to control module states (e.g., Open feedback energizes and closed
feedback de-energizes whenever the valve stat is OPEN).
The ability to enable simulation shall be restricted to Supervisors, System Administrators,
Engineering, and Maintenance personnel. PCS event log(s) and/or alarm log(s) shall
indicate transitions to/from simulation mode.
3.1.8.5. Disaster Recovery
System documentation shall include detailed procedures for a complete re-install of
software on each PCS component. These procedures shall include sufficient detail to
completely re-build the PCS from purchased hardware and archived software.
Independent electronic copies of all software required to re-build the PCS shall be
supplied with the PCS.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 28 of 66
December 7, 2002


3.1.9. Performance and Timing
3.1.9.1. PCS Performance
PCS performance should be adequate to provide a safe, effective, and responsive system.
The following guidelines are intended to indicate performance expectations:
Activity/Event Performance Expectation
Process Monitoring
and Basic Control
Response
PCS control responses (e.g., PID controller output change in
response to a deviation from setpoint) should be commensurate with
the potential significance of the process change. For example:
Slow-moving regulatory response (e.g., vessel temperature
control) should occur within five (5) seconds.
Fast-moving regulatory response (e.g., line pressure control)
should occur within one (1) second.
Process Input
Display
PCS display of process condition changes should be commensurate
with the potential significance of the process change. For example:
All changes in process conditions (i.e., instrument readings
and discrete feedback states) should be reflected in PCS
displays within five (5) seconds.
For process conditions that can exhibit rapid and significant
changes (e.g., pressure and flow readings, vessel rupture
disks), changes should be reflected in PCS displays within
two (2) seconds.
User Control
Command
Evidence of PCS response to user commands (e.g., changing control
module states, starting a batch) should be presented to the user
within one (1) second (e.g., by changing a commanded state
indication). Process control response to user commands should be
commensurate with the potential significance of the requested
change. For example:
A valid user command to start a batch should activate the
first equipment phase within ten (10) seconds.
A valid user command to change the state of a control
module should change the appropriate control output within
two (2) seconds.
Display Navigation
Evidence of PCS response to a user command to change displays
should be presented to the user within one (1) second. The target
display should be completely painted, with up-to-date data values,
within five (5) seconds.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 29 of 66
December 7, 2002


Activity/Event Performance Expectation
Workstation
Synchronization
When a process attribute is changed from one workstation, the
attribute change must be reflected on other workstation displays.
Such attribute changes should be reflected on all workstations
within three (3) seconds.
PCS Startup
In general, it should be possible to bring the PCS from a de-
energized state to a full working state within fifteen (15) minutes.
PCS Shutdown
In general, it should be possible to bring the PCS from a full
working state to a fully de-energized state in a controlled manner
within fifteen (15) minutes.

3.1.9.2. Date and Time
The PCS shall be designed to minimize and, as necessary, compensate for differences in
date and time values among PCS components. The following is a description of the
recommended date/time compensation procedure for a networked PCS:
A single timekeeper node shall be designated for the PCS. The date/time value for the
timekeeper node will be periodically reconciled to a known accurate date/time source.
Timekeeper node date/time value should not normally deviate from the known accurate
date/time source value by more than ten (10) seconds between periodic reconciliations. If
manual intervention is required to reconcile the timekeeper node date/time value,
reconciliations should not be required more frequently than once per week.
PCS nodes that base any activity, log, or display on the local date/time value should
automatically (i.e., without user intervention) reconcile their date/time value with the
timekeeper node date/time value periodically (typically once per day). Node date/time
values should not normally deviate from the timekeeper node date/time value by more
than ten (10) seconds between periodic reconciliations. All date/time reconciliations
(including the timekeeper node reconciliation) shall be recorded in the PCS event log(s)
in a way that allows determination of the pre-reconciliation date/time value offset.
3.1.10. Response to Failures
PCS components should include self-diagnostic capabilities for detecting:
Hardware failures and anomalies,
Software (application and services) failures and anomalies,
Operating System failures and anomalies, and
Communication failures and anomalies.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 30 of 66
December 7, 2002


All such PCS failures and anomalies should be treated as process alarms (i.e.,
annunciated and subjected to alarm management functions). PCS fault conditions that
potentially impact data quality should be propagated and accommodated, as appropriate,
in data processing, collection, and display.
3.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.
3.1.12. Safety
The PCS must be designed to both mitigate process hazards and to prevent introduction
of any new hazards related to the PCS components. The following process hazards
should be considered in PCS design:
Process Hazard Description

The following PCS component hazards should be considered in PCS design:
PCS Hazard Description
Repetitive Stress
Injury
Components that require routine use (e.g., user interface hardware)
should be ergonomically designed. All PCS components should
allow for easy access to facilitate cleaning, preventive maintenance,
and replacement.
Electrical
PCS equipment should comply with site electrical and construction
standards including appropriate grounding and fusing.
Explosive
PCS equipment should comply with regulations and standards
related to the explosive hazard classification of the installation area.
Tripping
PCS equipment should not block normal entry and egress pathways
or other personnel traffic areas.

JETT
USER REQUIREMENTS
SPECIFICATION
Page 31 of 66
December 7, 2002


3.2. Data
3.2.1. Preliminary Data Definitions
{Include or attach any project-specific data relevant to PCS specification and/or design.
The following should be considered minimum essential preliminary data:
Process Flow Diagram
Process Description
Scope of Automation
The following additional preliminary data should be included if available:
P&IDs
I/O List
Instrument List
Identification of Critical Parameters
Proposed PCS System Architecture and/or Hardware List(s)
Alarm Lists (Priorities, Types, Areas, Specific Alarms
Process Units List
Control Module Classes List
Control Modules List
Interlock List
Complex Module Classes List
Complex Modules List
Equipment Phase Class Lists (including parameter and faults)
Equipment Phase List
Recipe Lists (Procedures, Unit Operations, and Operations)
Historical Data Collection List
Locally Controlled Equipment List and/or Description(s)
Managed Resources List
Engineering Parameters List
User Interfaces List
JETT
USER REQUIREMENTS
SPECIFICATION
Page 32 of 66
December 7, 2002


User Interface Displays List
Statistical Process Control Description
Reports List and/or Description(s)
External PCS Interfaces List and/or Description(s)
Refer to Attachment A for sample Preliminary Data Formats. Note that much of the
additional preliminary data listed above represents preliminary functional and/or
design specifications. If practicable, development and publication of these items should
be reserved for the Functional Specification and/or Design Specification documentation.}
3.2.2. Capacity Requirements
Hardware and software selection should allow for some expansion without additional
hardware or software purchase. Hardware and software selection should allow for
significant future PCS expansion and/or extension with the purchase of additional
hardware and/or software. The following capacity constraints are recommended:
Feature Capacity
Process Inputs and
Outputs
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
for installation of additional I/O (i.e., additional wiring, terminals,
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.
Processing Power
No more than 50% of the processing capacity of PCS components
should be required to provide normal processing and display
functionality with satisfactory performance.
Memory
No more than 50% of the installed physical memory in PCS
components should be required to provide normal processing and
display functionality.
Local Electronic
Storage
No more than 50% of the installed hard disk capacity in PCS
components should be consumed by installed software.
Historical and
Archive Storage
Historical data storage capacity should allow for online retrieval of
at least 30 days of any historical data. Archive data storage should
be adequate to fulfill current electronic record retention
requirements with at least 25% spare capacity.
User Interfaces
The PCS should have the ability to expand user interfaces
(workstations and/or displays) by at least 25% without deviating
from the fundamental PCS architecture.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 33 of 66
December 7, 2002


Feature Capacity

3.2.3. Access Speed
3.2.3.1. Real-time Data
Access to real-time data, via workstation displays, is a primary function of the PCS.
Refer to the Functions - Performance and Timing subsection for a description of
performance expectations including input display and workstation synchronization
features.
3.2.3.2. Online Historical Data
PCS historical data includes all of the following:
Time-sequenced instrument readings and other process-related analog values,
Alarm and event logs, and
Batch event and data records.

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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 34 of 66
December 7, 2002


3.2.3.3. Archived Historical Data
Access to archived historical data should also be optimized for efficient retrieval. Since
archiving and retrieval mechanisms vary, no specific access speed specification is
applicable. In general, access to archived data in a specific format (report, chart, or
restoration to online status) should not require more than one (1) calendar day.
3.2.4. Archive Requirements
PCS historical data retention capabilities must conform to site and/or product data
retention requirements. In general, all PCS historical data (including time-sequenced
analog values, alarm, event, and batch logs) should be accessible for at least ten (10)
years. Any robust archiving technology is acceptable, however, existing site archiving
facilities, technologies, and procedures should be exploited if possible. Archive system
design should consider the potential for having to migrate the historical data so that
access can be preserved beyond the point of PCS de-commissioning.
PCS system manuals must include detailed procedures for committing historical data to
archive and for retrieving historical data from archive. Retrieved historical data must
include any and all data that was, or may have been, considered for verifying
manufacturing and/or product quality. Retrieved data context, format, and/or access must
be identical to, or at least comparable to, original data context, formats, and/or access.
The PCS must provide the ability to retrieve archived data without interrupting ongoing
process operations.
3.2.5. Data Security and Integrity
PCS data security and integrity features must be consistent with controls required by 21
CFR Part 11 to protect electronic records. The following table identifies anticipated PCS
design features intended to satisfy these requirements:
Part 11 Control PCS Compliance Feature(s)
System Validation
PCS development lifecycle and documentation must be adequate to
support system validation. This should include a specifications
traceability matrix and/or similar quality control mechanisms.
Copying Records
PCS manuals should include detailed procedures for generating
accurate and complete copies of records in both human readable
and electronic form.
Protection through
Retention Period
Refer to the Data - Archive Requirements subsection of this
document.
Limiting System
Access
Refer to the Functions - Security and User Interfaces - General:
Security subsections of this document.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 35 of 66
December 7, 2002


Part 11 Control PCS Compliance Feature(s)
Audit Trails
All PCS historical records shall use secure, computer-generated,
time-stamped audit trails to independently record the date and time
of operator entries and actions that create, modify, or delete
electronic records. Record changes shall not obscure previously
recorded information.
Operational System
Checks
PCS specification documentation shall clearly identify permitted
sequencing of steps and events that must be enforced, if any. The
PCS must be designed to enforce this sequencing, as appropriate.
Authority Checks
Refer to the Functions - Security and User Interfaces - General:
Security subsections of this document.
Device Checks
PCS specification documentation shall clearly identify restrictions
to valid sources of data input or operational instruction, if any. The
PCS must be designed to enforce these restrictions, as appropriate.
Training
Project documentation must identify minimum qualifications
(experience and training) for PCS developers. Each PCS
developers qualifications must be vetted against these
requirements. Developer resumes, or similar certificates of
qualification, must be included in project and/or PCS
documentation.
System
Documentation
Controls
System operation and maintenance documentation must be
included with the PCS. Distribution of, access to, and use of this
documentation must be adequately controlled and subject to
revision and change control procedures that maintain an audit trail
that documents time-sequenced development and modification of
systems documentation.
Open System
Controls
Systems with any component(s) that are not installed in an
environment in which system access is controlled by persons
responsible for the content of electronic records that are on the
system are considered Open Systems. Open systems must
include controls to ensure the authenticity and integrity of
electronic records from the point of their creation to the point of
their receipt. Such procedures and controls shall include additional
measures such as document encryption and use of appropriate
digital signature standards.

JETT
USER REQUIREMENTS
SPECIFICATION
Page 36 of 66
December 7, 2002


3.3. User Interfaces
3.3.1. General
3.3.1.1. User Interface Design
User Interfaces are designed to facilitate both general process awareness and specific
PCS tasks. The following table outlines the specific tasks accommodated by PCS user
interface features:
Task Description
Process Monitoring:
Overview
Features designed to provide a rapid and accurate assessment of the
status of the entire process within the scope of PCS control.
Overview displays typically display key module states and/or
measurements for a process cell, or a portion of a process cell, in a
graphical format.
Process Monitoring:
Unit
Features designed to provide structured access to the primary
state(s) and values for all modules and/or measurements. Unit
displays typically present modules related to a single process unit
and/or ancillary equipment in a graphical format.
Process Monitoring:
Detail
Features designed to provide structured access to all important
attributes (including identification, modes, states, setpoints, values,
etc.) of an individual module and/or instrument. Detailed process
monitoring is commonly provided through onscreen popups that
mimic traditional analog instrument faceplates.
Process Monitoring:
Analytical
Features designed to display historical and/or statistical information
to users. These typically include a historical trend display and, for
discrete manufacturing, one or more Statistical Process Control
displays.
Process Control:
Detailed
Features that allow users to manipulate process control elements
(e.g., by changing control module modes, states, etc.). Process
control is commonly provided as part of the process monitoring
detail interface features.
Process Control:
Batch Management
Features that provide for monitoring and control of recipe
execution. Batch management features typically include screens
for batch initiation, resource arbitration, batch monitoring, user
prompts/responses, individual phase control, alarms, and reports.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 37 of 66
December 7, 2002


Task Description
Supervisory
Functions
Features, protected from operator access, designed to provide
extraordinary process and batch management controls. Protected
supervisory capabilities may include overriding interlocks,
modifying batch execution, temporarily modifying engineering
parameters, workstation shutdown, etc.
Alarm Management
Features designed to notify user of monitored alarms, allow
acknowledgement of those alarms, provide a record of alarm-
related events, and display summaries and histories of alarms.
PCS Analysis
Features designed to display the status of the Process Control
System components.
Reports
Features designed to select and display/print written summaries of
historical production data.
Programming and
Configuration
Features provided to allow for future modification of application
configuration and/or source code. These typically include access to
the primary operating system interface(s) and employ strict user
access controls to help enforce adherence to change control
procedures.
Recipe Management
Features provided to allow for creation, modification, and deletion
of process recipes.

3.3.1.2. User Interface Hardware
User Interface hardware may include computer terminals, panel-mounted interface
equipment (push-buttons, signal/status lights, hand switches, etc.), tower lights, horns,
message displays, and printers. User interface hardware locations are intended to provide
users ready access to the PCS in close proximity to the process operation or process
equipment of interest. Hardware and/or enclosures must be suitable to the installation
environment (refer to the Environment - Physical Conditions subsection for details).
User Interface hardware fault-tolerance features must be appropriate to the hardware
function. Where possible, hardware failure alerts should be integrated with the user
interface in a way that allows for appropriate response and maintenance.
3.3.1.3. Security
All PCS user interfaces must be designed to control user access. Access controls must be
consistent with 21 CFR Part 11 requirements for protection of computer systems that
employ electronic records and electronic signatures. These include (but are not limited
to) the following:
JETT
USER REQUIREMENTS
SPECIFICATION
Page 38 of 66
December 7, 2002


User accounts shall be unique to one individual and shall not be reused by, or
reassigned to, anyone else.
User accounts not based on biometrics shall employ at least two distinct
identification components such as a User ID and password. At least one of
these components should be secret or otherwise guaranteed to be unique.
Workstation logins should expire (e.g., by automatic logout) if no user activity
occurs within a pre-determined, definable time period.
Use of transaction safeguards to prevent unauthorized use of a user account,
and to detect and report in an immediate and urgent manger any unauthorized
access attempt to the system security unit, and, as appropriate, to
organizational management.
Access level assigned to an individual will dictate which workstations, interfaces, and
displays a user has access to, and which operations the user can perform. Where feasible,
user access administration should leverage existing site computer security policies and
procedures (including security administration servers and existing user accounts).
Users may be allowed to view and navigate operating displays without login. However, a
login is required to perform any activity that changes any process attribute (e.g., module
modes and states, setpoints, and parameter values) or in any way modifies the Process
Control System (e.g., configuration changes, node startup/shutdown, and code changes).
Activity-based, as opposed to workstation login based, security features are preferred.
Records of operator actions should include the operators identity, as confirmed by user
account login information. All PCS access attempts and results must be recorded and
accessible for review and/or reporting.
3.3.1.4. Workstation Roles and Access
Startup characteristics of each workstation should be appropriate to the role of the
workstation and/or the workstation login account authority. For example, process
operator workstations should start by showing a startup menu and/or overview display
appropriate to the specific role of the workstation. The following may be controlled
according to the workstation role:
Access to specific displays,
Menu system(s) appearance,
Alarms annunciated locally, and
Alarm list filtering.
Workstation features should allow for changing the specific role of the workstation
without restarting.
With proper authority, all PCS operating displays should be accessible from any PCS
workstation. Security features should be capable of limiting workstation functionality
according to the following user characteristics:
JETT
USER REQUIREMENTS
SPECIFICATION
Page 39 of 66
December 7, 2002


User Attribute
Level/class of Authority (operator, maintenance, supervisor, etc)
Area of Process Responsibility (utilities, process unit A, cleaning, etc.)
Recipe or Recipe Class Responsibility
Training Certification (process and/or recipe training course completion)

3.3.1.5. Workstation Display Navigation
Display navigation design should provide easy access to all user interface features. The
following navigation characteristics should be provided:
Navigation Attribute

Display navigation should be limited, as appropriate, based on the
workstation role and/or user login.

Navigation from any display to any other display should not require more
than four (4) keystrokes or pointing device clicks (excluding login).

A hierarchical menu system (e.g., in site map format and/or dropdown
list) should be provided. Process displays should provide single
keystroke/click navigation to this menu system.

Off-screen connectors to/from a process display should include single
keystroke/click navigation to the appropriate source/destination display.

Process displays should provide single keystroke/click navigation to detail
displays related to objects shown on the display (e.g., overview to unit and
unit to faceplate).

Process displays should provide single keystroke/click navigation to the
previously viewed display(s) (e.g., a Back button).

Process displays should provide single keystroke/click navigation to
upstream and downstream process displays according to a comprehensive
sequence, or sequences, of process displays.

Process displays should provide single keystroke/click navigation to alarm
management display(s).

Process Unit displays should provide single keystroke/click navigation to
real-time and/or historical trend display(s).

Process detail displays (i.e., faceplates) should provide single
keystroke/click navigation to real-time and/or historical trend display(s).
JETT
USER REQUIREMENTS
SPECIFICATION
Page 40 of 66
December 7, 2002


Navigation Attribute

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).

3.3.2. Process Monitoring
3.3.2.1. Common Display Features
The following display elements must be included on all full-screen PCS process
monitoring displays in a consistent location or screen area:
PCS Identification,
Display title,
Display filename or other Display Identification (if appropriate),
Current Date (DD-MMM-YY format),
Current Time (HH:MM:SS format, 24 hour military time, local time zone),
Indications (preferably counts) of active and unacknowledged alarms,
Indication of active simulation or similar unusual system mode(s),
Common navigation and control features (e.g., home button, back button,
print button, pull-down menus)

The PCS must be capable of capturing and printing a live color snapshot of all process
monitoring displays.
3.3.2.2. Process Overview Displays
Process overview displays provide discrete icons or symbols for each process unit or
ancillary system subordinate to the overview. Every process unit and ancillary system
within the scope of the PCS should be included on one and only one overview display.
Where multiple process overview displays are required to represent the entire scope of
the PCS, process overview displays should be linked by a rapid navigation capability.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 41 of 66
December 7, 2002


Process overview displays should be logically organized and, if necessary, logically
subdivided. Organization may be based on product flow path, physical equipment layout,
operating areas, functional classes, or some combination of the above.
The following are display elements typically included on process overview displays:
Common process monitoring display features, as previously identified,
Process unit and ancillary system icons or symbols,
Rapid navigation capability to each subordinate process unit and ancillary
system display,
Representation of primary product flow path,
Graphical and/or text representation of key instrument readings (e.g., level,
flow, temperature, etc.), and
Graphical and/or text representation of key resource attributes (e.g., process
unit states, assigned batch IDs, operational modes, etc.).

3.3.2.3. Process Unit Displays
Process unit displays are typically associated with a single process unit or ancillary
system (e.g., headers, bulk material systems, shared equipment, etc.). These displays
provide discrete dynamic icons, symbols, and/or text representations for each subordinate
equipment module, control module, and other key dynamic process attributes.
Every equipment module, control module, and key dynamic process attribute within the
scope of the PCS should be included on a process unit display. With the possible
exception of shared modules, every equipment module, control module, and key dynamic
process attribute within the scope of the PCS should be included on only one process unit
display.
Where multiple process unit displays are required to represent a single process unit or
ancillary system, the displays should be linked by a rapid navigation capability. A
rapid navigation capability should also be provided to the following:
Related process unit displays (e.g., upstream units, downstream units, and
supporting utilities),
Encompassing process overview display, and
Subordinate process detail displays.
Process unit displays should be logically organized and, if necessary, logically
subdivided. Organization may be based on product flow path, physical equipment layout,
operating responsibilities or some combination of the above.
In addition to the common process monitoring display features previously identified, the
following elements and animations are common to process unit displays:
Object Attribute(s) Dynamic?
JETT
USER REQUIREMENTS
SPECIFICATION
Page 42 of 66
December 7, 2002


Object Attribute(s) Dynamic?
Simple Discrete Inputs (level switch,
pressure switch, etc.)
State (Open, Closed, etc.) Yes
Alarms Yes
Simple Analog Inputs (temperatures,
pressures, levels, etc.)
Value Yes
Engineering Units No
Alarms Yes
Discrete Control Modules (valves,
pumps, etc.)
Mode (Auto, Manual, etc.) Yes
Alarms Yes
Interlocks Yes
Analog Control Modules
(controllers, variable frequency
drives, etc.)
Mode (Auto, Manual, etc.) Yes
Setpoint (SP) Yes
Control Output (CV) Yes
Process Value (PV) Yes
Engineering Units (PV, SP, and CV) No
Alarms Yes
Interlocks Yes
Pipes and other conduits Content/service No
Equipment Phases
Identifier No
State Yes
Step Number Yes
Batch Management
Batch ID Yes
Batch state Yes
Procedure ID Yes
Unit Operation ID Yes
Operation ID Yes
Message pending indicator Yes

3.3.2.4. Process Detail Displays
Process detail displays are typically associated with a single module or object (e.g.,
specific valve, specific controller, specific equipment phase, etc.). This type of display is
sometimes referred to as faceplates or device pop-ups. They provide dynamic icons,
symbols, and/or text representations for every important aspect of the subject equipment
module, control module, or other dynamic process resource.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 43 of 66
December 7, 2002


Every equipment module, control module, and dynamic process resource within the
scope of the PCS should be accessible through a process detail display. These displays
may float over other process displays in a moveable window, occupy a configurable
portion of another process display, or be part of a dedicated whole-screen display of
process details.
Access to a process detail display is typically provided through a rapid navigation link
on a process unit display (e.g., clicking a valve symbol shows the process detail display
for the specific valve that was clicked). If practicable, a dropdown list or other menu
system should be provided in the process detail display to allow changing the subject
module.
All process detail displays should include the following:
Object Name,
Object Descriptor,
Alarm Indication(s),
Interlock Indication(s), and
Appropriate navigation features (e.g., Close/Exit button, Trend display button,
Interlock detail display, tuning display, etc.),
In addition, the following elements and animations are common to process detail display
classes:
Detail Display Class Attribute(s)
Simple Discrete Inputs (level switch,
pressure switch, etc.)
List of possible states (High, Normal, etc.)
State (High, Normal, etc.)
Simple Analog Inputs (temperatures,
pressures, levels, etc.)
Value
Engineering Units
Instrument range
Discrete Control Modules (valves, pumps,
etc.)
State (Open, Closed, etc.)
Ability to change state
Mode (Auto, Manual, etc.)
Ability to change mode
Analog Control Modules (controllers,
variable frequency drives, etc.)
State (Open, Closed, etc.)
Ability to change state, if appropriate
Analog values (SP, CV, PV)
Analog ranges (SP, CV, PV)
Engineering units (PV, SP, and CV)
JETT
USER REQUIREMENTS
SPECIFICATION
Page 44 of 66
December 7, 2002


Detail Display Class Attribute(s)
Ability to change analog values (SP and CV)
Equipment Phases
State (Idle, Running, etc.)
Ability to change state
Phase parameter values
Phase parameter ranges
Phase parameter value engineering units
Ability to change parameter values

3.3.2.5. Trend Displays
Real-time trending and historical data trending displays shall be provided for key process
attributes. In addition to the common process monitoring display features previously
identified, these displays shall have controls, as appropriate, for:
Selecting data values to be trended,
Changing chart zero and scale, and
Changing chart start time and duration.
3.3.2.6. Statistical Process Control Displays
Standard Statistical Process Control (SPC) displays (e.g., X-Bar charts and Pareto
Diagrams) shall be employed as appropriate to provide analysis of manufacturing batch
quality and cycle time.
3.3.3. Batch Management Interfaces
3.3.3.1. Graphical Environment and Navigational Aids
Batch Manager to PCS integration shall be accomplished both visually and functionally.
Visually, a PCS alarm and message screen shall always be present on the operator
workstation. Regardless of the Batch Manager or PCS graphic screens called the PCS
alarm and message screen shall always be visible. The operator is notified of action
requests generated by controller resident procedural elements or recipe operation via a
flashing color-coded button on this screen. Navigation controls are provided which guide
the operator to the appropriate screen for the requesting action. This Operator Action
Request (OAR) button shall exist for each unit. The button is activated by SCADA when
a pending OAR exists for the unit. When depressed the button activates navigation
controls that will take the operator to either the appropriate Batch Manager recipe or PCS
Unit Phase Display depending upon the unit mode.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 45 of 66
December 7, 2002


3.3.3.2. Unit Phase Display
The PCS shall provide the operator interface to the unit through a Unit Phase/Recipe
status and control screen. In automatic mode the operator may monitor the unit, which
receives commands from the recipe. Note that the interface to the recipe is provided
through Batch Manager screens. In manual mode the PCS screens provide the operator
interface to the equipment procedural control through phase faceplate displays. The Unit
Phase display shall provide the following:
Display name and status of procedural element currently active on the unit
Display the current unit mode (Auto /Manual) and provide a means for
Operator selection of the unit mode
Provide a phase command interface for the Operator
Provide a means for display of and response to, unit level Operator Messages
3.3.3.3. Operator Messages
The PCS shall provide the capability to issue information or instructive messages to the
operator. Operator messages shall be displayed on the Unit Phase Control screen.
Operator messages are generated by controller resident procedural elements and are
instructive text which guide the operator through a manual activity which is embedded in
an controller resident procedural element. The mechanism for triggering a specific
message shall be separate from the contents of the message. This shall allow
modification of the text within the message without modification of the logic defining the
activation of the message. PCS shall provide a means for Operator acknowledgement of
the message. The message and subsequent response/acknowledgement shall be recorded
in the PCS Event Log along with the operators electronic signature, date, time, unit and
batch ID number.
3.3.4. Alarm Management Interfaces
3.3.4.1. Alarm Display
All system alarms shall be presented to the operator on a priority basis defined as oldest,
highest priority, non-acknowledge alarm first. All alarms shall be displayed in an alarm
list/banner and on a relevant graphic, in the specified colors. Alarm display
characteristics are determined according to their state and their priority. The display and
annunciation of an alarm is activated by a change in state of the alarm. The system shall
support configuration of dynamic color change of foreground and background text based
on current alarm state at a given priority level. The system shall also support
configuration of an internal audible signal as well as an output to external light or audible
signal based on current alarm state at a given priority level. Alarm states are defined as:
Normal No alarm condition exists
Active process measurement is outside of prescribed alarm setpoint value.
Active Acknowledged Alarm is and has been acknowledged by the operator
JETT
USER REQUIREMENTS
SPECIFICATION
Page 46 of 66
December 7, 2002


Active Unacknowledge - Alarm is active but not acknowledged by the
operator
Cleared Unacknowledged Alarm condition has returned to normal state
without operator acknowledgement.
3.3.4.2. Alarm Summary Display Information
The alarm summary shall display to the operator a list of all alarms that are currently:
ActiveUnacknowledged
ActiveAcknowledged
ClearedUnacknowledged

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
Process Area / Cell / Unit

3.3.4.3. Alarm Log
A journal of alarms will be maintained on the PCS. GMP alarms will also be captured
for inclusion in the batch record. The PCS shall provide the following alarm logging
capability. Note that all logging shall conform to 21 CFR Part 11 requirements. All
pertinent data including tag number, batch ID (if applicable) time of alarm, value of
alarm and maximum and minimum deviations are recorded to the alarm database with
each alarm event. The system shall also calculate and record the duration of an alarm
when the alarm clearance event is detected.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 47 of 66
December 7, 2002


System alarm logging shall be triggered by the following alarm status changes:
Activation (and re-activation)
Clearance
Acknowledgement
Disable / Enable
Upon alarm activation the system shall log the following formation:
Alarm tag
Value of the alarm setting being transgressed
Time and date of alarm activation
Area / Cell / Unit in which the alarm was generated
Alarm state and severity
Lot # (if appropriate)
Upon acknowledgement of an alarm the system shall append the following information to
the log created upon activation of that alarm:
Operator electronic signature
Time and date of alarm acknowledgement
Upon clearance of an alarm the system shall calculate and append the following
information to the log created upon activation of that alarm:
Value of the alarmed process variable
Time and date of alarm clearance
Minimum and maximum deviation values while in alarm
Duration of alarm

3.3.4.4. Alarm Reports
The system shall be capable of producing the following alarm reports for investigation
and alarm performance analysis: The system shall provide a review tool providing query
capability by either tag, time, process area/cell/unit, batch ID or combination of the
above.

Alarm Reports Table
Report Description
JETT
USER REQUIREMENTS
SPECIFICATION
Page 48 of 66
December 7, 2002


Report Description
GMP Alarm Batch Report A report identifying all the GMP alarms. This report may get
attached to the manufacturing batch record and used as source
information triggering deviation investigations.
All Alarm Report A report listing all alarms generated, arranged by category.
Alarm Frequency Batch Report A report listing the 10 most frequent alarms
Standing Alarm Report A report listing all alarms that did not clear within a specified
period of time.
Disabled Alarm Report A report listing all current disabled alarms

3.3.5. PCS Status Interface
3.3.5.1. PCS Status Display
PCS status display(s) should include a dynamic system architecture diagram with
animations indicating the location of active PCS alarms.
3.3.5.2. PCS Event and Error Logs
Important PCS events should be annunciated and presented to the appropriate system
user(s). The following event types may be included:
Event Type Description
Error A significant problem, such as loss of data or loss of functionality. For example, if
a service fails to load during startup, an error will be logged.
Warning An event that is not necessarily significant, but may indicate a possible future
problem. For example, when disk space is low, a warning will be logged.
Information An event that describes the successful operation of an application, driver, or
service. For example, when a network driver loads successfully, an Information
event will be logged.
Success Audit An audited security access attempt that succeeds. For example, a user's successful
attempt to log on to the system will be logged as a Success Audit event.
Failure Audit An audited security access attempt that fails. For example, if a user tries to access
a network drive and fails, the attempt will be logged as a Failure Audit event.

Annunciated PCS events are to be treated as electronic records (i.e., not maintained
exclusively in text files).
JETT
USER REQUIREMENTS
SPECIFICATION
Page 49 of 66
December 7, 2002


3.3.6. Programming and Configuration Interfaces
Offline ability to modify and test changes to PCS software must be provided. If existing
development facilities and/or equipment are to be leveraged for this purpose,
qualification testing must verify the validity of this approach.
Programming and configuration interfaces must provide all the functionality used for
original system development. Access to programming and configuration interfaces must
be restricted to authorized users.
3.3.7. Recipe Management Interface
Offline ability to modify and test changes to PCS recipes must be provided. If existing
recipe management facilities and/or equipment are to be leveraged for this purpose,
qualification testing must verify the validity of this approach.
Recipes developed for the PCS must be controlled as electronic records, in accordance
with 21 CFR Part 11. This includes:
Validation of systems that create, modify, maintain, or transmit the recipe,
Ability to generate accurate and complete copies of recipes in electronic and
human-readable formats,
Ability to archive recipes (for record protection) to enable accurate and ready
retrieval throughout the batch record retention period, and
Use of secure, computer-generated, time-stamped audit trails to independently
record the date and time of user entries and actions that create, modify, or
delete recipes. Recipe changes must not obscure information from a previous
recipe version.

3.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.).

Additional required reports may include:
Production summary reports (e.g., Shift Reports),
Equipment Use Logs and/or Cleaning Reports,
JETT
USER REQUIREMENTS
SPECIFICATION
Page 50 of 66
December 7, 2002


Alarm and Event Reports, and
Recipe Reports.
3.4. Remote PCS Access
The PCS architecture should include a secure network interface to the <User Company>
Local Area Network (LAN). Authorized <User Company> LAN users should have
selected ability to monitor the process remotely. No control or engineering capability
should be accessible from any remote interface (i.e., interfaces that are not within the
scope of the PCS should be view-only).
3.5. Interfaces with Other Systems
3.5.1. Intelligent Process Interfaces
{Describe in this section any PCS process interfaces beyond standard simple electrical
I/O (e.g., Analog Inputs, Analog Outputs, Discrete Inputs, Discrete Outputs, Pulse and
Binary Coded Decimal I/O). Examples of intelligent process interfaces include Barcode
Equipment, Weigh Cells, Analytical Instruments, and Variable Frequency Drives. More
sophisticated I/O collection mechanisms, such as Fieldbus or DeviceNet networks, should
also be described.
Include in these descriptions the extent of monitoring and/or coordination for each
interface. For example, characterize the extent of remote maintenance capabilities to be
provided.}
3.5.2. Other Process Control Systems
{Describe in this section any messaging to/from the PCS and other process control
systems. For example, key process status indicators may be transmitted to central
monitoring systems, and/or to controllers for upstream, downstream, and service/utility
processes. Include in these descriptions the anticipated communication mechanism (I/O,
TCP/IP, etc.) and the degree of interaction between the systems.}
3.5.3. Other Computerized Systems
{Describe in this section communications and coordination with other site computerized
systems, such as Laboratory Information Management Systems (LIMS), Manufacturing
Execution Systems (MES), and Enterprise Resource Planning (ERP) systems. Include in
these descriptions the anticipated communication mechanism (I/O, TCP/IP, etc.) and the
degree of interaction between the systems.>
3.5.4. Shared Resources
<In many cases, process control systems may be constrained by shared equipment and
services such as utilities and bulk supply systems. Describe in this section any such
constraints and how the PCS is to cope with such limitations.}
JETT
USER REQUIREMENTS
SPECIFICATION
Page 51 of 66
December 7, 2002


3.6. Environment
3.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}
It is anticipated that the <PCS Identifier> equipment will be distributed within this
facility. The following considerations and principles should guide the physical design
and location of PCS equipment:
Equipment locations must balance wiring costs, access convenience, cleaning
requirements, throughway obstruction, and consumption of valuable
production and/or personnel space.
All equipment must be readily accessible for use (if applicable), cleaning, and
maintenance.
Equipment that requires routine and/or frequent access should consider user
access ergonomics.
The ability to receive, install, and remove equipment from the site should be
considered.
Ready access to system manuals and appropriate procedures should be
provided.

3.6.2. Physical Conditions
The following environmental conditions should be considered in determining appropriate
equipment installation locations:
Area Classification(s) Description

The following is a brief characterization of area classifications. For more detailed
descriptions and equipment requirements, refer to appropriate industrial standards.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 52 of 66
December 7, 2002


Classification Description
NEMA4
Refers to the minimum protection provided by enclosures located in the
area. Type 4 enclosures are intended for indoor or outdoor use primarily
to provide a degree of protection against windblown dust and rain,
splashing water, and hose directed water; and to be undamaged by the
formation of ice on the enclosure.
NEMA4X
area. Type 4X enclosures are intended for indoor and outdoor use
primarily to provide a degree of protection against corrosion, windblown
dust and rain, splashing water, and hose-directed water; and to be
undamaged by the formation of ice on the enclosure.
NEMA12
area. Type 12 enclosures are intended for indoor use primarily to
provide a degree of protection against dust, falling dirt, and dripping
noncorrosive liquids.
NEC Class I
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
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).
NEC Class II
Class II locations are defined by the National Electric Code as those
locations that are hazardous due to the presence of combustible dusts.
All NEC classes may be subdivided as Division 1 (Normally Hazardous)
or Division 2 (Not Normally Hazardous).
US FS 209D
Class 100
United States Federal Standard for clean room air classification
characterized by airborne particulates (> 5 microns) less than 100
particles per cubic foot (equivalent to US FS 209E class M 3.5 and to
ISO EN 14644-1 class 5).
US FS 209D
Class 1000
characterized by airborne particulates (> 5 microns) less than 1,000
US FS 209D
Class 10,000
US FS 209D
Class 100,000

JETT
USER REQUIREMENTS
SPECIFICATION
Page 53 of 66
December 7, 2002


4.0 CONSTRAINTS
4.1. Project Constraints
4.1.1. Schedule
{Insert project schedule and/or key milestones}
4.1.2. Procedural Constraints
{Identify any project execution and reporting constraints applicable to PCS development.
For example, project tracking mechanism/software, status reporting requirements,
communication methods and logs, and project contacts.}

JETT
USER REQUIREMENTS
SPECIFICATION
Page 54 of 66
December 7, 2002


4.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.}
4.2.1. Hardware Standards and Preferences
The following table identifies corporate and/or site and/or process area and/or project
standards for Process Control System hardware:
Role Standard(s) Comments
I/O Enclosure
I/O Termination
I/O Bus
I/O-Controller Interface
Controller Enclosure
Controller Small Process
Controller Medium Process
Controller Large Process
Controller-OIT Interface
Operator Interface Terminal
Controller-SCADA Interface
SCADA PC
Workstation (HMI) PC
Workstation Enclosure
LAN Components
Server PC

{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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 55 of 66
December 7, 2002


4.2.2. COTS Software Standards and Preferences
The following table identifies corporate and/or site and/or process area and/or project
standards for Process Control System Commercial Off-The-Shelf (COTS) software:
Role Standard(s) Comments
I/O Bus Configuration
Controller Configuration and
Programming

OIT Configuration and
Programming

PC Operating System
Controller-SCADA Interface
SCADA
HMI
Process Simulation
Batch/Recipe Management
Process Historian
Manufacturing Execution System
Relational Database
Custom Application Programming

{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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 56 of 66
December 7, 2002


4.2.3. PCS Configuration and Integration Standards
To help reduce validation, training, and maintenance costs, a set of corporate and/or site
and/or process area and/or project standards are employed. Standards for Process Control
System (PCS) configuration and integration include:
! Basic design principles for Process Control Systems,
! PCS terminology and naming conventions,
! PCS documentation principles,
! Basic configuration of PCS hardware and software components, and
! General network and IT standards.
PCS Configuration and Integration Standards are <location of standards (e.g., URS
attachment ID)> {NOTE: If Configuration and Integration standards do not exist,
development and approval of project-specific standards may be part of PCS Functional
Specifications.}. Application of alternate standards 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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 57 of 66
December 7, 2002


4.2.4. PCS User Interface Standards
System (PCS) User Interfaces include:
! Basic design principles for PCS User Interfaces,
! PCS display libraries, symbols, fonts, and colors,
! PCS display classes (e.g., Overview, Process Unit, Control Popup), standard
layouts, and navigation,
! Alarm Management and Annunciation, and
! User Interface security.
PCS User Interface Standards are <location of standards (e.g., URS attachment ID)>
{NOTE: If User Interface standards do not exist, development and approval of project-
specific standards may be part of PCS Functional Specifications.}. Application of
alternate standards 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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 58 of 66
December 7, 2002


4.2.5. PCS Programming Standards
System (PCS) Programming include:
! Basic design principles for PCS Programming,
! Program identification and version control,
! PCS object naming conventions,
! PCS code format and commenting,
! Program flow control,
! User Interface, and
! Error Handling.
Application of alternate standards 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.
4.2.5.1. Controller Programming
PCS Controller Programming Standards are <location of standards (e.g., URS
attachment ID)> {NOTE: If programming standards do not exist, development
and approval of project-specific standards may be part of PCS Functional
Specifications. Project-specific standards may be based on Systems Integrator
internal quality control standards.}.
4.2.5.2. SCADA Scripts and Custom Applications
PCS SCADA Scripts and Custom Applications Programming Standards are
<location of standards (e.g., URS attachment ID)> {NOTE: If programming
standards do not exist, development and approval of project-specific standards
may be part of PCS Functional Specifications. Project-specific standards may be
based on Systems Integrator internal quality control standards.}.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 59 of 66
December 7, 2002


4.3. Maintenance

5.0 LIFE-CYCLE
5.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 Users 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.
5.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.
5.3. Delivery
The [equipment/system], with all options, equipment, and the documentation listed below,
shall be delivered to the Users receiving dock.
5.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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 60 of 66
December 7, 2002


The Supplier shall use the formats described in the GAMP Supplier Guide, Current
Version, to produce the documentation. The Supplier shall provide the
documentation for preliminary review. The Supplier shall provide documentation
reflecting as-built condition with final delivery.
All final documents shall be shipped with transmittals that identify them as
contractually required documents. All final documents and drawings shall reflect
as-built condition.
All documents shall in the language of the destination country and supplied with
hard copies and electronic versions supplied in the format identified for each
document:
User should define format for document transmission (ie. MS Word, Autocad, etc.) Below is an
example:

Project Plan Microsoft Word 97 (*.doc)
User Requirements Specification Microsoft Word 97 (*.doc)
Functional Specification/Requirements Microsoft Word 97 (*.doc)
Design Specifications Microsoft Word 97 (*.doc)
Controls Test Microsoft Word 97 (*.doc)
Hardware Installation Test Microsoft Word 97 (*.doc)
Operational Test Microsoft Word 97 (*.doc)
Factory Acceptance Test Microsoft Word 97 (*.doc)
Operator, Maintenance and Service Manuals Microsoft Word 97 (*.doc)
Process and Instrumentation Diagram (P&ID) AutoCAD version 12.0 (*.dxf)
Instrument Listing Microsoft Word 97 (*.doc) or Excel 97 (*.xls)
Control Schematics AutoCAD version 12.0 (*.dxf)
Control Panel Assembly Drawings AutoCAD version 12.0 (*.dxf)
Equipment Assembly Drawings AutoCAD version 12.0 (*.dxf)
Bill of Materials Microsoft Word 97 (*.doc) or Excel 97 (*.xls)
Spare Parts List Microsoft Word 97 (*.doc) or Excel 97 (*.xls)
Component Cut Sheets Microsoft Word 97 (*.doc) or Excel 97 (*.xls)
CONTROL PLATFORM Program
Printout and Disk File XXX Program Development format
OIP Configuration Printout and Disk File XXX Program Development format
JETT
USER REQUIREMENTS
SPECIFICATION
Page 61 of 66
December 7, 2002


5.4. Support
Describe what support activities are required after acceptance. The paragraphs outlined
below provide some areas for consideration.
5.4.1.Start-up Support (list available options)
5.4.1.1. Training (list training options available)
5.4.2.Post Start-up Support (list post-startup support available)
5.4.2.1. Technical Support
Telephone (Voice or Modem)
Replacement Parts Availability List (Normal lead times shall be listed)
5.4.2.2. User Site Support
Preventative Maintenance (list maintenance contracts available)
System Improvements (supplier shall notify user of any improvements
available on a regular basis)

JETT
USER REQUIREMENTS
SPECIFICATION
Page 62 of 66
December 7, 2002


6.0 GLOSSARY
6.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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 63 of 66
December 7, 2002


Term Definition
Operation A procedural element defining an independent processing activity
consisting of the algorithm necessary for the initiation, organization, and
control of phases. An example might be CIP.
Phase A procedural element that provides an interface to basic control.
Examples might be wash, fill, rinse.
Procedural Control Control that directs equipment oriented actions to take place in an ordered
sequence that can carry out some process-oriented task.
Procedure A manufacturing procedure that has one or more operations and product
specific recipe data.
Process Stage A part of the process that usually operates independently from other
process stages and that usually results in a planned sequence of chemical
or physical changes in the material being processed.
Recipe The necessary set of information that uniquely defines the production
requirements for a specific product or unit operation. SP-88 defines four
levels of recipes. The general recipe is the highest order recipe, followed
by the site recipe, the master recipe, and the control recipe. SP-88 is
flexible in that, depending on the needs of the enterprise, more levels of
recipe may be used, or that all levels need not be implemented. Procedural
control requirements specify procedures, unit procedures, recipe
operations, and phases. The control recipe specifies these even further for
the actual equipment. The procedural control component of the recipe
contains one or more procedures, which contain one or more unit
procedures, which contain one or more operations, which contain one or
more phases.
Recipe Management The control activity that includes creating, editing, storing and retrieving
master and control recipes.
S88.01 Part 1 of an Instrument Society of America standard that describes models
and terminology for batch control systems.
Unit A Unit is comprised of all the equipment that works together to carry out a
major independent process activity. A unit may contain one or more
equipment modules and/or one or more control modules.
Unit Procedure A production sequence (consisting of contiguous operations and the
algorithm necessary for the initiation, organization, and control of those
operations) executed within a unit.
Working Recipe A working recipe is the control recipe loaded into the MES for control of
production. The technician during production of a batch may alter it.

JETT
USER REQUIREMENTS
SPECIFICATION
Page 64 of 66
December 7, 2002


6.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
Standards Institute
An organization that produces standards, practices,
and 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
Manufacturing Practices
A set of regulations governing the manufacture of
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
Agency
A United States agency responsible for environmental
protection.
degF Fahrenheit A unit of measure for temperature.
FDA Food and Drug
Administration
A United States agency responsible for consumer
safety related to drugs and drug products.
GAMP
Good Automated
Manufacturing Practices
A methodology for implementing and documenting
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
Electronics Engineers
An organization that produces standards related to
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.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 65 of 66
December 7, 2002


IS Intrinsically Safe Standards related to equipment and wiring installation
in explosive or potentially explosive environments.
ISA Instrument Society of
America
An organization that produces standards related to
process control and instrumentation.
ISO International Standards
Organization
An organization that produces standards, practices,
and codes related to pharmaceutical manufacturing.
JETT Joint Equipment Transition
Team
A consortium of pharmaceutical users
(manufacturers), equipment suppliers, and consultants
seeking to improve communications between Users
and Suppliers to more effectively meet the
"validation" requirements of the pharmaceutical
industry.
LAN Local Area Network A group of computers connected to facilitate
computer-to-computer communications.
LCL Lower Control Limit The minimum parameter value required to assure that
a product is manufactured according to specifications.
LIMS Laboratory Information
Management System
A software system used to store and retrieve
laboratory information related to sampling, testing,
and product release.
MES Manufacturing Execution
System
One or more software products or applications
responsible for transferring data between plant floor
production systems and higher-level business
application systems.
MMI Man-machine Interface see HMI.
MSDS Material Safety Data Sheet Documentation of the chemical and hazardous
properties of a substance.
NDA New Drug Application A process prescribed by the US FDA for introducing a
new pharmaceutical product or product form to the US
marketplace.
NEC National Electric Code United States Standards governing the design,
installation, and use of electrical equipment.
NEMA National Electrical
Manufacturers Association
An organization that, among other activities, defines
categories of environment resistance for electrical
equipment.
OEM Original Equipment
Manufacturer
The supplier of industrial equipment packages that are
typically skid-mounted and include pre-wired
instrumentation and control components.
OQ Operational Qualification Approved documented verification that an object or
system operates in accordance with written and
approved specifications throughout all anticipated
operating ranges.
JETT
USER REQUIREMENTS
SPECIFICATION
Page 66 of 66
December 7, 2002


OSHA Occupational Safety and
Health Act
United States regulations related to work places and
practices.
P&ID Piping and Instrumentation
Diagram
Engineering drawings that present basic process
information, especially instrument and sensor
locations.
PC Personal Computer A microcomputer designed primarily for use by a
single individual.
PLC Programmable Logic
Controller
A device that provides control functionality via
software. It is typically programmed in ladder logic
and replaces relays, electrical devices, timers, counters
and analog instrumentation.
SCADA Supervisory Control and
Data Acquisition
A SCADA system provides communication between
supervisory applications (e.g., HMI or batch
management) and plant floor control devices, typically
PLCs.
SKU Stock Keeping Unit A number or other identifier used to distinguish
packaging and/or product forms.
SOP Standard Operating
Procedure
Site instructions for operating and maintaining the
facility and process.
SQL Structured Query Language A standard syntax used to extract selected data from a
database.
TCP/IP Transmission Control
Protocol / Internet Protocol
A routable computer communication protocol.
UCL Upper Control Limit The maximum parameter value required to assure that
a product is manufactured according to specifications.
UPS Uninterruptable Power
Supply
Battery-based system for providing electrical power
during temporary power outages.
WFI Water For Injection Highly purified water suitable for use in the
production of products that may be injected into a
human body.

USER REQUIREMENTS TEMPLATE For A Supervisory Control and Data Acquisition (SCADA) Process Control System

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

USER REQUIREMENTS TEMPLATE For A Supervisory Control and Data Acquisition (SCADA) Process Control System

Загружено:

Авторское право:

Доступные форматы

USER REQUIREMENTS TEMPLATE

Вам также может понравиться