About the Downtime event table

Downtime events use alarms/events to provide extra information to staff that enter cause and classifications for Downtimes. The premise is that most Downtimes result after an event has occurred in the plant.

The Event Table item is a standard OleDbDataSource that accepts data from an external source, such as a SCADA system. AVEVA™ Production Management examines the list for criteria and matches alarms and events that occurred within a specific time window with certain criteria.

This information can be used to offer a list of possible events that are related to a Downtime.

When an operator selects the relevant event, this causes other fields such as Effect and Cause Location to auto-populate with data from the external source.

• The Event Table item is a standard OleDbDataSource.

• The Event Table enables AVEVA™ Production Management to parse the SCADA Alarm list and inspect alarms around the time of the Downtime event.

• The Downtime Events feature automatically assigns an event, effect and cause location to a Downtime record.

• The additional information is aimed to assist operators to select the cause of a Downtime.

Example: A Downtime event is created

A conveyor belt transports product. If the conveyor motor stops, the belt stops. The SCADA system receives an alarm to say that the motor has stopped due to a thermal overload. The AVEVA™ Production Management system records a Downtime because the conveyor belt has stopped. If Downtime Events are configured, the following fields are populated in the Downtime record:

• Cause Location: Conveyor

• Effect: Thermal Overload

• Event: Conveyor_ThermalOverload

How does it work?

Regular expressions are configured in the plant hierarchy to match the alarm descriptions. AVEVA™ Production Management uses the naming convention for alarms to filter possible events to find the relevant event in a three part process:

• Define Event Masks

• Define Event Areas

• Configure Effect Mappings

For detailed information on the three part process, see steps 5, 7, and 8 in Configure the Downtime event table.

The first alarm found that matches one of the possible causes assigns the Cause Location.

This diagram shows an example of a naming convention that might be used by a manufacturing plant. Each plant uses their own site-specific naming convention.

Example

In this example, an event is detected at 10:02:50 AM and that four alarms were the only alarms recorded in the SCADA system around that time.

If the system is configured to inspect alarms for a window of 1 minute prior to the event, it begins parsing alarms after 10:01:50 AM for any alarm tags that contain "ESTOP", "BC", "TOL", or "LL". It searches for ESTOP first, and if it finds none, it searches for BC, and so on. In this example, the alarm that it associates with the event is DMC1101_TOL as this is the first alarm that contains a parsing string that occurred after 10:01:50 AM.

The system can then be configured to use a portion of the alarm tag or description to identify the Cause Location in the AVEVA™ Production Management hierarchy.

Related topics

• Configure the Downtime event table

• Overview of Downtime