Summary
The Track Gap Detector Processor can be used to detect the absence of events from event data. Like the Incident Detector Processor, event records sent from the Track Gap Detector Processor are not copies (or derivatives) of event records received by the processor. Event records sent from the processor are associated with the TrackGap GeoEvent Definition created when GeoEvent Server is installed.
Examples
- The Track Gap Detector Processor can be used to monitor the ongoing status of a fleet of vehicles. For example, each vehicle may be reporting a status update once every 30 minutes. If a vehicle has gone more than 30 minutes since it last reported its status, the gap event produced by this processor could help indicate the vehicle is disabled and requires assistance.
- The processor can be used to monitor the regular occurrence of data from a stationary sensor. For example, a pressure gauge connected to sensitive equipment may be reporting data at a regular interval. If the gauge fails to report information after a given period of time, either the gauge is faulty or the pressure has exceeded the safe threshold. In either scenario, the gap event could be used to trigger an immediate notification to check the sensor and preserve the sensitive equipment.
Usage notes
- Event records sent to a Track Gap Detector Processor must have a GeoEvent Definition with a TRACK_ID tag. The processor uses the TRACK_ID tagged field to determine when event records are no longer being received. The processor must receive at least one event record with a given Track ID before it will be able to detect the absence of event records for that track.
- Event records sent from the processor are associated with the TrackGap GeoEvent Definition created when GeoEvent Server is installed.
- The schema of the TrackGap GeoEvent Definition is shown below. Event records sent from the processor adhere to this schema in place of the original source schema.
Name | Description | Type |
---|---|---|
trackID | The value used to uniquely identify tracked assets. Event records sent to the processor must have a field tagged TRACK_ID. The TRACK_ID tag is applied to this field for gap events created by the processor. | String |
Gap | A flag set to True to indicate an event record satisfies the gap condition. The flag is set to False to indicate the gap condition has ended. | Boolean |
lastReceived | The date/time an event record was last received before satisfying the gap condition. | Date |
Geometry | The geometry associated with a gap event record from the processor. The processor appends the geometry from the last received event record to the gap events it generates. The GEOMETRY tag is applied to the field for gap events created by the processor. | Geometry |
- The Gap Duration (seconds) and Gap Detection Interval (seconds) parameters must be specified:
- Gap Duration (seconds) parameter specifies the number of seconds the processor will wait before determining expected data has not been received.
- Gap Detection Interval (seconds) parameter specifies the number of seconds in each polling interval. For example, assuming the processor is configured with a gap detection interval of 120 seconds and a gap duration of 300 seconds, the processor would check its internal register of received event records every two minutes (120 seconds) to see if any TRACK_ID in its registry had not been observed within the last five minutes (300 seconds).
- The gap detection interval also controls how often notifications are generated. When the Gap Notification Mode parameter is set to Continuous, a new gap event will be generated on each poll of the processor's internal registry for each TRACK_ID expected but not recently received. If the requirement is for a single notification when a gap is first detected, followed by a second event to notify when the expected event records are once again being received, specify the On Change gap notification mode.
- When configuring the processor, an event record field that contains the geometry can be specified. If an event record field name is specified, the processor will append the geometry from the most recently received event record to the gap events it generates. For example, if a data feed is reporting the position of vehicles and the processor was configured to poll every 30 seconds to determine if a gap of at least 120 seconds existed since the last received vehicle report, the processor could be configured to include the last reported vehicle location with its gap notification events.
- The Geometry Field parameter will display the name of every field from every GeoEvent Definition with a geometry data type. When selecting the geometry field by name, choose the name of the correct geometry field that corresponds to the event record’s GeoEvent Definition.
Parameters
Parameter | Description |
---|---|
Name | A descriptive name for the processor used for reference in GeoEvent Manager. |
Processor | The name of the selected processor. |
Gap Notification Mode | The gap notification mode for gaps detected by the processor. The default is On Change.
|
Gap Duration (seconds) | The amount of time, in seconds, the processor will wait before determining expected event data has not been received. The processor monitors for expected event records using TRACK_ID’s stored in an internal registry of received events. The default is 300. |
Gap Detection Interval (seconds) | The amount of time, in seconds, the processor will wait before polling its internal registry of received events to determine if any known TRACK_ID’s have not been observed. The default is 120. |
Geometry Field | The name of the geometry field or the GEOMETRY tagged field the processor uses to apply the last known geometry of event records to the gap events it creates. |
Considerations and limitations
- Consider the relationship between the Gap Duration (seconds) and Gap Detection Interval (seconds) parameters when monitoring for gap events. It is recommended you find a balance between the two values specified in these parameters. Consider the following scenarios:
- Setting the Gap Duration (seconds) parameter to 60 seconds and the Gap Detection Interval (seconds) parameter to 600 seconds would result in a delayed reporting of gaps. A missing event record is considered absent after a minute but would not be known about for 10 minutes due to the processor’s configured interval polling. Depending on the nature of the event data, this type of delay may be unacceptable. Consider reducing the Gap Detection Interval (seconds) parameter.
- Inversely, setting the Gap Duration (seconds) parameter to 3600 seconds and the Gap Detection Interval (seconds) parameter to 1 second for event data received and updated only once every 10 minutes would result in an unnecessary impact on the performance of the GeoEvent Service. Event records are considered absent from streaming after 30 minutes of no additional updates. However, the same event records are only received by the GeoEvent Service every 10 minutes and therefore can only be updated once every 10 minutes. An interval polling interval of 1 second would result in the unnecessary us of system processing and resources since updates to event records can only happen every 10 minutes, not each second. Consider increasing the Gap Detection Interval (seconds) parameter.
Vous avez un commentaire à formuler concernant cette rubrique ?