Development Techniques for Using Simulation to Remove Risk in Software/Hardware Integration

Failings of Current "Configurable" Systems

Some embedded software providers are waking up to this problem. In fact, even the desktop is becoming increasingly wary of this "one size fits all" approach. Desktop and workstation operating systems have been trying to alleviate the symptoms of the problem by the use of dynamic kernel module loading, DLLs, shared libraries, etc. But that still doesn't fix the cause.

One of the biggest problems facing embedded software configuration is the same as that facing desktop software development - most commercial software is currently only supplied in binary format. In the embedded world, this is often either object files to link against, or a kernel with a loader for your program image. It is again the "one size fits all" approach, although at least with object files, the linker can remove unused functions or data.

Still, suppliers are trying to retrofit configuration to these systems, albeit often using workarounds. SunOS used to be supplied with a compiler and linker purely to allow the building and linking of its kernel. Some monolithic UNIX kernel images can be changed on disk using the "rdev" utility, for example, to set the default partition containing the root directory, effective with the next reboot. Solaris 2 provides the "ndd" utility to set certain global variables inside the kernel at run time. Linux provides a slightly better interface by providing a "/proc" virtual file system, which includes writable files to set kernel global variables. And of course there are simple configuration files for most application software.

But with this approach, all the code is still present, and still uses static resources. Extra conditionals are in the code to check for the status of the necessary global variables, thus slowing down execution even in the most frequently used execution paths. These overheads can only be reduced with source-level configuration.

Also, while there is no theoretical maximum limit, there are not many options to choose from; after all using the methods above, it would be too easy to get lost in the hundreds of options - configurability was bolted in as an afterthought, not designed in. This also proves the need for tools to manage the complexity of configuration, so that users cannot be swamped by an explosion in the number of options, at a level of detail that would otherwise be difficult to comprehend.

With existing configurable systems, it may be possible to set mutually incompatible options. In fact, one can be fairly sure that much of the above software has not been tested with multiple options set to non-default values - it would be difficult to manage using standard techniques. This proves the need for tools to manage inter-dependencies between options.

By their efforts, it can be seen that suppliers are trying their best to increase configurability in their software. But the embedded solutions have been weak. Taking the example of Microsoft® Windows CE, product literature claims that:

Because Windows CE is componentized, you can design embedded system platforms using the minimum set of software modules and components needed to support the platform's system requirements, which minimizes the memory footprint and maximizes performance of the operating system.

This sounds highly promising, and agrees with the principle of configurability. But at the same time, they have to say:

For example, a low-end system with just the kernel, the communications stacks, and a single non-display application would require less than 500K of ROM and 350K or RAM, depending on the application's needs.

As embedded developers would be aware, these figures are out of all proportion to the requirements. And one can feel confident that although there is a claim that it may take less space, this is highly unlikely in practice. One of the reasons for this failure is that although CE is componentized, these components are too unwieldy for anything more than coarse-grain configuration. Since these components are shipped in binary form, it again suffers from the failings of a "one size fits all" approach.