III.2.Data
{Include or attach any project-specific data relevant to PCS specification and/or design. The following should be considered “minimum essential” preliminary data:
-
Process Flow Diagram
-
Process Description
-
Scope of Automation
The following additional preliminary data should be included if available:
-
P&IDs
-
I/O List
-
Instrument List
-
Identification of Critical Parameters
-
Proposed PCS System Architecture and/or Hardware List(s)
-
Alarm Lists (Priorities, Types, Areas, Specific Alarms
-
Process Units List
-
Control Module Classes List
-
Control Modules List
-
Interlock List
-
Complex Module Classes List
-
Complex Modules List
-
Equipment Phase Class Lists (including parameter and faults)
-
Equipment Phase List
-
Recipe Lists (Procedures, Unit Operations, and Operations)
-
Historical Data Collection List
-
Locally Controlled Equipment List and/or Description(s)
-
Managed Resources List
-
Engineering Parameters List
-
User Interfaces List
-
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:
-
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.
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.
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.
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.
|
Operational System Checks
|
PCS specification documentation shall clearly identify permitted sequencing of steps and events that must be enforced, if any. The 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.
|
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.
|
Share with your friends: |
