Event Analysis
Many errors, warnings, and notifications occur daily at a plant. Individual messages are acknowledged, and production continues. However, it is not immediately clear which malfunctions are repeatedly causing delays.
The event analysis evaluates this history. It shows which messages occur frequently, remain pending for a long time, or cluster during specific time periods. This provides production and maintenance with concrete starting points for troubleshooting.
Find frequent and long-standing reports
The historical analysis compares reports based on frequency and duration. Both perspectives help in selecting an issue:
- Frequency: Which message keeps appearing? This is a clue to recurring interruptions or frequent operator intervention.
- Total duration: Which alert has been active for a particularly long time during the period under review? It is worth checking for long-lasting disruptions here.
- Individual events: How is the total duration distributed across individual events? A long incident may require a different response than many short, repeated occurrences.
A frequently occurring warning may appear during ongoing production. A less frequent message, on the other hand, may be associated with a long production stoppage. Therefore, use frequency and duration as a starting point and then examine the production context.
Recognizing Temporal Patterns
The time series shows when alerts cluster and whether a system's behavior is changing. The breakdown by time of day helps identify recurring time periods. For example, you can check whether an alert tends to occur during startup or at similar times of day.
Such patterns allow for a more targeted investigation. If an alert occurs sporadically throughout the day, a different investigative approach is warranted than if a cluster of alerts occurs immediately after a restart. You can supplement the operational context with knowledge from production and the available plant and status data.
From the Template to the Individual Report
The event table allows you to review specific messages. It provides a clear overview of the available details, such as ID, category, time information, duration, and status. Message metadata supplements technical identifiers with readable text and a functional classification.
If you notice a suspicious time window, also examine the sequence of events: Which message appeared first? Which ones followed shortly afterward? Does the same sequence repeat in other incidents? This helps distinguish a possible triggering fault from messages that only appear as a result of the interruption.
The sequence provides a framework for investigation. Whether the first event actually caused the shutdown will then be verified at the facility.
Current News and Historical Analysis
The Live View supplements the analysis of past data with current reports. As a result, the views answer different questions:
| View | Question about everyday work |
|---|---|
| Live View | What news stories are coming up? |
| Frequency and Duration Analysis | Which reports should we process on a recurring basis? |
| Time Course and Time of Day | When does the problem occur, and is there a pattern? |
| Incident Table | What specific reports are associated with this incident? |
The history is particularly helpful when preparing for a maintenance task. It shows whether the current incident is an isolated case or part of a recurring problem.
Link notifications to downtime
In the state analysis, you can select a period of concern and examine the associated messages, provided that message data is available. This allows you to start with an actual observed loss phase and search specifically for the accompanying events.
The duration of a work order and downtime are different metrics. A work order may be pending during productive time. Conversely, multiple work orders may be associated with the same downtime. Therefore, their durations cannot simply be added together to calculate lost equipment time. Use the machine statuses for this time evaluation.
Example: Investigating a recurring interruption
A station stops briefly several times throughout the day. After restarting, it continues to run each time.
- Select a time period. Look at a day with the known interruptions and the affected station.
- Narrow down the reports. Review common reports and their history. Which ones occur repeatedly during the relevant time periods?
- Trace events. Compare individual incidents in the event table. Look for recurring patterns and time intervals.
- Accept these conditions. Check whether the station was actually experiencing a malfunction or undergoing maintenance at those times.
- Check the system specifically. Provide the maintenance team with the specific reports and times. That way, they won't have to piece the incident together from a long list of reports.
- Compare the results after implementing the measure. Observe whether the selected events occur less frequently and whether the associated disruptions decrease.
To do this, compare time periods with similar durations or production volumes. Fewer reports on a single day with significantly lower production do not necessarily indicate an improvement.
Prepare Report Data
In the configuration, the processed, aggregated event and alarm log is assigned. It is important to have consistent message IDs, a reference to the correct system, and unambiguous time information. Metadata provides text and categories.
To ensure meaningful time periods, the system must distinguish between when a report begins and when it ends. An acknowledgment does not automatically mean that the technical malfunction has been resolved. Open reports and events that extend beyond the selected time period must also be taken into account during interpretation.