When we want our car checked out, most of us have a mental image of someone in greasy overalls looking under the hood at the mechanics. The explosion of embedded intelligence now going into the next generation of vehicles conjures a very different picture of white-coated technicians remotely analyzing the vehicle even while you are driving.
This change is not a dream, but instead reflects three major trends in automotive-electronics development: the increasing number of CPUs per vehicle; the migration from 4-and 8-bit to16-and 32-bit CPUs; and the increasing complexity of embedded software.
Some idea of the scale of this trend can be seen in the global production of electronic control units (ECU), which are expected to reach 800 million in 2005 , according to Strategy Analytics with the fastest growth occurring in 32-bit applications. Europe is currently ahead of the game, with the latest luxury cars having more than 50 ECUs.
A number of factors is driving these trends. Tough legislation both in Europe and in the U.S. seeks to reduce vehicle emissions. Cleaner exhausts combined with consumer demand for reduced fuel consumption and better performance requires more sensors, more complex engine control algorithms needing more CPU power and more embedded software. To remain competitive, auto manufacturers have to offer better features such as multiple air bags, driver information systems and active suspension systems. In addition, to comply with the relentless pressure to reduce costs, auto manufacturers are replacing mechanical control systems with electromechanical systems such as brake-by-wire.
Car manufacturers have traditionally been mechanical-system integrators but are now facing the requirement to deliver large amounts of complex embedded software. This requirement is compounded by time-to-market pressures as car design cycles shorten and cost pressures increase to reduce the price of the ECUs. It should be noted that development of automotive software is already expensive because of the stringent quality requirements associated with critical safety systems and the enormous cost of car recall programs.
Traditionally, embedded automotive design has involved electronics modules, the electronic control units, implemented on 8- and 16-bit processors with relatively low code sizes.
Real-time designs have been made with handcrafted, interrupt-driven systems or simple in-house real-time operating systems (RTOSes) tightly integrated with the CPU architecture.
In-house RTOSes, if well-designed, can have the optimum performance for the application, but lack quality third-party RTOS-level tool support.
In addition, this model of software design creates two costly supplier dependencies in the production chain. First, the ECU supplier will have invested a large sum of money in an embedded software product that is very tightly integrated with the CPU architecture, making it difficult to change CPU suppliers or reuse the software in a new generation of products.
Second, the car manufacturer will have invested a lot in application software that is integrated into a proprietary layer from the ECU supplier, making the move to another supplier expensive.
For these in-house development efforts, many automotive companies use computer-aided software-engineering (CASE) tools for specification, modeling and simulation for the high-level design process. Such designing is often done in a department other than software design and then "thrown over the wall" as specification documents. This leaves a tenuous link between the high-level design and the code, making it difficult to ensure that changes in either environment are reflected in the other.
Another factor complicating the embedded automotive software problem can be attributed to the ECUs themselves. Not only are these individual ECUs becoming more powerful, but the links between them are becoming more important. For example, the driver display system needs to receive messages from any malfunctioning component within the electronics systems. As another example, it can be desirable to re-allocate computational loads-for instance, so that a security lock controller CPU can perform a function other than validating access to the vehicle.
Furthermore, as cars become complex distributed systems, car manufacturers need to ensure ECUs from multiple suppliers use the same networking and communication standards. Without a common standard, manufacturers bear the cost of enforcing a proprietary communications and networking system.
Given the complexity of the embedded automotive environment, off-the-shelf commercial operating systems fall short of meeting current demands. These RTOSes tend to be too large, have insufficient scalability, inappropriate networking technology and are not available on the required architectures. Some car manufacturers have delineated their specific software requirements and taken delivery of custom operating systems from third-party RTOS suppliers. GM PowerTrain, for example, has standardized on Wind River's WindStream operating system. However, those customized solutions are too narrow in their applications to become the standard for other automotive manufacturers.
In 1993 BMW, Bosch, Daimler-Benz, Opel, Siemens and Volkswagen formed a group aimed at solving some of those standardization problems. As a result, an RTOS, called OSEK, was created with a standard API (application programming interface). OSEK is an acronym for a German phrase meaning "open systems and their corresponding interfaces for automotive electronics." French manufacturers Renault and PSA have also joined and integrated OSEK with their standard Vehicle Distributed eXecutive (VDX).
The OSEK operating system consists of a kernel, a communications module for data exchange between ECUs and a network-management module for network configuration and monitoring.
In order to be a viable standard in the vehicle, the OSEK operating system must be applicable to a wide range of processors-from the simplest 8-bit window lifter ECU to the most complex, high-end 32-bit engine-management system. It should be noted that most vendors describe their commercial operating systems as "scalable." This means that different components of the OS can be included or excluded, such as networking stacks, but the kernel is always present and unchanged. OSEK takes the scalable concept to a new level-it allows the actual kernel structure to be optimized for each application.
The OSEK operating system is built with a tool called a configurator. The user defines the structure of the OS with an intuitive graphical interface and then allows the configurator to build the source code of the OSEK operating system. During the design cycle, the user can choose one of several scheduling policies and select from different "conformance classes" offering varying levels of functionality. For example, a choice can be made between preemptive and non-preemptive scheduling, balancing kernel size and RAM memory requirements against the real-time constraints of the system. Ultimately, a highly optimized OSEK-compliant operating system can be built for a wide variety of applications with the optimum speed, ROM and RAM footprint.
Part of the OSEK standard is the OIL (OSEK implementation language) file that describes each instance of an OSEK operating system in an ASCII file. That delivers a standard description of the structure of an RTOS. CASE tools can interrogate the specific OSEK instance and generate appropriate code or even the RTOS description and send it as an OIL file to be built in the configurator tool.
With OSEK operating-system implementations available on several CPU architectures, most of the ECU manufacturer's code can be abstracted from the underlying hardware, allowing software reuse and lowering switching costs. Additionally, the car manufacturer can use different ECU suppliers during the life of the vehicle because the application code is part of a standard OSEK API. And with a common communication and networking standard, car manufacturers can reduce cost by integrating different ECUs into one distributed system.
Although OSEK is a small operating system, the requirement to offer highly optimized operating systems with several conformance classes on multiple CPU architectures requires a major effort. Also, the ability to provide integrated OSEK tool environments is complicated by the number of RTOSes available for the different CPUs. That fragmentation in the RTOS market has been necessary to achieve the high levels of optimization required by the automotive industry. However, since OSEK is a standard and there is a growing development community, it has been possible to entice global RTOS vendors to develop and support OSEK products.
In Europe, OSEK is becoming the de facto standard and the U.S. and Japan, while in an earlier stage of adoption, are considering it.