Design Article
Autosar rev raises questions for auto design
Christoph Hammerschmidt
11/13/2012 12:21 PM EST
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."
|
|
|
|
|
KenKrechmer
11/14/2012 3:05 PM EST
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
Sign in to Reply
ArLi
11/19/2012 3:55 AM EST
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.
Sign in to Reply