Progress zenon projects to FDA 21

CFR Part 11 compliance

History

Date Comment

18.08.2010 Robert Harrison, original author

2
Contents

History ............................................................................................................................................. 2
Contents .......................................................................................................................................... 3
1. Introduction ......................................................................................................................... 4
2. Objective .............................................................................................................................. 4
3. User administration ........................................................................................................... 5
3.1 Users ............................................................................................................... 5
3.2 User groups..................................................................................................... 6
3.3 Active Directory ............................................................................................... 6
3.4 Biometric logon ............................................................................................... 7
3.5 Project properties ............................................................................................ 8
3.6 User administration at runtime ........................................................................ 9
4. Audit-trail ............................................................................................................................. 9
4.1 Process variables .......................................................................................... 10
4.2 Dynamic elements ........................................................................................ 11
4.3 CEL logging................................................................................................... 13
4.4 Alarm logging ................................................................................................ 14
4.5 CEL & Alarm archiving .................................................................................. 15
5. Project wide activity......................................................................................................... 17
5.1 Function authorizations ................................................................................. 17
5.2 History of changes ........................................................................................ 17
5.3 Runtime changeable data ............................................................................. 18
6. Check list ........................................................................................................................... 19

3
 1. Introduction
The regulation process requires the manufacturer of a regulated product to prove and
document that a product meets all claims related to its performance. Regulations provide
the measure of security that the manufacturing process is controlled to meet all quality
and design specifications. The data required must prove that the equipment, material and
processes used in the manufacture will produce the same results each time this product
is produced.

Pharmaceutical and other regulated industries prior to the advent of Part 11 had
paperbased systems for recording regulated processes. The FDA 21 CFR Part 11
outlines the use of electronic records and electronic signatures in this environment, it
defines the criteria for electronic records and signatures to be trustworthy, reliable and
considered equivalent to paper based signatures.

The collection of electronic data must adhere to the strict guidlines, electronic signatures
must be linked to the electronics records, all activity must be recorded in an audit-trail,
security mearsures must be in place to restrict access to systems in the regulated
environment.

Software products themselves cannot be certified or validated, only the end product or
project of the regulated company can be validated. zenon offers the functionalities to
enable project designers to create a validated project.

2. Objective
zenon has the integral functionality to adhere to FDA 21 CFR Part 11 regulations. The
use of integral functionality has a significant advantage in that all projects can be
configured at any stage to be compliant. The process of evolving a project to be
compliant is a simple matter of selecting options to activate User administration, Audit-
trail, Authorizations, and Alarm management.

User administration regulates who can have access to this closed system, restricting
usage to authorized personnel through an username & password verification. Password
aging must enforced, with unsuccessful login attempts being recorded and forcing system
lockouts when unauthorized access is requested.

Each operation, event, and critical exception must be documented, recording who, what,
why, where and when information. Through the audit-trail it must be possible to
reconstruct the complete history of events and processes.

The functionality within a project must be restricted to certain users, using authorization to
limit activity, and force a certain workflow of operations. Authorization levels on dynamic
elements permit which operations can be performed.

Each process variable must have the possibility to have alarm limits attributed. The alarm
limits reflect critical process exceptions, general alarms & warnings.

4
 3. User administration
To access a closed system a user must be authorized by providing a username &
password with a valid account. In zenon different methods are supported to achieve this;
zenon has local user administration, where users are established in both the editor and
run time. The user can be attributed authorization levels directly, and/or be attributed a
User group, where authorization levels have previously been defined to groups organized
by functionality. Windows Active Director (includes ADAM & AD LDS) can also be
established, where user accounts can be managed centrally. Active Directory works in
tandem with local zenon accounts, when logging in Active Directory is first checked, if the
user exists the user is logged in, if the user doesn’t exist in the Active Directory account
local accounts in the zenon project are checked.

Local zenon User accounts can be administred in the editor and in the run-time.

In the editor the creating of User and User Groups is achieved under the item ‘User
administration’ in the Project Manager.

3.1 Users
Under Project properties ‘User administration’ – ‘User’ a new account can be created.
Each user must enter a username, a full name, and a password. Here the administrator
privildeges can be applied, and the user can be locked. The same dialog is opened when
a user account is modified in the runtime.

The final stage is to attribute the authorization levels this user can access, which are later
used in the project to restrict access, only persons with this specific authorization level
can execute the specific functionality.

5
 3.2 User groups

levels to functionalities, e.g. ‘Common

User groups are established to group authorization levels
functionalitites’ are attributed the authorization levels 1-20, ‘Engineers’ have specific
authorization levels of 50-60, ‘Quality’ personnel utilize authorization levels 100-120.

Once user groups have been established when creating or modifying user accounts
under the tab ‘User groups’ the individual groups are displayed, multiple groups can be
selected, therefore an engineer can have ‘Common functionalities’ and the ‘Engineering’
group attributed. Additionally specific authorization levels can be attributed individually,
therefore a user can be a ‘Quality’ user and have additional levels 140-145 attributed.

3.3 Active Directory

Under the ‘User administration’ section in the Project settings ‘User administration’ Active
Directory can be enabled. Simply select ‘Yes’ to enabled access to Active Directory and
supply the connection parameters.

6
If the Active Directory Group name is also a User group name in zenon, this person is
attribute the user group authorization levels.

Individual authorization levels can be set in the Active Directory Group Description using
HEX demonination.

3.4 Biometric logon

Under the FDA regulations access to a system must be through two unique
identifying properties from the user, a username and a password; this ensures as far
as practically possible that the person logging in is the person authorized, and all
reasonable attempts to stop unauthorized use of this login account have been made.

The use of Biometric identification is allowed under

under the FDA regulation, but must
ensure that the account cannot be used by anyone other than the intended user, and
that the biometric system is capable of identifying a person uniquely.

The biometric system connected to zenon will supply one variable with the
identification of the user. This could be a user name, or number. Using the zenon
function ‘Login without password’, this variable can be selected. When a value enters
this variable, if the value is a user with an established account in the project, the user
is logged in.

7
 3.5 Project properties

In the project properties ‘User administration’ several settings must be inplace

• Delete user; should not be set, as user cannot be deleted in a regulated

environment
• Password period of validity (days), should be set, a value above zero will enable
password aging
• Password length, a zero value disables this check
• Maximum User errors, the system will be locked after unsuccessful user ID
attempts
• Maximum Password errors, the user will be locked out after unsuccessfull
password attempts
• Automatic log out (minutes), to only allow a certain access time after logging in

8
Additionally temporary login can be enabled here. When a user accesses a dynamic
element which requires an authorization not currently active in the current login, a dialog
box is opened where a temporary user can be logged in just for this operation.

Once a user or system has been locked out, only a user with administrator privileges can
perform a reset.

3.6 User administration at runtime

User administration continues in the runtime. Two functions enable user administration at
runtime, ‘Change password’ allows a user to modify their password; ‘Change User’ opens
the administrator functionality, where a user can be locked, unlocked, passwords
changed, authorization and user groups attributed, add new users, create or modify user
groups.

4. Audit-trail
The audit-trail must log all activity during runtime. By default the zenon audit-trail
(Choronological Events List ‘CEL’) records system events, such as user log in/out, start of
system. In addition user actions and process variable events can be recorded in the
audit-trail.

Zenon also has integral Alarm management, in this section the activation of both the CEL
& Alarms are each explained, however the two are separate entities and can be operated
independently.

9
 4.1 Process variables
Process variables can be set certain characteristics depending on their purpose. Limit
values are set at the variable to record critical process execptions or warnings. Manual
changes of the variable must log ‘From’ & ‘To’ values, manual changes also require a
reason for the change to be entered.

Under Variable parameters ‘Limits’:

Dynamic or static limits can be applied to a variable, to specify the states of the variable.

The limit violation can be selected to be recorded in the audit-trail (CEL), and in the Alarm
message list. Alarm management
management actions are selected here, with ‘To acknowledge’ and
Alarm group & classes.

Alarms can be classed and grouped, where the group could relate to equipment i.e.
Reactor, Crystalizer, etc, to collate alarms to a specific process area. The class could
relate to the severity of the alarm i.e. Information, Warning, Error, Critical process
exception. These can be utilized & filtered later in the alarm management screen.

Reaction matrices can be also be used to offer the same functionality as limit values, in
addition all states of the variable can be attributed in one dialog:

10
The reaction matrix is first declared and configured. The reaction matrix is then linked to
the variable in the ‘Limits’ area of the variable. Common limits and texts can be defined in
the reaction matrix and then attributed to several variables.

When a variable is under the control

control of the user such as a ‘set point’, manual changes to
the variable must also be logged in the audit-trail, with the old and new values. Logging
can be limited to dynamic elements when an operator makes the changes, or all write
activity of this variable.

4.2 Dynamic elements

To make changes to a variable (such as a set point change) a user must be logged in to
the system with the required authorization to make the change. Each dynamic element
must have an authorization level applied, and once a dynamic element has an
authorization level a user needs this specific level to perform its function.

The authorization level is attributed under the individual dynamic element properties
‘Authorization’, select the authorization level from the drop down box. Additionally a
specific login on each change can be applied, this is achieved by selecting the ‘Signature
necessary’. In this case even when a person is logged in to the system, the user will need
to log in again to facilitate this change.

A signature text can be applied automatically to the dynamic element, this text will appear
in the audit-trail when a manual change is carried out. In most cases the signature text
must be specific to each manual change, where the operator gives a specific reason for
the manual change. This is a global project property, under the ‘User administration’
properties of the project, activate the ‘Signature text editable’ checkbox.

11
The configuration of the audit-trail so far would achieve the following results, when a
manual change to a variable value is carried out:

1. The user is required to log in

2. A reason for the change is demanded from the operator as a signature text
3. The value is changed
4. The event is logged in the CEL

12
 4.3 CEL logging
The CEL data can be logged in two areas; firstly a local ringbuffer is held in memory,
where a limited number of entries are recorded in a First-In-First-Out buffer; secondly
data is stored on the hard disk.

Under the Project properties ‘Chronologic event list’ the behavior can be defined.

The CEL of course needs to be active. Under ‘Column settings CEL’ selection can be
made on the information to be displayed, such as Variable name, User full name, Time,
Unit, etc.

‘Data storage CEL’ section; the ringbuffer is stored in memory and therefore the size is
limted to a default of 100 events, this can be modified to suit a particular installation. As
stated above the CEL can stored in memory as a ringbuffer and in the hard disk
simultaneously. By changing the option ‘Save CEL data’ this behavior is determined.
Selecting ‘Ringbuffer and historic data’ uses both area simultaneously; ‘Only ringbuffer’
would not use the hard disk; ‘Default’ depends on the operating system, under CE only
the ringbuffer is used to save disk space, under other platforms both ringbuffer and hard
disk are used. Enabling ‘Save ringbuffer on change’ will save the CEL to hard disk on
each event, disabling would only save the historic data to disk after 4k of data is
generated, this saves hard disk usage. In a regulated environment due to the potential
loss of data risk the options ‘Save ringbuffer on change’ must be enabled, and the
‘Ringbuffer and historic data’ should be selected. This would record each event to hard
disk, and so in the event of a system crash, or power failure the data generated by the
CEL would be saved.

In the ‘Logging’ section Alarm acknowledge must be checked. Finally the Recipe Group
Manager (RGM) activity should be logged, select ‘Log recipes and values’ for both ‘Send
recipes’ and ‘Change recipes’. This will record the changes made to recipes, and record
which values were transfered to the equipment.

13
Within the calling function to the audit-trail CEL screen, the origin of the data can be
selected to be either the ‘Ringbuffer’ or the ‘Historic data’. If ringbuffer is selected only the
last 100 events are displayed, with historic data the limit is user defined.

Example zenon CEL Audit-trail.

4.4 Alarm logging

The CEL lists all activity during operation including alarms, however the management of
alarms is carried out in the alarm list. Here the alarms can be viewed, filtered,
acknowledged, and comments added.

The setup of the alarm list is similar to the CEL, and is located under Project properties
‘Alarm message list’.

The Alarm Message list must be active, the ringbuffer and historic data must be saved,
with the ringbuffer saved on each change. The behavior of the ringbuffer in the Alarm
message list can be modified, First-In-First-Out, Last-In-First-Out, Reject new, can be
selected.

14
The colours of the alarm status can be modified to suit a specific company standard,
graphic elements can also be used to show alarm status.

The Alarm management function also has a status line, which by default appears at the
top of the screen. Operation of the status line can be activated/deactivated, and the alarm
to display can be selected between oldest or newest alarm.

Example Alarm message list

4.5 CEL & Alarm archiving

The running data within the audit-trail CEL can be archived and so
taken off-line. Three options exist to archive the data within the CEL,
Exporting, Copy the actual CEL file, Print to .pdf. These three
functions are available in zenon, and can be manual or event driven,
such as a on a timed basis.

15
‘Export CEL’ function. Set the relative period of time to be exported.

‘Print CEL’ function. Select the Chronological events list, the project defined printer is
then used.

To copy the CEL file, use the ‘Windows file operations’ function.

16
 5. Project wide activity

5.1 Function authorizations

Under the Project properties ‘User administration’ project wide settings can be applied,
such as loading a project into the editor, acknowledge alarm restrictions. Open the
properties by clicking on the ‘Function authorizations’, and select each property and the
authorization level needed.

5.2 History of changes

The history of changes within a project can be recorded, therefore keeping track
of project activity carried out during development or modification. In the ‘Project
manager’ under ‘History of changes’ all activity is recorded to trace project
advancements, with ‘Form’ and ‘To’ values, the User, Computer name, Date &
Time, etc.

17
The Histroy of changes is activated under Project properties ‘History of changes’, and the
detail level is specified. Displaying changes to ‘Object‘ level will report which screen,
function, variable, etc has changed. ‘Property’ level would report on the property which
has changed, position, color, etc. ‘Values’ would record down to the actual value changes
with Old & New values, e.g. Red to White,

5.3 Runtime changeable data

When first creating the project, all project data needs to be transferred to the runtime;
however once a system is operational certain data must only be changeable by the
runtime. The User administration for example must only be changed using the runtime
system.

To control what is complied in a runtime the ‘RT changeable data’ must be configured.
Under the Project properties ‘General’, click on the ‘RT changeable data’ and a dialog is
opened, enable the checkbox ‘User administration – Do not generate and transfer’. Now
the runtime user administration accounts are not generated when the runtime is
compiled, and so the runtime user administration remains untouched and is secured.

18
 6. Check list
Item
User account
Administrator account
Delete users inactive
Password aging
Max user error
Max password error
Timeout active
Timeout value
RT User administrator
RT User password
Variable limit text
In Alarm Message list active
To acknowledge active
To delete inactive
In Chronological Events list
active
Location Scope Comment
Project properties|Useradministration Once in project Are user accounts created
Project properties|Useradministration Once in project At least one Administrator account needs to
be created
Project properties|Useradministration Once in project Deleting users is not allowed, user are locked
to be made inactive
Project properties|Useradministration Once in project All passwords must expire
Project properties|Useradministration Once in project Unrecognized username signals
unauthorized login, the system is
locked after this number is reached
Project properties|Useradministration Once in project Incorrect password signals unauthorized
login, the user is locked
after this number is reached
Project properties|Useradministration Once in project The logged in user must be automatically
logged out
Project properties|Useradministration Once in project Set the logout time
Functions|Change user Once in project Runtime function must be available to
administer user accounts
Functions|Change password Once in project Runtime function must be available to
change passwords
Variable properties|Limits Each variable Description of the limit violation
Variable properties|Limits Each variable This alarm is listed and managed in the alarm
message list
Variable properties|Limits Each variable Alarms must be acknowledged
Variable properties|Limits Each variable Deleting an alarm is not allowed
Variable properties|Limits Each variable Record limit violations in the audit-trail
Logging All or Only with dyn.
Element
Old and new values active
Variable limit text
In Alarm Message list active
To acknowledge active
To delete inactive
In Chronological Events list
active
Link reaction matrix to
variable
Authorization level
Signature necessary active
Signature text editable active Project properties|Useradministration
CEL active
Save ringbuffer on change
active
Save CEL data, Ringbuffer
and historic data
Alarm acknowledge active
Send recipes, Log recipes and Project properties|Chronologic event list
values
Change recipes, Log recipes
and values
Variable properties|Limits
Variable properties|Limits
Reaction matrix
Reaction matrix
Reaction matrix
Reaction matrix
Reaction matrix
Variable properties|Limits
Dynamic element
Dynamic element
Project properties|Chronologic event list
Project properties|Chronologic event list
Project properties|Chronologic event list
Project properties|Chronologic event list
Project properties|Chronologic event list
Each variable Select the logging activity, operator and
automated activity
Each variable Record the 'From' and 'To' values when
changing values
For each set of values Description of the limit violation
For each set of values This alarm is listed and managed in the alarm
message list
For each set of values Alarms must be acknowledged
For each set of values Deleting an alarm is not allowed
For each set of values Record limit violations in the audit-trail
Each variable The reaction matrix needs to be used with a
variable
for each restricted activity, Set the required level of authorization for this
e.g. set point change functionality
For each restricted activity, Force a user to login when a value change is
e.g. set point change requested
Once in project Allow the user to add a comment when a
change is carried out
Once in project Activate the audit-trail operation
Once in project Save each audit-trail event to the hard disk
Once in project Save audit-trail to both memory and hard
disk
Once in project Record alarm acknowledgments in the audit-
trail
Once in project When a recipe is sent to the PLC the value
changes are written to
the audit-trail
Once in project When a recipe is changed the value changes
are written to the audit-trail
20
Alarm Message list active
Save ringbuffer on change
active
Save AML data, Ringbuffer
and historic data
History of changes active
Detailing level, value change
RT changable data, User
administration
Project properties|Alarm Message list Once in project Activate the alarm management operation
Project properties|Alarm Message list Once in project Save each alarm event to the hard disk
Project properties|Alarm Message list Once in project Save alarm to both memory and hard disk
Project properties|History of changes Once in project Record project activity
Project properties|History of changes Once in project Record with the all information
Project properties|General|RT changable Once in project In design the user accounts can be written to
data the runtime, during
operation this must not happen
21
© 14.09.2009 COPA-DATA GmbH

All rights reserved.

Distribution and/or reproduction of this document or parts thereof in any form are permitted solely
with the written permission of the COPA-DATA company. The technical data contained herein have
been provided solely for informational purposes and are not legally binding. Subject to change,
technical or otherwise.