Manufacturing a car had never been a smooth ride for OEMs, even back in the old days when automobiles were all mechanical. But then, automotive electronics and safety systems started to control many vehicle capabilities and passenger services. With this increasing number of complex functions, in-vehicle electronics development became a daunted task.
Implementing a standard with well-defined processes such as AUTOSAR was then a real turning point in software engineering practices. So, what is AUTOSAR? What is its architecture made of? What’s the difference between the Classic and the Adaptive platforms? Why have standardization and abstraction opened the way to new challenges for engineers?
And finally, what are SodiusWillert’s AUTOSAR tools? Fasten your seatbelts, and we’ll tell you all about it in this blog article! 

Why AUTOSAR?

In the late 90s, Electronic Control Unit (ECU) software deployed by OEMs were located on different systems. Each ECU was made up of specific modules and interfaces. Indeed, software development was company-proprietary and hardware-dependent. There was no such thing as a shared architecture that could be used (and reused) by Tier 1 suppliers to develop the ECU software for car makers. 

Imagine what it must have been to deal with the recurring obsolescence of microcontrollers just before the start of production: a nightmare that brought about risky software adaptations, under high time pressure. Handling such heterogenous subsystems into interdependent vehicle network required considerable testing effort, and errors were far too common.

It’s also important to understand how a workflow, from design to implementation, started to require the intervention of more parties (software engineers, system architects, testers, developers, etc.) Therefore, a greater amount of data was (and this is still the case) permanently exchanged between all these stakeholders, at every step of the project lifecycle. Managing workflow, dealing with the unexpected, and finding one’s way around a huge influx of data were new and major challenges for the industry.

And that’s just a brief insight into the daily routine back then. Ask your colleagues who experienced that pivotal moment, they surely have plenty of stories to tell. Facing this never-ending complexity, rigorous formalization of and standardized processes for software were then more than expected. So, in 2003, companies from automotive electronics, car manufacturers, semiconductor, and software industries, set up a consortium known as the AUTomotive Open System ARchitecture (AUTOSAR). Leading industry players such as BMW, Bosch, Continental, PSA, Mercedes-Benz, Toyota, and many others were among the founding members of AUTOSAR. Over the years, other major companies became part of the AUTOSAR community, including SodiusWillert being a premier member!.

---

Defining AUTOSAR

AUTOSAR is an open and standardized architecture framework for automotive electronics. It stands as a unique and powerful means to manage ever more complex E/E in-vehicle environments. AUTOSAR also leverages and values the quality, and efficiency of automotive systems. 

It enables the setting of a common ECU software architecture by supporting standardized interfaces between application software and basic vehicular functions. This common “playbook” allows certain aspects of development including reusability and transferability. 

As you can see, the long-awaited standardization is now the cornerstone of this solution. Is AUTOSAR a solution? Not really! It’s first and foremost a standard. It can also be considered as a series of skills and expertise allowing the development of tools compatible with the existing development ecosystem. We can also call it a methodology, a language or a partnership of leading Automotive companies. All this serves one purpose: developing standardized automotive software applications.