Transcript No Slide Title

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 and Project Plan


Quality System
Capability
Audits
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 usersite
 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, walkthrough etc) by independent developer(s)
 Examined against formal procedures prior to
testing
 Ensure written / configured against predefined 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