Autosar rev raises questions for auto design

The upcoming Autosar version 4.11, due in the first quarter
of 2013 will include support for multicore processors and
Ethernet. In an interview with EE Times Europe, the new Autosar
spokesperson Stefan Schmerler explained what currently drives the
automotive software standard framework.

With the upcoming extensions, the Autosar consortium reacts to
the demand from automotive OEMs, said Schmerler (pictures, right) whose primary
job is general manager for electronics, electrics and
architecture at carmaker Daimler. The upcoming Autosar version
will also include more support for functional safety processes -
a matter that currently is on the mind of the industry.

Responding to critics from the automotive industry watchers
that not all OEMs are interpreting the Autosar standard in the
same way, Schmerler defended the industry.

"Yes there are different releases in place at the OEMs. But
since the start of the respective vehicle developments has
started at different points in time, it is only logic that these
developments are based on the release status that was current
when they launched their developments. And once they have
committed to a certain release, they will stay with it
throughout the design cycle", Schmerler said.

And, yes, Autosar
is a moving target, he added - "but this is the way all
standards are developed."

In order to avoid problems arising from changing release
versions, newer versions are always backwards compatible with
older ones. "Nevertheless, it would be impossible to completely
rule out incompatibilities," he said. "Otherwise we would
obstruct the possibilities for technological progress."

With regard to the two major releases currently circulating in
the industry, Schmerler said that release 3 and release 4 will
be available for a long time. Users should expect minor bug
fixes, but the long-term stability of these versions is a common
goal.

Electric driving does not generate additional requirements for
the software standard, Schmerler said. "Yes, we have identified
electromobility as a future application, but ECUs for electric
vehicles are not different in terms of software requirements",
he said, adding that today "all OEMs are working on the
development of electric vehicles."

The "question" was about incompatibilities caused by standard interpretations and Mr. Schmerler answer was about different Autosar versions - which shows more about (good) PR skills than about solution for real problems.
IMHO actual Autosar implementations/usage are at the same stage as early OLE/COM Windows applications - big mess. During design of software based on Autosar, the XML editor (for handcrafting configuration files) is one of the main tool and deep inside knowledge about Autosar intrinsic is just a must. This is something different than it was promised by Autosar.
After more than 5 years of intensive "standard" changes it is really hard to believe that Autosar have good vision what they (as a consortium) want to achieve.

Stefan Schmerler's comments reflect common thinking about standards, but not current theory.
It is possible to create standards for multi-layered programmable interfaces (e.g., APIs)that are perfectly backward compatible and do not "obstruct the possibilities for technological progress." A paper identifing how this is accomplished on interfaces for next generation networks is available at http://www.csrstds.com/pdf/exploring.pdf