Introduction to Autosar Layers

Copyright 2022, Nexteer Automotive Corporation. All rights reserved.

1 Version: 1.00 | Artifact ID: SID_002
 Agenda

• Why Autosar?
• What is Autosar?
• Autosar Layers

2
 Why Autosar?

3
 Why Autosar?
• One of the biggest problems faced by the
Automotive Companies was that the software
must often be rewritten from scratch
when hardware is changed.

• BSW Standardisation: AUTOSAR standardised the BSW system. This

provides an opportunity for the software developers to now focus on customer
features and functionalities, thereby increasing the competitive value. OEM
will prefer to pay only for Application Software but not for the BSW.

• Hardware Abstraction: AUTOSAR provides hardware abstraction i.e.,

AUTOSAR provides a software module called as Microcontroller Abstraction
Layer (MCAL) that makes the Basic Software (BSW) and the application layer
independent of the the Microcontroller. The software developer can now focus
on building the application than on worrying about configuring the micro
controller.

4
 Why Autosar?

• Reusability of functions: across vehicle networks and across OEM boundaries. One of
the biggest challenges faced by the OEM was when an OEM wanted to add a function to
an existing ECU it required a lot of effort. With the introduction of AUTOSAR this large effort
when reusing functions has been reduced. Partitioning and relocation of functions has also
been made possible with the introduction of AUTOSAR.

• Standardization of exchange formats: Before AUTOSAR every supplier to the OEM

developed products in an ad-hoc mode. This created a lot a compatibility issues as OEM’s
work with different suppliers for different products. AUTOSAR is working on standardising
the specification of exchange formats. This allows an opportunity for seamless integration
among different products from different suppliers. Interfaces has been standardised.

5
What is Autosar?
Automotive open system architecture

6
 Autosar Layers

7
 Autosar Layers

8
 Application SW

9
 Run Time Environment
Provides communication services to the application
software (AUTOSAR Software Components and/or
AUTOSAR Sensor/Actuator components).

The AUTOSAR Software Components communicate with

other components (inter and/or intra ECU) and/or services
via the RTE.

Task
Make AUTOSAR Software Components independent from
the mapping to a specific ECU.

Properties
Implementation: ECU and application specific (generated
individually for each ECU)
Upper Interface: completely ECU independent

10
 Run Time Environment
 Abstracts BSW from application
 Allows parallel SW development
 Completely auto-generated for specific ECU
 VFB realized through implementation of RTE
 Provides services to SW-Cs & to BSW to access the
data/ services
 Provides data integrity & consistency mechanisms
 Runnables are scheduled by OS
 RTE events to synchronize the application needs
 Communication with in Runnables

11
 Basic SW

12
 Services Layer
Services Layer offers:
 Operating system functionality
 Vehicle network communication and management services
 Memory services (NVRAM management)
 Diagnostic Services (including UDS communication, error memory and fault
treatment)
 ECU state management, mode management

Task
Provide basic services for applications, RTE and basic software
modules.

Properties
Implementation: mostly μC and ECU hardware independent
Upper Interface: μC and ECU hardware independent

13
 ECU Abstraction
The ECU Abstraction Layer interfaces the drivers of the
Microcontroller Abstraction Layer. It also contains drivers
for external devices.
It offers an API for access to peripherals and devices
regardless of their location (μC internal/external) and their
connection to the μC (port pins, type of interface)

Task
Make higher software layers independent of ECU hardware
layout.

Properties
Implementation: μC independent, ECU hardware
dependent
Upper Interface: μC and ECU hardware independent

14
 ECU Abstraction
I/O Hw Abstraction Com HW Abstraction Memory Hw Abstraction

15
 Microcontroller Abstraction layer
The Microcontroller Abstraction Layer is the lowest
software layer of the Basic Software.
It contains internal drivers, which are software modules
with direct access to the μC and internal peripherals.

Task
Make higher software layers independent of μC.

Properties
Implementation: μC dependent
Upper Interface: standardized and μC independent.

16
 Microcontroller Abstraction layer

17
 Complex drivers
Implements non-standardized functionality within the basic software stack.

Ex. Implementing complex sensor evaluation and actuator control with

direct access to the μC using specific interrupts and/or complex μC
peripherals (like PCP, TPU), e.g.
 Injection control
 Electric valve control
 Incremental position detection

Task:
Fulfill the special functional and timing requirements for handling complex
sensors and actuators

Properties:
Implementation: highly μC, ECU and application dependent
Upper Interface to SW-Cs: specified and implemented according to
AUTOSAR (AUTOSAR interface)
Lower interface: restricted access to Standardized Interfaces

18
 Autosar Interfaces

19
 Autosar Interfaces

20
 Q&A
Q: As per my understanding CDDs are developed for external interfaces for the peripherals as per specific
requirement. MCAL is for internal peripherals of the MCU provided by the chip manufacturers. Vivek
Sharma, Shanmuga Mayilsamy please comment.

A: Not exactly,, as beautifully explained by Vivek, if we need a fast access of datas from the bus, we can
utilize CDD option that is ready provided by the Autosar. But there are certain rules that we have to follow
while using CDD.

CDDs are not necessarily developed for external interfaces only. CDD may directly access a controller
resource. It can use the MCAL if needed resource is managed by MCAL, provided there are no specific
constraints like timing. It also helps to avoid conflicts like parallel accesses. All in, it depends on specific
requirements.

Q: What are Non Rte modules?

A:

21
 Q&A
Dem Clients are Non Rte.

There are service ports where user can access directly, Dem Get/Set fault status etc..
Os, Dem, DCM, Nvm has services ports which can be accessed directly.

Some Example of Non RTE

using in Nexteer same will get added in FDD dependencies
files under Non Rte calls .

22
 Q&A
Q: ASIL-D compliance is a challenge yet with adaptive, as per my understanding?

A: Yes, you are correct, the current adoptive standard is not addressing, I think in future they will fix all the
limitation.

Q: If CDD needs inputs system states etc from BSW, it will get this data by traversing path
RTE ->Application->RTE->BSW->RTE->Application -> RTE -> CDD ?

A: No, It will be like: APPL SWC 1 => RTE => CDD SWC 2

23
 Q&A
Q: What is the difference between Classic Autosar and Adaptive Autosar?
A:

24
 Q&A
Q: How is Classic Autosar different from Adaptive Autosar in terms of Architecture?
A:

25
 Q&A
Q: Why there is different naming used Ports and interfaces ,what is the difference ?
A: Ports are basically the channels through which the Application SW components will interact with each
other. Interfaces define what kind of information is being shared

26