Feature #7126
Sequence-Of-Event record being overflowed if binary points “chatter”
0%
Description
IEEE P13 “Beginners Guide to 61850” discussed the problem of binary/analog Sequence-Of-Event record being overflowed if binary points “chatter”.
The changing value will be logged in SOE and eventually cause wanted points to be released due to (memory) resource limits.
Proposal descriptions
There is a chatter filter on binary data; analogue measurements can be treated with deadbands.
- Can the a/m chatter filters be aplied to calculated outputs (or do these functions need to implement timing behaviours to bring down the rate of updating their outputs (ThresholdLN: ‘OpDlTmms’ / ’RsDlTmms’) ?
- Do we need filters for INS/INC and ENS/ENC data?
Updated by Carlos Rodriguez del Castillo about 1 month ago
- Status changed from New to Triage
- Assignee set to Bruce Muschlitz
- Needs More Information changed from No to Yes
The proposal to IEEE was to use FXOT, FXUT to reduce the number of alarms. But the proposal from IEEE was to include chatter behaviour in all CDC (SPS, DPS, ENS, ...).
We think it is outside the scope of the standard to define this behaviour in data types.
Without a real use case is impossible to evaluate this.
Updated by Michael Haecker about 1 month ago
Use case
The use case is that a noisy analog input is monitored by a device with a deadband which is too small. This can happen, for example, when a screw terminal becomes loose in a substation.
For example, an open-circuit input to a high-impedance measurement input point may generate an analog deadband event once every measurement cycle (think about the oscilloscope display when you hold the probe in your hand).
This will cause a sequence-of-event (SOE) log which is configured in “wrap-around” mode to be filled with this “analog chatter” which will cause any desired SOE entries to be ejected from the log before the entries can be retrieved.
For the above purpose, a finite-sized unbuffered or buffered report control may be substituted for the SOE log.
Use case steps:
1. analog deadband and other signals are configured to be placed in the SOE log upon data-change event
2. analog input becomes noisy causing continuous SOE entries
3. significant event occurs in the automation system requiring post-event analysis
4. analog input event count exceeds buffer size of SOE/report control before client begins log/report retrieval
5. attempt to retrieve the significant event results in only retrieving the analog “chatter” resulting in information loss
There are proprietary solutions to this problem which mainly center upon recognition that the event rate for the analog input exceeds some value (in a similar manner that binary inputs are detected to “chatter”) and the analog input events are somehow “throttled”. However there is no way to indicate to the client that this analog event “throttling” is occurring and the automation system might make an error when this happens.
So there are really 2 problems here:
1. Similarly to binary inputs, there is no interoperable method to configure an analog/integer/enumeration chatter filter
2. Unlike binary inputs, there is no way to report that analog events are being suppressed due to excessive transition rate.