MTBR

The definition for MTBR (mean time between removals) is a measure of the product reliability parameter related to demand for logistic support. The total number of system life units divided by the total number of items removed from that product during a stated period of time is the MTBR value. This term is defined to exclude removals performed to facilitate other maintenance and removals for product improvement. As you have an MTBF evaluation, you must identify all the failures in this evaluation that will result in removal action, which means you probably need to have access to an FMEA analysis. Excluding the non-removal failure rates should result in a prediction of MTBR..

The definition for MTBR (mean time between removals) is a measure of the product reliability parameter related to demand for logistic support. The total number of system life units divided by the total number of items removed from that product during a stated period of time is the MTBR value. This term is defined to exclude removals performed to facilitate other maintenance and removals for product improvement. As you have an MTBF evaluation, you must identify all the failures in this evaluation that will result in removal action, which means you probably need to have access to an FMEA analysis. Excluding the non-removal failure rates should result in a prediction of MTBR..

AG-300 (NATO/DTIC) defines the calculation as MTBR= Total Flight Hours/Total Number of Removals
MIL-STD-338B defines it as MTBRf= Total Operating Hours or Flight Hours/Total Equipment Removals

Nowhere does the definition describe what “system life units” is…

I know this is a severely old thread, but I too have questions and comments on this as our office decided to use this metric instead of the DoD/AF required metrics for reliability/sustainability.

According to multiple books, predominantly logistics engineering related, Mean Time Between Removals is actually an “M” metric, not an “R” metric in the RAM series, and barely an “M” metric at that. MTBF and MTBM directly affect MTBR, but not really the other way around. The above definition from the RIAC member derives from that of the antiquated MIL standards such as MIL-STD-338B as well as a few others that have not been revised to accomodate the RAM metrics appropriately. In reality this MTBR metric cares about one thing, simplistically stated, how many times on average did I remove that part or LRU in a given time period.

The MTBR metric ultimately is a spare-part requirements metric and not really any more than that. With current swap-tronics type maintenance, a BIT failure causes the avionics tech to remove the LRU from the aircraft, necessitating in turn, the availability of a spare part and inventory requirement, making this a key logistics support metric as MTBR is built on a “per LRU” basis at the heart.

Despite the fact that the older MIL standards try to make MTBR a reliability metric, attempting to move this “M” metric over to an “R” reliability metric would leave your system reliability reporting skewed.

Using the above calculation as a root for understanding, take the following example. I remove a processor (LRU) resulting from a BIT failure from my aircraft that flew a total of 60 flight hours during a trip across the pond; this feeds the overall MTBR metric since this is a removal. This derives from MTBM because I had to remove that LRU for a maintenance activity. What this does not take into account is the actual reliability and here is why…what this does not show is the fact that I didn’t even turn that processor on until 8 hours into my flight, and that the processor failed 5 minutes after I turned it on. But because of this metric, I account for the total flight hours before removal of the LRU and not the actual LRU failure in respect to LRU operating time between failures, which would feed the true reliabiltiy of MTBF.

Since MTBR is based on actual removals of the equipment, the only way this correlates to reliability is that if true reliability (MTBF in relation to hours) increases, the byproduct is that is the MTBM hours increase theoretically, thus increasing the MTBR hours between removals.

So after this soap box of a diatribe, I finally come to my questions:
With the basic understanding that I need to move our program to proper sustainment metrics, and that MTBR only cares about how many times I removed an LRU…..
1) How do I move MTBR into an actual reliability metric such as MTBF? I imagine I would need the actual LRU counter times to approximate MTBF instead of this flight hour count, right?
2) If we are forced to keep using this terrible MTBR metric for reliability and since this metric is simplistic and only cares about how many times I removed an LRU during a reporting period, do I have to calculate for LRU type that has multiple of the same (i.e. 5 identical sensor LRUs on the same aircraft), or being that this metric only cares about removal, do I stick with the fact that I removed that sensor X times over the reporting period and not worry about series/parallel calculations for the multiple LRU on the aircraft like I would for “R” metrics like MTBF? My thoughts are that MTBR only cares about how many times I removed the LRU, driving a logistics support trigger such as a spare part out of supply.

Regarding question 2, using the 5 sensor LRU idea, my office currently calculates this as MTBR=(5 Sensors^Total Flight Hours)/Total Removals, so if the aircraft fleet had 57612 flight hours, with 19 removals, it would look like this
MTBR=(5^57612)/19 –> MTBR= 18193 hours.

For this being a LRU removal metric under “M” category, this does not jive for me. This states that the LRU is removed on average 18193 flight hours when in reality the sensor LRU is removed on average 3032 hours by the original calculations defined by AG-300 and MIL-STD-338B. Would you want your spare parts buy based on 18193 hours when the LRU is actually removed on average at 3032 hours? You wouldn’t keep enough spares on hand if you base it on the 18000 hours. If this was MTBF, then yes I would consider series calculations (Lusser), or parallel calculations for identical elements as defined by Pieruschka because the MTBF metric is an actual reliability metric.

Sorry for the length, but this is a very large contentious point between functional departments here.

The System Reliability Toolkit identifies two types of reliability parameters: Inherent Reliability and Operational Reliability. Inherent Reliability is typically used to define, measure and evaluate a design program. It accounts only for failure events subject to design and manufacturing control. A typical measure of inherent reliability is mean time between failures (MTBF). MTBF is usually a series measure (does not account for redundancy) and includes only inherent failures within a system. Actions resulting from scheduled preventive maintenance, or from induced and can-not-duplicate (CND) incidents are not counted towards MTBF. Another measure of inherent reliability is mean time between critical failures (MTBCF). MTBCF includes only failures that are critical to system performance or mission success and accounts for redundancy.

Operational Reliability is used to describe reliability performance when a system is operated in the expected environment. It includes the combined effects of item design, quality, installation environment, preventive maintenance policy, repair/fix, etc. Typical operational reliability terms include mean time between maintenance (MTBM) and mean time between removal (MTBR). MTBM includes any incident resulting in a maintenance action (i.e., system downtime) including inherent failures, induced failures, CNDs, and scheduled preventive maintenance. MTBR is a measure of how often a product is removed from a system. As indicated in a previous post, removals performed to facilitate other maintenance and removals for product improvement are ideally excluded from the MTBR parameter. Unless certain maintenance activities (preventive and corrective) can be accomplished without removal, MTBR will contain MTBM. The risk to a supplier of using operational reliability for contractual reliability requirements is that these terms often include factors that are beyond a supplier’s control.

Regarding question 1, MTBF, MTBM and MTBR can be calculated in many different units including operating hours, flight hours, calendar hours, miles, cycles, etc. Ideally, MTBF would be calculated using LRU counter times, since this would provide the most accurate estimate of LRU operating time. If LRU counter times are not available, then operating time can be estimated from flight hours if the average operating to flight hour ratio is known. In this case, operating hours = flight hours * (operating hours/flight hour) * # LRUs per aircraft.

Regarding question 2, assuming that the exponential distribution (R=exp(-t/MTBR)) is being used as an input to the spares calculation, the use of the multiplier of 5 should not matter as long as the units for “t” and MTBR are consistent. For example, if you use an MTBR of 15,161 (the sample calculation was incorrect) sensor hours, then you must calculate “t” as 57,612 flight hours * 5 sensors/flight = 288,060 sensor hours. If you use an MTBR of 3,032 aircraft flight hours, then you must use “t” as 57,612 aircraft flight hours. It should be noted that this will result in a point estimate of the number of spares required. If necessary the Poisson distribution can be used to add a confidence level to this number.