s
Introduction Contents
Prerequisites for Configuring Automated Systems in a GMP
Environment
1
Requirements for Automated Systems in a GMP
Environment
2
Specification
3
Guidelines for Implementation in a GMP Environment with Standard SIMATIC PCS 7 Software
4
Supporting Functions during
Qualification
5
Additional Hardware /
Software Components
6
Glossary Index
SIMATIC PCS 7 V6.1
GMP - Engineering Manual
Guidelines for implementing automation projects
in a GMP environment
Edition 12/2006
A5E00362933-03
Safety-Related Notices
Notices that you should observe to ensure your own personal safety and to avoid damage to property and equipment can be found in the relevant technical manuals. The safety of pharmaceutical products of prime importance to the pharmacist must be evaluated by the pharmaceutical company itself. This document provides information on this topic.
Qualified Personnel
Only qualified personnel should be allowed to install and work on this equipment. Qualified persons are defined as persons who are authorized to commission, to ground, and to tag circuits, equipment, and systems in accordance with established safety practices and standards.
Trademarks
SIMATIC®, SIMATIC HMI®, SIMATIC IT® and SIMATIC NET® are registered trademarks of Siemens AG.
Third parties using for their own purposes any other names in this document which refer to trademarks might infringe upon the rights of the trademark owners.
Introduction
Purpose of the Manual
This manual describes what is required of the system, the software and the procedures for configuring SIMATIC PCS 7 from a GMP perspective. The relationship between requirements and implementation is illustrated based on practical examples.
Intended Audience
The manual is intended for all planners, plant operators, developers of branch- specific control system concepts, project leaders and configuration engineers, maintenance and service personnel who implement process control systems in a GMP environment. It describes approaches to the implementation of automation solutions with SIMATIC STEP 7 where GMP is mandatory.
Basic Knowledge Required
To understand this manual, you should be familiar with the basics of
SIMATIC PCS 7. Experience of GMP as practiced in the pharmaceutical industry is an advantage.
Disclaimer
This manual is a guide for system users and configuration engineers that will assist them in integrating the SIMATIC PCS 7 process control system in a GMP
environment with regard to validation and taking into account the aspects 21 CFR Part 11.
We have checked the contents of this manual for agreement with the hardware and software described. Since deviations cannot be precluded entirely, we cannot guarantee full agreement. The information in this document is checked regularly for system changes or changes to the regulations of the various organizations and necessary corrections will be included in subsequent issues. We would be thankful for any proposed improvements that should be sent to the Competence Center Chemical, Pharma in Karlsruhe (Germany).
Validity of the Manual
The information in this manual is valid for SIMATIC PCS 7 V6.1 incl. SP1. The components examined are PCS 7-ES, PCS 7-OS, SIMATIC BATCH and the options Central Archive Server, StoragePlus and SIMATIC IT Historian. Information relating to the precise compatilbility between the individual components and PCS 7 V6.1 SP1 can be found on the CD-ROM Catalog CA01. The CD-ROM Catalog is available on the Internet at: www.siemens.com/automation/ca01.
Further Sources of Information
The system documentation of the process control system SIMATIC PCS 7 V6.1 is an integral part of the SIMATIC PCS 7 system software. It is available to all users as online help (HTML Help) or as electronic documentation in Acrobat Reader format (PDF):
• Electronic manuals SIMATIC PCS 7 V6.1 SP1
- The electronic manuals are on the PCS 7 Toolset DVD
Structure of the Guidelines
This manual supplements the existing SIMATIC PCS 7 manuals. The guidelines are useful not only during configuration, but are also intended to provide an overview of the requirements for configuration and what is expected of automation systems in a GMP environment.
Laws and guidelines, recommendations and mandatory specifications that represent the basis for configuration of automation systems are explained.
All the necessary functions and requirements for hardware and software
components are also described and this should make the selection of components easier.
Based on examples, the use of hardware and software is explained and how it is configured or programmed to meet the requirements. More detailed explanations can be found in the standard documentation.
In the appendix, you will find a Glossary in which all the important terms are described again briefly and an index of topics.
Conventions
Further Support
If you have questions on the use of the products described in the manual and cannot find answers here, please speak to your Siemens contact in your local office.
You can find addresses of contacts at:
http://www.siemens.com/automation/partner
You will find the guide to the range of technical documentation available for the individual SIMATIC products and systems at:
http://www.siemens.de/simatic-tech-doku-portal
The online catalog and the online ordering system is available to you at:
http://mall.automation.siemens.com/
If you have questions on the manual, please contact the Competence Center Pharma:
E-mail: [email protected] Fax: +49 721 595 6930
You will find more information on the range offered by Siemens for the pharmaceutical industry at:
http://www.siemens.com/pharma
Training Center
To familiarize you with the SIMATIC S7 automation system, we offer a range of courses. Please contact your regional training center or the central training center in D 90327 Nuremberg, Germany.
Phone: +49 (911) 895-3200.
Internet: http://www.sitrain.com
Technical support
You can contact Technical Support for all A&D products
• using the Web form for a support request
http://www.siemens.de/automation/support-request
• Phone: + 49 180 5050 222
• Fax: + 49 180 5050 223
You will find more detailed information on our technical support on the Internet at http://www.siemens.de/automation/service
Service & Support on the Internet
In addition to our documentation services, you can also make use of our know-how on the Internet.
http://www.siemens.com/automation/service&support Here, you will find:
• The Newsletter that keeps you constantly up to date with the latest information on the products you use.
• The documents you need using the search features in Service & Support.
• A forum in which users and specialists worldwide exchange information and experience.
• Your local contacts for Automation & Drives.
• Information on local service, repairs, and spare parts. If you look in "Services", you will find much more information on a wide range of topics.
Contents
Introduction iii
Contents vii
1 Prerequisites for Configuring Automated Systems in a GMP Environment 1-1 1.1 Life Cycle Model ... 1-2 1.2 Regulations and Guidelines... 1-9 1.3 Responsibilities... 1-11 1.4 Approval Process... 1-12 1.5 Software Categorization of Control Systems... 1-14 2 Requirements for Automated Systems in a GMP Environment 2-1 2.1 Software Categorization ... 2-2 2.1.1 Software Creation ... 2-4 2.1.1.1 Use of Typicals for Programming ... 2-4 2.1.1.2 Identification of Software Modules / Typicals ... 2-4 2.1.1.3 Changing Software Modules / Typicals ... 2-4 2.2 Hardware Categorization ... 2-5 2.3 Configuration Management ... 2-5 2.3.1 Configuration Identification ... 2-6 2.3.2 Configuration Control... 2-6 2.3.2.1 Version Control ... 2-6 2.3.2.2 Change Control... 2-6 2.4 Access Protection and User Management ... 2-7 2.4.1 Using Access Protection in a System... 2-7 2.4.2 Requirements for the User ID and Password ... 2-8 2.4.3 Chip Cards and Biometric Systems... 2-8 2.5 Electronic Signatures... 2-9 2.5.1 Conventional Electronic Signatures... 2-9 2.5.2 Electronic Signatures Based on Biometrics... 2-10 2.5.3 Security Measures for User IDs/Passwords ... 2-10 2.6 Audit Trail... 2-11 2.7 Time Synchronization ... 2-11 2.8 Archiving Data ... 2-12 2.9 Data Backup ... 2-12 2.9.1 Application Software ... 2-13 2.9.2 Process Data ... 2-14 2.10 Retrieving Data Backups ... 2-14 2.11 Use of Third-Party Components ... 2-15
3 Specification 3-1 3.1 Criteria for Selecting Hardware ... 3-2 3.2 Criteria for Selecting Software ... 3-3 3.2.1 Basic Software for User Management... 3-3 3.2.2 Additional Software - Image & Partition Creator... 3-3 3.2.3 Basic Software for the Engineering System ... 3-3 3.2.3.1 Process Control Libraries ... 3-4 3.2.3.2 Multiproject Engineering ... 3-4 3.2.4 Additional Software - Engineering System ... 3-4 3.2.4.1 Version Cross Checker... 3-4 3.2.4.2 Import/Export Assistant... 3-4 3.2.4.3 Controller Tuning with the PCS 7 PID Tuner... 3-5 3.2.4.4 Simulation with S7-PLCSIM ... 3-5 3.2.5 Basic Software - Operator Station ... 3-6 3.2.6 Additional Software for an Operator Station ... 3-6 3.2.7 Basic Software - SIMATIC BATCH... 3-7 3.2.8 Interfaces to Process Data with OS Software Connectivity Pack... 3-10 3.2.9 Additional Software for Long-term Archiving ... 3-12 3.2.9.1 Central Archive Server (CAS)... 3-12 3.2.9.2 StoragePlus ... 3-12 3.2.9.3 SIMATIC IT Historian... 3-12 3.2.10 Basic Software of Higher-level Systems... 3-13 3.3 User Requirements Specification ... 3-14 3.4 Functional Specification... 3-15 3.5 Design Specification ... 3-16 3.5.1 Specification of Automation Hardware ... 3-16 3.5.2 Specification of Automation Software... 3-18 4 Guidelines for Implementation in a GMP Environment with Standard SIMATIC
PCS 7 Software 4-1
4.1 Introduction ... 4-1 4.2 Software Categorization of SIMATIC PCS 7 ... 4-1 4.3 Software Installation ... 4-3 4.3.1 Operating System ... 4-3 4.3.2 SIMATIC PCS 7 Software... 4-5 4.4 Installation of Utilities and Drivers ... 4-8 4.4.1 Printer Drivers... 4-8 4.4.2 Virus Scanners ... 4-8 4.5 Multiproject ... 4-9 4.5.1 Engineering... 4-9 4.5.2 Views ... 4-11 4.6 SIMATIC NET Settings ... 4-14 4.6.1 Setting up the OS, OS Client, OPC Server, and SIMATIC BATCH ... 4-15
4.7.3 Changing the User Software ... 4-22 4.8 Creating Software Modules ... 4-23 4.8.1 General ... 4-23 4.8.2 Example of a Process Tag Type ... 4-25 4.9 Setting up Process Value Archives ... 4-27 4.10 Import/Export Assistant (IEA) ... 4-31 4.11 Automatic Generation of Block Icons ... 4-32 4.12 Activating and Deactivating Simulation Software ... 4-34 4.13 OS Project Editor ... 4-35 4.14 Creating Overview Pictures ... 4-36 4.15 Integrating SIMATIC BATCH ... 4-37 4.15.1 BATCH Definition of Terms ... 4-37 4.15.2 Conformity with the ISA-88.01 Standard ... 4-37 4.15.3 ISA-88.01 - Software Model SIMATIC PCS 7 ... 4-38 4.15.4 Implementation of the ISA-88.01 Concept... 4-39 4.16 Configuring SIMATIC BATCH ... 4-41 4.17 Setting up Access Protection... 4-42 4.17.1 How Access Protection Works under Windows and in PCS 7 Process Mode4-44 4.17.2 Permission Management in Windows ... 4-45 4.17.3 User Management ... 4-46 4.17.4 Security Settings of Password Policy ... 4-48 4.17.5 Security Mechanisms for Account Lockout Policies ... 4-49 4.17.6 Security Settings for Audit Policy... 4-50 4.17.7 Configuring SIMATIC Logon... 4-52 4.18 Disabling the Windows Level in Process Mode (Runtime)... 4-62 4.18.1 Disabling on the SIMATIC PCS 7 OS... 4-62 4.18.2 Lockout by Configuration ... 4-63 4.18.3 Security with Configuration Settings in WINDOWS... 4-63 4.19 Audit Trail... 4-64 4.19.1 PCS 7 OS ... 4-64 4.19.2 SIMATIC BATCH ... 4-65 4.20 Time Synchronization ... 4-67 4.20.1 Concepts for Time Synchronization... 4-68 4.20.2 Example of Configuring Time Synchronization over Ethernet (OS Server as
Time Master)... 4-69 4.21 Lifebeat Monitoring ... 4-77 4.21.1 SIMATIC PCS 7... 4-77 4.21.2 Third-Party Systems ... 4-78 4.22 Use of SIMATIC BATCH Reports... 4-79 4.23 Backing up the System/User Software ... 4-80 4.23.1 Backing up the User Software ... 4-80 4.23.2 Backing up the Operating System and SIMATIC PCS 7... 4-80 4.24 Long-term Archiving... 4-82 4.24.1 Long-term Archiving with the Central Archive Server (CAS)... 4-82 4.24.1.1 How It Works ... 4-82 4.24.1.2 Integration in PCS 7... 4-84 4.24.1.3 Access Protection ... 4-87 4.24.1.4 Time Synchronization ... 4-87 4.24.1.5 Network Security... 4-87 4.24.1.6 Integrating the CAS in Lifebeat Monitoring... 4-88 4.24.1.7 OS Client for Visualizing CAS Data... 4-88 4.24.1.8 Audit Trail... 4-88 4.24.1.9 Archiving and Transferring to the CAS ... 4-89 4.24.1.10Data Display ... 4-89 4.24.2 Long-term Archiving with StoragePlus ... 4-90 4.24.2.1 How StoragePlus Works... 4-90 4.24.2.2 Software Packages of StoragePlus ... 4-91
4.24.2.3 Installation of StoragePlus ... 4-91 4.24.2.4 Security and Access Concept... 4-92 4.24.2.5 Time Synchronization ... 4-93 4.24.2.6 Network Security... 4-94 4.24.2.7 Audit Trail... 4-94 4.24.2.8 Configuration of Long-term Archiving ... 4-95 4.24.2.9 Configuration of the StoragePlus Database ... 4-97 4.24.2.10Transferring Archive Data (Backup) ... 4-98 4.24.2.11Retrieving Data Backups ... 4-101 4.24.2.12Restoring the System ... 4-101 4.24.2.13Data Displays... 4-101 4.24.3 Long-term Archiving with SIMATIC IT Historian ... 4-102 4.25 Data Exchange with the Plant Management Level... 4-103 4.26 Uninterruptible Power Supply ... 4-104 4.26.1 Configuration of Uninterruptible Power Supplies... 4-106 4.26.2 UPS Configuration over Digital Inputs ... 4-108 4.27 Creating SCL, C, VB Scripts... 4-110 4.28 SIMATIC PCS 7 Add-Ons... 4-111
5 Supporting Functions during Qualification 5-1
5.1 Introduction ... 5-1 5.2 Qualification of Automation Hardware ... 5-2 5.3 Qualification of Automation Software ... 5-5 5.3.1 Qualification of Standard Software ... 5-5 5.3.2 System Programs from SIMATIC PCS 7... 5-7 5.3.3 Installed Authorizations of SIMATIC PCS 7 ... 5-8 5.3.4 Qualification of the Application Software ... 5-9
6 Additional Hardware / Software Components 6-1
6.1 Time Synchronization ... 6-1 6.2 Solutions for Special Automation Tasks ... 6-2 6.3 SIMIT Simulation Software ... 6-3 6.4 Using MASTERGUARD UPS Systems ... 6-4
Glossary Glossary-1
Index Index-1
1 Prerequisites for Configuring Automated Systems in a GMP Environment
Before automated systems can be configured in a GMP Environment, approved specifications such as the user requirements and Functional Specification must exist. When creating these specifications, requirments stipulated in standards, recommendations and guidelines must be taken into account. This chapter lists the most important of these regulations as well as various specifications (URS, FS, DS).
1.1 Life Cycle Model
Good engineering practice (GEP) means the use and adherence to defined guidelines in the planning and configuration of systems. GEP includes the entire life cycle of a system. The schematic below shows the life cycle model of a system.
This manual is oriented on the information contained in the GAMP ® 4 Guide for Validation of Automated Systems. The procedures stipulated in GAMP ® 4 are explained and illustrated by practical examples.
Key to the life cycle model
Abbreviation/Acronym Description
VP Validation Plan1
QP Qualification Plan
QPP Quality and Project Plan
URS 2User Requirements Specification
FS Functional Specification
DS Design Specification (this includes, for example, P&I charts, software and software module specification and hardware design specification, etc.)
FAT Factory Acceptance Test
SAT Site Acceptance Test
IQ Installation Qualification
OQ Operational Qualification
PQ Performance Qualification
VR Validation Report
QR Qualification Report
1 To improve readability and recognition of familiar terminology, not all terms and abbreviations/acronyms were translated in the German version.
2 The meaning of the terms used in GAMP ® 4 "User Requirements Specification" and
"Functional Specification" do not correspond to the German terms "Lastenheft" or
"Pflichtenheft" as used, for example, in VDI 3694 and VDI 2519.
Validation Plan
The Validation Plan is used to specify the methods used for validation or qualification and measures for validating, for example, an automation system. A Validation Plan should specify all validation activities and name those responsible for their implementation. Further topics that should be covered by a Validation Plan include:
• Documentation of the results of the validation activities
• All standard operation procedures (SOP) that relate to the system
• Preservation of the validation status of the system
A system-specific Validation Plan may be preceded by a generic Validation Master Plan (VMP or MVP).
Qualification Plan
In contrast to the Quality and Project Plan, a Qualification Plan (QP) describes all the qualification measures while the Quality and Project Plan deals mainly with project and quality management. The Qualification Plan contains detailed descriptions of the necessary test measures and a description of the
interdependencies of the individual tests. References to other test documents such as FAT or SAT and a description of the deviation management must also be integrated in the Qualification Plan.
Quality and Project Plan
In contrast to the Qualification Plan, the Quality and Project Plan (QPP) documents project and quality management. It documents, for example, procedures for
managing documents or the procedures for change control. It should also contain a description of the individual test phases during the life cycle of a system. The responsibilities within the project and the milestones must also be specified.
Specification:
The specification phase begins with the creation of a user requirements
specification. The User Requirements Specification is normally created by the user and describes the requirements that the system should meet. On completion of the user requirements specification, the Functional Specification is created, usually by the supplier. The Functional Specification (FS) describes the implementation and the functions of the system set out in the user requirements specification. This is
The functional and Design Specification also form the test basis for later
qualification. The following aspects should also be specified in the functional and Design Specification phase:
• Software structure
• Programming standards
• Name convention
• File naming convention
Implementation
The functions described in the Design Specification are implemented in the implementation phase. The requirements of the pharmaceutical industry, in particular, must be taken into account at this stage.
Based on the naming and file naming conventions decided in the specification phase, the software, software blocks and variables must be named and
documented so that the program code can be structured clearly. Blocks or software modules must be labeled uniquely with author, date created, version, and
comment. Versioning of these blocks is important to allow easier tracking of subsequent changes. Software source code must be explained in comments.
"Dead code", in other words parts of the user program that are no longer called due to changes in the programming must be removed or commented out.
User program code must be commented accordingly.
To be able to restore the last project engineering status if data is lost, regular backups must be made:
• Backup of the user program
• Following changes to the settings of PC components - full backup of the component involved
Project Change Control
Changes (deviations from the specification) during editing of the project must be documented. Depending on the changes made, it may be necessary to agree the changes with the system user. If errors occur or if changes are required, change requests should be used as documentation.
During the project engineering phase, numerous small changes become necessary. The changes should also be subject to a structured change control process. Due to their numbers and the often minor effects, suitable handling must also be devised for such changes. Here, for example, the grouping of several changes or simplified documentation and procedure (for example in the form of lists) would be conceivable.
FAT
On completion of the implementation, a Factory Acceptance Test (FAT) is often performed at the supplier's site. The purpose of this is to find and eliminate any errors in the programming prior to delivery.
The aim of the FAT is the acceptance by the customer to allow the system to be delivered in the tested status. The customer should follow the FAT and confirm that it was completed correctly in a concluding report.
SAT
The Site Acceptance Test (SAT) shows that an automated system works within its operating environment with interfaces to the instrumentation and plant sections according to the specification. The SAT can contain additional tests during the course of the FAT that are possible for the first time with connected field
instruments and plant sections as well as interfaces to neighboring systems. The SAT can be combined with commissioning.
Qualification
The FAT is followed by the technical commissioning3 (commissioning phase). In this phase, the system along with the user program that has been created is installed at the system user's site, the technology is commissioned, tested and qualified.
The commissioning phase and qualification phases can run sequentially or simultaneously. It is advisable to synchronize the activities of commissioning and qualification to save both time and costs.
The Qualification Plan should therefore be created in good time so that it is
possible to check whether or not tests already made during FAT or SAT need to be repeated during qualification. In this case, the documented FAT / SAT tests must be referenced in the qualification documents.
When creating the test documentation, tests and acceptance criteria must be described so that they are easy to understand. Test documentation, for example for FAT, SAT or qualification phases must be created according to the defined methodology so that the system user will accept it as material that can be referenced for qualification. Referencing previously performed tests during qualification saves tests being repeated and reduces qualification costs. One requirement for referencing test documentation is, however, that the test documentation is approved according to schedule.
To be able to reference test documentation, it must be completed in accordance with GMP principles and handed over to the qualification team.
Correctly labeled software backups and the complete technical documentation such as the process description, manuals etc. according to the agreed scope of the delivery, must be handed over to the system user. Among other things, the
archiving must be verified in the course of qualification.
Qualification Report
Based on the Qualification Plan, the qualification report (QR) sums up the test results of the tests performed and confirms the successful completion of the qualification phases.
Validation Report
The Validation Report (VR) sums up the results of the individual validation steps and confirms the validated status of the system. The creation of both the Validation Plan and the Validation Report is the responsibility of the customer.
Operation
Following successful qualification and subsequent operation (start of production) of the system, the plant must be serviced and maintained by the user. The
maintenance and service cycles must be defined and adhered to.
Change Control during Operation
If changes are made to an existing system, the procedures of the user for change control during operation must be used. Such changes must be clearly identified, described before they are made and the planned change approved for
implementation. After making the change and completing the defined
accompanying measures (for example repeating tests), the revision of the software must be incremented and the as-built documentation must be updated.
This is where good documentation of the software with suitable comments and logically structured application software prove their value.
After approval of the change requests, change specifications must be created and the life cycle is run through again. Depending on the extent and effects of the planned change to the existing documentation and the risk assessment of the change related to the existing plant, the effort involved during the life cycle and, in particular, the effort required for testing may vary greatly.
Risk Analysis
Risk analysis is a methodical procedure in which the process, the system or programs are analyzed in sufficient detail. The risks identified by the analysis for new installations and changes to plants are examined in terms of their results and effects on the (pharmaceutical) product are examined.
1.2 Regulations and Guidelines
When configuring automated systems requiring validation in a GMP environment, the recommendations and guidelines of various organizations should be adhered to. These are usually based on general guidelines such as Title 21 Code of Federal Regulations (21 CFR) of the American Food and Drug Administration (FDA) or the EU GMP Guideline Annex 11.
Regulation / Guideline
Issued by / Organization
Title Regulation /
Recommendation
Where Applicable Title 21 Code of
Federal Regulations (21 CFR)
FDA Part 11 Electronic records, electronic signature
Part 210 Current good manufacturing practice in
manufacturing, processing, packing, or holding of drugs;
General
Part 211Current good manufacturing practice for finished pharmaceuticals
Regulation USA and
importers into the USA
Annex 11 of the EU GMP Guideline
European Commission Directorate General III
Computer-aided Systems
Guideline Europe
Annex 18 of the EU GMP Guideline
European Commission Directorate General III
Good Manufacturing Practice for Active Pharmaceutical Ingredients
Guideline Europe
GAMP ® 4 ISPE GAMP ® 4 Guide for
Validation of
Automated Systems
Guideline Worldwide
NAMUR
Recommendation NE 58
NAMUR Execution of Process Control Projects Subject to Validation
Recommendation Europe
NAMUR
Recommendation NE 71
NAMUR Operation and
Maintenance of Validated Systems
Recommendation Europe
NAMUR
Recommendation NE 72
NAMUR Validation Support
by Use of Control Systems
Recommendation Europe
Note
This manual is based on the requirements of GAMP ® 4 and FDA 21 CFR Part 11.
Code of Federal Regulations Title 21 (21 CFR), Food and Drugs
The Code of Federal Regulations, Title 21 includes parts such as Parts 210 and 211. Part 11 (known as 21 CFR Part 11 is of particular importance for computer validation). This part deals with electronic records and electronic signatures.
Annex 11 of the EU GMP Guideline
Annex 11 of the EU GMP guideline is divided into 19 points and covers topics ranging from requirements for configuration, operation and change control for computerized systems in a GMP Environment. An interpretation of Annex 11 can be found in the GAMP ® 4 Guide in the form of an APV guideline for the validation of automated systems.
Annex 18 of the EU GMP Guideline
Annex 18 of the EU GMP guideline deals with good manufacturing practice for active pharmaceutical ingredients. This is intended as a GMP manual for the manufacture of active pharmaceutical ingredients within the framework of a suitable quality management system. Chapter 5 of Annex 18 deals with the process equipment and its use.
GAMP ® Guide for Validation of Automated Systems "GAMP ® 4"
The GAMP ® (Good Automated Manufacturing Practice) Guide for Validation of Automated Systems was compiled as a recommendation for suppliers and as a manual for users of automated systems in the manufacturing pharmaceutical industry. The current version "GAMP ® 4" was published in December 2001.
NAMUR Recommendations
NAMUR Recommendations are reports of the experience of the "Process Control Systems Special Interest Group of the chemical and pharmaceutical industry" for optional use by their members. They do not have the status of standards or directives. The following NAMUR recommendations are of particular interest with regard to configuration and the use of automated systems in a GMP Environment:
• NE58 "Execution of Process Control Projects Subject to Validation"
• NE71 "Operation and Maintenance of Validated Systems"
• NE72 "Validation Support by Use of Control Systems"
1.3 Responsibilities
When configuring automated systems in a GMP environment and creating the appropriate specifications, the responsibilities during the life cycle are defined as follows.
Documentation Location Responsibility User requirements
specification
User User creates and approves
Functional Specification Supplier Supplier creates / user approves Hardware Design
Specification Supplier Supplier creates / user approves
Software Design Specification
Supplier
Supplier creates / user approves System implementation Supplier Supplier creates / ideally checked
by user Factory Acceptance Test
FAT
Supplier Supplier performs / user approves
Site Acceptance Test SAT
User User performs / supported by supplier
Installation Qualification IQ
User User responsible / supplier and/or user performes
Operational Qualification OQ
User User responsible / supplier and/or user performes
Performance Qualification PQ
User User performs / supported by supplier
Change control during operation
User User performs / possibly supported by supplier
Shutdown User User performs / possibly supported by supplier
1.4 Approval Process
When changes are made to existing systems or when new systems are installed, certain approvals must be obtained during the various phases of system
configuration.
Several pertinent documents are listed below and the significance of their approval explained.
Quality and Project Plan
In contrast to the Qualification Plan, the Quality and Project Plan (QPP) documents project and quality management. It documents, for example, procedures for
managing documents or the procedures for change control. It should also contain a description of the individual test phases during the life cycle of a system. The responsibilities within the project must be defined.
Change control
Changes to an existing system (hardware / firmware, user software etc.) are proposed by the system user in a change request. This is approved and released by the user. This forms the basis of such a project.
User Requirements Specification
The User Requirements Specification describes the new requirements that the system is intended to meet based on the request described above. The User Requirements Specification is generally created by the system user but can also be created by the system supplier or a third party. The User Requirements Specification must always be checked and approved by the system user and the quality assurance department.
The User Requirements Specification should be adapted to the current situation during the planning phase and, if necessary, approved and released as a new version.
Functional Specification
The Functional Specification is normally created by the system supplier. Based on the User Requirements Specification or the change request, it describes the functions of the system in detail. The Functional Specification is created in
consultation with the system user and must be approved and released by the user.
The approved Functional Specification is used as the basis for creating the detailed specifications and for subsequent configuration.
Design Specification
The Design Specification (DS) like the Functional Specification is normally created by the system supplier. This is based on the Functional Specification and
supplements this with detailed descriptions, for example, of the hardware and software used, process variable lists etc. The Design Specification is created with the co-operation of the system user and must be approved and released by the system user.
Qualification documents (test documents)
The test documents must provide evidence that the requirements are met and that all functions were implemented as specified. This is done by creating suitable test documents that document test planning, test execution and the test results.
The test documents must be created by the system supplier according to the specifications of the Functional Specification or the detailed specification. The test documents must be checked and approved by the system user.
If tests performed previously in the FAT or SAT are referenced within the framework of qualification, this must be included in the Qualification Plan and approved by the user.
1.5 Software Categorization of Control Systems
As described in Section 2.1 "Software " and Section 4.2 "Software Categorization of SIMATIC PCS 7", the software of a system can be divided into five software categories according to the GAMP ® Guide for Validation of Automated Systems.
The software categories have a major influence on the effort involved during the test and qualification phase and should be defined during the specification phase for the software to be used.
2 Requirements for Automated Systems in a GMP Environment
In the context of GMP, automated systems must meet certain requirements.
Section 2 "Requirements for Automated Systems in a GMP Environment" lists the main requirements that an automated system must meet in a GMP environment.
These requirements must be stipulated in the specification and implemented during configuration. In general, it must always be ensured that proof of all changes (who did what, when, to change what) is recorded at all times ("why" is optional). The requirements involved in this task are implemented by various functions and are described in the following sections.
The graphic below shows the life cycle model. The requirements focused on in this section can be assigned to the specification area. This is illustrated in the following graphic by the marking in the area on the left.
2.1 Software Categorization
According to the GAMP ® Guide for Validation of Automated Systems, the
software components of a system can be divided into five software categories. The five GAMP ® software categories are listed below:
Category 1, Operating Systems
Category 1, operating systems, covers established commercially available operating systems. These are not subject to validation themselves, the name and version of the operating system must, however, be documented and verified during Installation Qualification (IQ).
Category 2, Firmware
Category 2 covers the firmware that is configured to match the local conditions.
Once again the name and version of the firmware and its configuration must be documented and verified during an Installation Qualification (IQ). The functionality of the software must be verified in an Operational Qualification (OQ).
Category 3, Standard Software Packages
Category 3 covers commercially available, standard software packages and "off- the-shelf" solutions for certain processes. The configuration of the software packages should be limited to adaptation to the runtime environment (for example network and printer connections) and the configuration of the process parameters.
The name and version of the standard software package should be documented and verified in an Installation Qualification (IQ). Special user requirements, such as security, alarms, messages, or algorithms must be documented and verified in an Operational Qualification (OQ).
Category 4, Configurable Software Packages
Category 4 covers configurable software packages that allow special business and manufacturing processes. This involves configuring predefined software modules.
These software packages should only be considered as belonging to Category 4 if they are well-known and mature. Normally, a supplier audit is necessary. If this is not available, the software packages should be handled as Category 5 and the supplier should use the GAMP ® 4 guide to provide the foundation for establishing
Category 5 User-specific (tailored) Software
Category 5 covers user-specific software developed specifically to meet the needs of the user company.
A supplier audit is normally required to confirm the quality systems to control development and subsequent maintenance. Otherwise, the supplier should use the GAMP ® 4 guide as the basis for a suitable quality system.
The name, version, and configuration should once again be documented and verified in an Installation Qualification (IQ). A detailed software specification must be created and the function of the software verified in an Operational Qualification (OQ). The Validation Plan should specify a full life-cycle approach to validation.
The test effort when using software belonging to Category 5 is far higher than when using software of the lower categories.
The effort required for validation and testing can be reduced by using standardized software packages. The following graphic illustrates the effort required for
validation related to the software category being used.
Software Kategorie
1 2 3 4 5
2.1.1 Software Creation
When creating software, guidelines documented in the Quality and Project Plan must be adhered to (GEP awareness). Guidelines on software creation can be found in the GAMP ® 4 Guide for Validation of Automated Systems and in the relevant standards and recommendations.
2.1.1.1 Use of Typicals for Programming
As seen in Section Fehler! Verweisquelle konnte nicht gefunden werden.
"Software CreationFehler! Verweisquelle konnte nicht gefunden werden.", the validation effort increases considerably from GAMP ® software category to category. While the validation effort for software of category 1 simply involves checking software names and versions, the effort for validation of software in category 5 involves verification of the entire range of functions and a supplier audit.
To keep the validation effort to a minimum, whenever possible only predefined standard function blocks should be used during configuration. User-tailored typicals are created from standard function blocks and tested according to Design
Specifications.
2.1.1.2 Identification of Software Modules / Typicals
During software creation, individual software modules should be given a unique name, version number, and a brief description of the corresponding block.
Changes to software modules should be reflected in the identification.
2.1.1.3 Changing Software Modules / Typicals
Changes to software modules should be indicated in the identification of the relevant module. Apart from the incremented version ID, the date and name of the person making the change should also be included in the software module
identification. The program sections to be modified should, where necessary, be identified with comments referencing the corresponding number of the change request / order. See also Section 4.20 "Time Synchronization".
2.2 Hardware Categorization
According to the GAMP ® 4 Guide, the hardware components of the system fall into two hardware categories. The two hardware categories are listed below:
Category 1, Standard Hardware Components
Category 1, standard hardware components, covers established commercially available hardware components. This hardware must also be subjected to relevant quality and test mechanisms.
The hardware is accepted and documented by the IQ test.
Category 2, Custom-built (bespoke) Hardware Components
The functionality must be specified in documentation and tested and documented in suitable documented tests.
2.3 Configuration Management
According to the GAMP ® Guide, configuration management is defined as the activity necessary to define an automated system precisely at every point in its life cycle from the first steps in development to its retirement.
Configuration management consists of the application of administrative and technical procedures through the life cycle of a system to:
• identify, define, and baseline system components and to specify them in general
• control modifications and releases of items
• record and report the status of the items and modifications to them
• ensure the completeness, consistency, and correctness of the items
• control storage, handling, and delivery of items.
Configuration management consists of the following activities:
• Configuration identification (WHAT is to be kept under control)
• Configuration control (how the control will be implemented)
• Configuration status accounting (how the control will be documented)
• Configuration evaluation (how the control will be verified).
This chapter covers the activities of configuration identification and configuration control.
2.3.1 Configuration Identification
Version and change management is only practicable with a suitable configuration environment. Every software and hardware package must therefore be identified by a unique product identifier (MLFB number) and a version number. For the user software, the parts of an automated system that are subject to configuration management must be clearly identified. The system should therefore be broken down into configuration items. These should be identified at an early phase of development so that a complete list of configuration items is defined and
maintained. The application-specific items should have a unique name or version ID. The depth of detail when specifying the elements is decided by the needs of the system, and the organization developing that system.
2.3.2 Configuration Control
The upkeep of the configuration items should be checked at regular intervals, for example in reviews. Here, particular attention must be paid to the change control and the related version control. Archiving and release of individual configuration items should also be taken into account.
2.3.2.1 Version Control
To ensure correct change management, the configuration elements must be versioned. The version must be updated with every change.
2.3.2.2 Change Control
During configuration, there must be suitable control mechanisms to achieve transparency by documenting the current status. The control mechanisms are described by SOPs and should include the following points.
• Software versioning
• Information such as programming guidelines, naming conventions etc.
• Guaranteeing the traceability of program changes
• Unequivocal identification of software and all the components it contains
2.4 Access Protection and User Management
To guarantee the security of automated systems in the context of GMP, these systems should be provided with an access control system. In addition to physical access control (locked rooms etc.), access control systems also provide the option of protecting systems from unauthorized access. Users should be put together in user groups with which the user permissions are managed. The access rights of individual users can be established in different ways:
• Combination of unique user ID and password. Configuration is described in Section 4.17 "Setting up Access Protection".
• Chip cards in conjunction with a password
• Biometric systems
To ensure security, the assignment and management of the access permissions should be controlled by the system owner or by an administrator named by the user.
2.4.1 Using Access Protection in a System
Actions that can be performed on an automated system should always be protected. Depending on the task, the user can be assigned various permissions.
Access to user administration should only be possible for the system owner or an employee named by the system owner. Access by unauthorized persons to the recording of electronic data must be prevented.
An automatic logout function should be installed in the system. The logout time should be defined in consultation with the user and stipulated in the Functional Specification.
!
NoteIt is important to make sure that only authorized persons can access PCs. This can be achieved by suitable mechanisms such as remote kits. Process control system PCs should be installed in control rooms with restricted access or integrated in lockable switching cabinets.
2.4.2 Requirements for the User ID and Password
User ID:
The user ID of a system should have a minimum length agreed with the customer and should be unique within the system.
Password:
A password should always consist of a combination of numeric and alphanumeric characters. When setting up passwords, the number of characters and a period after which a password expires should be stipulated. The structure of the password is normally selected to suit the specific customer. The configuration is described in the section Security Settings of Password Policy.
Criteria for the structure of a password are as follows:
• Minimum length of the password
• Use of numeric and alphanumeric characters
• Case sensitivity
2.4.3 Chip Cards and Biometric Systems
Apart from the traditional methods of identification with a user ID and password, users can also identify themselves with chip cards or with biometric systems, such as fingerprint scanners.
2.5 Electronic Signatures
Electronic signatures are computer-generated character strings that count as the legal equivalent of a handwritten signature.
The regulations for the use of electronic signatures are set out in 21 CFR Part 11 of the FDA.
Each electronic signature must be assigned uniquely to one person and must not be used by any other person.
It must be possible to confirm to the authorities that an electronic signature represents the legal equivalent of a handwritten signature.
Electronic signatures can be biometrically based or the system can be set up without biometric features.
!
Caution When exporting pharmaceuticals into the USA, the regulations according to 21 CFR Part 11 of the FDA must be adhered to.2.5.1 Conventional Electronic Signatures
If electronic signatures are used that are not based on biometrics, they must be created so that persons executing signatures must identify themselves using at least two identifying components. This also applies in all cases in which a chip card replaces one of the two identification components.
These identifying components, can, for example consist of a user identifier and a password. The identification components must be assigned uniquely and must only be used by the actual owner of the signature.
When owners of signatures want to use their electronic signatures, they must identify themselves by means of at least two identification components. The exception to this rule is when the owner executes several electronic signatures during one uninterrupted session. In this case, persons executing signatures need to identify themselves with both identification components only when applying the first signature. For the second and subsequent signatures, one unique
identification component (password) is then adequate identification.
2.5.2 Electronic Signatures Based on Biometrics
An electronic signature based on biometrics must be created in such a way that it can only be used by one person. If the person making the signature does so using biometric methods, one identification component is adequate.
Possible biometric recognition systems include systems for scanning a fingerprint or the iris of the eye.
Note
The use of biometric systems is currently considered a secure identification method. Nevertheless, there are reservations about the use of biometric
identification characteristics in the pharmaceutical industry (for example poor face recognition due to protective clothing covering the face, no fingerprint scans with gloves, the expense involved and the reaction times of retina scans).
2.5.3 Security Measures for User IDs/Passwords
To guarantee the security of electronic signatures when using a user ID and password, the following points are important:
• Uniqueness of the user ID and password
• Supervised issue of user IDs
• Cancellation of rights if a user ID or password is no longer secure or compromised
• Security measures to prevent unauthorized use of user IDs / passwords and to report misuse
• Training of personnel with documented proof of courses
2.6 Audit Trail
The audit trail is a control mechanism of the system that allows all data entered or modified to be traced back to the original data. A reliable and secure audit trail is particularly important in conjunction with the creation, change or deletion of GMP- relevant electronic records.
In this case, the audit trail must archive and document all the changes or actions made along with the date and time. Typical contents of an audit trail must be recorded and describe the procedures "who changed what and when" (old value/new value).
The archiving period must match the period stipulated in the specification.
There must be adequate hard disk space to allow the entire audit trail to be stored until the next transfer to an external data medium.
Systems must be used that ensure adequate data security (for example redundant systems, standby systems, RAID 5).
The audit trail of the SIMATIC PCS 7 process control system documents all actions and entries made by the plant operator. All actions and entries are documented and archived by SIMATIC PCS 7 with the date, time, user name, time of the entry, and detailed information about which data was changed.
2.7 Time Synchronization
Within a system, a uniform time reference must be guaranteed to allow messages, alarms etc. to be archived with unequivocal time stamps. Time synchronization to a standard time is desirable, however not absolutely necessary. Time
synchronization when archiving data, analyzing problems, and optimizing a plant is strongly recommended.
2.8 Archiving Data
Archiving data involves the data backup of all the cGMP-relevant process data during the manufacture of a batch. These include process values (often in the form of trends), messages (alarms, warnings etc.), the audit trail (who undertook which action and made which entries when) and, if applicable, other batch report data.
The storage space on the data media of a system is finite. To keep space available on these data media, data such as measured values, message archives, or reports should be transferred regularly to external data media.
Apart from keeping storage space available within a system, the archiving of cGMP-relevant data, such as process data, batch reports, or trends is obligatory.
The period for which such data must be retained is generally laid down in
• Legal regulations (for example for the retention of pharmaceutical documentation)
• Customer requirements
• International regulations
2.9 Data Backup
In contrast to the archiving of electronic data, data backup makes data available in emergency situations, for example a defective hard disk. The aim of data backup is to be able to recover a system completely following a system crash.
Data backups are created on external data media. The data media used should comply with the recommendations of the device manufacturer.
When backing up electronic data, a distinction is made between software backups (for example application software, hard disk backups) and archive data backups.
Here, particular attention is paid to the storage of data backup media (storage of the copy and original in different locations, protection from magnetic fields, and elementary damage).
