Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Finding defects in safety-critical code

Posted: 31 Mar 2009 ?? ?Print Version ?Bookmark and Share

Keywords:code safety critical? static analysis? testing rigorous?

Relationship with systematic testing
As mentioned previously, safety-critical developers are required to demonstrate coverage. There are of course different kinds of coverage, and the risk the code carries dictates which kind of coverage is required.

Table: Shown is the number of test cases required to achieve full coverage for each coverage criterion.

In the DO-178B standard for aviation, the riskiest code is required to be tested to 100 percent modified condition/decision coverage (MCDC). The next two most risky classes must be tested to 100 percent decision coverage and statement coverage respectively. The least risky code, such as the in-flight entertainment system, has no coverage requirements at all.

Most developers will be familiar with statement coverage, and anyone who has tried to test with 100 percent statement coverage will know exactly how difficult it is to achieve. Decision coverage is more stringent: it requires that all branches in the control flow are taken: you must make test cases that force all your conditional expressions to evaluate both true and false. MCDC coverage is stronger still, and means that all sub-expressions in a conditional should be evaluated to both true and false. Consider what this means in terms of the number of test cases for the following code snippet:

if (a || b || c)


The table shows the number of test cases required to achieve full coverage for each coverage criterion and example values required of the inputs.

Figure 3: A redundant condition warning from CodeSonar. (Click to view full image)

Clearly, achieving full coverage is non-trivial. It can of course be fundamentally impossible to achieve. If your program contains unreachable code, you cannot even get full statement coverage, never mind decision or MCDC. Similarly, if your code contains redundant conditions (conditions that are either always true or always false), then you might achieve statement coverage, but not decision coverage.

A developer may spend hours trying to develop a test case before it becomes evident that it is impossible. If this had been known in advance, much frustration and wasted time would have been saved.

Figure 4: A fragment of a report from CodeSonar illustrating a redundant condition. (Click to view full image)

See for example, line 475 in Figure 3. The comment in the leftmost column indicates that the condition on that line is always true. In this case, there is an obvious redundancy: The third sub-expression is the same as the second sub-expression. If the second sub-expression is true, the third will be evaluated, but that will always be true also. It is difficult to divine the real intent of the programmer here. Perhaps there was a third field whose value should have been checked.

These kinds of issues correlate well with bugs too. Consider the example shown in Figure 4.

Figure 5: The body of get_type(). There is an error on line 30. (Click to view full image)

The column on the left shows the condition that cannot be satisfied: pb->type can never be equal to 3. This value comes from a call to get_type(), whose definition is shown in Figure 5.

The error is on line 30 and is clearly a typo: The programmer missed the final "X".

Techniques for reducing the risk of bugs in software for safety-critical systems can work to reduce bugs in non-safety-critical systems. Advanced static-analysis tools can help by finding real errors automatically and reducing testing costs.

- Paul Anderson
VP of Engineering, GrammaTech Inc.

?First Page?Previous Page 1???2???3???4

Article Comments - Finding defects in safety-critical c...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top