Analyzing Data from Equipment Downtime Logs For product manufacturers who rely on repairable manufacturing equipment, downtime logs can be a valuable source of life data for reliability, maintainability and availability analyses. In order to prepare the data for reliability analysis, the analyst must convert the information in the equipment downtime logs into times-to-failure and times-to-repair. This can be a time-consuming and error-prone process when performed manually. This article describes the process for converting equipment downtime logs to usable reliability data and introduces Weibull++ MT, a special version of ReliaSoft’s Weibull++ life data analysis software package that provides utilities to automate the process. Variety
Among Equipment Downtime Logs Shift patterns for the operation of the equipment must also be taken into account during the conversion process because the accumulated age of the components will be different depending on the hours of operation for the system. Finally, some items may continue to accumulate age while the system is down due to the failure of another component, whereas other items will only accumulate age when the system is operating. This characteristic of the component must be taken into account when determining the times-to-failure. The following example will be used to demonstrate the process required to convert one type of equipment downtime log into life data. A similar process with specific adjustments can be used to convert and analyze the data in other types of downtime logs. Example:
Converting a Downtime Log to Life Data
Figure 1: Sample equipment downtime log The sample equipment downtime log contains a record of events from 12:00 p.m. on January 1, 1997 through 1:00 p.m. on March 18, 1997. All events reported in the log are failures and repair involves the replacement of the responsible component. The log contains the following information:
This information can be used to obtain times-to-failure and times-to-repair for each component. The procedure to analyze component B is different than the procedure for component A because component B continues to accumulate age even when the system is down due to the failure of another component. Both procedures for conversion are presented next. Analysis
for Component A
Figure 2: First time-to-failure for component A This represents a
right censored data point (i.e. suspension) because we do not know how
long the equipment operated before events began to be recorded in the downtime
log. The time-to-repair for component A as the result of this failure, Continuing with
component A, the second system failure due to component A is found in row 4 at
3:26 p.m. on January 12, 1997. Remember that component A does not age when the
system is down due to the failure of component B. Therefore, to compute
Figure 3: Second time-to-failure for component A To describe this
mathematically, we will use the function
The time that component A was not operating (NOP) during normal hours of operation is the time that the system was down due to the failure of component B, or:
Thus, the second
time-to-failure for component A,
To compute the time-to-repair for this failure, we determine the time between the occurrence of the failure and the completion of the repair, or:
The same process can be repeated for the rest of the observed failures of component A. Analysis
for Component B
The process to compute the times-to-repair for component B is the same as the process for component A. For example:
The complete data set with times-to-failure and times-to-repair for components A and B is presented in Table 1. Note that the last points for components A and B are right censored (i.e. suspensions) because we know that each component was operating successfully at the end of the observation period. We do not know what may have happened after the observation period ended. The reliability information in this table can be analyzed with standard reliability, maintainability and availability analysis techniques.
Table 1: Times-to-failure and times-to-repair for components A and B Using
Weibull++ MT to Automate the Analysis
Figure 4: Example of the Weibull++ MT interface
|
|
[1],
is the sum of the hours of operation for each day from the date/time when
events began to be recorded in the downtime log to the first failure
date/time. Thus, 
[1],
is the total time between the date/time when the failure occurred and the
date/time when the system was repaired, or 
, which returns the shift hours
worked during a range of times. For this example, given an 8 a.m. to 5 p.m.
shift, 
