Future directions for static analysis
To meet the future requirements for the growing number of safety critical embedded device designs, work needs to be done in two key areas: finding new classes of defects and coding for safety.

New Classes Of Defects. Traditional static analyzers are implemented in a high level language code processor (or "front end"). Such a tool consumes source code and produces defect diagnostics relating to the source code itself and nothing else.

The integrated compiler approach consumes source code, produces error diagnostics, and optionally generates the target object code for the software (adding "back end" functionality). By incorporating knowledge of the run-time object code characteristics of software, static analysis is able to locate some classes of defects that standalone analyzers simply cannot reach.

Stack overflow detection is one example. Multithreaded applications use concurrent threads to accomplish their work. In many classes of medical devices, memory is constrained, and the programmer must specify the size of run-time stack for each thread to use.

When a thread uses more stack space than was allocated, a stack overflow occurs. The result of a stack overflow varies. In some cases, the overflow causes corruption of critical data located beyond the stack segment, resulting in a downstream system failure.

During its target code generation phase, the static analyzer is able to compute the run-time stack memory size requirements for each subroutine. This information is combined with the analyzer's intelligent inter-module path comprehension to compute worst case stack size requirements for the entire application and warn the user when these requirements exceed the specified per-thread allocations.

Thus, an insidious run-time defect is detected and prevented with static analysis. This is one example where the soundness, or ability to detect defects, needs to improve over time in static analysis tools.

It is conceivable that other types of defects and secure software development features can be added to the static analysis tool. For example, since the analyzer understands the complex pathways through software and can generate code, unit testing software can be automatically inserted to improve coverage. This is one of many promising areas of research.

Coding For Safety. Most safe and secure development processes espouse the use of a coding standard that governs how developers write code [9]. The goal of the coding standard is to increase reliability by promulgating intelligent coding practices.

For example, a coding standard may contain rules that help developers avoid dangerous language constructs, limit complexity of functions, and use a consistent syntactical and commenting style.

These rules can reduce the occurrence of defects, make software easier to test, and improve long term maintainability. There are some tools that enable various parts of coding standards to be automatically enforced.

Good software practices also espouse "design by contract" (DbC) methodology. With DbC, the software developer uses language features or extensions to check subroutine preconditions and postconditions, correctness assertions, and other design invariants.

Unless the developer is using SPARK Ada or other obscure programming languages that incorporate DbC, the programmer must resort to run-time verification of these design contracts.

Of course thorough testing is also critical to software robustness. Although there are some tools for semi-automating the generation of test cases, most developers resort to traditional manual methods.

One vision for static analyzers is to incorporate all of the above robustness techniques (and more) into a single tool that is fully integrated, executes efficiently, and needs only to examine the source code statically. This "uber-analyzer" can perform traditional static analysis, enforce coding standards, generate test cases, enforce as many DbC constructs as possible, and more.

Conclusion
Static analysis represents the next major ingredient to be added to high quality coding standards for medical device software development. A number of optimizations and integrations are possible to make it easy and efficient to incorporate automated static source code checking into the everyday safe software development process.

Furthermore, static analysis can be an important weapon in the regulatory investigator's arsenal to quickly locate potential sources of malfunction in complex device software.

David Kleidermacher is chief technology officer at Green Hills Software where he has been designing compilers, software development environments, and real-time operating systems for the past 16 years. David frequently publishes articles in trade journals and presents papers at conferences on topics relating to embedded systems. He holds a BS in computer science from Cornell University, and can be reached at davek@ghs.com.

References
[1] The Economic Impacts of Inadequate Infrastructure for Software Testing; NIST; May 2002, p. 1-13.
[2] Are Vendors Doing Enough To Improve Software?; Robert Parker; Optimize Magazine;
[3] Debian-counting. Communication Systems Group of the University Rey Juan Carlos, Madrid Spain;
[4] American Association of Physicists in Medicine Radiation Therapy Committee Task Group 53: Quality assurance for clinical radiotherapy treatment planning; Benedick Fraass, et al.; 1998;
[5] CERT Statistics
[6] Common Vulnerabilities and Exposures (CVE)
[7] Survey of engineers at Embedded World 2006; Nuremberg, Germany
[8] TimeMachines: the future of debuggers; Mike Lindahl; RTC Magazine; October 2006
[9] DO-178B, Software Considerations in Airborne Systems and Equipment Certification; at RTCA.Inc.