Template:Crow extended equivalent single system rga

From ReliaWiki
Revision as of 21:08, 10 January 2012 by Nicolette Young (talk | contribs) (Created page with '===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 sys…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.
The basic assumptions and constraints for the use of this data type are listed below:

• 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.


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.

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]\displaystyle{ 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]\displaystyle{ 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]\displaystyle{ (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:


The test time for that BC mode, and one of the following for each of the other systems:


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


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. 



Example 6
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.

Three systems will event codes.



Solution
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. 

1) Figure ESSD illustrates the application of rule #1 for mode BD1. The mode in the equivalent single system is calculated as [math]\displaystyle{ (75+75+75)=225 }[/math] or [math]\displaystyle{ 75*3=225. }[/math]
Calculating a BD mode.


Figure 9.16 illustrates the application of rule #1 for mode A110. The mode in the equivalent single system is calculated as [math]\displaystyle{ (280+280+280)=840 }[/math] or [math]\displaystyle{ 280*3=840. }[/math]

Calculating an A mode.



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]\displaystyle{ (150+150+150)=450 }[/math] or [math]\displaystyle{ 150*3=450. }[/math]
Calculating a BC mode that occurred before an implemented fix.


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]\displaystyle{ (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]\displaystyle{ (350+300+350)=1000. }[/math]

[math]\displaystyle{ }[/math]

Calculating an implementation event.



Calculating a BC mode that occurred after I events.



Calculating a second occurrence of a BC mode in the same system, after I events have been implemented.



Growth Potential MTBF plot from three systems with event codes.


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]\displaystyle{ 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.


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

• 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.


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.

Transfering the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.



The transferred equivalent single system Crow Extended- Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet of Figure 9.15.


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.

Example 7
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]\displaystyle{ }[/math]

Repeated modes without iterations.



Warning when converting to Crow Extended- Continuous Evaluation model.



Repeated modes with iterations.



Solution
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.

Correct transfer to the Crow Extended - Continuous Evaluation model with the use of iterations on modes.



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.