PVSS00event - SYS/INFO - AlertBinarySignal/AlertNonBinarySignal, handleNewValue, newValueTime

Enclosed you'll find the explanation for a log-message which can occur when an alert is raised, the log-message is written to the PVSS_II.log-file.

Example for the log-message for binary alerts:

PVSS00event (0), 2010.12.08 22:03:36.628, SYS, INFO, 86, Invalid value, DP: System1:Plant_1.state.off:_original.._value, AlertBinarySignal, handleNewValue, newValueTime (2010.12.08 22:03:01.000) set to: 2010.12.08 22:03:10.907

Example for the log-message for non-binary alerts:

PVSS00event (0), 2010.12.08 22:03:36.628, SYS, INFO, 86, Invalid value, DP: System1:Plant_1.state.level:_original.._value, AlertNonBinarySignal, handleNewValue, newValueTime (2010.12.08 22:03:01.000) set to: 2010.12.08 22:03:10.907

Log-message with symbolic names:

PVSS00event (0), <TIMESTAMP>, SYS, INFO, 86, Invalid value, DP: <dp-element-name>, AlertBinarySignal, handleNewValue, newValueTime (<time1>) set to: <time2>

PVSS00event (0), <TIMESTAMP>, SYS, INFO, 86, Invalid value, DP: <dp-element-name>, AlertNonBinarySignal, handleNewValue, newValueTime (<time1>) set to: <time2>

This log-message describes that the timestamp for the alert is corrected. The alert-information in WinCC OA has to be in the correct chronological order.
In this case a newer alert-state is already saved in the process image with timestamp time2 and therefore the alert cannot be generated with the timestamp time1 which is written to the original-value.

Here is one example which could lead to this log-message:
-- an alert for DP-A is pending
-- the _alert_hdl-config is deactivated
-- the _alert_hdl-config is activated
-- during the activation a new alert is generated with the current time (time2)
-- the original-value for DP-A is set again with a timestamp before time2 (time1)
-- a new alert cannot be generated for time1 because a newer timestamp (time2) is already stored
The alert-time is corrected to time2 and the log-message is written.