Event Log Data - Revision history

Lisa Hacker at 19:15, 15 September 2023

2023-09-15T19:15:17Z

← Older revision		Revision as of 19:15, 15 September 2023
Line 1:		Line 1:
	{{Template:~~LDABOOK_SUB~~\|Additional Reliability Analysis Tools\|Event-Log Data Analysis}}		{{Template:LDABOOK\|Additional Reliability Analysis Tools\|Event-Log Data Analysis}}
	Event logs, or maintenance logs, store information about a piece of equipment's failures and repairs. They provide useful information that can help companies achieve their productivity goals by giving insight about the failure modes, frequency of outages, repair duration, uptime/downtime and availability of the equipment. Some event logs contain more information than others, but essentially event logs capture data in a format that includes the type of event, the date/time when the event occurred and the date/time when the system was restored to operation.		Event logs, or maintenance logs, store information about a piece of equipment's failures and repairs. They provide useful information that can help companies achieve their productivity goals by giving insight about the failure modes, frequency of outages, repair duration, uptime/downtime and availability of the equipment. Some event logs contain more information than others, but essentially event logs capture data in a format that includes the type of event, the date/time when the event occurred and the date/time when the system was restored to operation.

Kate Racaza at 18:26, 1 December 2015

2015-12-01T18:26:22Z

← Older revision		Revision as of 18:26, 1 December 2015
Line 262:		Line 262:
	This component and sub-component combination will yield a unique item that must be treated separately, much as components A and B were in the first example. The same concept applies when more levels are present. When specifying OTF (Operate Through other Failures) characteristics at this level, each component and sub-component combination is treated differently. In other words, it is possible that A-A1 and A-A2 have different OTF designations, even though they belong to the same component; however, all A-A2s must have the same OTF designation.		This component and sub-component combination will yield a unique item that must be treated separately, much as components A and B were in the first example. The same concept applies when more levels are present. When specifying OTF (Operate Through other Failures) characteristics at this level, each component and sub-component combination is treated differently. In other words, it is possible that A-A1 and A-A2 have different OTF designations, even though they belong to the same component; however, all A-A2s must have the same OTF designation.

			<div class="noprint">
	{{:Weibull++_Event_Log_Folio_Example}}		{{:Weibull++_Event_Log_Folio_Example}}
			</div>

Richard House at 18:44, 26 September 2012

2012-09-26T18:44:28Z

Kate Racaza at 22:33, 26 August 2012

2012-08-26T22:33:08Z

← Older revision		Revision as of 22:33, 26 August 2012
Line 262:		Line 262:
	This component and sub-component combination will yield a unique item that must be treated separately, much as components A and B were in the first example. The same concept applies when more levels are present. When specifying OTF (Operate Through other Failures) characteristics at this level, each component and sub-component combination is treated differently. In other words, it is possible that A-A1 and A-A2 have different OTF designations, even though they belong to the same component; however, all A-A2s must have the same OTF designation.		This component and sub-component combination will yield a unique item that must be treated separately, much as components A and B were in the first example. The same concept applies when more levels are present. When specifying OTF (Operate Through other Failures) characteristics at this level, each component and sub-component combination is treated differently. In other words, it is possible that A-A1 and A-A2 have different OTF designations, even though they belong to the same component; however, all A-A2s must have the same OTF designation.

			{{:Weibull++_Event_Log_Folio_Example}}
	{{~~Examples Box\|~~Weibull++~~_Examples\|<p>More event log folio examples are available! See also:</p>~~
	~~{{Examples Both\|http://www.reliasoft.com/Weibull/examples/rc6/index.htm\|Factory Equipment Failure Log\|http://www.reliasoft.tv/weibull/appexamples/weibull_app_ex_6.html\|Watch the video...}}<nowiki/>~~
	}}

Kate Racaza: /* Example: System with Components Operating Through System Failures */

2012-08-26T22:17:04Z

Example: System with Components Operating Through System Failures

← Older revision		Revision as of 22:17, 26 August 2012
Line 231:		Line 231:

	==Example: System with Components Operating Through System Failures==		==Example: System with Components Operating Through System Failures==
	~~In this example, we~~ will repeat the first example, but with an interesting twist. In the first example, the assumption was that when the system was down due to a failure, none of the components aged. We will now allow some of these components to age even when the system is down.		We will repeat the first example, but with an interesting twist. In the first example, the assumption was that when the system was down due to a failure, none of the components aged. We will now allow some of these components to age even when the system is down.

	Using the same data as in the first example, we will assume that component B accumulates age when the system is down for any reason other than the failure of component B. Component A will not accumulate age when the system is down. We indicate this in the data sheet in the OTF (Operate Through other Failures) column, where Y = yes and N = no. Note that this entry must be consistent with all other events in the data set associated with the component (i.e., all component A records must show N and all component B records must show Y).		Using the same data as in the first example, we will assume that component B accumulates age when the system is down for any reason other than the failure of component B. Component A will not accumulate age when the system is down. We indicate this in the data sheet in the OTF (Operate Through other Failures) column, where Y = yes and N = no. Note that this entry must be consistent with all other events in the data set associated with the component (i.e., all component A records must show N and all component B records must show Y).
Line 250:		Line 250:

	The TTR analysis is not affected by this setting and is identical to the result in the first example.		The TTR analysis is not affected by this setting and is identical to the result in the first example.


	==Example: System with Sub-Components==		==Example: System with Sub-Components==

Kate Racaza: /* Converting Event Logs to Failure/Repair Data */

2012-08-26T22:04:57Z

Converting Event Logs to Failure/Repair Data

← Older revision		Revision as of 22:04, 26 August 2012
Line 35:		Line 35:


	The four ~~equation~~ given above are valid for cases in which ~~the~~ component operates through the failure of other components. When the component does not operate through the failures, the assumptions must include the downtime of the system due to the other failures. In other words, the first four equations become:		The four equations given above are valid for cases in which a component operates through the failure of other components. When the component does not operate through the failures, the assumptions must include the downtime of the system due to the other failures. In other words, the first four equations become:


Line 53:		Line 53:


	All these equations should also take into consideration the periods when the system is not operating or not in use, as in the case of operations that do not run on a 24/7 basis.		All these equations should also take into consideration the periods when the system is not operating or not in use, as in the case of operations that do not run on a 24/7 basis.


	==Example: Simple System==		==Example: Simple System==

Harry Guo at 05:21, 24 August 2012

2012-08-24T05:21:47Z

← Older revision		Revision as of 05:21, 24 August 2012
Line 38:		Line 38:


	::<math>\text{Time-to-Failure}_{i}=t_{1}-r_{i-1}-(\text{System Downtime since}\,r_{i-1})\,\!</math>		::<math>\text{Time-to-Failure}_{i}=t_{i}-r_{i-1}-(\text{System Downtime since}\,r_{i-1})\,\!</math>

	::<math>\text{Time-to-~~failure~~}_{i}=t_{1}-(\text{System Start Time}-\text{System Downtime since System Start Time})\,\!</math>		::<math>\text{Time-to-Failure}_{1}=t_{1}-(\text{System Start Time}-\text{System Downtime since System Start Time})\,\!</math>

	::<math>\text{Suspension}_{1}=t_{1}-(\text{System Start Time}-\text{System Downtime since System Start Time})\,\!</math>		::<math>\text{Suspension}_{1}=t_{1}-(\text{System Start Time}-\text{System Downtime since System Start Time})\,\!</math>

	::<math>\text{~~LastSuspension~~} = \text{System End Time}-r_{n}-\text{System Downtime since}\,r_{n}\,\!</math>		::<math>\text{Last Suspension} = \text{System End Time}-r_{n}-\text{System Downtime since}\,r_{n}\,\!</math>

Harry Guo at 05:16, 24 August 2012

2012-08-24T05:16:25Z

← Older revision		Revision as of 05:16, 24 August 2012
Line 9:		Line 9:


	::<math>\text{Time-to-Failure}_{i}=t_{1}-r_{i-1}\,\!</math>		::<math>\text{Time-to-Failure}_{i}=t_{i}-r_{i-1}\,\!</math>

	::where:		::where:

Kate Racaza at 03:09, 24 August 2012

2012-08-24T03:09:27Z

← Older revision		Revision as of 03:09, 24 August 2012
Line 212:		Line 212:

	[[image:Event Log 7.png\|center\|700px]]		[[image:Event Log 7.png\|center\|700px]]


	==Example: System with Failure and Non-Failure Events==		==Example: System with Failure and Non-Failure Events==
Line 230:		Line 231:


	==Example: Components Operating Through System Failures==		==Example: System with Components Operating Through System Failures==
	In this example, we will repeat the first example, but with an interesting twist. In the first example, the assumption was that when the system was down due to a failure, none of the components aged. We will now allow some of these components to age even when the system is down.		In this example, we will repeat the first example, but with an interesting twist. In the first example, the assumption was that when the system was down due to a failure, none of the components aged. We will now allow some of these components to age even when the system is down.

Line 251:		Line 252:
	The TTR analysis is not affected by this setting and is identical to the result in the first example.		The TTR analysis is not affected by this setting and is identical to the result in the first example.

	==Example: System with ~~Different Component Levels~~==
			==Example: System with Sub-Components==
	In this example, we will repeat the first example, but use two component levels instead of a single level. Using the same data as in the first example, we will assume that component A has two sub-components, A1 and A2; and component B also has two sub-components, B1 and B2, as shown in the following table.		In this example, we will repeat the first example, but use two component levels instead of a single level. Using the same data as in the first example, we will assume that component A has two sub-components, A1 and A2; and component B also has two sub-components, B1 and B2, as shown in the following table.

Kate Racaza: /* Example: Components Operating Through System Failures */

2012-08-24T03:02:08Z

Example: Components Operating Through System Failures

← Older revision		Revision as of 03:02, 24 August 2012
Line 239:		Line 239:


	Because component A does not operate through other failures, the analysis steps (and results) are identical to the ones in the first example. However, the analysis for the times-to-failure for component B will be different (and ~~are~~ actually less cumbersome than in the first example because we do not need to subtract the time that the system was down due to the failure of other components).		Because component A does not operate through other failures, the analysis steps (and results) are identical to the ones in the first example. However, the analysis for the times-to-failure for component B will be different (and is actually less cumbersome than in the first example because we do not need to subtract the time that the system was down due to the failure of other components).

	Specifically:		Specifically:
Line 250:		Line 250:

	The TTR analysis is not affected by this setting and is identical to the result in the first example.		The TTR analysis is not affected by this setting and is identical to the result in the first example.


	==Example: System with Different Component Levels==		==Example: System with Different Component Levels==

← Older revision		Revision as of 18:44, 26 September 2012
Line 103:		Line 103:


	To illustrate this mathematically, we will use a function, <math>\tau</math>, which, given a range of times, returns the shift hours worked during that period. In other words, for this example <math>\tau</math>(1/1/97 3:00 AM - 1/1/97 6:00 PM) = 9 hours given an 8 AM to 5 PM shift. Furthermore, we will show the date and time a failure occurred as DTO and the date and time a repair was completed at DTR with a numerical subscript indicating the row that this entry is in (e.g., DTO<sub>4</sub> for the date and time a failure occurred in row 4).		To illustrate this mathematically, we will use a function, <math>\tau\,\!</math>, which, given a range of times, returns the shift hours worked during that period. In other words, for this example <math>\tau\,\!</math>(1/1/97 3:00 AM - 1/1/97 6:00 PM) = 9 hours given an 8 AM to 5 PM shift. Furthermore, we will show the date and time a failure occurred as DTO and the date and time a repair was completed at DTR with a numerical subscript indicating the row that this entry is in (e.g., DTO<sub>4</sub> for the date and time a failure occurred in row 4).

	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:		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:

	::TPH = <math>\tau</math>(DTO<sub>4</sub> – DTR<sub>1</sub>),		::TPH = <math>\tau\,\!</math>(DTO<sub>4</sub> – DTR<sub>1</sub>),

	::TPH = <math>\tau</math>(DTO<sub>4</sub> – DTR<sub>1</sub>) = 9 Days * 9 hours + 7:26 hours = 88:26 hours = 88.433 hours		::TPH = <math>\tau\,\!</math>(DTO<sub>4</sub> – DTR<sub>1</sub>) = 9 Days * 9 hours + 7:26 hours = 88:26 hours = 88.433 hours


	The time that component A was not operating (NOP) during normal hours of operation is the time that the system was down due to failure of component B, or:		The time that component A was not operating (NOP) during normal hours of operation is the time that the system was down due to failure of component B, or:

	::NOP = <math>\tau</math>(DTO<sub>2</sub> – DTR<sub>2</sub>) + <math>\tau</math>(DTO<sub>3</sub> – DTR<sub>3</sub>)		::NOP = <math>\tau\,\!</math>(DTO<sub>2</sub> – DTR<sub>2</sub>) + <math>\tau\,\!</math>(DTO<sub>3</sub> – DTR<sub>3</sub>)
	::NOP = <math>\tau</math>(DTO<sub>2</sub> – DTR<sub>2</sub>) + <math>\tau</math>( DTO<sub>3</sub> – DTR<sub>3</sub>) = 2:13 hours + 7:47 hours = 10:00 hours		::NOP = <math>\tau\,\!</math>(DTO<sub>2</sub> – DTR<sub>2</sub>) + <math>\tau\,\!</math>( DTO<sub>3</sub> – DTR<sub>3</sub>) = 2:13 hours + 7:47 hours = 10:00 hours


Line 128:		Line 128:
	To compute the time-to-repair for this failure:		To compute the time-to-repair for this failure:

	::TTR<sub>A</sub>[2] = <math>\tau</math> (DTO<sub>4</sub> – DTR<sub>4</sub>) = (3 h, 49 m) = 3.8166 hours		::TTR<sub>A</sub>[2] = <math>\tau\,\!</math> (DTO<sub>4</sub> – DTR<sub>4</sub>) = (3 h, 49 m) = 3.8166 hours


Line 178:		Line 178:
	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 on March 13, 1997 at 5:13 PM, the additional time of successful operation is:		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 on March 13, 1997 at 5:13 PM, the additional time of successful operation is:

	::TPH = <math>\tau</math>(End Time – DTR<sub>19</sub>) = (4 days * 9 hours/day + 5:00 hours) = 41:00 hours		::TPH = <math>\tau\,\!</math>(End Time – DTR<sub>19</sub>) = (4 days * 9 hours/day + 5:00 hours) = 41:00 hours

	::NOP = <math>\tau</math>( DTO<sub>20</sub> – DTR<sub>20</sub>) = 7:24 hours		::NOP = <math>\tau\,\!</math>( DTO<sub>20</sub> – DTR<sub>20</sub>) = 7:24 hours

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

	::TTF<sub>B</sub>[1] = <math>\tau</math>(Start Time - DTO<sub>2</sub> ) = 68:30 = 68.5 hours		::TTF<sub>B</sub>[1] = <math>\tau\,\!</math>(Start Time - DTO<sub>2</sub> ) = 68:30 = 68.5 hours

	::TTF<sub>B</sub>[2] = <math>\tau</math>(DTR<sub>2</sub> - DTO<sub>3</sub>) = 7:30 = 7.5 hours		::TTF<sub>B</sub>[2] = <math>\tau\,\!</math>(DTR<sub>2</sub> - DTO<sub>3</sub>) = 7:30 = 7.5 hours

	::TTF<sub>B</sub>[3] = <math>\tau</math>(DTR<sub>3</sub> - DTO<sub>6</sub>) = 41.26 hours		::TTF<sub>B</sub>[3] = <math>\tau\,\!</math>(DTR<sub>3</sub> - DTO<sub>6</sub>) = 41.26 hours

	The TTR analysis is not affected by this setting and is identical to the result in the first example.		The TTR analysis is not affected by this setting and is identical to the result in the first example.