Is your DDS Audit trail telling you everything it can?

July 5, 2016 / 0 comments / in General  / by Luke Williams

What was the last Data group added to a remote device?  Who edited the data element mapping inside a specific data group, and what was it set to before they changed it?

One of the challenges with administrating a CygNet site can be being aware of the changes made to device configurations, and who made them.

Each service offers a unique set of auditing categories, each with varying levels of depth, and detail.

If a change is made to a data group mapping, can you tell what the previous mapped entries were?  How about changes made to UIS command parameters?  You bet!

The Auditing Keywords section of a service’s configuration file is where auditing parameters are set.

Let’s look at the DDS configuration file, specifically the Auditing Keywords section.

DDS Auditing Keywords

The Audit Level keyword sets the overall level for the entire service.

In the above example, level 1 is set for the entire DDS, and individual keywords can be configured for more detail based on the level of auditing desired.

The Datagroup and UIS Command keywords are set to Level 3, the highest audit level supported by the DDS.  What does audit level 3 include?  To the Help File!

DDS Audited Operations

Using the Help File, under the Auditing > Defining Audit Levels > Service Audit Levels section we find a detailed table of the Audited Operation for each keyword/level.

Let’s compare edits made to a Data Group’s mapping at Level 1 to Level 3…

With the Data Group keyword set to Level 1, I added the DateTime Data Group, and added a new mapping to a Data Element inside that Data Group.

Level 1 Data Group Audit Record

With the Data Group keyword set to Level 3, I added the Shut-In Data Data Group, and mapped, the SWELL UDC to the WELLPLT_00 Facility.  Below is the Audit Record for that action.

Level 3 Data Group Audit Record

In addition to the old value (of nothing, in this case) I see each of the changes made as a result of the new Data Group being added, along with the UDC mapping.

What happens if someone edits an existing mapping inside a data group?  Let’s look at the audit record after an edit has been made to a data element.

Level 3 Data Group Audit Record

With the Data Group keyword set to an audit level of 3, we can track exactly what changes have been made, not just to data groups, but to the individual data elements inside each data group, including UDC and Facility mappings.

This is great!  But what about UIS Commands?  How can you figure out the edits made to Command Components and individual parameters?

In this example, our DDS has its Auditing Keywords UIS Command configured to an Audit Level of 1.  Looking in the AUD Service we find the following Audit Record entry…

Level 1 UIS Command Audit Record

Next, we’ll set the Audi Level to 3 for the UIS Command parameter in the DDS Configuration file.  An edit is next made to the parameter of the Date/Time Data Group of the UIS Command, changing the Contract Hour.

Level 3 UIS Command Audit Record

With Audit Level 3 set, the old value, and the new value is now exposed instead of simply a note that an edit occurred.

Understanding the Audited Operations for each Service is fundamental to setting up each service configuration files to gather the appropriate auditing information.  Doing so can be make modifications easier, but troubleshooting when trying to roll back to a last known configuration is much more feasible when you know what was created/edited, when, and by whom.

For additional information about the Service Audit Levels, check out the Auditing > Defining Audit Level > Service Audit Level section in the CygNet Help File.

Help File Service Audit Levels