AUTOSAR (Automotive Open System Architecture) can be defined as a common platform for the whole automotive industry that is designed to enhance the scope of application for vehicle functionality without affecting the current operating model. AUTOSAR is basically an open and standard software architecture which was jointly developed by automobile manufacturers, suppliers and tool developers. In this article we will learn what is AUTOSAR and about the different layers in its architecture.
The main motto of AUTOSAR is “Cooperate on standards, compete on implementation”. This unique architecture was developed in order to establish and maintain a common standard among the manufacturers, software suppliers, and tool developers so that the outcome of the process can be delivered without the need of any alterations.
AUTOSAR – How it all began?
In 2003, The AUTOSAR partnership was formed as an alliance of OEM (Original Equipment Manufacturer) manufacturers, Tire 1 automotive suppliers, semiconductor manufacturers, software suppliers, tool suppliers, and others. They established AUTOSAR as an open industry standard for automotive software architecture by considering the different automotive E/E architecture that were present and that tie and would be formed in the future.
The 10 Core partners of AUTOSAR are BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation, and Volkswagen.
Importance of AUTOSAR
The infrastructure of AUTOSAR isn’t simple, but why is it necessary to introduce such complex infrastructure to the automotive industry? On the first hand Why do we need AUTOSAR?
As the demand for the intelligent, safer and smarter vehicle increases the competition in the automotive industry will also increase. All this intelligence and vehicle functionality can’t be implemented by a single authority.
For example, a car has airbags, GPS system, Smart integration, etc. All of these features are implemented on the different ECUs (Electronic Control Units) by different automotive industries, so all the different automotive units should able to work hand in hand to get the desired outlet.
This also helps in software development process, because until recent time the software developed for automotive industries was only focused on delivering the functionality of the system and they never cared about what are the effects it can provide to the system. It got more complicated due to a lot of functionalities over various ECUs across different vehicle networks. It became a more critical problem with the increase in non-standard development procedures. Hence, they have developed the AUTOSAR.
Different Layers of AUTOSAR Architecture
If you look into the above image you can identify that the AUTOSAR’s architecture is made of three main layers which are
- Application Layer
- Runtime Environment (RTE)
- Basic Software (BSW)
Each of these layers has its own purpose and has a specific operation to perform
Application Layer
The AUTOSAR application layer consists of various applications and specific software components that are designed to perform a specific task as per the given instructions. The application layer is the topmost layer of AUTOSAR’s software Architecture that’s why it’s critical for all the vehicle applications. The application layer comprises three of the most important components that should be taken into consideration. They are application software components, ports of these components and port interfaces.
The software components ensure the functionality of the subsystem, which involves the operations and data elements that the software requires and the resources needed by the components. And the source of the application is independent of the location of the interactive components, the type of ECUs on which the component is mapped on and the number of times the component is instantiated in a system.
Runtime Environment (RTE) Layer
The runtime environment layer creates a suitable environment for the operation of the software components (SWCs). The SWC is always dependent on the interface provided by the RTE.
It can be considered as the communication center between the ECUs that are within the network. It helps the software components to operate independently of the communication mechanisms and channels. The RTE is making this possible by mapping the communication relationships between components that are implemented in the different templates, to a specific Intra communication mechanism like call or an inter ECU communication mechanisms like a COM message.
RTE has the responsibility of managing the life cycle of the SWC, It should startup and shutdown the functions based on the needs. It also acts as a separation layer between the Application Software (ASW) and the Base Software(BSW) where the Base software had the permission to call any API function or other modules directly, but the Application software can only communicate through ports.
The RTE is generated in Two Phases
- Contract Phase: This phase is independent of the ECU and it provides the contract between the application software and the RTE that is, the API of the ASW components can be coded against.
It has resulted in an ASW component specified header that we can include in the source code. The header file consists of all the RTE API functions that can be used in the ASW and also the necessary data types and structures needed by the ASW components are declared in the Header file.
- Generation Phase: This phase will focus on generating the concrete code for a given ECU. With the ASW components and Header Files created in the contract phase and all necessary BSW code, the generated code can be compiled into an executable file for the ECU.
Basic Software (BSW)
The Basic Software layer can be defined as the standardized software that can provide services to the AUTOSAR software components and it is also used to run the functional part of the software. The Basic software includes the standardized and ECU specified components.
The Basic Software layer is further divided into 4 Major parts namely Services Layer, ECU Abstraction Layer, Microcontroller Abstraction Layer and Complex Drivers.
I. Service Layer
It is the topmost layer of the basic software layer, It provides the basic software modules to the application software and it is independent of the micro-controller and ECU hardware.
The service layer provides functions such as
- Memory Services (NVRAM Management)
- Diagnostic services (Including UDS <protocol> communication and error memory)
- Vehicle network communications and management
- ECU state management
- Operating System (OS)
This layer’s mounting is specialized for micro-controller (MCU), Parts of the ECU hardware and their applications.
II. ECU Abstraction Layer
This layer acts as an interface of the micro-controller abstraction layer which also contains some drivers of external devices. It has access to the peripherals and the devices no matter where they are located either inside or the outside of the micro-controller. It also offers the API to interface with the micro-controller.
III. Microcontroller Abstraction Layer(MCAL)
Microcontroller layer is the access route to communicate with the hardware. This layer was framed in order to avoid direct access to micro-controller registers. The micro-controller Abstraction Layer( MCAL) is a hardware layer designed to ensure the standard interface to the components of basic software. It provides micro-controller independent values for the components of the basic software and also manages the micro-controller peripherals.
The MCAL is provided with a notification mechanism so that it can support the distribution of commands, responses, and information to different process. Apart from this the MCAL can include some of the functions and devices such as Digital I/O (DIO), Analog/Digital Converter (ADC), Pulse Width (De) Modulator (PWM, PWD) , EEPROM (EEP), Flash (FLS) , Capture Compare Uni(CCU), Watchdog Timer (WDT), Serial Peripheral Interface (SPI), I2C Bus.
IV. Complex Device Driver (CDD)
This layer has special timing and functional requirement for dealing with complex sensors and actuators. The CDD is used for handling complex functions, it can’t be found in any other layers and it has the ability to access the microcontroller directly. The complex functions include injection control, Control of electrical values, Position increase detection, etc.
Objectives of AUTOSAR
AUTOSAR was created for certain reasons that are helpful for the present and which will be helpful in the future also, some of the objectives are listed below.
- Implementation and standardization of basic functions as an industry-wide “standard core” solution.
- Integrations of functional modules from different suppliers.
- Easy to maintain the process throughout the life cycle.
- The ability to scale different vehicles independent of the platform.
- Redundancy activation.
- Consideration of availability and safety requirements.
- Easy transfer of functions from one ECU to another ECUs within the network.
- Using commercial off the shelf (COTS) hardware more.
- Regular software updates and upgrades throughout the lifetime of the vehicle.
Benefits of AUTOSAR
AUTOSAR serves different benefits in different stages of the vehicle’s life cycle
OEMs: With AUROSAR you can use the same software code again and again for different OEMs. It is more flexible to adapt for different designs and also reduces the time and cost of production.
Suppliers: Suppliers can increase their efficiency of functional development and create their own business model that is suitable for them.
Tool Provider: AUTOSAR has a common interface that helps the tools provider to standardize their development process.
New Market Entrant: For the new entrants AUTOSAR acts as a transparent and defined interface that can help them understand the industry standards and also to create their own business models.
What can you expect through AUTOSAR?
AUTOSAR is designed to serve various purposes to various departments of the automotive industry. Since it is versatile and flexible you can do many things from it apart from that, some of the basic outcomes that the AUTOSAR can give you are the ability to reuse the software in it for multiple units and the software used can be exchanged whenever it is needed to, AUTOSAR acts as a standard platform for all the vehicle softwares and it has no application of its own.
It has an OS with basic functions and interface softwares and the main advantage is that the same interface can be used in all basic software. The functionalities of AUTOSAR are supplied as software components and all the components involved are hardware independent.
