Beruflich Dokumente
Kultur Dokumente
21 CFR Part 11
Deployment guide
© 2016 by Schneider Electric. All rights reserved. No part of this document may be reproduced, stored
in or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording or otherwise), or for any purpose, without the express written
permission of Schneider Electric Except where noted, the companies, organizations, products, domain
names, e-mail addresses, logos, people, places and events depicted herein are fictitious and no
association with any real company, organization, product, domain name, e-mail address, logo, person,
place or event is intended or should be inferred.
Schneider Electric and the author(s) assume no responsibility for errors or omissions and no liability
is assumed for damages resulting from the use of the information contained herein. Use of the
Schneider Electric software described in this document is subject to the terms of the applicable
Schneider Electric / Wonderware license. These terms include provisions that limit your rights such
as use restrictions, disclaimers of warranties and limitations of Wonderware / Schneider Electric
liability.
By installing or using the Schneider Electric software, you agree to accept all of the terms of the
applicable Schneider Electric / Wonderware license. A copy of the applicable license will be displayed
upon initial installation of the software. If a copy of the license is not displayed or you require an
additional copy of the license, you may obtain one from Schneider Electric' Wonderware business
unit by calling 1.949.727.3200 or by sending an e-mail to support@wonderware.com.
LIABILITY LIMITATIONS
The methods described in this document represent general guidance and may require
adaptation and/or modification depending on the needs of your specific system
implementation. Schneider Electric will not be liable for any indirect, incidental, special,
punitive or consequential damages, or damages for loss of profits, revenue, data or use.
List of Tables
Table 1 - References .............................................................................................................................. 3
Table 2 - BatchHistory Tables with user information .......................................................................... 39
Table 3 - Model export tools ............................................................................................................... 45
List of Figures
Figure 1 - Architecture assumptions...................................................................................................... 2
Figure 2 - SFC used for batch monitoring ............................................................................................ 18
Figure 3 - Standard user authentication popup .................................................................................. 18
Figure 4 – Data type validation ............................................................................................................ 19
Figure 5 - Phase Logic Tool .................................................................................................................. 19
Figure 6 - Signature requirements for a recipe transition ................................................................... 20
Figure 7 - Signature requirements for a recipe phase ......................................................................... 21
Figure 8 - Batch Reports Web Site ....................................................................................................... 22
Figure 9 - InBatch security ................................................................................................................... 25
Figure 10 - Application access ............................................................................................................. 26
Figure 11 - Detailed access to application functions ........................................................................... 26
Figure 12 - Parameter edition ............................................................................................................. 27
Figure 13 - Phase and transition signatures ........................................................................................ 28
Figure 14 - “Done By” popups ............................................................................................................. 29
Figure 15 -”Check By” popup............................................................................................................... 29
Figure 16 - Role verification ................................................................................................................. 29
Figure 17 - Audit Event ........................................................................................................................ 30
Figure 18 - Batch Details information .................................................................................................. 30
Figure 19 - Configuring the recipe approval requirements ................................................................. 31
Figure 20 - Recipe approval popup ...................................................................................................... 32
Figure 21 - History of a recipe that was approved for test .................................................................. 32
Figure 22 - “Done By” approval visible in the History interface .......................................................... 33
Figure 23 - “Done By” and ”Check By”recipe approval are recorded .................................................. 33
Figure 24 - Recipe access ..................................................................................................................... 34
Figure 25 - Batch Historian ArchiveHistory .......................................................................................... 36
Figure 26 - Admin web security enabled ............................................................................................. 36
Figure 27 - Archiving, purging and Error Queue management ............................................................ 37
Figure 28 – Batch History Archiving Configuration .............................................................................. 37
Figure 29 - Securing Recipe approval .................................................................................................. 38
Figure 30 - Recipe comparison report ................................................................................................. 39
Figure 31 - Operator station access ..................................................................................................... 43
This InBatch 21 CFR Part 11 Deployment Guide offers information on InBatch features relevant to the 21 CFR
Part 11 requirements of the U.S. Food and Drug Administration (FDA).
While not directly subject to regulation under 21 CFR Part 11, the InBatch product incorporates features and
functionality designed to facilitate the development of applications for use in FDA-regulated industries.
Accordingly, Schneider Electric has developed this document to provide customers with a set of "best practices"
in regards to the 21 CFR Part 11 requirements.
Best practices suggested in this deployment guide, in conjunction with properly designed and implemented
external procedural controls, should reduce cost of development, validation, and re-qualification of applications.
Note: The methods described in this document represent general guidance and may require adaptation
or modification depending on the needs of your specific system implementation. For optimum results,
before applying the advice contained in this guide, consult a Wonderware endorsed System Integrator.
Auditing and security functions are tightly integrated with Microsoft products, and working knowledge of both
Microsoft SQL Server and the Microsoft Windows operating system is required. It is assumed that you are
familiar with administering a Microsoft SQL Server DBMS and using the administrative tools provided with the
Microsoft Windows Server operating system.
For more information on Microsoft SQL Server or the Microsoft Windows operating system, please refer to the
relevant Microsoft user documentation.
InBatch uses Microsoft Windows Server Operating Systems and can be configured so that it manages and
monitors processes used in FDA-regulated industries. InBatch Historian uses Microsoft SQL Server as its
database management system/ DBMS
InBatch is a flexible batch management software designed to model and automate batch processes. It is typically
used in combination with Wonderware System Platform, InTouch, Wonderware Historian, the Wonderware
Alarm System and procedural controls to implement systems that comply with the FDA's 21 CFR Part 11
regulation.
A separate “Wonderware System Platform 2014 R2 with InTouch 2014 R2 21 CFR Part 11 Deployment Guide
(21_CFR_Part11_Deployment_Guide.pdf) contains recommendations for using Wonderware System Platform,
InTouch, Wonderware Historian and the Wonderware Alarm System in FDA-regulated industries.
Note: Closed systems are defined as systems where access is controlled by the people responsible for the
content of the electronic records. This document does not address Open Systems.
The InBatch CFR 21 Part 11 Deployment Guide describes the 21 CRF Part 11 Regulation in section 2. The
regulation can be met using a combination of procedural controls that are described in section 3 and
technological controls that are described in section 4.
The present guide will focus on the development options using InBatch in a Wonderware System Platform
environment. It does not cover any specific Foxboro Evo, Core Control Services, or I/A Series Software. Any
custom code is out of scope of this document.
InBatch .NET controls and/or ActiveX can be inserted in ArchestrA graphics or InTouch views respectively to
integrate the InBatch client components in an InTouch container. Alternatively, the InBatch standalone clients
(Batch Display, Batch Scheduler) can be used as the human machine interface to operate or schedule batches.
InBatch provides the ability to connect to the control system in two different ways:
1. Using IBSERV and InBatch’s tag linker to connect to a DA Server (only in Standalone mode)
2. Using IBMX and ArchestrA objects which themselves are connected to DI Objects and DA Server.
As this document is using the combination of Wonderware InBatch with Wonderware System Platform, the latter
approach used is represented in Figure 1.
InBatch Server
User authentication · Recipe Management
· Security editor
· Batch Management
· ... ArchestrA Application Object Server
IBMX · Plant model (Units/CMS/EMs)
Phase Statuses,
Actual parameters · Phase objects representing PLC phases
Phase Commands,
Target parameters
Data Acquisition Server
Commands, Statuses,
Target Actual Other Real
Legend: parameters parameters time data
Wonderware InBatch components
PLC
Other Wonderware System · Phase execution
Platform components · Parameters
Third party components · Control commands and statuses
Because the recommended architecture involves Wonderware System Platform, InTouch and the Wonderware
Alarm System, the reader should also refer to “Wonderware System Platform 2014 R2 with InTouch 2014 R2,
21 CFR Part 11 Deployment Guide” for completeness.
The following tables list the references and documentation available for the individual Schneider Electric
products discussed in this guide and relevant to the 21 CFR Part 11 regulations.
Table 1 - References
Document name Description
(File name)
Wonderware System Platform 2014 R2 21 CFR Part 11 Deployment Guide for
with InTouch 2014 R2 Wonderware System Platform™ 2014 R2 with
21 CFR Part 11 Deployment Guide InTouch 2014 R2; available on the Wonderware
(21_CFR_Part11_Deployment_Guide.pdf) System Platform 2014 R2 DVD
1.2.2 Validation
FDA documents can be downloaded off the FDA’s web site at http://www.fda.gov/ and guides developed by
ISPE can be bought through ISPE at http://www.ispe.org/.
1.4 Glossary
This document uses the following terms, abbreviations, and acronyms:
Item Description
Biometrics A method of verifying an individual’s physical feature(s) or repeatable action(s) where
those features and/or actions are both unique to that individual and measurable
cGMP Current Good Manufacturing Practice
CFR Code of Federal Regulations
Closed system An environment in which system access is controlled by persons who are responsible
for the content of electronic records that are on the system
Control system This expression is used to represent the system that controls the physical process
elements. This is usually a PLC (Programmable Logic Controller) or a DCS
(Distributed Control System). InBatch interfaces with these systems to execute the
recipes.
DA Server Data Access Server
DB Database
EMI Enterprise Manufacturing Intelligence
DCS Distributed Control System
ER/ES Electronic Record/Electronic Signature
FDA Food and Drug Administration
GAMP Good Automated Manufacturing Practice
Historian The Wonderware Historian component of the System Platform is a high-
performance real-time database for historical information. It combines the power
and flexibility of a relational database with the speed and compression of a true
process historian, integrating the office with the factory floor or any industrial
operation.
HMI Human-machine interface
I/A Series Schneider Electric Foxboro Distributed Control system (DCS)
ID Identification or an item used to verify one’s identity (e.g. user name)
IDE Integrated Development Environment
IT Information Technology
ISPE International Society for Pharmaceutical Engineering
Developments in documentation technology, specifically electronic records and electronic signatures, offered
companies advantages over paper-based documentation. Companies in regulated industries sought to use
these electronic record and electronic signature capabilities to satisfy regulatory requirements.
The United States government responded with guidance in the form of a regulation, 21 CFR Part 11, governing
the use of electronic records and electronic signatures needed or used to satisfy FDA requirements.
Subpart A, General Provisions, defines what electronic records and electronic signatures must comply with this
regulation. The records subject to Part 11 are those in electronic form “created, modified, maintained, archived,
retrieved, or transmitted, under any records requirements set forth in agency regulations.”1 The regulation
also applies to any electronic records submitted to the FDA even if the record is not specifically identified in the
FDA regulations. Any signatures applied electronically to such records must also comply with the Part 11
regulations.
The General Provisions also definitively state that electronic records and electronic signatures in compliance
with this regulation will be considered the equivalent of paper records and handwritten signatures applied to
paper.
1
21 CFR Part 11, Subpart A, section 11.1 (b)
The controls for closed systems are summarized here but addressed in greater detail within sections 3 and
4 of this guide:
o 11.10 (a): Systems must be validated (tested to verify they operate as designed)
o 11.10 (b): Records must be available for inspection in both electronic and human readable
form
o 11.10 (c): Records must be protected for retrieval during the required retention period
o 11.10 (d): System access is limited to authorized individuals
o 11.10 (e): Operator entries and actions that create, modify, or delete electronic records must
be tracked in a secure, computer-generated audit trail
o 11.10 (f): System checks will enforce sequencing of steps or events
o 11.10 (g): Authority checks will be used to ensure system use or electronic signatures only by
authorized individuals
o 11.10 (h): Device checks will determine validity of inputs or operational instructions
o 11.10 (i): System users have the necessary education, training, and experience for their tasks
o 11.10 (j): Written policies that hold individuals accountable for actions initiated by their
electronic signatures
o 11.10 (k): Controls over system documentation including access to and changes therein
2.1.2.2 Signature Manifestation (11.50)
Electronic records must include information associated with each electronic signature applied to the record.
This information must be controlled to the same degree as the electronic records and all aspects of the
signature will be included in the human readable form of the electronic record.
Note: This guide does not address the application of handwritten signatures to electronic records.
o 11.300 (a): Maintain user ID and password combinations so no two individuals can have the
same combination
o 11.300 (b): Codes and passwords are periodically checked or revised
o 11.300 (c): Lost or potentially compromised identification devices (e.g. tokens, cards) or
passwords are voided and replaced with a new equivalent
o 11.300 (d): Transaction safeguards are used to prevent unauthorized use of IDs or passwords
o 11.300 (e): ID or password generating devices (e.g. tokens) must be tested initially and
periodically to ensure they are unaltered and function properly
While the intent was to produce a wide use of technology, concerns about Part 11 developed within the
industry to the point where the regulation was perceived as having the opposite effect (see ISPE White Paper
for examples).
In February of 2003, the FDA issued draft Part 11 guidance with a final guidance following in August 2003. In
this final guidance, the FDA presented the group’s intention to limit the scope and application of Part 11.
Specific industry concerns about Part 11 were noted in this final guidance:
o Unnecessarily restricts the use of electronic technology inconsistent with the regulations
intent
o Can significantly increase the costs of compliance due to the Part 11 requirements
o Discourages innovation and technological advances without providing significant public
health benefit
The revised guidance is intended by the FDA to address these industry concerns, as the result of the original
Part 11 regulation was the opposite of the intent. The emphasis within this revised guidance is clear:
The enforcement discretion is strictly limited to the Part 11 requirements but some of these
aspects of a system may still apply to satisfy the predicate rules. Regarding the areas identified
for enforcement discretion, Part 11 should be viewed as not adding to or increasing the
regulatory requirements defined in other regulations. Part 11 does not remove or invalidate
existing requirements defined in other regulations. For example, system validation is still
required for some systems by 21 CFR 820.70(i).
Once a system is found to require Part 11 compliance, the company needs to determine how to comply with
the applicable requirements. This requires a mixed solution of two types of controls: technological and
procedural. Some specific requirements may even be addressed by both types of controls.
The presence of procedural requirements means that no technological solution, software, etc. can be compliant
with the Part 11 regulation, as it exists on its own. This guide will focus on the application of technological
controls, but will also identify where procedural controls are required.
2
Complying with 21 CFR Part 11, Electronic Records and Electronic Signatures, Part 2
Procedural controls must be applied as part of any Part 11 solution. These procedural controls are outside the scope
of Wonderware’s products and offerings to the industry but this guide addresses the procedural controls and
provides some content to aid a company’s efforts to understand and apply the necessary procedural controls.
Companies need to define and execute a system with components (e.g. SOPs, processes, tools) that will ensure
the closed system controls are properly established and maintained. Periodic verification, or auditing, of the
controls should be performed to maintain the integrity of the controls, once established.
3.1.1.1 Validation - 11.10 (a)
21 CFR Part 11:
“(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the
ability to discern invalid or altered records.”
Validation is one of the requirements where enforcement discretion will be applied. In this area, that
means validation of electronic record/electronic signature (ER/ES) systems will not face any new
requirements due to the Part 11 record. System validation must still be performed in compliance with
the predicate rule (21 CFR 820.70(i)).
This validation should follow a defined methodology. The GAMP5 guide recommends important
validation principles for companies to consider using. Significant procedural activities to perform include
defining requirements, documenting system design, and testing that the system performs as defined by
the design – including documenting this testing or verification.
3.1.1.2 Record Protection - 11.10 (c)
21 CFR Part 11:
“(c) Protection of records to enable their accurate and ready retrieval throughout the records
retention period.”
The following procedural actions should be performed to protect and enable record retrieval:
o Define procedures for providing records to internal and external parties
o Specify retention requirements – specifically the retention period
o Define backup, recovery, archival, and retrieval processes for electronic records
This is another area where enforcement discretion will be applied but this discretion is specifically
limited to generating copies of records. Electronic records should be available at a company’s facility
using that company’s defined tools and methods or the records should be made available as copies
in some common format (e.g. PDF, XML).
Procedures need to be defined that address system user administration, including who should be
granted access and how that access is granted. Often systems require administrator level or
otherwise high level users with great latitude in the actions they can perform within the system.
These high level users should get special attention when considering rules, limitations, and other
procedural safeguards that can be applied.
Some customers may interpret the Part 11 guidelines to require a record of changes to user access
profiles. InBatch records the creation or description change of a user or role profile but does not
record the access details history. If required, a manual procedure should be established to create and
maintain these records.
Reliability of records must still be maintained even though an audit trail may not be specifically
required due to the FDA’s enforcement discretion defined in the revised guidance. Procedures should
be established that require documentation of the methods for ensuring reliable records, whether this
includes an audit trail or not.
3.1.1.5 Authority Checks - 11.10 (g)
21 CFR Part 11:
“(g) Use of authority checks to ensure that only authorized individuals can use the system,
electronically sign a record, access the operation or computer system input or output device, alter
a record, or perform the operation at hand.”
Procedures need to define how systems should perform authority checks. If any variation in
authorization method is allowed, the specific scenarios and authorization methods for each must be
specifically defined.
This requirement is related to the access limitation requirement (section 0). However, this
requirement addresses allowing specific actions within the system whereas the access limitation
requirement relates to general access to the system.
3.1.1.6 User Qualifications - 11.10 (i)
21 CFR Part 11:
“(i) Determination that persons who develop, maintain, or use electronic record/electronic
signature systems have the education, training, and experience to perform their assigned tasks.”
The method or methods used to determine persons who are qualified to interact with ER/ES systems
must be defined.
Policies need to define the responsibilities of those users with electronic signature capabilities. This
should include any consequences or other deterrents for misuse of the electronic signature function
by those users. This requirement is intended to ensure electronic records can be trusted as signed.
3.1.1.8 Documentation Control - 11.10 (k)
21 CFR Part 11:
“(k) Use of appropriate controls over systems documentation including:
(1) Adequate controls over the distribution of, access to, and use of documentation for system
operation and maintenance.
(2) Revision and change control procedures to maintain an audit trail that documents time-
sequenced development and modification of systems documentation.”
The controls placed on system documentation must be defined by procedures. Requirements for
recording and tracking system documentation changes must also be defined.
Procedures should be established to ensure an electronic signature is unique and can only be used by
one individual Companies should also be prepared, with defined procedures, to handle situations
where signature authorities are not available because no others can execute a signature on their
behalf. A valid remedy is to establish rules for delegation of signature responsibility so work flow can
progress even if primary signature authorities are not available to execute an electronic signature.
3.2.1.2 User Identity - 11.100 (b)
21 CFR Part 11:
“(b) Before an organization establishes, assigns, certifies, or otherwise sanctions an individual’s
electronic signature, or any element of such electronic signature, the organization shall verify the
identity of the individual.”
Procedures should be established to define what distinct identification components are considered
valid for use in an electronic signature. These procedures should also define what is considered a
continuous period of controlled access for the purpose of identifying when only one electronic
signature component is required for subsequent signings.
These procedures also need to ensure persons only use or apply their own electronic signature and
they do not share or distribute any components of their electronic signature such that others cannot
falsely sign electronic records for them.
Finally, the procedures need to define and manage signature components such that a single person
cannot attempt to use another’s signature. It is the responsibility of the customer to have procedures
in place to force users to change their passwords after being initially set by the administrator. This
functionality is supported by Windows security.
ID and passwords are given specific mention in the regulation as they are by far the most commonly
used electronic signature components.
3.2.3.1 ID & Password Uniqueness - 11.300 (a)
21 CFR Part 11:
“(a) Maintaining the uniqueness of each combined identification code and password, such that no
two individuals have the same combination of identification code and password.”
This requirement is most likely addressed by the procedures required for electronic signature
uniqueness in 21 CFR 11.100(a).
Identification codes should be disabled for users that are no longer allowed access to a system. Users
should be periodically reviewed to ensure they are currently assigned to the correct user groups as
many systems grant access or permissions based on membership in defined user groups. These types
of changes are often due to change in roles or separation from the company. Whatever method is
applied; the procedures should not jeopardize the integrity of signatures already executed which
means it may not be possible to completely remove a user from the system.
Passwords are commonly required to be periodically changed in an effort to minimize the likelihood
an ID-password combination can be compromised. This generally accepted practice is especially
important in ER/ES systems. Additional rules, such as password cannot be changed to be the same
as the user ID, passwords cannot be reused or reused within a specific time period, and others should
also be considered to protect the integrity of passwords.
Also, rules for password components can be used to make passwords more difficult to guess. For
example, password length of 6 or more characters, at least one capital letter, at least one letter and
one number, would all contribute to making it more difficult to guess another’s password.
Loss management procedures must be clearly defined and consistently applied to protect the
integrity of electronic signatures when passwords or any other signature component or component
generating device is lost or compromised.
3.2.3.4 Transaction Safeguards - 11.300 (d)
21 CFR Part 11:
“(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification
codes, and to detect and report in an immediate and urgent manner any attempts at their
unauthorized use to the system security unit, and, as appropriate, to organizational management.”
Procedures should define how to handle any unauthorized attempts to use a person’s ID and/or
password. This will depend on the technological controls to identify the unauthorized attempted use.
3.2.3.5 Device Testing - 11.300 (e)
21 CFR Part 11:
“(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate
identification code or password information to ensure that they function properly and have not
been altered in an unauthorized manner.”
Procedures need to define the testing to perform and when it should be performed, including the
frequency of the periodic tests.
FDA-audited industries are required to properly validate their applications. The software world uses the
term validation and verification interchangeably. However, according to the document “General
Principals of Software Validation; Final Guidance for Industry and FDA Staff”, Schneider Electric provides
software that is verified.
System Validation
Validation of the applications and systems created using the Schneider-Electric Software products is
entirely in the responsibility of the FDA-audited industry. Creating and maintaining a validated system
state is simplified by features and functionality provided by the Schneider-Electric Software products.
For example, Wonderware InBatch includes batch sequencing management features with a SFC
(Sequential Flow Chart) as the main interface to monitor the batch progress as depicted in Figure 2.
The software supports ISA S88.01 standards to communicate with the underlying control system. The
InBatch capability of managing the sequence of unit procedures, operations and phases in a proper
and consistent order has been thoroughly tested; as well as the proper usage of the phase control,
status bits, parameter download, etc. These standard capabilities are part of the off-the-shelf product
and do not need validation on their own.
InBatch also provides a set of ActiveX and .NET controls that can be used in InTouch views or ArchestrA
graphics. These controls provide capabilities for communicating with the Batch server to view or enter
parameters, enter credentials, and to acknowledge entry or exit of phases, etc.
They can be used with minimal or no configuration in the customer’s HMI and their functions do not
need to be validated on their own. An example of standard popup for user authentication is depicted
in Figure 3.
Figure 3 - Standard user authentication popup
The configuration of InBatch also allows defining the data types and verifies that the specific entry
corresponds to the specified data type as illustrated in Figure 4 where an error popup warns the
operator about the bad entry. Once the value is entered correctly in the standard InBatch field, it is
not necessary to validate that the entry populates the right InBatch phase parameter as this is a
standard product feature. It is only necessary to verify that the InBatch phase (including all phase
parameters) is correctly connected to the control system phase instance.
Verification that the InBatch management system is connected properly to each individual control system phase
is critical and is facilitated by the InBatch Phase Logic tool. InBatch Phase Logic is an engineering tool available
from the InBatch Environment Display that allows running a phase for testing purposes outside of a batch and
test the handshake interface between the Batch Manager and the control system phase logic. The Phase Logic
tool is depicted in Figure 5; it contains buttons to test all standard control and status bits for the phase as well
as a simple interface to view and modify the phase parameters. Once the phases are individually tested with
this interface, they can be used in a recipe with a high level of confidence that the connectivity with the control
system is working and that the handshake is properly implemented in the control system.
Important: Only the Ask () functions in expressions – as shown below in Figure 6 and Figure 7 – provide support
for DoneBy/CheckBy. Other transitions with regular expressions do not support these CFR21 Part 11 support
functions.
The recipe flow may be verified offline using the InBatch Simulator. It is recommended to use the
InBatch Simulator at the design phase to verify that the phases are correctly defined and modular
enough to be reused in different recipes.
The InBatch configuration uses a concept of process to represent a certain type of unit. All units in a
process share the same phase definitions; this improves consistency and reduces the development
effort as the phases are defined only once for a given process. Similarly, defining tags at the process
level rather than at the unit level ensures consistency between the units of a given process. It removes
the need to test a recipe with all units of a given process as long as the control system (PLC/DCS) code
is consistent between units. Note that the consistency of PLC/DCS code between units is outside of
InBatch scope; InBatch boundary is the interface with the Control System.
InBatch extends the ISA S88.01 standards to represent transfer classes. Phases can be defined on
these classes and several instances of transfer equipment with the same capabilities can be
instantiated as connections; this has similar impact on the development and testing activities as
explained for the processes and units.
In order to reduce the possible risk of tag linking errors, it is recommended to use the InBatch model
import utility in the IDE. This generates the InBatch templates and objects automatically with their
associated parameters. The templates may then be edited to define the desired IO assignment of the
tags, using the ArchestrA System Platform 2014 R2 feature of Auto I/O Assignment. This feature
generates the attributes extensions to the Control System’s tags automatically, based on the
parameter name. It enforces standardization of the tag name in the Control system. Although this is
not a requirement – each tag could be individually assigned for each phase instance – using the Auto
I/O Assignment feature removes the risk of error in custom scripting for tag assignment.
The individual connection of the parameters and control/status bits to the control system still need
to be verified for each individual phase since they depend on different additional factors like the
quality of the network connection to the individual Control Systems running the actual phases in the
plant.
Decisions to reduce testing scope are completely within the boundaries of currently accepted industry
methodology. GAMP 5 specifically promotes the use of a risk-based approach to validation, including
testing. Capabilities within the Wonderware products like those mentioned above may provide a
strong case of reduced testing when properly employed within a custom-configured system.
The Batch Reports web site is encrypted and available through the BatchReport Icon in Environment
Display as depicted in Figure 8:
Although phase parameters high and low deviation limits may be defined in InBatch and downloaded
to the control layer, the InBatch management system does not have its own independent alarm
management system (unless using InBatch with I/A Components). Instead, alarms are stored in the
Wonderware Alarm system. Standard ActiveX and .NET controls are available to view both the
current alarms and the historical alarms. The alarms related to a given batch are included in the batch
report provided that the ArchestrA objects generating the alarm are prefixed with the name of a unit
or connection that was allocated to the batch.
Alarms are discussed in more details in the Wonderware System Platform 2014 R2 with InTouch 2014
R2 21 CFR Part 11 Deployment Guide, specifically on page 37.
Protection of records includes performing scheduled backups of data. Backups must be made and
maintained for InBatch databases (BatchHistory and BatchArchive databases) on a regular basis, for
example daily full backups and hourly differential backups.
Other backups required in a typical InBatch environment need to be planned; for example, the
Wonderware Historian runtime data (history blocks) and the alarms and events database (A2ALMDB)
typically contain process data that must be backed up. Please refer to the Wonderware System
Platform 2014 R2 with InTouch 2014 R2 21 CFR Part 11 Deployment Guide, specifically on page 40 for
these databases.
Backing up recipes
The InBatch server can be configured to automatically export new recipes using a B2MML (XML)
format when they are changed or approved. A daily backup of these files is recommended since they
can later be used to identify changes between versions using the recipe comparison utility.
The system parameter "Version File Path" defines the XML recipe directory path. The system
parameters “Version at Save” and “Version at Approval” give the ability to configure the export of an
.xml version of the recipe every time the version is saved or approved for production.
These Environment Display system parameters are described in detail on pages 53 to 54 of the
Wonderware® InBatch™ User’s Guide (InBatchUserGuide.pdf).
InBatch has different security options as displayed in Figure 9: InBatch “Standard” (native) security,
“Operating System” security and “ArchestrA” security. The “Security Enabled” check box shall be
checked in a FDA-audited industry. This enables security verifications and recording of the users who
perform the “Done By” and “Check By” signatures.
FDA-audited industries should use the Operating System Security model for best results. Both OS
Security models (User based and Group based) use Windows operating system authentication. This
permits user name and password management, outside of InBatch, directly in the Windows operating
system environment. By using OS Security you benefit from the standard Windows functions for
password length and complexity. Other Wonderware products that are typically used with InBatch
are also capable of using the OS security. Although an ArchestrA Galaxy used with InBatch may be
setup to use OS Group security, the InBatch Server should authenticate directly with the OS rather
than through the ArchestrA security.
If using OS Group Based Security Authentication Mode, make sure there is an understanding of the
Windows operating system, particularly its user permissions, groups and security features. InBatch
OS Group-based security uses these Windows features. For more help, see the Microsoft online help
or a 3rd party book about Windows security.
When using local OS Groups as Roles, each client node interacting with the Batch server must have
the same OS Users, Groups, and user-group mappings to get the same level of access to the user at
each node. In order to avoid this complexity in regulated environments, the use of a Windows Domain
controller and Windows Active Directory is recommended in multiple node installations.
InBatch roles should be designed carefully to limit the access to the different InBatch application
components and functions. Once InBatch roles have been designed, they can be configured and later
linked to different OS groups.
Some of the InBatch applications have more detailed security configuration possible, especially the
Batch Display (batch client function) which is the User interface for Batch execution. The details for
each application are setup in the bottom part of the Application-Function Editor, in the Functions
section as depicted in Figure 11. The configuration of these functions is critical in FDA-audited
industries. The roles that are authorized to access some functions like Aborting a phase, starting a
batch, editing a phase parameter are defined through this interface.
In order to record the user who performed an action during the batch as part of the batch record, the
specific function need to have the Security Enabled checkbox activated and roles defined in the “Done
By” and “Check By” boxes. In Figure 11, the Abort Batch button will require the signature of either
an administrator (ADM) or an engineer (ENG) but will not require a second user to perform the ”Check
By” action. In this case, only one user’s signature can be recorded for a batch Abort.
The different settings that impact the capability to edit a parameter and the requirements for “Done
By” and ”Check By” signatures are depicted in Figure 12.
Restrictions shall also be added in FDA-audited industries to the “Edit Phase” function which
enables a batch client to edit the phase Properties and Instructions in the Inactive Phase Parameter
Editor.
In addition to the detailed functions and parameter access described above, each recipe can:
· Specify if “Done By” or “Check By” signatures are required for entry or exit. This is
specified for each individual recipe phase. This requires setting up the security for “Ack to
enter”, “Ack to exit” functions as well as checking the appropriate boxes for each phases in
the recipe as depicted in Figure 13.
· Require signature to authorize a transition to move on to the next activity in the recipe
once the transition condition is met. This requires setting up the security function for
“Answer question” as depicted in Figure 13 as well as defining the appropriate condition or
question in the recipe transition expression. (Note that a question transition condition
will only allow continuing when the “Yes” button is pressed. N parallel transitions need to
be set to represent N possible paths, each path requiring its own signature.)
During the batch execution, all functions that have been set to require “Done By” / ”Check By”
signatures in the Security Editor (and recipe editor for phases enter and exit) will display the
corresponding popups before authorizing the action. The meaning of the signature is displayed at
the top of the popup, in the Action field. Figure 14 depicts two “Done By” popups with different
actions fields.
Figure 14 - “Done By” popups
When “Check By” is required, a second popup is displayed after the “Done By” authentication is
successful. Figure 15 shows that the “Check By” popup includes the signature meaning in the Action
field and verifies that the “Done By” and “Check By” User IDs are different.
Figure 15 -”Check By” popup
Figure 16 shows that the system verifies the role requested for a specific function.
In addition to the AuditEvent table, the BatchDetails table includes detailed “Done By”/ ”Check By”
information on the events happening in a batch or phase. This is depicted in Figure 18 where we
can see some “Done By” and ”Check By” information along with the context of the event (Batch id,
unit, procedure, operation, phase) in the first few columns and the description of the event in the
description column.
Up to five levels of approvals (including the author’s approval) may be defined for recipes and
configured with security enabled and “Done By / ”Check By” roles as depicted in Figure 19. Until the
recipe is approved, it is not available for scheduling as a production recipe.
The system does not prevent the same user from approving several levels for the same recipe.
There needs to be either a procedure to state that the approvers should be different or the roles
need to be set so that no user has more than one level of approval.
In order to use a recipe for test, only the “Author” and “Approval Test” levels of approval are
required. It is therefore recommended to add an additional level of security for the Recipe test
approval. This can be done either by:
· Giving access to test recipes to specific users or roles. The typical configuration of InBatch
gives the engineer who develops the recipes access to all recipes so that they can create
and test recipes without going back to the security edition for each new recipe. The other
users are only given access to the specific recipes that they were trained on.
· Requiring “Done By” / ”Check By” signatures for “Approval Test” function. This means that
two “Approved for test” signatures are required to enable the corresponding checkbox.
Figure 20 shows the approval popup of a recipe that was approved for test.
Figure 21 shows the resulting history of a recipe after it was approved for test.
Figure 23; in this example, the second level of approval required both “Done By” and ”Check By”
signatures.
InBatch Security Editor provides the ability to associate recipes to users and/or groups. This can be
used as a way to limit the recipe access to users until they are trained.
In the example in Figure 24, the selected user only has access to the execution of two out of the 4
recipes. When recipes are associated to roles, then the user will have access to all of the recipes
associated to his different roles.
InTouch and InTouch for System Platform are often used in an InBatch environment as a host for
either InBatch ActiveX or ArchestrA graphics containing InBatch .NET controls. As mentioned
before, InBatch should be set to use OS security. It is recommended to use the ArchestrA based
security for InTouch applications. ArchestrA security itself should be set to OS security, preferably
OS groups to simplify and centralize user management at the IT level.
Important: Although the InBatch components can be hosted in an InTouch application, InBatch does
not use the InTouch user to verify the access rights to InBatch components. The InBatch security is
autonomous. The developer may choose to use ArchestrA security to protect buttons leading to an
InBatch component but the InBatch function itself is protected through the InBatch Security
Manager.
The Batch records are stored in the BatchHistory and BatchArchive databases.
As mentioned in the beginning of the document, within closed systems access is controlled by the
people responsible for the content of the electronic records. Access attempts to the system
(successful as well as unsuccessful) are added to the AuditEvent table of the system.
The system does not create a SQL user in the BatchHistory or BatchArchive databases. The user must
configure a Windows OS user to run the HistQReader Service and ReportQReader Services.
This configuration is done at install time where the user configuring the system must be a sysadmin.
Note that the service user does not need to be an admin or have any SQL rights. He will get the
required read/write access to the DB by the system.
In order to access batch reports, the system configures a SSRS data source that is used to retrieve
data from InBatch’s HistoryDB. The data source can be configured to use Windows Integrated Security
or a specific Standard SQL account. It is in the administrative user’s responsibility to manually create
and provide read-only access to any data source user.
SSRS also has a level of security that needs to be configured by the system user using the reporting
portal. The system creates a local Windows OS group (ibReportsUsers) that can be used to assign
users or groups to so that they can access batch reports
Please refer to the Wonderware System Platform 2014 R2 with InTouch 2014 R2 21 CFR Part 11
Deployment Guide, pages 46 and 47 for alarm security.
In InBatch, once a batch value is captured in the BatchHistory, there is no interface that allows changing or
deleting the record except for:
· the Purge/Archive mechanism which deletes the records from the BatchHistory database after
storing them in the BatchArchive db. Each Archive/Purge job is recorded in the BatchHistory
ArchiveHistory table with the following information:
[Archive_ID]
[Job_Name]
[Description]
[Target_DB]
[Archive_Device]
[Archive_Filename]
[HistoryDataStart_DT]
[HistoryDataEnd_DT]
[Archive_IND]
[Purge_IND]
[Restore_IND]
[JobStart_DT]
[JobEnd_DT]
[Status_Description]
[Status_CD]
An example of this table is depicted in Figure 25.
The error queue management provides a way to view and resubmit a failed transaction. Note that there is
no trace of successful re-submitted data other than the record being added to the history database and
deleted from the error queue.
Purge and Archive functions as well as the error queue management functions shall be restricted to
high level roles by enabling the security on the AdminWeb client as depicted in
Figure 26.
When a user does not have access and the security is enabled on the AdminWeb, an error is
displayed. The Batch History Archiving Configuration is shown in Figure 28.
SQL server Audit trails can be configured, by using triggers, to track and log changes made to any data, in
case a user accesses the database outside of the normal InBatch user interfaces. See the Microsoft SQL
Server documentation for more information. A sample for an event is the SQL RAISEERROR event that
the Stored Procedure inserting records into the AuditEvent table when there are too many login
failures within a time interval (3 attempts within 3 minutes).
Recipe Editor Approvals (at least Author and Approval #2) should be secured so that each approver
is recorded in the Audit Event table. Figure 29 shows the Security Editor window where 5 levels of
recipe approvals may be set.
The changes between two approved recipe versions can be verified using the recipe comparison tool.
This is possible when the System Parameter “Version at Approval” is set to true.
If the System Parameter “Version at Save” is set to true, then the comparison will be possible at each
save, and therefore the changes introduced by a specific author will be identifiable.
The recipe comparison report depicted in Figure 30 shows that the author of each version is recorded
and each section of the recipe containing a difference is included in the report. The additions,
modifications and deletions are all reported.
The following data is logged in the BatchHistory database along with the automatically generated
DateTime information and the user information (provided that the InBatch security is active and
that the corresponding functions have security enabled and user access defined).
This table should be carefully reviewed to ensure that all the audit trail requirements of an
application are met by InBatch or other Wonderware features.
One of the main feature of InBatch is to execute sequences of phases and transitions as defined in
approved recipes. Please refer to InBatch User's Guide: Chapter 8 Recipe Editor - Building a Recipe
Procedure for details on building the sequence.
The recipe sequences are enforced by InBatch at execution time. The following features allow the
user to operate out of sequence and therefore should be restricted to high level users with at least a
“Done By” signature. Figure 11 shows how to set this up in the InBatch Security Editor.
· Phase skip
· Phase jump
· Phase abort
· Batch abort
· Manual Batch execution mode.
The InBatch features relevant to authority checks are the same as those discussed previously in
Access Limitations - 11.10 (d).
4.1.1.8 Device Checks - 11.10 (h)
21 CFR Part 11:
“(h) Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of
data input or operational instruction.”
Operator station
The valid operator stations that can be used to interact with InBatch are configured in the InBatch
Security editor for each role or/and user. A Check box allows accessing all stations declared in the
system but it is possible to restrict a user or role to zero or more operator stations for more security.
If the InBatch client is executed on a terminal server, the terminal server needs to be properly
configured (not just using remote desktop) so that the client host name can be displayed. Otherwise,
the Terminal Server will be the only computer listed in this box as displayed in Figure 31.
Please refer to “Working with Operator Station Security” of the Wonderware® InBatch™ User’s Guide
for more information.
InBatch will store parameter changes that are made through the Batch Display interface, along with
the user who signed as the “Done By” or ”Check By” user, as part of the Batch record.
If other methods are used to allow parameter changes such as ArchestrA Applications objects, then
the information is not logged as part of the Batch Historian record. It is the responsibility of the FDA
audited industry to put procedures in place to limit and control the access to other methods for
parameter change during batch execution. If such methods are used, they shall require signature and
proper historization of the values (for example, in the Wonderware Historian and A2ALMDB).
Input devices
InBatch is usually connected to control systems through ArchestrA objects and DA servers. The
verification of the quality of the data coming from these devices is discussed in
21_CFR_Part11_Deployment_Guide.pdf.
InBatch can associate recipes to individual users or roles. This Security editor feature ensures that a
user who accesses a recipe is sufficiently trained to execute it. Figure 32 shows an example where a
user is configured to execute only 3 out of the 6 recipes.
A procedural control should be established over the system configuration as there is no automatic
versioning of the configuration except for the recipes. This section provides information on the
Wonderware tools that can be used to save and later compare some parts of the configuration.The
complete InBatch configuration is stored in the ...\InBatch\cfg\config_A folder. Before starting the
batch server with a new configuration, it is recommended to save a copy of this directory with a
version name. For example Config_A_v1.2_ 2016-01-05. It is also possible to save smaller parts of the
configuration individually, as xml, csv or text files for later comparison with third party tools. The
following table lists possible exports that may be used to validate that a specific aspect of the
configuration did not change since the last saved version.
All of the Environment Display programs allowing a change in the InBatch configuration must be
secured using the Security Editor; any access to these programs is then logged in the “AuditEvent”
Process Model To document a configuration change, an xml file of the Unit configuration
model with Editor may be produced using the InBatch Model Import/Export utility.
phases and
parameters
The Model Editor also has export capabilities but the generated file is a
Import/ text file rather than an xml file.
Export
Using a modified model at runtime requires stopping the batch server and
using the Update Runtime command.
Link db Tag The tag linker data can be exported in a csv file using the Export tags
linker/ menu.
IDE
Also, the units and phases instances generated in the ArchestrA
environment can be saved as csv files using the ArchestrA IDE csv dump
feature.
Using modified tag linker data at runtime requires stopping the batch
server and using the Update Runtime command.
Security Security A report of the security model may be exported as a text file.
model model
editor
Approval, versioning and a recipe xml comparison tool are available to
Recipes Recipe identify and control changes to a recipe. We recommend that you enable
editor
the "Version at Approval" or "Version at Save" option in EnvEdit System
Parameters in conjunction with using the Recipe Compare utility.
Enabling one of the versioning options will ensure that all recipe version
changes will be archived for comparison.
As discussed previously, (see Figure 14 and Figure 15) when a signature is requested, the “Action”
context relative to the signature is displayed. This action reflects the function name which is recorded
along with the user_id, user name, date time and signature level (“Done By”/”Check By”). This is
displayed in Figure 33.
The following tables contain user information for either “Done by” or “Check by” signature. The
user information is associated to the individual records (see Table 2 for detailed column
information).
· AuditEvent
· BatchAdmin
· BatchDetail
· ProcessVarChange
· MaterialInputChange
· OperatorComment
· BatchQuestion
· EquipStatus
· DocViewEvent
For example, Figure 33 depicts records from the AuditEvent table containing the user id for either
“Check By” or “Done By" signature. The InBatch interface does not provide any way to manipulate
the signature associated with a record once they are entered.
Furthermore, once a user signs in an InBatch user interface, the signature popup is closed and a
subsequent user has no way to copy the previous user password in order to falsify a signature.
The event records are maintained in a SQL Server relational database. If, despite the security setup
around the servers and database, the risk of having a user accessing the database to manipulate the
records is considered significant, an MS SQL Audit trail should be setup by the database
administrator.
FDA-audited industries should use the OS User Based or OS Group Based Security model for best
results. Both OS Security models use Windows operating system authentication. This permits user
name and password management, outside InBatch, directly in the Windows operating system
environment. By using OS Security you benefit from the standard Windows functions for password
aging, logon maximum trial, user name uniqueness and more.
It is not recommended to use local OS Groups as Roles, as that requires each node within a Batch
environment to have the same OS Users, Groups, and user-group mappings to get the same level of
access to the user at each node. Defining users on individual nodes creates a possibility of the same
user name being assigned to different users. For example, if user name jdoe was used on a node for
John Doe and jdoe was used on a different node for Jane Doe, within the same system, records would
not be able to distinguish between the users. Managing users in a single location and authenticating
by connecting to that location eliminates the potential for multiple users having the same user name,
which in turn ensures signature uniqueness.
Once an individual leaves a company, the user shall not be removed from the system but rather
disabled so that the user name remains unique in the system.
Situations where a workflow is stopped because a single user who can perform an action is not
available should be avoided if possible because of the risk that a userid and password is divulgated to
allow the process to continue. Each secured function role/user assignment should be reviewed with
the human organization in mind. InBatch Security Editor provides a mapping of functions vs roles that
can be used for this analysis (Print Applications and Functions). An example printout is depicted in
Figure 34.
(i) When an individual executes a series of signings during a single, continuous period of
controlled system access, the first signing shall be executed using all electronic signature
components; subsequent signings shall be executed using at least one electronic signature
component that is only executable by, and designed to be used only by, the individual.
The InBatch “User Id timeout” system parameter shall be set as depicted in Figure 35 to
specify the number of seconds that the current User ID is retained before it must be re-
entered. The default value of 0 retains the User ID indefinitely.
A very small number such as 1 (second) will force users to re-enter their user id every time.
The proper timeout should be carefully determined by the customer since this is a system wide
parameter and depending on the duration of each phase, it may require a lot of entries from
the InBatch users. Regardless of the specified timeout, user are required to enter their
password every time.
(ii) When an individual executes one or more signings not performed during a single,
continuous period of controlled system access, each signing shall be executed using all of the
electronic signature components.
If the time between two signatures exceeds the InBatch system parameter “User ID timeout”,
then both components of the signature popup are set to blank and the user is required to re-
enter their respective user id in addition to the always required password.
There is no technological control to prevent unauthorized use of IDs or passwords if those ID and
password combinations are compromised or known to more than the individual assigned a specific
ID and password combination.
(3) Be administered and executed to ensure that attempted use of an individual’s electronic signature
by anyone other than its genuine owner requires collaboration of two or more individuals.”
The risk of two following situations happening needs to be evaluated by the customer and appropriate
procedures need to be put in place to address the identified level of risk:
1. An IT administrator with the ability to reset a password would reset the password of a user who
accesses InBatch or the SQL Server database and then use it to manipulate the Batch system.
The customer should put procedures in place on all Active directory user accounts (except the
service ones) to force the user to change the password after being initially assigned. The active
directory should be set so that a notification (such as an email) is sent to an administrator and to
the user who changed his password when a password change occurs so that a fraudulent password
change can be detected and reported by the user.
2. An IT administrator with the ability to assign roles would assign the InBatch roles to himself and then
use his own user name to enter InBatch.
The Active directory should put procedures in place to control the addition of users to an OS group
and generate necessary notifications or audit trail so that new assignments to an OS group used by
InBatch are reviewed by proper authorities in a timely manner.
If no mechanism is available to detect such an event in the operating system, then the usage of OS
User based security provides better control than OS role based security; OS users are created by
an IT administrator but their InBatch roles are configured by the InBatch system administrators
which are defined in the InBatch Security editor. With this configuration, at least two persons are
required to use the system in a fraudulent way: an IT administrator and an InBatch administrator.
The InBatch security editor access can also be set to require a different user from the Environment
In addition to the previous security features, a report can be printed from the InBatch security
editor showing the InBatch roles vs OS groups or users. A manual customer procedure can require
verifying and archiving this report after any security change. Access to this report from the security
editor is depicted in Figure 36.
A part of the output of this report is depicted in Figure 37. We can see here that the role ADM is
associated to a few Active directory users. The applications and functions on the right are available
to a user with engineering role for the specified “Done By” and/or ”Check By” signature.
This requirement is addressed by the content in 4.2.1.1 Signature Uniqueness - 11.100 (a).
4.2.3.2 Password Changes - 11.300 (b)
21 CFR Part 11:
“(b) Ensuring that identification code and password issuances are periodically checked, recalled, or
revised (e.g., to cover such events as password aging).”
Any failed authentication in InBatch is reported in the AuditEvent table as depicted in Figure 38. The
OS security shall also be set to disable a user after a certain number of failed attempts. The reason
for failure is contained in the Reason_ID column. The meaning of the codes is defined in the
StringTable. For example: the two failed (0) reason_ids displayed in Figure 38 correspond to:
1033: “Done By Approved – need Check By”
1018: “Same users for both done by and check by clearance is illegal.”
Figure 38 - Authentication success or failure
SQL Server Alerts can be configured to respond to new records in the AuditEvent table corresponding
to authentication failure. See Microsoft SQL Server documentation.
In addition to this log, Windows security shall be configured to disable a user’s account after
consecutive failed logons.