± ± ± ± ± ± ± ± ± ± ± ± ± ñ ± ± ƒ

Transcription

1 ± ± ± ± ± ± ± ± ± ± ± ± ± Ò ± ± ƒ

2 Introduction Configuring in a GMP Environment 1 Requirements for Computer Systems in a GMP Environment 2 SIMATIC PCS 7 V8.1 GMP Engineering Manual Guidelines for Implementing Automation Projects in a GMP Environment System Specification 3 System Installation and Configuration 4 Project Settings and Definitions 5 Creating Application Software 6 Support for Verification 7 Data Backup 8 Operation, Maintenance and Servicing 9 System Updates and Migration 10 Abbreviations Index List 09/2015 A5E AA

3 Legal information Warning notice system 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 only to property damage have no safety alert symbol. These 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 indicates that minor personal injury can result if proper precautions are not taken. NOTICE indicates that property damage can result if proper precautions are not taken. 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 product/system described in this documentation may be operated only by personnel qualified for the specific task in accordance with the relevant documentation, in particular its warning notices and safety instructions. Qualified personnel are those who, based on their training and experience, are capable of identifying risks and avoiding potential hazards when working with these products/systems. Proper use of Siemens products the following: WARNING Trademarks Siemens products may only be used for the applications described in the catalog and in the relevant technical documentation. If products and components from other manufacturers are used, these must be recommended or approved by Siemens. Proper transport, storage, installation, assembly, commissioning, operation and maintenance are required to ensure that the products operate safely and without any problems. The permissible ambient conditions must be complied with. The information in the relevant documentation must be observed. All names identified by are registered trademarks of 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. Siemens AG Division Process Industries and Drives Postfach Nürnberg GERMANY A5E AA 09/2015 Subject to change Copyright Siemens AG All rights reserved

4 Introduction Introduction Purpose of the manual This manual contains instructions for system users and configuring engineers for integrating SIMATIC systems into the GMP environment (GMP = Good Manufacturing Practice). It covers validation and takes into account special requirements of international regulatory bodies and organizations, such as 21 CFR Part 11 of the FDA or EU GMP Guidelines Annex 11. In the first chapters, this manual describes what is required from the pharmaceutical, regulatory viewpoint (in short: GMP environment), of the computer system, the software and the procedure for configuring such a system. In the following chapters, practical examples are used to explain the relationship between requirements and implementation. To suggest improvements to this document, please use the contact details provided at the back of this manual. Target groups This manual is intended for all plant operators, those responsible for system designs for specific industries, project managers and programmers, servicing and maintenance personnel who use the automation and process control technology in the GMP environment. Basic knowledge required Basic knowledge of SIMATIC PCS 7 is required to understand this manual. Knowledge of GMP as practiced in the pharmaceutical industry is also an advantage. Validity of the manual The information in this manual applies to SIMATIC PCS 7 V8.1. The components examined are the PCS 7 ES, PCS 7 OS, and SIMATIC BATCH. Refer to the product catalog or compatibility tool for detailed information on the compatibility of the individual components. Product Catalog CA 01: Compatibility tool: Any questions about the compatibility of the add-on products for SIMATIC PCS 7 should be addressed directly to the suppliers. Industry Mall catalog and ordering system Add-ons for SIMATIC PCS 7 A5E AA 3

5 Introduction Position in the information landscape The system documentation of the SIMATIC PCS 7 process control system is an integral part of the SIMATIC PCS 7 system software. It is available to every user as online help (HTML help) or as electronic documentation in PDF format. This manual supplements the existing SIMATIC PCS 7 manuals. It is not only useful during configuration; it also provides an overview of the requirements for configuration and what is expected of computer systems in a GMP environment. Structure of this manual The regulations and guidelines, recommendations and mandatory specifications are explained. These provide the basis for configuration of computer systems. All the necessary functions and requirements for hardware and software components are also described; this should make the selection of components easier. Based on examples, the use of the hardware and software is explained and how they are configured or programmed to meet the requirements. More detailed explanations can be found in the standard documentation. Training center Siemens offers a number of training courses to familiarize you with SIMATIC PCS 7. Please contact your regional training center, or the central training center in D Nuremberg, Germany. Internet: Siemens on the Internet You will find a guide to the technical documentation offered for the individual SIMATIC Products and Systems here at: SIMATIC PCS 7 V8.1 technical documentation The online catalog and online ordering system are available at: You can find additional information about the products, systems, and services from Siemens for the pharmaceutical industry at: 4 A5E AA

6 Introduction Technical support on the Internet You can find comprehensive information on our Service and Support at: The product support offered there includes: Technical specifications and information on the product status FAQs and application examples You will also find on this page: Application examples Comprehensive overview of services, e.g. information about on-site service, repairs, spare parts, and much more A bulletin board in which users and specialists worldwide exchange their knowhow mysupport for personal filters, notifications, support requests, among other things, our newsletter containing up-to-date information on your products. Additional support Contact your Siemens partner at your local office or agencies if you have any questions relating to the product and do not find the right answers in this manual. Find your personal Siemens contact person at: If you have questions on this manual, please contact: pharma@siemens.com A5E AA 5

7 Table of Contents Table of Contents Introduction... 3 Table of Contents Configuring in a GMP Environment Regulations and guidelines Life cycle model Responsibilities Approval and change procedure Risk-based approach Requirements for Computer Systems in a GMP Environment Categorization of hardware and software Test effort depending on the categorization Change and configuration management Software creation Access control and user administration Applying access control to a system Requirements for user IDs and passwords Requirements for electronic records Electronic signatures Audit trail Reporting batch data Archiving data Data backup Retrieving archived data Time synchronization Use of third-party components System Specification Selection and specification of the hardware Hardware specification Selecting the hardware components CPU 410-5H for process automation Hardware solutions for special automation tasks Security of the plant network Specification of the basic software Operating system Basic software user administration Software components for engineering Software components for operation level A5E AA

8 Table of Contents SIMATIC BATCH basics and options Long-term archiving Reporting Application software specification Additional software SIMATIC PCS 7 Add-ons versiondog Version assignment and configuration control OPD User dialogs and electronic signatures Utilities and drivers Printer drivers Virus scanners Image & partition tools System Installation and Configuration Installation of the operating system Installation of SIMATIC PCS Setting up user administration User administration on the operating system level Security settings in Windows SIMATIC user groups Configuration of SIMATIC Logon Administration of user rights Administration of user rights on the Engineering System (ES) Administration of user rights on the Operation System (OS) Administration of user rights in SIMATIC BATCH Access control to operating system level Configuration settings in Windows Configuration setting on SIMATIC PCS 7 OS Secure configuration Data and information security SIMATIC Security Control (SSC) SCALANCE S Project Settings and Definitions Project setup Multiproject Multi-user engineering Referenced OS stations Using the master data library Synchronizing shared declarations Synchronizing SFC types Synchronizing the plant hierarchy SIMATIC NET Configuring SIMATIC NET Plant bus and terminal bus PROFIBUS Foundation Fieldbus (FF) PROFINET SIMATIC PDM OS Project Editor Time synchronization Configuration management A5E AA 7

9 Table of Contents 5.8 Versioning of software elements Versioning of AS elements in PCS Versioning of OS elements in PCS Additional information on versioning Creating Application Software Software modules, types, and copy templates Modules and types in PCS Example of a process tag type Automatic generation of block icons Type Change in RUN (TCiR) Bulk engineering Bulk engineering with the process object view Bulk engineering with the IEA Type/instance concept with the Advanced ES Creating process pictures User-specific blocks and scripts Interfaces to PCS PCS 7 OS Web option OS Client in a virtual environment Open PCS SIMATIC BATCH API Recipe control with SIMATIC BATCH Batch definition of terminology Conformity with the ISA standard Configuring SIMATIC BATCH Functions and settings in SIMATIC BATCH Messages in SIMATIC BATCH Creating batch reports SIMATIC Route Control Alarm management Specification Message classes Priorities Suppressing, filtering, hiding Monitoring PCS 7 components Lifebeat Monitoring Monitoring PCS 7 components SMMC Monitoring connected systems Audit trail and change control PCS 7 ES PCS 7 OS SIMATIC BATCH Configuration for electronic signatures Electronic signature in SIMATIC BATCH Electronic signatures on PCS 7 OS Electronic signature on PCS 7 ES Recording and archiving data electronically Determining the data to be archived Setting up process value archives Archiving batch data Long-term archiving on a central archive server Uninterruptible power supply (UPS) Configuration of a UPS A5E AA

10 Table of Contents UPS configuration via digital inputs MASTERGUARD UPS systems Support for Verification Test planning Verification of hardware Verification of software Software categorization according to GAMP Guide Verification of the application software Simulation for test mode Configuration control Versioning of projects with Version Trail Recipe comparison Version comparison with Version Cross Manager (VXM) Configuration control with "versiondog" Write protection for CFCs/SFCs and SFC types Block encryption with "S7 Block Privacy" Data Backup Backup of system installation Data backup for application software Operation, Maintenance and Servicing Operation and monitoring Process visualization Asset Management Operational change control Remote maintenance System restoration System Updates and Migration General procedure Updating the system software Migration of application software Validation effort for migration Abbreviations Index List A5E AA 9

11 Configuring in a GMP Environment 1 Configuring in a GMP Environment As a prerequisite for configuring computer systems in the GMP environment, approved specifications must be available. Requirements contained in standards, recommendations, and guidelines must be followed when creating these specifications and when implementing and operating computer systems. This chapter deals with the most important sets of regulations and explains some of the basic ideas. 1.1 Regulations and guidelines The regulations, guidelines and recommendations of various national and international authorities and organizations have to be observed when configuring computer systems requiring validation in the GMP environment. Regarding computer systems, the following are of particular significance: Title (author) 21 CFR Part 11 (U.S. Food and Drug Administration, FDA) Annex 11 of the EU GMP Guidelines (European Commission) GAMP5 (ISPE) Subtitle Electronic Records, Electronic Signatures Computerised systems A Risk-Based Approach to Compliant GxP Computerized Systems Area of application Law/regulation for manufacturers and importers of pharmaceutical products for the U.S. market Binding directive within the European Union for implementation in relevant national legislation Guideline with worldwide validity as recommendation 1.2 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 known as the risk-based approach that meets the relevant requirements. GAMP5 approach The following figure shows the general approach of GAMP5 for the development of computerized systems. It begins with the planning phase of a project and ends with the start of pharmaceutical production following completion of the tests and reports. 10 A5E AA

12 Configuring in a GMP Environment The lifecycle approach illustrated here is known as a generic model in GAMP5. With this as the basis, we will introduce several examples of lifecycle models for a variety of "critical" systems with different stages of specification and verification phases. Once production has started, the system life cycle continues until decommissioning. Siemens Validation Manual Siemens has produced a "Validation Manual" based on the recommendations of the GAMP Guide. This provides internal project teams with general information and concrete (document) templates to help specify the validation strategy for a project. There are templates not only for project planning documents but also for system specification and test documentation. In contrast to this GMP Engineering Manual, the Siemens Validation Manual is intended for internal Siemens use only. 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. As this definition is usually laid down specific to a customer and project, and requires a contractual agreement, it is recommended to integrate the definition in the Quality and Project Plan (QPP). See also GAMP5 Guide, Appendix M6 "Supplier Quality and Project Planning" A5E AA 11

13 Configuring in a GMP Environment 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 maintain the validated status, which means ensuring the traceability of the steps undertaken. Before setting up or modifying a system, it is therefore necessary to plan, document and obtain the customer's or plant operator's approval of the pending steps in terms of functionality and time. 1.5 Risk-based approach Both the U.S. FDA ("Pharmaceutical cgmps for the 21st Century Initiative", 2004) and the industry association ISPE/GAMP ("GAMP5" Guide, 2008) recommend a risk-based approach to the validation of systems. This means that the question as to whether or not and to what extent a system should be validated depends on its complexity and its influence on the product quality. 12 A5E AA

14 Requirements for Computer Systems in a GMP Environment 2 Requirements for Computer Systems in a GMP Environment This chapter describes the essential requirements an automated system in the GMP environment must meet regarding the use of computerized systems. These requirements must be defined in the specification and implemented during configuration. In case of subsequent changes or interventions in the system, reliable evidence must be provided at all times, regarding who, at what time, and what was changed or implemented. The requirements for this task are implemented in various functions and described in the following chapters. This chapter describes the general requirements for computerized systems. How to meet these requirements with a specific system is dealt with starting from chapter Categorization of hardware and software Hardware (HW) categorization According to the GAMP Guide, hardware components of a system fall into two categories "standard hardware components" (category 1) and "custom built hardware components" (category 2). Software (SW) categorization According to the GAMP Guide, the software components of a system are divided into various software categories. These range from commercially available and preconfigured "standard" software products that are merely installed to configured software products and customized applications ("programmed software"). 2.2 Test effort depending on the categorization The effort involved in validation (specification and testing) is much greater when using configured and, in particular, customized products compared to the effort for standard products (hardware and/or software). The overall effort for validation can therefore be significantly reduced by extensive use of standard products. 2.3 Change and configuration management All the controlled elements of a system should be identified by name and version and any changes made to them should be checked. The transition from the project phase to the operational procedure should be decided in good time. A5E AA 13

15 Requirements for Computer Systems in a GMP Environment The procedure includes, for example: Identification of the elements affected Identification of the elements by name and version number Change control Control of the configuration (storage, release, etc.) Periodic checks of the configuration See also GAMP5 Guide, Appendix M8 "Project Change and Configuration Management" 2.4 Software creation Certain guidelines must be followed during software creation and documented in the Quality and Project Plan (in the sense of Good Engineering Practice, in short GEP concept). Guidelines for software creation can be found in the GAMP Guide and in relevant standards and recommendations. Use of type/instance concepts and copy templates While the validation of standard software only calls for the software name and version to be checked, customized software validation requires the entire range of functions to be checked and a potential supplier audit to be performed. Therefore, to keep validation work to a minimum, preference should be given to standardized blocks during configuration (products, in-house standards, project standards). From these, customized types and templates are created and tested according to the design specifications. Identification of software modules/types/copy templates During software creation, the individual software modules must be assigned a unique name, a version, and a brief description of the module. Changes to software modules/ types/copy templates Changes to software modules should be appropriately documented. Apart from incrementing the version identifier, the date and the name of the person performing the change should be recorded, when applicable with a reference to the corresponding change request/order. 2.5 Access control and user administration To ensure the security of computer systems in the GMP environment, such systems must be equipped with an access-control system. In addition to physical access control to certain areas, access-control systems protect systems against unauthorized logical access. Users are assembled into groups, which are then used to manage user permissions. Individual users can be granted access authorization in various ways: 14 A5E AA

16 Requirements for Computer Systems in a GMP Environment Combination of unique user ID and password, see also chapter Requirements for user IDs and passwords" Smart cards together with a password Evaluation of biometrics, e.g. fingerprint scanners Applying access control to a system In general, actions that can be performed on a computer system must be protected against unauthorized access. Depending on a user's particular field of activity, a user can be assigned various permissions. Access to user administration should only be given to the system owner or to a very limited number of employees. Furthermore, it is absolutely essential that unauthorized access to electronically recorded data is prevented. The use of an automatic logout function is advisable and provides additional access protection. This does not, however, absolve the user from the general responsibility of logging off when leaving the system. The automatic logout time should be agreed with the user and defined in the specification. Only authorized persons must be able to access PCs and the system. This can be supported by appropriate measures such as mechanical locks and through the use of hardware and software for remote access Requirements for user IDs and passwords User ID: The user ID for a system must be of a minimum length defined by the customer and be unique within the system. Password: When defining passwords, a minimum number of characters and the expiry period of the password should be defined. In general, a password should comprise a combination of characters that meet the minimum length requirement as well as at least three of the criteria listed below. Use of uppercase letters Use of lowercase letters Use of numerals (0-9) Use of special characters See also Chapter 4.3 "Setting up user administration" A5E AA 15

17 Requirements for Computer Systems in a GMP Environment 2.6 Requirements for electronic records The following requirements additionally apply to the use of electronic records for relevant data: The system must be validated. Only authorized persons must be able to enter or change data (access control). Changes to data or deletions must be recorded (audit trail). Electronic records that are relevant for long-term archiving must be stored securely and kept available for their retention period.. 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. If an electronic manufacturing report 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 report can also be combined in one document. See also EU GMP Guidelines, chapter 4.9 and Annex CFR Part 11 "Electronic Records, Electronic Signatures", U.S. FDA 2.7 Electronic signatures Electronic signatures are computer-generated information, which acts as legally binding equivalent to handwritten signatures. Regulations concerning the use of electronic signatures are defined, for example, in 21 CFR Part 11 of the US FDA or in EU GMP Guidelines Annex 11. Electronic signatures are relevant in practice, for example, for manual data inputs and operator interventions during runtime, approval of process actions and data reports, and changes to recipes. Each electronic signature must be uniquely assigned to one person and must not be used by any other person. During the production of drugs and medical devices, which enter the U.S. market, the FDA regulations must be met; this also refers to 21 CFR Part 11 with respect to electronic signatures. 16 A5E AA

18 Requirements for Computer Systems in a GMP Environment Conventional electronic signatures If electronic signatures are used that are not based on biometrics, they must be created so that persons executing signatures must identify themselves using at least two identifying components. This also applies in all cases in which a smart card replaces one of the two identification components. These identifying components can, for example, consist of a user ID and a password. The identification components must be assigned uniquely and must only be used by the actual owner of the signature. 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. Biometric characteristics include fingerprints, iris structure, etc. 2.8 Audit trail The audit trail is a control mechanism of the system that allows all data entered or modified to be traced back to the original data. A secure audit trail is particularly important when GMP-relevant electronic records are created, modified or deleted. Such an audit trail must document all the changes or actions made along with the date and time. The typical content of an audit trail describes who changed what and when (old value / new value), as an option it may also include "why". 2.9 Reporting batch data The batch documentation is of particular importance in the production of pharmaceuticals and medical devices. For pharmaceutical manufacturers, the properly created batch documentation often represents the only documented evidence within the framework of product liability. The components of the batch documentation are as follows: Master production record and batch production record Packaging instructions and packaging record (the packaging of the finished drug is part of the manufacturing process from the pharmaceutical perspective) Test instructions and test report (for all quality checks, for example, in the chemical analysis) Central importance is assigned to the concept of the batch production record or packaging record, which is defined as follows: The batch production record is always related to a product and batch, always based on the corresponding parts of the applicable master production record, and contains all process-relevant measurement and control processes as actual values and deviations from the specified set points. A5E AA 17

19 Requirements for Computer Systems in a GMP Environment 2.10 Archiving data (Electronic) archiving means the permanent storage of electronic data and records in a long-term storage medium. The customer is responsible for defining the procedures and controls relating to the storage and retention of electronic data. Based on predicate rules (EU GMP Guidelines, 21 CFR Part 210/211, etc.), the customer must decide how electronic data is stored and, in particular, which data is affected by this. This decision should be based on a reasonable and documented risk assessment, which also considers the significance of the electronic records over the retention period. If the archived data are migrated or converted, the integrity of the data must be assured over the entire conversion process. See also GAMP5 Guide, Appendix O9 "Backup and restore" 2.11 Data backup In contrast to the archiving of electronic data, data backups are used to create backup copies, which ensure system restoration in case of original data loss or system failure. The backup procedure must include periodic backup of non-retentive information in order to avoid total loss of data due to system components failure or data being deleted by mistake. Backup procedures must be tested to ensure that data is saved correctly. Backup records should be labeled clearly and intelligibly and dated. Data backups are created on external data carriers. The data media used should comply with the recommendations of the device manufacturer. When backing up electronic data, the following distinctions are made Backup of the installation, for example partition image Backup of the application Backup of archive data, for example process data 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). See also GAMP5 Guide, Appendix O9 "Backup and restore" 18 A5E AA

20 Requirements for Computer Systems in a GMP Environment 2.12 Retrieving archived data It must be ensured that archived/backed up data can be read back at any time. If a system update/migration is to be performed, compatibility of the data archived/backed-up before the update must be ensured. If required, the archive data must also be migrated. See also GAMP5 Guide, Appendix O13 "Archiving and recovery" GAMP5 Guide, Appendix D7 "Data migration" 2.13 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 analysis of faults. UTC (Universal Time Coordinated, see also ISO 8601) is recommended as the time base for saving data. The time stamp of messages and values can be displayed in local time with a note indicating daylight saving time / standard time Use of third-party components When third-party components (hardware and software) are used, their compatibility to other components in use must be verified. If components specifically "tailored" (customized) to individual projects are used, a supplier audit should be considered in order to check the supplier and its quality management system. See also GAMP5 Guide, Appendix M2 "Supplier Assessment" A5E AA 19

21 System Specification 3 System Specification During the specification phase for a computer system, the system to be built and its functionality are defined in as much detail as is required for implementation. Specifications not only represent the basis for a structured and traceable configuration but are particularly in the GMP environment an essential reference for final verification of the system. The specification covers the selection of products, product variants, options, and system configurations, as well as the application software. The overall system specification can be divided, for example, into: Functional specification (FS) in response to user requirement specifications (URS) System specification general (DCS design, general topics) Hardware (and network) design specification (HDS) Software design specification (SDS) HMI design specification A very good overview of the PCS 7 Portfolio as well as for optimized processing of projects from planning, to implementation and the test, through to handover to the customer is also offered by: "Fast Track Engineering" multimedia demonstration system Online support under Entry ID A5E AA

22 System Specification 3.1 Selection and specification of the hardware Various system designs are used for the automation as well as the operation and monitoring of simple and complex production processes and manufacturing operations. The selection of hardware components should be measured against the requirements. These requirements may be functional, but also include aspects such as local conditions, compatible software or data security Hardware specification The Hardware Design Specification (acronym: HDS) describes the hardware architecture and configuration including the networks. The HDS should, for example define the points listed below. This specification is used later as a test basis for the verification. Hardware overview diagram, system structure and organization Control cabinets (control cabinet names, UPS configuration, location), PC station control cabinets, automation system with CPUs, I/O cards, etc. PC components for server and client Installation procedures and instructions for servers, clients, ES Appropriate subdivision of plant and plant unit areas for the AS Network structure for Industrial Ethernet, e.g. switches, transmission technology (electrical, optical, wireless), names and Ethernet configuration of the stations (AS, PC stations, etc.), general network settings Profibus installation, division of networks for the automation systems, and specific Profibus settings Time synchronization for hardware (SICLOCK) Barcode scanner configuration Field devices The HDS can be an integral part of an overall specification document or be extracted into a separate document. The information in the hardware overview diagram and the naming of hardware components must be unequivocal. See also GAMP5 Guide, Appendix D3 "Configuration and Design" Selecting the hardware components Use of hardware components from the PCS 7 catalog ensures the long-term availability of hardware and spare parts. For reasons of system availability and data security/integrity, appropriate class RAID systems for PC components, such as ES, OS single stations, OS servers and BATCH servers should be implemented in the system design. When a SIMATIC PCS 7 bundle is supplied, the customer receives a PC on which all software required for the relevant applications is installed. The components contained in the bundle are not always identical to the products of the same names A5E AA 21

23 System Specification available on the market. As a consequence, the availability of spare parts will differ too. Also in virtual systems you should prefer well-proven system components, such as ESXi server. Only hardware from the current PCS 7 catalog should be used. The use of unreleased configurations requires additional effort for specification and test phase. See If PCs are placed in control cabinets, make sure that suitable hardware components are provided, such as operator channel extensions. There are different types of automation systems. Standard automation system Fault-tolerant automation system The user programs loaded in both CPUs are fully identical and are run synchronously by both CPUs. The switchover has no effect on the ongoing process because it is bumpless. Fail-safe automation system It automatically brings the plant to a safe state in the event of a fault. The relevant national regulations must be observed when configuring, commissioning, and operating fail-safe systems. S7 F-systems provide a reference sum of the fail-safe program section available. This sum is recorded to enable the detection of changes in the fail-safe program. See also Manual "PCS 7 PC Configuration" Online support under Entry ID CPU 410-5H for process automation The "CPU 410-5H Process Automation" is specifically designed for the SIMATIC PCS 7 control system. As with previous controllers of the SIMATIC PCS 7 system, the CPU 410-5H Process Automation can be used in all process automation industries. The very flexible scalability based on PCS 7 process objects makes it possible to cover the entire performance range from the smallest to the largest controller, in standard, fault-tolerant and fail-safe applications with only one hardware. This yields the following benefits: Reduced number of CPU versions, no memory cards Resulting in fewer spare parts Easy system and functionality extension Flexible area of application, increased ruggedness See also "PCS 7 CPU 410-5H Process Automation" system manual Online support under Entry ID A5E AA

24 System Specification Hardware solutions for special automation tasks Additional device-specific solutions are required to integrate hardware components which are not offered in the SIMATIC hardware manager. These components are interfaced using special device master data. Integration examples for such hardware components include: Integration of weighing modules (SIWAREX) Integration of frequency inverters for drives (Masterdrives, Micromaster) Integration of user-specific field devices To keep validation work to a minimum, hardware components from the PCS 7 Addon catalog (ST PCS 7 AO) should be given preference. 3.2 Security of the plant network In the field of modern process control systems, the boundaries between the office and automation environments are disappearing at an ever increasing rate. Automation solutions with connected WEB clients, MES applications, and customized office networks and applications are growing in importance. To satisfy these demands and ensure as high a level of data security as possible, the planning and structure of networked PCS 7 automation solutions are highly important. Measures for increasing data and plant security SIMATIC offers several options for increasing data and information security and, thus, the security of a production plant. These include: Staggered user, group, and role concept Safety concepts for network security and limited access to network drives SIMATIC Security Control (SSC) SCALANCE S firewall and VPN modules For additional information, see also Chapter 4.6 "Data and information security" Online support under Entry ID "Security Concept PCS 7 and WinCC", Online support under Entry ID Manual "PCS 7 Engineering Compendium Part F - Industrial Security", Online support under Entry ID A5E AA 23

25 System Specification 3.3 Specification of the basic software The Software Design Specification (SDS) describes the software s architecture and configuration. This describes not only the application software but also the "standard" software components used in the system, for example by specifying the name, version number etc. This description serves as a reference when performing subsequent tests (FAT, SAT, etc.). Commercially available standard software components include automation software components and software provided by third parties, see also chapter 7.3 "Verification of software". Hardware and software requirements and operating system selection Information on compatibility, Online support under Entry ID Compatibility tool PCS 7 Toolset DVD, Readme file Manual "PCS 7 PC Configuration" Online support under Entry ID Operating system Information is included regarding the release of SIMATIC products with various operating systems (32-bit and 64-bit) in the CA01 product catalog in the compatibility tool in the online help, readme file The security updates provided by Microsoft and "Important Updates" for the Windows operating system are tested by Siemens for compatibility with SIMATIC software and released, see note under chapter 10.2 "Updating the system software" Basic software user administration An essential requirement in particular in the GMP field is the access control to the system; which is the only way of ensuring secure operation in compliance with regulations (21 CFR Part 11 and EU GMP Guidelines Annex 11). Unauthorized access to both the operating and monitoring system as well as the file system and the folder structures in the operating system must be avoided. Appropriate planning is required with this in mind: Definition of user groups with various authorization levels for operation and maintenance Definition of users and assignment to user groups Determination of adjusted plant structure and drive storage including authorizations Access to the SIMATIC PCS 7 system components is controlled by SIMATIC Logon. More information on the installation and configuration of the different SIMATIC Logon components can be found in chapter 4.3 "Setting up user administration" and "Configuration Manual SIMATIC Logon". 24 A5E AA

26 System Specification Software components for engineering Some of the most important functions of the SIMATIC PCS 7 engineering software are described below. See also Manual "PCS 7 Engineering System (V8.1)", chapter 8.7, Online support under Entry ID Multiproject engineering For a description of setting up and using multiprojects, see chapter 5.1 "Project setup" of this manual. Process Control Libraries The process control libraries contain ready-made, tested objects (blocks, faceplates, and symbols). When these libraries are used, engineering is usually limited to the configuration of the relevant objects. One major advantage of using predefined objects when engineering automated systems is the lower-level software categorization (see chapter "Software categorization according to GAMP Guide") and the possibility of implementing updates. Therefore, the validation work required is less than that for user-specific blocks. WinCC Configuration Studio The WinCC Configuration Studio provides a simple means of configuring bulk data for OS projects. The user interface is split into a navigation area and a data area oriented on Microsoft Excel. The WinCC Configuration Studio includes the following editors and functions: Tag Management Alarm Logging Tag Logging Text Library User Administrator Horn CFC (Continuous Function Chart) The CFC Editor provides a graphic interface for configuring automation and control functions. Drag & drop is used to move function blocks from libraries to a CFC chart, where they are interconnected and configured in accordance with requirements. SFC (Sequential Function Chart) The SFC Editor facilitates the graphic configuration and commissioning of sequential controls. Essential components here are steps and transitions, as well as simultaneous and alternative branches. A5E AA 25

27 System Specification Import/Export Assistant (IEA) The Import/Export Assistant is a tool used to configure systems which feature recurring functions and/or plant units. Process tag lists or CAD charts previously created in the planning phase are used during configuration to create CFCs for process tags, for the most part automatically. During this process, replicas of the models are generated and then supplied with specific data, see chapter 6.2 "Bulk engineering". Advanced Engineering System (AdvES) The AdvES is based on a type/instance concept, which enables improved bulk engineering and thus minimizes the risk of errors. Similar to the typicals in the IEA, templates are created in the AdvES from which instances are generated. Unlike in the IEA, the instances in the AdvES are still linked to the type following duplication and can be updated. Further information regarding configuration and the advantages of using the AdvES can be found in chapter "Type/instance concept with the Advanced ES". Block protection Blocks can be protected from changes and access so that only the inputs and outputs are still accessible. "S7 Block Privacy" (PCS 7 V8.0 and higher) provides greater security than the previous Know-How protection and should therefore be used preferentially for sensitive areas in particular, see chapter for write protection and chapter for block encryption. In order to work with blocks encrypted with "S7 Block Privacy", the AS must have a CPU 4xx with firmware version V6.0 or higher. Version Trail SIMATIC PCS 7 Version Trail enables multiprojects, single projects, and projectspecific libraries to be backed up together with the assignment of a unique version ID for the archived projects. In PCS 7 V8.0 and higher, it is also possible to back up multiprojects, projects, and libraries at defined times automatically and with versioning, and to read back block parameters in a time-controlled manner. For more information on configuration and use of "Version Trail", refer to chapter "Versioning of projects with Version Trail". Version Cross Manager (VXM) The Version Cross Manager is an additional software package for PCS 7, which allows two PCS 7 user projects or libraries to be compared and any differences to be displayed. Multiprojects cannot be compared. For more information on configuration and use of the VXM, refer to chapter "Version comparison with Version Cross Manager (VXM)". 26 A5E AA

28 System Specification Route Control The SIMATIC Route Control additional software package is used to configure, monitor, and diagnose materials handling (paths) within a plant. It is fully integrated in SIMATIC PCS 7 and SIMATIC BATCH. For more information on configuration and use of "SIMATIC Route Control", refer to chapter 6.7 "SIMATIC Route Control". Simulation with S7-PLCSIM and SIMIT S7 PLCSIM is a simulation tool for S7 user programs. This software component, which is available as an option, simulates a SIMATIC S7-CPU on a programming device or PC. The configured application software can be tested without the use of AS hardware (CPU and/or signal modules). Only one CPU can be simulated at a given time. Communications processors and Route Control cannot be simulated. The use of S7 PLCSIM is of particular interest for the test system, for example, for typical tests. For a subsequent operation with an Ethernet network, the Ethernet connection should be configured beforehand in PLCSIM, since all communication links have to be reconfigured for the use of MPI. SIMIT can be used from the simulation of the field level through to process simulation, see chapter "Simulation for test mode" Software components for operation level Basic software for Operator System (OS) Systems for the operator control and monitoring of the plant are implemented either as single or multiple station systems. With a single station system, all operator control and monitoring tasks can be handled on one PC. A multiple station system (client-server architecture) consists of operator stations (OS clients) and one or more OS servers, which supply the OS clients with data. Redundant systems can be set up to increase availability. The number of licenses for the operator stations can be increased at a later time using suitable packs. When extending/updating a license, the existing license must be available, i.e. runtime cannot be active. Online extension is only possible for redundant servers. A5E AA 27

29 System Specification SFC Visualization additional software An SFC (sequential function chart) is used as a sequential control system (also known as a sequencer) of processes. SFCs consist of a sequence of steps that are separated from one another in each case by step enabling conditions (or transitions). Using SFC Visualization, the configured SFCs can be displayed on the operator station and operated in manual mode. SFC Visualization enables processes to be clearly displayed by showing their different process actions. No additional effort is necessary to configure the SFC visualization. OS Web Option additional software The PCS 7 OS Web option enables the PCS 7 plant to be operator controlled and monitored via the Intranet or Internet. Use of the Web option in a controlled environment must be thoroughly discussed and agreed with the customer. Aspects such as access to the Web Client, critical or non-critical operator control and monitoring functions, logons, and audit trails, as well as a secure data connection, must be considered during these discussions. Additional information on the use and configuration of the Web option can be found in chapter "PCS 7 OS Web option" and in the manual "PCS 7 OS Web Option" SIMATIC BATCH basics and options The SIMATIC BATCH software is integrated in SIMATIC PCS 7. It can be operated as a single user station system or a client/server system and can be used in various different plants, thanks to its modular architecture and scalability. SIMATIC BATCH servers can be configured redundantly. SIMATIC BATCH includes a range of functionalities: 28 A5E AA

30 System Specification Batch planning Enables batch planning and control in BatchCC, supported by order category list, production order list, batch results list, etc. Hierarchical recipes Enables creation of hierarchical recipes according to ISA-88 ROP library (library operations) Enables creation and central management of library operations, including passing them on to instances. The reference to the master module can be resolved at a later point in the project. Separation of procedure/formula Enables recipes with formulas and formula categories that are independent of a particular plant unit. Any number of formulas (parameter sets) can be created for one procedure. API interface SIMATIC BATCH API is an open interface and offers many functions for online and offline operation, such as for connection to the plant control level. Refer to the system documentation for more information on using and configuring the individual BATCH functionalities. See also Chapter 6.6 "Recipe control with SIMATIC BATCH" Long-term archiving In the regulated environment, relevant production and quality data must be retained in some cases for 5 or 10 years or even longer. It is essential for these data to be defined, reliably saved, and transferred to external archives. The basic package contains configuration options for archiving. The strategy for exporting to another computer will be defined according to the amount of data accumulated and the retention period. Long-term archiving of process values and messages can be set up using an import/export of concepts are introduced below. OS archiving Process values and messages are stored in a short-term archive based on Microsoft SQL server technology. The data saved on the archive server can be exported to another computer and, if required, read back again, or permanently transferred to a long-term archive, see chapter "Setting up process value archives" for this purpose. A5E AA 29

31 System Specification SIMATIC Process Historian A SIMATIC Process Historian can be used to centrally acquire and archive process values and messages from several WinCC servers (also redundant systems) as well as batch data. Transparent access to the archived data in order to view the messages and process values in the user interface is handled by the system automatically in the background. The messages saved in WinCC archives are fully transferred to the Process Historian. Only those variables that are labeled as being "Long-term relevant" are transferred. If the Process Historian is unobtainable, the completed archives remain on the WinCC servers and are transferred later on when the link to the Process Historian is reactivated. For this purpose, sufficient memory volume is to be planned on SIMATIC WinCC servers. Monitoring of the network connection may also be advisable. Defined interfaces provide direct access to archived process values and messages. This means that important production data is available throughout the company. See also "Process Historian 2014" manual, Online support under Entry ID Reporting For the necessary quality certification, a definition is made to establish which production data is relevant for output in a report. A report can include messages and alarms, batch data as well as process values in tables or trend format. See also Manual "PCS 7 Engineering System (V8.1)" chapter 5.2.5, Online support under Entry ID Report Designer The WinCC Report Designer continually reports process data for a defined period of time. The report output is started via a print job. The Report Designer is also used for documentation of the configured WinCC project. For this purpose, preconfigured report layouts and print jobs are included in the SIMATIC PCS 7 scope of supply. Both the preconfigured report layouts and print jobs can be opened in the Report Designer and modified as required. Information Server The SIMATIC Information Server offers the option of reporting on recorded process values, batch data, and messages. Both preconfigured and those configured based on Microsoft Reporting Services can be represented in the web-based interface and exported to various formats. Additional integration in Microsoft Word, Excel or PowerPoint shows the reports for the archive data in the familiar office environment. 30 A5E AA

32 System Specification Data exchange via Open PCS 7 Open PCS 7 can be used to exchange data with external systems, such as the plant management and production control level, MES level, or ERP level via the OPC interface, without knowledge of the PCS 7 project topology being required. OPC (OLE for Process Control) refers to a uniform, vendor-independent software interface, the standard of which was defined by the OPC Foundation. The OPC Foundation is an alliance of leading companies in the field of industrial automation. Information on OPC can be found on the Internet at the use of Open PCS 7 is described in more detail in chapter "Open PCS 7". 3.4 Application software specification In addition to the selection and definition of the hardware (chapter 3.1) and the utilized standard software components (chapter 3.3), the specification of the application software is an integral component of the design specification. This is not only used to specify functions but also serves later as acceptance criteria during system verification (FAT, SAT, etc.). The design specification can consist of one or more documents. Additional separate documents are often added as supplements, e.g., process tag list, I/O list, parameter list, P&ID, etc. Like for the other specification documents (URS, FS, DS), the status of these documents (version, release) must be clearly defined. See also GAMP5 Guide, Appendix D3 "Configuration and Design" In addition to the previously mentioned hardware specification, the design specification can be divided as follows, for example: System specification (general) Organization of domain, domain administration User administration in Windows, Definition of user groups, users, authorizations, local users, configuration of SIMATIC Logon, WinCC user administration, SIMATIC BATCH role distribution, Route Control user groups, etc. Domain and PC profile Printer configuration Archive configuration (archives, archive cycles, batch reports) Interfaces (S7 connections, OPC, discrete I/O processing) HMI design specification Examples of the aspects specified for the user interface include the following: Screen layout and navigation Plant pictures, unit pictures, detail pictures of interfaces Operator level, access authorizations Picture hierarchy Screen resolution, picture cycles Block icons, faceplates used Message capability, message classes, priorities, representation, see chapter A5E AA 31

33 System Specification Software design specification General information such as name of multiproject, name of projects, name of libraries, plant hierarchy Appropriate division of plant and plant unit areas for the automation systems, see also HDS in chapter 3.1 Software structure, typical and module specification, possibly in a separate document Control modules (CM) and control module types (CMT) (statuses, behavior, response to restart) Equipment modules (EM) and types (statuses, logic status, behavior, configuration) Route Control, if present (function, interface blocks) SIMATIC BATCH (function, distribution of recipes, use of forms) Any other utilized functionalities, such as RFID etc. Power failure and restart behavior (behavior of PC stations and automation systems, failure of an AS) Time synchronization, specification of time master and slave Description of exceptional statuses for reliable plant operation Emergency-Off response As a basis for configuring batch control, SIMATIC PCS 7 uses the model of ANSI/ISA-88.01, see also chapter See also Application example for specification of technical functions with SFC types as well as instantiation, Online support under Entry ID Additional software SIMATIC PCS 7 Add-ons The SIMATIC PCS 7 Add-On catalog contains solutions for various areas of application or special branches, such as the process industry. The addresses of the relevant contacts for these add-ons are listed in the catalog. Priority should be given to add-ons from the latest catalog when implementing functions that go beyond the standard scope of PCS 7. See SIMATIC PCS 7 Add-ons versiondog Version assignment and configuration control The entire lifecycle of a SIMATIC PCS 7 system can be tracked through the version history with versiondog - from planning through commissioning to continuous optimization during operation. If a new version is created, versiondog automatically determines the changes and makes them transparent to the user. PCS 7 Smart Compare shows the differences between two versions in the familiar SIMATIC PCS 7 project structure. Differences between two CFCs or SFCs are highlighted in color in a graphic comparison. The audit trail of versiondog allows 32 A5E AA

34 System Specification you verify at any time who made a change, when it was made, what was done and why it was done. See also PCS 7 Add-on description on the Internet, including manufacturer details OPD User dialogs and electronic signatures The software operator dialog (OPD) simplifies the interaction between operating personnel and process control system. As a powerful operator tool, it facilitates control of the process and provides complete proof of all manual operations. The OPD software, which can be executed in a SIMATIC PCS 7 / SIMATIC BATCH system environment, is based on the Microsoft SQL server software. It uses the SIMATIC logon for user verification and electronic signatures. See also PCS 7 Add-on description on the Internet, including manufacturer details 3.6 Utilities and drivers Printer drivers It is advisable to use the printer drivers integrated in the operating system and approved for PCS 7. If external drivers are used, no guarantee of proper system operation can be provided Virus scanners The use of virus scanners in process mode (runtime) is permitted. Additional information on selecting, configuring, and updating virus scanners can be found in the PCS 7 Readme files as well as in Online Support under Entry ID and in Manual "PCS 7 Managing Virus Scanners" in Online Support under Entry ID When virus scanners are used, the following settings must be observed: The real-time search is one of the most important functions. It is sufficient, however, to restrict the analysis to incoming data traffic. The time-controlled search should be deactivated, as it significantly limits system performance in process mode. The manual search should not be run during process mode. It can be performed at regular intervals, e.g. during maintenance cycles. These arrangements should be described in the specification and/or where necessary, in a work instruction (SOP) from the IT department in charge. A5E AA 33

35 System Specification Image & partition tools Supplemental Imaging and Partitioning software allows you to create a backup of the entire contents of a hard drive, the so-called image, as well as to partition the hard drives. A quick restoration of the system is possible with the system and user software backed up in the image. Backed up hard drive contents can also be imported to devices of the same type. This facilitates the replacement of computers. Siemens provides the software package "SIMATIC Image and Partition Creator (IPC)" to perform these tasks. This can even be done without a separate installation by starting the program directly from CD or USB Flash Drive. Administration skills are needed for this process. The created images are used to restore the installed system, but not to back up online data. 34 A5E AA

36 System Installation and Configuration 4 System Installation and Configuration 4.1 Installation of the operating system When selecting the operating system, observe the information given in chapter 3 and the sources named therein. See also Installation instructions for the operating system Manual "PCS 7 PC Configuration" Online support under Entry ID Installation of SIMATIC PCS 7 To install SIMATIC PCS 7, follow the instructions of the setup program. When required, approved third-party components (e.g. Office) must be installed prior to installing PCS 7. More installation information is contained in the Manual "Security Concept PCS 7 and WinCC" Online support under Entry ID Manual "PCS 7 PC Configuration" Online support under Entry ID Manual PCS 7 "Released Modules" PCS 7 installation DVD Readme files of the individual SIMATIC components SIMATIC Logon must be selected in the installation setup. 4.3 Setting up user administration For secure operation in compliance with regulations, controlled access is required to both, the operation level and configuration level as well as archive data and backup copies is required. A user-related logon and logoff for operator actions is a basic functionality for meeting this requirement. The user management of SIMATIC Logon uses the mechanisms of the Windows operating system and therefore ensures reliable access protection. For the organization of operating authorization, the users are assigned their tasks according to various user groups in the Windows user administration. These user groups are assigned authorizations for the individual operator actions. A5E AA 35

37 System Installation and Configuration The structure of the user groups should already be defined in the specification at the start of the configuration. The individual operator rights of the software modules are defined in the module description. All authorization levels for operation via the visualization interface (faceplates, input fields, buttons, etc.) and their assignment to user groups are to be set up according to specifications and tested in the course of the project. The setup is differentiated in terms of which level the user operates. The affiliation to certain Windows User Groups is therefore required for the start or the configuration of SIMATIC components such as SIMATIC WinCC or SIMATIC Logon. These user groups are automatically created in the Windows user administration upon installation of the software components and must not be deleted. For the operation of process mode, project-specific user groups are set up which are equipped with the required operation permissions in the configuration. The following sequence is recommended when setting up user administration with SIMATIC Logon and is described in the following chapters: Setup of user groups and users under on operating systems, see chapter Setting up security settings in Windows, see chapter SIMATIC user groups, see chapter Setup and configuration of SIMATIC Logon, see chapter Administration of authorizations for the individual user groups in SIMATIC components (ES, OS, BATCH); see chapter User administration on the operating system level Administration of user permissions using SIMATIC Logon is based on the mechanisms of the Windows operating system. There are two user administration options here: Centralized administration in a domain structure Administration on one computer of a work group When using multiple servers or when there are redundant servers, the domain structure must be used to ensure that users will still be able to perform operations and log on even if one domain server fails. However, the domain server functionality may not be installed on a PCS 7 system. The complete name for each user must be entered under "Local users and groups" in the Windows Computer Management. This name can be used for the display in SIMATIC PCS 7 after logon to the application and is required for electronic signatures. Êach user s full name should therefore be entered. See also "Security Concept PCS 7 and WinCC", Online support under Entry ID A5E AA

38 System Installation and Configuration Manual "PCS 7 Engineering Compendium Part A", Online support under Entry ID , chapter "Work group and domains" While a user is authenticated for his operator rights in the SIMATIC environment when he logs on, a "default user" is always logged on to the operating system at the same time and has the permissions required for the operating system level. These should not be higher than actually required, see also chapter 4.5 "Access control to operating system level". The user logged on to the operating system must be the same one who is logged on throughout the entire system; he must be logged on automatically when an OS computer starts up. Logons, logoffs and unsuccessful logon attempts can be viewed in the SIMATIC Logon Eventlog Viewer and exported; changes to the user and group configuration are recorded on the operating system level in the Eventlog and can be saved there Security settings in Windows Access authorizations as well as password settings such as the length, complexity, and validity period can and should be configured appropriately to increase data security. When using SIMATIC Logon, the system administrator makes the following security settings in Windows under Control Panel > Administration> Local security regulations > Security settings > Account regulations / Local regulations: Password policies such as complexity, password length, password aging Account lockout policies Audit policies (e.g. logon events and logon attempts) A5E AA 37

39 System Installation and Configuration Following Windows installation, default parameters are set for the password policies, account lockout policies, and audit policies. The settings must be checked and adapted to the requirements of the current project. See also Chapter 4.5 "Access control to operating system level" Chapter 4.6 "Data and information security" Manual "PCS 7 Engineering Compendium Part F", chapter 6.4 "Password policies", Online support under Entry ID All-round protection with Industrial Security system security, Online support under Entry ID SIMATIC user groups When PCS 7 is installed, local SIMATIC standard user groups are automatically created in the operating system with various rights (SIMATIC HMI, etc.). These must not be changed or deleted. The defined users and user groups must be made members of these SIMATIC user groups which have the appropriate authorization. A differentiation is made when logging on the Windows level between system administrator and user (plant operator), which results in a consequent division of the computer access authorization. See also Chapter 4.5 "Access control to operating system level" "Security Concept PCS 7 and WinCC", Online support under Entry ID A5E AA

40 System Installation and Configuration Configuration of SIMATIC Logon SIMATIC Logon serves as an interface between the Windows user administration and SIMATIC components. It checks the correctness of logon data for a user against the central user administration. If the logon is valid, the associated user groups are returned to the operator station. The basic settings for SIMATIC Logon are made with the "Configure SIMATIC Logon" dialog. The available settings are described in "SIMATIC Logon" configuration manual and include, for example: The logon of a "default user" after a user logoff Logon server ("working environment") Automatic logoff on using SIMATIC Logon Events, such as successful and failed logons and logoffs, password changes, etc. are stored in the EventLog database of SIMATIC Logon. This must be taken into account when backing up data, see also chapter 6.9 "Audit trail and change control". A5E AA 39

41 System Installation and Configuration Default user after user logs off In the "General" tab, you can define whether a default user should be logged on after a user logs off. Unlike all other users, the "Default User" does not have to be created as a Windows user. The "Default user" is a member of the "Default group" or any other user group assigned here. The rights of this group are determined in WinCC User Administrator. Automatic logoff (Auto-Logoff) To prevent unauthorized accesses from occurring with the logged-on user, the "Auto-Logoff" function must be enabled and a time assigned in the SIMATIC Logon configuration. If use of the default user has been activated, this user is then logged on. The "Auto-Logoff" function must not be enabled at the operating system level, as this will close down the user interface completely. A screen saver should also be disabled when SIMATIC Logon is used. Otherwise, when unlocking the screen, the system would ask for the password of the Windows user, which the PCS 7 OS operator should not know. 40 A5E AA

42 System Installation and Configuration 4.4 Administration of user rights Administration of user rights on the Engineering System (ES) Access to projects and libraries can be controlled using SIMATIC Logon. When activating access protection for new or unprotected projects, the Windows user who is logged on is automatically defined as the project administrator. That user can then define other users as project editors or project administrators. To complete activation of access protection, the user must specify a project password which should only be known to the project administrators. "SIMATIC Logon role management" serves as the interface for assigning users to the group of project editors or project administrators. Instructions Access protection must be activated for every project and every library used in the multiproject. Synchronization: Within a multiproject, access protection for one project or library can be passed down to all other projects/libraries. The project format is changed when access protection is activated for the first time. The project can then no longer be edited using a STEP 7 version < V5.4. Possible user permissions on the ES A user on the ES may be given the following permissions: Project editor Make project changes Display change log Project administrator Make project changes A5E AA 41

43 System Installation and Configuration Display change log Enable and disable the change log Manage access protection Deactivating access protection Synchronizing access protection in the multiproject In order for a user to be assigned to permission roles, he must already be known in Windows user administration. The following presents three possible scenarios for establishing and using protected projects / libraries. Scenario 1 SIMATIC Logon installed User known in Windows Access permission for the project is available When the user has the required permission, he can open a project without any further authentication, provided it is in the same network as the user. This also applies if the project has been taken out of the multiproject. Scenario 2 SIMATIC Logon installed User known in Windows Access permission for the project is not available If a user does not have access permission, protected projects/libraries are displayed in gray. If the user attempts to open the project, he will be prompted to enter the project password. If the user knows this password and enters it, he is automatically defined as a project administrator. The project password should only be known to the project administrator. 42 A5E AA

44 System Installation and Configuration Scenario 3 SIMATIC Logon not installed If SIMATIC Logon is not installed, there is no project administration function. Each time a protected project/library is opened, the project password must be entered. Also in this case, the project password should only be made known to the relevant group of people. If the protected project has been provided by a customer, they must decide whether or not the existing password should be changed in their system. The way in which the project password is used and the time at which access protection is to be activated on the ES level should be given careful consideration and defined at an early stage. See also Configuration manual "PCS 7 Engineering System" Online support under Entry ID Administration of user rights on the Operation System (OS) Windows user groups are assigned to PCS 7 OS groups by virtue of their same names. For example, if you want to assign an "Operator" Windows group, an identically named "Operator" group must be created in the PCS 7 OS User Administrator and the required rights assigned. The following procedure must be followed for this: Open PCS 7 OS project Open User Adminstrator via WinCC Control Center Create the group(s) Assign the permissions for each group The figure below shows how operator authorizations are assigned to individual groups. A5E AA 43

45 System Installation and Configuration Centralized management of users, such as that provided by SIMATIC Logon, is essential in many situations, especially in regulated environments. For this, the check mark for activation of SIMATIC Logon must be set in the PCS 7 OS "User Administration" of the respective PCS 7 OS computer Administration of user rights in SIMATIC BATCH Permissions and roles are assigned in the SIMATIC BATCH application using "SIMATIC Logon Role Management". 44 A5E AA

46 System Installation and Configuration The individual roles are assigned to operator rights in SIMATIC BATCH. The following can also be defined: User permissions for a user role Permitted user roles per computer Permitted user roles per unit Rights management in SIMATIC BATCH has been re-structured as of V8.1 to have a clearer layout, thanks to an additional organizational level. All existing rights remain in place following an upgrade, meaning that the existing configuration can be used. 4.5 Access control to operating system level For the general network configuration, refer to the manuals "PCS 7 Engineering System Configuration" and "PCS 7 and WinCC Security Concept". Since access to the Windows operating system level should be avoided for security reasons, additional configuration settings are necessary. These settings prevent unauthorized access from SIMATIC PCS 7 process mode to sensitive operating system data. A5E AA 45

47 System Installation and Configuration Access to the operating system level should be reserved exclusively for administrators and technical maintenance personnel. Automatic startup and logon The "default user" on the operating system level should be logged on automatically when each server or client starts up. Activating the operator control level (runtime) Automatic starting of the PCS 7 operator control level (runtime) must be activated so that the operating system level cannot be accessed Configuration settings in Windows You can use hot keys to go to the operating system level. This option must be disabled for operator stations in particular. 46 A5E AA

48 System Installation and Configuration Some graphics cards also offer such settings, which should be disabled: Configuration setting on SIMATIC PCS 7 OS Access to the operating system during process operation (runtime) is configured via the OS parameter properties. It must also be ensured in PCS 7 OS user administrator that the button for terminating process operation (deactivate OS) can only be clicked if the appropriate permission is available Secure configuration If possible, no OLE objects should be configured, as such objects often allow unauthorized access to folders, files, and programs. 4.6 Data and information security In the regulated environment, production processes and recorded data are subject to control and secure retention to ensure verification of product quality. The secure handling of data is a basic requirement for operation in compliance with regulations. National and international standards require retention of relevant production data and operator inputs for many years. For this reason, there are many facets to data and information security, some of which are described here. Definition of a suitable system structure For system structure including user management, see Windows settings in chapters and as well as in chapter "SCALANCE S". Planning of data storage and of input and output devices Secure storage of sensitive data with redundancy and access protection Use of virus scanners, see chapter For defined behavior on startup and when operating the user interface, see chapter 4.5 "Access control to operating system level" A5E AA 47

49 System Installation and Configuration Organizational measures Planning and assignment of the required access permissions Supplementation by codes of behavior, e.g. for handling of USB sticks Work instructions for archiving, readback, and possibly data migration Operating system settings and network security The settings in the Windows operating system are configured using SIMATIC Security Control SIMATIC Security Control (SSC) Using SIMATIC Security Control increases the level of computer security. The application can be run either when PCS 7 installation is completed or at a later point in time. The following settings are configured automatically for specific functions (OS client/server, ES, etc.): Configuration of the Windows Firewall exception list for PCS 7 communication (firewall can be activated) DCOM settings for PCS 7 (Distributed Component Object Model) Security-related registry entries Following installation, the Start > SIMATIC > SimaticSecurityControl menu command can be used to perform configuration at any time. SSC also enables the settings made in the system to be documented. If the SIMATIC PC station is integrated into another work environment (domain or workgroup), it must be reconfigured. See also Comprehensive information about "Industrial Security" in Online support under Entry ID SCALANCE S The increasing integration of plant networks in office networks is accompanied by increased security risks, from network problems such as the duplicate assignment of network addresses, to problems with viruses, and even the possibility of attacks by cyber-crime. In certain applications, the SCALANCE S security modules can be used to counteract these risks. They basically offer two different functions: Firewall If a firewall is used, only registered nodes can communicate over the network. See also "Protection of an automation cell via a firewall" including the document attached there, Online support under Entry ID A5E AA

50 System Installation and Configuration VPN A virtual private network (VPN) links external computers in two or more local networks via the Internet and encrypts the transferred data at the same time. A VPN connection enables external systems to perform secure remote access over the Internet. To do this, SCALANCE S technology uses the widely used IPSec protocol, which provides an extremely high level of security in tunnel mode (VPN tunnel). See also "Security via IPSec-secured VPN tunnel", including the document attached there, Online support under Entry ID SCALANCE S technology offers various applications. More information can be found in the manuals of the SCALANCE product series. A5E AA 49

51 Project Settings and Definitions 5 Project Settings and Definitions 5.1 Project setup Multiproject Multiproject engineering allows a project to be divided into several sub-projects so that it can be worked on by more than one person. A higher-level "multiproject", which contains the individual projects (AS, OS, SIMATIC BATCH) and the master data library, is defined in the SIMATIC Manager. Projects can be added to and removed from the multiproject. The master data library supports consistent data management within the multiproject. In a controlled environment in particular, it is essential to use the master data library to centrally manage process tag types, models, SFC types, and shared declarations. The SIMATIC PCS 7 "New project" wizard assists you in creating projects. It automatically creates a multiproject. A new project can be added to an existing multiproject as an empty or a preconfigured project. The project name to be assigned must be previously defined in the software specification, as it can be difficult to subsequently rename a project. See also Manual "PCS 7 Compendium Part A", chapter 4.2 "Required settings in the SIMATIC Manager" and chapter 4.3 "Automatically creating a multiproject" Online support under Entry ID For projects whose size means they are suitable candidates for division into several multiprojects, the project structure and modes of operation must be carefully planned and documented. Your usual Service & Support contacts would be happy to assist you with this. See also "Multiproject engineering", Online support under Entry ID "Multiproject engineering with SIMATIC BATCH", Online support under Entry ID Good coordination among the project team is essential, especially in larger projects! Therefore, to the extent possible, actions such as compiles or downloads should be scheduled so that they do not block the entire team. 50 A5E AA

52 Project Settings and Definitions Multi-user engineering The configuration of an extensive range of projects can be performed in parallel by various users, whereby the users process different resources. The release for the Multi-user engineering is activated in a property on the PCS 7 OS server. A resource dialog provides an overview of which resource is in process on which computer. In contrast to remote configuration via a configuration client, the configuration clients do not need to be entered in the computer list for Multi-user engineering. 5.2 Referenced OS stations Using a referenced OS station allows you to create a reference to an existing OS station. Several OS types can be configured as samples and all other OS stations derived from these samples, similar to the way the type/instance concept works. Configuration types The following types of OS stations can be referenced: a) Referenced station for OS single user station (WinCC application ref.) b) Referenced station for OS client station (WinCC application client ref.) Software configuration using the example of a client The referenced OS client station needs a standard multiclient as a reference. A referenced OS client station is then added to the project and the "OS Basis" is defined in the object properties (see figure). The number of referenced OS client stations is limited by the maximum number of operator stations, which is defined by PCS 7. If the reference station is changed, all OS stations which point to it must be loaded. A5E AA 51

53 Project Settings and Definitions Advantages of using referenced stations Referenced stations help to minimize errors and the amount of work required. Only the reference station has to be tested in detail according to its specification. For the referenced stations merely special configuration features need to be taken into account, for example, screen resolutions, PCS 7 client-specific operating ranges, and user rights. General function tests also need to be performed. 5.3 Using the master data library To allow several instances of the same functions to be generated, SIMATIC PCS 7 offers a duplication option, based on a defined software procedure. However, this is only possible in conjunction with the master data library, which contains not only the folders for process tag types and models, but also the folders for shared declarations (units, enumerations, and equipment properties). The project typicals are created on the basis of the libraries used (PCS 7 standard library, Advanced Process Library APL, etc.). They are then stored and managed in the master data library. The PCS 7 standard libraries include templates that can be used. The modules and typicals should be verified in a module test and approved by the customer prior to instantiation. Not only must the same versions of faceplates, SFC types, and typicals be used in all projects within a multiproject, but such projects must also be based on a common plant hierarchy and shared declarations. The individual projects must be synchronized with the master data library for this. SIMATIC Version Trail is used to clearly archive and organize versions of the master data library during the course of the project. The faceplates, SFC types, and shared declarations are the smallest user software modules. These are used in creating process tag types and models, which are then duplicated either manually or via the IEA interface, see also chapter Bulk engineering with the IEA" as well as chapter "Type/instance concept with the Advanced ES" for more on this. See also Manual "PCS 7 Compendium Part A", chapter "Process tag types (templates)", Online support under Entry ID A5E AA

54 Project Settings and Definitions Synchronizing shared declarations Shared declarations are generated in the master data library automatically when the multiproject is created. These declarations can be synchronized to make them available in all projects. Centralized maintenance in the master data library is strongly recommended in order to ensure consistency throughout the multiproject. A5E AA 53

55 Project Settings and Definitions Synchronizing SFC types SFC types must be created and maintained in the master data library in order to achieve data consistency. These types can be synchronized to make the current SFC types available in the projects. Differences can be evaluated using the Version Cross Manager prior to synchronization Synchronizing the plant hierarchy Three views are available in SIMATIC PCS 7 for configuration purposes: Component view for configuring hardware Plant view for structuring the process engineering hierarchy Process object view for centralized editing of parameters, signals, messages, picture objects, archive tags, etc. 54 A5E AA

56 Project Settings and Definitions It is advisable to structure the plant hierarchy in the same way in all projects within a multiproject. To do this, place the plant hierarchy in a project (recommendation: OS project) and transfer this structure to all projects of the multiproject. The shared declarations of the template project are also transferred to the selected projects as part of this process. This forms a connection between the hierarchy folders. See also Manual "PCS 7 Compendium Part A", chapter 4.6 "Creating the plant hierarchy", Online support under Entry ID The template project takes on a kind of master role, in other words the names of the created hierarchy folders can only be changed centrally in the template. Names in the replicas can only be changed once this connection has been removed. A5E AA 55

57 Project Settings and Definitions 5.4 SIMATIC NET Configuring SIMATIC NET SIMATIC NET reflects the gateways used in the project. The SIMATIC NET network addresses and settings for the AS, OS, distributed I/O, etc. described in the specification must be used for configuration. This is verified later during testing (for example, FAT, IQ). The gateways are configured using the "Advanced PC Configuration" procedure. With Windows, all the automation stations (AS) and operator stations (OS) can be configured on a central engineering station and the configuration files can be downloaded. Specifically, the following connections are configured: AS/OS connections AS/AS connections ES/AS connections Remote I/O connections These connections can also be designed to be fault-tolerant. Additional information can be found in the SIMATIC NET documentation Plant bus and terminal bus Industrial Ethernet offers a comprehensive range of network components for electrical and optical data transmission. In SIMATIC PCS 7, a distinction is made between a plant bus and a terminal bus. To guarantee a high degree of security and performance, it is advisable to install these two buses separately. Industrial Ethernet plant bus Industrial Ethernet is used as the plant bus. The Industrial Ethernet network operates according to the access method CSMA/CD as defined in IEEE (Carrier sense multiple access with collision detection). The automation stations are connected with the OS servers and the engineering station over the plant bus. The ISO protocol is generally used as the transport protocol. See also Manual "PCS 7 Compendium Part A", chapter "Configuring the plant bus", Online support under Entry ID Ethernet terminal bus The PCS 7 servers are connected with the clients, archive servers, and higherlevel MES systems over the terminal bus. The TCP/IP protocol is normally used as the transport protocol. See also Manual "PCS 7 Compendium Part A", chapter "Configuring the terminal bus", Online support under Entry ID A5E AA

58 Project Settings and Definitions PROFIBUS Reliable communication with the field level must be in place in order to ensure trouble-free plant operation. Such communication is based on a high-performance real-time bus system such as PROFIBUS versions DP and PA. See also System manual "SIMATIC NET PROFIBUS Network Manual" Manual "PCS 7 Engineering System (V8.1)" chapter 5.5.6, Online support under Entry ID Manual "PCS 7 Compendium Part A", Chapter 5.4 "Settings on the CP Ext as PROFIBUS master" Online support under Entry ID The configuration of the PROFIBUS devices/communication is integrated into the overall project in the SIMATIC Manager. A backup of the engineering project therefore contains the entire user software. This has corresponding advantages in terms of regular data backups and verification of the software within the framework of the test phases. PROFIBUS DP Remote I/O stations such as ET 200 can have a simple or a redundant design over electrical or optical PROFIBUS DP networks. With the help of an isolating transformer (RS 485iS coupler) used as a barrier and the intrinsically safe ET 200iSP, PROFIBUS DP can even be used in hazardous zone 1. This makes data transfer rates of up to 1.5 Mbps possible, even in hazardous areas. Complex process I/O devices such as those listed below can be linked to PCS 7 using predefined add-on blocks: SIMOCODE pro motor management system MICROMASTER 4 frequency inverters SIWAREX weighing system Also available: Function modules (e.g. closed-loop controllers, motor starters, etc.) HART modules (for integrating HART field devices) F-modules (for fail-safe applications) Ex modules (connection of actuators/sensors from EX zone) HART modules can be configured via PDM, see chapter "SIMATIC PDM". PROFIBUS PA PROFIBUS PA can also be implemented in simple installation or with increased availability. The ring topology can be used here for a redundant structure. The PROFIBUS PA can be run via corresponding devices (Ex-coupler or AFDiS(D)) as well as intrinsically safe bus. As such, devices can be connected from Ex-zones. The AFDiSD is also characterized by its extended diagnostic capability, such as signal level, jitter, etc. according to NAMUR NE107 "Self-Monitoring and Diagnosis of Field Devices" for main cables and spur cables. A5E AA 57

59 Project Settings and Definitions See also Operating Instructions "Bus Links DP/PA Coupler, DP/PA Link and Y Link", Online support under Entry ID When configured as a diagnostic slave, the FDC DP/PA coupler is fully integrated into plant-level PCS 7 Asset Management Foundation Fieldbus (FF) In addition to facilitating communication via PROFIBUS and HART, SIMATIC PCS 7 offers interfaces for FOUNDATION Fieldbus (H1), allowing a wide range of FF instruments and positioners to be integrated into the process control system. The FOUNDATION Fieldbus H1 is connected to PROFIBUS DP via the DP/FF link. This concept offers: Central engineering of the DP/FF link and FF field devices without the need for additional tools FF drivers in the PCS 7 library and the support of the driver wizard Integration in PCS 7 Asset Management Deterministic communication Cyclic and acyclic communication Cyclic diagnostic information provided by the DP/FF link and the FF field devices See also Manual "DP/FF Link", Online support under Entry ID Manual "SIMATIC Process Control System PCS 7, FOUNDATION Fieldbus", Online support under Entry ID Diagnostics wit PCS 7 Asset Management DP/FF links and FF field devices are displayed identically in PCS 7 Asset Management and behave like DP/PA links and Profibus PA field devices PROFINET Profinet IO is a manufacturer-independent standard (IEC ), and within the scope of Totally Integrated Automation (TIA) it is the joining and extension of the PROFIBUS DP standard, the established fieldbus, and Industrial Ethernet. Similarly to PROFIBUS, PROFINET stands for maximum transparency, open IT communication, network security and real-time communication down to the field level. See also System Manual "SIMATIC PROFINET System Description" Manual "SIMATIC Process Control System PCS 7 Engineering System (V8.0)" Chapter "Planning the Field Level with PROFINET" PROFINET remote I/O stations such as ET200M can have a simple design over electrical or optical Ethernet networks. In addition to this, there is the option of integrating PROFIBUS DP and PROFIBUS PA devices via a proxy. 58 A5E AA

60 Project Settings and Definitions PROFINET fulfills the following properties: Transmission of time-critical data in guaranteed time intervals. Deterministic system: Accurate prediction in terms of the transmission time Problem-free communication using other standard protocols within the same network The following table compares PROFIBUS and PROFINET: PROFIBUS PROFINET Transmission rate 12 Mbps 100 Mbps Cycle time Min. 300 µs Min Jitter <1µs <1µs User data per device (slave) 244 bytes 64 KB (internal) 8 KB (external) Number of devices/interfaces internal 128 external Number of devices/supports onboard IF+10 CPs Consistent user data I/O address space 244 internal 128 external 8 KB internal 8 KB external onboard IF+4 CPs 1440 internal 240 external 8 KB internal 4 KB external The advantages of PROFINET for the user are the merging of PROFIBUS and Ethernet into one standardized and flexible overall concept. (See the following figure). A5E AA 59

61 Project Settings and Definitions SIMATIC PDM SIMATIC PDM (Process Device Manager) is a software package for the configuration, parameter assignment, commissioning, and maintenance of devices (for example, transducers). Among other things, it enables process values and alarms, as well as device status information, to be monitored easily. In addition, commissioning and maintenance is supported by the LifeList functionality which detects and addresses field devices online at the bus. Changes to the field device configuration can be reproduced with the PDM "Change log". This function is disabled by default, and it should be enabled under the PDM project settings. Electronic Device Description (EDD) The EDD forms the basis for device integration. It is supplied by the device manufacturer, made available via the Internet, or included in the device catalogs of EDD applications. SIMATIC PDM is fully integrated in PCS 7. All devices integrated in a project using EDD can be parameterized, commissioned, and maintained from a central engineering station by means of a single tool. When selecting the devices, ensure that the EDDs must be integrated into the PDM. PDM is provided with one device library of the previously integrated device descriptions. A list of the integrated EDDs, for the respective version, can be called in Online support under Entry ID "SIMATIC PDM Device Library". The integration of EDDs not contained in this library can be costly and in some cases not even necessary. As a general rule, an integration test is advisable for the field devices prior to the final selection. Export functions in SIMATIC PDM In SIMATIC PDM, the following field device data can be backed up via an export procedure: Device parameters Change log, changes sorted according to object Calibration report, contains information relating to commissioning and maintenance, as well as test results Version information can be saved in the device s comment field. This information is then exported together with the device data. A version can also be identified by the name given to the export file. 60 A5E AA

62 Project Settings and Definitions As the export file contains a reference to an appropriate transformation file, the content of the export file is displayed in the Web browser in a readable HTML format. The corresponding transformation file ("PDMExportEddl.XSL" for the device parameters and change log or "PDMExportCalibration.XSL" for the calibration report) is copied to the export file location as part of the export procedure. If the export file is copied to a different directory or computer and the HTML display is to be used, the corresponding transformation file must also be copied. 5.5 OS Project Editor The OS Project Editor serves as the basic tool for configuring the user interface, for example, for setting the screen layout, screen resolution, etc. When an OS project is created in the SIMATIC PCS 7 ES, the OS Project Editor is initialized with the default settings. Many of these default settings can and should be retained in projects. Any deviations must be defined in the specification and require very special attention in every update of the system. Some settings are always project-specific. These settings and any changes in response to customer requirements are defined in the specification. The screenshot above shows the layout of the OS Project Editor. It is also used to specify, for example, whether the user interface should display the "user name" or the "user ID". The layout is configured in runtime in the "Layout" tab. This includes the screen formats, number of monitors per OS station and the display of the user name or user ID in runtime. A5E AA 61

63 Project Settings and Definitions Message classes, message types, message blocks, and the PCS 7 standard messages are configured in the "Message configuration" tab. Messaging response is configured in the "Message display" tab. This includes the display of messages in the message pages and the group display, message filters and Smart Alarm Hiding. Under "Areas" the representation of area and server keys (for example, process cell, unit, functions, etc.) are configured for the overview area. The number and arrangement of picture windows is configured in the "Runtime Window" tab. The pictures (graphics) and faceplates are opened in the picture windows in runtime. In the "Basic Data" tab, you can specify which modified files of the project are to be overwritten by factory state files. However, you should always ensure when making this configuration change that runtime operation remains consistent and safe. The "General" tab contains settings for the OS Project Editor. See also Process Control System PCS 7 OS V8.1, Online support under Entry ID Manual "PCS 7 Compendium Part A", chapter "Working with the OS project editor", Online support under Entry ID Time synchronization Time synchronization is an important feature in automated systems in the GMP environment. When several automation stations (AS) and/or operator stations (OS) interact, messages, alarms, trends, and audit trail data must be archived with synchronized time stamps. In SIMATIC PCS 7, the default time transmitted on the buses is always the standardized world time UTC (Universal Time Coordinated). The time stamps are generated in UTC and stored in the archive of the OS server. In runtime, all the process data stored in the archive (messages and trends) are displayed converted from UTC to the time zone set in the Windows system (taking the daylight-saving/standard time setting into account). Activating time synchronization in PCS 7 means that an active time master handles the synchronization of all OS servers, operator stations, automation stations, and the engineering station. To ensure synchronized time, all the stations in the PCS 7 system must be synchronized so that messages can be processed in the correct chronological order throughout the plant (archiving of trends, messages, redundancy synchronization of servers). Time Synchronization in a Windows Workgroup: In a workgroup environment, the plant bus is synchronized via the central plant clock, SICLOCK, for example. The OS servers obtain the time from the plant bus; they are configured as "cooperative time masters". If no SICLOCK timer is available, an OS server becomes the active time master. The automation stations obtain the time from SICLOCK; they are configured as time slaves. The OS clients obtain the time from an OS server; they only receive the time from OS servers whose server data they have also loaded. 62 A5E AA

64 Project Settings and Definitions Time synchronization in a Windows domain If the automation system is operated in a Windows domain, the domain controller with the PDC role serves as the time master on the terminal bus. It obtains its time from a SICLOCK connected in series, for example. The OS servers receive the time from this domain controller via the terminal bus. The OS clients obtain the time from a selected OS sever. The plant bus and, as a result, the connected automation stations (AS) are also synchronized by this OS server (the first server to enter process mode). The server then becomes the active time master. When high-precision time stamping is required, the automation stations also have to be synchronized directly by a SICLOCK TM via the plant bus. If the plant uses components, such as BATCH servers on which no operator station is installed, these also need to be synchronized. This can be done via an additional DCF77 (e.g. SICLOCK) or GPS service or by means of software over the network or the Internet. Time synchronization for package units Package units may be integrated in many PCS 7 environments. These package units can obtain their time from the Windows domain through the standardized Network Time Protocol (NTP). It is also possible to send the time from one Siemens automation system to another via the S7 protocol. It must be ensured that the automatic daylight-saving/standard time adjustment is set correctly in the operating system. If a SICLOCK is used as the clock and the operator station display will be adjusted for daylight-saving time, the SICLOCK must also be set to adjust for daylightsaving time to ensure that all messages are archived with the correct time stamps. This adjustment must be activated on the operator station in the Control Panel > Date and Time > Time Zone. See also Function manual "PCS 7 Time Synchronization", Online support under Entry ID Configuration manual "PCS 7 Engineering System", chapter "Setting the Time Synchronization", Online support under Entry ID Configuration manual "PCS 7 Operator Station", chapter 13 "Time Synchronization", Online support under Entry ID "Security Concept PCS 7 and WinCC", Online support under Entry ID "PCS 7 Compendium Part A", chapter "Time Synchronization" Online support under Entry ID "DCF77", Online support under Entry ID "Industrial Ethernet", Online support under Entry ID "Windows domains" Online support under Entry ID "Setting the Time Synchronization", Online support under Entry ID FDA Guidance 21 CFR Part 11 Time Stamps, 2002, withdrawn A5E AA 63

65 Project Settings and Definitions 5.7 Configuration management The configuration of a computer system consists of various hardware and software components that may vary in complexity and range from commercially-available standard components to specially customized user components. A clear and complete overview of the current system configuration must always be available. This is achieved by dividing the system into configuration elements, which can be identified by a unique designation and a version number and can be distinguished from the previous version. 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. If customerspecific hardware is used, more work is required; see chapter 3.1 "Selection and specification of the hardware" for more information. Such "standard components" are used at least in part for the software, for example, SIMATIC PCS 7 system software, its libraries and options. Just like the hardware, these are defined and documented with designation, version number, etc. The application software is configured and programmed on the basis of standard software. It is not possible to give a blanket definition of the individual configuration elements that the user software must be divided into, due to differing customer requirements and system designs. Versioning of configuration elements While the version designation of standard software cannot be influenced by the user or configuring engineer, work instructions for issuing of version numbers, change control procedures, and the like must be defined for configuring the application software. All configuration elements must be maintained in a transparent manner right from the start of system's creation. Chapter 5.8 "Versioning of software elements" includes examples of how individual software elements can be versioned. Change control of various elements is explained in chapter 6.9 "Audit trail and change control" and chapter 7.4 "Configuration control". Always consult the plant operator to agree upon a procedure for making changes to a plant in ongoing operation; see chapter 9.2 "Operational change control". See also GAMP5 Guide, Appendix M8 "Project Change and Configuration Management" 5.8 Versioning of software elements The project guidelines must define which elements are to be versioned, when versioning is to take place, and whether a major version or minor version is to be incremented; for example: "The major version is set to 1.0 following the FAT and to 2.0 after commissioning. All other changes are reflected by incrementing the sub version." 64 A5E AA

66 Project Settings and Definitions However, 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. The version, author, and comment fields can be written using the Import/Export Assistant (IEA). The following chapters show various examples of software element versioning, which are basically divided into: AS elements, which act as control functions in the controller OS elements, which are used for operator control and monitoring Versioning of AS elements in PCS 7 The individual configuration levels in PCS 7 provide various options for assigning a version identification and, possibly, an author and comment to each element. Versioning of blocks, CFCs, and SFCs For blocks, CFCs, and SFCs, as well as for SFC types and models, version numbers are managed in the properties of the respective object. PCS 7 supports the option for semi-automatic versioning of CFC/SFCs and SFC types. This versioning must be enabled in the properties of the particular project or multiproject, see following picture. A5E AA 65

67 Project Settings and Definitions When the versioning for the respective project is enabled, a dialog box opens automatically when you close a modified CFC/SFC or SFC type. In the example below this is the "Properties CFC Chart" dialog. Use the right and left cursor keys of the version number to increment the minor or major version. If you make an incorrect entry, the version can only be decremented to the last saved version. Changes to the version number must always be performed on the engineer s responsibility. Once saved, a version number can no longer be reversed. The project team member must carefully examine his entries before confirming with OK. The version number can be set in the range of to A5E AA

68 Project Settings and Definitions Information on the version history can also be added to the chart as a separate comment in the form of a text field, see graphic below. A5E AA 67

69 Project Settings and Definitions Another possible variant is versioning on the unit level, if the plant has an appropriate structure. The unit and lower-level elements are managed and versioned as functional units. The version of the unit can be transferred to all elements using the "Find/Replace" function in the process object view. Version and change comments should then be maintained in the unit CFC. Versioning of hardware configuration in "HW Config" In the "Properties" mask, the comment field can be used to enter the version ID and additional information, such as the version history. Versioning of configuration in SIMATIC NET The version identification can be entered in the properties on the bus level (system bus, PROFIBUS). 68 A5E AA

70 Project Settings and Definitions Versioning of OS elements in PCS 7 During software creation, all graphics, reports, C scripts, and VB scripts created by the user must be assigned data such as an author, date, comment, and version ID. User objects (picture typicals), for example, feature a version field for this purpose. Scripts and user FBs (SCL) can be identified by means of their date of change; the version identification and comment must be inserted in the script header in text format. Configuration settings must be appropriately documented, on the one hand to act as a reference for use in validation, and on the other hand to ensure they are available if the system needs to be restored. Example for graphics Top graphic: Versioning in a hidden field within the graphic display Bottom graphic: Version identification as a visible field within the graphic display; explanations relating to the version history outside it A5E AA 69

71 Project Settings and Definitions Example for reports Visible text field for versioning, e.g., in the report footer: Example for C/VB scripts Inserting of version and comments within a script: 70 A5E AA

72 Project Settings and Definitions Additional information on versioning Versioning of BATCH elements Recipe versioning is described under "Change Control for Recipes" in chapter "SIMATIC BATCH". Versioning of projects, multiprojects, and libraries Supporting system functions for versioning of projects, etc. are described in chapter 7.4 "Configuration control". A5E AA 71

73 Creating Application Software 6 Creating Application Software This chapter presents information and recommendations intended to aid in the creation of application software in environments subject to GMP. 6.1 Software modules, types, and copy templates Software modules or type templates in the form of function blocks, function charts or complex step sequences are widespread in the process control engineering. They are created in advance and reproduced within the scope of the configuration. Modules and types are defined with the aim of not only reducing the amount of configuration work required but also, and more importantly, of creating a clear software structure. This helps to simplify the associated documentation and a riskbased definition of the testing work involved, while also supporting subsequent system maintenance. See also Chapter 2.4 "Software creation" Modules and types in PCS 7 A distinction is made in SIMATIC PCS 7 between an SFC type, a process tag type, and a model. SFC type Process tag type Model Interface to SIMATIC BATCH for operating equipment phases/equipment operations, for example: Heating Stirring (agitation) Emptying A CFC, for example Valves Pumps Motors Combination of several CFC and/or SFCs, for example: PID tempering of a tank Level monitoring, including safety shutdown to protect against overflow of tank Unit The mode of operation of the modules must be described in a specification in which the parameter assignments (MES-relevant, archiving, block comment, unit of measure, etc.) and interconnections are defined. For more information on using types for programming, see also chapter 2.4 "Software creation". 72 A5E AA

74 Creating Application Software Instructions Modules are named in accordance with the Functional Specification and the Design Specification. The modules/types must be verified and approved by means of a module test before they are duplicated. An up-to-date record of the software modules used must be kept for each AS, in the form of a document containing software version details. SFC type The SIMATIC PCS 7 type/instance concept enables types of sequential controls to be created. The "SFC type" allows sequential controls to be defined, including an interface in the form of a CFC block. The sequence logic of the SFC type is based on the interface I/Os of the SFC type, i.e. in contrast to an SFC, an SFC type cannot access just any process signals. More detailed information on this topic can be found in the Manual "SFC for SIMATIC S7" in Online support under Entry ID The SFC type is not executable on its own. An SFC type, just like a function block type, must be placed in a CFC before it receives an executable object, in this case an SFC instance. The SFC type and the SFC instances are included in the "Compile program" operation. To execute an SFC instance, both the SFC type and the SFC instance are downloaded to the automation system. Process tag type / model With SIMATIC PCS 7, a process tag type/model consisting of one or more CFC and/or SFCs can be created for subcomponents of the same type. Creating process tag types or models for similar plant units saves on work required for engineering and testing. Once a process tag type or model has been tested, it can quickly be duplicated as often as required in the multiproject in the form of replicas. For each replica, the plant hierarchy, CFC name, messages, I/Os for parameters or signals, and various module properties can be adapted. Each block instance can also be assigned a picture icon, which can then be automatically inserted, along with its tag interface, into the flow chart defined in the SIMATIC Manager by deriving it from the screen hierarchy during OS compilation. This saves work and ensures that the picture icon is connected to the correct block instance. Models can contain pictures and reports. See chapter "Automatic generation of block icons" for information on using block icons. These block icons should be tested together with the associated software module as a process tag type and approved by the customer before they are duplicated. A5E AA 73

75 Creating Application Software Example of a process tag type Every software module is created as a template in the form of a CFC. Following a software module test, this is released for instantiation and can be used within the framework of the configuration. For a spring-closing valve, the module might appear as shown below. The valve to be controlled features a control signal for the OPEN function and two feedback messages for the states opened and closed, as well as monitoring of module I/O faults for the open/closed feedback message. Blocks from the PCS 7 standard library were used for the example above. In accordance with GMP requirements, the parameter assignment and the interconnection of the inputs and outputs must be described in detail in a suitable specification ("Software Module Design Specification", for example) and verified by means of a test ("software module test" or "typical test"). See also Manual "PCS 7 Compendium Part A", chapter "Process tag types (templates)", Online support under Entry ID Consideration can also be given to settings like process value archiving, for example, when creating the process tag type. 74 A5E AA

76 Creating Application Software Automatic generation of block icons Graphic block icons are used to display information relating to process states (e.g. valve open, closed, faulty, etc.) on the PCS 7 operator station (OS). PCS 7 offers graphic templates for all blocks contained in the PCS 7 library, thus supporting the type/instance concept from the function block in the AS through to the operator component in the PCS 7 OS plant pictures. PCS 7 provides several templates for use. Generating block icons automatically reduces the risk of an error occurring. See also PCS 7 on Tour Basic, Chapter 10 section 5 "Adapted block icons and faceplates" If the Create/Update Block Icons function is executed, the block icons are derived from the plant hierarchy of the project by means of their names and priorities, copied from the templates, and automatically linked to the tag interface of the relevant operator panel. Priority Image name Remark starting alphabetically with the last picture is contained in the standard template The "@@PCS7Typicals.pdl" picture is included in every PCS 7 OS project by default. It contains the standard block icons. The "@@PCS7Typicals.pdl" original file must not be changed under any circumstances. Any changes to the original file will be overwritten when an update or upgrade is performed. Separate templates should be created for customer-specific block icons, "@PCS7Typicals*.pdl". See also "Use of template Online support under Entry ID "Copying pictures in the OS project editor", Online support under Entry ID Project-specific template A project-specific template, "@PCS7Typicals*.pdl", can be created by copying the template "@@PCS7Typicals.pdl". Customer-specific changes can then be made to the "new" template. A5E AA 75

77 Creating Application Software template The template is primarily used when block icons are inserted into pictures manually. These block icons are not connected to the plant hierarchy and are not, therefore, created or updated by the system. Anyhow, it can be helpful to use the template file. On the one hand you are not then linked to the plant hierarchy, and on the other hand you can use a wizard to export picture objects from one or all flow charts to a configuration file, modify block icons and their connections, and finally import the picture objects again. The configuration file can be edited using tools such as Excel. The "@Template.pdl" file is maintained by the PCS 7 system and is overwritten when an update or upgrade is performed. It is therefore advisable to back up the "@Template.pdl" file on a regular basis. Other Template Used to create/update lifebeat Used to create/update diagnostic The template contains a collection of predefined objects for creating block Used to create/update block icons for SIMATIC Used to create/update block icons for SIMATIC Route Control. This list is not exhaustive. Central changeability of picture objects In the type definition, SIMATIC PCS 7 allows objects to be changed centrally; in other words, subsequent changes to picture objects are made in the template pictures. The central changeability of picture objects does not mean that changes are automatically passed on/down to the instances. As a result, the "Export Picture Objects" function must be executed via the dynamic wizard before the changes are passed on; this ensures that all objects will be located at their original positions after "Import Picture Objects" is performed. 76 A5E AA

78 Creating Application Software Type Change in RUN (TCiR) TCiR is available as of PCS 7 V8.1 in connection with an AS410 CPU as of firmware version V8.1. TCiR enables changes to block connections (inputs, outputs) to be downloaded from blocks in running operation. This functionality can only be used to a limited extent, due to the necessary validation procedures in the pharmaceutical industry, meaning that the effects of such a change must be known and easily controlled. A possible application could, for example, be an ultra-pure water plant in a group of plants. 6.2 Bulk engineering Bulk engineering with the process object view If this involves checking or changing numerous parameters quickly, this can be performed in the Process Object view. Using this, parameters can be filtered by certain criteria and their values viewed and processed. The Process Object View enables searching of charts throughout the entire multiproject Bulk engineering with the IEA The Import/Export Assistant (IEA) is used for two tasks. Duplication with the IEA The Import/Export Assistant is used to duplicate process tag types or models. For this, project-dependent typicals are defined on the basis of standard libraries; these typicals can then be copied as instances as often as required using the Import/Export Assistant. A5E AA 77

79 Creating Application Software Engineering Shared declarations Model: create / test UNIT Model: create / test Technical functions Technical fct. 1 User blocks create / test Tag type: create / test Basic functions Basic fct. Heating Basic fct. 1 Basic fct. 2 Basic fct. 1 Basic fct. 2 Basic fct. n Technical fct. 2 PCS 7 Library Basic fct. n Master Data Library Bulk engineering with IEA Technical fct. n Application software Unit Heating Technical fct. 1 Unit 4711 Basic fct Heating Technical fct. 1 Basic fct. 1 Basic fct. 2 Basic fct Heating Basic fct. 2 Basic fct. 1 Basic fct. n Basic fct. 1 Basic fct. 2 Basic fct. 2 Basic fct. n Technical fct. 2 Basic fct. Basic 2 fct. n Basic fct. n Technical fct. 2 Technical fct. n Basic fct. n Technical fct. n The modular software structure and the process of duplication using the IEA significantly reduce both the risk of errors occurring and the engineering and testing effort required. Parameter editing with the IEA Furthermore, the IEA File Editor is used to enter parameters and signal processing in a table for each instance in accordance with the definitions contained in the specifications. 78 A5E AA

80 Creating Application Software The Import/Export Assistant is managed as a separate optional package in SIMATIC PCS 7. It is included on the PCS 7 Toolset DVD and installed as part of the general setup, although it does require a separate license. See also Manual "PCS 7 Engineering System", chapter "Creating process tags from process tag types (multiproject)", Online support under Entry ID Type/instance concept with the Advanced ES Like the IEA, the Advanced Engineering System (AdvES) is also an application for copying, editing, and importing software/hardware components using bulk engineering. For example, it is possible to import process tag and signal lists in AdvES. The plant hierarchy, signal settings, and parameter settings can be adopted automatically from the imported process tag lists and signal lists. The hardware (distributed I/O including channel assignment) can be generated from the signal lists. All software/hardware components configured in AdvES can be transferred to PCS 7 and used there. While duplication in the IEA is limited to copying (usually a one-time operation), the type/instance concept also provides a tool for subsequent maintenance of types (control module types, CMT) and their associated instances (control modules, CM). Comparison of the AdvES with the IEA User interface When configuring with AdvES, the program guides the user through the various configuring steps. For this, the user interface of AdvES features a progress display consisting of various steps. The user is shown which step is currently active. The steps must be processed in a logical sequence one after the other. Only one step at a time can be processed. All preceding steps and following steps are blocked from processing. This minimizes the risk of errors when configuring. The processing status of the project can always be recognized. This is especially important in the case of multi-user engineering, when several persons are working on the project, or if the work in the AdvES had to be interrupted. Type/instance versus copying If a typical is changed subsequently in the IEA, this requires a complete re-import of the "instances" (copies). This means that parameter assignments and interconnections to other functions or higher functions will be lost and that postprocessing including validation is required. On the other hand, users can change existing, and possibly already instantiated, CMTs in the AdvES at any time. Previously generated CMs can be checked for deviations from the CMT and the changes can be adopted. As result, configuring of CMTs is more flexible than configuring of IEA typicals. A5E AA 79

81 Creating Application Software Type variants with optional blocks When configuring a CMT, it is possible to insert optional blocks. For generation of CMs, it is possible to specify whether optional blocks are to be used and, if so, which ones. This produces classes and subclasses during the typical creation. Thus, for example, a valve with an interlock block and another valve without an interlock block are generated from the same CMT. With the IEA, two typicals would be necessary for these two valves. When the IEA is used, up to 8 typicals, depending on the combination, would have to be created and tested, as opposed to a single CMT with, for example, three optional blocks. Configuring with AdvES Following installation, AdvES is contained in SIMATIC Manager and is opened there. You select and right-click a project to open a menu that contains the "Open project in AdvancedES" option. When AdvEs is opened the first time, an AdvES project is created automatically and linked to the PCS 7 project from which it was opened. After AdvES is opened, the existing relevant hardware and software components (plant hierarchy, etc.) must be imported in AdvES. The project will then be released in AdvES for processing. AdvES guides the user through the various configuring steps using a progress display. The user can generate CMTs from a process tag type from the master data library or create completely new CMTs. CMTs can contain individual control units, control tags, and messages. Both the green colored block headers in the following figure and the top area of the image illustrate that a CMT is involved. 80 A5E AA

82 Creating Application Software Individual control unit types, their attributes, individual control units, control tags, and messages can be processed in AdvES. CMs are generated by copying a CMT to the plant hierarchy. It can be specified for each CM whether optional blocks will be used and, if so, which ones. After the project is processed in AdvES, all relevant data are exported back to the PCS 7 project. Further processing of the project takes place in SIMATIC Manager. See also Manual "PCS 7 Advanced Process Functions Engineering System", Online support under Entry ID "High-performance mass data engineering", Online support under Entry ID Creating process pictures Process pictures must be created in accordance with the definitions contained in the specifications (e.g. URS, FS, and P&ID). Similarly to all the other work steps in the GMP environment, initially planning, then implementation and subsequently testing is performed. Block icons should be assigned using the "automatic generation of block icons" function, which means one block icon is assigned to each instance-specific module (valve, pump, closed-loop controller, etc.) in the process picture using the IEA file. The picture and the block charts must be configured in the same plant hierarchy folder, or in plant hierarchy folders with the same name, in order for block icons to be generated. A5E AA 81

83 Creating Application Software After the graphics are created, they should be submitted to the customer in the form of screenshots for approval. See also Chapter "Automatic generation of block icons" for information on using template pictures as a library Manual "PCS 7 Compendium Part A", chapter 9.2 "Visualization interface" Online support under Entry ID User-specific blocks and scripts User-specific blocks (FB, FC) and scripts (C, VB) are programs written and created by the user, which are assigned to GAMP software category 5. This type of software was developed to meet customer-specific demands not covered by existing functions and libraries. In general with such customized blocks and scripts, a greater effort for validation must be calculated for detailed functional and interface descriptions as well as documented tests; see also chapter "Software categorization according to GAMP Guide". When user-specific blocks and scripts are created, the rules for creating software elements should be defined in instructions specific to the project/department (coding standards, PCS 7 style guide, etc.). See also Manual "PCS 7 V7.0 Programming Instructions for Blocks", Online support under Entry ID Manual "PCS 7 Compendium Part A", chapter "Creating user-defined technological blocks" Online support under Entry ID Interfaces to PCS PCS 7 OS Web option This option enables PCS 7 system processes to be controlled and monitored via an Internet/Intranet connection. One PCS 7 OS Web server and at least one PCS 7 Web client is required. Within a PCS 7 OS multiple station system the PCS 7 OS Web Server is installed as an OS client with PCS 7 OS Web Server functionality. It should not also be used as an operator station (OS client). This can be ensured by deactivating graphics runtime. The WebViewer is installed automatically when the Web client is installed. For remote access, it is advisable to use this in preference to the Internet Explorer since the WebViewer can be custom configured. The Web server itself should be certified so that access to Web server functions is secure, authenticated, and encrypted (keyword: https access). 82 A5E AA

84 Creating Application Software All pictures and required scripts are stored on the OS Web server so that they can be displayed and run on the Web client. All pictures and scripts must be published. The "Web View Publisher" is used for this. See also Manual "PCS 7 OS Web Option", chapter 4.4, Online support under Entry ID , Manual "PCS 7 V7.0 Programming Instructions for Blocks", Chapter "WebClient (differences compared to WinCC)" Online support under Entry ID Manual "PCS 7 Compendium Part A", Chapter 9.2 "Visualization interface", Online support under Entry ID "Operator actions via WebNavigator", Online support under Entry ID If scripts are used, preference should be given to event-controlled script editing wherever possible, as it saves on resources. By contrast, cyclic scripts should only be used on a specific basis as needed. SIMATIC Logon must be installed on the Web server, thus integrating the Web client into the SIMATIC Logon functions. As a result, access to the Web client is password-protected. User permissions are assigned in the OS User Administrator. They correspond to those of standard clients, the only additional requirement is that the Intranet/Internet access option must be enabled. See also Chapter 4.6 "Data and information security" "Security Concept PCS 7 and WinCC", Online support under Entry ID Load Balancing Functionality When several Web Navigator servers are used, the "Load Balancing" functionality enables an even load balance among the servers. In addition, the Web Clients are automatically redistributed among the other Web Servers if one of the Web Servers fails. This works by selecting a Load Balancing server in advance from the participating Web Navigation servers. If a Web Client then logs on to a Load Balancing server, this server assigns the Web Client to the server with the lowest load. To make use of the functionality, one "Load Balancing" license per Web Server is required. Up to 32 Web Servers can be networked together. No additional license is needed for the clients. For WinCC computers, it is sufficient to have a "WinCC Redundancy" license with the "Load Balancing Step-Up" license. The "WinCCViewerRT.exe" application does not support the "Load Balancing" function. To make use of the Load Balancing functionality, it must be configured on each participating Web Server. The WinCC Basic system and the Web Navigator server A5E AA 83

85 Creating Application Software must be installed for this. The Web Servers must be set up identically (applies also to the user administration), and the standard website must be set for Web Navigator. The configuration of the Load Balancing function must be opened in WinCC Explorer using the shortcut menu of the Web Navigator. The window that opens must list each individual Web Server using its IP address. For the Load Balancing server, the "Allow Load Balancing" check box must be selected and a polling interval must be set. Web Servers with a "Web Navigator Diagnostics Server" license must not be listed as a Load Balancing participant. Thin Client In PCS 7 V8.0 and higher, a thin client solution allows the terminal server and the Web Server to be operated on one computer. In this case, a terminal session is opened on the terminal server for each thin client. The thin clients can then access the terminal server and Web Server using the Remote Desktop Protocol (RDP). Because this is a server-based functionality, a user does not have to be logged on to the terminal server. A thin client solution is easy to maintain because changes only have to be made once on the terminal server and are then available to every thin client. See also "Thin Clients", Online support under Entry ID OS Client in a virtual environment On high-performance computers (see VMWare system requirements under it is possible to create multiple virtual environments. These then serve as the basis for an OS Client, irrespective of the actual hardware. OS Clients are shared in a virtual environment. The use of VMWare ESXi visualization software is supported. Various operating systems can be run on the virtualization, such as Windows NT, Windows 2000, Windows XP, and Windows 7 32/64-bit version. When an OS Client is operated in a virtual environment, the following limitations must be anticipated. Multiple virtualizations can run simultaneously on a VMware ESXi, but only one Remote Desktop Connection per virtualization is possible. Multi VGA cards are not supported. In addition, the horn functionality as well as USB connections are not supported. This must be noted, for example, for programs that are licensed using a USB dongle. See also "Virtualization in PCS 7", Online support under Entry ID A5E AA

86 Creating Application Software Open PCS 7 Open PCS 7 makes PCS 7 data available to higher-level systems, such as the plant control level. The standard interfaces below are available for exchanging data between Open PCS 7 stations: OPC UA (Unified Architecture) OPC "Classic" OPC DA (Data Access) OPC A&E (Alarm & Events) OPC HDA (Historical Data Access) OPC H A&E (Historical Alarm & Events) OLE/DB for applications with OLE capability, such as MS Office products; OLE/DB permits access to historical values, alarms, and messages via standardized database calls The Open PCS 7 station can be used to access several redundant server pairs. If a server fails, the Open PCS 7 station performs redundancy switchover automatically. If the active server fails, the station switches to the remaining server automatically, so that this server carries out the next read job. An uninterrupted read job is repeated on the server which is then active. A connection via OPC UA (Unified Architecture) offers increased security in data communication in comparison to the OPC DA connection. OPC UA Server and OPC UA Client both provide a certificate. These certificates must be exchanged and accepted by the connection partners. Only then can data communication take place successfully. Access to the station OPC interface Data type OS server UA Process values and messages OS server DA Process picture tags OS server A&E Alarms and messages (Alarm Logging) OS server HDA Historical measured values (Tag Logging) OS server H A&E Historical alarms and messages (Alarm Logging) OS server OLE-DB Direct access to archive data See also Manual "Open PCS 7", chapter 7.1 "Access options", Online support under Entry ID Advantages of OPC UA compared to previous OPC specifications are: Integrated security concept (authentication and authorization, encryption and data integrity) Independent of DCOM, no DCOM settings are required Independent of operating system, independent of manufacturer Unification of the previous OPC standards to form one interface; one common OPC standard for tags, alarms, and historical data Communication via a single firewall port A5E AA 85

87 Creating Application Software The OPC connection should not serve as an extended operating source, but essentially as data evaluation or information. When establishing an OPC connection, particular emphasis must therefore be placed on data security and the assignment of write authorization should be carefully performed. The PCS 7 OS Web Option should be selected for possible operation from outside the PCS 7 environment, see chapter SIMATIC BATCH API The SIMATIC BATCH interface provides the following function calls as the programming interface: Access to BATCH objects and data Navigate through SIMATIC BATCH object hierarchies Notifications about events A field of application is the data interface for transmission of events and methods (e.g., CreateBatch, ArchiveBatch, GetParameter, etc.) to an MES level. The option also exists to reference the interface directly via "SAP" or to use the SIMATIC API via separate software solutions. 6.6 Recipe control with SIMATIC BATCH SIMATIC BATCH is a software package for PCS 7, which structures discontinuous processes, known as batch processes. SIMATIC BATCH is used to graphically design, plan, modify, control and monitor recipe structures. A major advantage of the batch production is the collection and archiving of production data. These production data are needed for both the regulatory requirements for traceability (audit trail) as well as for operational analysis of the production process. 86 A5E AA

88 Creating Application Software Batch definition of terminology Some commonly used batch terminology is described below. Term Description Master recipe Set of rules and information required to define how a product is manufactured. Control recipe Batch Process Copy of the master recipe with extra information specific to a process cell. Equipment-dependent amount of a product manufactured in a defined, discontinuous production sequence. A sequence of chemical, physical, or biological activities for manufacturing materials or products Conformity with the ISA standard ISA-88, also known as S88, is an international standard for batch control, which represents the design specifications for software, equipment and operation of the processing. SIMATIC BATCH was developed on the basis of the ANSI/ISA (1995) Batch Control, Part 1: Models and Terminology standard. One of the recommendations contained in the "Technical Report" ISA-TR is the use of SFC (Sequential Function Charts, DIN/IEC 1131) as a graphic language for describing recipe procedures. Recipes created with the BATCH Recipe Editor follow the structures and functionalities described in this standard. SIMATIC PCS 7 software model ISA describes various models, which can be fully implemented with PCS 7 and SIMATIC BATCH. The process cell model (physical model) describes the process cell, unit, equipment module, and device control level, which is mapped using the plant hierarchy in the plant view of SIMATIC Manager. A5E AA 87

89 Creating Application Software In SIMATIC BATCH, the procedural model (procedure, unit procedure, operation, phase) reflects the process cell model from the point of view of the control sequence. Term Recipe procedure Recipe unit procedure Recipe operation/recipe phase Control-loop level Description A recipe procedure runs in a process cell to control a process and to create a batch of a product. A recipe unit procedure runs on a unit to control a recipe stage. A unit can only be occupied by one batch at any one time. A recipe operation or a recipe phase runs on an equipment module to implement a process engineering task or function. The control-loop level is not within the scope of the BATCH system and is addressed only via the equipment module. It is entirely located in the automation system. Application of the ISA standard in SIMATIC PCS 7 The ISA software model divides the process into various modules, simplifying the process of validation. The process is split up hierarchically into the following parts: Physical model Plant Process cell Graphic Procedural elements Procedure Procedure Implementation in PCS7 BATCH component: Recipe Implemented by Operator / supported by supplier Sequence Unit Unit procedure Unit procedure(s) CFC component: Unit block BATCH component: Unit recipe Operator / supported by supplier System equipment Equipment module (EM) Control Module (CM) Control module (CM) Recipe operation / SFC type component: phase Use of SFC types to Recipe operation / allow instantiation. phase (equipment phases, (may contain equipment operations) control strategies) - CFC component: Use of the PCS 7 library and of CFCs Supplier / supported by operator Vendor The names and functions of the modules correspond to the definitions contained in the specifications. See also Operating Manual "PCS 7 SIMATIC BATCH V8.1" (SP1)", Online support under Entry ID A5E AA

90 Creating Application Software Configuring SIMATIC BATCH Basics and options of SIMATIC BATCH are explained in chapter "SIMATIC BATCH basics and options". See also Manual "Getting Started PCS 7 SIMATIC BATCH", Online support under Entry ID Manual "PCS 7 Compendium Part C", Online support under Entry ID The individual configuring steps are divided into the following: Working in SIMATIC Manager Creating and configuring BATCH systems Creating the plant hierarchy Compiling OS data Generating BATCH types (SFC type) Propagating BATCH types Compiling instances Transferring data to OS Loading process cell data Working in the BATCH Control Center (BCC) and Recipe Editor (RP) Reading batch data Creating master recipes Creating the recipe structure Releasing master recipes for production Creating an order Releasing a batch Creating ROP libraries, formula categories, and formulas Exporting/importing recipes, parameter sets, etc. (optional) See also Application examples for specification of technical functions with SFC types as well as instantiation, Online support under Entry ID Functions and settings in SIMATIC BATCH Various functions and project settings can be used in SIMATIC BATCH. These settings are described in detail in the relevant system documentation. A number of settings are presented in the following. For detailed versions, see "SIMATIC BATCH V8.1 SP1" in chapter Predefined batch names With the "Use predefined batch names" function, batch names can be automatically created from various static and dynamic elements. A5E AA 89

91 Creating Application Software The length of the batch name is restricted to 32 characters. Recipe step specific set-points Within the defined equipment limits, the range for set-points can also be limited for each recipe step. This means that the process can be guided better and the quality of the final product is increased. Editing of recipes with 'Release revoked/invalid status" With the "No" setting, you prevent recipes in 'Release revoked/invalid' status from being re-released with the same name/version. The default setting is "Yes" and should be set to "No" in the regulated environment. Automatically release batches Newly added batches are automatically released upon creation for production. The default setting is "No". For the setting "Yes", the user saves a separate release step, which may make sense for other authorizations. A configured signature is requested for the release even when using automatic system release. Exporting/importing of batch objects For the export/import of Libraries Master recipes Formula categories and formulas see Operating Manual "SIMATIC BATCH V8.1 (SP1)", chapter 8.5.8, Online support under Entry ID A5E AA

92 Creating Application Software Online structure changes for recipe structures SIMATIC BATCH allows you to change recipe structures in both hierarchical recipes and flat recipes. This applies to control recipes that have the status "released", "planned" or "started". Online structural changes are an additional functionality for master recipes during testing. They serve to simplify the optimization of recipes. Online structural changes are not possible during production (master recipe released for production). Default setting is "No". Settings for performing online structure changes The master recipe has the status "Release for testing". The user must have the "structural changes" permission. The check mark must be set for "Allow online structure change" in the project settings. If the option "Active batches have to be held" is selected, this provides protection by bringing the current batch to a safe state when changes are made to recipe structures. Once the change is made, the batch must be resumed by the operator. If the option "Active batches have to be held" is disabled, the change can be made during ongoing operation, which has the disadvantage that the batch automatically applies and enables the changes when the changes are made. s and restrictions When online structure changes are being made to a batch, access to this batch by other clients is blocked. A visual comparison of the changes to all Batch clients is made once the online structure changes are complete. It is advisable to stop the batch for structural changes. If a structural change is made without stopping the batch, a complete reporting cannot be ensured. A5E AA 91

93 Creating Application Software Deleting a canceled batch Attention should be given, for example, to the point "Permit deletion of completed, not archived batches". This means that canceled batches can be deleted without archiving the data. This is only rarely desired in the pharmaceutical environment. This setting should therefore remain deselected, unless the customer expressly requests otherwise. Additional settings in SIMATIC BATCH Important parameters and settings are also contained in Chapter on the topics of "Audit trail and change control" Chapter "Electronic signature in SIMATIC BATCH" Messages in SIMATIC BATCH All messages for the batch control, which are managed in the WinCC archives, can also be displayed on the SIMATIC BATCH Client. The requirement is that a PCS 7 OS application is running on the computer. See also Operating Manual "SIMATIC BATCH V8.1 (SP1)", chapter "Display of operation and status messages" and chapter "Display of warning and error messages", Online support under Entry ID Creating batch reports The SIMATIC BATCH report ensures the documentation of recipes and batch data in the form of logs: The recipe report contains all the data required for production. This includes the recipe header data, the input materials and output materials list and the procedural rules. The batch report contains all the information required for the reproducibility of the batch process, quality assurance and the fulfillment of legal requirements. The reports can be automatically saved as a PDF file. The report is integrated in the user interface of the Batch Control Center. See also Operating Manual "SIMATIC BATCH V8.1 (SP1)", chapter and chapter 8.9, Online support under Entry ID SIMATIC Route Control SIMATIC Route Control is a program package of SIMATIC PCS 7, which is used for automated transport of materials in plants. Typical application examples include: Transport of solids and liquids Buffer applications and provision of buffers for production Bio-reactors, such as cell culture plants with upstream and downstream CIP and SIP procedures with various flushing paths 92 A5E AA

94 Creating Application Software A Route Control server is needed in order to use SIMATIC Route Control. Route Control servers can have a redundant configuration. SIMATIC Route Control is configured on the SIMATIC PCS 7 engineering station. The following figure illustrates the individual configuring steps. The use of SIMATIC Route Control becomes economical with as few as 5 parallel material transports. The main benefit of this is in engineering. The engineering is similar to the configuration of SIMATIC BATCH. With the SIMATIC Route Control Center, routes and partial routes are easily assembled. The easy-to-understand visualization in SIMATIC Route Control Center makes it easy to allocate production and cleaning paths, whereby the work involved in validation is significantly reduced. Furthermore, the material tracking is ensured by SIMATIC Route Control (Route Control Log). Particular requirements for SIMATIC Route Control: Testing of material compatibility Alternative transfer paths in case of malfunction (automatic) Status check of line Scaling depending on plant size A5E AA 93

95 Creating Application Software See also Programming and Operating Manual SIMATIC Route Control (V8.1), Online support under Entry ID Description of the product on the Internet which includes e-learning under Import / export You can use the CSV interface (CSV export/import) to simplify and accelerate configuring in Route Control. For example, partial routes and additional data can be edited conveniently in Excel and then imported in Route Control Engineering. The option to edit data in Excel can also be used to efficiently define routes in the specification phase and then import them. Graphical route search Another added feature is the graphical route search. This can be used to check route networks graphically. In addition, routes can be saved and stored as preferences instead of being called using the automatic route search. 6.8 Alarm management An alarm system must be able to perform the following basic functions: Warn the operator in the event of problems in the plant Provide information about the characteristics of the problem Guide the operator to the most significant problem Support the operator in evaluating multiple pending problems Specification The specification of an alarm system includes the following: Definition of formats for alarm line and alarm page Message classes, colors, and priorities Acknowledgment concept (e.g. single acknowledgment) Event texts, e.g. "too high" for a high alarm 94 A5E AA

96 Creating Application Software Process-dependent alarm suppression, e.g. suppression of flow monitoring if a pump is switched off These points must be defined if they deviate from standard specifications. The preassigned standards for displaying message classes, colors, and priorities should be retained if possible and only be changed upon customer request. If the alarm system configuration differs from the standard configuration, the differences must be documented and an update procedure described; see also chapter 10 "System Updates and Migration". See also Manual "PCS 7 Compendium Part A", chapter "Changing the message class, priority and message text" Online support under Entry ID Message classes The different message classes, such as fault, alarm, warning, or process control message are usually defined on a function and event-specific basis. For example, if a measurement is taken, reaching the high limits will trigger an alarm, the low limits a warning, and a runtime error on a valve, for example, will trigger a fault message. See also Manual "PCS 7 Compendium Part A", chapter "Message classes and message types", Online support under Entry ID Priorities To ensure that the plant operator can still perform actions even in critical situations, messages can be additionally prioritized in PCS 7 in accordance with their possible effect (plant standstill, reduction in product quality, or production delays) and the available reaction time (e.g. < 5 minutes, 5 20 minutes, > 20 minutes). The priority is defined on an instance-specific basis in PCS 7 during message configuration and is initially set to "0". It is preferable for the priorities to be set in the process object view. A5E AA 95

97 Creating Application Software Suppressing, filtering, hiding Locking messages When the appropriate permission is granted, in process mode the plant operator is able to set individual process tags to the "out of service" status, thus suppressing all messages of this process tag. This function is used, for example, if a process tag is being used for the first time. The operator can use this feature to suppress messages which are of no immediate use, allowing him to focus his full attention on the relevant messages. On all levels, operators are able to identify objects whose message reaction has been suppressed. Filtering messages Message filtering within alarm lists can be adapted on a user-specific basis. The filter criteria are message properties (date, time, message class, message text, etc.). The point of changing filter criteria online is to enable the user to temporarily focus on a particular period, event, etc. when analyzing errors. Hiding messages (Smart Alarm Hiding) This function allows alarms to be hidden on a situation-specific basis. These messages are not taken into account when generating the collective status, i.e. the collective status of a measurement with a pending, hidden alarm does not indicate an alarm status in the process picture, is ignored when the collectivestatus display is generated for the diagram, and does not output an audible signal (alarm horn). The currently pending, hidden messages can be viewed at any time in the list of hidden messages. All messages hidden by the current setting are summarized in the "Messages to be hidden" list. The messages are only hidden in terms of the display, i.e. hidden messages are still archived and taken into account during archive synchronization if a server redundancy failover is performed. "Smart Alarm Hiding" offers two ways of hiding alarms: Manual hiding and displaying of alarms Automatic showing and hiding of alarms, depending on process states Hiding alarms manually: The alarms are shown again after a defined period of time has elapsed. Manually hidden alarms are acknowledged automatically. Manual alarm hiding applies to all clients of the relevant OS server. An operator message is triggered if alarms are hidden and shown manually. 96 A5E AA

98 Creating Application Software Hiding alarms automatically: Automatic alarm hiding must be configured and is always controlled via status blocks in the AS, which hide or show state-dependent alarms in conjunction with a hiding matrix. Technological (messaging) blocks are assigned to a status block via the new "block group" block property. The main difference between message suppression and alarm hiding is that suppressed (blocked) messages are not even generated at the respective process tag and they are therefore not sent to the OS. Neither are they recorded or archived. Alarm hiding, on the other hand, only affects the visualization Monitoring PCS 7 components Lifebeat Monitoring SIMATIC PCS 7 Lifebeat Monitoring allows the functionality of automation and operator stations to be monitored. To facilitate this, all automation and operator stations must be configured in HW Config and the OPC connections to the operator stations must be created. To configure the nodes to be monitored in WinCC Explorer, select the menu command Editor > Lifebeat monitoring > Open. Here, all the nodes to be monitored and the monitoring cycle in which lifebeat monitoring will be performed can be configured. The lifebeat monitoring is activated automatically when the OS starts up. Alternatively, all process control equipment can also be managed in the PCS 7 Asset Management. A maintenance station (MS) provides an overview of the diagnostic and service information for all equipment. Asset management does not require any additional configuration. The configuration data are generated from the hardware and software configuration data, see also chapter "Asset Management". A5E AA 97

99 Creating Application Software Monitoring PCS 7 components SMMC The SIMATIC Management Console (SMMC) is a program package, which supports the monitoring, documentation and management of the hardware and software installed. To use the SMMC, the software package is to be installed on a PC. In doing so, either a separate computer or the existing ES should be used. The "SIMATIC Management Agent" is also to be installed on computers to be managed. The SMMC can now be used to created detailed reports on the currently installed hardware and software. The data required for this purpose is taken directly by the SMMC from computers and AS systems of the plant. The documentation always corresponds to the actual "As Built" state of the plant. The authorizations for the SIMATIC Management Console must be set up separately, for this purpose see "SIMATIC Management Console (V8.1), chapter 3.1 "Managing rights"; Online support under Entry ID Monitoring connected systems Lifebeat monitoring for connected systems must be configured manually. Its use depends on the corresponding communication partner. If the connected system represents an important interface to SIMATIC PCS 7, lifebeat monitoring is absolutely necessary. Coupling third-party systems to PCS 7 via Ethernet and OPC The graphic shows an example of a solution for lifebeat monitoring with a thirdparty system. SIMATIC PCS 7 sets a defined OPC variable bit from logic 0 to 1. After a defined period of time X, the connected system must reset the OPC variable bit from logic 1 to 0. This operation is repeated in cycles. If the connected system does not perform a state transition within the specified time, a process control message is generated in the SIMATIC PCS 7 process control system. This message indicates to the operator that communication with the connected system is not functioning correctly. 98 A5E AA

100 Creating Application Software 6.9 Audit trail and change control Traceability of operator intervention and critical parameters and data changes must be recorded with information about the operator (audit trail). The requirements of this topic are defined by 21 CFR Part 11 of the U.S. Food and Drug Administration, for example. In a controlled environment, changes to the project configuration or user management, for example, are subject to change control. This change control is supported by recording log files. In a PCS 7 system, this is implemented by a multilayered approach to the topics of audit trail and change control. OS Audit Trail / Change Log Operator entries System messages BATCH Audit Trail / Change Log Batch control Recipe administration ES Audit Trail / Change Log Download to CPU Project access SIMATIC Logon Audit Trail / Change Log Recording events, e.g. logon / logoff Auto logoff Password and change dialog Logon device (e.g. keyboard, smart card reader) Interface to 3rd-party and project-specific applications Windows Audit Trail / Change Log For system access (e.g., creating new users) PCS 7 ES Audit trail on PCS 7 ES Typically, configuration data on the engineering level is not directly subject to the extremely strict requirements of 21 CFR Part 11. Having said that, system components are usually concerned, which must be validated and controlled. The traceable online parameter change feature also enables certain quality-related data to be accessed directly via the ES. However, it is practical and advisable in a regulated environment for such interventions to only be performed on the operator control level with the corresponding operator permission. Such changes are then being recorded in the central audit trail of the OS. A5E AA 99

101 Creating Application Software Parameter changes made on the OS interface are not automatically transferred to the offline project. To do this, the relevant parameters must be selected and the function executed. Depending on the customer, controlled online parameter changes made via the ES may sometimes be accepted, or even desired, during the commissioning phase. However, once a plant has been validated, such parameter changes must only be made via the OS level or on the ES by means of a change request. See also "Labeling parameters for readback", Online support under Entry ID Change control of the ES configuration and ES project engineering The Version Cross Manager is suitable for controlling the offline configuration in the ES, when used in conjunction with a defined change process and an appropriate strategy for backing up project data. This enables different project versions to be compared against one another; see chapter "Version comparison with Version Cross Manager (VXM)". The current status of the offline/online configuration can also be verified by activating "test mode" in the ES. Parameter readback also has to be taken into account here, see "" above. Project access activities and online changes performed on the ES are recorded with the aid of the SIMATIC Logon change log, in a similar way to an audit trail (who has changed what and when). The following are logged: Events relating to access protection (open project, access to project denied, activate/deactivate access protection, etc.) Target system events (AS configuration loaded, software application loaded, online mode activated/deactivated) Events relating to online value changes (old value, new value) Version changes (archiving of versioned projects) 100 A5E AA

102 Creating Application Software Change control for AS download In addition to protection against unauthorized access to the ES configuration via the "Activate Access Protection" project setting, a CPU password can also be used to protect against unauthorized downloads to the CPU. However, as with online value changes, downloads made to the CPU are not recorded unless the change log file is activated, see chapter "PCS 7 ES" above regarding ES change control. The time at which this access protection should be activated and the activation of the change log file must be defined together with the customer at an early stage. Depending on the configuration environment, it may be practical to have access protection in place even as early as the configuration phase, with the change log file being activated at the start of the FAT. Once access protection is configured, you can often forgo the additional CPU password, if the customer agrees to it PCS 7 OS Audit trail in PCS 7 OS SIMATIC PCS 7 records all operations and parameter changes performed in process mode, assigning them to the "Operating messages" message class in the message archive. Acknowledgments of alarms, warnings, system messages, etc. are available in the history of the process control system. The figure below shows an extract taken from the operation list. The user ID of the user who is currently logged on can be seen in the overview area. If parameter changes are made via input/output fields, message output must be configured separately. A5E AA 101

103 Creating Application Software Select the hard disk capacity so that the entire audit trail can be stored there until it is exported to an external data medium. Change control for the OS configuration and OS project engineering The OS configuration, as well as the project engineering of OS elements (pictures, scripts, etc.), is versioned on the ES (SIMATIC Version Trail) and archived, together with the overall project. Changes made to individual OS elements must be controlled in accordance with the applicable change procedure following their initial release SIMATIC BATCH Audit trail in SIMATIC BATCH Operator actions performed in SIMATIC BATCH are recorded in the same message archive as OS operator actions (see above). A batch report containing information on the operator actions performed for each batch (who, when, what) is also created in SIMATIC BATCH. The changes to recipes, formulas, libraries, batches, and materials are documented in the change log (audit trail). Change control for recipes and batch objects The change control for recipes is supported by: Change log for essential processing steps Version assignment and release workflow including signatures Authorizations and project settings Recipe comparer Changes made to recipe data and batch data (deleted batches, for example) are logged in the change log; see previous chapter. The user, the time of day, and the action are entered in this log. 102 A5E AA

104 Creating Application Software To ensure consistent version management, the following project settings must be made: "System-aided versioning" option is selected and The property "Allow editing of recipes with 'Release revoked/invalid' status" is deactivated (default is "yes"). If these settings are made, the message below is output if a change is to be made to a recipe. The recipe can only be edited after "Save As" has been used: A5E AA 103

105 Creating Application Software -> The above setting ensures that once a recipe is released, it cannot be edited later without changing the version or name. See also "Saving recipes", Online support under Entry ID Operating Manual "SIMATIC BATCH V8.1 (SP1)", chapter "Versioning", Online support under Entry ID The Comparison of recipe objects in the BatchCC enables a comparison of various versions of master recipes, libraries and formulas. See also Operating Manual "SIMATIC BATCH V8.1 (SP1)", chapter "Comparing recipe objects", Online support under Entry ID If recipes are deleted, this is recorded in the log: 104 A5E AA

106 Creating Application Software 6.10 Configuration for electronic signatures If electronic signatures are to be used in a computer system instead of handwritten signatures, certain legal regulations must be complied with, such as those contained in 21 CFR Part 11 of the U.S. Food and Drug Administration, or even Annex 11 of the EU GMP Guidelines. Other laws and regulations define the actions of the process owner for which signatures are required. The process owner is always the one who decides the actions for which signatures will be provided electronically Electronic signature in SIMATIC BATCH With the installation of SIMATIC Logon an Electronic Signature package will also be available, whose basic function is to enable electronic signatures to be used in SIMATIC BATCH. The figure below shows the "Properties" dialog window for configuring electronic signatures. Two electronic signatures are required in this example; they are specified in the SIMATIC BATCH Recipe Editor in the "Configured roles" box. The project settings can also be used to make an electronic signature necessary for releasing recipes, parameter sets (formulas), and recipe operations, for example. A5E AA 105

107 Creating Application Software A comment can also be entered for each electronic signature; this comment can be forced in the mask shown above. In addition to these global project rules, object-specific rules can also be created for electronic signatures. The figure below shows some example signature rules for a batch. The settings are made in the recipe properties. 106 A5E AA

108 Creating Application Software The electronic signatures provided are stored in the change log of SIMATIC BATCH and are also available in the report. A5E AA 107

109 Creating Application Software Electronic signatures on PCS 7 OS There are different ways to configure an electronic signature for the operating level of PCS 7 OS. Example of a single electronic signature with SIMATIC Logon dialog SIMATIC Logon offers a dialog to specify an electronic signature. This dialog is opened if the Show Dialog function is called in a VB or C script. Example of a multiple electronic signature An application example for configuration of several electronic signatures for one dedicated action on PCS 7 OS is available in the Online Support. 108 A5E AA

110 Creating Application Software See also Application example "Configuring electronic signatures", Online support under Entry ID Further notes in "GMP Engineering Manual WinCC V7.3", Chapter 6.4 "Electronic signature" FAQ "Verifying a logged-on user" Online support under Entry ID Chapter "OPD User dialogs and electronic signatures" Electronic signature on PCS 7 ES Configuration data in the engineering system are subject to change control, and changes must be documented in a traceable manner. The requirements of 21 CFR Part 11 for audit trails and electronic signatures usually do not apply to engineering systems. If individual items of data or any inputs or changes made in relation to them have a bearing on quality, they must only be entered via the operator control level (OS) and, if required, assigned an electronic signature at that same location. A5E AA 109

111 Creating Application Software 6.11 Recording and archiving data electronically It is very important to provide consistent quality evidence relating to quality-relevant production data, especially for production plants operating in a GMP environment. The following steps are involved in electronic recording and archiving: Definition of data to be archived, the archive sizes and the suitable archiving strategy, see chapter Set up process value archives for the online storage of selected process values, see chapter Archiving batch data, see chapter Long-term archiving, definition of parameters for exporting to the archive server (time period or amount of storage space used), see chapter Determining the data to be archived Various factors, such as those listed below, must be taken into account when defining the archiving strategy and determining the required storage space: Definition of the data to be archived coming from different sources: process values, messages, batch data and batch reports, audit trail data, log files, etc. Definition of the relevant recording cycles Specification of the period of storage online and offline Definition of the archiving cycle for transfer to external storage In PCS 7, this data is stored in various archives: Process value archive "Tag Logging fast", archiving of process values <1 min Process value archive "Tag Logging slow", archiving of process values >1 min Message archive "Alarm Logging" OS and batch reports On top of this, in other parts of the system, further actions are monitored and recorded in log files or databases: Change log on ES level for "Downloading the target system" and online parameter changes SIMATIC Logon database "EventLog.mdb" Event Viewer under Windows Computer Management (logon/logoff activities, account management, permission settings for the file system, etc. according to the corresponding configuration) All the files mentioned (and others, if required) must be considered in the archiving concept Setting up process value archives The procedure for configuring a process value archive is broken down into the following steps: Creating the new process value archive and selecting the tags to be stored in the short-term archive. 110 A5E AA

112 Creating Application Software Configuring the process value archive by specifying or selecting access permission levels or the storage location, for example. The process value archive is used to record tag-related process values (analog and binary values) in a database in the form of a short-term archive. The size of the short-term archive is defined in the specifications (URS, FS, DS). The segments in the short-term archive must be created in such a way that they are exported at regular intervals, ensuring that no data can be lost. The process values and messages saved in the OS server can be exported to an external drive or transferred to an archive server for long-term archiving. Accumulated batch data and reports can also be passed on to the archive server by the BATCH server. If the connection to the archive server is interrupted, the data is buffered in the short-term archive of the station concerned. A5E AA 111

113 Creating Application Software The size of the database is determined by the number of process value archives and the process tags they contain. The size of each process value archive depends on the measurement with the fastest acquisition cycle. Cycle acquisition should be performed uniformly within a process value archive. It is therefore advisable to always store process tags with the same acquisition cycle (e.g. 500 ms, 1 s, 10 s, 1 min) together in one process value archive. As a result, a separate process value archive is configured for each acquisition cycle. Archiving cycles are specified in the process object view. The specification documents (process tag list, design specification, etc.) contain definitions for the following process value archive parameters, for example: Classification of messages which have a bearing on quality and those which do not Type of acquisition, cyclic, cyclic-continuous, upon change, etc. Cycle time Type of value (instantaneous value, average value, maximum value, etc.) See also System manual "WinCC: Working with WinCC", chapter 6 "Archiving process values", Online support under Entry ID Manual "PCS 7 Compendium Part A", chapter "Archiving Introduction" Online support under Entry ID Archiving batch data Batch data is stored in XML format in SIMATIC BATCH for long-term archiving. You can choose from several formats. A PDF report can be created regardless of the format. When specifying the archive path, it should be ensured that the batch data is stored in a directory "protected" by Windows security mechanisms or in a database and is therefore only accessible to authorized persons or systems. 112 A5E AA

114 Creating Application Software Long-term archiving on a central archive server Long-term archiving takes place on a standalone server PC (e.g. Process Historian), which can also be designed redundantly. It does not require a connection to the plant bus. It is used for the long-term archiving of messages, process values, and reports. Process values and messages exported from the OS archives as well as OS reports and batch data of SIMATIC BATCH can be displayed in the system later. Segment data remains available even after it has been copied to the specified backup location. The segment is only deleted if the associated "Time period of all segments" or "Max. size of all segments" parameter is exceeded for it. Network security For information on accessing from another network segment (Internet/Intranet), refer to Manual "SIMATIC PCS 7 and WinCC Security Concept". Integration in Lifebeat Monitoring The integration of the long-term server is the same as described in chapter "Monitoring PCS 7 components" for integration of SIMATIC PCS 7 components into Lifebeat Monitoring. An OPC connection simply needs to be set up, via which lifebeat monitoring can be performed. Audit trail Changes to archived data are generally not desired. By default, users only have read access to the archived data. The long-term server therefore does not support an audit trail in accordance with 21 CFR Part 11. All events, such as exporting of data to external media or failed exports, are nevertheless saved in a log file directory with the Process Historian. See also Configuration manual "PCS 7 Operator Station (V8.1)", Online support under Entry ID Manual "PCS 7 Engineering Compendium Part A", chapter 9.4 "Archiving", Online support under Entry ID "Calculation of storage space requirements", Online support under Entry ID Uninterruptible power supply (UPS) UPS systems are necessary so that process and audit trail data, for example, can continue to be recorded during power failures. The design of the UPS must be agreed with the system user and specified accordingly. The following items must be taken into consideration: Energy consumption of systems to be supplied Performance capability of the UPS Desired duration of the UPS battery backup The energy consumption of the systems with battery backup determines the size of the UPS. A further selection criterion is the priority of the system. Systems with higher priority are: A5E AA 113

115 Creating Application Software Automation system (AS) Archiving server Operator station (OS) server Operator station (OS) clients Network components In each case, it is important to include the systems for data recording in the battery backup. The system should also record the time of the power failure. The use of UPS systems is linked to the installation and configuration of software. The following must be taken into account: Configuration of alarms regarding power failure Determination of the time frame for shutting down the PC Specification of the time frame of the UPS battery backup The process control system must be programmed so that it is brought to a safe state after a specified buffer time in the event of a power failure Configuration of a UPS The following table contains an example of the configuration of an uninterruptible power supply for an operator station in a process control system. The same basic procedure can be used with automation stations. Cas e Action 1 Power failure <10 seconds Response The process control system computers are supplied by backup battery power of the UPS. An alarm using a digital input in the process control system documents the power failure. 2 Power failure > 20 minutes. Power returns after 25 minutes The process control system computers are supplied by backup battery power of the UPS. An alarm in the process control system documents the power failure and the shutdown of the process control system after 20 minutes. The UPS stops supplying power after a defined hold time to ensure that the process control system computers can restart independently after restoration of power. 3 Power failure > 1 hour The process control system computers are supplied by backup battery power of the UPS. An alarm in the process control system documents the power failure and the shutdown of the process control system after 20 minutes. The UPS stops supplying power after a defined hold time to ensure that the process control system computers can restart independently after restoration of power. 114 A5E AA

116 Creating Application Software UPS configuration via digital inputs In addition to the standard buffering provided by UPS devices, the option of monitoring the power supplies should be used. In this case, the phase is monitored via one or several digital inputs. The failure of the energy supply can be registered via alarm messages and archived during production in the batch report. This guarantees a complete record of the plant problems. UPS battery backup of load voltage The automation CPU is supplied with power by the UPS 24 V module both during voltage dips and longer power failures. The phase monitoring module monitors the status change during a power failure using a digital input that should be designed as a fail-safe input signal. If a power failure occurs, an additional alarm can be generated to inform the operator of the power failure (alarm message). By logging it in the message system, this power failure can be used for subsequent investigations. With power failure concepts, safe states can also be implemented immediately or after a certain delay (for example, equipment phase hold, establishing a safe plant status even after power has returned, etc.). A5E AA 115

117 Creating Application Software UPS battery backup of power supply In addition to phase monitoring, the OS server is also buffered by standard UPS 220 V modules. This ensures that the server continues to operate even after a power failure. UPS buffering informs the operator of the power failure, by means of alarm messages, for example. Safe states can be introduced by the operator or through automated concepts. The safe shutdown of the OS server can be indicated by PCS 7 alarm messages and initiated if the power does not return within a specified time. This functionality increases the system availability after power restoration MASTERGUARD UPS systems All MASTERGUARD UPS systems belong to the "online UPS" category. They supply an output voltage free of interference voltage, electromagnetic interference, frequency variations, and voltage distortion. More detailed information on the different MASTERGUARD ranges can be found in the SIMATIC PCS 7 catalog. 116 A5E AA

118 Support for Verification 7 Support for Verification The following graphic shows an example of a lifecycle approach. After creation of the system, it must be tested. GAMP5 calls this phase the "Verification". The aim of verification is documented proof from testing (e.g. FAT, SAT) to ensure that the system meets specified requirements (URS, FS). The terms "validation" and "qualification" are not replaced by this but rather supplemented. The areas covered by tests performed by the supplier and suitably documented can be used for the validation activities of the pharmaceuticals company. Various standard functionalities of SIMATIC PCS 7 can be used as support for such verification. 7.1 Test planning In defining a project life cycle, various test phases are specified. Therefore, basic 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 design, simulation) A5E AA 117

119 Support for Verification 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. A suitable test environment and time, as well as appropriate test documentation, can help to ensure that only very few tests need to be repeated, or even none at all. 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 Verification of hardware Tests are performed to verify whether the installed components and the overall system design meet the requirements of the Design Specification. This covers such aspects as component designations, firmware/product version, location, server and clients used, interfaces, etc. Printouts and screenshots can each be used as evidence. Use of the SIMATIC Management Console proves useful here. A visual inspection of the hardware can also be performed. Verification of field devices Field devices are specified and tested by means of the following information, for example: Identification of manufacturer and type Order number Function / installation location Process tag name / measuring range / unit of measure Connection type Address number The Asset Management from SIMATIC PCS 7 can offer support here. 118 A5E AA

120 Support for Verification Verification of the automation hardware Automation stations are specified and tested by means of the following information, for example: Identification of manufacturer and type Order number Number of racks Verification of the hardware components used (CPU, CP, etc.) Number of distributed I/O stations Interfaces to third-party systems Address number HW Config printouts and those with SIMATIC Management Console support the relevant documentation. The control cabinet documentation must also comply with HW Config. Verification of the network structure The information below is an example of the data which should be specified and tested for verification of the network structure: Name of station, PC, AS, clients, etc. Communication module, type of connection, and communication partner (Ethernet, PROFIBUS, serial, etc.) MAC address (when using the ISO protocol on the plant bus) TCP/IP address and subnet mask (when using clients) PROFIBUS addresses The SIMATIC NetPro configuration can be printed out. Verification of the employed PC hardware The information below is an example of the data which should be specified and tested for verification of the PC hardware: Manufacturer/type designation/essential components Additionally installed hardware components (additional network adapter, printer, etc.) Verification of the configured network addresses, screen resolution, etc. Utilities can read detailed information about the configuration of the computer and print it as a documented proof. SIMATIC Management Console can be used to perform this from a central point across the entire plant. A5E AA 119

121 Support for Verification 7.3 Verification of software Software categorization according to GAMP Guide According to the GAMP5 Guide, the software components of a system are assigned to one of four software categories for the purpose of validating automated systems. In terms of a PCS 7 system, this means that the individual components require different amount of effort for specification and testing depending on their software category. Category 1: Infrastructure software Scope of the testing: - Check and document the version number - Check and document the correct installation AS-OS Engineering Import/Export Assistant PCS 7 Library Version Cross Manager PCS 7 Faceplates WinCC Basic System BATCH Base BATCH ROP Library Route Control Base Basic installation including editors (CFC, SFC, Graphics Designer, Faceplate Designer, etc.) Check / read installation Check / read installation Check / read installation Check / read installation Check / read installation Check / read installation Check / read installation Check / read installation Category 3: Non-configured products Scope of the testing: - Check and document the version number - Check and document the correct installation - Function test Batch Server Redundancy Set up redundancy and check functionality WinCC redundancy Set up redundancy and check functionality Web Server Lifebeat monitoring Time synchronization (Time master, SICLOCK) SIMATIC PDM Basic Software SIMATIC Logon SIMATIC Management Console Set up and check Web connection Function test Set up time synchronization and check functionality Documentation of the configuration, test field components in IQ/LoopCheck Test in the context of access control and user permissions, user management Documentation of configuration, test access to managed computers 120 A5E AA

122 Support for Verification Category 4: Configured products Scope of the testing: - Check and document the version number - Check and document the correct installation and configuration - Risk-based test for proof of correct operation in the test environment and within the business processes Function block diagrams SFCs Graphics Designer, Alarm and Trend Control SIMATIC BATCH Engineering Process Historian Route Control Engineering OPC Server/Client, Open PCS 7 CFC templates (process tag types), CFC instances, FBD (function block diagram), LAD (ladder diagram) SFC Type / SFC Instances Graphics, faceplates, trend pictures, etc. Create and test recipes, unit recipes, equipment modules, etc. Set up archiving Configuring and testing routes Configure interface and test data therein Category 5: Customer-specific applications Scope of the testing: - Check and document the version number - Planning and releasing the design - Check and document the correct installation, the functions of the source code - Risk-based test for proof of correct operation in the test environment and within the business processes Create blocks WinCC scripts BATCH API Interface STL (statement list) VB and C scripts Applicative interface to SIMATIC BATCH While a PCS 7 system configured customer-specifically as a whole would usually have to be assigned to category 4 or sometimes even 5, the individual standard components to be installed (without configuration) should be treated in the same way as category 3 or 1. The configuration part based on installed products, libraries, function blocks etc. then corresponds to category 4. If "free code" is also programmed, this corresponds to category 5. Procedure for functions of category 5 Provision must be made to expend more effort for specification and testing: 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 operator control and monitoring capability 5. Creation of software in accordance with specifications and programming guidelines 6. Testing of the structure for compliance with programming guidelines 7. Testing of the function for compliance with the functional description 8. Approval prior to use and/or duplication A5E AA 121

123 Support for Verification Verification of software products During verification of the "Standard software products" in use, checks are made to verify whether or not the installed software meets the requirements of the specifications. These are usually products that are not specifically designed for a customer and which are freely available on the market, for example: Operating system SIMATIC PCS 7 software packages (OS Server/Client, Engineering System, etc.) SIMATIC options such as SIMATIC BATCH, SIMATIC Route Control, etc. Standard libraries Third-party software such as Acrobat Reader, MS Office (Word, Excel), etc. Operating system and other software packages The installed software can be verified by means of operating system functions. The information can be found in the Control Panel > Add/Remove Programs. All installed software components are displayed there. Installed SIMATIC software Installed SIMATIC software can be verified using the "Installed SIMATIC software" software tool. The tool provides information about the SIMATIC software currently installed on the computer; the listing can also be printed or exported. By using the SIMATIC Management Console, the installed software of all managed computers can be centrally recorded. The work involved in creating such documentation is therefore significantly reduced. 122 A5E AA

124 Support for Verification SIMATIC software licenses The SIMATIC "Automation License Manager" tool provides information on the licenses currently installed on the PC. For this, the partition of the PC on which the licenses are installed must be selected in the Automation License Manager. The available system licenses are then shown on the right side of the window. The SMMC also enables central access to the licenses of the managed computers. SIMATIC PCS 7 installation log When SIMATIC PCS 7 is installed, the current status of the installed system programs is saved in the "citamis.str" file. Retro-installations are also documented. Depending on the operating system installed, this file is located in either the "WINNT" or the "WINDOWS" folder. A5E AA 123

125 Support for Verification Verification of the application software During verification of the application software, checks are made to verify whether or not the created software meets the requirements of the specifications (FS/DS). You need to consult with the user to agree upon and create the test descriptions (for example for FAT/SAT). These descriptions must take into account the complexity of the software and the design specifications. The aspects listed below are usually tested; therefore this list can be used as a reference for qualification: Check the name of the application software Check the plant hierarchy (plant, unit, technical equipment, individual control element, etc.) Software module test (typical test) Check the communication with other nodes (third-party controllers, MES systems, etc.) Check all inputs and outputs Check all control modules (individual control level) Check all equipment phases and equipment operations (technical functions) Check the relationships between operating modes (MANUAL/AUTOMATIC switchovers, interlocks, start, running, stopped, aborting, completed, etc.) Check the process tag names Check the visualization structure (P&ID representation) Check the operator control policies (access control, group permissions, user permissions) Check the archiving concepts (short-term archives, long-term archives) Check the message concept Check the trends, curves Check the time synchronization If other blocks are needed in addition to the PCS 7 standard libraries in order to configure specific processes or functions, the block libraries (FB, FC, DB) of the PCS 7 Add-on catalog should be used if possible. If blocks created by the user are to be employed, significantly more work will be required in terms of specification, creation, and verification; this fact should be taken into consideration. The process object view can be used for testing revisions for verification purposes. The software versions can also be modified there (see figure). 124 A5E AA

126 Support for Verification Analyzing the CPU load Asset management can be used to analyze and document CPU utilization. CPU connection utilization Asset management can also be used to analyze and document CPU connection utilization. This can prove particularly relevant, for example, if certain reserves have been agreed with the customer. A5E AA 125

127 Support for Verification DOCPRO DOCPRO is a tool for creating and managing plant documentation. DOCPRO enables the structuring of project data, the editing in form of circuit manuals and the printout in a uniform print layout. As default, footers are available that comply with DIN The layout can however be adjusted to the requirements in the wide range Simulation for test mode SIMATIC PCS 7 enables the input and output variables of various blocks to be simulated. The simulation is important for test purposes, for example in the context of the FAT, because it allows the project engineer to influence digital and analog inputs and outputs in such a way that complex functions (e.g. temperature control) can be represented and checked. Enabling simulation Simulation for test purposes can be enabled at the channel input or channel output driver blocks. Using the example of a valve, simulation is enabled at the SimOn inputs, and the input can be simulated at the SIMPV_In input. Disabling simulation Enabled simulations should be documented in accordance with good practice. After conclusion of the test, all simulations must be deactivated before the plant operation is enabled. Where possible, central software switches, which are interconnected with all input drivers, can be configured for specific units to enable/disable simulation. On completion of the tests, this central switch can be deleted or disabled, thus switching simulation off from a central location. Forcing variables In SIMATIC Manager, one can compile inputs and outputs using a variable table and specify a value using the menu (Variable -> Force). It is also important here to deactivate the forcing again for ALL variables once the test has been performed. 126 A5E AA

128 Support for Verification SIMIT simulation software SIMIT enables a software test to be performed via a simulation platform, without the need for the actual field devices. SIMIT simulates field devices and facilitates versatile use of simple signal tests at the touch of a button, through to complex function tests (such as temperature control). Used in conjunction with the S7 PLCSIM PLC or SIMIT Virtual Controller (VC) simulation software, which emulates the CPU of an automation system, it enables software tests to be performed without an automation station or field devices and can be used by the software provider to perform the Factory Acceptance Test (FAT), for example. Use of SIMIT: I/O simulation Process simulation Virtual acceptance tests and commissioning support Operator training SIMIT is ideally suited for use on a test or simulation system. Almost all designspecific and functional errors can be detected early and remedied before the actual commissioning. In production, changes requiring validation can be simulated and tested beforehand, for example. See also Configuration-manual "SIMIT (V8.1)", Online support under Entry ID Configuration manual "SIMIT Virtual Controller", Entry ID SIMBA simulation hardware In connection with SIMIT software, SIMBA simulation hardware enables a software test without requiring field devices. SIMBA basically provides a hardware interface for SIMIT. SIMBA features PROFIBUS and PROFINET interfaces, which are connected to the AS in a similar way to PROFIBUS or PROFINET and simulate the hardware. The advantage here is that the real hardware interface of the AS is directly addressed, which makes the test more realistic. This increases the probably of discovering errors prior to commissioning and therefore reducing them. 7.4 Configuration control Versioning of projects with Version Trail SIMATIC PCS 7 Version Trail can be used to save and archive multiprojects, single projects, and project-specific libraries with a unique version ID. This is performed in accordance with the PCS 7 archiving procedure. Project-specific libraries are also backed up when a multiproject is archived and thus remain associated with the corresponding multiproject. A5E AA 127

129 Support for Verification SIMATIC PCS 7 Version Trail ensures continuous incrementing of the version according to validation factors. A completed version can no longer be changed. However, any archived version can be reloaded in the system using Version Trail or in SIMATIC Manager. Since GMP requirements demand that SIMATIC Logon be used, all relevant actions are saved with details of the logged-on user. Instructions Before a multiproject is archived, a check must be performed to ensure that no projects or libraries belonging to the multiproject have been removed. This is because only projects and libraries contained in the multiproject at the time of archiving will actually be archived. The projects to be archived must not be open in the SIMATIC Manager. In a validated plant, previous project versions can be read back (retrieved) only in exceptional cases and after joint planning with the plant operator. See also Configuration Manual "PCS 7 Engineering System (V8.1)" chapter Online support under Entry ID Online help of SIMATIC PCS 7, topic "Version Trail" The project structure is only adopted once when an archive is created. Subsequent changes in the actual project will not be adopted by Version Trail and must be handled manually. The representation in Version Trail does not affect the actual archiving. However, automatic archiving operations can only be created from the visible elements. Automatic archiving following download As of PCS 7 V8.1, the "Archive project after successful download" function is available. In doing so, when using SIMATIC Version Trail, once the project has been successfully downloaded, a project backup is made of the downloaded software version. 128 A5E AA

130 Support for Verification Automatic archiving in a time-controlled manner In PCS 7 V8.0 and higher, Version Trail also allows automatic archiving and versioning of multiprojects, projects, and libraries at defined times, including timecontrolled readback of block parameters. The Windows Task Manager initiates the execution of the respective jobs. For this it is necessary to select "Create archiving job..." in the shortcut menu of the desired object (multiproject, project, library). Only one single archiving job can be created for each object! If an archiving job already exists for an object, this procedure can also be used to modify it. In the displayed dialog window, click the "Create/edit archiving job" button to open the Windows Task Manager. Here, you can modify the parameters and initiate execution of the created jobs. In Windows Task Manager, double-click the relevant job in the "Simatic VT" folder to select it. This opens its properties. A5E AA 129

131 Support for Verification The appropriate settings must be made on the "General" and "Triggers" tabs. In so doing, special attention must be paid to the security options for the user account on the "General" tab. At this point it can be specified whether or not the user has to be logged on for the archiving to run and the privileges with which archiving will be run. The user under which the archiving was run then also appears in the version table in Version Trail. Descriptive information about the task should be entered in "Description" on the "General" tab. This includes the name of the action, the name of the versioned object to be archived, the name of the person who created the job, and the date the job is created/modified. The archiving job must now be activated in the "Create archiving job" dialog window. Here, it can also be specified whether the CPUs will be read back before the archiving operation. A notice appears on the screen 20 seconds before an automatic job is run. It can still be canceled during this period. Version Trail must not be open at the time a job is run, since this will prevent the job from running. Automatic readback The Windows Task Manager also initiates the automatic readback of online parameters if a corresponding readback job exists. This job can be created via the shortcut menu of a CPU. 130 A5E AA

132 Support for Verification The same procedure is used to create a readback job as for an archiving job. The only difference is in the selection of the readback scope. Here, it is possible to select between all parameters, parameters that can be controlled and monitored, or marked parameters. Manual archiving and readback Version Trail also offers the option to perform manual archiving and/or readback. To do this, "Archive..." or "Readback..." must be selected in the shortcut menu of the desired object. A5E AA 131

133 Support for Verification The respective dialog then opens. When manual archiving is performed, it is also possible to specify whether or not the CPUs are to be read back beforehand. A descriptive comment is helpful. Retrieving Archived objects (multiprojects, projects, libraries) can be retrieved at any time; see however the note at the start of chapter7.4.1 "Versioning of projects with Version Trail". The appropriate entry in the version project window of Version Trail must be selected, and the "Retrieve..." item must be selected in the shortcut menu. Delete The procedure used to retrieve archived objects can also be used to delete them. To do so, the "Delete" command must be selected in the shortcut menu of the selected entry. Only the selected entry is deleted. To delete all entries of a versioned archive, the appropriate element must be selected directly in the tree structure and the "Delete" command must be selected in the shortcut menu. 132 A5E AA

134 Support for Verification Comparing archived projects The Version Trail interface enables archived projects to be compared with one another or with online versions. Version Trail makes use of the Version Cross Manager here, by calling it and displaying any differences, see chapter "Version comparison with Version Cross Manager (VXM)" for more information. Version history SIMATIC PCS 7 Version Trail manages all actions relating to a versioned project, such as creating, archiving, and deleting versions, in the version history. The version history can be called up using the Options > Version Trail menu. All actions relating to the archiving of projects and deletion of versions are logged. The figure below shows the version history, from the creation of versioned project to the archiving of different versions. When using SIMATIC PCS 7 Version Trail for continuous archiving, the version history is a good way of documenting different software versions during an automation system s life cycle. All software versions are listed in chronological order, together with their archiving date and version. This ensures that the latest software version can be copied back in case the application software got lost Recipe comparison The Comparison of recipe objects in the BatchCC enables a comparison of various versions of master recipes, libraries and formulas. See also Operating Manual "SIMATIC BATCH V8.1 (SP1)", chapter "Comparing recipe objects", Online support under Entry ID A5E AA 133

135 Support for Verification Version comparison with Version Cross Manager (VXM) The Version Cross Manager compares the following objects within projects: Library Hardware configuration CFC/SFC engineering data such as charts, types, chart folders, block folders Shared declarations Block sequences S7 program S7 blocks S7 symbols Messages The projects to be compared are executed synchronously, i.e. the object trees of the corresponding software structures are compared attribute by attribute. Any differences detected by the comparison are highlighted in color in a results tree and can be printed in PDF format. The color display setting can be customized. The Version Cross Manager retrieves the archived projects in a temporary folder for the comparison and then deletes them after the comparison. 134 A5E AA

136 Support for Verification Saving or printing differences between projects The differences between projects detected by the comparison can be saved in a.csv file or printed out. The following information is displayed: Additional objects contained in project A Additional objects contained in project B Differences between project A and project B Application examples for the VXM Case 1: The Version Cross Manager can be used to verify that a change has been implemented correctly in the context of the change control system, for example. By comparing the software version before the change with the current program version in the CPU of the automation system, the changes in the system are identified. These changes must match the specified changes. Case 2: The VXM can be used to demonstrate that an archived software version matches the current program version in the CPU of the automation system. Without a change request, deviations between the software backup and the CPU are not permitted. For information on operational change control, see chapter 9.2 "Operational change control" Configuration control with "versiondog" The PCS 7 Add-on "versiondog" combines the functionalities of SIMATIC Version Trail and Version Cross Manager and its scope of functions goes beyond this. It can be used as a central tool for data backup, change control and software versioning. Further notes can be found in chapter "versiondog Version assignment and configuration control" as well as the PCS 7 Add-on catalog Write protection for CFCs/SFCs and SFC types CFC/SFCs and SFC types can be provided with write protection to ensure safe operation of the plant after commissioning and verification. If the write protection is enabled, the operating and maintenance personnel can only open CFC/SFCs and SFC types and monitor process values online. They cannot perform intentional or unintentional changes to charts and types. To enable write protection, "Write-protection for charts" can be selected in the properties of the chart folder for each automation station. A5E AA 135

137 Support for Verification The project staff also has the option of enabling or disabling write protection for individual charts or SFC types. The check box for "Write-protection for charts" can be shown here in two different ways. White background with black check mark: write protection is selected for all charts Shaded background and gray check mark: at least one chart or SFC type is write-protected. If the write protection is not enabled for all charts, disabling and enabling write protection for the "Charts" folder once enables write protection for all CFC/SFCs and SFC types of each automation station. If the chart of a CFC/SFC or SFC type is open, you will see the following notice with write-protected charts: In the process object view, changes can then be made even when the chart folders are read-only. 136 A5E AA

138 Support for Verification Block encryption with "S7 Block Privacy" The "S7 Block Privacy" package can be used to encrypt and decrypt function blocks (FB) and functions (FC). It is not possible to encrypt other blocks, such as organization blocks (OB), fail-safe blocks, or blocks with "Know-how protection". The encryption occurs directly in the database of a project. All FBs and FCs that have been encrypted and downloaded to the AS have the status "S7 Block Privacy". Instructions In order to process encrypted blocks, the AS CPU 4xx with firmware version V6.0 or higher is required. "S7 Block Privacy" is a new function of PCS 7 V8.0. For this reason, encrypted blocks cannot be processed with an older version of PCS 7. It is not possible to use S7-PLCSIM with encrypted blocks. "S7 Block Privacy" provides greater security than the previous Know-How protection and should therefore be used preferentially for sensitive areas in particular. Procedure To encrypt blocks, the "Block Privacy" command must be selected in the shortcut menu of a block folder. A5E AA 137

139 Support for Verification The tree structure of the encryption tool lists all blocks and SCL sources in the project. The selection marked with a check mark can be encrypted using the "Encrypt Block..." command in the shortcut menu. This opens a dialog whose instructions must be followed. SCL sources SCL sources that are contained in the project and whose blocks have been encrypted should be deleted before transferring the project to third parties. This action can also be performed in the "S7 Block Privacy" application. The "Delete source" function must be selected in the shortcut menu of the source. Once the sources have been deleted and are removed from the tree structure, the source folder still has to be reorganized. It is the reorganization step that actually deletes the sources. Before that, the sources are merely designated for deletion and removed from SIMATIC Manager. However, they are still present at the memory location of the project. Decrypting The procedure used to encrypt blocks is also used to decrypt them. However, decryption of blocks requires the correct key and the decompilation information. 138 A5E AA

140 Data Backup 8 Data Backup Periodic data backups are not only necessary to avoid data loss during the configuring phase. They are also necessary during the operation phase to ensure a smooth system restoration in the event of data loss or system failure. An emergency plan is also required for this case. In addition to the backup of the system installation, the configuration data should also be backed up on a regular basis in order to be able to revert back to the last saved system configuration in the event of a hardware defect or data loss. The following data backups should be considered: Backups of system installation, see chapter 8.1 Backup of the installation, including all project files (image) following system updates and major project changes as well as periodically, e.g., every 12 months Change-driven backup of project data before/after every change Periodic backup or "recopying" of all archived data every 3 to 5 years, for example, to ensure the readability of the data. The backup of the user software and the backup of the system partition with and without SIMATIC PCS 7 should be stored on external media (for example, CD, DVD, network backup). See also Chapter 9.4 "System restoration" 8.1 Backup of system installation Hard disk images should be used to back up the operating system and the PCS 7 installation. These images allow you to restore the original state of PCs. Which images are advisable? Creation of an image of the operating system installation with all drivers and all settings for the network, user administration, etc., without SIMATIC PCS 7 Creation of an image of the installed PCs with SIMATIC PCS 7 Creation of an image of the installed PCs with SIMATIC PCS 7, including all projects A5E AA 139

141 Data Backup An image can only be imported on a PC with identical hardware. For this reason, the hardware configuration of the PC must be suitably documented, for example using SIMATIC Management Console. Images of individual partitions can only be exchanged between image-compatible PCs because various settings, for example, in the registry differ from PC to PC. 8.2 Data backup for application software We recommend generating regular data backups of project data. In this storage concept, it might be specified, for example, that the project is backed up following every change. The project backup can be performed in various ways. See also Manual "PCS 7 Service Support and Diagnostics", chapter 3.2, Online support under Entry ID Backing up user software in the engineering system The SIMATIC Manager "Archive Project" system function should be used for this purpose or the "Version Trail" optional package, which includes version-specific archiving. With the SIMATIC Version Trail option, the project can be backed up manually or in a time-controlled manner and at the same time the versions can be checked. An older version can also be copied back via the interface. See also Chapter "Versioning of projects with Version Trail" If data backups are to be created during plant operation, consideration must be given to whether and, if so, which online parameters must be read back prior to generating the backup. Parameter changes which are not read back will be lost if the system or project is restored. Backing up recipe data in SIMATIC BATCH The project configuration must be backed up in PCS 7, as must application data in SIMATIC BATCH (libraries, master recipes, materials, user rights, etc.). This backup is created from within the SIMATIC BATCH Control Center. SIMATIC BATCH supports automatic and time-controlled backup of BATCH project data. This includes, for example: Plant settings Project settings Libraries Formulas Master recipes Materials 140 A5E AA

142 Data Backup The backup data can be copied back again using the "Restore" command. A5E AA 141

143 Operation, Maintenance and Servicing 9 Operation, Maintenance and Servicing 9.1 Operation and monitoring Process visualization SIMATIC PCS 7 provides extensive process visualization. Individually configured user interfaces can be created for each application for reliable process control and optimization of the entire production sequence. Runtime data can be output by the system based on reports Asset Management In the context of process engineering, asset management aims to use appropriate methods to ensure that a production plant benefits from maximum availability at the lowest possible operating costs. The most efficient strategy is without doubt statusoriented maintenance, which must be based on a status detection procedure that is as continuous as possible. Asset management relies on having access to precise information relating to the current plant status, which can then be used to determine exactly which maintenance activities need to be carried where and at what time. Implementation in PCS 7 The asset management integrated in SIMATIC PCS 7 is used for plant maintenance. Additional hardware and software tools are not required. Plant operators and maintenance engineers use the same SIMATIC PCS 7 tools and user interfaces, along with information which has been filtered and prepared according to the field of activity concerned. While the plant operators operate and monitor the process on the PCS 7 operator station (OS), the maintenance engineer uses the maintenance station (MS) to control the hardware structure of the production facility in order to handle the diagnostics and maintenance requirements. The various components of a PCS 7 plant can be monitored with the diagnostic and maintenance functions integrated in SIMATIC PCS 7. PCS 7 Maintenance Station (MS) is available in the following forms: MS Basic MS Standard MS PDM 142 A5E AA

144 Operation, Maintenance and Servicing As PCS 7 V8.1 is possible in connection with PDM V8.2, use the Maintenance Client functionalities from each OS Client. A Client Server architecture makes this possible. In each case, the requirement is that an engineering station is switched on with a running Asset Service, as this functions as a server for the PDM requests to the device. The device parameters can be read out and processed via a maintenance client. For documentation about this, see Function Manual "PCS 7 Maintenance Station" Online support under Entry ID Service Manual "PCS 7 Service Support and Diagnostics" Manual "PCS 7 Help on PDM V8.2", Entry ID The maintenance engineer has access to all details of the components and devices when needed, beginning with an overview display (plant view). The overview display uses the standardized symbols to visualize the condition of a component itself and also provides collective information on the conditions of all devices in the lower-level hierarchies. There are four areas on the top level: HMI area (IPCs, server, clients, ES, PH) Network area (network switches) AS area, which is divided into two subareas CPU area IO range (field devices, field distributor, Remote IO) User range (monitoring of system parts based on configured variables such as operating hours or switching cycles) The group status message shows the OK condition or the seriousness of the problem in traffic light colors. Maintenance work can be requested directly via the diagnostic faceplate of a monitored component. Furthermore, the status of the work can be specified and monitored. This is recorded in the form of an operating message and indicated by the symbols. A work instruction number and a comment can be entered for each work request. Service appointments or intervals can also be determined. Once the set interval expires, a system message is automatically created, which indicates the service required, such as calibration necessary. A report can be created and printed out for each component. The creation of logs for entire device groups can be useful. In this case, it is possible to filter devices by their priority. The requirement here is the corresponding identification of devices, which is performed in SIMATIC Manager. Currently it is possible to identify devices as "important" or "SIF" (safety relevant). A5E AA 143

145 Operation, Maintenance and Servicing Condition Monitoring It is often necessary to take into account certain process engineering, chemical, and mechanical conditions in a plant s maintenance concept. Condition monitoring (e.g. pump operating points, motor bearing monitoring) is generally used in a preventive capacity in this regard, as the user receives an automatic notification before critical conditions are reached. PCS 7 Asset Management enables user-specific, maintenance-relevant process variables or parameters to be integrated into the existing diagnostic structure. PCS 7 provides the appropriate interfaces for this: a function block on the AS and a faceplate on the OS. 144 A5E AA

146 Operation, Maintenance and Servicing 9.2 Operational change control Any changes to validated plants must always be planned in consultation with the plant operator, documented, and only executed and tested once they have been released. The following chapters use examples to describe how to make changes: 1. Initiation, description and approval of planned change by plant user 2. Check and backup of the current application software version (project data) 3. Adjustment of system specification 4. Performing the change, including documentation of the performed change (poss. support using tool comparison) 5. Testing the change, including test documentation in suitable form 6. Backup of the changed project with new version ID The effects of the change to other parts of the application and the resulting tests must be specified based on risk and documented. It is advisable to categorize various actions and measure the change effort for the risk. In the case of a 1:1 exchange of a hardware component, for example, the risk must be lower than with different components. Furthermore, for software updates an assessment may be needed between system security and conformity with regulations, see also chapter 10.2 "Updating the system software". 9.3 Remote maintenance Various technical options are available for remote access. Depending on the program, to dial in to an external PC station, not only must the user have the appropriate access permission (user name and password), but the Allow remote access authorization must also be enabled. This should however be planned and documented within the scope of the entire system, as access must be controlled. In a controlled GMP environment, many control systems are configured as closed systems or "singular solutions". Thorough discussions must be held with the plant operator before a remote maintenance functionality is set up. Those responsible for the plant must give their express consent for each individual connection that is established to the system (logon). See also Readme PCS 7 V8.1, chapter ; Online support Entry ID A practical solution could be to assign the logical access permission, but to only establish a physical connection when necessary, and then only when on-site maintenance staff are present. A5E AA 145

147 Operation, Maintenance and Servicing 9.4 System restoration The procedure described in this chapter should enable the end user to restore the 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 Damage or failure to hardware 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 chapter 8 "Data Backup"). The instructions provided by the relevant software supplier for the data backup application should be followed. If a PC with an identical hardware 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. Restoring the application software The process for restoring the application software depends on the kind of backup. Reading back the data using the software version trail 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 Retrieve button. Reading back the data from a manually created backup A manually created backup copy can also be used. Retrieving recipes Retrieving archives This concerns the following, depending on the system configuration and the scope of the problem: process data, messages, batch data, log files, etc. Project-specific adaptations Project-specific project adaptations that are not stored with the project file must be restored. 146 A5E AA

148 Operation, Maintenance and Servicing Backup/restore for the SIMATIC BATCH database When a data backup of the SIMATIC BATCH database is read, a start batch ID can be assigned; this prevents batch IDs being assigned more than once. This dialog box also specifies whether or not the associated log is to be imported. A5E AA 147