II.4.Exclusions and Future Considerations

III.1.3.2.Control Modules

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.).
Control request management	Control modules should be designed to seamlessly accept, and respond appropriately to, mode, state, and setpoint requests from: User interface(s) (including local control stations), Supervisory processes (e.g., phases), and Interlocks. Control module interfaces should, where possible, clearly identify the current state, the current mode, and the source of active control. Invalid user inputs should, where possible, produce a message identifying the reason the input will not be processed.
Bumpless transfer	Control module mode changes should not cause an immediate corresponding change in control module state, setpoint, or output.
Fault annunciation and response	Every unexpected combination of I/O states (and/or values) should result in a specific failure alarm (e.g., “valve uuu-XV-iiii failed to open”). Control module fault response should be designed to mitigate risk to personnel, product, and equipment.
Harmony with supervisory control	Control modules may be subordinate to supervisory objects including complex modules (e.g., header or dispensing system) and phases. Mode changes and faults in subordinate control modules shall either: Propagate the mode or fault to the supervisory object, or Override the subordinate mode and/or fault monitoring and comprehensively replace it with mode and/or fault monitoring by the supervisory object.
Data utilization	All relevant data (I/O, user requests, parameters, etc.) shall be appropriately considered by the control module algorithms. For example, if a block valve includes both an Open limit switch and a Closed limit switch, the state of both switches should be considered in determining the actual state of the valve.
Harmony with simulation	Where applicable and possible, installed simulation activation and I/O forcing shall be obvious from all impacted user interfaces and reports.

III.1.3.3.Interlocks

Factor	Description
Product independence	Interlock functionality should not consider current product processing requirements. In general, interlocks should only be applied for personnel protection, equipment protection, and/or prevention of product contamination.
Harmony with supervisory control	Control modules may be subordinate to supervisory objects including complex modules (e.g., header or dispensing system) and phases. Interlocks in subordinate control modules shall either: Propagate the interlock to the supervisory object, or Disable (fault) the supervisory object, or Override the subordinate interlock and replace it with a complimentary interlock and/or fault monitoring by the supervisory object.
Overrides	The ability to manually override interlocks, if available, shall be reserved for engineering and maintenance users.
Display	Control module interfaces should, where possible, clearly identify whether or not a control module interlock is active. The specific cause of the interlock should be either displayed as part of the control module interface and/or readily accessible from the control module interface.
Record of interlock events	Historical data collection must include a record of interlock-related events (activation, clearing, overrides, etc.). Reports that include a list of alarms and events should include interlock-related events.

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:

Factor	Description
Commonality and consistency	All complex modules should be instantiated from a limited number of complex module classes. Uncommon complex module attributes (e.g., extra routing valves) should be transparent to PCS users where appropriate.
Class attributes	Each complex module class should have a specific and well-defined set of attributes. Typical attributes include: Setpoint (Vxxxx-Vyyyy, charge, jacket control, etc.), State (Vxxxx-Vyyyy, charge, jacket control, etc.), Requested Mode (manual, automatic, etc.) Mode (manual, automatic, etc.), and Fault (failed to start, deviation from setpoint, etc.).
Control request management	Complex modules should be designed to seamlessly accept, and respond appropriately to, mode, state, and setpoint requests from: User interface(s) (including local control stations), Supervisory processes (e.g., phases), and Interlocks. Complex module interfaces should, where possible, clearly identify the current state, the current mode, and the source of active control. Invalid user inputs should, where possible, produce a message identifying the reason the input will not be processed.
Bumpless transfer	Complex module mode changes should not cause an immediate corresponding change in complex module state, setpoint, or output.
Fault annunciation and response	Every unexpected combination of control module states (and/or values) should result in a specific failure alarm (e.g., “valve uuu-XV-iiii failed to open”). Complex module fault response should be designed to mitigate risk to personnel, product quality, and process equipment.
Harmony with supervisory phases	Mode changes and faults in complex modules that are subordinate to a phase shall either: Propagate the mode or fault to the phase, or Override the subordinate mode and/or fault monitoring and comprehensively replace it with mode and/or fault monitoring at the phase level.
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.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,
  
• 
  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.
  

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.

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:

• 
  Scaling constants and alarm limits,
  
• 
  Deadbands and delays,
  
• 
  Controller tuning constants,
  
• 
  Dispensing pre-action limits and tolerances, and
  
• 
  Conversion constants (e.g., material specific gravity).
  

III.1.8.Modes of Operation

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

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 “auto-respond” to control module states (e.g., Open feedback energizes and closed feedback de-energizes whenever the valve stat is OPEN).
  

The ability to enable simulation shall be restricted to Supervisors, System Administrators, Engineering, and Maintenance personnel. PCS event log(s) and/or alarm log(s) shall indicate transitions to/from simulation mode.

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:

Activity/Event	Performance Expectation
Process Monitoring and Basic Control Response	PCS control responses (e.g., PID controller output change in response to a deviation from setpoint) should be commensurate with the potential significance of the process change. For example: Slow-moving regulatory response (e.g., vessel temperature control) should occur within five (5) seconds. Fast-moving regulatory response (e.g., line pressure control) should occur within one (1) second.
Process Input Display	PCS display of process condition changes should be commensurate with the potential significance of the process change. For example: All changes in process conditions (i.e., instrument readings and discrete feedback states) should be reflected in PCS displays within five (5) seconds. For process conditions that can exhibit rapid and significant changes (e.g., pressure and flow readings, vessel rupture disks), changes should be reflected in PCS displays within two (2) seconds.
User Control Command	Evidence of PCS response to user commands (e.g., changing control module states, starting a batch) should be presented to the user within one (1) second (e.g., by changing a “commanded state” indication). Process control response to user commands should be commensurate with the potential significance of the requested change. For example: A valid user command to start a batch should activate the first equipment phase within ten (10) seconds. A valid user command to change the state of a control module should change the appropriate control output within two (2) seconds.
Display Navigation	Evidence of PCS response to a user command to change displays should be presented to the user within one (1) second. The target display should be completely painted, with up-to-date data values, within five (5) seconds.
Workstation Synchronization	When a process attribute is changed from one workstation, the attribute change must be reflected on other workstation displays. Such attribute changes should be reflected on all workstations within three (3) seconds.
PCS Startup	In general, it should be possible to bring the PCS from a de-energized state to a full working state within fifteen (15) minutes.
PCS Shutdown	In general, it should be possible to bring the PCS from a full working state to a fully de-energized state in a controlled manner within fifteen (15) minutes.

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.

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.

Download 396.6 Kb.

Share with your friends: