Excessive Event Journal Logging

[sbeadle1]

📖 Home  Back  
A point can be configured to log an event when the point changes state. This can cause problems when a point is fluctuating between states as an excessive amount of events can be logged.

You can reduce the number of events logged by reducing the number of point state changes reported by the outstation or by filtering out certain point state changes at the master station. The following sections describe the action you can take depending on whether your extra event messages relate to analog or digital points:

Excessive Events for Analog Points

For analog points, the point changes state whenever its value rises above or drops below one of the defined point limits. For example, if an analog point is configured with a High limit of 80 and the point value rises to 84, the point will change state from Normal to High and an event will be logged.

It is possible for an analog point to 'jitter'. This means that the value of the point fluctuates quickly between a value below a limit and a value above a limit, which results in an excessive amount of events being logged. A common example of this is an analog point that is used to represent a flow meter. As a flow meter will rarely report a consistent value, even if the flow is consistent, it is likely that the point value will fluctuate. This may cause an excessive amount of events to be logged.

For example, let's assume that the point's High limit is 40. The flow meter is reporting values around 40 - some values are below the 40 limit, and some values are 40 or are above the 40 limit. Every value that causes the point value to rise to or above the 40 limit or drop below the 40 limit will cause an event to be logged. This means that an excessive number of events will be logged.

To prevent fluctuating point values from causing excessive amounts of events from being logged, you need to:

• Reduce the number of values (around the defined limit) that are reported by the outstation or similar device. To do this, you need to determine whether your outstation provides any event deviation features that set the outstation to only report values that cross a limit boundary by a defined amount or percentage. Quite often, these features can only be set by configuring the outstation locally or by using a Logic program in the outstation. However, some outstations can support having these settings downloaded from ClearSCADA.

• Prevent the point from changing state when its value crosses a point limit by a defined amount (using Hysteresis) or duration (using Persistence). To do this, you can apply the following features in ClearSCADA:

• Hysteresis

Prevents a point from changing state when its value is moving towards normal (i.e. dropping below a High limit or rising above a Low limit). The point will only change state when its value has moved towards normal by a specified amount.




For example, if the Hysteresis is set to 5, the point's Low limit is 25 and the point's value rises from 20 (Low) to 26, the point will not change state, even though its value is moving towards normal and has crossed the Low limit. The Hysteresis feature ensures that the point's state will only change if the point's value moves towards normal by at least the Hysteresis amount. So, if the point value was 20 and increased to 30, the point would change state as it has moved towards normal over a point limit by the Hysteresis amount. As events are only logged when the point changes state, reducing the amount of times the point changes state also reduces the number of events that are logged.




You can configure the Hysteresis setting on the Point Form for each database point (on outstations that support Hysteresis). For more information, see ClearSCADA Help.

• Persistence

Sets a point so that the point only changes state when it has remained in its new state for a defined amount of time. For example, on some outstations, a point could be configured to have a High limit of 60 and a Persistencesetting of 10 seconds (for values rising away from Normal). The point's current value is 58, which then rises to 64. The point's value drops back to 58 within 3 seconds, and so a point state change is not reported, even though the point value did cross the point limit boundary. As the point did not change state, an event was not logged. If the point's current value had remained above 60 for 10 seconds or more, the point state would have changed and an event would have been logged (as the point value would have crossed the point limit boundary for the Persistence time).




The configuration settings for the Persistence feature vary according to the type of outstation being used. For those outstations that support Persistence configuration downloaded from ClearSCADA, you can configure the Persistence setting on the Point Form for each database point. For more information, see ClearSCADA Help. For other types of outstation, you should refer to the outstation hardware documentation for more information.

• If you cannot prevent the point from frequently changing state, the only way to reduce the number of events is to disable event logging for the relevant point limit. For example, if an excessive amount of events are being logged because a point value frequently rises above and drops below a High point limit of 40, you should disable event logging for the High limit.

You can enable and disable event logging for point states by using the Point Form for each database point. For more information, see ClearSCADA Help.

Excessive Events for Digital Points

To reduce the amount of unnecessary events being logged for a digital point that frequently changes state:

• If there are an excessive number of events relating to a digital point changing state, you should use the Persistence setting (if supported by the outstation). By configuring the digital point to use Persistence, you ensure the point updates only change the state of the point if the point remains in the new state for a defined amount of time (the Persistence time). For example, if a digital point jitters between State 0 and State 1 every second, this will cause the point state to change every second and therefore an event will be logged every second. However, if the Persistence feature is set to 5 seconds, the point will only change state if it changes state and remains in the new state for 5 seconds. So, if the point changes state from State 0 to State 1 and remains in State 1 for at least 5 seconds, the point state will be updated and an event will be logged. If the point changed state from State 1 back to State 0 in less than 5 seconds, the point state would not update and so an event would not be logged.

The Persistence (at the outstation) feature is supported by most advanced drivers. You can configure the Persistence setting for digital points on the Point Form. For more information, see ClearSCADA Help.




For simple drivers, you may be able to use the Persistence feature at the master station (see below).

• If you are using a simple driver outstation that does not support Persistence at the outstation, you may be able to apply Persistence at the master station (some points cannot use Persistence at either the outstation or master station).

Persistence at the master station works in the same way as Persistence at the outstation, except that the master station determines whether a point has remained in its new state for the required Persistence time. This can be less accurate than Persistence applied at the outstation as it is dependent on the master station being able to scan or poll the outstation for the point's data. To be successful, the Persistence time for the point must be set to be equal to or greater than the amount of time it takes the master station to poll the outstation for the point's data.




You can define the Persistence (at the master station) time for digital points by using the Digital Point Form. If the relevant simple driver supports Persistence at the master station, you can set the Persistence time on the __ tab of the Digital Point Form, for example, for a Modbus digital point, the Persistence setting is on the Modbus tab of the Digital Point Form.

• Check the configuration of the digital point.

If the digital point does not have its states set to Fleeting, you may be able to alter the configuration of the digital point so that it does not log redundant event messages.




A common cause of excessive events for a 1 bit digital point is that the point is configured to have one state set to trigger an alarm and another state set to log an event. As ClearSCADA logs all alarms in the Event Journal as they are raised and when they are cleared, there is no need for the digital point's other state(s) to be set to log an event. If you enable event logging for the non-alarm state for a 1 bit digital point, this will cause extra events to be logged. To reduce the number of events that are logged, ensure that the 1 bit digital point is configured so that its non-alarm state does not log an event.




For example, if a digital point is configured to have State 0 set to log events and State 1 set to trigger an alarm. When the point enters State 1 an alarm is raised and an event is logged. When the alarm is cleared, the point changes to State 0 and two events are logged - both events relate to the point returning to State 0. So, the number of events logged can be reduced by configuring State 0 so that it does not log an event.




You can also use this technique on 2 bit and 3 bit digital points but only if they have a maximum of 1 state set to None. If they are configured to have 2 or more states set to None, there will be no events for changes between the those states. For example, if a 2 bit digital point is configured to have State 0 set to Alarm, and State 1, State 2, and State 3 are set to None(do not cause alarms to be raised or events to be logged), there will only be an event logged when the point changes from State 1, 2 or 3 to State 0 or from State 0 to State 1, 2, or 3. If the point changes between any of the non-alarm states (State 1 to State 2, State 2 to State 3 etc.), there will be no event logged as these states are set to* None*. This means there will be no record of the state changes in the Event Journal.




Another limitation is that if a digital point is configured to have one state set to Alarm and another state set to None, an event will not be logged if the alarm is removed before the point changes back to the None state. For example, if a 1 bit digital point has State 0 set to Alarm and State 1 set to None, an alarm is raised for the point when the point changes from State 1 to State 0. If that alarm is removed (by using the Remove pick action) while the point is still in State 0, there will be no event logged when the point changes from State 0 to State 1 (as State 1 is set to None and an event will not be logged for the alarm being cleared as the alarm has been removed).




Note that if the states of a digital point are set to Fleeting, the point's alarms are removed as soon as they are acknowledged. This means that they do not cause an event to be logged if the point then changes to another state.

• If your outstation does not support Persistence, you cannot apply Persistence at the master station, and you cannot reduce the number of events logged by altering the point's configuration, your only remaining option is to use the Point Form to disable event logging for the point (see ClearSCADA Help).

After disabling event logging for a digital point, you can still view a full record of the state changes for the point by enabling the Historic feature for the point (again, by using the Point Form). If the Historic feature is enabled, you can view the point's state changes in the Historic List and on Trends. Normally, you would only use the Event Journal to record digital point state changes on points that do not change state quickly.




For example, if a pump starts 100 times a day and there are 100 pumps in the system, there would be a total of over 20000 events per day (200 events per pump - 1 event for starting, and 1 event for stopping). As each event record uses 768 bytes of disk space, this means that nearly 15MB of data is being stored to disk every day, just for pump starts. So when you search the Event Journal, you need to search through an extra 15 MB of records per day.




The historic database is much more efficient, using only 32 bytes per historic record, which would mean a daily total of 0.6 MB instead of 15 MB. So, for digital points that have all states set to Event or None and change state frequently, you really should use the historic features instead of the Event Journal.


Go: Home Back