FormalMajorityVoter (input_vector, e, r*) // This Decision Mechanism determines the correct or // adjudicated result (r*), given the input vector // (input_vector) of variant results and the maximum // allowed distance (e), via the Formal Majority // adjudication algorithm. Set Status = NIL, r* = NIL, FS = NIL Receive Variant Results, input_vector, e Was a Result Received from each Variant? No: Set Status = NO CORRECT RESULT (Exception), Go To Out Adjudicating the Results 301 Variant inputs Randomly select a variant output, x Set status = NO CORRECT RESULT (exception) Set r ∗ = = randomly selected member of FS Set status SUCCESS Return r ∗, status Yes Set status NIL= Receive variant results, ,R and tolerance, A No Is the feasibility set empty ? Construct the feasibility set FS { , , 1, , }= ∈  − ≤ = …x r R x r i n i i A Formal majority voter Yes No Figu re 7.14 Fo rmal majority voter operation. Yes: Continue Randomly Select a Variant Output, x . Construct the Feasibility Set (FS), where FS = {x, y in input_vector | |x - y| ≤ z} Is FS empty? No: Set r* = Randomly Selected Value in FS Se t Status = SUCCESS Yes: Set Status = NO CORRECT RESULT (Exception) Out Return r*, Status // FormalMajorityVoter 7.1.5.2 Example An example of the formal majority voter operation is shown in Figure 7.15. Suppose we have a fault-tolerant component with three variants, n = 3. If the results of the variants are r 1 = 17.632; r 2 = 17.674; r 3 = 18.795; then the input vector to the voter is (17.632, 17.674, 18.795). 302 Software Fault Tolerance Techniques and Implementation (17.632, 17.674, 18.795) Input vector A 0.05= Comparison: |17.632 − 17.674| 0.042= < A ✓ |17.632 − 18.795| 1.121= > A ✗ FS {17.632, 17.674}= Randomly select from FS 17.632 as the result, H ∗ Output H ∗ (17.632) and status 17.632 17.674 17.632, SUCCESS 18.795 Figu re 7.15 Ex ample of formal majority voter. Suppose the variant result selected as the focal point, x,isr 2 . The other variant results are checked to see if they are within the tolerance, A = 0.05, of x. x − r 1  = 17.674 − 17.632 = 0.042 < 0.05 ✓ x − r 3  = 17.674 − 18.795 = 1.121 > 0.05 ✗ Since r 1 matches x (r 2 ) within A, the FS = {r 1 , r 2 } = {17.632, 17.674}. One of these values, say 17.632, is randomly selected from FS as the adjudicated result. 7.1.5.3 Discussion The formal majority voter expects a result from each variant and when all variant results are not present, the voter can fail. A way to avoid this type of failure is to make the formal majority dynamic (see Section 7.1.6). For data diverse software fault tolerance techniques, this type of DM is quite useful when the DRA is approximate (causing the copies to produce similar, but not exact, acceptable results). The formal majority voter is sometimes called a tolerance voter because of the tolerance on the values of the results. The value of this tolerance is important. If it is too large, then it masks failure events. If it is too small, it will lead to too many conflict events (e.g., false alarms that can lead to increased testing costs [35] and degraded operation or critical system failure). The formal majority voter uses a two-step adjudication function [36]. Other voters using a two-step adjudication function include: formalized plu- rality voter [28], modified interactive convergence algorithm (MCNV) [37], sliding majority decision algorithm (SLIDE) [37], filter strategy [38], the adjudication function used in the DEDIX system [39], and the adjudication function used in the CRB [24]. 7.1.6 Dynamic Majority and Consensus Voters The dynamic majority and consensus voters [4042] operate in a way similar to their nondynamic counterparts (i.e., the majority and consensus voters, respectively), with the exception that these dynamic voters can handle a vary- ing number of inputs. The dynamic voters can process from zero to n inputs. The reasons a voter may receive less than n inputs include catastrophic failure of some or all of the variants, some or all variants not providing their results Adjudicating the Results 303 in a timely manner, or some or all variant results failing an AT prior to being sent to the voter. Suppose we have a dynamic voter with n = 5. If two of the variants fail to provide results to the voter, then the voter will vote upon the existing three variant results. If there are only two results, a comparison takes place. When comparing, if the results do not match, then the results fail. Otherwise, the matching value will be output as the correct result. If only one variant result makes it to the voter, and if that result has passed an AT prior to reaching the voter, then the dynamic voter assumes the single result is correct. If, however, no AT is involved, the dynamic voter designer must decide whether or not to pass the single result on as a correct result. This decision can be based on the criticality of the function implemented by the variant and the confidence in the reliability of the variant. 7.1.6.1 Operation The dynamic majority voter selects as the correct output, r∗, the variant output occurring most frequently, if such a value exists, from the available variant results. In contrast to the exact majority voter, the dynamic majority voter does not require all variants to provide a result in order to function. Recall m, the agreement number from the exact majority voter discussion (the number of versions required to match for system success), and n, the total number of variants. For the dynamic majority voter, m is equal to (k + 1)/2, where  is the ceiling function and k ≤ n. k is the number of variant results that made it to the voter. If three or more variant results make it to the dynamic voter, then the voter operates as a majority voter in evaluat- ing those results. If two results make it to the voter, then they must match to be considered correct. For our discussions and the examples in this section, if a single variant result makes it to the voter, we will assume it is correct and output it as the result of the dynamic majority voter. The dynamic consensus voter operates as the consensus voter (described in Section 7.1.4) with the variant results available to the voter at the time of each vote. Table 7.9 provides brief examples to illustrate the dynamic majority voter (also see Section 7.1.6.2). r i = ∅ indicates that the i th variants result did not make it to the voter. Table 7.10 presents a list of syndromes and provides the results of using the dynamic majority voter, given several sets of example inputs to the voter. The examples are provided for n = 3. r i is the result of the i th variant. Table entries A, B, and C are numeric values, although they could be charac- ter strings or other results of execution of the variants. The symbol ∅ indi- cates that no result was produced by the corresponding variant. The symbol 304 Software Fault Tolerance Techniques and Implementation A i is a very small value relative to the value of A, B, or C. An exception is raised if a correct result cannot be determined by the adjudication function. The dynamic majority voter functionality is illustrated in Figure 7.16. The variable Status indicates the state of the voter, for example, as follows: Status = NIL The voter has not completed examining the variant results. Status is initialized to this value. If the Status returned from the voter is NIL, then an error occurred during adjudication. Ignore the returned r∗. Status = NO CORRECT RESULT The voter was not able to find a correct result given the available input variant results. Ignore the returned r∗. Status = SUCCESS The voter completed processing and found an (assumed) correct result, r∗. The following pseudocode illustrates the dynamic majority voter. Recall that r∗ is the adjudicated or correct result. Values for Status are used as defined above. Adjudicating the Results !# Table 7.9 Examples of Dynamic Majority Voter Results Variant Results, 4 Dynamic Majority Voter Result, H* (5.0, 5.0, 5 .0, 4.0, 5.0) r ∗ = 5.0 All variant result s to the voter (i.e., k = n = 5). Majority exists. (4.95, 5.0, 6.0, 5.0, 6.0 ) r ∗ = ∅ (exception) All var iant results to the voter (i.e., k = n = 5). Majority does not exist. (3.0, 5.0, 5 .0, 5.0, ∅) r ∗ = 5.0 3 ≤ k ≤ n. Majority exists. (1.0, 2.0, 3 .0, 4.0, ∅) r ∗ = ∅ (exception) 3 ≤ k ≤ n. Majority does not exist. (5.0, ∅, 5.0, ∅, 4.5) r∗ = 5.0 3 ≤ k ≤ n. Majority exist s. (5.0, ∅, 4.1, ∅, 4.7) r∗ = ∅ (exception) 3 ≤ k ≤ n. Majority does not exist. (5.0, ∅, ∅, 5.0, ∅) r ∗ = 5.0 k = 2. Compare results - match. (5.0, ∅, ∅, 4.7 , ∅) r∗ = ∅ (exception) k = 2. Compare results - no match. (∅, ∅, ∅, 4.7, ∅) r ∗ = 4.7 k = 1. Assume result is correct. (∅, ∅, ∅, ∅, ∅) r∗ = ∅ (exception) k = 0. No variant results to adjudicate. DynamicMajorityVoter (input_vector, r*) // This Decision Mechanism determines the correct or // adjudicated result (r*), given the input vector of // variant results (input_vector), via the Dynamic // Majority Voter adjudication function. Set Status = NIL, r* = NIL, k = 0 Receive Variant Results (input_vector) Set k = Number of Variant Results Received If k > 2 Is there a Majority Match? No: Set Status = NO CORRECT RESULT (Exception), Go To Out 306 Software Fault Tolerance Techniques and Implementation Table 7.10 Dynamic Majority Voter Syndromes, n = 3 Variant Results(H 1 , H 2 , H 3 ) Voter Result, H∗ Notes (A, A, A) A Majority vote. (A, A, B) A Majority vote. (A, B, A) A Majority vote. (B, A, A) A Majority vot e. (A, A, ∅) A Comparison. (A, ∅, A) A Comparison. (∅, A, A) A Comparison. (A, B, ∅) Exception Com parison. (A, ∅, B) Exception Com parison. (∅, A, B) Exception Com parison. (A, ∅, ∅) A Assumed correct. (∅, A, ∅) A Assumed correct. (∅, ∅, A) A Assumed correct. (∅, ∅, ∅) Exception  (A, B, C) Exception Mu ltiple correct or incorrect results. See discussion in Section 7.1.6.3. (A, A + A 1 , A − A 2 ) Excepti on With a tolerance voter (Section 7.1.5), r ∗ = A if tolerance > A 1 or A 2 . Also see discussion i n Section 7.1.6.3. Other combina tions with small varianc es between variant resul ts. Exception See tolerance voter (Section 7.1.5) and discussion in Section 7.1.6.3. TEAMFLY Team-Fly ® Adjudicating the Results 307 Variant inputs Return r∗, status Dynamic majority voter Set status NIL,= r k∗ = =NIL,0 Receive variant results, R Set number of variant results receivedk = Set status = NO CORRECT RESULT Set r∗ = Majority result Set status = SUCCESS No No Majority exists ? k > 2 ? k = 2 ? k = 1 ? No Yes Results match? Yes Yes Yes No Set r∗ = = matching result Set status SUCCESS No Yes Set r∗ = = only result Set status SUCCESS Set status NO CORRECT RESULT= Figu re 7.16 Dy namic majority voter operati on. Yes: Set r* = Majority Value Set Status = SUCCESS I f k = 2 Do the 2 values Match? Yes: Set r* = Matching Results Set Status = SUCCESS No: Set Status = NO CORRECT RESULT (Exception) Else If k = 1 Yes: Set r* = the Only Result Set Status = SUCCESS Else Set Status = NO CORRECT RESULT (Exception) End If Out Return r*, Status // DynamicMajorityVoter 7.1.6.2 Example An example of the consensus voter operation is shown in Figure 7.17. Sup- pose we have a fault-tolerant component with five variants, n = 5. Let the results of the variants be r 1 = 17.6; r 2 = ∅; r 3 = 18.7; r 4 = ∅; r 5 = 17.6; then the input vector to the voter is (17.6, ∅, 18.7, ∅, 17.6). 308 Software Fault Tolerance Techniques and Implementation (17.6, ,∅ 18.7, , 17.6) Input vector∅ k > 2 variant results available Look for majority (2-out-of-3) Majority match, r∗ = 17.6 Output r∗(17.6) and status 17.6 18.7 17.6, SUCCESS 17.6 ∅ ∅ Figu re 7.17 Ex ample of dynamic majority voter. The basic majority voter would fail, given this input set, because it expects a result from each variant. However, the dynamic majority voter is made to handle just this situation. As we see, only three of five variant results are sent to the voter. In this case, the dynamic majority voter takes the three available results and tries to find a majority match. In this example, there is a majority result, 17.6, and it is output as the adjudicated result, r∗. 7.1.6.3 Discussion FPA and MCR (see Chapter 3) can yield different, but approximately equal correct results. This can defeat any DM that attempts to find exact matches among variant results. If these are the types of correct results expected for an application, it is appropriate to use comparison tolerances in the voter (see Section 7.1.5). Comparison tolerances can be used with the dynamic voter to make a more powerful and robust voter for floating-point algorithms. 7.1.7 Summary of Voters Discussed The first part of this chapter presented the detailed operation of eight voters. Before continuing, we summarize some details of those voters in Table 7.11 (which was fashioned after a summary table found in [28]). The table states the resulting output of a fault-tolerant technique, given the type of variant results provided to the voter and the type of voter. The voter outputs are: • Correct: The voter outputs a correct result; • Possibly correct: The voter outputs a result that may be correct; • Possibly incorrect: The voter outputs a result that may be incorrect; • Incorrect: The voter outputs an incorrect result; • No output: The voter does not output a result; an exception is raised. The Variant Results Type column is not exhaustive, for example, it does not include the various cases of missing results that the dynamic voters handle. To use this table, consider the primary concerns surrounding the soft- wares application and some details about the output space and variant results. If safety is the primary concern, then select the voter that most avoids outputting an incorrect result. That is, the voter would rather raise an excep- tion and produce no selected output than present an incorrect output as correct. Of the voters examined in this chapter, the safest (based on this criterion) are the majority voters: exact majority voter, formal majority voter, Adjudicating the Results 309 310 Software Fault Tolerance Techniques and Implementation Table 7.11 Voter Results Given Variant Output Type Variant Results Type Voter Exact Majority Voter Median Voter Mean Voter Weighted Average Voter Consensus Voter Formal Majority Voter Dynamic Majority Voter Dynamic Consensus Voter All outputs identical and correct Correct Correct Correct Possibly correct Correct Correct Correct Correct Majority identical and correct Correct Correct Possibly correct Possibly correct Correct Correct Correct Correct Plurality identical and correct No output Possibly correct Possibly correct Possibly correct Correct No output No output Correct Distinct outputs, All correct No output Correct Possibly correct Possibly correct No output No output No output No output Distinct outputs, All incorrect No output Incorrect Possibly incorrect Possibly incorrect No output No output No output No output Plurality identical and wrong No output Possibly incorrect Possibly incorrect Possibly incorrect Incorrect No output No output Incorrect Majority identical and wrong Incorrect Incorrect Possibly incorrect Possibly incorrect Incorrect Incorrect Incorrect Incorrect All outputs identical and wrong Incorrect Incorrect Incorrect Incorrect Incorrect Incorrect Incorrect Incorrect [...]... Achieve Software Fault- Tolerance, ” in J Zalewski and W Ehrenberger (eds.), Hardware and Software for Real Time Process Control, Elsevier Science Publishers B.V., NorthHolland, 1989 324 Software Fault Tolerance Techniques and Implementation [51] Hecht, H., Fault- Tolerant Software, ” IEEE Transactions on Reliability, Vol R-28, No 3, 1979, pp 227–232 [52] Hecht, H., and M Hecht, Fault- Tolerant Software, ”... provided background, and design and programming guidelines and techniques for software fault tolerance The next three chapters described design diverse, data diverse, and other software fault tolerance techniques The techniques are built on the foundations presented in Chapters 1–3 and typically present a result or set of results to an adjudicator This chapter presented the voters and DMs that decide... Wiley and Sons, 1995 [22] Scott, R K., et al., “Investigating Version Dependence in Fault- Tolerant Software, ” AGARD 361, 1984, pp 21.1–21 .10 322 Software Fault Tolerance Techniques and Implementation [23] Scott, R K., et al., “Experimental Validation of Six Fault- Tolerant Software Reliability Models,” Proceedings of the 14th International Symposium on Fault- Tolerant Computing (FTCS-14), Orlando, FL,... Pradhan (ed.), FaultTolerant Computing: Theory and Techniques, Vol 2, Upper Saddle River, NJ: Prentice-Hall, 1986, pp 658–696 [53] Randell, B and J Xu, “The Evolution of the Recovery Block Technique,” in M R Lyu (ed.), Software Fault Tolerance, Chichester, U.K.: John Wiley and Sons, 1995, pp 1–21 [54] Randell, B., “System Structure for Software Fault- Tolerance, ” IEEE Transactions on Software Engineering,... 1990, pp 114–123 [10] Avizienis, A., and L Chen, “On the Implementation of N-Version Programming for Software Fault- Tolerance during Program Execution,” Proceedings COMPSAC ’77, New York, 1977, pp 149–155 [11] Grnarov, A., J Arlat, and A Avizienis, “On the Performance of Software Fault Tolerance Strategies,” Proceedings of the 10th International Symposium on Fault- Tolerant Computing (FTCS -10) , Kyoto, Japan,... (FTCS-14), Orlando, FL, 1984, pp 102 107 [24] Scott, R K., J W Gault, and D F McAllister, Fault- Tolerant Reliability Modeling,” IEEE Transactions on Software Engineering, Vol SE-13, No 5, 1987, pp 582–592 [25] Shimeal, T J., and N G Leveson, “An Empirical Comparison of Software FaultTolerance and Fault Elimination,” Proceedings of the 2nd Workshop on Software Testing, Verification, and Analysis, Banff, 1988,... requirements, accounting tests, reasonableness 320 Software Fault Tolerance Techniques and Implementation tests, and computer run-time tests—were described and examples given of each A means of determining the best type of AT to use in a given system would be a welcome addition to the software fault tolerance field Experience with similar systems, subject-matter expertise, and the hints provided in this chapter... Software on System Reliability and Availability,” in M Kersken and F Saglietti (eds.), Software Fault Tolerance: Achievement and Assessment Strategies, Berlin: Springer-Verlag, 1992, pp 199–212 [3] Avizienis, A., “The N-Version Approach to Fault- Tolerant Software, ” IEEE Transactions on Software Engineering, Vol SE-11, No 12, 1985, pp 1491–1501 [4] Lyu, M R (ed.), Handbook of Software Reliability Engineering,... Belli, F., and P Jedrzejowicz, “Comparative Analysis of Concurrent Fault- Tolerance Techniques for Real-Time Applications,” Proceedings of the Second International Symposium on Software Reliability Engineering, Austin, TX, 1991 [42] Gantenbein, R E., S Y Shin, and J R Cowles, “Evaluation of Combined Approaches to Distributed Software- Based Fault Tolerance, ” Pacific Rim International Symposium on Fault Tolerant... negotiating voting [44], confidence voter [45], maximum likelihood voter (MLV) [46, 64], fuzzy MLV and fuzzy consensus voting [47], and the selfconfiguring optimal programming (SCOP) adjudicator [48] Other voters and voter performance are discussed in [60–63, 65, and 67–69] 312 Software Fault Tolerance Techniques and Implementation Variant input General AT Receive variant result Apply AT Set pass/fail indicator . background, and design and programming guidelines and techniques for software fault tolerance. The next three chapters described design diverse, data diverse, and other soft- ware fault tolerance techniques. . exact majority voter, formal majority voter, Adjudicating the Results 309 310 Software Fault Tolerance Techniques and Implementation Table 7.11 Voter Results Given Variant Output Type Variant Results. on satisfaction of requirements might check that the horizontal, vertical, and 314 Software Fault Tolerance Techniques and Implementation two diagonals associated with each queen do not contain the