What is Autosar

What is AUTOSAR?

AUTOSAR is acronym for

Automotive Open System Architecture

It is a standard Software architecture , tailor-made

for Automotive applications (Automotive ECUs). It
is an open-source and specifications are accessible
free of cost.
 Why do we need it?

 IN College days, for Arduino, 8051, PIC, ATMEGA projects etc

we never had software architecture

 We heard about software architecture after we start our jobs

 Higher the complexity of system, and more people and teams

work on same software, we will need a guidance and
foundation.

 Software architecture fulfills this purpose

 So multiple teams can work on various modules and they can

fit together in the system with minimal effort and function.
 So initially each company had their own software architectures
and the product owners only had to provide entire software for
the ECUs

 OEMs wanted to involve multiple tier1 suppliers for software.

And different tier1 suppliers had different software
architectures.

 So solution is Standardize the software architecture.

 Hence AUTOSAR was born

What Autosar Stadardizes
What does Autosar Standardize?

Which are the different modules

Architecture and how are they placed and
responsibility of each module

What are the different file and formats

Methodology involved and defines flow from
requirements till final hex is generated

How do modules interact with each

other and the format and standards
Interfaces of exchanging data and fulfilling
services
Autosar Architecture
Architecture shows the blueprint of any Automotive ECU
Software must look like and responsibility of various modules
and clear cut boundries between modules.

Autosar has specified 3 confirmation classes for Autosar

Architecture

Confirmation Classes (ICC) are the level of modularity of Basic

Software

Helps in Migration from non-Autosar platform to Autosar

platform

One major feature is CDD module which helps in migration

ICC1 as Layered architecture of AUTOSAR

Application Layer + RTE + Basic Software Layer

Difference between ASW and BSW in purpose

RTE is collection of connectors

BSW = Services + ECUAL + MCAL + CDD

ICC2 as Inclusion of vertical stacks to ICC1

The Stacks are group of modules dedicated to a

particular area of functionality

4 main stacks are below:

System stack + ComStack + IOStack + MemStack

Diagstack is infact part of Comstack itself. But in

companies its considered as separate stack
ICC3 is deeper module level classification of Stacks.
Highest level of conformation class

ICC3 consists of All the possible modules that can be

present in a AUTOSAR BSW.

An Autosar based software need not have all the

available modules shown in the standard but have a
subset depending on the requirement and hardware
resources.
If the software has more modues which are not in
ICC3 then its included in CDD

What is CDD and what is its purpose?

The Complex Device Driver (CDD) Software
Component is used to model a function outside of
the normal AUTOSAR Basic Software stack for
complex or resource critical sensor evaluation or
actuator control, especially for hardware that is not
directly supported by AUTOSAR (like project specific
ASICs).
The ComplexDeviceDriverSwComponentType can
define Ports to directly interact with Software
Components via AUTOSAR Interfaces and it can also
interact directly with Basic Software Modules via
Standardized Interfaces. It needs to be mapped with
the corresponding BswModuleDescription via
SwcBswMapping.
ASW Vs BSW
 Application Software Component
Realizes a feature which is a value addition
to the car
Differs from ECU to ECU
Has mainly Autosar Interfaces
Autosar doesn’t provide specs. Just
guidelines
Independent of Underlying Hardware
completely
Allocation is flexible
Ex: Injection system in Engine ECU,
Crash detection system in Airbag ECU
Brake trigger system in ABS ECU etc
Base Software Component
Assists ASW to realize the feature by
managing hardware resources.
Almost common for all ECUs
Has Standardized Interfaces
The modules are standardized and has
specification
Dependant on underlying hardware
Allocation is fixed to ECU
Ex: Modules in comstack like CAN Driver,
DCM to handle UDS Tester req & resp
Fls to handle flash memory etc