anomaly

The anomaly table records events relevant to anomalies as they traverse through pipelines.

When an anomaly is newly created in a pipe segment:

• A new row is created in the Historical anomaly table for that given RealTime anomaly for that segment.

• The following fields are populated based on the anomaly and segment values at the time the RealTime anomaly is created.

  • time

  • offset

  • ownSysId

  • datasetId

  • anomaly

  • anomalyType

  • segment

  • createTime

  • startSlipFactor

  • startVolumeOffset

  • startFlowRate

  • operatorComment

• If the anomaly was automatically created by an anomaly detector of type launcher:

  • The action field is set to LAUNCHED.

  • The detector field is set to the name of the anomaly detector that was responsible for launching the anomaly.

• If the anomaly was manually created:

  • The action is set to INSERTED.

  • The detector remains as null.

• The remaining fields are null.

When a RealTime anomaly moves to a new pipe segment:

• The following fields are updated for the most recent row in the previous segment. These are the values for the anomaly captured in the previous segment immediately prior to the anomaly moving to the new pipe segment:

  • endTime

  • endTimeOffset

  • endSlipFactor

  • endVolumeOffset

  • endFlowRate

• A new Historical anomaly row is created for the segment the RealTime anomaly is now in.

• time and offset are set to the respective endTime and endTimeOffset values of the previous row.

• startVolumeOffset is set to the initial volume offset of the RealTime anomaly as it enters the new segment.

• startSlipFactor is set to the actively used slip factor of the RealTime anomaly as it enters the new segment.

• startFlowRate is set to the flow rate of the new segment as the RealTime anomaly enters the new segment.

• The action field is set to MOVED to indicate the anomaly has moved from one segment to another.

• If the anomaly moved because of an anomaly detector, the detector field is set to the name of the anomaly detector that was responsible for moving the anomaly. Otherwise, the detector field is null.

When an anomaly is deleted from a pipe segment:

• The following fields for the most recent row in the current segment are updated based on the RealTime anomaly and segment state immediately prior to deletion:

  • endTime

  • endTimeOffset

  • endSlipFactor

  • endVolumeOffset

  • endFlowRate

• A new Historical anomaly row is created for the segment the anomaly was last in. All field values match that of the previous row.

• For the new row, if the anomaly was automatically deleted because of an anomaly receiver, the action field is RECEIVED and the detector field is the anomaly detector responsible for deleting the anomaly. Otherwise, the action field is DELETED and the detector field is null.

When an anomaly location is automatically adjusted within a segment because of an anomaly detector:

• A new Historical anomaly row is created for the segment the anomaly is still in. All field values match that of the previous row in the same segment.

• For the new row, the startSlipFactor, startVolumeOffset and startFlowRate fields are updated to match when the anomaly’s location was updated to after the adjustment. The action is ADJUSTED and the detector is the anomaly detector responsible for adjusting the location of the anomaly.

When an anomaly detector detection signal is triggered:

• A new Historical anomaly row is created with the detector field as DETECTED.

  • Time and offset correspond to when the detection signal was received.

• If the detection signal was not determined to correspond to any anomaly, then the createTime field matches the time field. All the other anomaly and segment related fields are empty, 0, or null, respectively:

  • anomaly

  • originalName

  • anomalyType

  • segment

  • endTime

  • endTimeOffset

  • startSlipFactor

  • endSlipFactor

  • startVolumeOffset

  • endVolumeOffset

  • startFlowRate

  • endFlowRate

  • operatorComment

• If the detection signal was determined to correspond to an anomaly, then all the initial anomaly and segment related fields are populated with the anomaly and segment information at the time the anomaly was detected.

  • anomaly

  • originalName

  • anomalyType

  • segment

  • createTime

  • startSlipFactor

  • startVolumeOffset

  • startFlowRate

  • operatorComment

    With every action described above, operatorComment will be updated to reflect the value snapshotted at the time of the action.

    Note: If an anomaly record requires an update but the system was unable to find the historical record associated with the original creation of the anomaly (due to the record being manually deleted or archived), the system will not attempt to recreate the missing record. Any updates expected to be made to the original record will be skipped.