|
|
|
Dan Hildebrand
Senior Architect, R&D
QNX Software Systems Ltd.
danh@qnx.com
The huge, rapidly evolving personal computer (PC) marketplace is generating a wealth of tools and platforms that manufacturers can use to create internet applianceseverything from web browsers to highly integrated embedded processors. Nonetheless, a problem remains. The operating-system environments for the desktop PC typically impose massive disk and memory overheads, making them inappropriate for consumer-priced products. The ideal solution? A standards-based realtime operating environment specifically designed for processor- and memory-constrained runtime systems.
This paper explores how such a solution, based on the QNX
realtime OS and its Photon microGUI, makes
it possible to develop low-cost, high-performance internet appliances that can
track rapidly evolving internet services. Since PC hardware is evolving just
as fast, this paper also explores issues related to product life cycle
(configuration, scalability, obsolescence management) and discusses embedded
PC hardware that addresses the longer-term needs of appliance manufacturers.
With the widespread availability of cost-effective 32-bit microprocessors, applications formerly found only on the desktopincluding applications for accessing the Internetcan now be integrated into a variety of embedded systems and appliance-class devices. Examples of such devices include digital set-top boxes (STBs) for televisions, smart phones for the home or office, and intranet devices for industry-specific application areas, such as the point of sale. In this paper, we refer to all such internet-enabled devices as internet appliances.
Developers are already creating a variety of reference designs for internet appliances: everything from roll-your-own OS kernels running on low-cost embedded processors to desktop operating systems running on modified PC workstations, complete with MPEG hardware for live video. While these reference platforms point to where internet appliances are ultimately going, most internet connections (modems, cable companies, etc.) available to the consumer still lack the infrastructure and network bandwidth to deliver services such as "video on demand." Nonetheless, internet appliances can already access several viable information services, including the World Wide Web.
Internet services and technologies are evolving at breakneck speed. As a result, products that can't track these technologies have little chance to gain a foothold in the market. To keep up with consumer demand, both the hardware and software used in an internet appliance must be scalable, ideally through customer-applied upgrades. Furthermore, these components must be relatively cheap so that the appliance can be regularly replaced or exchanged when it inevitably becomes obsolete.
Within this turbulent marketplace, product developers are tasked with creating products that cost little, yet deliver high functionality. They also face exceptional time-to-market pressures. For example, consumer appliance manufacturers normally put significant effort into designing the product for "manufacturability," to minimize production costs. Given the inherently short life cycle of any appliance that provides internet access, this cost-reduction phase must be as brief as possible. Furthermore, the design must be able to accommodate quick updates without requiring a completeand expensiveretooling.
Fortunately, manufacturers don't have to create the technology needed to track these rapidly changing functionality requirements. Instead, they can borrow that technology from a readily available source: The desktop PC.
With its huge marketshare and thousands of vendors worldwide, the PC platform is the de facto standard across a wide spectrum of applications, offering a proven, "off the shelf" toolset. In fact, because much of the technology needed for internet appliances is actually created on and for the desktop PC, an internet appliance design that borrows from the PC will benefit from reduced engineering effortand risk.
For example, during early discussions of video-on-demand for television STBs, realtime decompression of MPEG video streams was identified as a significant performance problem, and high-speed RISC processors were routinely suggested as the solution. At the same time, the multimedia movement on the PC desktop started to generate a number of MPEG-capable video chipsets and CPU instruction-set extensions, such as MMX. Ultimately, the large demand for desktop multimediaand economies of scalecreated cost-effective dedicated silicon that addressed the MPEG performance issues, even when that silicon was paired with lower-end PC processors. The net effect: PC-derived technologies for live-video STBs.
With various desktop PC technologies available for integration into the internet appliance, other advantages of the PC architecture come into play. For example, the desktop PC provides what is arguably the richest selection of operating systems, development tools, and peripherals for the embedded systems developer. Also, because a PC-derived appliance is architecturally equivalent to the desktop PC, the PC and the software available for it become natural prototyping tools for the internet-appliance developer. And there's another, even more important benefit: With internet and multimedia technologies initially coming to life on PCs, having the internet appliance architecturally track the desktop makes it easier to migrate those hardware and software technologies to the internet appliance.
Still, there are dangers to tracking PC technologies too closely. While it's relatively easy to create a "PC compatible" embedded system by pairing an x86 processor with a PC motherboard chipset, next-generation parts make most chipsets obsolete very quickly. In fact, for competitive reasons, motherboard chipset manufacturers are driven to generate new versions about every six months! Obviously, products based on these components will require frequent redesign just to maintain manufacturability. The manufacturer must be prepared to either negotiate long-term arrangements with component manufacturers or accelerate the redesign life cycle of the appliance to match that of desktop PC hardware (a feasible option since the internet appliance marketplace may require that product life cycles be accelerated compared to other consumer electronics). Nonetheless, there are other PC hardware options more closely tuned to the needs of appliance manufacturers.
Thanks to the rapid growth of the embedded x86 industry, a number of high-integration x86 processors have become available, including the AMD ÉlanSC310/400 (www.amd.com), the Cyrix MediaGX (www.cyrix.com), the Intel386 EX (www.intel.com), and the National Semiconductor NS486SXF (www.national.com). Since these processors are specifically targeted at the embedded marketplace, their manufacturers are more willing to make them available for the long termmuch longer than for motherboard chipsets targeted at the desktop PC. Better yet, these processors integrate a variety of peripherals into the CPU, reducing the component count, and cost, of system designs.
Besides these processors, companion chips with long-term availability guarantees also exist. For example, the RadiSys R380EX chip (www.radisys.comwww.radisys.com), when paired with the Intel386 EX, provides a significant portion of the functionality required to build an embedded PC.
To give manufacturers a jump start, x86 chipmakers also offer evaluation boards and reference designs, including some targeted directly at the low-cost requirements of internet appliances. These include the AMD ÉlanSC310 reference design (www.amd.com), the Intel EXPLR2 evaluation board (www.explr2.com), and the National Semiconductor Odin web-appliance reference design (www.national.com). Manufacturers can use these platforms "as is" for product evaluation, rapid prototyping, system development, and, in some cases, limited production runs. They can also readily "cut and paste" from these designs to create their own custom hardware.
Recognizing an opportunity, many PC-clone manufacturers have also made available STB-suitable cases, power supplies, infrared wireless keyboards, wireless mice, and so on. This hardware allows an STB manufacturer to bypass many initial tooling problems and configure a system around off-the-shelf hardware, much as a PC clone vendor does today. While this approach won't likely meet the price points required of a true consumer-class product, it certainly enables a developer to get to market quickly.
So far we've discussed the applicability of PC hardware, but the lion's share of an internet appliance's functionality is expressed through software. Fortunately, this software already exists on the desktop PC. Unfortunately, the operating systems used to host that software share a prodigious appetite for RAM, disk storage, and CPU cycles. Equipping an internet appliance with sufficient resources to run a desktop OS and GUI, including an internet browser, would push the hardware complement of the internet appliance into the range of the desktop PC, missing the consumer price point entirely.
Since the internet appliance is a purpose-specific device, not a general-purpose PC, it needn't carry the software overhead of a desktop OS designed to support generic desktop applicationssuch as a resource-intensive windowing system, binary compatibility with legacy applications, and so on. Instead, the appliance can run a much smaller, purpose-built OS, specifically designed to host internet appliance applications. With the greater efficiency and reduced memory/disk requirements of this OS, hardware costs can be trimmed and that elusive sub-$300 price point achieved. For STB applications, the resulting low unit cost can be "buried" within the monthly cable-service charge, removing the need for a consumer purchase in the first place.
Besides the basic multitasking capabilities needed to run a mix of processes, an internet appliance needs to provide a web browser, an email program, possibly a news reader, and other applications expected by the consumer, such as a channel guide. To host these applications, and to make the environment easy to use, the appliance needs a GUI. Given the precise timing requirements for managing the flow of video and audio data in some applications, it also requires realtime services of the OS.
Conveniently, realtime OSs for embedded applications provide processor- and memory-efficient runtime environments suited to this application. Nonetheless, the same need to minimize engineering effort that encourages manufacturers to "borrow" from PC hardware standards should also move them in the direction of software API standards. If the API supported by the chosen OS matches the API used by the applications to be hosted on the appliance, the manufacturer can save significant development effort simply by porting those applications from the PC and other environments. Better still, a standard API enables the manufacturer to closely track the rapidly evolving technologies demanded by consumers.
For an example of the efficacy of a standards-based OS environment, consider the port of the Spyglass HTML 3.2 web browser (www.spyglass.com) to the QNX realtime OS. Just a single day was required for a "proof of concept" port of the X Windows version of Spyglass technology to QNX. Clearly, X is too resource intensive for use in an internet appliance, so the Spyglass port has since been adapted to QNX's Photon microGUI ® windowing system (described later), and runs in roughly 400K of ROM or flash and 1M of RAM. This is an excellent example of how a standards-based environment can ease the porting of a popular internet technology to an internet appliance, since Spyglass is also the web-browser technology that Microsoft based their web browser on. Developing a web browser from scratch for a proprietary OS and a minimal graphics library would have required significantly more development effortan effort that could arguably never end in an attempt to track evolving web-browsing technologies.
Given that much of the existing internet software was created on Unix systems, it follows that a Unix or POSIX API is a good choice. Also, a review of the Java runtime-engine source code reveals that it favors an essentially POSIX-compliant OS with asynchronous I/O, generic thread support, a filesystem, networking support, and a windowing system. While POSIX environments have a reputation for being resource intensive (given their historical roots in Unix), a reading of the POSIX standards shows a careful definition of interface, but not of implementation. As a result, a microkernel architecture can be used to provide a POSIX API without the architectural "weight" of the Unix kernel.
For example, the QNX/Neutrino® realtime microkernel (www.qnx.com) delivers virtually all of the basic POSIX OS services in about 32K of code. These include the core services of POSIX 1003.1a, 1003.1b (realtime), 1003.1c (threads), and 1004.1d (realtime extensions). In fact, the only kernel-class functionality the microkernel doesn't offer is the ability to create additional processes. That functionality is provided by the Neutrino Process Manager, Proc, which requires just another 32K of memory. The resulting 64K OS core delivers much of the OS functionality required of the Java runtime engine (networking, a filesystem, and a windowing system are external to the kernel).
Neutrino offers multiple levels of memory protection, from no protection to full process-to-process protection. In the no-protection model, application processes run as threads in one address space. In the process-to-process protection model, each process runs in a separate, MMU-protected address space (most embedded x86 processors have integrated MMUs). For Java applets downloaded through the web, this level of protection is unnecessary, since Java itself provides a secure runtime environment. But for components of the system not implemented in Java, memory protection maintains system reliability by providing "firewalls" between those components. The end result? An internet appliance can support both Java applets and high-performance processor-native applications, without any loss of reliability.
With the ability to adopt POSIX (and hence Unix) source code, the internet appliance manufacturer can track many emerging technologiesPC or otherwisewith minimal effort. But, of course, not all these technologies come from the Unix world; many come from the Windows world. As a result, QNX Software Systems is working with Award Software International (www.phoenix.com) on a port of the APIAccess toolkit, which allows developers to port Win32 source code to the QNX realtime OS.
To host the variety of graphical applications expected by the consumer, an internet appliance requires a windowing system. A conventional graphics library, while small enough, lacks the functionality required to host full-scale applications such as web browsers. On the other hand, a conventional desktop windowing system, which provides all the functionality needed, consumes too many resources to be cost-effective!
There is a way out of this dilemma. We've already seen how microkernel technology can help create a rich, yet memory-lean, OS environment. It can do the same for a windowing environment. For example, QNX's Photon microGUIwhich is built around a "graphical" microkernelis a scalable windowing system that can deliver the functionality of a high-end GUI in very little memory: roughly 500K as configured for an internet appliance.
To complete the functionality needed to build an internet appliance, the QNX/Photon runtime environment supports a minimal TCP/IP implementation occupying 50K and a filesystem for flash memory (or rotating disk). Both services are added in the form of processes managed by the OS microkernel. The total memory requirements for this environmentincluding OS, windowing system, networking, filesystem, HTML 3.2 web browser, email, internet news reader, and a personal information manager (scheduling, address list, etc.)add up to less than 2M of flash memory and 4M of RAM. This "2+4" memory configuration is obviously smaller than what a desktop OS requires to deliver similar functionality. But it's also significantly smaller than what a Java OS environment requires.
A demo of this software environment, which offers more functionality than the above configuration (and requires somewhat more memory), can be downloaded from www.qnx.com/iat.
Since the internet appliance can be an essentially PC-compatible platform, the developer can use a conventional desktop PC as a development and prototyping platform for the final product. The necessary peripheral hardware can be installed in the PC (e.g. a cable modem) and software development begun while the hardware team works in parallel. To more closely model the performance characteristics of the actual appliance, the developer can opt to use one of several evaluation boards provided by AMD, Intel, or National Semiconductor.
By borrowing hardware technology from the desktop PC world,
and combining it with a suitable embedded software environment, the developer
can readily derive an internet appliance design. And, as customer requirements
increase, the developer can incorporate additional technologies from the
ever-evolving PC world with a minimum of redesign. This mix of attributes
allows a PC-derived internet appliance to achieve the hallmarks of a
commercially successful consumer-electronics product: short time-to-market,
low engineering cost, minimal risk, and an ability to support the latest
features and technologies expected by consumers.
© QNX Software Systems Ltd. 1997
QNX, Neutrino, and Photon microGUI are registered trademarks of QNX Software
Systems Ltd.
All other trademarks and registered trademarks belong to their respective owners.