Imagine that you are at a doctor's office. Something has been bothering you, preventing you from going about your daily life normally. The doctor needs some information in order to know how best to treat you, BUT you are unable to tell them what is going on. Instead your doctor must attempt to parse out your issue from tests, observation, and some complicated data. It'll take time to get the diagnosis, and thus the cure, right.
Wouldn't it be easier if you could simply tell the doctor what is wrong?
This is why Thiele has implemented their Downtime Monitor—to give your machine a voice.
Thiele's Downtime Monitor provides an overview of all the conditions that have prevented the system from running in Automatic mode throughout the day, as well as the amount of time each condition accumulated.
What sets the downtime monitor apart, is that Thiele has taken the time to finetune its presentation. The downtime monitor provides you detailed information about your system in both graphical and numerical form - giving you at a glance ability to quickly parse the data and determine what, if anything, needs to be addressed.
Let's take a closer look at the Downtime Monitor's screen to see what is going on in this example.
Reading the Downtime Monitor
As you'll see (and you might have already noticed), reading the downtime monitor is quick and easy, but let's dive in to understand it. Below, we examine one row of data being provided.
Top Row: Current Day Downtime Total
| Section |
Explanation |
| A |
Total event time accumulated (minutes/seconds) |
| B |
A bar graph of total time, scaled to 180 minutes. (short term) or 1440 minutes (long term) |
| C |
Counts - the number of times that this event has occurred. |
| D |
Event name - a human-readable name for each event |
The top bar on the Downtime Monitor displays the Current Day's Total Downtime for this machine. Unlike the rows below it, which will break out the individual events that make up this total, there is on percentage listed, since it's the daily total (hence, always 100%).
Like all rows, the graph has two scales:
- 0-180 minutes - For shorter time totals.
- 0-1140 minutes - For downtime totals exceeding 180 minutes.
At a glance, we can see that there have been 150 Events accounting for 260 Minutes of total downtime. Because the total downtime has exceeded 180 minutes, the scale of the graph has increased to 1440 minutes.
Now, let's dig in to the real power of the Downtime Monitor - it's easy at
a glance downtime breakdown!
Downtime Event Rows
As you can see, each row contains the following information for each entry:
| Section |
Explanation |
| A |
Total event time accumulated (minutes/seconds) |
| B |
A bar graph of total time, scaled to 180 minutes. (short term) or 1440 minutes (long term) |
| C |
Percentage of current total machine downtime that this event represents |
| D |
Counts - the number of times that this event has occurred. |
| E |
Event name - a human-readable name for each event |
Digging in to the above example, we quickly see that the machine's Guard Door has stopped the machine 22 times and accounts for 39 minutes of downtime.
Interesting, yes? BUT, we can also see that this event is responsible for 15% of current downtime on the machine. So we are now getting an idea of how serious a problem this event is.
But what about that bar graph? To understand how powerful this feature can be, let's pull back out to the full screen example.
Look again at that graph. Now we know, at a glance, how this issue compares to other stoppages that have occurred. The bar graph can quickly draw your attention to the events that are impacting normal machine operation the most.
So in our example image, we can see that the the guard door is being opened pretty frequently, but that it's only the third highest factor to downtime on our theoretical machine. We see that the operator has been frequently stopping the machine, accounting for 45% of this machine's total downtime that day.
Then there's the Waiting on Scales row. And now it's time to talk about why some of these rows are Purple 1.
Purple rows indicate downtime that is not the fault of the machine. These events have occurred up or down stream from the machine, causing it to wait.
In our example above, we see that 20% (52 minutes) of our total downtime can be attributed to the machine "Waiting on Scales" and that this has happened 30 times throughout the course of the day.
Putting It All Together
Thiele's downtime monitor makes parsing collected machine downtime information easier by presenting that data in one quickly digestible screen. In our example, we know that our major factors of downtime for the day breakdown like this:
The operator is stopping the machine frequently and opening the guard doors often. There also appears to be a slow-down affecting the scales, which is trickling down to the bagger.
And there you have it. Your three biggest issues identified in three seconds flat. No parsing through complicated data looking for patterns, Thiele's Downtime Monitor takes the guesswork out of downtime analysis to show you what is happening and help you be more productive by quickly sorting out issues.
Footnotes
1: Screen color implementations can vary from machine to machine. Downtime event reporting for events that are not the fault of the machine will be offset and in a different color from other machine-related downtime events.