When designing communications equipment, large or small, choosing an embedded operating system (OS) is perhaps the most critical decision you'll make. That choice dramatically impacts the time-to-market, functionality, cost, performance, and reliability of the resulting system. In fact, the crux of the OS selection process is determining the appropriate tradeoffs between those five characteristics.
Fortunately, making those tradeoffs is easier than ever these days, for several reasons. Increasingly sophisticated tools are now available to support the use of in-house-developed kernels. At the same time, embedded OS vendors offer a wider range of specialized options. The result has been a diversification and specialization of embedded OSs. Embedded real-time OSs (RTOSs), such as VRTX from Mentor Graphics and VxWorks from Wind River Systems, Alameda, Calif., have been extended to support current networking protocols, standard programming interfaces, and Java Virtual Machines (JVMs).
Meanwhile, a new breed of desktop-derived embedded OS has been introduced. The most notable examples are Windows CE from Microsoft, Redmond, Wash., and ChorusOS from Sun Microsystems, Palo Alto, Calif. For its part, Windows CE has garnered attention—and that's not just because of the Microsoft brand. The attraction is its compatibility with desktop Windows programming interfaces (Win32), as well as its support for a rich set of features for embedded systems to interoperate with desktop applications. And these features are enhanced by its facilities, which support the building of sophisticated user interfaces (see the table).
Interestingly, this specialization in embedded OSs mirrors a similar trend in the embedded-chip industry. For example, in a move toward application-specific microcontrollers, Motorola, Austin, Texas, and IBM, Armonk, N.Y., offer over 30 different variants of the PowerPC microprocessor. Each one is designed for applications with different cost, performance, power-consumption, and peripheral requirements.
The growing range of OS choices gives communications system designers the flexibility to choose an operating system best suited to a specific application's needs. To take advantage of this diversification and specialization of embedded OSs, those designers must evaluate, choose, and trade off the appropriate set of OS requirements before starting the development process. Later in this article, a telephone-system example will illustrate the OS selection process.
Before examining each of the five tradeoffs individually, frame the issues by considering some general points. For example, the more full-featured an OS is, the easier and therefore quicker it is to develop an application on top of it. An OS may even have features, such as support for particular communications protocols. Those add functionality and value to the resultant application.
Unfortunately, these features come at the expense of increased memory requirements. Such demands raise system cost and almost always carry a performance penalty. This penalty is the result of the added software layers and the increased amount of information tracked by the OS. Worse, the added memory and boosted performance requirements both translate to greater power consumption.
The end application's requirements also must be weighed. With a simple high-volume wireless handset, the principal design objective may be to lower system cost. In that case, a scalable real-time OS is more desirable than a desktop-derived embedded OS. That's because it reduces system cost in two ways: It requires less memory, and its higher performance enables real-time requirements to be met with a slower, lower-cost CPU. Moreover, minimization of memory and CPU speed both contribute to lower power utilization and increased battery life.
But the primary goal with an advanced handset may be to provide functionality and ease-of-use to the end user. That could mean adding features like Internet access and information management. If written from scratch, crafting that software would take dozens of staff years to develop. Using a desktop-derived OS offers big benefits. It's likely to include the necessary underlying protocol and user-interface facilities, which will shave a tremendous amount of development time and risk from the process. While a faster processor may then be required to support the real-time requirements, this bandwidth benefits the performance of the features built into the phone.
Prior to selecting an embedded OS, evaluate these tradeoffs:
- Functionality
- Time-to-market
- Cost
- Performance
- Reliability
Functionality: For a communications system, there are two key OS functionality aspects to consider: communications support and user-interface support. At another level, the requirements typically align along two distinct application areas: infrastructure equipment and end-user applications. Reflecting this division, real-time OSs and desktop-derived embedded OSs are generally targeted at meeting the requirements of those two areas.
At one end of the extreme are real-time OSs, like VRTX. Such OSs have communications and user-interface features that address the requirements of infrastructure-equipment applications. Networking support is optimized for situations in which the equipment will be used as a data conduit. Supported applications include network boot, network management (including remote login), signaling, and routing.
Because infrastructure equipment is generally accessed via a network, minimal support is provided for building user interfaces on top of the real-time OS itself. Instead, provisions exist for running sophisticated user interfaces on remote desktop PCs or workstations. These have access to the embedded system via protocols like TCP/IP, Common Object Request Broker Architecture (CORBA), and Simple Network Management Protocol (SNMP). Access to an embedded interactive shell is provided via network login protocols, such as Telnet.
At the other end of the spectrum, desktop-derived embedded OSs are oriented towards end-user applications, including subscriber and test equipment. Here, communications support facilitates application-to-application interoperability. Windows CE, for example, includes web browsing, Telephony Application Programming Interface (TAPI), remote printer access, and file synchronization. Support also is provided for building sophisticated, local graphical user interfaces with either a proprietary or Windows 95/NT look and feel.
Time-to-market: Nowhere is time-to-market more vital than in the fiercely competitive world of communications. The key factors affecting time-to-market are the functionality provided by the embedded OS and the availability and ease-of-integration of third-party software components. Such software components help meet requirements that the OS does not fulfill directly.
The ease with which third-party components can be integrated into an OS depends a lot on the Application Programming Interfaces (APIs) supported by the OS. There are two primary API standards: Portable Operating System Interface for UNIX (POSIX) and Win32. POSIX is based on UNIX APIs and Win32 on Windows 95/NT APIs. It's supported by many real-time OSs, as well as by some desktop-derived embedded OSs, whereas Windows CE supports Win32.
Here again, the OS choice depends heavily on the end-application requirements. Communication protocols typically use POSIX interfaces. Meanwhile, almost anything written for a PC tends to be Win32-compatible, such as databases and graphical-user-interface enablers. Choose an OS that includes those APIs and is supported by third-party software components. Those features speed up the time-to-market by simplifying the porting process. Moreover, the developer's learning curve is influenced by the APIs supported. UNIX developers will find it easy to understand an OS that supports POSIX, while PC developers will find Windows CE more familiar.
The ease of porting to an application's hardware also impacts time-to-market. Real-time OSs like VRTX are designed to be ported to custom hardware. Such RTOSs generally support tools and OS capabilities that simplify the porting process. Desktop-derived embedded OSs are more often oriented toward specific reference-hardware implementations. They require more hardware support to enable the added functionality that they provide. While a desktop-derived OS can be ported, it's usually more time-consuming than with a real-time OS. The process of porting an OS like Windows CE to custom hardware can be accelerated using third-party system-level tools (Fig. 1).
Cost: The embedded OS you choose makes certain demands on the hardware resources in your system design. That affects overall system cost. Kernels created in-house can be developed to provide exactly the functionality required by the application. You can minimize the hardware and processor bandwidth required to meet real-time performance requirements. Off-the-shelf, real-time OSs are generally scalable, and let you minimize hardware resource requirements by scaling down to just what you need. For example, versions of VRTX can run with as little as 2 kbytes of ROM and less than 1 kbyte of RAM. And VRTX doesn't require that the microcontroller include a floating-point unit (FPU) or memory-management unit (MMU).
Because of their higher real-time performance, a real-time OS enables you to choose a slower, lower-cost microprocessor to meet an application's requirements. In contrast, desktop-derived embedded OSs usually require several hundred kbytes of ROM and RAM, plus a microprocessor with MMU and FPU support.
Performance: By nature, embedded systems have stringent performance requirements. The performance needed will vary by application. In order to have a "good" feel to the human user, a handheld device may have to update its screen within a few hundred milliseconds or so. In contrast, an embedded system controlling data switching might have to respond in the nanosecond range—and do so with real-time guarantees.
To select an OS that meets an application's performance requirements, characterize and quantify the application's needs. Over the years, the embedded industry has developed just such a set of measurements, helping to define the performance abilities of a given OS. These include Interrupt Disable Time, Interrupt Latency, Scheduling Latency, Context Switch Time, and System Call Timing.
Interrupt Disable Time is the time it takes the OS to disable interrupts internally, thereby protecting its critical regions. Interrupt Latency measures the interval between an interrupt occurring and the start of a task associated with the interrupt running. Scheduling Latency is the period between a high-priority task being ready to run and the actual time it runs. The time it takes the OS to switch between tasks is Context Switch Time. Although this last number is often quoted, it's generally not very useful. It doesn't measure end-to-end time (as does Interrupt Latency), which really affects the application. Finally, System Call Timing measures timing for best, worst, and average cases for each OS service (system calls).
Real-time OSs, as their name implies, almost always provide guarantees as to their real-time performance using those metrics. With VRTX, for example, Interrupt Disable Time ranges from hundreds of nanoseconds to a few microseconds, depending on the processor and clock rate. Interrupt Latency is typically less than five microseconds, and both Scheduling Latency and Context Switch Time are usually below 20 µs.
The real-time performance of desktop-derived embedded OSs is generally less well-characterized than with real-time OSs. And that performance tends to vary more between different products. The Interrupt Disable Time and Context Switch Time for desktop-derived embedded OSs usually range from 50 to 100 µs. Worst-case Interrupt Latency and Scheduling Latency vary from 100 µs into the millisecond range.
Most embedded OSs make some overall summary of their suitability for "hard" real-time applications. In these applications, the system must guarantee that the responses will occur on time, every time. It's still considered hard real-time whether these deadlines are to be measured within nanoseconds, milliseconds, or even hours. Simply put, the right results need to be available on time by whatever measure "on time" means in the application. Armed with this data, system designers can select an OS that meets an application's performance requirements.
Reliability: No company wants to develop an unreliable product. There's a considerable range in the consequences, both business and perhaps even legal, if a company does create an unreliable application. If a cell phone, for example, needs to be occasionally turned off and on again because of a software bug, the user may not like it. But he or she will probably tolerate it. On the other hand, the equipment underlying a telecommunications network has strict requirements for reliability, with serious consequences if these requirements aren't met.
Embedded OSs vary in their ability to meet reliability requirements. When examining these issues, development and testing standards come into play. For "mission-critical" applications with strict requirements for dependability, an OS built with formalized development and testing procedures may be required. It could be necessary to provide test data proving that 100% of the OS's code-coverage testing has been achieved.
Along with formal development and testing methods, service history is a concern. An OS's ability to meet reliability requirements can rest on its history in other deployed applications. Having an OS with thousands of hours of successful operation without failure provides an additional level of assurance that the system will operate successfully in a new application.
A third influence on OS reliability is tool support. When building an application, it's possible to avoid or eliminate errors that could lead to unreliability by using development tools. One of the attractions of the Java language is that it can wipe out certain types of errors caused by bad pointers. That's because the language doesn't support the concept of a pointer in the first place. The JVM pre-checks Java applications before they're run. And it can perform run-time checks as the program executes to eliminate or isolate errors in the system.
Even the interaction between hardware and the OS can affect reliability. By using the capabilities of the MMU available on some processors, an OS can contain errors. The MMU in such processors can isolate the effects of an error in one program from other programs. This sufficiently meets the reliability requirements of applications in which run-time error recovery is possible, without resulting in unacceptable equipment outages.
For applications demanding strict reliability guarantees via comprehensive, formal testing and a positive service history, RTOSs are the most suitable choice. VRTX, for example, has been certified under the RTCA/DO-178B Level A standards for mission-critical aerospace systems. For their part, desktop-derived embedded OSs generally address reliability needs by relying on the presence of an MMU to isolate faults and permit graceful recovery where possible. Most embedded OSs today, both real-time and desktop-derived, support JVM as an additional means of achieving fault prevention and isolation.
Clearly, the growing number and diversity of embedded applications will continue to drive the evolution and introduction of embedded OSs targeted at specific sets of requirements and tradeoffs. In the communications domain, this is especially true. New communications equipment is being introduced rapidly to enable and exploit emerging technologies and services. To best capitalize on the increasing breadth of OS options, it's becoming ever more important to identify up front the optimal tradeoffs between time-to-market, functionality, cost, performance, and reliability for a given application. By doing so, you'll be able to select the most appropriate OS for your needs.
Picking the right OS for a design requires careful consideration of a variety of factors. For some applications, requirements may be so at odds with each other that there's no obvious OS choice. Experience teaches, however, that some guidelines exist that can help determine the critical factors in that choice. A wireless telephone system perfectly exemplifies a system in which different operating systems are required to meet the specific demands of the various pieces of equipment that make up the system (Fig. 2).
Telephone-systems equipment may be divided into end-user or subscriber devices and infrastructure equipment. As the figure shows, there are two types of subscriber devices: a low-end, low-cost handset and a high-function, high-cost handset/palmtop device. These end-user devices, in turn, rely on infrastructure equipment to handle communication with devices like the cell-site processors and central office switches. To round out the range of applications, a piece of test equipment is included for testing and debugging the cell-site radio transmitters/receivers. The requirements for each of these devices are detailed, and a separate OS selection is recommended for each.
Simple handset: This device is meant to be produced in high volume and at as low a cost as possible to provide entry-level service for a large number of subscribers. The handset needs only a base set of features, with a simple LCD alphanumeric display. Battery life is a key competitive feature, so using a low-power CPU, as well as minimizing the memory footprint, is important. A simple, power-aware, real-time operating system (RTOS) of minimal footprint will serve the application well.
There's no requirement for complex graphics, memory protection, or other desktop-derived features. The high performance of the RTOS allows use of a slower, more power-conserving CPU. These RTOSs typically have attractive royalty costs or perhaps are sold on a one-time charge basis. This also helps keep the cost down.
Full-featured handset/palmset: On the opposite end of the feature/cost spectrum, you'll find the high-end handset. This device has very sophisticated capabilities, perhaps including e-mail and Internet access. Battery life, as well as overall cost, is largely sacrificed to support the high-end features. The user interface is graphical and requires a windowing capability.
This device will be produced in moderate volumes and will command a premium price. It's possible that multiple applications will run on the device, or that new ones will be developed by third parties. It's therefore important that some form of application protection be available. A desktop-derived OS, with graphics and the ability to run multiple, protected applications, fits the bill.
The cell-site processor must handle a complex but dedicated application. As calls are made, the cell site must track the duration of the call and coordinate the transfer of the call to an adjacent site—all in real time. It also must respond to telecommunication management activities and be compliant with the management protocols. The faster the processor, the more calls it can correctly handle.
In this case, it's useful to trade memory for performance. So a relatively large memory footprint is acceptable as long as the overall system-performance requirements are met. Support for standard networking protocols, such as TCP/IP, also must be included. A full-featured RTOS, with built-in support for networking and the ability to handle the hard real-time requirements of the application, is a good fit.
Cell-site radio test equipment: The test-equipment application will need some form of user interface, although not necessarily a multiwindowed one. The equipment may interface to high-speed hardware or be required to sample the equipment under test within guaranteed response times. For flexibility, the test equipment might be required to run different test programs. This may require some form of multiprogramming. In this case, the specific mix of user-interface real-time response and multiprogramming determines whether a desktop-derived OS or a full-featured RTOS will do.
Central-office switch: The central-office switch is composed of multiple processors. Typically, the overall system-control processor is a high-end desktop-type CPU, whereas the hardware controlling each telephone line can be a dedicated microcontroller-type processor residing on a line card.
The system controller may support an application that's 10 to 20 Mbytes of object-code size and composed of multiple application programs. To protect the overall switching function and meet the uptime requirements, the system controller needs protection between the various running applications. In fact, the underlying hardware itself may be fault-tolerant and capable of swapping boards in or out while the system is running. A protected, highly functional OS supporting fault-tolerance will best meet those demands.
The line cards, however, have dedicated applications that run on custom-made hardware dedicated to controlling the basic operation of the incoming lines. There may be real-time requirements for servicing the overall number of lines connected to each line card. Use a high-performance RTOS here.