Which is the best approach to handle floating point exceptions in embedded code?

Question

I'm working on a safety critical, embedded program (in C) where I'd like to use IEEE 754 floating-point arithmetics (with NaN and Infs) for engineering calculations. Here I have two approach (afaik) to deal with floating point exceptions:

• go to a permanent fault state if any exception occurs. This one is might more robust from error detection point of view, but bad for fault-tolerance/availability.

• ignore exceptions, and check the final results whether they finite numbers (sucsessfull calculation) or NaN, inf (failed calculation). This solution is more fault tolerant, but it is more risky because outputs might accidentally be excluded from the check.

  1. Which would be a better solution in a safety critical system?
  2. Are there other options?
  3. If the complexity of the calculations does not allow the first solution (I can not avoid exceptions in normal usage) are the final checks enough or are there other aspects I should consider?

Answer 1

1. Which would be better in a safety-critical system depends on the system and cannot be answered without more information.

2. Another option is to design the floating-point code so that no undesired behavior is possible (or can be handled as desired) and to write a proof of that.

3. In general, checking final values is inadequate to detect whether exceptions or other errors occurred during computation.

In regard to 3, consider that various exceptional results can vanish in subsequent operations. Infinity can produce zero when used as a divisor. NaN vanishes in some implementations of minimum or maximum. (E.g., max(3, NaN) may produce 3 rather than NaN.) Analyzing your code might (or might not) reveal whether or not these things are possible in your specific computations.

However, an alternative to checking final values is checking exception flags. Most implementations of IEEE 754 have cumulative flags—once an exception occurs, its flag is raised and remains raised until explicitly reset. So you can clear flags at the start of computations and test them at the end, and, unlike testing final values, this will guarantee that you observe exceptions after they occur.