GAMP - Process Control SIG

GAMP 4 + Beyond

Tony de Claire

GAMP - Process Control SIG

SIG Background Evolved from impromptu lunchtime meeting at the launch of

initial GAMP (PICSVF) draft release in Westminster Two control engineering representatives given a mission at a

meeting hosted by Wellcome, Dartford soon after Initial Group set up, with recruitment at a hotel bar in Basle

(May’96) Group’s basic aim is to “voice” control system issues Well attended group with members of “user” background Active with / instigating a variety of contributor panels

GAMP - Process Control SIG

Purpose: Address the considerations in applying GAMP Principles to

Process Control System applications Work focus:

Process Control Systems Section in GAMP 4 * Forthcoming GAMP “Good Practice Guide” Input to Calibration panel, Audit, GEP revisions Liaison with NAMUR and JETT

( * copies of pre-edited Draft available)

GAMP 4 - Process Control Systems

Used to automate manufacturing processes Dynamic real-time I/O Collect data Control and manage the process Link to higher level data handling functionality or

systems in Computer Integrated Manufacturing (CIM)

GAMP 4 - Process Control Systems

Covers a wide range of systems Small control systems, e.g. in manufacturing

equipment Large control systems, e.g. operating bulk product

plants Two Main Categories

Embedded Standalone (Integrated)

Embedded Systems

Microprocessor, PLC, or PC with sole purpose of controlling / monitoring manufacturing equipment.

Usually delivered ‘embedded’ in a unit or machine Multi-discipline engineering effort required to

produce Much of the lifecycle documentation produced by

supplier

Standalone Systems

Self contained systems, usually delivered separately & connected to field devices

May be linked to / provide higher level functionality

Supervisory Control and Data Acquisition (SCADA) Distributed Control Systems (DCS) Controller or PLC controlling part of a process

Project engineering and co-ordination required

GAMP Validation Principles

Lifecycle (ref. Draft Figs 3.3, 3.4, 3.5) Planning, Supplier and Compliance Risk

Assessments User and Supplier Partnership Specifications Traceability Formal Testing and Verification Documented Evidence

Lifecycle Phases

Planning & Requirement Definition Design Specification, System Development, & Build Design Review and Acceptance Testing Qualification & GEP Commissioning * Operation and Maintenance Decommissioning and Retirement

( * Aligns with ISPE Baseline Guide for Commissioning & Qualification )

Planning & Definition

Define Scope Software Hardware Instrumentation Electrical Mechanical

Planning (continued)

Supplier Assessment Quality System Capability Audits

Quality and Project Plan Define structure of lifecycle documents

GxP Criticality and Compliance Risk Assessment

Importance of Specifications

Provide a structured definition of system requirements

Enable requirement traceability matrix Allow complimentary lifecycle documents to be

developed Support focused and auditable system development Establish test acceptance criteria Support maintenance of the system

User Requirements Specification

For small embedded applications, could be part of equipment specification

For large standalone applications, e.g. DCS or SCADA, a separate URS is normal

User Requirements Specification

URS to clearly identify: Parameters to be controlled and monitored Data to be generated, manipulated, or stored Functions to be performed Process sequence, interlocks, alarms Quality-related critical parameters, data & functions Safety and Environmental requirements Levels of testing required

Functional Specification

Embedded System – FS may be part of overall equipment specifications, including instrument, electrical, and mechanical elements

Standalone System – FS typically one document, identifying the functions, features and the design intentions for the system hardware and software

Functional Specification

Establishes how the requirements of the URS will be implemented Functions to be performed Facilities to be provided Detailed process sequence logic and interlocks Interfaces to instruments, equipment, and other

systems Normally produced by supplier in response to the

URS

Functional Specification

Basis of subsequent testing and verification, e.g. System Acceptance Testing

Divergence with the URS to be identified Should identify any software functions that

are not being utilised Often a contractual document subject to

Change Control by Supplier

Design Specifications

Specifications for system design: Software Hardware Instrumentation

………… may include mechanical and electrical general arrangement drawings

Detailed Design Documentation

Process and Instrument Diagrams (P&IDs) Showing process flow Identification and location of associated control

and monitoring loops

Plant Equipment Layout Identification and location of major items

Detailed Design Documentation

Loop and Instrument Schedule Identify items in the loops Measurement ranges and tolerances Inputs and output signals Identifies Critical Parameters Alarm trip points and actions Sequence Logic & Interlock details

Detailed Design Documentation

Interconnection Drawings Connections to field instrumentation Wiring termination, identification, rating, and

polarity Sufficient detail to enable assembly, installation,

and fault diagnosis

Hardware Design Specification

Defines architecture and configuration of the hardware, including: Controllers PCs Input / Output types & allocation System Interfaces

Software Design Specification

Defines how the software is to implement the Functions Specification

Defines the software and data structure, architecture, the software modules, their interactions, and interfaces.

Structural modular programming language / techniques

Software Design Specification

Should identify programming standards where coding is involved, and naming conventions in all cases

Ensure “annotated” hardcopy of software software provides clear understanding and can be used testing aid

All non-standard software to be identified

System Software Development

Against pre-defined design intentions In accordance with suitable structured

programming standards Author fully conversant with programming

language / techniques Author experienced in similar design

intentions

System Build

Embedded System - usually final assembly into automated equipment precedes installation at user-site

Standalone System – the computer system & instrumentation are shipped to site, inspected and installed in conjunction with the manufacturing / process equipment

(All system build carried out according to approved manufacturer design/assembly documentation)

Software Review

Software to be reviewed (inspection, walk-through etc) by independent developer(s)

Examined against formal procedures prior to testing

Ensure written / configured against pre-defined intentions and in accordance with programming standards

Design (& Development) Review

Formal and systematic verification that specified requirements are covered by the design and development activities Supported by a structured set of lifecycle documentation May be a series of reviews throughout system design and

development To verify adherence to Requirements Traceability Matrix Can encompass elements of “acceptance testing” Requirements and Design intentions should be agreed before

significant code development Findings to be documented in a Design Review Report

Acceptance Testing

Proving the correct operation of software, hardware, and instrumentation, as defined by the URS and FS

Based on approved Test Specifications, and formally reported

Test specifications to include objectives, procedures and “acceptance criteria”

To focus on GxP and other critical functions and data Determine level of testing to support Lifecycle

“Qualifications”

Acceptance Testing

Depending on circumstances can encompass system development / build testing: Software development tests Hardware manufacturing tests System integration tests Instrument manufacturing / calibration tests SAT (and FAT)

Tests during & on completion of manufacture to be to pre-defined procedures and documented

Acceptance Testing

Factory Acceptance Testing (FAT) Pre-delivery Normally a “contractual milestone” For standalone systems - without connection to

field instrumentation, with an agreed level of process simulation

Testing constraints to be documented Opportunity to identify problems best resolved in

Supplier environment

Acceptance Testing

Site Acceptance Testing To determine that the system and any associated

equipment has not been damaged, and functions correctly in the operating environment

Normally a repeat of the FAT plus tests possible with process, instrumentation, interfaces, and service connections in place

With adequate level of test procedures may be combined with engineering commissioning to provide necessary test data for IQ and OQ

Calibration of Instrumentation

Pre- and post-delivery, to defined, approved procedures

Test equipment documented, and traceable back to acceptable standards

Calibration test results retained Establish calibration interval depending on

criticality, robustness, sensitivity, and operational experience

Qualification

Installation Qualification (IQ) confirms: Hardware, electrical connections, data highways, field

instrumentation, field cabling (and associated electrical & pneumatic equipment) is installed to documented design / standards

Software loaded correctly Basic system functions operate satisfactorily on power-up System configuration / calibration Field instrumentation calibrated Lifecycle and associated support documentation approved

and available

Qualification

Operational Qualification (OQ) - confirms that operation of system hardware, software, I/O devices and field instrumentation will function satisfactorily under normal operating conditions and, where appropriate, under realistic stress conditions

Performance Qualification (PQ) - normally carried out in conjunction with process qualification to confirm the correct operation of all system components, associated equipment, people and procedures that combine to run the manufacturing process

Validation

Qualification / Validation Reports – on successful completion of qualification testing and approved summary reports, a Validation Report will confirm that the system is ready for use in the manufacturing process for which it was designed

Operation & Maintenance

To ensure validation status is maintained: Quality, Maintenance and Calibration regime Configuration Management Change Control

Reference to critical process parameters / data and Requirements Traceability Matrix

Periodic Reviews and Internal Audits System reliability, repeatability, performance & diagnostic data Approved Lifecycle document status and accuracy SOP status and use

System Retirement

Decommissioning to include archiving data and software

Archive Report to describe approach, list documents, raw data, and electronic records

Verification of critical instrument calibration Special care with preservation and availability of

GxP records throughout their retention period, as required by of 21 CFR Part 11, and associated predicate rules

Conclusions

GAMP Principles - can be applied effectively to process control systems, both embedded and standalone

Good Engineering Practice - normal engineering commissioning activities can support the requirements of Qualification testing

GAMP – Process Control SIG

Q. What’s next? A. Produce a Good Practice Guide

Work underway to expand on the work done for the new GAMP 4 publication and produce a supplementary Good Practice Guide for “Validation of Process Control Systems”

Validation of Process Control Systems Guide

Proposed Contents Introduction, Background, Definitions Regulatory Considerations Supplier Assessments Standalone and Embedded Systems Importance of Good Specifications Manufacturing Parameters & Quality Data Lifecycle of Process Control Systems Criticality Assessment Systems Specification, Design, Development and Review

Validation of Process Control Systems Guide

Proposed Contents (continued) Factory Acceptance Tests Installation Qualification Operational Qualification Maintenance Calibration Change Management Review of Existing Systems Retirement / De-commissioning New Technologies

Validation of Process Control Systems Guide

Proposed Contents (continued) Appendices

Critical Parameters & Data Software Categories for Control Systems Postal Audit of Suppliers NAMUR guidance documents

GAMP Liaison

Thanks to

Sion Wyn & John Andrews

Tony de Claire

Process Control SIG

Any Questions?