Crow Extended - Revision history

David J. Groebel: /* Mathematical Formulation */

2020-08-19T23:08:57Z

Mathematical Formulation

← Older revision		Revision as of 23:08, 19 August 2020
Line 138:		Line 138:

	:<math>\begin{align}		:<math>\begin{align}
	{{\lambda }_{\~~Pro jected~~}}= & {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\		{{\lambda }_{\Pr ojected}}= & {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\

David J. Groebel: /* Mathematical Formulation */

2020-08-19T23:07:39Z

Mathematical Formulation

← Older revision		Revision as of 23:07, 19 August 2020
Line 138:		Line 138:

	:<math>\begin{align}		:<math>\begin{align}
	{{\lambda }_{\~~Projected~~}}= & {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\		{{\lambda }_{\Pro jected}}= & {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\

David J. Groebel: /* Mathematical Formulation */

2020-08-19T23:04:42Z

Mathematical Formulation

← Older revision		Revision as of 23:04, 19 August 2020
Line 138:		Line 138:

	:<math>\begin{align}		:<math>\begin{align}
	{{\lambda }_{\~~Pr ojected~~}}= & {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\		{{\lambda }_{\Projected}}= & {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\

David J. Groebel: /* Mathematical Formulation */

2015-02-18T00:33:13Z

Mathematical Formulation

← Older revision		Revision as of 00:33, 18 February 2015
Line 141:		Line 141:
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\
	= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}+h\left( t \right)		= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}+dh\left( t \right)
	\end{align}\,\!</math>		\end{align}\,\!</math>

David J. Groebel: /* Transferring Data to an Equivalent Single System */

2014-08-27T15:06:51Z

Transferring Data to an Equivalent Single System

← Older revision		Revision as of 15:06, 27 August 2014
Line 498:		Line 498:
	RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.		RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.

	[[Image:rga9.23.png\|center~~\|450px~~]]		[[Image:rga9.23.png\|center]]

	The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.		The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.

David J. Groebel at 17:23, 30 May 2014

2014-05-30T17:23:12Z

← Older revision		Revision as of 17:23, 30 May 2014
Line 44:		Line 44:
	It is very important to note that once a BD failure mode is in the system, it is rarely totally eliminated by a corrective action. After a BD mode has been found and fixed, a certain percentage of the failure intensity will be removed, but a certain percentage of the failure intensity will generally remain. For each BD mode, an ''effectiveness factor'' (EF) is required to estimate how effective the corrective action will be in eliminating the failure intensity due to the failure mode. The EF is the fractional decrease in a mode's failure intensity after a corrective action has been made, and it must be a value between 0 and 1. It has been shown empirically that an average EF, <math>d\,\!</math>, is about 70%. Therefore, about 30 percent, (i.e., 100 <math>(1-d)\,\!</math> percent), of the BD mode failure intensity will typically remain in the system after all of the corrective actions have been implemented. However, individual EFs for the failure modes may be larger or smaller than the average. The next figure displays the RGA software's Effectiveness Factor window where the effectiveness factors for each unique BD failure mode can be specified.		It is very important to note that once a BD failure mode is in the system, it is rarely totally eliminated by a corrective action. After a BD mode has been found and fixed, a certain percentage of the failure intensity will be removed, but a certain percentage of the failure intensity will generally remain. For each BD mode, an ''effectiveness factor'' (EF) is required to estimate how effective the corrective action will be in eliminating the failure intensity due to the failure mode. The EF is the fractional decrease in a mode's failure intensity after a corrective action has been made, and it must be a value between 0 and 1. It has been shown empirically that an average EF, <math>d\,\!</math>, is about 70%. Therefore, about 30 percent, (i.e., 100 <math>(1-d)\,\!</math> percent), of the BD mode failure intensity will typically remain in the system after all of the corrective actions have been implemented. However, individual EFs for the failure modes may be larger or smaller than the average. The next figure displays the RGA software's Effectiveness Factor window where the effectiveness factors for each unique BD failure mode can be specified.

	[[Image:rga9.2.png\|center\|~~400px~~\|Effectiveness factors defined for each unique BD mode.]]		[[Image:rga9.2.png\|center\|450px\|Effectiveness factors defined for each unique BD mode.]]

	The EF does not account for the scenario where additional failure modes are created from the corrective actions. If this happens, then the actual EF will be lower than the assumed value. An EF greater than or equal to 0.9 indicates a significant improvement in a failure mode's MTBF (or reduction in failure intensity). This is indicative of a design change. The increase in a failure mode's MTBF, given an EF, can be calculated using:		The EF does not account for the scenario where additional failure modes are created from the corrective actions. If this happens, then the actual EF will be lower than the assumed value. An EF greater than or equal to 0.9 indicates a significant improvement in a failure mode's MTBF (or reduction in failure intensity). This is indicative of a design change. The increase in a failure mode's MTBF, given an EF, can be calculated using:
Line 303:		Line 303:
	Management controls the resources for corrective actions. Consequently, the effectiveness factors are part of the management strategy. For the BD mode failure intensity that has been seen during development testing, 100 <math>d\,\!</math> percent will be removed and 100 <math>(1-d)\,\!</math> percent will remain in the system. Therefore, after the corrective actions have been made, the current system instantaneous failure intensity consists of the failure intensity due to the A modes plus the failure intensity for the unseen BC modes, and plus the failure intensity for the unseen BD modes plus the failure intensity for the BD modes that have been seen. The following pie chart shows how the system's instantaneous failure intensity can be broken down into its individual pieces based on the current failure mode strategy.		Management controls the resources for corrective actions. Consequently, the effectiveness factors are part of the management strategy. For the BD mode failure intensity that has been seen during development testing, 100 <math>d\,\!</math> percent will be removed and 100 <math>(1-d)\,\!</math> percent will remain in the system. Therefore, after the corrective actions have been made, the current system instantaneous failure intensity consists of the failure intensity due to the A modes plus the failure intensity for the unseen BC modes, and plus the failure intensity for the unseen BD modes plus the failure intensity for the BD modes that have been seen. The following pie chart shows how the system's instantaneous failure intensity can be broken down into its individual pieces based on the current failure mode strategy.

	[[Image:rga9.5.png\|center\|~~400px~~\|System failure intensity after the corrective actions.]]		[[Image:rga9.5.png\|center\|450px\|System failure intensity after the corrective actions.]]

	Keep in mind that the individual components of the system's instantaneous failure intensity will depend on the classifications defined in the data. For example, if BC modes are not present within the data, then the BC mode MTBF will not be a part of the overall system MTBF. The individual pieces of the pie, as shown in the above figure, are calculated using the following equations.		Keep in mind that the individual components of the system's instantaneous failure intensity will depend on the classifications defined in the data. For example, if BC modes are not present within the data, then the BC mode MTBF will not be a part of the overall system MTBF. The individual pieces of the pie, as shown in the above figure, are calculated using the following equations.
Line 498:		Line 498:
	RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.		RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.

	[[Image:rga9.23.png~~\|thumb~~\|center\|~~250px\|Transferring the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.~~]]		[[Image:rga9.23.png\|center\|450px]]

	The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.		The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.
Line 510:		Line 510:
	The next figure shows the transferred equivalent single system Crow Extended - Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet for the data from the [[Crow_Extended#Example:_Equivalent_Single_System\|Equivalent Single System example]] given above.		The next figure shows the transferred equivalent single system Crow Extended - Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet for the data from the [[Crow_Extended#Example:_Equivalent_Single_System\|Equivalent Single System example]] given above.

	[[Image:rga9.24.png~~\|thumb~~\|center\|~~400px\|The transferred equivalent single system Crow Extended- Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet of Figure 9.15.~~]]		[[Image:rga9.24.png\|center\|450px]]

	===Iteration Method for Naming Repeated Modes===		===Iteration Method for Naming Repeated Modes===
Line 517:		Line 517:
	For example, consider the data set shown in the following figure, which represents one system only for simplicity. Notice that the modes BC25, BC35 and BC45 received implemented fixes at the time of failure. Based on that, when they get transferred to the Crow Extended - Continuous Evaluation equivalent single system, they will be considered as BC modes. The subsequent failures of the modes 25, 35 and 45 will also be converted to BC modes, when in reality they had implemented fixes (''I'' events) at a later time.		For example, consider the data set shown in the following figure, which represents one system only for simplicity. Notice that the modes BC25, BC35 and BC45 received implemented fixes at the time of failure. Based on that, when they get transferred to the Crow Extended - Continuous Evaluation equivalent single system, they will be considered as BC modes. The subsequent failures of the modes 25, 35 and 45 will also be converted to BC modes, when in reality they had implemented fixes (''I'' events) at a later time.

	[[Image:rga9.25.png~~\|thumb~~\|center\|~~400px\|Repeated modes without iterations.~~]]		[[Image:rga9.25.png\|center\|450px]]

	The RGA software will display a warning if you try to convert this data sheet without using iterations.		The RGA software will display a warning if you try to convert this data sheet without using iterations.
Line 523:		Line 523:
	The next figure shows the same data sheet with the use of iterations for the modes 25, 35 and 45. The subsequent failures are named as BC25.1, BC35.1 and BC45.1.		The next figure shows the same data sheet with the use of iterations for the modes 25, 35 and 45. The subsequent failures are named as BC25.1, BC35.1 and BC45.1.

	[[Image:rga9.27.png~~\|thumb~~\|center\|~~400px\|Repeated modes with iterations.~~]]		[[Image:rga9.27.png\|center\|450px]]

	This way, the conversion to the Crow Extended - Continuous Evaluation model occurs in a valid fashion, because although the original BC modes are converted to BC25, BC35 and BC45, the subsequent failures are converted to BD25.1, BD35.1 and BD45.1 together with their respective implemented fixes (''I'' events). This is shown in the next figure below. Note that the use of iterations is recommended only when transferring to the Crow Extended - Continuous Evaluation equivalent single system; it is not necessary when using the Multiple Systems with Event Codes data sheet that is calculated with the Crow Extended model.		This way, the conversion to the Crow Extended - Continuous Evaluation model occurs in a valid fashion, because although the original BC modes are converted to BC25, BC35 and BC45, the subsequent failures are converted to BD25.1, BD35.1 and BD45.1 together with their respective implemented fixes (''I'' events). This is shown in the next figure below. Note that the use of iterations is recommended only when transferring to the Crow Extended - Continuous Evaluation equivalent single system; it is not necessary when using the Multiple Systems with Event Codes data sheet that is calculated with the Crow Extended model.

	[[Image:rga9.28.png~~\|thumb~~\|center\|~~400px\|Correct transfer to the Crow Extended - Continuous Evaluation model with the use of iterations on modes.~~]]		[[Image:rga9.28.png\|center\|450px]]

	==More Examples==		==More Examples==

Chris Kahn: /* Transferring Data to an Equivalent Single System */

2014-05-15T20:19:42Z

Transferring Data to an Equivalent Single System

← Older revision		Revision as of 20:19, 15 May 2014
Line 498:		Line 498:
	RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.		RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.

	[[Image:rga9.23.png\|thumb\|center\|~~319px~~\|Transferring the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.]]		[[Image:rga9.23.png\|thumb\|center\|250px\|Transferring the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.]]

	The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.		The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.

Chris Kahn: /* Equivalent Single System */

2014-05-14T17:49:22Z

Equivalent Single System

← Older revision		Revision as of 17:49, 14 May 2014
Line 482:		Line 482:

	The following list shows the basic rules for calculating the equivalent single system on which the Crow Extended model is applied. Note that the list is not exhaustive since there is an infinite number of scenarios that can occur. These rules cover the most common scenarios. The main concept is to add the time that each system was tested under the same configuration.		The following list shows the basic rules for calculating the equivalent single system on which the Crow Extended model is applied. Note that the list is not exhaustive since there is an infinite number of scenarios that can occur. These rules cover the most common scenarios. The main concept is to add the time that each system was tested under the same configuration.
			<ol>
	# To get to the equivalent single system, each failure time for A modes and BD modes is calculated by adding the time that each system was tested under the same configuration. In practice this means multiplying the failure time in the system by the number of total systems under test. For example, if we have 4 total systems, and system 2 has a BD1 mode at time 30, the BD1 mode failure time in the equivalent single system would be <math>304=120\,\!</math>. If system 3 had another BD1 mode at time 40, then that would yield another BD1 mode in the equivalent single system at time <math>404=160\,\!</math>. These calculations are done assuming that the start time for the systems are at time zero. If the start time is different than zero, then that time would have to be subtracted from the failure time on each system. For example, if system 1 started at time S=10, and there was a failure at time 30, the equivalent system time would be <math>(30-10)*4=80\,\!</math>.		<li>To get to the equivalent single system, each failure time for A modes and BD modes is calculated by adding the time that each system was tested under the same configuration. In practice this means multiplying the failure time in the system by the number of total systems under test. For example, if we have 4 total systems, and system 2 has a BD1 mode at time 30, the BD1 mode failure time in the equivalent single system would be <math>304=120\,\!</math>. If system 3 had another BD1 mode at time 40, then that would yield another BD1 mode in the equivalent single system at time <math>404=160\,\!</math>. These calculations are done assuming that the start time for the systems are at time zero. If the start time is different than zero, then that time would have to be subtracted from the failure time on each system. For example, if system 1 started at time S=10, and there was a failure at time 30, the equivalent system time would be <math>(30-10)*4=80\,\!</math>.</li>
	# Each failure time for a BC mode that occurred before an implemented fix (''I'' event) for that mode is also calculated by multiplying the failure time in the system by the number of total systems in test, as described above.		<li>Each failure time for a BC mode that occurred before an implemented fix (''I'' event) for that mode is also calculated by multiplying the failure time in the system by the number of total systems in test, as described above.</li>
	#The implemented fix (''I'' event) time in the equivalent single system is calculated by adding the test time invested in each system before that ''I'' event takes place. It is the total time that the system has spent at the same configuration in terms of that specific mode.		<li>The implemented fix (''I'' event) time in the equivalent single system is calculated by adding the test time invested in each system before that ''I'' event takes place. It is the total time that the system has spent at the same configuration in terms of that specific mode.</li>
	# If the same BC mode occurs in another system after a fix (''I'' event) has been implemented in one or more systems, the failure time in the equivalent single system is calculated by adding the test time for that BC mode, and one of the following for each of the other systems:		<li>If the same BC mode occurs in another system after a fix (''I'' event) has been implemented in one or more systems, the failure time in the equivalent single system is calculated by adding the test time for that BC mode, and one of the following for each of the other systems:
	::*If a BC mode occurs in a system that has already seen an ''I'' event for that mode, then you add the time up to the ''I'' event.		::*If a BC mode occurs in a system that has already seen an ''I'' event for that mode, then you add the time up to the ''I'' event.
	:::or		:::or
	::*If the ''I'' events occurred later than the BC failure time or those systems did not have any ''I'' events for that mode, then you add the time of the BC failure.		::*If the ''I'' events occurred later than the BC failure time or those systems did not have any ''I'' events for that mode, then you add the time of the BC failure.</li>
	~~:5.~~ If the same BC mode occurs in the same system after a fix (''I'' event) has been implemented in one or more systems, the failure time in the equivalent single system is calculated by adding the test time of each system after that ''I'' event was implemented to the ''I'' event time in the equivalent single system, or zero if an ''I'' event was not present in that system.		<li>If the same BC mode occurs in the same system after a fix (''I'' event) has been implemented in one or more systems, the failure time in the equivalent single system is calculated by adding the test time of each system after that ''I'' event was implemented to the ''I'' event time in the equivalent single system, or zero if an ''I'' event was not present in that system.</li>
			</ol>
	====Example: Equivalent Single System====<!-- THIS SECTION HEADER IS LINKED FROM ANOTHER PLACE IN THIS DOCUMENT. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->		====Example: Equivalent Single System====<!-- THIS SECTION HEADER IS LINKED FROM ANOTHER PLACE IN THIS DOCUMENT. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->
	{{:Equivalent_System_Example}}		{{:Equivalent_System_Example}}

David J. Groebel: /* Example: Test-Fix-Find-Test Data */

2014-04-24T19:28:25Z

Example: Test-Fix-Find-Test Data

← Older revision		Revision as of 19:28, 24 April 2014
Line 395:		Line 395:
	\end{align}\,\!</math>		\end{align}\,\!</math>

	===Example: Test-Fix-Find-Test Data=== <!-- THIS SECTION HEADER IS LINKED FROM: Operational Mission Profile Testing. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->		===Example - Test-Fix-Find-Test Data=== <!-- THIS SECTION HEADER IS LINKED FROM: Operational Mission Profile Testing. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->
	{{:Test-Fix-Find-Test_Data_Example}}		{{:Test-Fix-Find-Test_Data_Example}}

David J. Groebel: /* Example: Test-Find-Test Data */

2014-04-24T19:28:06Z

Example: Test-Find-Test Data

← Older revision		Revision as of 19:28, 24 April 2014
Line 195:		Line 195:
	:<math>M\hat{T}B{{F}_{GP}}={{[{{\hat{r}}_{GP}}]}^{-1}}\,\!</math>		:<math>M\hat{T}B{{F}_{GP}}={{[{{\hat{r}}_{GP}}]}^{-1}}\,\!</math>

	===Example: Test-Find-Test Data===		===Example - Test-Find-Test Data===
	{{:Test-Find-Test_Data_Example}}		{{:Test-Find-Test_Data_Example}}