Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Batch Management

Audit Trail - 11​.10 (e)

  • Last UpdatedMar 06, 2025
  • 6 minute read

21 CFR Part 11:

(e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

Capturing System Information and Audit Trails

In AVEVA Batch Management, 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.

Figure 25 - Batch Historian ArchiveHistory

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.

Figure 26 - Admin web security enabled

Figure 27 shows the page giving access to the archiving, purging and error queue functions.

Figure 27 - Archiving, purging and Error Queue management

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.

Figure 28 – Batch History Archiving Configuration

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 AVEVA Batch Management 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).

Changes to recipe data

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.

Figure 29 - Securing Recipe approval

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.

Figure 30 - Recipe comparison report

Changes to values at execution time 

The following data is logged in the BatchHistory database along with the automatically generated DateTime information and the user information (provided that the AVEVA Batch Management 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 AVEVA Batch Management or other AVEVA features. 

 

Table 2 - BatchHistory Tables with user information 

Table 

Data including user id 

Remark 

AuditEvent 

[Audit_Event_ID]

,[User_ID]

      ,[User_Name] 

      ,[App_Name] 

      ,[Func_Name] 

      ,[Func_Lvl] 

      ,[DateTime] 

      ,[Op_Station] 

      ,[Recipe_ID] 

      ,[PassFail] 

      ,[Reason_ID] 

      ,[Batch_Server_Name] 

The AuditEvent table contains one record for every security system event that is generated during batch processing.   

The Func_Name defines why the signature occurred (Start Batch, Enter Comment, etc).   

The Func_Lvl indicates if the record corresponds to a "Done By" or "Check By" signature. 

The reason explains why the event passed or failed (ex: "Password reuse timeout prevents entry of password at this time").                                                                                                                                                                                            

BatchAdmin 

[BatchAdmin_ID] 

      ,[Create_DT] 

      ,[Start_DT] 

      ,[End_DT] 

      ,[Completion_CD] 

      ,[Completion_DT] 

      ,[Scheduled_by_User] 

      ,[Archive_Desc] 

      ,[Archive_Device] 

      ,[Archive_FileName] 

      ,[Purge_IND] 

      ,[Restore_IND] 

      ,[Archive_IND] 

      ,[Status_CD] 

      ,[Target_DB] 

      ,[Status_Desc] 

      ,[Schedule_DT] 

The BatchAdmin table contains records for archive tasks defined in the history archive. The history archive controls the data in this table. 

BatchDetail 

[Batch_Log_ID] 

      ,[DateTime] 

      ,[UnitOrConnection] 

      ,[UnitProcedure_ID] 

      ,[Operation_ID] 

      ,[Phase_ID] 

      ,[Phase_Instance_ID] 

      ,[DoneBy_User_ID] 

      ,[Phase_Label] 

      ,[CheckBy_User_ID] 

      ,[Action_CD] 

      ,[Batch_Server_Name] 

The BatchDetail table contains a record for every event in the processing of a batch.  Events are defined using an action code.  The action codes are defined in the CodeTable table.  Batch Manager controls the data in this table. 

Note that all batch events are recorded in this table but the DoneBy_User_ID and CheckBy_User_ID are populated only if the corresponding functions in the Batch Client are associated to DoneBy and CheckBy roles and if the security is enabled.  Signatures for both phases and transitions are recorded in this table. 

ProcessVarChange 

 

 

[Batch_Log_ID] 

      ,[DateTime] 

      ,[UnitOrConnection] 

      ,[UnitProcedure_ID] 

      ,[Operation_ID] 

      ,[Phase_ID] 

      ,[Phase_Instance_ID] 

      ,[Phase_Label] 

      ,[DoneBy_User_ID] 

      ,[Parameter_ID] 

      ,[CheckBy_User_ID] 

      ,[Old_Target_Value] 

      ,[New_Target_Value] 

      ,[UnitOfMeasure] 

      ,[Batch_Server_Name] 

The ProcessVarChange table contains a record for every change made to a phase process variable "Target" parameter by an operator during a batch. 

 

Important: Changes to the target that come from I/O are not logged to BatchHistory. The value must be changed by the operator 

 

Changes to "Actual" parameters are not logged in this table.  The final value of an "Actual" parameter is logged at the end of a phase in the ProcessVar table with no user information. 

When a user edits a phase parameter, whether it is a target or actual, his signature is logged in the AuditEvent table. The value of the actual is not logged with this record though.  If it is important to log the intermediate values that were entered by the operator, the parameter actual should be historized differently.  For example, the corresponding Actual attribute in the A2 phase object could be historized in the AVEVA Historian. 

MaterialInputChange 

 

 

[Batch_Log_ID] 

      ,[DateTime] 

      ,[UnitOrConnection] 

      ,[UnitProcedure_ID] 

      ,[Operation_ID] 

      ,[Phase_ID] 

      ,[Phase_Instance_ID] 

      ,[Phase_Label] 

      ,[Material_Parameter] 

      ,[Material_ID] 

      ,[DoneBy_User_ID] 

      ,[CheckBy_User_ID] 

      ,[Old_Target_Qty] 

      ,[New_Target_Qty] 

      ,[Batch_Server_Name] 

The MaterialInputChange table contains a record for every quantity change made by an operator for a material consumed in a batch. Batch Manager controls the data in this table. 

OperatorComment 

 

 

[Batch_Log_ID] 

      ,[DateTime] 

      ,[UnitOrConnection] 

      ,[UnitProcedure_ID] 

      ,[Operation_ID] 

      ,[Phase_Instance_ID] 

      ,[Phase_ID] 

      ,[Phase_Label] 

      ,[DoneBy_User_ID] 

      ,[CheckBy_User_ID] 

      ,[Operator_Comment] 

      ,[SeqNum] 

      ,[Batch_Server_Name] 

The OperatorComment table contains a record for every comment entered by an operator during a batch. 

BatchQuestion 

 

[Batch_Log_ID] 

      ,[DateTime] 

      ,[DoneBy_User_ID] 

      ,[CheckBy_User_ID] 

      ,[Question] 

      ,[Answer] 

      ,[Batch_Server_Name] 

The BatchQuestion table contains a record for every question shown to and answered by the operator during the processing of a batch.  Batch Manager controls the data in this table.   

 

EquipStatus 

 

[UnitOrSegment] 

      ,[DateTime] 

      ,[New_Status] 

      ,[Old_Status] 

      ,[Recipe_ID] 

      ,[Last_Recipe_ID] 

      ,[DoneBy_User_ID] 

      ,[CheckBy_User_ID] 

      ,[Operator_Comment] 

      ,[ESField1] 

      ,[ESField2] 

      ,[ESField3] 

      ,[ESField4] 

      ,[ESField5] 

      ,[ESField6] 

      ,[ESField7] 

      ,[ESField8] 

      ,[Batch_Server_Name] 

      ,[Formula_Name] 

      ,[Last_Formula_Name] 

The EquipStatus table contains a record for every unit or segment status transition.   Batch Manager controls the data in this table. 

DocViewEvent 

 

 

[Batch_Log_ID] 

      ,[UnitORConnection_ID] 

      ,[UnitProcedure_ID] 

      ,[Operation_ID] 

      ,[Phase_ID] 

      ,[Phase_Instance_ID] 

      ,[Phase_Label] 

      ,[DoneBy_User_ID] 

      ,[CheckBy_User_ID] 

      ,[DateTime] 

      ,[Doc_Loc] 

      ,[Doc_Desc] 

      ,[Batch_Server_Name] 

The DocViewEvent table contains one record for each event that is 

generated when an operator must view and acknowledge an external document. 

In This Topic
TitleResults for “How to create a CRG?”Also Available in