Gamp y66s
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3i3n4
Overview 26281t
& View Gamp as PDF for free.
More details 6y5l6z
- Words: 1,882
- Pages: 45
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 of “” background Active with / instigating a variety of contributor s
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 , 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 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 focused and auditable system development Establish test acceptance criteria maintenance of the system
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
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 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, 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
ed by a structured set of lifecycle documentation May be a series of reviews throughout system design and development To adherence to Requirements Traceability Matrix Can encom 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 Lifecycle “Qualifications”
Acceptance Testing
Depending on circumstances can encom 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 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 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 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 of “” background Active with / instigating a variety of contributor s
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 , 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 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 focused and auditable system development Establish test acceptance criteria maintenance of the system
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
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 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, 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
ed by a structured set of lifecycle documentation May be a series of reviews throughout system design and development To adherence to Requirements Traceability Matrix Can encom 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 Lifecycle “Qualifications”
Acceptance Testing
Depending on circumstances can encom 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 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 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
Related Documents 3h463d
Gamp y66s
April 2022 0
Gamp Classification 6e66
November 2019 167
Gamp Ppt x4b1a
October 2021 0
Gamp 5 4o6b1y
November 2019 60
Ispe Gamp Gxp2nded Toc w5i6n
December 2019 39
V Model - Gamp 6u2n68
April 2023 0More Documents from "sina20795" 2b2j6
1 System302-7 Components 4a1k1y
October 2022 0