Template:Multiple systems with event codes rga: Difference between revisions

From ReliaWiki
Jump to navigation Jump to search
(Created page with '==Multiple Systems with Event Codes== The Multiple Systems with Event Codes data type is used to analyze the failure data from a reliability growth test in which a number of sys…')
 
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
==Multiple Systems with Event Codes==
#REDIRECT [[Crow Extended]]
 
The Multiple Systems with Event Codes data type is used to analyze the failure data from a reliability growth test in which a number of systems are tested concurrently and the implemented fixes are tracked during the test phase. With this data type, all of the systems under test are assumed to have the same system hours at any given time. The Crow Extended model is used for this data type so all the underlying assumptions regarding the Crow Extended model apply. As such, this data type is only applicable to data within a single test phase.
As previously presented, the failure mode classifications for the Crow Extended model are defined as follows:
<br>
<br>
:• A indicates that no corrective action was performed or will be performed (management chooses not to address for technical, financial or other reasons).
:• BC indicates that the corrective action was implemented during the test. The analysis assumes that the effect of the corrective action was experienced during the test (as with other test-fix-test reliability growth analyses).
:• BD indicates that the corrective action will be delayed until after the completion of the current test.
<br>
Therefore, implemented fixes can only be applied to BC modes since all BD modes are assumed to be delayed until the end of the test.
For each BC mode, there must be a separate entry in the data set that records the time when the fix was implemented during the test.
<br>
<br>
===Event Codes===
The Multiple Systems with Event Codes data type analyzed with the Crow Extended model uses a column to indicate the types of events that occurred during a test phase. Within RGA, event codes are entered within the Event column of the Multiple Systems with Event Codes data sheets. <br>
<br>
The possible event codes that can be used in the analysis are:
<br>
<br>
I: denotes that a certain BC failure mode has been corrected at the specific time; in other words, a fix has been implemented. For this data type, each BC mode must have an associated I event. The I event is essentially a timestamp for when the fix was implemented during the test.
<br>
Q: indicates that the failure was due to a quality issue. An example of this might be a failure caused by a bolt not being tightened down properly. You have the option to decide whether or not to include quality issues in the analysis. This option can be specified by checking or clearing the Include Q Events checkbox under Event Code Options on the Analysis tab.
<br>
P: indicates that the failure was due to a performance issue. You can determine whether or not to include performance issues in the analysis. This option can be specified by checking or clearing the Include P Events checkbox under Event Code Options on the Analysis tab.
<br>
X: indicates that you wish to exclude the data point from the analysis. An "X" can be placed in front of any existing event code (e.g. XF to exclude a particular failure time) or entered by itself. This row of data will then not be included in the analysis.
<br>
S: indicates the system start time. This event code is only selectable in the Normal View.
<br>
F: indicates a failure time.
<br>
E: indicates the system end time. This event code is only selectable in the Normal View.
<br>
The analysis is based on the equivalent system that combines the operating hours of all the systems. 
<br>
<br>
===Crow Extended Equivalent Single System===
In order to analyze a Multiple Systems with Event Codes data sheet, the data are converted into a Crow Extended equivalent single system. The implemented fixes (I events) are taken into account when building the equivalent single system from the data for multiple systems.
<br>
The basic assumptions and constraints for the use of this data type are listed below:
<br>
<br>
:• Failure modes are assumed to be independent of each other and with respect to the system configuration. The same applies to their related implemented fixes (I events). As such, each mode and its related implemented fixes (I events) are examined separately in terms of their impact to the system configuration.
:• If there are BC modes in the data set, there must be at least 3 unique BC modes to analyze the data (together with implemented fixes for each one of them).
:• If there are BD modes in the data set, there must be at least 3 unique BD modes to analyze the data.
:• To be consistent with the definition of BC modes in the Crow Extended model, every BC mode must have at least one implemented fix (I event) on at least one system.
:• Implemented fixes (I events) cannot be delayed to a later phase, because the Crow Extended model applies to a single phase only.
<br>
The following are 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.
<br>
<br>
:1) 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 will be  <math>30*4=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>40*4=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> .
:2) 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.
:3) 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.
:4) 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:
<br>
:The test time for that BC mode, and one of the following for each of the other systems:
<br>
::a) 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
<br>
::b) 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.
: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. 
<br>
<br>
'''Example 6'''
<br>
Consider the data set shown in Figure Simple example Crow Extended ESS. The data sheet needs to be converted to the Crow Extended equivalent single system. This example is used to demonstrate the application of the five rules mentioned above.
 
[[Image:rga9.15.png|thumb|center|400px|Three systems will event codes.]]
<br>
<br>
'''Solution'''
<br>
The first step to create the equivalent single system is to isolate each failure mode and its implemented fixes independently from each other. The numbered items that follow represent an example application for each one of the five rules mentioned above and are presented in the same numbering sequence. 
<br>
:1) Figure ESSD illustrates the application of rule #1 for mode BD1. The mode in the equivalent single system is calculated as  <math>(75+75+75)=225</math>  or  <math>75*3=225.</math>
 
[[Image:rga9.16.png|thumb|center|400px|Calculating a BD mode.]]
<br>
 
Figure 9.16 illustrates the application of rule #1 for mode A110. The mode in the equivalent single system is calculated as
<math>(280+280+280)=840</math>  or  <math>280*3=840.</math>
 
[[Image:rga9.17.png|thumb|center|400px|Calculating an A mode.]]
<br>
<br>
:2) Figure ESSC10 illustrates the application of rule #2 for the first occurrence of the mode BC10 in system 1. The mode in the equivalent single system is calculated as  <math>(150+150+150)=450</math>  or  <math>150*3=450.</math>
 
[[Image:rga9.18.png|thumb|center|400px|Calculating a BC mode that occurred before an implemented fix.]]
<br>
 
:3) Figure ESSBC10 illustrates the application of rule #3 for implemented fixes (I events) of the mode BC10. In the graph the I events are symbolized by having the letter "I" before the naming of the mode, in this case IBC10 for the implemented fix of mode BC10. The IBC10 in the equivalent single system is calculated as  <math>(200+175+200)=575</math> .
 
:4) Figure ESSC20 illustrates the application of rule #4 for the mode BC20 in system 1, which occurs after a fix for the same mode was implemented in system 2. The mode in the equivalent single system is calculated as  <math>(350+300+350)=1000.</math>
<math></math>
<br>
<br>
[[Image:rga9.19.png|thumb|center|400px|Calculating an implementation event.]]
<br>
<br>
[[Image:rga9.20.png|thumb|center|400px|Calculating a BC mode that occurred after I events.]]
<br>
<br>
[[Image:rga9.21.png|thumb|center|400px|Calculating a second occurrence of a BC mode in the same system, after I events have been implemented.]]
<br>
<br>
[[Image:rga9.22.png|thumb|center|400px|Growth Potential MTBF plot from three systems with event codes.]]
<br>
:5) Figure ESSC10econd illustrates the application of rule #5 for the second occurrence of the mode BC10 in system 1, which occurs after an implemented fix (I event) had occurred for that mode in the same system. The mode in the equivalent single system is calculated as  <math>575+(175+200+175)=1125.</math>
 
 
After having transferred the data set to the Crow Extended equivalent single system, the data set is analyzed using the Crow Extended model as presented in this chapter. Figure multipleventP shows the growth potential MTBF plot that is generated from the Multiple Systems with Event Codes data sheet presented in Figure Simple example Crow Extended ESS.
 
 
====Transferring to Crow Extended - Continuous Evaluation Equivalent Single System====
RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. Figure MultipleventoSS 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.
 
<br>
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. This model is covered in detail in Chapter 10 and familiarity with that model is necessary for the discussion presented in this section.
<br>
When using the Crow Extended - Continuous Evaluation model to transfer the data sheet from Multiple Systems with Event Codes to an equivalent single system, the following rules are used (in addition to the five basic rules presented earlier for calculating the equivalent single system):
<br>
<br>
:• BD modes in the Crow Extended data sheet become BD modes in the equivalent single system of the Crow Extended - Continuous Evaluation data sheet.
:• BC modes in the Crow Extended data sheet become BD modes in the equivalent single system of the Crow Extended - Continuous Evaluation data sheet. These BD modes will have associated implemented fixes (I events). Implemented fixes (I events) for BC modes in the Crow Extended data sheet become implemented fixes (I events) for the converted BD modes in the equivalent single system of the Crow Extended - Continuous Evaluation data sheet.
:• If an implemented fix (I event) occurred at the same time as the failure and was implemented at that exact time across all systems, then this becomes a BC mode in the equivalent single system. If the fixes (I events) were not all implemented at the same time or if the fix was not implemented on all systems at the failure time, then this becomes a BD mode in the equivalent single system.
<br>
Figure ESSECE shows the transferred equivalent single system Crow Extended - Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet of Figure Simple example Crow Extended ESS.
 
[[Image:rga9.23.png|thumb|center|400px|Transfering the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.]]
<br>
<br>
[[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.]]
 
<br>
====Iterations====
When recording modes for transfer from the Multiple Systems with Event Codes to a Crow Extended -Continuous Evaluation equivalent single system, it is recommended to consider using an iteration method to name subsequent recurrences of the same mode. This will help alleviate any issues with the conversion of the definitions of the modes from the Crow Extended model to the Crow Extended - Continuous Evaluation model. For example, if the first occurrence of a mode is BC25, then the second occurrence is suggested to be named as BC25.1. The reasoning behind this recommendation is that in the case that BC25 in the Multiple Systems with Event Codes data sheet has received implemented fixes (I events) at the same time that the failure occurred, in all systems, then this mode will be translated as a BC mode in the Crow Extended - Continuous Evaluation equivalent single system. The next recurring failure would also be treated as a BC mode but in reality it did not have an implemented fix (I event) at the time of failure.
<br>
<br>
'''Example 7'''
<br>
Consider the example shown in Figure iterationsithout, that 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.
Figure iterationsarning shows a warning when trying to convert this data sheet without using iterations.
 
<math></math>
[[Image:rga9.25.png|thumb|center|400px|Repeated modes without iterations.]]
<br>
<br>
[[Image:rga9.26.png|thumb|center|400px|Warning when converting to Crow Extended- Continuous Evaluation model.]]
<br>
<br>
[[Image:rga9.27.png|thumb|center|400px|Repeated modes with iterations.]]
<br>
<br>
 
'''Solution'''
<br>
Figure iterationsith 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.28.png|thumb|center|400px|Correct transfer to the Crow Extended - Continuous Evaluation model with the use of iterations on modes.]]
<br>
<br>
 
This way, the conversion to the Crow Extended - Continuous Evaluation model occurs in a valid fashion, since 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 Figure iterationsHASES. 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.

Latest revision as of 02:09, 23 August 2012

Redirect to:

Retrieved from "https://www.reliawiki.com/index.php?title=Template:Multiple_systems_with_event_codes_rga&oldid=33314"