As a private pilot, I’m well acquainted with the benefits of simulation. With a light plane, it’s pretty clear. You can virtually fly for hours at near zero cost using only a laptop (and maybe a couple extra controllers and a nice monitor, if you’re fancy), whereas the cost of flying an actual plane can be as much as hundreds of dollars per hour. There are other benefits too, such as being able to fly when the weather wouldn’t permit operation of a real plane and being able to simulate failure conditions that you would never want to face in a real airplane with your life at stake.
As embedded software developers, though, the benefits of a virtual environment may seem a little bit fuzzier at first, although, interestingly, the flying metaphor holds pretty well. When your team is developing a new embedded system, chances are good that the hardware and software are being developed in parallel. Often, functionality that will eventually be supplied by cost-reduced, high-volume hardware components is prototyped with expensive programmable hardware such as FPGAs, and highly-customized circuit boards often drive the price of prototypes to hundreds of times what a production unit will cost. The net result is that developing software on prototype hardware can be a very expensive proposition.
If your project is like most embedded system development projects these days, the proportion of the system complexity contained in software (versus hardware) is rapidly increasing, as is overall system complexity itself. This leads to much, much more complex software being charged with increasingly critical roles in system operation. The net result is that teams need more software engineers to get the job done, and those software engineers have to do a better job than ever before. Development process solutions that will allow more software developers to work faster, cheaper, and more effectively are essential – even to maintain system-level status quo.
As in flight simulation, cost is just the beginning of the benefit picture for development using simulation instead of the real thing. When working with real hardware and real interfaces between hardware and software, visibility can be difficult to come by. With a virtual model, however, you can freeze your system at just about any point and examine pretty much anything your curiosity desires. With a real hardware system, you can examine only what your debugger shows you or what you can connect a very expensive piece of test equipment to.
Particularly now that multi-core processing systems are becoming the norm, even in embedded systems, the task of low-level debug for software executing on multiple processing elements in parallel can be greatly simplified using virtualized software development. While the hardware guys are still working out the kinks in the multi-core computing platform, software development can be racing along in parallel, and even informing the hardware design efforts by characterizing the software’s particular platform needs.
Also, as in flight simulation, you can create failure conditions that would be unsafe, difficult, or even impossible to create with a real, working system. Many software quality assurance groups have jumped on the virtual platform bandwagon for just this reason – it allows them to evaluate the response of the software to various system failures that can’t be easily initiated in real life. This extends effective fault coverage in software QA into critical areas for embedded design – areas where failure mechanisms span the boundary between hardware and software.
Virtual models also allow even more creative analysis – tricks we wouldn’t even conceive with real hardware, such as reverse execution and complex breakpointing that triggers on interactions between both hardware and software elements of the system. These capabilities can be useful both in locating the cagier bugs and in developing software and systems that don’t have as many bugs in the first place.
In military and aerospace applications, virtualized software development has been catching on even faster than in commercial segments. Part of this can be attributed to the fact that military and aerospace hardware is more expensive and scarce, and therefore the savings on development platform costs are more pronounced. Another reason is that these applications tend to face stricter quality and documentation standards than your average consumer project, and virtualized software development helps to meet those higher standards.
In some cases, our metaphor even meets reality. Recently, BAE Systems and Virtutech announced that BAE would be using Virtutech’s Simics simulation system for development of space-bound applications on the RAD750 Space Computer. The RAD750 is a new generation of BAE Systems’s special-purpose computing platform for satellites. BAE and Virtutech announced that they would work together to allow mutual customers to develop software for the RAD750, even while hardware development was still in progress. With development of a satellite, it’s easy to see how actual hardware is an expensive and difficult environment for software development and debug, particularly when you consider the debug and qualification requirements and the kinds of failure mechanisms that must be tested and evaluated.
In these types of applications, faults such as those caused by conditions encountered only in space can be injected into software systems, and the flight software’s responses can be evaluated and tuned. The virtual platform can also be used to train end-user/operators on the system’s behavior during various failure modes. The software development platform is then effectively extended into a user training simulator.
As applications such as these prove and improve the effectiveness of virtual platforms for embedded software development, we expect to see the technology make its way into more commercial and industrial development projects as well. With time-to-market pressures mounting, the concurrent engineering afforded by virtualized software development will become increasingly attractive. More teams will follow in the footsteps of the current early-adopters, and virtual-platform-based software development may become the norm.
Several obstacles still exist, of course. It takes a concerted and coordinated effort on the part of hardware and software development teams in an embedded system design project to get a virtual platform up and running. In companies where hardware and software engineers rarely talk and possibly even eat in separate cafeterias, this kind of cooperation may be a long time coming. Still, over time, the benefits should outweigh even the professional cultural gaps that must be bridged, and we will all be happier, better rounded, and more productive as a result.
