• Application Layer: This layer has the application code which resides in top. It can have different application blocks called as Software Components(SWCs) for each feature which the ECU needs to support according to application. For example, the functions like power window and temperature measurement will have separate SWC. This is not a norm, but it depends on the Designer. 
  
• AUTOSAR RTE: This is one of the important layers of AUTOSAR, it provides communication between different SWCs and also between ECUs. Application layer uses this layer while communicating with other layers below using ports. For more information on RTE, I request you to read this article.
• Services Layer: This layer provides different services for application to use. Services like: System Services, Memory Services, Crypto Services, Off board communication services, Communication services.
• ECU Abstraction Layer: This layer provides ECU related abstractions. It contains different abstracted layers like I/O Hardware Abstraction layer, On board device abstraction, Memory hardware Abstraction, Crypto hardware abstraction, etc. to make applications hardware independent.
• MCAL: This is Micro Controller Abstraction Layer it has drivers using which the above layers communicates with Micro controller hardware peripherals.

What Is The Need Of AUTOSAR?

• Embedded systems is a vast field having n number of semiconductor manufacturers, hardware and software platforms which can be selected based on application requirements. Due to such varieties, the development effort is tough and the portability of code is hard which further increases the development cost. 
• A automotive is a complex machine which consists of n number of small embedded systems called Electronic control Unit(ECUs) so maintenance and development of code for such controllers is not easy. Further complexity is increased if different ECUs use different MCUs for meeting cost requirements, then each ECU will have different software as hardware platforms will be different. 
• To partially standardize things, sometimes there is also a need to develop and follow custom created standard ( Custom standard means to develop a protocol for communication which is agreed by all ECUs in network ) to communicate with other ECUs. This is the conventional way of writing software which is very hard to maintain and has very less chance of code portability or reuse ability. 
• A automobile has n number of parts which are manufactured by different companies called Tier 1 companies which supplies the parts to OEMs like BMW, Volkswagen, etc. Today almost all mechanical parts are becoming intelligent by adding ECU in them to increase control and efficiency. So those ECUs also need to have a common way of communication to communicate with the ECUs of OEM for this again a custom standard needs to be implemented and maintained. 

Hence a standardized software development infrastructure was needed to solve these problems and AUTOSAR solves this very well.

AUTOSAR uses a layered architecture which has different layers dedicated to perform different operations and abstraction. The application code is fully portable as AUTOSAR is designed in such a way that the application code is written independent of the hardware so the same application code can run on different hardware platforms. AUTOSAR has a layer dedicated to support hardware functionalities called MCAL (Micro controller abstraction) layer which has drivers for accessing the underlying hardware peripherals of MCU. As AUTOSAR provides standard way of communication, ECUs can communicate with each other irrespective of ECU developer (whether OEM or Tier1) and hence there is no need to maintain custom standard of communication. ECUs utilizing AUTOSAR can communicate with each other irrespective of underlying differences in hardware. Mostly chip manufacturers provides MCAL layer of AUTOSAR, but if they don’t then the developer needs to write his own MCAL layer or outsource to companies providing such services.