If  T. Adrian Hill is right, the best way to find as many bugs as possible in your embedded system code may be to use what psychologists and therapists call "tough love."

Rather than probe and question the patient and gently dig out the underlying problems, tough love involves creating a situation in which the subject is pushed nearly to to the breaking point where the underlying problems can be quickly observed and resolved.

At the upcoming Embedded Systems Conference, Silicon Valley, Hill will be reprising his popular class on "Stress Testing Embedded Software Applications (ESC-420)," where he will discuss various tough love techniques for finding what is wrong with software by stressing it to the breaking point.

A member of the Principal Profession Staff at the John Hopkins Applied Physics Laboratory, he has led the embedded software development on numerous NASA missions including the Hubble Space Telescope.

Just as the "tough love" concepts are considered beyond the accepted norms for psychological counseling and treatment, the software stress testing techniques developed at the Applied Physics Lab by Hill and his coworkers are in many ways the antithesis of the traditional software acceptance testing and debugging.

In his class he will go into detail on the methodologies developed at the Lab for the stress testing of software included on three recently launched NASA missions, the MESSENGER mission to Mercury launched in August, 2004; the New Horizons mission to the Pluto-Kuiper Belt, launched in January, 2006 and the STEREO mission to study the Sun close up, launched in October of 2006.

In the traditional approach test engineers develop and execute test that are defined to validate software requirements. "Testing is a standard phase in nearly every software development methodology," said Hill. " Test engineers develop and execute tests that are defined to validate software requirements. The tests tend to be rigid with specific initial conditions and well-defined expected results.

The tests typically execute software within the limits prescribed by the software design. While these tests are often complemented with System Tests or Use Case Tests, these higher level scenarios still conform within the design bounds of the software."

Software stress testing, however, runs counter to these traditional approaches, said Hill. "Stress testing involves intentionally subjecting software to unrealistic loads while denying it critical system resources," he said. "The software is intentionally exercised 'outside the box' and known weaknesses and vulnerabilities in the software design may be specifically exploited."

However, there are some caveat's to keep in mind when conducting such tests, according to Hill. "Degraded performance of a system under stress may be deemed perfectly acceptable, thus, the interpretation of test results and definition of pass / fail criteria is more subjective,"he said.

"Furthermore, a test that stresses one aspect of the software may lead to undesirable side effects in another area of the software so the entire system behavior as a whole must be evaluated to properly analyze the results."

Even so, the results of such testing on the NASA missions, he said, proves the usefulness of this approach. There, the stress testing uncovered a total of 32 problems across the three software efforts, which Hill details and analyses in his class.

Based on his experience, Hill believes software stress testing should be an essential component for any critical embedded software development program.

"While such testing is typically not written as a formal requirement, users have an expectation that the software demonstrates the characteristics of robustness and elasticity in response to any user actions," he said. "Furthermore, stress testing can expose design flaws and software bugs that are not easily uncovered using traditional testing methods.

"The problems uncovered in stress testing often involve the complex interactions between tasks such as missed real-time deadlines, deadlocks, race conditions, and reentrancy issues. A formal and rigorous approach to Software Stress Testing can uncover serious problems before the software is released into the user community."

Other software development, debug and testing classes worth checking out at the conference include

1) "Peer Code Review doesn't have to suck (ESC-300)," presented by Jason Cohen.

2) "System visibility via call graphs (ESC-340)," a class taught by George Mock.

3) "Fault detection in Embedded Systems (ESC-360)," presented by Lorenzo Lupini and Massimo Qauagliani.

4) "Static code analysis for embedded software (ESC-430)," taught by David Kalinsky.

5) "Guide to adopting static source analysis (ESC-528)," presented by Nikola Velerjev.

6) "Debugging the toughest software bugs using a static analyzer (ESC-550)," a class taught by David Stewart.

Click here to register for the Embedded Systems Conference, Silicon Valley.