• The date and time of each failure is recorded.
• The date and time of repair completion for each failure is recorded.
• The repair involves replacement of the responsible component.  
• The responsible component for each failure is recorded.

For this example, we will assume that an engineer began recording these events on January 1, 1997 at 12 p.m. and stopped recording on March 18, 1997 at 1 p.m., at which time the analysis was performed. Information for events prior to January 1 are unknown.

Analysis Objective & Discussion 

The objective of the analysis is to obtain failure and repair distributions for each component. To do this, times-to-failure and times-to-repair for each component need to be computed from the data in the above table. Once the times-to-failure and times-to-repair data are obtained, a life distribution will be fitted to each data set. The principles and theory for fitting a life distribution is presented are detail in ReliaSoft's on-line life data analysis reference.

Solution to Example 1

Obtaining Failure and Repair Times for Component A

We begin the analysis by looking at component A. The first time that component A is known to have failed is recorded in row 1; thus, the first age (or time-to-failure) for A is the difference between the time we began recording the data and the time when this failure event happened. Since the system operates in shifts, the component is not aging when the system is down due to the failure of another component. Therefore, this time must be taken into account.

1. The First Time-To-Failure for Component A, TTF_A[1]
The first time-to-failure of component A, TTF_A[1], is the sum of the hours of operation for each day, starting on the start date (and time) and ending with the failure date (and time). This is shown graphically next. The operating periods are indicated with a green background.

Thus, TTF_A[1]=5+8=13 hours. 

2. The First Time-To-Repair for Component A, TTR_A[1]
The time-to-repair for component A for this failure, TTR_A[1], is [Date/Time Restored - Date/Time Occurred] or:

TTR_A[1]   = (Jan 02 1997 / 7:49 PM - Jan 02 1997 / 4:00 PM) = 3:49 =3.8166 hrs

(Note that in the case of repair actions, shifts are not taken into account since it is assumed that repair actions will be performed as needed to bring the system up.)

3. The Second Time-To-Failure for Component A, TTF_A[2]
Continuing with component A, the second system failure due to component A is found in row 4, on January 12, 1997 at 3:26 PM. Thus, to compute TTF_A[2], you must look at the age the component accumulated, from the last repair time, taking shifts into account as before, but with the added complexity of accounting for the times that the system was down due to failures of other components (i.e. component A was not aging when the system was down for repair due to a component B failure).

This is shown graphically next using green to show the operating times of A and orange to show the downtimes of the system for reasons other than the failure of A (and to the closest hour).

Then, the total possible hours (TPH) that component A could have operated from the time it was repaired to the time it failed the second time is:

TTF_A[3]=8.9333
TTF_A[4]=56.25
TTF_A[5]=33.05
TTF_A[6]=100.8433
TTF_A[7]=35.7
TTF_A[8]=112.3166
TTF_A[9]=23.1
TTF_A[10]=13.9666
TTF_A[11]=90.5166

and 

TTR_A[3]= 0.4166
TTR_A[4]= 29.6166
TTR_A[5]= 0.4833
TTR_A[6]= 4.5166
TTR_A[7]= 17.2833
TTR_A[8]= 0.4833
TTR_A[9]= 0.45
TTR_A[10]= 5.5
TTR_A[11]= 0.4666

6. Creating the Data Sets
Once the above computations are complete, we can create the data set needed to obtain the life distributions for the failure and repair times for component A. To accomplish this, modifications will need to be performed on the TTF data, given the original assumptions, as follows:

• TTF_A[2] through TTF_A[11] will remain as is and be designated as times-to-failure (F).

• TTF_A[1] will be designated as a right censored data point (or suspension “S”). This is because when we started collecting data, component A was operating for a period of time X (unknown period of time), so the true time-to-failure for component A is the operating time observed (in this case, TTFA[1]=13 hrs) plus the unknown operating time X. Thus, what we know is that the true time-to-failure for A is some time greater than the observed TTF_A[1] (i.e. a right censored data point).

• An additional right censored observation (suspension) will be added to the data set to reflect the time that component A operated without failure from its last repair time to the end of the observation period. This is presented next:

Since our analysis time ends on March 18, 1997 at 1:00 pm and component A has operated successfully from the last time it was replaced or March 13, 1997 at 5:13 p.m., the additional time of successful operation is:

TPH= t (End Time – DTR₁₉)= (4 days*9 hrs/day + 5:00 hrs)=41:00 hrs
NOP= t ( DTO₂₀ – DTR₂₀) =7:24 hrs

Thus, the remaining time that component A operated without failure is:

TTS=TPH-NOP=33:36=33.6 hrs.

7. Data for Life Data Analysis in Weibull++
The next two tables show the data as needed for further analysis in Weibull++ 6. 

8. Automated Analysis in Weibull++ MT
The analysis in Example 1 can be performed automatically in the Weibull++ MT software. Simply enter the data from the equipment downtime log into Weibull++ MT's data entry spreadsheet as shown in Figure 1.

Use the Set Shift Pattern window to specify 8:00 a.m. to 5:00 p.m. shifts seven days a week, as shown in Figure 2.

Figure 2:

The utility will automatically convert the equipment downtime log data to time-to-failure and time-to-repair data and fit failure and repair distributions to the data set. The results are displayed in the Weibull++ MT Results sheet, as shown in Figure 3.

9. Discussion
In this example, we demonstrated the data reduction technique using a simple two-component data set with a single level. This analysis can easily be extended to more components using the same principles. Examples 2, 3 and 4 deal with variations of this process.

Obviously, when dealing with a large system composed of multiple levels (e.g. subsystems, sub-subsystems, assemblies and parts), this analysis process can be very cumbersome. Before the release of Weibull++ MT, it took a ReliaSoft engineer over 40 hours to reduce an equipment downtime log to usable data for analysis in Weibull++. The same analysis was later performed in Weibull++ MT in seconds.

[Exemplo 1]  [Exemplo 2]  [Exemplo 3]  [Exemplo 4]