Skip to main content
W
WL_105213006-Contributor
6-Contributor
January 17, 2025
Solved

Design question of RTPPM for MTTR and MTBF and Uptime

  • January 17, 2025
  • 1 reply
  • 890 views

Hi there,

 

I'm currently working with ThingWorx RTPPM and have a question about the MTTR (Mean Time To Repair) and MTBF (Mean Time Between Failures) metrics. Specifically, I'm curious about how RTPPM determines what is considered "maintenance" for the MTTR calculation.

The MTTR metric refers to the total maintenance time. In my case, I have RTPPM configured to track downtime only. How does RTPPM know what events or activities should be classified as maintenance? Does it differentiate between different types of downtime, or is there a specific configuration needed to ensure accurate maintenance tracking? And similar question for MTBF metric. What is consider operational time? How does RTPPM know.

 

Additionally, I'm also interested in understanding how uptime is calculated in the RTPPM KPI Overview Report. Could someone explain the calculation method for uptime in this report?

 

Any insights or experiences with this would be greatly appreciated!

 

Mean Time To Repair (MTTR)
Mean time to repair (MTTR) is a maintenance metric that measures the average time required to troubleshoot and repair failed equipment. It reflects how quickly an organization can respond to unplanned breakdowns and repair them.
MTTR calculations will exclude all downtimes that are not process downtimes (Plant Not Open, Planned Downtimes, Work Unit Constraint, Line Constraint).
(Total Maintenance Time / Total Number Of Repairs)
Mean Time Between Failures (MTBF)
Mean time between failures (MTBF) is the average time between system breakdowns.
(Total Operational Time / Total Number Of Failures)
Best answer by mstarnaud

Hi

 

I haven't had time to really investigate this yet. This is just a temporary answer until someone (me?) gets the time to fully look into it and validate if my explanation below is correct.

 

MTBF seems very straight forward : the average uptime duration. If in a 24h day, you're down from midnight to 1AM, 6AM to 8AM, 11PM to midnight. That means you have 2 uptimes : 1->6 and 8->23. So the average of 5h and 15h is 10h. I expect your MTBF should be 10 hours. Note : I'm not sure how it separates it if you're in uptime at the start & end of the day, I'm expecting it will "close" the uptimes at the specified times (midnight) but I need to validate.

 

MTTR's basis should be the average downtime duration. But it has the added mention that some types of downtimes will be ignored. So for example if in your day you're down from midnight to 1AM, 6AM to 8AM and 11PM to midnight, but the first downtime is Workunit Constraint. Then it should be the average of the 2 remaining downtimes : 6->8 and 23->24, so I think the MTTR would be 1.5 hours.

 

So now about the categories mentioned for MTTR. 

  • A downtime can be associated to a reason Hierarchy.
    • This is a specific point in the reason tree. For example if the equipment is in downtime because the operator is on lunch break right now, you can select your "No Operator" -> "Break" -> "Lunch Break" Hierarchy for this one downtime.
  • Each Hierarchy can be associated to one or many Categories.
  • The Categories have a Type as mentioned in the documentation (Planned, Workunit Restraint, etc.).
    • This is an extra step I dislike, so usually I just create 1 Category for each Type and give them the same name. So I make a Category called Planned with Type=Planned, and so on.
  • A Hierarchy that has a Category will automatically give this Category to all its children.
    • For example you can create category Planned (with type = Planned), put it on the "No Operator" -> "Break" Hierarchy, and its child "Lunch Break" Hierarchy will automatically receive this category.
  • And then when the KPIs are calculated, it only includes downtimes that have (or don't have) specific categories.
  • Here, the MTTR calculation says it will exclude all downtimes that have one of these Categories : Plant Not Open, Planned Downtimes, Work Unit Constraint, Line Constraint.
    • So if you have 3 downtimes : one with no Category, one that is Unplanned, and one that is Workunit Restraint, then this 3rd downtime should not be used by MTTR : it's as if you had an uptime instead.
  • The configurations mentioned above (Categories, Hierarchy) can be configured in the Configuration -> Reason Trees screen. For the Hierarchy, you have to edit a Reason Tree and go in the 2nd tab : Tree Configuration. You will see columns for Categories & Types and a button to edit them.

1 reply

M
mstarnaud16-PearlAnswer
16-Pearl
January 24, 2025

Hi

 

I haven't had time to really investigate this yet. This is just a temporary answer until someone (me?) gets the time to fully look into it and validate if my explanation below is correct.

 

MTBF seems very straight forward : the average uptime duration. If in a 24h day, you're down from midnight to 1AM, 6AM to 8AM, 11PM to midnight. That means you have 2 uptimes : 1->6 and 8->23. So the average of 5h and 15h is 10h. I expect your MTBF should be 10 hours. Note : I'm not sure how it separates it if you're in uptime at the start & end of the day, I'm expecting it will "close" the uptimes at the specified times (midnight) but I need to validate.

 

MTTR's basis should be the average downtime duration. But it has the added mention that some types of downtimes will be ignored. So for example if in your day you're down from midnight to 1AM, 6AM to 8AM and 11PM to midnight, but the first downtime is Workunit Constraint. Then it should be the average of the 2 remaining downtimes : 6->8 and 23->24, so I think the MTTR would be 1.5 hours.

 

So now about the categories mentioned for MTTR. 

  • A downtime can be associated to a reason Hierarchy.
    • This is a specific point in the reason tree. For example if the equipment is in downtime because the operator is on lunch break right now, you can select your "No Operator" -> "Break" -> "Lunch Break" Hierarchy for this one downtime.
  • Each Hierarchy can be associated to one or many Categories.
  • The Categories have a Type as mentioned in the documentation (Planned, Workunit Restraint, etc.).
    • This is an extra step I dislike, so usually I just create 1 Category for each Type and give them the same name. So I make a Category called Planned with Type=Planned, and so on.
  • A Hierarchy that has a Category will automatically give this Category to all its children.
    • For example you can create category Planned (with type = Planned), put it on the "No Operator" -> "Break" Hierarchy, and its child "Lunch Break" Hierarchy will automatically receive this category.
  • And then when the KPIs are calculated, it only includes downtimes that have (or don't have) specific categories.
  • Here, the MTTR calculation says it will exclude all downtimes that have one of these Categories : Plant Not Open, Planned Downtimes, Work Unit Constraint, Line Constraint.
    • So if you have 3 downtimes : one with no Category, one that is Unplanned, and one that is Workunit Restraint, then this 3rd downtime should not be used by MTTR : it's as if you had an uptime instead.
  • The configurations mentioned above (Categories, Hierarchy) can be configured in the Configuration -> Reason Trees screen. For the Hierarchy, you have to edit a Reason Tree and go in the 2nd tab : Tree Configuration. You will see columns for Categories & Types and a button to edit them.
Terms & ConditionsCookie settingsAccessibility statement