Automotive platform faces roadblocks

The pursuit of different options within the Autosar automotive-software platform is leading to software incompatibilities that could undermine the standard's high-level goals, according to experts. That would be ironic, because Autosar was set up by automotive OEMs and their tier-one suppliers to control the complexity and diversity in their vehicles' software.

The main idea behind the Autosar standard, presently available in version 2.1, is to uncouple software-implemented functions from the vehicle's MCUs and electronic control unit (ECU) hardware through an intermediate and strictly defined layer. The Autosar Consortium is aiming not only to standardize critical system functions but also to create a platform that allows the integration of software from different vendors, increasing the efficiency of the overall industry.

But at the dawn of the implementation phase, the first obstacles are appearing in the developers' windshields. One major question is which version of the standard should be implemented. During the standard creation process, many participants—OEMs as well as tier-one supplier companies—lobbied to get functions included that not all consortium members were interested in. For example, the standard provides three possibilities as to when in the design process developers must commit to a specific communications strategy. The strategy that defines communications topologies and the protocols to be used by an ECU can be determined either at precompile time—with the effect that the ECU running the respective software will be communicating in a fixed way—or at link time, allowing some flexibility.

At the instigation of Swedish carmaker Volvo, the standards body included an additional "postbuild" communications behavior option, which would give the designer the highest degree of flexibility. However, Volvo seems to be the only OEM using this feature. "Things like this bloat the standard's definition at the expense of clarity," said an expert who asked for anonymity. "The consequence will be that many suppliers offer different subsets of the standard definition."

Uncertain approach
Automotive supplier Bosch GmbH presented its "shopping cart" concept for Autosar-compliant building blocks at a Euroforum congress on automotive software in Germany, but after the presentation, attendees expressed uncertainty about the approach. Responding to questions about the openness and completeness of the implementations, Walter Grote, general manager of Bosch's automotive-system integration activities, said: "We are as open as any supermarket, but it might happen that not all intended functions are available—or that someone who tries to integrate modules from different manufacturers might have to undergo a certain matching effort."

The invocation of the so-called "matching effort" could be interpreted as saying the lofty goal of software plug-and-play compatibility was always unrealistic, even for Autosar. Grote pointed out that developers will have to deal with trade-offs—the more complete the implementation, the higher the ECU resource demand, especially memory footprint and computing power.

"Tailored systems that cover only subsets can be implemented much more resource-effectively," agreed a source. "Given the extreme price pressure on automotive hardware, many suppliers will certainly choose to offer slimmed-down versions of their software, with significant differences depending on customer and application."

Indirectly, Grote agreed. "Today, the Autosar software is not yet ready for plug-and-play unless you equip your ECU very generously with resources," he said. "However, this would not be tolerated for volumes in the millions of units."

Real-time issues
The real-time behavior of Autosar software is also leading to discord. While Autosar provides a methodology for the development of real-time software, the industry has to deal with a large number of parameters. "It is a moving target," said Harald Heinecke, CEO of BMW subsidiary Car IT.

The Autosar software architecture is designed to shield the application logic from the underlying hardware.

One problem is that Autosar challenges the traditional automotive business model, under which OEMs defined and developed software modules while the tier-one suppliers provided the hardware and performed the integration. Autosar is trying to create a PC-like model, with software provided by independent third parties.

Despite all these concerns, Hans Martin Schulz, chief technology officer of consulting company Extessy AG, remained optimistic. "Presently, we see the creation of tools that cover particular aspects of Autosar. An integrated Autosar process is not yet reality. We expect the conversion to Autosar standards to take several years," he said.

Version 3.0 of Autosar, set for release late this year, is expected to solve a number of issues in version 2.1. "This refers to the ECU startup/wake-up behavior and the Autosar design methodology," said Autosar spokesman Hartmut Fennel. "In addition, release 3.0 will contain far more definitions regarding functional interfaces and components for the body, power train and chassis control segments."

Release 4.0, scheduled for 2009, will add conformance tests, safety features and more functional interfaces.

- Christoph Hammerschmidt
EE Times