Bubble wrap syndrome (BWS): A safety critical issue

We all know what it is:

Bubble wrap syndrome (BWS): The overwhelming desire to “pop” cells
in a sheet of bubble wrap.  See also Packing Peanut Popping (PPP).

Even if it isn’t a real psychiatric diagnosis it makes for a good, slightly humorous, starting point of this post.  Bubble wrap is designed to protect items in shipping.  When we “pop” bubbles we decrease the effectiveness of the wrap.  In the software domain, this corresponds to the slow creep of “features” into the diagnostic code.

The road to heck…

By design diagnostic code is isolated from the functional code.  Because of this diagnostic code will, sometimes, duplicate calculations that exist in the functional code.  It can be tempting to interleave, reuse, those calculations for both the functional and diagnostic code.

There are three problems with this

1. Unit test interference: by mixing the functional and diagnostic code you prevent unit testing of the components.
2. Development independence / common failure mode: Mixing the two components together you run the risk of introducing a common failure mode in the analysis of the data.
3. Link to a common processor: for some safety critical systems diagnostic code runs on a separate processor or core.

 

Where are the boundaries?

In this example, the “Proposed Mines” are the possible infestation of our pristine “boundary waters” diagnostic code.  The question is “how close is to close?”  The following rules of thumb can be applied

1. The functional code should not depend on any output from the diagnostic beyond the diagnostic flags.
2. The diagnostic code should not make calls to functional code
3. The diagnostic code should not perform filtering, table lookups or integration operations
4. The diagnostic code should be non-interuptable.