Introduction To AUTOSAR Tutorial
AUTOSAR is a brand in the automotive industry and each and every person from customer to Manufacturer is talking about it. Actually what it is? Yes, it is an ECU design software architecture and it is famous in the name of AUTOSAR architecture. Autosar architecture is the most and best automotive ECU design software architecture introduced by some OEM and tier1 automotive companies to make the ECU application software independent of ECU hardware. The AUTOSAR architecture is having its own AUTOSAR documents and AUTOSAR layers t which everyone should follow to design any ECU for which basically in the automotive industry it is named as AUTOSAR layered architecture.
The more customer demand as more services, security, economy, and comfort. More increase in software complexity due to an increase in more number of ECU and more increment of software sharing and vehicle functionality. The more increase of hardware and networking for more sensors and actuators with IoT, AI, etc. implementation to fulfill customer satisfaction.
AUTOSAR (Automotive Open System Architecture) is one of the most common standardized famous software architecture used in automotive ECU’s software development. Basically, we are using it to implement the application software independent of the hardware platform. The mastering complexity of ECU architectures is one of the most challenges in the automotive industry. In order to manage growing system complexity and the increasing number of dependencies while keeping the costs feasible, the basic software and the interfaces to applications and bus systems have to be standardized in the future for more research on vehicle architecture instead of basic software by the global OEM’s.
In the content of this, leading automotive manufacturers and suppliers launched the AUTOSAR (AUTomotive Open System ARchitecture) Development Partnership in 2003 to develop the automotive industry and to give more safety to the human inside the vehicle. The objective of this co-operation was to make an open automotive industry standard for the automotive software system architecture so that all the suppliers and OEM’s will follow the same which will help to rapid development, safety, and security with having a big motto as “Cooperate On Standards, Compete On Implementation”. In short, if you are asking What is an AUTOSAR?
To overcome all these, the leading automobile companies and Tier1 suppliers have formed a partnership in 2003. This was established as an automotive industry-wide standard for automobile electronic development by 10 core of world’s biggest partners named BMW, Continental, FORD motor, Daimler Chrysler, General Motors, PSA Peugeot Citroen, Siemens VDO, Toyota, and Volkswagen, Robert BOSCH.
The AUTOSAR is now a very common and highest used automotive software architecture. Whenever it was developed, very less used in the field but later it gets very famous. So to improvise it and use it in all over the vehicle ECUs they have made another standard. So as per the naming and use conventions, it is divided into two parts, such as:
Objectives Of AUTOSAR:
- Strongly consideration of availability and safety requirements in the vehicle.
- Scalability to different vehicle and platform variants.
- Most of the redundancy activation for flexibility.
- Implementation and standardization of functionalities as a worldwide standard for the “standard core” solution.
- The integration of different functional modules from multiple suppliers.
- Increased in use of most cutting edge hardware’s.
- Transferability of functions from one ECU to another ECU in the network of ECU.
- Reuse of existing software (OEM).
- Reduced software development cost and time.
- Common interface with the development process.
- Transparency and the defined interface will enable new business models.
AUTOSAR Layered Architecture:
The main concept or object of the AUTOSAR architecture is to separate the application software from the basic software and make it independent of the hardware (standardized infrastructure). This is divided into layered software architecture as:
- Application Layer (Number of SW-C).
- RTE (Run Time Environment) Layer.
- BSW (Basic Software) Layer.
Application Layer In AUTOSAR
The top layer is the application layer that consists of software components that provide various functionalities and services in the vehicle. The two most significant types are the application software component type and the sensor actuator type.
The latter is a software representation of a hardware component (a sensor or an actuator) while the former can make use of sensor data to provide actuators with relevant input. The application layer is having consists of different vehicle sub-functionalities as known as components (SWC) which are to execute the specific set of tasks as per the requirement.
It is the development of application layer software components that the whole AUTOSAR initiative is based around and that justify its existence. The lower layers and the RTE have, in essence, the purpose of making the development of application layer software components easier and standardizing the development of said software components. Everything that uses the AUTOSAR platform is located in the application layer; this is the part of the system where the components actually do something useful in the vehicle.
Run-Time Environment (RTE) In AUTOSAR
The RTE layer is the middleware in between the Application layer and the BSW layer. Basically, it is used to manage the Inter and Intra ECU communication between the application layer and the BSW layer. The RTE is also the run time representation of the Virtual Functional Bus. The RTE Layer is basically ECU specific which communicates with the SWC – SWC using Virtual Functional Bus (VFB) without the BSW module.
The RTE is responsible for mapping the components in the application layer and the basic software layer so that they can communicate and make use of each other’s functionality. The way this is done in AUTOSAR is through the concept of ports. A port is either of type providing or requiring.
A providing port in AUTOSAR is realized as an implemented function while a requiring port is realized as a function call. The ports can be configured in one of two ways; either as a sender-receiver interface or as a client-server interface. Depending on which interface is used and how it is configured the behavior of the RTE may vary. If for instance a requiring port interface is configured as asynchronous the RTE will not block in order to call the providing port, instead, it will schedule the call at a more convenient time and continue execution.
At the design level, the RTE is abstracted to a Virtual Function Bus (VFB) through which all communication runs. This also alleviates the communication handling for application layer development. In a way, the RTE is the heart of the architecture, the glue that binds all the other components. Since the entire system is not fully known at the time when the RTE is being developed some parts of it must be generated afterward. This is done when the system is configured, i.e. when all the different components are known and their descriptions have been made. A schematic view of the connections the RTE provides is seen in the figure above.
Basic Software (BSW) In AUTOSAR
The bottom layer is the Basic Software Layer (BSW). This is the only layer that can access the Microcontroller itself. It consists of a number of modules that are used by the Application layer via the Run-time Environment (RTE). Each module has an AUTOSAR specification that specifies the module’s requirements, data types, and interfaces. The BSW standardized software layer is used to provide the services to the application component modules through the RTE to make the microcontroller hardware independent of the Manufacturer’s application software. Again this is divided into 3 categories as:
- Service Layer.
- ECU Abstraction Layer.
- MCAL Layer.
MCAL Layer In AUTOSAR
The MCAL (Microcontroller Abstraction Layer) is a lower-level software module of the BSW layer which is direct access to the internal MCU peripheral modules (All the lower-level driver software) and external devices that are mapped into the MCU memory. The MCAL module making independent of the upper-level software with the hardware (MCU). – It contains internal drivers that have access to the microcontroller and internal peripherals. The MCAL makes the higher software layers independent of the microcontroller. This means that if for some reason the microcontroller needs to be replaced, the rest of the system can be left as it is. The only changes that are needed are those modules concerning the MCAL. The modules of the MCAL are divided into four different blocks as:
- The Microcontroller drivers block consists of four drivers; the General Purpose Timer, the Watchdog Driver, the MCU driver, and the Core Test.
- The Memory Drivers block contains drivers which provide services for memory handling, such as reading from, writing to, or simply erasing memory devices. In terms of memory devices, the AUTOSAR standard supports internal and external Flash memory and internal EEPROM (Electrically Erasable Programmable Read-Only Memory).
- The Communication Drivers block contains drivers for the different methods of communication supported in AUTOSAR such as CAN FlexRay and Ethernet (in AUTOSAR 4.0).
- The I/O Drivers block contains drivers for input and output modules, such as PWM (Pulse Width Modulation) and ADC (Analog Digital Converter).
ECU Abstraction Layer In AUTOSAR
The ECU Abstraction Layer is the next upper layer of the BSW module which is responsible for any external components, and drivers that are outside of the MCU, then this module will integrate with all the internal MCU components and provides a single interface for a specific ECU to the service layer. It makes the higher software layers independent of the hardware layout of the ECU. In order to achieve the desired independence, the layer is divided into five blocks in an attempt to mimic an ECU.
I/O Hardware Abstraction Module:
The I/O Hardware Abstraction provides functionality for handling input and output to the system. This is the only block in the ECU abstraction layer that has access to the RTE directly, instead of through the system layer as is the case for the other blocks in the layer.
Communication Hardware Abstraction Module
The Communication Hardware Abstraction is a collection of interfaces for each of the communication techniques of an AUTOSAR compliant ECU. These interfaces abstract the drivers for the specific communication technique and provide the upper layers with transmission functions such as status information and send/receive- functions. Instead of having direct access to microcontroller hardware, the equivalent MCAL driver is used.
Memory Hardware Abstraction Module
The Memory Hardware Abstraction is in function a lot like the communication hardware abstraction. It provides the upper layer with the functionality required to access memory via the MCAL drivers.
Onboard Device Abstraction Module
The Onboard Device Abstraction is used for any devices that do not fit in anywhere else. Access to these devices is routed through the MCAL.
Complex Device Driver Module
Any components that are not in the AUTOSAR specification but still need to access the hardware falls into the Complex Driver Layer. It provides the possibility to add extra functionality such as device drivers; some might argue that this isn’t strictly part of the ECU abstraction layer.
AUTOSAR Service Layer
The service layer provides the different types of background services like Vehicle Network Communication, Management services, diagnostic services, Memory management, ECU state management, different mode management, etc. and the OS is also a part of this layer. It provides services such as memory and OS functionality for the other BSW modules and the application layer.
System Service Module In BSW Layer Of AUTOSAR
The System Services module contains the AUTOSAR OS (Operating System) which handles scheduling and run-time resource protection and offers reasonable real-time performance. It is the scheduling functionality in the OS that executes the upper layer software components via the tasks that they are mapped to.
Communication Service Module In BSW Layer Of AUTOSAR
Communication Services provides the necessary functionality in order to run the vehicle network communication. This is done by providing an interface to the different vehicle techniques such as CAN and FlexRay, along with network management and diagnostics. This includes reworking the message frames and omitting transport layer-specific data such as message headers and other various properties (hardware timestamps for example). This layer is responsible for communication between RTE and BSW Layer for the protocols like CAN, LIN, FlexRay, etc to handle the CAN states, LIN states, etc.
Memory Service Module In BSW Layer Of AUTOSAR
Memory Services consists of modules that are responsible for managing all non-volatile data. The purpose of the memory service block is to provide non-volatile data to upper-layer applications in a uniform and well-defined way, abstract memory from the corresponding locations and properties relevant to the application. It also provides mechanisms for saving, loading, checksum protection, and verification.
Diagnostic Communication Manager
Diagnostic Event Manager (DEM):
The DEM module provides a
Protocol Data Unit Router (PduR module):
The PduR module provides functions to transmit and receive diagnostic data. Specifically, it provides DCM with data on incoming diagnostic requests. Proper operation of the DCM module presumes that the PduR interface supports all service primitives defined for the Service Access Point (SAP) between the diagnostic application layer and the underlying transport layer.
Communication Manager (ComM):
The ComM module provides functions such that the DCM module can indicate the states “active” and “inactive” for diagnostic communication. The DCM module provides functionality to handle the communication requirements “Full-/ Silent-/ No-Communication”. Additionally, the DCM module provides the functionality to enable and disable Diagnostic Communication if requested by the ComM module.
SW-C and RTE:
The DCM module has the capability to analyze the received diagnostic request data stream and handles all functionalities related to diagnostic communication such as protocol handling and timing. Based on the analysis of the request data stream the DCM module assembles the response data stream and delegates routines or IO-Control executions to SW-Cs. If any of the data elements or functional states cannot be provided by the DCM module itself the DCM requests data or functional states from SW-Cs via port interfaces or from other BSW modules through direct function calls.
VFB: The Virtual Functional Bus
Diagnostic Event Management (DEM):
Function Inhibition Manager (FIM):
The Function Inhibition Manager (FIM) stands for the evaluation and assignment of events to the required actions for Software Components (e.g. inhibition of specific “Monitor Functions”). The DEM informs and updates the Function Inhibition Manager (FIM) upon changes of the event status in order to stop or release function entities according to assigned dependencies. An interface to the function entities is defined and supported by the “ECU State Manager”. The FIM is not part of the DEM.
