user requirements template for a supervisory control and data acquisition (scada) process control...
TRANSCRIPT
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
1/66
USER REQUIREMENTS TEMPLATE
for a
Supervisory Control and Data Acquisition (SCADA)
Process Control System
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
2/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 2 of 66
URS, Rev.0 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 andease 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 thespecific 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 theacceptable ranges of variables or other critical requirements that have been derived.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
3/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 3 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
TABLE OF CONTENTS
REVISION HISTORY ............................................................................................................................. 5
1.0
INTRODUCTION ........................................................................................................................ 61.1. PURPOSE...................................................................................................................................... 6
1.2. ORIGIN AND CONTEXT................................................................................................................. 61.3. SCOPE.......................................................................................................................................... 7
1.4. DOCUMENT ORGANIZATION........................................................................................................ 8
2.0 OVERVIEW .................................................................................................................................. 9
2.1. BACKGROUND.............................................................................................................................. 92.1.1. Project Overview ................................................................................................................ 9
2.1.2. Facility Overview .............................................................................................................. 102.1.3. Automation Overview........................................................................................................ 12
2.2. GENERAL SYSTEM FUNCTIONS.................................................................................................. 14
2.3. SIMULATION SYSTEM................................................................................................................. 142.4. EXCLUSIONS AND FUTURE CONSIDERATIONS............................................................................ 14
3.0 OPERATIONAL REQUIREMENTS ....................................................................................... 16
3.1. FUNCTIONS................................................................................................................................ 163.1.1. Process Monitoring ........................................................................................................... 16
3.1.2. Alarm Management ........................................................................................................... 173.1.3. Basic Control .................................................................................................................... 19
3.1.4. Equipment Phase Control ................................................................................................. 233.1.5. Batch Management ........................................................................................................... 24
3.1.6. Historical Data Collection and Retention ........................................................................ 253.1.7. Other Monitoring and Control Features .......................................................................... 26
3.1.8. Modes of Operation .......................................................................................................... 263.1.9. Performance and Timing .................................................................................................. 28
3.1.10. Response to Failures ......................................................................................................... 293.1.11. Security ............................................................................................................................. 30
3.1.12. Safety ................................................................................................................................. 303.2. DATA......................................................................................................................................... 31
3.2.1. Preliminary Data Definitions ........................................................................................... 313.2.2. Capacity Requirements ..................................................................................................... 32
3.2.3. Access Speed ..................................................................................................................... 333.2.4. Archive Requirements ....................................................................................................... 34
3.2.5. Data Security and Integrity ............................................................................................... 34
3.3. USER INTERFACES...................................................................................................................... 363.3.1. General ............................................................................................................................. 363.3.2. Process Monitoring ........................................................................................................... 40
3.3.3. Batch Management Interfaces .......................................................................................... 443.3.4. Alarm Management Interfaces .......................................................................................... 45
3.3.5. PCS Status Interface ......................................................................................................... 483.3.6. Programming and Configuration Interfaces .................................................................... 49
3.3.7. Recipe Management Interface .......................................................................................... 49
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
4/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 4 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
3.3.8. Reports .............................................................................................................................. 493.4. REMOTE PCSACCESS................................................................................................................ 50
3.5. INTERFACES WITH OTHER SYSTEMS........................................................................................... 50
3.5.1. Intelligent Process Interfaces ........................................................................................... 503.5.2. Other Process Control Systems ........................................................................................ 503.5.3. Other Computerized Systems ............................................................................................ 50
3.5.4. Shared Resources .............................................................................................................. 503.6. ENVIRONMENT........................................................................................................................... 51
3.6.1. Layout ............................................................................................................................... 513.6.2. Physical Conditions .......................................................................................................... 51
4.0 CONSTRAINTS .......................................................................................................................... 534.1. PROJECT CONSTRAINTS ............................................................................................................. 53
4.1.1. Schedule ............................................................................................................................ 534.1.2. Procedural Constraints ..................................................................................................... 53
4.2. COMPATIBILITY ......................................................................................................................... 544.2.1. Hardware Standards and Preferences .............................................................................. 54
4.2.2. COTS Software Standards and Preferences ..................................................................... 554.2.3. PCS Configuration and Integration Standards ................................................................ 56
4.2.4. PCS User Interface Standards .......................................................................................... 574.2.5. PCS Programming Standards ........................................................................................... 58
4.3. MAINTENANCE........................................................................................................................... 59
5.0 LIFE-CYCLE .............................................................................................................................. 59
5.1. DEVELOPMENT........................................................................................................................... 595.2. TESTING..................................................................................................................................... 59
5.3. DELIVERY.................................................................................................................................. 595.3.1. Documentation .................................................................................................................. 59
5.4. SUPPORT .................................................................................................................................... 615.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........................................................................................................................... 626.2. ACRONYMS................................................................................................................................ 64
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
5/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 5 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 andcontent
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
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
6/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 6 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 . 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
has been contracted by to develop the URS for
the , to be located in . The format and content of thisURS 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:
! Once approved, this document will provide a foundation for the development of
functional specifications, design specifications, and Performance Qualification testingprotocols. 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 URS:
# Reference Contains
1 Project Scope and Charter
2 Process design
3 Applicable automation standards
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
7/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 7 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 policies and procedures. Thebenefit of meeting or exceeding these key objectives is a profitable manufacturing facilityoffering flexibility to meet market demand.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
8/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 8 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 constraintsCompatibility 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
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
9/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 9 of 66
URS, Rev.0 URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
2.0 OVERVIEW
2.1. Background
2.1.1. Project Overview
2.1.1.1. Project Summary
The 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 functionalityand flexibility while simultaneously meeting the requirements of ISPE GAMP 4, cGMP,FDAs 21 CFR Part 11, ISA S88.01, and policies and procedures. The
benefit of meeting or exceeding these key objectives is a profitable manufacturing facilityoffering 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 CapacityManufacturing Process Change
Reduced Product Losses
Increased Flexibility
Improved Regulatory Compliance
Reduced Maintenance
Technology Upgrade
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
10/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 10 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
2.1.2. Facility Overview
The is a manufacturing facility located in designed to
produce . The following model identifies site equipmentpertinent 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 yourfacility.}
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 TankT101
Manufacturing Cell A
Reactor
R200
Centrifuge
C200
Wash Tank
T200
Receiving TankT201
Manufacturing Cell B
Bottle Prep A
Bottling Line A
Bottling Line B
Cartoning
Packaging Area A
Existing New Modified
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
11/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 11 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
2.1.2.1. Existing Facilities and Equipment
2.1.2.2. New Facilities and Equipment
2.1.2.3. Modifications to Existing Facilities and Equipment
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
12/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 12 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 forthe automation overview. Replace with diagrams and/or information specific to yourfacility.}
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
Process Control System
Manufacturing Cell B
Process Control System
Manufacturing
Process Control
High Purity Steam
Skid Controller
Chilled Water
Skid Controller
WFI
Process Control System
Utilities
Process Control
Process Automation Systems
Regulated Systems
Existing New Modified
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
13/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 13 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
2.1.3.1. Existing Systems
2.1.3.2. New Systems
2.1.3.3. Modifications to Existing Systems
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
14/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 14 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 thecGMP portion of the to:
Provide an interactive illustration of the process for operatorinformation and process control
Provide equipment status and monitoring functionality
Provide sequential process control via control modules, phases and/orprocedures
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 shallbe initially installed at the vendor site and utilized for the development and factory testing
of the application software. When the applicationsoftware is ready for installation at the 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 site, and utilized for PCS application maintenance andenhancement activities.
2.4. Exclusions and Future Considerations
The S88.01 standard and the utilized hardware/software platform provide extensive
capabilities within a batch environment. has elected to limit the initialimplementation 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. Allother sequential functionality required is implemented at the unit phase level.
Manufacturing operations will be performed by manually initiating equipmentphases 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/placingall control modules are in automatic mode, etc.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
15/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 15 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
It is s intent to continue development of various facilityprocedures, beyond those initially provided at PCS startup. It is the intent that
phases developed for the project be suitable for use in these
future procedure development activities. Where feasible, procedures andoperations are designed and implemented as a library of phase buildingblocks, 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 proceduredevelopment, 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 sterilityexpiration. When a PCS phase/procedure is initiated by an operator, it is theoperators responsibility, supported via manual paper systems, to ensure the
subject process equipment is suitable for the PCS phase or procedureapplication. The PCS ensures that the subject process equipment is available
and not currently in-use by another phase/procedure. The PCS equipmentmodel only maintains process unit statuses of In-Use or Available.
Additional statuses or states pertaining to a units fitness for use are notrequired.
Material tracking, including all batch/lot material and intermediate productgenealogy tracking.
Batch/lot tracking, including batch/lot reporting. PCS-generated electronictickets and automated batch reports are not required. Additionally, PCS is
not required to maintain or track unique batch identifiers. Lot Identifiers andProduct Codes are manually input to the PCS at appropriate process intervalsand utilized for historical data record retention as key fields.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
16/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 16 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
3.0 OPERATIONAL REQUIREMENTS
3.1. Functions
3.1.1. Process Monitoring
3.1.1.1. Real-Time Data Collection and Dissemination
The 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 realtime, 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 statedefinition.
Design of PCS data collection features shall consider all of the following:
Factor Description
Requiredimmediacy
Response time for value display and alarming, historical data
collection frequency, and control processing requirements shoulddictate the minimum acceptable data collection and transfer rates.
Required precisionInsignificant digits should not be presented to users, historicallycollected, or considered in data processing.
Data consistency
In some component systems, communication delays may introduce
transient and/or scan-based differences in data values. Datacollection design must prevent inconsistent display, control
response, and historical collection of alarm and other thresholdevents. The design must also avoid other data collection and
communication mechanisms that could result in sustainedinaccuracies between display data, historical data, and control
processing data.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
17/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 17 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
Factor Description
Future expansion
and/orenhancement
Hardware, software, and communications design should provide
capacity for future expansion and potential changes to controland/or display strategies.
Fault tolerance
The PCS must be designed to prevent any individual failure fromjeopardizing personnel safety and/or product quality. Where PCS
features are instrumental in protecting personnel and/or productquality 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 engineeringunits prior to use in any comparison or control logic. This conversion should also includenormalization 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 outputsshould undergo similar conversions immediately prior to transmittal.
3.1.1.3. Process Alarm Detection
Process alarm detection functionality compares data values against range and alarmlimits. Range errors and alarms should be propagated, as appropriate, to subsequent data
processing logic. All non-discrete dynamic system inputs automatically monitored by thePCS 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 andsubjected 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 besupported by the PCS, process alarms and equipment alarms. Process alarms differ from
equipment alarms in that their parameters such as, setpoint, time delay, deadband, etcmust 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 equipmentrequirements 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.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
18/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 18 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
The Locally Controlled Packaged Equipment section discusses the operator interfacewith 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, whichare 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 willbe assigned to equipment protection, personnel safety and operator information.
The S88 concept of process units, grouped in plant cells and areas will allow for alarmenable/disable of those groupings (e.g. during maintenance, shutdown etc.). Additionally,
it will also be possible to suppress temporarily (override), with proper authority, anindividual 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 controllerresident phase.
The system shall support the following configuration parameters for each alarm
Type of Alarm Absolute alarm, Offset from Setpoint, Percent Offset fromSetpoint.
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 associatedwith momentary measurement spikes (e.g., an alarm condition must exist for 5seconds before activating an alarm).
Alarm Deadband the ability to configure an alarm to turn on at one valueand clear at another Ramp setpoints and configure alarms as setpoint +/-
tolerance. This helps minimize nuisance alarms associated with normalcontrol loop setpoint changes.
Pause Enable Configurable ability for alarm activation to cause runningbatch logic to pause. Note alarm point must be directly associated with aprocess unit.
3.1.2.2. Alarm Acknowledgement
Operators must be logged on to the PCS and have the proper authority as enforced byPCS security to acknowledge alarms. The PCS shall record in the operator action log all
acknowledgement activities. The operators electronic signature, the action taken, dateand 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 eachindividual alarm.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
19/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 19 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
3.1.2.3. Alarm Output devices
The system shall support the following output devices. System configuration shall allowfor 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 (includingprocess control inputs, user inputs, tunable parameters, and constants) to determine the
state of process control outputs. Included in basic control are normal control modulealgorithms (valve control, pump control, feedback loop control, etc.) and interlocking.
Basic control is intended to be completely independent of the intended use of the processequipment. 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 ofcontrol modules include block valves, modulating valves, PID controllers, fixed-speed
motors, and variable speed motors. Design of PCS control modules shall consider all ofthe following:
Factor Description
Commonality andconsistency
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 userswhere appropriate.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
20/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 20 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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, andrespond 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 transferControl 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) shouldresult in a specific failure alarm (e.g., valve uuu-XV-iiii failed to
open). Control module fault response should be designed tomitigate risk to personnel, product, and equipment.
Harmony withsupervisory control
Control modules may be subordinate to supervisory objectsincluding complex modules (e.g., header or dispensing system) and
phases. Mode changes and faults in subordinate control modulesshall either:
Propagate the mode or fault to the supervisory object, or
Override the subordinate mode and/or fault monitoring andcomprehensively 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 aClosed limit switch, the state of both switches should be consideredin determining the actual state of the valve.
Harmony withsimulation
Where applicable and possible, installed simulation activation and
I/O forcing shall be obvious from all impacted user interfaces andreports.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
21/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 21 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
3.1.3.3. Interlocks
Interlocks modify control module states in response to process conditions in order toprotect personnel, process equipment, and/or product. Design of PCS interlocks shall
consider all of the following:
Factor Description
Product
independence
Interlock functionality should notconsider current productprocessing requirements. In general, interlocks should only be
applied for personnel protection, equipment protection, and/orprevention of product contamination.
Harmony withsupervisory control
Control modules may be subordinate to supervisory objectsincluding 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 acomplimentary interlock and/or fault monitoring by thesupervisory object.
OverridesThe ability to manually override interlocks, if available, shall bereserved for engineering and maintenance users.
Display
Control module interfaces should, where possible, clearly identify
whether or not a control module interlock is active. The specificcause of the interlock should be either displayed as part of the
control module interface and/or readily accessible from the controlmodule interface.
Record of interlockevents
Historical data collection must include a record of interlock-relatedevents (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 ormore block valves)
Temperature control module (where media routing valves are controlled basedon a desired vessel jacket state or temperature setpoint)
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
22/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 22 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
NOTE: Complex Modules are differentiated from Equipment Phases which arecontrolled 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 manualequipment 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 andconsistency
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 transferComplex module mode changes should not cause an immediatecorresponding change in complex module state, setpoint, or output.
Fault annunciation
and response
Every unexpected combination of control module states (and/orvalues) should result in a specific failure alarm (e.g., valve uuu-
XV-iiii failed to open). Complex module fault response should bedesigned to mitigate risk to personnel, product quality, and process
equipment.
Harmony with
supervisory phases
Mode changes and faults in complex modules that are subordinate toa phase shall either:
Propagate the mode or fault to the phase, or
Override the subordinate mode and/or fault monitoring andcomprehensively replace it with mode and/or faultmonitoring at the phase level.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
23/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 23 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
Factor Description
Harmony with
simulation
Where applicable and possible, installed simulation activation and
I/O forcing shall be obvious from all impacted user interfaces andreports.
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 sequentialcontrol 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 andshould in no way be product-specific,
Equipment phases should operate autonomously, except as necessary tocoordinate material transfers or other multi-unit activities,
Equipment phases should not share control modules with other equipmentphases except where necessitated by process equipment design, and
Shared equipment phases and shared control modules should notunnecessarily restrict or otherwise interfere with parallel activities.
3.1.4.2.
Normal OperationOnce initiated, an equipment phase typically initiates appropriate monitoring (e.g., faultdetection) 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 tosupport 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 producttransfers), or
The execution of subsequent equipment phases, or
The anticipated state or status of uncontrolled equipment.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
24/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 24 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
3.1.4.3. Exception Handling
Equipment phase exception handling should respond, as appropriate, to controlledequipment alarms, interlocks, and faults, unexpected process deviations, invalid
parameter values, communication faults, and user intervention commands. Exceptionhandling should be sufficiently exception-specific in order to provide the least intrusive
response that still provides adequate personnel, equipment, and product protection. Forexample, 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 thatjeopardizes personnel, equipment, or product,
Exception handling actions are appropriate to both the type of exception andthe progress of the equipment phase sequence at the time of the exception,
Equipment phase execution is not interrupted by minor anomalies that areunlikely to jeopardize personnel, equipment, or product (though operatornotification of all anomalies is generally required),
The response of concurrently executing equipment phases is appropriatelyimpacted to preserve the integrity of a Unit Operation,
The equipment phase, and associated Unit Operation, can be restarted by anoperator 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, shouldautomatically resume manufacturing operations without unnecessarily
repeating steps or extending execution times (e.g., by unnecessarily resettingtotalizers, counters and timers).
3.1.5. Batch Management
The automation solution includes both the PCS and a batch managementsystem. The PCS shall be implemented within the framework of the Instrument Society
of America (ISA) standards S88.01, Standard for Batch Models and Terminology, anddraft 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 businessand automation objectives. The S88.01 control activity model defines the followingactivities
Production Planning and Scheduling
Information Management
Recipe Management
Process Management.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
25/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 25 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
Unit Supervision and
Process Control
The focus of this PCS is the Process Control activities defined by the S88 Standard. Thissection defines the interface requirements for the PCS to the Unit Supervision, Process
Management and Recipe Management activities implemented by the Batch ManagementSystem 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 recipeexecution
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 historicaldatabase. Since these data are important electronic records, the PCS should employ
appropriate provisions for secure data collection and retention (e.g., automatic dailybackup, disaster recover provisions, long-term data archiving and restoration procedures,
etc). Existing site database facilities, capabilities, and procedures should be exploited, ifpossible. 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 theprimary 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 proceduresshould be exploited, if possible. Historical alarm and event data shall be accessible for
inclusion in onscreen displays and, as applicable, reports.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
26/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 26 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 includessufficient local control capability to perform the intended functionality. These packaged
systems are designed to include the necessary interface capability to permitcommunication with the PCS. It is the responsibility of the System Integrator to
coordinate with the packaged equipment vendor(s) to determine the appropriate PCScontrol strategy, general interface requirements, etc. Where practicable, PCS interface to
packaged equipment should follow S88 paradigms (e.g., by treating the packagedequipment operation as an equipment phase).
3.1.7.2. Resource Management
Modes, states, statuses, and other attributes of all process resources (including processunits, bulk material supplies, logical modules such as totalizers, etc.) should be clearly
defined and appropriately managed. User interfaces to these process resources shouldprovide for attribute monitoring and, with appropriate security, manual adjustment.
Managed resource attributes (e.g., bulk material supply Ready status and process unitClean 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 tunablevariables 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 shallmaintain controlled process equipment in its pre-defined safe (typically de-energized)
state until specific user commands are applied to begin process control.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
27/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 27 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
To the extent possible, PCS event log(s) shall record events indicating the startup of PCScomponents. 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 andcomplete 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 alarmlog(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 beenabled. 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 validvalue, and
The ability to set individual control modules feedback simulation to auto-respond to control module states (e.g., Open feedback energizes and closedfeedback de-energizes whenever the valve stat is OPEN).
The ability to enable simulation shall be restricted to Supervisors, System AdministratorsEngineering, and Maintenance personnel. PCS event log(s) and/or alarm log(s) shall
indicate transitions to/from simulation mode.
3.1.8.5. Disaster RecoverySystem documentation shall include detailed procedures for a complete re-install of
software on each PCS component. These procedures shall include sufficient detail tocompletely 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.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
28/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 28 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 Monitoringand Basic Control
Response
PCS control responses (e.g., PID controller output change in
response to a deviation from setpoint) should be commensurate withthe potential significance of the process change. For example:
Slow-moving regulatory response (e.g., vessel temperaturecontrol) should occur within five (5) seconds.
Fast-moving regulatory response (e.g., line pressure control)should occur within one (1) second.
Process InputDisplay
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 readingsand discrete feedback states) should be reflected in PCS
displays within five (5) seconds.
For process conditions that can exhibit rapid and significantchanges (e.g., pressure and flow readings, vessel rupture
disks), changes should be reflected in PCS displays withintwo (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 userwithin one (1) second (e.g., by changing a commanded stateindication). Process control response to user commands should be
commensurate with the potential significance of the requestedchange. For example:
A valid user command to start a batch should activate thefirst equipment phase within ten (10) seconds.
A valid user command to change the state of a control
module should change the appropriate control output withintwo (2) seconds.
Display NavigationEvidence of PCS response to a user command to change displaysshould 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.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
29/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 29 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
Activity/Event Performance Expectation
WorkstationSynchronization
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 StartupIn general, it should be possible to bring the PCS from a de-
energized state to a full working state within fifteen (15) minutes.
PCS ShutdownIn general, it should be possible to bring the PCS from a fullworking state to a fully de-energized state in a controlled manner
within fifteen (15) minutes.
3.1.9.2. Date and TimeThe PCS shall be designed to minimize and, as necessary, compensate for differences indate 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. Ifmanual 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 shouldautomatically (i.e., without user intervention) reconcile their date/time value with thetimekeeper 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 morethan 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.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
30/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 30 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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/oraccidental activities that could potentially compromise personnel, product, equipment,
and electronic records. Physical controls should include protection of all PCScomponents (through locking individual enclosures and/or through isolation in protected
areas such as locked rooms) from reasonable attempts to disrupt or modify thecomponent. Logical controls should include user authentication for any process control
or PCS modification activity. Refer to the User Interfaces section for additionaldescriptions related to logical PCS controls.
3.1.12. Safety
The PCS must be designed to both mitigate process hazards and to prevent introductionof 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 StressInjury
Components that require routine use (e.g., user interface hardware)
should be ergonomically designed. All PCS components shouldallow 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.
ExplosivePCS equipment should comply with regulations and standardsrelated to the explosive hazard classification of the installation area.
TrippingPCS equipment should not block normal entry and egress pathwaysor other personnel traffic areas.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
31/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 31 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
32/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 32 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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/ordesign 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 additionalhardware and/or software. The following capacity constraints are recommended:
Feature Capacity
Process Inputs andOutputs
At least 10% installed spare capacity should be provided for each
I/O type (discrete inputs, discrete outputs, analog inputs, analogoutputs, 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 atleast 50% (e.g., through addition of cabinets, processors, etc.)
should be provided.
Processing PowerNo more than 50% of the processing capacity of PCS componentsshould 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 anddisplay functionality.
Local Electronic
Storage
No more than 50% of the installed hard disk capacity in PCS
components should be consumed by installed software.
Historical andArchive Storage
Historical data storage capacity should allow for online retrieval ofat least 30 days of any historical data. Archive data storage shouldbe adequate to fulfill current electronic record retention
requirements with at least 25% spare capacity.
User InterfacesThe PCS should have the ability to expand user interfaces(workstations and/or displays) by at least 25% without deviating
from the fundamental PCS architecture.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
33/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 33 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 ofperformance expectations including input display and workstation synchronization
features.
3.2.3.2.
Online Historical DataPCS 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 efficientretrieval. 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 inprogress indication should be provided.
For data retrieval that could take more than twenty (20) seconds, an ability tocancel the query should be provided.
For data retrieval that could take more than thirty (30) seconds, a roughprogress indicator (e.g., percent complete bar graph) should be provided.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
34/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 34 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
3.2.3.3. Archived Historical Data
Access to archived historical data should also be optimized for efficient retrieval. Sincearchiving and retrieval mechanisms vary, no specific access speed specification is
applicable. In general, access to archived data in a specific format (report, chart, orrestoration 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 dataretention 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 systemdesign 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 mustinclude 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 mustbe 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 ongoingprocess 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 PCSdesign 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 specificationstraceability 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 readableand electronic form.
Protection throughRetention Period
Refer to the Data - Archive Requirements subsection of thisdocument.
Limiting System
Access
Refer to the Functions - Security and User Interfaces - General:
Security subsections of this document.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
35/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 35 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 timeof operator entries and actions that create, modify, or delete
electronic records. Record changes shall not obscure previouslyrecorded information.
Operational SystemChecks
PCS specification documentation shall clearly identify permittedsequencing of steps and events that must be enforced, if any. The
PCS must be designed to enforce this sequencing, as appropriate.
Authority ChecksRefer 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. ThePCS 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 theserequirements. Developer resumes, or similar certificates of
qualification, must be included in project and/or PCSdocumentation.
System
DocumentationControls
System operation and maintenance documentation must beincluded with the PCS. Distribution of, access to, and use of this
documentation must be adequately controlled and subject torevision and change control procedures that maintain an audit trail
that documents time-sequenced development and modification ofsystems documentation.
Open System
Controls
Systems with any component(s) that are not installed in an
environment in which system access is controlled by personsresponsible for the content of electronic records that are on the
system are considered Open Systems. Open systems mustinclude controls to ensure the authenticity and integrity of
electronic records from the point of their creation to the point oftheir receipt. Such procedures and controls shall include additional
measures such as document encryption and use of appropriatedigital signature standards.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
36/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 36 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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 userinterface 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 agraphical format.
Process Monitoring:
Unit
Features designed to provide structured access to the primarystate(s) and values for all modules and/or measurements. Unit
displays typically present modules related to a single process unitand/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 thatmimic traditional analog instrument faceplates.
Process Monitoring:
Analytical
Features designed to display historical and/or statistical informationto users. These typically include a historical trend display and, for
discrete manufacturing, one or more Statistical Process Controldisplays.
Process Control:Detailed
Features that allow users to manipulate process control elements
(e.g., by changing control module modes, states, etc.). Processcontrol 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 screensfor batch initiation, resource arbitration, batch monitoring, user
prompts/responses, individual phase control, alarms, and reports.
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
37/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 37 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
Task Description
SupervisoryFunctions
Features, protected from operator access, designed to provide
extraordinary process and batch management controls. Protectedsupervisory capabilities may include overriding interlocks,
modifying batch execution, temporarily modifying engineeringparameters, workstation shutdown, etc.
Alarm ManagementFeatures designed to notify user of monitored alarms, allowacknowledgement of those alarms, provide a record of alarm-
related events, and display summaries and histories of alarms.
PCS AnalysisFeatures designed to display the status of the Process ControlSystem components.
ReportsFeatures 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 tothe primary operating system interface(s) and employ strict user
access controls to help enforce adherence to change controlprocedures.
Recipe ManagementFeatures provided to allow for creation, modification, and deletionof 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 processequipment 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 beconsistent with 21 CFR Part 11 requirements for protection of computer systems that
employ electronic records and electronic signatures. These include (but are not limitedto) the following:
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
38/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 38 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
User accounts shall be unique to one individual and shall not be reused by, orreassigned 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 ofthese components should be secret or otherwise guaranteed to be unique.
Workstation logins should expire (e.g., by automatic logout) if no user activityoccurs 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 unauthorizedaccess attempt to the system security unit, and, as appropriate, toorganizational management.
Access level assigned to an individual will dictate which workstations, interfaces, anddisplays a user has access to, and which operations the user can perform. Where feasible,
user access administration should leverage existing site computer security policies andprocedures (including security administration servers and existing user accounts).
Users may be allowed to view and navigate operating displays without login. However, alogin 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 ProcessControl 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 andaccessible 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 theworkstation and/or the workstation login account authority. For example, process
operator workstations should start by showing a startup menu and/or overview displayappropriate 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 workstationwithout restarting.
With proper authority, all PCS operating displays should be accessible from any PCSworkstation. Security features should be capable of limiting workstation functionality
according to the following user characteristics:
-
8/11/2019 USER REQUIREMENTS TEMPLATE for a Supervisory Control and Data Acquisition (SCADA) Process Control System
39/66
JETTUSER REQUIREMENTS
SPECIFICATION
Process Control System
Page 39 of 66
URS, Rev.0
December 7, 2002
JOINT EQUIPMENT TRANSITION TEAM
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. Thefollowing navigation characteristics should be provided:
Navigation Attribute
Display navigation should be limited, as appropriate, based on theworkstation role and/or user login.
Navigation from any display to any other display should not require morethan 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 singlekeystroke/click navigation to this menu system.
Off-screen connectors to/from a process display should include singlekeystroke/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 andunit 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 sin