The business and technology benefits of embedded Linux offers compelling incentives for designers of next generation telematics equipment. Until recently, embedded Linux technology lacked the determinism, boot-time performance, and power management capabilities to be viable for the telematics market. Today, automotive-grade Linux is a requirement for the automotive electronics of the future.
Telematics is an umbrella term that's come to represent a wide number of vehicle and driver information systems and services. Automated emergency call and location flagging—the so-called e911 service—is one key element, but following close behind are remote vehicle-security and -tracking systems, route guidance, real-time traffic information, dedicated mobile messaging, and a host of concierge services including automated hotel and restaurant reservations, booking and payment for parking spaces, and more. In the near future drivers can expect on-demand audio and video downloads (of the kind available to personal computers and cellular phones) to be offered. Furthermore, auto makers are increasingly interested to move into remote diagnostic and repair services in a bid to improve both vehicle reliability and bottom-line profitability.
Currently, telematics services operate via a dedicated in-vehicle piece of hardware, known generically as the “black box.” The black box typically combines a global positioning system (GPS) receiver with hard-wired antenna, a central microprocessor, and a telecoms board geared to the prevailing external cellular infrastructure.
Many technologies are now evolving that will require later-generation GPS receivers and communications boards, to allow for upcoming developments in satellite location (Europe will get its own satellite network in 2009) and in telecoms (updates to a third generation, or 3G, of the cellular network are already occurring, and wider adoption of 802.11 “Wi-Fi” and satellite communications are on the way). All these improvements means that under the present model complete black box changes or updates will be commonplace.
The issue of local market predilections is increasingly important as North American drivers have begun subscribing to national satellite radio systems, while Europeans favor Digital Audio Broadcast (DAB) systems. Both these broadcast systems, although each with totally different features, still need to be integrated with other elements of the driver information system that forms the primary interface with the telematics system.
Because such changes imply a heavy cost, a widespread move toward embedding the various elements into the core vehicle electrical architecture is perceived as a far more effective solution, as individual components can be quickly substituted, rather than replacing a composite cluster of components.
These regional requirements and the rapid technical evolution of telematics services places a substantial load on the shoulders of systems designers and integrators, not least because single-sourcing for in-vehicle hardware systems is almost unknown. A typical scenario is Jaguar's driver information system, which combines a touch screen by Mitsubishi with a Motorola hands-free telephone system integrated with Gentex rear-view mirror”mounted microphone, Clarion navigation, Visteon voice activation, Harman-Kardon audio, and more. Systems designers have thus far integrated these disparate products on a model-by-model basis, which is an acceptable development practice as long as complex systems remain within the realm of high-end vehicles where big development budgets and low build numbers permit such an approach.
As telematics technology cascades down to lower-margin, higher-volume vehicles, however, the watershed point is reached when these designers can use a common hardware and software platform, speeding integration and creating architectures for rapid deployment. The future of in-vehicle systems relies on a platform on which hardware and software from the most suitable sources can be built up at minimum development cost to provide maximum benefit to the drivers who purchase their products.
In addition to the basic business logic of economies of scale and flexibility of design for these platforms, add the stringent safety requirements laid down in national and international regulations. Using the underlying platform approach permits faster test turns and the modular building blocks that are key to reuse. Logically, applications that use a common operating platform (a combination of hardware and base software) at all levels will be the most effective.
Delphi, one of the world's biggest automotive electrical subassembly suppliers, declared several years ago that it was in favor of a common, open computing platform. This followed Delphi's 2000 declaration that it was joining forces with Ericsson, the Swedish telecoms business, to develop a range of what it describes as “plug and play” telematics and driver-information services. The model publicized by Delphi in media advisories at the time was indicative of the peculiar system requirements for in-vehicle telematics and multimedia systems. The modular system was based on an open platform and requires hardware picked and mixed from a range of elements:
- Microprocessor and companion IC, 200 to 500MIPS
- Memory: 128MB SDRAM and 128MB flash
- Electromagnetic Compatibility (EMC)
- Algorithm-processing capability
- Display capability (quarter-VGA to VGA+)
- Computer-generated graphics
- ATAPI for CD-ROM and DVD
- MPEG interface
- Power-down modes I2C, I2S, RS-232, IrDA, CAN, J1708, MML, PCMCIA, PCI, USB, AC97, SPI, and others
Add to this list a range of software functions including Java compatibility, a POSIX-compliant RTOS, navigation, speech or voice processing, video processing, and communications with in-vehicle data buses. To ensure vehicle systems capability and optimization of power consumption and dissipation, each module can be powered on and off under software control. The system has been designed to be fully scalable to provide the required level of determinism; the varying feature levels range by range or model by model can thus be accommodated without customizing the core platform. Delphi states, “the POSIX requirement is very key to the overall design strategy of the Open Computing Platform.”1 Reviewing the published requirements from suppliers and OEMs alike, the theme of common technology coupled with automotive-grade requirements continues to be present.
Looking more carefully at the requirements and the cycle of innovation required to keep pace in the electronics market, open-source software is a natural choice for automakers. The critical characteristics of scalable architecture and quick technology transfer create an opportunity for broad adoption of Linux as a platform operating system.
Linux provides the requisite foundation on which open-source, scalable in-vehicle architectures can be built. The inherent stability of Linux as an operating system will be underpinning all developments. The move into a process-based development method requires a number of further benefits extant within the Linux platform. Linux must be able to accommodate the driver expectation of a fast boot from reset and fast reaction to in-vehicle information from the CAN, serial, or MOST buses. Due to its process model, Linux is capable of dealing with local faults without causing a wholesale system crash, and of recovering from those faults cleanly. Thanks to its widespread availability there is no bar on the development of compatible hardware and software from external sources, meaning both systems integration and cost control become predictable when compared to other development models. Linux is an enabler to the favored open standard operating systems. Most notable among these is POSIX, the Portable Operating System Interface developed by the IEEE and which is currently issued in a second-tier form IEEE Std 1003.1, 2004 Edition.
The stability that is a key benefit of Linux is rooted in its core architecture; applications are segregated from each other and from the core Linux kernel. This process of isolation ensures that system tasks cannot be corrupted by normal users and is enforced by the hardware that normally runs the Linux operating system. This hardware, specifically the Memory Management Unit (MMUs), is readily available on many embedded processors today, and provides a virtual address range in which the kernel can reside. This virtual address range is mapped onto physical memory and the virtual address range is monitored by the MMU to ensure that accesses into and out of the range is correctly handled. When an access is out of range, an exception is sent to the operating system and is handled—thereby preventing user code to corrupt other areas of physical memory. The Linux operating system also uses the MMU to segment the user processes from each other, and in fact using services available to the user, can even provide a segmented device driver—making it easy to update at run-time and keeping critical device drivers from corrupting other system and application services. This means that system tasks are isolated from user tasks, rendering the former immune to the problems of the latter. It's also possible that they can be configured in such a way that they self repair and reboot automatically. Car drivers expect consistent reliability; open-source hardware and software offers the greatest likelihood of providing this level of service.
The footprint of the Linux kernel is much larger than that of a typical RTOS; it typically requires 600KB to 1.2MB, but within that range Linux can be customized to provide a wide array of services and capabilities, making it an excellent choice for telematics applications. Accompanying the broad kernel services are components such as communications stacks and GUIs—a display screen is almost invariably used as the centerpiece of the driver interface—that can require anything from one to several megabytes of memory. Linux's modular architecture, combined with embedded-specific utilities such as BusyBox (an embedded application toolkit combining many of the standard Unix utilities into one executable) ensure a “best fit” capability, while ensuring that system micromanagement costs remain manageable. Given that vehicles in different size classes will likely have varying levels of original equipment and retrofit hardware, such core flexibility is essential to automakers.
Figure 1: Automotive-grade Linux
Another key aspect of Linux, and one that makes it ideal for telematics and driver interface applications, is its ability to load device drivers on demand. This is especially useful when, for example, a CD-ROM, DVD, or hard drive is built into a vehicle but is used only sporadically. When that piece of hardware is required the device driver will be loaded in a few milliseconds and will automatically be unloaded again when that device is no longer needed by the system.
The on-demand capability ensures optimum operating speeds from the Linux platform at all times. A Linux system already has good real-time response for a broad range of products, but it can be further tuned to suit applications within the telematics and driver-interface arena. These optimizations are typically focused on maximizing the performance of the underlying hardware for the Linux OS and they center on two similar capabilities: a preemptive kernel capability and a low-latency patch. These can be used either separately or in combination. (Note: Patches are a common method for updates and modifications to be applied to the Linux kernel.) The added modifications to the boot loader provide the fast boot-up and rapid system-feature load and unload that most automotive software engineers expect. In addition to decreasing the response time of the Linux operating system to normal operating conditions, recently introduced technology now permits using the Linux operating system in environments requiring communications bus response times of under 60ms and overall boot requirements in the range of hundreds of milliseconds.
Linux also provides a means of solving another conundrum facing auto makers: that of power conservation. With the electrical/electronic content of cars expected to reach as much as 40% of the value of vehicles within the near future2 the expectation was that moving to a 42V system would be inevitable because it would provide the anticipated 8kW/h of power, considerably more than the existing 2 to 3kW/h provided by today's standard 12V (really 14.2V) battery systems. Considerable resistance was mustered, not least by manufacturers of vehicle subsystems (primarily lighting, batteries, instrumentation, and driver-information systems) that had made considerable investment in the existing 14.2V architecture. This unexpected resistance forced automakers to reconsider their 42V position. What is now emerging is an ability to stay within the power-generation confines of today's 14.2V systems, often by moving to a model of operation that allows electronic management systems to drop into a totally passive mode, switching back on instantly when they are required and then returning to a dormant state. This, paired with a move toward processor sharing, can be enough to maintain absolute efficiency in terms of both power consumption and systems operation. But without an open, stable, deterministic core operating system this will prove impossible to achieve, particularly in the harsh environment of an automobile.
The technical merits of Linux are part of its strength when using it as a basis for the overall platform. In addition, the broad community of developers contributing to the overall code base moves the technology forward quickly. Due to the licensing model, there are many sources for technical support and on-going development.
In fact, many semiconductor and board manufacturers are investing heavily in Linux technology for silicon validation and reference platform technology enhancements. While these merits are strong, there are also perceived limitations due to the licensing model of the kernel and drivers.
These perceptions hamper automakers' widespread adoption of open-source systems because they fear they may fall foul of intellectual property rights—either their own or another developer's. However, for applications created to run on the Linux operating system there's little ambiguity between what is and isn't “protectable” intellectual property.
There's also a concern that too few major systems providers and integrators are able to provide technology road maps that lay out the time scale and direction of future developments. As vendors provide a reliable, and dependable operating platform—the Linux operating system—with the technical capabilities required by the automotive market, the customers and market will demand and create solutions to those concerns. Most issues will be addressed with a combination of automotive-grade software development processes and procedures, clear understanding of the architecture requirements for inclusion of application code into the overall system, and the continued supply chain management of the key silicon and hardware vendors in the space.
Not if but when
Linux in this market continues to follow the standard automotive technology adoption curve. It's not a matter of if, but when, it will be broadly adopted. Market pressures continue to mount as semiconductor manufacturers are increasingly using Linux for presilicon evaluation and performance testing. Couple this process with the progression of the silicon designers' increasing understating of the importance of software architecture on the salability of their chips, and their burgeoning deployment of optimized Linux chip- and board-support packages to showcase the key features of their devices, and the confluence of market and technical conditions continue to point toward the success of Linux in this space. A move over to open-source provision of components is an ever-increasing imperative.
Automotive-grade Linux is the key to that change, and the component and software providers also have their part to play, by ensuring that a road map of developments is made available to auto makers, allowing them to move forward in their mutual desire to develop an industry-standard hardware and software platform.
Michael O'Donnell is manager of Core Technologies Marketing for Metrowerks Corporation. You can reach him at .
- Delphi Media Advisories passim.
- Foy D (2004) Global market review of interior electronics market Gloucester: Aroq.