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
- Unit test interference: by mixing the functional and diagnostic code you prevent unit testing of the components.
- 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.
- 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
- The functional code should not depend on any output from the diagnostic beyond the diagnostic flags.
- The diagnostic code should not make calls to functional code
- The diagnostic code should not perform filtering, table lookups or integration operations
- The diagnostic code should be non-interuptable.
Thanks, Michael. I’m curious what is behind the rule of thumb not to include table lookups in diagnostic code. Is this to avoid dependence on functional calibrations in the diagnostic code in favor of more easily controllable signal dependencies?
In general table look ups indicate that the developer of the diagnostic algorithm is reusing parameters / data from the control algorithm. With any rule of thumb context needs to be understood, if they table is there to provide boundary information (e.g. within this range you are “safe” then they are ok. If it is to calculate more complex data then those calculations, most likly, should be in the functional code.