systemAutomotive Embedded Systems part5(Introduction to AUTOSAR).

1. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automotive Embedded
Systems part5
(Introduction to AUTOSAR).
ENG.KEROLES SHENOUDA
1

2. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Introduction to AUTOSAR
it's time to wake up 
Learn In Depth 
2

3. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Background
 Today’s automotive industry is faced with
a growing demand for technical
appliances and this requires an increased
use of ECUs which is reflected in the
complexity of the system.
 Traditionally, solutions have been specific
for a certain platform or model and this
structure is more becoming unmanageable
and costly.
 Instead of making specific solutions a
standardized future is the way to go.
 This increased complexity could be
manageable and improved by a
standardized architecture and the
solution is AUTOSAR
3

4. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
4
(AUTomotive Open System ARchitecture)
 The main objective of
 Improve software quality and reduce costs by re-use
 Re-use of functions across carlines and across OEM boundaries
 Re-use of development methods and tools
 Re-use of basic software
AUTOSAR makes the application software independent from
the hardware

5. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 Application software that supports the AUTOSAR standard will receive
several benefits.
 The following examples are the driving forces why we need AUTOSAR as
listed in :
 Manage increasing E/E complexity – Associated with growth in functional scope.
 Improve flexibility – More room for updates, upgrades and modifications.
 Improve scalability – The system can in a more graceful manner be enlarged.
 Improve quality and reliability – Proven software applications can be reused.
 Detection of errors in early design phases
5
(AUTomotive Open System ARchitecture)

6. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Reusability
6

7. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automotive industry
7

8. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automotive industry
8
Source: www.autosar.org

9. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Layered Architecture
9
Source: www.autosar.org

10. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR: Specifications
10
www.autosar.org

11. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR: Specifications
11
www.autosar.org

12. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR is still growing
12

13. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is the AUTOSAR standard
and why is it created?
13

14. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemWhat is the AUTOSAR standard and
why is it created?
 AUTOSAR is standardized software architecture developed in
cooperation between car manufacturers originally intended for the
automotive industry but is steadily gaining interest from other
industries as well.
 AUTOSAR was developed with the intention of being able to handle
the increased complexity in today’s automotive industry and to
decouple software from hardware.
 Also Integration of functional modules from multiple suppliers
 Software updates and upgrades over vehicle lifetime
 Consideration of availability and safety requirements
14

15. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR
Benefits
15

16. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Developing a new car with AUTOSAR
16
Functions of the car
Brake control BC
Throttle Control TC
Engine Control EH
Door locking DL

17. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Developing a new car with AUTOSAR 17
Functions of the car
Brake control BC
Throttle Control TC
Engine Control EH
Door locking DL
Mapping of SWC to ECU
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)
DL
Software
Components
(SWCs)
ECU Extract FilesAn extract is created for
each ECU...

18. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemWith AUTOSAR 18

19. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
New Terms in AUTOSAR
19

20. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
START With AUTOSAR
20
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables
Mapping of SWC to ECU
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)

21. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
START With AUTOSAR
21
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables
Source: www.autosar.org

22. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 1: Input Descriptions
 The input description step contains three descriptions:
 Software Components: This description is independent
of the actual implementation of the software component.
Among the necessary data to be specified are the
interfaces and the hardware requirements.
 System: The system topology (interconnections between
ECUs) need to be specified together with the available
data busses, used protocols, function clustering and
communication matrix and attributes (e.g. data rates,
timing/latency, …).
 Hardware: The available hardware (processors, sensors,
actuators, …) needs to be specified together with the
signal processing methods and programming capabilities
22
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables

23. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 2: System Configuration
 This step distributes the software component
descriptions to the different ECU. This is an iterative
process where ECU-resources and system-constraints
are taken into account.
23
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables

24. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Templates and Description Files 24

25. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
System Constraint
Description
 The AUTOSAR “System Constraint
Description” contains the following
information:
 Information of network topology
 Limitations (“Constraints”)
 Protocol
 Given communication matrix (PDUs, signals, …)
 Baud rate, timing
 Structure and format are described by the
“System Template”.
25
SYSYEM
Description

26. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Resource Description
 The AUTOSAR “ECU Resource Description” contains the following
Information.
 Description of the hardware being used
 Sensors, actuators
 Memory
 Processor
 Communications periphery
 Pin assignments
 The structure and format are described by the “ECU Resource
Template”.
26

27. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Software Component Description
 The AUTOSAR “Software Component
Description” contains the followinginformation
 Ports and Interfaces (sender/receiver,
client/server)
 Runnable Entities with trigger events, port access,
etc
 Resource needs of the component (memory, CPU
time, etc.)
 Structure and format are described by the
“Software Component
 Template”.
27

28. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 1 & 2
28
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables

29. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Workflow with OEM and
TIER1
 OEM creates an ECU-
specific extract of the
vehicle system design
 TIER1 configures
AUTOSAR ECU based on
this extract
29
Mapping of SWC to ECU
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)
An extract is created for
each ECU...

30. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 3: ECU-configuration
 In this step, the Basic Software and
the Run Time Environment of each
electronic control unit (ECU) is configured.
 This is based on the dedication of the
application software components to each ECU.
30
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables
BASIC Software Layer

31. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Configuration
31
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables

32. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Configuration
32

33. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is a parameter?
33
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables

34. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Containers and Parameters
34
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables

35. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 4: Generation of Software
Executables
 Based on the configuration of the previous
step, the software executables are generated
by the Generator.
 For this step, it’s necessary to specify the
implementation of each software component.
35
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables

36. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Component development process
36

37. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Executable ECU
37
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables

38. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
4 Steps 38
Functions of the car
Brake control BC
Throttle Control TC
Engine Control EH
Door locking DL
Mapping of SWC to ECU
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)
DL
Software
Components
(SWCs)
ECU Extract FilesAn extract is created for
each ECU...
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables

39. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR architecture
39

40. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR architecture
 The AUTOSAR architecture is
using a layered approach consisting of a
total of three software layers running on
top of a microcontroller.
 These three layers are called, starting at
the bottom, BSW, RTE and finally
Application Layer (AL). An
introduction to each layer will be
presented below.
40

41. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Basic Software
 the BSW layer is a layer in itself,
internally it consists of four sub-layers
 Microcontroller Abstraction Layer
 ECU Abstraction Layer
 Complex Drivers Layer
 Services Layer
41

42. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Microcontroller Abstraction Layer
 The Microcontroller Abstraction Layer
(MCAL) is located at the very bottom of the
BSW layer.
 MCAL uses its internal software drivers to
directly communicate with the
microcontroller.
 These drivers include: memory,
communication and I/O drivers. The task of
the layer is to make layers above it
microcontroller independent.
 When the MCAL is implemented it is
microcontroller dependent but provides a
standardized and microcontroller
independent interface upwards in the stack
thus fulfilling its purpose
42
Source: www.autosar.org

43. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Abstraction Layer
 Located on top of the MCAL is the ECU Abstraction Layer
(ECUAL).
 Internally it has drivers for external devices and uses the
interface defined by the MCAL to access drivers at the lowest
level.
 Layers higher up in the stack can use the provided API to gain
access to devices and peripherals without having to know
anything about the hardware, for example, whether or not a
device is located internally or externally, what the
microcontroller interface looks like etc.
 The ECUAL aims to make upper layers independent of how the
ECU is structured.
 implementation the ECUAL is microcontroller independent but
dependent on the ECU hardware;
 Upper layers interfacing the ECUAL are no longer dependent on
either of them (microcontroller and ECU Hardware).
43

44. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Complex Drivers Layer
 Typically this layer is used to integrate special purpose
functionality and functionality currently being migrated from
a previous system
 Since this is the layer between the microcontroller and the
RTE, drivers for devices with strict timing constraints can
benefit from being placed in the CDL as the multi-layered
parts of the BSW layer is likely to introduce overhead due to
additional layers and standardization.
 Drivers for devices not compliant with AUTOSAR can also be
put here
 “How does the standard support migration from existing
solutions?”
 The introduction and creation of Complex Drivers in the
AUTOSAR standard can be used to migrate existing solutions
44

45. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Services Layer
 The top sub-layer in the BSW layer is called
Services Layer (SL). Along with operating
system functionality the SL provides a collection
of managers such as: memory-, network-,
and ECU state management. This is also
where diagnostic services reside.
45
Source: www.autosar.org

46. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Runtime Environment
 The RTE is the layer between the application layer
and the BSW layer. It provides the application
software with services from the service layer.
 All communication between SWCs, either on
the same ECU or different ones, or services are
done via the RTE.
 The main task of the RTE is to make the layer
above and below it completely independent of each
other.
 In other words, SWCs running on an ECU have no
idea what the ECU looks like hence a SWC will be
able to run on different looking ECUs without any
modifications
 Logically the RTE can be seen as two sub-parts
realizing different SWC functionality:
 Communication
 Scheduling
46
Source: www.autosar.org

47. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Virtual Function Bus
47
 It provides generic communication services
that can be consumed by any existing
AUTOSAR software component.
 Although any of these services are virtual,
they will then in a later development phase be
mapped to actual implemented methods, that
are specific for the underlying hardware
infrastructure.
 In virtual speciation of the communication
topology and interaction between components
which is done via the virtual function bus,
 the runtime environment provides an actual
implementation for these artifacts.
It could also be said that the runtime environment
provides an actual representation of the virtual
concepts of the VFB for one specific ECU.

48. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Example VFB to RTE mapping where the virtual communication topology is
mapped to three different ECU's
48
Source: www.autosar.org
 Each ECU has its own customized RTE
implementation which is generated
during the ECU Configuration process
.
The Depending on the location of each
component, the formerly virtual interaction
can then be mapped to real interaction
implementation.
 components that are mapped onto one
ECU will communicate through Intra
ECU-Mechanisms, like function calls
while Inter-ECU communication will be
realized using, e.g. a communication bus
infrastructure.

49. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Example for the body of a runnables source code
(Pseudo-Code)
49
Listing of AUTOSAR RTE API method prefixes for the
various send and receive communication modes

50. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Usage of the RTE API within a sender and receiver-
communication channel
50

51. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
RTE Send API implementation for Intra- and Inter-ECU
communication
51

52. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
RTE Receive API implementation for Intra- and
Inter-ECU communication
52

53. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Runnable Entities and Basic Software Schedulable
Entities to tasks (informative)
 RunnableEntity:
 A RunnableEntity represents the smallest code-fragment that is provided
by an AtomicSwComponentType and are executed under control of the
RTE.
53
Concepts of instantiation
Single instantiation Multiple instantiation

54. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Runnable Entities and Basic Software Schedulable
Entities to tasks (informative)
 The RTE-Configurator uses parts
of the ECU Configuration of
other BSW Modules, e.g. the
mapping of RunnableEntitys to
OsTasks. In this configuration
process the RTE-Configurator
expects OS objects (e.g. Tasks,
Events, Alarms...) which are used in
the generated RTE and Basic
Software Scheduler.
54
Source: www.autosar.org

55. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Category 1 RunnableEntitys to Basic Tasks 55
Source: www.autosar.org

56. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Category 1
RunnableEntitys to Extended Tasks
56
Source: www.autosar.org

57. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Inter task activation and mapping of runnable to
individual task for monitoring purpose
57
Source: www.autosar.org

58. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemRTE Implementation Example 1:
Without OsEvent
 Description of the example:
 RunnableEntity RE1 is activated by TimingEvent 100ms T1.
 RunnableEntity RE2 is activated by TimingEvent 100ms T2.
 RunnableEntity RE3 is activated by TimingEvent 100ms T3.
 Execution order of the RunnableEntitys shall be R1, R2 then R3. RE2 shall be monitored.
 Possible RTE configuration:
 RE1/T1 is mapped to OsTask TaskA with RtePositionInTask equal to 1.
 RE2/T2 is mapped to OsTask TaskB but virtually mapped to TaskA with RtePositionInTask equal to 2.
 RE3/T3 is mapped to OsTask TaskA with RtePositionInTask equal to 3.
 Possible RTE implementation: RTE starts cyclic OsAlarm with 100ms period. This OsAlarm is
configured to activate TaskA.
 Non preemptive scheduling is configured for Task A.
 TaskB priority = TaskA priority + 1
58
Source: www.autosar.org

59. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemRTE Implementation Example 2:
With OsEvent
 Description of the example:
 RunnableEntity RE1 is activated by DataReceivedEvent DR1.
 RunnableEntity RE2 is activated by DataReceivedEvent DR2.
 RunnableEntity RE3 is activated by DataReceivedEvent DR3. Evaluation order of the
RTEEvents shall be DR1, DR2 then DR3. All the runnables shall be monitored.
 Possible RTE configuration:
 RE1 is mapped to OsTask TaskB but virtually mapped to TaskA with a reference to OsEvent
EvtA and RtePositionInTask equal to 1.
 RE2 is mapped to OsTask TaskC but virtually mapped to TaskA with a reference to OsEvent
EvtB and RtePositionInTask equal to 2.
 RE3 is mapped to OsTask TaskD but virtually mapped to TaskA with a reference to OsEvent
EvtC and RtePositionInTask equal to 3.
 Possible RTE implementation:
 RTE set EvtA, EvtB and EvtC according to the callbacks from COM. Full preemptive
scheduling is configured for Task A.
 TaskB priority = TaskC priority = TaskD priority = TaskA priority + 1
59
Source: www.autosar.org

60. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
RTE APIs on RTE Specifications
https://www.autosar.org
60

61. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Application Layer
 SWCs are such a key part of this layer and
AUTOSAR and have as a result been awarded a
dedicated section.
 Creating SWCs and the behavior in the AL can be
done freely according to what a particular vendor
wants
 One restriction though is that all communication with
other components, whether it is intra- or inter-
communication, has to be achieved in a standardized
way by using the RTE.
61

62. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
The AUTOSAR Adaptive Platform
for Connected and Autonomous
Vehicles
62

63. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Adaptive AUTOSAR Use Cases
63

64. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Definition of Adaptive AUTOSAR
64

65. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemClassic Platform vs. Adaptive
Platform
65

66. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Another platform for different
applications
66

67. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
67
Source: www.autosar.org

68. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemClassic Platform vs. Adaptive
Platform
68
Source: www.autosar.org

69. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Architecture – machine level
69
Source: www.autosar.org

70. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Communication
software
components and
architecture
70

71. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automative buses
71

72. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Example using CAN
72
Source: www.autosar.org

73. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is Next ?
 We will create a MCAL “(Microcontroller Abstraction Layer)” Drivers
For Atmega32 according to Autosar Specifications
73
MCAL (Microcontroller
Abstraction Layer)
MCAL is a software module that
directly accesses on-chip MCU
peripheral modules and external
devices that are mapped to memory,
and makes the upper software layer
independent of the MCU.
Details of the MCAL software module
are shown below.

74. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
How to write
DIO AUTOSAR
MCAL for
atmega32
74
main.c
DIOMCAL LAYER

75. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
How to write DIO MCAL for
atmega32  Read First
AUTOSAR_SWS_DIODriver.pdf from
Autosar.org
75
Source: www.autosar.org

76. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
DIO Driver
Structure and
Integration
76
Source: www.autosar.org

77. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dependencies to other modules
77

78. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
File structure
78

79. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
API service ID’s
79
Source: www.autosar.org

80. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Error classification
80
Source: www.autosar.org

81. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Type definitions
81
Source: www.autosar.org

82. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Version Number
82

83. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemFunction Prototypes 83
Source: www.autosar.org

84. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_Cfg.h
84
Atmega32
A0
A7
B8
B15
c16
c23
D24
D31
Assuming the Pins Mapped as :

85. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
85

86. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
86

87. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
87

88. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
88

89. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
89

90. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
90

91. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
91

92. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
92

93. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Prepare your self for the next
session
(AUTOSAR OS)
And
(AUTOSAR APPlication Layer)
#LEARN_IN_DEPTH 
93

94. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 https://www.autosar.org
 Embedded Microcomputer Systems Real Time Interfacing Third
Edition Jonathan W. Valvano University of Texas at Austin.
 MicroC/OS-II the real-time kernel second edition jean j.labrosse.
 RTOS Concepts http://www.embeddedcraft.org.
 OSEK/VDX Operating System Specification 2.2.3
 AUTOSAR Layered Software Architecture
 The Trampoline Handbook release 2.0
 Trampoline (OSEK/VDX OS) Test Implementation -Version 1.0,
Florent PAVIN ; Jean-Luc BECHENNEC
94

95. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Trampoline:an open platform for (small) embedded systems based on
OSEK/VDX and AUTOSAR
http://trampoline.rts-software.org/
Jean-Luc Béchennec1;2, Sébastien Faucou1;3
1IRCCyN (Institute of Research in Communications and Cybernetics of Nantes)
2CNRS (National Center for Scientific Research) / 3University of Nantes
10th Libre Software Meeting
95

96. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Real Time Systems (RETSY)
Jean-Luc Béchennec - Jean-Luc.Bechennec@irccyn.ec-nantes.fr
Sébastien Faucou - Sebastien.Faucou@univ-nantes.fr
jeudi 12 novembre 15
 AUTOSAR Specification of Operating System V5.0.0 R4.0 Rev 3
 OSEK - Basics http://taisnotes.blogspot.com.eg/2016/07/osek-basic-
task-vs-extended-task.html
 OSEK OS Session Speaker Deepak V.
M.S Ramaiah School of Advanced Studies - Bangalore 1
 Introducción a OSEK-OS - El Sistema Operativo del CIAA-Firmware
Programación de Sistemas Embebidos
MSc. Ing. Mariano Cerdeiro
96

97. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Introduction to AUTOSAR, Stephen Waldron, Vector webinar
Wednesday 7th May 2014
https://vector.com/portal/medien/cmc/events/Webinars/2014/Vector_
Webinar_AUTOSAR_Introduction_20140507_EN.pdf
 Introduction to AUTOSAR, Stephen Waldron, Vector webinar
Tuesday 5th May 2015
https://vector.com/portal/medien/cmc/events/Webinars/2015/Vector_
Webinar_AUTOSAR_Introduction_20150505_EN.pdf
97

98. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Applying AUTOSAR in Practice Available Development Tools and
Migration Paths Master Thesis, Computer Science Authors: Jesper
Melin
http://www.idt.mdh.se/utbildning/exjobb/files/TR1171.pdf
Freescale AUTOSAR Software Overview.pdf
98

99. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 AUTOSAR Method, Vector Webinar 2013-04-17
https://vector.com/portal/medien/cmc/events/Webinars/2013/Vector_Web
inar_AUTOSAR_Method_20130417.pdf
 AUTOSAR Configuration Process - How to handle 1000s of parameters
Vector Webinar 2013-04-19
https://vector.com/portal/medien/cmc/events/Webinars/2013/Vector_Web
inar_AUTOSAR_Configuration_Process_20130419_EN.pdf
 AUTOSAR Runtime Environment and Virtual Function Bus, Nico Naumann
https://hpi.de/fileadmin/user_upload/fachgebiete/giese/Ausarbeitungen_A
UTOSAR0809/NicoNaumann_RTE_VFB.pdf
99

100. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 The AUTOSAR Adaptive Platform for Connected and Autonomous
Vehicles, Simon Fürst, AUTOSAR Steering Committee 8th Vector
Congress 29-Nov-2016, Alte Stuttgarter Reithalle, Stuttgart,
Germany
https://vector.com/congress/files/presentations/VeCo16_06_29Nov_Re
ithalle_Fuerst_BMW.pdf
 A Review of Embedded Automotive Protocols, Nicolas Navet1,
Françoise Simonot-Lion2 April 14, 2008
https://www.realtimeatwork.com/wp-
content/uploads/chapter4_CRC_2008.pdf
100

101. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 AUTOSAR Adaptive Platform
https://vector.com/conference_india/files/presentations/Day1/3_AUTO
SAR%20Adaptive%20Platform.pdf
101

102. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 http://www.autosar.org/about/technical-overview/ecu-software-
architecture/autosar-basic-software/
 http://www.autosar.org/standards/classic-platform/
 https://automotivetechis.files.wordpress.com/2012/05/communicationsta
ck_gosda.pdf
 https://automotivetechis.files.wordpress.com/2012/05/autosar_ppt.pdf
 https://automotivetechis.wordpress.com/autosar-concepts/
 https://automotivetechis.files.wordpress.com/2012/05/autosar_exp_laye
redsoftwarearchitecture.pdf
 http://www.slideshare.net/FarzadSadeghi1/autosar-software-component
 https://www.renesas.com/en-
us/solutions/automotive/technology/autosar/autosar-mcal.html
 https://github.com/parai/OpenSAR/blob/master/include/Std_Types.h
102

103. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
103

104. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
104