Operator Logs to SQL

Hi Mike,

PlantSCADA has the Tag Write Event queue which can intercept all writes to IO devices, and you can take the context and add to some record.  See here for details: TagWriteEventQue | Tag Functions | Cicode (aveva.com)

Also, I recommend logging to the SOE table as this allows you to place the logs in line with other significant events.  See here for details: SOEEventAdd | Sequence of Events Functions | Cicode (aveva.com).   Note that for SOEEventAdd to work, the event needs to be associated with an alarm.  There was some talk about removing this restriction, but it seems they might not have gotten around to it yet.  So an easy way to work around this is to have a dummy alarm in each piece of equipment with a consistent name which tag write events are logged against.  I have used this mechanism successfully on several projects.

Hope this helps

Stuart

Hi Mike,

PlantSCADA has the Tag Write Event queue which can intercept all writes to IO devices, and you can take the context and add to some record.  See here for details: TagWriteEventQue | Tag Functions | Cicode (aveva.com)

Also, I recommend logging to the SOE table as this allows you to place the logs in line with other significant events.  See here for details: SOEEventAdd | Sequence of Events Functions | Cicode (aveva.com).   Note that for SOEEventAdd to work, the event needs to be associated with an alarm.  There was some talk about removing this restriction, but it seems they might not have gotten around to it yet.  So an easy way to work around this is to have a dummy alarm in each piece of equipment with a consistent name which tag write events are logged against.  I have used this mechanism successfully on several projects.

Hope this helps

Stuart

Although you can use SOEEventAdd with alarms, you don't have to. Here's a Cicode function I used in the past to log user logins to SOE. You just leave the alarm tag argument blank.

// FUNCTION LoginToSummary
// This function displays a message on the summary page when the login is changed.

FUNCTION
LoginToSummary(INT bLogin);
 STRING sCurrentUser;
 STRING sNewUser;
 STRING sMessage;

 sCurrentUser = UserInfo(2);
 IF bLogin = TRUE THEN
 IF LoginForm() = 0 THEN
 sNewUser = UserInfo(2);
 IF sCurrentUser = "" THEN
 sMessage = sNewUser + " Logged In";
 ELSE
 sMessage = sCurrentUser + " Logged Out, " + sNewUser + " Logged In";
 END
 ELSE
 sMessage = "Failed to Log In";
 END
 ELSE //Log out
 IF Logout() = 0 THEN
 sMessage = sCurrentUser + " Logged Out";
 ELSE
 sMessage = "Failed to Log Out " + sCurrentUser;
 END
 END

 SOEEventAdd(TimestampCurrent(), sMessage, "");
END

That's interesting Eric.  We also found that we couldn't use the SOEEventAdd function unless we specified an alarm tag (that was tested using 2018 R2, but I don't know if that's changed since then).

Note that the SOE logs will obviously get archived at some point (along with the rest of the alarms), so people need to keep that in mind.

Thanks Eric, quite correct, if you don't specify an alarm, an entry is still created, but it has no equipment context.  If that isn't a requirement then that's fine, but I think in modern control systems, this would be missing an important feature!