Chip vendors facing up to AUTOSAR challenge

AUTOSAR offers advantages thanks to standardization and modularity, which open the way to higher reusability. An AUTOSAR-compliant component can be ported to another target environment without time-consuming and cost-intensive adaptation. This, in turn, reduces development and testing effort and puts the production of high-quality software on a commercially viable footing.

AUTOSAR's well-planned and continually improved modular concept is often cited as advantage by software developers. The separate components of an AUTOSAR environment communicate with each other via the virtual function bus (VFB). This communication interface is specified and can therefore be used with no problems. This applies especially also to modules from third-party manufacturers.

Figure 2: AUTOSAR reusability model

But AUTOSAR also has drawbacks. The introduction of an additional abstraction layer inevitably results in the need for higher computing power and increased memory capacity. This is nothing new. It is patently obvious that, on both counts, customized source code has the edge on standardized software.

The coming months will show whether the prospective cost savings will compensate for this disadvantage, when the first AUTOSAR-compliant systems enter series production. But current developments in the automotive market are an emphatic vote in favour of the AUTOSAR standard. Certainly all the Core Partners are planning to introduce AUTOSAR-compliant products by 2010 at the latest.

Figure 3: The NEC Microcontroller Abstraction Layer (MCAL) in the AUTOSAR system

AUTOSAR is a living and growing standard. The final version has not yet been reached and improvements are being developed all the time in the work groups.

Since the end of 2007, the AUTOSAR standard has been available as Release 3.0 where it is divided into three sections:

•Basic software (BSW) and runtime environment (RTE)

•Methodology and templates

•Function interfaces at application level

Release 3.0 contains the following changes and improvements in these sections compared with the previous Release 2.1:

BSW and RTE:

•Wake-up of ECU/network start-up

•Introduction of BSW modules:

   •CAN-SM (state manager)

   •FlexRay-SM

   •LIN-SM

•Generic network management (NM) supplemented by an NM gateway

•Improved BSW models, software specification (SWS) models and unified modelling language (UML) models

Methodology and templates:

•Template specification for description of BSW modules

•Improved meta model and associated templates

•Tuning of system templates and ECU configuration parameters Function interfaces at application level:

•Harmonization of a common master table for all application areas including data structures

•Explanatory documents for the automotive areas:

   •Body und comfort

   •Powertrain

   •Chassis

•XML (eXtensible Mark-up Language) specification for standardized function interfaces