AUTOSAR

BY
DR SAPNA P J
 AUTOSAR
Introduction
AUTOSAR stands for AUTomotive Open System ARchitecture which is a layered
architecture with standard specifications founded by consortium of companies.
Core Members are

A global development partnership of automotive manufacturers, suppliers,

and other companies.
 There are different types of memberships for AUTOSAR development those are Core
members, Premium Members, Development Members.
 Premium members are engaged in tool development, service providers ,etc.
 AUTOSAR aims to standardize the software development of the ECUs used in
automotive applications.
What is AUTOSAR?
It is a standard software architecture, tailor made for automotive applications i.e
automotive ECUs
It is an open source i.e specifications are accessible free of cost
Tagline: Co-operate on standards
Compete on Implementation
Aims to create and establish an open and standardized software
architecture for automotive electronic control units (ECUs).
 Common terminologies
1.Peripherals: Any computing device or equipment that is part of the
computer but does not perform any core computing process
For example Sensors which are meant to provide information to controller
but doesn’t have any computational intelligence to use the information
 2. Microcontroller
 It is a small computer on chip
 It contains one or more central processing unit along with memory and
programmable input/output peripherals
 3.Electronic control Unit
 It is an embedded system in automobile electronics that controls one or more
of the subsystems in a car
 It consists of Microcontroller with few peripherals like capacitors, ASICs etc
which enables the controller in its functionalities
 4. Stakeholders
 Stakeholders are individual or companies involved in building the
automobile
For example, the suppliers and OEMs who are manufacturing the automobile
by integrating the components built by suppliers, to bring automobile to life
 Why was AUTOSAR created?
To address the growing complexity of automotive software.
To ensure interoperability and compatibility across various suppliers and OEMs.

Key Facts:
Established in 2003.
Focuses on creating standardized software modules that can be reused across
different platforms and vehicles.
 We know that in a generic car there are100s of ECUs
 for example, air bag control unit, body control unit, door control unit, ABS and many
more

 These ECUS are made up of Sensors, Actuators, and Microcontrollers

 In a complex system such as car there is a need to connect these ECUs via some
communication link so that they can share the data they need.
 Microcontrollers are the brain of any ECU all the storage, computation & communication of
data happens in Microcontroller
 Controllers have specific set of internal registers, interrupts, memory and I/O
interfaces which defines the architecture
Software flashing
 EXAMPLE
Let us take an example of Automotive company X. which is working on a body control unit
project.
Lets say it they choose RL78 microcontroller for this project. They write the software
flashes it and works well. This software was designed keeping RL78 controller
architecture in mind. Lets say after some years renesas decides to increase the price of
RL78 MC. This price is too high for company X and they decide to shift to a new
controller. Let us say they choose ST Chorus which has a totally different architecture
from RL78.
but the software was dependent on the controller specifics that it can not be used for
the new controller
Hence this time company x decides to write software in two parts
BSW layer which controls the hardware and provides system functionalities
And ASW layer where the application for BCM is written
Now the software works fine in the standalone mode but when they test the software
with other modules in the car it does work due to compatibility issues
 This shows how important is a hardware and software portability

 That is a small change in architecture requires whole system to be redesigned

 This rework and lack of coordination between suppliers and OEMs gave birth
to a standard called automotive open system architecture
 Major AUTOSAR Objectives and Focus Areas
Interoperability and Scalability

 Ensures seamless integration of components from different suppliers.

 Facilitates scaling of software to different vehicle models.

Reusability and Transferability

 Promotes reusing software components across different projects, reducing development

time and cost.

Safety and Reliability

 Emphasizes building software that meets automotive safety standards (e.g., ISO 26262).
 Improves the overall reliability of automotive systems.

Future-Proofing

 Adapts to evolving automotive technologies such as autonomous driving and

electric vehicles.
 Advantages of Adopting AUTOSAR
Cost and Time Efficiency
Standardized components reduce the need for custom development, saving time and money.

Improved Quality
Rigorous testing and standardized processes lead to higher quality software.

Flexibility and Maintainability

Easier to update and maintain systems due to modular architecture.

Global Industry Adoption

Widely adopted by leading automotive companies, ensuring industry-wide compatibility.
 Application scope of AUTOSAR
AUTOSAR is dedicated for Automotive ECUs. Such ECUs have the following properties:

 Strong interaction with hardware (sensors and actuators)

 Connection to vehicle networks like CAN, LIN, FlexRay or Ethernet

 Microcontrollers (typically 16 or 32 bit) with limited resources of computing power and memory
(compared with enterprise solutions)

 Real Time System and

 Program execution from internal or external flash memory.

NOTE: In the AUTOSAR sense an ECU means one microcontroller plus peripherals and the according
software/configuration.
 AUTOSAR extensibility
The AUTOSAR Software Architecture is a generic approach:

 Standard modules can be extended in functionality

 Their configuration has to be considered in the automatic Basic SW

configuration process

 Non-standard modules can be integrated into AUTOSAR-based systems

as Complex Drivers

 Further layers cannot be added

Architecture –Overview of Software Layers

 AUTOSAR follows a three layer architecture.

 Application layer
 Real Time Environment Layer (RTE) and
 Basic SoftWare layer (BSW)
 Software which is a combination of these layers run over a microcontroller
Architecture –Overview of Software Layers
Top view

The AUTOSAR Architecture distinguishes on the highest abstraction level between three software
layers: Application, Runtime Environment and Basic Software which run on a Microcontroller.
Layered Software Architecture
 Application Layer: Contains application-specific software components.
 These are designed to execute specific set of tasks. Software components are simplest form of
application
Application is made of three parts
# Application software components
# Ports of these components
# Port interfaces

 Runtime Environment (RTE): Middleware layer between application layer and BSW.
 This enables communication between software components and BSW using ports and port interfaces.
 These ports exchanges data using RTE buffers and invoke BSW functionalities.
 Interesting fact about RTE is that the software architecture above RTE changes from layer to
component style
Basic Software (BSW):

 Provides standardized services and hardware abstraction.

Hardware abstraction refers to a layer of software that provides a
consistent interface for interacting with different hardware components,
allowing software applications to access hardware resources without needing to
know the specific details of the hardware.
This abstraction hides the complexity and variability of the underlying
hardware, providing a uniform interface to higher-level software.
 It is used to run the functional part of the software.
 BSW include standardised and ECU specific components
 Types of services
The Basic Software can be subdivided into the following types of services:
 Input/Output(I/O): Standardized access to sensors, actuators and ECU on-board peripherals
 Memory: Standardized access to internal/external memory (non volatile memory)
 Crypto: Standardized access to cryptographic primitives including internal/external hardware accelerators
 Communication: Standardized access to: vehicle network systems, ECU on-board communication systems
and ECU internal SW

 Off-board Communication: Standardized access to: Vehicle-to-X communication, in vehicle wireless

network systems, ECU off-board communication systems

 System: Provision of standardizeable (operating system, timers, error memory) and ECU specific (ECU state
management, watchdog manager) services and library functions
 Coarse view
The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction,
Microcontroller Abstraction and Complex Drivers.
 Services Layer
Topmost layer of BSW. It provides interfaces to the application which are independent of Microcontroller
and ECU hardware

The Services Layer offer:

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
Logical and temporal program flow monitoring
(Wdgmanager)
 Services Layer
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

 ECU Abstraction Layer
This layer offers uniform access to all the functionalities of ECU such as communication, memory or
IO. Regardless of whether these functionalities are part of controller Or implemented by peripheral
components

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

 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

Drivers in this layer are mainly provided by the µC

Manufacturers like Renesas and freescale
 Complex Drivers
 At last we have complex device driver layer (CDD) in BSW which is not in a horizontal space but
rather in a vertical space

 This layer has special timing and functional requirements for dealing with complex sensors and
actuators.

 CDD is used for handling complex functions that can not

be found in any other BSW layer

 It also has the ability to access the Microcontroller

directly
 Complex Drivers
The Complex Drivers Layer spans from the hardware to the RTE.

Task
Provide the possibility to integrate special purpose functionality,
e.g. drivers for devices:
which are not specified within AUTOSAR,
with very high timing constrains or
for migration purposes etc.

Properties
Implementation: might be application, µC and ECU
hardware dependent
Upper Interface: might be application, µC and ECU
hardware dependent
 Detailed view
The Basic Software Layers are further divided into functional groups. Examples of Services are
System, Memory and Communication Services.
 AUTOSAR Runtime Environment (RTE)
The RTE is a layer providing communication services to the application software (AUTOSAR Software
Components and/or AUTOSAR Sensor/Actuator components).
Above the RTE the software architecture style changes from “layered“ to “component style“.
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
 Example 1
Now let us try to understand the simple working principle behind a turn indicator ON and OFF
mechanism using AUTOSAR compatible software
Step1: software component for turn indicator request to turn ON the bulb.
Step 2:This request is routed through RTE to BSW responsible layer .
In this case it is IO hardware abstraction.
Step 3: This in turn switches on PWM signal on the
output pin where the bulb is connected
 Example 2
Door control unit wants to broadcast the status of
door via CAN to other ECUs in the car.
Step 1: First door status software component in the
application requests RTE to send a CAN signal.
Step2: This request is routed to communication layer
of BSW.
Step 3: Communication service layer routes the frame
through CAN-IF to CAN driver.
Step 4: CAN driver helps writing the CAN frame into
the hardware buffer which in turn converts it to
electrical signal which are then transmitted through
the CAN bus to other ECUs
 Driver [internal]
 A driver contains the functionality to control and access an internal or an external

device.
 Internal devices are located inside the microcontroller.
Examples for internal devices are
➢ Internal EEPROM
➢ Internal CAN controller
➢ Internal ADC

 A driver for an internal device is called internal driver and is located in the
Microcontroller Abstraction Layer.
 Driver [External]
 External devices are located on the ECU hardware outside the microcontroller.
Examples for external devices are:
➢ External EEPROM
➢ External watchdog
➢ External flash

 A driver for an external device is called external driver and is located in the ECU
Abstraction Layer.

 It accesses the external device via drivers of the Microcontroller Abstraction Layer.
 In AUTOSAR, the way drivers interact with external devices can vary depending on the
type of device and how it interfaces with the microcontroller.
Example: A driver for an external EEPROM with SPI interface accesses the external
EEPROM via the handler/driver for the SPI bus.
1. External EEPROM with SPI Interface

* An EEPROM (Electrically Erasable Programmable Read-Only Memory) is a type

of non-volatile memory used to store data that must be preserved even when power is
removed.
* When this EEPROM is accessed through an SPI (Serial Peripheral Interface) bus,
it means that data is transferred between the EEPROM and the microcontroller using the
SPI protocol, a common serial communication protocol
2. Access via SPI Handler/Driver:
 In this case, the EEPROM is not directly connected to the microcontroller but
through the SPI bus.
 To communicate with the EEPROM, the microcontroller uses an SPI driver.
 The SPI driver is responsible for managing the SPI bus, handling the
communication protocol, and transferring data between the EEPROM and
the microcontroller.
3. Layered Approach:

In a layered architecture like AUTOSAR, the driver for the EEPROM is considered
an "external driver" because it interacts with an external device.
 This driver uses the SPI handler/driver to communicate with the EEPROM, following the
principle of separating hardware-specific details (SPI communication) from the application
logic (using EEPROM).
Exception: Drivers for Memory-Mapped External Devices
1. Memory-Mapped External Devices (e.g., External Flash Memory):

 These are external devices directly mapped to the microcontroller’s address space.
 When a device is memory-mapped, the microcontroller can access it as if it were
internal memory.
 This direct access allows the microcontroller to read or write to the external device
without going through an intermediate communication protocol like SPI or I2C.
2. Direct Access:
 Since the device is directly accessible through the microcontroller’s memory
map, it does not require a separate communication handler or driver like SPI.
 The microcontroller can directly interact with the device's registers or memory,
allowing faster and more efficient access.
3. Microcontroller Abstraction Layer (MCAL):
 Drivers for these memory-mapped external devices are considered
microcontroller-dependent.
 Because the way these devices are accessed is directly tied to the
microcontroller’s hardware (e.g., its memory mapping, specific registers, etc.).
 Therefore, these drivers are typically placed in the Microcontroller Abstraction
Layer (MCAL) in AUTOSAR.

 The MCAL provides a standardized interface to the rest of the software stack,
abstracting away the details of the microcontroller’s hardware.
Drivers for SPI-Connected Devices: Use a layered approach where the device-
specific driver interacts with a bus handler (like SPI), which manages the
communication.

Drivers for Memory-Mapped Devices: Are more closely tied to the microcontroller
hardware and can access the device directly. These drivers are placed in the MCAL
due to their dependency on specific microcontroller features.
 Interface
 An interface module is a piece of software that provides a standard way to interact with

certain hardware or devices.

It acts as a middleman between the software that uses the device (like an application)
and the actual device or hardware.
What Does an Interface Module Do?

1. Abstracts Hardware Details: The interface module hides the specific details of how a device

or hardware is implemented.

This means you need not know how the device works internally or what type of hardware it
is—whether it’s built into the chip (on-chip) or a separate component (off-chip).
2. Provides a Generic API:
 An API (Application Programming Interface) is a set of functions or commands that a
programmer can use to perform tasks.
 A generic API provided by an interface module allows software to access different
types of hardware or multiple devices of the same type in a consistent way, without
worrying about the differences between them.
3. Does Not Change Data:
 The interface module simply facilitates communication between the software and the
hardware.
 It doesn't alter the data being sent or received; it just provides a way to access the data.
Where is the Interface Module Located?
 In AUTOSAR, interface modules are typically found in the ECU Abstraction Layer.
 This layer abstracts the hardware-specific details so that higher layers of software
can operate independently of the specific hardware being used.
 Example: an interface for a CAN communication system provides a generic API to
access CAN communication networks independent on the number of CAN
Controllers within an ECU and independent of the hardware realization (on
chip, off chip).
Why is This Useful?
By using an interface module:
•Simplifies Development: Programmers need not write different code for different
hardware implementations. They use the same API regardless of the hardware details.
•Increases Portability: The same software can be used on different hardware
platforms, making it easier to develop, maintain, and update the system.
 Handler
 A handler is a special type of interface in software that manages how different parts of a system

(called clients) access shared resources, like drivers or devices.

It helps to handle multiple requests to use a device or driver efficiently and without conflicts.

What Does a Handler Do?

1. Controls Access: The handler manages how different clients access a shared driver or device.

This is important when many parts of a system want to use the same resource at the same time.
2. Manages Multiple Requests: If multiple clients want to use the driver or device
simultaneously, the handler organizes these requests to avoid conflicts and ensure that
everyone gets a fair chance.
Performs Various Functions:

Buffering: Temporarily stores data when there is too much for the device or driver to
handle all at once.

Queuing: Arranges multiple requests in a line so they can be processed one by one in an
orderly fashion.
Arbitration: Decides which client’s request to handle first if multiple requests come in
at the same time.
Multiplexing: Combines multiple signals or data streams into one, allowing them to
share the same channel or connection.
3. Does Not Change Data: The handler doesn’t modify the actual content of the data
being sent or received; it only manages how and when the data is accessed.
Where is the Handler Used?

Incorporated in Drivers or Interfaces: Handler functionality is often built directly into

the drivers or interfaces themselves. (e.g. SPI Handler Driver, ADC Driver).
For example: an SPI Handler Driver manages multiple clients that want to use the SPI
bus (a communication interface), handling their requests efficiently without changing
the data being transmitted.
 Manager

 A manager is a type of software component that provides specific services to

multiple clients (parts of a system that request certain services).
 A Manager
Evaluates Data: It can check and analyze the data that is being handled to
ensure it meets certain criteria or requirements.
Changes or Adapts Data: The manager can modify the data, such as formatting
it differently, correcting errors, or updating values, to suit specific needs
Performs Complex Functions

Data Storage Management: Managing how data is stored and retrieved, ensuring
that data is saved correctly and can be accessed reliably.
Data Checking: Verifying that the data is correct and hasn’t been corrupted.
Providing Default Values: Supplying standard values if specific data is missing or
unavailable

 In general, managers are located in the Services Layer

Example: NVRAM Manager
•NVRAM Manager: This manager controls access to non-volatile memory such as flash
and EEPROM memory.
•What It Does:
• Manages Access: it controls how different clients access the memory to avoid
conflicts.
• Data Management: It also ensures data is stored reliably, checks the data for
errors, provides default values when needed, and manages data storage across
different types of memory.
Why is a Manager Useful?
•Provides Comprehensive Services: Managers offer more than just access
control
they also handle data management tasks, making them useful
when more complex interactions with data are required.
•Ensures Data Reliability: By managing how data is stored and checked,
managers help ensure that the system’s data remains accurate and reliable.
 Introduction to Libraries
Libraries are a collection of functions for
related purposes
Libraries:
➢ can be called by BSW modules (that
including the RTE), SW-Cs, libraries or
integration code
➢ run in the context of the caller in the
same protection environment
➢ can only call libraries
➢ are re-entrant
➢ do not have internal states
➢ do not require any initialization
➢ are synchronous, i.e. they do not have
wait points
 Introduction to Libraries
 In software development, a library is a collection of pre-written functions or routines
that perform specific, related tasks.
 These functions can be reused in different parts of a program or across multiple
programs, saving time and effort by not requiring developers to write the same code
from scratch.
 Key Characteristics of Libraries
1. Can Be Called by Various Modules:
such as BSW Modules (that including the RTE), Software
Components (SW-Cs), libraries or integration code (Other libraries or custom integration
code that brings different parts of the system together.)
2. Run in the Context of the Caller:
 Libraries execute in the same environment as the code that calls them.
 This means they share the same memory space and access rights as the caller,
which allows for efficient execution but also means they need to be safe and
secure to prevent unintended consequences.

3. Can Only Call Other Libraries:

 A function within a library can call functions in other libraries but cannot directly
call other types of modules or components.
 This keeps libraries simple and focused on their specific tasks.
4. Re-entrant:
 A function is re-entrant if it can be safely called again before its previous execution
is complete.
 This is important in multi-threaded or interrupt-driven environments because it
ensures that the same library function can be used simultaneously by different
parts of the system without causing conflicts or incorrect behavior.
5. Do Not Have Internal States:
 Libraries do not maintain any internal state between calls.
 Every time a library function is called, it works with the data given to it and does
not remember anything from previous calls.
 This makes libraries predictable and easy to use, as they do not depend on past
interactions or states.
6. Do Not Require Initialization:
 Unlike some software components or drivers that might need to set up specific
configurations before they can be used, libraries are ready to use as-is.
 a library function can be called without any preliminary setup, making them
straightforward and quick to deploy.
7. Are Synchronous:
 when a library function is called, it runs to completion before returning control to
the calling code.
 There are no wait points or delays; the caller waits until the library function
finishes its task.
 This ensures predictable behavior and timing, which is crucial in real-time systems.
Content of Software Layers
 MCAL (Microcontroller Abstraction Layer)
This layer consists of following module/blocks:
Microcontroller Drivers: This module has internal drivers for accessing the internal peripherals of the
MCU like Watchdog, General purpose Timers, or have functions for direct access to MCU like CoreTest.
Memory Drivers: This module has drivers for accessing on chip memories like internal Flash, internal
EEPROM, or memory mapped devices like external flash.
Crypto Drivers: This module has drivers for on chip Crypto devices like SHE, HSM.
Wireless Communication Drivers: This module has drivers for wireless network systems (in – vehicle or
off board communication).
Communication Drivers: This module has drivers for on board communication like SPI, I2C, etc and also
has the drivers for Vehicle communication like CAN, FlexRay.
I/O Drivers: This module has drivers for accessing and using the I/O pins of MCU including digital and
Analog (e.g. ADC, PWM, DIO)
 These drivers interact with the internal peripherals of the MCU (Microcontroller
Unit) and manage core functions that are essential for the MCU's operation.
 The internal peripherals of the MCU are Watchdog, General purpose Timers, or
have functions for direct access to MCU like CoreTest.
Watchdog Timer Driver: A watchdog timer is a hardware timer that resets the system
if the software fails to operate correctly.
 In automotive applications, a watchdog timer ensures that the system resets in
case of a software malfunction, avoiding unsafe conditions.
 Example: If a microcontroller is running a critical automotive application like
engine control, a Watchdog Timer driver would periodically reset the watchdog counter.
If the system hangs or encounters an error, the watchdog timer will trigger a
system reset.
General Purpose Timer Driver: These timers are used for generating time delays,
measuring time intervals, or producing PWM signals.
Example: In an embedded system controlling a motor, a GPT driver could be used to
generate PWM signals that control the speed of the motor.
 CoreTest Driver: This driver provides functions to test the core functionality of
the MCU, such as executing test routines on the CPU registers.

Example: In safety-critical systems, CoreTest drivers can perform self-tests to

ensure that the MCU's core components are functioning correctly before executing
the main application code.
 Memory Drivers

 This module has drivers for accessing on chip memories like internal Flash,
internal EEPROM, or memory mapped devices like external flash.

Internal Flash Driver: This driver handles read, write, and erase operations on the
MCU's internal flash memory.
Example: In an automotive ECU ,the Internal Flash Driver is used to store and
update firmware or configuration data.
Internal EEPROM Driver: This driver manages the non-volatile EEPROM memory,
which is used to store small amounts of data that must persist even after power is lost.
Example: The Internal EEPROM driver in a vehicle's MCU can store calibration
parameters or fault codes that need to be retained between power cycles.

External Flash Driver: This driver manages communication with an externally

connected flash memory device, typically via SPI or similar protocols.
Example: In a data logger system, an External Flash Driver could be used to store
large amounts of logged data.
 Crypto Drivers

 These drivers manage hardware-based cryptographic modules within the MCU,

which are used to secure communication and data storage.
 This module has drivers for on chip Crypto devices like SHE, HSM

SHE (Secure Hardware Extension) Driver: This driver interfaces with SHE, a security
module that provides encryption, decryption, and authentication services.

Example: In an automotive telematics unit, the SHE Driver encrypts sensitive data
before it is transmitted over the vehicle's communication network.
HSM (Hardware Security Module) Driver: The HSM provides advanced security
features, including secure boot, key management, and cryptographic operations.

Example: In a vehicle, the HSM Driver might be used to verify that the firmware has
not been tampered with before allowing the system to boot, ensuring the integrity
of the system.
 Communication Drivers

These drivers handle communication between the MCU and other devices using
standard communication protocols.

SPI Driver: SPI (Serial Peripheral Interface) is a synchronous serial communication

protocol used for short-distance communication, in embedded systems.

Example: An SPI Driver could be used to interface an MCU with an external sensor,
reading data from the sensor and processing it in the MCU.
CAN (Controller Area Network) Driver: CAN is a vehicle bus standard which allows
microcontrollers and devices to communicate with each other in applications without
a host computer.
Example: A CAN Driver could handle communication between different modules in
the vehicle, such as the engine control unit and the transmission control unit.

Flex-Ray Driver: Flex-Ray is a high-speed communication protocol designed for

automotive networks, offering higher data rates and reliability than CAN.
Example: A Flex-Ray Driver might be used in an advanced driver-assistance system
(ADAS) to ensure reliable communication between critical components like sensors
and control units.
LIN Driver: It is often used in non-critical applications like controlling power windows,
mirrors, or seat adjustments.

Example: In an automotive lighting system, a LIN driver could be used to control the
communication between the main control unit (master) and various lighting modules
(slaves).
For instance, when the driver turns on the headlights, the control unit sends a
command via the LIN network to the headlight module, which then activates the
lights.
The LIN driver ensures that the command is correctly transmitted and received.
Ethernet Driver: Ethernet is increasingly being used for in-vehicle networking, connecting
various ECUs sensors, and other devices.
Example: In an advanced driver-assistance system (ADAS), an Ethernet driver facilitates
high-speed communication between cameras, radar sensors, and the central processing
unit.
The Ethernet driver ensures that large amounts of sensor data are transmitted quickly,
enabling real-time processing and decision-making by the vehicle's control systems.
For instance, when a camera detects an obstacle, the image data is transmitted over
Ethernet to the processing unit, where it is analyzed to determine if evasive action is
needed.
 Wireless Communication Drivers
These drivers support communication over wireless networks, whether within the
vehicle (in-vehicle communication) or for external connections (off-board
communication).
Bluetooth Driver: This driver enables wireless communication between the MCU
and other Bluetooth-enabled devices.
Example: In a car infotainment system, the Bluetooth Driver allows the MCU to pair
with a smartphone to stream music or make hands-free calls.
Wi-Fi Driver: This driver allows the MCU to connect to Wi-Fi networks for data
communication.
Example: In a vehicle with a telematics system, the Wi-Fi Driver could enable the
MCU to connect to a cloud service for software updates or remote diagnostics.
 I/O Drivers
I/O (Input/Output) drivers manage the interface between the MCU's general-purpose
I/O pins and the external world, including both digital and analog signals.
ADC (Analog-to-Digital Converter) Driver:

Functionality:
 Converts analog signals (e.g., voltage levels from sensors) into digital data that the
MCU can process.
 Configures sampling rates, resolution, and input channels.
 Handles calibration and filtering of input signals to improve accuracy.
Examples:
Temperature Sensor Monitoring: An ADC driver can read the voltage from a
temperature sensor placed in the engine or cabin.
The sensor will output a voltage proportional to the temperature, and the ADC driver
converts this analog voltage to a digital value that the ECU uses to monitor and control

Throttle Position Sensing: In electronic throttle control, the ADC driver reads the
position of the throttle pedal (which is often sensed by a potentiometer). The digital
value is used to control the engine's throttle position, ensuring responsive acceleration.
 PWM Driver
Functionality:
 Generates PWM signals to control devices like motors, LEDs, and actuators.
 Adjusts the duty cycle and frequency of the PWM signal to control the power
delivered to the device.
 Supports features like phase correction, dead-time insertion, and fault handling.
Examples:

Motor Speed Control: In an electric power steering system, a PWM driver controls
the motor that assists the steering mechanism.
By varying the duty cycle of the PWM signal, the speed and torque of the motor are
adjusted to provide the necessary assistance based on the driver's input.
LED Dimming: PWM drivers are used to control the brightness of LEDs in automotive
lighting systems, such as headlights, dashboard lights, and ambient lighting.
The PWM signal's duty cycle determines the LED brightness, enabling smooth dimming
effects.
DIO (Digital Input/Output) Driver:

Functionality:
 Manages the digital input and output pins of the MCU.
 Configures pins as inputs or outputs, sets output states (high/low), and reads input
states.
 Supports features like pull-up/pull-down resistors, debouncing, and interrupt handling.
Examples:
Reading Switch Inputs: In a car's infotainment system, a DIO driver might read inputs
from various user interface buttons (e.g., volume control, track selection).
When a button is pressed, the DIO pin is pulled low, and the MCU detects this change
to trigger the appropriate response.
Controlling Relays: DIO drivers are used to control relays that activate various electrical
components, such as turning on the fuel pump, headlights, or windshield wipers.
The MCU sets the DIO pin high or low, energizing or de-energizing the relay to control
the component.
 Input Capture Unit Driver
Functionality:
 Captures the timing of external events, such as pulse widths or intervals between
signals.
 Generates precise output signals based on timing calculations, useful for tasks like
timing synchronization and event triggering.
Examples:
Wheel Speed Sensing: Capture drivers are used in anti-lock braking systems (ABS) to
measure the time intervals between pulses generated by wheel speed sensors.
These measurements help determine wheel speed and detect when a wheel is
about to lock up, allowing the ABS to modulate braking force.
Engine Timing: In engine management systems, capture drivers are used to precisely
time fuel injection and ignition events.
The driver captures the position of the crankshaft or camshaft and compares it to
the desired timing, allowing the ECU to adjust the timing of the injectors or ignition
coils.

OCU (Output Compare Unit) Driver

The Output Compare Unit (OCU) driver is a specialized driver used in

microcontrollers to generate precise timed output signals.
It is often used in applications where generating specific time-based events is crucial, such
as controlling motors, generating PWM signals, or timing events in automotive systems.

Examples
Motor Control:
In an automotive electric window or seat adjustment system, the OCU driver can
generate PWM signals to control the speed and position of the motors.
 By adjusting the duty cycle of the PWM signal, the system can precisely control
how fast or slow the motor operates, ensuring smooth and accurate movement.
Ignition Timing:

 In engine control, the OCU driver can be used to control the timing of spark ignition.
 The OCU compares the current timer value with the desired ignition timing and
triggers a spark at the exact moment needed for optimal combustion, improving
engine performance and efficiency.

Transmission Control:

 The OCU driver can be used in automatic transmission systems to control the timing of
gear shifts.
 By precisely controlling the engagement and disengagement of clutches, the OCU
driver ensures smooth and efficient shifting.
 Port Driver
Functionality:
Provides a simple interface to configure and control the general-purpose I/O pins on
the MCU.
Handles basic input and output operations without the need for specialized drivers.
Examples
Indicator Lights Control:
•The Port driver controls dashboard indicator lights (e.g., turn signals, high beam
indicator, check engine light).
•The MCU sets the output pin to the correct state (high or low) to turn the lights on or
off based on vehicle status.
Sensor Integration:
•In an automotive safety system, the Port driver may handle inputs from various
sensors, such as seatbelt sensors or door ajar switches.
• The MCU reads these inputs to determine whether all passengers are buckled in or if a
door is open, triggering warnings or safety mechanisms if necessary.

Actuator Control:

•The Port driver can control actuators in systems like central locking or sunroof
operation.
•The MCU sends commands to the Port driver to set the appropriate pins high or low,
activating the actuators to lock doors or open the sunroof.
Content of Software Layers
 Complex Device Drivers Or CDD
 This module is useful in implementing non standard functionality within BSW stack.

 There are many cases when we need to implement some functionality which is not
supported by AUTOSAR, so CDD is used for such cases.

If a functionality requires strict timing constraints which may be lesser than the
minimum timing of AUTOSAR OS resolution then CDD module is useful, as it directly
helps connecting the MCU with the application.

 Complex drivers functionality is highly MCU and application dependent and the code
may not be easy to port.
 Complex Drivers
An example is to implement 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
 Injection Control

 Injection control refers to managing fuel injection systems in internal combustion

engines.
 The Complex Driver must interact with sensors (like pressure or oxygen sensors) to
evaluate the engine's status in real-time and control the exact timing and amount
of fuel injected into the combustion chamber.
 This requires precise timing and fast responses, which can be achieved through
direct access to microcontroller interrupts, which handle events such as crankshaft
position sensing or fuel pump activation.
Role of μC and Complex Driver:
 The Complex Driver would access interrupts generated by the engine’s
crankshaft position sensor to determine when to open and close the fuel
injector valves.
 It ensures that the fuel injection happens at the correct moment in the engine
cycle (i.e., during the intake stroke), optimizing combustion for performance
and efficiency.
 Electric Valve Control

 Electric valve control is common in systems like engine management (e.g., variable valve
timing) or HVAC systems.
 Here, the Complex Driver will directly control electric valves by reading sensor data and
using microcontroller peripherals to adjust the valve position.
Direct μC Interaction: Using advanced timers or PWM peripherals, the Complex Driver can
precisely control the actuation of electric valves.
 The μC is required to adjust the valve positions in response to real-time feedback, which
might involve using a fast, dedicated peripheral like a TPU (Time Processing Unit).
Key Reasons for Complex Drivers:

•Non-standard functionality: These drivers handle specific tasks that cannot be

standardized across different platforms, like precise sensor/actuator control.

•Direct hardware access: Complex Drivers bypass certain layers of abstraction to

directly access hardware resources (interrupts, timers, peripherals), reducing latency.

•Real-time critical tasks: Timing-sensitive operations, such as those in fuel injection or

position detection, need immediate responses that standard drivers cannot provide.
 ECU Abstraction Layer
 The ECU Abstraction Layer in AUTOSAR is essential for achieving hardware
independence, not just for the Microcontroller but also for external peripherals
connected to the ECU.

This layer abstracts the low-level details of both on-chip and off-chip (external)
hardware, providing standardized interfaces for applications, thus shielding them from
hardware-specific dependencies.
I/O Hardware Abstraction module

 Abstracts the configuration of I/O ports, pins, and external components, and
provides standardized APIs for higher layers of the software stack.
 In conventional software development, an engineer would consider hardware-
specific details, like the configuration of microcontroller pins or the exact wiring of
external sensors.
 However, in AUTOSAR, the I/O Hardware Abstraction module hides these specifics
and allows developers to focus on higher-level functionality.
 Example: Headlight Control System in a Car

Involves several components like:

•A light sensor (to detect ambient light and decide when headlights should be turned on)
•A switch (for the driver to manually turn the lights on or off)
•Actuators to turn the headlights on/off or adjust the beam.
Without AUTOSAR (Conventional Approach):

1. We need to know how the light sensor is physically connected to the MCU (which
pin, what voltage levels).
2.We must understand the wiring of the switches and how they interact with the
microcontroller.
3.If the car manufacturer decides to change the sensor model or the wiring layout,
the software will need significant rework, as the code depends on specific
hardware pin configurations, signal processing, and other low-level details.
With AUTOSAR (I/O Hardware Abstraction)
Light Sensor Input:
The light sensor provides an Analog voltage based on Ambient light.
 In conventional software, we need to know which Analog input pin on the MCU is
connected to the sensor, how to configure the ADC to read that pin, and how to
calibrate the readings.
 In AUTOSAR, the I/O Hardware Abstraction module will handle these details.
 The application developer simply calls a standardized API, like
GetLightSensorValue(), which returns a processed value from the light sensor,
abstracting details like which pin the sensor is connected to or the specific ADC
settings for different MCUs
Headlight Switch Input
 The switch input may be connected to a digital I/O pin.
 The I/O Hardware Abstraction module abstracts the pin configuration, debouncing, and
other signal conditioning.
 The application layer just uses an API like GetSwitchStatus() to know whether the
headlight switch is ON or OFF, without worrying about pin assignments, debouncing
logic, or whether the switch input is active-high or active-low.
Headlight Actuation:

 The headlight actuator involves controlling an external relay or a PWM signal to drive
the headlights.
 Whether the control signal is sent directly to an on-chip PWM module or through an
external driver (e.g., a dedicated headlight control IC), the I/O Hardware Abstraction
module handles it.
 The application would simply call an API like SetHeadlightState(ON/OFF).
Summary
 The I/O Hardware Abstraction module allows application developers to write
software that is independent of the specific details of the ECU hardware,
including how sensors and actuators are wired.
 It ensures that even if the microcontroller or external peripherals change, only
the abstraction layer and drivers need to be updated, while the application
logic remains unaffected.
 This is crucial for building scalable and maintainable automotive software,
where different car models may use different hardware, but the core
functionality remains the same.
Communication Hardware Abstraction
Abstracts the communication controllers and the hardware layout of the ECU, enabling
communication across different protocols such as CAN, LIN, and FlexRay.

This abstraction hides the complexities related to the physical location of

communication controllers— on-chip or off-chip (in external peripherals).

Consider an architecture of an ECU that involves both internal and external CAN
controllers, lets see how the Communication Hardware Abstraction handles these cases.
Example: ECU with Two Internal CAN Channels and a CAN-ASIC with Four External CAN Controllers
ECU Architecture Overview
Microcontroller : The microcontroller has two internal CAN communication channels
(CAN0 and CAN1).

CAN-ASIC: An additional on-board ASIC contains four CAN controllers (CAN2, CAN3,
CAN4, CAN5), and this ASIC is connected to the microcontroller via SPI.

• The ECU needs to handle messages across all six CAN controllers seamlessly,
abstracting whether the controllers are internal to the
microcontroller or external via an ASIC.
 In a traditional non-AUTOSAR approach: We have to explicitly manage each
communication controller and write separate logic for internal CAN controllers
(directly handled by the MCU) and external CAN controllers (communicated through
the SPI interface).
 Developers need to manually handle the differences in accessing the internal and
external controllers, leading to complex and error-prone code, and lack of portability.
 In AUTOSAR, the Communication Hardware Abstraction layer simplifies and
standardizes the interaction with both internal and external CAN controllers
 It provides a unified interface, making it irrelevant to the application whether the
CAN controller is located on-chip or off-chip.
CAN Interface: This module provides a standardized API
for accessing CAN communication, regardless of where
the CAN controllers are located (internal or external).
 It shields the higher layers (e.g., the application layer
or communication stack) from knowing which
hardware controller is being used.
Communication Hardware Abstraction (ComM):
 This module manages the physical communication
controllers and their configuration, abstracting the
fact that some CAN controllers are internal and others
are external (connected via SPI).
CAN Driver: The CAN Driver handles the specific
communication tasks, like sending and receiving
messages.
 For internal CAN controllers, the driver directly
accesses the microcontroller's registers.
 For external CAN controllers, the driver
communicates via SPI.
Internal CAN Controllers:
•The two internal CAN controllers (CAN0 and CAN1) are
integrated into the microcontroller and are accessed
directly by the CAN Driver
•The CAN Interface calls the CAN Driver’s API to send
or receive CAN messages.
•Since the CAN controllers are on-chip, the driver
directly interacts with the controller hardware.
External CAN Controllers (via SPI):
•The four external CAN controllers (CAN2, CAN3,
CAN4, CAN5) are located on an ASIC that is connected
to the microcontroller via SPI.
•The Communication Hardware Abstraction layer
ensures that the higher software layers do not need
to know about the specific details of the SPI interface.
•It handles the communication between the
Microcontroller and the external CAN controllers.
•The CAN Driver for the external controllers is
different from the driver for the internal controllers.
• It sends and receives CAN messages through the SPI
bus, using the SPI driver to communicate with the
ASIC.
•From the perspective of the higher layers, such as
the CAN Interface, there is no distinction between
internal and external CAN controllers.
•Whether a message is being sent via CAN0 (internal)
or CAN5 (external via SPI), the interface remains the
same.
 Crypto Hardware Abstraction
 Crypto Hardware Abstraction in AUTOSAR abstracts the
interaction between the application layer or service
layer and cryptographic hardware (like a Hardware
Security Module- HSM).
 This layer ensures that higher-level software
components can use cryptographic functions
(encryption, decryption, signature verification, etc.)
without understanding the specifics of the hardware.
Example: Secure Communication in a Car

 Imagine a car's ECU that needs to communicate securely over the CAN bus with other
ECUs to prevent unauthorized message tampering (e.g., secure CAN communication).
 To achieve this, encryption and decryption are necessary.

Without Crypto Hardware Abstraction (Conventional Approach):

Direct Access to Hardware: The ECU software must interact directly with the
cryptographic hardware (such as an HSM).
 This involves low-level code that depends on the specific hardware, like configuring
registers and handling keys securely.
Hardware-Specific Code: hardware is changed (e.g., moving from an HSM to a
different external cryptographic module), the software needs to be rewritten or
adapted to the new hardware, making it less portable and more complex to maintain.
 The Crypto Hardware Abstraction layer simplifies this process:

1. Initialization: The Crypto HAb initializes the hardware security module (HSM) or
external cryptographic module during ECU startup. The application does not need
to know which hardware is used.
Encryption of Data (CAN Message):
 The application layer requests to send a secure message over CAN using encryption. It
calls the Crypto Service Manager (part of the Service Layer).
 The Crypto Service Manager forwards this request to the Crypto Hardware
Abstraction layer.
 The Crypto HAb interacts with the underlying cryptographic hardware (whether it’s
the HSM or an external module) and performs the encryption.
 The encrypted data is then sent over the CAN bus.
Decryption of Data:
 On the receiving ECU, the encrypted CAN message is received.
 The ECU requests the Crypto HAb to decrypt the message using the appropriate
cryptographic algorithms.
 The Crypto HAb again communicates with the underlying crypto hardware to
perform decryption and returns the decrypted data to the higher layers.
 Memory Hardware Abstraction
Imagine you have two types of storage in your house: on-chip storage (like a drawer in your desk) and
external storage (like a USB drive).

 whether you want to store something in your desk drawer or on your USB drive, you don’t want to worry
about where it’s actually being stored. You just want to save and retrieve data in the same way.

Memory Hardware Abstraction in AUTOSAR is like having a helper that makes storing and retrieving
information easy.

This helper allows you to treat both the desk drawer (on-chip memory like Flash or EEPROM) and the USB
drive (external memory like external EEPROM) the same way, even though they are different.
Example of Memory Abstraction
Storing a temperature reading in external EEPROM.

Memory Abstraction Interface: Provides a uniform way to

access different types of memory, whether it is on-chip or
external.
EEPROM Abstraction: Manages access to EEPROM, regardless of
whether it's internal (on-chip) or external (off-chip).
Flash EEPROM Emulation: If a device doesn't have EEPROM,
Flash memory can emulate its behavior. This allows the
application to treat Flash memory as if it were EEPROM.
External EEPROM Driver: Manages the communication with an
external EEPROM chip (for example, through the SPI interface).
External Flash Driver: Handles external Flash memory if it is
used instead of EEPROM.
1. The application requests to store the temperature
reading in EEPROM
2. RTE Passes this request to the Memory Abstraction
Layer without concern for whether the memory is on-
chip or off-chip.
3. Memory Abstraction Interface determines whether
the data will be stored in EEPROM or Flash
(depending on the configuration).
4. EEPROM Abstraction: Handles the request and ensures
data is stored in the right place.
If using external EEPROM, the External EEPROM Driver
will be used.
If using Flash emulation for EEPROM, the Flash EEPROM
Emulation and Flash Driver will manage the storage.

5. COM Drivers: If the external EEPROM is connected via

SPI, the SPI Handler Driver will manage the
communication between the microcontroller and the
external EEPROM.
6.Memory Drivers: The EEPROM Driver handles low-level
operations like writing data to EEPROM
7. Microcontroller (μC): At the hardware level, the
microcontroller interacts with the memory device
(EEPROM or Flash) through interfaces like SPI.
 On-board Device Abstraction
 This module provides abstraction from ECU specific on board devices.

 This module contains drivers for on board devices which cannot be called as
sensors or actuators or timers like internal or external watchdog timers.

 Example: Watchdog Timer Implementation

 Suppose the ECU system has a watchdog timer, a safety
feature that monitors the system’s health.
 If the system hangs (stops responding), the watchdog will
reset it.
 There are both internal and external watchdogs

Internal Watchdog: A watchdog within the microcontroller.

External Watchdog: A separate watchdog chip connected

via SPI.
Application Layer:

The application sets up the watchdog, instructing it to reset

the system if no response is received within a set time (e.g.,
1 second).

The application may regularly "kick" (reset) the watchdog

timer to prevent the system from resetting, ensuring that the
system is still functioning properly.

The RTE forwards the application’s requests (e.g., setting the

watchdog timer) to the appropriate abstraction and driver
layers.
On-board Device Abstraction Layer:

The Watchdog Interface abstracts whether you're dealing

with an internal or external watchdog.
Microcontroller Drivers:

Internal Watchdog Driver: If the watchdog is internal, this

driver will directly interact with the MCU’s internal
watchdog peripheral to set up the timer and manage
resets.

SPI Handler Driver: If the watchdog is external, the SPI

driver handles communication between the MCU and the
external watchdog chip, sending signals to reset the timer.
 Services: Crypto Services
The Crypto Services consist of three modules
➢ the Crypto Service Manager is responsible
for the management of cryptographic jobs
➢ the Key Manager interacts with the key
provisioning master (either in NVM or Crypto
Driver) and manages the storage and
verification of certificate chains
➢ The Intrusion Detection System Manager is
responsible for handling security events
reported by BSW modules or SW-C
 The Communication Service in AUTOSAR provides a standardized interface for
managing data exchange between different ECUs via communication buses such as
CAN, LIN, FlexRay, and Ethernet.
 The communication service abstracts the lower-level details of communication
protocols and manages the data flow in a structured manner.

Example:

Scenario: The Body Control Module (BCM) needs to send a signal over the CAN bus to
the Lighting Control Module (LCM) to turn on the headlights.
Service: The Com service handles the transmission and reception of signals between
ECUs, ensuring the data is properly packaged and sent over the communication bus.
Lower Layers:

 Com Module: High-level service that manages message transmission.

 CAN Interface (CanIf): Abstracts the CAN driver and handles message packaging.

 CAN Driver (from MCAL): Directly interfaces with the CAN hardware to send/receive

messages.
 Off-Board Communication Service

 The Off-Board Communication Service manages communication between the vehicle’s

ECUs and external diagnostic or service tools (e.g., diagnostic testers or factory
reprogramming tools).
 It supports protocols such as UDS (Unified Diagnostic Services) and DoIP (Diagnostics
over Internet Protocol).
Example:
Scenario: During a vehicle service, an external diagnostic tool needs to read error codes
from the Engine Control Unit (ECU).
Service: The DCM (Diagnostic Communication Manager) handles diagnostic requests like
reading error codes from the ECU.
Lower Layers:

 TP (Transport Protocol): Segments large diagnostic messages for transmission.

 PduR (Protocol Data Unit Router): Routes data to the correct protocol (e.g., UDS).

 CAN Driver (MCAL): Sends the diagnostic message over the CAN bus.
The Memory Service in AUTOSAR manages the storage and retrieval of data in non-
volatile memory (EEPROM, Flash, or RAM).
It ensures that critical data such as configuration settings, diagnostic logs, or user
preferences can be stored permanently and retrieved across vehicle power cycles.
Example:
Scenario: The seat adjustment system allows the driver to store their seat position
settings, which should be retained even when the vehicle is turned off.
Service: The NVM Manager (NvM) is responsible for writing and reading these seat
settings to/from the EEPROM.
Lower Layers:

EEPROM Abstraction Module: Provides a uniform interface for internal and external
EEPROM.
EEPROM Driver (MCAL): Interacts with the actual EEPROM hardware.
 The Crypto Service provides encryption, decryption, and digital signature
functionalities.
 It uses lower-level drivers from the Crypto Hardware Abstraction and Crypto Drivers in
MCAL to perform cryptographic operations using hardware accelerators or software
implementations.
Example: Digital Signature Verification
Service: The Crypto Service verifies the digital signature of a software update.
 The System Service (e.g., BswM – Basic Software Mode Manager) handles system-
level operations like power management, startup, and mode transitions.
 It interacts with hardware abstraction layers to manage system state transitions.

Example: Transition to Low-Power Mode

Service: The BswM requests a transition to low-power mode when the vehicle is
turned off.