Strategies for overlapping the development of embedded systems software and hardware

Building embedded systems involves the production of the hardware, the development of an API that defines how to access that hardware, and software that drives usage of that hardware. Embedded systems development teams want to be able to start developing and testing software before the hardware is ready, but the software and hardware need to be developed in parallel because time to market is so critical in this industry. In this article, I provide an overview of how developers of embedded software can address this challenge. In a nutshell, I recommend performing a significant amount of testing from the desktop so that hardware testing need only verify the interfaces between the software and the hardware, and confirm that the functionality that was verified on the desktop still operates as expected on the target device.



CODING POLICIES

Since you’ll typically be using two different compilers over the course of the product lifecycle— one for compiling code that will execute on the desktop (host) system, as well as a cross-compiler for compiling code that will execute on the target hardware device— you need to be very careful about how you write your code. You and your team members should determine which coding constructs are not supported by both compilers (typically, the cross-compiler is more restrictive than the desktop compiler), then define a coding policy that specifies which constructs should be avoided.

Adherence to this policy can be checked by static analysis tools that allow you to define and enforce custom coding policies. Additionally, it is helpful to use the same tool to check for violations of industry-standard coding rules; this is a very effective and effortless way to vet many classes of bugs.



UNIT TESTING ON THE DESKTOP

Whenever you develop software, it’s important to start building and running regression test suites from the earliest phases of development. This is the only way to ensure that the software is working correctly, and that code modifications/additions do not introduce problems or unexpected changes into the existing functionality. However, early testing is complicated by the fact that embedded hardware is typically not completed until the later phases of the software development lifecycle— when it is exponentially more difficult and costly to find and resolve bugs.



Stubbing enables you to start ensuring that code works correctly as it is being built—regardless of the status or availability of the hardware. This involves “stubbing out” software calls to the hardware so that they are directed to stubs that you create to represent the API. These stubs should be designed so that when they receive inputs, they can respond with several values that make sense, according to the specification. After stubs are defined, unit test cases should be built in such a way that they actually intercept calls to the hardware and direct them to stubs instead.



With these unit tests and stubs, you can begin testing from your desktop (also known as “the host system”), using your desktop compiler to compile your program executable as well as your tests. Your goal for testing on the desktop is not only to expose defects and ensure that the software’s logic is working properly, but also to establish a robust regression test suite that can be leveraged to validate that the software functions in the same way when it executes on the target device.



UNIT TESTING ON THE HARDWARE DEVICE

Once the hardware is available, you can recompile the code with the cross-compiler, then execute and test it on the target device.



The challenge here is that your desktop-level test suite will be configured to intercept calls to the hardware and redirect them to stubs, but now that you will be testing code on the actual target device, these same calls need to be routed to the actual device. This is relatively simple, as long as you are using an automated testing tool that generates unit test cases in such a way that they are essentially small programs which can have stubbing enabled or disabled.



In order to configure your desktop regression test suite to execute on the target device, you recompile the test programs—this time using the real libraries instead of stubs— using your cross-compiler, then you deploy them to the target device for testing, which can be controlled from your testing tool’s GUI (on your desktop). The test programs then execute on the target and report back to the desktop via a serial interface or a TCP/IP connection.



FINAL THOUGHTS

Since you start testing on the desktop, you establish a regression test suite that you can run daily—regardless of whether the hardware is completed or available for testing—to ensure that problems and unexpected changes are exposed as soon as they are introduced, which is when they are fastest, easiest, and least costly to fix. Moreover, since the code has been thoroughly tested on the desktop before it ever reaches the target decide, you obtain reasonable assurance that the code will run on the target device when it is available. Most issues in the software’s logic will have been vetted and resolved during desktop testing, so this should significantly reduce the amount of time you need to spend testing the code on the target device. In fact, when the target device becomes available for testing, you should only need to use it to verify the interfaces between the software and the hardware, and to confirm that the functionality which was verified on the desktop still operates as expected on the target device.



Dr. Adam Kolawa is the co-founder and CEO of Parasoft, a leading provider of Automated Error Prevention (AEP) software solutions. Kolawa's years of experience with various software development processes has resulted in his unique insight into the high-tech industry and the uncanny ability to successfully identify technology trends. As a result, he has orchestrated the development of several successful commercial software products to meet growing industry needs to improve software quality - often before the trends have been widely accepted. Kolawa, co-author of Bulletproofing Web Applications (Hungry Minds 2001), has contributed to and written over 100 commentary pieces and technical articles for publications such as The Wall Street Journal, CIO, Computerworld, Dr. Dobb's Journal, and IEEE Computer; he has also authored numerous scientific papers on physics and parallel processing. His recent media engagements include CNN, CNBC, BBC, and NPR. Kolawa holds a Ph.D. in theoretical physics from the California Institute of Technology, and has been granted ten patents for his recent inventions. In 2001, Kolawa was awarded the Los Angeles Ernst & Young's Entrepreneur of the Year Award in the software category.