Configure the Unexpected Anomaly Types tab of the Pipe Segment record

The Unexpected Anomaly Types tab configures up to ten anomaly types that are not expected to enter this segment.

This table defines the fields on the Anomaly Type Alarms tab and their corresponding Batch Tracking Compiler attributes.

There are two abnormal alarms that are associated with the configurations of this tab. The two alarms are:

• Anomaly approaching a segment that does not expect this type of anomaly.

• Anomaly entering a segment that does not expect this type of anomaly.

The following sections discuss how Batch Tracking checks for the conditions that cause these alarms to be raised.

Anomaly approaching a segment that does not expect this type of anomaly

To enable this type of check, the Controller must specify a positive value in the anomaly's Unexpected Anomaly Detection Volume field.

The purpose of this check is to provide an advance warning to the Controller if entering the next downstream segment will result in a situation where the anomaly is guaranteed to pass through a segment (further downstream) that does not expect this type of anomaly. To make this determination, when an anomaly approaches any node in the pipeline (that is, it is detected to be within the Unexpected Anomaly Detection Volume window), Batch Tracking will perform the following procedure:

Retrieve all segments immediately downstream of the node. This can yield no segments if this is the end of the pipeline, a single segment if there is no branching at the node, or multiple segments if there is branching at the node.

1. Filter out segments that are not currently flowing.

2. Filter out segments that are currently flowing but in the opposite direction.

3. If there are no remaining segments, exit the procedure without an alarm.

4. Otherwise, for each remaining segment (flowing in the same direction):

   1. Search downstream for a viable physical path in the pipeline. In this context, viable paths are defined as paths that do not go through a segment which does not accept this type of anomaly. This search does not take into consideration the flowing conditions of the downstream paths.

      Note: For anomalies associated with a Receiver, their designated Receiver constitutes a viable physical path.

   2. If at least one viable path is found, do not raise an alarm. If no viable paths are found, raise an Unexpected Anomaly Approaching alarm. If the alarm is inhibited, only an event will be raised.

Anomaly entering a segment that does not expect this type of anomaly

The purpose of this check is to alert the Controller of a situation where an anomaly has either entered a segment that does not expect this type of anomaly, or entered a segment that will ultimately lead to a segment further downstream that does not expect this type of anomaly.

If the segment (or a different one downstream) is configured to not expect this type of anomaly, an Unexpected Anomaly Entering alarm will be raised. If the alarm is inhibited, only an event will be raised.

Example

In this example, anomaly Pig X is moving with the flow of the pipeline. Arrows indicate direction of flow. Segments in red are not flowing. Segment 5 is the only segment that has anomaly type restrictions where anomalies of type pig are not expected. The shaded areas A through D show the Unexpected Anomaly Detection Volume associated with Pig X.

After some time, when Pig X enters the volume window A:

• Retrieve the flowing segments immediately downstream: Segment 2.

• Starting with Segment 2, search downstream for viable physical paths. There are multiple physical paths that Pig X can go through:

  • Path 1: Segment 2 -> Segment 3 -> Segment 4 -> Segment 5. This path is not viable because Segment 5 does not expect anomalies of type pig.

  • Path 2: Segment 2 -> Segment 7 -> Segment 8. This path is viable. Note that at this point, the fact that these segments are not flowing is not relevant because flow conditions might change as Pig X continues to move down the pipeline.

• There is at least one viable physical path. Do not raise the Unexpected Anomaly Approaching alarm.

When Pig X enters Segment 2:

• There are no anomaly type restrictions for Segment 2 and there is at least one path downstream which does not lead to an unexpected segment. Do not raise the Unexpected Anomaly Entering alarm.

Assuming flowing conditions have not changed, when Pig X enters the volume window B:

• Retrieve the flowing segments immediately downstream: Segment 3 only. Segment 7 is excluded because it is not flowing.

• Starting with Segment 3, search downstream for viable physical paths. There is only one physical path that Pig X can go through:

  • Path 1: Segment 3 -> Segment 4 -> Segment 5. This path is not viable because Segment 5 does not expect anomalies of type pig.

• There is no viable physical path. Raise the Unexpected Anomaly Approaching alarm.

When Pig X enters Segment 3:

• There are no anomaly type restrictions for Segment 3, but the only path from this segment is not viable as there is a segment that does not expect this type of anomaly. Raise the Unexpected Anomaly Entering alarm.

In this example, if flowing conditions do not change, and the Controller takes no action to relocate or remove the simulated pig, the two alarms will continue to be raised until the pig leaves Segment 5.