Progress zenon projects to FDA 21 CFR Part 11 compliance

(1)

Progress zenon projects to FDA 21

CFR Part 11 compliance

(2)

History

Date Comment

18.08.2010 Robert Harrison, original author

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

(5)

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.

(6)

3.2 User groups

User groups are established to group authorization level functionalitites’ are attributed the authorization levels 1 authorization levels of 50

Once user groups have been

under the tab ‘User groups’ the individual groups are displayed, selected, therefore an

group attributed. Additionally specific authorization levels can be attributed individually, therefore a user can be a

3.3 Active Directory

Under the ‘User administration’ section in the P

Directory can be enabled. Simply select ‘Yes’ to enabled access to Active Directory and supply the connectio

User groups

e established to group authorization levels to functionalities, e.g. are attributed the authorization levels 1-20, ‘Engineers

authorization levels of 50-60, ‘Quality’ personnel utilize authorization levels 100

user groups have been established when creating or modifying user under the tab ‘User groups’ the individual groups are displayed, multiple group selected, therefore an engineer can have ‘Common functionalities

group attributed. Additionally specific authorization levels can be attributed individually, therefore a user can be a ‘Quality’ user and have additional levels

Active Directory

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

s to functionalities, e.g. ‘Common Engineers’ have specific personnel utilize authorization levels 100-120.

d when creating or modifying user accounts multiple groups can be ommon functionalities’ and the ‘Engineering’ group attributed. Additionally specific authorization levels can be attributed individually,

ditional levels 140-145 attributed.

‘User administration’ Active Directory can be enabled. Simply select ‘Yes’ to enabled access to Active Directory and

(7)

If the Active Directory

attribute the user group authorization levels.

Individual authorization levels can be set HEX demonination

3.4 Biometric logon

Under the FDA regulations access to a system must be through two unique identifying properties from the user,

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 und

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 identification of the user. This

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, th is logged in.

irectory Group name is also a User group name in zenon attribute the user group authorization levels.

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

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 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 identification of the user. This could be a user name, or number. Using the

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, th

zenon, this person is

in the Active Directory Group Description using

Under the FDA regulations access to a system must be through two unique

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.

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

will supply one variable with the 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

(8)

3.5 Project properties

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

• Delete user; should not be set, as environment

• Password password aging

• Password length, a zero value disables this check

• Maximum User errors, the system will be locked after unsuccessful user ID attempts

• Maximum Passwo password attempts • Automatic log out

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 reg 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 In the project properties ‘User administration’ several settings must be inplace

user cannot be deleted in a regulated

, should be set, a value above zero will enable

Maximum User errors, the system will be locked after unsuccessful user ID

after unsuccessfull

(9)

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.

(10)

4.1 Process variables

Process variables can be set certain values are set at the variable changes of the variable

reason for the change to be entered.

Under Variable parameters ‘Limits

Dynamic or static l

The limit violation can be selected to be recorded in the audit message list. Alarm managemen

Alarm group & classes

Alarms can be classed and groupe Reactor, Crystalizer

relate to the severity of the alarm i.e. Information, Warning, exception. These can be utiliz

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:

Process variables

Process variables can be set certain characteristics depending on their are set at the variable to record critical process execptions or

of the variable must log ‘From’ & ‘To’ values, manual changes for the change to be entered.

ariable parameters ‘Limits’:

Dynamic or static limits can be applied to a variable, to specify the s

iolation can be selected to be recorded in the audit-trail (CEL)

larm management actions are selected here, with ‘To acknowledge’ and Alarm group & classes.

s 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 states of the variable can be attributed in one dialog:

characteristics depending on their purpose. Limit rocess execptions or warnings. Manual must log ‘From’ & ‘To’ values, manual changes also require a

specify the states of the variable.

trail (CEL), and in the Alarm t actions are selected here, with ‘To acknowledge’ and

late to equipment i.e. to collate alarms to a specific process area. The class could

Error, Critical process later in the alarm management screen.

(11)

The reaction matrix is first

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 cont

the variable must also be logged in the audit

can be limited to dynamic elements when an operator makes the activity of this variable

4.2 Dynamic elements

To make changes

the system with the required authorization to make the change. Each dynamic element must have an authorization level

authorization level a user needs this specific level to perform its function.

The authorization level ‘Authorization’, sel

specific login on each change can be applied, this is achieved by selecting the ‘Signature necessary’. In this case even when

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.

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

can be limited to dynamic elements when an operator makes the changes, or all write this variable.

Dynamic elements

make changes to a variable (such as a set point change) a user must be

the system with the required authorization to make the change. Each dynamic element have an authorization level applied, and once a dynamic element has an

authorization level a user needs this specific level to perform its function.

ation level is attributed under the individual dynamic element properties ‘Authorization’, select the authorization level from the drop down box.

specific login on each change can be applied, this is achieved by selecting the ‘Signature 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.

text can be applied automatically to the dynamic element, this text will appear 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.

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

rol of the user such as a ‘set point’, manual changes to trail, with the old and new values. Logging

changes, or all write

user must be logged in to the system with the required authorization to make the change. Each dynamic element

c element has an authorization level a user needs this specific level to perform its function.

dynamic element properties the drop down box. Additionally a specific login on each change can be applied, this is achieved by selecting the ‘Signature

a person is logged in to the system, the user will need

text can be applied automatically to the dynamic element, this text will appear 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.

(12)

The configuration of the audit manual change to a variable value

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

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

The user is required to log in

A reason for the change is demanded from the operator as a signature text The value is changed

The event is logged in the CEL

trail so far would achieve the following results, when a

(13)

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.

(14)

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.

(15)

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.

(16)

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

(17)

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.

(18)

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

(19)

User account

Project properties|Useradministration

Once in project

Are user accounts created

Administrator account

Project properties|Useradministration

Once in project

At least one Administrator account needs to

be created

Delete users inactive

Project properties|Useradministration

Once in project

Deleting users is not allowed, user are locked

to be made inactive

Password aging

Project properties|Useradministration

Once in project

All passwords must expire

Max user error

Project properties|Useradministration

Once in project

Unrecognized username signals

unauthorized login, the system is

locked after this number is reached

Max password error

Project properties|Useradministration

Once in project

Incorrect password signals unauthorized

login, the user is locked

after this number is reached

Timeout active

Project properties|Useradministration

Once in project

The logged in user must be automatically

logged out

Timeout value

Project properties|Useradministration

Once in project

Set the logout time

RT User administrator

Functions|Change user

Once in project

Runtime function must be available to

administer user accounts

RT User password

Functions|Change password

Once in project

Runtime function must be available to

change passwords

Variable limit text

Variable properties|Limits

Each variable

Description of the limit violation

In Alarm Message list active

Variable properties|Limits

Each variable

This alarm is listed and managed in the alarm

message list

To acknowledge active

Variable properties|Limits

Each variable

Alarms must be acknowledged

To delete inactive

Variable properties|Limits

Each variable

Deleting an alarm is not allowed

In Chronological Events list

active

(20)

Logging All or Only with dyn.

Element

Variable properties|Limits

Each variable

Select the logging activity, operator and

automated activity

Old and new values active

Variable properties|Limits

Each variable

Record the 'From' and 'To' values when

changing values

Variable limit text

Reaction matrix

For each set of values

Description of the limit violation

In Alarm Message list active

Reaction matrix

For each set of values

This alarm is listed and managed in the alarm

message list

To acknowledge active

Reaction matrix

For each set of values

Alarms must be acknowledged

To delete inactive

Reaction matrix

For each set of values

Deleting an alarm is not allowed

In Chronological Events list

active

Reaction matrix

For each set of values

Record limit violations in the audit-trail

Link reaction matrix to

variable

Variable properties|Limits

Each variable

The reaction matrix needs to be used with a

variable

Authorization level

Dynamic element

for each restricted activity,

e.g. set point change

Set the required level of authorization for this

functionality

Signature necessary active

Dynamic element

For each restricted activity,

e.g. set point change

Force a user to login when a value change is

requested

Signature text editable active Project properties|Useradministration

Once in project

Allow the user to add a comment when a

change is carried out

CEL active

Project properties|Chronologic event list Once in project

Activate the audit-trail operation

Save ringbuffer on change

active

Project properties|Chronologic event list Once in project

Save each audit-trail event to the hard disk

Save CEL data, Ringbuffer

and historic data

Project properties|Chronologic event list Once in project

Save audit-trail to both memory and hard

disk

Alarm acknowledge active

Project properties|Chronologic event list Once in project

Record alarm acknowledgments in the

audit-trail

Send recipes, Log recipes and

values

Project properties|Chronologic event list Once in project

When a recipe is sent to the PLC the value

changes are written to

the audit-trail

Change recipes, Log recipes

and values

Project properties|Chronologic event list Once in project

When a recipe is changed the value changes

(21)

Alarm Message list active

Project properties|Alarm Message list

Once in project

Activate the alarm management operation

Save ringbuffer on change

active

Project properties|Alarm Message list

Once in project

Save each alarm event to the hard disk

Save AML data, Ringbuffer

and historic data

Project properties|Alarm Message list

Once in project

Save alarm to both memory and hard disk

History of changes active

Project properties|History of changes

Once in project

Record project activity

Detailing level, value change

Project properties|History of changes

Once in project

Record with the all information

RT changable data, User

administration

Project properties|General|RT changable

data

Once in project

In design the user accounts can be written to

the runtime, during

(22)

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.

Progress zenon projects to FDA 21 CFR Part 11 compliance