Orthogonal redundancy…

There is an old saying “measure twice, cut once”‘; wise words of caution before you take an irrevocable action.  However, if you have a faulty measuring tape then measuring twice will just produce the same error twice.

Orthogonal redundancy is an approach to safety-critical software where the same dependent variable is calculated using 2 or more methods.  In the woodworking example, this could be done by using a standard tape measure the first time and laser guide the second.

Achieving software orthogonality

There are three basic approaches to software orthogonality, listed in terms of “strength”

1. Unique algorithms:
2. Common algorithm: unique parameterization
3. Common algorithm: unique inputs

Unique algorithm:

Using a unique algorithm has the advantage that it removes the chance of a common point of failure; e.g. if one algorithm can overflow, the second doesn’t.  (Mind you, you should catch the overflow problem).  The downside to this approach then is that you need to create validation test cases for each unique algorithm

Common algorithm: unique parameterization

In this case, the same algorithm is used however the parameterization is different for each instance.  This is commonly seen for hardware sensors, such as unique scaling on a set of analog input sensors.  For example, as in the image shown a simple linear equation (y = m*x + b) can be used to determine the throttle angle, however, the coefficient or “m” and “b” are different.

Common algorithm: unique inputs

This final approach is used when the input source data is suspect or can fail.  The solution, in this case, is to create multiple input sources for the same data.  The throttle body example above, redundant sensors, is an example of this; a more robust example would be to have two different types of sensors.

When and how?

Using orthogonal algorithms requires additional execution steps and memory; both for the algorithm and for the validation of results against each other.  Because of this, the use of the algorithms should be limited to safety critical calculations.

The standard way to use multiple results is with triple redundancy.  The results are compared with each other, as long as they are in agreement (within tolerance) of each other then the result is passed on.  If two of the three agree that value is used. If there is no agreement then the results are flagged as an error.