Message-passing microkernel RTOS fits open source Web

Message-passing microkernel RTOS fits open source Web
Almost every embedded project forms part of a larger end-to-end system that may encompass everything from wireless access devices to back-end servers to operator workstations — all connected into a distributed, and ideally seamless, whole.

Not surprisingly, this paradigm shift has massive implications for how embedded projects are designed and managed, and even for how they are funded. Until recently, the bulk of investment has been directed toward building the device itself. But now, it's also focused on the services delivered through the device.

This trend cuts across market boundaries. For instance, the in-vehicle telematics market, though still in its infancy, is already moving toward a distributed model that integrates multiple subsystems. The components, including back-seat media systems, Bluetooth-based cell phones, infotainment radios, navigation systems, and safety/service interfaces, must not only communicate with each other, but share each other's resources. A similar need for integration exists within high-end network elements, which comprise a number of embedded systems interoperating within a single box.

This "connectedness" adds enormously to the complexity of both developing and maintaining a project. For instance, consider a relatively simple net-centric application: An intranet server feeding multimedia content to a retail kiosk, in which the server runs an operating system such as Linux and the kiosk runs an real-time OS (RTOS) such as QNX. For this, the project team may need tools to configure and maintain the server, format HTML and XML content, create Java applications, customize the kiosk's C++ browser, and create custom C drivers for the kiosk's RTOS.

These tools need to be integrated with specialized tools for the end-to-end middleware, debugging, and code measurement tools that apply to each target environment. Often, some of the tools are available on one development host, some on another. Clearly, development teams need to consider the net-centric framework in which the tools are used. Many organizations depend on manual or "batch/make" file techniques for integrating the broad range of tools with which they must deal. This requires a lot of understanding, labor, and constant maintenance. Most of the time, the command-line interfaces exposed by this level of tooling proves inconvenient or inadequate to the task. With the advent of projects that incorporate server, middleware, infrastructure, and embedded elements created by different organizations and subcontractors, the situation rapidly gets out of control. Eclipse.org was recently formed to establish an open-source project and community focused on creating integrated, interoperable tools. These tools are designed to improve the automation of tasks that all developers must perform to create, maintain, and deploy projects.

Conceived as a pure object-oriented framework that supports extendable plug-ins, the Eclipse platform supplies most of the elements needed to adapt existing tools or to create new ones, all in a completely integrated environment that can operate over Internet links.

This tools deployment model holds much value, not only for companies managing end-to-end projects, but also for tool and OS vendors, such as QNX. By collaborating on a common, open-source tooling environment, these vendors have more time to focus on the tools and technology in which they specialize. Nobody has to reinvent the wheel. And such a common Web services workbench can also foster the cooperative relationship needed among the multiple companies that may contribute components for an end-to-end project in such distributed environments.

For example, enterprise project developers that already use Eclipse platform-based server and workstation tools will find it easier to learn the QNX RTOS and incorporate it into their project plans, since QNX will deliver an integrated development environment (IDE) based on the same tooling platform with which they are already familiar.

But while a common tooling environment can ensure integration between tools and development teams, there is still the question of interoperability between the actual devices that make up a multinode, net-centric system.

For instance, in a cost-sensitive environment such as an in-car infotainment network, a resource — Internet connection, flash storage, or audio driver — on any given device may need to be shared by several other devices on the network. This approach, in which all devices share resources as peers, eliminates redundant hardware and enables the software on each device to be as thin as possible.

Nonetheless, the approach also places a burden on the development team to know the exact configuration of the network beforehand and then to implement remote procedure calls wherever needed. Aside from requiring additional development effort, these calls can also consume additional compute time and resources. And they pose a problem for applications that require predictable response times, since they provide no guarantee that requests going to and from the multiple devices will be processed in priority order.

A microkernel-based message-passing RTOS helps address this problem by blurring the distinction between local and remote calls. For instance, if an application sends a message to a device driver, it doesn't have to know whether the driver is on the same device or on another, network-connected device. Either way, it's exactly the same message. As a result, the application can transparently access any resource on any other node. Moreover, QNX messages are handled in priority order whether they are local or network-remote, allowing applications to respond predictably even if they depend on resources distributed across several nodes.

Any or all of these embedded devices may also need to interact with a back-end server that uses a completely different OS, such as Unix or Linux. But if the embedded RTOS and server OS both share the same application program interfaces (APIs), then a high degree of interoperability over a network environment can still be achieved.

For instance, a microkernel RTOS can share the same Posix APIs as Unix and Linux server OSs, albeit on a smaller, real-time architecture. Consequently, popular Internet software such as Apache, Perl, and GateD can all run natively on the RTOS without code changes. This not only enables interoperability between embedded and server systems, but also gives system designers much greater choice as to where services can be deployed. The exact same protocol, for instance, could reside on the server or on an embedded system, or on both, wherever it's most appropriate.

All this has productivity advantages as well. Since systems on both sides of the server-client equation can share the same APIs and source code, programming talent on the server team can be leveraged on the embedded side as well. This, combined with the fact that both teams can use a similar Eclipse-based tooling platform and, in many cases the same tools, simplifies the creation and maintenance of the overall project.