
There are a variety of reasons that production can stop on a manufacturing line. Equipment failure, material shortages, and quality issues are a few common causes. Regardless of the reason, downtime is a significant issue for manufacturers.

To combat downtime, we see various maintenance strategies in use, operator training, and process improvements. While these strategies can be effective, they often lack the necessary data to identify the root causes of downtime and measure the effectiveness of improvement efforts. That's where downtime monitoring comes in.

Downtime monitoring comes in a variety of forms, from manually recording downtime events in a shift log, to automated, integrated systems like **[Line Interpreter](https://lineinterpreter.com)**, that track downtime events and provide real-time data to operators, maintenance teams, and managers.

We're often asked about the benefits of automated downtime monitoring, and how it can be used to improve plant performance. Here are a few key benefits:

## Improved Visibility
Automated downtime monitoring provides real-time visibility into production processes, allowing teams to quickly identify and address issues as they arise. One of the difficulties with manual downtime tracking is that it can be difficult to understand how well a line is operating during a shift, especially for new or inexperienced operators. Line Interpreter is designed to deploy dashboards to large screens on the production floor, our experience has shown that the act of displaying OEE at the line can lead to significant improvements in OEE without any other intervention.

## Improved Downtime Details
Manual downtime tracking often lacks the necessary downtime details of downtime events, and often misses downtime events altogether. At one site, that relied on recording downtime in shift logs, 40% of downtime events (only counting events greater than 5 minutes) were not recorded in the shift logs. The shorter events (2-5 minutes) in duration, were completely missed. Automated downtime monitoring systems can capture all downtime events, regardless of duration, and prompt operators to enter detailed information about each event, including a description, cause, category and location of the event. This accurate, structured data is crucial for identifying root causes of downtime and measuring the effectiveness of improvement efforts.

## Enhanced Collaboration
Automated monitoring systems facilitate better communication and collaboration between different teams involved in the production process. By providing a centralized source of truth for downtime data, these systems help ensure that everyone is on the same page and working towards common goals.

## Conclusion
Automated downtime monitoring is a powerful tool for manufacturers looking to improve plant performance. By providing real-time visibility, enabling root cause analysis, measuring performance, enhancing collaboration, and supporting continuous improvement, these systems can help organizations unlock significant value from their production processes.


Recording downtime is one of the first steps a company makes to improve their OEE. After all, you need to be able to measure what you're working to improve. Too often we see companies that have issues crunching data or understanding their plants performance. Data that is too granular, unstructured, or vague can can make it difficult to understand where energy should best be focused. This article covers the selection of downtime intervals, cause codes, categories and data collection methods. Keep in mind that there is no one-size fits all, as most of these decisions are dependant on the organisation or production line.

## Minimum downtime Interval

The **minimum downtime interval** is the shortest duration where downtime will be recorded. At first glance, it's tempting to record all stoppages of a line as downtime. However, consider a line that stops for 5 seconds, runs for a minute and stops for another 5 seconds. What happens when the operator is asked to record that downtime? If it's being recorded in a spreadsheet or on paper it might take a minute to record all the details. It won't be long before these short downtime events disappear - but only because operators stop recording these events.

For manually recorded downtime, a minimum downtime interval between 5 and 10 minutes works best. For automated systems where the operator needs to enter details for each event, this can be reduced to around 2 minutes, and automated systems that give the flexibility to hide short events from operators, or automatically assign causes can be set as low as 5 seconds.

If your line suffers from a high frequency of downtime events, consider increasing the minimum downtime interval, conversely, if the line has only a few downtime events per hour, the interval could be reduced.

Essentially the goal is to achieve a balance of data quality and operability of the downtime recording system. No downtime recording system works without the support of operators, so choose a minimum downtime interval that gets the important data, but doesn't overwhelm them with data entry.

Regardless of what minimum downtime interval you choose, you should review it after 3-6 months and adjust it as required.

## Downtime categories and causes

Downtime categories are the high-level groupings of downtime events. This is usually fairly simple to define. Basically, you want a category for each work group that will resolve an issue. A good starting point is `Mechanical`, `Electrical`, `Operations`. You can also add categories such as `Admin`, which can be useful if you want to record things like mandatory meetings, training, etc... separate to the operations category, which can then be more focused on more immediate impacts to the line such as waiting for, or running out of material.

It's typically better to have a short list of categories, and it works best if a category can be assigned to an individual or a team for improvement. For example, the electrical team leader can just look at the top three causes of downtime in the electrical category. But if there are categories like 'control signals', 'sensors', 'motive power', 'PLC', etc... it can be unclear what needs to be prioritised.

**screenshot**

Causes, is the next step of granularity, where there starts to be enough detail to really focus improvement initiatives. The list of causes should be highly informed by your production line. For example, most production lines use photoelectric sensors to manage product flow, so codes like 'sensor failed', 'sensor dirty', 'sensor blocked', 'sensor alignment' are pretty common in all industries. On the other hand, in a sawmill, product is conveyed primarily by chains and rollers so codes like 'chain tension', 'chain off', 'roller bearing' would be common, but these may not be relevant for a bottling line in a food factory.

Around 15 causes per category is a good starting point, along with reviewing them every few months until they are well established. It's important to also have an 'other' option so that you can review and add new causes something particular starts to become common. However, be careful when adding or removing causes because you want to build a long term trend of downtime. Changing causes can make this long-term data less data less accurate.

## Downtime locations / equipment reference

It's important to identify the location of the downtime. The list of locations can be taken from your ERP or CMMS systems if available. Otherwise you'll need to develop one. This list should be hierarchial in the form

**Line > Machine > Component > Part**

For example:

Packing Line > Palletiser > Robot > Grabber Closed Prox

This would be for a proximity sensor detecting the palletiser robot end effector has closed (grabbed a carton). It is preferable to use the real name of the sensor in this situation (something like PX290) to keep data consistent across plant displays, drawings, PLC code and labels.

However, the big question is how deep to make this hierarchy? Again the answer depends. LineInterpreter allows you to configure and select data in a hierarchial way, expanding and shrinking locations, so defining locations all the way to the part level is possible, while keeping the system user-friendly. Our location select widget also has search to make it even easier to find locations when entering downtime.

**SCREENSHOT**

recording downtime events by hand or using Excel, it's best to stop at the machine or component level. The last thing you want is an Excel dropdown bigger than the screen, requiring scrolling, or multiple printed pages of downtime locations at the operator station.

## Operator comments

Always give the ability for commentary to be added to downtime events. For short events, this isn't too important, but if you have an event longer than 15 minutes, it should have some sort of comment. These comments are especially important on events with a cause of 'other'.

## Collection method

Last up, collection method. Are you going to collect data with hand-written notes, on a computer using Microsoft Excel or Access, or using a purpose-built downtime recording system, such as Line Interpreter. Most companies start downtime recording with hand-written sheets before quickly moving to Microsoft Excel. So here we'll compare using manual downtime recording with Excel to a purpose-built downtime recording system.

**Cost** - Manual downtime entry is cheaper. It's likely there's already a PC at the operator station that can be used to enter downtime into Excel. A purpose-built downtime recording system will have a cost, either for software or hardware, or both. In the case of Line Interpreter, we deploy and manage a group of servers in the cloud for each of our customers. We maintain backups, deploy security patches, provide support, and add new features. This costs more than a local Excel spreadsheet, but it means our customers can focus on improving their performance, rather than the downtime monitoring system.

**Data Accuracy** - While it's possible to get good results out of a manual downtime recording system, without close management, data accuracy can fall significantly. It's not uncommon for up to 50% of downtime events to go unrecorded when relying on manual data entry. With automated downtime recording systems, downtime events won't be missed, and operators are prompted to enter details for each event.

**Reporting** - Reporting is another area where automated systems shine. With manual systems, generating reports can be time-consuming and error-prone, often requiring significant effort to collate and analyze data. Automated systems, on the other hand, can generate reports with minimal effort. Line interpreter allows users to create custom reports that can be emailed to stakeholders automatically.

## Conclusion

The advice on each aspect of a downtime monitoring strategy changes depending on the data collection method being used, but has been summarised in the table below. Essentially, with a manual downtime recording system, compromises are required to keep the system usable. With an automated downtime recording system, there is no need to compromise. Automated systems collect the most accurate data, and can analyse it in real-time, displaying it on large screens around the production area so operators just need to look up to see if the shift is running to target. These systems provide significant advantages to operations and engineering teams, for more information, just look at our **[features](https://lineinterpreter.com)**. You'll spend less time wrangling with spreadsheets, and more time fixing problems with a purpose-built downtime recording system.

| Decision                  | Advice                                                                                                                                                             |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Minimum downtime interval | Balance operability and data quality.                                                                                                                              |
| Categories                | One per work group resolving issues (but at a minimum have mechanical, electrical, operations).                                                                    |
| Causes                    | Informed by the line structure. Start with 15 per category, periodically review, but don't change unless there is a real need, as it will affect long-term trends. |
| Locations                 | Machine or component level for manual entry, as deep as you want with an automated system.                                                                         |
| Operator comments         | Always leave space for them.                                                                                                                                       |
| Collection Method         | Automated solutions are better, but more expensive.                                                                                                                |



## Charts

Line Interpreter comes with a rich set of customisable charts for displaying plant data. Here are some of the charts available and how they can be used.


# Worm Chart

<ArticleImage src="/posts/test-article/example-image-2.png" />

The worm chart is designed to give a quick overview of the current shifts production. On the X axis is the shift time the amount of products produced (or volume/weight/etc...). The chart features a line showing the target rate for the given line/product combination. 

This chart is useful because it's easy to see how far behind or ahead of target the shift is, as well as the ability to easily see periods of downtime (flat sections of the line).

# OEE Gauge

<ArticleImage src="/posts/test-article/example-image-2.png" />

The OEE gauge is a simple chart that shows the OEE of a line as well as the availability, performance and quality. This chart is useful to see how performance is tracking at a glance and can be used in a multi-line dashboard to quickly understand the performance of an entire plant or group of plants.

# Downtime Table

<ArticleImage src="/posts/test-article/example-image-2.png" />

The downtime table lists downtime events and can be configured to display the downtime start time, duration, cause, location and more. Downtime tables can be used in multiple ways. Downtime can be aggregated by category, cause or location, which makes it a useful tool to dive into particular plant areas or types of downtime.

The downtime table can also show individual downtime events per row, which can be useful to quickly see the most recent downtime events, or the longest downtime events during a shift.

# Pareto Chart

<ArticleImage src="/posts/chart-types/pareto.png" />

The pareto chart consists of two parts. The first is a bar chart showing downtime categorised by location, cause category or cause. The bars are ordered by duration. The second component is a cumulative sum of the bars, expressed as a percentage.

The benefit of using a pareto chart for analysing downtime is that you can very quickly see what percentage of downtime comes from the top categories. For example, some organisations like to target the top 50% of downtime causes, when plotted on a pareto it's easy to see the causes that make up that 50% of downtime.




When moving from manual to automated downtime and OEE monitoring, there are a few steps that can be taken to make the transition more smooth.

## Data Preparation

It's important to define what should be captured. There are a few key things to properly define.
1. Hierarchy
2. Downtime Categories
3. Downtime Causes

Often with manual downtime entry, operators have the freedom to enter whatever data they want for each of these fields. Automated downtime recording typically onstrains them to use only the predefined options (or select other). This means it's important to analyse any available historical downtime data and determine the hierarchy, categories and causes that should be available for operators to choose. 


## Stakeholder Engagement

This leads into the second point, which is stakeholder engagement. Operators, Maintenance and Management will all be using the system to understand the plant's performance. Representatives from each group should form part of the implementation team, making decisions about what downtime gets recorded, what the categories and causes look like and what reports need to be generated. Without sufficient buy-in from stakeholders, the transition may not go smoothly.

## The Line Availability Will Change

One of the most important things to understand and communicate is that the recorded line availability will change. When moving to an automated downtime recording solution, typically more downtime events will be recorded. These are typically the shorter duration events that tend to be missed when recording manually. For this reason, it's not very useful to compare availability pre and post implementation of automated downtime recording. However, do keep tracking OEE. Theoretically, the OEE shouldn't change just by monitoring downtime automatically. However, in practice, it's not uncommon to see OEE improve by around 5% simply because OEE is being recorded and displayed live on the production floor.

Automating downtime monitoring to improve plant performance

What's your downtime monitoring strategy?

Line Interpreter charts

Moving from manual to automated downtime and OEE monitoring