User Requirements Template for a Supervisory Control and Data Acquisition (scada) Process Control System notes for use of the User Requirements Template

III.3.User Interfaces

III.3.1.General

III.3.1.1.User Interface Design

Task	Description
Process Monitoring: Overview	Features designed to provide a rapid and accurate assessment of the status of the entire process within the scope of PCS control. Overview displays typically display key module states and/or measurements for a process cell, or a portion of a process cell, in a graphical format.
Process Monitoring: Unit	Features designed to provide structured access to the primary state(s) and values for all modules and/or measurements. Unit displays typically present modules related to a single process unit and/or ancillary equipment in a graphical format.
Process Monitoring: Detail	Features designed to provide structured access to all important attributes (including identification, modes, states, setpoints, values, etc.) of an individual module and/or instrument. Detailed process monitoring is commonly provided through onscreen popups that mimic traditional analog instrument faceplates.
Process Monitoring: Analytical	Features designed to display historical and/or statistical information to users. These typically include a historical trend display and, for discrete manufacturing, one or more Statistical Process Control displays.
Process Control: Detailed	Features that allow users to manipulate process control elements (e.g., by changing control module modes, states, etc.). Process control is commonly provided as part of the process monitoring detail interface features.
Process Control: Batch Management	Features that provide for monitoring and control of recipe execution. Batch management features typically include screens for batch initiation, resource arbitration, batch monitoring, user prompts/responses, individual phase control, alarms, and reports.
Supervisory Functions	Features, protected from operator access, designed to provide extraordinary process and batch management controls. Protected supervisory capabilities may include overriding interlocks, modifying batch execution, temporarily modifying engineering parameters, workstation shutdown, etc.
Alarm Management	Features designed to notify user of monitored alarms, allow acknowledgement of those alarms, provide a record of alarm-related events, and display summaries and histories of alarms.
PCS Analysis	Features designed to display the status of the Process Control System components.
Reports	Features designed to select and display/print written summaries of historical production data.
Programming and Configuration	Features provided to allow for future modification of application configuration and/or source code. These typically include access to the primary operating system interface(s) and employ strict user access controls to help enforce adherence to change control procedures.
Recipe Management	Features provided to allow for creation, modification, and deletion of process recipes.

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.

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.

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

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

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.

Every equipment module, control module, and dynamic process resource within the scope of the PCS should be accessible through a process detail display. These displays may “float” over other process displays in a moveable window, occupy a configurable portion of another process display, or be part of a dedicated whole-screen display of process details.

Access to a process detail display is typically provided through a “rapid navigation” link on a process unit display (e.g., clicking a valve symbol shows the process detail display for the specific valve that was clicked). If practicable, a dropdown list or other menu system should be provided in the process detail display to allow changing the subject module.

All process detail displays should include the following:

• 
  Object Name,
  
• 
  Object Descriptor,
  
• 
  Alarm Indication(s),
  
• 
  Interlock Indication(s), and
  
• 
  Appropriate navigation features (e.g., Close/Exit button, Trend display button, Interlock detail display, tuning display, etc.),
  

In addition, the following elements and animations are common to process detail display classes:

Detail Display Class	Attribute(s)
Simple Discrete Inputs (level switch, pressure switch, etc.)	List of possible states (High, Normal, etc.)
	State (High, Normal, etc.)
Simple Analog Inputs (temperatures, pressures, levels, etc.)	Value
	Engineering Units
	Instrument range
Discrete Control Modules (valves, pumps, etc.)	State (Open, Closed, etc.)
	Ability to change state
	Mode (Auto, Manual, etc.)
	Ability to change mode
Analog Control Modules (controllers, variable frequency drives, etc.)	State (Open, Closed, etc.)
	Ability to change state, if appropriate
	Mode (Auto, Manual, etc.)
	Ability to change mode
	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.)
	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.

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

III.3.5.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 should be annunciated and presented to the appropriate system user(s). The following event types may be included:

Event Type	Description
Error	A significant problem, such as loss of data or loss of functionality. For example, if a service fails to load during startup, an error will be logged.
Warning	An event that is not necessarily significant, but may indicate a possible future problem. For example, when disk space is low, a warning will be logged.
Information	An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, an Information event will be logged.
Success Audit	An audited security access attempt that succeeds. For example, a user's successful attempt to log on to the system will be logged as a Success Audit event.
Failure Audit	An audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt will be logged as a Failure Audit event.

Annunciated PCS events are to be treated as electronic records (i.e., not maintained exclusively in text files).

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.

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.
  

Download 396.6 Kb.

Share with your friends: