GAMP - Process Control SIG

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

Any Questions? Tony de Claire Process Control SIG

GAMP - Process Control SIG