8. Approach to Control Systems
8.1. Definition of a Control System
Control systems monitor and control production processes or environments.
Control systems include equipment that measure physical variables, present and store data and through pre-programmed/configured control algorithms, logic blocks etc., effect real time control on physical parameters. Control systems may also be linked to higher levels of computer integrated manufacturing systems.
A wide range of equipment is covered from, for example, a single loop temperature controller through to a large distributed process control system with thousands of inputs and outputs.
Control systems may be sub divided into two main classes:
• Embedded systems.
An embedded system refers to control systems that are delivered as an integrated part of a piece of manufacturing equipment (e.g. filling machine, centrifuge, packaging machine). Typically for these systems the control system documentation and qualification will be combined with that for the overall equipment, and the multi-disciplined engineering effort to produce this associated life-cycle documentation will be the contracted responsibility of the supplier.
• Standalone systems.
A standalone system refers to control systems that are typically supplied to control or monitor and collect data from a process, and are generally supplied separate to the process equipment. Standalone systems typically could include multi-loop controllers/PLCs used to control part of a process, and SCADA/DCS systems used to control the process plant as a whole. These systems may be integrated vertically with other management systems, and with embedded systems covering individual items of process equipment.
These systems are generally developed and tested (factory acceptance testing) in isolation before delivery to site. Following delivery and installation, acceptance testing and qualification with the process equipment is completed.
8.2. Scope of Systems Covered
Control system equipment typically includes the following:
• Programmable logic controllers (PLCs).
• Distributed control systems (DCSs).
• Data historian/trending systems.
• Supervisory control and data acquisition systems (SCADA).
• Systems controlled by standalone personal computers (PC).
• Loop controllers.
• Data acquisition systems linked to production systems.
• Expert control systems.
• Intelligent Instrumentation and associated networks.
• Networks and interfaces within the process control system and to any other connected system.
Examples of less obvious applications utilising control systems might be:
• Warehouse management systems.
• Site entry systems.
• Building management systems.
8.3. Responsibilities
Particularly for large DCS systems there are likely to be multiple equipment/system suppliers, possibly systems integrators (configuring the systems), a managing contractor and project team.
For systems where separate process and computer validation plans exist, the interfaces and responsibilities of the computer and process validation specialists should also be considered.
For less complex systems roles and responsibilities may be combined, however independent developer, user and QA/Validation roles should always be assigned.
Responsibilities should be clearly defined throughout the lifetime of the system.
8.4. Systems Register
The definition of what comprises a system needs careful consideration.
Where a large DCS is interfaced to embedded PLCs controlling process equipment, the PLCs may be considered separate systems as they provided discrete standalone functionality.
8.5. Validation Life-Cycle
The validation of control systems is one element of the equipment/process validation. Control systems validation should be in line with this guideline and support the process validation requirements. The following points provide some additional process control specific guidance for each of the life-cycle phases as described in Section 4.
8.5.1. Planning
For projects where control systems are only a part of a larger project, it is important that the control system (high level) requirements are considered at this stage. The user should specify requirements in consultation with developer/engineers.
Control systems should be assessed for applicability with the electronic records, electronic signatures regulations. For systems where the regulations apply consideration as to how the system will comply should be included within the requirements and functional specifications. GQG 3202 provides additional guidance on ERES requirements.
Co-ordination of activities with those defined in any associated process/equipment validation plans is essential, particularly during the IQ and OQ stages. For small process control systems, the validation activities may be encompassed within the overall project validation plan.
8.5.2. Supplier Assessments
For embedded control systems it may be more efficient to have a combined audit to establish the supplier’s capabilities with respect to mechanical and electrical activities in addition to control system development.
Development and maintenance organisations may operate from different locations and to different quality management systems. The need to assess both the development and maintenance organisation should be assessed and documented in the validation plan.
8.5.3. Requirements Phase
The user requirements specification (URS) for large applications, e.g. DCS or SCADA, may involve the development of a separate URS for just the control system. The advantage of this approach is that it helps to focus the software developer on the control functionality aspects. A separate requirement specification should provide appropriate production process and product information, electrical and mechanical details and performance requirements.
For embedded systems the control system functions may be included within the overall specification for the machine or equipment.
The physical parameters to be monitored/controlled and the data to be generated by a control system should be clearly documented during
reviewed with regard to their overall function (GxP, safety/environmental, process control) and level of criticality. A categorisation of parameters and data should be carried out to ensure the design and testing of both hardware and software associated with each is appropriate for the function and level of criticality. This information provides the basis for the traceability of critical parameters and data through the design process to the final testing stage. This traceability can be documented as a requirements traceability matrix (RTM).
8.5.4. Design and Code Phase Functional Specifications
The structure of Functional Specifications should be tailored to suit the category and complexity of the system, some examples are provided below for guidance:
• Embedded system.
Typically a single document combining computerised system and overall functional specification (process, mechanical, electrical etc.) for the equipment is appropriate.
• Small SCADA system.
The functional specification typically only covers the control system (i.e. not process, electrical or mechanical etc) and is often termed a functional design specification where it combines sufficient detailed design information for the system to be configured and built.
• Complex DCS.
The functional specification often consists of multiple documents, typically one for each process unit covered by the system and/or a functional specification for each area of functionality, e.g. sequence logic, device/interface logic, trips and alarms etc.
Detailed Design
The detailed design includes the production of hardware, software and associated instrumentation specifications. For embedded systems these documents may include the preparation of mechanical and electrical specifications/documentation.
Control systems differ to IT and laboratory systems in terms of the direct interface to the manufacturing process and field instrumentation/plant equipment. Within the detailed design therefore consider the following key documents:
• Plant/equipment layout drawings.
• Engineering line drawings/process and instrument drawings.
• Loop/Instrument schedules and alarm/trip schedules.
• Process description/sequences.
• Interconnection drawings.
Design Review
The fundamental purpose of a design review is to ensure that the user and functional requirements have been addressed satisfactorily within the design of the system. Mechanisms such as requirement traceability matrices (RTM) can therefore assist in the design review process.
For larger systems with multiple design documents, there are likely to be multiple design reviews. Some form of hazard and operational study (e.g. CHAZOP) should also be performed on the system.
For larger and/or more complex control systems some detailed design information may not be available until later stages of the project, e.g. alarm settings. The use of 'holds' within documents is recommended to allow work to continue, with each hold logged and subject to review once resolved.
For embedded systems where there are no safety/operability issues, design review may consist of a simplified process to ensure that GSK requirements have been covered within the supplier’s standard document set.
Code Review
During the design phase the configuration languages and complexity should be considered in order to establish the approach to code review.
Where the supplier has conducted code reviews, auditing should be considered to ensure that competent individuals have completed the reviews and that they are independent from those developing the
8.5.5. Development Testing Phase
Testing of the system should be a combination of off-line simulation, and integration testing utilising plant/equipment, in order to demonstrate the operation of equipment under computer control.
Thorough system integration testing and usually factory acceptance testing should be completed prior to delivery of the system to site.
This is particularly important for more complex systems such as DCS.
Where pre-installation test activities are well documented, with supporting evidence and have been executed to the principles of cGMP, then these may be used to support OQ. Particular attention should be focussed on stress and boundary testing at this stage as performing such tests in a 'live' environment on process plant may not be possible.
Simulation tools are often used to simulate both the input/output (I/O) devices (instrumentation and control devices) and the operation of devices and process for example when the DCS sends an output to open a block valve, the corresponding confirmation inputs are transmitted back to the DCS by the simulation package.
The use of such tools is generally to be encouraged as these provide the opportunity to perform more thorough, realistic and challenging tests to the control system software; particularly in terms of stress testing where these could potentially cause damage to process equipment.
It is not considered necessary to formally validate simulation packages where the following points have been addressed (see also guidance on software tools):
• The system vendor has approved use of the simulation tool.
• The simulation tool cannot, itself alter the configuration of the control system.
• The use, scope and limitations of the simulation tool are documented.
• The nature and scope of changes required to the control system configuration for the simulation tool to operate (e.g. disabling of I/O scan blocks) are understood and documented.
Any configuration of the simulation tool itself is documented and verified.
Simulation is not used instead of formal OQ and PQ in the 'live' process environment.
8.5.6. Deployment Phase
Operational and Support Planning
Control systems should have hardware maintenance and diagnostic procedures, a list of manuals or procedures specifying how the equipment and process instrumentation will be maintained and serviced, including security methods for computer hardware.
Installation Qualification
The purpose of IQ is to demonstrate that the system (including software, hardware and equipment) has been installed according to the manufacturer’s specifications.
The configuration parameters of standard instruments should be recorded in the equipment IQ.
Hardware and equipment IQ establishes that adequate documentation for the installation of the system is available, and that the system is properly installed (as per the appropriate specifications).
A typical list of documentation that should be available for hardware and equipment IQ includes, but is not limited to, the following:
• Documentation describing all hardware components and any peripherals associated with the system including CPU, interfaces and instruments, printers, etc.
• List of instruments and field devices associated with the system.
• Documents describing all network and communication hardware (including for larger systems a network/topology diagram) associated with the system.
• Documents describing all wiring and connections associated with the system.
• Documents describing all electrical connections, including grounding and shielding.
• Documents describing the actual accuracy of I/O devices and instrument associated with the system.
• Documents describing switch settings, internal and external, to configure the system as specified.
• List of the loop drawings that indicate the writing terminal address on each process control panel, field equipment panel, field sensor, control device and alarm.
• Documents describing environment condition requirements for the system and associated equipment, including temperature, humidity, dust, static, power fluctuation (power supply stability), electromagnetic interference and radio frequency interference (power line noise and required filtration).
• Documents describing the system’s total core and storage capacity as installed.
• Documents describing calibration requirements for associated instruments and equipment.
Operational Qualification
The purpose of OQ is to ensure that the system functions in the user environment as intended.
• Hardware and equipment testing.
This area will ensure that physical devices attached to the control system operate correctly and over the required ranges (may be termed hot loop testing). This area also includes testing of trips, interlocks and any other safety/guarding devices.
This aspect may also cover verifying display information, and verifying that devices can be operated (manually) from the system – note that this activity may be conducted as a separate activity. Data capture, archiving and retrieval systems can also be tested within this phase.
• Functional acceptance testing.
This should be designed such that the testing covers the entire range of the system’s specified operating parameters and also demonstrates system repeatability over a number of test runs.
System tests should include testing the system under stress conditions where these cannot be effectively tested during factory acceptance testing. Some examples are:
− Verifying the full-scale measurement capability during hot loop testing.
− Verifying system operation with multiple operator requests.
− Verifying the capability of the system to deal with multiple critical alarms.
− Radio Frequency Interference (RFI), Electro-Magnetic Interference (EMI) susceptibility of the system.
For many active pharmaceutical ingredient (API) manufacturing control systems (SCADA and DCS), OQ is frequently split into two phases, OQ1 and OQ2 and performed in conjunction with the process validation activities. Typically OQ1 includes all activities up to and including system testing using water runs in plant, OQ2 generally covers systems testing utilising solvent and commissioning batches.
For secondary manufacture, OQ will typically involve the use of placebo, bottles, boxes, ampoules etc., but not necessarily product.
Pre-installation tests (e.g. Factory Acceptance Testing) may be used to support (but not replace) OQ activities where these have been conducted to GxP principles. Further, certain tests may only be possible within a simulated/environment off-line.
Performance Qualification
This should always be performed at the user site and include testing specific to the user environment and defined ways of working.
Frequently for control systems, PQ will be conducted as part of an overall process validation activity. Where this is the case the associated validation documentation should have clear cross-referencing to indicate this.
Post Implementation Monitoring
In addition to general areas described in Section 4, consider the following:
• Trips and alarms – frequency of nuisance alarms, number of 'standing alarms' on the system.
• Operability – is the plant being operated in line with the original philosophy for example where a high degree of automation is available is this being used or is the plant effectively being run
• Are system maintenance and calibration (support) procedures being completed (including support agreements with system suppliers).
• Configuration changes – inevitably with control systems minor configuration changes are required through the life of the system.
• Verify that the change control system is being adhered to and that the number of minor changes is not excessive.
8.5.7. Use Phase
Operational and support plans are implemented as stated in the management principles. Periodic review and revalidation will be conducted in accordance with criticality of the system to the production process.
8.5.8. Decommissioning
For control systems with ERES functionality particular care should be given to archiving of the electronic records, raw data and system software (including configuration).
For control systems with non-standard data formats and hardware consideration should be given to migrating data to portable data formats (using a validated process) or retention of hardware to allow retrieval of data/records.
8.5.9. Cross Phase Activities
Change Control, Configuration Management and Incident Management
Changes to associated manufacturing processes or equipment are likely to have an effect on the associated control systems.
Consequently, process or equipment change proposals should trigger an assessment of whether the associated control system requires modification.
Document Management
Control systems are often dependant on documentation that is not 'owned' solely by the control system. For example, instrument/electrical schedules, Engineering line diagrams (ELDs), process and instrumentation diagrams (P&IDs) and process descriptions. It is therefore important that a clear cross-referencing
system is established to these 'external' documents (see also change control section above).
Where 'as built' changes have been included on documentation such as ELDs/P&IDs, these should be reviewed for any potential impact on the control system e.g. accuracy of process diagrams displayed on operator screens.
8.6. Examples of System Categorisation
The following list gives guidance on the expected categories (refer to Section 6) of some typical process control systems. The need to assess each system individually is still strongly recommended.
Process control systems type Categories
Loop Controllers 2
Smart Instruments (analogue transmission of process variable)
2
Smart Instruments (digital transmission of process variable) 2, 3 Intelligent Instruments (without control/logic functions) 1, 2, 3 Intelligent Instruments (with control/logic functions utilised) 1, 2, 4
PLCs (customised system) 1, 5
PLCs (embedded system with no customisation 1, 4 SCADA system (no user defined macros) 1, 3, 4 SCADA system (with user defined macros) 1, 3, 4, 5
DCSs (standard configuration) 1, 3, 4
DCSs (customised e.g. Visual Basic routines) 1, 3, 4, 5 Data acquisition systems (configured, but no user
macros/programming)
1, 4
Expert Control systems 1, 4, 5
Standard interfaces to other connected systems (e.g. MRPII, LIMS, MES)
3 or 4
Bespoke/customised interfaces to other connected systems 5
Smart Instruments report one process parameter (on an exception basis the instrument can be interrogated for configuration such as range and engineering unit). Intelligent instruments (e.g. Fieldbus devices) control multiple process parameters and implement control functions.