This article is about the use of downtime. The article explains how to measure downtime and manage the registrations by editing existing and closed downtime.

 

Measuring downtime 

Measuring downtime means finding the total amount of lost operational hours a downtime registration has incurred. This is done in the web app when closing a downtime registration. It is a manual step for rather precise measurements, but the system helps you with easy registration.

Mobaro calculates the total amount of nominal operational hours through:

<registered operational hours> + <registered downtime> = nominal operational hours

From this you can find the downtime percentage by the equation:

<registered downtime> / <nominal operational hours> *100 = downtime percentage

 

The rule of thumb, is to only register the amount of time the location was out of operation where it should have been operating. This leads to three different scenarios for downtime registrations: 

  1. Short-lived downtime registrations within normal operational hours, which are opened and closed within a few minutes or hours.
  2. Downtime registrations spanning across normal operational hours, where the downtime registration exceeds the expected operational hours.
  3. Downtime registrations spanning over multiple days.

 

In the following we will walk you through all three scenarios.

 

A downtime registration within normal operational hours

ex1.png

In this example, we have a location which is expected to be operational from 06:00 in the morning until 20:00 in the evening. That’s a total of 14 hours of nominal operational hours.

The downtime registration starts at 14:00 and ends at 15:00 resulting in 1 hour of downtime, and 13 hours of operational hours registered. 

When closing the downtime registration in web app, you are expected to verify the amount of downtime. The system registers the time downtime was started and the time the downtime entered the resolved state. The time between these two are suggested for you, but you can edit this if needed.

The amount of nominal operational hours are:  13 + 1 = 14  hours

The downtime percentage for this example is:  1/14 = 7.1%

 

When a downtime registration exceeds normal operational hours

ex3.png

In this example, the location still has 14 hours of expected operation. A downtime registration starts at 14:00 in the afternoon and isn’t resolved before 22:00 in the evening.

The system registers a time span of 8 hours for the downtime, and will suggest that as the duration when closing the registration.

However, registering 8 hours of downtime would result the nominal operational hours for the location to be higher than it should be. It would be calculated as 8 + 8 = 16 hours, instead of the actual 14 hours.

This is due to registering 8 hours of operational hours before the downtime is registered, and according to the equation continues until 22:00. In reality, the location only suffered from 6 hours of lost operational hours, from 14:00 to 20:00, which would equal a downtime percentage of 6/14 = 42%.

Be aware that the downtime duration registered on the individual entries should only represent the amount of lost operational hours.

 

Downtime registration spanning over multiple days

ex4.png

In this example we have a downtime registration, which is initiated on day one at 14:00 and resolved at day two at 22:00. This situation is somewhat similar to the previous example.

From the system’s standpoint, the registration would be: 

ex5.png

  • Closed = 8 hours
  • Open = 8 hours 
  • Downtime = 32 hours 

This would sum up to 32/40 = 80% of downtime. The 40 being the 8 hours operation added to the 32 hours of downtime.

The system lacks information about the closing time of the location on day one, as well as any information about open/close events on day two. You have to take this into account when finalizing the downtime registration and registering the final downtime duration.

The final calculation should be as follows:

  • Downtime day one = 6 hours. The location is out of operation at 14:00 and was expected to operate until 20:00.
  • Downtime day two = should be 14 hours. The downtime is continued from day one and is not resolved until late in the evening. It is only the 14 hours of expected operation for the location, which have been lost.

The actual amount of downtime to be registered is 20 hours – out of a total of 28 hours of expected operational hours for those two days. This would result in a downtime percentage of 71%.

 

Edit existing and closed downtime registrations

You can manage existing and closed downtime registrations through the web app. 

  1. Go to the downtime tab.
  2. Change the filter to include downtimes in the closed state.
  3. Select the downtime registration from the list and press edit.
  4. Remember to press save.

 

Comments

0 comments

Please sign in to leave a comment.