ReliaWiki - User contributions [en]

Crow Extended

2020-08-19T23:08:57Z

David J. Groebel: /* Mathematical Formulation */

{{template:RGA BOOK|3.3|Crow Extended}}
In reliability growth analysis, the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP) model]] assumes that the corrective actions for the observed failure modes are incorporated during the test (test-fix-test). However, in actual practice, fixes may be delayed until after the completion of the test (test-find-test) or some fixes may be implemented during the test while others are delayed (test-fix-find-test). At the end of a test phase, two reliability estimates are of concern: ''demonstrated reliability'' and ''projected reliability''. The demonstrated reliability, which is based on data generated during the test phase, is an estimate of the system reliability for its configuration at the end of the test phase. The projected reliability measures the impact of the delayed fixes at the end of the current test phase.
<br>

Most of the reliability growth literature are concerned with procedures and models for calculating the demonstrated reliability, and very little attention has been paid to techniques for reliability projections. The procedure for making reliability projections utilizes engineering assessments of the effectiveness of the delayed fixes for each observed failure mode. These effectiveness factors are then used with the data generated during the test phase to obtain a projected estimate for the updated configuration by adjusting the number of failures observed during the test phase. The process of estimating the projected reliability is accomplished using the Crow Extended model. The Crow Extended model allows for a flexible growth strategy that can include corrective actions performed during the test, as well as delayed corrective actions. The test-find-test and test-fix-find-test scenarios are simply subsets of the Crow Extended model.

For developmental testing, the Crow Extended model can be applied when using any of the following [[RGA_Data_Types|data types]]:

*Failure Times Data
*Multiple Systems (Known Operating Times)
*Multiple Systems (Concurrent Operating Times)
*Multiple Systems with Dates
*Multiple Systems with Event Codes
*Grouped Failure Times
*Mixed Data

As the name implies, Crow Extended is simply an "extension" of the Crow-AMSAA (NHPP) model. The calculations for Crow Extended still incorporate the methods for Crow-AMSAA based on the data type, as described on the [[Crow-AMSAA (NHPP)]] page. The Crow-AMSAA model estimates the growth during the test, while the Crow Extended model accounts for the growth after the test based on the delayed corrective actions. Additional details regarding the calculations for the Crow Extended model are presented in the sections below.

==Background==
When a system is tested and failure modes are observed, management can make one of two possible decisions: to fix or to not fix the failure modes. Failure modes that are not fixed are called ''A modes'' and failure modes that receive a corrective action are called ''B modes''. The A modes account for all failure modes that management considers to be not economical or not justified to receive corrective action. The B modes provide the assessment and management metric structure for corrective actions during and after a test. There are two types of B modes: BC modes, which are corrected during the test, and BD modes, which are corrected only at the end of the test. The management strategy is defined by how the corrective actions, if any, will be implemented. In summary, the classifications are defined as follows:

*'''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. BD modes will provide a jump in the system's MTBF at the termination time.

In terms of assessing a system's reliability, there are three specific metrics of interest:

*'''Demonstrated (or achieved) MTBF (DMTBF)''' is the system's instantaneous MTBF at the termination time.
*'''Projected MTBF (PMTBF)''' is the system's expected instantaneous MTBF after the implementation of the delayed corrective actions.
*'''Growth Potential MTBF (GPMTBF)''' is the maximum MTBF that can be attained for the system design and management strategy.

These metrics can also be displayed in RGA in terms of failure intensity (FI). The demonstrated MTBF is calculated using basically the same methods, depending on data type, as presented on the [[Crow-AMSAA (NHPP)]] page. Projected MTBF/FI and growth potential MTBF/FI are presented in detail in the sections below.

The following picture shows an example of data entered for the Crow Extended model.

[[Image:rga9.1.png|center|500px|Failure times data for a single system in cumulative format, including classification and mode information.]]

As you can see, each failure is indicated with A, BC or BD in the '''Classification''' column. In addition, any number or text can be used to specify the failure mode. In this example, numbers were used in the '''Mode''' column for simplicity, but you could just as easily use "Seal Leak," or whatever designation you deem appropriate for identifying the mode. In RGA, a failure mode is defined as a problem and a cause.

Reliability growth is achieved by decreasing the failure intensity. The failure intensity for the A failure modes will not change; therefore, reliability growth can only be achieved by decreasing the BC and BD mode failure intensity. In general, the only part of the BD mode failure intensity that can be decreased is that which has been seen during testing, since the failure intensity due to BD modes that were unseen during testing still remains. The BC failure modes are corrected during test, and the BC failure intensity will not change any more at the end of test.

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

:<math>Multiplier=\frac{1}{1-EF}</math>

Using this equation, an <math>EF=0.7\,\!</math> corresponds to an increase of 3.3X. Therefore, if a failure mode had an MTBF of 100 and a delayed fix was applied, an estimate of the failure mode's MTBF after the fix is equal to <math>\approx 333\,\!</math>. An <math>EF=0.9\,\!</math> corresponds to a 10X increase in the failure mode's MTBF. So there is a large increase between EF = 0.7 and EF = 0.9. Before assigning an EF to a BD mode, it is recommended to run a test to verify the fix and to validate the assumed EF value. Ideally, you want to have some sort of justification for using the entered EF value. If you do not know the EF value for each BD mode, then you can also specify a fixed EF which is then applied to all modes. The average value of EF = 0.7 is a good place to start, but if you want to be a bit more conservative, then an EF = 0.4, or a smaller value, could be used.

==Test-Find-Test==
Test-find-test is a testing strategy where all corrective actions are delayed until after the test. Therefore, there are not any BC modes when analyzing test-find-test data (only A and BD modes). This scenario is also called the ''Crow-AMSAA Projection'' model, but for the purposes of the RGA software, it is simply a special case of the Crow Extended model. The picture below presents the test-find-test scenario.

[[File:TestFindTest.png|center|400px|Test-find-test.]]

Since there are no fixes applied during the test, the assumption is that the system's MTBF does not change during the test. In other words, the system's MTBF is constant. The system should not be exhibiting an increasing or decreasing trend in its reliability if changes are not being made. Therefore, the assumption is that <math>\beta = 1\,\!</math>. RGA will return two <math>\beta\,\!</math> values; Beta (hyp) which always shows a value equal to 1 since this is the underlying assumption, and Beta which is the Crow-AMSAA (NHPP) estimate that considers all of the failure times. The assumption of <math>\beta = 1\,\!</math> can be verified by looking at the confidence bounds on <math>\beta\,\!</math>. If the confidence bounds on <math>\beta\,\!</math> include one, then you can fail to reject the hypothesis that <math>\beta = 1\,\!</math>. RGA does this check automatically and uses a confidence level equal to 1 minus the specified significance level to check if the confidence bounds on <math>\beta\,\!</math> include one. If the <math>\beta = 1\,\!</math> assumption is violated, then the value for Beta (hyp) will be displayed in red text. If the confidence bounds on <math>\beta\,\!</math> do not include 1, then the following questions should be considered as they relate to the data:

*If multiple systems were tested, did they have the same configuration throughout the test? Were the corrective actions applied to all systems?
*Were the test conditions consistent for each system?
*Was there a change in the failure definition?
*Any issues with data entry?

<math>\beta = 1\,\!</math> is then used to estimate the demonstrated MTBF of the system and it is also used in the goodness-of-fit tests.

===Projected Failure Intensity===
Suppose a system is subjected to development testing for a period of time, <math>T\,\!</math>. The system can be considered as consisting of two types of failure modes: A modes and BD modes. It is assumed that all BD modes are in series and fail independently according to the exponential distribution. Also assume that the rate of occurrence of A modes follows an exponential distribution with failure intensity <math>{{\lambda }_{A}}\,\!</math>. The system MTBF is constant throughout the test phase since all of the corrective actions are delayed until after the completion of the test. After the delayed fixes have been implemented, the system MTBF will then jump to a higher value.

Let <math>K\,\!</math> denote the total number of BD modes in the system, and let <math>{{\lambda }_{i}}\,\!</math> denote the failure intensity for the <math>{{i}^{th}}\,\!</math> BD mode, such that <math>i = 1,2,\ldots ,K\,\!</math>. Then, at time equal to zero, the system failure intensity <math>r(0)\,\!</math> is:

:<math>\begin{align}
r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}
\end{align}\,\!</math>

where:

:<math>{{\lambda }_{BD}}=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{\lambda }_{i}}\,\!</math>.

During the test <math>(0,T)\,\!</math>, a random number of <math>M\,\!</math> distinct BD modes will be observed, such that <math>M\le K\,\!</math>. Denote the effectiveness factor (EF) for the <math>{{i}^{th}}\,\!</math> BD mode as <math>{{d}_{i}}\,\!</math>, <math>i = 1,2,\ldots ,K\,\!</math>. The effectiveness factor <math>{{d}_{i}}\,\!</math> is the percent decrease in <math>{{\lambda }_{i}}\,\!</math> after a corrective action has been made for the <math>{{i}^{th}}\,\!</math> BD mode. That is, the corrective action for the <math>{{i}^{th}}\,\!</math> BD mode removes <math>100\times {{d}_{i}}\,\!</math> percent of the failure rate, and <math>100\times (1-{{d}_{i}})\,\!</math> percent remains. The failure intensity for the <math>{{i}^{th}}\,\!</math> BD failure mode after a corrective action is <math>(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>. If corrective actions are taken on the <math>M\,\!</math> BD modes observed by time <math>T\,\!</math>, then the system failure intensity is reduced from <math>r(0)\,\!</math> to:

:<math>\begin{align}
r\left( T \right) = & {{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,\left( 1-{{d}_{i}} \right){{\lambda }_{i}}+({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{\lambda }_{i}}) \\
= & {{\lambda }_{A}}+{{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}
\end{align}\,\!</math>

where:

*<math>\underset{i=1}{\overset{M}{\mathop{\sum }}}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math> is the failure intensity for the <math>M\,\!</math> modes after the corrective actions
*<math>({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop{\sum }}}\,{{\lambda }_{i}})\,\!</math> is the remaining failure intensity for all unseen BD modes

All <math>M\,\!</math> BD modes observed by test time <math>T\,\!</math> may not be fixed by time <math>T\,\!</math> so the actual failure intensity at time <math>T\,\!</math> may not be <math>r(T)\,\!</math>. However, <math>r(T)\,\!</math> can be viewed as the achieved failure intensity at time <math>T\,\!</math> if all fixes were updated and incorporated into the system. All of the fixes for the BD modes found during the test are incorporated as delayed fixes at the end of the test phase. Therefore, the system failure intensity is constant at <math>r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}\,\!</math> through the test phase and will then jump to a lower value <math>r(T)\,\!</math> after the delayed fixes have been implemented. Let <math>{{N}_{A}}\,\!</math> and <math>{{N}_{BD}}\,\!</math> be the total number of A and BD failures observed during the test <math>(0,T)\,\!</math> and let <math>N={{N}_{A}}+{{N}_{BD}}\,\!</math>. In addition, there are <math>M\,\!</math> distinct BD modes observed during the test. After implementing the <math>M\,\!</math> fixes, the failure intensity for the system at time <math>T\,\!</math> (after the jump) is given by the function <math>r(T)\,\!</math>.

<math>r(0)\,\!</math> is actually the demonstrated failure intensity, which is based on actual system performance of the hardware tested and not of some future configuration. A demonstrated reliability value should be determined at the end of each test phase. The demonstrated failure intensity is:

:<math>{{\hat{\lambda }}_{D}}(T)=r(0)=\frac{{{N}_{A}}+{{N}_{BD}}}{T}\,\!</math>

The demonstrated MTBF is given by:

:<math>\widehat{{MTBF}_{D}}={{[{{\hat{\lambda }}_{D}}(T)]}^{-1}}\,\!</math>

The detailed procedure for estimating <math>r(T)\,\!</math> is given in Crow [[RGA_References|[20]]] and is reviewed here.

Let <math>E[\cdot ]\,\!</math> denote the expected value:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}{{e}^{-{{\lambda }_{i}}T}}\,\!</math>

Under realistic assumptions, <math>E[r(T)]\,\!</math> also may be expressed as:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T)\,\!</math>

where <math>\overline{d}\,\!</math> is the mean effectiveness factor and <math>h(T)\,\!</math> is the instantaneous rate at which a new BD mode will occur at time <math>T\,\!</math>. <math>\overline{d}h(T)\,\!</math> is the bias term (or sometimes called the 3<sup>rd</sup> term), such that:

:<math>B(T)=\overline{d}h(T)\,\!</math>

The mean <math>\overline{d}\,\!</math> is given by:

:<math>\overline{d}=\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\,\!</math>

Therefore, the projected failure intensity <math>r(T)\,\!</math> is then estimated at the end of the test phase by:

:<math>\hat{r}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)+\overline{d}h(T)\,\!</math>

The projected MTBF is:

:<math>\widehat{{MTBF}_{P}}={{[r(T)]}^{-1}}\,\!</math>

===Mathematical Formulation===
As indicated previously, the failure intensity of the system at <math>t=0\,\!</math> is given by:

:<math>\begin{align}
{{\lambda }_{System}}= & {{\lambda }_{A}}+{{\lambda }_{BD}} \\
= & {{\lambda }_{A}}+{{\lambda }_{B{{D}_{Seen}}}}+{{\lambda }_{B{{D}_{Unseen}}}}
\end{align}\,\!</math>

The estimate for the projected failure intensity, after the corrective actions have been implemented, is then:

:<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 }_{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}}+dh\left( t \right)
\end{align}\,\!</math>

This is the basic format of the equation for the projected failure intensity when the Crow Extended model is used with the test-find-test strategy.

===h(t) Function===
h(t) is defined as the unseen BD mode failure intensity. It is also defined as the rate at which new unique BD modes are being discovered. The maximum likelihood estimate of <math>h(t)\,\!</math> is calculated using:

:<math>\hat{h}\left( t \right)={{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{t}^{{{{\overline{\beta }}}_{BD}}-1}}\,\!</math>

where <math>{\overline{\beta }_{BD}}\,\!</math> is the unbiased estimate. The unbiased estimate is always used when calculating <math>\hat{h}\left( t \right)\,\!</math>.

The parameters of the <math>h(t)\,\!</math> function, <math>{{\beta }_{BD}}\,\!</math> and <math>{{\lambda }_{BD}}\,\!</math>, are calculated using the first occurrence of each BD mode. In order to have growth, <math>{{\beta }_{BD}}\,\!</math> must be less than one. If <math>{{\beta }_{BD}}\,\!</math> is close to one then it is possible that the program could be in trouble since this indicates that there are very few repeat occurrences. In this case, each failure tends to be a unique mode. If <math>{{\beta }_{BD}}\,\!</math> is less than one then the rate at which new unique BD modes are occurring is decreasing.

Let <math>{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{M}}<T\,\!</math> denote the cumulative test times for the first occurrences of BD modes. Then, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are:

:<math>{{\hat{\beta }}_{BD}}=\frac{M}{\underset{i=1}{\overset{M}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

The unbiased estimate of <math>{{\beta }_{BD}}\,\!</math> is:

:<math>{{\bar{\beta }}_{BD}}=\frac{M-1}{M}{{\hat{\beta }}_{BD}}\,\!</math>

:<math>{{\hat{\lambda }}_{BD}}=\frac{M}{{{T}^{{{{\overline{\beta }}}_{BD}}}}}\,\!</math>

In particular, the maximum likelihood estimate for the rate of occurrence for the distinct BD modes at the termination time, <math>T\,\!</math>, is:

:<math>\begin{align}
\hat{h}(T) = & {{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{T}^{{{\overline{\beta }}_{BD}}-1}} \\
= & \frac{M{{\overline{\beta }}_{BD}}}{T}
\end{align}\,\!</math>

The parameters associated with <math>h(t)\,\!</math> can be viewed in RGA by selecting '''BD modes''' from the dropdown to the right of '''Results (All Modes)''' in the Results Area on the control panel to the right of the data sheet. The displayed value for the failure intensity, '''FI''', is <math>h(T)\,\!</math>.

===Growth Potential===
Growth Potential, when represented in terms of MTBF, is the maximum system reliability that can be attained for the system design with the current management strategy. The maximum MTBF will be attained when all <math>K\,\!</math> BD modes have been observed and fixed with EFs <math>{{d}_{i}}\,\!</math>. If the system is tested long enough then the failures that are observed in this case will be either repeat BD modes or A modes. In other words, there is not another unique BD mode to find within the system, and in most cases the growth potential is a value that may never actually be achieved. The growth potential can be thought of as an upper bound on the system's MTBF and ideally, should be about 30% above the system's requirement. As the system's MTBF gets closer to the growth potential, it becomes more difficult to increase the system's MTBF because it is taking more and more test time to propagate the next unique BD mode. The BD modes present opportunities for growth, but the rate of occurrence for unique BD modes goes down due to the decrease in <math>h(t)\,\!</math>. The growth potential is reached when <math>h(t)\,\!</math> is equal to zero. In other words, the difference between the projected failure intensity and the growth potential is <math>h(t)\,\!</math>. At about 2/3 of the growth potential it becomes increasingly difficult to increase the system's MTBF as <math>h(t)\,\!</math> function starts to flatten out.

The failure intensity <math>r(T)\,\!</math> will depend on the management strategy that determines the classification of the A and BD failure modes. The engineering effort applied to the corrective actions determines the effectiveness factors. In addition, <math>r(T)\,\!</math> depends on <math>h(t)\,\!</math>, which is the rate at which problem failure modes are being seen during testing. <math>h(t)\,\!</math> drives the opportunity to take corrective actions based on the seen failure modes and it is an important factor in the overall reliability growth rate. The reliability growth potential is the limiting value of <math>r(T)\,\!</math> as <math>T\,\!</math> increases. This limit is the maximum MTBF that can be attained with the current management strategy. In terms of failure intensity, the growth potential is expressed by the following equation:

:<math>{{r}_{GP}}={{\lambda }_{A}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>

In terms of the MTBF, the growth potential is given by:

:<math>\begin{align}
MTB{{F}_{GP}}=1/{{r}_{GP}}
\end{align}\,\!</math>

The procedure for estimating the growth potential is as follows. Suppose that the system is tested for a period of time <math>T\,\!</math> and that <math>N\,\!</math> failures have been observed. According to the management strategy, <math>{{N}_{A}}\,\!</math> of these failures are A modes and <math>{{N}_{BD}}\,\!</math> of these failures are BD modes. For the BD modes, there will be <math>M\,\!</math> distinct fixes. As before, <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. From this data, the growth potential failure intensity is estimated by:

:<math>{{\hat{r}}_{GP}}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)\,\!</math>

The growth potential MTBF is estimated by:

:<math>M\hat{T}B{{F}_{GP}}={{[{{\hat{r}}_{GP}}]}^{-1}}\,\!</math>

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

==Test-Fix-Find-Test==
Traditional reliability growth models provide assessments for two types of testing and corrective action strategies: ''test-fix-test'' and ''test-find-test''. In test-fix-test, failure modes are found during testing and corrective actions for these modes are incorporated during the test. Data from this type of test can be modeled appropriately with the [[Crow-AMSAA (NHPP)|Crow-AMSAA model]]. In test-find-test, modes are found during testing, but all of the corrective actions are delayed and incorporated after the completion of the test. Data from this type of test can be modeled appropriately with the Crow-AMSAA Projection model, which was described above in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]]. However, a common strategy involves a combination of these two approaches, where some corrective actions are incorporated during the test and some corrective actions are delayed and incorporated at the end of the test. This strategy is referred to as ''test-fix-find-test''. Data from this test can be modeled appropriately with the Crow Extended reliability growth model, which is described next.

Recall that B failure modes are all failure modes that will receive a corrective action. In order to provide the assessment and management metric structure for corrective actions during and after a test, two types of B modes are defined. BC failure modes are corrected during the test and BD failure modes are delayed until the end of the test. Type A failure modes are defined as before; (i.e., those failure modes that will not receive a corrective action, either during or at the end of the test).

===Development of the Crow Extended Model===
Let <math>{{\lambda }_{BD}}\,\!</math> denote the constant failure intensity for the BD failure modes, and let <math>h(t|BD)\,\!</math> denote the first occurrence function for the BD failure modes. In addition, as before, let <math>K\,\!</math> be the number of BD failure modes, let <math>{{d}_{i}}\,\!</math> be the effectiveness factor for the <math>{{i}^{th}}\,\!</math> BD failure mode and let <math>\overline{d}\,\!</math> be the average effectiveness factor.

The Crow Extended model projected failure intensity is given by:

:<math>{{\lambda }_{EM}}={{\lambda }_{CA}}-{{\lambda }_{BD}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T|BD)\,\!</math>

where <math>{{\lambda }_{CA}}=\lambda \beta {{T}^{\beta -1}}\,\!</math> is the achieved failure intensity at time <math>T\,\!</math>.

The Crow Extended model projected MTBF is:

:<math>\begin{align}
{{M}_{EM}}=1/{{\lambda }_{EM}}
\end{align}\,\!</math>

This is the MTBF after the delayed fixes have been implemented. Under the extended reliability growth model, the demonstrated failure intensity before the delayed fixes is the first term, <math>{{\lambda }_{CA}}\,\!</math>. The demonstrated MTBF at time <math>T\,\!</math> before the delayed fixes is given by:

:<math>{{M}_{CA}}\text{ }={{[{{\lambda }_{CA}}]}^{-1}}\,\!</math>

If you assume that there are no delayed corrective actions (BD modes), then the model reduces to a special case of the Crow-AMSAA model where the achieved MTBF equals the projection, <math>\lambda_{CA}\,\!</math>. That is, there is no jump. If you assume that there are no corrective actions during the test (BC modes) then the model reduces to the test-find-test scenario described in the previous section.

===Estimation of the Model===
In the general estimation of the Crow Extended model, it is required that all failure times during the test are known. Furthermore, the ID of each A, BC and BD failure mode needs to be entered.

The estimate of the projected failure intensity for the Crow Extended model is given by:

:<math>{{\widehat{\lambda }}_{EM}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}+\overline{d}\widehat{h}(T|BD)\,\!</math>

where <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. In order to obtain the first term, <math>{{\widehat{\lambda }}_{CA}}\,\!</math>, fit all of the data (regardless of mode classification) to the Crow-AMSAA model to estimate <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math>, thus:

:<math>{{\widehat{\lambda }}_{CA}}=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

The remaining terms are analyzed with the Crow Extended model, which is applied only to the BD data.

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>
:<math>\begin{align}
\widehat{h}(T|BD) = & {{\widehat{\lambda }}_{BD}}{{\widehat{\beta }}_{BD}}{{T}^{{{\widehat{\beta }}_{BD}}-1}} \\
= & \frac{M{{\widehat{\beta }}_{BD}}}{T}
\end{align}\,\!</math>

<math>{{\widehat{\beta }}_{BD}}\,\!</math> is the unbiased estimated of <math>\beta \,\!</math> for the Crow-AMSAA model based on the first occurrence of <math>M\,\!</math> distinct BD modes.

The structure for the Crow Extended model includes the following special data analysis cases:

#Test-fix-test with no failure modes known or with BC failure modes known. With this type of data, the Crow Extended model will take the form of the [[Crow-AMSAA (NHPP)|traditional Crow-AMSAA analysis]].
#Test-find-test with BD failure modes known. With this type of data, the Crow Extended model will take the form of the Crow-AMSAA Projection analysis described previously in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]].
#Test-fix-find-test with BC and BD failure modes known. With this type of data, the full capabilities of the Crow Extended model will be applied, as described in the following sections.

===Reliability Growth Potential and Maturity Metrics===
The growth potential and some maturity metrics for the Crow Extended model are calculated as follows.

*Initial system MTBF and failure intensity are given by:

:<math>{{\widehat{M}}_{I}}=\frac{\Gamma \left( 1+\tfrac{1}{\widehat{\beta }} \right)}{{{\widehat{\lambda }}^{\tfrac{1}{\widehat{\beta }}}}}\,\!</math>

and:

:<math>{{\widehat{\lambda }}_{I}}={{[{{\widehat{M}}_{I}}]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for all data regardless of the failure mode classification (i.e., A, BC or BD).

*The A mode failure intensity and MTBF are given by:

:<math>{{\widehat{\lambda }}_{A}}=\frac{{{N}_{A}}}{T}\,\!</math>

:<math>{{\widehat{M}}_{A}}={{[{{\widehat{\lambda }}_{A}}]}^{-1}}\,\!</math>

*The Initial BD mode failure intensity is given by:

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>

*The BC mode initial failure intensity and MTBF are given by:

:<math>{{\widehat{\lambda }}_{I(BC)}}={{\widehat{\lambda }}_{I}}-{{\widehat{\lambda }}_{A}}-{{\widehat{\lambda }}_{BD}}\,\!</math>

:<math>{{\widehat{M}}_{I(BC)}}={{[{{\widehat{\lambda }}_{I(BC)}}]}^{-1}}\,\!</math>

*Failure intensity <math>h(T|BC)\,\!</math> and instantaneous MTBF <math>M(T|BC)\,\!</math> for new BC failure modes at the end of test time <math>T\,\!</math> are given by:

:<math>\widehat{h}(T|BC)=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

:<math>\widehat{M}(T|BC)={{[\widehat{h}(T|BC)]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for the first occurrence of distinct BC modes.

*Average effectiveness factor for BC failure modes is given by:

:<math>{{\widehat{d}}_{BC}}=\frac{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{N}_{BC}}}{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{M}_{BC}}}\,\!</math>

:where <math>{{N}_{BC}}\,\!</math> is the total number of observed BC modes, <math>{{M}_{BC}}\,\!</math> is the number of unique BC modes and <math>{{\hat{\beta }}_{BC}}\,\!</math> is the MLE for the first occurrence of distinct BC modes. If <math>{{\hat{\beta }}_{BC}}\ge 1\,\!</math> then <math>{{\widehat{d}}_{BC}}\,\!</math> equals zero.

*Growth potential failure intensity and growth potential MTBF are given by:

:<math>{{\widehat{\lambda }}_{GP}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}\,\!</math>

:<math>{{\widehat{M}}_{GP}}={{[{{\widehat{\lambda }}_{GP}}]}^{-1}}\,\!</math>

===Failure Mode Management 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|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.

Let:

:<math>\hat{r}(T)=\hat{\lambda }\hat{\beta }{{T}^{\hat{\beta }-1}}\,\!</math>

where <math>T\,\!</math> is the test time and <math>\hat{\beta }\,\!</math> and <math>\hat{\lambda }\,\!</math> are the maximum likelihood estimates of the Crow-AMSAA model for all of the data. <math>\hat{\beta }\,\!</math> is the biased estimate of <math>\beta \,\!</math>. Therefore:

:<math>\hat{\beta }=\frac{N}{\underset{i=1}{\overset{N}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

:<math>\hat{\lambda }=\frac{N}{{{T}^{{\hat{\beta }}}}}\,\!</math>

where <math>N\,\!</math> is the total number of failures, and <math>{{X}_{i}}\,\!</math> is the <math>{{i}^{th}}\,\!</math> time-to-failure. Let the successive failures <math>0<{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{3}}<{{X}_{N}}\,\!</math> be partitioned into the A mode failures ( <math>{{N}_{A}}\,\!</math> ), BC first occurrence failures ( <math>{{N}_{BCF}}\,\!</math> ), BC remaining failures ( <math>{{N}_{BCR}}\,\!</math> ), BD first occurrence failure ( <math>{{N}_{BDF}}\,\!</math> ) and the BD remaining failures ( <math>{{N}_{BDR}}\,\!</math> ). For continuous data, each portion of the pie chart, due to each of the modes, is calculated as follows:

*A modes

:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{A}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{Ai}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
B{{D}_{remain}} = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\
= & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\
= & \overline{d}\cdot B{{D}_{seen}}
\end{align}\,\!</math>

For grouped data, the maximum likelihood estimates of <math>\beta \,\!</math> and <math>\lambda \,\!</math> from the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP)]] model are calculated such that the following equations are satisfied:

:<math>\underset{i=1}{\overset{K}{\mathop \sum }}\,{{N}_{i}}\left[ \frac{t_{i}^{{\hat{\beta }}}\ln ({{t}_{i}})-t_{i-1}^{{\hat{\beta }}}\ln ({{t}_{i-1}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-\ln T \right]=0\,\!</math>

:<math>\hat{\lambda }=\frac{N}{T_{K}^{{\hat{\beta }}}}\,\!</math>

where <math>K\,\!</math> is the number of groups and <math>N=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{N}_{i}}\,\!</math>.

*A modes

:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{A}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{Ai}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
B{{D}_{remain}} = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\
= & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\
= & \overline{d}\cdot B{{D}_{seen}}
\end{align}\,\!</math>

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

==Confidence Bounds==
The RGA software provides two methods to estimate the confidence bounds for the Crow Extended model when applied to developmental testing data. The Fisher Matrix approach is based on the Fisher Information Matrix and is commonly employed in the reliability field. The Crow bounds were developed by Dr. Larry Crow.

See the [[Crow Extended Confidence Bounds]] chapter for details on how these confidence bounds are calculated.

===Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example}}

===Another Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example_2}}

==Grouped Data== 

Parameter estimation for grouped data using the Crow Extended model is the same as the procedure used for the traditional [[Crow-AMSAA (NHPP)#Grouped_Data| Crow-AMSAA (NHPP)]] model. The equations used to estimate the parameters of the Crow Extended model are presented next. For test-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are calculated using the first occurrences of the BD modes such that:

:<math>\underset{i=1}{\overset{k}{\mathop \sum }}\,{{n}_{i}}\left[ \frac{T_{i}^{\widehat{\beta }}\ln {{T}_{i}}-T_{i-1}^{\widehat{\beta }}\ln {{T}_{i-

1}}}{T_{i}^{\widehat{\beta }}-T_{i-1}^{\widehat{\beta }}}-\ln {{T}_{k}} \right]=0\,\!</math>

:<math>\widehat{\lambda }=\frac{n}{T_{k}^{\widehat{\beta }}}\,\!</math>

where <math>{{n}_{i}}\,\!</math> is the number of distinct BD modes within the <math>{{i}^{th}}\,\!</math> interval. For test-fix-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BC}}\,\!</math> and <math>{{\beta }_{BC}}\,\!</math> are estimated in the same manner using the first occurrences of the BC modes.

===Confidence Bounds for Grouped Data===
*'''Parameters:''' The confidence bounds on the parameters for the Crow Extended model for grouped data are calculated using the same procedure presented in the [[Crow-AMSAA_Confidence_Bounds|Crow-AMSAA Confidence Bounds]] chapter.
*'''Failure Intensity and MTBF:'''
**If there are no BC modes, the confidence bounds on the demonstrated failure intensity and MTBF, projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as the procedure presented for [[Crow Extended Confidence Bounds|non-grouped data]].
**If there are BC modes, then the confidence bounds on the demonstrated failure intensity and MTBF are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter, and the confidence bounds on the projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as for non-grouped data.
*'''Time:''' The confidence bounds on time are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter.

==Mixed Data==
The Crow Extended model can also be applied to discrete data from one-shot (success/failure) testing. In the RGA software, the '''Discrete Data > Mixed Data''' option creates a data sheet that can accommodate data from tests where a single unit is tested for each successive configuration (individual trial-by-trial), where multiple units are tested for each successive configuration (configurations in groups) or a combination of both. This data sheet can be analyzed with either the Crow-AMSAA (NHPP) model or the Crow Extended model.

For discrete data, corrective actions cannot take place at the time of failure. With that in mind, the mixed data type does not allow for BC modes. For discrete data there are only A or BD modes. In terms of practical applications, think of a growth test for missile systems. Because missiles are one-shot items, any corrective actions applied to the failure modes are delayed until at least the next trial.

Note that for calculation purposes, it is required to have at least three failures in the first interval. If that is not the case, then the data set needs to be grouped before calculating. The RGA software performs this operation in the background.

===Example===
{{:Mixed_Data_-_Crow_Extended_Example}}

==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 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 applicable only to data from within a single test phase.

As previously presented, the failure mode classifications for the Crow Extended model are defined as follows:

*'''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.

Therefore, implemented fixes can be applied only 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.

===Event Codes===
A Multiple Systems with Event Codes data sheet that is analyzed with the Crow Extended model has an '''Event''' column that allows you to indicate the types of events that occurred during a test phase. The possible event codes that can be used in the analysis are:

*'''''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.

*'''''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''' check box under Event Code Options on the Analysis tab.

*'''''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''' check box under Event Code Options on the Analysis tab.

*'''''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. The row of data with the ''X'' will not be included in the analysis.

*'''''S''''': indicates the system start time. This event code is only selectable in the Normal View.

*'''''F''''': indicates a failure time.

*'''''E''''': indicates the system end time. This event code is only selectable in the Normal View.

The analysis is based on the equivalent system that combines the operating hours of all the systems.

===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 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>
<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>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>.</li>
<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>
<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>
<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.
:::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.</li>
<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====
{{:Equivalent_System_Example}}

===Transferring Data to an Equivalent Single System===
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]]

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.

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.

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|center|450px]]

===Iteration Method for Naming Repeated Modes===
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.

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|center|450px]]

The RGA software will display a warning if you try to convert this data sheet without using iterations.

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

[[Image:rga9.28.png|center|450px]]

==More Examples==
===Adjusting the Failure Mode Management Strategy===
{{:Concurrent_Operating_Times_-_Crow_Extended_Example}}

===Estimating the Failure Intensity Remaining After Fixes===
{{:Grouped_Data_-_Crow_Extended_Example}}

===Determining if Design Will Meet MTBF Goal===
{{:Known_Operating_Times_-_Crow_Extended_Example}}

Crow Extended

2020-08-19T23:07:39Z

David J. Groebel: /* Mathematical Formulation */

{{template:RGA BOOK|3.3|Crow Extended}}
In reliability growth analysis, the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP) model]] assumes that the corrective actions for the observed failure modes are incorporated during the test (test-fix-test). However, in actual practice, fixes may be delayed until after the completion of the test (test-find-test) or some fixes may be implemented during the test while others are delayed (test-fix-find-test). At the end of a test phase, two reliability estimates are of concern: ''demonstrated reliability'' and ''projected reliability''. The demonstrated reliability, which is based on data generated during the test phase, is an estimate of the system reliability for its configuration at the end of the test phase. The projected reliability measures the impact of the delayed fixes at the end of the current test phase.
<br>

Most of the reliability growth literature are concerned with procedures and models for calculating the demonstrated reliability, and very little attention has been paid to techniques for reliability projections. The procedure for making reliability projections utilizes engineering assessments of the effectiveness of the delayed fixes for each observed failure mode. These effectiveness factors are then used with the data generated during the test phase to obtain a projected estimate for the updated configuration by adjusting the number of failures observed during the test phase. The process of estimating the projected reliability is accomplished using the Crow Extended model. The Crow Extended model allows for a flexible growth strategy that can include corrective actions performed during the test, as well as delayed corrective actions. The test-find-test and test-fix-find-test scenarios are simply subsets of the Crow Extended model.

For developmental testing, the Crow Extended model can be applied when using any of the following [[RGA_Data_Types|data types]]:

*Failure Times Data
*Multiple Systems (Known Operating Times)
*Multiple Systems (Concurrent Operating Times)
*Multiple Systems with Dates
*Multiple Systems with Event Codes
*Grouped Failure Times
*Mixed Data

As the name implies, Crow Extended is simply an "extension" of the Crow-AMSAA (NHPP) model. The calculations for Crow Extended still incorporate the methods for Crow-AMSAA based on the data type, as described on the [[Crow-AMSAA (NHPP)]] page. The Crow-AMSAA model estimates the growth during the test, while the Crow Extended model accounts for the growth after the test based on the delayed corrective actions. Additional details regarding the calculations for the Crow Extended model are presented in the sections below.

==Background==
When a system is tested and failure modes are observed, management can make one of two possible decisions: to fix or to not fix the failure modes. Failure modes that are not fixed are called ''A modes'' and failure modes that receive a corrective action are called ''B modes''. The A modes account for all failure modes that management considers to be not economical or not justified to receive corrective action. The B modes provide the assessment and management metric structure for corrective actions during and after a test. There are two types of B modes: BC modes, which are corrected during the test, and BD modes, which are corrected only at the end of the test. The management strategy is defined by how the corrective actions, if any, will be implemented. In summary, the classifications are defined as follows:

*'''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. BD modes will provide a jump in the system's MTBF at the termination time.

In terms of assessing a system's reliability, there are three specific metrics of interest:

*'''Demonstrated (or achieved) MTBF (DMTBF)''' is the system's instantaneous MTBF at the termination time.
*'''Projected MTBF (PMTBF)''' is the system's expected instantaneous MTBF after the implementation of the delayed corrective actions.
*'''Growth Potential MTBF (GPMTBF)''' is the maximum MTBF that can be attained for the system design and management strategy.

These metrics can also be displayed in RGA in terms of failure intensity (FI). The demonstrated MTBF is calculated using basically the same methods, depending on data type, as presented on the [[Crow-AMSAA (NHPP)]] page. Projected MTBF/FI and growth potential MTBF/FI are presented in detail in the sections below.

The following picture shows an example of data entered for the Crow Extended model.

[[Image:rga9.1.png|center|500px|Failure times data for a single system in cumulative format, including classification and mode information.]]

As you can see, each failure is indicated with A, BC or BD in the '''Classification''' column. In addition, any number or text can be used to specify the failure mode. In this example, numbers were used in the '''Mode''' column for simplicity, but you could just as easily use "Seal Leak," or whatever designation you deem appropriate for identifying the mode. In RGA, a failure mode is defined as a problem and a cause.

Reliability growth is achieved by decreasing the failure intensity. The failure intensity for the A failure modes will not change; therefore, reliability growth can only be achieved by decreasing the BC and BD mode failure intensity. In general, the only part of the BD mode failure intensity that can be decreased is that which has been seen during testing, since the failure intensity due to BD modes that were unseen during testing still remains. The BC failure modes are corrected during test, and the BC failure intensity will not change any more at the end of test.

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

:<math>Multiplier=\frac{1}{1-EF}</math>

Using this equation, an <math>EF=0.7\,\!</math> corresponds to an increase of 3.3X. Therefore, if a failure mode had an MTBF of 100 and a delayed fix was applied, an estimate of the failure mode's MTBF after the fix is equal to <math>\approx 333\,\!</math>. An <math>EF=0.9\,\!</math> corresponds to a 10X increase in the failure mode's MTBF. So there is a large increase between EF = 0.7 and EF = 0.9. Before assigning an EF to a BD mode, it is recommended to run a test to verify the fix and to validate the assumed EF value. Ideally, you want to have some sort of justification for using the entered EF value. If you do not know the EF value for each BD mode, then you can also specify a fixed EF which is then applied to all modes. The average value of EF = 0.7 is a good place to start, but if you want to be a bit more conservative, then an EF = 0.4, or a smaller value, could be used.

==Test-Find-Test==
Test-find-test is a testing strategy where all corrective actions are delayed until after the test. Therefore, there are not any BC modes when analyzing test-find-test data (only A and BD modes). This scenario is also called the ''Crow-AMSAA Projection'' model, but for the purposes of the RGA software, it is simply a special case of the Crow Extended model. The picture below presents the test-find-test scenario.

[[File:TestFindTest.png|center|400px|Test-find-test.]]

Since there are no fixes applied during the test, the assumption is that the system's MTBF does not change during the test. In other words, the system's MTBF is constant. The system should not be exhibiting an increasing or decreasing trend in its reliability if changes are not being made. Therefore, the assumption is that <math>\beta = 1\,\!</math>. RGA will return two <math>\beta\,\!</math> values; Beta (hyp) which always shows a value equal to 1 since this is the underlying assumption, and Beta which is the Crow-AMSAA (NHPP) estimate that considers all of the failure times. The assumption of <math>\beta = 1\,\!</math> can be verified by looking at the confidence bounds on <math>\beta\,\!</math>. If the confidence bounds on <math>\beta\,\!</math> include one, then you can fail to reject the hypothesis that <math>\beta = 1\,\!</math>. RGA does this check automatically and uses a confidence level equal to 1 minus the specified significance level to check if the confidence bounds on <math>\beta\,\!</math> include one. If the <math>\beta = 1\,\!</math> assumption is violated, then the value for Beta (hyp) will be displayed in red text. If the confidence bounds on <math>\beta\,\!</math> do not include 1, then the following questions should be considered as they relate to the data:

*If multiple systems were tested, did they have the same configuration throughout the test? Were the corrective actions applied to all systems?
*Were the test conditions consistent for each system?
*Was there a change in the failure definition?
*Any issues with data entry?

<math>\beta = 1\,\!</math> is then used to estimate the demonstrated MTBF of the system and it is also used in the goodness-of-fit tests.

===Projected Failure Intensity===
Suppose a system is subjected to development testing for a period of time, <math>T\,\!</math>. The system can be considered as consisting of two types of failure modes: A modes and BD modes. It is assumed that all BD modes are in series and fail independently according to the exponential distribution. Also assume that the rate of occurrence of A modes follows an exponential distribution with failure intensity <math>{{\lambda }_{A}}\,\!</math>. The system MTBF is constant throughout the test phase since all of the corrective actions are delayed until after the completion of the test. After the delayed fixes have been implemented, the system MTBF will then jump to a higher value.

Let <math>K\,\!</math> denote the total number of BD modes in the system, and let <math>{{\lambda }_{i}}\,\!</math> denote the failure intensity for the <math>{{i}^{th}}\,\!</math> BD mode, such that <math>i = 1,2,\ldots ,K\,\!</math>. Then, at time equal to zero, the system failure intensity <math>r(0)\,\!</math> is:

:<math>\begin{align}
r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}
\end{align}\,\!</math>

where:

:<math>{{\lambda }_{BD}}=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{\lambda }_{i}}\,\!</math>.

During the test <math>(0,T)\,\!</math>, a random number of <math>M\,\!</math> distinct BD modes will be observed, such that <math>M\le K\,\!</math>. Denote the effectiveness factor (EF) for the <math>{{i}^{th}}\,\!</math> BD mode as <math>{{d}_{i}}\,\!</math>, <math>i = 1,2,\ldots ,K\,\!</math>. The effectiveness factor <math>{{d}_{i}}\,\!</math> is the percent decrease in <math>{{\lambda }_{i}}\,\!</math> after a corrective action has been made for the <math>{{i}^{th}}\,\!</math> BD mode. That is, the corrective action for the <math>{{i}^{th}}\,\!</math> BD mode removes <math>100\times {{d}_{i}}\,\!</math> percent of the failure rate, and <math>100\times (1-{{d}_{i}})\,\!</math> percent remains. The failure intensity for the <math>{{i}^{th}}\,\!</math> BD failure mode after a corrective action is <math>(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>. If corrective actions are taken on the <math>M\,\!</math> BD modes observed by time <math>T\,\!</math>, then the system failure intensity is reduced from <math>r(0)\,\!</math> to:

:<math>\begin{align}
r\left( T \right) = & {{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,\left( 1-{{d}_{i}} \right){{\lambda }_{i}}+({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{\lambda }_{i}}) \\
= & {{\lambda }_{A}}+{{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}
\end{align}\,\!</math>

where:

*<math>\underset{i=1}{\overset{M}{\mathop{\sum }}}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math> is the failure intensity for the <math>M\,\!</math> modes after the corrective actions
*<math>({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop{\sum }}}\,{{\lambda }_{i}})\,\!</math> is the remaining failure intensity for all unseen BD modes

All <math>M\,\!</math> BD modes observed by test time <math>T\,\!</math> may not be fixed by time <math>T\,\!</math> so the actual failure intensity at time <math>T\,\!</math> may not be <math>r(T)\,\!</math>. However, <math>r(T)\,\!</math> can be viewed as the achieved failure intensity at time <math>T\,\!</math> if all fixes were updated and incorporated into the system. All of the fixes for the BD modes found during the test are incorporated as delayed fixes at the end of the test phase. Therefore, the system failure intensity is constant at <math>r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}\,\!</math> through the test phase and will then jump to a lower value <math>r(T)\,\!</math> after the delayed fixes have been implemented. Let <math>{{N}_{A}}\,\!</math> and <math>{{N}_{BD}}\,\!</math> be the total number of A and BD failures observed during the test <math>(0,T)\,\!</math> and let <math>N={{N}_{A}}+{{N}_{BD}}\,\!</math>. In addition, there are <math>M\,\!</math> distinct BD modes observed during the test. After implementing the <math>M\,\!</math> fixes, the failure intensity for the system at time <math>T\,\!</math> (after the jump) is given by the function <math>r(T)\,\!</math>.

<math>r(0)\,\!</math> is actually the demonstrated failure intensity, which is based on actual system performance of the hardware tested and not of some future configuration. A demonstrated reliability value should be determined at the end of each test phase. The demonstrated failure intensity is:

:<math>{{\hat{\lambda }}_{D}}(T)=r(0)=\frac{{{N}_{A}}+{{N}_{BD}}}{T}\,\!</math>

The demonstrated MTBF is given by:

:<math>\widehat{{MTBF}_{D}}={{[{{\hat{\lambda }}_{D}}(T)]}^{-1}}\,\!</math>

The detailed procedure for estimating <math>r(T)\,\!</math> is given in Crow [[RGA_References|[20]]] and is reviewed here.

Let <math>E[\cdot ]\,\!</math> denote the expected value:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}{{e}^{-{{\lambda }_{i}}T}}\,\!</math>

Under realistic assumptions, <math>E[r(T)]\,\!</math> also may be expressed as:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T)\,\!</math>

where <math>\overline{d}\,\!</math> is the mean effectiveness factor and <math>h(T)\,\!</math> is the instantaneous rate at which a new BD mode will occur at time <math>T\,\!</math>. <math>\overline{d}h(T)\,\!</math> is the bias term (or sometimes called the 3<sup>rd</sup> term), such that:

:<math>B(T)=\overline{d}h(T)\,\!</math>

The mean <math>\overline{d}\,\!</math> is given by:

:<math>\overline{d}=\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\,\!</math>

Therefore, the projected failure intensity <math>r(T)\,\!</math> is then estimated at the end of the test phase by:

:<math>\hat{r}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)+\overline{d}h(T)\,\!</math>

The projected MTBF is:

:<math>\widehat{{MTBF}_{P}}={{[r(T)]}^{-1}}\,\!</math>

===Mathematical Formulation===
As indicated previously, the failure intensity of the system at <math>t=0\,\!</math> is given by:

:<math>\begin{align}
{{\lambda }_{System}}= & {{\lambda }_{A}}+{{\lambda }_{BD}} \\
= & {{\lambda }_{A}}+{{\lambda }_{B{{D}_{Seen}}}}+{{\lambda }_{B{{D}_{Unseen}}}}
\end{align}\,\!</math>

The estimate for the projected failure intensity, after the corrective actions have been implemented, is then:

:<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 }_{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}}+dh\left( t \right)
\end{align}\,\!</math>

This is the basic format of the equation for the projected failure intensity when the Crow Extended model is used with the test-find-test strategy.

===h(t) Function===
h(t) is defined as the unseen BD mode failure intensity. It is also defined as the rate at which new unique BD modes are being discovered. The maximum likelihood estimate of <math>h(t)\,\!</math> is calculated using:

:<math>\hat{h}\left( t \right)={{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{t}^{{{{\overline{\beta }}}_{BD}}-1}}\,\!</math>

where <math>{\overline{\beta }_{BD}}\,\!</math> is the unbiased estimate. The unbiased estimate is always used when calculating <math>\hat{h}\left( t \right)\,\!</math>.

The parameters of the <math>h(t)\,\!</math> function, <math>{{\beta }_{BD}}\,\!</math> and <math>{{\lambda }_{BD}}\,\!</math>, are calculated using the first occurrence of each BD mode. In order to have growth, <math>{{\beta }_{BD}}\,\!</math> must be less than one. If <math>{{\beta }_{BD}}\,\!</math> is close to one then it is possible that the program could be in trouble since this indicates that there are very few repeat occurrences. In this case, each failure tends to be a unique mode. If <math>{{\beta }_{BD}}\,\!</math> is less than one then the rate at which new unique BD modes are occurring is decreasing.

Let <math>{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{M}}<T\,\!</math> denote the cumulative test times for the first occurrences of BD modes. Then, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are:

:<math>{{\hat{\beta }}_{BD}}=\frac{M}{\underset{i=1}{\overset{M}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

The unbiased estimate of <math>{{\beta }_{BD}}\,\!</math> is:

:<math>{{\bar{\beta }}_{BD}}=\frac{M-1}{M}{{\hat{\beta }}_{BD}}\,\!</math>

:<math>{{\hat{\lambda }}_{BD}}=\frac{M}{{{T}^{{{{\overline{\beta }}}_{BD}}}}}\,\!</math>

In particular, the maximum likelihood estimate for the rate of occurrence for the distinct BD modes at the termination time, <math>T\,\!</math>, is:

:<math>\begin{align}
\hat{h}(T) = & {{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{T}^{{{\overline{\beta }}_{BD}}-1}} \\
= & \frac{M{{\overline{\beta }}_{BD}}}{T}
\end{align}\,\!</math>

The parameters associated with <math>h(t)\,\!</math> can be viewed in RGA by selecting '''BD modes''' from the dropdown to the right of '''Results (All Modes)''' in the Results Area on the control panel to the right of the data sheet. The displayed value for the failure intensity, '''FI''', is <math>h(T)\,\!</math>.

===Growth Potential===
Growth Potential, when represented in terms of MTBF, is the maximum system reliability that can be attained for the system design with the current management strategy. The maximum MTBF will be attained when all <math>K\,\!</math> BD modes have been observed and fixed with EFs <math>{{d}_{i}}\,\!</math>. If the system is tested long enough then the failures that are observed in this case will be either repeat BD modes or A modes. In other words, there is not another unique BD mode to find within the system, and in most cases the growth potential is a value that may never actually be achieved. The growth potential can be thought of as an upper bound on the system's MTBF and ideally, should be about 30% above the system's requirement. As the system's MTBF gets closer to the growth potential, it becomes more difficult to increase the system's MTBF because it is taking more and more test time to propagate the next unique BD mode. The BD modes present opportunities for growth, but the rate of occurrence for unique BD modes goes down due to the decrease in <math>h(t)\,\!</math>. The growth potential is reached when <math>h(t)\,\!</math> is equal to zero. In other words, the difference between the projected failure intensity and the growth potential is <math>h(t)\,\!</math>. At about 2/3 of the growth potential it becomes increasingly difficult to increase the system's MTBF as <math>h(t)\,\!</math> function starts to flatten out.

The failure intensity <math>r(T)\,\!</math> will depend on the management strategy that determines the classification of the A and BD failure modes. The engineering effort applied to the corrective actions determines the effectiveness factors. In addition, <math>r(T)\,\!</math> depends on <math>h(t)\,\!</math>, which is the rate at which problem failure modes are being seen during testing. <math>h(t)\,\!</math> drives the opportunity to take corrective actions based on the seen failure modes and it is an important factor in the overall reliability growth rate. The reliability growth potential is the limiting value of <math>r(T)\,\!</math> as <math>T\,\!</math> increases. This limit is the maximum MTBF that can be attained with the current management strategy. In terms of failure intensity, the growth potential is expressed by the following equation:

:<math>{{r}_{GP}}={{\lambda }_{A}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>

In terms of the MTBF, the growth potential is given by:

:<math>\begin{align}
MTB{{F}_{GP}}=1/{{r}_{GP}}
\end{align}\,\!</math>

The procedure for estimating the growth potential is as follows. Suppose that the system is tested for a period of time <math>T\,\!</math> and that <math>N\,\!</math> failures have been observed. According to the management strategy, <math>{{N}_{A}}\,\!</math> of these failures are A modes and <math>{{N}_{BD}}\,\!</math> of these failures are BD modes. For the BD modes, there will be <math>M\,\!</math> distinct fixes. As before, <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. From this data, the growth potential failure intensity is estimated by:

:<math>{{\hat{r}}_{GP}}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)\,\!</math>

The growth potential MTBF is estimated by:

:<math>M\hat{T}B{{F}_{GP}}={{[{{\hat{r}}_{GP}}]}^{-1}}\,\!</math>

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

==Test-Fix-Find-Test==
Traditional reliability growth models provide assessments for two types of testing and corrective action strategies: ''test-fix-test'' and ''test-find-test''. In test-fix-test, failure modes are found during testing and corrective actions for these modes are incorporated during the test. Data from this type of test can be modeled appropriately with the [[Crow-AMSAA (NHPP)|Crow-AMSAA model]]. In test-find-test, modes are found during testing, but all of the corrective actions are delayed and incorporated after the completion of the test. Data from this type of test can be modeled appropriately with the Crow-AMSAA Projection model, which was described above in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]]. However, a common strategy involves a combination of these two approaches, where some corrective actions are incorporated during the test and some corrective actions are delayed and incorporated at the end of the test. This strategy is referred to as ''test-fix-find-test''. Data from this test can be modeled appropriately with the Crow Extended reliability growth model, which is described next.

Recall that B failure modes are all failure modes that will receive a corrective action. In order to provide the assessment and management metric structure for corrective actions during and after a test, two types of B modes are defined. BC failure modes are corrected during the test and BD failure modes are delayed until the end of the test. Type A failure modes are defined as before; (i.e., those failure modes that will not receive a corrective action, either during or at the end of the test).

===Development of the Crow Extended Model===
Let <math>{{\lambda }_{BD}}\,\!</math> denote the constant failure intensity for the BD failure modes, and let <math>h(t|BD)\,\!</math> denote the first occurrence function for the BD failure modes. In addition, as before, let <math>K\,\!</math> be the number of BD failure modes, let <math>{{d}_{i}}\,\!</math> be the effectiveness factor for the <math>{{i}^{th}}\,\!</math> BD failure mode and let <math>\overline{d}\,\!</math> be the average effectiveness factor.

The Crow Extended model projected failure intensity is given by:

:<math>{{\lambda }_{EM}}={{\lambda }_{CA}}-{{\lambda }_{BD}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T|BD)\,\!</math>

where <math>{{\lambda }_{CA}}=\lambda \beta {{T}^{\beta -1}}\,\!</math> is the achieved failure intensity at time <math>T\,\!</math>.

The Crow Extended model projected MTBF is:

:<math>\begin{align}
{{M}_{EM}}=1/{{\lambda }_{EM}}
\end{align}\,\!</math>

This is the MTBF after the delayed fixes have been implemented. Under the extended reliability growth model, the demonstrated failure intensity before the delayed fixes is the first term, <math>{{\lambda }_{CA}}\,\!</math>. The demonstrated MTBF at time <math>T\,\!</math> before the delayed fixes is given by:

:<math>{{M}_{CA}}\text{ }={{[{{\lambda }_{CA}}]}^{-1}}\,\!</math>

If you assume that there are no delayed corrective actions (BD modes), then the model reduces to a special case of the Crow-AMSAA model where the achieved MTBF equals the projection, <math>\lambda_{CA}\,\!</math>. That is, there is no jump. If you assume that there are no corrective actions during the test (BC modes) then the model reduces to the test-find-test scenario described in the previous section.

===Estimation of the Model===
In the general estimation of the Crow Extended model, it is required that all failure times during the test are known. Furthermore, the ID of each A, BC and BD failure mode needs to be entered.

The estimate of the projected failure intensity for the Crow Extended model is given by:

:<math>{{\widehat{\lambda }}_{EM}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}+\overline{d}\widehat{h}(T|BD)\,\!</math>

where <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. In order to obtain the first term, <math>{{\widehat{\lambda }}_{CA}}\,\!</math>, fit all of the data (regardless of mode classification) to the Crow-AMSAA model to estimate <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math>, thus:

:<math>{{\widehat{\lambda }}_{CA}}=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

The remaining terms are analyzed with the Crow Extended model, which is applied only to the BD data.

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>
:<math>\begin{align}
\widehat{h}(T|BD) = & {{\widehat{\lambda }}_{BD}}{{\widehat{\beta }}_{BD}}{{T}^{{{\widehat{\beta }}_{BD}}-1}} \\
= & \frac{M{{\widehat{\beta }}_{BD}}}{T}
\end{align}\,\!</math>

<math>{{\widehat{\beta }}_{BD}}\,\!</math> is the unbiased estimated of <math>\beta \,\!</math> for the Crow-AMSAA model based on the first occurrence of <math>M\,\!</math> distinct BD modes.

The structure for the Crow Extended model includes the following special data analysis cases:

#Test-fix-test with no failure modes known or with BC failure modes known. With this type of data, the Crow Extended model will take the form of the [[Crow-AMSAA (NHPP)|traditional Crow-AMSAA analysis]].
#Test-find-test with BD failure modes known. With this type of data, the Crow Extended model will take the form of the Crow-AMSAA Projection analysis described previously in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]].
#Test-fix-find-test with BC and BD failure modes known. With this type of data, the full capabilities of the Crow Extended model will be applied, as described in the following sections.

===Reliability Growth Potential and Maturity Metrics===
The growth potential and some maturity metrics for the Crow Extended model are calculated as follows.

*Initial system MTBF and failure intensity are given by:

:<math>{{\widehat{M}}_{I}}=\frac{\Gamma \left( 1+\tfrac{1}{\widehat{\beta }} \right)}{{{\widehat{\lambda }}^{\tfrac{1}{\widehat{\beta }}}}}\,\!</math>

and:

:<math>{{\widehat{\lambda }}_{I}}={{[{{\widehat{M}}_{I}}]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for all data regardless of the failure mode classification (i.e., A, BC or BD).

*The A mode failure intensity and MTBF are given by:

:<math>{{\widehat{\lambda }}_{A}}=\frac{{{N}_{A}}}{T}\,\!</math>

:<math>{{\widehat{M}}_{A}}={{[{{\widehat{\lambda }}_{A}}]}^{-1}}\,\!</math>

*The Initial BD mode failure intensity is given by:

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>

*The BC mode initial failure intensity and MTBF are given by:

:<math>{{\widehat{\lambda }}_{I(BC)}}={{\widehat{\lambda }}_{I}}-{{\widehat{\lambda }}_{A}}-{{\widehat{\lambda }}_{BD}}\,\!</math>

:<math>{{\widehat{M}}_{I(BC)}}={{[{{\widehat{\lambda }}_{I(BC)}}]}^{-1}}\,\!</math>

*Failure intensity <math>h(T|BC)\,\!</math> and instantaneous MTBF <math>M(T|BC)\,\!</math> for new BC failure modes at the end of test time <math>T\,\!</math> are given by:

:<math>\widehat{h}(T|BC)=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

:<math>\widehat{M}(T|BC)={{[\widehat{h}(T|BC)]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for the first occurrence of distinct BC modes.

*Average effectiveness factor for BC failure modes is given by:

:<math>{{\widehat{d}}_{BC}}=\frac{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{N}_{BC}}}{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{M}_{BC}}}\,\!</math>

:where <math>{{N}_{BC}}\,\!</math> is the total number of observed BC modes, <math>{{M}_{BC}}\,\!</math> is the number of unique BC modes and <math>{{\hat{\beta }}_{BC}}\,\!</math> is the MLE for the first occurrence of distinct BC modes. If <math>{{\hat{\beta }}_{BC}}\ge 1\,\!</math> then <math>{{\widehat{d}}_{BC}}\,\!</math> equals zero.

*Growth potential failure intensity and growth potential MTBF are given by:

:<math>{{\widehat{\lambda }}_{GP}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}\,\!</math>

:<math>{{\widehat{M}}_{GP}}={{[{{\widehat{\lambda }}_{GP}}]}^{-1}}\,\!</math>

===Failure Mode Management 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|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.

Let:

:<math>\hat{r}(T)=\hat{\lambda }\hat{\beta }{{T}^{\hat{\beta }-1}}\,\!</math>

where <math>T\,\!</math> is the test time and <math>\hat{\beta }\,\!</math> and <math>\hat{\lambda }\,\!</math> are the maximum likelihood estimates of the Crow-AMSAA model for all of the data. <math>\hat{\beta }\,\!</math> is the biased estimate of <math>\beta \,\!</math>. Therefore:

:<math>\hat{\beta }=\frac{N}{\underset{i=1}{\overset{N}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

:<math>\hat{\lambda }=\frac{N}{{{T}^{{\hat{\beta }}}}}\,\!</math>

where <math>N\,\!</math> is the total number of failures, and <math>{{X}_{i}}\,\!</math> is the <math>{{i}^{th}}\,\!</math> time-to-failure. Let the successive failures <math>0<{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{3}}<{{X}_{N}}\,\!</math> be partitioned into the A mode failures ( <math>{{N}_{A}}\,\!</math> ), BC first occurrence failures ( <math>{{N}_{BCF}}\,\!</math> ), BC remaining failures ( <math>{{N}_{BCR}}\,\!</math> ), BD first occurrence failure ( <math>{{N}_{BDF}}\,\!</math> ) and the BD remaining failures ( <math>{{N}_{BDR}}\,\!</math> ). For continuous data, each portion of the pie chart, due to each of the modes, is calculated as follows:

*A modes

:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{A}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{Ai}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
B{{D}_{remain}} = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\
= & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\
= & \overline{d}\cdot B{{D}_{seen}}
\end{align}\,\!</math>

For grouped data, the maximum likelihood estimates of <math>\beta \,\!</math> and <math>\lambda \,\!</math> from the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP)]] model are calculated such that the following equations are satisfied:

:<math>\underset{i=1}{\overset{K}{\mathop \sum }}\,{{N}_{i}}\left[ \frac{t_{i}^{{\hat{\beta }}}\ln ({{t}_{i}})-t_{i-1}^{{\hat{\beta }}}\ln ({{t}_{i-1}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-\ln T \right]=0\,\!</math>

:<math>\hat{\lambda }=\frac{N}{T_{K}^{{\hat{\beta }}}}\,\!</math>

where <math>K\,\!</math> is the number of groups and <math>N=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{N}_{i}}\,\!</math>.

*A modes

:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{A}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{Ai}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
B{{D}_{remain}} = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\
= & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\
= & \overline{d}\cdot B{{D}_{seen}}
\end{align}\,\!</math>

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

==Confidence Bounds==
The RGA software provides two methods to estimate the confidence bounds for the Crow Extended model when applied to developmental testing data. The Fisher Matrix approach is based on the Fisher Information Matrix and is commonly employed in the reliability field. The Crow bounds were developed by Dr. Larry Crow.

See the [[Crow Extended Confidence Bounds]] chapter for details on how these confidence bounds are calculated.

===Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example}}

===Another Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example_2}}

==Grouped Data== 

Parameter estimation for grouped data using the Crow Extended model is the same as the procedure used for the traditional [[Crow-AMSAA (NHPP)#Grouped_Data| Crow-AMSAA (NHPP)]] model. The equations used to estimate the parameters of the Crow Extended model are presented next. For test-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are calculated using the first occurrences of the BD modes such that:

:<math>\underset{i=1}{\overset{k}{\mathop \sum }}\,{{n}_{i}}\left[ \frac{T_{i}^{\widehat{\beta }}\ln {{T}_{i}}-T_{i-1}^{\widehat{\beta }}\ln {{T}_{i-

1}}}{T_{i}^{\widehat{\beta }}-T_{i-1}^{\widehat{\beta }}}-\ln {{T}_{k}} \right]=0\,\!</math>

:<math>\widehat{\lambda }=\frac{n}{T_{k}^{\widehat{\beta }}}\,\!</math>

where <math>{{n}_{i}}\,\!</math> is the number of distinct BD modes within the <math>{{i}^{th}}\,\!</math> interval. For test-fix-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BC}}\,\!</math> and <math>{{\beta }_{BC}}\,\!</math> are estimated in the same manner using the first occurrences of the BC modes.

===Confidence Bounds for Grouped Data===
*'''Parameters:''' The confidence bounds on the parameters for the Crow Extended model for grouped data are calculated using the same procedure presented in the [[Crow-AMSAA_Confidence_Bounds|Crow-AMSAA Confidence Bounds]] chapter.
*'''Failure Intensity and MTBF:'''
**If there are no BC modes, the confidence bounds on the demonstrated failure intensity and MTBF, projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as the procedure presented for [[Crow Extended Confidence Bounds|non-grouped data]].
**If there are BC modes, then the confidence bounds on the demonstrated failure intensity and MTBF are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter, and the confidence bounds on the projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as for non-grouped data.
*'''Time:''' The confidence bounds on time are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter.

==Mixed Data==
The Crow Extended model can also be applied to discrete data from one-shot (success/failure) testing. In the RGA software, the '''Discrete Data > Mixed Data''' option creates a data sheet that can accommodate data from tests where a single unit is tested for each successive configuration (individual trial-by-trial), where multiple units are tested for each successive configuration (configurations in groups) or a combination of both. This data sheet can be analyzed with either the Crow-AMSAA (NHPP) model or the Crow Extended model.

For discrete data, corrective actions cannot take place at the time of failure. With that in mind, the mixed data type does not allow for BC modes. For discrete data there are only A or BD modes. In terms of practical applications, think of a growth test for missile systems. Because missiles are one-shot items, any corrective actions applied to the failure modes are delayed until at least the next trial.

Note that for calculation purposes, it is required to have at least three failures in the first interval. If that is not the case, then the data set needs to be grouped before calculating. The RGA software performs this operation in the background.

===Example===
{{:Mixed_Data_-_Crow_Extended_Example}}

==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 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 applicable only to data from within a single test phase.

As previously presented, the failure mode classifications for the Crow Extended model are defined as follows:

*'''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.

Therefore, implemented fixes can be applied only 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.

===Event Codes===
A Multiple Systems with Event Codes data sheet that is analyzed with the Crow Extended model has an '''Event''' column that allows you to indicate the types of events that occurred during a test phase. The possible event codes that can be used in the analysis are:

*'''''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.

*'''''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''' check box under Event Code Options on the Analysis tab.

*'''''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''' check box under Event Code Options on the Analysis tab.

*'''''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. The row of data with the ''X'' will not be included in the analysis.

*'''''S''''': indicates the system start time. This event code is only selectable in the Normal View.

*'''''F''''': indicates a failure time.

*'''''E''''': indicates the system end time. This event code is only selectable in the Normal View.

The analysis is based on the equivalent system that combines the operating hours of all the systems.

===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 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>
<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>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>.</li>
<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>
<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>
<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.
:::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.</li>
<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====
{{:Equivalent_System_Example}}

===Transferring Data to an Equivalent Single System===
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]]

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.

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.

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|center|450px]]

===Iteration Method for Naming Repeated Modes===
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.

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|center|450px]]

The RGA software will display a warning if you try to convert this data sheet without using iterations.

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

[[Image:rga9.28.png|center|450px]]

==More Examples==
===Adjusting the Failure Mode Management Strategy===
{{:Concurrent_Operating_Times_-_Crow_Extended_Example}}

===Estimating the Failure Intensity Remaining After Fixes===
{{:Grouped_Data_-_Crow_Extended_Example}}

===Determining if Design Will Meet MTBF Goal===
{{:Known_Operating_Times_-_Crow_Extended_Example}}

Crow Extended

2020-08-19T23:04:42Z

David J. Groebel: /* Mathematical Formulation */

{{template:RGA BOOK|3.3|Crow Extended}}
In reliability growth analysis, the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP) model]] assumes that the corrective actions for the observed failure modes are incorporated during the test (test-fix-test). However, in actual practice, fixes may be delayed until after the completion of the test (test-find-test) or some fixes may be implemented during the test while others are delayed (test-fix-find-test). At the end of a test phase, two reliability estimates are of concern: ''demonstrated reliability'' and ''projected reliability''. The demonstrated reliability, which is based on data generated during the test phase, is an estimate of the system reliability for its configuration at the end of the test phase. The projected reliability measures the impact of the delayed fixes at the end of the current test phase.
<br>

Most of the reliability growth literature are concerned with procedures and models for calculating the demonstrated reliability, and very little attention has been paid to techniques for reliability projections. The procedure for making reliability projections utilizes engineering assessments of the effectiveness of the delayed fixes for each observed failure mode. These effectiveness factors are then used with the data generated during the test phase to obtain a projected estimate for the updated configuration by adjusting the number of failures observed during the test phase. The process of estimating the projected reliability is accomplished using the Crow Extended model. The Crow Extended model allows for a flexible growth strategy that can include corrective actions performed during the test, as well as delayed corrective actions. The test-find-test and test-fix-find-test scenarios are simply subsets of the Crow Extended model.

For developmental testing, the Crow Extended model can be applied when using any of the following [[RGA_Data_Types|data types]]:

*Failure Times Data
*Multiple Systems (Known Operating Times)
*Multiple Systems (Concurrent Operating Times)
*Multiple Systems with Dates
*Multiple Systems with Event Codes
*Grouped Failure Times
*Mixed Data

As the name implies, Crow Extended is simply an "extension" of the Crow-AMSAA (NHPP) model. The calculations for Crow Extended still incorporate the methods for Crow-AMSAA based on the data type, as described on the [[Crow-AMSAA (NHPP)]] page. The Crow-AMSAA model estimates the growth during the test, while the Crow Extended model accounts for the growth after the test based on the delayed corrective actions. Additional details regarding the calculations for the Crow Extended model are presented in the sections below.

==Background==
When a system is tested and failure modes are observed, management can make one of two possible decisions: to fix or to not fix the failure modes. Failure modes that are not fixed are called ''A modes'' and failure modes that receive a corrective action are called ''B modes''. The A modes account for all failure modes that management considers to be not economical or not justified to receive corrective action. The B modes provide the assessment and management metric structure for corrective actions during and after a test. There are two types of B modes: BC modes, which are corrected during the test, and BD modes, which are corrected only at the end of the test. The management strategy is defined by how the corrective actions, if any, will be implemented. In summary, the classifications are defined as follows:

*'''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. BD modes will provide a jump in the system's MTBF at the termination time.

In terms of assessing a system's reliability, there are three specific metrics of interest:

*'''Demonstrated (or achieved) MTBF (DMTBF)''' is the system's instantaneous MTBF at the termination time.
*'''Projected MTBF (PMTBF)''' is the system's expected instantaneous MTBF after the implementation of the delayed corrective actions.
*'''Growth Potential MTBF (GPMTBF)''' is the maximum MTBF that can be attained for the system design and management strategy.

These metrics can also be displayed in RGA in terms of failure intensity (FI). The demonstrated MTBF is calculated using basically the same methods, depending on data type, as presented on the [[Crow-AMSAA (NHPP)]] page. Projected MTBF/FI and growth potential MTBF/FI are presented in detail in the sections below.

The following picture shows an example of data entered for the Crow Extended model.

[[Image:rga9.1.png|center|500px|Failure times data for a single system in cumulative format, including classification and mode information.]]

As you can see, each failure is indicated with A, BC or BD in the '''Classification''' column. In addition, any number or text can be used to specify the failure mode. In this example, numbers were used in the '''Mode''' column for simplicity, but you could just as easily use "Seal Leak," or whatever designation you deem appropriate for identifying the mode. In RGA, a failure mode is defined as a problem and a cause.

Reliability growth is achieved by decreasing the failure intensity. The failure intensity for the A failure modes will not change; therefore, reliability growth can only be achieved by decreasing the BC and BD mode failure intensity. In general, the only part of the BD mode failure intensity that can be decreased is that which has been seen during testing, since the failure intensity due to BD modes that were unseen during testing still remains. The BC failure modes are corrected during test, and the BC failure intensity will not change any more at the end of test.

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

:<math>Multiplier=\frac{1}{1-EF}</math>

Using this equation, an <math>EF=0.7\,\!</math> corresponds to an increase of 3.3X. Therefore, if a failure mode had an MTBF of 100 and a delayed fix was applied, an estimate of the failure mode's MTBF after the fix is equal to <math>\approx 333\,\!</math>. An <math>EF=0.9\,\!</math> corresponds to a 10X increase in the failure mode's MTBF. So there is a large increase between EF = 0.7 and EF = 0.9. Before assigning an EF to a BD mode, it is recommended to run a test to verify the fix and to validate the assumed EF value. Ideally, you want to have some sort of justification for using the entered EF value. If you do not know the EF value for each BD mode, then you can also specify a fixed EF which is then applied to all modes. The average value of EF = 0.7 is a good place to start, but if you want to be a bit more conservative, then an EF = 0.4, or a smaller value, could be used.

==Test-Find-Test==
Test-find-test is a testing strategy where all corrective actions are delayed until after the test. Therefore, there are not any BC modes when analyzing test-find-test data (only A and BD modes). This scenario is also called the ''Crow-AMSAA Projection'' model, but for the purposes of the RGA software, it is simply a special case of the Crow Extended model. The picture below presents the test-find-test scenario.

[[File:TestFindTest.png|center|400px|Test-find-test.]]

Since there are no fixes applied during the test, the assumption is that the system's MTBF does not change during the test. In other words, the system's MTBF is constant. The system should not be exhibiting an increasing or decreasing trend in its reliability if changes are not being made. Therefore, the assumption is that <math>\beta = 1\,\!</math>. RGA will return two <math>\beta\,\!</math> values; Beta (hyp) which always shows a value equal to 1 since this is the underlying assumption, and Beta which is the Crow-AMSAA (NHPP) estimate that considers all of the failure times. The assumption of <math>\beta = 1\,\!</math> can be verified by looking at the confidence bounds on <math>\beta\,\!</math>. If the confidence bounds on <math>\beta\,\!</math> include one, then you can fail to reject the hypothesis that <math>\beta = 1\,\!</math>. RGA does this check automatically and uses a confidence level equal to 1 minus the specified significance level to check if the confidence bounds on <math>\beta\,\!</math> include one. If the <math>\beta = 1\,\!</math> assumption is violated, then the value for Beta (hyp) will be displayed in red text. If the confidence bounds on <math>\beta\,\!</math> do not include 1, then the following questions should be considered as they relate to the data:

*If multiple systems were tested, did they have the same configuration throughout the test? Were the corrective actions applied to all systems?
*Were the test conditions consistent for each system?
*Was there a change in the failure definition?
*Any issues with data entry?

<math>\beta = 1\,\!</math> is then used to estimate the demonstrated MTBF of the system and it is also used in the goodness-of-fit tests.

===Projected Failure Intensity===
Suppose a system is subjected to development testing for a period of time, <math>T\,\!</math>. The system can be considered as consisting of two types of failure modes: A modes and BD modes. It is assumed that all BD modes are in series and fail independently according to the exponential distribution. Also assume that the rate of occurrence of A modes follows an exponential distribution with failure intensity <math>{{\lambda }_{A}}\,\!</math>. The system MTBF is constant throughout the test phase since all of the corrective actions are delayed until after the completion of the test. After the delayed fixes have been implemented, the system MTBF will then jump to a higher value.

Let <math>K\,\!</math> denote the total number of BD modes in the system, and let <math>{{\lambda }_{i}}\,\!</math> denote the failure intensity for the <math>{{i}^{th}}\,\!</math> BD mode, such that <math>i = 1,2,\ldots ,K\,\!</math>. Then, at time equal to zero, the system failure intensity <math>r(0)\,\!</math> is:

:<math>\begin{align}
r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}
\end{align}\,\!</math>

where:

:<math>{{\lambda }_{BD}}=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{\lambda }_{i}}\,\!</math>.

During the test <math>(0,T)\,\!</math>, a random number of <math>M\,\!</math> distinct BD modes will be observed, such that <math>M\le K\,\!</math>. Denote the effectiveness factor (EF) for the <math>{{i}^{th}}\,\!</math> BD mode as <math>{{d}_{i}}\,\!</math>, <math>i = 1,2,\ldots ,K\,\!</math>. The effectiveness factor <math>{{d}_{i}}\,\!</math> is the percent decrease in <math>{{\lambda }_{i}}\,\!</math> after a corrective action has been made for the <math>{{i}^{th}}\,\!</math> BD mode. That is, the corrective action for the <math>{{i}^{th}}\,\!</math> BD mode removes <math>100\times {{d}_{i}}\,\!</math> percent of the failure rate, and <math>100\times (1-{{d}_{i}})\,\!</math> percent remains. The failure intensity for the <math>{{i}^{th}}\,\!</math> BD failure mode after a corrective action is <math>(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>. If corrective actions are taken on the <math>M\,\!</math> BD modes observed by time <math>T\,\!</math>, then the system failure intensity is reduced from <math>r(0)\,\!</math> to:

:<math>\begin{align}
r\left( T \right) = & {{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,\left( 1-{{d}_{i}} \right){{\lambda }_{i}}+({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{\lambda }_{i}}) \\
= & {{\lambda }_{A}}+{{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}
\end{align}\,\!</math>

where:

*<math>\underset{i=1}{\overset{M}{\mathop{\sum }}}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math> is the failure intensity for the <math>M\,\!</math> modes after the corrective actions
*<math>({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop{\sum }}}\,{{\lambda }_{i}})\,\!</math> is the remaining failure intensity for all unseen BD modes

All <math>M\,\!</math> BD modes observed by test time <math>T\,\!</math> may not be fixed by time <math>T\,\!</math> so the actual failure intensity at time <math>T\,\!</math> may not be <math>r(T)\,\!</math>. However, <math>r(T)\,\!</math> can be viewed as the achieved failure intensity at time <math>T\,\!</math> if all fixes were updated and incorporated into the system. All of the fixes for the BD modes found during the test are incorporated as delayed fixes at the end of the test phase. Therefore, the system failure intensity is constant at <math>r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}\,\!</math> through the test phase and will then jump to a lower value <math>r(T)\,\!</math> after the delayed fixes have been implemented. Let <math>{{N}_{A}}\,\!</math> and <math>{{N}_{BD}}\,\!</math> be the total number of A and BD failures observed during the test <math>(0,T)\,\!</math> and let <math>N={{N}_{A}}+{{N}_{BD}}\,\!</math>. In addition, there are <math>M\,\!</math> distinct BD modes observed during the test. After implementing the <math>M\,\!</math> fixes, the failure intensity for the system at time <math>T\,\!</math> (after the jump) is given by the function <math>r(T)\,\!</math>.

<math>r(0)\,\!</math> is actually the demonstrated failure intensity, which is based on actual system performance of the hardware tested and not of some future configuration. A demonstrated reliability value should be determined at the end of each test phase. The demonstrated failure intensity is:

:<math>{{\hat{\lambda }}_{D}}(T)=r(0)=\frac{{{N}_{A}}+{{N}_{BD}}}{T}\,\!</math>

The demonstrated MTBF is given by:

:<math>\widehat{{MTBF}_{D}}={{[{{\hat{\lambda }}_{D}}(T)]}^{-1}}\,\!</math>

The detailed procedure for estimating <math>r(T)\,\!</math> is given in Crow [[RGA_References|[20]]] and is reviewed here.

Let <math>E[\cdot ]\,\!</math> denote the expected value:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}{{e}^{-{{\lambda }_{i}}T}}\,\!</math>

Under realistic assumptions, <math>E[r(T)]\,\!</math> also may be expressed as:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T)\,\!</math>

where <math>\overline{d}\,\!</math> is the mean effectiveness factor and <math>h(T)\,\!</math> is the instantaneous rate at which a new BD mode will occur at time <math>T\,\!</math>. <math>\overline{d}h(T)\,\!</math> is the bias term (or sometimes called the 3<sup>rd</sup> term), such that:

:<math>B(T)=\overline{d}h(T)\,\!</math>

The mean <math>\overline{d}\,\!</math> is given by:

:<math>\overline{d}=\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\,\!</math>

Therefore, the projected failure intensity <math>r(T)\,\!</math> is then estimated at the end of the test phase by:

:<math>\hat{r}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)+\overline{d}h(T)\,\!</math>

The projected MTBF is:

:<math>\widehat{{MTBF}_{P}}={{[r(T)]}^{-1}}\,\!</math>

===Mathematical Formulation===
As indicated previously, the failure intensity of the system at <math>t=0\,\!</math> is given by:

:<math>\begin{align}
{{\lambda }_{System}}= & {{\lambda }_{A}}+{{\lambda }_{BD}} \\
= & {{\lambda }_{A}}+{{\lambda }_{B{{D}_{Seen}}}}+{{\lambda }_{B{{D}_{Unseen}}}}
\end{align}\,\!</math>

The estimate for the projected failure intensity, after the corrective actions have been implemented, is then:

:<math>\begin{align}
{{\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}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\
= & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}+dh\left( t \right)
\end{align}\,\!</math>

This is the basic format of the equation for the projected failure intensity when the Crow Extended model is used with the test-find-test strategy.

===h(t) Function===
h(t) is defined as the unseen BD mode failure intensity. It is also defined as the rate at which new unique BD modes are being discovered. The maximum likelihood estimate of <math>h(t)\,\!</math> is calculated using:

:<math>\hat{h}\left( t \right)={{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{t}^{{{{\overline{\beta }}}_{BD}}-1}}\,\!</math>

where <math>{\overline{\beta }_{BD}}\,\!</math> is the unbiased estimate. The unbiased estimate is always used when calculating <math>\hat{h}\left( t \right)\,\!</math>.

The parameters of the <math>h(t)\,\!</math> function, <math>{{\beta }_{BD}}\,\!</math> and <math>{{\lambda }_{BD}}\,\!</math>, are calculated using the first occurrence of each BD mode. In order to have growth, <math>{{\beta }_{BD}}\,\!</math> must be less than one. If <math>{{\beta }_{BD}}\,\!</math> is close to one then it is possible that the program could be in trouble since this indicates that there are very few repeat occurrences. In this case, each failure tends to be a unique mode. If <math>{{\beta }_{BD}}\,\!</math> is less than one then the rate at which new unique BD modes are occurring is decreasing.

Let <math>{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{M}}<T\,\!</math> denote the cumulative test times for the first occurrences of BD modes. Then, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are:

:<math>{{\hat{\beta }}_{BD}}=\frac{M}{\underset{i=1}{\overset{M}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

The unbiased estimate of <math>{{\beta }_{BD}}\,\!</math> is:

:<math>{{\bar{\beta }}_{BD}}=\frac{M-1}{M}{{\hat{\beta }}_{BD}}\,\!</math>

:<math>{{\hat{\lambda }}_{BD}}=\frac{M}{{{T}^{{{{\overline{\beta }}}_{BD}}}}}\,\!</math>

In particular, the maximum likelihood estimate for the rate of occurrence for the distinct BD modes at the termination time, <math>T\,\!</math>, is:

:<math>\begin{align}
\hat{h}(T) = & {{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{T}^{{{\overline{\beta }}_{BD}}-1}} \\
= & \frac{M{{\overline{\beta }}_{BD}}}{T}
\end{align}\,\!</math>

The parameters associated with <math>h(t)\,\!</math> can be viewed in RGA by selecting '''BD modes''' from the dropdown to the right of '''Results (All Modes)''' in the Results Area on the control panel to the right of the data sheet. The displayed value for the failure intensity, '''FI''', is <math>h(T)\,\!</math>.

===Growth Potential===
Growth Potential, when represented in terms of MTBF, is the maximum system reliability that can be attained for the system design with the current management strategy. The maximum MTBF will be attained when all <math>K\,\!</math> BD modes have been observed and fixed with EFs <math>{{d}_{i}}\,\!</math>. If the system is tested long enough then the failures that are observed in this case will be either repeat BD modes or A modes. In other words, there is not another unique BD mode to find within the system, and in most cases the growth potential is a value that may never actually be achieved. The growth potential can be thought of as an upper bound on the system's MTBF and ideally, should be about 30% above the system's requirement. As the system's MTBF gets closer to the growth potential, it becomes more difficult to increase the system's MTBF because it is taking more and more test time to propagate the next unique BD mode. The BD modes present opportunities for growth, but the rate of occurrence for unique BD modes goes down due to the decrease in <math>h(t)\,\!</math>. The growth potential is reached when <math>h(t)\,\!</math> is equal to zero. In other words, the difference between the projected failure intensity and the growth potential is <math>h(t)\,\!</math>. At about 2/3 of the growth potential it becomes increasingly difficult to increase the system's MTBF as <math>h(t)\,\!</math> function starts to flatten out.

The failure intensity <math>r(T)\,\!</math> will depend on the management strategy that determines the classification of the A and BD failure modes. The engineering effort applied to the corrective actions determines the effectiveness factors. In addition, <math>r(T)\,\!</math> depends on <math>h(t)\,\!</math>, which is the rate at which problem failure modes are being seen during testing. <math>h(t)\,\!</math> drives the opportunity to take corrective actions based on the seen failure modes and it is an important factor in the overall reliability growth rate. The reliability growth potential is the limiting value of <math>r(T)\,\!</math> as <math>T\,\!</math> increases. This limit is the maximum MTBF that can be attained with the current management strategy. In terms of failure intensity, the growth potential is expressed by the following equation:

:<math>{{r}_{GP}}={{\lambda }_{A}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>

In terms of the MTBF, the growth potential is given by:

:<math>\begin{align}
MTB{{F}_{GP}}=1/{{r}_{GP}}
\end{align}\,\!</math>

The procedure for estimating the growth potential is as follows. Suppose that the system is tested for a period of time <math>T\,\!</math> and that <math>N\,\!</math> failures have been observed. According to the management strategy, <math>{{N}_{A}}\,\!</math> of these failures are A modes and <math>{{N}_{BD}}\,\!</math> of these failures are BD modes. For the BD modes, there will be <math>M\,\!</math> distinct fixes. As before, <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. From this data, the growth potential failure intensity is estimated by:

:<math>{{\hat{r}}_{GP}}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)\,\!</math>

The growth potential MTBF is estimated by:

:<math>M\hat{T}B{{F}_{GP}}={{[{{\hat{r}}_{GP}}]}^{-1}}\,\!</math>

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

==Test-Fix-Find-Test==
Traditional reliability growth models provide assessments for two types of testing and corrective action strategies: ''test-fix-test'' and ''test-find-test''. In test-fix-test, failure modes are found during testing and corrective actions for these modes are incorporated during the test. Data from this type of test can be modeled appropriately with the [[Crow-AMSAA (NHPP)|Crow-AMSAA model]]. In test-find-test, modes are found during testing, but all of the corrective actions are delayed and incorporated after the completion of the test. Data from this type of test can be modeled appropriately with the Crow-AMSAA Projection model, which was described above in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]]. However, a common strategy involves a combination of these two approaches, where some corrective actions are incorporated during the test and some corrective actions are delayed and incorporated at the end of the test. This strategy is referred to as ''test-fix-find-test''. Data from this test can be modeled appropriately with the Crow Extended reliability growth model, which is described next.

Recall that B failure modes are all failure modes that will receive a corrective action. In order to provide the assessment and management metric structure for corrective actions during and after a test, two types of B modes are defined. BC failure modes are corrected during the test and BD failure modes are delayed until the end of the test. Type A failure modes are defined as before; (i.e., those failure modes that will not receive a corrective action, either during or at the end of the test).

===Development of the Crow Extended Model===
Let <math>{{\lambda }_{BD}}\,\!</math> denote the constant failure intensity for the BD failure modes, and let <math>h(t|BD)\,\!</math> denote the first occurrence function for the BD failure modes. In addition, as before, let <math>K\,\!</math> be the number of BD failure modes, let <math>{{d}_{i}}\,\!</math> be the effectiveness factor for the <math>{{i}^{th}}\,\!</math> BD failure mode and let <math>\overline{d}\,\!</math> be the average effectiveness factor.

The Crow Extended model projected failure intensity is given by:

:<math>{{\lambda }_{EM}}={{\lambda }_{CA}}-{{\lambda }_{BD}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T|BD)\,\!</math>

where <math>{{\lambda }_{CA}}=\lambda \beta {{T}^{\beta -1}}\,\!</math> is the achieved failure intensity at time <math>T\,\!</math>.

The Crow Extended model projected MTBF is:

:<math>\begin{align}
{{M}_{EM}}=1/{{\lambda }_{EM}}
\end{align}\,\!</math>

This is the MTBF after the delayed fixes have been implemented. Under the extended reliability growth model, the demonstrated failure intensity before the delayed fixes is the first term, <math>{{\lambda }_{CA}}\,\!</math>. The demonstrated MTBF at time <math>T\,\!</math> before the delayed fixes is given by:

:<math>{{M}_{CA}}\text{ }={{[{{\lambda }_{CA}}]}^{-1}}\,\!</math>

If you assume that there are no delayed corrective actions (BD modes), then the model reduces to a special case of the Crow-AMSAA model where the achieved MTBF equals the projection, <math>\lambda_{CA}\,\!</math>. That is, there is no jump. If you assume that there are no corrective actions during the test (BC modes) then the model reduces to the test-find-test scenario described in the previous section.

===Estimation of the Model===
In the general estimation of the Crow Extended model, it is required that all failure times during the test are known. Furthermore, the ID of each A, BC and BD failure mode needs to be entered.

The estimate of the projected failure intensity for the Crow Extended model is given by:

:<math>{{\widehat{\lambda }}_{EM}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}+\overline{d}\widehat{h}(T|BD)\,\!</math>

where <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. In order to obtain the first term, <math>{{\widehat{\lambda }}_{CA}}\,\!</math>, fit all of the data (regardless of mode classification) to the Crow-AMSAA model to estimate <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math>, thus:

:<math>{{\widehat{\lambda }}_{CA}}=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

The remaining terms are analyzed with the Crow Extended model, which is applied only to the BD data.

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>
:<math>\begin{align}
\widehat{h}(T|BD) = & {{\widehat{\lambda }}_{BD}}{{\widehat{\beta }}_{BD}}{{T}^{{{\widehat{\beta }}_{BD}}-1}} \\
= & \frac{M{{\widehat{\beta }}_{BD}}}{T}
\end{align}\,\!</math>

<math>{{\widehat{\beta }}_{BD}}\,\!</math> is the unbiased estimated of <math>\beta \,\!</math> for the Crow-AMSAA model based on the first occurrence of <math>M\,\!</math> distinct BD modes.

The structure for the Crow Extended model includes the following special data analysis cases:

#Test-fix-test with no failure modes known or with BC failure modes known. With this type of data, the Crow Extended model will take the form of the [[Crow-AMSAA (NHPP)|traditional Crow-AMSAA analysis]].
#Test-find-test with BD failure modes known. With this type of data, the Crow Extended model will take the form of the Crow-AMSAA Projection analysis described previously in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]].
#Test-fix-find-test with BC and BD failure modes known. With this type of data, the full capabilities of the Crow Extended model will be applied, as described in the following sections.

===Reliability Growth Potential and Maturity Metrics===
The growth potential and some maturity metrics for the Crow Extended model are calculated as follows.

*Initial system MTBF and failure intensity are given by:

:<math>{{\widehat{M}}_{I}}=\frac{\Gamma \left( 1+\tfrac{1}{\widehat{\beta }} \right)}{{{\widehat{\lambda }}^{\tfrac{1}{\widehat{\beta }}}}}\,\!</math>

and:

:<math>{{\widehat{\lambda }}_{I}}={{[{{\widehat{M}}_{I}}]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for all data regardless of the failure mode classification (i.e., A, BC or BD).

*The A mode failure intensity and MTBF are given by:

:<math>{{\widehat{\lambda }}_{A}}=\frac{{{N}_{A}}}{T}\,\!</math>

:<math>{{\widehat{M}}_{A}}={{[{{\widehat{\lambda }}_{A}}]}^{-1}}\,\!</math>

*The Initial BD mode failure intensity is given by:

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>

*The BC mode initial failure intensity and MTBF are given by:

:<math>{{\widehat{\lambda }}_{I(BC)}}={{\widehat{\lambda }}_{I}}-{{\widehat{\lambda }}_{A}}-{{\widehat{\lambda }}_{BD}}\,\!</math>

:<math>{{\widehat{M}}_{I(BC)}}={{[{{\widehat{\lambda }}_{I(BC)}}]}^{-1}}\,\!</math>

*Failure intensity <math>h(T|BC)\,\!</math> and instantaneous MTBF <math>M(T|BC)\,\!</math> for new BC failure modes at the end of test time <math>T\,\!</math> are given by:

:<math>\widehat{h}(T|BC)=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

:<math>\widehat{M}(T|BC)={{[\widehat{h}(T|BC)]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for the first occurrence of distinct BC modes.

*Average effectiveness factor for BC failure modes is given by:

:<math>{{\widehat{d}}_{BC}}=\frac{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{N}_{BC}}}{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{M}_{BC}}}\,\!</math>

:where <math>{{N}_{BC}}\,\!</math> is the total number of observed BC modes, <math>{{M}_{BC}}\,\!</math> is the number of unique BC modes and <math>{{\hat{\beta }}_{BC}}\,\!</math> is the MLE for the first occurrence of distinct BC modes. If <math>{{\hat{\beta }}_{BC}}\ge 1\,\!</math> then <math>{{\widehat{d}}_{BC}}\,\!</math> equals zero.

*Growth potential failure intensity and growth potential MTBF are given by:

:<math>{{\widehat{\lambda }}_{GP}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}\,\!</math>

:<math>{{\widehat{M}}_{GP}}={{[{{\widehat{\lambda }}_{GP}}]}^{-1}}\,\!</math>

===Failure Mode Management 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|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.

Let:

:<math>\hat{r}(T)=\hat{\lambda }\hat{\beta }{{T}^{\hat{\beta }-1}}\,\!</math>

where <math>T\,\!</math> is the test time and <math>\hat{\beta }\,\!</math> and <math>\hat{\lambda }\,\!</math> are the maximum likelihood estimates of the Crow-AMSAA model for all of the data. <math>\hat{\beta }\,\!</math> is the biased estimate of <math>\beta \,\!</math>. Therefore:

:<math>\hat{\beta }=\frac{N}{\underset{i=1}{\overset{N}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

:<math>\hat{\lambda }=\frac{N}{{{T}^{{\hat{\beta }}}}}\,\!</math>

where <math>N\,\!</math> is the total number of failures, and <math>{{X}_{i}}\,\!</math> is the <math>{{i}^{th}}\,\!</math> time-to-failure. Let the successive failures <math>0<{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{3}}<{{X}_{N}}\,\!</math> be partitioned into the A mode failures ( <math>{{N}_{A}}\,\!</math> ), BC first occurrence failures ( <math>{{N}_{BCF}}\,\!</math> ), BC remaining failures ( <math>{{N}_{BCR}}\,\!</math> ), BD first occurrence failure ( <math>{{N}_{BDF}}\,\!</math> ) and the BD remaining failures ( <math>{{N}_{BDR}}\,\!</math> ). For continuous data, each portion of the pie chart, due to each of the modes, is calculated as follows:

*A modes

:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{A}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{Ai}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
B{{D}_{remain}} = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\
= & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\
= & \overline{d}\cdot B{{D}_{seen}}
\end{align}\,\!</math>

For grouped data, the maximum likelihood estimates of <math>\beta \,\!</math> and <math>\lambda \,\!</math> from the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP)]] model are calculated such that the following equations are satisfied:

:<math>\underset{i=1}{\overset{K}{\mathop \sum }}\,{{N}_{i}}\left[ \frac{t_{i}^{{\hat{\beta }}}\ln ({{t}_{i}})-t_{i-1}^{{\hat{\beta }}}\ln ({{t}_{i-1}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-\ln T \right]=0\,\!</math>

:<math>\hat{\lambda }=\frac{N}{T_{K}^{{\hat{\beta }}}}\,\!</math>

where <math>K\,\!</math> is the number of groups and <math>N=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{N}_{i}}\,\!</math>.

*A modes

:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{A}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{Ai}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
B{{D}_{remain}} = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\
= & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\
= & \overline{d}\cdot B{{D}_{seen}}
\end{align}\,\!</math>

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

==Confidence Bounds==
The RGA software provides two methods to estimate the confidence bounds for the Crow Extended model when applied to developmental testing data. The Fisher Matrix approach is based on the Fisher Information Matrix and is commonly employed in the reliability field. The Crow bounds were developed by Dr. Larry Crow.

See the [[Crow Extended Confidence Bounds]] chapter for details on how these confidence bounds are calculated.

===Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example}}

===Another Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example_2}}

==Grouped Data== 

Parameter estimation for grouped data using the Crow Extended model is the same as the procedure used for the traditional [[Crow-AMSAA (NHPP)#Grouped_Data| Crow-AMSAA (NHPP)]] model. The equations used to estimate the parameters of the Crow Extended model are presented next. For test-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are calculated using the first occurrences of the BD modes such that:

:<math>\underset{i=1}{\overset{k}{\mathop \sum }}\,{{n}_{i}}\left[ \frac{T_{i}^{\widehat{\beta }}\ln {{T}_{i}}-T_{i-1}^{\widehat{\beta }}\ln {{T}_{i-

1}}}{T_{i}^{\widehat{\beta }}-T_{i-1}^{\widehat{\beta }}}-\ln {{T}_{k}} \right]=0\,\!</math>

:<math>\widehat{\lambda }=\frac{n}{T_{k}^{\widehat{\beta }}}\,\!</math>

where <math>{{n}_{i}}\,\!</math> is the number of distinct BD modes within the <math>{{i}^{th}}\,\!</math> interval. For test-fix-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BC}}\,\!</math> and <math>{{\beta }_{BC}}\,\!</math> are estimated in the same manner using the first occurrences of the BC modes.

===Confidence Bounds for Grouped Data===
*'''Parameters:''' The confidence bounds on the parameters for the Crow Extended model for grouped data are calculated using the same procedure presented in the [[Crow-AMSAA_Confidence_Bounds|Crow-AMSAA Confidence Bounds]] chapter.
*'''Failure Intensity and MTBF:'''
**If there are no BC modes, the confidence bounds on the demonstrated failure intensity and MTBF, projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as the procedure presented for [[Crow Extended Confidence Bounds|non-grouped data]].
**If there are BC modes, then the confidence bounds on the demonstrated failure intensity and MTBF are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter, and the confidence bounds on the projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as for non-grouped data.
*'''Time:''' The confidence bounds on time are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter.

==Mixed Data==
The Crow Extended model can also be applied to discrete data from one-shot (success/failure) testing. In the RGA software, the '''Discrete Data > Mixed Data''' option creates a data sheet that can accommodate data from tests where a single unit is tested for each successive configuration (individual trial-by-trial), where multiple units are tested for each successive configuration (configurations in groups) or a combination of both. This data sheet can be analyzed with either the Crow-AMSAA (NHPP) model or the Crow Extended model.

For discrete data, corrective actions cannot take place at the time of failure. With that in mind, the mixed data type does not allow for BC modes. For discrete data there are only A or BD modes. In terms of practical applications, think of a growth test for missile systems. Because missiles are one-shot items, any corrective actions applied to the failure modes are delayed until at least the next trial.

Note that for calculation purposes, it is required to have at least three failures in the first interval. If that is not the case, then the data set needs to be grouped before calculating. The RGA software performs this operation in the background.

===Example===
{{:Mixed_Data_-_Crow_Extended_Example}}

==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 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 applicable only to data from within a single test phase.

As previously presented, the failure mode classifications for the Crow Extended model are defined as follows:

*'''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.

Therefore, implemented fixes can be applied only 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.

===Event Codes===
A Multiple Systems with Event Codes data sheet that is analyzed with the Crow Extended model has an '''Event''' column that allows you to indicate the types of events that occurred during a test phase. The possible event codes that can be used in the analysis are:

*'''''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.

*'''''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''' check box under Event Code Options on the Analysis tab.

*'''''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''' check box under Event Code Options on the Analysis tab.

*'''''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. The row of data with the ''X'' will not be included in the analysis.

*'''''S''''': indicates the system start time. This event code is only selectable in the Normal View.

*'''''F''''': indicates a failure time.

*'''''E''''': indicates the system end time. This event code is only selectable in the Normal View.

The analysis is based on the equivalent system that combines the operating hours of all the systems.

===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 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>
<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>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>.</li>
<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>
<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>
<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.
:::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.</li>
<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====
{{:Equivalent_System_Example}}

===Transferring Data to an Equivalent Single System===
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]]

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.

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.

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|center|450px]]

===Iteration Method for Naming Repeated Modes===
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.

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|center|450px]]

The RGA software will display a warning if you try to convert this data sheet without using iterations.

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

[[Image:rga9.28.png|center|450px]]

==More Examples==
===Adjusting the Failure Mode Management Strategy===
{{:Concurrent_Operating_Times_-_Crow_Extended_Example}}

===Estimating the Failure Intensity Remaining After Fixes===
{{:Grouped_Data_-_Crow_Extended_Example}}

===Determining if Design Will Meet MTBF Goal===
{{:Known_Operating_Times_-_Crow_Extended_Example}}

Main Page

2020-08-19T22:09:02Z

David J. Groebel:

{{DISPLAYTITLE:ReliaWiki}} __NOTOC__ __NOEDITSECTION__
<div style="position:relative; float:left; display:block; width:100%; margin:10px;">
ReliaWiki is owned and maintained by [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=p8TH7lvo8O%2FAHl72KXuPWlZmIR3P7GFj HBM Prenscia] and is an extension of [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=vQQfu%2FkoXaOAQyVYZnqaSTIPBB24C0kx weibull.com]. Due to continuous improvement to ReliaSoft software, the product images and step-by-step instructions featured on ReliaWiki may not reflect the current version.
</div>

<div style="position:relative; float:left; width:100%;">

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=blue_triangle.png
|title=Life Data Analysis
|links=
{{TitleBoxLink|link=Life_Data_Analysis_Reference_Book|text=Reference Book}}
{{TitleBoxLink|link=Weibull++_Examples|text=Weibull++ Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=green_triangle.png
|title=System Analysis (RBDs and Fault Trees)
|links=
{{TitleBoxLink|link=System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=BlockSim_Examples|text=BlockSim Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=red_triangle.png
|title=Reliability Growth and Repairable System Analysis
|links=
{{TitleBoxLink|link=Reliability_Growth_and_Repairable_System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=RGA_Examples|text=RGA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=rcm_triangle.png
|title=Reliability Centered Maintenance (RCM)
|links=
{{TitleBoxLink|link=RCM%2B%2B_Examples|text=RCM++ Software Examples}}
}}
</div>

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=yellow_triangle.png
|title=Accelerated Life Testing Data Analysis
|links=
{{TitleBoxLink|link=Accelerated Life Testing Data Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=ALTA_Examples|text=ALTA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=doe_triangle.png
|title=Experiment Design and Analysis (DOE)
|links=
{{TitleBoxLink|link=Experiment_Design_and_Analysis_Reference|text=Reference Book}}

}}

{{TitleBox
|bgcolor=#C8D4E0
|image=fmea_triangle.png
|title=Failure Modes & Effects Analysis (FMEA)
|links=
{{TitleBoxLink|link=FMEA_and_RCM_Articles|text=Articles}}
{{TitleBoxLink|link=Xfmea_Examples|text=Xfmea Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=api_triangle.png
|title=ReliaSoft API
|links=
{{TitleBoxLink|link=ReliaSoft API Reference|text=API Reference}}
{{TitleBoxLink|link=API_Changelog|text=API Changelog}}
}}
</div>
</div>
<div style="position:relative; float:left; width:100%;">
<br><br><cshow logged="1">This text will appear if a user with membership to 'sysop' group views this page</cshow> {{ReliaSoft Footer}}
</div>

Main Page

2020-08-19T22:08:49Z

David J. Groebel:

{{DISPLAYTITLE:ReliaWiki}} __NOTOC__ __NOEDITSECTION__
<div style="position:relative; float:left; display:block; width:100%; margin:10px;">
ReliaWiki is owned and maintained by [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=p8TH7lvo8O%2FAHl72KXuPWlZmIR3P7GFj HBM Prenscia] and is an extension of [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=vQQfu%2FkoXaOAQyVYZnqaSTIPBB24C0kx weibull.com]. Due to continuous improvement to ReliaSoft software, the product images and step-by-step instructions featured on ReliaWiki may not reflect the current version.
</div>

<div style="position:relative; float:left; width:100%;">

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=blue_triangle.png
|title=Life Data Analysis TEST
|links=
{{TitleBoxLink|link=Life_Data_Analysis_Reference_Book|text=Reference Book}}
{{TitleBoxLink|link=Weibull++_Examples|text=Weibull++ Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=green_triangle.png
|title=System Analysis (RBDs and Fault Trees)
|links=
{{TitleBoxLink|link=System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=BlockSim_Examples|text=BlockSim Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=red_triangle.png
|title=Reliability Growth and Repairable System Analysis
|links=
{{TitleBoxLink|link=Reliability_Growth_and_Repairable_System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=RGA_Examples|text=RGA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=rcm_triangle.png
|title=Reliability Centered Maintenance (RCM)
|links=
{{TitleBoxLink|link=RCM%2B%2B_Examples|text=RCM++ Software Examples}}
}}
</div>

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=yellow_triangle.png
|title=Accelerated Life Testing Data Analysis
|links=
{{TitleBoxLink|link=Accelerated Life Testing Data Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=ALTA_Examples|text=ALTA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=doe_triangle.png
|title=Experiment Design and Analysis (DOE)
|links=
{{TitleBoxLink|link=Experiment_Design_and_Analysis_Reference|text=Reference Book}}

}}

{{TitleBox
|bgcolor=#C8D4E0
|image=fmea_triangle.png
|title=Failure Modes & Effects Analysis (FMEA)
|links=
{{TitleBoxLink|link=FMEA_and_RCM_Articles|text=Articles}}
{{TitleBoxLink|link=Xfmea_Examples|text=Xfmea Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=api_triangle.png
|title=ReliaSoft API
|links=
{{TitleBoxLink|link=ReliaSoft API Reference|text=API Reference}}
{{TitleBoxLink|link=API_Changelog|text=API Changelog}}
}}
</div>
</div>
<div style="position:relative; float:left; width:100%;">
<br><br><cshow logged="1">This text will appear if a user with membership to 'sysop' group views this page</cshow> {{ReliaSoft Footer}}
</div>

CScheduledTask.SetPools Method

2020-05-04T17:03:00Z

David J. Groebel:

{{DISPLAYTITLE:cScheduledTask.SetPools Method}}{{Template:API}}{{Template:APIBreadcrumb|.[[CScheduledTask_Class|cScheduledTask]]}}

<onlyinclude>Sets the Pool IDs and number of parts for all pools required for the task.</onlyinclude>

'''Remarks''': Alternatively, .NET users can use the <code>Pools()</code> property in the class to get or set the crew IDs.

== Syntax ==
'''.SetPools'''({{APIPrefix|ByRef}} ''arr()'')

===Parameters===
''arr()''
:Required as [[PoolInfo|PoolInfo]]. An array of the Pool IDs and the number of parts for all pools required for the task.

== Example ==
This example assumes that the repository contains existing pools.
'''VBA'''

{{APIComment|...}}

{{APIComment|'Add code to create a new task or get an existing task.}}
{{APIPrefix|Dim}} aTask {{APIPrefix|As}} cScheduledTask
{{APIComment|...}}

{{APIComment|'Create an array and define the pools to be assigned. For this example,}}
{{APIComment|'assume that Pool ID#2 and ID#4 are to be assigned to the task with 3 and 5 parts, respectively.}}
{{APIPrefix|Dim}} myarray(1) {{APIPrefix|As PoolInfo}}
myarray(0).ID = 2
myarray(0).NumParts = 3
myarray(1).ID = 4
myarray(1).NumParts = 5

{{APIComment|'Assign the pools to the task.}}
{{APIPrefix|Call}} aTask.SetPools(myarray)

CCorrectiveTask.SetPools Method

2020-05-04T17:02:21Z

David J. Groebel:

{{DISPLAYTITLE:cCorrectiveTask.SetPools Method}}{{Template:API}}{{Template:APIBreadcrumb|.[[CCorrectiveTask_Class|cCorrectiveTask]]}}

<onlyinclude>Sets the Pool IDs and number of parts for all pools required for the task.</onlyinclude>

'''Remarks''': Alternatively, .NET users can use the <code>Pools()</code> property in the class to get or set the crew IDs.

== Syntax ==
'''.SetPools'''({{APIPrefix|ByRef}} ''arr()'')

===Parameters===
''arr()''
:Required as [[PoolInfo|PoolInfo]]. An array of the Pool IDs and the number of parts for all pools required for the task.

== Example ==
This example assumes that the repository contains existing pools.
'''VBA'''

{{APIComment|...}}

{{APIComment|'Add code to create a new task or get an existing task.}}
{{APIPrefix|Dim}} aTask {{APIPrefix|As}} cCorrectiveTask
{{APIComment|...}}

{{APIComment|'Create an array and define the pools to be assigned. For this example,}}
{{APIComment|'assume that Pool ID#2 and ID#4 are to be assigned to the task with 3 and 5 parts, respectively.}}
{{APIPrefix|Dim}} myarray(1) {{APIPrefix|As PoolInfo}}
myarray(0).ID = 2
myarray(0).NumParts = 3
myarray(1).ID = 4
myarray(1).NumParts = 5

{{APIComment|'Assign the pools to the task.}}
{{APIPrefix|Call}} aTask.SetPools(myarray)

CScheduledTask Class

2019-05-28T16:28:01Z

David J. Groebel: /* Properties */

{{DISPLAYTITLE:cScheduledTask Class}}{{Template:API}}{{Template:APIBreadcrumb}}

<onlyinclude>Represents a scheduled task resource. The task may be a preventive maintenance, inspection or on condition task.</onlyinclude>

==Constructors==
{| {{APITable}}
|-
|style="width: 240px;"|cScheduledTask||Creates an instance of the cSheduledTask class.
|-
|[[CScheduledTask_Constructors|cScheduledTask()]]||{{:CScheduledTask_Constructors}}
|}

==Methods==
{| {{APITable}}
|-
|style="width: 240px;"|[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]||{{:CScheduledTask.OnCondGetTeams_Method}}
|-
|[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]||{{:CScheduledTask.OnCondSetTeams_Method}}
|-
|[[CScheduledTask.GetPools_Method|GetPools]]||{{:CScheduledTask.GetPools_Method}}
|-
|[[CScheduledTask.SetPools_Method|SetPools]]||{{:CScheduledTask.SetPools_Method}}
|-
|[[CScheduledTask.GetTeams_Method|GetTeams]]||{{:CScheduledTask.GetTeams_Method}}
|-
|[[CScheduledTask.SetTeams_Method|SetTeams]]||{{:CScheduledTask.SetTeams_Method}}
|}

==Properties==
{| {{APITable}}
|-
| style="width: 240px;"|BringItemDown||Indicates whether the task brings the item down. '''Boolean'''. Default value = True.
|-
|BringSystemDown||Indicates whether the task brings the system down. '''Boolean'''. Default value = False.
|-
|Condition||Gets or sets a description of the condition that indicates that a failure will occur (for reliability centered maintenance analysis), such as a threshold for a measurement of wear, vibration, etc. '''String'''.
|-
|DurationModelID||Gets or sets the numeric ID of the model that represents the duration of the task. '''Integer'''
|-
|GroupIDs()||Gets an array containing the numeric IDs of the selected maintenance groups when the task is performed based on maintenance groups. (.NET only) '''Long'''.
|-
|ID||Gets the numeric ID of the task. '''Integer'''.
|-
|Intervals()||Gets or sets an array containing the interval start values when the task is performed based on dynamic intervals. '''Double'''.
|-
|{{Template:API_TxtIdentifiers}}
|-
|[[CScheduledTask.MaintenanceTriggers|MaintenanceTriggers]]||{{:CScheduledTask.MaintenanceTriggers}}
|-
|MiscCostModelID||Gets or sets the numeric ID of the model that represents the task's cost per task. Applies to preventive and inspection tasks. '''Integer'''.
|-
|MiscCostPerTimeModelID||Gets or sets the numeric ID of the model that represents the task's downtime rate ($/Hr). Applies to preventive and inspection tasks. '''Integer'''.
|-
|Name||Gets or sets the task's name. '''String'''.
|-
|OCMiscCostModelID||Gets or sets the numeric ID of the model that represents the task's cost per task. Applies to on condition tasks upon detection. '''Integer'''.
|-
|OCMiscCostPerTimeModelID||Gets or sets the numeric ID of the model that represents the task's downtime rate($/Hr). Applies to on condition tasks upon detection.'''Integer'''.
|-
|OnCondBringItemDown||Indicates whether the task brings the item down. Applies to on condition tasks upon detection. '''Boolean'''. Default value = True.
|-
|OnCondBringSystemDown||Indicates whether the task brings the system down. Applies to on condition tasks upon detection. '''Boolean'''. Default value = False.
|-
|OnCondDurationModelID||Gets or sets the numeric ID of the model that represents the duration of the task. Applies to on condition tasks upon detection. '''Integer'''.
|-
|OnCondFailureDetectionThreshold||Gets or sets the value for the task's failure detection threshold interval (0.9 = 90% percent of life). '''Double'''. Default value = 0.9.
|-
|OnCondPFInterval||Gets or sets the value for the task's prior-to-failure (P-F) interval. '''Double'''. Default value = 100.
|-
|OnCondPFIntervalUnitID||Gets or sets the numeric ID of the unit of measurement applied to the P-F interval. '''Integer'''.
|-
|OnCondResFactorValue||Gets or sets the on condition task's restoration amount. A value of 1 indicates an "as good as new" condition," a value of 0 indicates an "as bad as old" condition. A value between 0 and 100 indicates partial restoration. '''Double'''. Default value = 1.
|-
|OnCondResFactorType||Gets or set a value from the '''[[TaskRestorationTypeEnum Enumeration|TaskRestorationTypeEnum]]''' enumeration, which specifies the effect of the restoration. Default value = 1 (restores all accumulated damage).
|-
|OnCondTeams||Returns a '''{{APIPrefix|List}}(Of [[TeamInfo Class|TeamInfo]])''' containing teams assigned for the 'On condition' task (in the order of priority). (.NET Only)
|-
|OnCondUsePFInterval||Indicates whether the prior-to-failure (P-F) interval should be used to detect imminent failures. '''Boolean'''. If true, specify a value for OnCondPFInterval; if false, specify a value for OnCondFailureDetectionThreshold. Default value = False.
|-
|PackageID||Gets the numeric ID of the task package that will override the task's scheduling properties (0 = no override). '''Integer'''.
|-
|PerformTaskEvenIfItBringsSysDown||Indicates whether the task should be performed if bringing the item down causes the system to go down. '''Boolean'''. Default value = True.
|-
|PerformTaskEvenIfItemAlreadyFailed||Indicates whether the task should be performed even if the item failed before the task was scheduled to occur. '''Boolean'''. Default value = False.
|-
|Pools||Returns the list containing spare pool ID and the number of parts for each pool assigned for the task as a new list of [[PoolInfo|PoolInfo]] (.NET only). In case of duplicate entries (same pool ID), the latest entry takes preference.
|-
|ProjectID||Gets the numeric ID of the project the task belongs to. '''Integer'''.
|-
|PropInterval||Gets or sets the interval value that was initially proposed for the task (for reliability centered maintenance analysis). '''Variant'''.
|-
|PropIntervalUnitID||Gets or sets numeric ID for the unit of measurement applied to the proposed interval. '''Integer'''.
|-
|RefDoc||Gets or sets the description for the reference document that provides more detailed information about the task (for reliability centered maintenance analysis). '''String'''.
|-
|ResFactorType||Gets or sets a value from the '''[[TaskRestorationTypeEnum Enumeration|TaskRestorationTypeEnum]]''' enumeration, which specifies the effect of the restoration. Default value = 1 (restores all accumulated damage).
|-
|ResFactorValue||Gets or sets the scheduled task's restoration amount. A value of 1 indicates an "as good as new" condition," a value of 0 indicates an "as bad as old" condition. A value between 0 and 100 indicates partial restoration. '''Double'''. Default value = 1.
|-
|Status||Gets or sets the status of the task (for reliability centered maintenance analysis). '''String'''.
|-
|TaskAccess||Gets or sets the access that will be required in order to perform the task (typically for aircraft MSG-3 analyses). '''String'''.
|-
|TaskClass||Gets or set one of the values of the '''[[TaskClassEnum Enumeration|TaskClassEnum]]''', which specifies the task's class (e.g., preventive task, inspection or on condition). Default value = 0 (preventive task).
|-
|TaskFrequencyID||Gets or sets a value from the '''[[TaskFrequencyEnum Enumeration|TaskFrequencyEnum]]''', which specifies the frequency at which the task is performed. Default value = 5 (whenever system is down).
|-
|TaskFrequencyUnitID||Gets or sets the numeric ID of the unit of measurement of the intervals at which the task is performed. '''Integer'''.
|-
|TaskFrequencyValue||Gets or sets the fixed interval at which the task is performed. '''Double'''. Default value = 1.
|-
|TaskFreqValueVariableID||Gets or sets the numeric ID of the variable that represents the fixed interval at which the task is performed. '''Integer'''.
|-
|TaskTypeID||Gets or sets the numeric ID of the RCM++ or RBI task type (1 = the first task type defined in the repository). '''Integer'''. Default value = -1, which indicates no task type is available.
|-
|TaskZone||Gets or sets the zone of the system in which the task will be performed (aircraft MSG-3 analyses). '''String'''.
|-
|Teams||Returns the list containing teams assigned for the task (in the order of priority). '''List(Of [[TeamInfo Class|TeamInfo]])'''. (.NET Only)
|-
|UDD1||Gets or sets the text in the first user-defined drop-down field. Only applicable to RCM++. (Limited to 50 characters.) '''String'''.
|-
|UDD2||Gets or sets the text in the second user-defined drop-down field. Only applicable to RCM++. (Limited to 50 characters.) '''String'''.
|-
|UDT1||Gets or sets the date in the first user-defined date field. Only applicable to RCM++. '''Variant'''.
|-
|UDT2||Gets or sets the date in the second user-defined date field. Only applicable to RCM++. '''Variant'''.
|-
|UN1||Gets or sets the value in the first user-defined number field. Only applicable to RCM++. '''Variant'''.
|-
|UN2||Gets or sets the value in the second user-defined number field. Only applicable to RCM++. '''Variant'''.
|-
|UT1||Gets or sets the date in the first user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT2||Gets or sets the date in the second user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT3||Gets or sets the date in the third user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT4||Gets or sets the date in the fourth user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT5||Gets or sets the date in the fifth user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|}

==See Also==
*[[Repository.Task.AddScheduledTask|Repository.Task.AddScheduledTask Method]]
*[[Repository.Task.GetAllScheduledTasks|Repository.Task.GetAllScheduledTasks Method]]
*[[Repository.Task.GetScheduledTask|Repository.Task.GetScheduledTask Method]]
*[[Repository.Task.UpdateScheduledTask|Repository.Task.UpdateScheduledTask Method]]

CScheduledTask Class

2019-05-28T16:27:35Z

David J. Groebel: /* Properties */

{{DISPLAYTITLE:cScheduledTask Class}}{{Template:API}}{{Template:APIBreadcrumb}}

<onlyinclude>Represents a scheduled task resource. The task may be a preventive maintenance, inspection or on condition task.</onlyinclude>

==Constructors==
{| {{APITable}}
|-
|style="width: 240px;"|cScheduledTask||Creates an instance of the cSheduledTask class.
|-
|[[CScheduledTask_Constructors|cScheduledTask()]]||{{:CScheduledTask_Constructors}}
|}

==Methods==
{| {{APITable}}
|-
|style="width: 240px;"|[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]||{{:CScheduledTask.OnCondGetTeams_Method}}
|-
|[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]||{{:CScheduledTask.OnCondSetTeams_Method}}
|-
|[[CScheduledTask.GetPools_Method|GetPools]]||{{:CScheduledTask.GetPools_Method}}
|-
|[[CScheduledTask.SetPools_Method|SetPools]]||{{:CScheduledTask.SetPools_Method}}
|-
|[[CScheduledTask.GetTeams_Method|GetTeams]]||{{:CScheduledTask.GetTeams_Method}}
|-
|[[CScheduledTask.SetTeams_Method|SetTeams]]||{{:CScheduledTask.SetTeams_Method}}
|}

==Properties==
{| {{APITable}}
|-
| style="width: 240px;"|BringItemDown||Indicates whether the task brings the item down. '''Boolean'''. Default value = True.
|-
|BringSystemDown||Indicates whether the task brings the system down. '''Boolean'''. Default value = False.
|-
|Condition||Gets or sets a description of the condition that indicates that a failure will occur (for reliability centered maintenance analysis), such as a threshold for a measurement of wear, vibration, etc. '''String'''.
|-
|DurationModelID||Gets or sets the numeric ID of the model that represents the duration of the task. '''Integer'''
|-
|GroupIDs()||Gets an array containing the numeric IDs of the selected maintenance groups when the task is performed based on maintenance groups. (.NET only) '''Long'''.
|-
|ID||Gets the numeric ID of the task. '''Integer'''.
|-
|Intervals()||Gets or sets an array containing the interval start values when the task is performed based on dynamic intervals. '''Double'''.
|-
|{{Template:API_TxtIdentifiers}}
|-
|[[CScheduledTask.MaintenanceTriggers|MaintenanceTriggers]]||{{:CScheduledTask.MaintenanceTriggers}}
|-
|MiscCostModelID||Gets or sets the numeric ID of the model that represents the task's cost per task. Applies to preventive and inspection tasks. '''Integer'''.
|-
|MiscCostPerTimeModelID||Gets or sets the numeric ID of the model that represents the task's downtime rate ($/Hr). Applies to preventive and inspection tasks. '''Integer'''.
|-
|Name||Gets or sets the task's name. '''String'''.
|-
|OCMiscCostModelID||Gets or sets the numeric ID of the model that represents the task's cost per task. Applies to on condition tasks upon detection. '''Integer'''.
|-
|OCMiscCostPerTimeModelID||Gets or sets the numeric ID of the model that represents the task's downtime rate($/Hr). Applies to on condition tasks upon detection.'''Integer'''.
|-
|OnCondBringItemDown||Indicates whether the task brings the item down. Applies to on condition tasks upon detection. '''Boolean'''. Default value = True.
|-
|OnCondBringSystemDown||Indicates whether the task brings the system down. Applies to on condition tasks upon detection. '''Boolean'''. Default value = False.
|-
|OnCondDurationModelID||Gets or sets the numeric ID of the model that represents the duration of the task. Applies to on condition tasks upon detection. '''Integer'''.
|-
|OnCondFailureDetectionThreshold||Gets or sets the value for the task's failure detection threshold interval (0.9 = 90% percent of life). '''Double'''. Default value = 0.9.
|-
|OnCondPFInterval||Gets or sets the value for the task's prior-to-failure (P-F) interval. '''Double'''. Default value = 100.
|-
|OnCondPFIntervalUnitID||Gets or sets the numeric ID of the unit of measurement applied to the P-F interval. '''Integer'''.
|-
|OnCondResFactorValue||Gets or sets the on condition task's restoration amount. A value of 1 indicates an "as good as new" condition," a value of 0 indicates an "as bad as old" condition. A value between 0 and 100 indicates partial restoration. '''Double'''. Default value = 1.
|-
|OnCondResFactorType||Gets or set a value from the '''[[TaskRestorationTypeEnum Enumeration|TaskRestorationTypeEnum]]''' enumeration, which specifies the effect of the restoration. Default value = 1 (restores all accumulated damage).
|-
|OnCondTeams||Returns a '''{{APIPrefix|List}}(Of [[TeamInfo Class|TeamInfo]])''' containing teams assigned for the 'On condition' task (in the order of priority). (.NET Only)
|-
|OnCondUsePFInterval||Indicates whether the prior-to-failure (P-F) interval should be used to detect imminent failures. '''Boolean'''. If true, specify a value for OnCondPFInterval; if false, specify a value for OnCondFailureDetectionThreshold. Default value = False.
|-
|PackageID||Gets the numeric ID of the task package that will override the task's scheduling properties (0 = no override). '''Integer'''.
|-
|PerformTaskEvenIfItBringsSysDown||Indicates whether the task should be performed if bringing the item down causes the system to go down. '''Boolean'''. Default value = True.
|-
|PerformTaskEvenIfItemAlreadyFailed||Indicates whether the task should be performed even if the item failed before the task was scheduled to occur. '''Boolean'''. Default value = False.
|-
|Pools||Returns the list containing spare pool ID and the number of parts for each pool assigned for the task as a new list of [[PoolInfo|PoolInfo]] (.NET only). In case of duplicate entries (same pool ID), the latest entry takes preference.
|-
|ProjectID||Gets the numeric ID of the project the task belongs to. '''Integer'''.
|-
|PropInterval||Gets or sets the interval value that was initially proposed for the task (for reliability centered maintenance analysis). '''Variant'''.
|-
|PropIntervalUnitID||Gets or sets numeric ID for the unit of measurement applied to the proposed interval. '''Integer'''.
|-
|RefDoc||Gets or sets the description for the reference document that provides more detailed information about the task (for reliability centered maintenance analysis). '''String'''.
|-
|ResFactorType||Gets or sets a value from the '''[[TaskRestorationTypeEnum Enumeration|TaskRestorationTypeEnum]]''' enumeration, which specifies the effect of the restoration. Default value = 1 (restores all accumulated damage).
|-
|ResFactorValue||Gets or sets the scheduled task's restoration amount. A value of 1 indicates an "as good as new" condition," a value of 0 indicates an "as bad as old" condition. A value between 0 and 100 indicates partial restoration. '''Double'''. Default value = 1.
|-
|Status||Gets or sets the status of the task (for reliability centered maintenance analysis). '''String'''.
|-
|TaskAccess||Gets or sets the access that will be required in order to perform the task (typically for aircraft MSG-3 analyses). '''String'''.
|-
|TaskClass||Gets or set one of the values of the '''[[TaskClassEnum Enumeration|TaskClassEnum]]''', which specifies the task's class (e.g., preventive task, inspection or on condition). Default value = 0 (preventive task).
|-
|TaskFrequencyID||Gets or sets a value from the '''[[TaskFrequencyEnum Enumeration|TaskFrequencyEnum]]''', which specifies the frequency at which the task is performed. Default value = 5 (whenever system is down).
|-
|TaskFrequencyUnitID||Gets or sets the numeric ID of the unit of measurement of the intervals at which the task is performed. '''Integer'''.
|-
|TaskFrequencyValue||Gets or sets the fixed interval at which the task is performed. '''Double'''. Default value = 1.
|-
|TaskFreqValueVariableID||Gets or sets the numeric ID of the variable that represents the fixed interval at which the task is performed. '''Integer'''.
|-
|TaskTypeID||Gets or sets the numeric ID of the RCM++ or RBI task type (1 = the first task type defined in the repository). '''Integer'''. Default value = -1, which indicates no task type is available.
|-
|TaskZone||Gets or sets the zone of the system in which the task will be performed (aircraft MSG-3 analyses). '''String'''.
|-
|Teams||Returns the list containing teams assigned for the task (in the order of priority). '''List(Of [[TeamInfo Class|TeamInfo]])'''. (.NET Only)
|-
|UDD1||Gets or sets the text in the first user-defined drop-down field. Only applicable to RCM++. (Limited to 50 characters.) '''String'''.
|-
|UDD2||Gets or sets the text in the second user-defined drop-down field. Only applicable to RCM++. (Limited to 50 characters.) '''String'''.
|-
|UDT1||Gets or sets the date in the first user-defined date field. Only applicable to RCM++. '''Variant'''.
|-
|UDT2||Gets or sets the date in the second user-defined date field. Only applicable to RCM++. '''Variant'''.
|-
|UN1||Gets or sets the value in the first user-defined number field. Only applicable to RCM++. '''Variant'''.
|-
|UN2||Gets or sets the value in the second user-defined number field. Only applicable to RCM++. '''Variant'''.
|-
|UT1||Gets or sets the date in the first user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT2||Gets or sets the date in the second user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT3||Gets or sets the date in the first user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT4||Gets or sets the date in the second user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|-
|UT5||Gets or sets the date in the second user-defined text field. Only applicable to RCM++ and RBI. '''String'''.
|}

==See Also==
*[[Repository.Task.AddScheduledTask|Repository.Task.AddScheduledTask Method]]
*[[Repository.Task.GetAllScheduledTasks|Repository.Task.GetAllScheduledTasks Method]]
*[[Repository.Task.GetScheduledTask|Repository.Task.GetScheduledTask Method]]
*[[Repository.Task.UpdateScheduledTask|Repository.Task.UpdateScheduledTask Method]]

File:RgaA.3.png

2019-05-22T22:22:05Z

David J. Groebel: uploaded a new version of "File:RgaA.3.png"

File:RgaA.3.png

2019-05-22T22:19:41Z

David J. Groebel: uploaded a new version of "File:RgaA.3.png"

File:RgaA.2.png

2019-05-22T22:17:00Z

David J. Groebel: uploaded a new version of "File:RgaA.2.png"

Failure Discounting Example

2019-05-22T22:16:25Z

David J. Groebel:

<noinclude>{{Banner RGA Examples}}
''This example appears in the article [[Failure Discounting]]''.
</noinclude>

Assume that during the 22 launches given in the first table below, the first failure was caused by Mode 1, the second and fourth failures were caused by Mode 2, the third and fifth failures were caused by Mode 3, the sixth failure was caused by Mode 4 and the seventh failure was caused by Mode 5.

#Find the standard Gompertz reliability growth curve using the results of the first 15 launches.
#Find the predicted reliability after launch 22.
#Calculate the reliability after launch 22 based on the full data set from the second table, and compare it with the estimate obtained for question 2.

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="10" style="text-align:center"|'''Launch Sequence with Failure Modes and Failure Values'''
|-
!Launch Number
!Result/Mode
!Failure 1
!Failure 2
!Failure 3
!Failure 4
!Failure 5
!Sum of Failures
|-
|1|| F1|| 1.000|| || || || || 1.000
|-
|2|| F2|| 1.000|| 1.000 || || || || 2.000
|-
|3|| F3|| 0.900|| 1.000|| 1.000|| || || 2.900
|-
|4|| S|| 0.684|| 0.900|| 1.000|| || || 2.584
|-
|5|| F2|| 0.536|| 1.000|| 0.900|| || || 2.436
|-
|6|| F3|| 0.438|| 1.000|| 1.000|| || || 2.438
|-
|7|| S|| 0.369|| 0.900|| 1.000|| || || 2.269
|-
|8|| S|| 0.319|| 0.684|| 0.900|| || || 1.902
|-
|9|| S|| 0.280|| 0.536|| 0.684|| || || 1.500
|-
|10|| S|| 0.250|| 0.438|| 0.536|| || || 1.224
|-
|11|| S|| 0.226|| 0.369|| 0.438|| || || 1.032
|-
|12|| S|| 0.206|| 0.319|| 0.369|| || || 0.894
|-
|13|| S|| 0.189|| 0.280|| 0.319|| || || 0.788
|-
|14|| S|| 0.175|| 0.250|| 0.280|| || || 0.705
|-
|15|| S|| 0.162|| 0.226|| 0.250|| || || 0.638
|-
|16|| S|| 0.152|| 0.206|| 0.226|| || || 0.584
|-
|17|| F4|| 0.142|| 0.189|| 0.206|| 1.000 || || 1.537
|-
|18|| S|| 0.134|| 0.175|| 0.189|| 1.000 || || 1.498
|-
|19|| F5|| 0.127|| 0.162|| 0.175|| 0.900 || 1.000 || 2.364
|-
|20|| S|| 0.120|| 0.152|| 0.162|| 0.684 || 1.000 || 2.118
|-
|21|| S|| 0.114|| 0.142|| 0.152|| 0.536 || 0.900 || 1.844
|-
|22|| S|| 0.109|| 0.134|| 0.142|| 0.438 || 0.684 || 1.507
|}

<br>

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="4" style="text-align:center"|'''Comparison of the Predicted Reliability with the Actual Data'''
|-
!Launch Number
!Calculated Reliability (%)
!ln(R)
!Gompertz Reliability (%)
|-
|1|| 0.000 || ||
|-
|2|| 0.000 || ||
|-
|3|| 3.333 || 1.204 ||
|-
|4|| 35.406 || 3.567 || 28.617
|-
|5|| 51.283 || 3.937 || 45.883
|-
|6|| 59.372 || 4.084 || 60.841
|-
|7|| 67.585 || 4.213 || 72.017
|-
|8|| 76.219 || 4.334 || 79.654
|-
|9|| 83.334 || 4.423 || 84.600
|-
| || || <math>{{S}_{1}}\,\!</math> = 24.558 ||
|-
|10|| 87.764 || 4.475 || 87.701
|-
|11|| 90.614 || 4.507 || 89.609
|-
|12|| 92.555 || 4.528 || 90.769
|-
|13|| 93.939 || 4.543 || 91.469
|-
|14|| 94.964 || 4.553 || 91.891
|-
|15|| 95.746 || 4.562 || 92.143
|-
| || || <math>{{S}_{2}}\,\!</math> = 27.167 ||
|-
|16|| 96.356 || 4.568 || 92.295
|-
|17|| 90.960 || 4.510 || 92.385
|-
|18|| 91.681 || 4.518 || 92.439
|-
|19|| 87.560 || 4.472 || 92.472
|-
|20|| 89.411 || 4.493 || 92.491
|-
|21|| 91.219 || 4.513 || 92.503
|-
| || || <math>{{S}_{3}}\,\!</math> = 27.076 ||
|-
|22|| 93.152 ||4.534 || 92.510
|}

'''Solution'''
<ol>
<li>In the table above, the failures are represented by columns "Failure 1", "Failure 2", etc. The "Result/Mode" column shows whether each launch is a failure (indicated by the failure modes F1, F2, etc.) or a success (S). The values of failure are based on <math>CL=0.90\,\!</math> and are calculated from:

:<math>f=1-{{(1-CL)}^{\tfrac{1}{{{S}_{n}}}}}\,\!</math>

These values are summed and the reliability is calculated from:

:<math>R=\left[ 1-\left( \frac{\mathop{}_{i=1}^{N}{{f}_{i}}}{n} \right) \right]\cdot 100\text{ }%\,\!</math>

where <math>N\,\!</math> is the number of failures and <math>n\,\!</math> is the number of events, tests, runs or launches.

*Failure 1 is Mode 1; it occurs at launch 1 and it does not recur throughout the process. So at launch 3, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 2 is Mode 2; it occurs at launch 2 and it recurs at launch 5. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 4 and at launch 7, and so on.

*Failure 3 is Mode 3; it occurs at launch 3 and it recurs at launch 6. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 5 and at launch 8, and so on.

*Failure 6 is Mode 4; it occurs at launch 17 and it does not recur throughout the process. So at launch 19, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 7 is Mode 5; it occurs at launch 19 and it does not recur throughout the process. So at launch 21, <math>{{S}_{n}}=1\,\!</math>, and so on.

For launch 3 and failure 1, <math>{{S}_{n}}=1\,\!</math>.

:<math>\begin{align}
{{f}_{1/3}}=1-{{(1-0.90)}^{1/1}}=0.900
\end{align}\,\!</math>

For launch 4 and failure 1, <math>{{S}_{n}}=2\,\!</math>.

:<math>\begin{align}
{{f}_{1/4}}=1-{{(1-0.90)}^{1/2}}=0.684
\end{align}\,\!</math>

And so on.

Calculate the initial values of the Gompertz parameters using the second table above. Based on the equations from the [[Gompertz Models]] chapter, the initial values are:

:<math>\begin{align}
c &= \left ( \frac{S_{2}-S_{3}}{S_{2}-S_{1}} \right )^\frac{1}{n\cdot I} \\
&= \left [ \frac{27.167-27.076}{27.167-24.558} \right ]^\frac{1}{6} \\
&= 0.572 \\
\end{align}\,\!</math>

:<math>\begin{align}
a &= e^\left [\frac{1}{n}\left (S_{1} + \frac {S_{2}-S_{1}}{1-e^{n\cdot I}} \right )\right ] \\
&= e^\left [\frac{1}{6}\left (24.558 + \frac{27.167 - 24.558}{1-0.572^{6}}\right ) \right ] \\
&= 94.024% \\
\end{align}\,\!</math>

:<math>\begin{align}
b &= e^\left [\frac{(S_{2}-S_{1})(c-1)}{(1-c^{n})^{2}} \right ] \\
&= e^\left [\frac{(27.167-24.558)(0.572-1)}{(1-0.572^{6})^{2}} \right ] \\
&= 0.301 \\
\end{align}\,\!</math>

Now, since the initial values have been determined, the Gauss-Newton method can be used. Substituting <math>{{Y}_{i}}={{R}_{i}},\,\!</math> <math>g_{1}^{(0)}=94.024,\,\!</math> <math>g_{2}^{(0)}=0.301,\,\!</math> <math>g_{3}^{(0)}=0.572\,\!</math>. The iterations are continued to solve for the parameters. Using the RGA software, the estimators of the parameters for the given example are:

:<math>\begin{align}
\widehat{a}&= 0.9252 \\
\widehat{b} &= 0.1404 \\
\widehat{c} &= 0.5977
\end{align}\,\!</math>

The next figure shows the entered data and the estimated parameters.

[[Image:rgaA.1.png|center|600px]]

The Gompertz reliability growth curve may now be written as follows where <math>{{L}_{G}}\,\!</math> is the number of launches, with the first successful launch being counted as <math>{{L}_{G}}=1\,\!</math>. Therefore, <math>{{L}_{G}}\,\!</math> is equal to 19, since reliability growth starts with launch 4.

:<math>R=0.9299{{(0.0943)}^{{{0.7170}^{{{L}_{G}}}}}}\,\!</math>

</li>
<li>The predicted reliability after launch 22 is therefore:

:<math>\begin{align}
R &= 0.9252{{(0.1404)}^{{{0.5977}^{19}}}} \\
&= 0.9251
\end{align}\,\!</math>

The predicted reliability after launch 22 is calculated using the Quick Calculation Pad (QCP), as shown next.

[[Image:rgaA.2.png|center|450px]]

</li>
<li>In the second table, the predicted reliability values are compared with the reliabilities that are calculated from the raw data using failure discounting. It can be seen in the table, and in the following figure, that the Gompertz curve appears to provide a good fit to the actual data.

[[Image:rgaA.3.png|center|450px]]</li>
</ol>

File:RgaA.1.png

2019-05-22T22:12:33Z

David J. Groebel: uploaded a new version of "File:RgaA.1.png"

Failure Discounting Example

2019-05-22T22:08:57Z

David J. Groebel:

<noinclude>{{Banner RGA Examples}}
''This example appears in the article [[Failure Discounting]]''.
</noinclude>

Assume that during the 22 launches given in the first table below, the first failure was caused by Mode 1, the second and fourth failures were caused by Mode 2, the third and fifth failures were caused by Mode 3, the sixth failure was caused by Mode 4 and the seventh failure was caused by Mode 5.

#Find the standard Gompertz reliability growth curve using the results of the first 15 launches.
#Find the predicted reliability after launch 22.
#Calculate the reliability after launch 22 based on the full data set from the second table, and compare it with the estimate obtained for question 2.

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="10" style="text-align:center"|'''Launch Sequence with Failure Modes and Failure Values'''
|-
!Launch Number
!Result/Mode
!Failure 1
!Failure 2
!Failure 3
!Failure 4
!Failure 5
!Sum of Failures
|-
|1|| F1|| 1.000|| || || || || 1.000
|-
|2|| F2|| 1.000|| 1.000 || || || || 2.000
|-
|3|| F3|| 0.900|| 1.000|| 1.000|| || || 2.900
|-
|4|| S|| 0.684|| 0.900|| 1.000|| || || 2.584
|-
|5|| F2|| 0.536|| 1.000|| 0.900|| || || 2.436
|-
|6|| F3|| 0.438|| 1.000|| 1.000|| || || 2.438
|-
|7|| S|| 0.369|| 0.900|| 1.000|| || || 2.269
|-
|8|| S|| 0.319|| 0.684|| 0.900|| || || 1.902
|-
|9|| S|| 0.280|| 0.536|| 0.684|| || || 1.500
|-
|10|| S|| 0.250|| 0.438|| 0.536|| || || 1.224
|-
|11|| S|| 0.226|| 0.369|| 0.438|| || || 1.032
|-
|12|| S|| 0.206|| 0.319|| 0.369|| || || 0.894
|-
|13|| S|| 0.189|| 0.280|| 0.319|| || || 0.788
|-
|14|| S|| 0.175|| 0.250|| 0.280|| || || 0.705
|-
|15|| S|| 0.162|| 0.226|| 0.250|| || || 0.638
|-
|16|| S|| 0.152|| 0.206|| 0.226|| || || 0.584
|-
|17|| F4|| 0.142|| 0.189|| 0.206|| 1.000 || || 1.537
|-
|18|| S|| 0.134|| 0.175|| 0.189|| 1.000 || || 1.498
|-
|19|| F5|| 0.127|| 0.162|| 0.175|| 0.900 || 1.000 || 2.364
|-
|20|| S|| 0.120|| 0.152|| 0.162|| 0.684 || 1.000 || 2.118
|-
|21|| S|| 0.114|| 0.142|| 0.152|| 0.536 || 0.900 || 1.844
|-
|22|| S|| 0.109|| 0.134|| 0.142|| 0.438 || 0.684 || 1.507
|}

<br>

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="4" style="text-align:center"|'''Comparison of the Predicted Reliability with the Actual Data'''
|-
!Launch Number
!Calculated Reliability (%)
!ln(R)
!Gompertz Reliability (%)
|-
|1|| 0.000 || ||
|-
|2|| 0.000 || ||
|-
|3|| 3.333 || 1.204 ||
|-
|4|| 35.406 || 3.567 || 28.617
|-
|5|| 51.283 || 3.937 || 45.883
|-
|6|| 59.372 || 4.084 || 60.841
|-
|7|| 67.585 || 4.213 || 72.017
|-
|8|| 76.219 || 4.334 || 79.654
|-
|9|| 83.334 || 4.423 || 84.600
|-
| || || <math>{{S}_{1}}\,\!</math> = 24.558 ||
|-
|10|| 87.764 || 4.475 || 87.701
|-
|11|| 90.614 || 4.507 || 89.609
|-
|12|| 92.555 || 4.528 || 90.769
|-
|13|| 93.939 || 4.543 || 91.469
|-
|14|| 94.964 || 4.553 || 91.891
|-
|15|| 95.746 || 4.562 || 92.143
|-
| || || <math>{{S}_{2}}\,\!</math> = 27.167 ||
|-
|16|| 96.356 || 4.568 || 92.295
|-
|17|| 90.960 || 4.510 || 92.385
|-
|18|| 91.681 || 4.518 || 92.439
|-
|19|| 87.560 || 4.472 || 92.472
|-
|20|| 89.411 || 4.493 || 92.491
|-
|21|| 91.219 || 4.513 || 92.503
|-
| || || <math>{{S}_{3}}\,\!</math> = 27.076 ||
|-
|22|| 93.152 ||4.534 || 92.510
|}

'''Solution'''
<ol>
<li>In the table above, the failures are represented by columns "Failure 1", "Failure 2", etc. The "Result/Mode" column shows whether each launch is a failure (indicated by the failure modes F1, F2, etc.) or a success (S). The values of failure are based on <math>CL=0.90\,\!</math> and are calculated from:

:<math>f=1-{{(1-CL)}^{\tfrac{1}{{{S}_{n}}}}}\,\!</math>

These values are summed and the reliability is calculated from:

:<math>R=\left[ 1-\left( \frac{\mathop{}_{i=1}^{N}{{f}_{i}}}{n} \right) \right]\cdot 100\text{ }%\,\!</math>

where <math>N\,\!</math> is the number of failures and <math>n\,\!</math> is the number of events, tests, runs or launches.

*Failure 1 is Mode 1; it occurs at launch 1 and it does not recur throughout the process. So at launch 3, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 2 is Mode 2; it occurs at launch 2 and it recurs at launch 5. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 4 and at launch 7, and so on.

*Failure 3 is Mode 3; it occurs at launch 3 and it recurs at launch 6. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 5 and at launch 8, and so on.

*Failure 6 is Mode 4; it occurs at launch 17 and it does not recur throughout the process. So at launch 19, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 7 is Mode 5; it occurs at launch 19 and it does not recur throughout the process. So at launch 21, <math>{{S}_{n}}=1\,\!</math>, and so on.

For launch 3 and failure 1, <math>{{S}_{n}}=1\,\!</math>.

:<math>\begin{align}
{{f}_{1/3}}=1-{{(1-0.90)}^{1/1}}=0.900
\end{align}\,\!</math>

For launch 4 and failure 1, <math>{{S}_{n}}=2\,\!</math>.

:<math>\begin{align}
{{f}_{1/4}}=1-{{(1-0.90)}^{1/2}}=0.684
\end{align}\,\!</math>

And so on.

Calculate the initial values of the Gompertz parameters using the second table above. Based on the equations from the [[Gompertz Models]] chapter, the initial values are:

:<math>\begin{align}
c &= \left ( \frac{S_{2}-S_{3}}{S_{2}-S_{1}} \right )^\frac{1}{n\cdot I} \\
&= \left [ \frac{27.167-27.076}{27.167-24.558} \right ]^\frac{1}{6} \\
&= 0.572 \\
\end{align}\,\!</math>

:<math>\begin{align}
a &= e^\left [\frac{1}{n}\left (S_{1} + \frac {S_{2}-S_{1}}{1-e^{n\cdot I}} \right )\right ] \\
&= e^\left [\frac{1}{6}\left (24.558 + \frac{27.167 - 24.558}{1-0.572^{6}}\right ) \right ] \\
&= 94.024% \\
\end{align}\,\!</math>

:<math>\begin{align}
b &= e^\left [\frac{(S_{2}-S_{1})(c-1)}{(1-c^{n})^{2}} \right ] \\
&= e^\left [\frac{(27.167-24.558)(0.572-1)}{(1-0.572^{6})^{2}} \right ] \\
&= 0.301 \\
\end{align}\,\!</math>

Now, since the initial values have been determined, the Gauss-Newton method can be used. Substituting <math>{{Y}_{i}}={{R}_{i}},\,\!</math> <math>g_{1}^{(0)}=94.024,\,\!</math> <math>g_{2}^{(0)}=0.301,\,\!</math> <math>g_{3}^{(0)}=0.572\,\!</math>. The iterations are continued to solve for the parameters. Using the RGA software, the estimators of the parameters for the given example are:

:<math>\begin{align}
\widehat{a}&= 0.9252 \\
\widehat{b} &= 0.1404 \\
\widehat{c} &= 0.5977
\end{align}\,\!</math>

The next figure shows the entered data and the estimated parameters.

[[Image:rgaA.1.png|center|600px]]

The Gompertz reliability growth curve may now be written as follows where <math>{{L}_{G}}\,\!</math> is the number of launches, with the first successful launch being counted as <math>{{L}_{G}}=1\,\!</math>. Therefore, <math>{{L}_{G}}\,\!</math> is equal to 19, since reliability growth starts with launch 4.

:<math>R=0.9299{{(0.0943)}^{{{0.7170}^{{{L}_{G}}}}}}\,\!</math>

</li>
<li>The predicted reliability after launch 22 is therefore:

:<math>\begin{align}
R &= 0.9299{{(0.0943)}^{{{0.7170}^{19}}}} \\
&= 0.9260
\end{align}\,\!</math>

The predicted reliability after launch 22 is calculated using the Quick Calculation Pad (QCP), as shown next.

[[Image:rgaA.2.png|center|450px]]

</li>
<li>In the second table, the predicted reliability values are compared with the reliabilities that are calculated from the raw data using failure discounting. It can be seen in the table, and in the following figure, that the Gompertz curve appears to provide a good fit to the actual data.

[[Image:rgaA.3.png|center|450px]]</li>
</ol>

Failure Discounting Example

2019-05-22T22:07:29Z

David J. Groebel:

<noinclude>{{Banner RGA Examples}}
''This example appears in the article [[Failure Discounting]]''.
</noinclude>

Assume that during the 22 launches given in the first table below, the first failure was caused by Mode 1, the second and fourth failures were caused by Mode 2, the third and fifth failures were caused by Mode 3, the sixth failure was caused by Mode 4 and the seventh failure was caused by Mode 5.

#Find the standard Gompertz reliability growth curve using the results of the first 15 launches.
#Find the predicted reliability after launch 22.
#Calculate the reliability after launch 22 based on the full data set from the second table, and compare it with the estimate obtained for question 2.

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="10" style="text-align:center"|'''Launch Sequence with Failure Modes and Failure Values'''
|-
!Launch Number
!Result/Mode
!Failure 1
!Failure 2
!Failure 3
!Failure 4
!Failure 5
!Sum of Failures
|-
|1|| F1|| 1.000|| || || || || 1.000
|-
|2|| F2|| 1.000|| 1.000 || || || || 2.000
|-
|3|| F3|| 0.900|| 1.000|| 1.000|| || || 2.900
|-
|4|| S|| 0.684|| 0.900|| 1.000|| || || 2.584
|-
|5|| F2|| 0.536|| 1.000|| 0.900|| || || 2.436
|-
|6|| F3|| 0.438|| 1.000|| 1.000|| || || 2.438
|-
|7|| S|| 0.369|| 0.900|| 1.000|| || || 2.269
|-
|8|| S|| 0.319|| 0.684|| 0.900|| || || 1.902
|-
|9|| S|| 0.280|| 0.536|| 0.684|| || || 1.500
|-
|10|| S|| 0.250|| 0.438|| 0.536|| || || 1.224
|-
|11|| S|| 0.226|| 0.369|| 0.438|| || || 1.032
|-
|12|| S|| 0.206|| 0.319|| 0.369|| || || 0.894
|-
|13|| S|| 0.189|| 0.280|| 0.319|| || || 0.788
|-
|14|| S|| 0.175|| 0.250|| 0.280|| || || 0.705
|-
|15|| S|| 0.162|| 0.226|| 0.250|| || || 0.638
|-
|16|| S|| 0.152|| 0.206|| 0.226|| || || 0.584
|-
|17|| F4|| 0.142|| 0.189|| 0.206|| 1.000 || || 1.537
|-
|18|| S|| 0.134|| 0.175|| 0.189|| 1.000 || || 1.498
|-
|19|| F5|| 0.127|| 0.162|| 0.175|| 0.900 || 1.000 || 2.364
|-
|20|| S|| 0.120|| 0.152|| 0.162|| 0.684 || 1.000 || 2.118
|-
|21|| S|| 0.114|| 0.142|| 0.152|| 0.536 || 0.900 || 1.844
|-
|22|| S|| 0.109|| 0.134|| 0.142|| 0.438 || 0.684 || 1.507
|}

<br>

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="4" style="text-align:center"|'''Comparison of the Predicted Reliability with the Actual Data'''
|-
!Launch Number
!Calculated Reliability (%)
!ln(R)
!Gompertz Reliability (%)
|-
|1|| 0.000 || ||
|-
|2|| 0.000 || ||
|-
|3|| 3.333 || 1.204 ||
|-
|4|| 35.406 || 3.567 || 28.617
|-
|5|| 51.283 || 3.937 || 45.883
|-
|6|| 59.372 || 4.084 || 60.841
|-
|7|| 67.585 || 4.213 || 72.017
|-
|8|| 76.219 || 4.334 || 79.654
|-
|9|| 83.334 || 4.423 || 84.600
|-
| || || <math>{{S}_{1}}\,\!</math> = 24.558 ||
|-
|10|| 87.764 || 4.475 || 87.701
|-
|11|| 90.614 || 4.507 || 89.609
|-
|12|| 92.555 || 4.528 || 90.769
|-
|13|| 93.939 || 4.543 || 91.469
|-
|14|| 94.964 || 4.553 || 91.891
|-
|15|| 95.746 || 4.562 || 92.143
|-
| || || <math>{{S}_{2}}\,\!</math> = 27.167 ||
|-
|16|| 96.356 || 4.568 || 92.295
|-
|17|| 90.960 || 4.510 || 92.385
|-
|18|| 91.681 || 4.518 || 92.439
|-
|19|| 87.560 || 4.472 || 92.472
|-
|20|| 89.411 || 4.493 || 92.491
|-
|21|| 91.219 || 4.513 || 92.503
|-
| || || <math>{{S}_{3}}\,\!</math> = 27.076 ||
|-
|22|| 93.152 ||4.534 || 92.510
|}

'''Solution'''
<ol>
<li>In the table above, the failures are represented by columns "Failure 1", "Failure 2", etc. The "Result/Mode" column shows whether each launch is a failure (indicated by the failure modes F1, F2, etc.) or a success (S). The values of failure are based on <math>CL=0.90\,\!</math> and are calculated from:

:<math>f=1-{{(1-CL)}^{\tfrac{1}{{{S}_{n}}}}}\,\!</math>

These values are summed and the reliability is calculated from:

:<math>R=\left[ 1-\left( \frac{\mathop{}_{i=1}^{N}{{f}_{i}}}{n} \right) \right]\cdot 100\text{ }%\,\!</math>

where <math>N\,\!</math> is the number of failures and <math>n\,\!</math> is the number of events, tests, runs or launches.

*Failure 1 is Mode 1; it occurs at launch 1 and it does not recur throughout the process. So at launch 3, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 2 is Mode 2; it occurs at launch 2 and it recurs at launch 5. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 4 and at launch 7, and so on.

*Failure 3 is Mode 3; it occurs at launch 3 and it recurs at launch 6. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 5 and at launch 8, and so on.

*Failure 6 is Mode 4; it occurs at launch 17 and it does not recur throughout the process. So at launch 19, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 7 is Mode 5; it occurs at launch 19 and it does not recur throughout the process. So at launch 21, <math>{{S}_{n}}=1\,\!</math>, and so on.

For launch 3 and failure 1, <math>{{S}_{n}}=1\,\!</math>.

:<math>\begin{align}
{{f}_{1/3}}=1-{{(1-0.90)}^{1/1}}=0.900
\end{align}\,\!</math>

For launch 4 and failure 1, <math>{{S}_{n}}=2\,\!</math>.

:<math>\begin{align}
{{f}_{1/4}}=1-{{(1-0.90)}^{1/2}}=0.684
\end{align}\,\!</math>

And so on.

Calculate the initial values of the Gompertz parameters using the second table above. Based on the equations from the [[Gompertz Models]] chapter, the initial values are:

:<math>\begin{align}
c &= \left ( \frac{S_{2}-S_{3}}{S_{2}-S_{1}} \right )^\frac{1}{n\cdot I} \\
&= \left [ \frac{27.167-27.076}{27.167-24.558} \right ]^\frac{1}{6} \\
&= 0.572 \\
\end{align}\,\!</math>

:<math>\begin{align}
a &= e^\left [\frac{1}{n}\left (S_{1} + \frac {S_{2}-S_{1}}{1-e^{n\cdot I}} \right )\right ] \\
&= e^\left [\frac{1}{6}\left (24.558 + \frac{27.167 - 24.558}{1-0.572^{6}}\right ) \right ] \\
&= 94.024% \\
\end{align}\,\!</math>

:<math>\begin{align}
b &= e^\left [\frac{(S_{2}-S_{1})(c-1)}{(1-c^{n})^{2}} \right ] \\
&= e^\left [\frac{(27.167-24.558)(0.572-1)}{(1-0.572^{6})^{2}} \right ] \\
&= 0.301 \\
\end{align}\,\!</math>

Now, since the initial values have been determined, the Gauss-Newton method can be used. Substituting <math>{{Y}_{i}}={{R}_{i}},\,\!</math> <math>g_{1}^{(0)}=89.31,\,\!</math> <math>g_{2}^{(0)}=0.127,\,\!</math> <math>g_{3}^{(0)}=0.578\,\!</math>. The iterations are continued to solve for the parameters. Using the RGA software, the estimators of the parameters for the given example are:

:<math>\begin{align}
\widehat{a}&= 0.9299 \\
\widehat{b} &= 0.0943 \\
\widehat{c} &= 0.7170
\end{align}\,\!</math>

The next figure shows the entered data and the estimated parameters.

[[Image:rgaA.1.png|center|600px]]

The Gompertz reliability growth curve may now be written as follows where <math>{{L}_{G}}\,\!</math> is the number of launches, with the first successful launch being counted as <math>{{L}_{G}}=1\,\!</math>. Therefore, <math>{{L}_{G}}\,\!</math> is equal to 19, since reliability growth starts with launch 4.

:<math>R=0.9299{{(0.0943)}^{{{0.7170}^{{{L}_{G}}}}}}\,\!</math>

</li>
<li>The predicted reliability after launch 22 is therefore:

:<math>\begin{align}
R &= 0.9299{{(0.0943)}^{{{0.7170}^{19}}}} \\
&= 0.9260
\end{align}\,\!</math>

The predicted reliability after launch 22 is calculated using the Quick Calculation Pad (QCP), as shown next.

[[Image:rgaA.2.png|center|450px]]

</li>
<li>In the second table, the predicted reliability values are compared with the reliabilities that are calculated from the raw data using failure discounting. It can be seen in the table, and in the following figure, that the Gompertz curve appears to provide a good fit to the actual data.

[[Image:rgaA.3.png|center|450px]]</li>
</ol>

Failure Discounting Example

2019-05-22T21:54:41Z

David J. Groebel:

<noinclude>{{Banner RGA Examples}}
''This example appears in the article [[Failure Discounting]]''.
</noinclude>

Assume that during the 22 launches given in the first table below, the first failure was caused by Mode 1, the second and fourth failures were caused by Mode 2, the third and fifth failures were caused by Mode 3, the sixth failure was caused by Mode 4 and the seventh failure was caused by Mode 5.

#Find the standard Gompertz reliability growth curve using the results of the first 15 launches.
#Find the predicted reliability after launch 22.
#Calculate the reliability after launch 22 based on the full data set from the second table, and compare it with the estimate obtained for question 2.

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="10" style="text-align:center"|'''Launch Sequence with Failure Modes and Failure Values'''
|-
!Launch Number
!Result/Mode
!Failure 1
!Failure 2
!Failure 3
!Failure 4
!Failure 5
!Sum of Failures
|-
|1|| F1|| 1.000|| || || || || 1.000
|-
|2|| F2|| 1.000|| 1.000 || || || || 2.000
|-
|3|| F3|| 0.900|| 1.000|| 1.000|| || || 2.900
|-
|4|| S|| 0.684|| 0.900|| 1.000|| || || 2.584
|-
|5|| F2|| 0.536|| 1.000|| 0.900|| || || 2.436
|-
|6|| F3|| 0.438|| 1.000|| 1.000|| || || 2.438
|-
|7|| S|| 0.369|| 0.900|| 1.000|| || || 2.269
|-
|8|| S|| 0.319|| 0.684|| 0.900|| || || 1.902
|-
|9|| S|| 0.280|| 0.536|| 0.684|| || || 1.500
|-
|10|| S|| 0.250|| 0.438|| 0.536|| || || 1.224
|-
|11|| S|| 0.226|| 0.369|| 0.438|| || || 1.032
|-
|12|| S|| 0.206|| 0.319|| 0.369|| || || 0.894
|-
|13|| S|| 0.189|| 0.280|| 0.319|| || || 0.788
|-
|14|| S|| 0.175|| 0.250|| 0.280|| || || 0.705
|-
|15|| S|| 0.162|| 0.226|| 0.250|| || || 0.638
|-
|16|| S|| 0.152|| 0.206|| 0.226|| || || 0.584
|-
|17|| F4|| 0.142|| 0.189|| 0.206|| 1.000 || || 1.537
|-
|18|| S|| 0.134|| 0.175|| 0.189|| 1.000 || || 1.498
|-
|19|| F5|| 0.127|| 0.162|| 0.175|| 0.900 || 1.000 || 2.364
|-
|20|| S|| 0.120|| 0.152|| 0.162|| 0.684 || 1.000 || 2.118
|-
|21|| S|| 0.114|| 0.142|| 0.152|| 0.536 || 0.900 || 1.844
|-
|22|| S|| 0.109|| 0.134|| 0.142|| 0.438 || 0.684 || 1.507
|}

<br>

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="4" style="text-align:center"|'''Comparison of the Predicted Reliability with the Actual Data'''
|-
!Launch Number
!Calculated Reliability (%)
!ln(R)
!Gompertz Reliability (%)
|-
|1|| 0.000 || ||
|-
|2|| 0.000 || ||
|-
|3|| 3.333 || 1.204 ||
|-
|4|| 35.406 || 3.567 || 28.617
|-
|5|| 51.283 || 3.937 || 45.883
|-
|6|| 59.372 || 4.084 || 60.841
|-
|7|| 67.585 || 4.213 || 72.017
|-
|8|| 76.219 || 4.334 || 79.654
|-
|9|| 83.334 || 4.423 || 84.600
|-
| || || <math>{{S}_{1}}\,\!</math> = 24.558 ||
|-
|10|| 87.764 || 4.475 || 87.701
|-
|11|| 90.614 || 4.507 || 89.609
|-
|12|| 92.555 || 4.528 || 90.769
|-
|13|| 93.939 || 4.543 || 91.469
|-
|14|| 94.964 || 4.553 || 91.891
|-
|15|| 95.746 || 4.562 || 92.143
|-
| || || <math>{{S}_{2}}\,\!</math> = 27.167 ||
|-
|16|| 96.356 || 4.568 || 92.295
|-
|17|| 90.960 || 4.510 || 92.385
|-
|18|| 91.681 || 4.518 || 92.439
|-
|19|| 87.560 || 4.472 || 92.472
|-
|20|| 89.411 || 4.493 || 92.491
|-
|21|| 91.219 || 4.513 || 92.503
|-
| || || <math>{{S}_{3}}\,\!</math> = 27.076 ||
|-
|22|| 93.152 ||4.534 || 92.510
|}

'''Solution'''
<ol>
<li>In the table above, the failures are represented by columns "Failure 1", "Failure 2", etc. The "Result/Mode" column shows whether each launch is a failure (indicated by the failure modes F1, F2, etc.) or a success (S). The values of failure are based on <math>CL=0.90\,\!</math> and are calculated from:

:<math>f=1-{{(1-CL)}^{\tfrac{1}{{{S}_{n}}}}}\,\!</math>

These values are summed and the reliability is calculated from:

:<math>R=\left[ 1-\left( \frac{\mathop{}_{i=1}^{N}{{f}_{i}}}{n} \right) \right]\cdot 100\text{ }%\,\!</math>

where <math>N\,\!</math> is the number of failures and <math>n\,\!</math> is the number of events, tests, runs or launches.

*Failure 1 is Mode 1; it occurs at launch 1 and it does not recur throughout the process. So at launch 3, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 2 is Mode 2; it occurs at launch 2 and it recurs at launch 5. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 4 and at launch 7, and so on.

*Failure 3 is Mode 3; it occurs at launch 3 and it recurs at launch 6. Therefore, <math>{{S}_{n}}=1\,\!</math> at launch 5 and at launch 8, and so on.

*Failure 6 is Mode 4; it occurs at launch 17 and it does not recur throughout the process. So at launch 19, <math>{{S}_{n}}=1\,\!</math>, and so on.

*Failure 7 is Mode 5; it occurs at launch 19 and it does not recur throughout the process. So at launch 21, <math>{{S}_{n}}=1\,\!</math>, and so on.

For launch 3 and failure 1, <math>{{S}_{n}}=1\,\!</math>.

:<math>\begin{align}
{{f}_{1/3}}=1-{{(1-0.90)}^{1/1}}=0.900
\end{align}\,\!</math>

For launch 4 and failure 1, <math>{{S}_{n}}=2\,\!</math>.

:<math>\begin{align}
{{f}_{1/4}}=1-{{(1-0.90)}^{1/2}}=0.684
\end{align}\,\!</math>

And so on.

Calculate the initial values of the Gompertz parameters using the second table above. Based on the equations from the [[Gompertz Models]] chapter, the initial values are:

:<math>\begin{align}
c &= \left ( \frac{S_{3}-S_{2}}{S_{2}-S_{1}} \right )^\frac{1}{n\cdot I} \\
&= \left [ \frac{26.946-26.776}{26.776-22.218} \right ]^\frac{1}{6} \\
&= 0.578 \\
\end{align}\,\!</math>

:<math>\begin{align}
a &= e^\left [\frac{1}{n}\left (S_{1} + \frac {S_{2}-S_{1}}{1-e^{n\cdot I}} \right )\right ] \\
&= e^\left [\frac{1}{6}\left (22.218 + \frac{26.776 - 22.218}{1-0.578^{6}}\right ) \right ] \\
&= 89.31% \\
\end{align}\,\!</math>

:<math>\begin{align}
b &= e^\left [\frac{(S_{2}-S_{1})(c-1)}{(1-c^{n})^{2}} \right ] \\
&= e^\left [\frac{(26.776-22.218)(0.578-1)}{(1-0.578^{6})^{2}} \right ] \\
&= 0.127 \\
\end{align}\,\!</math>

Now, since the initial values have been determined, the Gauss-Newton method can be used. Substituting <math>{{Y}_{i}}={{R}_{i}},\,\!</math> <math>g_{1}^{(0)}=89.31,\,\!</math> <math>g_{2}^{(0)}=0.127,\,\!</math> <math>g_{3}^{(0)}=0.578\,\!</math>. The iterations are continued to solve for the parameters. Using the RGA software, the estimators of the parameters for the given example are:

:<math>\begin{align}
\widehat{a}&= 0.9299 \\
\widehat{b} &= 0.0943 \\
\widehat{c} &= 0.7170
\end{align}\,\!</math>

The next figure shows the entered data and the estimated parameters.

[[Image:rgaA.1.png|center|600px]]

The Gompertz reliability growth curve may now be written as follows where <math>{{L}_{G}}\,\!</math> is the number of launches, with the first successful launch being counted as <math>{{L}_{G}}=1\,\!</math>. Therefore, <math>{{L}_{G}}\,\!</math> is equal to 19, since reliability growth starts with launch 4.

:<math>R=0.9299{{(0.0943)}^{{{0.7170}^{{{L}_{G}}}}}}\,\!</math>

</li>
<li>The predicted reliability after launch 22 is therefore:

:<math>\begin{align}
R &= 0.9299{{(0.0943)}^{{{0.7170}^{19}}}} \\
&= 0.9260
\end{align}\,\!</math>

The predicted reliability after launch 22 is calculated using the Quick Calculation Pad (QCP), as shown next.

[[Image:rgaA.2.png|center|450px]]

</li>
<li>In the second table, the predicted reliability values are compared with the reliabilities that are calculated from the raw data using failure discounting. It can be seen in the table, and in the following figure, that the Gompertz curve appears to provide a good fit to the actual data.

[[Image:rgaA.3.png|center|450px]]</li>
</ol>

CScheduledTask.OnCondGetTeams Method

2019-03-14T18:27:28Z

David J. Groebel:

{{DISPLAYTITLE:cScheduledTask.OnCondGetTeams Method}}{{Template:API}}{{Template:APIBreadcrumb|.[[CScheduledTask_Class|cScheduledTask]]}}

<onlyinclude>Returns an array teams required for the 'On condition' task.</onlyinclude>

'''Remarks''': Designed for VB6/VBA users, but can also be used in .NET. Alternatively, .NET users can use the <code>OnCondTeams()</code> property in the class to get or set the teams.

== Syntax ==
'''.OnCondGetTeams'''({{APIPrefix|ByRef}} ''arr()'')

===Parameters===
''arr()''
:Required as [[TeamInfo Class|TeamInfo]]. An array of the team IDs for the task.

== Example ==
'''VBA'''

{{APIComment|'Declare a new Repository object and connect to a Synthesis repository.}}
{{APIPrefix|Dim}} MyRepository {{APIPrefix|As New}} Repository
MyRepository.ConnectToAccessRepository({{APIString|"C:\RSRepository1.rsr19"}})
MyRepository.Project.SetCurrentProject(1)

{{APIComment|'Get a particular task with ID of 2 from repository.}}
{{APIPrefix|Dim}} aTask {{APIPrefix|As}} cScheduledTask
{{APIPrefix|Set}} aTask = MyRespository.Task.GetScheduledTask(2)

{{APIComment|'Create instance of TeamInfo if on condition task}}
{{APIPrefix|If}} aTask.TaskClass = TaskClassEnum_OnCondition {{APIPrefix|Then}}
{{APIPrefix|Dim}} Teams() {{APIPrefix|As}} TeamInfo
{{APIPrefix|Call}} aTask.OnCondGetTeams(Teams)
{{APIPrefix|End If}}

CScheduledTask.GetTeams Method

2019-03-14T18:27:07Z

David J. Groebel:

{{DISPLAYTITLE:cScheduledTask.GetTeams Method}}{{Template:API}}{{Template:APIBreadcrumb|.[[CScheduledTask_Class|cScheduledTask]]}}

<onlyinclude>Returns an array teams required for the task.</onlyinclude>

'''Remarks''': Designed for VB6/VBA users, but can also be used in .NET. Alternatively, .NET users can use the <code>Teams()</code> property in the class to get or set the teams.

== Syntax ==
'''.GetTeams'''({{APIPrefix|ByRef}} ''arr()'')

===Parameters===
''arr()''
:Required as [[TeamInfo Class|TeamInfo]]. An array of the team IDs for the task.

== Example ==
'''VBA'''

{{APIComment|'Declare a new Repository object and connect to a repository.}}
{{APIPrefix|Dim}} MyRepository {{APIPrefix|As New}} Repository
MyRepository.ConnectToAccessRepository({{APIString|"C:\RSRepository1.rsr19"}})
MyRepository.Project.SetCurrentProject(1)

{{APIComment|'Get a particular task with ID of 2 from repository.}}
{{APIPrefix|Dim}} aTask {{APIPrefix|As}} cCorrectiveTask
{{APIPrefix|Set}} aTask = MyRespository.Task.GetScheduledTask(2)

{{APIComment|'Create instance of TeamInfo.}}
{{APIPrefix|Dim}} Teams() {{APIPrefix|As}} TeamInfo
{{APIPrefix|Call}} aTask.GetTeams(Teams)

CCorrectiveTask.GetTeams Method

2019-03-14T18:26:41Z

David J. Groebel:

{{DISPLAYTITLE:cCorrectiveTask.GetTeams Method}}{{Template:API}}{{Template:APIBreadcrumb|.[[CCorrectiveTask_Class|cCorrectiveTask]]}}

<onlyinclude>Returns an array teams required for the task.</onlyinclude>

'''Remarks''': Designed for VB6/VBA users, but can also be used in .NET. Alternatively, .NET users can use the <code>Teams()</code> property in the class to get or set the teams.

== Syntax ==
'''.GetTeams'''({{APIPrefix|ByRef}} ''arr()'')

===Parameters===
''arr()''
:Required as [[TeamInfo Class|TeamInfo]]. An array of the team IDs for the task.

== Example ==
'''VBA'''

{{APIComment|'Declare a new Repository object and connect to a Synthesis repository.}}
{{APIPrefix|Dim}} MyRepository {{APIPrefix|As New}} Repository
MyRepository.ConnectToAccessRepository({{APIString|"C:\RSRepository1.rsr19"}})
MyRepository.Project.SetCurrentProject(1)

{{APIComment|'Get a particular task with ID of 2 from repository.}}
{{APIPrefix|Dim}} aTask {{APIPrefix|As}} cCorrectiveTask
{{APIPrefix|Set}} aTask = MyRespository.Task.GetCorrectiveTask(2)

{{APIComment|'Create instance of TeamInfo.}}
{{APIPrefix|Dim}} Teams() {{APIPrefix|As}} TeamInfo
{{APIPrefix|Call}} aTask.GetTeams(Teams)

API Changelog

2019-03-14T17:54:51Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Before you upgrade to the latest version of the ReliaSoft API, review what's new and what has changed since the last version. The latest version may have introduced some code-breaking changes, requiring you to make changes to your code before upgrading.

'''How to get the latest version of the ReliaSoft API object library file'''

The object library file is located in the folder where the ReliaSoft applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019".

To get the latest version of the file, choose '''File > Help > Check for Updates''' or download the latest software update from [https://support.hbmprenscia.com HBM Prenscia Support Portal]. You may need to to update the library reference of your custom applications to point to the location of the object library file. For VBA applications, use the ReliaSoftAPI19.tlb file. For .NET applications, use the ReliaSoftAPI19.dll file.

== Highlights ==
Here's a brief overview of the most significant enhancements and deprecations in the API since the previous version.

*For a complete list of all new classes and enumerations added to the object library, see [[New Classes and Enumerations]].

*For a complete list of all new methods and properties added to existing objects, see [[New Members and Constants]].

*For a complete list of all deprecations, see [[Deprecated and Removed Members]].

===19.0.1===
*Changed the name of the libraries to ReliaSoftAPI19.tlb and ReliaSoftAPI19.dll. The API's are also now version dependent.
*Added the following to the [[Repository Class|Repository]] class:
:*[[Repository.Action.GetFMEAActionLocatorLinkPath|Repository.Action.GetFMEAActionLocatorLinkPath]]
*Added the following methods and properties to [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*[[CCorrectiveTask.GetPools_Method|GetPools]]
:*[[CCorrectiveTask.SetPools_Method|SetPools]]
:*[[CCorrectiveTask.GetTeams_Method|GetTeams]]
:*[[CCorrectiveTask.GetTeams_Method|SetTeams]]
:*Pools
:*Teams
*Removed the following methods and property from the [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
*Added the following methods and properties to the [[CScheduledTask Class|cScheduledTask]] class:
:*[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]
:*[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]
:*[[CScheduledTask.GetPools_Method|GetPools]]
:*[[CScheduledTask.SetPools_Method|SetPools]]
:*[[CScheduledTask.GetTeams_Method|GetTeams]]
:*[[CScheduledTask.GetTeams_Method|SetTeams]]
:*OnCondTeams
:*Pools
:*Teams
*Removed the following methods and property from the [[CScheduledTask Class|cScheduledTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
:*OnCondCrewIDs
*Added the [[PoolInfo|PoolInfo]] structure to be used with the [[CScheduledTask.GetPools_Method|GetPools]] and [[CScheduledTask.SetPools_Method|SetPools]] methods, as well as the Pools property.
*Added the [[TeamInfo Class|TeamInfo]] class which contains the following methods and property:
:*[[TeamInfo.GetCrewIDs_Method|GetCrewIDs]]
:*[[TeamInfo.SetCrewIDs_Method|SetCrewIDs]]
:*CrewIDs
*Added the following properties to the [[XfmeaEffect Class|XFMEAEffect]] class:
:*SubSev1Init
:*SubSev1Rev
:*SubSev2Init
:*SubSev2Rev
:*SubSev3Init
:*SubSev3Rev
:*SubSev4Init
:*SubSev4Rev
:*SubSev5Init
:*SubSev5Rev
:*SubSev6Init
:*SubSev6Rev
:*SubSev7Init
:*SubSev7Rev
:*SubSev8Init
:*SubSev8Rev
*Added the following property to the [[XfmeaItem Class|XFMEAItem]] class:
:*Qty

===18.0.3===
*Added the following methods to the [[Repository Class|Repository]] class:
:*[[Repository.Project.GetUserAccessibleProjects|Repository.Project.GetUserAccessibleProjects]]
:*[[Repository.Project.GetUserPermissions|Repository.Project.GetUserPermissions ]]

===18.0.2===
*Increased the length of a scheduled task name up to 2,000 characters to match the desktop applications.

===18.0.1===
Initial public release for Version 2018 applications.

*In the <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object, the type for the NumberInGroup parameter was changed from Integer to Double to allow fractional failure calculations.
*In <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object, added the ReliabilityPolicyType property.
*Added the following properties to the [[WAPlotSettings Class|WAPlotSettings ]]:
**ShowDataPoints
**Show3PWeibullAdjustedItems
**Show3PWeibullUnadjustedItems
*Added the following methods to the Repository class:
:*[[Repository.Xfmea.AssignActionToXfmeaCause Method|Repository.Xfmea.AssignActionToXfmeaCause]]
:*[[Repository.Xfmea.AssignControlToXfmeaCause Method|Repository.Xfmea.AssignControlToXfmeaCause]]
:*[[Repository.Xfmea.GetXfmeaCauseActions Method|Repository.Xfmea.GetXfmeaCauseActions]]
:*[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Repository.Xfmea.GetXfmeaCauseActionsDictionary]]
:*[[Repository.Xfmea.GetXfmeaCauseControls Method|Repository.Xfmea.GetXfmeaCauseControls]]
:*[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method |Repository.Xfmea.GetXfmeaCauseControlsDictionary]]

===11.0.1===
Initial public release for Version 11 applications.

*Added new classes and methods for accessing ''profiles'', which is a new type of Synthesis resource introduced in the latest version of the Synthesis desktop applications.
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class and replaced it with the new [[CProfile Class|cProfile]] class.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class and replaced it with the new [[ProfileSegment Class|ProfileSegment]] class.

===10.1.4===
*Added ability to assign a URD to a BlockSim block in a Synthesis repository. Includes ability to get an array of BlockSim block names, RBDs, fault trees and properties.
*Added ability to hide messages when doing batch calculations and customize event procedures for <code>Repository</code>, <code>WeibullDataSet</code> and <code>ALTADataSet</code> objects.
*For locally-hosted licensing, added the [http://www.synthesisplatform.net/synthesis_api_ante_service.htm Synthesis API Ante Service] to improve response times.

===10.1.1===
*Added ability to get global and reference resources. An optional <code>Filter</code> parameter has been added to the following methods. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]
*Added a class that allows VBA users to change the API library language.
*Added a method for getting a single system hierarchy item.
*Added new user-defined properties to relevant resource classes.
*Deprecated a couple of obsolete properties.
*Various fixes and non-breaking changes.

===10.0.3===
Initial public release for Version 10 applications.

'''Improved flexibility'''
:*Added all new classes and methods for accessing FMEA and related data from Xfmea, RCM++ and RBI.
:*Added several new methods in the Repository class to provide more options for manipulating Synthesis resources. The most significant of these is the ability to get a single resource from a Synthesis repository. You are no longer limited to using arrays to access a particular resource item.

'''New features incorporated'''
:*Added new properties and enumerations in the cAction class to take advantage of the expanded action-tracking capabilities introduced in the latest version of the Synthesis platform. This includes action properties relevant to the project planner and Xfmea/RCM++/RBI test plans.
:*For all resource objects (e.g., cModel, cURD, cCrew, etc.), added a new set of properties for accessing the Synthesis identifiers fields in the platform.

'''Deprecations'''
:*The Repository class has been restructured to organize its growing number of members. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.

API Changelog

2019-03-14T17:52:12Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Before you upgrade to the latest version of the ReliaSoft API, review what's new and what has changed since the last version. The latest version may have introduced some code-breaking changes, requiring you to make changes to your code before upgrading.

'''How to get the latest version of the ReliaSoft API object library file'''

The object library file is located in the folder where the ReliaSoft applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019".

To get the latest version of the file, choose '''File > Help > Check for Updates''' or download the latest software update from our website at [http://www.reliasoft.com/synthesis/downloads.htm http://www.ReliaSoft.com/synthesis/downloads.htm]. You may need to to update the library reference of your custom applications to point to the location of the object library file. For VBA applications, use the SynthesisAPI.tlb file. For .NET applications, use the SynthesisAPI.dll file.

== Highlights ==
Here's a brief overview of the most significant enhancements and deprecations in the API since the previous version.

*For a complete list of all new classes and enumerations added to the object library, see [[New Classes and Enumerations]].

*For a complete list of all new methods and properties added to existing objects, see [[New Members and Constants]].

*For a complete list of all deprecations, see [[Deprecated and Removed Members]].

===19.0.1===
*Changed the name of the libraries to ReliaSoftAPI19.tlb and ReliaSoftAPI19.dll. The API's are also now version dependent.
*Added the following to the [[Repository Class|Repository]] class:
:*[[Repository.Action.GetFMEAActionLocatorLinkPath|Repository.Action.GetFMEAActionLocatorLinkPath]]
*Added the following methods and properties to [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*[[CCorrectiveTask.GetPools_Method|GetPools]]
:*[[CCorrectiveTask.SetPools_Method|SetPools]]
:*[[CCorrectiveTask.GetTeams_Method|GetTeams]]
:*[[CCorrectiveTask.GetTeams_Method|SetTeams]]
:*Pools
:*Teams
*Removed the following methods and property from the [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
*Added the following methods and properties to the [[CScheduledTask Class|cScheduledTask]] class:
:*[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]
:*[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]
:*[[CScheduledTask.GetPools_Method|GetPools]]
:*[[CScheduledTask.SetPools_Method|SetPools]]
:*[[CScheduledTask.GetTeams_Method|GetTeams]]
:*[[CScheduledTask.GetTeams_Method|SetTeams]]
:*OnCondTeams
:*Pools
:*Teams
*Removed the following methods and property from the [[CScheduledTask Class|cScheduledTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
:*OnCondCrewIDs
*Added the [[PoolInfo|PoolInfo]] structure to be used with the [[CScheduledTask.GetPools_Method|GetPools]] and [[CScheduledTask.SetPools_Method|SetPools]] methods, as well as the Pools property.
*Added the [[TeamInfo Class|TeamInfo]] class which contains the following methods and property:
:*[[TeamInfo.GetCrewIDs_Method|GetCrewIDs]]
:*[[TeamInfo.SetCrewIDs_Method|SetCrewIDs]]
:*CrewIDs
*Added the following properties to the [[XfmeaEffect Class|XFMEAEffect]] class:
:*SubSev1Init
:*SubSev1Rev
:*SubSev2Init
:*SubSev2Rev
:*SubSev3Init
:*SubSev3Rev
:*SubSev4Init
:*SubSev4Rev
:*SubSev5Init
:*SubSev5Rev
:*SubSev6Init
:*SubSev6Rev
:*SubSev7Init
:*SubSev7Rev
:*SubSev8Init
:*SubSev8Rev
*Added the following property to the [[XfmeaItem Class|XFMEAItem]] class:
:*Qty

===18.0.3===
*Added the following methods to the [[Repository Class|Repository]] class:
:*[[Repository.Project.GetUserAccessibleProjects|Repository.Project.GetUserAccessibleProjects]]
:*[[Repository.Project.GetUserPermissions|Repository.Project.GetUserPermissions ]]

===18.0.2===
*Increased the length of a scheduled task name up to 2,000 characters to match the desktop applications.

===18.0.1===
Initial public release for Version 2018 applications.

*In the <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object, the type for the NumberInGroup parameter was changed from Integer to Double to allow fractional failure calculations.
*In <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object, added the ReliabilityPolicyType property.
*Added the following properties to the [[WAPlotSettings Class|WAPlotSettings ]]:
**ShowDataPoints
**Show3PWeibullAdjustedItems
**Show3PWeibullUnadjustedItems
*Added the following methods to the Repository class:
:*[[Repository.Xfmea.AssignActionToXfmeaCause Method|Repository.Xfmea.AssignActionToXfmeaCause]]
:*[[Repository.Xfmea.AssignControlToXfmeaCause Method|Repository.Xfmea.AssignControlToXfmeaCause]]
:*[[Repository.Xfmea.GetXfmeaCauseActions Method|Repository.Xfmea.GetXfmeaCauseActions]]
:*[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Repository.Xfmea.GetXfmeaCauseActionsDictionary]]
:*[[Repository.Xfmea.GetXfmeaCauseControls Method|Repository.Xfmea.GetXfmeaCauseControls]]
:*[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method |Repository.Xfmea.GetXfmeaCauseControlsDictionary]]

===11.0.1===
Initial public release for Version 11 applications.

*Added new classes and methods for accessing ''profiles'', which is a new type of Synthesis resource introduced in the latest version of the Synthesis desktop applications.
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class and replaced it with the new [[CProfile Class|cProfile]] class.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class and replaced it with the new [[ProfileSegment Class|ProfileSegment]] class.

===10.1.4===
*Added ability to assign a URD to a BlockSim block in a Synthesis repository. Includes ability to get an array of BlockSim block names, RBDs, fault trees and properties.
*Added ability to hide messages when doing batch calculations and customize event procedures for <code>Repository</code>, <code>WeibullDataSet</code> and <code>ALTADataSet</code> objects.
*For locally-hosted licensing, added the [http://www.synthesisplatform.net/synthesis_api_ante_service.htm Synthesis API Ante Service] to improve response times.

===10.1.1===
*Added ability to get global and reference resources. An optional <code>Filter</code> parameter has been added to the following methods. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]
*Added a class that allows VBA users to change the API library language.
*Added a method for getting a single system hierarchy item.
*Added new user-defined properties to relevant resource classes.
*Deprecated a couple of obsolete properties.
*Various fixes and non-breaking changes.

===10.0.3===
Initial public release for Version 10 applications.

'''Improved flexibility'''
:*Added all new classes and methods for accessing FMEA and related data from Xfmea, RCM++ and RBI.
:*Added several new methods in the Repository class to provide more options for manipulating Synthesis resources. The most significant of these is the ability to get a single resource from a Synthesis repository. You are no longer limited to using arrays to access a particular resource item.

'''New features incorporated'''
:*Added new properties and enumerations in the cAction class to take advantage of the expanded action-tracking capabilities introduced in the latest version of the Synthesis platform. This includes action properties relevant to the project planner and Xfmea/RCM++/RBI test plans.
:*For all resource objects (e.g., cModel, cURD, cCrew, etc.), added a new set of properties for accessing the Synthesis identifiers fields in the platform.

'''Deprecations'''
:*The Repository class has been restructured to organize its growing number of members. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.

API Changelog

2019-03-14T17:51:54Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Before you upgrade to the latest version of the ReliaSoft API, review what's new and what has changed since the last version. The latest version may have introduced some code-breaking changes, requiring you to make changes to your code before upgrading.

'''How to get the latest version of the ReliaSoft API object library file'''

The object library file is located in the folder where the ReliaSoft applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019".

To get the latest version of the file, choose '''File > Help > Check for Updates''' or download the latest software update from our website at [http://www.reliasoft.com/synthesis/downloads.htm http://www.ReliaSoft.com/synthesis/downloads.htm]. You may need to to update the library reference of your custom applications to point to the location of the object library file. For VBA applications, use the SynthesisAPI.tlb file. For .NET applications, use the SynthesisAPI.dll file.

== Highlights ==
Here's a brief overview of the most significant enhancements and deprecations in the API since the previous version.

*For a complete list of all new classes and enumerations added to the object library, see [[New Classes and Enumerations]].

*For a complete list of all new methods and properties added to existing objects, see [[New Members and Constants]].

*For a complete list of all deprecations, see [[Deprecated and Removed Members]].

===19.0.1===
*Changed the name of the libraries to ReliaSoftAPI19.tlb and ReliaSoftAPI19.dll. The API's are also now version dependent.
*Added the following to the [[Repository Class|Repository]] class:
:*[[Repository.Action.GetFMEAActionLocatorLinkPath|Repository.Action.GetFMEAActionLocatorLinkPath]]
*Added the following methods and properties to [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*[[CCorrectiveTask.GetPools_Method|GetPools]]
:*[[CCorrectiveTask.SetPools_Method|SetPools]]
:*[[CCorrectiveTask.GetTeams_Method|GetTeams]]
:*[[CCorrectiveTask.GetTeams_Method|SetTeams]]
:*Pools
:*Teams
*Removed the following methods and property from the [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
*Added the following methods and properties to the [[CScheduledTask Class|cScheduledTask]] class:
:*[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]
:*[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]
:*[[CScheduledTask.GetPools_Method|GetPools]]
:*[[CScheduledTask.SetPools_Method|SetPools]]
:*[[CScheduledTask.GetTeams_Method|GetTeams]]
:*[[CScheduledTask.GetTeams_Method|SetTeams]]
:*OnCondTeams
:*Pools
:*Teams
*Removed the following methods and property from the [[CScheduledTask Class|cScheduledTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
:*OnCondCrewIDs
*Added the [[PoolInfo|PoolInfo]] structure to be used with the [[CScheduledTask.GetPools_Method|GetPools]] and [[CScheduledTask.SetPools_Method|SetPools]] methods, as well as the Pools property.
*Added the [[TeamInfo Class|TeamInfo]] class which contains the following methods and property:
:*[[TeamInfo.GetCrewIDs_Method|GetCrewIDs]]
:*[[TeamInfo.SetCrewIDs_Method|SetCrewIDs]]
:*CrewIDs
*Added the following properties to the [[XfmeaEffect Class|XFMEAEffect]] class:
:*SubSev1Init
:*SubSev1Rev
:*SubSev2Init
:*SubSev2Rev
:*SubSev3Init
:*SubSev3Rev
:*SubSev4Init
:*SubSev4Rev
:*SubSev5Init
:*SubSev5Rev
:*SubSev6Init
:*SubSev6Rev
:*SubSev7Init
:*SubSev7Rev
:*SubSev8Init
:*SubSev8Rev
*Added the following property to the [[XfmeaItem Class|XFMEAItem]] class:
:*Qty

===18.0.3===
*Added the following methods to the [[Repository Class|Repository]] class:
:*[[Repository.Project.GetUserAccessibleProjects|Repository.Project.GetUserAccessibleProjects]]
:*[[Repository.Project.GetUserPermissions|Repository.Project.GetUserPermissions ]]

===18.0.2===
*Increased the length of a scheduled task name up to 2,000 characters to match the desktop applications.

===18.0.1===
Initial public release for Version 2018 applications.

*In the <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object, the type for the NumberInGroup parameter was changed from Integer to Double to allow fractional failure calculations.
*In <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object, added the ReliabilityPolicyType property.
*Added the following properties to the [[WAPlotSettings Class|WAPlotSettings ]]:
**ShowDataPoints
**Show3PWeibullAdjustedItems
**Show3PWeibullUnadjustedItems
*Added the following methods to the Repository class:
:*[[Repository.Xfmea.AssignActionToXfmeaCause Method|Repository.Xfmea.AssignActionToXfmeaCause]]
:*[[Repository.Xfmea.AssignControlToXfmeaCause Method|Repository.Xfmea.AssignControlToXfmeaCause]]
:*[[Repository.Xfmea.GetXfmeaCauseActions Method|Repository.Xfmea.GetXfmeaCauseActions]]
:*[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Repository.Xfmea.GetXfmeaCauseActionsDictionary]]
:*[[Repository.Xfmea.GetXfmeaCauseControls Method|Repository.Xfmea.GetXfmeaCauseControls]]
:*[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method |Repository.Xfmea.GetXfmeaCauseControlsDictionary]]

===11.0.1===
Initial public release for Version 11 applications.

*Added new classes and methods for accessing ''profiles'', which is a new type of Synthesis resource introduced in the latest version of the Synthesis desktop applications.
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class and replaced it with the new [[CProfile Class|cProfile]] class.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class and replaced it with the new [[ProfileSegment Class|ProfileSegment]] class.

===10.1.4===
*Added ability to assign a URD to a BlockSim block in a Synthesis repository. Includes ability to get an array of BlockSim block names, RBDs, fault trees and properties.
*Added ability to hide messages when doing batch calculations and customize event procedures for <code>Repository</code>, <code>WeibullDataSet</code> and <code>ALTADataSet</code> objects.
*For locally-hosted licensing, added the [http://www.synthesisplatform.net/synthesis_api_ante_service.htm Synthesis API Ante Service] to improve response times.

===10.1.1===
*Added ability to get global and reference resources. An optional <code>Filter</code> parameter has been added to the following methods. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]
*Added a class that allows VBA users to change the API library language.
*Added a method for getting a single system hierarchy item.
*Added new user-defined properties to relevant resource classes.
*Deprecated a couple of obsolete properties.
*Various fixes and non-breaking changes.

===10.0.3===
Initial public release for Version 10 applications.

'''Improved flexibility'''
:*Added all new classes and methods for accessing FMEA and related data from Xfmea, RCM++ and RBI.
:*Added several new methods in the Repository class to provide more options for manipulating Synthesis resources. The most significant of these is the ability to get a single resource from a Synthesis repository. You are no longer limited to using arrays to access a particular resource item.

'''New features incorporated'''
:*Added new properties and enumerations in the cAction class to take advantage of the expanded action-tracking capabilities introduced in the latest version of the Synthesis platform. This includes action properties relevant to the project planner and Xfmea/RCM++/RBI test plans.
:*For all resource objects (e.g., cModel, cURD, cCrew, etc.), added a new set of properties for accessing the Synthesis identifiers fields in the platform.

'''Deprecations'''
:*The Repository class has been restructured to organize its growing number of members. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.

ReliaSoft API Object IDs

2019-03-14T17:51:14Z

David J. Groebel:

{{Template:API}}
{{Template:BacktoPrevPage}}


Each item in a ReliaSoft repository is identified by a unique record identifier called an ''object ID''. Object IDs can help you trace responses from the API, which are helpful when learning how to use the API to read/write data to a repository.

To display the object ID in a ReliaSoft desktop application, choose '''File > Application Setup''', then click '''Other''' under the '''Synthesis Settings''' heading in the navigation panel. Select the check box for '''Display Object IDs'''. The object IDs will be displayed for the following items:

{|border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse; text-align: left; cellborder"
|- style="background:#F2F2F2;"
!<span style="color:#585858;">Item</span>
!<span style="color:#585858;">Location of ID in the application</span>
|-
|Project||The ID is displayed in two locations:

* The Project Properties window ('''Project > Management > Edit Project Properties''') displays the project's object ID at the caption bar of the window.

* The Manage Projects window ('''Project > Management > Manage Projects''') displays a column containing the object IDs of each project in the database.
|-
|Resource (e.g., models,URDs, etc.)||The Resource Manager ('''Home > Synthesis > Resource Manager''') displays a column containing the object IDs of the resources.
|-
|Xfmea, RCM++ or RBI system hierarchy item||To display the object ID (also called ''record ID'') of a system hierarchy item, right-click any of the column headers in the System Hierarchy panel and choose '''Customize Columns'''. Select the '''Record ID''' check box.
|-
|FMEA records (e.g., functions, causes, etc.)||To display the object IDs of FMEA functions, causes, effects, controls and actions, right-click any of the column headers in the FMEA analysis and choose '''Customize Columns'''. Select the '''Record ID''' check box.
|-
|BlockSim diagrams and block IDs ||The IDs are displayed on the diagram control panel.
|}

API Changelog

2019-03-14T17:44:29Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Before you upgrade to the latest version of the ReliaSoft API, review what's new and what has changed since the last version. The latest version may have introduced some code-breaking changes, requiring you to make changes to your code before upgrading.

'''How to get the latest version of the ReliaSoft API object library file'''

The object library file is located in the folder where the ReliaSoft applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019".

To get the latest version of the file, choose '''File > Help > Check for Updates''' or download the latest software update from our website at [http://www.reliasoft.com/synthesis/downloads.htm http://www.ReliaSoft.com/synthesis/downloads.htm]. You may need to to update the library reference of your custom applications to point to the location of the object library file. For VBA applications, use the SynthesisAPI.tlb file. For .NET applications, use the SynthesisAPI.dll file.

== Highlights ==
Here's a brief overview of the most significant enhancements and deprecations in the API since the previous version.

*For a complete list of all new classes and enumerations added to the object library, see [[New Classes and Enumerations]].

*For a complete list of all new methods and properties added to existing objects, see [[New Members and Constants]].

*For a complete list of all deprecations, see [[Deprecated and Removed Members]].

===19.0.1===
*Changed the name of the libraries to ReliaSoftAPI19.tlb and ReliaSoftAPI19.dll. The API's are also now version dependent.
*Added the following to the [[Repository Class|Repository]] class:
:*[[Repository.Action.GetFMEAActionLocatorLinkPath|Repository.Action.GetFMEAActionLocatorLinkPath]]
*Added the following methods and properties to [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*[[CCorrectiveTask.GetPools_Method|GetPools]]
:*[[CCorrectiveTask.SetPools_Method|SetPools]]
:*[[CCorrectiveTask.GetTeams_Method|GetTeams]]
:*[[CCorrectiveTask.GetTeams_Method|SetTeams]]
:*Pools
:*Teams
*Removed the following methods and property from the [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
*Added the following methods and properties to the [[CScheduledTask Class|cScheduledTask]] class:
:*[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]
:*[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]
:*[[CScheduledTask.GetPools_Method|GetPools]]
:*[[CScheduledTask.SetPools_Method|SetPools]]
:*[[CScheduledTask.GetTeams_Method|GetTeams]]
:*[[CScheduledTask.GetTeams_Method|SetTeams]]
:*OnCondTeams
:*Pools
:*Teams
*Removed the following methods and property from the [[CScheduledTask Class|cScheduledTask]] class:
:*SetCrewIDs
:*GetCrewIDs
:*CrewIDs
:*OnCondCrewIDs
*Added the [[PoolInfo|PoolInfo]] structure to be used with the [[CScheduledTask.GetPools_Method|GetPools]] and [[CScheduledTask.SetPools_Method|SetPools]] methods, as well as the Pools property.
*Added the [[TeamInfo Class|TeamInfo]] class which contains the following methods and property:
:*[[TeamInfo.GetCrewIDs_Method|GetCrewIDs]]
:*[[TeamInfo.SetCrewIDs_Method|SetCrewIDs]]
:*CrewIDs
*Added the following properties to the [[XfmeaEffect Class|XFMEAEffect]] class:
:*SubSev1Init
:*SubSev1Rev
:*SubSev2Init
:*SubSev2Rev
:*SubSev3Init
:*SubSev3Rev
:*SubSev4Init
:*SubSev4Rev
:*SubSev5Init
:*SubSev5Rev
:*SubSev6Init
:*SubSev6Rev
:*SubSev7Init
:*SubSev7Rev
:*SubSev8Init
:*SubSev8Rev
*Added the following property to the [[XfmeaItem Class|XFMEAItem]] class:
:*Qty

===18.0.3===
*Added the following methods to the [[Repository Class|Repository]] class:
:*[[Repository.Project.GetUserAccessibleProjects|Repository.Project.GetUserAccessibleProjects]]
:*[[Repository.Project.GetUserPermissions|Repository.Project.GetUserPermissions ]]

===18.0.2===
*Increased the length of a scheduled task name up to 2,000 characters to match the desktop applications.

===18.0.1===
Initial public release for Version 2018 applications.

*In the <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object, the type for the NumberInGroup parameter was changed from Integer to Double to allow fractional failure calculations.
*In <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object, added the ReliabilityPolicyType property.
*Added the following properties to the [[WAPlotSettings Class|WAPlotSettings ]]:
**ShowDataPoints
**Show3PWeibullAdjustedItems
**Show3PWeibullUnadjustedItems
*Added the following methods to the Repository class:
:*[[Repository.Xfmea.AssignActionToXfmeaCause Method|Repository.Xfmea.AssignActionToXfmeaCause]]
:*[[Repository.Xfmea.AssignControlToXfmeaCause Method|Repository.Xfmea.AssignControlToXfmeaCause]]
:*[[Repository.Xfmea.GetXfmeaCauseActions Method|Repository.Xfmea.GetXfmeaCauseActions]]
:*[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Repository.Xfmea.GetXfmeaCauseActionsDictionary]]
:*[[Repository.Xfmea.GetXfmeaCauseControls Method|Repository.Xfmea.GetXfmeaCauseControls]]
:*[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method |Repository.Xfmea.GetXfmeaCauseControlsDictionary]]

===11.0.1===
Initial public release for Version 11 applications.

*Added new classes and methods for accessing ''profiles'', which is a new type of Synthesis resource introduced in the latest version of the Synthesis desktop applications.
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class and replaced it with the new [[CProfile Class|cProfile]] class.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class and replaced it with the new [[ProfileSegment Class|ProfileSegment]] class.

===10.1.4===
*Added ability to assign a URD to a BlockSim block in a Synthesis repository. Includes ability to get an array of BlockSim block names, RBDs, fault trees and properties.
*Added ability to hide messages when doing batch calculations and customize event procedures for <code>Repository</code>, <code>WeibullDataSet</code> and <code>ALTADataSet</code> objects.
*For locally-hosted licensing, added the [http://www.synthesisplatform.net/synthesis_api_ante_service.htm Synthesis API Ante Service] to improve response times.

===10.1.1===
*Added ability to get global and reference resources. An optional <code>Filter</code> parameter has been added to the following methods. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]
*Added a class that allows VBA users to change the API library language.
*Added a method for getting a single system hierarchy item.
*Added new user-defined properties to relevant resource classes.
*Deprecated a couple of obsolete properties.
*Various fixes and non-breaking changes.

===10.0.3===
Initial public release for Version 10 applications.

'''Improved flexibility'''
:*Added all new classes and methods for accessing FMEA and related data from Xfmea, RCM++ and RBI.
:*Added several new methods in the Repository class to provide more options for manipulating Synthesis resources. The most significant of these is the ability to get a single resource from a Synthesis repository. You are no longer limited to using arrays to access a particular resource item.

'''New features incorporated'''
:*Added new properties and enumerations in the cAction class to take advantage of the expanded action-tracking capabilities introduced in the latest version of the Synthesis platform. This includes action properties relevant to the project planner and Xfmea/RCM++/RBI test plans.
:*For all resource objects (e.g., cModel, cURD, cCrew, etc.), added a new set of properties for accessing the Synthesis identifiers fields in the platform.

'''Deprecations'''
:*The Repository class has been restructured to organize its growing number of members. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.

Deprecated and Removed Members

2019-03-14T17:32:32Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Below is a summary of what has been changed, removed and deprecated in the Synthesis API since its previous version. The status of an object member may be any of the following:

*'''Changed''' - The syntax of the member has changed.
*'''Deprecated''' - The member is obsolete and may be removed in future versions of the API. Do not use it in new applications.
*'''Removed''' - The member has been removed from the object model.

==Revisions since 19.0.1==
*'''<span style="color:#FCF8F8; background-color:#1D572F">  Major  </span>''' Removed the following depracated properties from the [[Repository Class|Repository]] class. The methods with the same names exist in the relevant sub-sections (for example instead of Repository.GetAllProjects, use Repository.Project.GetAllProjects).
:*GetAllProjects
:*GetCurrentProjects
:*SetCurrentProject
:*GetAllUnits
:*GetDefaultUnitID
:*GetAllModelsInfo
:*GetModel
:*GetAllModels
:*AddModel
:*UpdateModel
:*GetAllURDs
:*AddURD
:*UpdateURD
:*GetAllVariables
:*AddVariable
:*UpdateVariable
:*GetAllCorrectiveTasks
:*AddCorrectiveTask
:*UpdateCorrectiveTask
:*GetAllScheduledTasks
:*AddScheduledTask
:*UpdateScheduledTask
:*GetAllTaskTypes
:*GetAllCrews
:*AddCrew
:*UpdateCrew
:*GetAllPools
:*AddPool
:*UpdatePool
:*GetAllActions
:*AddAction
:*UpdateAction
:*ImportBlockSimXMLFile
:*ExportBlockSimXMLFile
:*SaveRawDataSet
:*GetAllXfracasEntities
:*ImportXfracasXmlFile
:*ImportXfracasXmlString
:*ImportXfracasXml
:*SerializeXMLObjectToByteArray
:*ProcessXfracasImports
:*WriteToDiagnosticsLog
:*WriteToDiagnosticsLog

*Removed the following obsolete methods and properties from [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*[[CCorrectiveTask.GetCrewIDs_Method|GetCrewIDs]]
:*[[CCorrectiveTask.SetCrewIDs_Method|SetCrewIDs]]
:*CrewIDs
:*PoolID

*Removed the following obsolete methods and properties from [[CScheduledTask Class|cScheduledTask]] class:
:*[[CScheduledTask.GetCrewIDs_Method|GetCrewIDs]]
:*[[CScheduledTask.SetCrewIDs_Method|SetCrewIDs]]
:*PoolID
:*OnCondCrewIDs
:*OnCondPoolID

==Revisions since 11.0.1==
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class. Use the [[CProfile Class|cProfile]] class going forward.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class. Use the [[ProfileSegment Class|ProfileSegment]] class going forward.

==Revisions since 10.1.1==
*Removed the obsolete <code>Nr</code> property in [[XfmeaItem Class|XfmeaItem]] class. Use the <code>PartNr</code> property going forward.
*Removed the obsolete <code>OnCondPerformTaskEvenIfItBringsSysDown</code> property in [[CScheduledTask_Class|cScheduledTask]] class.
*Non-breaking changes were made to the following methods. An optional <code>Filter</code> parameter has been added to give the ability to get global or reference resources. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]

==Revisions since 10.0.3==
*'''<span style="color:#FCF8F8; background-color:#1D572F">  Major  </span>''' The [[Repository Class|Repository]] class has been restructured. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.
* Deprecated the [[Repository.Model.GetAllModelsInfo|Repository.Model.GetAllModelsInfo()]] method.
* Removed the following obsolete properties in [[CAction Class|cAction]] class:
:*AppDate
:*AppUserID
:*CompDate
:*DueDate
:*Duration
:*EstCost
:*PersonResp
:*RespUserID
:*ShortDsc
:*StartDate
:*StatusFlag
*Removed the following obsolete properties in [[CScheduledTask_Class|cScheduledTask]] class:
:*TaskFrequencyIDOrig
:*TaskFrequencyUnitIDOrig
:*TaskFrequencyValueOrig
:*TaskFreqValueVariableIDOrig

Deprecated and Removed Members

2019-03-14T17:32:17Z

David J. Groebel:

CCorrectiveTask Class

2019-03-14T17:31:08Z

David J. Groebel:

{{DISPLAYTITLE:cCorrectiveTask Class}}{{Template:API}}{{Template:APIBreadcrumb}}

<onlyinclude>Represents a corrective task resource.</onlyinclude>

==Constructors==
{| {{APITable}}
|-
| style="width: 240px;"|CCorrectiveTask||Creates an instance of the cCorrectiveTask class.
|-
|[[CCorrectiveTask Constructors|cCorrectiveTask()]]||{{:CCorrectiveTask Constructors}}
|}

==Methods==
{| {{APITable}}
|-
|style="width: 240px;"|[[CCorrectiveTask.GetPools_Method|GetPools]]||{{:CCorrectiveTask.GetPools_Method}}
|-
|[[CCorrectiveTask.SetPools_Method|SetPools]]||{{:CCorrectiveTask.SetPools_Method}}
|-
|[[CCorrectiveTask.GetTeams_Method|GetTeams]]||{{:CCorrectiveTask.GetTeams_Method}}
|-
|[[CCorrectiveTask.SetTeams_Method|SetTeams]]||{{:CCorrectiveTask.SetTeams_Method}}
|}

== Properties ==
{| {{APITable}}
|-
| style="width: 240px;"|BringItemDown||Indicates whether the task will bring the item down. '''Boolean'''. Default value = True.
|-
|BringSystemDown||Indicates whether the task will bring the system down. '''Boolean'''. Default value = False.
|-
|DurationModelID||Gets or sets the numeric ID of the duration model assigned to the task. '''Integer'''.
|-
|ID||Gets the numeric ID of the task. '''Integer'''
|-
|{{Template:API_TxtIdentifiers}}
|-
|MiscCostModelID||Gets or sets the numeric ID of the model that represents the cost per task. '''Integer'''.
|-
|MiscCostPerTimeModelID||Gets or sets the numeric ID of the model that represents the downtime rate. '''Integer'''.
|-
|Name||Gets or sets the name of the task. '''String'''.
|-
|PerformTaskEvenIfItBringsSysDown||Indicates whether the task should be performed if bringing the item down causes the system to go down. '''Boolean'''. Default value = True.
|-
|ProjectID||Gets the numeric ID of the project the task belongs to. '''Integer'''.
|-
|ResFactorType||Gets or sets a value from the '''[[TaskRestorationTypeEnum Enumeration|TaskRestorationTypeEnum]]''', which specifies the effect of the restoration. Default value = 1 (restores all accumulated damage).
|-
|ResFactorValue||Gets or sets the restoration amount (0.9 = 90% restoration). A value = 1 indicates an as good as new condition, a value = 0 indicates an as bad as old condition. A values greater than zero but less than 1 indicates a partial restoration. '''Double'''.
|-
|TaskFrequencyID||Gets or sets a value from the '''[[TaskFrequencyEnum Enumeration|TaskFrequencyEnum]]''', which specifies the frequency at which the task is performed. Default value = 8 (task is performed upon item failure).
|-
|Teams||Returns a '''{{APIPrefix|List}}(Of [[TeamInfo Class|TeamInfo]])''' containing teams assigned for the task (in the order of priority). (.NET Only)
|}

==See Also==
*[[Repository.Task.AddCorrectiveTask|Repository.Task.AddCorrectiveTask Method]]
*[[Repository.Task.GetAllCorrectiveTasks|Repository.Task.GetAllCorrectiveTasks Method]]
*[[Repository.Task.GetCorrectiveTask|Repository.Task.GetCorrectiveTask Method]]
*[[Repository.Task.UpdateCorrectiveTask|Repository.Task.UpdateCorrectiveTask Method]]

API Changelog

2019-03-14T17:30:28Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Before you upgrade to the latest version of the ReliaSoft API, review what's new and what has changed since the last version. The latest version may have introduced some code-breaking changes, requiring you to make changes to your code before upgrading.

'''How to get the latest version of the ReliaSoft API object library file'''

The object library file is located in the folder where the ReliaSoft applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019".

To get the latest version of the file, choose '''File > Help > Check for Updates''' or download the latest software update from our website at [http://www.reliasoft.com/synthesis/downloads.htm http://www.ReliaSoft.com/synthesis/downloads.htm]. You may need to to update the library reference of your custom applications to point to the location of the object library file. For VBA applications, use the SynthesisAPI.tlb file. For .NET applications, use the SynthesisAPI.dll file.

== Highlights ==
Here's a brief overview of the most significant enhancements and deprecations in the API since the previous version.

*For a complete list of all new classes and enumerations added to the object library, see [[New Classes and Enumerations]].

*For a complete list of all new methods and properties added to existing objects, see [[New Members and Constants]].

*For a complete list of all deprecations, see [[Deprecated and Removed Members]].

===19.0.1===
*Changed the name of the libraries to ReliaSoftAPI19.tlb and ReliaSoftAPI19.dll. The API's are also now version dependent.
*Added the following to the [[Repository Class|Repository]] class:
:*[[Repository.Action.GetFMEAActionLocatorLinkPath|Repository.Action.GetFMEAActionLocatorLinkPath]]
*Added the following to the [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*[[CCorrectiveTask.GetPools_Method|GetPools]]
:*[[CCorrectiveTask.SetPools_Method|SetPools]]
:*[[CCorrectiveTask.GetTeams_Method|GetTeams]]
:*[[CCorrectiveTask.GetTeams_Method|SetTeams]]
*Added the following properties to the [[CCorrectiveTask Class|cCorrectiveTask]] class:
:*Pools
:*Teams
*Added the following to the [[CScheduledTask Class|cScheduledTask]] class:
:*[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]
:*[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]
:*[[CScheduledTask.GetPools_Method|GetPools]]
:*[[CScheduledTask.SetPools_Method|SetPools]]
:*[[CScheduledTask.GetTeams_Method|GetTeams]]
:*[[CScheduledTask.GetTeams_Method|SetTeams]]
*Added the following properties to the [[CScheduledTask Class|cScheduledTask]] class:
:*OnCondTeams
:*Pools
:*Teams
*Added the following properties to the [[XfmeaEffect Class|XFMEAEffect]] class:
:*SubSev1Init
:*SubSev1Rev
:*SubSev2Init
:*SubSev2Rev
:*SubSev3Init
:*SubSev3Rev
:*SubSev4Init
:*SubSev4Rev
:*SubSev5Init
:*SubSev5Rev
:*SubSev6Init
:*SubSev6Rev
:*SubSev7Init
:*SubSev7Rev
:*SubSev8Init
:*SubSev8Rev
*Added the following property to the [[XfmeaItem Class|XFMEAItem]] class:
:*Qty

===18.0.3===
*Added the following methods to the [[Repository Class|Repository]] class:
:*[[Repository.Project.GetUserAccessibleProjects|Repository.Project.GetUserAccessibleProjects]]
:*[[Repository.Project.GetUserPermissions|Repository.Project.GetUserPermissions ]]

===18.0.2===
*Increased the length of a scheduled task name up to 2,000 characters to match the desktop applications.

===18.0.1===
Initial public release for Version 2018 applications.

*In the <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object, the type for the NumberInGroup parameter was changed from Integer to Double to allow fractional failure calculations.
*In <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object, added the ReliabilityPolicyType property.
*Added the following properties to the [[WAPlotSettings Class|WAPlotSettings ]]:
**ShowDataPoints
**Show3PWeibullAdjustedItems
**Show3PWeibullUnadjustedItems
*Added the following methods to the Repository class:
:*[[Repository.Xfmea.AssignActionToXfmeaCause Method|Repository.Xfmea.AssignActionToXfmeaCause]]
:*[[Repository.Xfmea.AssignControlToXfmeaCause Method|Repository.Xfmea.AssignControlToXfmeaCause]]
:*[[Repository.Xfmea.GetXfmeaCauseActions Method|Repository.Xfmea.GetXfmeaCauseActions]]
:*[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Repository.Xfmea.GetXfmeaCauseActionsDictionary]]
:*[[Repository.Xfmea.GetXfmeaCauseControls Method|Repository.Xfmea.GetXfmeaCauseControls]]
:*[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method |Repository.Xfmea.GetXfmeaCauseControlsDictionary]]

===11.0.1===
Initial public release for Version 11 applications.

*Added new classes and methods for accessing ''profiles'', which is a new type of Synthesis resource introduced in the latest version of the Synthesis desktop applications.
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class and replaced it with the new [[CProfile Class|cProfile]] class.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class and replaced it with the new [[ProfileSegment Class|ProfileSegment]] class.

===10.1.4===
*Added ability to assign a URD to a BlockSim block in a Synthesis repository. Includes ability to get an array of BlockSim block names, RBDs, fault trees and properties.
*Added ability to hide messages when doing batch calculations and customize event procedures for <code>Repository</code>, <code>WeibullDataSet</code> and <code>ALTADataSet</code> objects.
*For locally-hosted licensing, added the [http://www.synthesisplatform.net/synthesis_api_ante_service.htm Synthesis API Ante Service] to improve response times.

===10.1.1===
*Added ability to get global and reference resources. An optional <code>Filter</code> parameter has been added to the following methods. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]
*Added a class that allows VBA users to change the API library language.
*Added a method for getting a single system hierarchy item.
*Added new user-defined properties to relevant resource classes.
*Deprecated a couple of obsolete properties.
*Various fixes and non-breaking changes.

===10.0.3===
Initial public release for Version 10 applications.

'''Improved flexibility'''
:*Added all new classes and methods for accessing FMEA and related data from Xfmea, RCM++ and RBI.
:*Added several new methods in the Repository class to provide more options for manipulating Synthesis resources. The most significant of these is the ability to get a single resource from a Synthesis repository. You are no longer limited to using arrays to access a particular resource item.

'''New features incorporated'''
:*Added new properties and enumerations in the cAction class to take advantage of the expanded action-tracking capabilities introduced in the latest version of the Synthesis platform. This includes action properties relevant to the project planner and Xfmea/RCM++/RBI test plans.
:*For all resource objects (e.g., cModel, cURD, cCrew, etc.), added a new set of properties for accessing the Synthesis identifiers fields in the platform.

'''Deprecations'''
:*The Repository class has been restructured to organize its growing number of members. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.

API Changelog

2019-03-14T17:24:06Z

David J. Groebel:

{{Template:API}}{{Template:APIUpgradesNavBox}}

Before you upgrade to the latest version of the ReliaSoft API, review what's new and what has changed since the last version. The latest version may have introduced some code-breaking changes, requiring you to make changes to your code before upgrading.

'''How to get the latest version of the ReliaSoft API object library file'''

The object library file is located in the folder where the ReliaSoft applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019".

To get the latest version of the file, choose '''File > Help > Check for Updates''' or download the latest software update from our website at [http://www.reliasoft.com/synthesis/downloads.htm http://www.ReliaSoft.com/synthesis/downloads.htm]. You may need to to update the library reference of your custom applications to point to the location of the object library file. For VBA applications, use the SynthesisAPI.tlb file. For .NET applications, use the SynthesisAPI.dll file.

== Highlights ==
Here's a brief overview of the most significant enhancements and deprecations in the API since the previous version.

*For a complete list of all new classes and enumerations added to the object library, see [[New Classes and Enumerations]].

*For a complete list of all new methods and properties added to existing objects, see [[New Members and Constants]].

*For a complete list of all deprecations, see [[Deprecated and Removed Members]].

===19.0.1===
*Changed the name of the libraries to ReliaSoftAPI19.tlb and ReliaSoftAPI19.dll. The API's are also now version dependent.
*Added the following to the Repository class:
:*[[Repository.Action.GetFMEAActionLocatorLinkPath|Repository.Action.GetFMEAActionLocatorLinkPath]]
*Added the following to the cCorrectiveTask class:
:*[[CCorrectiveTask.GetPools_Method|GetPools]]
:*[[CCorrectiveTask.SetPools_Method|SetPools]]
:*[[CCorrectiveTask.GetTeams_Method|GetTeams]]
:*[[CCorrectiveTask.GetTeams_Method|SetTeams]]
*Added the following properties to the cCorrectiveTask Class:
:*Pools
:*Teams
*Added the following to the cScheduledTask class:
:*[[CScheduledTask.OnCondGetTeams_Method|OnCondGetTeams]]
:*[[CScheduledTask.OnCondSetTeams_Method|OnCondSetTeams]]
:*[[CScheduledTask.GetPools_Method|GetPools]]
:*[[CScheduledTask.SetPools_Method|SetPools]]
:*[[CScheduledTask.GetTeams_Method|GetTeams]]
:*[[CScheduledTask.GetTeams_Method|SetTeams]]
*Added the following properties to the cScheduledTask Class:
:*OnCondTeams
:*Pools
:*Teams
*Added the following properties to the XfmeaEffect class:
:*SubSev1Init
:*SubSev1Rev
:*SubSev2Init
:*SubSev2Rev
:*SubSev3Init
:*SubSev3Rev
:*SubSev4Init
:*SubSev4Rev
:*SubSev5Init
:*SubSev5Rev
:*SubSev6Init
:*SubSev6Rev
:*SubSev7Init
:*SubSev7Rev
:*SubSev8Init
:*SubSev8Rev
*Added the following property to the XfmeaItem class:
:*Qty

===18.0.3===
*Added the following methods to the Repository class:
:*[[Repository.Project.GetUserAccessibleProjects|Repository.Project.GetUserAccessibleProjects]]
:*[[Repository.Project.GetUserPermissions|Repository.Project.GetUserPermissions ]]

===18.0.2===
*Increased the length of a scheduled task name up to 2,000 characters to match the desktop applications.

===18.0.1===
Initial public release for Version 2018 applications.

*In the <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object, the type for the NumberInGroup parameter was changed from Integer to Double to allow fractional failure calculations.
*In <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object, added the ReliabilityPolicyType property.
*Added the following properties to the [[WAPlotSettings Class|WAPlotSettings ]]:
**ShowDataPoints
**Show3PWeibullAdjustedItems
**Show3PWeibullUnadjustedItems
*Added the following methods to the Repository class:
:*[[Repository.Xfmea.AssignActionToXfmeaCause Method|Repository.Xfmea.AssignActionToXfmeaCause]]
:*[[Repository.Xfmea.AssignControlToXfmeaCause Method|Repository.Xfmea.AssignControlToXfmeaCause]]
:*[[Repository.Xfmea.GetXfmeaCauseActions Method|Repository.Xfmea.GetXfmeaCauseActions]]
:*[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Repository.Xfmea.GetXfmeaCauseActionsDictionary]]
:*[[Repository.Xfmea.GetXfmeaCauseControls Method|Repository.Xfmea.GetXfmeaCauseControls]]
:*[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method |Repository.Xfmea.GetXfmeaCauseControlsDictionary]]

===11.0.1===
Initial public release for Version 11 applications.

*Added new classes and methods for accessing ''profiles'', which is a new type of Synthesis resource introduced in the latest version of the Synthesis desktop applications.
*Removed the obsolete [[ALTAStressProfile_Class|ALTAStressProfile]] class and replaced it with the new [[CProfile Class|cProfile]] class.
*Removed the obsolete [[ALTASegment Class|ALTASegment]] class and replaced it with the new [[ProfileSegment Class|ProfileSegment]] class.

===10.1.4===
*Added ability to assign a URD to a BlockSim block in a Synthesis repository. Includes ability to get an array of BlockSim block names, RBDs, fault trees and properties.
*Added ability to hide messages when doing batch calculations and customize event procedures for <code>Repository</code>, <code>WeibullDataSet</code> and <code>ALTADataSet</code> objects.
*For locally-hosted licensing, added the [http://www.synthesisplatform.net/synthesis_api_ante_service.htm Synthesis API Ante Service] to improve response times.

===10.1.1===
*Added ability to get global and reference resources. An optional <code>Filter</code> parameter has been added to the following methods. The filter's default value is 0, which returns local resources.
:*[[Repository.Action.GetAllActions]]
:*[[Repository.Control.GetAllXfmeaControls]]
:*[[Repository.Model.GetAllModels]]
:*[[Repository.Model.GetAllModelsInfo]]
:*[[Repository.Crew.GetAllCrews]]
:*[[Repository.Pool.GetAllPools]]
:*[[Repository.Task.GetAllScheduledTasks]]
:*[[Repository.Task.GetAllCorrectiveTasks]]
:*[[Repository.URD.GetAllURDs]]
:*[[Repository.Variable.GetAllVariables]]
*Added a class that allows VBA users to change the API library language.
*Added a method for getting a single system hierarchy item.
*Added new user-defined properties to relevant resource classes.
*Deprecated a couple of obsolete properties.
*Various fixes and non-breaking changes.

===10.0.3===
Initial public release for Version 10 applications.

'''Improved flexibility'''
:*Added all new classes and methods for accessing FMEA and related data from Xfmea, RCM++ and RBI.
:*Added several new methods in the Repository class to provide more options for manipulating Synthesis resources. The most significant of these is the ability to get a single resource from a Synthesis repository. You are no longer limited to using arrays to access a particular resource item.

'''New features incorporated'''
:*Added new properties and enumerations in the cAction class to take advantage of the expanded action-tracking capabilities introduced in the latest version of the Synthesis platform. This includes action properties relevant to the project planner and Xfmea/RCM++/RBI test plans.
:*For all resource objects (e.g., cModel, cURD, cCrew, etc.), added a new set of properties for accessing the Synthesis identifiers fields in the platform.

'''Deprecations'''
:*The Repository class has been restructured to organize its growing number of members. All of its members are now organized into fields named after the object type they apply to. For example, the <code>Repository.GetAllModels()</code> method, which returns a cModel object, has been renamed to <code>Repository.Model.GetAllModels()</code>; similarly, the <code>Repository.ImportBlockSimXMLFile</code> method has been renamed to <code>Repository.BlockSim.ImportBlockSimXMLFile</code>, etc. The previous versions of the methods still exist so your code is not broken, but they are deprecated and may be removed in future versions of the API.

ReliaSoft API Object IDs

2019-03-14T17:03:17Z

David J. Groebel:

{{Template:API}}
{{Template:BacktoPrevPage}}


Each item in a ReliaSoft repository is identified by a unique record identifier called an ''object ID''. Object IDs can help you trace responses from the API, which are helpful when learning how to use the API to read/write data to a repository.

To display the object ID in a ReliaSoft desktop application, choose '''File > Application Setup''', then click '''Other''' under the '''Synthesis Settings''' heading in the navigation panel. Select the check box for '''Display Object IDs'''. The object IDs will be displayed for the following items:

{|border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse; text-align: left; cellborder"
|- style="background:#F2F2F2;"
!<span style="color:#585858;">Item</span>
!<span style="color:#585858;">Location of ID in the application</span>
|-
|Project||The ID is displayed in two locations:

* The Project Properties window ('''Project > Management > Edit Project Properties''') displays the project's object ID at the caption bar of the window.

* The Manage Projects window ('''Project > Management > Manage Projects''') displays a column containing the object IDs of each project in the database.
|-
|Resource (e.g., models,URDs, etc.)||The Resource Manager ('''Project > Synthesis > Resource Manager''') displays a column containing the object IDs of the resources.
|-
|Xfmea, RCM++ or RBI system hierarchy item||To display the object ID (also called ''record ID'') of a system hierarchy item, right-click any of the column headers in the System Hierarchy panel and choose '''Customize Columns'''. Select the '''Record ID''' check box.
|-
|FMEA records (e.g., functions, causes, etc.)||To display the object IDs of FMEA functions, causes, effects, controls and actions, right-click any of the column headers in the FMEA analysis and choose '''Customize Columns'''. Select the '''Record ID''' check box.
|-
|BlockSim diagrams and block IDs ||The IDs are displayed on the diagram control panel.
|}

Synthesis API Object IDs

2019-03-14T17:00:38Z

David J. Groebel: moved Synthesis API Object IDs to ReliaSoft API Object IDs: Remove reference to "Synthesis"

#REDIRECT [[ReliaSoft API Object IDs]]

ReliaSoft API Object IDs

2019-03-14T17:00:38Z

David J. Groebel: moved Synthesis API Object IDs to ReliaSoft API Object IDs: Remove reference to "Synthesis"

{{Template:API}}
{{Template:BacktoPrevPage}}


Each item in a Synthesis repository is identified by a unique record identifier called an ''object ID''. Object IDs can help you trace responses from the API, which are helpful when learning how to use the API to read/write data to a repository.

To display the object ID in a Synthesis application, choose '''File > Application Setup''', then click '''Other''' under the '''Synthesis Settings''' heading in the navigation panel. Select the check box for '''Display Object IDs'''. The object IDs will be displayed for the following items:

{|border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse; text-align: left; cellborder"
|- style="background:#F2F2F2;"
!<span style="color:#585858;">Item</span>
!<span style="color:#585858;">Location of ID in the application</span>
|-
|Project||The ID is displayed in two locations:

* The Project Properties window ('''Project > Management > Edit Project Properties''') displays the project's object ID at the caption bar of the window.

* The Manage Projects window ('''Project > Management > Manage Projects''') displays a column containing the object IDs of each project in the database.
|-
|Resource (e.g., models,URDs, etc.)||The Resource Manager ('''Project > Synthesis > Resource Manager''') displays a column containing the object IDs of the resources.
|-
|Xfmea, RCM++ or RBI system hierarchy item||To display the object ID (also called ''record ID'') of a system hierarchy item, right-click any of the column headers in the System Hierarchy panel and choose '''Customize Columns'''. Select the '''Record ID''' check box.
|-
|FMEA records (e.g., functions, causes, etc.)||To display the object IDs of FMEA functions, causes, effects, controls and actions, right-click any of the column headers in the FMEA analysis and choose '''Customize Columns'''. Select the '''Record ID''' check box.
|-
|BlockSim diagrams and block IDs ||The IDs are displayed on the diagram control panel.
|}

Main Page

2019-03-14T16:57:08Z

David J. Groebel:

{{DISPLAYTITLE:ReliaWiki}} __NOTOC__ __NOEDITSECTION__
<div style="position:relative; float:left; display:block; width:100%; margin:10px;">
ReliaWiki is owned and maintained by [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=p8TH7lvo8O%2FAHl72KXuPWlZmIR3P7GFj HBM Prenscia] and is an extension of  [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=vQQfu%2FkoXaOAQyVYZnqaSTIPBB24C0kx weibull.com]. 
</div>

<div style="position:relative; float:left; width:100%;">

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=blue_triangle.png
|title=Life Data Analysis
|links=
{{TitleBoxLink|link=Life_Data_Analysis_Reference_Book|text=Reference Book}}
{{TitleBoxLink|link=Weibull++_Examples|text=Weibull++ Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=green_triangle.png
|title=System Analysis (RBDs and Fault Trees)
|links=
{{TitleBoxLink|link=System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=BlockSim_Examples|text=BlockSim Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=red_triangle.png
|title=Reliability Growth and Repairable System Analysis
|links=
{{TitleBoxLink|link=Reliability_Growth_and_Repairable_System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=RGA_Examples|text=RGA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=rcm_triangle.png
|title=Reliability Centered Maintenance (RCM)
|links=
{{TitleBoxLink|link=RCM%2B%2B_Examples|text=RCM++ Software Examples}}
}}
</div>

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=yellow_triangle.png
|title=Accelerated Life Testing Data Analysis
|links=
{{TitleBoxLink|link=Accelerated Life Testing Data Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=ALTA_Examples|text=ALTA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=doe_triangle.png
|title=Experiment Design and Analysis (DOE)
|links=
{{TitleBoxLink|link=Experiment_Design_and_Analysis_Reference|text=Reference Book}}

}}

{{TitleBox
|bgcolor=#C8D4E0
|image=fmea_triangle.png
|title=Failure Modes & Effects Analysis (FMEA)
|links=
{{TitleBoxLink|link=FMEA_and_RCM_Articles|text=Articles}}
{{TitleBoxLink|link=Xfmea_Examples|text=Xfmea Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=api_triangle.png
|title=ReliaSoft API
|links=
{{TitleBoxLink|link=ReliaSoft API Reference|text=API Reference}}
{{TitleBoxLink|link=API_Changelog|text=API Changelog}}
}}
</div>
</div>
<div style="position:relative; float:left; width:100%;">
<br><br><cshow logged="1">This text will appear if a user with membership to 'sysop' group views this page</cshow> {{ReliaSoft Footer}}
</div>

Main Page

2019-03-14T16:56:46Z

David J. Groebel:

{{DISPLAYTITLE:ReliaWiki}} __NOTOC__ __NOEDITSECTION__
<div style="position:relative; float:left; display:block; width:100%; margin:10px;">
ReliaWiki is owned and maintained by [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=p8TH7lvo8O%2FAHl72KXuPWlZmIR3P7GFj HBM Prenscia] and is an extension of  [https://koi-3QN72QORVC.marketingautomation.services/net/m?md=vQQfu%2FkoXaOAQyVYZnqaSTIPBB24C0kx weibull.com]. 
</div>

<div style="position:relative; float:left; width:100%;">

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=blue_triangle.png
|title=Life Data Analysis
|links=
{{TitleBoxLink|link=Life_Data_Analysis_Reference_Book|text=Reference Book}}
{{TitleBoxLink|link=Weibull++_Examples|text=Weibull++ Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=green_triangle.png
|title=System Analysis (RBDs and Fault Trees)
|links=
{{TitleBoxLink|link=System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=BlockSim_Examples|text=BlockSim Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=red_triangle.png
|title=Reliability Growth and Repairable System Analysis
|links=
{{TitleBoxLink|link=Reliability_Growth_and_Repairable_System_Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=RGA_Examples|text=RGA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=rcm_triangle.png
|title=Reliability Centered Maintenance (RCM)
|links=
{{TitleBoxLink|link=RCM%2B%2B_Examples|text=RCM++ Software Examples}}
}}
</div>

<div style="position:relative; float:left; width:49%; margin:5px;">
{{TitleBox
|bgcolor=#C8D4E0
|image=yellow_triangle.png
|title=Accelerated Life Testing Data Analysis
|links=
{{TitleBoxLink|link=Accelerated Life Testing Data Analysis_Reference|text=Reference Book}}
{{TitleBoxLink|link=ALTA_Examples|text=ALTA Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=doe_triangle.png
|title=Experiment Design and Analysis (DOE)
|links=
{{TitleBoxLink|link=Experiment_Design_and_Analysis_Reference|text=Reference Book}}

}}

{{TitleBox
|bgcolor=#C8D4E0
|image=fmea_triangle.png
|title=Failure Modes & Effects Analysis (FMEA)
|links=
{{TitleBoxLink|link=FMEA_and_RCM_Articles|text=Articles}}
{{TitleBoxLink|link=Xfmea_Examples|text=Xfmea Software Examples}}
}}

{{TitleBox
|bgcolor=#C8D4E0
|image=api_triangle.png
|title=Synthesis API
|links=
{{TitleBoxLink|link=ReliaSoft API Reference|text=API Reference}}
{{TitleBoxLink|link=API_Changelog|text=API Changelog}}
}}
</div>
</div>
<div style="position:relative; float:left; width:100%;">
<br><br><cshow logged="1">This text will appear if a user with membership to 'sysop' group views this page</cshow> {{ReliaSoft Footer}}
</div>

Synthesis API Reference

2019-03-14T16:56:08Z

David J. Groebel: moved Synthesis API Reference to ReliaSoft API Reference: Remove reference to "Synthesis"

#REDIRECT [[ReliaSoft API Reference]]

ReliaSoft API Reference

2019-03-14T16:56:08Z

David J. Groebel: moved Synthesis API Reference to ReliaSoft API Reference: Remove reference to "Synthesis"

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [https://www.reliasoft.com/products/reliability-management/xfracas/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." As of Version 2019, the library names are now version dependent. For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file. Prior to Version 2019, the files to use were SynthesisAPI.tlb (VBA) and SynthesisAPI.dll (.NET).

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the [https://support.hbmprenscia.com HBM Prenscia Support Portal].

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls.)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

ReliaSoft API Reference

2019-03-14T15:50:00Z

David J. Groebel:

ReliaSoft API Reference

2019-03-14T15:49:37Z

David J. Groebel:

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [https://www.reliasoft.com/products/reliability-management/xfracas/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." As of Version 2019, the library names are now version dependent. For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file. Prior to Version 2019, the files to use were SynthesisAPI.tlb (VBA) and SynthesisAPI.dll (.NET).

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the [https://support.hbmprenscia.com Support Portal].

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls.)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

ReliaSoft API Reference

2019-03-14T15:48:00Z

David J. Groebel:

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [https://www.reliasoft.com/products/reliability-management/xfracas/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." As of Version 2019, the library names are now version dependent. For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file. Prior to Version 2019, the files to use were SynthesisAPI.tlb (VBA) and SynthesisAPI.dll (.NET).

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the Support Portal at https://support.hbmprenscia.com.

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls.)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

ReliaSoft API Reference

2019-03-14T15:42:55Z

David J. Groebel:

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [https://www.reliasoft.com/products/reliability-management/xfracas/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." As of Version 2019, the library names are now version dependent. For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file. Prior to Version 2019, the files to use were SynthesisAPI.tlb (VBA) and SynthesisAPI.dll (.NET).

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the Support Portal at https://support.hbmprenscia.com.

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls. (See [http://www.reliasoft.com/support/rs20024.htm ReliaSoft KB article RS20024].)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

Repository.Action.GetFMEAActionLocatorLinkPath

2019-03-13T23:53:28Z

David J. Groebel:

{{Template:API}}{{Template:APIBreadcrumb|.[[Repository Class|Repository]]}}

<onlyinclude>Creates a locator link file for the action and returns the path.</onlyinclude>

== Syntax ==
'''.Action.GetFMEAActionLocatorLinkPath'''(''actionID'', ''[causeID]'') {{APIPrefix|As}} String

=== Parameters ===
''actionID''
:Required. The ID of the action.

''causeID''
:Optional. The ID of the cause that the action belongs to. Set to 0 to use the first cause where the action is used.

== Example ==

'''VBA'''

{{APIComment|'Declare a new Repository object and connect to a Synthesis repository.}}
{{APIPrefix|Dim}} MyRepository {{APIPrefix|As New}} Repository
MyRepository.ConnectToAccessRepository({{APIString|"C:\RSRepository1.rsr10"}})

{{APIComment|'Get action #1 from project #1.}}
{{APIPrefix|Dim}} MyAction {{APIPrefix|As}} cAction
MyRepository.Project.SetCurrentProject(1)
{{APIPrefix|Set}} MyAction = MyRepository.Action.GetAction(1)
{{APIComment|'Get string which contains the path to the action}}
{{APIPrefix|Dim}} sPath {{APIPrefix|As}} String
sPath = MyAction.GetFMEAActionLocatorLinkPath

Repository Class

2019-03-13T23:53:16Z

David J. Groebel:

{{Template:API}}{{Template:APIBreadcrumb}}<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;"><span style="font-family:arial;font-size:5;color:#585858">Other Versions: [[Repository Class 10|Version 10]]</span></div>

Represents a Synthesis repository.

'''Remarks''': Use any of the first four methods to establish a connection to a Synthesis repository. Once you have a connection, you can use any of the rest of the methods to read/write data to the repository.

==Constructors==
{| {{APITable}}
|-
| style="width: 240px;"|Repository||Creates an instance of the Repository class.
|}

==Methods==
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.ConnectToAccessRepository|ConnectToAccessRepository]]||{{:Repository.ConnectToAccessRepository}}
|-
|[[Repository.ConnectToOracleRepository|ConnectToOracleRepository]]||{{:Repository.ConnectToOracleRepository}}
|-
|[[Repository.ConnectToRepository|ConnectToRepository]]||{{:Repository.ConnectToRepository}}
|-
|[[Repository.ConnectToSQLRepository|ConnectToSQLRepository]]||{{:Repository.ConnectToSQLRepository}}
|-
|[[Repository.DisconnectFromRepository|DisconnectFromRepository]]||{{:Repository.DisconnectFromRepository}}
|}

===<span style="color:#585858">Action</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Action.AddAction|Action.AddAction]]||{{:Repository.Action.AddAction}}
|-
|[[Repository.Action.GetAction|Action.GetAction]]||{{:Repository.Action.GetAction}}
|-
|[[Repository.Action.GetAllActions|Action.GetAllActions]]||{{:Repository.Action.GetAllActions}}
|-
|[[Repository.Action.GetAllActionsDictionary|Action.GetAllActionsDictionary]]||{{:Repository.Action.GetAllActionsDictionary}}
|-
|[[Repository.Action.GetFMEAActionLocatorLinkPath|Action.GetFMEAActionLocatorLinkPath]]||{{:Repository.Action.GetFMEAActionLocatorLinkPath}}
|-
|[[Repository.Action.UpdateAction|Action.UpdateAction]]||{{:Repository.Action.UpdateAction}}
|}

===<span style="color:#585858">BlockSim</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.BlockSim.ExportBlockSimXMLFile|BlockSim.ExportBlockSimXMLFile]]||{{:Repository.BlockSim.ExportBlockSimXMLFile}}
|-
|[[Repository.BlockSim.GetAllFaultTrees|BlockSim.GetAllFaultTrees]]||{{:Repository.BlockSim.GetAllFaultTrees}}
|-
|[[Repository.BlockSim.GetAllRBDBlocksData|BlockSim.GetAllRBDBlocksData]]||{{:Repository.BlockSim.GetAllRBDBlocksData}}
|-
|[[Repository.BlockSim.GetAllRBDs|BlockSim.GetAllRBDs]]||{{:Repository.BlockSim.GetAllRBDs}}
|-
|[[Repository.BlockSim.GetRBDBlockData|BlockSim.GetRBDBlockData]]||{{:Repository.BlockSim.GetRBDBlockData}}
|-
|[[Repository.BlockSim.ImportBlockSimXMLFile|BlockSim.ImportBlockSimXMLFile]]||{{:Repository.BlockSim.ImportBlockSimXMLFile}}
|-
|[[Repository.BlockSim.UpdateRBDBlockData|BlockSim.UpdateRBDBlockData]]||{{:Repository.BlockSim.UpdateRBDBlockData}}
|}

===<span style="color:#585858">Control</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Control.AddXfmeaControl|Control.AddXfmeaControl]]||{{:Repository.Control.AddXfmeaControl}}
|-
|[[Repository.Control.GetAllXfmeaControls|Control.GetAllXfmeaControls]]||{{:Repository.Control.GetAllXfmeaControls}}
|-
|[[Repository.Control.GetAllXfmeaControlsDictionary|Control.GetAllXfmeaControlsDictionary]]||{{:Repository.Control.GetAllXfmeaControlsDictionary}}
|-
|[[Repository.Control.GetXfmeaControl|Control.GetXfmeaControl]]||{{:Repository.Control.GetXfmeaControl}}
|-
|[[Repository.Control.UpdateXfmeaControl|Control.UpdateXfmeaControl]]||{{:Repository.Control.UpdateXfmeaControl}}
|}

===<span style="color:#585858">Crew</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Crew.AddCrew|Crew.AddCrew]]||{{:Repository.AddCrew}}
|-
|[[Repository.Crew.GetAllCrews|Crew.GetAllCrews]]||{{:Repository.GetAllCrews}}
|-
|[[Repository.Crew.GetCrew|Crew.GetCrew]]||{{:Repository.GetCrew}}
|-
|[[Repository.Crew.UpdateCrew|Crew.UpdateCrew]]||{{:Repository.UpdateCrew}}
|}

===<span style="color:#585858">Data Warehouse</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.DataWarehouse.SaveRawDataSet|DataWarehouse.SaveRawDataSet]]||{{:Repository.DataWarehouse.SaveRawDataSet}}
|}

===<span style="color:#585858">Model</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Model.AddModel|Model.AddModel]]||{{:Repository.Model.AddModel}}
|-
|[[Repository.Model.DeleteModel|Model.DeleteModel]]||{{:Repository.Model.DeleteModel}}
|-
|[[Repository.Model.GetAllModels|Model.GetAllModels]]||{{:Repository.Model.GetAllModels}}
|-
|[[Repository.Model.GetModel|Model.GetModel]]||{{:Repository.Model.GetModel}}
|-
|[[Repository.Model.IsModelUsed|Model.IsModelUsed]]||{{:Repository.Model.IsModelUsed}}
|-
|[[Repository.Model.UpdateModel|Model.UpdateModel]]||{{:Repository.Model.UpdateModel}}
|-
|[[Repository.Model.GetAllModelsInfo|Model.GetAllModelsInfo]]||{{:Repository.Model.GetAllModelsInfo}}
|}

===<span style="color:#585858">Pool</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Pool.AddPool|Pool.AddPool]]||{{:Repository.Pool.AddPool}}
|-
|[[Repository.Pool.GetAllPools|Pool.GetAllPools]]||{{:Repository.Pool.GetAllPools}}
|-
|[[Repository.Pool.GetPool|Pool.GetPool]]||{{:Repository.Pool.GetPool}}
|-
|[[Repository.Pool.UpdatePool|Pool.UpdatePool]]||{{:Repository.Pool.UpdatePool}}
|}

===<span style="color:#585858">Profiles</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Profile.AddProfile|Profile.AddProfile]]||{{:Repository.Profile.AddProfile}}
|-
|[[Repository.Profile.GetProfile|Profile.GetProfile]]||{{:Repository.Profile.GetProfile}}
|-
|[[Repository.Profile.GetAllProfiles|Profile.GetAllProfiles]]||{{:Repository.Profile.GetAllProfiles}}
|-
|[[Repository.Profile.UpdateProfile|Profile.UpdateProfile]]||{{:Repository.Profile.UpdateProfile}}
|}

===<span style="color:#585858">Project</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Project.GetAllProjects|Project.GetAllProjects]]||{{:Repository.Project.GetAllProjects}}
|-
|[[Repository.Project.GetCurrentProject|Project.GetCurrentProject]]||{{:Repository.Project.GetCurrentProject}}
|-
|[[Repository.Project.GetUserAccessibleProjects|Project.GetUserAccessibleProjects]]||{{:Repository.Project.GetUserAccessibleProjects}}
|-
|[[Repository.Project.GetUserPermissions|Project.GetUserPermissions]]||{{:Repository.Project.GetUserPermissions}}
|-
|[[Repository.Project.SetCurrentProject|Project.SetCurrentProject]]||{{:Repository.Project.SetCurrentProject}}
|}

===<span style="color:#585858">Task</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Task.AddCorrectiveTask|Task.AddCorrectiveTask]]||{{:Repository.Task.AddCorrectiveTask}}
|-
|[[Repository.Task.AddScheduledTask|Task.AddScheduledTask]]||{{:Repository.Task.AddScheduledTask}}
|-
|[[Repository.Task.GetAllCorrectiveTasks|Task.GetAllCorrectiveTasks]]||{{:Repository.Task.GetAllCorrectiveTasks}}
|-
|[[Repository.Task.GetAllScheduledTasks|Task.GetAllScheduledTasks]]||{{:Repository.Task.GetAllScheduledTasks}}
|-
|[[Repository.Task.GetAllTaskTypes|Task.GetAllTaskTypes]]||{{:Repository.Task.GetAllTaskTypes}}
|-
|[[Repository.Task.GetCorrectiveTask|Task.GetCorrectiveTask]]||{{:Repository.Task.GetCorrectiveTask}}
|-
|[[Repository.Task.GetScheduledTask|Task.GetScheduledTask]]||{{:Repository.Task.GetScheduledTask}}
|-
|[[Repository.Task.UpdateCorrectiveTask|Task.UpdateCorrectiveTask]]||{{:Repository.Task.UpdateCorrectiveTask}}
|-
|[[Repository.Task.UpdateScheduledTask|Task.UpdateScheduledTask]]||{{:Repository.Task.UpdateScheduledTask}}
|}

===<span style="color:#585858">Unit</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Unit.GetAllUnits|Unit.GetAllUnits]]||{{:Repository.Unit.GetAllUnits}}
|}

===<span style="color:#585858">URD</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.URD.AddURD|URD.AddURD]]||{{:Repository.URD.AddURD}}
|-
|[[Repository.URD.GetAllURDs|URD.GetAllURDs]]||{{:Repository.URD.GetAllURDs}}
|-
|[[Repository.URD.GetURD|URD.GetURD]]||{{:Repository.URD.GetURD}}
|-
|[[Repository.URD.UpdateURD|URD.UpdateURD]]||{{:Repository.URD.UpdateURD}}
|}

===<span style="color:#585858">Variable</span>===
{| {{APITable}}
|-
| style="width: 240px;"|[[Repository.Variable.AddVariable|Variables.AddVariable]]||{{:Repository.Variable.AddVariable}}
|-
|[[Repository.Variable.GetAllVariables|Variables.GetAllVariables]]||{{:Repository.Variable.GetAllVariables}}
|-
|[[Repository.Variable.GetVariable|Variables.GetVariable]]||{{:Repository.Variable.GetVariable}}
|-
|[[Repository.Variable.UpdateVariable|Variables.UpdateVariable]]||{{:Repository.Variable.UpdateVariable}}
|}

===<span style="color:#585858">XFMEA</span>===
{| {{APITable}}
|-
| style="width: 250px;"|[[Repository.Xfmea.AddItemToSystemHierarchy Method|Xfmea.AddItemToSystemHierarchy]]||{{:Repository.Xfmea.AddItemToSystemHierarchy Method}}
|-
|[[Repository.Xfmea.AddXfmeaCause Method|Xfmea.AddXfmeaCause]]|| {{:Repository.Xfmea.AddXfmeaCause Method}}
|-
|[[Repository.Xfmea.AddXfmeaEffect Method|Xfmea.AddXfmeaEffect]]||{{:Repository.Xfmea.AddXfmeaEffect Method}}
|-
|[[Repository.Xfmea.AddXfmeaFailure Method|Xfmea.AddXfmeaFailure]]||{{:Repository.Xfmea.AddXfmeaFailure Method}}
|-
|[[Repository.Xfmea.AddXfmeaFunction Method|Xfmea.AddXfmeaFunction]]|| {{:Repository.Xfmea.AddXfmeaFunction Method}}
|-
|[[Repository.Xfmea.GetAllItemsInSystemHierarchy Method|Xfmea.GetAllItemsInSystemHierarchy]]||{{:Repository.Xfmea.GetAllItemsInSystemHierarchy Method}}
|-
|[[Repository.Xfmea.GetAllItemsInSystemHierarchyDictionary Method|Xfmea.GetAllItemsInSystemHierarchyDictionary]]|| {{:Repository.Xfmea.GetAllItemsInSystemHierarchyDictionary Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaCauses Method|Xfmea.GetAllXfmeaCauses]]||{{:Repository.Xfmea.GetAllXfmeaCauses Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaCausesDictionary Method|Xfmea.GetAllXfmeaCausesDictionary]]||{{:Repository.Xfmea.GetAllXfmeaCausesDictionary Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaEffects Method|Xfmea.GetAllXfmeaEffects]]||{{:Repository.Xfmea.GetAllXfmeaEffects Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaEffectsDictionary Method|Xfmea.GetAllXfmeaEffectsDictionary]]||{{:Repository.Xfmea.GetAllXfmeaEffectsDictionary Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaFailures Method|Xfmea.GetAllXfmeaFailures]]||{{:Repository.Xfmea.GetAllXfmeaFailures Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaFailuresDictionary Method|Xfmea.GetAllXfmeaFailuresDictionary]]||{{:Repository.Xfmea.GetAllXfmeaFailuresDictionary Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaFunctions Method|Xfmea.GetAllXfmeaFunctions]]|| {{:Repository.Xfmea.GetAllXfmeaFunctions Method}}
|-
|[[Repository.Xfmea.GetAllXfmeaFunctionsDictionary Method|Xfmea.GetAllXfmeaFunctionsDictionary]]||{{:Repository.Xfmea.GetAllXfmeaFunctionsDictionary Method}}
|-
|[[Repository.Xfmea.GetItemInSystemHierarchy_Method|Xfmea.GetItemInSystemHierarchy]]||{{:Repository.Xfmea.GetItemInSystemHierarchy_Method}}
|-
|[[Repository.Xfmea.GetXfmeaCause Method|Xfmea.GetXfmeaCause]]||{{:Repository.Xfmea.GetXfmeaCause Method}}
|-
|[[Repository.Xfmea.GetXfmeaEffect Method|Xfmea.GetXfmeaEffect]]||{{:Repository.Xfmea.GetXfmeaEffect Method}}
|-
|[[Repository.Xfmea.GetXfmeaFailure Method|Xfmea.GetXfmeaFailure]]||{{:Repository.Xfmea.GetXfmeaFailure Method}}
|-
|[[Repository.Xfmea.GetXfmeaFunction Method|Xfmea.GetXfmeaFunction]]|| {{:Repository.Xfmea.GetXfmeaFunction Method}}
|-
|[[Repository.Xfmea.UpdateItemInSystemHierarchy Method|Xfmea.UpdateItemInSystemHierarchy]]||{{:Repository.Xfmea.UpdateItemInSystemHierarchy Method}}
|-
|[[Repository.Xfmea.UpdateXfmeaCause Method|Xfmea.UpdateXfmeaCause]]||{{:Repository.Xfmea.UpdateXfmeaCause Method}}
|-
|[[Repository.Xfmea.UpdateXfmeaEffect Method|Xfmea.UpdateXfmeaEffect]]||{{:Repository.Xfmea.UpdateXfmeaEffect Method}}
|-
|[[Repository.Xfmea.UpdateXfmeaFailure Method|Xfmea.UpdateXfmeaFailure]]||{{:Repository.Xfmea.UpdateXfmeaFailure Method}}
|-
|[[Repository.Xfmea.UpdateXfmeaFunction Method|Xfmea.UpdateXfmeaFunction]]|| {{:Repository.Xfmea.UpdateXfmeaFunction Method}}
|-
|[[Repository.Xfmea.AssignActionToXfmeaCause Method|Xfmea.AssignActionToXfmeaCause]]|| {{:Repository.Xfmea.AssignActionToXfmeaCause Method}}
|-
|[[Repository.Xfmea.AssignControlToXfmeaCause Method|Xfmea.AssignControlToXfmeaCause]]|| {{:Repository.Xfmea.AssignControlToXfmeaCause Method}}
|-
|[[Repository.Xfmea.GetXfmeaCauseActions Method|Xfmea.GetXfmeaCauseActions]]|| {{:Repository.Xfmea.GetXfmeaCauseActions Method}}
|-
|[[Repository.Xfmea.GetXfmeaCauseActionsDictionary Method|Xfmea.GetXfmeaCauseActionsDictionary]]|| {{:Repository.Xfmea.GetXfmeaCauseActionsDictionary Method}}
|-
|[[Repository.Xfmea.GetXfmeaCauseControls Method|Xfmea.GetXfmeaCauseControls]]|| {{:Repository.Xfmea.GetXfmeaCauseControls Method}}
|-
|[[Repository.Xfmea.GetXfmeaCauseControlsDictionary Method|Xfmea.GetXfmeaCauseControlsDictionary]]|| {{:Repository.Xfmea.GetXfmeaCauseControlsDictionary Method}}
|}

===<span style="color:#585858">XFRACAS</span>===
{| {{APITable}}
|-
| style="width: 240px;"|
|-
|[[Repository.XFRACAS.AddSystemMetric1|XFRACAS.AddSystemMetric1]] ||{{:Repository.XFRACAS.AddSystemMetric1}}
|-
|[[Repository.XFRACAS.AddSystemMetric2|XFRACAS.AddSystemMetric2]]||{{:Repository.XFRACAS.AddSystemMetric2}}
|-
|[[Repository.XFRACAS.AddSystemMetric3|XFRACAS.AddSystemMetric3]]||{{:Repository.XFRACAS.AddSystemMetric3}}
|-
|[[Repository.XFRACAS.GetAllXFRACASEntities|XFRACAS.GetAllXFRACASEntities]]|| {{:Repository.XFRACAS.GetAllXFRACASEntities}}
|-
|[[Repository.XFRACAS.ImportXFRACASXML|XFRACAS.ImportXFRACASXML]]|| {{:Repository.XFRACAS.ImportXFRACASXML}}
|-
|[[Repository.XFRACAS.ImportXFRACASXMLFile|XFRACAS.ImportXFRACASXMLFile]]|| {{:Repository.XFRACAS.ImportXFRACASXMLFile}}
|-
|[[Repository.XFRACAS.ImportXFRACASXMLString|XFRACAS.ImportXFRACASXMLString]] ||{{:Repository.XFRACAS.ImportXFRACASXMLString}}
|-
|[[Repository.XFRACAS.ProcessXfracasImports|XFRACAS.ProcessXfracasImports]]|| {{:Repository.XFRACAS.ProcessXfracasImports}}
|-
|[[Repository.XFRACAS.SerializeXMLObjectToByteArray|XFRACAS.SerializeXMLObjectToByteArray]]||{{:Repository.XFRACAS.SerializeXMLObjectToByteArray}}
|-
|[[Repository.XFRACAS.WriteExceptionToDiagnosticsLog|XFRACAS.WriteExceptionToDiagnosticsLog]]||{{:Repository.XFRACAS.WriteExceptionToDiagnosticsLog}}
|-
|[[Repository.XFRACAS.WriteMessageToDiagnosticsLog|XFRACAS.WriteMessageToDiagnosticsLog]]||{{:Repository.XFRACAS.WriteMessageToDiagnosticsLog}}
|}

==Properties==
{| {{APITable}}
|-
| style="width: 250px;"|EnforceRENOCompliance||Indicates whether spaces and special characters are allowed in the names of models created via the Synthesis API. '''Boolean'''. Default value = True.
|-
|Use Events||Indicates whether to enable user-defined event procedures for the <code>Repository</code> object. '''Boolean'''. Default value = False.
|-
|XFRACAS.XFRACASCommandTimeout||Gets or sets the wait time in seconds before terminating the attempt to execute an XFRACAS command. '''Integer'''.
|}

==Events==
{| {{APITable}}
|-
| style="width: 250px;"|[[Repository.Message|Message]]||{{:Repository.Message}}
|}

Repository.Action.GetFMEAActionLocatorLinkPath

2019-03-13T23:51:29Z

David J. Groebel:

{{Template:API}}{{Template:APIBreadcrumb|.[[Repository Class|Repository]]}}

<onlyinclude>Creates a locator link file for the action and returns the path to the file.</onlyinclude>

== Syntax ==
'''.Action.GetFMEAActionLocatorLinkPath'''(''actionID'', ''[causeID]'') {{APIPrefix|As}} String

=== Parameters ===
''actionID''
:Required. The ID of the action.

''causeID''
:Optional. The ID of the cause that the action belongs to. Set to 0 to use the first cause where the action is used.

== Example ==

'''VBA'''

{{APIComment|'Declare a new Repository object and connect to a Synthesis repository.}}
{{APIPrefix|Dim}} MyRepository {{APIPrefix|As New}} Repository
MyRepository.ConnectToAccessRepository({{APIString|"C:\RSRepository1.rsr10"}})

{{APIComment|'Get action #1 from project #1.}}
{{APIPrefix|Dim}} MyAction {{APIPrefix|As}} cAction
MyRepository.Project.SetCurrentProject(1)
{{APIPrefix|Set}} MyAction = MyRepository.Action.GetAction(1)
{{APIComment|'Get string which contains the path to the action}}
{{APIPrefix|Dim}} sPath {{APIPrefix|As}} String
sPath = MyAction.GetFMEAActionLocatorLinkPath

Repository.Action.GetFMEAActionLocatorLinkPath

2019-03-13T23:44:55Z

David J. Groebel: Created page with '{{Template:API}}{{Template:APIBreadcrumb|.Repository}} <onlyinclude>Creates a locator link file for the action and returns the path to the file.</onlyinclu…'

ReliaSoft API Reference

2019-03-13T23:36:33Z

David J. Groebel:

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [http://xfracas.reliasoft.com/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." As of Version 2019, the library names are now version dependent. For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file. Prior to Version 2019, the files to use were SynthesisAPI.tlb (VBA) and SynthesisAPI.dll (.NET).

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the Support Portal at https://support.hbmprenscia.com.

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls. (See [http://www.reliasoft.com/support/rs20024.htm ReliaSoft KB article RS20024].)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

ReliaSoft API Reference

2019-03-13T23:27:45Z

David J. Groebel:

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [http://xfracas.reliasoft.com/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the Support Portal at https://support.hbmprenscia.com.

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls. (See [http://www.reliasoft.com/support/rs20024.htm ReliaSoft KB article RS20024].)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

ReliaSoft API Reference

2019-03-13T23:27:32Z

David J. Groebel:

{{Template:API}}

<div style="border:1px solid #D0CDE8; background:#EEEDF7; border-radius:10px; width:auto; margin:0 0 1em 1em; padding:1em; float:right;">
*'''[[API Changelog|Changelog]]'''
*'''[[API Reference Documentation|API Documentation]]
*'''[[API Tutorials|Tutorials]]
</div>

The ReliaSoft ''Application Programming Interface'' (API) enables you to programmatically read and write data to ReliaSoft repositories, as well as analyze and plot data sets from external sources. It is provided for Visual Basic for Applications (VBA) and .NET applications, allowing you to create automated solutions using popular Microsoft Office applications, such as Excel and PowerPoint, or create custom applications for your organization.

Implementing the ReliaSoft API allows you to connect data in repositories with the systems and tools used within your organization. It provides the functionality to:

*'''Transfer and synchronize data via XML'''
:Use XML files to manage structured data (such as system hierarchies/BOMs, incidents and work orders) between ReliaSoft’s [http://xfracas.reliasoft.com/ XFRACAS] and a variety of different PLMs, ERPs, CMMS and other external systems. You can also use XML files to create reliability block diagrams (RBDs) in [http://www.reliasoft.com/products/reliability-analysis/blocksim BlockSim].
*'''Read/write specific data elements'''
:Read or write data to resources (models, actions, URDs, etc.), system hierarchy items and FMEA records (causes, effects, failures, etc.). Initiate batch data processing and create custom solutions for importing/exporting data from ReliaSoft repositories, as well as load data into the Synthesis Data Warehouse (SDW).
*'''Obtain calculated results'''
:Read data from published models and obtain calculated results such as reliability, probability of failure, BX% life, failure rate and mean time.
*'''Analyze data'''
:Use [http://www.reliasoft.com/products/reliability-analysis/weibull Weibull++'s] or [http://www.reliasoft.com/products/reliability-analysis/alta ALTA’s] analysis and plotting engines to analyze data from third-party sources, and incorporate the functionality into your own custom applications. (Requires a ReliaSoft API license.)

==Prerequisites==
*'''Getting the latest version'''
:The ReliaSoft API consists of a library file that contains the classes, methods and events that provide access to ReliaSoft applications. The file is located in the folder where the ReliaSoft desktop applications are installed. By default, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

:To obtain the latest version of the library file and the ReliaSoft applications, choose '''File > Help > Check for Updates''' or download the latest version from the Support Portal at https://support.hbmprenscia.com.

*'''Build environment'''
:For Visual Studio projects using Version 10 or 11, at minimum you will need Visual Studio 2010 and the .NET Framework 4.0 runtime. Version 2018 and later require Visual Studio 2015 and the .NET Framework 4.6.1 developer pack and runtime.

*'''32- vs. 64-bit'''
:For VBA, the bit version of the ReliaSoft applications that you've installed must match your installed version of Microsoft Office. If they do not match, you may see an error related to ActiveX controls. (See [http://www.reliasoft.com/support/rs20024.htm ReliaSoft KB article RS20024].)

:For Visual Studio projects targeting the .NET Framework 4.5 (or later) and compiled to run an any platform (Any CPU), turn off the '''Prefer 32-bit''' property of the build configuration if you want instances of your application to run as a 64-bit process; otherwise, the application will run as a 32-bit process on both 32- and 64-bit versions of Windows. Note that when using [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing], it is necessary to ensure your application bitness matches the bitness of the ReliaSoft desktop applications installed wherever your application is run due to dependencies on platform-specific libraries.

*'''Running API applications on a server
:If you plan to run the API on a Windows server, you must use [https://www.reliasoft.com/locally-hosted-licensing locally hosted licensing] and you’ll need to install the ReliaSoft API Ante Service to scale the implementation (the service is not required when running the API on a Windows desktop environment). For instructions on how to install and configure the service, see https://www.reliasoft.com/reliasoft-api-ante-service.

*'''Access to calculations functionality
:Access to Weibull++'s and ALTA’s analysis and plotting engines require a ReliaSoft API license. To obtain a license, please see [http://www.reliasoft.com/contact.htm contact ReliaSoft].

==Getting Started==

====Referencing the ReliaSoft API Library File====

<onlyinclude>To use the ReliaSoft API in your code, you must reference the ReliaSoft API library in your VBA or .NET projects. The file is located in the folder where the ReliaSoft desktop applications are installed. By default for Version 2019, this folder is at "C:\Program Files\ReliaSoft\ReliaSoft 2019." For VBA, you will use the '''ReliaSoftAPI19.tlb''' file; for .NET applications, you will use the '''ReliaSoftAPI19.dll''' file.

'''To reference the library in VBA''':
:#Enter the VBA environment by clicking the '''Visual Basic''' command on the Developer tab (If the Developer tab is not visible, see [https://msdn.microsoft.com/en-us/library/bb608625.aspx this Microsoft article]).
:#In the VBA environment, choose '''Tools > References'''.
:#Click '''Browse''' and find the ReliaSoftAPI19.tlb file on your computer. Click '''OK'''.

'''To reference the library in Visual Studio:'''
:#In the Solution Explorer, right-click the '''References''' node and choose '''Add References'''.
:#In the Reference Manager window, click the '''Browse''' tab and find the ReliaSoftAPI19.dll file on your computer. Click '''OK'''.
:#Copy the following files from the ReliaSoft installation folder to your target folder (e.g., bin/Debug or bin/Release Folder).
:::*licncr.dll
:::*licncr.dll.nsign
:::*licshr.dll
:::*licshr.dll.nsign
:::*msvcp110.dll
:::*msvcr110.dll
:::*RSDB.dll
:::*RSLM8nCodeDotNetWrapper.dll
:::*utlibr.dll
</onlyinclude>
====Examples====
Sample applications that you can test and tweak yourself are included with the ReliaSoft installation. The files are stored on your computer at C:\Users\Public\Public Documents\ReliaSoft\Examples19\API.

The sample applications are available for Excel VBA and VB.NET projects. (To run the Excel examples, macros must be enabled. See [http://office.microsoft.com/en-us/excel-help/enable-or-disable-macros-in-office-documents-HA010031071.aspx this Microsoft article].)

====Tutorials====
[[API Tutorials|Tutorials]] are available to help you learn the core objects of the ReliaSoft API and start coding right away. The tutorials include code samples for both VBA and VB.NET.

==Object Library ==
Below is a summary of the core objects in the ReliaSoft API library. For an alphabetical listing of all objects in the latest version, see [[API Reference Documentation]].

*The <code>'''[[Repository Class|Repository]]'''</code> object represents the ReliaSoft repository. All other objects use the functions in this class to read or write data to the repository. This class also contains the functions for importing/exporting XML files.

*The following objects represent the ReliaSoft resources. Instances of each class can be used to store data for an existing or new resource.
**<code>'''[[CAction Class|cAction]]'''</code>
**<code>'''[[CCorrectiveTask Class|cCorrectiveTask]]'''</code>
**<code>'''[[CScheduledTask Class|cScheduledTask]]'''</code>
**<code>'''[[CCrew Class|cCrew]]'''</code>
**<code>'''[[CModel Class|cModel]]'''</code>
**<code>'''[[CPool Class|cPool]]'''</code>
**<code>'''[[CProfile Class|cProfile]]'''</code>
**<code>'''[[CURD Class|cURD]]'''</code>
**<code>'''[[CVariable Class|cVariable]]'''</code>
**<code>'''[[CXfmeaControl Class|cXfmeaControl]]'''</code>

*The following objects build data sets for the Synthesis Data Warehouse (SDW).
**<code>'''[[RawData Class|RawData]]'''</code> represents a single data point.
**<code>'''[[RawDataSet Class|RawDataSet]]'''</code> serves as the data container for <code>RawData</code> objects.

*The <code>'''[[XfmeaItem Class|XfmeaItem]]'''</code> object represents a system hierarchy item. Instances of this class can be used to store data for a system or assembly, as well as build a multi-level system configuration.

*The following objects represent the FMEA records. Instances of each class can be used to store data for an existing or new FMEA analysis.
**<code>'''[[XfmeaFunction Class|XfmeaFunction]]'''</code>
**<code>'''[[XfmeaCause Class|XfmeaCause]]'''</code>
**<code>'''[[XfmeaEffect Class|XfmeaEffect]]'''</code>
**<code>'''[[XfmeaFailure Class|XfmeaFailure]]'''</code>

*The <code>'''[[WeibullDataSet Class|WeibullDataSet]]'''</code> object represents a Weibull++ data sheet for life data analysis. Instances of this class are used to define a data set and fit a statistical distribution to the data.

*The <code>'''[[ALTADataSet Class|ALTADataSet]]'''</code> object represents an ALTA data sheet for accelerated life testing data analysis. Instances of this class are used to define a data set, and fit a distribution and life-stress relationship to the data.

*The <code>'''[[WAPlots Class|WAPlots]]'''</code> object represents a plot based on a <code>cModel</code>, <code>WeibullDataSet</code> or <code>ALTADataSet</code> object. Instances of this class are used to display a plot of the analysis results.

File:APIWiki.png

2019-03-13T23:25:31Z

David J. Groebel: uploaded a new version of "File:APIWiki.png"

For API banner

File:APIWiki.png

2019-03-13T23:25:10Z

David J. Groebel: uploaded a new version of "File:APIWiki.png": Reverted to version as of 21:03, 24 July 2015

For API banner