AUTOSAR on its way to production

The growth in the number of complex vehicle functions is making the development of automotive electronics increasingly more extensive and complicated. Customer wishes, e.g. for more variants and equipment variety in the vehicle, as well as non-functional requirements such as diagnostic capability and availability, are requiring more intensive ECU development processes. Vehicles, in particular luxury vehicles, may have more than approx. 1,000 software functions, several vehicle electrical networks and more than 70 ECUs. Due to the variety of hardware platforms used in this field, ECU software dependencies on the hardware and system configurations being used has become problematic. Each change to one of these constraints requires reprogramming or at least modification of the software.

To make the complexity of ECU software development manageable, the AUTOSAR development partnership has defined a practice-tested software architecture that serves as a foundation for developing reusable applications. This open standard for system architecture " created by automotive OEMs, suppliers and other companies in the global software, semiconductor and electronics industries " lets users avoid proprietary solutions that would result in increasingly high development cost and effort.

AUTOSAR subdivides the electronics architecture into a number of layers and modules. With the simultaneous definition of interfaces, AUTOSAR creates standards for easy exchange of software components or hardware platforms. The development partnership not only provides specifications for the base software modules. It also offers a methodology for developing applications and distributed systems. This methodology begins with a model-based description of the software applications and the distributed system, and ideally ends in an automatically generated and reproducible test. This formal approach simplifies the use of a universal tool chain.

A full three years after its start, the AUTOSAR development partnership published Release 2.1 at the beginning of 2007. A stable level was reached with this release, and it has been tested in several validation projects for its practical utility. At many businesses, the action item of "AUTOSAR evaluation" has been successfully completed. Now it is ready to be implemented in concrete production ECUs.

AUTOSAR architecture

To realize the objectives of AUTOSAR — the separation of the application software from basic modules and functions — the vehicle electronics is abstracted and subdivided into several layers (Figure 1). The connection to the actual microcontroller, i.e. the physical foundation, is represented by the Microcontroller Abstraction Layer, which maps the microcontroller's functions and periphery. It defines interfaces for memory, the I/O driver and its communication connections. In this layer, features that the microcontroller does not offer may also be emulated in software. The second layer that lies above this is the ECU Abstraction Layer. It establishes die ECU-specific hardware layout and provides drivers for the periphery external to the ECU, for example.

Fig. 1: Figure 1: AUTOSAR layer model for ECU software.

In another layer, the Services Layer, various basic services are represented such as network services, memory management, bus communication services and the operating system. This layer is already largely independent of the hardware. The RTE represents the fourth layer. This is where the actual separation of application and basic software (BSW) is made. The RTE handles integration of the application software and regulates the exchange of data between the application and the BSW. It is only at this layer that reuse of already written application software is possible, because the defined interfaces make it possible to develop the application software without special knowledge of the hardware to be used at a later time, and the software can be used for any other AUTOSAR-conformant ECUs.

Page 2: next page
Page 1 | 2 | 3