Figure 8.11: The Block Details results for component A.
Simulation results for each component can also be viewed. Figure 8.11 shows the results for component A. These results are explained in the sections that follow.
This the number of times the component went down (failed). It includes all downing events.
This is the number of times that this component's downing caused the system to be down. For component A, this is 2.009. Note that this value is the same in this case as the number of component failures, since the two components are reliability-wise in series. If this were not the case (e.g. if they were in a parallel configuration), this value would be different.
This is the number of times the component failed and does not include other downing events. Note that this could also be interpreted as the number of spare parts required for CM actions for this component. For component A, this is 2.009.
This is the number of times that this component's failure caused the system to be down. Note that this may be different from the Number of SD Events. It only counts the failure events that downed the system and does not include zero duration system failures.
This has the same definition as for the system with the exception that this looks only at the component.
This has the same definition as for the system with the exception that this looks only at the component.
This is the average time the component was up. For component A, this is 279.996.
This is the average time the component was down for any reason. For component A, this is 279.996.
ReliaSoft's Downing Event Criticality Index (RS DECI) is a relative index showing the percentage of times that a downing event of the component caused the system to go down (i.e. the number of system downing events caused by the component divided by the total number of system downing events). For component A, this is 50.25%. This implies that 50.25% of the times that the system went down, the system failure was due to the fact that component A went down. This is obtained from:
This is the mean time between downing events of the component, which is computed from:
For component A, this is 139.3709.
ReliaSoft's Failure Criticality Index (RS FCI) is a relative index showing the percentage of times that a failure of the component caused a system failure (i.e. the number of system failures caused by the component divided by the total number of system failures). Note that this relates to all failures, not just downing failures. For component A, this is 50.25%. This implies that 50.25% of the times that the system failed, it was due to the fact that component A failed. This is obtained from:
FZD is a special counter of system failures not included in ComponentNSDF. This counter is not explicitly shown in the results but is maintained by the software. The reason for this counter is the fact that zero duration failures are not counted in ComponentNSDF since they really did not down the system. However, these zero duration failures need to be included when computing RS FCI.
It is important to note that for both RS DECI and RS FCI, and if overlapping events are present, the component that caused the system event gets credited with the system event. Subsequent component events that do not bring the system down (since the system is already down) do not get counted in this metric.
Mean time between failures is the mean (average) time between failures of this component, in real clock time. This is computed from:
CFDowntime is the downtime of the component due to failures only (without PM and inspection). The discussion regarding what is a failure downtime that was presented in the section explaining Mean Availability (w/o PM & Inspection) also applies here.
For component A, this is 139.37. Note that this value could fluctuate for the same component depending on the simulation end time. As an example, consider the deterministic scenario for this component. It fails every 100 hours and takes 10 hours to repair. Thus, it would be failed at 100, repaired by 110, failed at 210 and repaired by 220. Therefore, its uptime is 280 with two failure events, MTBF = 280/2 = 140. Repeating the same scenario with an end time of 330 would yield a failures at 100, 210 and 320. Thus, the uptime would be 300 with three failures, or MTBF = 300/3 = 100. Note that this is not the same as the MTTF (mean time to failure), commonly referred to as MTBF by many practitioners.
Mean downtime per event is the average downtime for a component event. This is computed from:
The remaining component (block) results are similar to those defined for the system with the exception that now they apply only to the component.
See Also:
Repairable Systems Analysis Through Simulation
Go
to weibull.com
Go
to ReliaSoft.com
©1999-2007. ReliaSoft Corporation. ALL RIGHTS RESERVED.