Already today these automotive control systems have grown to such an extent that they have outstripped the complexity of most avionics systems. Even Apollo 13 had less processing performance than today's high-end cars.

To enable such environment-independent reuse of building blocks for hypersystems, a midware layer called OSEK/VDX (roughly translated from German as "Open System and Interfaces for Automotive Electronics/Vehicle Distributed Executive") has been defined to interface between the underlying hardware and the application software. This layer furthermore establishes interfaces between networked modules (distributed modules). Therefore OSEK includes a basic task-management and a communication-driver library. It provides the above-mentioned standardized interfaces, but it lacks an ability to "encapsulate" modules. Therefore modules can be reused, but have to be tested and validated each time they are reused. This works against the benefits of the hierarchical system design approach.

As a result, system integration and validation eat up more and more resources and lengthen the design cycle, turning them into bottlenecks.

All major automotive system, vehicle, and semiconductor vendors focus on reducing system-integration time and test efforts. Automotive system designers ask for clean module encapsulation of hardware, midware, communication and software. This allows submodule certification and testing, and error-free usage in a variety of different hypersystems and hypersystem layers. This should significantly reduce design cycles and is seen as the main enabler for forthcoming extremely complex safety systems, known as x-by-wire, currently in development for mass production.

This approach of module encapsulation involves "composability," the property to grant features established and tested at a subsystem level when integrating the subsystem into a larger system. Composability was, and remains, one of the driving forces behind object-oriented software. It is now being extended into the realm of automotive hardware and communication. Composability is asked to provide standardized dependable and cost-effective realizations for automotive mass production.

Automotive control operating systems that comply with OSEK/VDX specifications support the integration of software modules from multiple sources (composability on the data interface level) by providing respective software interfaces. But it does not provide interfaces in the time domain (temporal composability) because addition of new or enhanced modules impact the real-time behavior (rate, timing) of previously validated software. Additional memory management through fixed partitioning of application code/data, communication bandwidth management, and processing time management is required to isolate each functional module/thread to avoid any risk of resource (memory, processing time, I/O allocation) corruption.

This can no longer be handled solely by software-for example, within an OSEK/VDX extension. Hardware and communication systems have to provide stepping stones onto which to build the hierarchy. Resources have to be deterministically allocated to a specific module. All the building blocks have to be individually testable and the interfaces protected. This approach has to build on a multilayer hardware approach with respective protection mechanism. On top of this is the multilayer software and system architecture. Each single interface is protected and tested.

So what are the stepping stones required?

First, all semiconductor devices have to provide a composable architecture. These devices provide hardware add-ons to offer a "virtual microcontroller" to each thread or task. This avoids errors or uncontrolled interactions spilling from one task into others. To provide such virtual microcontrollers, the semiconductor devices have to include:

• Stack protection to avoid noncontrolled interaction of two threads through the stack;
• Memory protection to control the memory resources allocated to a thread;
• Protected processing time scheduling to allow deterministic processing resource and rate for each thread;
• Built-in real-time self-test (Bist) to allow continuous check-ing of the hardware for specified performance;
• Hardware interrupt prioritization, scheduling and control to minimize non-deterministic resource allocation by asynchronous interrupts;
• Reconfigurable hardware to allow parallel and independent thread execution having hard real-time constraints. The power and flexibility of such units can best be compared with an FPGA, since the final hardware functionality can be configured via software;
• Hierarchical I/O layers to build up multiple layers of firewalls between protected inner circles and unprotected I/O domain;
• Hierarchical processing layers to allow decoupling of different real-time domains (for example, angle time, time).

These features have to be implemented within the microcontroller core architecture, such as Infineon's TriCore, and the microcontroller system architecture, such as Infineon's Audo architecture.

TriCore and the respective Audo architectures are examples of the latest generation microcontroller architectures providing such hardware support for composability. Each thread can run on its own stack. Dedicated hardware controls access to the stack only within user-controlled upper and lower bounds. The instruction memory and data memories are protected by so-called memory sets. These sets assign eight memory blocks to data and instruction memory. Each of these blocks has user-defined upper and lower bounds. For each block the user can assign the type of access (read, write, execute) to be enabled or disabled. With this scheme, shared memory between two threads/tasks (for example, for semaphores etc.) can be implemented as local and global memory.

TriCore supports up to four sets of memory by hardware. The active set is stored in the program-status word of the processor, therefore restored after interrupts and passed on to subroutines. An operating system in supervisor mode can either change the active set or reload the respective registers (upper and lower bound mode). These allow users to extend the number of sets as applicable for the application.

The second feature of the TriCore and Audo architecture is a completely hardware-controlled interrupt system, so low-priority interrupts cannot intrude in a non-deterministic manner on processing performance. Such performance is required to determine if, for instance, the interrupt service routine is not to be executed because the interrupt is of no value at this point of time. The Audo prioritizes 256 levels of interrupt for up to four interrupt destinations. Two destinations are implemented-the TriCore and the PCP (peripheral control processor). This hierarchical processing architecture can handle two independent real-time domains. This could be angle-based and time-based processing or hard real-time and soft real-time processing.

The next composable feature of the Audo architecture is an array of timer processing elements to allow reconfigurable computing. This reconfigurable hardware allows programming by software function directly into hardware. This means that sequential processing through a single core is no longer performed, but a mixture of parallel/sequential processing, as appropriate.

Last but not least, a hierarchical I/O layering allows, within the TriCore, decoupling and independent feedback loops between threads/tasks. Currently, Infineon is developing a second-generation chip to address this within the European-funded OMI-Brake project.

Beside the semiconductor device layer, composable designs in most cases also heavily rely on a composable communication system and protocol. In the automotive market field, several initiatives are ongoing to create a composable Class C network protocol.

TTP/C was one of the first initiatives started in the automotive realm. This protocol provides a deterministic message scheduling, but fails to provide a homogeneous seamless composable communication link.

Due to a missing standardization group/initiative, further development of TTP/C for automotive applications currently seems to be non-applicable.