Simplified block diagram of AUTOSAR architecture

What is AUTOSAR?

What is AUTOSAR?

Translate in your language

Prerequisites:

Reader reading this and using AUTOSAR must have knowledge of Embedded Systems, C programming, layered Architecture, knowledge of communication protocols like CAN, I2C, etc. AUTOSAR is advanced stage of Embedded Systems so reader is expected to have knowledge of terms given above.


AUTOSAR stands for AUTomotive Open System ARchitecture which is a layered architecture with standard specifications founded by consortium of companies like BMW Group, BOSCH,Continental,Daimler,Ford,General Motors,PSA Group,Toyota, and VOLKSWAGEN.These are the core members of the AUTOSAR partnership who founded AUTOSAR. There are different types of memberships by which a entity can contribute to AUTOSAR development those are Core members, Premium Members, Development Members. I have listed above the Core members but there are many premium members who are engaged in tool development, service providers,etc. AUTOSAR aims to standardize the software development of the ECUs used in automotive applications.

AUTOSAR has implemented a layered architecture similar to OSI model. It has different layers to handle and abstract different operations of code. AUTOSAR is used for micro controllers which targets applications mostly in automotive space which utilizes CAN, Flex Ray, Ethernet etc. Being used in applications based on micro controllers, it is developed with a view to use least memory possible as micro controllers have resource constraints.

Simplified block diagram of AUTOSAR architecture
Fig: Simplified AUTOSAR Layered Architecture

Above image is a simplified AUTOSAR layered architecture. Its called simplified because there are also deep layers in each block which are hidden as this post discusses about AUTOSAR introduction. I will brief below about layers: 

  • 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?

Listed below are the problems faced in conventional ways of writing software for ECUs:
  • 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. 


Isn’t this a limitation as AUTOSAR has all drivers and layers implemented already?

Actually its not a limitation because, in today’s fast paced world, there are strict deadlines to be met for project completion. But considering above shared problems in conventional software design, its not possible to rapidly develop software to meet demand, so AUTOSAR is useful. Although AUTOSAR seems to have everything already implemented, but we have to manually write code for functionality of SWC in a Runnable of SWC.  

What if I am using a external peripheral device which AUTOSAR don’t support?

If you are using a device which is not supported by AUTOSAR, then you can use the Complex Device Drivers SWC for it. This layer gives you direct access to MCAL layer from application and you can directly interface the device with the ECU, but you need to develop its software by your own and due to its highly hardware dependency, its not reusable or portable like SWC.

Types Of AUTOSAR:

There are two types of AUTOSAR architectures named as Classic and Adaptive. The classic have all the modules which are generally needed for a application whereas the Adaptive can be configured and adapted according to application by removing unnecessary modules. Current Classic release version is 4.4.0 and current adaptive version is 19.03
 
I guess introduction of AUTOSAR is done till now. If you have any doubts or suggestions please let me know in comments.

Like us on Facebook!

Subscribe for newsletters!