SCADAURS[1]

7/31/2019 SCADAURS[1]

1/64

7/31/2019 SCADAURS[1]

2/64

JETTUSER REQUIREMENTS

SPECIFICATIONProcess Control System

Page 2 of 64

URS, Rev.0

December 7, 2002

NOTES for use of the User Requirements Template:

Upon completion of the template, delete this page prior to updating the Table of Contents and printing.

1. Many areas of this template have selections or tables that have been prepared for guidance 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 the specificdocument being created should be deleted as well.

2. To update the final Table of Contents, place the cursor inside the shaded area, press the Rightmouse 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.

JOINT EQUIPMENT TRANSITION TEAM

7/31/2019 SCADAURS[1]

3/64



Page 3 of 64

URS, Rev.0

December 7, 2002

TABLE OF CONTENTS

REVISION HISTORY..................................................................................................................................4

I.0 INTRODUCTION....................................................................................................................................5

II.0 OVERVIEW............................................................................................................................................8

III.0 OPERATIONAL REQUIREMENTS..............................................................................................15

IV.0 CONSTRAINTS...................................................................................................................................51

V.0 LIFE-CYCLE........................................................................................................................................57

VI.0 GLOSSARY..........................................................................................................................................60


7/31/2019 SCADAURS[1]

4/64



Page 4 of 64

URS, Rev.0

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

contentA3 6/1/03 Content Review by Chris Roerig, Paul Coury, Steve Smith, John

LiebenthalA4 6/14/04 Content Review by Chris Roerig, Pat Cashman, Andre Powell,

Sarah Powell, Michelle Ubele


7/31/2019 SCADAURS[1]

5/64



Page 5 of 64

URS, Rev.0

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.

I.0 INTRODUCTION

I.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, constraintssuch as time and costs, and what deliverables are to be supplied.

I.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) Guideavailable 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 testing

protocols. Modifications to, and/or deviations from, the specifications in an approvedURS are subject to formal change control procedures.

The following documents are related to the URS:

# Reference Contains1 Project Scope and Charter 2 Process design3 Applicable automation standards


7/31/2019 SCADAURS[1]

6/64

7/31/2019 SCADAURS[1]

7/64

7/31/2019 SCADAURS[1]

8/64

7/31/2019 SCADAURS[1]

9/64



Page 9 of 64

URS, Rev.0

December 7, 2002

II.1.2. Facility OverviewThe is a manufacturing facility located in designed to

produce . 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.}

R e c e i v

W a r e h

P r e w e

W F I

B u f f e r

S h i p p

M a t e r i a l H

H i g h P u r i t

C h i l l e d W

I n s t r u m e

W a s t e H

U t i l i t i e s

R e a c tR 1 0 0

C e n t r iC 1 0 0

W a s hT 1 0 0

R e c e i v iT 1 0 1

M a n u f a c t

R e a c t oR 2 0 0

C e n t r i f uC 2 0 0

W a s h TT 2 0 0

R e c e i v i nT 2 0 1

M a n u f a c t u r i

B o t t l e P

B o t t l i n g

B o t t l i n g

C a r t o n

P a c k a g i n

E x i s N e M o d


7/31/2019 SCADAURS[1]

10/64



Page 10 of 64

URS, Rev.0

December 7, 2002

II.1.2.1. Existing Facilities and Equipment

II.1.2.2. New Facilities and Equipment

II.1.2.3. Modifications to Existing Facilities and Equipment


7/31/2019 SCADAURS[1]

11/64



Page 11 of 64

URS, Rev.0

December 7, 2002

II.1.3. Automation OverviewThe 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.}

M R P S y s t

D o c u m e n t MS y s t e m

L I M S

P r o c e s s H i

C o r e S y s t e

W a r e h o u s e

S y s t e m

P r e w e i g h

B u i l d i n g M aS y s t e m

M a t e r i a l H aS y s t e m s

B u f f e r P r B a t c h i n g S

M a n u f a c t u r P r o c e s s C o n

M a n u f a c t u r P r o c e s s C o n

M a n u f a c t u

P r o c e s s C

H i g h P u r i t yS k i d C o n t

C h i l l e d WS k i d C o n t

W F IP r o c e s s C o n

U t i l i t i e sP r o c e s s C

P r o c e s s A u t o m

R e g u l a t e d S

E x i s N e M o d


7/31/2019 SCADAURS[1]

12/64



Page 12 of 64

URS, Rev.0

December 7, 2002

II.1.3.1. Existing Systems

II.1.3.2. New Systems

II.1.3.3. Modifications to Existing Systems


7/31/2019 SCADAURS[1]

13/64



Page 13 of 64

URS, Rev.0

December 7, 2002

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

II.3. Simulation SystemThe PCS vendor scope includes the hardware and packaged software necessary toconfigure and support an independent Simulation System. The Simulation System shall

be initially installed at the vendor site and utilized for the development and factory testingof the application software. When the applicationsoftware is ready for installation at the facility, itwill be transferred from the Simulation System to the facility PCS hardware platform.Subsequently, the Simulation System hardware and packaged software will also be movedto the site, and utilized for PCS application maintenance andenhancement activities.

II.4. Exclusions and Future Considerations

The S88.01 standard and the utilized hardware/software platform provide extensivecapabilities within a batch environment. has elected to limit the initialimplementation of select batch capabilities, favoring a high level of manual processinteraction by operating personnel, supported by Standard Operation Procedure (SOP)driven paper system(s). This initial operating philosophy does not imply that futureenhancement(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/placingall process unit valves in automatic mode, verifying/placing all controlmodules are in automatic mode, etc.

It is s intent to continue development of various facility procedures, beyond those initially provided at PCS startup. It is the intent that


7/31/2019 SCADAURS[1]

14/64



Page 14 of 64

URS, Rev.0

December 7, 2002

phases developed for the project be suitable for use in thesefuture procedure development activities. Where feasible, procedures andoperations are designed and implemented as a library of phase building

blocks, even though a given phase may not be utilized in a procedure at thetime of PCS startup. It is understood that the phase library at PCS startup, maynot 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 performthe following functions:

Tracking process equipment fitness for use for a specific function (such asClean, 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 thesubject process equipment is suitable for the PCS phase or procedureapplication. The PCS ensures that the subject process equipment is availableand 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 isnot 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.


7/31/2019 SCADAURS[1]

15/64



Page 15 of 64

URS, Rev.0

December 7, 2002

III.0 OPERATIONAL REQUIREMENTS

III.1. Functions

III.1.1. Process Monitoring

III.1.1.1. Real-Time Data Collection and DisseminationThe 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, theknown state of the process. Control strategy algorithms produce process control outputsthat 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

Requiredimmediacy

Response time for value display and alarming, historical datacollection frequency, and control processing requirements shoulddictate the minimum acceptable data collection and transfer rates.

Required precision Insignificant digits should not be presented to users, historicallycollected, or considered in data processing.

Data consistency

In some component systems, communication delays may introducetransient and/or scan-based differences in data values. Datacollection design must prevent inconsistent display, control response,and historical collection of alarm and other threshold events. Thedesign must also avoid other data collection and communication

mechanisms that could result in sustained inaccuracies betweendisplay data, historical data, and control processing data.

Future expansionand/or enhancement

Hardware, software, and communications design should providecapacity for future expansion and potential changes to control and/or display strategies.


7/31/2019 SCADAURS[1]

16/64

7/31/2019 SCADAURS[1]

17/64



Page 17 of 64

URS, Rev.0

December 7, 2002

The system shall provide for process alarm priorities, a minimum of five levels, which areselectable during configuration. At least one of the priority levels will represent alarmsthat affect the quality of the batch (GMP alarm level). Other alarm priorities will beassigned 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 berecorded 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 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 normal controlloop 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.

III.1.2.2. Alarm AcknowledgementOperators must be logged on to the PCS and have the proper authority as enforced by PCSsecurity to acknowledge alarms. The PCS shall record in the operator action log allacknowledgement activities. The operators electronic signature, the action taken, dateand time must be recorded with each acknowledgement. The PCS shall support twomeans 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. Notethat group acknowledgement shall result in an entry in the operator action log for eachindividual alarm.

III.1.2.3. Alarm Output devicesThe 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


7/31/2019 SCADAURS[1]

18/64



Page 18 of 64

URS, Rev.0

December 7, 2002

Alarm printer Annunciator panels

III.1.3. Basic Control

III.1.3.1. ConceptBasic control consists of algorithms performed on monitored data values (including

process control inputs, user inputs, tunable parameters, and constants) to determine thestate 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.).

III.1.3.2. Control ModulesA 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-speedmotors, and variable speed motors. Design of PCS control modules shall consider all of the 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.

Class attributes

Each control module class should have a specific and well-definedset 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.).


7/31/2019 SCADAURS[1]

19/64



Page 19 of 64

URS, Rev.0

December 7, 2002

Factor Description

Control requestmanagement

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 identifythe current state, the current mode, and the source of active control.Invalid user inputs should, where possible, produce a messageidentifying the reason the input will not be processed.

Bumpless transfer Control module mode changes should not cause an immediatecorresponding change in control module state, setpoint, or output.

Fault annunciationand 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 toopen). 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 and

comprehensively replace it with mode and/or faultmonitoring by the supervisory object.

Data utilization

All relevant data (I/O, user requests, parameters, etc.) shall beappropriately 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 andI/O forcing shall be obvious from all impacted user interfaces andreports.

III.1.3.3. InterlocksInterlocks modify control module states in response to process conditions in order to

protect personnel, process equipment, and/or product. Design of PCS interlocks shallconsider all of the following:


7/31/2019 SCADAURS[1]

20/64



Page 20 of 64

URS, Rev.0

December 7, 2002

Factor Description

Productindependence

Interlock functionality should not consider current product processing requirements. In general, interlocks should only beapplied for personnel protection, equipment protection, and/or

prevention 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 a

complimentary interlock and/or fault monitoring by thesupervisory object.

Overrides The ability to manually override interlocks, if available, shall bereserved for engineering and maintenance users.

Display

Control module interfaces should, where possible, clearly identifywhether or not a control module interlock is active. The specificcause of the interlock should be either displayed as part of thecontrol module interface and/or readily accessible from the controlmodule interface.

Record of interlock events

Historical data collection must include a record of interlock-relatedevents (activation, clearing, overrides, etc.). Reports that include alist of alarms and events should include interlock-related events.

III.1.3.4. Complex ModulesComplex modules include control modules with subordinate control modules andequipment 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 basedon a desired vessel jacket state or temperature setpoint) NOTE: Complex Modules are differentiated from Equipment Phases which arecontrolled through the Batch Manager interface. A complex module is an independentobject that can be utilized with and/or without the Batch Manager. PCS design need onlyinclude 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:


7/31/2019 SCADAURS[1]

21/64



Page 21 of 64

URS, Rev.0

December 7, 2002

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

Class attributes

Each complex module class should have a specific and well-definedset 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 requestmanagement

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 identifythe current state, the current mode, and the source of active control.Invalid user inputs should, where possible, produce a messageidentifying the reason the input will not be processed.

Bumpless transfer Complex module mode changes should not cause an immediatecorresponding change in complex module state, setpoint, or output.

Fault annunciationand 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 bedesigned to mitigate risk to personnel, product quality, and processequipment.

Harmony withsupervisory 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 and

comprehensively replace it with mode and/or faultmonitoring at the phase level.

Harmony withsimulation

Where applicable and possible, installed simulation activation andI/O forcing shall be obvious from all impacted user interfaces andreports.


7/31/2019 SCADAURS[1]

22/64



Page 22 of 64

URS, Rev.0

December 7, 2002

III.1.4. Equipment Phase Control

III.1.4.1. Concept

Equipment phases provide all of the recipe-driven processing functionality of the PCS.Each equipment phase provides a strategic combination of regulatory and sequentialcontrol intended to exploit a specific processing capability of the equipment. Thefollowing 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 equipment phases except where necessitated by process equipment design, and

Shared equipment phases and shared control modules should not unnecessarilyrestrict or otherwise interfere with parallel activities.

III.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 identityof 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.

III.1.4.3. Exception HandlingEquipment 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 intrusiveresponse that still provides adequate personnel, equipment, and product protection. For example, a product temperature deviation should not necessarily disable automatictemperature 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,


7/31/2019 SCADAURS[1]

23/64



Page 23 of 64

URS, Rev.0

December 7, 2002

Equipment phase execution is not interrupted by minor anomalies that areunlikely to jeopardize personnel, equipment, or product (though operator notification 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, should

automatically resume manufacturing operations without unnecessarilyrepeating steps or extending execution times (e.g., by unnecessarily resettingtotalizers, counters and timers).

III.1.5. Batch ManagementThe 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, and draftstandard dS95.01, Standard for Enterprise Control System Integration Models andTerminology. The use of these standards supports application of industry standardsoftware 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. 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, ProcessManagement 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 recipe

execution Provide download and upload capability for recipe parameters Provide for PCS ad hoc event reporting to the Batch Manager.


7/31/2019 SCADAURS[1]

24/64



Page 24 of 64

URS, Rev.0

December 7, 2002

III.1.6. Historical Data Collection and Retention

III.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 employappropriate 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, asapplicable, reports.

III.1.6.2. Alarms and EventsProcess alarm and event data shall be accumulated in a historical database. Each recordshall 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 PCSshould employ appropriate provisions for secure data collection and retention (e.g.,automatic daily backup, disaster recover provisions, long-term data archiving andrestoration 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.

III.1.7. Other Monitoring and Control Features

III.1.7.1. Locally Controlled Packaged EquipmentSelect process equipment is packaged in a stand-alone configuration that includessufficient local control capability to perform the intended functionality. These packagedsystems are designed to include the necessary interface capability to permitcommunication with the PCS. It is the responsibility of the System Integrator tocoordinate 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).

III.1.7.2. Resource ManagementModes, states, statuses, and other attributes of all process resources (including processunits, bulk material supplies, logical modules such as totalizers, etc.) should be clearlydefined 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 unitClean status) should be considered in Basic Control interlocks and Equipment Phaseexception handling, as appropriate.


7/31/2019 SCADAURS[1]

25/64



Page 25 of 64

URS, Rev.0

December 7, 2002

III.1.7.3. Engineering ParametersIn general, hard-coded values related to both Basic Control and Equipment Phase Controlshould 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).

III.1.8. Modes of Operation

III.1.8.1. StartupSystem documentation shall include detailed procedures for starting the PCS (in total) andfor 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.

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.

III.1.8.2. ShutdownSystem documentation shall include a detailed procedure for performing a controlled andcomplete shutdown of the PCS. PCS shutdown shall cause controlled process equipmentto revert to a pre-defined safe (typically de-energized) state.

The ability to shutdown the PCS shall be restricted to Supervisors, SystemAdministrators, Engineering, and Maintenance personnel. PCS event log(s) and/or alarmlog(s) shall indicate the normal shutdown of any PCS component. Where possible, PCSevent log(s) and/or alarm log(s) shall indicate abnormal PCS component shutdowns (e.g.,

power interruptions).

III.1.8.3. Normal OperationOn PCS restart according to the PCS startup procedure(s), normal operation shall beenabled. System documentation shall include detailed procedures for normal PCSoperation (e.g., display elements and navigation, starting batches, using control modules,etc.). The ability to perform normal PCS operations shall be based on privilegesassociated with the users account.


7/31/2019 SCADAURS[1]

26/64



Page 26 of 64

URS, Rev.0

December 7, 2002

III.1.8.4. SimulationThe 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 closedfeedback 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) shallindicate transitions to/from simulation mode.

III.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 besupplied with the PCS.

III.1.9. Performance and Timing

III.1.9.1. PCS PerformancePCS performance should be adequate to provide a safe, effective, and responsive system.The following guidelines are intended to indicate performance expectations:


7/31/2019 SCADAURS[1]

27/64



Page 27 of 64

URS, Rev.0

December 7, 2002

Activity/Event Performance Expectation

Regulatory ProcessMonitoring andBasic ControlResponse

PCS control responses (e.g., PID controller output change inresponse 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 commensuratewith 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 PCSdisplays within five (5) seconds.

For process conditions that can exhibit rapid and significantchanges (e.g., pressure and flow readings, vessel rupturedisks), changes should be reflected in PCS displays withintwo (2) seconds.

User ControlCommand

Evidence of PCS response to user commands (e.g., changing controlmodule states, starting a batch) should be presented to the user within one (1) second (e.g., by changing a commanded stateindication). Process control response to user commands should becommensurate 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 controlmodule should change the appropriate control output withintwo (2) seconds.

Display Navigation

Evidence of PCS response to a user command to change displaysshould be presented to the user within one (1) second. The targetdisplay should be completely painted, with up-to-date data values,within five (5) seconds.

WorkstationSynchronization

When a process attribute is changed from one workstation, theattribute 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 ShutdownIn general, it should be possible to bring the PCS from a full workingstate to a fully de-energized state in a controlled manner withinfifteen (15) minutes.


7/31/2019 SCADAURS[1]

28/64



Page 28 of 64

URS, Rev.0

December 7, 2002

III.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 thetimekeeper node will be periodically reconciled to a known accurate date/time source.Timekeeper node date/time value should not normally deviate from the known accuratedate/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 shouldautomatically (i.e., without user intervention) reconcile their date/time value with thetimekeeper node date/time value periodically (typically once per day). Node date/timevalues 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) ina way that allows determination of the pre-reconciliation date/time value offset.

III.1.10. Response to FailuresPCS 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.

All such PCS failures and anomalies should be treated as process alarms (i.e., annunciatedand subjected to alarm management functions). PCS fault conditions that potentiallyimpact data quality should be propagated and accommodated, as appropriate, in data

processing, collection, and display.

III.1.11. SecurityAll 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 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 controlor PCS modification activity. Refer to the User Interfaces section for additionaldescriptions related to logical PCS controls.


7/31/2019 SCADAURS[1]

29/64



Page 29 of 64

URS, Rev.0

December 7, 2002

III.1.12. SafetyThe 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 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 constructionstandards including appropriate grounding and fusing.

Explosive PCS equipment should comply with regulations and standardsrelated to the explosive hazard classification of the installation area.

Tripping PCS equipment should not block normal entry and egress pathwaysor other personnel traffic areas.

III.2. Data

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


7/31/2019 SCADAURS[1]

30/64



Page 30 of 64

URS, Rev.0

December 7, 2002

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

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 theadditional preliminary data listed above represents preliminary functional and/or design s pecifications. If practicable, development and publication of these items should be reserved for the Functional Specification and/or Design Specification documentation. }

III.2.2. Capacity RequirementsHardware and software selection should allow for some expansion without additionalhardware 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:


7/31/2019 SCADAURS[1]

31/64



Page 31 of 64

URS, Rev.0

December 7, 2002

Feature Capacity

Process Inputs andOutputs

At least 10% installed spare capacity should be provided for eachI/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, andI/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 componentsshould be required to provide normal processing and displayfunctionality 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 ElectronicStorage

No more than 50% of the installed hard disk capacity in PCScomponents should be consumed by installed software.

Historical andArchive 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 retentionrequirements 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.

III.2.3. Access Speed

III.2.3.1. Real-time DataAccess 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 performanceexpectations including input display and workstation synchronization features.

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


7/31/2019 SCADAURS[1]

32/64



Page 32 of 64

URS, Rev.0

December 7, 2002

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 diversenature 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 tocancel the query should be provided.

For data retrieval that could take more than thirty (30) seconds, a rough progress indicator (e.g., percent complete bar graph) should be provided.

III.2.3.3. Archived Historical DataAccess to archived historical data should also be optimized for efficient retrieval. Sincearchiving and retrieval mechanisms vary, no specific access speed specification isapplicable. 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.

III.2.4. Archive RequirementsPCS historical data retention capabilities must conform to site and/or product dataretention requirements. In general, all PCS historical data (including time-sequencedanalog values, alarm, event, and batch logs) should be accessible for at least ten (10)years. Any robust archiving technology is acceptable, however, existing site archivingfacilities, technologies, and procedures should be exploited if possible. Archive systemdesign should consider the potential for having to migrate the historical data so thataccess can be preserved beyond the point of PCS de-commissioning.

PCS system manuals must include detailed procedures for committing historical data toarchive and for retrieving historical data from archive. Retrieved historical data mustinclude any and all data that was, or may have been, considered for verifyingmanufacturing 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.

III.2.5. Data Security and IntegrityPCS data security and integrity features must be consistent with controls required by 21CFR Part 11 to protect electronic records. The following table identifies anticipated PCSdesign features intended to satisfy these requirements:


7/31/2019 SCADAURS[1]

33/64



Page 33 of 64

URS, Rev.0

December 7, 2002

Part 11 Control PCS Compliance Feature(s)

System ValidationPCS development lifecycle and documentation must be adequate tosupport system validation. This should include a specificationstraceability matrix and/or similar quality control mechanisms.

Copying RecordsPCS manuals should include detailed procedures for generatingaccurate and complete copies of records in both human readableand electronic form.

Protection throughRetention Period

Refer to the Data - Archive Requirements subsection of thisdocument.

Limiting SystemAccess

Refer to the Functions - Security and User Interfaces - General:Security subsections of this document.

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 deleteelectronic 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. ThePCS 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. ThePCS must be designed to enforce these restrictions, as appropriate.

Training

Project documentation must identify minimum qualifications(experience and training) for PCS developers. Each PCSdevelopers 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 be includedwith the PCS. Distribution of, access to, and use of thisdocumentation must be adequately controlled and subject torevision and change control procedures that maintain an audit trailthat documents time-sequenced development and modification of systems documentation.


7/31/2019 SCADAURS[1]

34/64



Page 34 of 64

URS, Rev.0

December 7, 2002

Part 11 Control PCS Compliance Feature(s)

Open SystemControls

Systems with any component(s) that are not installed in anenvironment in which system access is controlled by personsresponsible for the content of electronic records that are on thesystem are considered Open Systems. Open systems must includecontrols to ensure the authenticity and integrity of electronic recordsfrom the point of their creation to the point of their receipt. Such

procedures and controls shall include additional measures such asdocument encryption and use of appropriate digital signaturestandards.

III.3. User Interfaces

III.3.1. General

III.3.1.1. User Interface DesignUser Interfaces are designed to facilitate both general process awareness and specific PCStasks. 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 thestatus 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. Unitdisplays 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 importantattributes (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.


7/31/2019 SCADAURS[1]

35/64



Page 35 of 64

URS, Rev.0

December 7, 2002

Task Description

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 monitoringdetail interface features.

Process Control:Batch Management

Features that provide for monitoring and control of recipeexecution. Batch management features typically include screens for

batch initiation, resource arbitration, batch monitoring, user prompts/responses, individual phase control, alarms, and reports.

SupervisoryFunctions

Features, protected from operator access, designed to provideextraordinary process and batch management controls. Protectedsupervisory capabilities may include overriding interlocks,modifying batch execution, temporarily modifying engineering

parameters, 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 Analysis Features designed to display the status of the Process ControlSystem components.

Reports Features designed to select and display/print written summaries of historical production data.

Programming andConfiguration

Features provided to allow for future modification of applicationconfiguration 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 control

procedures.

Recipe Management Features provided to allow for creation, modification, and deletionof process recipes.

III.3.1.2. User Interface HardwareUser Interface hardware may include computer terminals, panel-mounted interfaceequipment (push-buttons, signal/status lights, hand switches, etc.), tower lights, horns,message displays, and printers. User interface hardware locations are intended to provideusers 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 installationenvironment (refer to the Environment - Physical Conditions subsection for details).

User Interface hardware fault-tolerance features must be appropriate to the hardwarefunction. Where possible, hardware failure alerts should be integrated with the user interface in a way that allows for appropriate response and maintenance.


7/31/2019 SCADAURS[1]

36/64



Page 36 of 64

URS, Rev.0

December 7, 2002

III.3.1.3. SecurityAll 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: 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 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 and

procedures (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., modulemodes 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.

III.3.1.4. Workstation Roles and AccessStartup characteristics of each workstation should be appropriate to the role of theworkstation and/or the workstation login account authority. For example, processoperator workstations should start by showing a startup menu and/or overview displayappropriate to the specific role of the workstation. The following may be controlledaccording 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.


7/31/2019 SCADAURS[1]

37/64



Page 37 of 64

URS, Rev.0

December 7, 2002

With proper authority, all PCS operating displays should be accessible from any PCSworkstation. Security features should be capable of limiting workstation functionalityaccording to the following user characteristics:

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)

III.3.1.5. Workstation Display NavigationDisplay 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 single keystroke/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 detaildisplays 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 single keystroke/click navigation toupstream and downstream process displays according to a comprehensivesequence, or sequences, of process displays.

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

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


7/31/2019 SCADAURS[1]

38/64



Page 38 of 64

URS, Rev.0

December 7, 2002

Navigation Attribute

Process detail displays (i.e., faceplates) should provide single keystroke/click navigation to real-time and/or historical trend display(s).

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

Batch management displays should provide single keystroke/click navigationto 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., keyboardkeystrokes should be sufficient for navigation).

III.3.2. Process Monitoring

III.3.2.1. Common Display FeaturesThe following display elements must be included on all full-screen PCS processmonitoring 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 processmonitoring displays.

III.3.2.2. Process Overview DisplaysProcess overview displays provide discrete icons or symbols for each process unit or ancillary system subordinate to the overview. Every process unit and ancillary systemwithin 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 thePCS, process overview displays should be linked by a rapid navigation capability.


7/31/2019 SCADAURS[1]

39/64



Page 39 of 64

URS, Rev.0

December 7, 2002

Process overview displays should be logically organized and, if necessary, logicallysubdivided. 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.).

III.3.2.3. Process Unit DisplaysProcess unit displays are typically associated with a single process unit or ancillarysystem (e.g., headers, bulk material systems, shared equipment, etc.). These displays

provide discrete dynamic icons, symbols, and/or text representations for each subordinateequipment module, control module, and other key dynamic process attributes.

Every equipment module, control module, and key dynamic process attribute within thescope of the PCS should be included on a process unit display. With the possibleexception 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 unitdisplay.

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. Arapid navigation capability should also be provided to the following:

Related process unit displays (e.g., upstream units, downstream units, andsupporting 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, operatingresponsibilities or some combination of the above.

In addition to the common process monitoring display features previously identified, thefollowing elements and animations are common to process unit displays:

Object Attribute(s) Dynamic?State (Open, Closed, etc.) Yes


7/31/2019 SCADAURS[1]

40/64



Page 40 of 64

URS, Rev.0

December 7, 2002

Object Attribute(s) Dynamic?Simple Discrete Inputs (level switch,

pressure switch, etc.) Alarms Yes

Simple Analog Inputs (temperatures, pressures, levels, etc.)

Value YesEngineering Units NoAlarms Yes

Discrete Control Modules (valves, pumps, etc.)

State (Open, Closed, etc.) YesMode (Auto, Manual, etc.) YesAlarms YesInterlocks Yes

Analog Control Modules(controllers, variable frequencydrives, etc.)

State (Open, Closed, etc.) YesMode (Auto, Manual, etc.) Yes

Setpoint (SP) YesControl Output (CV) YesProcess Value (PV) YesEngineering Units (PV, SP, and CV) NoAlarms YesInterlocks Yes

Pipes and other conduits Content/service No

Equipment PhasesIdentifier NoState Yes

Step Number YesBatch Management Batch ID Yes

Batch state YesProcedure ID YesUnit Operation ID YesOperation ID YesMessage pending indicator Yes

III.3.2.4. Process Detail DisplaysProcess 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 issometimes referred to as faceplates or device pop-ups. They provide dynamic icons,symbols, and/or text representations for every important aspect of the subject equipmentmodule, control module, or other dynamic process resource.


7/31/2019 SCADAURS[1]

41/64

7/31/2019 SCADAURS[1]

42/64



Page 42 of 64

URS, Rev.0

December 7, 2002

Detail Display Class Attribute(s)Ability to change stateMode (Auto, Manual, etc.)Ability to change modePhase parameter valuesPhase parameter rangesPhase parameter value engineering unitsAbility to change parameter values

III.3.2.5. Trend DisplaysReal-time trending and historical data trending displays shall be provided for key process

attributes. In addition to the common process monitoring display features previouslyidentified, 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.

III.3.2.6. Statistical Process Control DisplaysStandard Statistical Process Control (SPC) displays (e.g., X-Bar charts and ParetoDiagrams) shall be employed as appropriate to provide analysis of manufacturing batchquality and cycle time.

III.3.3. Batch Management Interfaces

III.3.3.1. Graphical Environment and Navigational AidsBatch 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 PCSalarm and message screen shall always be visible. The operator is notified of actionrequests generated by controller resident procedural elements or recipe operation via aflashing color-coded button on this screen. Navigation controls are provided which guidethe 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 whena pending OAR exists for the unit. When depressed the button activates navigationcontrols that will take the operator to either the appropriate Batch Manager recipe or PCSUnit Phase Display depending upon the unit mode.


7/31/2019 SCADAURS[1]

43/64



Page 43 of 64

URS, Rev.0

December 7, 2002

III.3.3.2. Unit Phase DisplayThe PCS shall provide the operator interface to the unit through a Unit Phase/Recipestatus 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 providedthrough Batch Manager screens. In manual mode the PCS screens provide the operator interface to the equipment procedural control through phase faceplate displays. The UnitPhase 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

III.3.3.3. Operator MessagesThe PCS shall provide the capability to issue information or instructive messages to theoperator. Operator messages shall be displayed on the Unit Phase Control screen.Operator messages are generated by controller resident procedural elements and areinstructive text which guide the operator through a manual activity which is embedded inan controller resident procedural element. The mechanism for triggering a specificmessage shall be separate from the contents of the message. This shall allow modificationof 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 PCSEvent Log along with the operators electronic signature, date, time, unit and batch IDnumber.

III.3.4. Alarm Management Interfaces

III.3.4.1. Alarm DisplayAll 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 alarmlist/banner and on a relevant graphic, in the specified colors. Alarm displaycharacteristics are determined according to their state and their priority. The display andannunciation of an alarm is activated by a change in state of the alarm. The system shallsupport configuration of dynamic color change of foreground and background text based

on current alarm state at a given priority level. The system shall also supportconfiguration of an internal audible signal as well as an output to external light or audiblesignal 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 Active Unacknowledge - Alarm is active but not acknowledged by the operator


7/31/2019 SCADAURS[1]

44/64



Page 44 of 64

URS, Rev.0

December 7, 2002

Cleared Unacknowledged Alarm condition has returned to normal statewithout operator acknowledgement.

III.3.4.2. Alarm Summary Display InformationThe 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 basisdefined as oldest, highest priority, non-acknowledge alarm first. The PCS shall providefor filtering and display of the alarm list in the following ways:

Alarm severity Critical alarm category Process Area / Cell / Unit

III.3.4.3. Alarm LogA 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 loggingcapability. 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 alarmand maximum and minimum deviations are recorded to the alarm database with eachalarm event. The system shall also calculate and record the duration of an alarm when thealarm clearance event is detected.

System alarm logging shall be triggered by the following alarm status changes: Activation (and re-activation) Clearance


7/31/2019 SCADAURS[1]

45/64



Page 45 of 64

URS, Rev.0

December 7, 2002

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 Critical alarm category 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 tothe 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 followinginformation 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

III.3.4.4. Alarm ReportsThe system shall be capable of producing the following alarm reports for investigationand alarm performance analysis: The system shall provide a review tool providing querycapability by either tag, time, process area/cell/unit, batch ID or combination of theabove.

Alarm Reports Table

Report DescriptionGMP Alarm Batch Report A report identifying all the GMP alarms. This report may get

attached to the manufacturing batch record and used as sourceinformation 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 alarmsStanding 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


7/31/2019 SCADAURS[1]

46/64



Page 46 of 64

URS, Rev.0

December 7, 2002

III.3.5. PCS Status Interface

III.3.5.1. PCS Status DisplayPCS status display(s) should include a dynamic system architecture diagram withanimations indicating the location of active PCS alarms.

III.3.5.2. PCS Event and Error LogsImportant PCS events and errors should be annunciated and presented to the appropriatesystem user(s). The following event types may be included:

Event Type DescriptionError 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 Informationevent will be logged.

Success Audit An audited security access attempt that succeeds. For example, a user's successfulattempt 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 anetwork drive and fails, the attempt will be logged as a Failure Audit event.

Annunciated PCSThese events and errors are to be treated as electronic records (i.e., notmaintained exclusively in text files).

III.3.6. Programming and Configuration InterfacesOffline ability to modify and test changes to PCS software must be provided. If existingdevelopment facilities and/or equipment are to be leveraged for this purpose, qualificationtesting 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.

III.3.7. Recipe Management InterfaceOffline ability to modify and test changes to PCS recipes must be provided. If existingrecipe management facilities and/or equipment are to be leveraged for this purpose,qualification testing must verify the validity of this approach.


7/31/2019 SCADAURS[1]

47/64



Page 47 of 64

URS, Rev.0

December 7, 2002

Recipes developed for the PCS must be controlled as electronic records, in accordancewith 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 previousrecipe version.

III.3.8. ReportsPCS user interfaces should provide the features needed to request, display, and printreports. A comprehensive batch end report that includes all values and events needed toevaluate 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, Alarm and Event Reports, and Recipe Reports.

III.4. Remote PCS Access

The PCS architecture should include a secure network interface to the Local Area Network (LAN). Authorized LAN users should have

selected ability to monitor the process remotely. No control or engineering capabilityshould be accessible from any remote interface (i.e., interfaces that are not within thescope of the PCS should be view-only).


7/31/2019 SCADAURS[1]

48/64



Page 48 of 64

URS, Rev.0

December 7, 2002

III.5. Interfaces with Other Systems

III.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 eachinterface. For example, characterize the extent of remote maintenance capabilities to be

provided.}

III.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.}

III.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 thedegree of interaction between the systems.>

III.5.4. Shared Resources

7/31/2019 SCADAURS[1]

49/64



Page 49 of 64

URS, Rev.0

December 7, 2002

It is anticipated that the equipment will be distributed within thisfacility. The following considerations and principles should guide the physical design andlocation of PCS equipment:

Equipment locations must balance wiring costs, access convenience, cleaningrequirements, 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.

III.6.2. Physical ConditionsThe following environmental conditions should be considered in determining appropriateequipment installation locations:

Area Classification(s) Description

The following is a brief characteriz

Documents

SCADAURS[1]