Handhelds give OSes a workout
Steven Dufresne, Product Specialist, R&D, QNX Software Systems Ltd., Kanata, Ontario
The resource-constrained handheld computer presents many challenges to the systems developer. Besides attempting to deliver desktop-like functionality within limited resources, the developer must now also address Internet connectivity and interoperability with the desktop.
For reasons of cost, size and battery life, the operating system (OS) environment for a handheld computer must run much more efficiently than its counterpart on the desktop. But efficiency is only the beginning; the OS must also be highly modular. A vertical-market handheld, for example, may or may not have any of the following: mass storage, such as flash memory and PCMCIA hard disk, a large memory capacity, a high bit-rate network interface, a bar-code scanner, a phone/modem/fax interface, and handwriting or voice recognition. The handheld may also include one or more transducers for measuring temperature, pressure, voltage, pH level, light level, heart rhythm and other physical quantities.
Besides providing the modularity needed to support such a variety of features, a well-designed handheld computer OS will also allow the user to exchange PCMCIA devices while the computer is powered up. To do this, the OS must be able to mount or unmount entire OS subsystems on the fly.
Together, these features demand a great deal of flexibility on the part of the operating system. It must provide efficient, robust mechanisms for extending the OS itself. It must be dynamically scalable and its components must be dynamically restartable. And, for reasons of portability, connectivity and time-to-market, it should also allow handheld developers to leverage existing open standards.
A microkernel OS architecture, such as the one used in the Posix-certified QNX OS, provides one way to achieve this balance of efficiency, scalability, extensibility and portability. In fact, the QNX microkernel OS has already successfully addressed similar challenges in a wide range of other embedded systems.
Open systems standards that have evolved primarily from the Unix, Posix and Internet computing worlds will benefit the handheld environment in at least two major ways. First, they will allow handheld computers to rapidly adopt a wealth of existing technology. Second, they will help avoid the huge costs that typically result when multiple incompatible APIs proliferate. And, compared to APIs derived from the desktop, the Posix standards offer distinct advantages. For example, they've been created with resource-constrained environments in mind. They also provide real-time APIs that address the deterministic requirements of many vertical handheld applications.
Standards can also give handheld developers more time to innovate. For example, by adopting existing standards for common, underlying services-multitasking, networking, general file I/O and device I/O, and so on-handheld developers can spend less time reinventing what has already been developed elsewhere and more time on developing innovative technologies unique to the handheld computer. Adopting these standards will also yield greater portability, not to mention a better variety of high-quality applications and development tools.
Since programmers are already at home in desktop software environments, it would be counterproductive to create yet another programming environment for the handheld computer, except where no available technology can be modified to fit. Various aspects of desktop technology need to be considered for the palmtop computer: development environments, programming languages, operating-system APIs, GUIs and support for various I/O subsystems. Where the desktop and handheld hardware share common requirements, existing standards should be used. New technologies should be created only in areas where the requirements differ. Other advantages of open standards include:
Portable source code. Many classes of desktop applications will also be useful on handhelds. Porting something like a database engine is significantly easier if the handheld's OS API conforms to the database's original API.
Portable development staff. With an open systems API, handheld developers can tap into the large number of programmers experienced with these standards. As an added benefit, a single development effort can readily produce both a desktop and a handheld version of an application.
Native development tools. A pen-equipped workstation or PC running an open-systems OS can be a functional superset of the handheld. As a result, handheld applications can be developed natively on the workstation or PC, using mature and stable desktop tools; there's no need to resort to a less functional-and less efficient-cross-development environment.
Handheld computers, whether standalone, or network connected, can vary widely in hardware resources. But how can a single OS or user interface address everything from a tiny, ROM-based system with only the simplest of peripherals to a device with functionality rivaling a desktop computer? One answer is to adopt a microkernel approach.
The basic idea of a microkernel architecture-be it an operating system or a graphical user interface-is to extract the simplest core services from which higher-level functionality can be constructed. The resulting microkernel itself can then serve as a simple starting point for efficiently implementing complex systems.
The art of designing a microkernel centers on deciding which primitives are essential to the kernel, and which should reside outside. While difficult to quantify, the elegance of the design is important. With an appropriate design, many of the system's functional goals become clean extensions that require no "kludges" to the underlying architecture. In fact, a properly architected microkernel will allow developers to cleanly implement extensions not anticipated in the original design.
Another factor in assessing a microkernel design is determining the work the hardware must perform to carry out the requests made of it. A "good" microkernel exhibits high performance by allowing application-level requests to be serviced with very little overhead-an important consideration given the performance constraints of a typical handheld.
While open systems standards have evolved primarily from existing Unix practices, these standards don't necessarily require the existence of a Unix kernel to provide appropriate services. A good thing, since the traditional Unix monolithic kernel architecture is far too feature-rich (i.e. large) for a handheld computer. It also lacks the dynamic reconfigurability required of a handheld OS.
However, an OS with a distinct "object-like" microkernel architecture, such as the QNX OS can provide these standards, such as Posix certification, yet still offer a high degree of scalability. OS services can, in fact, be included or excluded "on the fly." To achieve this, an object-like microkernel provides most OS services via separate, optional processes. The dynamic nature of these processes allows the OS to be scaled, on demand, to accommodate a variety of peripheral and connectivity needs.
Real-time executive
The microkernel is comparable to a small real-time executive, both in terms of services provided and the real-time performance of those services. The microkernel uses 14 kernel calls to implement four basic services, such as interprocess communication (IPC via message passing), process scheduling, interrupt dispatching and network message redirection.
These IPC services are used to implement a lightweight RPC (remote procedure call); this RPC is the mechanism used to provide access to both local and network-remote services. All OS services are built upon this lightweight RPC and exhibit performance comparable or superior to their monolithic kernel equivalents.
Unlike a real-time executive, the microkernel allows user-level processes to provide additional services that can then appear to other processes as seamlessly integrated OS capabilities. As a result, the operating system can be extended in any manner desired; if an SQL server is started, for example, the OS will appear as if native SQL services formed an integral part of the OS itself. Even a highly handheld-specific information-management service-such as a content-addressable, object-store file system-can be implemented as an add-on resource manager.
The microkernel OS can be scaled by launching additional processes until the full functionality of a workstation OS is achieved, including X Window, Motif, TCP/IP, NFS, fault-tolerant distributed networking, DOS/Windows emulation, CD-ROM support, and so on. Of course, the handheld device user wouldn't elect to run all these modules; the point is that the microkernel OS poses no limits on dynamically configuring a wide range of functionality.
Taking advantage of this architecture, an OS such as QNX can also provide a robust environment by executing the individual components of the operating system (including device drivers) as separate, MMU-protected processes. Consequently, a developer can add experimental OS extensions without blending them into the kernel in an unprotected manner. If the extensions "crash and burn," they won't bring the OS down with them.
Importantly, a well-designed microkernel like QNX can maintain this robust architecture at run-time, without compromising performance. With some microkernel designs, add-on processes are folded into the kernel at run-time to boost performance-at the expense of overall system reliability and dynamic scalability.
Meanwhile, battery life is fundamental to mobile computing. Not only must the software technology have low resource requirements to minimize the hardware that would consume power (e.g. RAM, ROM or flash), but it must also implement power management. In addition, the CPU and peripherals in the handheld computer must be able to run in low-power, or power-off mode, when the system is idle.
To enable this, the entire OS architecture must be "power-management aware." A microkernel OS again provides distinct advantages in that power-management functionality can be included in the modules that handle various hardware components. This allows the kernel to remain simple, though it still plays a role in the overall power-management scheme. This approach also makes it easier to take advantage of all the power-management functionality of specific hardware.
Sans GUI standard
Although an OS applications programming interface (API) suitable for the handhelds is defined by the Posix standards, a GUI standard appropriate to the handheld doesn't exist, MS-Windows and X Window notwithstanding. Neither of these can be scaled small enough to fit a low-end handheld.
Since a microkernel approach allows an open-systems OS API to scale down to the level of the handheld, a similar approach can be used to create a scalable windowing system-the Photon microGUI. With an interface library that borrows from the widget-library concept of X (but scaled down for the handheld), it provides an API that is robust, extensible and already familiar to open-systems programmers. For additional open-systems functionality, Photon also supports a low-overhead X server that runs as an optional Photon process.
Running under the microkernel OS (the QNX OS), the microkernel-based microGUI implements only a few fundamental primitives that other processes use to construct the higher-level functionality of a windowing system. In fact, for the microkernel itself, windows do not exist. Nor can the microkernel draw anything, or manage a pen, mouse or keyboard. All these services are provided by optional cooperating processes that communicate with the microGUI microkernel. This abstraction is similar to the concept of an OS microkernel, which must rely on external processes to provide such high-level services as file systems or device I/O. The benefit is also the same-like the microkernel-based OS, the microGUI can be scaled up or down dynamically.
Since the Photon microkernel inherits the network transparency of the OS microkernel, its applications or drivers can run on any node, allowing additional graphics drivers to extend the graphical space of the microGUI to the physical displays of many networked computers.
A variety of interesting applications become possible with this capability. For example, a factory operator with a wireless-LAN handheld computer could walk up to a desktop computer and drag a window from a plant-control screen onto the handheld. The operator could then walk out onto the plant floor and use the handheld to interact with the control system.
Work-group computing, using multiple handheld computers, is also possible. For example, a group of people could simultaneously see the same application screen on their devices and cooperatively operate the application. From the application's perspective, the whole group of handheld and networked computers would look like a single, unified graphical space.
Much of the code for OS and the microGUI can be moved to ROM, leaving a relatively small amount of code in RAM. The remaining RAM in the handheld computer can be used to run transient applications, loaded either from a local file system or through the network connection. Additional applications can also be run directly from ROM, using the system RAM as a workspace.
Most handheld computers can't host the caliber of tools to which the modern software developer is accustomed. What's needed is a desktop machine equipped with appropriate tools for handheld computing application development. The QNX/Photon environment, for example, allows handheld applications to run on a desktop under either the microGUI or Unix's X Window, so that debugging and usage-testing can be done without the handheld computer.
Once the application has evolved to the point that testing on the computer itself is required, any network connection to the handheld will allow the developer to launch the application onto the mobile device. Since the full-screen symbolic debugger and other tools can continue to run on the desktop machine, the developer can debug the program as if it were still running on the desktop. A useful by-product of this development environment naturally presents itself here: a single development effort can produce an application targeted at both the handheld and the desktop system.
To demonstrate the "handheld computing readiness" of this open-systems environment, we built a feature-rich, Win CE-like environment with only four man-weeks of development effort. Running in 4 Mbits of flash, the environment includes the RTOS, the microGUI, QNX's desktop-caliber Voyager Browser-which supports HTML 3.2, frames, JavaScript and various plug-ins-an e-mail client, a text editor, a spreadsheet, an Internet dialer, a TCP/IP stack and other components.
Several factors made this project possible. First, we had already developed most of the handheld computer functionality found in other products on the market, and much more in many areas. Second, the microGUI's application builder allowed us to assemble new applications quickly by providing a rich variety of customizable widgets.
And, of course, the microkernel architecture of both the OS and the microGUI allowed us to include only those OS and GUI services the environment needed. We didn't have to spend time architecting an OS or GUI just for the handheld. In fact, most of our effort went into customizing the applications to work on a small LCD display in four-color mode. Everything else was virtually done.
Importantly, the same flexible architecture that allowed QNX to provide a Win CE-like environment in a few weeks also enables QNX to be readily used in a variety of vertical applications that provide services well beyond those of a handheld consumer product.
These include everything from medical devices that require hard real-time determinism (which QNX provides without any OS extensions) to data-collection handhelds that integrate seamlessly into a fully distributed environment. |
