Challenges of Embedded Software development

Once upon a time, embedded devices were essentially hardware devices which stored a few Kilobytes of code. Things are different now. Embedded software development has become a complex, multi-billion dollar industry. We try to chalk out these developments, drawing comparisons with the world of desktop computing.

Embedded software development business is going through a facelift. Gone are the days where a small team of engineers used to hack out assembly code running into a few thousand bytes for an embedded device. Embedded projects today are often large, and carried out by diverse teams with multi-million dollar budgets working with the latest processors and software tools, racing to complete code and ship a product before the market passes it by.

This is true not just for large network switches or complex defence/aerospace projects, but also for the slew of sub-$100 consumer devices that keep coming into the market almost every week these days. Mobile phone manufacturers like Nokia has teams of 30-40 software engineers working on a single phone model, developing a suite of applications and protocols that will run on a device with 1 MB RAM and some on-board ROM. They have, at any point in time, twenty or more different embedded consumer devices in planning or in production. Older designs may still run small programs on 8-bit processors, but the latest designs with the most market impact are both fast and highly intelligent, and run far more code than ever before. 

Issues like size, complexity and time-to-market are causing fundamental changes in how embedded software is written. In some aspects, embedded developers are learning from their desktop counterparts, who also witnessed revolutions these past years, with Windows GUI and the Internet.

However, the approach to embedded software has been, and will continue to be, quite different. So, instead of writing a crude and simple program loader, you buy a real-time OS; instead of Assembly, you buy a good C compiler; and objects -- useless when programming a few Kbytes of code -- suddenly become indispensable for modeling complex real-world systems and designing code.

In practice, however, embedded programmers are breaking new ground in technologies and design practices. About the only thing embedded software developers have in common is diversity. Embedded software designers and programmers are working on everything from satellite systems to consumer electronics to network devices. There are no applications, techniques, or tools that are common to developers in all of these areas.

Nevertheless, there are some principles that can be applied across most projects -- at least those that use 32-bit processors and require a significant amount of code. These types of projects offer the ability to add value to embedded devices, and allow both product and software designers to be creative.

Approach

Starting from scratch, the embedded software design process is a whole new ball game. A few years ago, it was common for programmers to develop all of the software that went into a device. But the code involved was often relatively small, so it was possible to write and maintain a few thousand lines.

Embedded software today typically includes an RTOS, a variety of device drivers, network protocol stacks, windowing systems, and application software, sometimes totaling hundreds of thousands of lines of code. Few, if any projects, can approach this kind of project from scratch, at least not in any reasonable time frame.

One solution is to focus on one area where the embedded developer can add value. Another approach is to view the embedded developer's job as that of an integrator, rather than as a traditional programmer. Many of the components, including any level of RTOS support required, protocol stacks, Web servers, and windowing systems, are all available from at least several commercial sources. The embedded product designer may add little anew, but still manage to produce an entirely new mix with a different combination of components and features, or a new price/performance point.

Even if you're planning to develop large amounts of code yourself for a unique system or application, components have already been developed that you can simply pick and use. The RTOS is a given; there are simply too many alternatives available to not find one that meets your needs. Data communications is a second area where established solutions already exist, both from RTOS vendors and from third parties.

Web and Internet services, especially in conjunction with network protocol stacks, are available from multiple sources. These can range from established, name-brand components for high-end devices from Spyglass to a small and innovative Web server and content compiler from Agranat Systems.

Sophistication is the Key

To support more complex operations, today's RTOS does more. In the past, a principal selling point was the size of the kernel, usually the minimal execution unit. Some vendors still brag about their kernel size, but most, even the best known in the business, won't mention it unless asked. 

At the same time, many embedded system designers think nothing of discussing products like cellular telephones and TV set-top boxes with 32-bit processors and a megabyte or more of memory. How are small kernels reconciled with big address spaces? Through the use of add-on components, from drivers to file systems to protocol stacks. RTOS vendors have used this type of architecture to accommodate a variety of embedded needs, and it has enabled users to select the exact components they need.

What's driving the RTOS requirements to these levels? First, faster 32-bit processors with hardware memory protection and more flexible instruction sets require system-level support. Second, embedded devices simply need to do more, with networking, Web, multiple peripherals and simultaneous control of many tasks. The proliferation of devices to be controlled and the level of control required mean that even small kernels have to support many different drivers and file systems.

The question in the RTOS world today is assessing the impact of Microsoft's Windows CE. The RTOS market is highly fragmented, with more than 10 products vying for customers. Of course, from the vendors' point of view, it was worse three years ago when there were nearly a hundred players. Since then, the large players have gobbled up the smaller ones. Although four or five vendors can be considered major players today, Windriver is the most dominant. Some analysts say that this situation is ripe for further consolidation, and Microsoft is just the company to do so.

In the early days, the biggest impact was on the compression in terms of size of the application and speed of the compiler. Make no mistake. These are still important considerations. But today, speed of development and debugging, and ease of use, have taken their place alongside these characteristics as critical factors in choosing a toolset.

The first, and arguably most complete toolset available, is WindRiver Systems' Tornado environment. Tornado combines compiler and debugging tools with a comprehensive host-target connection. It also enables third-party tool vendors to plug in their products and work within the overall architecture. But despite its success, Tornado remains tied to WindRiver's VxWorks operating system. Others have been scrambling to catch up.

Several vendors, such as Metrowerks, offer IDEs that compete with Tornado, yet are more platform-independent. To further combat Tornado, there's a trend toward using PC development tools, such as Microsoft Visual Studio and Borland C++, as vehicles for embedded tools. If you make a visit to www.Microsoft.com\embedded, you will understand that now every development tool from Microsoft has an embedded version too. Hence, you might soon find yourself coding on Visual Basic Embeded and VC++ Embedded.

But PC development tools aren't the panacea they appear to be. While familiar to many developers, it's important to note that they were designed specifically for desktop development. Some features, such as MDI wizards and Win32 object libraries, simply have no use in embedded development.

Hardware and Software

It is almost a fantasy to think that, given enough on design, software will always work properly when implemented. Testing and debugging will always be necessary to find design defects, uncover limitations on target platforms, resolve implementation ambiguities, and simply correct human errors. While established software development processes can minimise these issues, they won't eliminate them entirely.

Embedded software may share a growing number of characteristics with desktop software, but there's one thing that will always make it unique -- it interfaces directly with the processor and other hardware devices. While programs may call operating system services or other programs, more often than not, the programs are drivers that work with specific devices or peripherals.

Furthermore, the devices that run embedded programs are neither uniform nor standardised. The target could be anything from a network switch to a cable TV box. This means that there are few programming standards that can be followed across this range of products. The interface between hardware and software remains rapidly changing and hard to characterise.

Much of the problem in working with this interface is that it has been occupied by those with two fairly distinct types of skills -- hardware engineers, who design the device, and software engineers, who make the device do something. In many projects, the software's value is increasingly recognised as designers increasingly exert more control over hardware choices. 

But many software engineers lack detailed technical knowledge of hardware internals. That's why embedded software companies like Encore Software "prefer to recruit electronics engineers and teach them software programming, rather than the other way around" as Encore CEO Vinay Deshpande put it. The required knowledge may range from processors to buses to peripherals, all of which have to interface with software. Without an understanding of how these devices work, a program can be correct in theory, but not work on the hardware target.

Debugging

The key to debugging at this frontier of software and hardware is visibility into the execution of the program. With most embedded systems, it's not possible to watch a program execute on the screen. What's needed are tools to get inside the device and observe register values, memory locations, and data and instruction flow.

There are tools to help this interface from being so painful. Logic analysers help out the hardware engineers by testing the robustness of the electrical connections and circuitry. On the software side, emulators enable software engineers to test code in a controlled environment that bears some relation to the actual target. Hewlett-Packard's software group offers both in its new 16600A and 16700A logic analysers, which provide physical interfaces to the embedded board of use to both hardware and software engineers.

Lastly, embedded debuggers support far better visibility than many tools for desktop application development. 

Getting Them to Work

While embedded developers are somewhat behind the rest of the software industry in adopting and using modern design methodologies, large and complex projects are forcing the issue. The intent behind a methodology is to guide the analysis, design, and implementation of a system project. In short, a methodology leads you through the turning of an idea into silicon and software.

Nevertheless, complex embedded projects will benefit from the use of a methodology. There are too many available to consider them all. Many embedded designers are looking toward object-oriented methodologies, thanks to a better understanding of objects that has been fostered by the increased use of C++ and Java.

OO techniques, however, may not apply well to the analysis and design of some embedded real-time systems. Real-time designers tend to think along the lines of tasks, which are often the most logical way to partition the activities of a system that must respond to concurrent real-world events. In contrast, object-orientation urges designers to think along the lines of objects. Bridging the two is often difficult. An object is an encapsulation of data and action, while a task is a thread of activity that acts on data. As a result, real-time designers are reluctant to abandon the 'task' view and adopt the 'object' one.

Probably, the biggest news this year in OO methodology circles was the release of the Unified Modeling Language (UML). UML is the brainchild of the OO guru-triad of Grady Booch, Jim Rumbaugh and Ivar Jacobson of Rational Software. It's an amalgam of the best notational tools from each of its authors' own methodologies: Booch, OMT (object modeling technique, from Rumbaugh), and OOSE (Object-Oriented Software Engineering, from Jacobson).

Methodologies are one area that borrow heavily from computer development projects. Artisan Software adapted its Real-Time Perspective methodology, which uses UML notation, from a sister company that sold a traditional enterprise modeling technology, and adapted it for real-time use. 

To make a methodology work, what's needed is ongoing improvements in the toolsets. Virtually all of the OO toolsets available support model execution, which gives the designer a powerful prototyping tool. Errors can be caught early in the design; they don't percolate down into hiding places in the generated code.

Tomorrow, the tool chain may move to an yet higher level. The vast movement of many embedded projects to object-oriented design makes it possible to precisely specify a design diagrammatically, and let the code be generated.

Again, the biggest challenge is to develop software on a hardware platform that is getting built as the development takes place. Unlike the PC platform, which is more open, hardware requirements are very dedicated and can also be proprietary. "The biggest challenge for our development centre in India is that we need to develop software on a chip that is getting developed simultaneously in our European labs," says Dr Bob Hoekstra, CEO of the Philips Software Centre in Bangalore.


Are these Advances Helping?

What do all of these innovations do to the cost of the typical embedded system? Except for small numbers of defence or mission-critical systems, cost is still the driving factor behind the design of an embedded device. With more memory and processing power, more complex software, and the development infrastructure, do these advances pay?

The answer is yes. For one, it's not nearly as easy to issue bug fixes and updates to embedded software as it is to desktop software. Getting high-quality code the first time is a demanding but necessary goal, and one that more sophisticated tools and development methodologies help do.

Second, the cost of hardware and software has decreased rapidly over the last couple of years, and will continue to do so in the future. We all know the performance improvements and lower costs of microprocessors and memory, but few realise that the same relationship also holds for much of software. Software development kits that cost thousands of dollars a few years ago retail for less than a tenth of that today.

Lastly, shortened time-to-market can make the difference between a product's success and failure. Software tools that let you design at a higher level, and make you more productive more quickly are becoming essential parts of that equation.

Embedded software will continue to get more complex as embedded systems of all types get faster processors and are asked to do more things. If anything, systems are called upon to be even more reliable, and delivered almost as soon as they've been conceived. About the only characteristic available in more quantities is processing power and dynamic storage, and both have to be used judiciously.

Embedded software development has become a large and complex undertaking. The application of modern software design principles, adapted to embedded products, enables designers and programmers to adapt to more complex processors and code to produce high-quality software with improved time-to-market.