JETT-SCADA-URS

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

JETT

USER REQUIREMENTS SPECIFICATION

Process Control System

Page 2 of 65 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 and ease of template completion. Text in italics is intended to be used as notes to the User and should be deleted prior to printing. Any options and/or examples that are not applicable to the specific document being created should be deleted as well. 2. To update the final Table of Contents, place the cursor inside the shaded area, press the Right mouse key, and select Update Field. 3. Items that can be directly tested are identified with a ∇ . 4. Where possible, the User should identify the source (e.g. studies, standards, etc.) for the acceptable ranges of variables or other critical requirements that have been derived.

JOINT EQUIPMENT TRANSITION TEAM

JETT




TABLE OF CONTENTS REVISION HISTORY.............................................................................................................................5 I.0 INTRODUCTION................................................................................................................................6 I.1. PURPOSE..........................................................................................................................................6 I.2. ORIGIN AND CONTEXT........................................................................................................................6 I.3. SCOPE.............................................................................................................................................7 I.4. DOCUMENT ORGANIZATION.................................................................................................................8 II.0 OVERVIEW........................................................................................................................................9 II.1. BACKGROUND..................................................................................................................................9 II.1.1. Project Overview......................................................................................................................9 II.1.2. Facility Overview....................................................................................................................10 II.1.3. Automation Overview.............................................................................................................12 II.2. GENERAL SYSTEM FUNCTIONS..........................................................................................................14 II.3. SIMULATION SYSTEM......................................................................................................................14 II.4. EXCLUSIONS AND FUTURE CONSIDERATIONS........................................................................................14 III.0 OPERATIONAL REQUIREMENTS...........................................................................................16 III.1. FUNCTIONS..................................................................................................................................16 III.1.1. Process Monitoring...............................................................................................................16 III.1.2. Alarm Management...............................................................................................................17 III.1.3. Basic Control.........................................................................................................................19 III.1.4. Equipment Phase Control.....................................................................................................23 III.1.5. Batch Management................................................................................................................24 III.1.6. Historical Data Collection and Retention.............................................................................25 III.1.7. Other Monitoring and Control Features...............................................................................25 III.1.8. Modes of Operation...............................................................................................................26 III.1.9. Performance and Timing.......................................................................................................27 III.1.10. Response to Failures...........................................................................................................29 III.1.11. Security................................................................................................................................29 III.1.12. Safety...................................................................................................................................30 III.2. DATA.........................................................................................................................................30 III.2.1. Preliminary Data Definitions................................................................................................30 III.2.2. Capacity Requirements..........................................................................................................31 III.2.3. Access Speed..........................................................................................................................32 III.2.4. Archive Requirements............................................................................................................33 III.2.5. Data Security and Integrity...................................................................................................34 III.3. USER INTERFACES.........................................................................................................................35 III.3.1. General..................................................................................................................................35 III.3.2. Process Monitoring...............................................................................................................39 III.3.3. Batch Management Interfaces...............................................................................................43 III.3.4. Alarm Management Interfaces..............................................................................................44 III.3.5. PCS Status Interface..............................................................................................................47 III.3.6. Programming and Configuration Interfaces.........................................................................47 III.3.7. Recipe Management Interface...............................................................................................48 III.3.8. Reports...................................................................................................................................48


JETT




III.4. REMOTE PCS ACCESS...................................................................................................................48 III.5. INTERFACES WITH OTHER SYSTEMS..................................................................................................49 III.5.1. Intelligent Process Interfaces................................................................................................49 III.5.2. Other Process Control Systems.............................................................................................49 III.5.3. Other Computerized Systems.................................................................................................49 III.5.4. Shared Resources..................................................................................................................49 III.6. ENVIRONMENT..............................................................................................................................49 III.6.1. Layout....................................................................................................................................49 III.6.2. Physical Conditions...............................................................................................................50 IV.0 CONSTRAINTS..............................................................................................................................52 IV.1. PROJECT CONSTRAINTS..................................................................................................................52 IV.1.1. Schedule.................................................................................................................................52 IV.1.2. Procedural Constraints.........................................................................................................52 IV.2. COMPATIBILITY.............................................................................................................................53 IV.2.1. Hardware Standards and Preferences...................................................................................53 IV.2.2. COTS Software Standards and Preferences..........................................................................53 IV.2.3. PCS Configuration and Integration Standards.....................................................................55 IV.2.4. PCS User Interface Standards...............................................................................................56 IV.2.5. PCS Programming Standards...............................................................................................57 IV.3. MAINTENANCE.............................................................................................................................58 V.0 LIFE-CYCLE....................................................................................................................................58 V.1. DEVELOPMENT...............................................................................................................................58 V.2. TESTING.......................................................................................................................................58 V.3. DELIVERY.....................................................................................................................................58 V.3.1. Documentation........................................................................................................................58 V.4. SUPPORT.......................................................................................................................................59 V.4.1. Start-up Support (list available options)................................................................................60 V.4.2. Post Start-up Support (list post-startup support available)...................................................60 VI.0 GLOSSARY.....................................................................................................................................61 VI.1. TERMINOLOGY..............................................................................................................................61 VI.2. ACRONYMS..................................................................................................................................63


JETT




REVISION HISTORY Rev. A1 A2

Date 11/05/02 12/07/02

A3

6/1/03

A4

6/14/04

Approval

REVISION SUMMARY Initial document creation by Mark Tuepker Modifications to more accurately reflect JETT format and content Content Review by Chris Roerig, Paul Coury, Steve Smith, John Liebenthal Content Review by Chris Roerig, Pat Cashman, Andre Powell, Sarah Powell, Michelle Ubele


Page 6 of 65


JETT

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, constraints such 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 this URS are based on the Good Automated Manufacturing Practices (GAMP) Guide available through the International Society for Pharmaceutical Engineering (ISPE). The project role and significance of this document is identified in: θ Once approved, this document will provide a foundation for the development of functional specifications, design specifications, and Performance Qualification testing protocols. Modifications to, and/or deviations from, the specifications in an approved URS are subject to formal change control procedures. The following documents are related to the URS: # 1 2 3

Reference

…

Contains Project Scope and Charter Process design Applicable automation standards …



JETT I.3.



Scope This document begins to define the process control system requirements for: • • • • • • •

Hardware and software platforms Network communication Equipment control Automated process area sequencing Process equipment modeling for Batch management Human Machine Interface (HMI) Electronic data and record storage

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, FDA’s 21 CFR Part 11, ISA S88.01, and policies and procedures. The benefit of meeting or exceeding these key objectives is a profitable manufacturing facility offering flexibility to meet market demand.



JETT I.4.



Document Organization In accordance with the GAMP Guide description of URS contents, the remainder of this document includes the following sections:

# 2

Section Overview

Sub-Section Background Key objectives and benefits Main functions and interfaces Applicable GxP Requirements Other Applicable Regulations

3

Operational Requirements

Functions Data Interfaces: User Interfaces Interfaces: System Interfaces Interfaces: Equipment Interfaces Environment: Layout Environment: Physical Conditions

4

Constraints

Project Constraints Compatibility Maintenance

5

Life Cycle

Development Testing

6

Glossary

Delivery Support Terminology Acronyms

Contains Facility Overview, Project Overview, and Automation Overview General statement of automation constraints. Description of the process control system role. Specific identification of constraining regulatory requirements Specific identification of other constraining regulatory requirements Functions required, calculations, modes of operation, performance and timing requirements, action required in case of failure, safety, security Definition of data, capacity requirements, access speed requirements, archive requirements, data security and integrity User roles/functions and the interface provisions Interface with other automated or computerized systems Interface to sensors and actuators Space(s) provided for automation equipment Physical conditions prevalent in space(s) provided for automation equipment Timescales and milestones, procedural constraints Existing systems, automation strategies, and automation policies Availability, ease of maintenance, expansion capability, likely enhancements, expected lifetime, and long term support Methodologies, project management, and quality assurance Testing strategies, special requirements, and simulations Information related to required supplier deliverables Support required after system acceptance List of document terms and their meanings List of abbreviations and their meanings



JETT II.0



OVERVIEW II.1.

Background II.1.1.

Project Overview

II.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.} II.1.1.2. Key Objectives The key objective is to provide a process control system with the required functionality and flexibility while simultaneously meeting the requirements of ISPE GAMP 4, cGMP, FDA’s 21 CFR Part 11, ISA S88.01, and policies and procedures. The benefit of meeting or exceeding these key objectives is a profitable manufacturing facility offering flexibility to meet market demand. II.1.1.3. Anticipated Benefits The following is a list of the major benefits anticipated from the project: Benefit

Explanation

Increased Capacity Manufacturing Process Change Reduced Product Losses Increased Flexibility Improved Regulatory Compliance Reduced Maintenance Technology Upgrade


Page 10 of 65


JETT

URS, Rev.0


December 7, 2002

II.1.2. Facility Overview The 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.} M

a t e

r ia

l H

a n

R

e c e

iv in g

a r e

h

o u

r e

w

e

ig h

W

F

I

f f e

r

d lin g

U W P

B

M

a

u S

h

ip p

n

u

f a

R

e R

C

e C

W

a T

R

e

P

in g

g

T

E

W

In s t r u m a s t e

S t e a m a t e r

e n t H

R R

a

g

e

C

n

kW

e a c to r 2 0 0

x i s t i n g

C

P

e n tr if u g e C 2 0 0 a s h T a n k T 2 0 0

TR a e nc ek i v i n g T 2 0 1

N

e

w

A

ir

a n d lin g

r Mi n a g n u C f a e c lt lu Ar i n g

n t r if u 1 0 0 s h 1 0 0

P u r ity

h il l e d

W

r

c e iv in 1 0 1

T

ig h

r e p

c t o 0

0

H C

c t u

a 1

t i li t i e s

s e

e ll B

a

c k a

g

in g

A

P

r e p

a

B

o

B

o t t lin g

L

in e

A

B

o t t lin g

L

in e

B

a r t o

n in g

T a n k

M

C

t t le

r e

o

d

i f i e

d


A

A

JETT




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


Page 12 of 65


JETT

URS, Rev.0


December 7, 2002

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

C

o r e

M

D

R

S

P

y s t e m

S

s

y s t e m

o c u m e n t M S y s t e m

M

W

e g u la t e d

S y s t e m

s

a t e r i a l H a n dP l ri no g c e s s S y s t e m s

A

u t o m

a r e h o u s e S y s t e m

M

a n a gM e a m n e u nf at c t u r i n g P r o c e s s C o n t r o l

a n a g eP mr e e w n e t i g h

M

E

P

S

r o c e s s

H

S

y s t e m

S

B u a t c B u il d i n g M a n a g e m e n t S y s t e m M a n u P r o c e is t o r ia n M a n u P r o c e B

L IM

a t io n

ff e r P r e p h in g S t a tio n s f a c t u r in g C e ll A s s C o n t r o l S y s t e m f a c t u r in g C e ll B s s C o n t r o l S y s t e m

U t ilit ie s r o c e s s C

P

H S

ig h k id

o n t r o l

P u r ity S t e a m C o n t r o lle r

C h il l e d W a t e r S k id C o n t r o lle r

P

E

x i s t i n g

N

e

w

M

o

d

W F r o c e s s

i f i e

I C

d


o n t r o l S

y s t e m

s

JETT




II.1.3.1. Existing Systems II.1.3.2. New Systems II.1.3.3. Modifications to Existing Systems



JETT 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 the cGMP portion of the to: • • • • •

II.3.

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

Simulation System The PCS vendor scope includes the hardware and packaged software necessary to configure and support an independent Simulation System. The Simulation System shall be initially installed at the vendor site and utilized for the development and factory testing of the application software. When the application software 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 and enhancement activities.

II.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 initial implementation of select batch capabilities, favoring a high level of manual process interaction by operating personnel, supported by Standard Operation Procedure (SOP) driven paper system(s). This initial operating philosophy does not imply that future enhancement(s) will not take greater advantage of the capabilities provided by the PCS, but does significantly impact functions commonly associated with a S88.01 batch facility. The PCS functionality is limited as follows: •

Implemented procedures pertain exclusively to CIP and SIP functions. All other sequential functionality required is implemented at the unit phase level. Manufacturing operations will be performed by manually initiating equipment phases as required. Additionally, prior to initiating a phase, the operator may be required to manually perform any set-up required such as: verifying/placing all process unit valves in automatic mode, verifying/placing all control modules are in automatic mode, etc.



JETT

Process Control System •


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

In lieu of PCS implementation, SOP driven, manual paper system(s), are used to perform the following functions: •

• •

Tracking process equipment “fitness for use” for a specific function (such as “Clean”, “Sterile”, “Full”, “Empty”, etc.), as well as equipment sterility expiration. When a PCS phase/procedure is initiated by an operator, it is the operator’s responsibility, supported via manual paper systems, to ensure the subject process equipment is suitable for the PCS phase or procedure application. The PCS ensures that the subject process equipment is available and not currently in-use by another phase/procedure. The PCS equipment model only maintains process unit statuses of “In-Use” or “Available”. Additional statuses or states pertaining to a unit’s fitness for use are not required. Material tracking, including all batch/lot material and intermediate product genealogy tracking. Batch/lot tracking, including batch/lot reporting. PCS-generated “electronic tickets” and automated batch reports are not required. Additionally, PCS is not required to maintain or track unique batch identifiers. Lot Identifiers and Product Codes are manually input to the PCS at appropriate process intervals and utilized for historical data record retention as key fields.



JETT III.0



OPERATIONAL REQUIREMENTS III.1. Functions III.1.1.

Process Monitoring

III.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 real time, the known state of the process. Control strategy algorithms produce process control outputs that are also combined into the logical database to complete the process state definition. Design of PCS data collection features shall consider all of the following: Factor

Description

Required immediacy

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

Required precision

Insignificant digits should not be presented to users, historically collected, or considered in data processing.

Data consistency

In some component systems, communication delays may introduce transient and/or scan-based differences in data values. Data collection design must prevent inconsistent display, control response, and historical collection of alarm and other threshold events. The design must also avoid other data collection and communication mechanisms that could result in sustained inaccuracies between display data, historical data, and control processing data.

Future expansion and/or enhancement

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



JETT



Factor

Description

Fault tolerance

The PCS must be designed to prevent any individual failure from jeopardizing personnel safety and/or product quality. Where PCS features are instrumental in protecting personnel and/or product quality and/or major processing equipment, a Failure Modes and Effects Analysis (or comparable risk assessment) is required.

III.1.1.2. Basic Data Processing All data monitored by the PCS shall be immediately converted to standard engineering units prior to use in any comparison or control logic. This conversion should also include normalization of discrete data values (e.g., so that “1” always represents the “alarm” state for a discrete input alarm and the “open” state for a valve). Process control outputs should undergo similar conversions immediately prior to transmittal. III.1.1.3. Process Alarm Detection Process alarm detection functionality compares data values against range and alarm limits. Range errors and alarms should be propagated, as appropriate, to subsequent data processing logic. All non-discrete dynamic system inputs automatically monitored by the PCS should be subjected to both range checking and appropriate alarm checking. All non-discrete manual system inputs should also be subjected to range checking. Outof-range manual data entries should be rejected (with an appropriate message explaining why the value was rejected) and/or treated as a process alarm (i.e., annunciated and subjected to alarm management functions), as appropriate. All manual entries, including rejected entries, should be recorded in PCS event logs, if practicable. III.1.2.

Alarm Management

III.1.2.1. Alarm Configuration The PCS must provide for configuration of alarms to detect unexpected process excursions for operator notification and /or response. Two basic types of alarms must be supported by the PCS, process alarms and equipment alarms. Process alarms differ from equipment alarms in that their parameters such as, setpoint, time delay, deadband, etc must be modifiable during progression of a batch process on a per step basis from the phase logic. Equipment alarm parameters are tuned to meet the specific equipment requirements and once set, are only modified if physical changes occur to the equipment. Both types are subjected to the alarm management requirements described in this section. The “Locally Controlled Packaged Equipment” section discusses the operator interface with vendor provided control system(s) on packaged equipment. Alarms originating within these vendor provided control system(s), but displayed on PCS screens, are also subject to the alarm management requirements as described within this section.



JETT



The system shall provide for process alarm priorities, a minimum of five levels, which are selectable during configuration. At least one of the priority levels will represent alarms that affect the quality of the batch (GMP alarm level). Other alarm priorities will be assigned to equipment protection, personnel safety and operator information. The S88 concept of process units, grouped in plant cells and areas will allow for alarm enable/disable of those groupings (e.g. during maintenance, shutdown etc.). Additionally, it will also be possible to suppress temporarily (override), with proper authority, an individual alarm caused by a defective device. Operator alarm override actions will be recorded by the system and will automatically be reset at the beginning of each controller resident phase. The system shall support the following configuration parameters for each alarm • • • • •

•

Type of Alarm – Absolute alarm, Offset from Setpoint, Percent Offset from Setpoint. Alarm Setpoints for low-low, low, high and high-high severity levels Alarm Priority – minimum of five levels definable during configuration Alarm Delay - time delay of alarm conditions to eliminate alarms associated with momentary measurement spikes (e.g., an alarm condition must exist for 5 seconds before activating an alarm). Alarm Deadband – the ability to configure an alarm to turn on at one value and clear at another Ramp setpoints and configure alarms as setpoint +/tolerance. This helps minimize nuisance alarms associated with normal control loop setpoint changes. Pause Enable – Configurable ability for alarm activation to cause running batch logic to pause. Note alarm point must be directly associated with a process unit.

III.1.2.2. Alarm Acknowledgement Operators must be logged on to the PCS and have the proper authority as enforced by PCS security to acknowledge alarms. The PCS shall record in the operator action log all acknowledgement activities. The operator’s electronic signature, the action taken, date and time must be recorded with each acknowledgement. The PCS shall support two means for operators to acknowledge alarms, on an individual basis, and on a group basis. The group shall be all current unacknowledged alarms displayed on the alarm list. Note that group acknowledgement shall result in an entry in the operator action log for each individual alarm. III.1.2.3. Alarm Output devices The system shall support the following output devices. System configuration shall allow for changes in alarm states to activate any combination of the devices: • • •

Console screen (visual) Console screen (audible) Control room or plant floor flashing light and/or horn



JETT

Process Control System • • III.1.3.


Alarm printer Annunciator panels Basic Control

III.1.3.1. Concept Basic control consists of algorithms performed on monitored data values (including process control inputs, user inputs, tunable parameters, and constants) to determine the state of process control outputs. Included in basic control are normal control module algorithms (valve control, pump control, feedback loop control, etc.) and interlocking. Basic control is intended to be completely independent of the intended use of the process equipment. This provides the flexibility to permit manual operations that may: • • • •

Not have been anticipated during the process and/or control system design, Require some level of operator protection (alarms, interlocks, etc.), Require documented evidence of what was done, and/or Require some level of automation (input scaling, closed-loop control, etc.).

III.1.3.2. Control Modules A control module is a regulating device, a state-oriented device, or a combination of regulating and state oriented devices that is operated as a single device. Examples of control modules include block valves, modulating valves, PID controllers, fixed-speed motors, and variable speed motors. Design of PCS control modules shall consider all of the following: Factor

Description

Commonality and consistency

All control modules should be instantiated from a limited number of control module classes. Uncommon control module attributes (e.g., reverse-acting limit switch) should be transparent to PCS users where appropriate.

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



JETT



Factor

Description

Control request management

Control modules should be designed to seamlessly accept, and respond appropriately to, mode, state, and setpoint requests from: • User interface(s) (including local control stations), • Supervisory processes (e.g., phases), and • Interlocks. Control module interfaces should, where possible, clearly identify the current state, the current mode, and the source of active control. Invalid user inputs should, where possible, produce a message identifying the reason the input will not be processed.

Bumpless transfer

Control module mode changes should not cause an immediate corresponding change in control module state, setpoint, or output.

Fault annunciation and response

Every unexpected combination of I/O states (and/or values) should result in a specific failure alarm (e.g., “valve uuu-XV-iiii failed to open”). Control module fault response should be designed to mitigate risk to personnel, product, and equipment.

Control modules may be subordinate to supervisory objects including complex modules (e.g., header or dispensing system) and phases. Mode changes and faults in subordinate control modules Harmony with shall either: supervisory control • Propagate the mode or fault to the supervisory object, or • Override the subordinate mode and/or fault monitoring and comprehensively replace it with mode and/or fault monitoring by the supervisory object.

Data utilization

All relevant data (I/O, user requests, parameters, etc.) shall be appropriately considered by the control module algorithms. For example, if a block valve includes both an Open limit switch and a Closed limit switch, the state of both switches should be considered in determining the actual state of the valve.

Harmony with simulation

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

III.1.3.3. Interlocks Interlocks modify control module states in response to process conditions in order to protect personnel, process equipment, and/or product. Design of PCS interlocks shall consider all of the following:



JETT



Factor

Description

Product independence

Interlock functionality should not consider current product processing requirements. In general, interlocks should only be applied for personnel protection, equipment protection, and/or prevention of product contamination.

Control modules may be subordinate to supervisory objects including complex modules (e.g., header or dispensing system) and phases. Interlocks in subordinate control modules shall either: Harmony with • Propagate the interlock to the supervisory object, or supervisory control • Disable (fault) the supervisory object, or • Override the subordinate interlock and replace it with a complimentary interlock and/or fault monitoring by the supervisory object. Overrides

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

Display

Control module interfaces should, where possible, clearly identify whether or not a control module interlock is active. The specific cause of the interlock should be either displayed as part of the control module interface and/or readily accessible from the control module interface.

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

III.1.3.4. Complex Modules Complex modules include control modules with subordinate control modules and equipment modules with subordinate equipment modules and/or control modules. Common complex modules include: •

Header valve groups (where the complex module setpoint identifies a transfer source, a transfer destination, or a source-destination pair) • Batch dispense stations (including a flow control valve, a totalizer, and one or more block valves) • Temperature control module (where media routing valves are controlled based on a desired vessel jacket state or temperature setpoint) NOTE: Complex Modules are differentiated from Equipment Phases which are controlled through the Batch Manager interface. A complex module is an independent object that can be utilized with and/or without the Batch Manager. PCS design need only include complex modules if routine non-automatic production is anticipated and manual equipment phase control is too cumbersome for this routine non-automatic production. Design of PCS complex modules shall consider all of the following:



JETT



Factor

Description

Commonality and consistency

All complex modules should be instantiated from a limited number of complex module classes. Uncommon complex module attributes (e.g., extra routing valves) should be transparent to PCS users where appropriate.

Class attributes

Each complex module class should have a specific and well-defined set of attributes. Typical attributes include: • Setpoint (Vxxxx-Vyyyy, charge, jacket control, etc.), • State (Vxxxx-Vyyyy, charge, jacket control, etc.), • Requested Mode (manual, automatic, etc.) • Mode (manual, automatic, etc.), and • Fault (failed to start, deviation from setpoint, etc.).

Control request management

Complex modules should be designed to seamlessly accept, and respond appropriately to, mode, state, and setpoint requests from: • User interface(s) (including local control stations), • Supervisory processes (e.g., phases), and • Interlocks. Complex module interfaces should, where possible, clearly identify the current state, the current mode, and the source of active control. Invalid user inputs should, where possible, produce a message identifying the reason the input will not be processed.

Bumpless transfer

Complex module mode changes should not cause an immediate corresponding change in complex module state, setpoint, or output.

Fault annunciation and response

Every unexpected combination of control module states (and/or values) should result in a specific failure alarm (e.g., “valve uuuXV-iiii failed to open”). Complex module fault response should be designed to mitigate risk to personnel, product quality, and process equipment.

Mode changes and faults in complex modules that are subordinate to a phase shall either: Harmony with • Propagate the mode or fault to the phase, or supervisory phases • Override the subordinate mode and/or fault monitoring and comprehensively replace it with mode and/or fault monitoring at the phase level. Harmony with simulation

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



JETT

Process Control System 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 sequential control intended to exploit a specific processing capability of the equipment. The following principles should guide the identification of equipment phases: • • • •

Equipment phases should be based on process equipment capability and should in no way be product-specific, Equipment phases should operate autonomously, except as necessary to coordinate material transfers or other multi-unit activities, Equipment phases should not share control modules with other equipment phases except where necessitated by process equipment design, and Shared equipment phases and shared control modules should not unnecessarily restrict or otherwise interfere with parallel activities.

III.1.4.2. Normal Operation Once initiated, an equipment phase typically initiates appropriate monitoring (e.g., fault detection) and proceeds through an orderly sequence of steps. The quantity and identity of steps should be sufficient to clearly distinguish the equipment phase progress and to support orderly restart logic. If general, successful equipment phase operation should not be contingent upon: • • • •

The execution of previous equipment phases, or The execution of parallel equipment phases (except as needed for product transfers), or The execution of subsequent equipment phases, or The anticipated state or status of uncontrolled equipment.

III.1.4.3. Exception Handling Equipment phase exception handling should respond, as appropriate, to controlled equipment alarms, interlocks, and faults, unexpected process deviations, invalid parameter values, communication faults, and user intervention commands. Exception handling should be sufficiently “exception-specific” in order to provide the least intrusive response that still provides adequate personnel, equipment, and product protection. For example, a product temperature deviation should not necessarily disable automatic temperature control. Equipment phase exception handling should be sufficiently robust that: • •

Direct and immediate actions are taken to ameliorate any condition that jeopardizes personnel, equipment, or product, Exception handling actions are appropriate to both the type of exception and the progress of the equipment phase sequence at the time of the exception,



JETT

Process Control System • • • •


Equipment phase execution is not interrupted by minor anomalies that are unlikely to jeopardize personnel, equipment, or product (though operator notification of all anomalies is generally required), The response of concurrently executing equipment phases is appropriately impacted to preserve the integrity of a Unit Operation, The equipment phase, and associated Unit Operation, can be restarted by an operator with a minimum of extraordinary manual restart preparations (e.g., by simply commanding the Unit Operation to restart), and Restarting an equipment phase, and associated Unit Operation, should automatically resume manufacturing operations without unnecessarily repeating steps or extending execution times (e.g., by unnecessarily resetting totalizers, counters and timers).

III.1.5. Batch Management The automation solution includes both the PCS and a batch management system. The PCS shall be implemented within the framework of the Instrument Society of America (ISA) standards S88.01, Standard for Batch Models and Terminology, and draft standard dS95.01, Standard for Enterprise – Control System Integration Models and Terminology. The use of these standards supports application of industry standard software packages and provides for flexibility and modularity required by the business and automation objectives. The S88.01 control activity model defines the following activities • • • • • •

Production Planning and Scheduling Information Management Recipe Management Process Management. Unit Supervision and Process Control

The focus of this PCS is the Process Control activities defined by the S88 Standard. This section defines the interface requirements for the PCS to the Unit Supervision, Process Management and Recipe Management activities implemented by the Batch Management System as well as the required operator interfaces to these control activities. The Batch Manager Interface (BMI) is required to: • • • •

Provide an operator interface for manual control of batch state transitions Report status for equipment procedural logic elements used as a part of recipe execution Provide download and upload capability for recipe parameters Provide for PCS ad hoc event reporting to the Batch Manager.



JETT

Process Control System 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 historical database. Since these data are important electronic records, the PCS should employ appropriate provisions for secure data collection and retention (e.g., automatic daily backup, disaster recover provisions, long-term data archiving and restoration procedures, etc). Existing site database facilities, capabilities, and procedures should be exploited, if possible. Historical data shall be accessible for display in historical trends and, as applicable, reports. III.1.6.2. Alarms and Events Process alarm and event data shall be accumulated in a historical database. Each record shall include a date/time stamp, Batch/Lot identifier and the source process unit as the primary keys for data retrieval. Since these data are important electronic records, the PCS should employ appropriate provisions for secure data collection and retention (e.g., automatic daily backup, disaster recover provisions, long-term data archiving and restoration procedures, etc). Existing site database facilities, capabilities, and procedures should be exploited, if possible. Historical alarm and event data shall be accessible for inclusion in onscreen displays and, as applicable, reports. III.1.7.

Other Monitoring and Control Features

III.1.7.1. Locally Controlled Packaged Equipment Select process equipment is packaged in a stand-alone configuration that includes sufficient local control capability to perform the intended functionality. These packaged systems are designed to include the necessary interface capability to permit communication with the PCS. It is the responsibility of the System Integrator to coordinate with the packaged equipment vendor(s) to determine the appropriate PCS control strategy, general interface requirements, etc. Where practicable, PCS interface to packaged equipment should follow S88 paradigms (e.g., by treating the packaged equipment operation as an equipment phase). III.1.7.2. Resource Management Modes, states, statuses, and other attributes of all process resources (including process units, bulk material supplies, logical modules such as totalizers, etc.) should be clearly defined and appropriately managed. User interfaces to these process resources should provide for attribute monitoring and, with appropriate security, manual adjustment. Managed resource attributes (e.g., bulk material supply “Ready” status and process unit “Clean” status) should be considered in Basic Control interlocks and Equipment Phase exception handling, as appropriate.



JETT



III.1.7.3. Engineering Parameters In general, hard-coded values related to both Basic Control and Equipment Phase Control should be scrupulously avoided. Instead, tunable variables and/or constants should be identified, initialized, and used throughout the control logic. Examples of tunable variables and/or constants, referred to generally as “Engineering Parameters”, include: • • • • • III.1.8.

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). Modes of Operation

III.1.8.1. Startup System documentation shall include detailed procedures for starting the PCS (in total) and for starting individual PCS components, as appropriate. On startup, the PCS shall maintain controlled process equipment in its pre-defined safe (typically de-energized) state until specific user commands are applied to begin process control. To the extent possible, PCS event log(s) shall record events indicating the startup of PCS components. The ability to restart the PCS components after an abnormal shutdown (e.g., power interruptions) shall, in general, be available to any user with a valid PCS user account. III.1.8.2. Shutdown System documentation shall include a detailed procedure for performing a controlled and complete shutdown of the PCS. PCS shutdown shall cause controlled process equipment to revert to a pre-defined safe (typically de-energized) state. The ability to shutdown the PCS shall be restricted to Supervisors, System Administrators, Engineering, and Maintenance personnel. PCS event log(s) and/or alarm log(s) shall indicate the normal shutdown of any PCS component. Where possible, PCS event log(s) and/or alarm log(s) shall indicate abnormal PCS component shutdowns (e.g., power interruptions). III.1.8.3. Normal Operation On PCS restart according to the PCS startup procedure(s), normal operation shall be enabled. System documentation shall include detailed procedures for normal PCS operation (e.g., display elements and navigation, starting batches, using control modules, etc.). The ability to perform normal PCS operations shall be based on privileges associated with the user’s account.



JETT



III.1.8.4. Simulation The PCS shall include process simulation capability including: •

The ability to temporarily force any discrete or analog input to any valid value, and • The ability to set individual control modules feedback simulation to “autorespond” to control module states (e.g., Open feedback energizes and closed feedback de-energizes whenever the valve stat is OPEN). The ability to enable simulation shall be restricted to Supervisors, System Administrators, Engineering, and Maintenance personnel. PCS event log(s) and/or alarm log(s) shall indicate transitions to/from simulation mode. III.1.8.5. Disaster Recovery System documentation shall include detailed procedures for a complete re-install of software on each PCS component. These procedures shall include sufficient detail to completely re-build the PCS from purchased hardware and archived software. Independent electronic copies of all software required to re-build the PCS shall be supplied with the PCS. III.1.9.

Performance and Timing

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



JETT

Process Control System Activity/Event


Performance Expectation

PCS control responses (e.g., PID controller output change in response to a deviation from setpoint) should be commensurate with Regulatory Process the potential significance of the process change. For example: Monitoring and • Slow-moving regulatory response (e.g., vessel temperature Basic Control control) should occur within five (5) seconds. Response • Fast-moving regulatory response (e.g., line pressure control) should occur within one (1) second.

Process Input Display

PCS display of process condition changes should be commensurate with the potential significance of the process change. For example: • All changes in process conditions (i.e., instrument readings and discrete feedback states) should be reflected in PCS displays within five (5) seconds. • For process conditions that can exhibit rapid and significant changes (e.g., pressure and flow readings, vessel rupture disks), changes should be reflected in PCS displays within two (2) seconds.

User Control Command

Evidence of PCS response to user commands (e.g., changing control module states, starting a batch) should be presented to the user within one (1) second (e.g., by changing a “commanded state” indication). Process control response to user commands should be commensurate with the potential significance of the requested change. For example: • A valid user command to start a batch should activate the first equipment phase within ten (10) seconds. • A valid user command to change the state of a control module should change the appropriate control output within two (2) seconds.

Evidence of PCS response to a user command to change displays should be presented to the user within one (1) second. The target Display Navigation display should be completely painted, with up-to-date data values, within five (5) seconds. Workstation Synchronization

When a process attribute is changed from one workstation, the attribute change must be reflected on other workstation displays. Such attribute changes should be reflected on all workstations within three (3) seconds.

PCS Startup

In general, it should be possible to bring the PCS from a deenergized state to a full working state within fifteen (15) minutes.

PCS Shutdown

In general, it should be possible to bring the PCS from a full working state to a fully de-energized state in a controlled manner within fifteen (15) minutes.


JETT




III.1.9.2. Date and Time The PCS shall be designed to minimize and, as necessary, compensate for differences in date and time values among PCS components. The following is a description of the recommended date/time compensation procedure for a networked PCS: A single “timekeeper node” shall be designated for the PCS. The date/time value for the timekeeper node will be periodically reconciled to a known accurate date/time source. Timekeeper node date/time value should not normally deviate from the known accurate date/time source value by more than ten (10) seconds between periodic reconciliations. If manual intervention is required to reconcile the timekeeper node date/time value, reconciliations should not be required more frequently than once per week. PCS nodes that base any activity, log, or display on the local date/time value should automatically (i.e., without user intervention) reconcile their date/time value with the timekeeper node date/time value periodically (typically once per day). Node date/time values should not normally deviate from the timekeeper node date/time value by more than ten (10) seconds between periodic reconciliations. All date/time reconciliations (including the timekeeper node reconciliation) shall be recorded in the PCS event log(s) in a way that allows determination of the pre-reconciliation date/time value offset. III.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. 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. III.1.11. Security All PCS components and networks shall be designed to protect against deliberate and/or accidental activities that could potentially compromise personnel, product, equipment, and electronic records. Physical controls should include protection of all PCS components (through locking individual enclosures and/or through isolation in protected areas such as locked rooms) from reasonable attempts to disrupt or modify the component. Logical controls should include user authentication for any process control or PCS modification activity. Refer to the User Interfaces section for additional descriptions related to logical PCS controls.



JETT



III.1.12. Safety The PCS must be designed to both mitigate process hazards and to prevent introduction of any new hazards related to the PCS components. The following process hazards should be considered in PCS design: Process Hazard

Description

The following PCS component hazards should be considered in PCS design: PCS Hazard

Description

Repetitive Stress Injury

Components that require routine use (e.g., user interface hardware) should be ergonomically designed. All PCS components should allow for easy access to facilitate cleaning, preventive maintenance, and replacement.

Electrical

PCS equipment should comply with site electrical and construction standards including appropriate grounding and fusing.

Explosive

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

Tripping

PCS equipment should not block normal entry and egress pathways or other personnel traffic areas.

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



JETT



•

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 the “additional preliminary data” listed above represents preliminary functional and/or design specifications. If practicable, development and publication of these items should be reserved for the Functional Specification and/or Design Specification documentation.} III.2.2. Capacity Requirements Hardware and software selection should allow for some expansion without additional hardware or software purchase. Hardware and software selection should allow for significant future PCS expansion and/or extension with the purchase of additional hardware and/or software. The following capacity constraints are recommended:



JETT



Feature

Capacity

Process Inputs and Outputs

At least 10% installed spare capacity should be provided for each I/O type (discrete inputs, discrete outputs, analog inputs, analog outputs, etc.). At least 25% total spare space should be available for installation of additional I/O (i.e., additional wiring, terminals, and I/O modules) without the need for additional conduits or cabinets. Theoretical ability to expand the scope of the PCS by at least 50% (e.g., through addition of cabinets, processors, etc.) should be provided.

Processing Power

No more than 50% of the processing capacity of PCS components should be required to provide normal processing and display functionality with satisfactory performance.

Memory

No more than 50% of the installed physical memory in PCS components should be required to provide normal processing and display functionality.

Local Electronic Storage

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

Historical and Archive Storage

Historical data storage capacity should allow for online retrieval of at least 30 days of any historical data. Archive data storage should be adequate to fulfill current electronic record retention requirements with at least 25% spare capacity.

User Interfaces

The PCS should have the ability to expand user interfaces (workstations and/or displays) by at least 25% without deviating from the fundamental PCS architecture.

III.2.3.

Access Speed

III.2.3.1. Real-time Data Access to real-time data, via workstation displays, is a primary function of the PCS. Refer to the “Functions - Performance and Timing” subsection for a description of performance expectations including input display and workstation synchronization features. III.2.3.2. Online Historical Data PCS historical data includes all of the following: • • •

Time-sequenced instrument readings and other process-related analog values, Alarm and event logs, and Batch event and data records.



JETT



Online user interfaces to PCS historical data includes all of the following: • • •

Time-sequenced trending of analog values, Query-driven display of alarm, event, and batch records, and Pre-configured reports.

Access to online (i.e., not yet archived) historical data should be optimized for efficient retrieval. However, no specific access speed specification is applicable due to the diverse nature of potential queries. Instead, the following interface guidelines are recommended: • • •

For data retrieval that could take more than ten (10) seconds, an on-screen “in progress” indication should be provided. For data retrieval that could take more than twenty (20) seconds, an ability to cancel the query should be provided. For data retrieval that could take more than thirty (30) seconds, a rough progress indicator (e.g., percent complete bar graph) should be provided.

III.2.3.3. Archived Historical Data Access to archived historical data should also be optimized for efficient retrieval. Since archiving and retrieval mechanisms vary, no specific access speed specification is applicable. In general, access to archived data in a specific format (report, chart, or restoration to “online status”) should not require more than one (1) calendar day. III.2.4. Archive Requirements PCS historical data retention capabilities must conform to site and/or product data retention requirements. In general, all PCS historical data (including time-sequenced analog values, alarm, event, and batch logs) should be accessible for at least ten (10) years. Any robust archiving technology is acceptable, however, existing site archiving facilities, technologies, and procedures should be exploited if possible. Archive system design should consider the potential for having to migrate the historical data so that access can be preserved beyond the point of PCS de-commissioning. PCS system manuals must include detailed procedures for committing historical data to archive and for retrieving historical data from archive. Retrieved historical data must include any and all data that was, or may have been, considered for verifying manufacturing and/or product quality. Retrieved data context, format, and/or access must be identical to, or at least comparable to, original data context, formats, and/or access. The PCS must provide the ability to retrieve archived data without interrupting ongoing process operations.



JETT



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

PCS Compliance Feature(s)

System Validation

PCS development lifecycle and documentation must be adequate to support system validation. This should include a specifications traceability matrix and/or similar quality control mechanisms.

Copying Records

PCS manuals should include detailed procedures for generating accurate and complete copies of records in both human readable and electronic form.

Protection through Retention Period

Refer to the “Data - Archive Requirements” subsection of this document.

Limiting System Access

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

Audit Trails

All PCS historical records shall use secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information.

PCS specification documentation shall clearly identify permitted Operational System sequencing of steps and events that must be enforced, if any. The Checks PCS must be designed to enforce this sequencing, as appropriate. Authority Checks

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

Device Checks

PCS specification documentation shall clearly identify restrictions to valid sources of data input or operational instruction, if any. The PCS must be designed to enforce these restrictions, as appropriate.

Training

Project documentation must identify minimum qualifications (experience and training) for PCS developers. Each PCS developer’s qualifications must be vetted against these requirements. Developer resumes, or similar certificates of qualification, must be included in project and/or PCS documentation.

System Documentation Controls

System operation and maintenance documentation must be included with the PCS. Distribution of, access to, and use of this documentation must be adequately controlled and subject to revision and change control procedures that maintain an audit trail that documents time-sequenced development and modification of systems documentation.



JETT



Part 11 Control

PCS Compliance Feature(s)

Open System Controls

Systems with any component(s) that are not installed in an environment in which system access is controlled by persons responsible for the content of electronic records that are on the system are considered “Open Systems”. Open systems must include controls to ensure the authenticity and integrity of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include additional measures such as document encryption and use of appropriate digital signature standards.

III.3. User Interfaces III.3.1.

General

III.3.1.1. User Interface Design User Interfaces are designed to facilitate both general process awareness and specific PCS tasks. The following table outlines the specific tasks accommodated by PCS user interface features: Task

Description

Features designed to provide a rapid and accurate assessment of the status of the entire process within the scope of PCS control. Process Monitoring: Overview displays typically display key module states and/or Overview measurements for a process cell, or a portion of a process cell, in a graphical format. Features designed to provide structured access to the primary Process Monitoring: state(s) and values for all modules and/or measurements. Unit Unit displays typically present modules related to a single process unit and/or ancillary equipment in a graphical format. Features designed to provide structured access to all important attributes (including identification, modes, states, setpoints, values, Process Monitoring: etc.) of an individual module and/or instrument. Detailed process Detail monitoring is commonly provided through onscreen popups that mimic traditional analog instrument faceplates. Features designed to display historical and/or statistical information Process Monitoring: to users. These typically include a historical trend display and, for Analytical discrete manufacturing, one or more Statistical Process Control displays.



JETT



Task

Description

Process Control: Detailed

Features that allow users to manipulate process control elements (e.g., by changing control module modes, states, etc.). Process control is commonly provided as part of the process monitoring detail interface features.

Process Control: Batch Management

Features that provide for monitoring and control of recipe execution. Batch management features typically include screens for batch initiation, resource arbitration, batch monitoring, user prompts/responses, individual phase control, alarms, and reports.

Supervisory Functions

Features, protected from operator access, designed to provide extraordinary process and batch management controls. Protected supervisory capabilities may include overriding interlocks, modifying batch execution, temporarily modifying engineering parameters, workstation shutdown, etc.

Features designed to notify user of monitored alarms, allow Alarm Management acknowledgement of those alarms, provide a record of alarmrelated events, and display summaries and histories of alarms. PCS Analysis

Features designed to display the status of the Process Control System components.

Reports

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

Programming and Configuration

Features provided to allow for future modification of application configuration and/or source code. These typically include access to the primary operating system interface(s) and employ strict user access controls to help enforce adherence to change control procedures.

Recipe Management

Features provided to allow for creation, modification, and deletion of process recipes.

III.3.1.2. User Interface Hardware User Interface hardware may include computer terminals, panel-mounted interface equipment (push-buttons, signal/status lights, hand switches, etc.), tower lights, horns, message displays, and printers. User interface hardware locations are intended to provide users ready access to the PCS in close proximity to the process operation or process equipment of interest. Hardware and/or enclosures must be suitable to the installation environment (refer to the “Environment - Physical Conditions” subsection for details). User Interface hardware fault-tolerance features must be appropriate to the hardware function. Where possible, hardware failure alerts should be integrated with the user interface in a way that allows for appropriate response and maintenance.



JETT



III.3.1.3. Security All PCS user interfaces must be designed to control user access. Access controls must be consistent with 21 CFR Part 11 requirements for protection of computer systems that employ electronic records and electronic signatures. These include (but are not limited to) the following: •

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


JETT




With proper authority, all PCS operating displays should be accessible from any PCS workstation. Security features should be capable of limiting workstation functionality according to the following user characteristics: 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 Navigation Display navigation design should provide easy access to all user interface features. The following navigation characteristics should be provided: Navigation Attribute Display navigation should be limited, as appropriate, based on the workstation role and/or user login. Navigation from any display to any other display should not require more than four (4) keystrokes or pointing device “clicks” (excluding login). A hierarchical menu system (e.g., in “site map” format and/or dropdown list) should be provided. Process displays should provide single keystroke/click navigation to this menu system. Off-screen connectors to/from a process display should include single keystroke/click navigation to the appropriate source/destination display. Process displays should provide single keystroke/click navigation to detail displays related to objects shown on the display (e.g., overview to unit and unit to faceplate). Process displays should provide single keystroke/click navigation to the previously viewed display(s) (e.g., a “Back” button). Process displays should provide single keystroke/click navigation to upstream and downstream process displays according to a comprehensive sequence, or sequences, of process displays. Process displays should provide single keystroke/click navigation to alarm management display(s). Process Unit displays should provide single keystroke/click navigation to real-time and/or historical trend display(s).



JETT



Navigation Attribute Process detail displays (i.e., faceplates) should provide single keystroke/click navigation to real-time and/or historical trend display(s). Process displays should provide single keystroke/click navigation to batch management display(s). Batch management displays should provide single keystroke/click navigation to associated process display(s). Display navigation (excluding login) should not require keyboard keystrokes (i.e., pointing device motion and clicks should be sufficient for navigation). Display navigation should not require use of a pointing device (i.e., keyboard keystrokes should be sufficient for navigation).

III.3.2.

Process Monitoring

III.3.2.1. Common Display Features The following display elements must be included on all full-screen PCS process monitoring displays in a consistent location or screen area: • • • • • • • •

PCS Identification, Display title, Display filename or other Display Identification (if appropriate), Current Date (DD-MMM-YY format), Current Time (HH:MM:SS format, 24 hour military time, local time zone), Indications (preferably counts) of active and unacknowledged alarms, Indication of active simulation or similar unusual system mode(s), Common navigation and control features (e.g., “home” button, “back” button, “print” button, pull-down menus)

The PCS must be capable of capturing and printing a “live color snapshot” of all process monitoring displays. III.3.2.2. Process Overview Displays Process overview displays provide discrete icons or symbols for each process unit or ancillary system subordinate to the overview. Every process unit and ancillary system within the scope of the PCS should be included on one and only one overview display. Where multiple process overview displays are required to represent the entire scope of the PCS, process overview displays should be linked by a “rapid navigation” capability.



JETT



Process overview displays should be logically organized and, if necessary, logically subdivided. Organization may be based on product flow path, physical equipment layout, operating areas, functional classes, or some combination of the above. The following are display elements typically included on process overview displays: • • • • • •

Common process monitoring display features, as previously identified, Process unit and ancillary system icons or symbols, “Rapid navigation” capability to each subordinate process unit and ancillary system display, Representation of primary product flow path, Graphical and/or text representation of key instrument readings (e.g., level, flow, temperature, etc.), and Graphical and/or text representation of key resource attributes (e.g., process unit states, assigned batch IDs, operational modes, etc.).

III.3.2.3. Process Unit Displays Process unit displays are typically associated with a single process unit or ancillary system (e.g., headers, bulk material systems, shared equipment, etc.). These displays provide discrete dynamic icons, symbols, and/or text representations for each subordinate equipment module, control module, and other key dynamic process attributes. Every equipment module, control module, and key dynamic process attribute within the scope of the PCS should be included on a process unit display. With the possible exception of shared modules, every equipment module, control module, and key dynamic process attribute within the scope of the PCS should be included on only one process unit display. Where multiple process unit displays are required to represent a single process unit or ancillary system, the displays should be linked by a “rapid navigation” capability. A “rapid navigation” capability should also be provided to the following: •

Related process unit displays (e.g., upstream units, downstream units, and supporting utilities), • Encompassing process overview display, and • Subordinate process detail displays. Process unit displays should be logically organized and, if necessary, logically subdivided. Organization may be based on product flow path, physical equipment layout, operating responsibilities or some combination of the above. In addition to the common process monitoring display features previously identified, the following elements and animations are common to process unit displays: Object

Attribute(s) State (Open, Closed, etc.)


Dynamic? Yes

JETT




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

Dynamic? Yes Yes No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes No No Yes Yes Yes Yes Yes Yes Yes Yes

III.3.2.4. Process Detail Displays Process detail displays are typically associated with a single module or object (e.g., specific valve, specific controller, specific equipment phase, etc.). This type of display is sometimes referred to as “faceplates” or “device pop-ups”. They provide dynamic icons, symbols, and/or text representations for every important aspect of the subject equipment module, control module, or other dynamic process resource.



JETT



Every equipment module, control module, and dynamic process resource within the scope of the PCS should be accessible through a process detail display. These displays may “float” over other process displays in a moveable window, occupy a configurable portion of another process display, or be part of a dedicated whole-screen display of process details. Access to a process detail display is typically provided through a “rapid navigation” link on a process unit display (e.g., clicking a valve symbol shows the process detail display for the specific valve that was clicked). If practicable, a dropdown list or other menu system should be provided in the process detail display to allow changing the subject module. All process detail displays should include the following: • • • • •

Object Name, Object Descriptor, Alarm Indication(s), Interlock Indication(s), and Appropriate navigation features (e.g., Close/Exit button, Trend display button, Interlock detail display, tuning display, etc.), In addition, the following elements and animations are common to process detail display classes: Detail Display Class

Attribute(s) List of possible states (High, Normal, etc.) Simple Discrete Inputs (level switch, pressure switch, etc.) State (High, Normal, etc.) Value Simple Analog Inputs (temperatures, Engineering Units pressures, levels, etc.) Instrument range State (Open, Closed, etc.) Discrete Control Modules (valves, pumps, Ability to change state etc.) Mode (Auto, Manual, etc.) Ability to change mode State (Open, Closed, etc.) Ability to change state, if appropriate Mode (Auto, Manual, etc.) Ability to change mode Analog Control Modules (controllers, variable frequency drives, etc.) Analog values (SP, CV, PV) Analog ranges (SP, CV, PV) Engineering units (PV, SP, and CV) Ability to change analog values (SP and CV) Equipment Phases State (Idle, Running, etc.)


Page 43 of 65


JETT

URS, Rev.0

Process Control System Detail Display Class

December 7, 2002 Attribute(s) Ability to change state Mode (Auto, Manual, etc.) Ability to change mode Phase parameter values Phase parameter ranges Phase parameter value engineering units Ability to change parameter values

III.3.2.5. Trend Displays Real-time trending and historical data trending displays shall be provided for key process attributes. In addition to the common process monitoring display features previously identified, these displays shall have controls, as appropriate, for: • • •

Selecting data values to be trended, Changing chart zero and scale, and Changing chart start time and duration.

III.3.2.6. Statistical Process Control Displays Standard Statistical Process Control (SPC) displays (e.g., X-Bar charts and Pareto Diagrams) shall be employed as appropriate to provide analysis of manufacturing batch quality and cycle time. III.3.3.

Batch Management Interfaces

III.3.3.1. Graphical Environment and Navigational Aids Batch Manager to PCS integration shall be accomplished both visually and functionally. Visually, a PCS alarm and message screen shall always be present on the operator workstation. Regardless of the Batch Manager or PCS graphic screens called the PCS alarm and message screen shall always be visible. The operator is notified of action requests generated by controller resident procedural elements or recipe operation via a flashing color-coded button on this screen. Navigation controls are provided which guide the operator to the appropriate screen for the requesting action. This Operator Action Request (OAR) button shall exist for each unit. The button is activated by SCADA when a pending OAR exists for the unit. When depressed the button activates navigation controls that will take the operator to either the appropriate Batch Manager recipe or PCS Unit Phase Display depending upon the unit mode.



JETT



III.3.3.2. Unit Phase Display The PCS shall provide the operator interface to the unit through a Unit Phase/Recipe status and control screen. In automatic mode the operator may monitor the unit, which receives commands from the recipe. Note that the interface to the recipe is provided through Batch Manager screens. In manual mode the PCS screens provide the operator interface to the equipment procedural control through phase faceplate displays. The Unit Phase display shall provide the following: • • • •

Display name and status of procedural element currently active on the unit Display the current unit mode (Auto /Manual) and provide a means for Operator selection of the unit mode Provide a phase command interface for the Operator Provide a means for display of and response to, unit level Operator Messages

III.3.3.3. Operator Messages The PCS shall provide the capability to issue information or instructive messages to the operator. Operator messages shall be displayed on the Unit Phase Control screen. Operator messages are generated by controller resident procedural elements and are instructive text which guide the operator through a manual activity which is embedded in an controller resident procedural element. The mechanism for triggering a specific message shall be separate from the contents of the message. This shall allow modification of the text within the message without modification of the logic defining the activation of the message. PCS shall provide a means for Operator acknowledgement of the message. The message and subsequent response/acknowledgement shall be recorded in the PCS Event Log along with the operator’s electronic signature, date, time, unit and batch ID number. III.3.4.

Alarm Management Interfaces

III.3.4.1. Alarm Display All system alarms shall be presented to the operator on a priority basis defined as ‘oldest, highest priority, non-acknowledge alarm’ first. All alarms shall be displayed in an alarm list/banner and on a relevant graphic, in the specified colors. Alarm display characteristics are determined according to their state and their priority. The display and annunciation of an alarm is activated by a change in state of the alarm. The system shall support configuration of dynamic color change of foreground and background text based on current alarm state at a given priority level. The system shall also support configuration of an internal audible signal as well as an output to external light or audible signal based on current alarm state at a given priority level. Alarm states are defined as: • • •

Normal – No alarm condition exists Active – process measurement is outside of prescribed alarm setpoint value. Active Acknowledged – Alarm is and has been acknowledged by the operator



JETT

Process Control System • •


Active Unacknowledge - Alarm is active but not acknowledged by the operator Cleared Unacknowledged – Alarm condition has returned to normal state without operator acknowledgement.

III.3.4.2. Alarm Summary Display Information The alarm summary shall display to the operator a list of all alarms that are currently: • • •

Active—Unacknowledged Active—Acknowledged Cleared—Unacknowledged

The alarm summary shall provide the following real-time information for each alarm: • • • • • • • •

Alarm tag Value of the alarm setting being transgressed Time and date of last alarm activation Alarm severity Critical alarm category Area / Cell / Unit in which the alarm was generated Alarm state and severity Lot # (if appropriate)

As a default, all system alarms should be presented to the operator on a priority basis defined as ‘oldest, highest priority, non-acknowledge alarm’ first. The PCS shall provide for filtering and display of the alarm list in the following ways: • • •

Alarm severity Critical alarm category Process Area / Cell / Unit

III.3.4.3. Alarm Log A journal of alarms will be maintained on the PCS. GMP alarms will also be captured for inclusion in the batch record. The PCS shall provide the following alarm logging capability. Note that all logging shall conform to 21 CFR Part 11 requirements. All pertinent data including tag number, batch ID (if applicable) time of alarm, value of alarm and maximum and minimum deviations are recorded to the alarm database with each alarm event. The system shall also calculate and record the duration of an alarm when the alarm clearance event is detected. System alarm logging shall be triggered by the following alarm status changes: •

Activation (and re-activation)



JETT



• Clearance • Acknowledgement • Disable / Enable Upon alarm activation the system shall log the following formation: • Alarm tag • Value of the alarm setting being transgressed • Time and date of alarm activation • 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 to the log created upon activation of that alarm: • Operator electronic signature • Time and date of alarm acknowledgement Upon clearance of an alarm the system shall calculate and append the following information to the log created upon activation of that alarm: • • • •

Value of the alarmed process variable Time and date of alarm clearance Minimum and maximum deviation values while in alarm Duration of alarm

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

All Alarm Report Alarm Frequency Batch Report Standing Alarm Report

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



JETT


Report Disabled Alarm Report

III.3.5.


Description A report listing all current disabled alarms

PCS Status Interface

III.3.5.1. PCS Status Display PCS status display(s) should include a dynamic system architecture diagram with animations indicating the location of active PCS alarms. III.3.5.2. PCS Event and Error Logs Important PCS events and errors should be annunciated and presented to the appropriate system user(s). The following event types may be included: Event Type Error Warning Information

Success Audit Failure Audit

Description 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. 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. An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, an Information event will be logged. An audited security access attempt that succeeds. For example, a user's successful attempt to log on to the system will be logged as a Success Audit event. An audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt will be logged as a Failure Audit event.

Annunciated PCSThese events and errors are to be treated as electronic records (i.e., not maintained exclusively in text files). III.3.6. Programming and Configuration Interfaces Offline ability to modify and test changes to PCS software must be provided. If existing development facilities and/or equipment are to be leveraged for this purpose, qualification testing must verify the validity of this approach. Programming and configuration interfaces must provide all the functionality used for original system development. Access to programming and configuration interfaces must be restricted to authorized users.



JETT



III.3.7. Recipe Management Interface Offline ability to modify and test changes to PCS recipes must be provided. If existing recipe management facilities and/or equipment are to be leveraged for this purpose, qualification testing must verify the validity of this approach. Recipes developed for the PCS must be controlled as electronic records, in accordance with 21 CFR Part 11. This includes: • • • •

Validation of systems that create, modify, maintain, or transmit the recipe, Ability to generate accurate and complete copies of recipes in electronic and human-readable formats, Ability to archive recipes (for record protection) to enable accurate and ready retrieval throughout the batch record retention period, and Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of user entries and actions that create, modify, or delete recipes. Recipe changes must not obscure information from a previous recipe version.

III.3.8. Reports PCS user interfaces should provide the features needed to request, display, and print reports. A comprehensive batch end report that includes all values and events needed to evaluate production quality. These include, at least, the following: • • • •

Record of all employed recipes and/or procedures, Record of all alarms and acknowledgements, Record of all important events (processing steps, manual actions, etc.), and Record of key process measurements (temperatures, pressures, sample results, etc.).

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 capability should be accessible from any remote interface (i.e., interfaces that are not within the scope of the PCS should be view-only).



JETT



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 each interface. 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 the degree of interaction between the systems.> III.5.4. Shared Resources
III.6. Environment III.6.1. Layout The following draft floor plan(s) indicates the physical location of the process and related equipment: {Insert preliminary facility floor plan(s) for the process area(s), control locations, and server rooms}



JETT



It is anticipated that the equipment will be distributed within this facility. The following considerations and principles should guide the physical design and location of PCS equipment: • • • • •

Equipment locations must balance wiring costs, access convenience, cleaning requirements, throughway obstruction, and consumption of valuable production and/or personnel space. All equipment must be readily accessible for use (if applicable), cleaning, and maintenance. Equipment that requires routine and/or frequent access should consider user access ergonomics. The ability to receive, install, and remove equipment from the site should be considered. Ready access to system manuals and appropriate procedures should be provided.

III.6.2. Physical Conditions The following environmental conditions should be considered in determining appropriate equipment installation locations: Area

Classification(s)

Description

The following is a brief characterization of area classifications. For more detailed descriptions and equipment requirements, refer to appropriate industrial standards. Classification Description Refers to the minimum protection provided by enclosures located in the area. Type 4 enclosures are intended for indoor or outdoor use primarily NEMA4 to provide a degree of protection against windblown dust and rain, splashing water, and hose directed water; and to be undamaged by the formation of ice on the enclosure. Refers to the minimum protection provided by enclosures located in the area. Type 4X enclosures are intended for indoor and outdoor use NEMA4X primarily to provide a degree of protection against corrosion, windblown dust and rain, splashing water, and hose-directed water; and to be undamaged by the formation of ice on the enclosure.


JETT




Classification Description Refers to the minimum protection provided by enclosures located in the area. Type 12 enclosures are intended for indoor use primarily to NEMA12 provide a degree of protection against dust, falling dirt, and dripping noncorrosive liquids. Class I locations are defined by the National Electric Code as those locations in which flammable gas or vapor may be present in the air in NEC Class I quantities sufficient to produce explosive or ignitable mixtures. All NEC classes may be subdivided as Division 1 (Normally Hazardous) or Division 2 (Not Normally Hazardous). Class II locations are defined by the National Electric Code as those locations that are hazardous due to the presence of combustible dusts. NEC Class II All NEC classes may be subdivided as Division 1 (Normally Hazardous) or Division 2 (Not Normally Hazardous). United States Federal Standard for clean room air classification US FS 209D characterized by airborne particulates (> 5 microns) less than 100 Class 100 particles per cubic foot (equivalent to US FS 209E class M 3.5 and to ISO EN 14644-1 class 5). United States Federal Standard for clean room air classification US FS 209D characterized by airborne particulates (> 5 microns) less than 1,000 Class 1000 particles per cubic foot (equivalent to US FS 209E class M 4.5 and to ISO EN 14644-1 class 6). United States Federal Standard for clean room air classification US FS 209D characterized by airborne particulates (> 5 microns) less than 10,000 Class 10,000 particles per cubic foot (equivalent to US FS 209E class M 5.5 and to ISO EN 14644-1 class 7). United States Federal Standard for clean room air classification US FS 209D characterized by airborne particulates (> 5 microns) less than 100,000 Class 100,000 particles per cubic foot (equivalent to US FS 209E class M 6.5 and to ISO EN 14644-1 class 8).


JETT IV.0




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



JETT



IV.2. Compatibility {This section identifies corporate and/or site and/or process area and/or project standards applicable to the Process Control System (PCS). The arrangement and subdivision of standards is unimportant (e.g., PCS Configuration, User Interface, and Coding Standards may be identified in separate or combined standards), however, all standards identified in this section should be addressed by the URS. IMPORTANT: In the interest of project efficiency, standards attached to the URS should specifically identify the constraints applicable to the subject PCS (not general one-size-fits-all standards). A checklist showing exactly which standards will be verified is recommended.} IV.2.1. Hardware Standards and Preferences The following table identifies corporate and/or site and/or process area and/or project standards for Process Control System hardware: Role I/O Enclosure I/O Termination I/O Bus I/O-Controller Interface Controller Enclosure Controller – Small Process Controller – Medium Process Controller – Large Process Controller-OIT Interface Operator Interface Terminal Controller-SCADA Interface SCADA PC Workstation (HMI) PC Workstation Enclosure LAN Components Server PC

Standard(s)

Comments

{Complete the above table. Clearly indicate which roles are, and are not, applicable to the current project.} Solutions based on other hardware may be acceptable, but must be identified, justified, and approved at the earliest possible point within the project. Conformance to project standards is verified as part of Design Qualification and/or Acceptance Testing and/or Installation Qualification. IV.2.2. COTS Software Standards and Preferences The following table identifies corporate and/or site and/or process area and/or project standards for Process Control System Commercial Off-The-Shelf (COTS) software:


JETT



Role I/O Bus Configuration Controller Configuration and Programming OIT Configuration and Programming PC Operating System Controller-SCADA Interface SCADA HMI Process Simulation Batch/Recipe Management Process Historian Manufacturing Execution System Relational Database Custom Application Programming

Standard(s)

Page 54 of 65 URS, Rev.0 December 7, 2002 Comments

{Complete the above table. Clearly indicate which roles are, and are not, applicable to the current project.} Solutions based on other COTS software may be acceptable, but must be identified, justified, and approved at the earliest possible point within the project. Conformance to project standards is verified as part of Design Qualification and/or Acceptance Testing and/or Installation Qualification.



JETT



IV.2.3. PCS Configuration and Integration Standards To help reduce validation, training, and maintenance costs, a set of corporate and/or site and/or process area and/or project standards are employed. Standards for Process Control System (PCS) configuration and integration include: θ

Basic design principles for Process Control Systems,

θ

PCS terminology and naming conventions,

θ

PCS documentation principles,

θ

Basic configuration of PCS hardware and software components, and

θ

General network and IT standards.

PCS Configuration and Integration Standards are {NOTE: If Configuration and Integration standards do not exist, development and approval of project-specific standards may be part of PCS Functional Specifications.}. Application of alternate standards may be acceptable, but must be identified, justified, and approved at the earliest possible point within the project. Conformance to project standards is verified as part of Design Qualification and/or Acceptance Testing and/or Installation Qualification.



JETT



IV.2.4. PCS User Interface Standards To help reduce validation, training, and maintenance costs, a set of corporate and/or site and/or process area and/or project standards are employed. Standards for Process Control System (PCS) User Interfaces include: θ

Basic design principles for PCS User Interfaces,

θ

PCS display libraries, symbols, fonts, and colors,

θ PCS display classes (e.g., Overview, Process Unit, Control Popup), standard layouts, and navigation, θ

Alarm Management and Annunciation, and

θ

User Interface security.

PCS User Interface Standards are {NOTE: If User Interface standards do not exist, development and approval of projectspecific standards may be part of PCS Functional Specifications.}. Application of alternate standards may be acceptable, but must be identified, justified, and approved at the earliest possible point within the project. Conformance to project standards is verified as part of Design Qualification and/or Acceptance Testing and/or Installation Qualification.


JETT




IV.2.5. PCS Programming Standards To help reduce validation, training, and maintenance costs, a set of corporate and/or site and/or process area and/or project standards are employed. Standards for Process Control System (PCS) Programming include: θ Basic design principles for PCS Programming, θ Program identification and version control, θ PCS object naming conventions, θ PCS code format and commenting, θ Program flow control, θ User Interface, and θ Error Handling. Application of alternate standards may be acceptable, but must be identified, justified, and approved at the earliest possible point within the project. Conformance to project standards is verified as part of Design Qualification and/or Acceptance Testing and/or Installation Qualification. IV.2.5.1. Controller Programming PCS Controller Programming Standards are {NOTE: If programming standards do not exist, development and approval of project-specific standards may be part of PCS Functional Specifications. Project-specific standards may be based on Systems Integrator internal quality control standards.}. IV.2.5.2. SCADA Scripts and Custom Applications PCS SCADA Scripts and Custom Applications Programming Standards are {NOTE: If programming standards do not exist, development and approval of project-specific standards may be part of PCS Functional Specifications. Project-specific standards may be based on Systems Integrator internal quality control standards.}.



JETT



IV.3. Maintenance

V.0

LIFE-CYCLE V.1.

Development If S88 is to be applied to the equipment being acquired, it should be referenced in this section of the document. The Supplier shall provide a Quality and Project Plan as part of their proposal. The Supplier shall have a quality system in place. Internal quality procedures shall be available for the User’s review. The Supplier shall provide a Project Manager for the project to provide a single communication point with the User. The project shall utilize the GAMP methodology when developing the system and documentation.

V.2.

Testing Describe the Supplier testing requirements. Reference the Validation Test Plan, Factory Acceptance Test, special tests, etc. This section should also include required amount of demonstrated run time, any special materials necessary to complete testing, integration testing, etc. In order to verify system performance, the User shall witness the execution of the Factory Acceptance Test procedures. The Supplier shall notify the User _______ weeks in advance of the start of this test. The Factory Acceptance Test Specification shall be submitted to the User for review and approval prior to execution. A minimum of _______ weeks shall be allowed for the User to review and to comment and/or approve the Factory Acceptance Test Specification. Refer to the Equipment Validation Plan for applicable procedures.

V.3.

Delivery The [equipment/system], with all options, equipment, and the documentation listed below, shall be delivered to the User’s receiving dock. V.3.1.Documentation Installation, operation, and maintenance instruction documentation for the system shall be developed to a level that is comprehensible to a high school graduate. The Supplier shall use the formats described in the GAMP Supplier Guide, Current Version, to produce the documentation. The Supplier shall provide the



JETT



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

Microsoft Word 97 (*.doc)

• User Requirements Specification


• Functional Specification/Requirements


• Design Specifications


• Controls Test


• Hardware Installation Test


• Operational Test


• Factory Acceptance Test


• Operator, Maintenance and Service Manuals


• Process and Instrumentation Diagram (P&ID) • Instrument Listing

AutoCAD version 12.0 (*.dxf)

Microsoft Word 97 (*.doc) or Excel 97 (*.xls)

• Control Schematics


• Control Panel Assembly Drawings


• Equipment Assembly Drawings


• Bill of Materials


• Spare Parts List


• Component Cut Sheets


• CONTROL PLATFORM Program Printout and Disk File

XXX Program Development format

• OIP Configuration Printout and Disk File

XXX Program Development format

V.4.

Support Describe what support activities are required after acceptance. The paragraphs outlined below provide some areas for consideration.



JETT



V.4.1.Start-up Support (list available options) V.4.1.1.

Training (list training options available)

V.4.2.Post Start-up Support (list post-startup support available) V.4.2.1.

Technical Support Telephone (Voice or Modem) Replacement Parts Availability List (Normal lead times shall be listed)

V.4.2.2.

User Site Support Preventative Maintenance (list maintenance contracts available) System Improvements (supplier shall notify user of any improvements available on a regular basis)



JETT VI.0



GLOSSARY VI.1. Terminology {If necessary, attach a glossary of terms that may be unfamiliar to the Supplier (or other document readers) and/or terms that may have meanings specific to entries in this User Requirements Specification. For example (example list is not intended to be complete):}

Term Alarm Log

Definition A listing that is a permanent record of alarm activities within a defined period. The listing is a replica of sequential alarm events, normally including the activation and acknowledgement activities. Alarm Summary A listing of alarms that are currently in active and/or have been yet been acknowledged. The listing is not a permanent record alarm-related events. Basic Control Control that is dedicated to establishing and maintaining a specific state of equipment. Batch The material that is being produced or that has been produced by a single execution of a batch process. Batch Process A process that produces a specific quantity of product by subjecting specific quantities of raw materials to a defined order of discontinuous processing actions over a period of time using one or more pieces of equipment. Control Module A regulating device, a state-oriented device, or a combination of regulating and state oriented devices that are controlled as a single device. Control Recipe A type of recipe, which, through its execution, defines the manufacture of a single batch of a specific product. The control recipe contains the specific processing requirements for the actual batch, raw materials, and product. It is a copy of a master recipe made unique through the assignment of a lot number. Coordination Control A type of control that directs, initiates, and/or modifies the execution of procedural control and the utilization of equipment entities. Equipment Control The equipment specific functionality that provides the actual control capability for an equipment entity, including procedural, basic and coordination control, which is not part of the recipe. Equipment Module A functional group of subordinate equipment modules and/or control modules that can carry out a specific minor processing activity such as producing individual CIP fluids. Life-Cycle A series of stages through which a system passes during its lifetime. Lot Number An alphanumeric set of characters that uniquely identify and specify the product that is produced at a specific unit operation. Master Recipe A type of recipe that accounts for equipment capabilities and may include process cell-specific information. The master recipe is used as a template for creation of a control recipe.


JETT




Term Operation

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



JETT



VI.2. Acronyms {If necessary, attach a list of acronyms that may be unfamiliar to the Supplier (or other document readers) and/or acronyms that may have meanings specific to entries in this User Requirements Specification. For example (example list is not intended to be complete):} Acronym ANSI degC CFR cGMP CPG DCS

EBR EPA degF FDA GAMP GUI HMI I/O IEEE IQ IS

Full Spelling American National Standards Institute Celsius (centigrade) Code of Federal Regulations

Definition An organization that produces standards, practices, and codes related to pharmaceutical manufacturing. A unit of temperature measurement. Written version of the national laws of the United States of America. current Good A set of regulations governing the manufacture of Manufacturing Practices pharmaceutical products. Compliance Policy Guide US FDA Publications that supplement and/or explain and/or interpret specific requirements from the Code of Federal Regulations(CFR) Distributed Control System A proprietary automation solution providing I/O monitoring and control equipment with a tightly integrated HMI and ancillary applications (trending, redundancy, etc.). Electronic Batch Record A collection of production data stored in secure electronic (digital) form. Environmental Protection A United States agency responsible for environmental Agency protection. Fahrenheit A unit of measure for temperature. Food and Drug A United States agency responsible for consumer Administration safety related to drugs and drug products. Good Automated A methodology for implementing and documenting Manufacturing Practices automated systems. Graphical User Interface An application resident on an Operator Interface that provides a pictorial interface for process monitoring and control. Human-Machine Interface A PC-based graphical user interface used for monitoring and controlling an industrial process. Input/Output The hardware required to convert field signals to/from a computer-usable form. Institute of Electrical and An organization that produces standards related to Electronics Engineers electrical and electronic components, including networking. Installation Qualification Approved documented verification that an object or system is installed according to written and approved specifications and drawings. Intrinsically Safe Standards related to equipment and wiring installation in explosive or potentially explosive environments.


JETT Acronym ISA ISO JETT


Process Control System Full Spelling Instrument Society of America International Standards Organization Joint Equipment Transition Team

LAN

Local Area Network

LCL

Lower Control Limit

LIMS

Laboratory Information Management System

MES

Manufacturing Execution System

MMI MSDS

Man-machine Interface Material Safety Data Sheet

NDA

New Drug Application

NEC

National Electric Code

NEMA

National Electrical Manufacturers Association

OEM

Original Equipment Manufacturer

OQ

Operational Qualification

OSHA

Occupational Safety and Health Act Piping and Instrumentation Diagram

P&ID


Definition An organization that produces standards related to process control and instrumentation. An organization that produces standards, practices, and codes related to pharmaceutical manufacturing. A consortium of pharmaceutical users (manufacturers), equipment suppliers, and consultants seeking to improve communications between Users and Suppliers to more effectively meet the "validation" requirements of the pharmaceutical industry. A group of computers connected to facilitate computer-to-computer communications. The minimum parameter value required to assure that a product is manufactured according to specifications. A software system used to store and retrieve laboratory information related to sampling, testing, and product release. One or more software products or applications responsible for transferring data between plant floor production systems and higher-level business application systems. see HMI. Documentation of the chemical and hazardous properties of a substance. A process prescribed by the US FDA for introducing a new pharmaceutical product or product form to the US marketplace. United States Standards governing the design, installation, and use of electrical equipment. An organization that, among other activities, defines categories of environment resistance for electrical equipment. The supplier of industrial equipment packages that are typically skid-mounted and include pre-wired instrumentation and control components. Approved documented verification that an object or system operates in accordance with written and approved specifications throughout all anticipated operating ranges. United States regulations related to work places and practices. Engineering drawings that present basic process information, especially instrument and sensor locations.


JETT Acronym PC PLC

SCADA

SKU SOP SQL TCP/IP UCL UPS WFI




Full Spelling Personal Computer

Definition A microcomputer designed primarily for use by a single individual. Programmable Logic A device that provides control functionality via Controller software. It is typically programmed in ladder logic and replaces relays, electrical devices, timers, counters and analog instrumentation. Supervisory Control and A SCADA system provides communication between Data Acquisition supervisory applications (e.g., HMI or batch management) and plant floor control devices, typically PLCs. Stock Keeping Unit A number or other identifier used to distinguish packaging and/or product forms. Standard Operating Site instructions for operating and maintaining the Procedure facility and process. Structured Query Language A standard syntax used to extract selected data from a database. Transmission Control A routable computer communication protocol. Protocol / Internet Protocol Upper Control Limit The maximum parameter value required to assure that a product is manufactured according to specifications. Uninterruptable Power Battery-based system for providing electrical power Supply during temporary power outages. Water For Injection Highly purified water suitable for use in the production of products that may be injected into a human body.


JETT-SCADA-URS

Recommend Documents