First a definition:

A software bug is an error, flaw, failure or fault
in a computer program or system that causes it to
produce an incorrect or unexpected result,
or to behave in unintended ways.

This is in contrast to incomplete development where the program is not yet performing the intended function.

There are three types of bugs:

1. Changed induced: these are bugs that arise when part or all of the program is changed.  These can often be resolved by doing comparisons against the earlier version of the program.
2. Corner case bugs: these bugs are due to missed behavioral cases; for instance not accounting for overflow in a button counter.
3. Incorrect library/function usage: these bugs arise from the use of library functions incorrectly; for instance passing a double to an integer function.

DIF:  Detect, Isolate, Fix

In debugging the first step is to trace the issue to its root; in Simulink, this is normally a subsystem, in Stateflow a set of state transitions; in either case, the issue could be due to changes in parameterization so…

1. Review/compare parameter data: inspect the parameter data that specifies the behavior of the system.  Try reverting to earlier versions of the data.
2. Introduce data logging: the simplest level of debugging is the introduction of intermediary data logging points.   If this is a change induced bug this is often enough to determine the problem.
3. Simulate by unit: where possible decompose the full model into components and simulate them in isolation to determine the subsystem behavior.
4. Introduce breakpoints: both Simulink and Stateflow allow for the introduction of breakpoints.  Conditional breakpoints, where the simulation halts for a given configuration, add additional debugging power.
5. Use formal methods: use of formal method tools such as Simulink Design Verifier to detect dead logic and overflows/underflows can automatically determine the location of some bugs.
6. Second eyes: Bring another person in to talk about your model, what you expect and what it is doing.

Common “bugs” and simple fixes

The following are common development bugs

1. Miss aligned ports:  verify that the inputs to a Model or Library correctly map with the calling subsystem.  This issue arises when the referenced model/library is changed.
2. Never reached: dead code due to logic that is never activated.  This is found using the coverage report or through SLDV.
3. NAN: nan, or not a number, occurs when you have a divide by zero operation.  To detect this set the Simulink diagnostic to detect this condition.
4. Interpolation data and tables: by default blocks in Simulink will interpolate outside of the specified range.  This can cause problems if
   1. The data is of integer type and the result is a float
   2. The data is not valid outside of the specified range
5. Saturation/limiters: frequently people put in limit blocks into systems during development.  These blocks can “prevent” issues but also introduce errors.  Inspect the data going into and out of limit blocks (and limits on integrators.)
6. Synchronization: in some instances, the behavior depends on synchronized data; if the signals are out of alignment due to either introduction of unit delays or sample rate of the system.  Look for cases where transitions are dependent on the status of two highly transient variables at the same time.

Feedback:

I would love to hear about your common bugs and debugging techniques.