GMP Engineering Manual - English · Guidelines for Implementing Automation Projects in a GMP Environment A5E02147610-01 3 Introduction Purpose of this manual This manual describes

A5E02147610D-01 GN: 63003_SXXN2139_WinCCflex

GMP Engineering Manual Edition 04/2008

SIMATIC WinCC flexible 2007Guidelines for Implementing

Automation Projectsin a GMP Environment

SIM

ATI

C W

inC

C fl

ex

ible

20

07

04

/20

08

GM

P En

gin

eeri

ng

Man

ual

Siemens AktiengesellschaftAutomation and DrivesCompetence Center Pharmaceuticals76181 KARLSRUHEGERMANY [email protected]/simatic-wincc-flexible

simatic hmi

A5E02147610-01

s

Introduction, Table of Contents Configuring in a GMP Environment 1 Requirements of Computer Systems in a GMP Environment

2 System Specification 3 System Installation 4 Project settings 5 Creating Application Software 6 Support During Qualification 7 Operation, Maintenance and Servicing 8 System Updates and Migration 9 Index

SIMATIC WinCC flexible 2007

GMP Engineering Manual

Guidelines for Implementing Automation Projects in a GMP Environment

04/2008 A5E02147610-01

Siemens AG Industry Automation Postfach 4848 90026 NÜRNBERG GERMANY

A5E02147610-01 04/2008

Copyright © Siemens AG 2008 Technical data subject to change

Safety Guidelines This manual contains notices you have to observe in order to ensure your personal safety, as well as to prevent damage to property. The notices referring to your personal safety are highlighted in the manual by a safety alert symbol, notices referring to property damage only have no safety alert symbol. The notices shown below are graded according to the degree of danger.

! Danger indicates that death or severe personal injury will result if proper precautions are not taken.

! Warning indicates that death or severe personal injury may result if proper precautions are not taken.

! Caution with a safety alert symbol indicates that minor personal injury can result if proper precautions are not taken.

Caution

without a safety alert symbol indicates that property damage can result if proper precautions are not taken.

Notice

indicates that an unintended result or situation can occur if the corresponding notice is not taken into account.

If more than one degree of danger is present, the warning notice representing the highest degree of danger will be used. A notice warning of injury to persons with a safety alert symbol may also include a warning relating to property damage.

Qualified Personnel The device/system may only be set up and used in conjunction with this documentation. Commissioning and operation of a device/system may only be performed by qualified personnel. Within the context of the safety notices in this documentation qualified persons are defined as persons who are authorized to commission, ground and label devices, systems and circuits in accordance with established safety practices and standards.

Prescribed Usage Note the following:

! Warning This device and its components may only be used for the applications described in the catalog or the technical description, and only in connection with devices or components from other manufacturers which have been approved or recommended by Siemens. Correct, reliable operation of the product requires proper transport, storage, positioning and assembly as well as careful operation and maintenance.

Trademarks All names identified by ® are registered trademarks of the Siemens AG. The remaining trademarks in this publication may be trademarks whose use by third parties for their own purposes could violate the rights of the owner.

Disclaimer of Liability We have reviewed the contents of this publication to ensure consistency with the hardware and software described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the information in this publication is reviewed regularly and any necessary corrections are included in subsequent editions.

Guidelines for Implementing Automation Projects in a GMP Environment A5E02147610-01 3

Introduction

Purpose of this manual This manual describes what is required from the pharmaceutical, regulatory viewpoint for Good Manufacturing Practice (GMP environment), of the computer system, the software and the procedure for configuring SIMATIC WinCC flexible. Practical examples are used to explain the relationship between requirements and implementation.

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

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

Disclaimer of liability

This manual is a guideline for system users and engineers for integrating SIMATIC WinCC flexible HMI systems in the GMP environment as it relates to validation while taking 21 CFR Part 11 into account.

We have checked that the contents of this document correspond to the hardware and software described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. 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 A&D Competence Center Pharma in Karlsruhe (Germany).

Introduction

Guidelines for Implementing Automation Projects in a GMP Environment 4 A5E02147610-01

Scope of this manual The information in this manual applies to SIMATIC WinCC flexible 2007. The examined components are SIMATIC WinCC flexible (ES/RT) in combination with the options ChangeControl, Audit, Recipe, Archives, and the WinCC add-ons PM-QUALITY, PM-Control and PM-OPEN IMPORT. Refer to the CD-ROM catalog CA01 for detailed information on the compatibility of the individual components. The CD-ROM catalog is available online at: www.siemens.com/automation/ca01. You can obtain information about using the WinCC add-ons through the Hotline of the WinCC Competence Center Mannheim, phone: + 49 621 456 3269.

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

You will find the electronic manuals for SIMATIC WinCC flexible 2007 on CD-ROM as the "SIMATIC HMI Document Collection".

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

The document explains the laws and guidelines, recommendations and mandatory specifications that represent the basis for configuration of computer 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 based on examples. More detailed explanations are available in the standard documentation.

The appendix to this documentation contains an index.

Conventions The following conventions are used in this manual.

Procedures that include numerous tasks are presented in tables and numbered in the order they should be carried out.

Operating instructions involving only a few steps are indicated by a bullet point (•).

References to other manuals are shown in bold italic.

http://www.siemens.com/automation/ca01�

Introduction


Additional support Please contact your local Siemens representative if you have any queries about the products described in this manual.

You will find information on who to contact at:

http://www.siemens.com/automation/partner

A signpost to the documentation of the various SIMATIC products and systems is available at:

http://www.siemens.de/simatic-tech-doku-portal

You will find the online catalog and order system at:

http://mall.automation.siemens.com/

If you have questions on the manual, please contact the Competence Center Pharma:

• E-mail: [email protected]

• Fax: + 49 721 595 6930

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

http://www.siemens.com/pharma

Training Center We offer courses to help get you started with the SIMATIC WinCC flexible HMI system. Please contact your regional training center or the central training center in 90327 Nuremberg, Germany.

• Phone: + 49 911 895 3200.

• Internet: http://www.sitrain.com

http://www.siemens.com/automation/partner�

http://www.siemens.de/simatic-tech-doku-portal�

http://mall.automation.siemens.com/�

mailto:[email protected]�

http://www.siemens.com/pharma�

http://www.sitrain.com/�

Introduction


Technical Support You can reach the Technical Support for all Industry Automation products

• Via the Web formula for the Support Request http://www.siemens.com/automation/support-request

• Phone: + 49 180 5050 222

• Fax: + 49 180 5050 223

Additional information about our Technical Support can be found on the Internet pages http://www.siemens.com/automation/service

Service & Support on the Internet In addition to our documentation, we offer our Know-how online on the internet at: http://www.siemens.com/automation/service&support

Where you will find the following:

• The newsletter, which constantly provides you with up-to-date information on your products.

• The right documents via our Search function in Product Support.

• A forum, where users and experts from all over the world exchange their experiences.

• Your local representative for Industry Automation.

• Information on field service, repairs and Consulting.

http://www.siemens.com/automation/support-request�

http://www.siemens.com/automation/service�

http://www.siemens.com/automation/service&support�


Table of Contents

Introduction 3 Table of Contents 7 1 Configuring in a GMP Environment 11

1.1 Life Cycle Model ................................................................................................ 11 1.2 Regulations, Guidelines and Recommendations .............................................. 16 1.3 Responsibilities.................................................................................................. 18 1.4 Approval and Change Procedure ...................................................................... 18

2 Requirements of Computer Systems in a GMP Environment 19 2.1 Hardware Categorization................................................................................... 19 2.2 Software Categorization .................................................................................... 20 2.3 Configuration Management ............................................................................... 20 2.3.1 Configuration Identification ................................................................................ 21 2.3.2 Configuration Control......................................................................................... 21 2.4 Software Creation .............................................................................................. 22 2.4.1 Using typicals for programming ......................................................................... 22 2.4.2 Identifying software modules/typicals ................................................................ 22 2.4.3 Changing software modules/typicals ................................................................. 22 2.5 Access Protection and User Administration ...................................................... 23 2.5.1 Applying access protection to a system ............................................................ 23 2.5.2 Requirements of user IDs and passwords......................................................... 24 2.5.3 Smart cards and biometric systems .................................................................. 24 2.6 Electronic Signatures......................................................................................... 25 2.6.1 Conventional electronic signatures.................................................................... 25 2.6.2 Electronic signatures based on biometrics ........................................................ 26 2.6.3 Security measures for user IDs / password....................................................... 26 2.7 Audit Trail........................................................................................................... 27 2.8 Time Synchronization ........................................................................................ 27 2.9 Archiving Data ................................................................................................... 28 2.10 Reporting Batch Data ........................................................................................ 29 2.10.1 Components of batch documentation................................................................ 29 2.10.2 Components of the manufacturing log............................................................... 29 2.10.3 The uses of electronic batch data...................................................................... 30 2.10.4 Requirements of electronic records................................................................... 30 2.11 Data Backup ...................................................................................................... 31 2.11.1 Backup of application software.......................................................................... 31 2.11.2 Backup of process data ..................................................................................... 33 2.12 Retrieving Archived Data................................................................................... 33 2.13 Use of Third-Party Components ........................................................................ 34

Table of Contents


3 System Specification 35 3.1 Specification of Visualization Hardware ............................................................ 36 3.1.1 Selecting hardware components ....................................................................... 36 3.1.2 Hardware specification ...................................................................................... 37 3.2 System and Network Security ........................................................................... 38 3.3 Specification of Basic Software ......................................................................... 38 3.3.1 Access protection and user administration........................................................ 38 3.3.2 Engineering........................................................................................................ 39 3.3.3 Runtime software............................................................................................... 39 3.3.4 Interfacing to higher-level IT systems................................................................ 40 3.4 SIMATIC Additional Software ............................................................................ 41 3.4.1 WinCC Premium add-ons.................................................................................. 41 3.5 Application Software Specifications................................................................... 41 3.6 Utilities and Drivers............................................................................................ 42 3.6.1 Printers / printer drivers ..................................................................................... 42 3.6.2 Antivirus tools .................................................................................................... 42 3.6.3 Image & Partition Creator .................................................................................. 42

4 System Installation 43 4.1 Installing the Operating System......................................................................... 43 4.2 Installing the System Software .......................................................................... 43 4.2.1 Installing SIMATIC WinCC flexible .................................................................... 43 4.2.2 Installing the SIMATIC WinCC flexible options ................................................. 44 4.2.3 Installing utilities and drivers.............................................................................. 44 4.3 Setting up User Administration .......................................................................... 45 4.3.1 Local User Administration.................................................................................. 45 4.3.2 Centralized user administration ......................................................................... 45 4.3.3 Setting up user groups in WinCC flexible .......................................................... 46 4.3.4 Setting up users in WinCC flexible .................................................................... 47 4.3.5 Security settings with local user administration................................................. 49 4.3.6 Security settings with centralized user administration....................................... 51 4.4 Access Protection with SIMATIC Logon............................................................ 52 4.4.1 User management in Windows.......................................................................... 52 4.4.2 Security settings in Windows............................................................................. 54 4.4.3 Configuration of SIMATIC Logon....................................................................... 56

5 Project settings 59 5.1 Project Manager ................................................................................................ 59 5.2 Multilingual Projects........................................................................................... 60 5.3 SIMATIC NET Settings ...................................................................................... 60 5.4 Time Synchronization ........................................................................................ 61 5.4.1 Set time.............................................................................................................. 61 5.4.2 Transferring the CPU system time to the HMI device ....................................... 62 5.4.3 Transferring the HMI device system time to the CPU ....................................... 64 5.4.4 Synchronization of the SIMATIC Logon server ................................................. 65 5.5 Support for Configuration Management ............................................................ 66 5.5.1 Defining configuration elements ........................................................................ 66 5.5.2 Versioning of configuration elements ................................................................ 67 5.5.3 Versioning the application software................................................................... 67

Table of Contents


6 Creating Application Software 71 6.1 Creating Process Screens................................................................................. 72 6.2 Setting Access Protection for an Object ............................................................ 75 6.3 Creating VB Scripts ........................................................................................... 76 6.4 Setting up the Audit Trail ................................................................................... 77 6.4.1 Generating audit trail entries ............................................................................. 79 6.4.2 Display of the audit trail ..................................................................................... 81 6.5 Electronic Signature........................................................................................... 82 6.6 Recipe Management with the Recipe Option .................................................... 83 6.7 Recording and Archiving Data Electronically..................................................... 86 6.7.1 Setting up data and alarm logs.......................................................................... 86 6.7.2 Archiving data logs, alarm logs and audit trails ................................................. 88 6.7.3 Restricting access to the network drive ............................................................. 90 6.7.4 Batch-oriented data recording ........................................................................... 93 6.8 Reporting ........................................................................................................... 96 6.8.1 Standard reporting ............................................................................................. 96 6.8.2 Batch-based reporting ....................................................................................... 99 6.9 Backups of System / Application Software...................................................... 104 6.9.1 Backing up application software from the engineering system ....................... 104 6.9.2 Backing up the operating system and SIMATIC WinCC flexible..................... 105 6.9.3 Backing up the operating system and the application software

of an HMI device (panel).................................................................................. 106 6.10 Interfacing to SIMATIC WinCC........................................................................ 107 6.10.1 Centralized user administration ....................................................................... 107 6.10.2 Central audit trail for multiple WinCC flexible systems.................................... 107 6.10.3 Central process value archiving and central alarm management ................... 108 6.10.4 Central recipe control and recipe management .............................................. 109 6.11 Interfacing SIMATIC S7................................................................................... 111 6.12 WinCC flexible Integrated in STEP 7............................................................... 112 6.13 Uninterruptible Power Supply .......................................................................... 117

7 Support During Qualification 121 7.1 Qualification Planning...................................................................................... 122 7.2 Qualification of the Visualization Hardware..................................................... 123 7.3 Qualification of the Visualization Software ...................................................... 125 7.3.1 Software categorization according to the GAMP guide................................... 125 7.3.2 Qualification of standard software ................................................................... 125 7.3.3 Qualification of the Application Software......................................................... 129 7.4 Checking the Configuration: Versioning and Archiving Projects ..................... 131 7.5 Tracking Configuration Changes ..................................................................... 133

8 Operation, Maintenance and Servicing 135 8.1 Diagnostics of Communication Connections................................................... 135 8.2 Operational Change Control ............................................................................ 135 8.3 Restoring the System ...................................................................................... 137

9 System Updates and Migration 139 9.1 Updates, Service Packs and Hotfixes ............................................................. 139 9.2 Migration of the Application Software .............................................................. 140

Index Index-1

Table of Contents



1 Configuring in a GMP Environment

The availability of approved specifications, such as the User Requirements Specification and Functional Specification, is a prerequisite for the configuration of computer systems in a GMP environment. Requirements contained in standards, recommendations, and guidelines should be observed when creating these specifications. This chapter deals with the most important of these sets of regulations and various specifications (URS, FS, DS).

1.1 Life Cycle Model A central component of Good Engineering Practice (GEP) is the application of a recognized project methodology, based on a defined life cycle. The aim is to deliver a solution that meets the relevant requirements and is also cost-effective.

The figure below shows the development life-cycle model used in this manual. It is based on the recommendations of the GAMP Guide for Validation of Automated Systems (GAMP 4). It begins with the planning phase of a project and ends with the start of pharmaceutical production following completion of qualification and validation.

TraceabilityMatrix

ModuleTesting

URSPQ

PQDevelopment Life Cycle of Automated Production Plant / Equipment

Development Life Cycle of Computer System

FS

DS FAT

ApplicationDevelopment

ModuleDevelopment

SAT

OQ

IQ

Test

ing

/ Qua

lific

atio

nSpecification

System Build

QR

VRVP

QP

QPP

Configuring in a GMP Environment


Legend for the life cycle model

Abbreviation Description

VP Validation Plan

QP Qualification Plan

QPP Quality and Project Plan

URS User Requirements Specification

FS Functional Specification

DR Design Specification

FAT Factory Acceptance Test

SAT Site Acceptance Test

IQ Installation Qualification

OQ Operational Qualification

PQ Performance Qualification

QR Qualification Report

VR Validation 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 multiple processes and automation systems), a further distinction can be made between a higher-level master document (Validation Master Plan, also referred to as VMP or MVP) and VPs valid only for individual plants and systems.

See also GAMP 4, Appendix M1 "Guideline for Validation 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.



Quality and Project Plan The Quality and Project Plan (QPP) defines the scope of and procedures relating to project and quality management, with document and change control procedures, for example, being specified. The QPP defines the life cycle and integrates not only project phases relevant for validation, but also other organizational relationships (for example different time schedules from the various sections).

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

Specification The specification phase starts with the creation of the User Requirements Specification (URS). As a rule, the URS is created by the user and describes the requirements which the system has to meet. Once the URS has been created, a Functional Specification (FS) is created, usually by the supplier. The FS specifies the requirements defined in the URS more precisely at the functional level. The subsequent Design Specification (DS) contains detailed requirements related to building the system.

The functional and design specifications both form the basis for later qualification and validation tests. The following issues also have to be addressed during the function and design specification phases:

• Software structure

• Programming standards

• Naming conventions

• File naming convention

User Requirements Specification (URS) The URS describes the requirements the system has to meet from the user point of view. The URS is not system-specific and is generally created by the system user possibly with the support of the system supplier.

It is the basis of all other specifications.

See also GAMP 4, Appendix D1 "Example Procedure for the Production of a URS".

Functional Specification (FS) As a rule, the FS is created by the system supplier, occasionally in collaboration with the end user. It describes in detail the functions of the system, based on the URS. The approved FS serves as the basis for creating detailed specifications.

See also GAMP 4, Appendix D2 "Example Procedure for the Production of an FS".



Design Specification (DS) The DS is normally created by the system supplier. It is based on the FS and supplements it with detailed descriptions of, for example, the hardware to be used, tag lists etc. These parts of the specification may also be spread over several documents, such as

• Hardware Design Specification (HDS) including a description of the system configuration

• Software Module Design Specification (SMDS) for typicals

• Software Design Specification (SDS)

• Other documents/elements such as a process tag list, I/O list, parameter list, P&I diagrams, etc.

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

System Build The system is implemented in accordance with the Design Specification during the system build phase. Along with the procedures defined in the QPP and additional guidelines (coding standards, naming conventions, and data backups, for example), change management also plays an important role and is intended to allow changes to and deviations from the original specifications to be tracked.

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

FAT Once the system build phase is complete, a Factory Acceptance Test (FAT) is often carried out on the supplier premises and documented. This allows any programming errors to be identified and remedied prior to delivery.

The aim of the FAT is for the customer to accept the system for delivery in its tested state.

SAT The Site Acceptance Test (SAT) demonstrates that a computer 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, the IQ and/or OQ.



Test phase / Qualification The FAT is followed by technical commissioning (commissioning phase). This involves installing the system at the system user premises along with the created application software, followed by technical commissioning, testing, and qualification.

The commissioning and qualification phases can follow on from one another or can be combined. To save time and money, it is recommended that commissioning and qualification activities are coordinated.

The test planning should therefore be created in good time so that it is possible to check whether or not tests undertaken 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 test documents are created, tests and acceptance criteria must be clearly described.

Qualification Report The Qualification Report (QR) summarizes the results of the tests performed, based on the Qualification Plan, and confirms that the qualification phases have been completed successfully.

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.



1.2 Regulations, Guidelines and Recommendations When configuring computer systems in an environment in which validation is mandatory, attention should be paid not only to the applicable laws and regulations, but also to the recommendations and guidelines of various organizations. These are usually based on general guidelines and regulations, such as the Code of Federal Regulations Title 21 (21 CFR) of the US Food and Drug Administration (FDA) or the EU GMP Guide Annex 11.

Regulation / guideline

Author / organization

Title Regulation / recommendation

Where applicable

21 CFR Part 11 US FDA Electronic records; electronic signatures

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

Law, regulation

Manufacturers and importers of pharmaceutical products for the US market

Annex 11 of the EU GMP Guide

European Commission Directorate General III

Computerised Systems Guideline Europe

Annex 18 of the EU GMP Guide

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

Guide Worldwide

GAMP Good Practice Guide

ISPE Validation of Process Control Systems

Recommendation

Worldwide

NAMUR NE 71

NAMUR Operation and Maintenance of Validated Systems

Recommendation

Europe

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 Code of Federal Regulations Title 21 is made up of different parts, such as Parts 11, 210, and 211. FDA 21 CFR Part 11 is of particular significance for computer systems (and is known as Part 11). This Part deals with electronic records and electronic signatures.

Annex 11 of the EU GMP Guide Annex 11 of the EU GMP Guide contains 19 points which describe the configuration requirements, operation, and change control of computer systems in the GMP environment. An interpretation of Annex 11 can be found in the GAMP 4 Guide for Validation of Automated Systems in the form of an APV (International Association for Pharmaceutical Technology) guideline.

Annex 18 of the EU GMP Guide Annex 18 of the EU GMP Guide deals with good manufacturing practice (GMP) for active pharmaceutical ingredients. It is designed to be used as a GMP guide when manufacturing active pharmaceutical ingredients in the context of a suitable quality management system. Section 5 of Annex 18 deals with process equipment and its use.

GAMP -Guide for Validation of Automated Systems The GAMP (Good Automated Manufacturing Practice) Guide for Validation of Automated Systems was compiled to be used as a recommendation for suppliers and a guide for the users of automated systems in the pharmaceutical manufacturing industry. The GAMP 4 version was published in December 2001.

GAMP Good Practice Guide - Validation of Process Control Systems The GAMP Good Practice Guide supplements the GAMP Guide and covers specific topics in greater detail. The "Good Practice Guide", for example, includes recommendations relating to the validation of process control systems.

NAMUR Recommendations NAMUR recommendations are field reports compiled by the "User Association of Process Control Technology in Chemical and Pharmaceutical Industries" for their members to use on an optional basis. They should not be viewed as standards or guidelines. The NAMUR recommendations below are of particular interest for the configuration and use of computer systems in a GMP environment:

• NE 71 "Operation and Maintenance of Validated Systems"



1.3 Responsibilities Responsibilities for the activities included in the individual life cycle phases must be defined when configuring computer systems in a GMP environment and creating relevant specifications. Since this definition is usually specific for customers and projects and requires a contractual agreement, we recommend that the definition is integrated into the quality and project plan, see also GAMP 4 Appendix M6.

1.4 Approval and Change Procedure When new systems requiring validation are set up or when existing systems requiring validation are changed, the top priority is to achieve or retain validated status.

Setting up new systems If a new system is set up, document approval and the transitions between life cycle stages are defined prior to commencement of the project. This is usually carried out in conjunction with the definition of responsibilities contained in the quality and project plan. A life cycle like the one described in Section 1.1 "Life Cycle Model" is used.

Changing validated systems Changes to an existing, validated system are regulated as per the company's change control procedures. Before any changes are carried out they must be described, potential consequences must be identified, and associated steps (for example, performing tests, updating as-built documentation) must be defined. Once final approval has been received, the planned change is carried out, as are the defined steps.

If extensive changes are necessary, a life cycle similar to the one described in this manual may be used.


2 Requirements of Computer Systems in a GMP Environment

This section lists the essential requirements relating to the use of computer systems in a GMP environment. These requirements must be defined in the specification and implemented during configuration. In general, proof of who has changed or performed what and when they have done it must always be recorded (the "why" is optional). The requirements of this task are implemented in various functions and described in the following chapters.

2.1 Hardware Categorization According to GAMP 4 Appendix M4, hardware components are divided into two hardware categories. The hardware categories are listed below:

Category 1, standard hardware Category 1, standard hardware includes established, commercially-available hardware components. This type of hardware is also subject to the relevant quality and testing mechanisms.

The hardware is accepted and documented by means of an IQ test.

Category 2, customized hardware The structure and functionality of such hardware must be specified and then tested in detail in suitable, documented tests.

Requirements of Computer Systems in a GMP Environment


2.2 Software Categorization According to the GAMP Guide for Validation of Automated Systems, the software components of a system are assigned to various software categories. This ranges from commercially available software packages that simply need to be installed or configured to freely programmed software.

When commercially available software packages are used, the name and version must be described and checked in a documented test. Customer requirements (such as access protection, alarms or calculations) must be specified and also tested in documented tests.

Project-specific configurations of configurable software must be additionally specified and then tested in documented tests.

When software was developed especially for one customer, a detailed software specification must be created; functional tests of the software but also structural software tests (code reviews) should be performed.

The effort involved in testing software in the higher categories is considerably greater than for software in the lower categories. Time and effort spent on testing can be reduced by using as much standardized software as possible.

2.3 Configuration Management GAMP 4 defines configuration management as the activity necessary to precisely define an automated system at any point during its life cycle, from initial development right through to decommissioning of the system.

Configuration management involves using administrative and technical procedures in order to:

• Identify and define basic system components and to specify them in general

• Control changes to and approvals of elements

• Record and document element statuses and modifications

• Ensure elements are complete, consistent, and correct

• Check storage, handling, and delivery of elements

Configuration management comprises the following activities:

• Configuration identification (what is to be kept under control)

• Configuration control (how the control is performed)

• Configuration status report (how the control is documented)

• Configuration evaluation (how the check is verified)

This section describes configuration identification and configuration control.



2.3.1 Configuration Identification Version and change management is only practical in an appropriate configuration environment.Siemens therefore identifies every software and hardware package using a unique product code (machine-readable product code - MLFB) and version identifier. For the application software, the parts of a computer system that are subject to configuration management shuold be clearly specified. The system should be divided into configuration elements to this end. These configuration elements should be defined at an early stage of system creation to ensure that a complete list of these elements can be created and maintained. Application-specific elements should have a unique ID (name or identification number). The amount of detail required when defining elements is determined by the requirements of the system and the supplier who is developing the application.

2.3.2 Configuration Control The maintenance of configuration elements must be checked at regular intervals, for example in reviews. Particular attention must be paid to change control and the associated version control. Archiving and release of individual configuration items should also be taken into account.

Versioning To ensure correct change management, the configuration elements must be versioned. The version must be updated each time a change is made.

Change Control Suitable control mechanisms must be in place during configuration in order to ensure that changes are documented and transparency achieved. The control mechanisms can be described by means of SOPs and should cover the following:

• Software versioning

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

• Safeguarding of the traceability of changes to program codes

• Unique identification of software and all components contained within



2.4 Software Creation Certain guidelines should be followed during software creation, which are then documented in the quality and project plan (GEP idea). Software creation guidelines can be found in the GAMP Guide as well as the relevant standards and recommendations.

2.4.1 Using typicals for programming As seen in Section 2.2 "Software Categorization", the amount of validation effort required increases enormously from one GAMP software category to the next. While the validation of lower category software only calls for the software name and version to be checked, category 5 software validation requires the entire range of functions to be checked and a supplier audit to be performed.

To keep the required level of validation work as low as possible, priority should be given to standardized function blocks (products, in-house standards, project standards) during configuration.Customer-tailored typicals are created from standard function blocks and tested according to design specifications.

2.4.2 Identifying software modules/typicals During software creation the individual software modules should be assigned a unique name, a version, and a short description of the module. If changes are made to software modules, this should be reflected in the module ID.

2.4.3 Changing software modules/typicals If changes are made to software modules, these should be reflected in the corresponding module ID. As well as incrementing the version identifier, the date of the change and the name of the change initiator should also be included in the software module's ID. If software modules need to be changed, this must be indicated, for example by a comment, and a reference to the corresponding change request/order; see also Section 8.2.



2.5 Access Protection and User Administration To ensure that computer systems in a GMP environment are secure, such systems must be equipped with an access-control system. Access-control systems not only deny or permit users access to certain rooms, but can also protect systems against unauthorized access. Users are put into groups which are in turn used to manage user rights. Individual users can be granted access authorization in various ways:

• A combination of unique user ID and password - a description of the configuration can be found in sections 4.3 and 4.4.

• Chip cards together with a password

• Biometric systems

The system owner or an employee (administrator) nominated by the user controls the assignment and management of access rights to ensure that access is suitably restricted.

2.5.1 Applying access protection to a system In general, actions that can be executed on a computer system should be protected. Depending on his or her particular field of activities, a user can be assigned various rights. Access to user administration should only be given to the system owner or to specified employees. Electronically recorded data must also be protected against unauthorized access.

An automatic logout function should be installed on the system. The logout time should be agreed and defined with the user and noted in the FS.

! Note Please note that only authorized persons must be able to access PCs and the system. This can be ensured by using appropriate measures such as mechanical locks and hardware and software for remote access.



2.5.2 Requirements of user IDs and passwords User ID:

The user ID for a system must be of a minimum length agreed with the customer and be unique for the system.

Password:

A password should usually be a combination of numeric and alphanumeric characters. When defining passwords, the minimum number of characters and the expiry period for the password should be defined. Generally, the password structure is defined on a customer-specific basis. Configurations are described in sections 4.3 and 4.4.

Password structure criteria:

• Minimum password length

• Use of uppercase letters

• Use of lowercase letters

• Use of numerals (0-9)

• Use of special characters

To comply with the Windows guidelines for password complexity, at least three of the criteria listed should be used in the password in addition to the minimum length.

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 along with a password/PIN or with biometric systems, such as fingerprint scanners.



2.6 Electronic Signatures An electronic signature is computer-generated information that acts as a legally binding equivalent of a handwritten signature.

Regulations concerning the use of electronic signatures are defined, for example, in US FDA 21 CFR Part 11.

Electronic signatures are of practical relevance, for example, when entering data and intervening manually during runtime, approving process actions and data reports, and changing recipes.

Each electronic signature must be assigned uniquely to one person and must not be used by any other person.

Electronic signatures can be biometrically based or the system can be set up without biometric features.

Note

The regulations contained in 21 CFR Part 11, published by the FDA, must be satisfied in the manufacture of all pharmaceutical products and medical devices intended for the US market.

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 where a smart card replaces one of the two identification components. These identification components can, for example, be a user ID 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 / password The following points should be observed to safeguard the security of electronic signatures when user IDs and passwords are used:

• Uniqueness of the user ID and password

• Controlled issue of user IDs

• Cancellation of rights if a user ID or password is lost, no longer secure or compromised

• Security measures to prevent unauthorized use of a user ID / password and to report any misuse

• Training of personnel with documented proof of such training



2.7 Audit Trail The audit trail is a system control mechanism that ensures that data entries or modifications can be traced. A secure audit trail is particularly important when GMP-relevant electronic records are created, modified or deleted.

In this case, the audit trail must document all the changes or actions made along with the date and time. Typical contents of an audit trail must be recorded and describe the procedures "who changed what and when" (old value/new value).

The audit trail records themselves must be archived for a defined period according to the stipulations of the specification documents.

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.

The systems used must ensure adequate data security (for example redundant systems, standby systems, mirrored hard disks based on RAID 1).

2.8 Time Synchronization A uniform time reference (including a time zone reference) must be guaranteed within a system, to be able to assign an unequivocal time stamp for archiving messages, alarms etc.

Time synchronization is especially important for archiving data and analyzing problems in a system. UTC (Universal Time Coordinated, defined in ISO 8601) is recommended as the time base for saving data.



2.9 Archiving Data Electronic archiving refers to the permanent safekeeping of a computer system electronic data and records in long-term storage.1

The customer is responsible for defining procedures and controls relating to the safekeeping of electronic data.

Based on predicate rules (EC GMP Guide, 21 CFR Part 210, 21 CFR Part 211, etc.), the customer must decide how electronic data will be stored and, in particular, which data will be involved. This decision must be founded on a sound and documented risk assessment, which also takes the relevance of the electronic data over the time period it is to be archived into account.

The customer should define the following requirements2:

• Whether any archiving is even required for the application in question (backup/restore functionality could deviate from the archive functionality)

• Required archiving duration for the relevant data, based on legal and commercial requirements

• An archiving procedure that ensures that data covering the entire storage period can be read back and that allows simple migration of data formats

Process values (often in the form of trends), messages (alarms, warnings, etc.), audit trails, and, where necessary, other data can be logged for SIMATIC systems.

The memory space on a system's data carriers is restricted. Data can be swapped out to external data carriers at regular intervals in order to free up space on these system data carriers.

If logged data is migrated or converted, the integrity of that data must be safeguarded throughout the entire conversion process.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 Reporting Batch Data When producing pharmaceuticals and medical equipment, batch documentation takes on a special significance. Correctly created batch documentation is often the only documentary evidence that pharmaceutical manufacturers can provide in the context 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 as 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 set point 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, where 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

• Records 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 data 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:

1. The electronic records form part of the batch documentation or

2. The entire manufacturing log is created electronically.

Since all the requirements listed above need to be completed fully in the case of an electronic manufacturing log and data of several systems (for example, laboratory data, operator comments) often need to be integrated, case 1 is often found.

2.10.4 Requirements of 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).

• Suitable measures must be taken for long-term archiving of the electronic data to be retained and to remain available.

• 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 that allow the system to be restored if the original data or entire system is lost.4

The backup procedure must include 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 tested to ensure that data is saved correctly. Backup records should be labeled clearly and intelligibly and dated.5

Data backups are created on external data carriers. The data carrier 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 logged 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 Backup of application software Software backups have to be created following every software change on a system. They must document the last valid software version of a system. If parts of the software are modified, it is sufficient to only back up the modified part of the application software. Complete software backups still have to be created at regular intervals, however. 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 the project the software version should be backed up and documented at defined milestones, such as at the end of the FAT (in other words, prior to delivery of the system), once the Installation Qualification (IQ) has been completed, prior to the tests involved in the Operational Qualification (OQ), and, of course, when the system is handed over to the user.

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

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

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 Compliance Assessment". Chris Reid & Barbara Mullendore, PDA 2001.



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

• Creation date

• System name

• Software name

• Software or version name

• Serial number of backup

• Reason for the software backup

• Date of first use

• Date of backup

• Date and signature of the person performing the backup

• Identity of the operator

Retaining software backups At least the two most recent software backups should be retained. To ensure that these are kept safely, they should be stored at a different location from the system, for example in a fire compartment separate from the system.

A suitable backup strategy must be defined, based on the frequency with which changes are made to the software.

The shelf life of the storage medium should be defined (based on manufacturer documentation, e.g.) and the software backup must be appropriately migrated, for eaxmple by copying it to a new storage medium, before this period expires.



2.11.2 Backup of process data The data stored in computer systems, such as trends, measured values, or alarms, should be backed up on external data storage devices at regular intervals. This will minimize the risk of data being lost should a fault occur.

Labeling process data backups According to GAMP 4, data backups should be documented either on the label of the backup or in a separate report containing the following information:

• System designations

• Software / data designation

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

• Creation date

• Date of first usage

• Consecutive number

• Date of the data backup

• Reason for the data backup

• Identity of the operator

Retaining process data backups The same guidelines apply as in the description of backup copies in section 2.11.1.

Because 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 Backed up 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 If third-party components (hardware and software) specifically tailored to individual customers are used, a supplier audit should be performed to check suppliers and their quality management system. It must be confirmed that such hardware components are compatible.

Compatibility must also be confirmed when standard hardware and software components provided by other manufacturers are used.

Note

Appendix M2 of GAMP 4 contains detailed instructions on auditing a product supplier, service provider or solution provider.


3 System Specification

During the specification phase for a computer system, the system to be set up and its functionality are defined in as much detail as is required for building the system. This also includes the selection of products, product versions/options, and system configurations.

In the following schematic, the label on the left shows the phase of the specification.

Test

/ Qu

alifi

catio

n

Specification

System Specification


3.1 Specification of Visualization Hardware

3.1.1 Selecting hardware components Siemens offers a range of HMI devices (panels) for machine-level operator monitoring and control of individual machine and even plant units. The panels are robust and designed for use directly at the machine. The panels can be supplied with stainless steel frames to comply with the cleaning requirements for sectors such as the food and beverage or pharmaceutical industries.

Externally the panels differ in their dimensions and control methods (membrane keyboards, touch screen). Mobile Panels allow direct operator control of the plant / machine from different locations. The decisive criterion for selection, however, is the performance.

To meet the demands for automation projects in a GMP environment, which requires operator interventions to be documented in an audit trail, only panels that support functions for data archiving can be used. This limits the selection to the panels beginning with the 270 series. The statements made in this manual, therefore, relate to devices of these classes.

An Ethernet connection is required to save the recorded data to a network drive. The current panels beginning with the 277 series have an on-board Ethernet port. The capability for data communication with other applications or other HMI systems is provided by the OPC Server option. This option is available for the MP 277 panels and higher.

Another selection criterion is the number of alarms that can be configured with the standard alarm function, S/SQ/D/DQ. The number is documented in the device manual of the respective panel.

Panels are equipped with the Windows CE operating system that is adapted to the performance of the specific panel.

A panel PC or a standard PC can be also used as an alternative to a panel. Panel PCs are offered in a variety of expansion stages (SIMATIC Panel PC, SINUMERIK Panel PC, SIMOTION Panel PC). They differ in features such as their processor configuration, work memory and interfaces. Depending on their configuration, panel PCs have the operating systems Windows XP embedded, Windows 2000 Professional (MUI) or Windows XP Professional (MUI) installed.



Note Although it is technically possible to access several automation stations with the same address with the Mobile Panel 277 by changing the connections, you should nevertheless always assign different addresses to the automation stations to prevent incorrect addressing.

Note

Technical details about the panels and the panel PCs are listed in the current SIMATIC HMI ST80 catalog or can be viewed using the link https://mall.automation.siemens.com and HMI Selection Help under Product Configurators.

3.1.2 Hardware specification The Hardware Design Specification (acronym: HDS) describes the hardware architecture and configuration. The HDS should, for example define the points listed below. This specification is used later as a test basis for the IQ and OQ.

• Hardware overview diagram

• PC components and/or operator panels

• Network structure and IT infrastructure (for example domain server)

Other hardware specifications are also relevant to the visualization system, for example those of the automation system with CPUs, I/O cards, field devices etc.

The HDS can be formulated as part of the Functional Specification or in a separate document.

! Note The information in the hardware overview plan and the naming of the hardware components must be unique, in other words, the name of each hardware component may only occur once in the automation system.

Note

Recommendations relating to the required content can be found in GAMP 4, Appendix D3.

https://mall.automation.siemens.com/�



3.2 System and Network Security To allow the latest options to be implemented, to meet customer requirements for networked systems and to ensure maximum data protection, the security of data and information plays an important part when planning and setting up networked systems. Measures to increase data and information security include, for example:

• User and access rights concept for visualization.

• Security concepts relating to network security and restricted access to network drives, see also Section 6.7.3.

• For notes on virus scanners, refer to Section 3.6.2.

3.3 Specification of Basic Software The Software Design Specification (SDS) describes the architecture and configuration of the software. It includes a description of the application software, as well as a definition of the standard software components used in the system, which are specified by means of their designation, version number, etc. This description serves as a reference when performing subsequent tests (FAT, SAT, IQ, OQ).

The SIMATIC WinCC flexible system software can be used as the engineering and runtime software for all HMI devices and panel PCs listed in Section 3.1.1 "Selecting hardware components".

3.3.1 Access protection and user administration

Single workstation solution A local user administration with user groups, users and access rights can be set up for each panel in the WinCC flexible Engineering System. The WinCC flexible Engineering System also provides configuration options for password security, such as password structure and aging.

Integrated solution (distributed systems) In distributed systems with multiple workstations, central user administration on one computer is preferable. This requirement is met by the SIMATIC Logon software. SIMATIC Logon is installed on one computer with the Windows XP Professional or 2003 Server operating system. SIMATIC Logon checks that the user ID and password belong together (authentication) based on the user administration of the Windows operating system. The location of the check can be configured; information can be checked either against the Windows user management of the local computer or another computer in the network, for example in a domain.

To connect panels to the central user administration with SIMATIC Logon, additional Logon remote access licenses are required to cover the number of panels involved. Logon remote access licenses are evaluated collectively, in other words, several Logon remote access license packages can be installed to allow the required number of panels to be checked with SIMATIC Logon.



3.3.2 Engineering The WinCC flexible engineering software is offered matched to the hardware in various versions reflecting performance levels. The SIMATIC WinCC flexible Standard engineering software can be used for panels of the 270 / 370 series and the SIMATIC WinCC flexible Advanced engineering software can be used for panels of the 270 / 370 series and for panel PCs or standard PCs.

Versioning and change control The licensed ChangeControl option expands the range of functions of the engineering software by adding versioning and recording of the history of changes in the project configuration. Creating a major version (trunk) and minor version (branch) provides a clear overview of the organization of the individual configuration states for WinCC flexible projects. A rollback is possible at any time.

Changes in the configuration, made in an accepted reference state for example, are recorded without gaps and can be traced in the change history.

Note

The versioning is performed when the Version Trail option is integrated for operation. Refer to the SIMATIC STEP 7 GMP Engineering manual for more information.

3.3.3 Runtime software The basic software for runtime operation is not required for panels because it is already available on them. Panel PCs and standard PCs require the installation of the licensed SIMATIC WinCC flexible Runtime (RT) software package, which is available with varying a number of Power Tags (external tags).

Audit trail The licensed WinCC flexible /Audit option is tailored to the requirements of FDA 21 CFR Part 11. Using this option, operator interventions in the ongoing process can be recorded in an audit trail in WinCC flexible along with a time stamp and comment. Another feature is the assignment of electronic signatures that can be configured for important operator interventions.

Recipe management The recipe management function is integrated in WinCC flexible. A recipe can be created from several data records. The number of configurable recipes and data records depends on the performance level of the employed panel.

The WinCC flexible /Recipes option requires a license in combination with the WinCC flexible RT software (for panel PCs, for example).



Data archiving The data archiving management functionality is integrated in WinCC flexible. Tags, alarm logs and audit trails can be archived. The number of logs and entries depends on the performance level of the employed panel. On a panel, the logged data can be stored either on a memory card or on a network drive when available. The size of the log depends on the available storage capacity.

The WinCC flexible /Archives option requires a license in combination with the WinCC flexible RT software (for panel PCs, for example).

Reporting With WinCC flexible, individual alarms can be logged line-by-line and alarm logs, recipe data and current process values can be output as reports.

3.3.4 Interfacing to higher-level IT systems The licensed WinCC flexible /OPC Server option is used for data communication with other systems based on OPC (OLE for process control). With this option, multipanels are configured as OPC-XML servers and WinCC flexible RT is configured as an OPC DA server (DCOM). This option makes recorded data available for OPC clients, for example for process visualization or logging.



3.4 SIMATIC Additional Software

3.4.1 WinCC Premium add-ons The catalog for Premium add-ons for WinCC and WinCC flexible contains additional solutions for certain areas of application. The addresses of the relevant contacts for these add-ons are listed in the catalog.

Note

To implement functions that are outside the standard range of WinCC flexible, the Premium add-ons in the current catalog should be given preference. http://www.automation.siemens.com/hmi/html_76/products/software/wincc_addons/index.htmhttps://pcs.khe.siemens.com/index_pcs_7_add_ons-6811.htm

3.5 Application Software Specifications As well as defining the standard software components used, another essential task of the Software Design Specification (SDS) is to specify the application software. This is then used as a basis for subsequent testing of the application software (FAT, SAT, IQ, OQ).

The SDS can be integrated in other specification documents (FS, DS) or can exist as a separate document.

Part of this specification usually takes the form of other, separate documents, such as a process tag list, I/O list, parameter list, P&I, etc. The status of these documents (version, release) must be unequivocal as with the other specification documents (URS, FS, DS).

The SDS includes the following, for example:

• Plant hierarchy

• Software structure

• Archiving, alarms, trends, etc.

• Module specification, possibly in a separate document,

provided that these have not already been adequately defined in the FS.

Note

Additional information relating to the required content is available in GAMP 4, Appendix D4.

http://www.automation.siemens.com/hmi/html_76/products/software/wincc_addons/index.htm�

http://www.automation.siemens.com/hmi/html_76/products/software/wincc_addons/index.htm�

https://pcs.khe.siemens.com/index_pcs_7_add_ons-6811.htm�



3.6 Utilities and Drivers

3.6.1 Printers / printer drivers A list of printers recommended for the panels is available on the Internet. This list can be viewed under the entry ID 11376409 (http://support.automation.siemens.com/). Points to note about connecting up the printers are also included in this list.

The link is included in the WinCC flexible Information System under Performance features > Recommended printers.

3.6.2 Antivirus tools The use of virus scanners on panel PCs and standard PCs in process mode with WinCC flexible is permitted. For more information about selecting and configuring virus scanners and updating them, refer to the WinCC flexible readme files.

If virus scanners are used, the following settings should be observed:

• The real-time search is one of the most important functions. It is sufficient, however, to only check incoming data traffic.

• The time-controlled search must be deactivated, as it significantly limits system performance in process mode.

• A manual search should not be executed in process mode. It can be performed at regular intervals, e.g. during maintenance cycles.

Such stipulations should be laid down in an SOP.

3.6.3 Image & Partition Creator The optional "SIMATIC PC/PG Image & Partition Creator" software allows users to make data backups of hard disk content of panel PCs or standard PCs. Backing up system and application software means that the system can be restored quickly. Backed-up contents of hard disks can also 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.

Note

The created images are used to restore the installed system, but not to back up online data.

http://support.automation.siemens.com/�


4 System Installation

4.1 Installing the Operating System The SIMATIC panels and SIMATIC panel PCs differ in regard to the software installation for HMI devices.

SIMATIC panels SIMATIC panels are preinstalled with the MS Windows CE operating system.

Note

If the installed MS Windows CE version of the SIMATIC panel does not correspond to the version required by the WinCC flexible system software, WinCC flexible provides images for upgrading the firmware. For more information, refer to the WinCC flexible Information System > Transfer of Operating Systems.

SIMATIC panel PCs SIMATIC panel PCs are supplied with a preinstalled Windows XP embedded, Windows 2000 Professional MUI (multi-language) or Windows XP Professional MUI operating system.

4.2 Installing the System Software

4.2.1 Installing SIMATIC WinCC flexible The WinCC flexible system software is integrated in the engineering system and runtime components. Each component requires a license. The runtime software is, however, integrated in a panel and does not require a license.

The engineering system is offered in a variety of expansion stages. The WinCC flexible Standard or Advanced Engineering System is suitable for panels of the 270 series and higher; the WinCC flexible Advanced Engineering System is suitable for panel PCs / standard PCs. The installation is performed on a SIMATIC programming device / PC or on a standard PC.

You can select Standard, Minimal or User-defined as the setup type. The Standard installation installs all WinCC flexible components. Select the user-defined installation to integrate WinCC flexible in the STEP 7 system. You can also choose from a variety of optional user interface languages. STEP 7 integration is only offered if you have already installed STEP 7 on the system. For detailed information about installation, refer to the WinCC flexible Information System > Getting Started > Installation Instructions > Installation > Installing WinCC flexible.

System Installation


You can also integrate WinCC flexible in STEP 7 at a later point in time.

The project created with the engineering software is compiled and transferred to the panel. The project can then be started for runtime operation. No additional runtime software is required for the panel.

Panel PCs or standard PCs used as HMI stations require the installation of the WinCC flexible RT software and a license key to run a configured WinCC flexible project.

4.2.2 Installing the SIMATIC WinCC flexible options The options available for expanding the functions of WinCC flexible are already contained in the WinCC flexible engineering software and can be configured or activated as required.

The licenses differ as to whether an option is used on a panel or in WinCC flexible RT. The following table provides an overview of the licenses for WinCC flexible options. Refer to the latest HMI catalog ST80 for details.

License key for WinCC flexible option /

Panel WinCC flexible RT WinCC flexible ES

ChangeControl ./. ./. Yes

Logs No Yes ./.

Recipes No Yes ./.

Audit Yes Yes ./.

OPC server Yes Yes ./.

License keys for panels are transferred to the panel via the Engineering System. The procedure is described in the WinCC flexible Information System.

4.2.3 Installing utilities and drivers Depending on the panel type, a printer can be connected to a USB port or a PROFINET port.

Note

When using Windows CE based HMI devices, a network printer must be addressable with a printer name. This means that the printer must be integrated in the network via a DNS server or print server. With Windows CE based HMI devices, it is not possible to address a network printer using the IP address.

With panel PCs and standard PCs, it is advisable to use the standard printer drivers integrated in the operating system because these drivers have been tested (including continuous duty tests).

System Installation


4.3 Setting up User Administration An automated system is safeguarded against unauthorized access by activating access protection that restricts access at the operator command level and configuration level, as well as to backup copies and logs. Access protection is an essential requirement in the pharmaceuticals sector (see "21 CFR Part 11" and "Annex 11 of the EC GMP Guide" in Section 2.5 "Access Protection and User Administration").

Access to the operator command level on panels or panel PCs can either be controlled by a local or central user administration. With both user administration variants, user groups are created and specific operator rights assigned to the individual groups. When users log on, they automatically have all the operator rights of the assigned user group.

Note

The definitions of the authorizations, user groups and users should be made at the beginning 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.

The difference between local and central user administration is in the administration of the individual users.

4.3.1 Local User Administration For local user administration, not only the user groups with assigned operator rights are created in the WinCC flexible Engineering System but also all required users. The Runtime security settings provide configuration options including password security and duration of validity; this data is transferred to the panel with the project.

4.3.2 Centralized user administration The SIMATIC Logon software allows for setup of a centralized user administration. SIMATIC Logon is installed on one computer in the network. Apart from the SIMATIC Logon license, a Logon remote access license is necessary for each of the panel workstations. If panel PCs with the Windows XP/2000 operating systems are used as the HMI devices, SIMATIC Logon must also be installed and licensed on these devices.

When SIMATIC Logon is configured, one computer in the network is selected as the central logon computer (for example a domain). All the required user groups and users are created in the Windows operating system on this computer. The settings for password security are made in the local security policies of this Windows operating system. When a user logs on at a panel, SIMATIC Logon checks that the user ID and password belong together and match the user administration of the selected computer. The user groups are created with the same names in the local user administration and are assigned the appropriate operator rights there.

System Installation


Note

When using centralized user administration, it is advisable to set up local users to allow emergency operation. See below for more detailed information.

4.3.3 Setting up user groups in WinCC flexible User groups are set up in the Runtime user administration > Groups editor. The operator control of the process during operation can be defined as individual, application-specific control authorizations and assigned to existing user groups.

System Installation


This configuration takes place for both a local and a centralized user administration.

Note

Point to note when using centralized user administration: Remember that the user groups created in WinCC flexible have the same names as the user groups in the Windows operating system of the computer configured as the logon computer in SIMATIC Logon (for example domain).

4.3.4 Setting up users in WinCC flexible

Users in local user administration In local user administration, the users authorized for process control are created under Runtime user administration > Users and assigned to a user group. The authorization for process control is regulated by the authorizations assigned to the group.

System Installation


Users in centralized user administration: With centralized user administration, the users are created in the Windows user administration of the logon computer and assigned to the appropriate user group. When a user logs on at the panel, SIMATIC Logon checks that the user ID and password match via Ethernet connection. If the logon is successful, the user is created temporarily on the panel and assigned to the user group in WinCC flexible with the same name as in the Windows operating system. The user therefore has the operator control rights that have been enabled for this user group in WinCC flexible. Both successful and failed logons are recorded in the audit trail. Individual attempted logons are also logged in the SIMATIC Logon Eventlog Viewer.

Note

In WinCC flexible, a user can only be assigned to one user group. The users user group is created as default in both WinCC flexible and the Windows user administration. Each user created must be removed from the users group in the Windows “user management”.

Only emergency users are created directly in the WinCC flexible user administration. These are required if the Ethernet connection to the logon computer is interrupted at the time of logon. The settings in the WinCC flexible Runtime security settings only apply to the emergency user.

Note

A user logged on centrally can control the process even when the Ethernet connection is interrupted, when necessary also with electronic signature. SIMATIC Logon checks the logon via Ethernet connection.

System Installation


The schematic shows an example of user administration on a panel with centralized user administration. The user Paul Smith is created temporarily on the panel and is assigned to the Tablettier_Operator user group.

If the Ethernet connection is interrupted, the emergency users can log on using the local user administration.

Note

To distinguish between a central logon and an emergency logon, emergency users should only be created in the local user administration. This ensures that these users are available only in an emergency situation.

4.3.5 Security settings with local user administration The security settings for password security for local user administration are configured in the WinCC flexible Engineering System in the Runtime user administration > Runtime security settings editor.

For locally created users, security measures can be defined for password aging and password security. The settings are made according to the stipulations in the specification (URS, FS or DS).

Available functions:

Functions for password aging:

• Number of days the password will remain valid

• Password generation (how many times a password can be repeated)

• Days for warning of the expiration of the password

System Installation


Functions for password security:

• At least one special character

• At least one number

• Password length

For detailed information, refer to the WinCC flexible Information System under Working with WinCC flexible > User administration > Elements and basic settings > Runtime security settings.

To administer the local users and to change passwords, the User view object is integrated in a process picture. Changes made while the process is running take effect immediately.

Note

Changes to the user administration are performed offline in the engineering system and are therefore not automatically updated. To prevent passwords and user settings on the local HMI device from being overwritten when new settings are transferred, deselect the Overwrite password list check box.

System Installation


4.3.6 Security settings with centralized user administration The participation in centralized user administration with SIMATIC Logon is also enabled in the Runtime user administration > Runtime security settings editor by selecting the Enable SIMATIC Logon check box. The server name or IP address (if this is specified in absolute form), the port number 16389 (default) and the name of a domain or workgroup must be specified. Encrypted transfer is possible.

For more detailed information, refer to the WinCC flexible Information System under Working with WinCC flexible > User administration > Working with the user administration > Managing users on the server > Central user administration using SIMATIC Logon.

Note

The User view object that can be integrated in a process screen shows the user logged on centrally via SIMATIC Logon during runtime. Here, users can change their passwords. The new password is checked to make sure that it meets the set Windows security policy on the logon computer. Changing the password on the logon computer is organized by SIMATIC Logon. Changes made while the process is running take effect immediately. Password changes are recorded both in the audit trail and in the SIMATIC Logon Eventlog Viewer.

System Installation


4.4 Access Protection with SIMATIC Logon

4.4.1 User management in Windows The user management of SIMATIC Logon uses the mechanisms of the Windows operating system. This means that there are two user management options under Windows:

Windows domains 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 If a computer is a member of a Windows workgroup, the computer acting as server of the workgroup must be specified. All user data are created and managed on this server. From here, they are made available to the other computers in the system. When selecting the server, a panel PC with WinCC flexible Runtime can, for example, be considered if the operating system requirements for SIMATIC Logon are met. To improve performance, however, the choice is often a separate computer that is used only for user administration.

On the panel, the user ID and password (here: password) are entered. The user can only be assigned to one user group. Emergency users can be set up locally for emergency operation.

System Installation


Creating user groups and users The users and groups are configured according to the specification in the user management of Windows.

The following schematic shows an example of the assignment of users to user groups.

After logging in during runtime, the operator has precisely the rights required to operate the plant as assigned to the relevant user group in WinCC flexible.

System Installation


4.4.2 Security settings in Windows General security settings can be configured in the Windows operating system with Start menu > Settings > Control Panel > Administrative Tools > Local Security Policy.

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.

Guideline Description of the security setting

Enforce password history

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

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 numeric 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 must be changed.

Minimum password age

Specifies the minimum time that a password must be used.

The following screenshot shows the Password policies dialog box. The settings shown are examples.

System Installation


Account lockout policies For the monitoring mechanisms of the account lockout policy of Windows, the settings as specified in the URS or FS 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 policies dialog box.

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 or not the instance of a user logging on to a computer is audited.

Audit account management

Specifies whether or not the individual events of account management are audited (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

System Installation


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.

4.4.3 Configuration of SIMATIC Logon When SIMATIC Logon is installed, the user group with the name "Logon_Administrator" is created automatically in Windows. All users assigned to this group have permission to configure SIMATIC Logon. To do this, go to Start > SIMATIC > SIMATIC Logon and open the Configure SIMATIC Logon dialog.

The following settings are made in the General tab:

1. Selection of the language in which the dialog user interface is displayed

2. Activation of the date / time display according to ISO 8601 The time stamp is then displayed in the Eventlog Viewer in the following format: CCYY-MM-DD hh:mm:ss ±hh:mm The first part is the universal time coordinated (UTC), the difference compared with local time is shown after the sign.

System Installation


If this option is not selected, the time stamp is shown in the local computer time.

3. Activation of a default user in a default group to be logged on after the user logoff (either by the user or automatically by the system).

4. Reminder of a password change with the number of days before expiration

! Note The default group and a default user functionalities and the password change in the future are not supported in WinCC flexible.

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.

System Installation


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. At the same time, the screen keypad can be enabled for the logon.

In the Automatic logoff tab, the user specifies whether automatic logoff is used.

! Note The "Use SIMATIC Logon automatic logoff" functionality is implemented for WinCC flexible by setting a time period for the Admin user. This means that the user logged on centrally is logged off when the period expires. The period expires when there is no operator activity. If a logoff time with the value 0 is entered for the Admin default user, the user is not automatically logged off.


5 Project settings

User interfaces in the form of interactive, graphical process screens are created with the WinCC flexible engineering software for operator control and monitoring of machines and plants. Alarms and meaningful alarm texts indicate the operational and error states of the production process. Process-relevant data are recorded in data logs and visualized with trend graphics. Access to the process is organized with user groups and users in the user administration. Special editors are available for the different configuration tasks.

5.1 Project Manager All configuration information is saved in a project directory assigned to the project. The configuration depends on the type of HMI device specified when the project is created. Functions supported by the HMI device are offered for the configuration.

Multiple HMI devices and even different device types can be configure in a project. This has the advantage of allowing multiple HMI devices that are employed for plant operation to be managed in a single project.

The integrated copy function enables you to duplicate the configuration for an HMI device and transfer it to other HMI devices. Functions that are not supported by another device type are hidden and listed in the output window. We recommend you begin configuration with the HMI device that requires the least amount of work. This will reduce the error rate and the work needed for configuration and validation.

Project settings


5.2 Multilingual Projects WinCC flexible supports the creation of multilingual projects. The configured texts in process screens, recipes, alarms, etc. are centrally collected for all HMI devices in the Project Texts editor. A separate column is created for each project language. The export/import function enables you to export the texts for translation in the form of an Excel table and then import them back into the project.

The integrated system dictionary provides additional support for configuring multilingual projects. It contains a variety of the terms used in automation in several languages. A custom dictionary can be maintained to ensure a uniform vocabulary within the project.

Note

WinCC flexible provides an on-screen keyboard, which is displayed for text input on touch panels. The keyboard layout corresponds to the language of the installed operating system.

5.3 SIMATIC NET Settings SIMATIC NET is used for industrial communication. SIMATIC NET provides the communication drivers for connecting WinCC flexible RT to the automation level via PROFIBUS or Industrial Ethernet.

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

Project settings


5.4 Time Synchronization All time synchronization activities depend on the requirements of the project. The requirements of time synchronization must be described in the specification. A uniform time reference must be guaranteed when archiving data and analyzing problems in a plant. Time synchronization to a standard time is desirable, but not mandatory.

Direct time synchronization between WinCC flexible and the automation system is not available. Instead, the time can either be set on the automation system or on the HMI device. "Set time-of-day", however, does not have the same level of accuracy as time synchronization since message frames and script runtimes are included. The time master must be defined within the system.

5.4.1 Set time Setting the time of day is performed via an area pointer in WinCC flexible. Area pointers are parameter fields from which WinCC flexible RT obtains information about the location and size of data areas in the PLC. During communication, the PLC and the HMI device alternately access these data areas for read and write operations. The PLC and the HMI device trigger defined interactions based on the evaluation of stored data.

The area pointers reside in PLC memory. Their addresses are configured in the "Area pointers" dialog of the "Connections" editor.

Note

The procedure for setting the time of day between a panel and STEP 7 is documented in detail in entry ID 24104104 (http://support.automation.siemens.com/). This entry describes setting the time of day from the automation system to the panel and vice versa in detail.

http://support.automation.siemens.com/WW/view/de/19353440/�

Project settings


5.4.2 Transferring the CPU system time to the HMI device

Creating the "Date/time PLC" data area in the data block A data area consisting of a "DATE_AND_TIME" tag and four "BYTE" reserves is defined in the automation system. We recommend organizing this data area in a structure (UDT).

The system time of the controller is transferred to the defined tag of the type DATE_AND_TIME in a one second cycle. This can be achieved by transferring the OB start time.

Project settings


Setting up the "Date/time PLC" area pointer in WinCC flexible The time of day is read cyclically from the automation system using this area pointer and set on the HMI device. The automation system is the time master.

The table of configured connections is opened with Communication > Connection. The connection to the Date/time PLC area pointer is selected in the Area Pointer tab of the For all connections table and linked to the data area in the PLC. The update period of the system time on the HMI device synchronized to the current system time of the CPU is specified with the acquisition cycle.

Changing between daylight saving and standard time Automatic switchover between daylight-saving and standard time is not currently supported on the panels. Display of the daylight saving time must be enabled or disabled manually in the Control Panel in the Date / Time object using the Daylight savings time currently in effect check box.

An alternative for switching over between daylight-saving and standard time is to set the switchover points using a process picture. A description of the procedure can be found under entry ID 26961516 (http://support.automation.siemens.com).

Project settings


5.4.3 Transferring the HMI device system time to the CPU The Date/time area pointer is used to transfer the system time of the HMI device to the CPU in WinCC flexible. Select the connection to the desired automation system with the menu command Communication > Connection. The "Date/time area pointer is enabled in the "Area Pointer" tab of the "For each connection" table and linked to the intended data area in the automation system. Setting the time of day is handled by control job "41" in WinCC flexible. To transfer job mailboxes, the "job mailbox" area pointer is linked to a data word in the "For each connection" table. The automation system cyclically writes the value 41 (BCD coded) in the defined data word to set the time of day. WinCC flexible resets the value to 0 as soon as the job mailbox has been processed.

You will find additional information on setting the time in the SIMATIC S7 GMP Engineering manual.

Project settings


5.4.4 Synchronization of the SIMATIC Logon server The time-of-day synchronization of SIMATIC Logon depends on the environment (Windows workgroup or domain) in which SIMATIC Logon is operated.

Time synchronization in a Windows workgroup The time of day can be synchronized in a Windows workgroup, for example with SICLOCK as the time master.

SICLOCK receives the current time via an external time source (DCF, GMP) and synchronizes the system time of the components such as HMI devices and automation systems connected via Ethernet. (Additional information is available on the Internet at http://siemens-edm.de/siclock.o.html)

Time Synchronization in a Windows Domain If SIMATIC Logon, the HMI devices, and the automation system are operated in a Windows domain, the domain server acts as time master. To set the time on the domain server, SICLOCK can once again be used. (see above)

If the time in the network is inaccurate, clients may be rejected in the domain. This means operator input from 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. 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 of the Windows operating systems.

http://siemens-edm.de/siclock.o.html�

Project settings


5.5 Support for Configuration Management Configuration of an automated system consists of various hardware and software components; these may be standard components or specially tailored user components. In keeping with configuration management according to GAMP 4, the current system configuration should be available and clearly arranged at all times. To achieve this, the system first has to be split into configuration elements, and it must be possible for these to be identified using a unique designation and version number and for them to be distinguished from the previous version.

The procedure for the steps described below is part of the configuration management and must be described in a SOP that is binding for all persons involved in the project.

5.5.1 Defining configuration elements In terms of hardware, standard components are usually used, which are defined by and documented with their type designation, version number, etc.

The Windows CE operating system is preinstalled on the panels when shipped. Any updates for the operating system are obtained in the WinCC flexible Engineering System. When commissioning, the WinCC flexible Engineering System should be used to check whether updates are available to the panel operating system.

The use of customer-specific hardware requires more effort. See also Section 2.1 "Hardware Categorization".

In the software, the standard components include, for example, the (non-configured) system software SIMATIC WinCC flexible Engineering System with its libraries, WinCC flexible PC Runtime and Premium add-ons. Just like the hardware, these are defined and documented with designation, version number, etc.

The application software is configured and/or programmed on the basis of standard software. The individual configuration elements into which the application software should be split cannot be defined for all cases as it differs depending on different customer requirements and system characteristics.

Below is a description of examples and options for versioning in WinCC flexible:

Project settings


5.5.2 Versioning of configuration elements While the version ID of standard software cannot be changed by the user / configuration engineers, the issuing of version numbers and a procedure for change control must be defined in the instructions etc. for configuring the application software. From when the application is first created, all configuration elements should be maintained following a defined procedure for configuration management.

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

• Name

• Date

• Version number

• Comment on the change

The change is described in greater detail in the relevant change request.

Note

Section 5.5.2 includes examples of how individual software elements can be versioned. For additional information on monitoring the configuration in WinCC flexible, refer to Section 2.3 and for general information on this topic to GAMP 4, Section 7.11.7 and the corresponding appendix M9. The procedure for changes made to a plant in runtime must always be coordinated with the plant user, see Section 8.2.

5.5.3 Versioning the application software The project guidelines must define which elements are to be versioned, when versioning is to take place, and whether a main version or sub version is to be incremented; for example:

"The main version is set to 1.0 following the FAT and to 2.0 following commissioning. All other changes are reflected by incrementing the sub version."

Whether the main version or the sub version is to be changed can also depend on the scope or effect of the change in question.

See also Section 7.4 "Checking the Configuration"

Project settings


Versioning a screen object A text describing the screen can be entered in the properties of the screen object in Properties > Help Text. In this text box, data for versioning can be maintained by specifying a versioning ID, name and change date as shown in the schematic below.

Note

The Change Control options includes a change control that records every change in the configuration with time stamp, user and object-dependent configuration differences.

Versioning VB scripts WinCC flexible provides predefined system functions for common configuration tasks. These can be used to perform many tasks in Runtime without needing any programming skills.

Runtime scripting can be used to solve more complex problems. Runtime scripting is a programming interface with which parts of the project data can be accessed in runtime, for example, to make application-specific evaluations.

It is advisable to maintain a history in the scripts indicating any changes made. The history can be entered in the script as a comment before the code or in Properties > Comment.

Project settings


The screenshot shows the history as a comment before the start of the code.

The screenshot shows the history in the comment box for the script.

The version ID must be kept up-to-date as specified in the SOP for configuration management.

Versioning reports A static text box for the manual entry of a version number can be inserted either in the report header or footer. The version ID must be kept up-to-date as specified in the SOP for configuration management.

The following screenshot shows an example of the footer of a report layout with version ID.

Project settings



6 Creating Application Software

This chapter explains the configuration of SIMATIC WinCC flexible in a GMP environment based on examples. The configuration of the automation level in a GMP environment is not described here.

In the schematic below, the markers in the lower part indicate the phase of system creation.

Test

/ Qu

alifi

catio

n

Specification

Creating Application Software


6.1 Creating Process Screens Process screens are configured in the WinCC flexible screen editor, a combination of a graphics program and tool for process visualization. The appropriate device layout in the screen depends on the selected HMI device. Function keys are also shown if the configured HMI device features them. The screen resolution, color depth, fonts and available objects also depend on the device type.

The basic design, such as the company name, logo, buttons for screen selection, etc., can be configured in a template. This template forms the basis for the process screens. Static and dynamic objects are provided in a toolbar to design screens.

Graphics The Graphics area in the toolbox contains a comprehensive collection of graphics and symbols for graphically editing screens. Graphic objects such as machines and plant components, measuring equipment, operator control elements and buildings are thematically organized. The library objects can be inserted in a screen with drag-and-drop and adapted as required.

Symbol library, project library, global library Libraries are a collection of screen object templates. The library objects can be used repeatedly without having to be configured again. The objects are inserted into the process screen using drag-and-drop.

The WinCC flexible engineering software package includes system libraries with configured operator control elements, faceplates and graphics. You can also create customized project libraries and several global libraries. Project libraries are only available within a library and are saved together with the project data. Global libraries are available for all projects. A global library is stored independent of project data in a separate file with the extension *.wlf. All application-specific objects should be stored in the project library so that the objects are saved with the project and changes are entered in the change log of the ChangeControl option.

Screen navigation Configuration of screen navigation for selecting screens is necessary in projects consisting of multiple screens. Various methods can be used for this.

• Screen selection via function keys, if they are available on the HMI device

• Creation of buttons for screen selection (in the template, for example)

• Using the WinCC flexible screen navigation with a navigation bar

Hierarchical screen navigation is created in the form of a tree in the WinCC flexible screen navigation. Navigation is performed with the integrated, configurable navigation bar.



Example of the navigation bar

Faceplates in conjunction with structure tags The faceplates functionality in WinCC flexible allows object-oriented configuration. A faceplate is a group of selected objects assembled and configured for a specific application and used for operator control and monitoring of a process unit such as a motor. Faceplates are automatically saved in the project library and are therefore available throughout the project. They can also be stored in a global library to make them available outside the project.

Once the individual objects are assembled in groups, only the object properties and events used for the dynamic characteristics of the faceplate are specified in a configuration dialog as an interface to the process.



The figure shows the objects in the faceplate on the right and the interface of faceplate configured for the specific application on the left. The colored connection lines indicate the object properties and events that form the interface to the outside for the dynamic characteristics. VB scripts, which are executed solely in the faceplate, can also be programmed.

Faceplates are given dynamic characteristics using structures that assemble several tags of differing type. Structures can be configured both internally and in connection with the SIMATIC S7 300/400 automation system. The "Motor" structure was created as an example in the faceplate configuration dialog in the figure above.

This structure contains the structure elements, temperature, speed, motor on etc. A tag of the type "Motor" is created for each relevant motor with the menu command Communication > Tags. The structure elements are connected directly to the externally oriented object properties in the configuration dialog for the faceplate.

When the faceplate is inserted in a process screen, the corresponding tag of the "Motor" type is specified and the motor name is adapted.



6.2 Setting Access Protection for an Object Once access protection has been set up with user groups and users, objects subject to control can be associated with an authorization. To do this, select the relevant object in the process screen (the "Copy" button in the figure) and specify an authorization for controlling the object in the Properties > Security area (the "Administration" authorization in the figure).



Care must be taken to ensure that access protection is configured for all objects requiring an electronic signature.

As a result of this configuration, the logon dialog is displayed automatically if no user is logged on. A change can be made in the I/O box only when a user with appropriate permissions is logged on.

6.3 Creating VB Scripts WinCC flexible provides predefined system functions for typical configuration tasks. The system functions (the setting of a bit, for example) can be linked to a screen object in a function list without requiring advanced programming skills.

You can use VB scripts to solve more complex tasks. For example, the predefined system functions can be used in a script together with instructions and conditions in a code based on Visual Basic Script. Access to the WinCC flexible object model is available using scripts. Writing VB scripts offers numerous possibilities for implementing application-specific functionality.

Note

Selections of the predefined system functions as well as the permitted set of commands depend on the HMI device employed.

VB scripts are programs written by the user that belong to the Category 5 software. This type of software is developed to meet customer-specific demands not covered by standard functions.

The procedure for creating Category 5 software is as follows:

1. Creation of a functional description for the software

2. Specification of the function blocks used

3. Specification of the inputs and outputs used

4. Specification of the block for operator control and monitoring

Note

The creation of custom software (GAMP Category 5) should be kept to a minimum since it increases the effort needed for testing and validation considerably.



6.4 Setting up the Audit Trail The WinCC flexible / Audit option is offered especially for use in GMP-relevant production plants. This option expands the range of functions in the WinCC flexible system software to ensure that the project conforms to FDA 21 CFR Part 11. The /Audit option requires a separate license key for HMI devices and WinCC flexible RT.

The range of functions in the /Audit option is described in the following:

Project setting When a project is created, Regulated project is selected centrally in the GMP settings.

Audit trail The audit trail is configured as a log in the Archive editor and GMP-relevant activities are recorded in runtime.



The audit trail is always a file in CSV format with a checksum. The checksum is generated with an integrated algorithm and ensures that any manipulation can be detected. The file name and storage location are defined during configuration. If there is not enough space at the storage location, suitable actions an be configured under the events. For more detailed information on configuring the audit trail, refer to the WinCC flexible Information System > Options > Audit.

The following entries are automatically saved in the audit trail:

• Runtime sequence Runtime start / stop, project information, failure of the USP when the uninterruptible power supply option is used (see also section 6.13)

• User administration User logon/logoff, failed logon attempts, etc.

• Alarm system Alarms requiring acknowledgment, acknowledgment attempts

• Archiving operations Starting, stopping, opening, closing of a log, etc.

• Change values of GMP-relevant tags by the user

• For GMP-relevant recipes Creating, changing, saving, loading data records, etc.

• Certain system functions A list of the GMP-relevant system functions is available in the WinCC flexible Information System > Options > Audit > Working with Audit > Logging system functions

Additional information is available in the WinCC flexible Information System under Options > Audit > Basic principles > Logging concept of the audit trail.

! Note The Force function must be deactivated in the GMP environment so that all operator actions can be recorded in the audit trail. We recommend evaluating the events Little free space and Little free space, critical and configuring a reaction in the function list. (for example, generating a notification message, moving the logs to a network drive) If no storage space is available, GMP-relevant actions can no longer be performed.



6.4.1 Generating audit trail entries When the /Audit option is used, the properties of tags are extended by the entry, GMP Settings. Selecting GMP relevant causes a changed tag value to be entered in the audit trail automatically. The change can either be linked to a mandatory comment or an electronic signature, see also Section 6.5 "Electronic Signature".

NotifyUserAction system function With the integrated NotifyUserAction system function, the audit trail can record specific user actions that would otherwise not be entered, such as activation of a button.



The acknowledgement type and comment properties can be configured. The description is stored in a text that comments the operator action. This text is always entered in the audit trail. The complete entry in the audit trail depends on the rest of the configuration. See also the section Electronic signature

The system function can be integrated in an application-specific script, for example to form a variable description of the performed action. The following figure shows a script that executes the "NotifyUserAction" system function and specifies the "Batch started" text in the description in connection with the batch name that is read from the "BatchName" tag.

! Note Once again, care must be taken that the control of the object (here a button) is protected by operator permissions. This means that a logon is forced if no user is logged on and only a user with suitable rights can provide the electronic signature.

Recipe configuration When the Recipe option is used in connection with the Audit option, GMP settings can be configured in the properties for the recipes. Details are described in the section 6.6 "Recipe Management with the Recipe ".

When the check boxes are activated, the following actions made to the recipe are commented with entries in the audit trail.

• Creating, changing and saving recipe data records

• Downloading/uploading a data record from/to the controller

• Electronic signature for transferring recipe data

• Electronic signature for saving recipe data



6.4.2 Display of the audit trail The WinCC Audit Viewer application is used to display the audit trail on a PC. This is available in the WinCC flexible system software package. The Audit Viewer can be installed on any PC with a Windows operating system.

The audit trail file is opened during process operation to record the relevant entries. To be viewed with the Audit Viewer, the file must be closed, copied or moved to another directory and then opened again. System functions are available for this action that can, for example, be linked to a button. While the file is closed to allow it to be copied, no GMP-relevant operator activity is possible on the panel. The moved file can then be opened with the Audit Viewer. The checksum generated for each entry by an integrated algorithm is evaluated for this. The green indicator in the "Data Validity Indicator" area shows that the file has not been manipulated. The indicator is red if manipulation has occurred. To avoid manipulation of the audit trail files, the Windows directory can be protected from unauthorized access using Windows tools; see also Section 6.7.3 "Restricting access to the network drive".

Additional details about the Audit Viewer are documented in the WinCC flexible Information System and in the help system for the Audit Viewer.

The checksum can also be verified with the HMIChecklogIntegrity.exe application that is available in the WinCC flexible 2007 Runtime folder after the WinCC flexible system software has been installed. The WinCC flexible Information System > Getting Started > Getting Started Options > Using Audit > Evaluating Audit Trails with DOS Program describes how to launch the HMIChecklogIntegrity.exe application.



6.5 Electronic Signature The electronic signature is set in the GMP settings for the tag. If there the value of the tag is changed during operation, a dialog box opens in which the password of the logged-on user is queried. If a "mandatory comment" is selected, a comment must be entered in addition to the electronic signature when a tag value is changed.

Note

Operator input to an object that causes a change in a GMP-relevant tag value must be protected using operator permission. This ensures that only a user with suitable permissions can perform the action.

The following screenshot shows a section of the audit trail with an entry for electronic signature.

The "NotifyUserAction" system function is another way of generating an audit trail. The selection made for the confirmation type is "Electronic signature". This means that when the system function executes, the dialog shown above is also displayed for the entry of a password. See also section 6.4.1 "Generating audit trail entries".



6.6 Recipe Management with the Recipe Option The Recipe option for panels requires no license. This option does require a license when WinCC flexible RT is used on a PC.

Associated records, such as machine parameters or production data, are collected in a recipe. A recipe consists of several data records in which the various values for the individual recipe entries are stored.

The recipes along with the corresponding recipe entries are created and managed in the "Recipes" editor. The number of recipes is based on the HMI device type. The following alternative methods are used to generate the data records:

• Recipe data is entered in the engineering system and transferred with the complete project data

• Recipe data is entered during ongoing operation

• Records are read in ongoing operation following the teach-in mode on a machine

• Recipe data is imported from a CSV file

The method selected for creating the data records depends on the conditions of the production plant.

For production plants operating in an environment requiring GMP, the GMP settings can be set during the configuration of the recipes in the WinCC flexible system software, see also Section 6.4.1 "Generating audit trail entries".

Either a separate recipe screen can be configured or the "recipe view" object can be integrated in a process screen to process or display the recipe data on the panel or in WinCC flexible RT.

These two variants are presented below:



Recipe view The recipe view is integrated as an object in a process screen. There are numerous options for configuring the display window and window characteristics in the object properties. To use the recipe view to simply display data, the operation during ongoing operation can be disabled and the status bar and buttons can be hidden.

A recipe view action in ongoing operation generates entries in the audit trail when the GMP settings have been selected as described above and the Audit option is enabled.

The following data are saved in the audit trail:

• Time stamp

• User ID

• Recipe name

• Record name

• Performed action

• User comment

Note

Data changed in a data record are not entered in the audit trail with the old value and new value. To nevertheless log changes to a record in the audit trail, value changes can be made in IO fields configured in the recipe screen in addition to the recipe view object. When GMP-relevance is selected for the process tags linked to the IO fields, all changes are commented in the audit trail with old value and new value. The transfer of the IO field data to a data record is controlled with the "Synchronize" button in the recipe view. This can prevent the tag values from being directly written to the controller. The transfer to the PLC is performed separately with the Transfer button and must be confirmed with an electronic signature when the GMP property is set. The transfer is recorded in the audit trail with a time stamp, user ID, recipe and record name as well as a comment by the user.



Recipe screen The recipe values are entered via I/O fields. GMP-relevance is selected for the linked process tags. (See also section 6.4.1) This causes each changed value to be recorded in the audit trail with the old value, new value, time stamp and user. The organization of the data records, such as Create new, Delete, Save, Transfer to automation system as well as Log, is performed via buttons. For this, either the system functions for recipe management integrated in WinCC flexible are called or customized application-specific scripts are attached in the button properties.

The version, user, date and time of the change and release of the recipe, etc., can be included as additional parameters. The boxes for displaying these parameters should be set up so that they cannot be written by direct input (read-only attribute). The parameters should be supplied with values only from scripts. This means, for example, the version can be incremented by a user-defined algorithm.



6.7 Recording and Archiving Data Electronically To acquire production-relevant data, data logs and alarm logs are created in WinCC flexible. The operator actions can be tracked and logged in the audit trail. The /Audit option is required to record an audit trail (see Section 6.4 "Setting up the Audit Trail").

6.7.1 Setting up data and alarm logs It is highly important to provide full quality verification relating to production data, especially for production plants operating in the GMP environment.

Data logs Data logs are used to acquire production-relevant, continuous process values. The data log stores the contents of selected tags with time stamps in a defined cycle.

The configuration is performed with the following tasks:

• Creating and configuring one or more data logs Specification of general settings such as name, log size, storage location etc. (see also Section 6.7.2 "Archiving data logs, alarm logs and audit trails")

• Configure the data log All tags in the project are created with Communication > Tags object. The data log and the archiving cycling are specified for the tags that are to be archived.

• The archived values can be visualized, for example with trend graphics in the process screens.



Alarm logs Alarms are configured to detect events and states that occur in the process. WinCC flexible also generates system events for displaying specific system states of the HMI device or PLC.

The following alarm types can be selected when configuring alarms:

• Discrete alarm type An alarm is triggered by the PLC due to a bit change in a tag. The time stamp of the alarm is set by the HMI device.

• Analog alarm type The HMI device monitors the limits of a tag and triggers an alarm if a tag violates a high or low limit. The time stamp of the alarm is set by the HMI device.

• Alarm number type The PLC transfers an alarm number (and any associated alarm text) to display an alarm. This requires that alarms are configured in STEP 7 in the ALARM_S/SQ/D/DQ alarm block. The time stamp of the message is set by the PLC.

Notes on the time stamping

With the discrete alarm and analog alarm types, the acquisition cycle, bus runtime and processing time are contained in the time stamp. Messages are lost if they are shorter than the acquisition cycle. With the alarm number type, the time stamp is recorded by the PLC when the alarm occurs and is passed to the HMI device. With the alarm number type, the SFCs Alarm_S/SQ and Alarm_D/DQ are used on the SIMATIC S7 controller. Refer to the relevant CPU manuals and the block descriptions in the SIMATIC STEP 7 online help for information on restrictions relating to the system resources for simultaneously pending alarms.

The following configuration steps are required to set up alarm logs:

• Create and configure one or more alarm logs Make general settings such as the name, size of the log, storage location, etc.; see also Section 6.7.2 "Local data archiving“.

• Log the alarms of an alarm class An alarm log can be assigned to each alarm class

• A detailed description of the configuration of alarm logs is available in the WinCC flexible Information System under Working with alarms > Alarm logging.

! Note Protect the network drive shared for data backup by assigning access authorizations (see Section 6.7.3).



6.7.2 Archiving data logs, alarm logs and audit trails The configuration of the log type for alarm and data logs specifies the reaction when a log is full:

• Circular log, the oldest entries are deleted

• Segmented circular log, the entries are stored in defined segments. When all segments are filled, the oldest segment is deleted.

• Logs with system events that depend on the fill level, a system event is triggered when a defined fill level is reached.

• Log with execution of system functions when log is full

The size of the data or alarm log depends on the length of individual entries and the number of entries. This is set by the number of data records. The storage capacity of the storage location (such as a CF card) must be taken into consideration when configuring the number of log entries.

The logs can be saved in a CSV file on panels. On PCs, data and alarm logs can also be saved in database format (ODBC).

The audit trail is configured as an endless log and is always written to a file in CSV format. A minimum amount of free disk space is defined as the limit for the storage location (memory card or network drive). If the available space falls below this limit, a configured function list can be executed (see section 6.5 "Electronic Signature“).

Note

A plant-specific archiving concept (URS, FS) must be developed for plants operating in an environment requiring GMP.

We recommend logging data locally on a memory card and then backing it up at regular intervals to a network drive (see also section 6.7.3).



Local data archiving The data can be logged locally on a panel using a memory card.

An Ethernet connection is required to save the log data to another storage medium. Transfer of the logs can be triggered, for example with a button that calls the integrated ArchiveLogFile system function.

Before being transferred, the logs are closed and then opened again when the transfer is completed. Any log events that occur in the meantime are buffered. Detailed information is available in the WinCC flexible Information System.

The access protection for the folder in which the CSV files are stored is configured under Properties > Security Settings for the folder in the Windows Explorer, see also Section 6.7.3.

Data saved as a database can be read again with a database system via an ODBC driver. The access protection is regulated in the respective database system.

Backing up logs A network drive in a local network can be specified for data backup of locally stored data and alarm logs as well as the audit trail. The panel is connected to a network via Ethernet for this. The steps necessary for establishing a network connection are described in detail in entry ID 13336639 (http://support.automation.siemens.com/).

The next Section 6.7.3 describes how the directories on the network drive are protected against unauthorized access.




6.7.3 Restricting access to the network drive The records are archived by WinCC flexible in the form of CSV files. The CSV format offers no data security options for protection against unauthorized user access. To ensure that the records are protected from unauthorized access, however, the folder containing the files from the panel must be suitably protected.

The following procedure is recommended for this:

A panel name with password is specified in the Identification tab of the network settings. The panel logs on to the network under this name. If the panel is associated with a domain, the domain name must also be specified.

Note

A panel can only access network devices in the same subnet.

A new user group, such as "Panel", is created on the PC on which the shared network drive is located. (In Windows XP under Control Panel > Administrative Tools > Computer Management > Local Users and Groups > Groups)



A new user is created with the panel name under Users. This is added to the newly created user group.

The access protection for the folder is set in the Security tab of the shared network drive’s properties. The Panel group requires Full access for HMI device "mp1" to be able to create the CSV files in the folders.



Users assigned to the "User group have read-only and no write access.

Write access can be denied for users in the "Administrators" group.

With these settings, only the "Panel" user group has “write” access for the folder.



Note The security settings do not have to be set directly on the network drive. If the log data is stored in a subfolder of the network drive, only the security settings for this subfolder need to be set.

Note

The security settings shown were made with the NTFS file system in the Windows XP Professional operating system.

6.7.4 Batch-oriented data recording The WinCC PM-QUALITY add-on can be used for batch-based acquisition of batch data in small to medium-sized plants. PM-QUALITY is installed on a standard or panel PC (check the operating system) that is connected to the panel via Ethernet. PM-QUALITY can be installed on the same PC together with WinCC flexible RT. PM-QUALITY provides various ActiveX controls for displaying the recorded or current batch data. These controls can be integrated in a process screen in WinCC flexible PC RT.

For more detailed information on PM-QUALITY, refer to section 6.8.2 “Batch-based reporting”.

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 was aborted, locked or reported as completed.

Automatic export of a batch is performed only once. By selecting the check box "Close and log batch automatically" in the Project Settings > Defaults dialog, no changes or additions can be made in the batch data following the automatic export.

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

PM-QUALITY checks if the completed batch is ready for export in the current acquisition cycle. The records 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 included in the PM-QUALITY package.

The batch is selected in the batch selection dialog and the view is started on screen using a button in the toolbar.



6.8 Reporting

6.8.1 Standard reporting In WinCC flexible, alarms can be output as reports on a printer. Recipes entered in the WinCC flexible recipe system can also be output as a report on a printer. To print out reports, layouts with suitable contents are configured in the Reports editor.

The following data can be documented:

• Alarms immediately when they occur

• Alarms from the alarm buffer

• Alarms from the alarm log

• Recipes

The options for data output depend on the performance of the HMI device and the licensing in PC RT.

Reports editor The Reports editor is divided into different areas. This division allows reports to be created with a cover sheet, back sheet, header and footers as well as one or more sheets of data.

Numerous objects are available to design a report, for example static objects such as texts and graphic elements and dynamic objects such as I/O boxes that allow current tag contents to be documented at the time of printing. The documentation of alarms and recipes is handled using special objects.

For more detailed information on designing reports, refer to the WinCC flexible Information System under Working with WinCC flexible > Working with reports.

Alarm logging To report alarms, the Print alarms object is inserted in a report page. The object properties define which alarms are reported.



Either alarm events or alarm log can be selected as the source for alarms. If alarm events is selected, the alarms from the alarm buffer are reported. If alarm log is selected, the alarms are printed from the assigned alarm log. This is available only for panels that have the alarm logging function. It is also possible to make the selection according to alarm classes.

To be able to assign alarms to a specific production sequence, a variable output range can be specified. The start and end of the range are transferred in tags of the type date / time.

Recipe output To document recipes created in the WinCC flexible recipe system, the Recipe view object is inserted from the toolbox window in a report page. The display options are set in the object properties.

When selecting the recipe, the user can decide whether to print a specific recipe or all recipes. At the same time, a specific data record of a selected recipe can be output.

Report output The configured reports can be output event-driven or cyclically. An event-controlled display is, for example, linked to an operator input object in a process screen.



Cyclic display regardless of the screen is configured in the scheduler.

It is possible to select not only time cycles but also the alarm buffer overflow event in the scheduler as the criterion for printout. If a critical status occurs in the fill-level of the alarm buffer, the alarm buffer can be printed out and then deleted with the system function DeleteAlarmBuffer in the toolbar.



6.8.2 Batch-based reporting The WinCC add-on PM-QUALITY can be used for batch-oriented reporting. The recording of the production-relevant records begins with the Batch start signal and ends with the Batch end signal. The records are assigned to a specific batch. The name of the batch can be configured and it can be 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 PM-SERVER application functions as the interface between WinCC flexible and PM-QUALITY. It is contained in the PM-QUALITY program package. An OPC station, in which the tags from the WinCC flexible project are imported, is configured in PM-SERVER for exchanging tags. The PM-SERVER can also import records from multiple HMI devices with different WinCC flexible projects.

Text import stations, which organize the import of the CSV files at the end of the batch, are always created in the PM-SERVER to acquire alarms and audit trail entries. A variety of alarm logs are created in the PM-SERVER. The entries of the CSV files are archived as alarms in these logs.



The tag values read into the PM-SERVER and the configured alarm logs are further processed in the PM-QUALITY application and put together according to the requirements of the batch-based reporting.

Note

You can find detailed descriptions about the configuration in the online help for PM-SERVER and PM-QUALITY.



VB scripts can be inserted into the report layout to release batches per electronic signature. Input boxes are then displayed in the batch report in which the user name, user ID and a comment can be entered.

Either the configurations in PM-SERVER or the Windows user management (when the SIMATIC Logon software is used) can be used to verify the user name, user ID and password.



The Release report button adds the electronic signature to the report data as a snapshot and the status is set from draft to original.



6.9 Backups of System / Application Software In order to be able to fall back on software that has been created, backup copies of the software versions must be made at regular intervals during the configuration phase.

It is also recommended that a backup / image be made of the system partition of the engineering system containing the operating system, SIMATIC WinCC flexible system software, WinCC flexible project, etc.

6.9.1 Backing up application software from the engineering system

Backing up project data in the engineering system When a WinCC flexible project is saved, the records are saved in the project database with the file extension *.hmi. At the same time, the log file, *_log.ldf, associated with the project is generated. These two files should not be separated. Shared moving / copying in the Windows file system is allowed for creating the data backup.

Note The WinCC flexible project must be closed for moving the project data.

Note Projects which are a component part of a SIMATIC STEP 7 project cannot be moved or copied in Windows Explorer in order to ensure data consistency. Instead, the project is handled and saved with the tools of the SIMATIC Manager. The Version Trail software can also be used to back up a SIMATIC STEP 7 project with an integrated WinCC flexible project. Version Trail backs up the project data structured under main and sub version as a compressed file. For more detailed information, refer to the GMP manual for SIMATIC STEP 7.



6.9.2 Backing up the operating system and SIMATIC WinCC flexible The backup of the operating system and the WinCC flexible installation should be made as a hard disk image. Such images can be used to restore the PC to its original status relatively easily (WinCC flexible Engineering System and / or WinCC flexible RT).

Which images are advisable • Create an image of the operating system installation with all drivers and all

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

• Create an image of the installed PC with SIMATIC WinCC flexible, WinCC flexible options and WinCC add-ons

• Create an image of the installed PC with SIMATIC WinCC flexible including all projects

Procedure for creating 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 backup of the application software and the backup of the operating system with and without SIMATIC WinCC flexible should be stored on external media (for example, MOD, CD, DVD, network backup).

! Note An image can only be copied back to a PC with identical hardware. The hardware configuration of the PC should therefore be adequately documented. Images of individual partitions cannot be exchanged between PCs because various settings, for example in the registry, differ from PC to PC.



6.9.3 Backing up the operating system and the application software of an HMI device (panel) The ProSave application is available for backing up the project and operating system data on an HMI device (panel). ProSave is included in the WinCC flexible system software package. The application is integrated in the WinCC flexible engineering system. This allows you to quickly perform commissioning again, for example, after replacing a HMI device.

Backup A backup from the panel to a *.psb file in the specified destination directory is generated with the menu command Project > Transfer > Backup. For detailed information on the backup procedure, refer to the WinCC Information System under Utilities for service and development > ProSave > Data backup.

! Note License keys on the panel are not backed up. The license keys must be saved beforehand using the Automation License Manager application.



6.10 Interfacing to SIMATIC WinCC Both the SIMATIC WinCC system software and the WinCC flexible system software can be used in a distributed system.

A connection for exchanging tag contents between the two systems is established via the OPC DA channel.

6.10.1 Centralized user administration SIMATIC Logon allows user administration to be organized centrally. The SIMATIC Logon server can be installed on the WinCC computer and licensed for the number of connected panels. What information does Section 4.3.2 “Centralized user administration” contain?

6.10.2 Central audit trail for multiple WinCC flexible systems Audit trail logs generated by the individual panels or WinCC flexible RT as circular logs can be transferred to the database of WinCC Alarm Logging with the PM-OPEN IMPORT WinCC add-on. The audit trail is evaluated in terms of operator input alarms that indicate a tag value change and system events. All alarms are entered in WinCC Alarm Logging as operator input alarms with the alarm number of the WinCC default operator input alarm (12508141). The original time stamps are retained. Operator input alarms for value changes are entered in WinCC Alarm Logging with the old and new values.

To allow the CSV files to be imported, a folder is defined on the WinCC server / single workstation system on which PM-OPEN IMPORT is installed for each WinCC flexible system and the audit trail can be moved to this folder either manually or cyclically. PM-OPEN IMPORT monitors the directories using Windows tools. This means that as soon as a directory contains a CSV file, PM-OPEN IMPORT starts to read in the data.

Further information on configuring PM-OPEN IMPORT is available in the online help of the WinCC Premium add-ons.

The WinCC alarm control can integrate the display of audit trail entries in a WinCC screen filtered according to operator input alarms and system events.

The WinCC add-on PM-QUALITY is another alternative with which the audit trail of several panels can be merged. PM-QUALITY acquires the production-relevant process values and alarms batch-oriented. On completion of the batch, data, alarm and audit trail logs generated by WinCC flexible while the batch was running are moved to a network drive either manually or automatically. From there, the data is read into the PM-QUALITY database and is available for evaluation and display.



6.10.3 Central process value archiving and central alarm management

Data and alarm logs generated in WinCC flexible as circular logs in CSV format can be evaluated with the WinCC add-on PM-OPEN IMPORT and transferred to the WinCC logs. Data from the data logs is entered in the WinCC Tag Logging logs and contents of the alarm logs are entered in WinCC Alarm Logging. See also Section 6.10.2 "Central audit trail for multiple WinCC flexible systems"

Further information on configuring PM-OPEN IMPORT is available in the online help of the WinCC Premium add-ons.



6.10.4 Central recipe control and recipe management The WinCC add-on PM-CONTROL is an alternative to the recipes option in WinCC flexible.

PM-CONTROL is a 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 planning and 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 the requirements of the FDA in article 21 CFR Part 11.

Operator input in the recipe system, for example creating, modifying, deleting recipes can be protected from unauthorized access using different authorizations. After they have been created, recipes require an electronic signature before they can be released for production. The recipe data is recorded in an Audit Trail from the point in time at which it is created. Every recipe change is recorded along with 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 of the orders is started, either automatically when requested by the automation level or manually with the required user rights.

PM-CONTROL is installed on a computer with a Windows operating system. This can, for example, be the WinCC flexible computer or a panel PC with a full operating system. The structure of PM-CONTROL allows central recipe data storage and order control for several WinCC flexible systems.

Tags are connected to panels using OPC XML and to WinCC flexible RT using OPC DA. To display recipe data and job management, PM-CONTROL provides ActiveX controls that can be integrated in a process screen in WinCC flexible RT.

Additional information on configuring PM-CONTROL is available in the online help of the WinCC Premium add-ons.



6.11 Interfacing SIMATIC S7 A physical connection is first required for the data communication between WinCC flexible and the automation systems. A communication connection suitable for the hardware being used is created in SIMATIC WinCC flexible under Communication > Connection.

Numerous drivers are listed for selection in the Communication driver column. The SIMATIC S7 300/400 driver is used in the figure above.

The tags are created with Communication > Tags. Internal tags without process connection and external tags with process connection can be configured for an existing connection.

The tags form the data interface between the automation system and WinCC flexible project. All editors configured in WinCC flexible read/write values of the tags.



6.12 WinCC flexible Integrated in STEP 7 As part of the Totally Integrated Automation (TIA) concept, the WinCC flexible project is integrated in a STEP 7 project.

Advantages of the integration:

• Central overview in the tree topology of the SIMATIC Manager

• Central overview in the symbol table of the SIMATIC Manager

• Central connection overview of all participating components via NetPro

Integration procedure You can integrate WinCC flexible in STEP 7 in a variety of ways and means.

Installation sequence

When the STEP 7 basic system is already installed on the system, the "WinCC flexible Engineering System" software package is installed automatically with the support for integration. The "Integration in STEP 7" option must be enabled for a customized installation. With this variant, WinCC flexible is launched from the SIMATIC Manager to configure the operator control and monitoring system.

Subsequent integration

WinCC flexible projects can also be integrated in a STEP 7 project at a later point in time. To do this, select the File > Integrate in STEP 7 menu in WinCC flexible. Existing STEP 7 projects can be selected for integration. When the integration is completed, the WinCC flexible project is processed through the SIMATIC Manager.



Central overview in the tree Screens and objects of the WinCC flexible project are integrated as objects in the tree of the SIMATIC Manager. The tree therefore offers a central overview of the configured objects in the entire automation solution. The WinCC flexible engineering system is automatically opened for handling the WinCC flexible objects.



Central tag management The integration in the STEP 7 basic software provides a decisive advantage in that it allows tags to be centrally created and maintained in the symbol table of the SIMATIC Manager.

Configuration of the tag interface

The following figure shows the symbol editor of the SIMATIC Manager. All external tags, bit memories, local data, data blocks, function blocks, etc. are defined with symbolic names and comments in the symbol editor. The symbol editor is the interface for the tag connection in the WinCC flexible engineering system.

The Tags object is shown under the Communication object for the HMI device in the SIMATIC Manager. Double-clicking on the Tags object in the right-hand window starts the WinCC flexible Engineering System and opens the tag table. The tags for operator control and monitoring are created there. The connection to the symbol table of the SIMATIC Manager is made in the Symbol column. Double-clicking on the Symbol column opens the connection to the SIMATIC Manager. You can navigate to the Symbols table or to the DB data blocks in the tree. The content of the selected block or the symbol table for selecting the address are listed in the right area.



Tags in WinCC flexible assigned to a structure (e.g. Motor) under the data type are mapped to the corresponding data area in a data block. The offset to configured tags is derived from the structure definition. These tags can be linked to a faceplate, for example.

Note

You cannot connect to a structure (instance of a UDT) in a STEP 7 data block.

Individual elements in a structure required as tags in the screens are entered as individual tags in the tag table.



Central communication connection overview All network connections of the STEP 7 project are clearly displayed and can be configured in the NetPro editor, which is opened in the SIMATIC Manager with the menu command Options > Configure Network. This also includes the network connections of the integrated HMI operator stations. The various network types, such as Ethernet, Profibus DP, MPI, etc., are displayed in different colors. Even the configuration of several subnets are supported by NetPro.

NetPro shows the stations and HMI devices with modules and interfaces that are specified in the hardware configuration of the STEP 7 project. The hardware configuration is performed in the HW Config editor.

Note

When a WinCC flexible project is later integrated in a STEP 7 project, the hardware configuration for the HMI device must be checked and may have to be adapted.

More detailed information on the topic of integrating WinCC flexible is documented in the WinCC flexible Information System.



6.13 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, for example, 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 systems to be supplied

• Power of the UPS

• Desired duration of UPS buffering

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

• Programmable controller

• WinCC flexible HMIs

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

In any case, it is important to include the systems for logging records in the buffering. The time at which the power failure occurred should also be recorded.

UPS system on panel The following options are available for connecting a UPS:

• UPS with serial port A UPS with a serial port is connected directly to the HMI device. The serial connection is used with a "SITOP DC-USV Module A" device. The driver for detecting and configuring the UPS is included in WinCC flexible and is installed on the HMI device through ProSave or the WinCC flexible Engineering System with the menu command Project > Transfer > Options (Uninterruptible Power Supply (UPS)).

• UPS without serial port A UPS without a serial port is connected to the PLC. The UPS signals the power failure to the connected PLC with a digital signal. The PLC program must then signal the HMI device that runtime must be terminated. To do this, the PLC changes a tag to which the "Exit runtime" function is configured in WinCC flexible.

• More detailed information is documented in the operating instructions for the panel.



UPS system on panel PC The use of UPS systems is a factor in the software installation. This software is installed and configured on the PC-based computer of the visualization system.

• Configuration of power failure alarms

• Specification of the time to elapse before the PC is shut down

• Specification of the duration of UPS buffering

The automation system must be programmed so that the system is brought to a safe state after a specified buffer time in the event of a 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 in a similar way 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.

Note

Siemens provides SITOP UPS for an uninterruptible power supply. A description of the quality requirement of the UPS can be found in entry ID 17241008. See also (http://support.automation.siemens.com/).




7 Support During Qualification

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

In the schematic below, the markers in the right-hand part indicate the phase of test / qualification of the system.

Test

/ Qu

alifi

catio

n

Specification

Support During Qualification


7.1 Qualification Planning In defining a project life cycle, various test phases are specified. Therefore, basic qualification activities are defined at a very early stage of the project and fleshed out in detail during the subsequent specification phases.

The following details are defined at the outset of the project:

• Parties responsible for planning and performing tests and approving their results

• Scope of tests in relation to the individual test phases

• Test environment (test structure, simulation)

Note

The work involved in testing should reflect not only the results of the risk analysis, but also the complexity of the component to be tested.

The individual tests are planned in detail at the same time as the system specifications (FS, DS) are compiled. The following are defined:

• Procedures for the individual tests

• Test methods, e.g. structural (code review) or functional (black box test)



7.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 should be verified during the subsequent system tests. The design specification describes all hardware used with information such as the serial number, order number, installation location etc. The components of the employed servers and clients, interfaces to third-party systems etc. are listed below.

Qualification of the PC hardware being used If PCs are used as HMI devices, the PC hardware used must be qualified. A check is necessary to ensure that the specifications of the hardware design specification were implemented. The so-called PC passport is useful for the qualification. The PC passport should list all installed hardware and software components.

This includes:

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



Qualification of the panels being used The panels are preconfigured with the MS Windows CE operating system. The panel type and version as well as added memory cards or network adapters need to be inspected for the hardware qualification.

The panel version can be read with Control Panel > OP on the panel.

The network configuration can be displayed with Control Panel > Network.



7.3 Qualification of the Visualization Software

7.3.1 Software categorization according to the GAMP guide According to the GAMP guide, the software components of a system are assigned to one of five software categories for the purpose of validating automated systems. In terms of a computer system, this means that the individual software components require different degrees of effort for specification and testing depending on their software category.

While an computer system as a whole is assigned to category 4 or even 5, the individual standard components to be installed (without configuration) can be considered as belonging to category 3 in terms of effort.

The configuration part based on installed products, libraries, function blocks etc. then corresponds to category 4. If "free code" is then programmed as well, this corresponds to category 5 and involves significantly more effort for specification and testing.

7.3.2 Qualification of standard software During qualification of the standard software used, checks are made to verify whether or not the installed software meets the requirements of the specifications. These checks vary depending on the HMI device. These include:

• Operating system

• SIMATIC WinCC flexible standard software

• Options / Add-ons (editors, standard screens, global symbol library)

Note

Screenshots and printouts from tools such as those described below can be used to verify the qualification (IQ/OQ) and to document that the requirements defined in the specification have been met.



Operating system Panel: (Windows CE operating system and WinCC flexible RT software are installed)

The installed software can be verified by operating system functions. The information can be found in Control Panel > System. The version of the operating system is displayed here.

PC:

• Operating system

• SIMATIC WinCC flexible PC RT software

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

• Standard libraries

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



System programs of SIMATIC WinCC flexible In an environment requiring GMP, documentation must be produced for every PC used as an HMI device describing the installed software packages (operating system, SIMATIC products, additional applications) with version and license. Detailed documentation of the installed SIMATIC software can be found in Programs > SIMATIC > Product notes > Installed software.

Information about the installed software and the products, options, etc., can also be called up from the WinCC flexible Engineering System. To do this, select the menu command Options > Version Management > Installed Software in WinCC flexible.



Installed licenses of SIMATIC WinCC flexible The Automation License Manager program provides information on the licenses installed on the PC (Engineering System, HMI device) and on the panel. To obtain the information, select the menu command Programs > SIMATIC > License Management to open the Automation License Manager. Select the partition in the left area of the Explorer bar to select the licenses for display. The installed licenses are listed in the right area.

A connection must be made to the Automation License Manager to display the licenses on the panel. This can be done either by selecting the menu command Project > Transfer > License Key in the WinCC flexible Engineering System or the menu command Edit > Connect Target System > Connect HMI Device in the Automation License Manager application when it is operated stand-alone.



7.3.3 Qualification of the Application Software During qualification of the application software, checks are necessary to ensure that the requirements of the software design specification were implemented. Test descriptions (for example for FAT/SAT) must be agreed with the user and generated. These test descriptions must be created individually for the software design specifications.

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

• Checking the name of the application software

• Checking the plant hierarchy (process cell, unit, equipment module, single control element, etc.)

• Software module test (typical test)

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

• Checking all inputs and outputs

• Checking all control modules (control-loop level)

• Checking all equipment phases and equipment operations (equipment phases)

• Checking the relationships between modes (MANUAL/AUTOMATIC switchovers, interlocks, start, running, held, aborting, completed, etc.)

• Checking process tag names

• Checking the visualization structure (P&I representation)

• Checking the operator input philosophy (access control, group rights, user rights)

• Checking logging concepts (circular logs, long-term alarm lists)

• Checking the alarm concept

• Checking trends, graphs

• Checking time synchronization



Reports on the application software The entire application software created with the WinCC flexible Engineering System or selected parts of it can be printed out as part of the documentation. This documentation provides support during qualification of the application software.



7.4 Checking the Configuration: Versioning and Archiving Projects

Versioning projects with "ChangeControl" WinCC flexible projects not integrated in STEP 7 are versioned with the versioning function of the ChangeControl option. A project version is a copy of a project at a defined point in time, for example at the beginning of a qualification phase or after a change has been made to the application software. The saved project version contains the entire project engineering. This includes all configured HMI devices, objects and the change log, etc.

Note

The project is always versioned in its entirety. The various HMI devices in the project therefore always have the same project version. To register a separate project version for each HMI device, a project containing exactly one HMI device is created and then saved in the versioning.

A new project version is saved on the trunk when the current version is the highest one on the trunk. A new version is saved on a new branch when the current project version is not the highest one on the trunk or branch.

To create a new project version, the project from which the new version is to be created must be open.

The new version states are stored under the object Version Management > Project Versions.

Note

We recommend only the trunk for versioning with the ChangeControl option to ensure you are always working with the latest version of the project. The comments for the version projects should be as descriptive as possible to help you later assign the version projects to the corresponding automation stations. For example, the comments can contain information about the reason for the logging. It makes sense to increment versions only for specific events or major changes (e.g. FAT, SAT).





7.5 Tracking Configuration Changes The change log is enabled to record changes between two versions of a project. This documents changes to a specific, advanced project phase without gaps, for example, all changes to a project version.

The change log is always activated only for a specific project. All changes to the project configuration data are logged, regardless of the user or the changes made. The name of the user logged on in Windows is recorded. When a new project version is created, the change log is closed and saved with the project version. A new change log is activated for the new project version.

Note

The activated change log places a load on the performance of the system and increases the data volume in the project. You should check whether the change log is actually needed during development or whether it is only required for changes made to an accepted project.

The change log displays configuration changes made in the project. It records who changes specific objects and object properties, the time changes are made and supplements this information with automatic comments.

Double-click Version Management > Change Log in the project window to open the change log.

Note

To open the change log of an older project version, first open the required project version in version management.

You can enable and disable the change log with the menu command Options > Version Management.




8 Operation, Maintenance and Servicing

8.1 Diagnostics of Communication Connections System events supported in WinCC flexible in the diagnostics of communications connections. The HMI device or the PLC triggers a system event if a certain system status or an error occurs in one of the devices or during communication between the devices.

The following system events are generated:

• HMI system events depending on the HMI device type

• System alarms by the PLC

A system event consists of a number and the event text. The event text can also include system tags that specify the cause of the error messages in greater detail. Device-specific HMI system events are listed in the manual of the relevant HMI device.

The system events that can be generated and a description of the possible causes are listed in the WinCC flexible Information System under Working with WinCC flexible > Reference > System alarms.

8.2 Operational Change Control It is essential that all changes made to validated, operational plants are planned in consultation with the plant user, documented, and only performed and tested once they have been approved.

Changes in the WinCC flexible project should not generally be made during ongoing operation.

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

Operation, Maintenance and Servicing


The following sections describe how to make changes to a WinCC project during operation based on examples.

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

6. Back up of the modified WinCC project with versioning

3. Back up of the current WinCC flexible project

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

4. Implementation of software change based on the new version

The Change Control option records changes in the engineering in a change log. Versions of the project software are also managed.

1. Initiation and approval of change specification by plant user



8.3 Restoring the System The procedure described in this section should enable the end user to restore the WinCC flexible system after a disaster.

Disasters are taken to mean the following cases:

• Damage to the operating system or installed programs

• Damage to the system configuration data or configuration data

• Loss or damage to runtime data

The system is restored using the saved data. The backed up data (medium) and all the materials needed for the restoration (basic system, loading software, documentation) must be saved at the defined point. There must be a Disaster Recovery Plan which must be checked on a regular basis.

Restoring the operating system and installed software The operating system and installed software are restored by loading the corresponding images (see Section 6.9 “Backups of System / Application Software"). The instructions provided by the relevant tool manufacturer should be followed.

An image can only be restored on a PC with identical hardware. If a PC with an identical configuration is not available, the installation has to be run again from scratch. The documentation that contains descriptions of the installed software and the updates, upgrades and hot fixes also installed, can be used to qualify the software. Adhere to the installation sequence described in section 1.

Restoring application software with WinCC flexible PC Runtime How application software is restored on the PC / panel PC depends on the available backup.

• Retrieving data using the Version Trail software (STEP 7 project) Version Trail lists all backup statuses with major and minor version and time stamp. To retrieve the data, the corresponding backup status is selected and the action started using the De-archive button.

• Retrieving via the Software “ProSave”, in case the backup was created this way

• Retrieving data from a manually created backup version Manually backed up WinCC flexible application software is copied back, see Section 6.9.1 "Backing up application software from the engineering system"



Restoring the runtime data Runtime data such as the content of the circular buffers of tags and alarm logs not yet transferred to a network drive may be lost if a disaster occurs. The extent of the data loss can be minimized by transferring the data regularly to archives.

Restoring the application software for a panel A panel is completely reloaded by restoring the operating system and project data. A restore is transferred to the panel with the menu command Project > Transfer > Restore.

Note All existing records on the panel are deleted, including any existing license keys.

Note For Windows CE devices, a backup/restore can be performed by backing up the data directly from the device to an external storage medium, such as a CF card. For additional information, refer to the appropriate device manuals.


9 System Updates and Migration

9.1 Updates, Service Packs and Hotfixes It is essential that system software updates for a validated, operational plant are agreed with the user. An update such as this represents a system change, which must be planned and executed in accordance with the applicable change procedure. Similar to the description found in Section 8.2, this roughly translates to the following steps:

• Describe the planned change

• Effects on functions / plant units / documentation inclusion of the system description of the new and modified functions in the readme file/release notes

• Assess risks

• Define the tests which need to be performed to obtain validated status, based on the risk assessment

• Approve/reject the change (in accordance with defined responsibilities)

• Update technical documentation

• Execute the change in accordance with manufacturer documentation (as the plant has been released for it)

• Document the activities performed

• Qualification: Carry out and document the necessary tests

In considering possible influences, the following may be relevant:

• Process screens / objects / alarm system and process value logging in function and display

• Interfaces

• Effects during download

• System performance

• Documentation (specifications)

• Qualification tests to be repeated or performed for the first time

Note

The SIMATIC Customer Support at http://support.automation.siemens.com provides support for software updates and project migration.


System Updates and Migration


9.2 Migration of the Application Software Due to obsolete system components that are no longer supported, the topic of migration is becoming more and more important. In this context, migration means the change to a later technical generation or a change of system to another technical basis.

Migration often means changing from another system to SIMATIC. Even when changing to a higher version within the WinCC flexible system software, it may be necessary to migrate or convert the data of the project created with an earlier version.

Note

The situations in which migration or conversion of the project data becomes necessary are described in the WinCC flexible Information System of the new WinCC flexible version in the section Readme > Migration.

The validation effort is decided in consultation with the plant operator. When migrating internally within SIMATIC, possible checkpoints are mainly the activities required for migration of the project data and the new functions available in WinCC flexible.

A customized migration strategy is designed, taking the necessary qualification measures into account and based on the relevant general conditions, such as the basis which is already installed and on which the migration is to take place, defined plant stoppages (usually as brief as possible), etc.

Guidelines for Implementing Automation Projects in a GMP Environment A5E02147610-01 Index-1

Index

A Access security ............................................... 75 Access security ................................... 23, 45, 52 Access security ............................................... 90 Account Lockout Policies ................................ 55 Alarm logs....................................................... 87 Application software backup ................... 31, 104 Archiving ................................................. 28, 131 Audit trail ............................................. 27, 39, 77 Audit trail - setting up ...................................... 77

B Backing up - operating system and SIMATIC

WinCC flexible .......................................... 105 Backing up logs............................................... 89 Backing up process data................................. 33 Backup............................................................ 31 Batch data....................................................... 29 Batch documentation ...................................... 29 Biometric systems........................................... 24

C Change control.......................... 21, 39, 133, 135 Configuration control....................................... 21 Configuration identification.............................. 21 Configuration Management..................... 20, 131 Creating process screens ............................... 72 Creating scripts ............................................... 76

D Data logging.................................................... 40 Data logs......................................................... 86 Design Specification ....................................... 14

E Electronic signature ........................................ 25 Engineering..................................................... 39 EU GMP Guide ......................................... 16, 17

F Faceplates in conjunction with structure tags . 73 FAT ................................................................. 14 FDA................................................................. 16

FDA 21 CFR Part 11 .......................................16 Functional Specification...................................13

G GAMP........................................................16, 17 GAMP Good Practice Guide............................17 GMP requirements ..........................................19 Graphics ..........................................................72

H Hardware categorization..................................19

I Interfacing SIMATIC S7.................................111 Interfacing to higher-level IT systems..............40

L Life cycle model...............................................11 Local data logging ...........................................89 Logon monitoring.............................................55

M Maintenance..................................................135 Manufacturing log............................................29 Migration........................................................140 Multilingual projects.........................................60

N NAMUR ...........................................................17 NotifyUserAction system function....................79

P Panel PCs .......................................................43 Panels .............................................................43 Password...................................................24, 26 Password Policies ...........................................54 PM-Quality.................................................93, 99 Printer driver....................................................42 Project Manager ..............................................59 Project settings................................................59

Index

Guidelines for Implementing Automation Projects in a GMP Environment Index-2 A5E02147610-01

Q Qualification .................................................... 15 Qualification of the visualization hardware.... 123 Qualification of the visualization software ..... 125 Qualification plan ............................................ 12 Qualification report.......................................... 15 Quality and project plan ............................ 13, 18

R Recipe configuration ....................................... 80 Recipe management....................................... 39 Recipe screen................................................. 85 Recipe view .................................................... 84 Reporting .................................................. 29, 40 Retrieving archived data ................................. 33 Runtime software ............................................ 39

S SAT................................................................. 14 Screen navigation ........................................... 72 Security Settings ................................. 49, 51, 54 Setting up data and alarm logs ....................... 86 SIMATIC NET ................................................. 60 Smart card ...................................................... 24

Software categorization ...........................20, 125 Specification ..............................................13, 35 Symbol library, project library, global library ....72 System creation...............................................14

T Third-party components...................................34 Time synchronization.................................27, 61 Typicals ...........................................................22

U Uninterruptible power supply .........................117 Updates, service packs, hotfixes ...................139 User administration ...................................23, 45 User groups.....................................................46 User ID ......................................................24, 26 User Requirements Specification ....................13

V Validation plan.................................................12 Validation report ..............................................15 Versioning .................................................21, 39 Versioning - Project .......................................131

A5E02147610D-01 GN: 63003_SXXN2139_WinCCflex

GMP Engineering Manual Edition 04/2008

SIMATIC WinCC flexible 2007Guidelines for Implementing

Automation Projectsin a GMP Environment

SIM

ATI

C W

inC

C fl

ex

ible

20

07

04

/20

08

GM

P En

gin

eeri

ng

Man

ual

Siemens AktiengesellschaftAutomation and DrivesCompetence Center Pharmaceuticals76181 KARLSRUHEGERMANY [email protected]/simatic-wincc-flexible

simatic hmi

A5E02147610-01

Documents

GMP Engineering Manual - English · Guidelines for Implementing Automation Projects in a GMP Environment A5E02147610-01 3 Introduction Purpose of this manual This manual describes