GMP-Engineering Manual 3 - Siemens Global · PDF fileoptions WinCC long-term server, SIMATIC...

s

Introduction Contents Prerequisites for Configuring Automated Systems in a GMP Environment

1 Requirements for Automated Systems in a GMP Environment 2 System Specification 3 Guidelines for Implementing STIMATIC WinCC in a GMP Environment

4 Supporting functions during qualification 5 Index

SIMATIC WinCC V6.0

GMP-Engineering Manual Guidelines for Implementing Automation Projects in a GMP Environment

04/2007 A5E01100604-01

Siemens AG Automation and Drives Competence Center Pharma (A&D CC P) D- 76181 KARLSRUHE GERMANY

A5E01100604-01 04/2007

Copyright © Siemens AG 2007 Technical data subject to change

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.

Guidelines for Implementing automation projects in a GMP environment A5E01100604-01 iii

Introduction

Purpose of this manual This manual describes what is required from the pharmaceutical, regulatory viewpoint for Good Manufacturing Practice (GMP environment), of the automation system, the software and the procedure for configuring SIMATIC WinCC. The relationship between the requirements and the implementation is explained based on practical examples.

Intended readership This manual is intended for all plant operators, those responsible for control system designs for specific industries, project managers and programmers, servicing and maintenance personnel who use the process control technology in the GMP environment. It describes solutions for implementing automation plans with SIMATIC WinCC in situations where the principles of GMP are mandatory.

Required basic knowledge Basic knowledge of SIMATIC WinCC is required to understand this manual. Knowledge of GMP as practiced in the pharmaceutical industry is also an advantage.

Disclaimer

This manual contains instructions for system users and programmers for integrating the SIMATIC WinCC SCADA system in the GMP environment with regard to validation and taking into account special aspects such as 21 CFR Part 11.

We have checked that the contents of this document correspond to the hardware and software described. Nevertheless, as deviations cannot be precluded entirely, we cannot guarantee complete accuracy of the information contained herein. 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 welcome any suggestions for improvement and ask that they be sent to the Competence Center Pharma in Karlsruhe (Germany).

Validity of the manual The information in this manual applies to SIMATIC WinCC V6.0 including SP4. The components investigated are SIMATIC WinCC (CS/RT) in conjunction with the options WinCC long-term server, SIMATIC Logon V1.3, SIMATIC Version Trail and the WinCC Premium Add-ons PM-CONTROL and PM-QUALITY. Information relating to the compatibility between the individual components with WinCC V6.0

Introduction

Guidelines for Implementing automation projects in a GMP environment iv A5E01100604-01

SP4 can be found in the CD-ROM catalog CA01 or for add-ons directly from the add-on supplier Tel.: (+49) 621 456-2392. The CD-ROM catalog is available in the Internet at: 0Hwww.siemens.com/automation/ca01.

Position in the information landscape The system documentation of the SIMATIC WinCC V6.0 HMI system is an integral part of the SIMATIC WinCC system software. It is available to every user as online help (HTML help) or as electronic documentation in Acrobat Reader format (PDF):

• SIMATIC WinCC V6.0 electronic manuals

- You can find the electronic manuals on the CD-ROM as the “SIMATIC HMI Document Collection”.

Layout of the manual This manual supplements the existing SIMATIC WinCC manuals. The guidelines are not only useful during configuration, they are also intended to provide an overview of the requirements for configuration and what is expected of automation systems in a GMP environment.

The laws and guidelines, recommendations and mandatory specifications are explained, that represent the basis for configuration of automation systems.

All the necessary functions and requirements for hardware and software components are also described, which should make the selection of components easier.

The use of the hardware and software and how they are configured or programmed to meet the requirements is explained using examples. More detailed explanations can be found in the standard documentation.

In the appendix of this manual, you will find an index listing all the important terms.

Conventions The following conventions are used in this manual.

Activities involving several steps are numbered in the order in which the activities should be performed.

Procedures involving only a few steps are indicated by a bullet (•).

References to other manuals are shown in bold italic.

Menu commands are shown in bold face.

Introduction

Guidelines for Implementing automation projects in a GMP environment A5E01100604-01 v

Additional support If, once you have read the manual, you have any questions about the products described in it, please contact your local Siemens representative.

You will find information on who to contact at:

1Hhttp://www.siemens.com/automation/partner

You will find a guide to the technical documentation we offer for individual SIMATIC products and systems at:

2Hhttp://www.siemens.de/simatic-tech-doku-portal

The online catalog and ordering system are available at:

3Hhttp://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

Additional information about the products, systems and services from Siemens for the pharmaceutical industry can be found at:

5Hhttp://www.siemens.com/pharma

Training centers Siemens offers a number of training courses to familiarize you with the SIMATIC WinCC operator control and monitoring system. Please contact your regional training center or the central training center in D90327 Nuremberg, Germany.

Phone: +49 (911) 895-3200. Internet: 6Hhttp://www.sitrain.com

Technical support You can reach the technical support team for all A&D projects at:

• With the Support Request form on the Web: 7Hhttp://www.siemens.de/automation/support-request

• Phone: + 49 180 5050 222

• Fax: + 49 180 5050 223

You can find additional information about our technical support in the Internet at 8Hhttp://www.siemens.de/automation/service

Introduction

Guidelines for Implementing automation projects in a GMP environment vi A5E01100604-01

Service & Support in the Internet In addition to our pool of documentation, we offer you a comprehensive knowledge base in the Internet. 9Hhttp://www.siemens.com/automation/service&support

There you can find:

• The Newsletter, which provides the latest information on your products

• The right documents for you, using our Service & Support search engine

• A forum where users and experts from all over the world exchange ideas

• Your local Automation & Drives representative

• Information about on-site services, repairs, spare parts. And lots more under "Services"

Guidelines for Implementing automation projects in a GMP environment A5E01100604-01 vii

Contents

10HIntroduction 159Hiii 11HContents 160Hvii 12H1 Prerequisites for Configuring Automated Systems in a GMP Environment 161H1-1

13H1.1 Life Cycle Model ............................................................................................... 162H1-2 14H1.2 Regulations and Guidelines.............................................................................. 163H1-7 15H1.3 Responsibilities................................................................................................. 164H1-9 16H1.4 Approval and Change Procedure ................................................................... 165H1-10 17H1.5 Software Categorization of Control Systems.................................................. 166H1-11

18H2 Requirements for Automated Systems in a GMP Environment 167H2-1 19H2.1 Hardware Categorization.................................................................................. 168H2-2 20H2.2 Software Categorization ................................................................................... 169H2-3 21H2.3 Configuration Management .............................................................................. 170H2-5 22H2.3.3 Configuration Identification ............................................................................... 171H2-5 23H2.3.4 Configuration Control........................................................................................ 172H2-5

24H2.3.4.1 Version Control ................................................................................................. 173H2-5 25H2.3.4.2 Change Control................................................................................................. 174H2-6

26H2.4 Software Creation ............................................................................................. 175H2-7 27H2.4.3 Use of Typicals for Programming ..................................................................... 176H2-7 28H2.4.4 Identification of Software Modules / Typicals ................................................... 177H2-7 29H2.4.5 Changing Software Modules / Typicals ............................................................ 178H2-7 30H2.5 Access Protection and User Management ....................................................... 179H2-8 31H2.5.3 Using Access Protection in a System............................................................... 180H2-8 32H2.5.4 Requirements for the User ID and Password................................................... 181H2-9 33H2.5.5 Smart Cards and Biometric Systems................................................................ 182H2-9 34H2.6 Electronic Signatures...................................................................................... 183H2-10 35H2.6.3 Conventional Electronic Signatures................................................................ 184H2-10 36H2.6.4 Electronic Signatures Based on Biometrics.................................................... 185H2-10 37H2.6.5 Security Measures for User IDs/Passwords................................................... 186H2-11 38H2.7 Audit Trail........................................................................................................ 187H2-12 39H2.8 Time Synchronization ..................................................................................... 188H2-13 40H2.9 Archiving Data ................................................................................................ 189H2-14 41H2.10 Batch reporting ............................................................................................... 190H2-15 42H2.10.3 Components of Batch Documentation............................................................ 191H2-15 43H2.10.4 Components of the Manufacturing Log .......................................................... 192H2-15 44H2.10.5 The Uses of Electronic Batch Records........................................................... 193H2-16 45H2.10.6 Requirements for Electronic Records............................................................. 194H2-16 46H2.11 Data Backup ................................................................................................... 195H2-17 47H2.11.3 Application Software....................................................................................... 196H2-17 48H2.11.4 Process Data .................................................................................................. 197H2-19 49H2.12 Retrieving Archived Data................................................................................ 198H2-20 50H2.13 Use of Third-Party Components ..................................................................... 199H2-21

51H3 System Specification 200H3-1 52H3.1 System structure............................................................................................... 201H3-2 53H3.2 Selection criteria for hardware.......................................................................... 202H3-3 54H3.3 Required/optional software packages .............................................................. 203H3-4 55H3.3.3 Basic software access control and user management ..................................... 204H3-4

Contents

Guidelines for Implementing automation projects in a GMP environment viii A5E01100604-01

56H3.3.4 Basic software for electronic signature............................................................. 205H3-4 57H3.3.5 Additional software SIMATIC PC/PG Image & Partition Creator...................... 206H3-5 58H3.3.6 Basic engineering software .............................................................................. 207H3-5

59H3.3.6.1 Tag management with Totally Integrated Automation (TIA)............................. 208H3-5 60H3.3.6.2 WinCC configuration tool .................................................................................. 209H3-5

61H3.3.7 Basic runtime software ..................................................................................... 210H3-5 62H3.3.7.1 Alarm logging.................................................................................................... 211H3-6 63H3.3.7.2 Tag logging ....................................................................................................... 212H3-6

64H3.3.8 Basic software reporting ................................................................................... 213H3-7 65H3.3.9 Additional software packages........................................................................... 214H3-7

66H3.3.9.1 Audit trail ........................................................................................................... 215H3-7 67H3.3.9.2 Configuration management: Change control.................................................... 216H3-9 68H3.3.9.3 Configuration management: Version control (Versioning).............................. 217H3-10 69H3.3.9.4 Parameter control ........................................................................................... 218H3-10 70H3.3.9.5 Long-term archiving ........................................................................................ 219H3-13 71H3.3.9.6 Batch-oriented reporting ................................................................................. 220H3-14

72H3.3.10 Interfaces to process data .............................................................................. 221H3-15 73H3.3.10.1 WinCC Dat@Monitor ...................................................................................... 222H3-15 74H3.3.10.2 Connectivity pack............................................................................................ 223H3-15

75H3.3.11 Basic software management execution systems (MES) ................................ 224H3-15 76H3.4 User requirements specification ..................................................................... 225H3-17 77H3.5 Functional specification .................................................................................. 226H3-18

78H4 Guidelines for implementing SIMATIC WinCC in a GMP environment 227H4-1 79H4.1 Introduction ....................................................................................................... 228H4-1 80H4.2 Software categorization of SIMATIC WinCC.................................................... 229H4-2 81H4.3 Software installation.......................................................................................... 230H4-3 82H4.3.3 Operating system.............................................................................................. 231H4-3 83H4.3.4 SIMATIC WinCC software ................................................................................ 232H4-3 84H4.3.5 Installing utilities and drivers............................................................................. 233H4-4 85H4.3.6 Installing SIMATIC WinCC options................................................................... 234H4-5 86H4.3.7 SIMATIC NET ................................................................................................... 235H4-5 87H4.4 Basic of configuration ....................................................................................... 236H4-6 88H4.4.3 Object-oriented configuration ......................................................................... 237H4-11 89H4.4.4 Creating process pictures............................................................................... 238H4-17

90H4.4.4.1 Symbol library ................................................................................................. 239H4-18 91H4.4.4.2 Project library.................................................................................................. 240H4-18 92H4.4.4.3 Project functions in the form of VB / C scripts ................................................ 241H4-19

93H4.4.5 Creating overview pictures ............................................................................. 242H4-19 94H4.4.6 Operator messages ........................................................................................ 243H4-21 95H4.5 Configuration management ............................................................................ 244H4-24 96H4.5.3 Changing system software ............................................................................. 245H4-24 97H4.5.4 Versioning user software ................................................................................ 246H4-26

98H4.5.4.1 General information on versioning.................................................................. 247H4-26 99H4.5.4.2 Versioning pictures in Graphics Designer ...................................................... 248H4-27 100H4.5.4.3 Versioning VB / C scripts ................................................................................ 249H4-28 101H4.5.4.4 Versioning reports........................................................................................... 250H4-31 102H4.5.4.5 Versioning projects ......................................................................................... 251H4-31

103H4.5.5 Changing application software ....................................................................... 252H4-33 104H4.6 Setting up access protection .......................................................................... 253H4-34 105H4.6.3 How access protection works ......................................................................... 254H4-35 106H4.6.4 User management in Windows....................................................................... 255H4-36 107H4.6.5 Configuring user management in Windows.................................................... 256H4-37 108H4.6.6 Configuring SIMATIC Logon........................................................................... 257H4-42 109H4.6.7 Configuring the User Administrator ................................................................ 258H4-47

Contents

Guidelines for Implementing automation projects in a GMP environment A5E01100604-01 ix

110H4.6.8 Disabling the Windows level in process mode ............................................... 259H4-48 111H4.6.8.1 Disabling the user interface ............................................................................ 260H4-48 112H4.6.8.2 Preventing access to the Windows level ........................................................ 261H4-49 113H4.6.8.3 Security with configuration settings in WINDOWS ......................................... 262H4-50

114H4.7 Electronic signature ........................................................................................ 263H4-51 115H4.8 Audit trail ......................................................................................................... 264H4-57 116H4.8.3 WinCC Audit ................................................................................................... 265H4-57 117H4.8.4 Audit trail via WinCC Alarm Logging .............................................................. 266H4-61 118H4.9 Time synchronization...................................................................................... 267H4-67 119H4.9.3 Concepts for time synchronization ................................................................. 268H4-67 120H4.9.4 Example configuration in WinCC.................................................................... 269H4-68

121H4.9.4.1 Client/Server ................................................................................................... 270H4-69 122H4.9.4.2 Via Ethernet / system bus............................................................................... 271H4-70 123H4.9.4.3 Via PROFIBUS / MPI...................................................................................... 272H4-71

124H4.9.5 Time stamping ................................................................................................ 273H4-71 125H4.10 Archiving data: Setting up process value archives......................................... 274H4-73 126H4.11 Long-term archiving ........................................................................................ 275H4-74 127H4.11.3 Long-term archiving in SIMATIC WinCC........................................................ 276H4-74 128H4.11.4 Batch-oriented long-term archiving with PM-QUALITY .................................. 277H4-77 129H4.12 Reporting ........................................................................................................ 278H4-80 130H4.12.3 Basic logginreportingg with SIMATIC WinCC Report Designer ..................... 279H4-80 131H4.12.4 Batch-oriented reporting with PM-QUALITY................................................... 280H4-85 132H4.12.5 Backup of the application software................................................................. 281H4-88 133H4.12.6 Backing up the operating system and SIMATIC WinCC ................................ 282H4-89 134H4.13 Lifebeat Monitoring ......................................................................................... 283H4-90 135H4.14 Data communication with the plant management level .................................. 284H4-91 136H4.14.3 Data communication with the connectivity pack............................................. 285H4-91 137H4.14.4 Data communication with Industrial Data Bridge............................................ 286H4-92 138H4.14.5 Data communication with ODK....................................................................... 287H4-93 139H4.15 Uninterruptible power supply .......................................................................... 288H4-94 140H4.15.3 Configuration of uninterruptible power supplies ............................................. 289H4-96 141H4.15.4 UPS configuration over digital inputs.............................................................. 290H4-98 142H4.16 Creating C and VB scripts ............................................................................ 291H4-101 143H4.17 Connecting to a Web client........................................................................... 292H4-102 144H4.18 Connecting SIMATIC WinCC flexible ........................................................... 293H4-107 145H4.19 Connecting SIMATIC S7............................................................................... 294H4-108 146H4.20 Connecting third-party components.............................................................. 295H4-110

147H5 Supporting functions during qualification 296H5-1 148H5.1 Introduction ....................................................................................................... 297H5-1 149H5.2 Qualification of the visualization hardware ....................................................... 298H5-2 150H5.3 Qualification of the visualization software......................................................... 299H5-3 151H5.3.3 Qualification of standard software .................................................................... 300H5-3 152H5.3.4 System programs of SIMATIC WinCC ............................................................. 301H5-3 153H5.3.5 Installed licenses of SIMATIC WinCC .............................................................. 302H5-4 154H5.3.6 Qualification of the application software ........................................................... 303H5-5

155HIndex Index-304H1

Contents

Guidelines for Implementing automation projects in a GMP environment x A5E01100604-01

Guidelines for Implementing automation projects in a GMP environment A5E01100604-01 1-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 be available. When creating these specifications, requirements 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).

Prerequisites for Configuring Automated Systems in a GMP Environment

Guidelines for Implementing automation projects in a GMP environment 1-2 A5E01100604-01

1.1 Life Cycle Model Good Engineering Practice (GEP) is defined as the application of acknowledged engineering methods within the framework of a defined life cycle. The aim is to provide a suitable and cost-effective solution in keeping with the requirements.

The following graphic shows the life cycle model used in this manual. It is oriented on the recommendations of the current GAMP® guideline for validation of computerized systems. It begins with the planning phase of a project and ends with the start of pharmaceutical production on completion of qualification and validation.



Key to the life cycle model

Abbreviation/Acronym Description

VP Validation Plan

QP Qualification Plan

QPP Quality and Project Plan

URS User Requirement Specification;

FS Functional Specification; also: Application specification

DS Design Specification

FAT Factory Acceptance Test

SAT Site Acceptance Test

IQ Installation Qualification

OQ Operational Qualification

PQ Performance Qualification

VR Validation Report

QR Qualification Report

Validation plan The validation plan (VP) specifies the overall strategy and specifies the parties responsible for the validation of a system in its operational environment [PDA, GAMP®4].

• In the case of complex plants (for example a production line with several process cells and automation systems), there may also be a master validation plan (MVP) as well as VPs valid only for specific process cells and systems.

• See also GAMP®4, Appendix M1, "Guideline for Validation Planning".

Quality and project plan The quality and project plan (QPP) defines the framework and procedures for project and quality management. It specifies, for example, procedures for managing documents and procedures for change control etc. The QPP defines the life cycle in such a way that it integrates not only the product phases relevant for validation but also other organizational relationships (for example, the various time plans of different trades).

Due to their similar structures and contents, a combination of the QPP and QP is possible.

• See also GAMP®4, Appendix M6, "Guideline for Quality and Project Planning".



Qualification plan In contrast to the validation plan, a qualification plan (QP) describes the qualification activities in detail. It defines the tests to be performed and indicates the dependencies.

The qualification plan follows a validation plan. Due to the similar contents of both documents, it is possible to combine the QP and the QPP.

Specification The specification phase begins with the creation of the 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) provides detailed information on the requirements defined in the URS at the functional level. This is followed by the detailed specification for implementation in the design specification (DS).

The functional specification and design specification also form the basis for subsequent tests within the framework of the qualification or validation. The following points must also be specified in the functional and design specification phases:

• Software structure

• Programming standards

• Naming convention

• File naming convention

User requirements specification (URS) The user requirements specification describes the requirements to be met by the system from the perspective of the user. The user requirements specification is generally created by the system user possibly with the support of the system supplier. It is the basis of all subsequent specifications.

• See also GAMP®4, Appendix D1 "Example Procedure for the Production of a User Requirement Specification".

Functional specification (FS) The functional specification is generally created by the system supplier with some cooperation from the end customer. Based on the user requirements specification, it describes the functions of the system in detail. The approved functional specification is the basis for creating detailed specifications.

• See also GAMP®4, Appendix D2 "Example Procedure for the Production of a Functional Specification".



Design specification (DS) The design specification (DS) is generally created by the system supplier. It is based on the functional specification and expands this with detailed descriptions, for example, of the hardware and software to be used, process tag lists, etc.

• See also GAMP®4, Appendix D3 "Example Procedure for the Production of a Hardware Design Specification" and GAMP®4, Appendix D4 " Example Procedure for the Production of Software Design Specifications and Software Module Design Specifications".

Implementation During the implementation phase, the system is implemented according to the design specification. Apart from the procedures and additional guidelines defined in the QPP (for example, coding standards, naming conventions, data backup), change management plays an important role making changes and deviations from the original specification traceable.

See also GAMP®4, Appendix M8 "Guideline for Project Change Control"; GAMP®4, Appendix M10 "Guideline for Document Management".

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.

SAT The site acceptance test (SAT) shows that an automated system works within its target operating environment with interfaces to the instrumentation and plant sections according to the specification. Depending on the project, the SAT can be combined with commissioning (and therefore with the IQ or OQ).

Test phase / qualification The FAT is followed by the technical commissioning (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 can be combined. It is advisable to synchronize the activities of commissioning and qualification to save both time and costs.

The test planning should therefore be created in good time so that it is possible to check whether or not tests made beforehand during FAT or SAT need to be repeated during qualification. In this case, the documented FAT / SAT tests become part of the qualification documentation.



When creating the test documentation, tests and acceptance criteria must be described so that they are easy to understand.

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 servicing cycles and the procedure for operational change control must be defined and adhered to.



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

21 CFR Part 11 US FDA Electronic records, electronic signature

21 CFR Part 210 US FDA Current good manufacturing practice in manufacturing, processing, packing, or holding of drugs; General

21 CFR Part 211 US FDA Current good manufacturing practice for finished pharmaceuticals

Regulation

Manufacturers and importers of medicines for the US market

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 Operation and Maintenance of Validated Systems



NAMUR Validation Support by Use of Control Systems


Note

This manual is based on the requirements of GAMP ® 4 and US 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 11, 210 and 211. For computerized systems, Part 11 (known as: 21 CFR Part 11) is particularly important. It 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 that were produced by 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 corresponding specifications, the responsibilities for the activities in the individual life cycle phases must be specified. Since this is normally decided with a specific customer and for a specific project and must be contractually agreed, it is advisable to specify these responsibilities in the quality and project plan. See also GAMP®4, Appendix M2.



1.4 Approval and Change Procedure When setting up new systems that require validation or when changing systems already in operation and subject to validation, the main priority is to achieve and maintain the validated status.

Setting up new systems When a new system is being set up, the approval of documents and the transition between life cycle phases is specified before the project is started. This is usually done along with the definition of responsibilities in the quality and project plan. A life cycle as described in section 305H1.1 "306HLife Cycle Model" is used.

Changing validated systems Changes to an existing system with validated status are governed by the operational change control. Changes must be described before they are implemented, potential effects must be identified and accompanying measures (for example running tests, updating the as-built documentation) must be defined. Following subsequent approval, both the planned change and the defined measures are implemented.

If the changes are extensive, a life cycle like the one shown in this manual can be used if necessary.



1.5 Software Categorization of Control Systems As described in section 307H2.2 "308HSoftware Categorization" and section 309H4.2 "310HSoftware categorization of SIMATIC WinCC", 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 311H2 "312HRequirements 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 in the graphic.

Requirements for Automated Systems in a GMP Environment


2.1 Hardware Categorization According to the GAMP ® 4 Guide, Appendix M4, hardware components of a system are divided into two categories. The hardware categories are listed below:

Category 1, Standard Hardware Category 1, standard hardware, 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 The functionality must be specified and tested and documented in detail in suitable documented tests.



2.2 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 includes the firmware, for example in field instruments or compact controllers, whose configuration was adapted to the on-site 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 device 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 these 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). User requirements, such as security, alarms, messages, or calculations must be documented and verified within the framework of the 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 category 4 if they are well known and fully developed, otherwise category 5 is more suitable. In the case of critical and / or complex applications, a supplier audit is usually required

The name, version, and configuration must 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 life cycle model and an assessment of suppliers and software packages.



Category 5 Custom (Bespoke) Software Category 5 covers custom 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, suppliers should use the GAMP ® 4 guide as the basis for their own development life cycle.

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 testing of software in higher categories involves far more effort than the software in lower categories.

The effort for validation and testing can be reduced by using standardized software whenever possible.



2.3 Configuration Management According to the GAMP ® 4 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 and define basic 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. Each software and hardware package is therefore 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 specified. The system should therefore be organized according to configuration items. These should be defined at an early phase of development so that a complete list of configuration items can be created and maintained. The application-specific elements should have a unique identifier (name or identification number). The degree of detail when specifying the elements is determined by the needs of the system and the supplier developing the 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 that achieve transparency by documenting any changes. The control mechanisms are described by SOPs and should include the following points.

• Software versioning

• Information such as programming guidelines, naming conventions, etc.

• Guarantees of the traceability of program code changes

• Unequivocal identification of software and all the components it contains



2.4 Software Creation When creating software, guidelines documented in the quality and project plan must be adhered to (Good Engineering Practice – 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.4.1 Use of Typicals for Programming As seen in section 313H2.2 "314HSoftware Categorization", 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 validation work to a minimum, standardized function blocks should therefore be used during configuration (products, standard company components, standard project components). User-tailored typicals are created from standard function blocks and tested according to design specifications.

2.4.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.4.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 software modules to be changed, must, where necessary, be made known by comments with a reference to the corresponding change request. See also section 315H4.5.1 "316HChanging system software".



2.5 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 assembled in user groups, which are used to manage the user permissions. The access rights of individual users can be established in different ways:

• A combination of unique user ID and password - a description of the configuration can be found in Chapter 317H2.5.2 "318HRequirements for the User ID and Password".

• Smart cards in conjunction with a password

• Biometric systems

To ensure security, the assignment and management of the access permissions should be controlled by the plant owner or by an administrator named by the user.

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



2.5.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 319H4.6 "320HSetting up access protection".

Criteria for the form of a password are as follows:

• Minimum length of the password

• Use of numeric and alphanumeric characters

• Case sensitivity

2.5.3 Smart Cards and Biometric Systems Apart from the traditional methods of identification with a user ID and password, users can also identify themselves with smart cards or with biometric systems, such as fingerprint scanners.



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

! Note When exporting pharmaceuticals into the USA, the regulations according to 21 CFR Part 11 of the FDA must be adhered to.

2.6.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 smart 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 with 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.6.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.6.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 not secure or compromised

• Security measures to prevent unauthorized use of user IDs / passwords and to report misuse

• Training of personnel with documented proof of training courses



2.7 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 (old value/new value) and when.

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



2.8 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 and analyzing problems in a plant is strongly recommended.



2.9 Archiving Data Archiving means the permanent storage of electronic data and records of a computer system in a long-term storage system.0F

1

The customer is responsible for the definition and checks involved in storing electronic data.

Based on legal requirements ("predicate rules"), a decision must be made as to how the electronic records are stored and, in particular, which data is involved. This decision should be based on a justified and documented risk assessment that takes into account the significance of the electronic records over the archiving period.

The customer should define the following requirements 1F

2:

• Whether archiving is necessary at all for the particular application (backup/restore functionality could be separate from archiving)

• Required period of archiving for the specific data types, based on legal and commercial aspects

• An archiving procedure; the restoration capability, data format, practicality, life of the media and the platform If electronic storage is selected, the electronic data can be stored in a standard format such as PDF, XML, SGML, etc.

• A procedure for storing the metadata for the correct interpretation of the stored data

• Presentation of the permanent checks of uninterrupted recording of electronic records and the authenticity of the electronic signatures

In SIMATIC systems, process values (often in the form of trends), messages (alarms, warnings, etc.), audit trails and possibly also other batch data can be archived.

The storage space on the data media of a system is finite. To ensure that there is adequate space on these data media, data can be regularly transferred to external storage media.

When migrating or converting the archived data, the integrity of the data must be assured over the entire conversion process.2F

3

1 "Good Practice and Compliance for Electronic Records and Signatures. Part 1, Good electronic records management". ISPE/PDA 2001. 2 "Good Practice and Compliance for Electronic Records and Signatures. Part 3, Models for Systems Implementation and Evolution". PDA 2004. 3 "Good Practice and Compliance for Electronic Records and Signatures. Part 3, Models for Systems Implementation and Evolution". PDA 2004.



2.10 Batch reporting When producing pharmaceuticals and medical equipment, batch documentation takes on a special significance. For a pharmaceutical manufacturer, methodically created batch documentation is often the only documented evidence within the framework of product liability.

2.10.1 Components of Batch Documentation The components of batch documentation are as follows:

• Manufacturing formula / processing instructions and manufacturing log

• Packaging instructions and packaging log (from a pharmaceutical point of view, the packaging of the finished medicinal product is part of the manufacturing process)

• Test instructions and test log (relating to quality checks for example analysis)

The manufacturing log (or packaging log) has a central significance here and this is defined below:

• The manufacturing log is always both product-related and batch-related

• It is always based on the relevant parts of the valid manufacturing formula and processing instructions

• It records all measurement and control procedures relevant to the process as actual values

• It compares these with the specified desired values

2.10.2 Components of the Manufacturing Log Mandatory parts of the manufacturing log include:

• Name of the product and number of the produced batch

• Date and time of commencement, significant interim stages and completion of production

• Name of the person responsible for each stage of production

• Initials of the operator involved in all significant production steps and, when applicable, the person checking the operations (double-check when weighing materials, for example)

• The batch number and / or the analytical control number and the actual quantities of all constituent materials

• All relevant processing steps, any unusual events and the major equipment used

• Recordings of in-process controls, including initials of the person performing them and the results obtained

• The yields of the relevant interim stages



• Information on special problems, including details of any deviation from the manufacturing formula and processing instructions and the signature of the person who authorized the deviation.

2.10.3 The Uses of Electronic Batch Records Since the term "electronic batch record" (acronym: EBR) is not clearly defined in this context, there are two ways of using electronic records in the documentation of pharmaceutical production:

• The electronic records form part of the batch documentation or

• The entire manufacturing log is created electronically.

Since all the requirements listed above must be met by an electronic manufacturing log and data from different systems (for example, PCS, laboratory data, remarks by operators) also needs to be integrated, the situation is often as in case 1. In other words, the data is used as part of the batch documentation, often in conjunction with data from other systems and records on paper.

2.10.4 Requirements for Electronic Records When electronic records are used as part of the batch documentation or even as the manufacturing log itself, the following additional requirements apply (see also EU GMP Guide, Section 4.9; 21 CFR Part 11 Electronic Records, Electronic Signatures):

• The initials and signatures required by the regulations must be implemented as electronic signatures

• "Relevant" production steps / processes, "significant" interim stages and "major" equipment must be defined in advance by the person responsible from a pharmaceutical perspective; this definition is often process-specific

• The system must be validated

• Only authorized persons should be able to enter or change data (access protection)

• Changes to data or deletions must be recorded (audit trail)

• The electronic records must be protected by back-up copies

• If an electronic manufacturing log is used, its structure and contents must match the structure and contents of the manufacturing formula / processing instructions. As an alternative, the manufacturing instructions and log can also be combined in one document



2.11 Data Backup In contrast to the archiving of electronic data, data backups are used to create backup copies which allow the system to be restored if the original data or entire system is lost.3F

4

The backup procedure must cover the periodic backup of volatile information to avoid total loss of data due to defective system components or inadvertent deletion of data. Backup procedures must be checked to ensure the correct storage of data. Backup records should be labeled clearly and intelligibly and dated. 4F

5

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, partition images) 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).

2.11.1 Application Software Software backups should be created following any software change to the system. They must document the last valid software version of a system. If changes are made to software components, it is sufficient to back up the modified components of the application software. A complete backup of the software should nevertheless be made at regular intervals. If software backups need to be created when changes are made to the software of an existing system or during the installation of a new system, they should be created after the installation. During the course of a project, the software version should be backed up and documented in conjunction with defined milestones, for example at the end of the FAT (in other words before the system is supplied), on completion of the installation qualification (IQ) as a basis for the tests for operational qualification (OQ) and, of course, on handover of the system to the user.

Software generations should also be recorded during the creation of new software versions at regular intervals in the form of software backups.

Software backups must be created for both the application software and the configuration parameters.

Labeling software backups According to the GAMP ® 4 Guide for Validation of Automated Systems, software backups should be documented both on the label of the backup medium itself and in a separate report containing the following information:

4 "Good Practice and Compliance for Electronic Records and Signatures. Part 1, Good electronic records management". ISPE/PDA 2001. 5 "Electronic records and electronic signatures assessment". Chris Ride & Barbara Mullendore, PDA 2001.



• Date of creation

• System designation

• Software designation

• Software or version designation

• Current number of the backup

• Reason for software backup

• Date of first usage

• Date of backup

• Date and signature of the person responsible

• Identity of the operator

Retention of software backups At least the last two software backups should be archived. For reasons of safety, these should be stored at a different location from the system (according to the recommendations of the BSI (German authority responsible for security in information technology), for example in a fire compartment separate from the system).

A suitable backup strategy must be defined depending on the frequency at which changes are made.

The storage life of the data medium should be defined (for example based on the manufacturer's information or on publications of the relevant national authorities for information technology) and before this expires, the backup should be migrated, for example by copying it to a new data medium.



2.11.2 Process Data The data saved in the system, such as trends, measured values or alarms should be backed up on external data media at periodic intervals. This measure can minimize data loss if problems occur.

Labeling data backups According to the GAMP ® 4 Guide for Validation of Automated Systems, data backups should be documented either on the label of the backup itself or in a separate report containing the following information:

• System designations

• Software / data designation

• Version and/or software/firmware build number, if available

• Date of creation

• Date of first usage

• Current number

• Date of the data backup

• Reason for the data backup

• Identity of the operator

Retention of data backups The same guidelines apply as in the section with the same name in Chapter 321H2.11.1 "322HApplication Software".

Since process data, in contrast to software, is not normally stored in "overlapping" versions, suitable measures must be taken to ensure data integrity.



2.12 Retrieving Archived Data Archived data must be retrievable at all times. Following system updates, care must be taken that the data transferred to archive prior to the update remains compatible.



2.13 Use of Third-Party Components When using predefined third-party components (hardware and software), a supplier audit should always be performed and the supplier's quality management system verified. The compatibility of the hardware components must be confirmed.

Even when using standard hardware and software components of other manufacturers, compatibility must be confirmed.

Note

The NAMUR Recommendation 72 contains a considerable amount of information on auditing a product supplier. Approaches to auditing a service provider or solution provider can also be found, for example, in the GAMP ® 4 Guide, Annex M2.


3 System Specification

This section focuses on the selection criteria for the hardware and software. The activities for the selection of the products, product variants and system constellations are performed in the specification phase of an automation system. This is demonstrated in the following life-cycle model by the marking in the left area.

System Specification


3.1 System structure The operator and control system SIMATIC WinCC is intended for all branches and can be adapted flexibly to specific customer requirements for a production plant.

With SIMATIC WinCC, you can implement a variety of different system configurations from single user systems to multiple user systems with a client/server structure.

With a single user system, the entire operator and control and monitoring of an automation system can be handled on one PC.

A multiple user system consists of operator stations (WinCC clients) and one or more WinCC servers that supply the WinCC clients with data.

Redundant systems can be created to increase availability.

To connect to the underlying automation level, for example, SIMATIC S7-300 / S7-400 or systems from other vendors, bus systems such as MPI, PROFIBUS or Industrial Ethernet can be used. The choice of bus system depends on the number of linked partners and the environmental conditions for data communication.

Note

The individual components can be selected from the current SIMATIC HMI catalog ST 80 to suit the specification of the production plant.



3.2 Selection criteria for hardware The SIMATIC WinCC software can be installed on any standard PC that meets the minimum requirements for the hardware and software configuration.

For production plants in a GMP environment (for example, in food and beverages or pharmaceutical industry) Siemens has developed particularly rugged panel PCs with touch screens and stainless steel fronts specially for installation on the shop floor. The SIMATIC WinCC software is available in conjunction with a Panel PC as a complete HMI system.

As an alternative to the Panel PC, the use of LCD monitors of the type SIMATIC Flat Panel is recommended. The monitors are rugged and designed for industry and they are intended for use directly on the machine separate from the PC. They are available both with and without control elements.

Details of the minimum requirements for the hardware and software configuration for the SIMATIC WinCC software and suitability of the recommended hardware for industrial use can be found in the current SIMATIC HMI catalog ST 80.

Note

We recommend using the approved hardware from the current SIMATIC HMI catalog ST80 since this has been checked by Siemens in system tests. When PCs are installed in switching cabinets, make sure that suitable hardware components are used, for example remote kits. SIMATIC PCs are available with the operating systems approved for WinCC.



3.3 Required/optional software packages This section introduces the basic functions of SIMATIC WinCC along with additional software packages to meet the " 323HRequirements for Automated Systems in a GMP Environment" as described in section 324H2.

3.3.1 Basic software access control and user management Access protection for SIMATIC WinCC system components and the WinCC Premium add-ons is implemented with the SIMATIC Logon software. SIMATIC Logon is a user management system based on Windows mechanisms that can be used both in workgroup and in a Windows domain. The use of SIMATIC Logon meets the requirements of the FDA regulation 21 CFR Part 11 for "Electronic Records and Electronic Signatures" regarding access control.

SIMATIC Logon The user logs on with the system using SIMATIC Logon. A logged-on user has the functions logoff, user change and password change available. SIMATIC Logon must be installed on all operator control and monitoring systems.

Note

The use of SIMATIC Logon in multi-user systems with clients without a local project is not allowed.

User administrator The permissions for controlling the process are configured in WinCC User Administrator. Controlling the process is divided into individual operator control functions that can be enabled for selected user groups. To be able to use these functions, the user must be a member of the appropriate user group. At runtime, the User Administrator checks the operator permissions in WinCC and SIMATIC Logon checks the authorizations.

3.3.2 Basic software for electronic signature Basic software for electronic signatures is available in SIMATIC WinCC only in conjunction with the SIMATIC Logon software. The Electronic Signature package is included in the SIMATIC Logon package. This package provides the interface that can be addressed in WinCC using script functions for checking the user ID and password.



3.3.3 Additional software SIMATIC PC/PG Image & Partition Creator The optional "SIMATIC PC/PG Image & Partition Creator" software allows users to make data backups of hard disks. Backing up system and user software makes it possible to restore the system quickly. Backed up contents of hard disks can be copied back to devices with an identical configuration. This simplifies replacement of computers or expansion of systems.

Apart from creating hard disk images, the Image & Partition Creator can also be used to create, modify, and delete hard disk partitions.

3.3.4 Basic engineering software SIMATIC WinCC is a modular software system. Its basic components are the Configuration Software (CS) and Runtime Software (RT) Both software components are included in the full WinCC package (RC). The selection of the full package depends on the number of power tags (external tags) required to interface with the automation level.

The Configuration Software (CS) contains all the basic functions for engineering SIMATIC WinCC. The central component is the WinCC editor in which editors can be opened for configuring the various functions. Some functions that are recommended for a GMP environment are pointed out below.

3.3.4.1 Tag management with Totally Integrated Automation (TIA) In a complete automation solution from Siemens (HMI system and SIMATIC S7 automation system), the variables (tags) can be imported from the SIMATIC Manager into the tag management of WinCC. The variables are created and managed centrally in the SIMATIC Manager. This ensures consistency within the project. It reduces the effort involved in validation of the software.

3.3.4.2 WinCC configuration tool The configuration tool provides the option for configuring mass data with the Microsoft Excel standard software. This means that the editing options of Microsoft Excel such as automatic repetition of items can be used. The data is transferred to the active WinCC project in a download procedure. The configuration tool allows you to configure data from the tag management, alarm logging, tag logging and the text library. Data from projects that have already been validated, for example, can be used again. The WinCC configuration can be output as an overview and used for qualification tests. The use of the configuration tool therefore reduces the work required for engineering and validating the software.

3.3.5 Basic runtime software The runtime software (RT) is used to control and monitor the automation process.

This is possible in single user or multiple user (client-server structure) system configuration.

Systems can include redundancy to increase availability.

The following sections discuss the basic functions of the runtime software for recording and displaying runtime data.



3.3.5.1 Alarm logging The entire message system is configured in Alarm Logging. This includes preparation, display, acknowledgment and archiving of messages. Alarm events from the process, from the automation system and from the WinCC system can be processed in the message system.

In production plants in a GMP environment, Alarm Logging is also used for an audit trail. Operator input in process pictures (for example changing an I/O value or acknowledging a button) trigger an operator input message that is entered in Alarm Logging with its time stamp, user ID, old value, and new value.

To display messages in runtime, the ActiveX Alarm control is linked into the process picture. At the same time, the message view is configured. The display of different message views is achieved by multiple linking of the Alarm Control and setting the appropriate message filters.

Messages are logged manually or automatically. Print jobs set up in the Report Designer control the logging.

3.3.5.2 Tag logging Archiving of process values is configured in the Tag Logging editor. Selected process values are recorded in definable acquisition cycles and stored in process value or compressed archives.

The recorded process values are stored in the archive database. Once the database reaches a defined database size or a specified interval has elapsed, the archive database is transferred to external storage. Long-term archiving is also an option (see section 325H4.11 "326HLong-term archiving" ).

In runtime, current or previously archived process data can be displayed as trends or tables. To achieve this, the relevant ActiveX Control (Online Trend Control, Online Table Control) is linked into a process picture.

The output of the archived process values log is configured in the Report Designer. Ready-made page layouts are filled with project-specific data or new page layouts can be defined. Print jobs set up in the Report Designer control the logging.



3.3.6 Basic software reporting

Report Designer The SIMATIC WinCC Report Designer is used both for documentation of the WinCC configuration and for reporting the runtime data.

The configuration data can be documented for the WinCC Explorer and every configured editor, for example Tag Logging, Alarm Logging, etc. The pre-configured print jobs and report layouts are included in the SIMATIC WinCC software package. The preconfigured report layouts can be opened with the page layout editor of the Report Designer and modified as necessary. To allow documentation in a GMP environment, a version number can be inserted.

For runtime reporting (for example, messages from Alarm Logging or process values from Tag Logging), there are preconfigured report layouts and print jobs that are shipped with the product. The user defines which runtime data will be reported in the pre-configured layouts. To define the contents, the layout is opened in the page layout editor of the Report Designer and edited as required.

The WinCC runtime components, for example Alarm Logging, use pre-configured print jobs. The output options, scope and layout of these print jobs can be modified. It is also possible to create customized print jobs.

3.3.7 Additional software packages To enhance the functionality of SIMATIC WinCC, WinCC options and WinCC Premium add-ons are available as supplementary software products.

The software packages presented below are particularly relevant for process visualization / automation in a GMP environment.

3.3.7.1 Audit trail

WinCC Audit For production plants operated in a GMP environment, in 21 CFR Part 11, the FDA specifies the recording of changes to data relevant for GMP including the time stamp, user name, old value and new value in the form of an audit trail. To expand this functionality in SIMATIC WinCC, the WinCC Audit option was developed. WinCC Audit is integrated in the WinCC Audit RC software packages for configuration of the audit trail and in WinCC Audit RT for recording the audit trail per station (server or client).

The following is recorded:

• In runtime mode, all operator activities, such as logon/logoff, changes to I/O fields, adjusting sliders, etc.

• In runtime mode, all changes to the user archives

• All configuration changes in the engineering phase. Changes to documents, such as scripts, reports, plant pictures and user documents



• Changes to the configuration of the audit trail

Configuration of the audit trail is straightforward and each of the tracking functions listed above can be selected or deselected.

It is also possible to insert freely selected texts into the audit trail for each WinCC object using the InsertAuditEntry function. This allows, for example, picture changes and switching cycles of any type to be included in the audit trail and increase its informative value.

The audit trail can be visualized with an Audit Viewer. Numerous standard and customized filters can be set in the Audit Viewer to allow the audit trail information to be selected and displayed quickly. This information can then be exported to an Excel sheet.

The audit trail is stored in an SQL database. The WinCC audit trail database can be configured so that either audit trail information from one WinCC project or from several WinCC projects can be recorded.

It is also possible to store the audit trail database on a local computer or on a computer in the network.

WinCC Audit works together with the SIMATIC Logon software to provide access control (see also section 327H3.3.1 "328HBasic software access control and user management").



3.3.7.2 Configuration management: Change control

WinCC Audit WinCC projects that have already reached a completed version accepted by the customer can be monitored for subsequent engineering changes by WinCC Audit. All engineering changes made since the project version was accepted can be continuously traced thereby minimizing plant downtimes.

WinCC Audit distinguishes between changes made in the WinCC Explorer or changes that can be tracked in the WinCC database and corrections made to files in the WinCC project tree.

Configuration changes made with the WinCC Explorer include, for example, adaptations to the tag management, in Alarm Logging, in Tag Logging, etc.

On the other hand, corrections made to documents or files, such as plant pictures, reports, scripts or user documents are recorded by the document control of WinCC Audit.

Document control assigns write protection to all documents of a WinCC project. To make a change to an individual document in WinCC Audit, it must be checked out individually, modified and then checked in again. When this is done, it is helpful to enter a comment to document the changes. In the audit trail, the file check out and check in is recorded with the time stamp, WinCC project name, file name, user ID and any comment that may have been entered. Document control also provides the option of archiving the documents so that a version of the documents can be created.

Note

When changes are made to documents, document control makes it possible to recognize that a document has been changed; details of the change are, however, not recorded and should be described in comments. Measures must be taken to ensure that file access rights are not modified manually.

The various versions of the documents can be displayed in a history view.

The rollback function allows an older document version to be restored. The indicators used to distinguish versions are the time stamp and comments made when the document was logged in.



3.3.7.3 Configuration management: Version control (Versioning)

Version Trail SIMATIC Version Trail is a software option developed for the engineering of SIMATIC PCS 7 for versioning libraries, projects and multiprojects that can be used universally in the context of Totally Integrated Automation with SIMATIC.

With Version Trail, project data, in other words complete multiprojects, single projects or libraries can be archived at a specified time and the data can be assigned a version ID (versioning). Project data that has already been versioned can also be retrieved and used again.

SIMATIC Version Trail also handles the entire management of the version history. This means, for example, that once a version has been completed, it can no longer be modified. The system automatically sets the versioning based on specifically configured guidelines relating to validation factors. Versions are always incremented by one digit (without gaps) and there can only be one valid version of a project under a single name in the version history.

Note

Because of the close link with SIMATIC Logon, SIMATIC Version Trail can only be operated in combination with this separately ordered, central user administration.

3.3.7.4 Parameter control

PM-CONTROL PM-CONTROL is a user-friendly, batch-oriented parameter control for recipe/product data management. The integrated order control allows flexible handling of production orders in which the recipe, production location, scalable production quantity and the time of production can be specified.

The software package is divided into three applications:

• Topology manager for mapping the process cell topology, creating the required parameters and configuring the interface to the automation level.

• Recipe system for creating and managing recipes / products

• Order control, assignment and management of production orders

To achieve a cost-effective solution for both simple and more complex tasks, PM-CONTROL is available in the "Compact", "Standard" and "Professional" variants.



PM-CONTROL supports measures to meet the requirements of FDA regulation 21 CFR Part 11.

In the Topology Manager, user rights are specified for certain user groups. User access is checked by SIMATIC Logon.

In the recipe system, the recipes are signed with an electronic signature after they have been created. After each recipe change, a new signature is necessary. In the Topology Manager configuration, it is possible to decide whether the full signature for a recipe requires one electronic signature or two electronic signatures from different users.

The recipe data is recorded in an internal audit trail from the point in time at which it is created. Each recipe change is recorded, among other things with the time stamp, user ID, old value and new value. The implemented rollback function allows an older recipe version to be restored. The Audit Trail can be printed out or exported to an XML file.

Only fully signed recipes can be included in an order by the order control. Each scheduled order, in turn, has an electronic signature. During processing, only data from signed orders can be loaded on the automation system.

The processing on the orders is started, either automatically when requested by the automation level or manually with the required user rights.

Recipes and processed orders remain in the database until a configurable retention period elapses. Recipes and orders can be printed out or exported to a CSV file.

The recipe system and order control can also be operated without electronic signatures but with the audit trail function.



PM-CONTROL can be used both in a WinCC single-user system and in a WinCC multi-user system.

User archive With the User Archive option, recipe data or machine data records can be created in the form of database tables. This option is only advisable for a small number of recipes or data records since, in contrast to PM-CONTROL, no recipe management or order control is integrated.

The User Archive editor creates database tables (archives) containing several data records for parameter data (recipe data / machine data). To meet the FDA requirements for an audit trail, the parameter data of a data record must be inserted in the database table using I/O fields. This is done by creating I/O fields in a WinCC picture and linking them with the relevant data fields. With suitable configuration, the entry of a value in an I/O field triggers an operator input message that is recorded along with the time stamp, user ID, old value and new value. WinCC Alarm Logging is used for this purpose. The interface to the automation system for loading and receiving data records takes the form of control variables that can also be linked to WinCC operator controls for triggering an operator input message.

To obtain an overview of the created data records in an archive, the ActiveX control WinCC User Archive – Table Element is inserted in a WinCC picture with read access.

Automatic versioning of the data records is not supported with the user archive option. Versioning must be implemented by the programmers themselves. The user archive can be exported manually in CSV format.



3.3.7.5 Long-term archiving

WinCC long-term archive server Both in WinCC Tag Logging and in WinCC Alarm Logging, there are options for long-term archiving. Apart from the archive size and segment change, the configuration for transfer to permanent storage can also be set. For long-term archiving in a GMP context, the "Signing off active" option is selected. This assigns a checksum to the transferred archives. Subsequent changes to the archive files are detected when they are read.

In the backup configuration for storing the archive backup files, a destination path is specified that can be located on any computer in the network. For reliable data storage, a second destination path is set and the "Backup to both paths" option is selected.

As a long-term archiving concept, it is advisable to set up a separate long-term server in the network. This is done by running the file server setup of WinCC on a computer and installing the MS SQL Server. All the archive backup files (from Tag Logging and Alarm Logging) are stored on this computer. To allow viewing, the archives are temporarily connected to the WinCC system. Further options for viewing are provided by the OLE-DB interface or the analysis tool Dat@View of the Dat@Monitor WinCC option.

Batch-oriented long-term archiving with PM-QUALITY PM-QUALITY is a powerful software package for batch-oriented acquisition of production data such as process values and messages.

The process values can either be taken from WinCC Tag Logging or recorded in a separate tag logging function, grouped according to the various acquisition cycles. Event-driven process values or those dependent on a trigger (for example setpoints/actual values) are read in as snapshots. Alarm events and audit trail entries are taken from WinCC Alarm Logging.

It is possible to configure automatic export of the batch data on completion of the batch. This can be in database format, in HTML format and/or in XML format. Each export can be activated separately. The export cycle is set in minutes and the destination for data storage must be set (for example any computer in the network).

The PM-QUALITY application Export View can be used to view the batch data exported in database format.



3.3.7.6 Batch-oriented reporting

PM-QUALITY The data recorded in PM-QUALITY can be displayed in trends (process values), printed as reports on a printer or exported as an HTML file, XML file or in database format. It is also possible to configure the export of batch data for long-term archiving on a different computer (see section 329H4.12.2 "330HBatch-oriented long-term archiving with PM-QUALITY“).

The software package includes the following applications:

• Topology Manager for mapping the plant topology and specifying the production data to be acquired

• Report Editor for creating the report layout for the acquired data and displaying batch logs on the screen

• Data Logging, a runtime component for acquisition of the data

• Data View / Export View and various ActiveX Controls for displaying batch data

Apart from the automatic acquisition of the configured batch data, manually entered values, for example laboratory values can be added to a batch log later. If the batch log is transferred to the archive automatically due to the set export option, no more changes can be made to the log if the "Complete automatically" option is set.

It is also possible to use a script in WinCC to configure an electronic signature of the batch logs by the logged-on user and with it the manual assignment of the batch status (released / locked).

PM-QUALITY can be used both in a WinCC single-user system and in a WinCC multi-user system.

For use in redundant systems, PM-QUALITY is also available with PM-QUALITY Data Center. This application merges the recorded batch data from two runtime databases in an export database. The Data Center can be installed separately from PM-QUALITY on any computer in the network.



3.3.8 Interfaces to process data

3.3.8.1 WinCC Dat@Monitor WinCC Dat@Monitor is simply a display and evaluation system for process values from WinCC or data from the WinCC long-term server. WinCC Dat@Monitor provides a number of analysis tools for interactive data display and for analysis of current process values and historical data:

• Dat@Workbook allows the integration of messages, archive data and current process values from WinCC in MS Excel and therefore supports online analysis.

• Dat@View is used to display and analyze historical data from WinCC runtime / the central archive server or from WinCC long-term servers. The data can be displayed in tables or in trends.

• Dat@Symphony is simply used for monitoring and navigating using WinCC process pictures with MS Internet Explorer (view only client).

3.3.8.2 Connectivity pack The connectivity pack provides interfaces for access to archive data and messages in WinCC. WinCC provides access to the following process data:

• Alarms and events (messages), OPC A&E, read and write (acknowledgments only) access

• Process value archives (trends), OPC HDA, read-only access

• Process tags (states), OPC DA, read and write access, ships with WinCC system software

• All archive data, WinCC OLE DB, read-only access

The connectivity pack provides standardized access with OPC and OLE DB from computer systems at enterprise management levels to computer systems at the process level.

3.3.9 Basic software management execution systems (MES)

SIMATIC IT With its numerous components, SIMATIC IT forms an MES (Manufacturing Execution System) following the ISA 95 standard.

SIMATIC IT is used to optimize the interaction of planning, development, and procurement within the framework of manufacturing processes.

The main elements of SIMATIC IT are:

• SIMATIC IT Framework (plant modeling)

• SIMATIC IT Components (specific functionality)

SIMATIC IT Framework connects the automation level to the operational management and production control levels, as well as to the company management and planning levels.



SIMATIC IT Framework is the cross-industry integration and coordination platform for operating processes, data, and functions. SIMATIC IT Framework is capable of integrating SIMATIC IT components and existing and heterogeneous IT products.

Examples of SIMATIC IT Components include:

• Production Suite (basic MES functions such as material management, production order management etc.)

• SIMATIC IT Historian (plant performance analysis and long-term archiving)

• SIMATIC IT Unilab (LIMS - laboratory information management system)

• SIMATIC IT Interspec (product specification management system).



3.4 User requirements specification The user requirements specification (URS) describes the requirements that a system should meet. Writing the user requirements specification is the responsibility of the user.

The user requirements specification is the basis for creating a functional specification (FS) and should therefore not include design solutions. The user requirements specification might include the following points:

• Introduction

- Purpose of the user requirements specification

- Author

- References

• Overview

- Description of the process / system

- Aim of the project

- Regulations to apply

• Requirements

- System functions

- Interfaces

- Detailed process description

Note

More detailed information relating to the requirements can be found in GAMP ® 4, Appendix D1.



3.5 Functional specification The functional specification describes the implementation and the functions of the system set out in the user requirements specification. Requirements contained in the user requirements specification that will not be implemented must be listed in the functional specification. The functional specification is normally created by the supplier.

The functional specification should include the following points: • Introduction

- Purpose of the functional specification - Author - References

• Overview - Aims and uses of the system - System interfaces - Deviations from the user requirements specification

• Functions - Information on the performance of the system - Access Protection - Reaction to failures - Startup behavior following a failure - Disaster recovery - Analogous to the user requirements specification

• Data - Definition of data / critical parameters - Access protection for data - Data logging

• Ports - Interfaces to other systems - Interfaces to system equipment - User interfaces

• Servicing - Availability - Servicing

Note For more detailed information on the requirements, refer to GAMP ® 4, Appendix D2.


4 Guidelines for implementing SIMATIC WinCC in a GMP environment

4.1 Introduction In a full automation solution, the SIMATIC WinCC SCADA system handles the operator input, monitoring and data archiving functions. The interface to the automation level is over powerful process links.

Section 331H1 explains the configuration of SIMATIC WinCC in a GMP environment based on examples. The configuration of the automation level in a GMP environment is not described in this section.

The following graphic shows the life-cycle model. The configuration focused on in this section belongs to the Implementation area in the graphic.

Guidelines for implementing SIMATIC WinCC in a GMP environment


4.2 Software categorization of SIMATIC WinCC According to the GAMP® 4 Guide of Validation of Automated Systems, the software components of a system can be assigned to five software categories. Below you will find examples illustrating how this categorization relates to SIMATIC WinCC.



4.3 Software installation The WinCC system software is available as a complete package (engineering und runtime software) or as a runtime package on CD. The software is licensed using license keys graduated according to the number of power tags (external tags) for interfacing to the automation level.

In a multi-user system with server/client structure, the system software with the required number of power tags and the server option is installed on the WinCC server. With a basic configuration, the smallest RT license is adequate for clients.

Prior to installation on a PC, the specified hardware requirements and approved operating systems as specified in the technical specifications in the current HMI catalog ST80 must be checked.

4.3.1 Operating system For detailed information on the hardware requirements and the Windows operating systems, refer to the WinCC Information System, the documentation for the SIMATIC WinCC system software.

By selecting the entry "Read this first" in the start menu of the WinCC CD, you open the WinCC Information System.

You will find information on the operating systems, language variants, service packs, settings, security guidelines, networks, redundant systems, etc. in the "Release Notes" and "Installation Notes" sections.

4.3.2 SIMATIC WinCC software The procedure for installing, the WinCC system software is described in detail in the WinCC Information System in the chapter "Installation Notes". The "Release Notes" section with important up-to-date information should also be read.

! Note WinCC is basically approved for operation in a domain or workgroup. Domain-group policies and domain restrictions can hinder the installation. In this case, remove the computer from the domain prior to installation. After the installation, the computer can be returned to the domain if the group policies and restrictions do not prevent operation of the WinCC software.

Before the WinCC system software is installed on the PC, setup checks whether certain system requirements are met.

• Operating system

• User permissions

• Security policies

• Graphic resolution

• Internet Explorer



•

• The following is required for installation:

• MS Message Queuing that is included as an option in the operating system software.

• SQL Server 2000 that ships on a separate CD along with the SIMATIC WinCC system software.

• Once all the requirements have been met, the installation of SIMATIC WinCC is started. Follow the instructions of the setup.

The setup types "typical installation", "minimum installation" and "user-defined installation" are available.

In a user-defined installation, additional WinCC functions can be selected or functions of the typical installation can be deselected. The Basic Process Control and AS/OS Engineering Mapper functions must be selected separately. The WinCC Server, Redundancy and User Archive options are also on the WinCC CD, but require their own separate license.

WinCC functions / options can be installed at any time.

In a multi-user system or redundant system, the WinCC system software is installed on each separate computer. Information on setting up multi-user systems can be found in the WinCC Information System.

Note

For straightforward operator control and monitoring station, install RT (runtime) only and not RC (configuration system).

4.3.3 Installing utilities and drivers

Print drivers It is advisable to use the printer drivers integrated in the operating system that have been approved for use. If external drivers are used, there can be no guarantee that the system will operate problem-free.

Virus scanners The use of virus scanners during process mode (runtime) is permitted. For more information on the use of virus scanners, refer to the WinCC Information System, section "Release Notes" – Notes on Operation.



4.3.4 Installing SIMATIC WinCC options Further WinCC options and WinCC Premium add-ons are installed only after the WinCC software has been installed.

Note

Care must be taken to make sure that the versions of the software products match up. For more information, refer to the release notes in the relevant documentation.

4.3.5 SIMATIC NET SIMATIC NET is used for industrial communication. SIMATIC NET supplies the communication drivers for interfacing WinCC to the automation level over PROFIBUS or Industrial Ethernet.

For more detailed information, refer to the WinCC Information System > Installation Notes > Scope of Delivery.



4.4 Basic of configuration The SIMATIC WinCC system software allows flexible configuration of process control and monitoring. The configuration is fully customized. A large proportion of the software in WinCC can be configured. Additional functionality can be programmed with scripts. This programmed software means greater effort in validation since it must be placed in category 5 according to the software categorization in the GAMP ® 4 Guidelines.

This section includes proposals and recommendations for configuring a WinCC project in a GMP context, all of which contribute to meeting the GMP requirements for validating a system.

Before turning our attention to configuration in detail, we will first look at several general topics relating to process mode (runtime) of the WinCC software.

Startup characteristics Once the configuration of a WinCC project has been customized, only the runtime component of WinCC is used to control and monitor a system and for data archiving. To prevent unauthorized access to the system, the computer can be configured so that WinCC Runtime is activated automatically when the computer starts up.

When the operating system starts, one user who is a member of the SIMATIC HMI user group must be logged on automatically. This procedure is described on the Customer Support Internet page under Entry ID 15390777 (156Hhttp://support.automation.siemens.com/).

The WinCC project to be opened when the computer starts up is specified in the "AutoStart Configuration" WinCC tool. An alternative / redundant project can also be specified. If the "Activate project at Startup" check box is selected, the WinCC project is activated immediately in runtime. Clicking the "Add to AutoStart" button enters the settings in the computer autostart and these go into effect the next time the computer is started.

The "AutoStart Configuration" dialog is opened with Start >Programs > SIMATIC > WinCC > Autostart.



Additional settings for the startup characteristics are made in the WinCC project. To do this, open the properties of the Computer object from the shortcut menu.

The "Startup" tab contains the WinCC components that were configured and must therefore be active in runtime (for example Tag Logging, Alarm Logging, etc.).

The EXE file of the WinCC option SIMATIC Logon is added in Additional Tasks/Applications. This means that SIMATIC Logon checks user access to process mode after runtime has started.

Other applications that are required to be active on the computer during process mode can be included in the list with the Add button as shown in the Additional Tasks/Applications box of the Computer properties dialog.



Multilingual projects WinCC supports the creation of multilingual projects. Projects can be configured in any language installed on the operating system. The majority of texts are stored centrally in the text library. Using the convenient export and import functions, texts can be exported for translation and then read in again. Configured text elements of the Graphics Designer (static text, tooltips, button labels) are not entered in the Text Library but are stored in the picture. Using the WinCC Easy Language tool, these texts can be exported for translation and then imported again.

The language can be changed during process mode, for example with a button.

Refer to the WinCC Information System for more information on multiple languages in WinCC projects.

Diagnostics for communication connections WinCC provides a channel diagnostics tool for monitoring communication connections to the lower-level controllers. The tool can be integrated into a WinCC picture as an ActiveX Control (for example in a diagnostics picture). The status of the channels that support diagnostics is displayed in a window. Information on the start / end of the connection, version number and error messages with date / time stamp are automatically recorded in a log file. This represents evidence of the quality of the communication connections provided by the system.



System information channel The system information channel is used to evaluate system information such as drive capacity, CPU load, server monitoring by a client, date, time and much more. The system information channel is configured as a separate connection. The relevant system function is linked to a system tag for display / evaluation.

In a GMP environment, it is often necessary to archive large amounts of data. By configuring the system information channel, the capacity of the hard disk can be monitored. If a definable limit value is exceeded, a reaction can be configured, for example a message in Alarm Logging.

The example shows how a system tag is set up to evaluate the hard disk capacity.

The display of the relevant system tag could, for example, be configured in a diagnostics picture along with the ActiveX control Channel Diagnosis.



4.4.1 Object-oriented configuration By using picture windows (for example for controlling process units such as valves, drives or similar) and user objects (for example for uniform visualization of objects) in WinCC, the configuration can be created object-oriented. The objects (picture window, user blocks) are created once for the various use cases. The design and control philosophy must be discussed with the customer, described in a specification and approved by the customer. The individual objects are then put through a function test and qualified. When configuring the process pictures, copies (user objects) or instances (picture windows) of the qualified objects are used.

User objects A user object is an object whose graphic representation and dynamic characteristics are tailored to the requirements of the system. The object properties and the events that cause a dynamic response in the object are specified individually in a configuration dialog. Structure tags are recommended for the dynamic response of the user objects (see structure variable below).

User objects are either entered in the project library or collected together in a standard picture.

The procedure for creating user objects is described in detail in the WinCC Information System.

Note

When a user object is duplicated, a copy is made. If a user object is changed, for example by adding an object property, all the linked user objects must be updated manually.



Picture window The picture window smart object allows a picture to be called within a picture. This functionality is used, for example, to call a window for controlling a process unit (valve, drive). Such an operator control picture is configured once for a particular function and then opened as an instance in a picture window. When the picture is called, a tag prefix is transferred (see structure tag below).

The example shows the properties of a picture window. The picture name, tag prefix and title properties were configured.



Structure tag Structure tags are used to make picture windows and user objects dynamic. A structure type is defined for a process unit, for example a motor, and contains all tag types for the motor as structure elements.

The example shows a simplified form.



A new tag of the data type "Motor" is created in the WinCC tag management for the corresponding communication connection. The addressing is configured accordingly.

Based on the example, the following tags will be created for the communication connection:



The tag name is made up of the structure instance, for example the name of the motor, and the structure elements of the structure type separated by a period. The structure instance is transferred to the picture window as the tag prefix property (see example of picture window above).



The individual structure elements are linked to the relevant object properties to allow a dynamic response in the picture that is called in a picture window to control of the motor.

By linking the structure elements, the picture is dynamically updated once. When the picture is called, only the tag prefix is transferred.

The procedure with user objects is similar. The structure elements are attached to the configured, user-defined object properties. To link to the tag instance, the dynamic Wizard "Change user object link" is used that is integrated in the WinCC Graphics Designer.



4.4.2 Creating process pictures The WinCC Graphics Designer editor is a combination of graphics program and process visualization tool. A series of utilities support both graphic creation and dynamization of the plant flowcharts.

To allow flexible graphic design, standard objects (graphic elements, static text), smart objects (bars, windows etc.) and Windows objects (buttons, checkboxes, sliders etc.) are available in an object palette.



The following refers to a few tools and functions used to reduce the validation work required for an automation system in the GMP environment.

4.4.2.1 Symbol library The integrated global library contains numerous pre-configured graphic objects. Graphic objects such as machines and plant components, measuring equipment, operator control elements and buildings are thematically organized. The library objects can be inserted with drag-and-drop and adapted as required.

Note

To keep the work for qualifying process pictures to a minimum, it is advisable to use standard symbols from the symbol library.

4.4.2.2 Project library The project library can be used to store objects developed and defined by the user that can then be included in multiple process pictures. User-defined objects that have been tested and qualified individually are stored in the project library and are then available as a project standard for multiple uses.

Note

The project library is part of the WinCC project and is located in the subdirectory "\library". To allow its use in other WinCC projects, the library.pxl file must be copied to the corresponding folder of the destination project.



4.4.2.3 Project functions in the form of VB / C scripts Functions required more than once in the WinCC project should be configured in the Global Script editor. The function code is created once either in the VB script or C script and then tested and qualified. The function is then available throughout the entire project. The function call is simply programmed in the property for the picture object.

4.4.3 Creating overview pictures To visualize a complex process for operator control and monitoring, a series of process pictures is created. This, however, means that a system is required for picture selection or picture navigation during process mode. The Basic Process Control option is a standardized system for process control available in SIMATIC WinCC.

Note

The option is included on the WinCC system software CD but installation must be selected extra.

If the Basic Process Control WinCC option is installed, the following editors are added to the WinCC Explorer.

The OS Project Editor is used to configure the WinCC project for standardized operator control of the process among other things, the monitor layout, monitor resolution, operating philosophy for the buttons, and message presentation are configured.

The user interface is divided into three areas, the overview area, the work area and the button area.



For detailed information on configuration, refer to the WinCC Information System; section Options > Options for Process Control.

Both the overview graphics and the operator control philosophy must be described in the specification (for example URS, FS and P&I) and created accordingly. When completed, these should be shown in the form of screenshots to the customer for approval.

Note

The OS Project Editor should be configured before starting to create the process pictures because the size of the individual process pictures depends on the monitor resolution and screen layout.

Additional editors included in the Basic Process Control WinCC option are:

• Time Synchronization (see section 332H4.9 "333HTime synchronization")

• Acoustic horn for acoustic signaling of alarms

• Lifebeat Monitoring (see section 334H4.13 "335HLifebeat Monitoring")



4.4.4 Operator messages For plants operated in a GMP environment, FDA regulation 21 CFR Part 11 requires that operator input to the process that affects data relevant to GMP can be traced.

GMP-relevant process input made using input/output fields or buttons must be configured in the WinCC Graphics Designer so that an operator input message is generated. This operator input message is recorded in WinCC Alarm Logging with the time stamp, user ID, old value and new value. This means that such actions can be traced within the system.

The operator input message is a system message that is displayed in WinCC Alarm Logging. WinCC Alarm Logging must be configured accordingly (see also section 336H4.8.2 "337HAudit trail via WinCC Alarm Logging").

Input/output field To create an operator input message for an I/O field object, the Operator input message property must be set to yes. If the Operator Activities Report property is also configured with yes, the system opens a window for entering comments after the value has been applied.

The I/O field is also assigned access protection. For the Authorization property, a function is selected that was configured earlier in the WinCC User Administrator (see section 338H4.6.5 "339HConfiguring the User Administrator"). Only persons authorized to use this function can make changes in the I/O field.

The figure shows the Properties > Miscellaneous selection for an I/O field in WinCC Graphics Designer.



Button As default in WinCC, an operator input message is generated only when a direct connection to a tag is configured. This means that if there is a direct connection, the mouse click event for the button writes the value specified for the constant to the defined tag. If the Operator Input Message check box is selected, the system generates a message. It is not possible to enter an operator input comment here.

Functions that are not offered here, for example entering comments, can be programmed using script functions. These functions belong to software class 5 and require more work for validation.



Script functions for changing values If the options described for creating an operator input message for I/O fields and buttons are not adequate, an operator input message can be generated using C scripts. The following project function was developed for this purpose:

ISALG_OperationLog int ISALG_OperationLog( char* pszSource, char* pszArea,

char* pszEvent, char* pszBatch, char* pszUnit, double fOld, double fNew, char* pszComment )

The transfer parameters in this function call have the following meaning:

pszSource Source (for example tag name or process tag name)

pszArea Area (for process cell area or unit)

pszEvent Event text (for example "Setpoint input" or "Motor ON")

pszBatch Batch name pszUnit Unit of measurement fOld Old value

fNew New value

pszComment Comment

This project function can be downloaded free of charge from Customer Support under entry ID 24325381 (http://support.automation.siemens.com/).



4.5 Configuration management SIMATIC WinCC is a cross-branch operator control and monitoring system. Standard components are available in the form of a global library containing a wide variety of graphic symbols and in the form of ActiveX controls used, for example, to display measured values graphically.

Configuration is customized to meet the requirements of the production plant being visualized. Configuration is difficult to trace without version and change management. Therefore, professional configuration management should be used right from the start of configuration.

The configuration management should be described in an SOP. Everyone involved in the project must be trained in the use of this SOP; this produces a common base for the configuration.

The following section provides an example of software versioning and change control.

Note

Always consult the plant operator to agree upon a procedure for making changes to a plant in ongoing operation.

4.5.1 Changing system software

Updates, service packs and hotfixes Updates, service packs and hotfixes are provided for the WinCC basic software for functional expansion or for fixing bugs.

• A WinCC update is an update within a WinCC version. This may require conversion of the project data.

• A service pack remedies faults and contains several hotfixes.

• A hotfix is a fast remedy for faults. Hotfixes are only provided in special situations.

The validation work with respect to changes is specified within the framework of a risk assessment.



Upgrades (migration) An upgrade upgrades the WinCC system software so that the range of functions is expanded or improved.

When there is a version change (for example from version 5.x to version 6.0) or a software update of the WinCC system software, it may be necessary to migrate or convert data created with the older version.

! Note The situations in which migration or conversion of the project data becomes necessary are described in the WinCC Information System of the new version in the section Upgrading WinCC > Notes on Migration of Projects.

The Project Migrator is available for migration. The project data is migrated in offline mode, the WinCC system software must be completely closed down. Follow the instructions of the Project Migrator. If adaptation of the project is necessary, this requires validation.

The validation effort is specified in consultation with the plant user. Possible test points are the new functions available in WinCC and the correct installation of the software components required for migration.

Note

The migration procedure is described in detail in the WinCC Information System in the section "Migration".

Procedure for updating the system software When updating the WinCC system software, certain measures are required to retain the validated status of the plant:

• Basis for a change is always the change request of the customer

• Description of the causes for the update of the system software

• Description of the new functions

• Information on the compatibility to the previous version

• Update of the technical documentation

• Installation according to manufacturer documentation (for example standard documentation, project migrator)

• We recommend you perform a risk analysis beforehand and specify the main testing points for the qualification

• Qualification



Note The SIMATIC Customer Support at 157Hhttp://support.automation.siemens.com provides support for software updating and project migration.

4.5.2 Versioning user software

4.5.2.1 General information on versioning The software version provides information on the current version of the system and application software.

The following data is specified for the versioning of the user software:

• Name

• Date

• Version number

• Comment on the change

Note

Automatic versioning of the software configuration is not implemented in WinCC. Versioning must be performed manually in the individual software components.

The procedure for the versioning is part of the configuration management and must be described in a SOP, which is binding for all persons participating in the project.



The following describes examples and options for versioning in WinCC:

4.5.2.2 Versioning pictures in Graphics Designer When the Graphics Designer editor is selected in WinCC Explorer, all existing process pictures are listed in the right window. The properties of every process picture can be displayed using the shortcut menu. The data shown is generated automatically by the WinCC system.



Additional information on versioning, for example the version number, date changed and name can be entered in a static text box. It is practical to place the text boxes for versioning in a separate picture level that can be shown or hidden as required. The display of the static text box during process mode is controlled by the Display object property.

Note Details of a change can, for example, be described in the relevant validation documents.

4.5.2.3 Versioning VB / C scripts VB or C scripts are created to access tags and graphic picture objects during process mode (runtime) and to trigger actions that are not dependent on pictures.

Scripts are also used to link functions triggered during process mode to individual object properties in Graphics Designer (for example input using the mouse).

Two different methods of script creation are distinguished in WinCC:

• Picture-dependent VB / C scripts that are linked to the property of an object in the Graphics Designer WinCC editor. These scripts are part of the picture and are stored with the picture. Versioning is performed in the picture.

• Non picture-dependent VB / C scripts created in the Global Script WinCC editor.



VB / C scripts created with the Global Script editor provide boxes in the Properties dialog for entering the data Create By, Changed By, Version and Comment. The creation date and date of change are entered automatically by the WinCC system.

An optional password can also be assigned.

Note

If a password is used, this is not checked against the logged-on user. Knowing the password allows the script to be opened / edited. If the password is forgotten, access to the script is permanently denied.



It is advisable to maintain a history in the scripts indicating any changes made. The history is entered as comment before the start of the code. As an alternative, the comment box of the Properties dialog (see above) can also be used to record the history.

Example of recording the history in a C script

Example of recording the history in a VB script



4.5.2.4 Versioning reports Automatic versioning in the report layouts is not supported. A static field can be inserted in the report layout for a version number allowing manual versioning. The version number must be kept up-to-date as specified in the SOP for configuration management. The following picture shows an example of report layout footer with a field added for versioning.

4.5.2.5 Versioning projects The concept for versioning WinCC projects is part of configuration management. A detailed description of the type of versioning, how it will be performed and how the version numbers will be assigned if required.

Variants of versioning

• Saving the project directory as a compressed file, for example using the Archiving function implemented in SIMATIC Manager if the project is integrated in STEP 7.

• Siemens "Version Trail" software product for projects integrated in STEP 7

In this storage concept, it might be specified, for example, that the project is backed up following a change. The WinCC project is backed up by saving it as a compressed file on a different drive (for example an external drive, network drive) or by burning to CD / DVD. Numbering of the version can, for example, be included in the file name of the compressed file. When compressing the WinCC project, it is important that the folder hierarchy is retained so that the project can be read again later.

Within the framework of Totally Integrated Automation (TIA), the WinCC HMI system is integrated in the SIMATIC Manager. The WinCC project has been integrated in the STEP 7 project. In this case, the Version Trail software product is used for versioning. Version Trail supports the archiving of projects and assignment of a version number. The version number is entered in a dialog along with a suitable comment. A major version and minor version can be distinguished. Older versions can be retrieved easily. A version history records actions such as creating, modifying, old versions, deleting, etc. with archive name, date and comments. This means that the system creates continuous documentation of the various versions. More detailed information can be found in the "SIMATIC S7 GMP Engineering manual: Guidelines for Implementing Automation Projects in a GMP Environment".



Note To ensure traceable versioning with a version history, variant 2 is recommended. The Archive function implemented in the SIMATIC Manager automatically compresses an integrated WinCC project.



4.5.3 Changing application software Changes to application software must be versioned along with a description of the change. When the change is implemented, the specifications of the user must be taken into account.

The following sections describe how to make changes to a WinCC project:

WinCC projects should not be changed during runtime when the process is running.

The effects of the changes to other parts of a WinCC application and the resulting tests must be specified as the basis of a risk analysis and documented.

3. Back up of the actual WinCC project

1.Release of change specification by plant owner

2. Description of the software change(e.g. FS)

4. Implementation of software change based on the new version

Document configuration changes in WinCC Audit

5. Test of changes incl documentation (e.g. FAT)

6. Back up of the changed software incl. versioning



4.6 Setting up access protection A crucial requirement for the pharmaceutical environment is access protection on the system (see “21 CFR Part 11” and “Annex 11 of the EU GMP Guide“ in section 340H1 as well as section 341H2.5 ). This includes setting up user groups. SIMATIC Logon allows graduation of operator input to the process within the SIMATIC WinCC system including PM-CONTROL, PM-QUALITY and other options / add-ons.

The WinCC option SIMATIC Logon is based on Windows user management. SIMATIC WinCC and the WinCC Premium add-ons work with SIMATIC Logon to provide access protection.

Note The structure of the access protection must be specified at the start of configuration. All the permissions for working with the visualization user interface (faceplates, input boxes, buttons, etc.) must be set up according to the specifications in the URS and the FS.

! Note The access security all the monitoring mechanisms (password age, password length, password generation, password lockout threshold, etc.) must be configured and set in Windows. The operating system user should also only have power user or user permissions and should not have administrator privileges. This ensures that only WinCC has access to the database. This means that access by the operating system to the SQL database is impossible.



The following order must be adhered to: • Setup of access protection in Windows (setting up of user groups and users)

• Installation and setup of SIMATIC Logon

• Setup of the access protection in SIMATIC WinCC > User Administrator

The individual applications can then be configured in any order:

• Assignment of permissions in the visualization user interface (picture window, input boxes, buttons)

• Setup of access protection in PM-CONTROL or PM-QUALITY if the WinCC Premium add-ons are used

4.6.1 How access protection works The mechanisms of Windows user management are used to administer operating system users and WinCC process mode (runtime).

Normally, at least two users are created in a SIMATIC WinCC production system. On the one hand, there is the operating system user coordinating SIMATIC WinCC runtime software, and on the other, these SIMATIC WinCC runtime user controlling and monitoring the process.



Operating system user Activities and permissions of operating system users:

• Changing application software to an active (process mode) state under SIMATIC WinCC (server, clients). In this state, the applications must have at least power user permissions under Windows so that the applications have read and write permissions for drives, folders, databases, etc.

• Making changes to the engineering system, shutting down WinCC runtime (process mode), access to all drives, creating, changing and deleting folders and setting up new users.

SIMATIC WinCC runtime users Activities and permissions of SIMATIC WinCC runtime users:

• Controlling the process in a productive system (runtime), checking processes, writing/modifying recipes, creating batches, etc.

• Only "Guest" permissions under Windows in the operating system, no possibility of shutting down WinCC runtime.

Note When the Windows audit trail is activated (see section 342H4.6.2 "343HUser management in Windows"), or changes made by an operating system user are recorded. SIMATIC WinCC runtime users with Windows "Guest" permissions cannot start any SIMATIC WinCC applications, delete folders or shut down PCs.

4.6.2 User management in Windows Since the user management of SIMATIC Logon is based on the mechanisms of the Windows operating system, there are two options are available for user management in Windows:

• In a domain

• In a workgroup

Windows domains Within a domain, the AGLP strategy (Access Global Local Permission) recommended by Microsoft in the management of resource access over trusted relationships in Windows) is used; in other words, if users of a domain with the same tasks are added to a global group, they are also added to a local group and then adopt the necessary permissions. If a domain server is used in the working environment, the advantages of the group and user management can be used in conjunction with SIMATIC Logon. The central administration of groups and users on the domain server allows all computers that belong to the domain access to the groups and users. To increase availability, domains can be set up with several domain servers.



Windows workgroup Within a workgroup, local users with the same topics should be added to a local group and the required permissions assigned to the group.

If a computer is a member of a Windows workgroup, the computer acting as server of the workgroup must be specified. All user data is created and managed on this server. From here, they are made available to the other computers in the system. The WinCC server can be included in the server selection, however for performance reasons a separate computer is often selected and used only for managing users.

In the logon list box, the local computer or a domain can be selected. This displays all groups of this server. Administration of the groups and users of the computers belonging to the workgroup is not necessary. A redundant configuration is not possible in this case. Emergency operation is possible using the local user management.

• SIMATIC WinCC supports the Windows permissions model. When SIMATIC WinCC is installed, the following local groups are set up:

• SIMATIC HMI

• SIMATIC HMI CS

• SIMATIC HMI VIEWER

• SIMATIC WinCC manages the security settings and share rights automatically. To create and start a WinCC project, a user requires the administrator or power user status and must be a member in the SIMATIC HMI user group. The access rights within the WinCC project are checked by User Administrator.

! Note The Windows domain must be used when there are several servers or redundant servers to make sure that users can continue to make input or log on if a domain server fails.

4.6.3 Configuring user management in Windows In Windows user management, users and groups are configured as specified in the URS or FS. Assigning a logon for the relevant tasks on WinCC PCs achieves the following:

• When logging onto Windows, each user is assigned exactly the permissions required to perform the particular task. For example, in order to work on the WinCC project, the user must be a member of the local group Power User and SIMATIC HMI.

• With the logon in process mode, the operators are assigned permissions for operating the plant according to their group rights.



The following screenshot shows the "Local Users and Groups" dialog box in which the users and user groups are defined.

Computer management is opened with Start menu > Control Panel > Administrative Tools (in the Windows XP operating system). After selecting Computer Management > Groups, all the user groups created in the operating system are displayed.

Further Information • WinCC Information System, section Working with WinCC > Setting Up User

Administration > WinCC Options for the User Administrator > Option SIMATIC Logon

• Permissions management in Windows SIMATIC HMI, Process Visualization System WinCC V6.0 SP4, Security Concept WinCC, Chapter 4 "User and Access Management in WinCC and Integration into Windows Management".



Security settings of password policies For the monitoring mechanisms of the password policies of Windows, the previously specified settings (URS, FS or DS) must be made. The following security settings of the password policies are relevant and must be configured in the operating system.

Policy Description of the security setting

Enforce password history

Specifies the number of unique, new passwords that must be used before an old password can be used for the user account.

Password must meet complexity requirements

When it is activated, the password must contain at least three of the four following categories: 1. A-Z uppercase letters 2. a-z lowercase letters 3. 0-9 numerical characters 4. !,$,% etc. special characters

Minimum password length

Specifies the minimum number of characters a password must contain

Maximum password age

Specifies the maximum time that a password may be used before it is changed.

Minimum password age

Specifies the minimum time that a password must be used.

The following screenshot shows the "Password Policy" dialog box. The settings shown are examples:

Computer management is opened with the following menu command: Start > Settings > Control Panel > Administrative Tools > Security Settings.



Security mechanisms for account lockout policies For the monitoring mechanisms of the account lockout policy of Windows, the settings as specified in the user requirements or functional specification must be made. The following security settings in the account lockout policies are relevant and must be configured.


Account lockout threshold Specifies the number of failed attempted logons before the user account is locked out.

Account lockout duration Specifies how long an account remains locked out before the lockout is canceled automatically. If the value 0 is set, the account remains locked out until it is unlocked by the administrator. This is the recommended setting.

Reset account lockout counter after

Specifies how long it takes in minutes before the account lockout counter is reset following failed logon attempts.

The following screenshot shows the "Account Lockout Policy" dialog box.



Security settings for audit policies The following settings must be made in the audit policies of Windows to generate a recording (audit trail) of attempted logons. The monitored events are stored in the event viewer in the security log and are available for investigation.


Audit logon attempts Specifies whether the instance of a user logging onto a computer is monitored.

Audit account management

Determines whether to audit each event of account management (creating or changing a user account, changing or setting passwords)

Audit logon events Determines whether each instance of a user should be audited when logging on or off on a computer.

Audit policy change Determines whether to audit every incidence of a change to user rights assignment policies, audit policies, or trust policies

Computer management is opened with the following menu command: Start > Settings > Control Panel > Administrative Tools > Local Security Settings.

Note To monitor the logon activity, the required settings must be made in the audit policy of the local policies of Windows.



! Note After installing Windows, default parameters are set for the password policy, account lockout policy and audit policy. The settings must be checked and adapted to the requirements of the current project.

Further Information • Additional information on setting up Windows workgroups and Windows

domains can be found in the operating system help of Microsoft Windows or in the appropriate Windows manual.

• On setting up user administration, refer to the WinCC Information System, Section "Working with WinCC".

• On permissions management in Windows SIMATIC HMI, Process Visualization System WinCC V6.0 SP6, Security Concept WinCC, Chapter 4 "User and Access Management in WinCC and Integration into Windows Management".

4.6.4 Configuring SIMATIC Logon To operate correctly, the following settings must be made for SIMATIC Logon:

• To configure SIMATIC Logon, a Windows group with the name "Logon_Administrator" must be created. All users assigned to this group have permissions to configure SIMATIC Logon.

• The full name of every user must be entered in "Local Users and Groups" in Windows Computer Management. This name is used by the application for display in SIMATIC WinCC after logging on.

The basic settings for configuring SIMATIC Logon are made with the "Configure SIMATIC Logon" tool. When the tool is started, the following dialog opens.

The relevant language is set in the "General" tab. It is also possible to define whether a default user is logged on after a user has logged off (add their own initiative or by the system). It is also possible to set the number of days after which a user is reminded that a password change is necessary.



! Note

In contrast to all other users, the "default user" must not be created as a Windows user. The "Default user" is a member of the "Default group" and "Emergency_operator" groups. Which rights these groups have is specified in the WinCC User Administrator (server/client).



In the "Working environment" tab, the user specifies whether the information relating to groups and users relates to a Windows domain or a Windows workgroup server. The name of the domain or workgroup server must be entered.

In the "Logon device" tab, the user specifies whether the logon is via the keyboard, smart card or other procedure such as biometric user identification, for example by fingerprint.

In the "Automatic logoff" tab, the user specifies whether automatic logoff is used. If this is selected, the delay before a user is automatically logged off must also be specified.



If automatic logoff is enabled, the user is logged off automatically if there is no activity within the specified time. Prior to the logoff, a dialog indicates that the automatic logoff will take place. This avoids accidental logging off.

! Note Activating a screensaver is not permitted in conjunction with SIMATIC Logon.

Connecting SIMATIC WinCC After configuring SIMATIC Logon, the following adaptations must be made in WinCC. These adaptations are made using the "WinCC Adapter" tool.

Procedure:

• Open the "WinCC Server" (Start menu > Programs > SIMATIC > WinCC > WinCC V6.0).

• Open the "User Administrator" and select the SIMATIC Logon check box.

• Open the "WinCC Adapter" (Start menu > Programs > SIMATIC > SIMATIC Logon > WinCC Adapter).

• The adaptations are then made automatically (see dialog box).

Note

To allow operator input in process mode, user groups are configured in the WinCC User Administrator.



4.6.5 Configuring the User Administrator The assignment of Windows groups to WinCC user groups is based on names. For example, the "Operator" Windows group will be assigned to a group of the same name "Operator" set up in the WinCC User Administrator. The Operator group is assigned the rights necessary for operator control in the WinCC system. The following procedure must be adhered to:

• Open WinCC project.

• Open User Administrator using WinCC Explorer.

• Create group(s).

• Assign permissions for each group.

The check box for enabling SIMATIC Logon must also be selected in the User Administrator of the WinCC project.

! Note In conjunction with SIMATIC Logon, it is not permitted to configure a time for an automatic logoff in the User Administrator. An automatic logoff is configured only in SIMATIC Logon. (See section 344H4.6.4 "345HConfiguring SIMATIC Logon")



Note

The configuration and assignment of user permissions is described in detail in the WinCC Information System in the section Working with WinCC > Setup of a User Administration.

4.6.6 Disabling the Windows level in process mode Since access to the Windows operating system level should be avoided for security reasons, additional configuration settings are necessary. These settings avoid unauthorized access from the process mode of SIMATIC WinCC to sensitive data of the operating system.

! Note Access to the operating system level should only be permitted for administrators or maintenance personnel.

4.6.6.1 Disabling the user interface Access to the operating system during process mode is configured in the WinCC project in the computer properties. All key shortcuts are disabled as shown below.



The "Keep the taskbar on top of other windows" setting must also be disabled in Windows.

It is important to ensure that process mode can only be deactivated with suitable operator permissions. After disabling and restarting, the operating system level can be accessed.

For more detailed information on security of data and the system, refer to the WinCC Information System, Installation Notes section.

4.6.6.2 Preventing access to the Windows level It is important to make sure that no OLE objects are configured, for example that call the Internet Explorer. Windows OLE objects represent a way in which folders, files and programs could be accessed without permission.



4.6.6.3 Security with configuration settings in WINDOWS Any HOT KEY assignments must also be disabled. HOT KEYs are often used, for example, to influence the properties of the graphics card. By changing the graphic card properties, it is also possible to reach the operating system user interface.



4.7 Electronic signature Operator actions in WinCC, for example, input via I/O fields or buttons, can be configured so that an electronic signature is required from the user. The operator actions that require an electronic signature in process mode must be specified in the specification (URS, FS).

Below, there is an example of configuring use of a button with an electronic signature.

In the example, the Start / Stop buttons turn the air-conditioning on or off. When the button is clicked, a picture window opens in which the password of the logged-on user is requested. The button function is executed only after the correct password has been entered.

Procedure:

2. Two buttons for Start and Stop are configured in a process picture. In the Object Properties > Miscellaneous, the operator control enable was set to No for every button. The status of the operator control enable Yes / No is controlled depending on the AirCond_Active tag. This is achieved by linking the tag or using a dynamic value dialog.

3. For the Authorization property, the Aircondition function was assigned to each button. This restricts the operator input permissions for the button to those users who are members of a user group to which the Aircondition function was assigned. This is configured in User Administrator (see section 346H4.6.5 "347HConfiguring the User Administrator").



4. In the object properties in the Events tab, the Mouse Action property is linked to a direct connection. Here, the Display property of the object AC_Signature (in this example the name of the picture window) is assigned the constant 1. The effect of this configuration is that when the mouse is clicked on the button, the AC_Signature object is displayed. In this configuration example, AC_Signature is the name of the picture window that will be displayed for the signature when the button is clicked.



5. In the object properties for the AC_Signature picture window, the Display property as the default No. The name of the picture to be displayed in the picture window is specified for the Picture Name property (here: ElectronicSignature.pdl).



The picture ElectronicSignature.pdl was configured as follows for the configuration example. Next to the static fields User ID / Name, a static text displays the content of the system tags @CurrentUser and @CurrentUserName. Next to the static field Password, an I/O field for entry of a string is configured in which the password can be specified. The Mouse Action property of the Sign button is linked to a script. When the Sign button is clicked, the script is checked to establish whether or not the entered password matches up with the logged-on user. If the password is wrong, a message is displayed. This script can be downloaded free of charge as the FAQ with Entry ID 24458155 from http://support.automation.siemens.com/.



The operator input is as follows in process mode:



4.8 Audit trail To record an audit trail of user actions involving data relevant for GMP, the use of the WinCC Audit option is recommended, however, Alarm Logging of WinCC can also be used. Both variants are introduced below.

4.8.1 WinCC Audit The runtime monitoring components are enabled in the configuration dialog of the WinCC Audit option. Runtime Data / Archives monitors entries both in the message / process value archives and in the user archives. Enabling Operator Actions records operator input during runtime in the audit trail. The logon/logoff procedures during runtime are also saved in the audit trail.

In WinCC Audit, operator input to standard objects such as I/O fields, sliders, check boxes, option buttons and text lists can be recorded. The recording of the operator control elements is enabled for each individual object in each process picture.

For I/O fields, text lists, and slider bars, the display of user comments can also be enabled.

A generation of an operator input message is enabled for WinCC tags written to over a direct connection in WinCC (see section 348H4.4.4 “349HOperator messages”).



The InsertAuditEntry function is also used to create audit trail entries. This function can be linked both in C scripts and VB scripts. This allows user-specific audit trail entries to be generated, for example due to events or changes in object properties.

Note For additional information on configuring WinCC Audit, refer to the documentation of this WinCC option.

The time stamp of the audit trail entries is the local computer time of the computer on which the audit trail is recorded. In a WinCC multi-user system, regular time synchronization is necessary to ensure the correct chronological order of the audit trail recordings.

The WinCC Audit option stores the audit trail in a separate database. The audit trail can be viewed with the Audit Viewer application that is part of WinCC Audit. Each WinCC Audit database can be selected and displayed in Audit Viewer.



The Audit Viewer displays the content of the audit trail database. Filter functions are integrated for displaying changes to the WinCC configuration (Configuration tab), operator input (Runtime tab), document control (Document Control tab) and WinCC Audit itself (WinCC Audit tab). A date/time filter is also available.



It is also possible to create and save user-defined filters (Custom tab).

To allow viewing of the audit trail in plant pictures during WinCC runtime, the Audit Viewer application can also be linked into a WinCC picture as an OCX.

Note The Audit Viewer only displays the data and there is therefore no possibility of entries being manipulated.

As an alternative, the audit trail database can also be viewed using other database applications, such as MS SQL Enterprise Manager, from any computer in a network. To protect the audit trail database, this view is enabled only via the user account WinCCAuditViewer that is assigned read-only permissions.

If required for other purposes, the generated audit trail can be exported to and MS Excel file. This is only possible if MS Excel version >= 10 is installed on the computer. It is also possible to document the data on a printer. If a PDF writer is installed on the computer, the data can be stored as a PDF file.



4.8.2 Audit trail via WinCC Alarm Logging Operator input through input/output fields or buttons can be configured in the Graphics Designer in WinCC so that and operator input message is generated by the system. (For the configuration, see section 350H4.4.1 "351HObject-oriented configuration")

To display logon and logoff activities in the WinCC system, the display of system messages is generally set up in WinCC Alarm Logging. This is done by selecting the entry WinCC System Messages in the Options menu. The following dialog opens in Alarm Logging:

The operator input message is a system message that cannot be configured user-defined. Values that are changed due to the operator input are automatically entered in process value 2 (old value) and in process value 3 (new value) by the system. We therefore recommend that you rename process value blocks 2 and 3.



To display operator input messages in a process picture, the WinCC Alarm Control is dragged from the object palette to a picture in the Graphics Designer.

Double-clicking on the control opens the Properties dialog. To ensure that only operator input messages are displayed, a selection must be made. The Selection button opens the configuration dialog. Under System Blocks > Message Classes, the System message, without acknowledgement is selected. On the right in the detailed window, the operator input message must simply be selected.



To allow entries for the logon / logoff of a user to be shown in the audit trail, the type must be changed from process control to operator input message by double-clicking in the Type column for the message numbers 1011500 through 1011511 in the WinCC Alarm Logging.

The display of the message blocks is also configured in the Message Lists tab.

The audit trail is displayed in the process picture as follows:



The X in the Comment column shows that a comment exists. This can be displayed with the button marked in the screenshot as follows:



4.9 Time synchronization In SIMATIC WinCC, the time transmitted on the bus as default is the standard world time UTC (Universal Time Coordinated). This corresponds to Greenwich Mean Time.

The time stamps are generated in UTC and stored in the archive of the WinCC server. In runtime, the process data stored in the archive (messages and texts) are displayed with the timebase configured in the Properties dialog of the ActiveX control. This allows a system configuration in WinCC over different time zones.

Activating time synchronization in WinCC means that an active time master handles the synchronization of all servers, operator stations, automation systems (AS) and the engineering station. To ensure that times match, all the stations belonging to the WinCC system must be synchronized to allow chronological processing (archiving trends, messages, redundancy synchronization of servers).

Note

The activation of time synchronization is necessary in plants in which GMP is mandatory.

! Note

Time synchronization must also be activated on the engineering stations otherwise problems could arise when downloading changes.

4.9.1 Concepts for time synchronization The configuration of the time synchronization must be carefully planned. Every time synchronization activity in the project is subject to the requirements. The requirements of time synchronization must be described in the function specification. The following sections introduce concepts in time synchronization.

Time synchronization in a Windows workgroup The time in a workgroup should be synchronized via the OS server. The time synchronization of the OS server can also be implemented using a time master, for example the DCF77 service or GPS service.



Time synchronization in a Windows domain If the automation system is operated in a Windows domain, the domain must act as time master. The time synchronization of the domain server can also be implemented using a time master, for example the DCF77 service or GPS service.

If the time is inaccurate, this can lead to clients being rejected in the domain. This would mean that operator input in process mode at these clients is no longer possible.

If a time difference of five minutes is exceeded between the domain and clients, the operating system assumes that an attacker has decrypted the logon and is attempting to take over the session. This is prevented by denying the client logon to the domain.

Note

The time on the clients in the domain is synchronized using Microsoft system services.

Further Information • Procedures for configuring time synchronization can be found in the following

documents:

• WinCC Information System > Options > Options for Process Control >Time Synchronization

• WinCC Information System > Release Notes > Process Control Options > Time Synchronization

• SIMATIC HMI manual, Process Visualization System WinCC V6.0 SP4, Security Concept WinCC, Chapter 5 "Planning Time Synchronization".

4.9.2 Example configuration in WinCC To configure time synchronization, the Time Synchronization editor is opened in WinCC Explorer.



4.9.2.1 Client/Server 1. Time synchronization over the plant bus (WinCC server is time master).

By selecting the "Synchronization via System Bus (Master, Slave)" checkbox, the access point for time synchronization can be defined. The WinCC server is also declared as time master.



2. Time synchronization of the clients Selecting the "Synchronization via Terminal Bus (Slave)" check box, specifies that the client is synchronized over the terminal bus / local area network. As reference partner, it is possible to specify whether the time is taken from a connected WinCC server or from a defined computer (in this case from the computer with the name "Server1".

4.9.2.2 Via Ethernet / system bus Time synchronization over the system bus/Industrial Ethernet is only available with WinCC server projects. If the computer being configured is a WinCC client, no settings are possible and the selection fields are not available.



4.9.2.3 Via PROFIBUS / MPI Direct time synchronization on the system bus over PROFIBUS / MPI is not available in WinCC. Instead, the time can be set in the automation system. “time setting“, however, does not have the same level of accuracy as time synchronization since message frames and script runtimes are included.

The procedure for setting the time is described in detail in the FAQ with Entry ID 7802886 (158Hhttp://support.automation.siemens.com/WW/view/de/7802886).

4.9.3 Time stamping

WinCC Alarm Logging Messages archived from the automation system in WinCC Alarm Logging, are given the time stamp either of the WinCC system or of the automation system SIMATIC S7-300/400.

With the bit message method, the message is detected due to a bit change in the message tag. Alarm Logging assigns the time stamp of the WinCC system. The time stamp has a certain inaccuracy due to the acquisition cycle, bus delay time and time required for processing the message. Alarms are lost if they are shorter than the acquisition cycle.

If tags in WinCC violate a limit value, a message is generated in Alarm Logging when the defined limit value is violated. The time stamp is set as in the bit message method.

With chronologically ordered signaling, the automation system sends a frame with the data of the message. The time stamp of the alarm is assigned by the PLC. A standard function or function block is used on the automation system to generate the message frame. Alarm Logging evaluates the frames. The date and time are set according to the time at which the message was detected in the automation system.

Note

For information on the message procedure, refer to the STEP 7 help > Configuring Messages > Basics of the Message Concept > Selecting a Message Procedure.

Note

The bit message procedure and limit value monitoring can be used with a single-user system in WinCC. In redundant systems or WinCC systems with several operator stations, chronological signaling is used for coordinated acknowledgment and transmission. For chronological signaling, the SFCs/SFBs Alarm, Alarm_S/SQ, Alarm_D/DQ, Alarm_8/8P are used on the SIMATIC S7. Refer to the respective CPU manuals and the block descriptions in the SIMATIC STEP 7 help to learn about restrictions in regard to the system resources for simultaneously pending alarms. To use the chronological signaling function, the SIMATIC S7-400 in conjunction with the Alarm and Alarm 8/8P blocks is recommended.



WinCC Tag Logging Process values acquired and evaluated in WinCC Tag Logging are given the time stamp either with the time they are acquired in WinCC or with the value from the automation system.

To read in the process values cyclically, acquisition cycles are defined. The shortest acquisition cycle is 500 ms. A time stamp assigned when the process value is acquired includes the inaccuracy of the acquisition cycle.

Process values that receive their time stamp from the automation system are prepared in the form of a frame on the automation system and transferred as a raw data tag. The packet structure is described in the WinCC Information System in Working with WinCC > Archiving Process Values > Basics of Archiving Process Values > Process Values and Tags > Structure of a Frame with Raw Data Tags. The frames are evaluated in Tag Logging by format DLLs and entered in the archive. The date and time correspond to the time at which the process value was stored in the automation system.

The specification (URS, FS) of a GMP-compliant plant must describe the way in which time stamping will be performed. The accuracy necessary for message and process data acquisition must be checked in detail. The methods of time stamping mentioned above can be used alongside each other.



4.10 Archiving data: Setting up process value archives It is highly important to provide full quality verification, especially for production plants operating in the GMP environment. This includes archiving production-relevant data.

In SIMATIC WinCC, the Tag Logging editor is used to archive data. Tag Logging is part of the WinCC system software. The editor is opened in WinCC Explorer for configuration.

Configuration of the process value archive is broken down into the following steps:

• Creating a process value archive and selecting the tags to be stored in the short-term archive.

• Configuration of the process archive, specifying the archive size, segment change and storage location for transfer to backup.

Data (analog and binary values) relating to process tags is stored in a database via the process value archive. A process value archive is created as a short-term archive. The size is decided in the specification (URS, FS, DS).

Basic principle of operation The process values are taken from a sensor via the I/O modules and transferred to the automation system, from there, they are transferred to the tag management of SIMATIC WinCC over the communication connection. Tag Logging handles the archiving of the value with date and time in the configured process value archive. For long-term archiving, the archived values can be transferred to an archive server by the backup configuration (see section 352H4.11 “ 353HLong-term archiving”).

Special configuration features Setting up and configuring a process value archive is described in detail in the WinCC Information System.

The setting Signing off active is made in the archive configuration (Tag Logging Fast and Tag Logging Slow) for process value archives that archive data from a GMP environment When the data is transferred, a checksum is generated. This allows subsequent manipulation to be detected when a backup process archive database is reconnected to the WinCC system. If a manipulated database is reconnected, WinCC displays a message.



4.11 Long-term archiving In the archiving concept of WinCC, as distinction is made between online archiving (short-term) and offline archiving (long-term). Online archiving is handled by WinCC Alarm Logging and WinCC Tag Logging.

4.11.1 Long-term archiving in SIMATIC WinCC For long-term archiving in WinCC, it is advisable to use a separate server in the network. The long-term archive server stores the transferred database segments from WinCC Alarm Logging and WinCC Tag Logging as backup. The long-term archive server is a server without a connection to the process.

A minimum WinCC installation (fileserver setup) is installed on the server.

There are various ways of viewing the data:

• Copy swap files onto the configuration computer on which Runtime is run. In Alarm Logging or Tag Logging, the backup files are connected to the project so that the archived values can be displayed in runtime.

• Access via OLE-DB (the MS SQL Server must be installed)

• Access over Dat@Monitor (see section 354H4.17 "355HConnecting to a Web client")



Backup configuration in Alarm Logging

In the properties of the message archive, a folder is entered as the destination path in the Backup Configuration tab. This folder is the folder set up on the long-term server. To avoid problems if the long-term server fails, a second alternative destination path can be specified.

Selecting the Signing off activated check box adds a checksum to the backed up databases. When the backup databases are reconnected to Alarm Logging, the checksum indicates whether data has been manipulated.



Backup configuration in Tag Logging

The backup for the Tag Logging Fast and Tag Logging Slow archives is configured in Tag Logging. For more information, refer to Alarm Logging above.

Backup configuration WinCC Audit (audit trails) There is no configurable, cyclic backup function in the WinCC Audit option.

To backup the audit trail database, the Enterprise Manager of Microsoft SQL Server can be used. Enterprise Manager provides functions for exporting, importing, restoring, etc. Users with administrator privileges in the Windows operating system can use these functions. If Microsoft SQL Server was installed with password protection, the password must be known.

If the audit trail is stored on a network drive, it is first recorded on the local computer with the WinCC project and then transferred to the remote computer. If the connection between the remote and local computer fails, all incoming audit trail information is buffered until the connection is established again. The buffered audit trail information is then automatically transferred from the local to the remote computer. This avoids problems and loss of data if the network is disrupted.



4.11.2 Batch-oriented long-term archiving with PM-QUALITY PM-QUALITY offers several methods for archiving logged batch data.

• Exporting in database format

• Exporting in HTML format

• Exporting in XML format

Only completed batches can be archived. A batch has the status closed, when:

• The batch was completed manually or automatically.

• The batch is aborted, locked or reported as completed.

Automatic export of a batch is performed only once. Selecting the Automatic batch finalize check box in the Project Settings > Defaults dialog has the effect that changes to the batch data are no longer possible after the automatic export.



For export in HTML format or XML format, subsequent manipulation of the data can be prevented by assigning the appropriate rights to the drive (read-only).

PM-QUALITY checks if the completed batch is ready for export in the current acquisition cycle. The data must first be exported to a local hard disk. Transferring the batch data to an external drive, for example to the long-term archive server, can be configured with Following action.



The Export View tool is used to view batch data in the database format. The tool is contained in the PM-QUALITY package.

The batch is selected in a batch list dialog; viewing on screen is started with a button in the toolbar.

For more detailed information on the WinCC premium add-on PM-QUALITY, refer to the product's online help.

Note

It is advisable to use SIMATIC IT Historian and SIMATIC IT Report Manager for long-term archiving and logging in large plants. For more detailed information, refer to the “SIMATIC PCS 7 GMP Engineering manual: Guidelines for Implementing Automation Projects in a GMP Environment”.



4.12 Reporting

4.12.1 Basic logginreportingg with SIMATIC WinCC Report Designer The Report Designer is integrated in the WinCC software to allow documentation of the configuration data and the runtime data.

The following runtime data can be logged:

Message sequence report Chronological listing of all messages that have occurred

Message report Messages of the current message list

Archive report Messages from the message archive

Tag table Tag contents from process value / compressed archives in the form of a table

Tag trend / picture Tag contents from process value / compressed archives in the form of a trend

Note

WinCC Report Designer supports reporting of continuous processes.

Note

Linking the audit trail of WinCC Audit into the logging with the Report Designer is not supported by WinCC Version V 6.0 SP4.

The contents of user archives can also be documented in the form of a table.

The design and output of the runtime data can be defined in page layouts. Print jobs control the printout. The output range and options are also specified in the print job.

A series of system layouts and system print jobs for various documentation requirements are supplied with the product. These can be used to create new layouts or print jobs but they should not be modified. Changing the system layout means additional test effort from a GMP perspective. If the system software is upgraded, the system layouts are overwritten by the installation.



Note The WinCC Information System lists available layouts print jobs in Working with WinCC > Documentation of Configuration and Runtime Data > Appendix System Layouts and Print Jobs for Runtime Documentation.

Page layout editor The page layout editor of the Report Designer is used to modify system layouts to meet users' needs or to create new layouts. System layouts are opened in the page layout editor and saved under a new name so that they can be modified.

The layouts are divided into a static and a dynamic section. To design the layout, static and dynamic system objects are available in the form of an object palette. A title page, for example with the company logo and a back page can be created for each report.

Headers and footers are configured in the static section. A version number can, for example, be configured in the footer that is changed manually in a variable.

The runtime data for output are configured in the dynamic section. The required object is selected from the Object Palette > Runtime Documentation and dragged to the work area (dynamic section) of the report layout.

In the following example, the Archive Report object under Alarm Logging RT is linked into the report to show the audit trail entries (user input messages). The column appearance is configured in the properties.



As a filter, either the number of the operator input message is specified (the message number is fixed by the WinCC system) or by clicking Message Class > System, without acknowledgment and selecting the Operator input check box.



Print jobs WinCC Report Designer documents data from continuous processes over a defined time. The period is set along with all other settings in the print job. During process mode and before the log starts, it is also possible to open a parameter assignment dialog in which the output selections, timebase, and time range for the output of archive tags can be changed for the log being output.



Note For more detailed information on the WinCC Report Designer, refer to the WinCC Information System, section Working with WinCC > Documentation of Configuration and Runtime data.

The audit trail entries are shown in the log as follows:

Note The X in column C indicates that a comment exists. The comment itself cannot be output in the log.



4.12.2 Batch-oriented reporting with PM-QUALITY The WinCC Premium add-on PM-QUALITY is used for batch-oriented archiving and reporting. The archiving of the production-relevant data begins with the Batch start signal and ends with the Batch end signal. The data is assigned to a specific batch, which can be configured, and called back up again with the batch name.

The report layouts for printing the batch data can be customized in the Report Editor application.

Static objects for report designs and dynamic objects for displaying the batch data are listed in the highlighted area at the lower left.

The dynamic objects are configured for the specific plant beforehand in the Topology Manager application. The dynamic objects include batch header data, phase sections, snapshots, alarm events, audit trail entries, tag logging values, etc. A tabular horizontal or vertical display style can be selected. Tag logging values are shown in the form of trend curves. This involves defining trend templates in which the values and the form of the trend graphic are specified. You can also display comparable trends with values from different batches.



The procedure for including audit trail entries (operator input messages) in a batch log is shown below based on an example.

The PM-SERVER application that is included in the PM-QUALITY software package is the interface between the WinCC system software and PM-QUALITY. A station is configured for the WinCC server in PM-SERVER in which the data from the WinCC project are imported (tags, alarm blocks, permissions and archive data). PM-SERVER can not only record data from one but from several WinCC servers with different projects. Based on the imported alarm blocks, a message column structure is configured in which the messages arriving from the WinCC projects are passed on to PM-QUALITY.

The operator input messages are recorded in WinCC Alarm Logging as audit trail (see also section 356H4.8.2 "357HAudit trail via WinCC Alarm Logging"). To receive the operator input messages, an Alarms object and an Alarm group is created in the Topology Manager below the relevant production unit, in this case with the name Audit Trail.

The alarm blocks to be shown in the batch report are selected in the properties of the Audit Trail alarm group. The alarm number for the operator input message as defined in the WinCC system is also entered in the Alarm filter dialog.



The Audit Trail alarm group is displayed in the area for the existing objects in the Report Layout editor. The Audit Trail alarm group is dragged to the right to be included in a report layout.

An audit trail can appear as follows in a batch report:

Change comments can be logged in the audit trail.

Note

For more detailed information on the WinCC Premium add-on PM-QUALITY, refer to the product's online help.



4.12.3 Backup of the application software

Backing up application software in the engineering system Following changes, it is advisable to make a backup of the project data. The WinCC Project Duplicator is recommended for this task. The tool is opened with Start > Programs > SIMATIC > WinCC > Tools > Project Duplicator. The project data of the selected WinCC project can be copied to any computer in the network.

! Note The WinCC project must be closed before it is copied.

Backing up data of WinCC options / WinCC Premium add-ons If WinCC options or WinCC Premium add-ons such as PM-CONTROL / PM-QUALITY are used in the WinCC project, the corresponding databases must also be backed up. Before the data is backed up, a check must be made to make sure that the databases of the add-ons were disconnected from the MS SQL Server when the WinCC project was closed. If the databases were not disconnected automatically, an error message is displayed when the data is backed up. The databases can be disconnected either with the detachdb.exe application (in the Programs/Siemens/PMCOMMON) or with the MS SQL Enterprise Manager. During installation, WinCC options and WinCC Premium add-ons automatically store their data in a separate folder below the WinCC project. In this case, the data is also backed up by the Project Duplicator. If a user defined storage path was specified during installation, the data must be backed up separately.

Backing up data with Version Trail If the WinCC project is linked into a STEP 7 project within the framework of Totally Integrated Automation (TIA), the Version Trail software product can be used for data backup. Version Trail backs up the data of the STEP 7 project folder. An integrated WinCC project is stored in a folder below the STEP 7 project. Extra add-ons such as PM-QUALITY, on the other hand, are located in a folder below the WinCC project. Version Trail archives all project data with a major or minor version (see also section 358H4.5.2 "359HVersioning user software"). Prior to archiving the data, a check should be made to establish whether the databases were disconnected from the MS SQL Server (see also section "Backing up data of WinCC options / WinCC Premium add-ons"). A version archived with Version Trail can be retrieved again at any time.

More detailed information can be found in the "SIMATIC S7 GMP Engineering manual: "Guidelines for Implementing Automation Projects in the GMP Environment".



4.12.4 Backing up the operating system and SIMATIC WinCC The operating system and the WinCC installation should be backed up as hard disk images. Such images can be used to restore the original state of the PC with little effort.

The required images • Create an image of the operating system installation with all drivers and all

settings relating to the network, user administration, etc. without SIMATIC WinCC.

• Create an image of the installed PCs with SIMATIC WinCC, WinCC options and WinCC Premium add-ons.

• Create an image of the installed PCs with SIMATIC WinCC including all the projects.

How to create an image Several applications are available for creating an image, for example, SIMATIC PC/PG Image & Partition Creator. Note in this regard that the image is written to a free partition.

Note

The backups of the user software and the backup of the operating system with and without SIMATIC WinCC should be stored on external media (for example MOD, CD, DVD, network backup).

! Note

An image can only be restored on a PC with identical hardware. For this reason, the hardware configuration of the PC must be adequately documented.

Images of individual partitions cannot be exchanged between PCs because their settings, such as registry settings, differ.



4.13 Lifebeat Monitoring The Lifebeat Monitor monitors all servers, clients and to the automation systems obtainable over PC networks and industrial networks (Industrial Ethernet, PROFIBUS or OPC).

To configure the nodes to be monitored, the Lifebeat Monitoring editor is opened in WinCC Explorer. Here, all the nodes to be monitored and the monitoring cycle in which the lifebeat monitoring takes place can be set up.

Note

Lifebeat monitoring for third-party systems must be configured manually. Its use depends on the communication partner of the third-party system. If the third-party system represents an important interface to SIMATIC WinCC, Lifebeat Monitoring is absolutely necessary. For additional information, refer to the WinCC Information System > Options > Options for Process Control > Lifebeat Monitoring.



4.14 Data communication with the plant management level Date communication with the plant management level or other systems must be covered by system functionalities. Here, there are several options open, including the integrated OPC connection (OPC Data Access), the connections of OPC A&E and OPC Historical Data Access, or the WinCC OLE DB connection.

4.14.1 Data communication with the connectivity pack The connectivity pack of SIMATIC WinCC allows standardized access from the plant management level to the process control system. The following mechanisms are used for this purpose:

• OPC Historical Data Access (access to the process value archive) OPC HDA. All or selected process value archives can be read. The process value archives can be read cyclically or user-controlled on certain events or at certain times. It is not possible to write to the process value archives.

• OPC Alarms and Events (access to the message archive) OPC A&E. All or only selected messages can be read. The message archive can be read cyclically or user-controlled on certain events or at certain times. Apart from acknowledgments, it is not possible to write to the message archive.

• WinCC OLE DB allows read access to Tag Logging and Alarm Logging archive databases.

Data communication is illustrated in the diagram below:



Process values and control states are recorded online. Depending on the stipulations in the specifications, the online process values and messages (alarms, warnings, system messages, operator input messages etc.) are stored in the Tag Logging and Alarm Logging short-term archive for a defined short-term archive time and are available to the plant management level for reading.

Configuring the connectivity pack It is not necessary to configure the connectivity pack in SIMATIC WinCC.

4.14.2 Data communication with Industrial Data Bridge The Industrial Data Bridge application is used to copy data between different applications, for example WinCC and an Oracle database. While data is being copied, user access to data is not possible.



4.14.3 Data communication with ODK The Open Development Kit (ODK) option describes the exposed programming interfaces that can be used to access data and functions of the WinCC configuration and WinCC runtime system. The interfaces are designed as C-Application Programming Interface (C-API).

Note

Due to the extreme amount or work involved, the ODK interface should only be used when there is no other way to implement certain functionalities.



4.15 Uninterruptible power supply An uninterruptible power supply (UPS) is a system for buffering the line voltage. If the power supply from the line fails, the battery of the UPS takes over the power supply. When the power supply from the line resumes, the power supply from the UPS battery ceases and the battery begins to recharge. Some UPS systems offer monitoring of the line voltage in addition to buffering the power supply from the line. This guarantees output voltage at all times without interference voltage.

UPS systems are necessary so that process and audit trail data can continue to be recorded during power failures. The system operator needs to be consulted in regard to the design of the UPS, which should be specified in the URS, FS, or DS. The following points must be considered in this regard:

• Power consumption of the system to be supplied

• Capacity of the UPS

• Desired duration of the UPS buffering

The power consumption of the system to be buffered determines the size of the UPS. Another criterion for the selection is the priority of the systems. Systems with high priority are:

• Automation system (AS)

• Archive server

• WinCC server

• WinCC clients

Field devices, which usually have relatively high power consumption, can be included in the buffering, depending on the performance capacity of the UPS. This should be based on the process category and selected in consultation with the system operator.

In any case, it is important to include the systems for reporting the data in the buffering. The time of the power failure should also be included in the reporting.

The use of UPS systems is a factor in the software installation. It needs to be installed and configured on the PC-based computer of the visualization system.

• Configuration of the alarming for power failure

• Specification of the time period for shutting down the PC

• Specification of the duration of the UPS buffering

The automation systems (PLC) should be programmed in a way that allows the process control system to be brought to a safe state with a specified buffer time in the event of power failure.

Due to varying requirements of individual devices, three classes have been established for the UPS context. These have been specified by the International Engineering Consortium (IEC) under the product standard IEC 62040-3 by the European Union under EN 50091-3:



Standby or offline UPS

The simplest and least expensive UPS systems (according to IEC 62040-3.2.20 of UPS class 3) are standby or offline UPS systems. They only protect against power failure and transient voltage fluctuations and peaks. They do not compensate for undervoltage or overvoltage. Offline UPS systems automatically switch to battery mode when undervoltage or overvoltage occurs.

Network-interactive UPS

Network-interactive UPS systems (according to IEC 62040-3.2.18 of class 2) operate similar to standby UPS systems. They protect against power failure and transient voltage peaks, and can continually compensate for voltage fluctuations using filters.

Online UPS

Double conversion or online UPS systems (according to IEC 62040-3.2.16 of Class 1) are considered real power generators that continuously generate their own line voltage. This means connected consumers are continuously supplied with line voltage without restrictions. The battery is charged at the same time.



4.15.1 Configuration of uninterruptible power supplies The configuration of uninterruptible power supplies (UPS) differs from case to case and must be described in the URS, DS or FS.

The two screenshots below are examples of the configuration of a UPS in Windows 2000/2003/XP.



The following table describes an example of configuring and uninterruptible power supply for an operator station in a process control system. The situation with automation systems (AS) is analogous.

Cas

e Action Reaction

1 Power failure < 10 seconds

The WinCC computers are buffered by the UPS. An alarm using a digital input in WinCC documents the power failure.

2 Power failure > 20 minutes Power returns after 25 minutes

The WinCC computers are buffered by the UPS, for example for 20 minutes. An alarm in the PCS documents the power outage and the shutdown of the WinCC computers after 20 minutes. The UPS stops supplying power after a defined time (for example 25 minutes) so that an independent restart of the WinCC computers is possible of and return of the power.

3 Power failure > 1 hour

The WinCC computers are buffered by the UPS, for example for 20 minutes. An alarm in the PCS documents the power outage and the shutdown of the WinCC computers after 20 minutes. The UPS stops supplying power after a defined time so that an independent restart of the WinCC computers is possible when power returns.

4.15.2 UPS configuration over digital inputs In addition to the standard buffering provided by UPS devices, the option of monitoring the power supplies should be used. In this strategy, the phase is monitored over one or more digital inputs. The advantage of this is that power outages can be registered, signaled and archived.



UPS 24 V buffering (load voltage) The automation system CPU is supplied with power by the UPS 24 V module both during voltage fluctuations and during longer power outages. The phase monitoring module monitors the status change during a power failure using a digital input that should be designed as a failsafe input signal. If there is a power outage, and a long can be generated to inform the operator of the power outage (alarm message). By logging the outage in the message system, the power failure can be researched later. Safety states can also be implemented based on power outage concepts that take effect immediately or after a certain time has elapsed (for example hold equipment phases, establish a safe plant status even after the return of the power etc.).



UPS 110 V / 220 V buffering (line voltage) In addition to the phase monitoring, the WinCC server is buffered by standard 110 V/220 V UPS modules. This ensures that the server remains in operation even after a power outage.

The operator is informed of the power outage by the UPS buffering, for example with alarm messages. Safe states can be initiated by the operator or by automated concepts.

The safe shutdown of the WinCC server can be signaled by WinCC alarm messages and put into effect if the power does not return within a specified time. This functionality increases the availability of the system on the return of the power.

Note

FAQ No. 17241008 includes important information on the quality of the output voltage (http://support.automation.siemens.com/WW/view/de/17241008) and should be read.



4.16 Creating C and VB scripts C und VB source files are programs written by the user that count as class 5 in the software categorization. This type of software is developed to meet customer-specific requirements that cannot be covered by the standard library.

With category 5 software, the constraints governing the creation of software according to ISO 9001 2000 should be adhered to.

If category 5 software is used, the development and implementation must comply with the stipulations of GAMP ® 4.

The procedure for creation of Category 5 software is as follows:

1. Creation of a functional description for the software

2. Specification of the employed function blocks

3. Specification of the employed inputs and outputs

4. Specification of the block for operator control and monitoring

! Warning The creation of category 5 software should be avoided because it significantly increases the work involved for testing and validation.



4.17 Connecting to a Web client To display and evaluate the archived data either from WinCC or from the long-term archive server, the application Dat@View of the WinCC option Dat@Monitor is used. Dat@View allows only read access to archived data.

Using the Internet Explorer, the archive data can be displayed on any computer in the network. To set up the functionality, the Dat@Monitor Server is installed on the WinCC server and licensed. To view the data on other computers, the Dat@View tool of the Dat@Monitor Client is installed. No extra license is necessary for these computers because the license is integrated in the server license.

Details of the procedure for installation, required user permissions, adaptation of the security policies in the network etc. are described in the online help Dat@Monitor Information System in the functional overview of WinCC. The section "Important Information" should also be read.

The Archive Connector tool is used to connect or disconnect the archived databases and the MS SQL Server. The databases are grouped under a symbolic name.



The data is displayed using Internet Explorer.



The data is selected for display from the relevant menu.

To display the data in Dat@View, a symbolic name with the relevant archives is selected in the Attach / Detach archive databases menu. The symbolic name was assigned in the Archive Connector.

Other display and evaluation options can be set:



Display of a trend view with Dat@Monitor:



4.18 Connecting SIMATIC WinCC flexible A connection between SIMATIC WinCC and SIMATIC WinCC flexible can be established over the OPC DA channel. The contents of tags can be exchanged over this connection.

Tag archives, message archives and audit trail are generated in the WinCC flexible as short-term archives in CSV format. These CSV files can be evaluated with the PM-OPEN IMPORT application and the contents can be entered in WinCC archives. Data from many tag archives are entered in WinCC Tag Logging archives and the content of the message archives is entered in WinCC Alarm Logging. The operator input messages and system messages in the entries of the audit trail are evaluated and entered as operator input messages with the message number of the WinCC standard operator input message, once again in WinCC Alarm Logging. To import the various CSV files, import jobs are defined in PM-OPEN IMPORT that are processed in a selectable cycle.

The audit trail CSV file of WinCC flexible can also be visualized using the Audit Viewer of WinCC Audit.

Further Information • Information on configuration of PM-OPEN IMPORT can be found in the online

help of the WinCC Premium add-ons.

• Information on the use of SIMATIC WinCC flexible in a GMP environment, can be found in the manual "SIMATIC WinCC flexible GMP Engineering: Guidelines for Implementing Automation Projects in a GMP Environment".



4.19 Connecting SIMATIC S7

Connection via defined channels To exchange data between WinCC and the automation systems, the first thing that is required is a physical connection. Any communication connection is configured in SIMATIC WinCC suitable for the hardware being used. The WinCC system software includes a series of communication drivers for this purpose.

The S7-300 and SIMATIC S7-400 automation systems, for example, are linked using the communication driver (communication channel) "WinCC SIMATIC S7 Protocol Suite". Depending on the communication hardware in use, various channel units are available for the channel. The channel unit serves as an interface with exactly one underlying hardware driver and therefore to exactly one communication processor in the PC. A detailed list of the existing channel units can be found in the WinCC Information System in the section Communication > SIMATIC S7 Protocol Suite.

A connection is configured for the selected channel unit in the tag management by creating the tags with a name and data type. These tags are also known as external tags.

The tag management forms the data interface between the automation system and WinCC system. All the editors integrated in WinCC read / write data to the tag management.

And introduction on the communication connection is indicated in the WinCC Alarm Logging if system messages are enabled.

Evaluating the tag status and quality status To allow monitoring, a status value and a quality code are generated for each tag. Among other things, the tag status indicates configured limit value violations and the link status between WinCC and the automation level. The quality code is a statement about the quality of the value transfer and value processing.

The evaluation of the tag status or the quality code can be configured, for example in the dynamic values dialog in the properties of a graphic object.



The evaluation of the tag status in this example is shown by a color. If the described state because, the color changes according to the configuration. The quality code is configured in much the same way.

The checking of the quality code and tag status can also be performed in VB / C scripts and linked to a user-defined action.

Note

For more detailed information on using SIMATIC S7 in a GMP environment, refer to the "SIMATIC S7 GMP Engineering manual: Guidelines for Implementing Automation Projects in a GMP Environment".



4.20 Connecting third-party components

Connection via defined channels As the communication connection between WinCC and third-party automation devices, we recommend that the OPC channel is used. The communication driver for OPC (OLE for Process Control) is certified by the OPC Foundation. The driver is included in the WinCC system software.

It is possible to link the OPC client with third-party control systems over an OPC server.

In tag management (data manager), a communication connection is configured for the OPC channel in which tags with name and type can be created. These tags form the interface between the automation system and WinCC. The WinCC system software uses the contents of the data manager for the configured functionalities.

WinCC also operates as an OPC DA server and transfers process data to other OPC clients.


5 Supporting functions during qualification

5.1 Introduction The following graphic shows the life-cycle model. Qualification, which is the focus of this section, is assigned to the area of Test / Qualification in the graphic.

The aim of the qualification is to provide documented proof that the system was set up according to the specifications and that all specified requirements have been met. Qualification describes, executes and finally evaluates all the activities necessary for this. Various standard functionalities of SIMATIC WinCC can be used as support in qualification during IQ and OQ.

Supporting functions during qualification


5.2 Qualification of the visualization hardware The design specification of the installed hardware is used to set up the system according to detailed specifications and adherence to these specifications is verified during the subsequent system tests. The design specification describes all hardware used with information such as order number, firmware/version, installation location, serial number etc. The components of the servers and clients, interfaces to the automation systems etc. are also listed.

Specification of the employed PC hardware In the qualification of the PVC hardware used, checks are necessary to ensure that the requirements of the hardware design specification were implemented. The so-called PC passport is useful for the qualification. All the installed hardware and software components should be listed in the PC passport.

These include:

• Order number of the employed PC hardware

• Additionally installed hardware components (additional network adapters, printers, etc.)

• Check for the configured network addresses, monitor resolution, etc.

• Note

The PC passport is normally created manually. Some PC manufacturers provide a utility for automatic detection of the hardware information. The PC passport can be printed and used to verify the qualification (IQ/OQ) of the installed PC hardware. Visual inspection can be carried out at the same time.



5.3 Qualification of the visualization software

5.3.1 Qualification of standard software In the qualification of the standard software used, checks are necessary to ensure that the requirements of the software design specification were implemented. These include:

• Operating system

• SIMATIC WinCC system software

• SIMATIC standard add-ons (Audit, SIMATIC Logon, Dat@Monitor, UserArchive, etc.)

• SIMATIC WinCC Premium add-ons (PM-CONTROL, PM-QUALITY)

• Standard libraries

Note (operating system)

The installed software can be verified by operating system functions. The information can be found in Control Panel > Add / Remove Programs). All installed software components are displayed here. A screenshot can be printed and used for the qualification (IQ/OQ).

5.3.2 System programs of SIMATIC WinCC In an environment in which GMP is mandatory, documentation listing the installed software packages (operating system, SIMATIC products, and other applications) with version and license should be created. Detailed documentation of the installed SIMATIC software can be found under Programs > SIMATIC > Product notes > Installed software.

Note

The installed components can be printed and used for the qualification (IQ/OQ).



5.3.3 Installed licenses of SIMATIC WinCC The Automation License Manager program provides information on the installed licenses on the WinCC computer. To view this information, open the Automation License Manager and select the partition of the PC on which the licenses are installed on the left in the Explorer bar. The available SIMATIC licenses of the system are now shown on the right.

Note

The installed licenses must correspond to the requirements defined in the specification. The installed licenses can be printed and used for the qualification (IQ/OQ).



5.3.4 Qualification of the application software In the qualification of the application software, checks are necessary to ensure that the requirements of the software design specification were implemented. The test descriptions (e.g. for FAT/SAT) must be agreed upon and generated in consultation with the operator. These test descriptions must be created individually to meet the software design specifications.

As a minimum, the following must be checked and tested and can be used as a reference for the qualification:

• Check of the name of the application software

• Check of the technological hierarchy (plant, plant section, technical equipment, individual control element etc.)

• Software module test (typical test)

• Check of the communication to other nodes (third-party controllers, MES systems etc.)

• Check of all inputs and outputs

• Check of all control modules (individual control level)

• Check of all equipment phases and equipment operations (technical functions)

• Check of the relationships between modes (MANUAL/AUTOMATIC switchovers, interlocks, start, running, stopped, aborting, completed etc.)

• Check of the process tag names

• Check of the visualization structure (P&I representation)

• Check of the operating philosophy (access control, group rights, user rights)

• Check of the archiving concepts (short-term archives, long-term archives)

• Check of the message concept

• Check of the trends

• Check of the time synchronization

Guidelines for Implementing automation projects in a GMP environment A5E01100604-01 Index-1

Index

2 21 CFR Part 11 .............................................. 1-7

A Access protection.................................. 2-8, 4-34 Access protection – setting up ..................... 4-34 Access protection under Windows

and in WinCC process mode ................... 4-35 Alarm logging................................................. 3-6 Archiving ...................................................... 2-14 Audit trail ......................................2-12, 3-7, 4-57

B Backup......................................................... 2-17 Backup - operating system .......................... 4-89 Backup process data ................................... 2-19 Backup user software .................................. 2-17 Batch documentation ................................... 2-15 Batch reporting............................................. 2-15 Batch-oriented reporting .............................. 3-14 Biometric systems.......................................... 2-9

C Change control........................................ 2-6, 3-9 Changing application software..................... 4-33 Changing system software........................... 4-24 Concepts for time synchronization ............... 4-67 Configuration control...................................... 2-5 Configuration identification............................. 2-5 Configuration management................... 2-5, 4-24 ConfigurationTool........................................... 3-5 Connectivity pack......................................... 3-15 Creating scripts - C, VB ............................. 4-101

D Data communication with Industrial

DataBridge ............................................... 4-92 Data communication with ODK .................... 4-93 Data communication with the

connectivity pack...................................... 4-91 Data communication with the

plant management level ........................... 4-91

Diagnostics.....................................................4-9 Disabling the Windows level.........................4-48

E Electronic signature..................... 2-10, 3-4, 4-51 Electronic signature - changing values.........4-23 Engineering software......................................3-5 EU GMP Guideline ..................................1-7, 1-8

F FAT.................................................................1-5 FDA ................................................................1-7 Functional specification .........................1-4, 3-18

G GAMP......................................................1-7, 1-8 GMP requirements .........................................2-1

H Hardware categorization.................................2-2

I Implementation...............................................1-5 Interfaces to process data ............................3-15

L Life cycle model..............................................1-2 Lifebeat Monitoring.......................................4-90 Long-term archiving.............................3-13, 4-74 Long-term archiving – PM-QUALITY............4-77 Long-term archiving - WinCC .......................4-74

M Management execution systems (MES).......3-15 Manufacturing log.........................................2-15

N NAMUR ...................................................1-7, 1-8

Index

Guidelines for Implementing automation projects in a GMP environment Index-2 A5E01100604-01

O Operating system installation......................... 4-3 Operator input message .............................. 4-21

P Password .............................................. 2-9, 2-11 Permission management - WinCC User

Administrator............................................ 4-47 PM-CONTROL............................................. 3-10 PM-QUALITY............................................... 3-14 Print drivers.................................................... 4-4 Process value archives - setup .................... 4-73 Project library ............................................... 4-18

Q Qualification ............................................ 1-5, 5-1 Qualification - hardware ................................. 5-2 Qualification - software .................................. 5-3 Qualification plan ........................................... 1-4 Qualification report......................................... 1-6 Quality and project plan ........................ 1-3, 1-10

R Report Designer............................................. 3-7 Reporting ..................................................... 4-80 Reporting with PM-QUALITY ....................... 4-85 Reporting with Report Designer ................... 4-80 Retrieving archived data .............................. 2-20

S S7 - connecting .......................................... 4-108 SAT................................................................ 1-5 Security setting - Windows audit trail .......... 4-41 Security setting - account............................. 4-40 Security setting - password.......................... 4-39 Selection criteria for hardware ....................... 3-3 SIMATIC IT .................................................. 3-15 SIMATIC Logon ............................................. 3-4 SIMATIC Logon – connecting

SIMATIC WinCC ...................................... 4-46 SIMATIC Logon configuration...................... 4-42 SIMATIC NET ................................................ 4-5 Smart card ..................................................... 2-9 Software - Runtime ........................................ 3-5 Software categorization ........................ 1-10, 2-3 Software categorization of

SIMATIC WinCC ........................................ 4-2 Software installation....................................... 4-3 Software packages - additional ...................... 3-7

Software update ...........................................4-25 Software-packages.........................................3-4 Specification ............................................1-4, 3-1 Specification - design specification.................1-5 Startup characteristics ....................................4-6 Symbol library...............................................4-18 System information channel .........................4-10

T Tag logging.....................................................3-6 Tag management ...........................................3-5 Third-party component .................................2-21 Time stamping..............................................4-71 Time synchronization...........................2-13, 4-67 Time synchronization - configuring...............4-68 Typicals ..........................................................2-7

U Uninterruptible power supply - configuration 4-95 Uninterruptible power supply (UPS) .............4-94 Updates, service packs and hotfixes ............4-24 Upgrades (migration)....................................4-25 User administrator ..........................................3-4 User archive .................................................3-12 User ID .......................................... 2-8, 2-9, 2-11 User management ..........................................2-8 User management in Windows.....................4-36 User requirements specification ............1-4, 3-17

V Validation plan................................................1-3 Validation report .............................................1-6 Version control ...............................................2-6 Version Trail .................................................3-10 Versioning ....................................................3-10 Versioning - pictures.....................................4-27 Versioning projects.......................................4-31 Versioning reports ........................................4-31 Versioning VB / C scripts..............................4-28 Virus scanners................................................4-4

W Web client – connecting .............................4-102 WinCC Audit............................................3-7, 3-9 WinCC Dat@Monitor ....................................3-15 WinCC flexible - connecting .......................4-107 WinCC long-term archive server ..................3-13 Windows domains ........................................4-36 Windows workgroup .....................................4-37

GMP-Engineering Manual 3 - Siemens Global · PDF fileoptions WinCC long-term server, SIMATIC...

Documents

Transcript of GMP-Engineering Manual 3 - Siemens Global · PDF fileoptions WinCC long-term server, SIMATIC...