Time-Dependent System Reliability (Analytical): Difference between revisions
Line 676: | Line 676: | ||
===Simple Standby Configuration=== | ===Simple Standby Configuration=== | ||
Consider two components in a standby configuration. Component 1 is the active component with a Weibull failure distribution with parameters <math>\beta </math> = 1.5 and <math>\eta </math> = 1,000. Component 2 is the standby component. When Component 2 is operating, it also has a Weibull failure distribution with <math>\beta </math> = 1.5 and <math>\eta </math> = 1,000. Furthermore, assume the following cases for the quiescent distribution. | Consider two components in a standby configuration. Component 1 is the active component with a Weibull failure distribution with parameters <math>\beta </math> = 1.5 and <math>\eta </math> = 1,000. Component 2 is the standby component. When Component 2 is operating, it also has a Weibull failure distribution with <math>\beta </math> = 1.5 and <math>\eta </math> = 1,000. Furthermore, assume the following cases for the quiescent distribution. | ||
:• Case 1: The quiescent distribution is the same as the active distribution (hot standby).<br> | :• Case 1: The quiescent distribution is the same as the active distribution (hot standby).<br> | ||
:• Case 2: The quiescent distribution is a Weibull distribution with <math>\beta </math> = 1.5 and <math>\eta </math> = 2000 (warm standby).<br> | :• Case 2: The quiescent distribution is a Weibull distribution with <math>\beta </math> = 1.5 and <math>\eta </math> = 2000 (warm standby).<br> | ||
:• Case 3: The component cannot fail in quiescent mode (cold standby).<br> | :• Case 3: The component cannot fail in quiescent mode (cold standby).<br> | ||
In this case, the reliability of the system at some time, <math>t</math> , can be obtained using the following equation: | In this case, the reliability of the system at some time, <math>t</math> , can be obtained using the following equation: | ||
Line 686: | Line 686: | ||
where: | where: | ||
:• <math>{{R}_{1}}</math> is the reliability of the active component.<br> | :• <math>{{R}_{1}}</math> is the reliability of the active component.<br> | ||
:• <math>{{f}_{1}}</math> is the <math>pdf</math> of the active component.<br> | :• <math>{{f}_{1}}</math> is the <math>pdf</math> of the active component.<br> | ||
Line 693: | Line 693: | ||
:• <math>{{t}_{e}}</math> is the equivalent operating time for the standby unit if it had been operating at an active mode, such that: <br> | :• <math>{{t}_{e}}</math> is the equivalent operating time for the standby unit if it had been operating at an active mode, such that: <br> | ||
<math>{{R}_{2;SB}}(x)={{R}_{2;A}}({{t}_{e}})</math><br> | <math>{{R}_{2;SB}}(x)={{R}_{2;A}}({{t}_{e}})</math><br> | ||
The second equation above can be solved for <math>{{t}_{e}}</math> and substituted into the first equation above. | The second equation above can be solved for <math>{{t}_{e}}</math> and substituted into the first equation above. | ||
The following figure illustrates the example as entered in BlockSim using a standby container. | The following figure illustrates the example as entered in BlockSim using a standby container. | ||
[[Image:5.24.png|center|150px|<div align="center"> Standby container.</div>]] | [[Image:5.24.png|center|150px|<div align="center"> Standby container.</div>]] | ||
The active and standby blocks are within a container, which is used to specify standby redundancy. Since the standby component has two distributions (active and quiescent), the Block Properties window of the standby block has two pages for specifying each one. The following figures illustrate these pages. | The active and standby blocks are within a container, which is used to specify standby redundancy. Since the standby component has two distributions (active and quiescent), the Block Properties window of the standby block has two pages for specifying each one. The following figures illustrate these pages. | ||
Line 707: | Line 705: | ||
[[Image:Fig 5.26.PNG|thumb|center|500px|<div align="center"> Defining the quiescent failure distribution </div>]] | [[Image:Fig 5.26.PNG|thumb|center|500px|<div align="center"> Defining the quiescent failure distribution </div>]] | ||
<br> | <br> | ||
The system reliability results for 1000 hours are given in the following table: | The system reliability results for 1000 hours are given in the following table: | ||
[[Image:5-24.png|center|200px|]] | [[Image:5-24.png|center|200px|]] | ||
Note that even though the <math>\beta </math> value for the quiescent distribution is the same as in the active distribution, it is possible that the two can be different. That is, the failure modes present during the quiescent mode could be different from the modes present during the active mode. In that sense, the two distribution types can be different as well (e.g., lognormal when quiescent and Weibull when active). | Note that even though the <math>\beta </math> value for the quiescent distribution is the same as in the active distribution, it is possible that the two can be different. That is, the failure modes present during the quiescent mode could be different from the modes present during the active mode. In that sense, the two distribution types can be different as well (e.g., lognormal when quiescent and Weibull when active). | ||
In many cases when considering standby systems, a switching device may also be present that switches from the failed active component to the standby component. The reliability of the switch can also be incorporated into | In many cases when considering standby systems, a switching device may also be present that switches from the failed active component to the standby component. The reliability of the switch can also be incorporated into |
Revision as of 06:23, 6 August 2012
In the previous chapter, different system configuration types were examined, as well as different methods for obtaining the system's reliability function analytically. Because the reliabilities in the problems presented were treated as probabilities (e.g.,
Analytical Life Predictions
The analytical approach presented in the prior chapter involved the determination of a mathematical expression that describes the reliability of the system, expressed in terms of the reliabilities of its components. So far we have estimated only static system reliability (at a fixed time). For example, in the case of a system with three components in series, the system's reliability equation was given by:
The values of
The reliability of the system for any mission time can now be estimated. Assuming a Weibull life distribution for each component, the first equation above can now be expressed in terms of each component's reliability function, or:
In the same manner, any life distribution can be substituted into the system reliability equation. Suppose that the times-to-failure of the first component are described with a Weibull distribution, the times-to-failure of the second component with an exponential distribution and the times-to-failure of the third component with a normal distribution. Then the first equation above can be written as:
It can be seen that the biggest challenge is in obtaining the system's reliability function in terms of component reliabilities, which has already been discussed in depth. Once this has been achieved, calculating the reliability of the system for any mission duration is just a matter of substituting the corresponding component reliability functions into the system reliability equation.
Advantages of the Analytical Method
The primary advantage of the analytical solution is that it produces a mathematical expression that describes the reliability of the system. Once the system's reliability function has been determined, other calculations can then be performed to obtain metrics of interest for the system. Such calculations include:
- • Determination of the system's
- • Determination of warranty periods.
- • Determination of the system's failure rate.
- • Determination of the system's MTTF.
In addition, optimization and reliability allocation techniques can be used to aid engineers in their design improvement efforts. Another advantage in using analytical techniques is the ability to perform static calculations and analyze systems with a mixture of static and time-dependent components. Finally, the reliability importance of components over time can be calculated with this methodology.
Disadvantages of the Analytical Method
The biggest disadvantage of the analytical method is that formulations can become very complicated. The more complicated a system is, the larger and more difficult it will be to analytically formulate an expression for the system's reliability. For particularly detailed systems this process can be quite time-consuming, even with the use of computers. Furthermore, when the maintainability of the system or some of its components must be taken into consideration, analytical solutions become intractable. In these situations, the use of simulation methods may be more advantageous than attempting to develop a solution analytically. Simulation methods are presented in later chapters.
Looking at a Simple Complex System Analytically
The complexity involved in an analytical solution can be best illustrated by looking at the simple complex system with 15 components, as shown below.
The system reliability for this system (computed using BlockSim) is shown next. The first solution is provided using BlockSim's symbolic solution. In symbolic mode, BlockSim breaks the equation into segments, identified by tokens, that need to be substituted into the final system equation for a complete solution. This creates algebraic solutions that are more compact than if the substitutions were made.
Substituting the terms yields:
BlockSim's automatic algebraic simplification would yield the following format for the above solution:
In this equation, each
Obtaining Other Functions of Interest
Once the system reliability equation (or the cumulative density function,
Consider the following simple system:
Furthermore, assume that component 1 follows an exponential distribution with a mean of 10,000 (
The system
System
Once the equation for the reliability of the system has been obtained, the system's
For the system shown above, this is:
The next figure shows a plot of the pdf equation.
Conditional Reliability
Conditional reliability is the probability of a system successfully completing another mission following the successful completion of a previous mission. The time of the previous mission and the time for the mission to be undertaken must be taken into account for conditional reliability calculations. The system's conditional reliability function is given by:
Equation above gives the reliability for a new mission of duration
For the simple two-component system, the reliability for mission of
Conditional Reliability for Components
Now in this formulation, it was assumed that the accumulated age was equivalent for both units. That is, both started life at zero and aged to 500. It is possible to consider an individual component that has already accumulated some age (used component) in the same formulation. To illustrate this, assume that component 2 started life with an age of T=100. Then the reliability equation of the system, as given in
In BlockSim, the start age input box may be used to specify a starting age greater than zero.
System Failure Rate
Once the distribution of the system has been determined, the failure rate can also be obtained by dividing the
For the simple two-component system:
The following figure shows a plot of the equation.
BlockSim uses numerical methods to estimate the failure rate. It should be pointed out that as
System Mean Life (Mean Time To Failure)
The mean life (or mean time to failure, MTTF) can be obtained by integrating the system reliability function from zero to infinity:
The mean time is a performance index and does not provide any information about the behavior of the failure distribution of the system.
For the simple two-component system:
Warranty Period and BX Life
Sometimes it is desirable to know the time value associated with a certain reliability. Warranty periods are often calculated by determining what percentage of the failure population can be covered financially and estimating the time at which this portion of the population will fail. Similarly, engineering specifications may call for a certain BX life, which also represents a time period during which a certain proportion of the population will fail. For example, the B10 life is the time in which 10% of the population will fail.
This is obtained by setting
For the simple two-component system:
To compute the time by which reliability would be equal to 90%, equation above is recast as follows and solved for
In this case,
Example 1
Consider a system consisting of three exponential units in series with the following failure rates (in failures per hour):
- • Obtain the reliability equation for the system.
- • What is the reliability of the system after 150 hours of operation?
- • Obtain the system's
- • Obtain the system's failure rate equation.
- • What is the MTTF for the system?
- • What should the warranty period be for a 90% reliability?
Solution
The analytical expression for the reliability of the system is given by:
At 150 hours of operation, the reliability of the system is:
In order to obtain the system's
The system's failure rate can now be obtained simply by dividing the system's
Combining
Solving the first equation above with respect to time will yield the corresponding warranty period for a 90% reliability. In this case, the system reliability equation is simple and a closed form solution exists. The warranty time can now be found by solving:
Thus, the warranty period should be 132 hours.
Example 2
Consider the system shown next.
Components
Determine the following:
- • The reliability equation for the system and its corresponding plot.
- • The system's
and its corresponding plot. - • The system's failure rate equation and the corresponding plot.
- • The
. - • The warranty time for a 90% reliability.
- • The reliability for a 200-hour mission, if it is known that the system has already successfully operated for 200 hours.
Solution
The first step is to obtain the reliability function for the system. The methods described in the previous chapter can be employed, such as the event space or path-tracing methods. Using BlockSim, the following reliability equation is obtained:
Note that since the starting and ending blocks cannot fail,
where
is the reliability equation for Component , etc.
Since the components in this example are identical, the system reliability equation can be further reduced to:
Or, in terms of the failure distribution:
The corresponding plot is given in the following figure.
In order to obtain the system's
The
The system's failure rate can now be obtained by dividing the system's
The corresponding plot is given below.
The
The warranty time can be obtained by solving
Lastly, the conditional reliability can be obtained using
This can be calculated using BlockSim's Analytical QCP, as shown below.
Approximating the System CDF
In many cases, it is valuable to fit a distribution that represents the system's times-to-failure. This can be useful when the system is part of a larger assembly and may be used for repeated calculations or in calculations for other systems. In cases such as this, it can be useful to characterize the system's behavior by fitting a distribution to the overall system and calculating parameters for this distribution. This is equivalent to fitting a single distribution to describe
For the system shown below:
To compute an approximate reliability function for this system,
A single distribution,
Example 3
Compute a single Weibull distribution approximation for the system in Example 2.
Solution
The system in the previous example, shown below, can be approximated by use of a 2-parameter Weibull distribution with
In BlockSim, this is accomplished by representing the entire system as one distribution by going to the Distribution fit area, as shown next.
As shown next, clicking inside the Distribution fit area opens the Distribution Estimator window. In this window you can select a distribution to represent the data. BlockSim will then generate a number of system failure times based on the system's reliability function. The system's reliability function can be used to solve for a time value associated with that unreliability value. The distribution of the generated time values can then be fitted to a probability distribution function.
Consider a value of
For the system of Example 2, the time for a 0.11 unreliability is 389.786 hours.
When enough points have been generated, the selected distribution will be fitted to this data set and the distribution's parameters will be returned. In addition, if ReliaSoft's Weibull++ is installed, the generated data can be viewed/analyzed using a Weibull++ instance, as shown in the next figure.
It is recommended that the analyst examine the fit to ascertain the applicability of the approximation.
Duty Cycle
Components of a system may not operate continuously during a system's mission, or may be subjected to loads greater or lesser than the rated loads during system operation. To model this, a factor called the Duty Cycle (
The reliability metrics for a component with a duty cycle are calculated as follows. Let
The reliability equation for the component is:
The component pdf is:
The failure rate of the component is:
Example 4
Consider a computer system with three components: a processor, a hard drive and a CD drive in series as shown next. Assume that all three components follow a Weibull failure distribution with the parameters
Solution
The reliability of the processor after 365 days of operation is given by:
The reliability of the hard drive after 365 days of operation is given by:
The reliability of the CD drive after 365 days of operation (taking into account the 30% operation using a duty cycle of 0.3) is given by:
Thus the reliability of the computer system after 365 days of operation is:
As shown in the following figure, this result can be obtained in BlockSim.
Load Sharing
As presented in earlier chapters, a reliability block diagram (RBD) allows you to graphically represent how the components within a system are reliability-wise connected. In most cases, independence is assumed across the components within the system. For example, the failure of component A does not affect the failure of component B. However, if a system consists of components that are sharing a load, then the assumption of independence no longer holds true.
If one component fails, then the component(s) that are still operating will have to assume the failed unit's portion of the load. Therefore, the reliabilities of the surviving unit(s) will change. Calculating the system reliability is no longer an easy proposition. In the case of load sharing components, the change of the failure distributions of the surviving components must be known in order to determine the system's reliability.
To illustrate this, consider a system of two units connected reliability-wise in parallel as shown below.
Assume that the units must supply an output of 8 volts and that if both units are operational, each unit is to supply 50% of the total output. If one of the units fails, then the surviving unit supplies 100%. Furthermore, assume that having to supply the entire load has a negative impact on the reliability characteristics of the surviving unit. Since the reliability characteristics of the unit change based on whether both or only one is operating, a life distribution along with a life-stress relationship (as discussed in A Brief Introduction to Life-Stress Relationships) will be needed to model each component.
To illustrate the steps needed, we will create the model starting from raw data. Assume that a total of 20 units were tested to failure at 7, 10 and 15 volts. The test data set is presented in the next table.
For this example, Units 1 and 2 are the same component. Therefore, only one set of data was collected. However, it is possible that the load sharing components in a system may not be the same. If that were the case, data would need to be collected for each component.
The data set in Table 1 was analyzed using ReliaSoft's ALTA software (as shown in the figure below) with the Inverse Power Law as the underlying life-stress relationship and Weibull as the life distribution.
The estimated model parameters,
Or:
.
And for this case:
The figure below shows a plot of
Now that the failure properties have been determined using the test data, the reliability of the system at some time,
where:
And:
- •
is the total load (or required output). - •
and are the portion of the total load that each unit supports when both units are operational. In this case, - •
and represent the portions of the load that Unit 1 and Unit 2 must support when both units are operational. - •
is the equivalent operating time for Unit 1 if it had been operating at instead of . A graphical representation of the equivalent time is shown in the following figure, where the curve marked by L represents the low stress (load) and the curve marked by H represents the high stress (load).
can be calculated by:
can be calculated the same way, or:
In this example, the reliability equations for Unit 1 and Unit 2 are the same since they are the same type of component and demonstrate the same failure properties. In addition, the total output is divided equally between the two units (when both units are operating), so
The next step is to determine the reliability of the system after 8,760 hours,
the system reliability is found to be:
Load Sharing in BlockSim
BlockSim uses this formulation when computing reliabilities of units in a load sharing configuration. When using the System Reliability Equation window, BlockSim returns a single token for the reliability of units in a load sharing configuration (as well as in the case of standby redundancy, discussed in the next section). As an example, consider the following RBD with Unit 1 in series with a container that includes two load sharing units.
BlockSim will return the system equation as:
where
BlockSim allows for
Example 5
A component has five possible failure modes,
Modes
If any
Solution
The first step is to create the RBD. Modes
The next step is to define the properties for each block, including those for the container. Based on the problem statement, the
The next step is to set the weight proportionality factor. This factor defines the portion of the load that the particular item carries while operating, as well as the load that shifts to the remaining units upon failure of the item. To illustrate, assume three units (1, 2 and 3) are in a load sharing container with weight proportionality factors of 1, 2 and 3 respectively (and a 1-out-of-3 requirement).
- • Unit 1 carries
or 16.6% of the total load. - • Unit 2 carries
or 33.3% of the total load. - • Unit 3 carries
or 50% of the total load.
The actual load on each unit then becomes the product of the entire load defined for the container times the portion carried by that unit. For example, if the container load is 100 lbs, then the portion assigned to Unit 1 will be
In the current example, all units share the same load and thus have equal weight proportionality factors. Because these factors are relative, if the same number is used for all three items then the results will be the same. Thus, weight proportional factor is set equal to 1 for each item.
The last properties that need to be defined are the total load and the 2-out-of-3 redundancy. The total load is dependent on how the parameters were computed. In this case, total load was assumed to be 3 when the parameters were computed (i.e., the load per item was 1 when all worked and 1.5 when two worked). As shown in the figure below, this is defined at the container level. When all of the parameters have been specified in BlockSim, the reliability at 1,000 hours can be determined. From the Analytical QCP, this is found to be 98.1048%.
Standby Components
In the previous section, the case of a system with load sharing components was presented. This is a form of redundancy with dependent components. That is, the failure of one component affects the failure of the other(s). This section presents another form of redundancy: standby redundancy. In standby redundancy the redundant components are set to be under a lighter load condition (or no load) while not needed and under the operating load when they are activated.
In standby redundancy the components are set to have two states: an active state and a standby state. Components in standby redundancy have two failure distributions, one for each state. When in the standby state, they have a quiescent (or dormant) failure distribution and when operating, they have an active failure distribution.
In the case that both quiescent and active failure distributions are the same, the units are in a simple parallel configuration (also called a hot standby configuration). When the rate of failure of the standby component is lower in quiescent mode than in active mode, that is called a warm standby configuration. When the rate of failure of the standby component is zero in quiescent mode (i.e., the component cannot fail when in standby), that is called a cold standby configuration.
Simple Standby Configuration
Consider two components in a standby configuration. Component 1 is the active component with a Weibull failure distribution with parameters
- • Case 1: The quiescent distribution is the same as the active distribution (hot standby).
- • Case 2: The quiescent distribution is a Weibull distribution with
= 1.5 and = 2000 (warm standby). - • Case 3: The component cannot fail in quiescent mode (cold standby).
In this case, the reliability of the system at some time,
where:
- •
is the reliability of the active component. - •
is the of the active component. - •
is the reliability of the standby component when in standby mode (quiescent reliability). - •
is the reliability of the standby component when in active mode. - •
is the equivalent operating time for the standby unit if it had been operating at an active mode, such that:
The second equation above can be solved for
The active and standby blocks are within a container, which is used to specify standby redundancy. Since the standby component has two distributions (active and quiescent), the Block Properties window of the standby block has two pages for specifying each one. The following figures illustrate these pages.
The system reliability results for 1000 hours are given in the following table:
Note that even though the
In many cases when considering standby systems, a switching device may also be present that switches from the failed active component to the standby component. The reliability of the switch can also be incorporated into
as presented in the next section.
BlockSim's System Reliability Equation window returns a single token for the reliability of units in a standby configuration. This is the same as the load sharing case presented in the previous section.
Reliability of Standby Systems with a Switching Device
In many cases when dealing with standby systems, a switching device is present that will switch to the standby component when the active component fails. Therefore, the failure properties of the switch must also be included in the analysis.
In most cases when the reliability of a switch is to be included in the analysis, two probabilities can be considered. The first and most common one is the probability of the switch performing the action (i.e., switching) when requested to do so. This is called Switch Probability per Request in BlockSim and is expressed as a static probability (e.g., 90%). The second probability is the quiescent reliability of the switch. This is the reliability of the switch as it ages (e.g., the switch might wear out with age due to corrosion, material degradation, etc.). Thus it is possible for the switch to fail before the active component fails. However, a switch failure does not cause the system to fail, but rather causes the system to fail only if the switch is needed and the switch has failed. For example, if the active component does not fail until the mission end time and the switch fails, then the system does not fail. However, if the active component fails and the switch has also failed, then the system cannot be switched to the standby component and it therefore fails.
In analyzing standby components with a switching device, either or both failure probabilities (during the switching or while waiting to switch) can be considered for the switch, since each probability can represent different failure modes. For example, the switch probability per request may represent software-related issues or the probability of detecting the failure of an active component, and the quiescent probability may represent wear-out type failures of the switch.
To illustrate the formulation, consider the previous example that assumes perfect switching. To examine the effects of including an imperfect switch, assume that when the active component fails there is a 90% probability that the switch will switch from the active component to the standby component. In addition, assume that the switch can also fail due to a wear-out failure mode described by a Weibull distribution with
Therefore, the reliability of the system at some time,
where:
- •
is the reliability of the active component. - •
is the of the active component. - •
is the reliability of the standby component when in standby mode (quiescent reliability). - •
is the reliability of the standby component when in active mode. - •
is the quiescent reliability of the switch. - •
is the switch probability per request. - •
is the equivalent operating time for the standby unit if it had been operating at an active mode.
This problem can be solved in BlockSim by including these probabilities in the container's properties, as shown in the figures below. In BlockSim, the standby container is acting as the switch.
Note that there are additional properties that can be specified in BlockSim for a switch, such as Switch Restart Probability, No. of Restarts and Switch Delay Time. In many applications, the switch is re-tested (or re-cycled) if it fails to switch the first time. In these cases, it might be possible that it switches in the second or third, or
The Switch Restart Probability specifies each additional attempt's probability of successfully switching and the Finite Restarts specifies the total number of attempts. Note that the Switch Restart Probability specifies the probability of success of each trial (or attempt). The probability of success of
Solving the analytical solution (as given by the above equation), the following results are obtained.
From the table above, it can be seen that the presence of a switching device has a significant effect on the reliability of a standby system. It is therefore important when modeling standby redundancy to incorporate the switching device reliability properties. It should be noted that this methodology is not the same as treating the switching device as another series component with the standby subsystem. This would be valid only if the failure of the switch resulted in the failure of system (e.g., switch failing open). In equation above, the Switch Probability per Request and quiescent probability are present only in the second term of the equation. Treating these two failure modes as a series configuration with the standby subsystem would imply that they are also present when the active component is functioning (i.e., first term of equation above). This is invalid and would result in the underestimation of the reliability of the system. In other words, these two failure modes become significant only when the active component fails.
As an example, and if we consider the warm standby case, the reliability of the system without the switch is 70.57% at 1000 hours. If the system was modeled so that the switching device was in series with the warm standby subsystem, the result would have been:
In the case where a switch failure mode causes the standby subsystem to fail, then this mode can be modeled as an individual block in series with the standby subsystem.
Example 6
Consider a car with four new tires and a full-size spare. Assume the following failure characteristics:
- • The tires follow a Weibull distribution with a
and an 40,000 miles while on the car due to wear. - • The tires also have a probability of failing due to puncture or other causes. For this, assume a constant rate for this occurrence with a probability of 1 every 50,000 miles.
- • When not on the car (i.e., is a spare), a tire's probability of failing also has a Weibull distribution with a
2 and 120,000 miles.
Assume a mission of 1,000 miles. If a tire fails during this trip, it will be replaced with the spare. However, the spare will not be repaired during the trip. In other words, the trip will continue with the spare on the car and if the spare fails the system will fail. Determine the probability of system failure.
Solution
Active failure distribution for tires:
- • Due to wear-out, Weibull
and miles. - • Due to random puncture, exponential
- • The quiescent failure distribution is a Weibull distribution with
and miles.
The block diagram for each tire has two blocks in series, one block representing the wear-out mode and the other the random puncture mode, as shown next:
There are five tires, four active and one standby (represented in the diagram by a standby container with a 4-out-of-5 requirement), as shown next:
For the standby Wear block, set the active failure and the quiescent distributions, but for the Puncture block, set only the active puncture distribution (because the tire cannot fail due to puncture while stored). Using BlockSim, the probability of system failure is found to be 0.003 or 0.3%.
Note Regarding Numerical Integration Solutions
Load sharing and standby solutions in BlockSim are performed using numerical integration routines. As with any numerical analysis routine, the solution error depends on the number of iterations performed, the step size chosen and related factors, plus the behavior of the underlying function. By default, BlockSim uses a certain set of preset factors. In general, these defaults are sufficient for most problems. If a higher precision or verification of the precision for a specific problem is required, BlockSim's preset options can be modified and/or the integration error can be assessed using the Integration Parameters... option for each container. For more details, you can refer to the documentation on the Algorithm Setup window in the BlockSim 8 User's help files.