AUTOSAR promises to give automotive electronics what it currently lacks-a plug-and-play environment where software modules work together seamlessly. Ultimately, its ability to redistribute computing power may destroy plug-and-play itself. By Kermit Whitfield, Senior Associate Editor(Automotive Design & Production)

"A real leap for electronics reliability." That's how Bob Rivard, vice president, advanced technology and product marketing, Robert Bosch, (, describes the technology partnership known as the "Automotive Open System Architecture" (AUTOSAR). AUTOSAR is an effort by OEMs and key automotive electronics suppliers to rein in the mounting costs of both software development and warranty claims resulting from the unanticipated interactions between software modules in vehicles. As electronic functions and software code have proliferated, so have glitches.

There are two reasons electronic gremlins are on the rise: (1) Each new piece of code is essentially custom-made to suit the proprietary automaker standards, and (2) there hasn't been a holistic approach to automotive electronics. The idea behind AUTOSAR is to create an open standard for fundamental software system functions that replaces proprietary standards. This creates a plug-and-play environment where software modules slot into the overall electronic architecture without unexpectedly disrupting others.

The challenge that AUTOSAR faces is how to get the benefits of standardization without commoditizing the software and eliminating the ability to make a profit from it. By defining only the most basic levels of software-low-level drivers, operating systems and interfaces between modules-AUTOSAR should avoid this problem. These are things that, according to Rivard, are "wasted resources if you have to re-invent them. The purpose is not to define every widget and part number, but to create an infrastructure that is highly flexibly and adaptive." Such an infrastructure frees supplier to concentrate on developing unique value-added functions.

The benefits of openness.

The potential benefits of this approach in terms of quality and reliability are huge. Re-using the same open code means bugs are found and fixed faster, leading to a robust software foundation that developers can use with confidence. "Implementing AUTOSAR should drastically reduce the number of recalls," says Ewald Liess, director, product account management at semiconductor maker Infineon Technologies ( Development cost and time-to-market should drop significantly, in part because AUTOSAR also introduces a common testing standard for software that simplifies the certification process. "Automakers currently invest a lot of time in adjusting and testing software from suppliers to meet their proprietary standards. With AUTOSAR they will need only one certification team and will know they can trust the software," says Liess.

The AUTOSAR initiative creates standardized open interfaces that allow developers to spend time on improving quality and reliability, instead of tweaking code to satisfy each automakers' proprietary standard, as is now the case. This approach promises to slash development time and cost and deliver software with fewer annoying bugs.


AUTOSAR proposes to eventually cover systems throughout the vehicle, but its initial impact will be felt in the body area, where most of the ECUs-remote entry systems, power windows, power seats, etc.-and balky code reside. Liess says that engine controllers probably will remain with proprietary standards for some time since supply is controlled by a handful of companies all of which have developed "good standards and reliable software."

Otherwise, the biggest gap for the new standard is multi-media. According to Liess, AUTOSAR does not currently define the optical bus interface used in automotive multimedia systems. One reason for this is that multimedia operating systems focus on human-machine interfaces that make them fundamentally different than the machine-machine communication used elsewhere in the vehicle. Plans call for multimedia eventually to be included under the AUTOSAR umbrella, but that could be a decade or more away.


AUTOSAR is the brainchild of BMW, DaimlerChrysler and Volkswagen and their suppliers, Bosch and Continental, who originally began discussing the possibility of creating an open standard for automotive electronics architecture back in 2002. Since then Siemens VDO, Toyota, Ford, Opel, and PSA Peugeot Citroen have joined the group of so-called "core partners," and every other major automaker or electronics supplier is on board at some level. And if that level of support is not enough to ensure success, add this-there is no rival standard. For more information on AUTOSAR go to


AUTOSAR standards are still being developed and modified, though an initial trial run is slated to occur in the fall of 2005. It will broadly verify if all of the plug-and-play modules are working together. By the end of 2006, the verification phase should be complete, and the new standard will be ready for ECUs bound for production vehicles. The first new vehicle to use AUTOSAR, produced by an as-yet-unnamed maker, is scheduled for a 2008 debut, but only about five of its ECUs will be designed entirely to AUTOSAR specifications. "It takes some time because you still have old legacy code that will need to be replaced," says Liess "but it will be adopted everywhere because the advantage for every car maker will be absolutely visible."

Destroying plug-and-play

One ironic aspect of AUTOSAR is that while it enables plug-and-play functionality it promises to break down the whole notion of a plug-and-play module as a distinct component. When all ECUs speak the same language and can share standardized data freely, what happens where becomes less important and the vehicle is transformed into a distributed computing platform. "If you really are operating at a vehicle level, the abstraction breaks down, and boxes are no longer barriers. Where the computation takes place becomes independent of the feature function," says Bosch's Rivard. "Ultimately, if I want to add a software feature I can put it anywhere. Why not do stability control functions in the rear taillight controller because it has excess computing power? That destroys everybody's visual model of plug-and-play modules and the traditional partitioning of systems, but it's a long-term benefit because it gets people to start cross-sharing between discrete areas."

Automotive Design & Production, autofieldguide