gamp - process control sig gamp 4 + beyondlibvolume2.xyz/.../gamp/gamppresentation2.pdf · gamp -...

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

BBBB 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?