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, Audittrail, 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 User groups are e established to group authorization levels to functionalities, e.g. Common 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 d 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 ditional 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 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 trail (CEL), and in the Alarm message list. Alarm management actions are selected here, with To acknowledge and Alarm group & classes. Alarms 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 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 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 Location Scope Comment 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 Variable properties Limits Each variable Record limit violations in the audit-trail
Logging All or Only with dyn. Variable properties Limits Each variable Select the logging activity, operator and Element 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 Reaction matrix For each set of values Record limit violations in the audit-trail active 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, Force a user to login when a value change is e.g. set point change 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 Project properties Chronologic event list Once in project Save each audit-trail event to the hard disk active 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 audittrail Send recipes, Log recipes and Project properties Chronologic event list Once in project When a recipe is sent to the PLC the value values changes are written to Change recipes, Log recipes and values Project properties Chronologic event list Once in project the audit-trail When a recipe is changed the value changes are written to the audit-trail 20
Alarm Message list active Project properties Alarm Message list Once in project Activate the alarm management operation Save ringbuffer on change Project properties Alarm Message list Once in project Save each alarm event to the hard disk active Save AML data, Ringbuffer Project properties Alarm Message list Once in project Save alarm to both memory and hard disk and historic data 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 Project properties General RT changable Once in project In design the user accounts can be written to administration 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.