Multiple Fault: Static Health Monitoring (Operational refinement not postponed)
What is the purpose of this algorithm?
The fault isolation algorithm Multiple Fault: Static Health Monitoring (Operational refinement not postponed) is a compromise between the two algorithms Multiple Fault: Half-Split Failure Probs. (refinement postponed) and Multiple Fault: Half-Split Failure Probs. (refine where appropriate). Rather than performing the most efficient tests first (that is, isolation tests that are guaranteed to reduce the suspect set), this algorithm produces test sequences that will use Operational Tests to perform refinement prior to performing isolation tests. The reason why this is useful is that Operational Tests are often used to represent tests that are simple, quick and inexpensive to perform (they may perhaps be automatic) and that can provide instant feedback about the health of the system. On the down side, because of the inefficiency of refinement tests, test sequences generated using this algorithm can be substantially larger than those generated using the other predefined isolation algorithms (remember, for refinement tests, only one of the two possible test outcomes is diagnostically meaningful). The highest-priority weightings for this algorithm are those that favor tests that come close to half-splitting the suspect set when they pass. Lower-priority weightings attempt to choose the refinement tests that are least likely to fail due to malfunctions not in the suspect set.
How was this algorithm implemented?
The full set of test selection criteria for this algorithm are as follows:
1. Test Candidate Grouping 1 of 5: Operational Refinement
a) Candidate Test Types (1)
b) Weightings: uses algorithm defaults
c) Cutoffs: uses algorithm defaults
2. Test Candidate Grouping 2 of 5: Test Set Isolation
a) Candidate Test Types (1)
b) Weightings: uses algorithm defaults
c) Cutoffs: uses algorithm defaults
3. Test Candidate Grouping 3 of 5: Internal Isolation
a) Candidate Test Types (2)
2) All Input Flags
b) Weightings: uses algorithm defaults
c) Cutoffs: uses algorithm defaults
4. Test Candidate Grouping 4 of 5: Test Set Refinement
a) Candidate Test Types (1)
b) Weightings: uses algorithm defaults
c) Cutoffs: uses algorithm defaults
5. Test Candidate Grouping 5 of 5: Other Refinement
a) Candidate Test Types (2)
b) Weightings: uses algorithm defaults
c) Cutoffs: uses algorithm defaults
1. Test Weighting 1 of 6: Sum Failure Probability
a) Priority: 80
b) Entity: Failure Probability
c) Type: Sum
d) Domain: Suspect Functions Proven
e) Best Equals: Half-Split
2. Test Weighting 2 of 6: Sum Failure Probability
a) Priority: 60
b) Entity: Failure Probability
c) Type: Sum
d) Domain: Suspect Failure Modes Proven
e) Best Equals: Half-Split
3. Test Weighting 3 of 6: Count Number of Items
a) Priority: 40
b) Entity: Number of Items
c) Type: Count
d) Domain: Suspect Functions Proven
e) Best Equals: Half-Split
4. Test Weighting 4 of 6: Sum Failure Probability
a) Priority: 30
b) Entity: Failure Probability
c) Type: Sum
d) Domain: Suspect Failure Modes Detected
e) Best Equals: Lowest
5. Test Weighting 5 of 6: Sum Failure Probability
a) Priority: 20
b) Entity: Failure Probability
c) Type: Sum
d) Domain: Suspect Functions Detected
e) Best Equals: Lowest
6. Test Weighting 6 of 6: Count Number of Items
a) Priority: 15
b) Entity: Number of Items
c) Type: Count
d) Domain: Suspect Functions Detected
e) Best Equals: Lowest
C. Default Test Cutoffs (2)
1. Cutoff 1 of 2: Count Number of Tests
a) Entity: Number of Tests
b) Type: Count
c) Domain: Isolation Path
d) Modifier: Test Usage
e) Target: Refinement
f) Condition: >= 3
g) Action: Ignore in Sequence
2. Cutoff 2 of 2: Count Number of Items
a) Entity: Number of Items
b) Type: Count
c) Domain: Suspected Items
d) Modifier: <none>
e) Target: <none>
f) Condition: <= 1
g) Action: Terminate Sequence
