Automotive embedded systems part5 v2

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

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Handbook
2
AUTOSAR
Layer
Model
AUTOSAR
OS
AUTOSAR
System
Services
AUTOSAR
BSW
AUTOSAR
Work
process and
activities
AUTOSAR
Safety
AUTOSAR
SW layer
AUTOSAR
RTE
AUTOSAR
interfaces

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Introduction to AUTOSAR
it's time to wake up 
Learn In Depth 
3

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
4

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
5
(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

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
6
(AUTomotive Open System ARchitecture)

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Reusability
7

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automotive industry
8

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automotive industry
9
Source: www.autosar.org

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Layered Architecture
10

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR: Specifications
11
www.autosar.org

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR: Specifications
12
www.autosar.org

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR is still growing
13

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is the AUTOSAR standard
and why is it created?
14

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
15

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR
Benefits
16

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

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Developing a new car with AUTOSAR 18
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...

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemWith AUTOSAR 19

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
New Terms in AUTOSAR
20

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
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
START With AUTOSAR
22
Executables

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 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
23
Executables

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 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.
24
Executables

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Templates and Description Files 25

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”.
26
SYSYEM
Description

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”.
27

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”.
28

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 1 & 2
29
Step 1: Input
Descriptions
Step 2: System
Configuration
Executables

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
30
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)
An extract is created for
each ECU...

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 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.
31
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration
Step 4: Generation of
Software Executables
BASIC Software Layer

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Configuration
32
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Configuration
33

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is a parameter?
34
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Containers and Parameters
35
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
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.
36
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Component development process
37

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Executable ECU
38
Step 1: Input
Descriptions
Step 2: System
Configuration
Step 3: ECU-
configuration

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
4 Steps 39
Brake control BC
Throttle Control TC
Engine Control EH
Door locking DL
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...
Executables

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR architecture
40

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.
41

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
42

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
43

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).
44

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
45

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.
46

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What the AUTOSAR Basic Software Module (BSW)
responsible for ?
47

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What the AUTOSAR Basic Software Module (BSW)
responsible for ?
AUTOSAR has defined a set of BSW modules.
They are responsible for different tasks:
 Operating System
 Access to non volatile memory
 Communication via CAN, LIN, FlexRay and Ethernet Handling the
diagnostics
 Access to I/O ports
 System services like ECU state management
 In addition, so-called Complex Device Drivers can be integrated into
an AUTOSAR ECU. They are used to access the features of the ECU,
which are not covered by the standard BSW of AUTOSAR
48

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Basic Software Module (BSW)
49
BASIC SOFTWARE (BSW) Stacks
i) Service stack: General services
ii) Comstack: Communication stack
for intra-ECU or inter-ECU
communication
iii) Memstack: Memory stack. Stack
of software modules which provide
services to access the memory
resources of ECU.
iv) Diagstack: Diagnosis stack.. v)
IO stack: Input Output Stack.

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
The AUTOSAR
communication stack for
FlexRay
Module
Name
Description
FlexRay
Interface
The purpose of the FlexRay Interface module is to provide a generally specified
interface to the communication system for the upper layer modules, e.g. PDU Router
and COM.
It extracts the number of FlexRay drivers and
manages the synchronization to global FlexRay time.
FlexRay Network
Management
This module is responsible for the FlexRay network management. It
coordinates the transition between normal operation and bus-sleep
mode of the network.
FlexRay State
Manager
The FlexRay State Manager controls and monitors the wakeup and startup of
the node in the FlexRay cluster.
FlexRay Transport
Layer
The FlexRay transport protocol segments long data packets in the transmit
direction, collects data in the receive direction and controls the data flow.
Errors such as message loss, message duplication or sequencing errors are detected.
FlexRay
Transceiver Driver
The driver for an external FlexRay transceiver is responsible for
Network diagnostics and switching a transceiver on and off.
50

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
The AUTOSAR
communication stack for
FlexRay
Module
Name
Description
AUTOSAR
COM
AUTOSAR COM is a module between the RTE and the PDU Router. It is responsible for
providing Signal level access to the application layer and PDU level access
to the lower layers independent of the protocol.
It packs the signals to a PDU at the transmitter and unpacks the received PDU to
provide signal level access to the application at the receiver. At the PDU level, COM is
responsible for grouping of the PDUs, starting and stopping of the PDU groups.
PDU Router
PDU Router is a module responsible for routing the PDU to the respective
Bus Specific Interface modules.
Above the PduR module all the PDUs are protocol independent, and below PduR all
the PDUs are routed to the protocol specific modules. PduR is also responsible for
PDU level gatewaying i.e. transmitting the received PDU from one Bus Specific
Interface module to other Bus Specific Interface module.
Gatewaying can also be done when a PDU is to be routed from
one controller to another over the same protocol.
51

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is AUTOSAR Communication Stack (ComStack)?
Introduction to CAN Communication Stack
52

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is AUTOSAR Communication Stack (ComStack)?
Introduction to CAN Communication Stack
 Depending on the Bus Type of the in-vehicle network
(such as CAN, LIN, Flex-Ray), implementation of the
communication stack is executed.
 A generic Communication Stack in AUTOSAR layered
architecture is a set of following software modules:
 AUTOSAR COM – part of the Services Layer
 Bus Specific Interface Modules – part of the ECU
Abstraction Layer (For example -CanIf, LinIf, FrIf)
 External Bus Drivers – part of the ECU Abstraction Layer
(For example – External drivers likeCanDrv, LinDrv,
FlexrayDrv)
 Internal Bus Drivers – part of the AUTOSAR MCAL (For
example – CanDrv, LinDrv, FrDrv)
53

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Communication Stack
 List of different modules of the CAN
Communication Stack ComStack:
 COM(Services Layer)
 PDU Router(Services layer)
 CAN State Manager(Services Layer)
 CAN Network Manager(Services Layer)
 CAN Transport Protocol(Services Layer)
 CAN Interface(ECU Abstraction Layer)
 External CAN Driver(ECU Abstraction Layer)
 CAN Driver(MCAL Layer)
54

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Communication Stack
 Can TP: The basic services offered by the Can TP module are segmentation of
messages which have a payload of more than 8 bytes, transmission of the
messages with flow control and reassembling the segmented messages at the
receiver.
 Can Interface: CAN Interface(CanIf) is a module in the ECU Abstraction Layer
which is responsible for services like Transmit Request, Transmit
Confirmation, Reception Indication, Controller mode control and PDU
mode control.
 Can State Manager (CanSM): This module shall implement the control flow for the
respective bus.
 CanNm: The AUTOSAR CAN Network Management is a hardware independent
protocol tools that can only be used on CAN network.Its main purpose is to
coordinate the transition between normal operation and bus-sleep mode of
the network. The CAN Network Management (CanNm) function provides an
adaptation between network Management Interface (NmIf) and CAN Interface
(CanIf) module.
 Can Driver (CanDrv): This module is a part of the MCAL layer and provides
hardware access to the upper layer services and a hardware-independent interface
to the upper layers. CanIf is the only module that can access the CAN driver.
55

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Stacks for CAN/LIN/FlexRAY
56

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is the Diagnostic Communication Manager (DCM)
57

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 The main purpose of the DCM is providing
a common API for diagnostic services. It
is used while development, manufactoring
or service by external diagnostic tools.
 In the AUTOSAR Architecture the
Diagnostic Communication Manager is
located in the Communication Services
(Service Layer).
58

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 The DCM module is network-independent.
All network-specific functionality (the specifics
of networks like CAN, LIN, FlexRay ) is handled
outside of the DCM module. The PDU Router
(PduR) module provides a network-independent
interface to the DCM module.
 The DCM module receives a diagnostic message
from the PduR module. The DCM module
processes and checks internally the diagnostic
message.
 As part of processing the requested diagnostic
service, the DCM will interact with other BSW
modules or with SW-Components (through the
RTE) to obtain requested data or to execute
requested commands. This processing is very
service-specific. Typically, the DCM will
assemble the gathered information and send a
message back through the PduR module.
59

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Memory Stack
60

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 Memory Stack (MemStack) provides basic
memory management services to the upper
Application layer and to the Basic Software
Modules (BSW) of the AUTOSAR layered
architecture.
 Non-Volatile Memory Manager (NvM)
 The NvM module ensures data storage and
maintenance of NV (non volatile) data
according to the individual requirements in an
automotive environment.
 The NvM module manages the NV data of an
EEPROM and/or a FLASH EEPROM emulation
device.
61

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 Memory Interface (MemIf) Module:
 The Memory Abstraction Interface (MemIf)
module facilitates abstraction from the
underlying FEE and EA modules. Hence MemIf
module provides upper layer (NvM) with a
virtual segmentation on a uniform linear
address space.
 This ensures that the Non-Volatile Memory
Manager (NvM) is independent of the driver
interface layers of EEPROM (Eep) and Flash
interface (Fls)
62

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 EEPROM Abstraction(Ea.):
 EPROM driver provides services for reading,
writing, erasing data to/from an EEPROM.
It also provides a service for comparing a
data block in the EEPROM with a data block
in the memory (e.g. RAM).
 Ea module facilitates abstraction from the
addressing scheme of underlying EEPROM driver
and hence provides a uniform addressing scheme.
 This ensures that the upper layer (NvM) need
not be changed if the underlying EEPROM driver
and device is replaced.
63

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 Flash EEPROM Emulation (FEE) Module:
 The Flash EEPROM Emulation (FEE) abstracts from the
device, a specific addressing scheme and segmentation.
 This provides the upper layers (NvM) with a virtual
addressing scheme, segmentation as well as a virtually•
unlimited number of erase cycles.
 Flash Driver (Fls):
 Fls Driver Initializes Flash and reads/writes to Flash
memory.
 EEPROM driver (EeP):
 EEPROM driver provides services for reading, writing,
erasing to/from an EEPROM.
 It also provides a service for comparing a data block in
the EEPROM with a data block in the memory (e.g.
RAM).
64

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
I/O Hardware Abstraction
 The I/O Hardware Abstraction
represents the connection between
the RTE and the I/O channels of
the ECU. It encapsulates access to
the I/O drivers such as ADC, DIO
or PWM, thereby making available
the ECU’s I/O signals.
65

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
System Services on BSW
66

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
67
Module Name Description
ECU State Manager EcuM
The ECU State Manager performs the initialization/de-initialization of all
basic software modules, including the RTE and the operating system
(OS). The module controls the operating state of an ECU (Sleep,
Startup, Wakeup, Shutdown, and Run) based on system events.
Communication
Manager
ComM
This module controls the state of all communication channels connected to
the ECU and provides a bus-independent interface to the SWCs (and thereby
their application) for requesting external communication.
Function Inhibition
Manager FIM
This module controls (enable/disable) functionalities of SW components based on
the conditions such as faults, signal quality, ECU and vehicle states, diagnostic
tester commands, etc.
Diagnostic Event
Manager DeM
This module implements error memory as per manufacturer-
specific documentation. A standardized interface for diagnostic monitors allow
for uniform, cross-manufacturer development of software components. The
DEMs module is responsible for administrating the Diagnostic TroubleCode
statuses, the error environment data, and for storing the data in NVRAM.

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
68
Module Name Description
Development
Error Tracer (Det)
This module supports error searches during software development
and provides an interface for error reporting. This interface is called
from the individual BSW modules in an error situation.
BSW Scheduler
The SCHM module calls the cyclic function for the individual BSW
modules and makes available the functions that the BSW modules
need to call at the beginning and end of critical sections. This
Module is part of RTE (Runtime Environment in R4.0)
Watchdog Interface This module provides uniform access to services of the
watchdog driver (WDG), such as mode switching and
triggering.
Watchdog
Manager
The Watchdog Manager monitors the reliability and functional assurance of the
application in an ECU. This includes monitoring the correct execution of the
SWCs and BSW modules, and the triggering of Watchdog at the required time
intervals. Where resumption of normal operation is impossible, the Watchdog
hardware performs a reset of the microcontroller.

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
BSW Conclusion
69

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
BSW Conclusion
70
The Microcontroller Abstraction Layer contains internal drivers, which
are software modules with direct access to the micro controller and
internal peripherals.
The ECU Abstraction Layer offers uniform access to all features of an
ECU like communication, memory or I/O, no matter if these features are
part of the microcontroller or realized by peripheral components. The
drivers for such external peripheral components reside in this layer.
The Service Layer provides various types of background services such as
vehicle network communication and management services, diagnostic
services, memory management, ECU state management, mode management
and Logical and temporal program flow monitoring. The operating system is
also part of this layer.
The RTE integrates the application layer with the BSW. It implements the data
exchange and controls the integration between the application software
component (SWCs) and BSW.
The Application Layer contains the SWCs, which realize the application
functionality of the ECU.

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
71

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Virtual Function Bus
72
 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.

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
73
 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.

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR System Design
74

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Example for the body of a runnables source code
(Pseudo-Code)
75
Listing of AUTOSAR RTE API method prefixes for the
various send and receive communication modes

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Usage of the RTE API within a sender and receiver-
communication channel
76

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
RTE Send API implementation for Intra- and Inter-ECU
communication
77

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
RTE Receive API implementation for Intra- and
Inter-ECU communication
78

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.
79
Concepts of instantiation
Single instantiation Multiple instantiation

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.
80

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Category 1 RunnableEntitys to Basic Tasks 81

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Category 1
RunnableEntitys to Extended Tasks
82

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
83

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.
 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
84

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
85

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
RTE APIs on RTE Specifications
https://www.autosar.org
86

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.
87

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
The AUTOSAR Adaptive Platform
for Connected and Autonomous
Vehicles
88

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Adaptive AUTOSAR Use Cases
89

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Definition of Adaptive AUTOSAR
90

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemClassic Platform vs. Adaptive
Platform
91

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Another platform for different
applications
92

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
93

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemClassic Platform vs. Adaptive
Platform
94

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Architecture – machine level
95

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Communication
software
components and
architecture
96

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automative buses
97

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Example using CAN
98

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
99
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.

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
How to write
DIO AUTOSAR
MCAL for
atmega32
100
main.c
DIOMCAL LAYER

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
101

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
DIO Driver
Structure and
Integration
102

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dependencies to other modules
103

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
File structure
104

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
API service ID’s
105

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Error classification
106

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Type definitions
107

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Version Number
108

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemFunction Prototypes 109

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_Cfg.h
110
Atmega32
A0
A7
B8
B15
c16
c23
D24
D31
Assuming the Pins Mapped as :

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
111

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
112

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
113

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
114

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel() Dio_ReadChannel()
115
#define no_of_pins 8
#define port_number ((channel_ID)/(no_of_pins))

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Dio_WriteChannel()
Dio_ReadChannel()
116

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
117

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
118

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 
119

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
120

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
121

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
122

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
123

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
124

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
125

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
126

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
 AUTOAR Specification of Diagnostic Communication Manager
https://www.autosar.org/fileadmin/user_upload/standards/classic/3-
1/AUTOSAR_SWS_DCM.pdf
 Automotive & Embedded Info
https://automotiveembeddedsite.wordpress.com/memory-stack/
127

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
128

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
129

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
130

Automotive embedded systems part5 v2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Automotive embedded systems part5 v2

Similaire à Automotive embedded systems part5 v2 (20)

Plus de Keroles karam khalil

Plus de Keroles karam khalil (19)

Dernier

Dernier (20)

Automotive embedded systems part5 v2