Why is AUTOSAR important? What are its objectives?

Why is AUTOSAR important? What are its objectives?

This is a series of blogs on AUTOSAR, ANCIT has decided to write to decode AUTOSAR. Our objective is to make it easy for users to understand AUTOSAR and implement the standard for better productivity.
AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of car manufacturers, suppliers and other companies from the electronics, semiconductor and software industry.
With the number of Electronic Control Units (ECU) in a car increasing rapidly every year and with the number of software defined functions in a car increasing rapidly AUTOSAR has gained significance. One of the biggest problems faced by the Automotive Companies was that the software must often be rewritten from scratch when hardware is changed. AUTOSAR was primarily formed to address this challenge.
AUTOSAR was formed to solve the following purposes.

Hardware Abstraction

There are numerous micro controllers available in the market. Each micro controller has a different design based on its development and manufacturer. Software developers who do application level development in the Electronic Control Unit (ECU) were wasting considerable amount of time in understanding and configuring the micro controller. AUTOSAR provides hardware abstraction i.e., AUTOSAR provides a software module called as Microcontroller Abstraction Layer (MCAL) that makes the Basic Software (BSW) and the application layer independent of the the Microcontroller. The software developer can now focus on building the application than on worrying about configuring the micro controller

BSW standardisation

The BSW will carry out the basic functions of the ECU like communication, Memory mapping,I/O, Device drivers and System. Before AUTOSAR, Software developers of the automotive industry were putting in a lot of effort in implementation and optimising the components in line with the micro controllers they used to design the ECU. This does not provide any value to the customer. Further, the suppliers used to bill the OEM for every new change in configuration (they billed the OEM fro the application and BSW). AUTOSAR standardised the BSW system. This provides an opportunity for the software developers to now focus on customer features and functionalities, thereby increasing the competitive value. Further, with the standardisation of BSW, the software quality improved considerably as well.

Standardization of exchange formats

Before AUTOSAR every supplier to the OEM developed products in an ad-hoc mode. This created a lot a compatibility issues as OEM’s work with different suppliers for different products. AUTOSAR is working on standardising the specification of exchange formats. This allows an opportunity for seamless integration among different products from different suppliers.

Reusability of functions

across vehicle networks and across OEM boundaries. One of the biggest challenges faced by the OEM was when an OEM wanted to add a function to an existing ECU it required a lot of effort. For instance, if there was a brake ECU and the OEM decides to add a type pressure monitoring system along with the brake ECU then OEMs had to put in a lot of effort to make it happen. With the introduction of AUTOSAR this large effort when reusing functions has been reduced. Partitioning and relocation of functions has also been made possible with the introduction of AUTOSAR.

Interfaces have been standardised

The usual process of development of an individual module in Automotive electronics works like this- The developer uses tools like MATLAB or RHAPSODY and builds the smallest model. MATLAB will generate the C code. When a new feature needs to be added a small piece of hand written code will be added to create the new feature in the model. However, such small improvements in existing models was very difficult because the interfaces were not standardised before AUTOSAR. With AUTOSAR making the hardware independent of the software , model based development has been made easy as the code generated from the model will be independent of the hardware and will be more focussed only on the functional aspect. This makes life easy for the OEM as the modules can be reused and it also reduces the interface proliferations between OEMS and suppliers. Different components from different suppliers can be interchangeably used to meet the requirements of the OEM.