SIMATIC PCS 7 V6.1. GMP - Engineering Manual. Guidelines for implementing automation projects in a GMP environment

Transcription

1 s SIMATIC PCS 7 V6.1 Guidelines for implementing automation projects in a GMP environment Introduction Contents Prerequisites for Configuring Automated Systems in a GMP Environment Requirements for Automated Systems in a GMP Environment 1 2 Specification 3 Guidelines for Implementation in a GMP Environment with Standard SIMATIC PCS 7 4 Software Supporting Functions during Qualification 5 Additional Hardware / Software Components 6 Glossary Index Edition 12/2006 A5E

2 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. Copyright Siemens AG 2006 All rights reserved The reproduction, transmission or use of this document or its contents is not permitted without express written authority. Offenders will be liable for damages. All rights, including rights created by patent grant or registration of a utility model or design, are reserved. Siemens AG Automation and Drives Group Competence Center Pharma (A&D CC P) D Karlsruhe Siemens Aktiengesellschaft Siemens AG 2006 Technical data subject to change. A5E

3 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 branchspecific 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). A5E iii

4 Introduction 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: 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 The following conventions are used in this manual. Activities involving several steps are shown in the form of a table and numbered in the order in which the activities should be performed. Activities involving only a few steps are indicated by a bullet ( ). References to other relevant literature are shown in bold italic. iv A5E

5 Introduction 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: You will find the guide to the range of technical documentation available for the individual SIMATIC products and systems at: The online catalog and the online ordering system is available to you at: If you have questions on the manual, please contact the Competence Center Pharma: Fax: You will find more information on the range offered by Siemens for the pharmaceutical industry at: 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 Nuremberg, Germany. Phone: +49 (911) Internet: Technical support You can contact Technical Support for all A&D products using the Web form for a support request Phone: Fax: You will find more detailed information on our technical support on the Internet at A5E v

6 Introduction Service & Support on the Internet In addition to our documentation services, you can also make use of our know-how on the Internet. 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. vi A5E

7 Contents Introduction Contents iii vii 1 Prerequisites for Configuring Automated Systems in a GMP Environment Life Cycle Model Regulations and Guidelines Responsibilities Approval Process Software Categorization of Control Systems Requirements for Automated Systems in a GMP Environment Software Categorization Software Creation Use of Typicals for Programming Identification of Software Modules / Typicals Changing Software Modules / Typicals Hardware Categorization Configuration Management Configuration Identification Configuration Control Version Control Change Control Access Protection and User Management Using Access Protection in a System Requirements for the User ID and Password Chip Cards and Biometric Systems Electronic Signatures Conventional Electronic Signatures Electronic Signatures Based on Biometrics Security Measures for User IDs/Passwords Audit Trail Time Synchronization Archiving Data Data Backup Application Software Process Data Retrieving Data Backups Use of Third-Party Components A5E vii

8 Contents 3 Specification Criteria for Selecting Hardware Criteria for Selecting Software Basic Software for User Management Additional Software - Image & Partition Creator Basic Software for the Engineering System Process Control Libraries Multiproject Engineering Additional Software - Engineering System Version Cross Checker Import/Export Assistant Controller Tuning with the PCS 7 PID Tuner Simulation with S7-PLCSIM Basic Software - Operator Station Additional Software for an Operator Station Basic Software - SIMATIC BATCH Interfaces to Process Data with OS Software Connectivity Pack Additional Software for Long-term Archiving Central Archive Server (CAS) StoragePlus SIMATIC IT Historian Basic Software of Higher-level Systems User Requirements Specification Functional Specification Design Specification Specification of Automation Hardware Specification of Automation Software Guidelines for Implementation in a GMP Environment with Standard SIMATIC PCS 7 Software Introduction Software Categorization of SIMATIC PCS Software Installation Operating System SIMATIC PCS 7 Software Installation of Utilities and Drivers Printer Drivers Virus Scanners Multiproject Engineering Views SIMATIC NET Settings Setting up the OS, OS Client, OPC Server, and SIMATIC BATCH Automation System (AS) Engineering Station (ES) Industrial Ethernet PROFIBUS Configuration Management Changes to the System Software Updates, Service Packs, and Hotfixes Upgrades (Migration) How to Update System Software Versioning the User Software Initial Creation of the User Software Initial Creation of the OS Versioning Project Data with "SIMATIC PCS 7 Version Trail" viii A5E

9 Contents Changing the User Software Creating Software Modules General Example of a Process Tag Type Setting up Process Value Archives Import/Export Assistant (IEA) Automatic Generation of Block Icons Activating and Deactivating Simulation Software OS Project Editor Creating Overview Pictures Integrating SIMATIC BATCH BATCH Definition of Terms Conformity with the ISA Standard ISA Software Model SIMATIC PCS Implementation of the ISA Concept Configuring SIMATIC BATCH Setting up Access Protection How Access Protection Works under Windows and in PCS 7 Process Mode Permission Management in Windows User Management Security Settings of Password Policy Security Mechanisms for Account Lockout Policies Security Settings for Audit Policy Configuring SIMATIC Logon Disabling the Windows Level in Process Mode (Runtime) Disabling on the SIMATIC PCS 7 OS Lockout by Configuration Security with Configuration Settings in WINDOWS Audit Trail PCS 7 OS SIMATIC BATCH Time Synchronization Concepts for Time Synchronization Example of Configuring Time Synchronization over Ethernet (OS Server as Time Master) Lifebeat Monitoring SIMATIC PCS Third-Party Systems Use of SIMATIC BATCH Reports Backing up the System/User Software Backing up the User Software Backing up the Operating System and SIMATIC PCS Long-term Archiving Long-term Archiving with the Central Archive Server (CAS) How It Works Integration in PCS Access Protection Time Synchronization Network Security Integrating the CAS in Lifebeat Monitoring OS Client for Visualizing CAS Data Audit Trail Archiving and Transferring to the CAS Data Display Long-term Archiving with StoragePlus How StoragePlus Works Software Packages of StoragePlus A5E ix

10 Contents Installation of StoragePlus Security and Access Concept Time Synchronization Network Security Audit Trail Configuration of Long-term Archiving Configuration of the StoragePlus Database Transferring Archive Data (Backup) Retrieving Data Backups Restoring the System Data Displays Long-term Archiving with SIMATIC IT Historian Data Exchange with the Plant Management Level Uninterruptible Power Supply Configuration of Uninterruptible Power Supplies UPS Configuration over Digital Inputs Creating SCL, C, VB Scripts SIMATIC PCS 7 Add-Ons Supporting Functions during Qualification Introduction Qualification of Automation Hardware Qualification of Automation Software Qualification of Standard Software System Programs from SIMATIC PCS Installed Authorizations of SIMATIC PCS Qualification of the Application Software Additional Hardware / Software Components 6-1 Glossary 6.1 Time Synchronization Solutions for Special Automation Tasks SIMIT Simulation Software Using MASTERGUARD UPS Systems Glossary-1 Index Index-1 x A5E

11 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). A5E

12 Prerequisites for Configuring Automated Systems in a GMP Environment 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. 1-2 A5E

13 Prerequisites for Configuring Automated Systems in a GMP Environment Key to the life cycle model Abbreviation/Acronym Description VP Validation Plan 1 QP QPP URS FS DS FAT SAT IQ OQ PQ VR QR Qualification Plan Quality and Project Plan 2 User Requirements Specification Functional Specification Design Specification (this includes, for example, P&I charts, software and software module specification and hardware design specification, etc.) Factory Acceptance Test Site Acceptance Test Installation Qualification Operational Qualification Performance Qualification Validation Report Qualification Report 1 2 To improve readability and recognition of familiar terminology, not all terms and abbreviations/acronyms were translated in the German version. 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 A5E

14 Prerequisites for Configuring Automated Systems in a GMP Environment 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 followed by the detailed planning and implementation in the Design Specification (DS). 1-4 A5E

15 Prerequisites for Configuring Automated Systems in a GMP Environment 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. A5E

16 Prerequisites for Configuring Automated Systems in a GMP Environment 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 commissioning 3 (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. 3 The technical commissioning must not be confused with the pharamceutical commissioning. The aim is to put the technical system into operation for the first time, for example to be able to run functional tests on the operational target system during the OQ. 1-6 A5E

17 Prerequisites for Configuring Automated Systems in a GMP Environment 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. A5E

18 Prerequisites for Configuring Automated Systems in a GMP Environment 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-8 A5E

19 Prerequisites for Configuring Automated Systems in a GMP Environment 1.2 Regulations and Guidelines Regulation / Guideline Title 21 Code of Federal Regulations (21 CFR) Annex 11 of the EU GMP Guideline Annex 18 of the EU GMP Guideline 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. Issued by / Organization FDA European Commission Directorate General III European Commission Directorate General III Title Regulation / Recommendation 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 Computer-aided Systems Good Manufacturing Practice for Active Pharmaceutical Ingredients GAMP 4 ISPE GAMP 4 Guide for Validation of Automated Systems NAMUR Recommendation NE 58 NAMUR Recommendation NE 71 NAMUR Recommendation NE 72 NAMUR NAMUR NAMUR Execution of Process Control Projects Subject to Validation Operation and Maintenance of Validated Systems Validation Support by Use of Control Systems Regulation Guideline Guideline Guideline Recommendation Recommendation Recommendation Where Applicable USA and importers into the USA Europe Europe Worldwide Europe Europe Europe Note This manual is based on the requirements of GAMP 4 and FDA 21 CFR Part 11. A5E

20 Prerequisites for Configuring Automated Systems in a GMP Environment 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 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-10 A5E

21 Prerequisites for Configuring Automated Systems in a GMP Environment 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 Installation Qualification IQ Operational Qualification OQ Performance Qualification PQ Change control during operation User User User User User User performs / supported by supplier User responsible / supplier and/or user performes User responsible / supplier and/or user performes User performs / supported by supplier User performs / possibly supported by supplier Shutdown User User performs / possibly supported by supplier A5E

22 Prerequisites for Configuring Automated Systems in a GMP Environment 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 A5E

23 Prerequisites for Configuring Automated Systems in a GMP Environment 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. A5E

24 Prerequisites for Configuring Automated Systems in a GMP Environment 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 A5E

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

26 Requirements for Automated Systems in a GMP Environment 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 "offthe-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 a suitable quality system. The name, version, and configuration should be documented and verified in an Installation Qualification (IQ). The functions of the software packages should be verified in terms of the user requirements in an Operational Qualification (OQ). The Validation Plan should take into account the lifecycle model and an assessment of suppliers and software packages. 2-2 A5E

27 Requirements for Automated Systems in a GMP Environment 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 A5E

28 Requirements for Automated Systems in a GMP Environment 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 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 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 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-4 A5E

29 Requirements for Automated Systems in a GMP Environment 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. A5E

30 Requirements for Automated Systems in a GMP Environment 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 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 Version Control To ensure correct change management, the configuration elements must be versioned. The version must be updated with every change 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-6 A5E

31 Requirements for Automated Systems in a GMP Environment 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 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.! Note It 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. A5E

32 Requirements for Automated Systems in a GMP Environment 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 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-8 A5E

33 Requirements for Automated Systems in a GMP Environment 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 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. A5E