Exception filtering
Exception filtering uses a deadband algorithm to determine whether to collect data and store it in the FactoryTalk Historian ME archive. For each point, you can set exception reporting specifications that create the deadband. The data collection service throws out values that fall inside the deadband and does not pass them to the archive.
In the figure above, values A, D, and C are reported to the FactoryTalk Historian ME server. Value A is the last reported value, and values B and C fall within the exception deadband. However, value D falls outside the deadband, so the data collection service reports value D as well as the previous value (in this case, value C).
The data collection service uses the following point attributes to choose the values that will be reported to the Historian ME server:
- Exception Deviation (ExcDev)It determines in engineering units how much a point value needs to change before the data collection service sends it to the Historian ME server.The exception deviation should be less than the compression deviation by at least a factor of 2.For example, a 12-bit A/D converter can never be more precise than 1 part in 4096.This attribute is used with the ExcDevPercent value.You can set either the ExcDev or the ExcDevPercent attribute. If you change one, the other is automatically adjusted. If you change both at once, the value of the ExcDevPercent attribute takes precedence.
- Exception Max (ExcMax)It sets a limit on how long the data collection service can go without reporting a value to the Historian ME server.Once the value of the attribute is exceeded, the data collection service sends the next new value to the Historian ME server, regardless of whether the value is different from the last reported value.The time between exception reports might be greater than the exception maximum time if no new values are received by the data collection service for a point.
- Exception Min (ExcMin)It sets a limit in seconds on how frequently the data collection service reports values.For example, if you want the data collection service to wait full ten minutes before reporting a new value to the Historian ME server, set the ExcMin attribute to ten minutes.A new data value that is received before the end of the ExcMin interval is discarded.
The exception algorithm relies on the following parameters:
This parameter | Defines |
|---|---|
Exception Maximum | The maximum time span between exceptions, expressed in seconds. This value is configured for each point in the ExcMax attribute. |
Exception Minimum | The minimum time span between exceptions, expressed in seconds. This value is configured for each point in the ExcMin attribute. |
ExcDev (Exception Deviation) | The deadband which causes an exception when it is exceeded. This value is configured for each point in either the ExcDev or ExcDevPercent attribute. |
OldEvent | The value/status/timestamp of the last event sent to the snapshot subsystem. This is the last event that passed the exception report. |
PrevEvent | The value/status/timestamp of the last event used for the comparison of the event value so as to determine whether the new value should be sent to the snapshot subsystem. |
NewEvent | The value/status/timestamp of the event that is to be tested for the exception. |
In the exception reporting the new event (NewEvent) is sent to the snapshot subsystem, provided that:
- The time between the timestamps of the new and old event is greater than or equal to the ExcMax value.
- For digital points, the new value differs from the old value. The ExcMin value is disregarded.
- For numeric points, the status changes from good to bad, or bad to good.
- For numeric points, the following conditions are met:
- The time between the old event and the new event is greater than or equal to the ExcMin value.
- The absolute value of the difference between the new value and the old value is greater than the ExcDev value.
The new event sent to the snapshot subsystem replaced the old event.
The previous event (PrevEvent) is sent to the snapshot subsystem, provided that:
- The PrevEvent value does not equal the original OldEvent value.
The only time the previous event is not sent to the snapshot subsystem is when two consecutive exception reports send there the new event. The PrevEvent value is used to accurately indicate what really happened to the value. Without it, a step change would look like a ramp change. Basically, if a measurement holds steady for hours, then makes a step change, just sending the new value to the snapshot subsystem, results in interpolating between the old value and the new value. By also sending the PrevEvent value, the step change is stored.
Provide Feedback