Introduction to AUToSAR and difference between CLASSIC and ADAPTIVE AUToSAR

3. 20 mins
Software design
15 mins
Automotive market
20 mins
Introduction to
AUTOSAR
50 mins
AUTOSAR layered
architecture
15 mins
EX: Software
specifications

4. Software Design?
It is the proposition of an architecture that will perform the required functionality,
guarantee the real time constraints while adhering to the system resources and any
other specified requirements.

5. Software design
● Static design
● Dynamic design

6. STATIC Design?
➔ Most systems are complex &big
➔ Divide the system to parts and
define the functionality of each
part
➔ Functionality breakdown
1-To decrease complexity
2-To facilitate maintainability
3-Make testing more easier
➔ Define sub_components
1-For complex component
2-For future porting/re-usability.

7. STATIC Design?
● Decomposition of software into
layer
● Layer :horizontal collection of
software modules .
● Why software layered
Architecture?
1- Isolated Application from
hardware changes as upper
layers don’t affect by lower ones
(portability)
2- Integration of functional modules
from multiple suppliers.
3- Provides the opportunity for re_use
by defining SW building.

8. STATIC Design?
4- Assists in breakdown of software requirements /functionalities.
5-Simplifies isolation of software bugs , Easier in Testing (detection and correction).
6- Facilitates software maintainability.
Disadvantage of dividing sw to layers ?
● More processing time due to calls between different layers and different modules
inside each layer
● requires more hardware resources (RAM,Storage,Processing Power,etc)

9. STATIC Design?

10. DYNAMIC Design?
● The objective of Dynamic design is guarantee the real time constraints are met.
● Define systems event ,tasks, isrs and their priorities
● Define time constraints.
● Methodology :
1- Process Definition.
2- Process Allocation
3- Timing calculations

11. DYNAMIC Design?
● Processes are definition
Process are defined based on
1- input acquisition
2-Decision making
3-Output generation

12. DYNAMIC Design?
● Process Allocation
Assign Processes to
● Tasks
➢ Event driven
➢ Scheduled
● ISRs
● Define priorities

13. INTRODUCTION TO

14. INTRODUCTION TO AUTOSAR?
● AUTOSAR (AUTomotive Open System ARchitecture) is a world wide.
● Standardization initiative of leading automotive manufacturers(OEM) ,
suppliers(TIER1,TIER2) and other companies that was founded in autumn of
2003.
● The goal is the development of a reference architecture for ECU software that
can manage the growing complexity of ECUs in modern vehicles.
● “Cooperate on standards, compete on implementation”
http://WWW.autosar.org

15. Automotive Market:

16. Why AUTOSAR ?
● Any software development is aimed at creating a new or improving an existing
function.
● Distribution of development between suppliers and/or within the company
● Flexibility in applying innovative solutions
● Simple integration of software into the system
● Reducing the total development cost
● Reducing the number of heterogeneous software due to industry
standardization
● Using standard software modules for different customers
● Increasing adaptation efficiency
● Software and accessories
● Standardized process developments and a data exchange format
● Development of new business models

17. WHY AUToSAR ?
1. MODULARITY:
Extend the requirements for given module. Modularity of automotive SW
Elements enables tailoring of SW according to the individual requirements of
Electronic control units and their tasks .
2. SCALABILITY:
Add new modules /stack and functionality (Ethernet) easily.Scalability of
functions
Ensure the adaptability of common sw modules to different vehicle platforms to
Prohibit proliferation of sw with similar function.
3. TRANSFERABILITY:
Transfer configuration from ecu to another one easily. Transferability of
functions
Optimizes the use of resources available throughout a vehicle’s electronic
Architecture.

18. WHY AUToSAR ?
4. RE_USABILITY:
Use stacks from different vendors .Re_usability of the functions helps to
improve
Product quality and reliability and to reinforce corporate brand image across
Product lines.
5. STANDARDIZED INTERFACE :
Standardization of functional interface across manufacturers and suppliers and
Standardization of the interface between the different software layers is seen
as a
Basis for achieving the technical goals of AUTOSAR.
6. ABSTRACTION FROM UNDERLYING:

19. Introduction to AUToSAR?
AUTOSAR CHALLENGES
● E/E complexity is growing fast.
● Many different hardware platforms are used.
● Development processes and data formats are not harmonized
● Quantity of sw is exploding.
The main objective of AUTOSAR
● Improve sw quality and reduce costs by re_use
- Reuse of the functions across carlines and
crossOEM boundaries
- Reuse of development methods and tools
- Reuse of the basic sw

20. AUTOSAR PARTNERSHIP STRUCTURE

21. AUTOSAR PARTNERSHIP STRUCTURE
● Core partners (9):
BMW, Volkswagen, Daimler, PSA.
Bosch, Continental.
Ford, GM.
Toyota
● Premium members (48+):
Fiat Chrysler, Hyundai, Mazda.
Volvo Cars, AB Volvo.
Mentor Graphics.
…..
● Associate members (104+)

22. AUTOSAR and Automotive Industry

23. ِAUTOSAR releases and it is still growing
● 8 major releases have been Published : 2.1, 3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 4.3.

24. AUToSAR standardizes two software platforms –
Classic and Adaptive

25. Software architecture of AUToSAR Classic Platform

26. AUToSAR Adaptive Platform Logical view

27. Classic Platform vs. Adaptive Platform Technical
characteristics

28. The background for the introduction of Adaptive AUTOSAR
platform:
● The upcoming developments in the field of automotive software are influenced
heavily towards the concept of Intelligent Connected Vehicles. Ex: Automated
Driving, Connectivity(IOT), Electrification etc.
● To achieve these, we would need to incorporate advance sensors, controllers
and actuators. The High Performance Computing coming into the picture, there
was a need to define new standards forming the Adaptive AUTOSAR platform.
● Conclusion: At least in the near future the new Adaptive Platform will not be
replacing the existing Classic Platform. Both the platforms will have to co-exist.
We would continue to implement the deeply embedded functionalities on
Classic Platform while the high performance functionalities will be
implemented on the Adaptive Platform.

30. AUTOSAR Software Architecture
● The AUTOSAR architecture is 3 Software Layers.
● The AUTOSAR architecture distinguishes on the highest abstraction level
between three software layers: Application, Runtime Environment, and Basic
Software which run on a Microcontroller.

32. AUTOSAR Software Architecture
● The AUTOSAR Basic Software is further divided in the layers: Services, ECU
Abstraction, Microcontroller Abstraction and Complex Drivers.
● Provides services to the application.
● In charge of the running the functional part of the software.

34. Microcontroller Abstraction Layer
● Lowest software layer of the BSW.
● It contains internal drivers, which are software modules with direct access to the
microcontroller and internal peripherals.
● Task:
Make higher software layers independent of microcontroller.
● Properties:
Implementation: Microcontroller dependent.
Upper Interface: standardized and microcontroller independent.
● Drivers in this layer are mainly provided by the microcontroller manufacture like
Renesas and Freescale or by Tier 2.

35. Microcontroller Abstraction Layer
● The Microcontroller Abstraction Layer consists of the following module groups:
○ I/O Drivers (e.g. ADC, PWM, DIO).
○ Communication Drivers (e.g. SPI, CAN, LIN, Ethernet, FlexRay)
○ Memory Drivers (e.g. internal flash, internal EEPROM)
○ Microcontroller Drivers (e.g. Watchdog, GPT, MCU, ICU)

36. ECU Abstraction Layer
● Middle software layer of the BSW.
● It contains drivers for external devices.
● It offers an API for access to peripherals and devices regardless of their location
(internal / external) and their connection to the microcontroller.
● Task:
Make higher software layers independent of ECU hardware layout.
● Properties:
Implementation: Microcontroller dependent, ECU hardware dependent.
Upper Interface: Microcontroller and ECU hardwareindependent.

37. Service Layer
● Highest software layer of the BSW.
● It offers:
○ OS 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.
○ Supervision and control services (WDG manager).
○ Error reporting service.

38. Complex Drivers
● Spans from the hardware to the RTE.
● Tasks:
Provides the possibility to integrate special purpose functionality, e.g. drivers for
devices.
○ Which are not specified within AUTOSAR
○ With very high timing constraints or for migration purposes etc.
● Properties:
Implementation: might be application, MC, and ECU hardware dependent.
Upper interface: might be application, MC, and ECU hardware dependent.
● Examples:
Injection control, Electric valve control, Incremental position detection

41. Application Layer
● Consists of software components (SWCs) which cover application requirements.
● SW-components are independent .
● SW-components are independent of MC and ECU on which it is mapped.
● SWCs interact with each other and with the BSW Layer through the RTE.
● All SWCs interactions are performed through the RTE.
○ Intra ECU communication
■ Communication between SWCS=s on the same ECU.
■ Communication between SWC and BSW modules.
■ Communication done through the RTE.
○ Inter ECU communication
■ Communication between SWCs on different ECUs.
■ Communication channels are used (CAN, LIN, Ethernet, FlexRay).

42. Runtime Environment Layer
● It provides communication services between the application software (AUTOSAR
software components) and each other.
● 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.
● RTE controls the connections between SWCs and from SWCs to the BSW.
● Tasks:
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.

44. METHODOLOGY
Derive E/E architecture from formal
descriptions of soft- and hardware
components
Functional software is described formally in
terms of “software Components” (SW-C).
Using “Software Component Descriptions”
as input, the “Virtual Functional Bus”
validates the interaction of all components
and interfaces before software
implementation.
Mapping of “Software Components” to
ECUs and configuration of basic software.
The AUTOSAR Methodology supports the
generation of an E/E architecture.

45. AUTOSAR SWS Examples

46. ACollaborative Effort Between…
1) Nesreen Muhammed
Linkedin : https://www.linkedin.com/in/nesreen-muhammed
Mail : nesreen191@gmail.com
Github: https://github.com/Nesreen-Muhammed
1) El_abbas Salah hatata
Linkedin : https://www.linkedin.com/in/el-abbas-salah-hatata-442743179/
Mail : abassalah219@gmail.com
Github: https://github.com/ELabbassalah56/
Thanks