1 / 45

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

mandel
Télécharger la présentation

GAMP - Process Control SIG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GAMP - Process Control SIG GAMP 4 + Beyond Tony de Claire

  2. 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

  3. 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)

  4. 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)

  5. 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)

  6. 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

  7. 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

  8. 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

  9. 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 )

  10. Planning & Definition • Define Scope • Software • Hardware • Instrumentation • Electrical • Mechanical

  11. Planning (continued) • Supplier Assessment • Quality System • Capability • Audits • Quality and Project Plan • Define structure of lifecycle documents • GxP Criticality and Compliance Risk Assessment

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. Design Specifications Specifications for system design: • Software • Hardware • Instrumentation ………… may include mechanical and electrical general arrangement drawings

  19. 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

  20. 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

  21. Detailed Design Documentation • Interconnection Drawings • Connections to field instrumentation • Wiring termination, identification, rating, and polarity • Sufficient detail to enable assembly, installation, and fault diagnosis

  22. Hardware Design Specification • Defines architecture and configuration of the hardware, including: • Controllers • PCs • Input / Output types & allocation • System Interfaces

  23. 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

  24. 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

  25. 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

  26. 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)

  27. 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

  28. 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

  29. 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”

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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”

  41. 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

  42. 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

  43. 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

  44. GAMP Liaison Thanks to Sion Wyn & John Andrews

  45. Any Questions? Tony de Claire Process Control SIG

More Related