Downtime masks
- Last UpdatedFeb 27, 2025
- 2 minute read
A Downtime mask condition defines the circumstances under which the data from a Downtime reporting point is masked, because the data is already being reported by another reporting point.
You can configure a Downtime reporting point so that if another Downtime reporting point is currently recording the same downtime event, data from both points is not seen, since it is a duplication of the same event. Therefore, the data captured by one of the points is hidden or masked.
Guidelines about masks
-
When a Downtime event starts, it checks to see if any of the masking rules are currently in a Downtime state. If they are, the event is marked as being masked.
-
Point 2 is not be masked if Point 1 is Pending On; the StartDelay has not yet expired.
-
If Point 2 is masked when Point 1 is active, then Point 2 continues to mask data even if the Point 2 remains active for a duration after the Point 1 clears.
-
A masked downtime is monitored and logged the same as a 'normal' downtime except that it is marked as masked. This is useful in the client when downtime events are viewed as you can filter out masked events.
-
Masked events do not notify users.
-
A Downtime reporting point is only masked by a Real Downtime.
-
A Masking reporting point automatically populates the Cause Location, Classification, Cause Code, Explanation, and Effect of affected masked events.
When to use Downtime masks
Masks are typically used when multiple Downtime reporting points are configured for serial processes. That is, process areas that occur one after the other and when one stops working, it causes another upstream process to stop working. They are also used when auxiliary or common infrastructure systems stop working, causing process areas to stop producing.