New RTOS Features Enable High-End Auto Applications

Our streets and freeways are becoming roadways for embedded networks on wheels. A modern road vehicle is a platform for fifty or more embedded processors, containing upward of a million lines of computer code. Vehicle manufacturers are looking to use off-the-shelf software wherever possible, so they can focus their internal software development efforts on automotive-specific areas where they have specialized expertise and a unique ability for creativity.

Many basic embedding-related issues are readily solved by real-time operating systems (RTOSs). A good example is the OSEK/VDX consortium of European automotive industries that have defined a standard architecture for distributed embedded control units in vehicles. OSEK/VDX-conforming RTOSs deal quite well with today's needs for automotive embedded control units in the areas of: Power train, chassis & suspension, and body electronics.

However, OSEK/VDX may fall short of the needs of future automotive applications in the areas of: High-performance power train, infotainment, and security/safety.

A number of alternative RTOSs for these high-end automotive applications are becoming available today.

RTOS Kernels
Most RTOS kernels support priority-based preemption for task scheduling. Some RTOSs also offer more sophisticated scheduling alternatives such as "deadline scheduling" or "partition scheduling." They also offer memory allocation schemes to manage large expanses of RAM memory, as well as Device I/O Supervisors to manage and structure large numbers of diverse device drivers. For example, a Device I/O Supervisor is useful in managing an array of communication device drivers such as may be found in an automotive telematics unit. Drivers could well include: CAN (Controller Area Network), LIN (Local Interconnect Network), FireWire, FlexRay, and MOST (Media-Oriented Systems Transport).

The Device I/O Supervisor provides a standard channel through which application software tasks can operate the various drivers.

The next main issue addressed in an RTOS kernel is inter-task communication and synchronization.

Indirect vs. Direct Message Passing
Most RTOSs offer some form of asynchronous message passing for inter-task communication. Asynchronous message passing is a simple and intuitive loosely coupled approach to data transfer from task to task, where a task sending a message does not wait for any information from the receiver task.

The implementation of asynchronous message passing may be done in different ways in different RTOSs. The conceptually simplest approach is called direct asynchronous message passing, in which a task can send a message directly to another task, as shown below.

Direct message passing for inter-task communication

This is a straightforward and elegant software design model. On the other hand, indirect asynchronous message passing, in which application software gets involved with message queues through which tasks send and receive their messages, shown here, is a more clumsy software design model.

Indirect message passing for inter-task communication

For highly complex applications such as automotive infotainment and safety, it is best to control software complexity by using direct message passing for inter-task communication. For these same reasons, direct message passing should be the primary communication mechanism in multi-core, distributed multi-processor and fault-tolerant automotive system designs.