This article is the first part of theĀ Series on AUTOSAR TutorialsĀ and carries the discussion on AUTOSAR. The aim of this series is to provide easy and practical examples that anyone can understand. In this article, we will see an AUTOSAR Introduction.
Table of Contents
AUTOSAR Introduction
What is AUTOSAR?
In the Automotive industry day by day, the complexity of the design of the vehicle is increasing due to the usage of plenty of ECUs. Each ECUs includes several functions that need to be written from scratch if we are going to change the hardware in the future. So it is very important to make the application software independent regardless of the hardware. To achieve the hardware-independent application fundamental functions are executed in AUTOSAR which is intended for automotive ECUs.
AUTOSAR stands for AUTomotive Open System ARchitecture. It is a layered architecture that was founded by automotive OEMs like Continental Automotive, BMW, Toyota, Ford, Volkswagen, PSA groups, and General Motors and 58 premium members like Elektrobit, HCL, Nissan, KPIT, Aptiv, and the year 2003, in order to standardize the functionality of the automotive embedded software. The goal of AUTOSAR is to standardize the functionality of automotive-embedded software.
There are two types of AUTOSAR are available,
- Classic AUTOSAR
Classic AUTOSAR in the automotive industry refers to the established standard that governs the design and development of software architecture in vehicles. It provides a framework for the implementation of functionalities, such as communication protocols, diagnostic services, and hardware abstraction, allowing for seamless integration of various electronic control units. The classic AUTOSAR approach ensures interoperability, scalability, and reusability in the complex automotive software ecosystem.
Classic AUTOSAR contains all kinds of modules that are needed for the general application. The current version of Classic AUTOSAR is 4.4.0.
- Adaptive AUTOSAR
Adaptive AUTOSAR is a technology used in the automotive industry. It is a flexible and scalable software architecture that enables the development of advanced and adaptable automotive systems. With Adaptive AUTOSAR, manufacturers can create vehicles with intelligent features and functionalities that can be updated and customized over time. It helps optimize performance, enhance cybersecurity, and enable seamless integration with various hardware and software components. This technology plays a crucial role in building the next generation of smart and connected vehicles.
Adaptive AUTOSAR can be configured based on the requirement of the application it is adapted and removes unwanted modules for the application. The current version of Adaptive AUTOSAR is 19.03.
The below image shows the difference between how the software and hardware are tightly coupled before AUTOSAR and After the introduction of AUTOSAR.
Objectives of AUTOSAR
The objectives of AUTOSAR are to standardize the software architecture of automotive electronics systems, improve software integration across different vehicle domains, promote the reusability of software components, enhance system reliability and safety, and enable the development of complex and innovative features in a cost-effective manner.
- Serviceability ā AUTOSAR provides service throughout the lifetime of the vehicle such as software updates and upgrades.Ā
- Abstraction ā AUTOSAR separates software and hardware for making development more flexible.Ā
- Configuration ā It shifts development activities from implementation to configuration.
- Software Quality ā It improves software quality by standardizing BSW (Basic Software).
- Reusability ā It provides software function reusability over the different vehicles and OEMs.
AUTOSAR Software Architecture ā AUTOSAR Introduction
As discussed, earlier AUTOSAR is a Layered architecture, and the AUTOSAR SW abstracts the hardware and the software of the ECU. There are 3 major layers in AUTOSAR, they are,
Application Layer
This layer is the topmost layer in AUTOSAR Architecture, and it includes various application-specific software components (SWC) which are designed to execute a specific set of tasks. Software components (SWC) are nothing but small pieces of code. Those small pieces of code are called as runnable, and it contains basic C code for specific functionality.
The application layer has 3 parts. They are,
- Application Software Component
- Ports
- Port interfaces
You can check this article to understand the Application Layer in AUTOSAR.
Run-Time Environment (RTE)
RTE is the middle layer in AUTOSAR Architecture, and this layer is between the Application layer and the Basic software layer. Generally, it acts as an abstract layer between application software and hardware. It provides a communication channel to communicate between two SWCs within the ECU and to communicate with other ECU SWCs with the help of ports and port interfaces.
Basic Software Layer(BSW)
Service Layer
This layer provides below services,
- Memory serviceā It gives access to internal and external memory.
- Ā I/O servicesā It gives access to input-output devices like sensors and actuators.
- Crypto service- It gives access to cryptographic primitives.
- System service ā A system service are a group of modules and function that can be used by all the modules in all the layers. This service is partially dependent on ECU but ultimately dependent on the microcontroller.
- Communication serviceā It provides the communication protocols like CAN, Flex Ray, LIN, SPI, etc for onboard and off-board communication.
ECU Abstraction Layer
This layer provides ECU-related abstractions like,
- Memory hardware abstraction- This module abstracts the location of the memory device either it can be flash or on board EEPROM or external EEPROM.
- Communication hardware abstraction- This module abstracts the communication controller from the application software it is purely based on AUTOSAR software only, it may be CAN, LIN, Flex Ray, or MOST.
- Crypto hardware abstraction- This module abstracts the cryptographic functionality by abstraction information like external or internal cryptos are used.
- I/O hardware abstraction- This module abstracts the details about the microcontroller pin details and hardware layout details. It only gives the signal to the upper layer.
- Onboard device abstractionā This module abstracts from ECU-specific onboard devices. This module contains drivers for onboard devices that are not sensors, actuators, or timers, such as internal or external watchdog timers.
Complex Device Drivers (CDD)
Complex device drivers support software modules that are not defined by AUTOSAR, which means CDD is used for special kinds of functionalities. It gives support for complex sensors and actuators. CDD is used when the specific functionality is strictly bounded by timing parameters. CDD modules directly communicate with the microcontroller and the application. So code portability is not that much easy.
Microcontroller Abstraction Layer (MCAL)
MCAL layer is the lowest layer in AUTOSAR architecture. This layer contains all the microcontroller-related drivers like the microcontroller driver, communication driver, I/O driver, memory driver, communication driver, and crypto driver. This layer is unique for each microcontroller.
Microcontroller Drivers- This module contains all the drivers related to internal peripherals like watchdog, MCU driver, core test, and GPT driver.
- Memory Drivers- This module contains drivers for on-chip memory devices like internal flash memory, internal EEPROM, or memory-mapped external memory devices like External EEPROM, and external flash.
- Communication Drivers- This module contains drivers for onboard devices like SPI, I2C and vehicle communication like CAN, LIN, and Flex Ray.
- I/O Drivers- This module contains drivers for PWM, Port, ADC, DIO, ICU, and OCU.
- Crypto Drivers- This module contains drivers for cryptographic primitives.
- Wireless Communication Drivers- This module contains drivers for wireless ethernet.
This layer can communicate with the microcontroller and internal peripherals directly. This layer provides microcontroller-independent value to the BSW components.
AUTOSAR Tool
To implement the Application software, tools like DaVinci developer, EB Tresos auto core, and K-SAR suite are used and to configure BSW tools like DaVinci configurator pro, EB Tresos studio are used. In this DaVinci developer and DaVinci configurator pro are vector tools. EB Tresos auto core and EB Tresos studio are proprietary tools of Elektrobit.
This concludes the AUTOSAR introduction. In the next article, we will see Application Layer in AUTOSAR.
You can also read the below tutorials.
Embedded Software Developer who is passionate about Embedded Systems.
