1. Introduction to GAMP4

2. IF IT’S NOT DOCUMENTED IT’S A RUMOUR!

3. GAMP Guide History
1994 – UK Pharmaceutical Industry Computer System Validation Forum set up (now known as the GAMP forum)
1994 – First draft issued
1995 – Version 1
1996 – Version 2
1998 – Version 3
2001 – Version 4
With GAMP4, the target audience has been expanded from just pharmaceuticals to the whole healthcare industry including biotechnology and medical devices. The scope has been expanded to cover automated systems within Good Clinical Practice (GCP), Good Laboratory Practice (GLP) and Good Distribution Practice (GDP) in addition to the original Good Manufacturing Practice (GMP) environment.
GAMP4 launched in Amsterdam 3&4 Dec 2001
Re-running sessions at ISPE Birmingham conference May if anyone missed out and wants to attend

4. Lots of Nasty Acronyms GCP GDP GLP GMP GxP URS VMP IQ OQ PQ SOP
GCP Good Clinical Practice
GDP Good Distribution Practice
GLP Good Laboratory Practice
GMP Good Manufacturing Practice
GxP All of the above!! Sometimes cGxP with ‘c’ for ‘current’
URS User Requirements Specification
VMP Validation Master Plan
IQ Installation Qualification
OQ Operational Qualification
PQ Performance Qualification
SOP Standard Operating Procedure
All from GAMP4 acronym list

5. Jargon for ‘project’ activities
GAMP4 – “Good Automated Manufacturing Practice” as defined in the GAMP4 Guide for Validation of Automated Systems. A set of guidelines for both users and suppliers – MORE LATER!
Validation – “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes”
Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”.
Operational Qualification [OQ] - “Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”.
Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.
GAMP4
Validation
Installation Qualification [IQ]
Operational Qualification [OQ]
Performance Qualification [PQ]
All from GAMP4 glossary
Validation – difference between ‘testing’ and ‘validation’ is that you can test without either documenting the result or verifying against pre-determined specification
Installation qualification – activities such as checking equipment powers up, communicates etc
Operational qualification – activities from loop testing, control of individual valves, motors, etc through to run-throughs of sequences
Performance qualification – typically requires test batches to be produced in order to check quality attributes are met

6. Jargon continued…
Calibration – “The set of operations which establish, under specified conditions, the relationships between values indicated by a measuring instrument, or values represented by a material measure or a reference material, and the corresponding values of a quantity realised by a reference standard.”
Change Control – “A formal process by which qualified representatives of appropriate disciplines review proposed or actual changes to a computer system. The main objective is to document the changes and ensure that the system is maintained in a state of control.”
Life Cycle Concept – “An approach to computer system development that begins with identification of the user's requirements, continues through design, integration, qualification, user validation, control and maintenance, and ends only when commercial use of the system is discontinued.”
21 CFR part 11 – FDA regulation covering the use of electronic records and electronic signatures – MORE LATER!
Calibration
Change Control
Life Cycle Concept
21 CFR part 11
Calibration – usually as control engineers we’re interested in measuring instrument vs reference standard. Need to record procedure used, conditions (eg temp), traceability to reference standard.
Change Control – Have to record review process aswell as actual changes

7. Validation What is validation?
“Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes”
What needs to be validated?
Pharmaceutical Process which produce drugs for the human and animal Consumption.
What is validated?
Process
Ensures that the process does what it supposed to do backed with documentary proof.
Who is responsible for validation?
The manufacturer is responsible for obtaining the validation.

8. Validation.. What could be our responsibility?
Provide a system with documentary evidence that satisfies the Users requirement specification.
The system documentary evidence will be integrated into the overall process documentation which will be submitted for the process validation.

9. Principle of validation
Document what is to be done
Document how it is to be done
Do it
Produce documented evidence that it was done in accordance with the “how”
Demonstrate that it remains in a state of control

10. Where Does Process Validation begin?
Validate the API process beginning at the point where the structure of the active ingredient become evident.
Secondary Process
Packaging
Includes
Storage
Utilities
HVAC

11. GAMP4 Structure Principles and Framework objectives of the Guide
overview of validation
validation lifecycle
IT systems
process control systems
benefits of validation
good practice definitions
glossary
source material.
Appendices
Management activities
validation planning/reporting
risk assessment
project change control, etc
Development activities
specification
code production
testing
Operating activities
service level agreements
performance monitoring
archive, etc
GAMP
principles
and framework
APPENDICES
Management
Development
Operation
GOOD PRACTICE GUIDES
GAMP4 book
Good Practice Guides published separately
To include Validation of Process Control Systems, Calibration management, IT infrastructure
Training materials produced to support ISPE courses/seminars
TRAINING MATERIALS

12. Don’t worry that you can’t read it – going to go through each phase separately in minute
Note scope – from planning right through to retirement

13. GAMP Lifecycle User Requirements Functional Specification Hardware
Design
Configuration
/ coding
Process
Qualification
Operational
Installation
Integrated
Testing
Customer responsibility
Eurotherm
responsibility
Build
Joint
Ongoing
Operation
Software
Module
GAMP Lifecycle

14. GAMP and Traceability FAULT Update requirements documentation
Functional
Specification
Operational
Qualification
Document Control
Software
Design
Hardware
Design
Installation
Qualification
FAULT
Document Control
Update configuration
Re-Test
Integrated
Testing
Hardware
Build
Module
Testing
Configuration
/ coding
Configuration Control

15. GAMP4 Lifecycle – Planning and Definition
Supplier Assessment (appendix M2)
Covering both preliminary assessment and detailed supplier audit.
Makes recommendations for audit planning and execution and also contains example checklists for both postal (preliminary assessment) audits and full supplier audits.
Validation planning (appendix M1)
Hierarchy of Validation Master Plans and individual system Validation Plans including:
GxP criticality assessment
validation strategy to cover the revised lifecycle model
formal list of validation deliverables
formal acceptance criteria for each lifecycle phase
formal detail of change control and document management procedures to be followed
formal list of SOP’s to be created or updated
Actions and procedures required to maintain the validated state after handover from project to ongoing operation D e s i g n R v w T r a c e b i l t y M x C h a n g e o t r l D o c u m e n t M a g
PLANNING AND DEFINITION
User Requirements Specification (Appendix D1)
Has to specify:
Operational requirements (process control, calculations, etc)
Data requirements (capacity, access, archive, etc)
Interfaces (operator, other equipment, plant)
Environment (layout, physical)
Constraints (timescales, compatibility with other equipment, etc)
Life Cycle (development / test requirements, deliverables, etc)
Validation
Plan
Risk Assessment (Appendix M3)
Covering risk assessment as part of the validation process.
Initial risk assessment during URS generation to identify how much validation effort is required and which areas are critical to GxP product quality, safety, environmental protection, or business continuity.
Review of the risk assessment during the design and development stage (to ensure that choice of supplier / implementation method has not introduced additional risks)
Review of the risk assessment at completion of the design review prior to validation testing (to ensure that any problems identified or work-arounds implemented have not introduced additional risks).
Once the system is in ongoing operation, risk assessment should form part of the ongoing change control strategy.
The appendix also describes an example risk assessment process used to identify risks, categorise according to severity and likelihood and determine appropriate mitigation strategies.
Design Review and Traceability Matrix (Appendix M5)
Covering design review planning and deliverables. Typically, a review is required at the end of each specification stage.
In order for the review process to be meaningful, a formal traceability of user requirements through to design documentation and tests carried out is required. An example traceability matrix format is provided.
Change Control (Appendix M8)
Change request, disposition and authorisation, completion and approval
Document Management (Appendix M10)
Production, approval, issue, change, withdrawal, records and storage
Vendor
Preliminary Assessment
User
Requirement
Specification
Risk Assessment + Critical Parameters
Specification Approval
Supplier Detailed
Assessment
Validation planning (appendix M1)
Hierarchy of Validation Master Plans and individual system Validation Plans
Brought in line with current best practice:
GxP criticality assessment
revised validation strategy to cover the revised lifecycle model
formal list of validation deliverables
formal acceptance criteria for each lifecycle phase
formal detail of change control and document management procedures to be followed
formal list of SOP’s to be created or updated
Actions and procedures required to maintain the validated state after handover from project to ongoing operation
Supplier Assessment (appendix M2)
New material covering both preliminary assessment and detailed supplier audit.
Makes recommendations for audit planning and execution and also contains example checklists for both postal (preliminary assessment) audits and full supplier audits.
User Requirements Specification (Appendix D1)
Very similar to GAMP3 requirements with the addition of ‘Applicable GXP requirements’ and ‘other applicable regulations’ to the overview section.
Has to specify:
Operational requirements (process control, calculations, etc)
Data requirements (capacity, access, archive, etc)
Interfaces (operator, other equipment, plant)
Environment (layout, physical)
Constraints (timescales, compatibility with other equipment, etc)
Life Cycle (development / test requirements, deliverables, etc)
Risk Assessment (Appendix M3)
New material covering risk assessment as part of the validation process.
Initial risk assessment during URS generation to identify how much validation effort is required and which areas are critical to GxP product quality, safety, environmental protection, or business continuity.
Review of the risk assessment during the design and development stage (to ensure that choice of supplier / implementation method has not introduced additional risks)
Review of the risk assessment at completion of the design review prior to validation testing (to ensure that any problems identified or work-arounds implemented have not introduced additional risks).
Once the system is in ongoing operation, risk assessment should form part of the ongoing change control strategy.
The appendix also describes an example risk assessment process used to identify risks, categorise according to severity and likelihood and determine appropriate mitigation strategies.
Design Review and Traceability Matrix (Appendix M5)
New material covering design review planning and deliverables. Typically, a review is required at the end of each specification stage.
In order for the review process to be meaningful, a formal traceability of user requirements through to design documentation and tests carried out is required. An example traceability matrix format is provided.
Change Control (Appendix M8)
Very similar to GAMP3 (change request, disposition and authorisation, completion and approval)
Document Management (Appendix M10)
Very similar to GAMP3 (production, approval, issue, change, withdrawal, records and storage)
KEY:
User Responsibility
Joint Responsibility
Supplier Responsibility
DESIGN AND DEVELOPMENT

16. GAMP4 Lifecycle – Design and Development
Supplier
Quality
Plan D e s i g n R v w T r a c e b i l t y M x C h a n g e o t r l D o c u m e n t M a g
Quality and Project Planning (Appendix M6)
Plan needs to include:
User quality requirements (eg procedure references)
Supplier quality system (certification details, activities to be undertaken, and procedures controlling these, responsibilities for each activity)
Project Plan (eg Gantt chart)
Project organisation (contacts, project team names and titles, interface to QA)
Deliverable items (format, media)
Activities (milestones, start/end dates for activities, allocation of personnel)
DESIGN AND DEVELOPMENT
Functional Specification (Appendix D2)
Specification replies to technical requirements from URS and needs to include:
Functional requirements (process control, calculations, etc)
Data requirements (capacity, access, archive, etc)
Interfaces (operator, other equipment, plant)
Non-Functional Attributes (availability, maintainability)
Hardware Design Specification (Appendix D3)
Needs to include:
Computer System (main computer, storage, peripherals, interconnections)
Inputs and Outputs (instruments used, accuracy, isolation, range, timing)
Environment (temperature, humidity, EMC, etc)
Electrical Supplies (filtering, loading, earthing, UPS, etc)
Software Design / Module Design Specifications (Appendix D4)
Need to include:
Software Design Specification
System Description (split into modules / interaction of modules)
System Data (files, databases, etc)
Module Descriptions
Software Module Design Specification
Module Overview (function, split into sub-programs)
Module Data (files, databases, etc)
Sub-Program Descriptions (language, standards, functions, parameters, etc)
Sub-Program Data (locally declared items)
Test Specifications (Appendix D6)
Need to include:
Scope of Tests
Overview and Test Plan (procedure for test execution, ordering of tests, personnel required, etc)
Test Requirements (hardware, software, test equipment, test software/data, documentation)
Test Scripts (unique reference, traceability to specification, pre-requisites, test instructions, data to be recorded, acceptance criteria, post test actions)
Functional
Design
Specification
Acceptance Test Specification
Software Production (Appendix D5)
Each module needs to address:
Identification (name, version, controlling specification, history)
Traceability (commenting of additions / deletions, cross reference to change source)
Programming Standards
Source code review attempts to ensure that programming standards are applied and that modules are in accordance with specifications. IQ
Protocol
Hardware
Test
Specification
Hardware
Design
Specification
Software
Design
Specifications
Software Integration Test Spec OQ
Protocol
Software
Module
Specifications
Software Module Test
Specifications PQ
Protocol
Produce
Hardware
Produce
Software
Quality and Project Planning (Appendix M6)
Similar to GAMP3. Plan needs to include:
User quality requirements (eg procedure references)
Supplier quality system (certification details, activities to be undertaken, and procedures controlling these, responsibilities for each activity)
Project Plan (eg Gantt chart)
Project organisation (contacts, project team names and titles, interface to QA)
Deliverable items (format, media)
Activities (milestones, start/end dates for activities, allocation of personnel)
Functional Specification (Appendix D2)
Similar to GAMP3 with addition of relevant GxP procedures to overview section. Specification replies to technical requirements from URS and needs to include:
Functional requirements (process control, calculations, etc)
Data requirements (capacity, access, archive, etc)
Interfaces (operator, other equipment, plant)
Non-Functional Attributes (availability, maintainability)
Hardware Design Specification (Appendix D3)
Similar to GAMP3. Needs to include:
Computer System (main computer, storage, peripherals, interconnections)
Inputs and Outputs (instruments used, accuracy, isolation, range, timing)
Environment (temperature, humidity, EMC, etc)
Electrical Supplies (filtering, loading, earthing, UPS, etc)
Software Design / Module Design Specifications (Appendix D4)
Similar to GAMP3. Need to include:
Software Design Specification
System Description (split into modules / interaction of modules)
System Data (files, databases, etc)
Module Descriptions
Software Module Design Specification
Module Overview (function, split into sub-programs)
Module Data (files, databases, etc)
Sub-Program Descriptions (language, standards, functions, parameters, etc)
Sub-Program Data (locally declared items)
Test Specifications (Appendix D6)
Scope of Tests
Overview and Test Plan (procedure for test execution, ordering of tests, personnel required, etc)
Test Requirements (hardware, software, test equipment, test software/data, documentation)
Test Scripts (unique reference, traceability to specification, pre-requisites, test instructions, data to be recorded, acceptance criteria, post test actions)
Software Production (Appendix D6)
Similar to GAMP3. Each module needs to address:
Identification (name, version, controlling specification, history)
Traceability (commenting of additions / deletions, cross reference to change source)
Programming Standards
Source code review attempts to ensure that programming standards are applied and that modules are in accordance with specifications.
KEY:
User Responsibility
Joint Responsibility
Supplier Responsibility
DEVELOPMENT TESTING AND SYSTEM BUILD

17. GAMP4 Lifecycle – Testing, Build, Acceptanceo n f i g u r a t M e m D e s i g n R v w T r a c e b i l t y M x C h a n g e o t r l D o c u m e n t M a g
DEVELOPMENT TESTING AND SYSTEM BUILD
Hardware
Acceptance
Testing
Software Module
Testing
Testing (Appendix D6)
Test procedure (documented in specification) needs to address:
Pre-requisites (availability of documentation, test equipment, test data etc)
Testing Philosophy (witnessing requirements, documentation and retention of results, indelible recording of results, etc)
Test Script Execution (what happens if acceptance criteria are met / not met?)
Test Results File (completed tests, documentation of test incidents / faults, etc)
Integration
Software Integration
Testing
DESIGN REVIEW AND ACCEPTANCE
Factory Acceptance
Testing
Testing (Appendix D6)
Similar to GAMP3. Test procedure (documented in specification) needs to address:
Pre-requisites (availability of documentation, test equipment, test data etc)
Testing Philosophy (witnessing requirements, documentation and retention of results, indelible recording of results, etc)
Test Script Execution (what happens if acceptance criteria are met / not met?)
Test Results File (completed tests, documentation of test incidents / faults, etc)
KEY:
User Responsibility
Joint Responsibility
Supplier Responsibility
COMMISSIONING AND QUALIFICATION

18. GAMP4 Lifecycle – Commissioning, Qualificationr a t M e m T r a c e b i l t y M x C h a n g e o t r l D o c u m e n t M a g
COMMISSIONING AND QUALIFICATION
Installation
Qualification
Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”.
Operational Qualification [OQ] - “Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”.
Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.
Operational
Qualification
Validation Reporting (appendix M7)
New material detailing best practice for validation reporting for both individual lifecycle phases and the final validation report.
Performance
Qualification
Validation Report
Installation Qualification [IQ] – “Documented verification that a system is installed according to written and pre-approved specifications”.
Operational Qualification [OQ] - “Documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges”.
Performance Qualification [PQ] – “Documented verification that a system is capable of performing or controlling the activities of the processes it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.
Validation Reporting (appendix M7)
New material detailing best practice for validation reporting for both individual lifecycle phases and the final validation report
KEY:
User Responsibility
Joint Responsibility
Supplier Responsibility
ONGOING OPERATION

19. GAMP4 Lifecycle –Ongoing Operation
Appendix O5 – Performance Monitoring
Guideline for parameters to be monitored (eg disk utilization, response times) and appropriate notification mechanisms.
Appendix O6 – Record Retention, Archiving and Retrieval
Guideline to address retention (security, indexing, availability during full retention period, etc) of all GxP records. Particular requirements for electronic record archival and retrieval.
Appendix O7 – Backup and Recovery
Guideline for data and software backups to guard against physical loss or accidental deletion.
Appendix O8 – Business Continuity Planning
Guideline covering broad issues of business continuity planning including risk assessment; disaster recovery procedures; contingency planning; emergency response planning; training; and rehearsal of the continuity plan.
Appendix O9 – EU Guideline on Computerized Systems
APV Specialist section interpretation of the Annex 11 ‘Computerized Systems’ points.
Appendix O1 – Periodic Review
Guideline for establishing whether validated state is being maintained (checking operation of O2 to O8 plus assessing changes in environment, legislation, operating procedures, personnel)
Appendix O2 – Service Level Agreements
Procedure for defining support requirements and agreeing support provisions between user and supplier (including control of fault reporting, workarounds / patches / upgrades, spares / consumables, routine calibration, support for software tools / hardware / infrastructure etc)
Appendix O3 – Automated System Security
Guideline for ensuring control, integrity, availability and confidentiality of data.
Appendix O4 – Operational Change Control
Guideline for review, risk assessment, authorization, documentation and re-test of changes. Allows exclusion of like-for-like replacement and emergency repairs (though emergency repairs must undergo the same review and control ‘after the event’).
ONGOING OPERATION
Change
Control
Service Level Agreement
Periodic Review
Performance Monitoring
System Security
Record Retention
Backup and Recovery
Business Continuity Planning
RETIREMENT
Retirement
Appendix O1 – Periodic Review
Guideline for establishing whether validated state is being maintained (checking operation of O2 to O8 plus assessing changes in environment, legislation, operating procedures, personnel)
Appendix O2 – Service Level Agreements
Procedure for defining support requirements and agreeing support provisions between user and supplier (including control of fault reporting, workarounds / patches / upgrades, spares / consumables, routine calibration, support for software tools / hardware / infrastructure etc)
Appendix O3 – Automated System Security
Guideline for ensuring control, integrity, availability and confidentiality of data.
Appendix O4 – Operational Change Control
Guideline for review, risk assessment, authorization, documentation and re-test of changes. Allows exclusion of like-for-like replacement and emergency repairs (though emergency repairs must undergo the same review and control ‘after the event’).
Appendix O5 – Performance Monitoring
Guideline for parameters to be monitored (eg disk utilization, response times) and appropriate notification mechanisms.
Appendix O6 – Record Retention, Archiving and Retrieval
Guideline to address retention (security, indexing, availability during full retention period, etc) of all GxP records. Particular requirements for electronic record archival and retrieval.
Appendix O7 – Backup and Recovery
Guideline for data and software backups to guard against physical loss or accidental deletion.
Appendix O8 – Business Continuity Planning
Guideline covering broad issues of business continuity planning including risk assessment; disaster recovery procedures; contingency planning; emergency response planning; training; and rehearsal of the continuity plan.
Appendix O9 – EU Guideline on Computerized Systems
APV Specialist section interpretation of the Annex 11 ‘Computerized Systems’ points.
KEY:
User Responsibility
Joint Responsibility
Supplier Responsibility

20. GAMP Hardware and Software Categories
Risk of failure increases with the progression from standard to bespoke.
Many systems are built up multiple components of various categories.
Validation strategy needs to reflect this in order to ensure that effort is correctly focused.

21. GAMP Software Categories (1)
CATEGORY 1 – Operating Systems
VALIDATION APPROACH - Record version (include service pack). The Operating System will be challenged indirectly by the functional testing of the application.
PROCESS CONTROL SYSTEM EXAMPLES
Instrument operating system is usually not separable from firmware – see category 2
Most SCADA or DCS workstation software runs on one of the Microsoft Windows ® operating systems

22. GAMP Software Categories (2)
CATEGORY 2 – Firmware
VALIDATION APPROACH
For non-configurable firmware record version. Calibrate instruments as necessary. Verify operation against user requirements.
For configurable firmware record version and configuration. Calibrate instruments as necessary and verify operation against user requirements.
Manage custom (bespoke) firmware as Category 5 software
PROCESS CONTROL SYSTEM EXAMPLES
Instrument firmware including set-up parameters.
3-Term Controllers, Recorders, etc

23. GAMP Software Categories (3)
CATEGORY 3 – Standard Software Packages
VALIDATION APPROACH
Record version (and configuration of environment) and verify operation against user requirements.
Consider auditing the supplier for critical and complex applications.
PROCESS CONTROL SYSTEM EXAMPLES
Provided that ‘off the shelf’ solutions are purchased rather than creating bespoke toolkits:
Historical data viewers
Statistical analysis packages
Configuration management tools
Application development tools
Diagnostic tools

24. GAMP Software Categories (4)
CATEGORY 4 – Configurable Software Packages
VALIDATION APPROACH
Record version and configuration, and verify operation against user requirements.
Normally audit the supplier for critical and complex applications.
Manage any custom (bespoke) programming as Category 5.
PROCESS CONTROL SYSTEM EXAMPLES
Control schemes configured from library blocks
Simple mimics
Recipes

25. GAMP Software Categories (5)
CATEGORY 5 – Custom (Bespoke) Software
VALIDATION APPROACH
Audit supplier and validate complete system .
PROCESS CONTROL SYSTEM EXAMPLES
Sequence Function Charts
Custom reporting using SQL queries
Complex mimics running scripts

26. GAMP Software Categories Spreadsheets / Tools
Special Considerations for Spreadsheets
Can fall into category 3, 4 or 5 depending on use.
Examples:
Category 3 – used purely to generate a paper document
Category 4 – more complex application involving templates
Category 5 – spreadsheet application using custom macros
Application Development and Diagnostic Tools
Can be bespoke or off-the-shelf
Validation requirements depend on software category and on whether the tool directly supports the business process (eg application builder) or only supports the development or management of applications (eg configuration management tool)

27. GAMP Hardware Categories
CATEGORY 1 – Standard Components
VALIDATION APPROACH
Record model, version, serial number. Verify correct installation / connection. Apply change control.
CATEGORY 2 – Custom Built Components
As for standard components but also require a design specification and acceptance test. Supplier may be audited.

28. The Eurotherm GAMP Offering
AIM – to understand how Eurotherm interprets the GAMP lifecycle and software / hardware categories
GAMP?

29. Example Architecture 1 – Control System
Ethernet
Eurotherm
Suite
Server /
Viewer
ALIN
Visual
supervisor
Profibus
2500 I/O

30. Example Categorisation 1 – Control System
HARDWARE
SOFTWARE
GAMP4 SOFTWARE CATEGORIESY PC PC
Windows NT
1 – Operating System
Eurotherm Suite
Eurotherm
Suite
Viewer
Database, Security, Alarming, Mimics,
Trending.
2 - Firmware
3 – Standard Software Package
4 - Configurable Software Package
5 - Custom Software
T800
T800
Visual
supervisor
Continuous Control
and mimics
GAMP4 HARDWARE CATEGORIES
Sequencing
1 – Standard Components
2 - Custom Built Components
2500 I/O
2500
2500

31. Example Architecture 2 – Graphic Recorders
Ethernet
PC viewer running Bridge 5000
Data PC running Review
5180V
5180V

32. Example Categorisation 2 – Graphic Recorders
Remote PC PC
Windows NT
Windows NT (inc ftp server)
Review
Bridge 5000
Review
configuration
Config
5180V
5180V
5180V
Recorder configurations shown as category 4
Also available treated as category 2 for simple configurations only (no user screens, no maths channels)
Software Categorisation
1 – operating system
2 - parameterised firmware
3 – ‘off the shelf’
4 - configured
5 - coded

33. Project Deliverables Compared
PLANNING
AND
DEFINITION
Category 2 Graphic Recorder
Category 4 / 5 Visual Supervisor
Quality Plan
Standard Functional Spec
Functional Specification
SPECIFICATION, DESIGN, CONSTRUCTION
Standard IQ Spec
Hardware
DS + TS IQ
Spec
Module
FS +TS OQ
Spec
Produce
Hardware
Produce
Configuration
Produce
Hardware
Produce
Software
Hardware Test
SW Module Test
DEVELOPMENT TESTING AND SYSTEM BUILD
Internal Test
Integrated Test
DESIGN REVIEW
& ACCEPTANCE
Factory Acceptance
Installation Qualification
Installation Qualification
COMMISSIONING AND QUALIFICATION
COMPLETION OF QUALIFICATION AND ONGOING OPERATION (TO CUSTOMER PROCEDURES)

34. End Slide