Common use of Level of Agreement Required Clause in Contracts

Level of Agreement Required. The level of agreement required among replicas (or conversely, the maximum amount of disagree- ment that can be allowed) depends on system requirements, both external and derived. For flight control systems, typical external requirements include limiting actuator force fight and minimizing divergence among different information outputs (e.g. differences between pilot and copilot displays). The limits of force fight can be required to minimize wear on actuator components and/or to minimize wasted energy. Note that a force fight can occur within an actuator or well “downstream” of the actuator, e.g. aero surfaces can cause a force fight in the air stream. Force fights caused by momentary disagreements or small amplitude disagreements seldom cause any problem. It is usually the accumulation of stress or wasted energy that requirements are put in place to avoid. And, this is why fault detection mechanisms for force fights typically include a time-amplitude integrator that is compared against some limit. There are applications other then flight control systems that can have a much more stringent level of agreement required. For example, spacecraft systems include pyrotechnic initiators that have stringent requirements on timing between replicant signals and “escapes” cannot be allowed because an erroneous command to fire cannot be undone. In the area of automotive X-by-wire systems, requirements for reaction times may be much more stringent than aircraft flight control. Typically, derived requirements are created to ensure that replicant outputs are close enough (in time and amplitude) that they do not exceed the capability of voters, compares, and selectors that are used for masking; or to prevent output “bumps” when switch-overs to backup replicants occur in active/standby systems. The latter could also be seen as an external requirement because the concern about “bumps” is effect on the system’s external environment. There are complexity trade-offs in these derived requirements. Typically, the better the system does at minimizing disagreement, the simpler the mechanisms need to be for comparison, selection, or voting. Simplicity affects not only size, weight, and power of an implemented system, but it also affects the ability to reason about the correctness of its design. A common trade-off to be addressed in the design of fault-tolerant system is the degree of rigidity in the fault tolerance mechanism. As a design becomes more rigid in the enforcement of replica determinism, the less uncertainty “dirt” is passed downstream that may require complicated fault tolerance mechanisms to handle. On the other hand, enforcement of replica determinism could become too rigid – that is it becomes “brittle” where instead of bending it breaks. A typical brittle system is one that does an all-or-nothing exchange. The benefit of this rigidity is that all recipients of the exchange are guaranteed that if they receive any input (without being flagged as bad) all other recipients get exactly the same input. The cost of this rigidity is that even a minor transient can cause the loss of data that could have been useful. Possibly even more brittle are systems with a policy of “one strike and you’re out” where a simple transient upset can cause a member of the replica set to be permanently voted out of membership.