BGSV Embedded Academy (BEA)

Focused Program to Develop Embedded Competence

BGSV EMBEDDED ACADEMY

Technical Methodological
Process Competence
Competence Competence
T1: Automotive Basics
(Sensor, SW, Mobility P1: Requirements
M1: SW Development Engineering
Solution) Lifecycle
T2: Automotive SW
Architecture (AUTOSAR) P2: Design Principles

T3: Embedded Programming P3: Review

M3: Clean Code

T5: Test Overview P4: Safety & Security

Classroom training, Online Self-learning, Live Demo

Purpose: Develop basic general embedded competence
Disclaimer

 This slide is a part of BGSV Embedded Academy (BEA) program and only used for
BEA training purposes.

 This slide is Bosch Global Software Technology Company Limited’s internal property.
All rights reserved, also regarding any disposal, exploitation, reproduction, editing,
distribution as well as in the event of applications for industrial property rights.

 This slide has some copyright images and text, which belong to the respective
organizations.
 T2
AUTOMOTIVE SOFTWARE
ARCHITECTURE
WHAT IS
SOFTWARE
ARCHITECTURE?
What is Software Architecture
Build a house
 Surveyor plan  Floor plan  2D or 3D views  Implementation

Plot environment (adjacent to Position and size of walls, wall 3D representation of the building Physical realization: built home
neighbors‘ plots), permissible and openings, floors and ceilings or parts of it. Location and views of (ready to move in).
used building footprint furniture and fixtures. Virtual tour
inside the object.

6
What is Software Architecture
How to build an ECU
 E/E architecture  Circuit  PCB Layout  Implementation

Network and electrical Logical wiring of components Physical location and wiring of Physical realization: anufactured
environment of the ECU describing electrical functions components (considering of non- Electronic Control Unit to be
functional requirements like EMV, installed into the vehicle.
heat dissipation, physical
interfaces to housing)

7
What is Software Architecture
How to build a software product – Oversimplify

8
What is Software Architecture
How to build a software product – Architectural Views

 Context view  Deployment view

Embedding of SW systems (as black Environment in which the SW is
box) in its environment, interfaces to running: HW components running the
neighboring systems (e.g. through SW, processors, network topologies
different communication channels) and protocols, as well as further
(Relation with new E/E architectures). physical components of the system
environment. The component view
+ change within the environment is optional.

 Component view Implementation

(+interfaces)  Dynamic runtime view
Static (hierarchical) composition of Description of run time behavior of
the SW system consisting of existing SW elements and their
architectural building blocks, concurrence. Dynamical structures.
subsystems, SW components and
their interfaces.

9
What is Software Architecture
What is an architecture
Definition of Architecture (IEEE, 2011-12-01): According to this definition architectures describe:
architecture <system> fundamental concepts or  fundamental concepts on which corresponding
properties of a system in its environment embodied in systems are built,
its elements, relationships, and in the principles of its  the environment where the system under design
design and evolution need to be integrated into,
 components which the system consists of, and
 relations between the components and the
environment.
What is Software Architecture
Quiz time
 Select the three most often used architecture views:
(a) Physical database view
(b) Context view
(c) Building Block/Component view
(d) Test-driven view
(e) Configuration view
(f) Runtime view

11
What is Software Architecture
Quiz time
 Select the three most often used architecture views:
(a) Physical database view
(b) Context view
(c) Building Block/Component view
(d) Test-driven view
(e) Configuration view
(f) Runtime view

12
WHAT IS
AUTOSAR?
What is AUTOSAR
AUTOSAR Vision
 AUTOSAR aims to improve complexity management of integrated E/E architectures through
increased reuse and exchangeability of SW modules between OEMs and suppliers.

Exchangeability
between suppliers’
Platform solutions Platform
a.1, a.2, a.n b.1, b.2, b.n

Supplier A Supplier B Supplier C

Platform • Chassis • Chassis • Body/Comfort Platform
f.1, f.2, f.n • Safety • Safety • Powertrain c.1, c.2, c.n
• Body/Comfort • Telematics • Telematics

Exchangeability
Exchangeability between vehicle
between manufacturers’ Platform Platform
platforms
applications e.1, e.2, e.n d.1, d.2, d.n
What is AUTOSAR
Aims and benefits of using AUTOSAR
 AUTOSAR aims to standardize the software architecture of Electronic Control Units (ECUs).
AUTOSAR paves the way for innovative electronic systems that further improve performance,
safety and security.
• Hardware and software –
Proprietary widely independent of each
other.
• Development can be de-
Application Application Software coupled (through abstraction)
Software Standardized
Standardized Middleware Methodology by horizontal layers, reducing
development time and costs.
Standardized Basic
Basic Software • Reuse of software
Software Hardware specific HW-specific enhances quality and
(ECUs) efficiency
Hardware Hardware

15
What is AUTOSAR
More Than 280 AUTOSAR Partners
9 Core Partners

58 Premium Partners 2 Strategic Partners

53 Development Partners
+ 152 Associate
Partners
+ 29 Attendees

16
What is AUTOSAR
AUTOSAR Deliverables Most common type of deliverables
• ATS: Acceptance Test Specification
• CONC: Concept document
Legend • EXP: Explanation document
Released as an own standard • MMOD: Meta-model files (M2)
Released as part of the standard it is extending
• MOD: Model files (M1)
A B A extends B
• PRS: Protocol Specification
• RS/SRS: Requirement Specification
A B A planned to extend B
• SWS: Software Specification
• TPS: Template Specification
Acceptance Application Sensor • TR: Technical Report
Test Interfaces Interfaces
AUTOSAR SVN copy @Bosch:
file://///si8256.de.bosch.com/AUTOSAR$/SVN3-
COPY/26_Standards/02_Releases/
Classic Platform Adaptive Platform
AUTOSAR Docupedia @Bosch:
https://inside-
Common documents and
Foundation docupedia.bosch.com/confluence/display/AUT
specifications for all standards

17
AUTOSAR LAYERED Architecture
AUTOSAR Layered Architecture
Top View
The AUTOSAR Architecture distinguishes on the highest abstraction level between three software layers:
Application, Runtime Environment and Basic Software which run on a Microcontroller.

Application Layer

Runtime Environment (RTE)

Basic Software (BSW)

Microcontroller
AUTOSAR Layered Architecture
Coarse view
The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction, Microcontroller
Abstraction and Complex Drivers.

Application Layer

Runtime Environment

Services Layer

Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller

20
AUTOSAR Layered Architecture
Detailed view
The Basic Software Layers are further divided into functional groups. Examples of Services are System, Memory
and Communication Services.

Application Layer

Runtime Environment
System Services Memory Crypto Services Off-board Communication I/O Hardware Complex
Services Communication Services Abstraction Drivers
Services

Onboard Device Memory Crypto Wireless Communication

Abstraction Hardware Hardware Communication Hardware
Abstraction Abstraction HW Abstraction Abstraction

Microcontroller Memory Drivers Crypto Drivers Wireless Communication I/O Drivers

Drivers Communication Drivers
Drivers

Microcontroller

21
AUTOSAR Layered Architecture
Microcontroller Abstraction Layer
The Microcontroller Abstraction Layer is the lowest software
Application Layer
layer of the Basic Software.
It contains internal drivers, which are software modules with direct RTE
access to the µC and internal peripherals.
Co
mpl
Task ECU Abstraction Layer ex
Driv
Make higher software layers independent of µC ers
Microcontroller Abstraction Layer

Properties Microcontroller

Implementation: µC dependent
Upper Interface: standardized and µC independent

22
AUTOSAR Layered Architecture
ECU Abstraction Layer
The ECU Abstraction Layer interfaces the drivers of the
Application Layer
Microcontroller Abstraction Layer. It also contains drivers for
external devices. RTE
It offers an API for access to peripherals and devices regardless of
their location (µC internal/external) and their connection to the Co
µC (port pins, type of interface) mpl
ex
ECU
ECU Abstraction
Abstraction Layer
Layer
Driv
ers
Task Microcontroller Abstraction Layer

Make higher software layers independent of ECU hardware layout Microcontroller

Properties
Implementation: µC independent, ECU hardware dependent
Upper Interface: µC and ECU hardware independent

23
AUTOSAR Layered Architecture
Complex Drivers
The Complex Drivers Layer spans from the hardware to the RTE.
Application Layer

Task RTE

Provide the possibility to integrate special purpose functionality, Services Layer

e.g. drivers for devices:

Complex
Drivers
➢ which are not specified within AUTOSAR, ECUECU Abstraction
Abstraction Layer
Layer

➢ with very high timing constrains or Microcontroller Abstraction Layer

➢ for migration purposes etc.
Microcontroller

Properties
Implementation: might be application, µC and ECU hardware
dependent
Upper Interface: might be application, µC and ECU hardware
dependent

24
AUTOSAR Layered Architecture
Services Layer
The Services Layer is the highest layer of the Basic Software
which also applies for its relevance for the application software: Application Layer

while access to I/O signals is covered by the ECU Abstraction

Layer, the Services Layer offers: RTE

➢ Operating system functionality Services Layer

➢ Vehicle network communication and management services

Complex
Drivers
➢ Memory services (NVRAM management) ECUECU Abstraction
Abstraction Layer
Layer
➢ Diagnostic Services (including UDS communication, error memory and
fault treatment) Microcontroller Abstraction Layer
➢ ECU state management, mode management
Microcontroller
➢ Logical and temporal program flow monitoring (Wdg manager)
Task
Provide basic services for applications, RTE and basic software
modules.
Properties
Implementation: mostly µC and ECU hardware independent
Upper Interface: µC and ECU hardware independent

25
AUTOSAR Layered Architecture
AUTOSAR Runtime Environment (RTE)
The RTE is a layer providing communication services to the application
software (AUTOSAR Software Components and/or AUTOSAR Application Layer

Sensor/Actuator components).
AUTOSAR Runtime Environment (RTE)

Above the RTE the software architecture style changes from “layered“ to Services Layer
“component style“.

Complex
Drivers
ECUECU Abstraction
Abstraction Layer
Layer
The AUTOSAR Software Components communicate with other components
Microcontroller Abstraction Layer
(inter and/or intra ECU) and/or services via the RTE.
Microcontroller
Task
Make AUTOSAR Software Components independent from the mapping to a
specific ECU.

Properties
Implementation: ECU and application specific (generated individually for
each ECU)
Upper Interface: completely ECU independent

26
AUTOSAR Basic Software
Quiz time
 From the top to bottom, how many software layers of the highest
abstraction level of AUTOSAR architecture?
(a) 3 layers: Application, RTE, BSW.
(b) 5 layers: Application, RTE, Service layer, ECU Abstraction layer, MCAL.
(c) 3 layers: Services layer, Abstraction layer, MCAL.
(d) 4 layers: Application, RTE, BSW, MCAL.

RTE = Runtime Environment

BSW = Basic Software
MCAL = Microcontroller Abstraction Layer

27
AUTOSAR Basic Software
Quiz time
 From the top to bottom, how many software layers of the highest
abstraction level of AUTOSAR architecture?
(a) 3 layers: Application, RTE, BSW.
(b) 5 layers: Application, RTE, Service layer, ECU Abstraction layer, MCAL.
(c) 3 layers: Services layer, Abstraction layer, MCAL.
(d) 4 layers: Application, RTE, BSW, MCAL.

RTE = Runtime Environment

BSW = Basic Software
MCAL = Microcontroller Abstraction Layer

28
AUTOSAR Layered Architecture
Quiz time
 Which of the following qualities can most likely be improved by
using a layered architecture?
(a) Runtime efficiency (performance).
(b) Flexibility in modifying or changing the system.
(c) Flexibility at runtime (configurability).
(c) Non-repudiability.

29
AUTOSAR Layered Architecture
Quiz time
 Which of the following qualities can most likely be improved by
using a layered architecture?
(a) Runtime efficiency (performance).
(b) Flexibility in modifying or changing the system.
(c) Flexibility at runtime (configurability).
(c) Non-repudiability.

30
AUTOSAR BASIC
SOFTWARE
AUTOSAR Basic Software
What is “Basic SW”?

Basic Software
/ˈbeɪ.sɪk/, adj /ˈsɑːft.wer/, noun
simple and not complicated, so able to the instructions that control what a computer
provide the base or starting point from which does; computer programs [cambridge.org]
something can develop [cambridge.org]

32
AUTOSAR Basic Software
What is “basic” to Embedded Software?
Embedded Software
ECU Function A
ECU Function B

ECU Function C
BSW

Communication
Schedule
Memory

…
I/O

33
 AUTOSAR Basic Software REF

Types of BSW modules

BSW Module

On-chip Driver Manager

A driver contains the functionality to Off-chip Driver Handler A manager offers specific
control and access an internal or an
Interface
services for multiple clients. It is
External devices are located on the A handler is a specific interface
external device. An Interface (interface module) needed in all cases where pure
ECU hardware outside the which controls the concurrent,
microcontroller. contains the functionality to handler functionality is not enough
Internal devices are located inside the multiple and asynchronous access
microcontroller. Examples for internal devices abstract from modules which are to abstract from multiple clients.
of one or multiple clients to one or
are: Examples for external devices are: architecturally placed below them.
- Internal EEPROM - External EEPROM more drivers. Besides handler functionality, a manager can
- Internal CAN controller - External watchdog evaluate and change or adapt the content of
- Internal ADC - External flash E.g., an interface module which abstracts I.e. it performs buffering, queuing, arbitration, the data.
A driver for an internal device is called internal A driver for an external device is called from the hardware realization of a specific multiplexing. In general, managers are located in the
driver and is located in the Microcontroller external driver and is located in the ECU device. It provides a generic API to access a The handler does not change the content of Services Layer
Abstraction Layer. Abstraction Layer. It accesses the external specific type of device independent on the the data. Example: The NVRAM manager manages
device via drivers of the Microcontroller number of existing devices of that type and Handler functionality is often incorporated in the concurrent access to internal and/or
Abstraction Layer. independent on the hardware realization of the driver or interface (e.g. SPIHandlerDriver, external memory devices like flash and
This way also components integrated in the different devices. ADC Driver). EEPROM memory. It also performs
System Basis Chips (SBCs) like transceivers The interface does not change the content of distributed and reliable data storage, data
and watchdogs are supported by AUTOSAR. the data. checking, provision of default values etc.
Example: a driver for an external EEPROM In general, interfaces are located in the ECU
with SPI interface accesses the external Abstraction Layer.
EEPROM via the handler/driver for the SPI Example: an interface for a CAN
bus. communication system provides a generic
API to access CAN communication networks
independent on the number of CAN
Controllers within an ECU and independent of
the hardware realization (on chip, off chip).
34
AUTOSAR Basic Software
Question 1
Map BSW module type to the suitable layer

Services Layer

On-chip Driver

Off-chip Driver
Complex
ECU Abstraction Layer Drivers
Interface

Handler

Manager
Microcontroller Abstraction Layer

35
AUTOSAR Basic Software
BSW Vertical view / Stack view

Application Layer

Runtime Environment BSW Layers

System
System Services Mem
Memory Crypto
Crypto Services Com
Communication I/O Hardware
I/O Complex
Complex Services
Services Services Abstraction Drivers
Stack Stack Stack Stack Stack Drivers

ECU Abstraction
Onboard Memory Crypto Communication
and Complex
Device Hardware Hardware Hardware
Drivers
Abstraction Abstraction Abstraction Abstraction

Microcontroller Memory Drivers Crypto Drivers Communication I/O Drivers Micro-controller

Drivers Drivers Abstraction

Microcontroller

36
AUTOSAR BASIC
SOFTWARE:
COMMUNICATION
STACK
AUTOSAR Basic Software
Communication Stack – Building Blocks
ComStack facilitates vehicle network
Application Layer communication and provides
communication services to other
BSW components and Application
AUTOSAR Runtime Environment (RTE) BSW-Layers Layer.

System Services Memory Communication I/O Hardware Complex Services

ComStack is consisting of Bus-
Services Services Abstraction Drivers dependent and Bus-independent
components. The following bus
system are covered by AUTOSAR:
Onboard Device Memory Comm. ECU
- CAN(TT)
Abstraction Hardware Hardware Abstraction - LIN
Abstraction Abstraction and Complex - FlexRay
Drivers - Ethernet
Micro-controller Memory Drivers Communi-cation I/O Drivers Micro- Different bus system follows the same
Drivers Drivers controller layered architecture but defines their
Abstraction
components distinctly. CAN is chosen
to represent ComStack in this
Microcontroller document.

38
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.) RTE

Layers
Signals Communication
Layer Communication Services is a group of modules for vehicle Manager
network communication with the communication system CAN.
Task:
- Provide a uniform interface to the CAN network Diagnostic
IPDU CAN State Generic
- Hide protocol and message properties from the application. multi- AUTOSAR Communi- Manager NM interface
Debugging
plexer COM cation
Manager
NM
Coordinator
I-PDU I-PDU I-PDU I-PDU
Layer Communication Hardware Abstraction is a group of modules
which abstracts from the location of communication controllers and the PDU Router
ECU hardware layout.
- Provide equal mechanisms to access CAN bus channel regardless I-PDU
I-PDU1 I-PDU1 NM
NM
of it‘s location (on-chip / on-board) Module
NM
Module
NM
CAN Tp Module
- µC independent, ECU hardware dependent and external device J1939Tp Module
dependent
N-PDU N-PDU

Communication
HW
Layer Microcontroller Abstraction contains internal drivers, which are CAN Interface2 Abstraction
software modules with direct access to the µC internal peripherals and
L-PDU
memory mapped µC external devices.
- Make higher software layers independent of µC Communication Drivers

CAN Driver2

39
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.) RTE

Components
Signals Communication
Com Manager
- Provides signal-oriented data interface to the RTE
- Packing/unpacking of AUTOSAR signals to I-PDUs
- Provides routing of individual signals or groups of signals between Diagnostic
IPDU CAN State Generic
different I-PDUs multi- AUTOSAR Communi- Manager NM interface
Debugging
plexer COM cation
Manager
NM
PduR Coordinator
I-PDU
- Provides routing of PDUs between different abstract communication I-PDU I-PDU I-PDU

controllers and upper layers

- Provides TP routing on-the-fly. Transfer of TP data is started before PDU Router

full TP data is buffered

I-PDU1 I-PDU1 NM
I-PDU NM
Module
NM
Module
NM
CAN Tp Module
<BusType>Tp J1939Tp Module
- The main purpose of the TP module is to segment and reassemble
(CAN) I-PDUs longer than 8 bytes N-PDU N-PDU

Communication
<BusType>If HW
Abstraction
- Provides a unique interface to manage different hardware device CAN Interface2
types e.g., CAN controllers and CAN transceivers used by the defined L-PDU
ECU hardware layout
Communication Drivers

CAN Driver2

40
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.) RTE

Components
Signals Communication
ComM Manager
- Collects the bus communication access requests from
communication requestors (Applications, Complex Drivers) and
coordinates the bus communication access requests. Diagnostic CAN State
IPDU Generic
- Triggers the Start-up and Shut-down the hardware units of the multi- AUTOSAR Communi- Manager NM interface
Debugging
communication systems plexer COM cation
Manager
NM
Coordinator
<BusType>SM I-PDU I-PDU I-PDU I-PDU

- Handles the communication system dependent Start-up and

Shutdown features PDU Router

I-PDU1 I-PDU1 NM
I-PDU NM
Module
NM
Nm CAN Tp
Module
NM
Module
- Acts as a bus-independent adaptation layer between the bus-specific J1939Tp Module
Network Management modules and the Communication Manager
N-PDU N-PDU
module (ComM)
- Synchronization of Network States of different communication
Communication
channels connected to an ECU via the network managements HW
handled by the NM Coordinator CAN Interface2 Abstraction

L-PDU
<BusType>Nm
Communication Drivers
- Coordinate the transition between normal operation and bus-sleep
mode of the network. CAN Driver2

41
AUTOSAR Basic Software REF

Communication Stack – Runtime: transmission and reception

System Signals and ISignals are introduced to distinguish Generic interface at VFB. SystemSignal_S
Data exchanged as System Signals.
between the unique pieces of data transferred between
SWCs and the interaction layer signal used to distribute Rte
Generic interface. ISignal_S1 ISignal_S2
this data to multiple receivers. Data exchanged as I-Signals.
Com
A PDU (Protocol Data Unit) is the information delivered Generic interface. Pdu1 Pdu2
through a network layer Data exchanged as I-PDUs.
PduR
A Frame is a piece of information that is exchanged over Bus Type dependent interface. Can_PDU
Data exchanged as I-PDUs.
the communication channels
CanIf
Can Driver Instance dependent interface e.g. rba_Can_MCan_Write PDU, HW Handler
ISO Layer Layer AUTOSAR Modules PDU Name Data exchanged as L-PDU and HW Handler.
Prefix
Can 1 Can 2
Layer 6: I COM, DCM I-PDU
Presentation I PDU router, PDU I-PDU Can Frames on physical network CanFrame1 CanFrame2
(Interaction) multiplexer

Layer 3: N TP Layer N-PDU

Network Layer
Layer 2: L Driver, Interface L-PDU
Data Link Layer

42
 AUTOSAR Basic Software REF

Communication Stack – Runtime (cont.)

RTE

Communication
Signals
Manager

BswM PDU Router

FlexRay
Secure Diagnostic Eth State TTCAN State CAN State LIN State Generic
Diagnostic State
SOME/IP Onboard IPDU AUTOSAR Communi- Manager Manager Manager Manager NM interface
I-PDUs Log and Manager
TP Communi- Multiplexer COM cation
Trace
cation Manager
Sd DoIP
NM Coordinator
I-PDUs I-PDUs I-PDU I-PDU I-PDU I-PDU I-PDU I-PDU
UDP NM

Socket Adaptor

XCP
PDU Router
Messages Streams
Ethernet Protocol
TCP/IP Communication

I-PDU1 I-PDU1 NM
DHCP I-PDU I-PDU1 I-PDU I-PDU NM
Module
NM
UDP TCP Module
NM
CAN Tp Module
Services

FlexRay Tp Module
Packet Segment J1939Tp

N-PDU N-PDU N-PDU

IPv4/v6
ARP/ND ICMP
Datagram Communication
HW
LIN Interface Abstraction
Communication HW Eth Interface FlexRay Interface CAN Interface2
(incl. LIN TP)
Eth Interface Abstraction
Eth. Frame L-PDU L-PDU L-PDU L-PDU

Communication Drivers Communication Drivers

Eth Driver
Eth Driver FlexRay Driver CAN Driver 2 LIN Low Level Driver

I-PDU: Interaction Layer PDU Note: This image is not complete with 1 The Interface between PduR and Tp differs significantly compared to the interface between PduR and the Ifs.
N-PDU: Network Layer PDU respect to all internal communication In case of TP involvement a handshake mechanism is implemented allowing the transmission of I-Pdus > Frame size.
L-PDU: Data Link Layer PDU paths. 2 CanIf with TTCAN serves both CanDrv with or without TTCAN. CanIf without TTCAN cannot serve CanDrv with TTCAN.

43
AUTOSAR Basic Software REF

Communication Stack – OSEK COM Layer Model

It’s the foundation of AUTOSAR ComStack!
ISO/OSI
Interaction Layer (IL) OSEK OS (OSEK Operating System) Model
• Provides the OSEK COM API which contains services for the transfer (send Application
and receive operations) of messages. Application
• For external communication it uses services provided by the lower layers,
whereas internal communication is handled entirely by the IL. Presentation
OSEK COM
Network Layer Session
OSEK NM
• Handles – depending on the communication protocol used – message Interaction Layer
Transport
(OSEK Network
segmentation/recombination and acknowledgement. Management) Network
• Provides flow control mechanisms to enable the interfacing of communication
peers featuring different levels of performance and capabilities. Network Layer Data Link Layer
• The Network Layer uses services provided by the Data Link Layer. (DLL)
• OSEK COM does not specify the Network Layer; it merely defines minimum
requirements for the Network Layer to support all features of the IL.
Data Link Layer

Data Link Layer

• Provides the upper layers with services for the unacknowledged transfer of
Bus Communication Hardware Physical
individual data packets (frames) over a network.
• Provides services for the NM.
• OSEK COM does not specify the Data Link Layer; it merely defines minimum
requirements for the Data Link Layer to support all features of the IL.

OSEK: Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen (DE) or Open Systems and the Corresponding Interfaces for Automotive Electronics (EN).

44
AUTOSAR Layered Architecture
Quiz time
 Which component is responsible for distribution of Pdu for inter-
and intra-ECU communication?
(a) Com.
(b) PduR.
(c) ComM.
(c) Rte.

45
AUTOSAR Layered Architecture
Quiz time
 Which component is responsible for distribution of Pdu for inter-
and intra-ECU communication?
(a) Com.
(b) PduR.
(c) ComM.
(c) Rte.

46
AUTOSAR Layered Architecture
Quiz time
 Which statement below is not correct when talking about data
exchange in AUTOSAR?
(a) On Application layer, System Signal is being exchanged without
context of bus system.
(b) Two Signal can be packed inside a Pdu. Two Pdus can be packed
inside a Frame.
(c) I-Pdu is data unit at Interaction layer. L-Pdu is data unit of Data-link
layer.
(c) N-Pdu is data unit at Transport layer, which is mandatory for all
AUTOSAR systems.

47
AUTOSAR Layered Architecture
Quiz time
 Which statement below is not correct when talking about data
exchange in AUTOSAR?
(a) On Application layer, System Signal is being exchanged without
context of bus system.
(b) Two Signal can be packed inside a Pdu. Two Pdus can be packed
inside a Frame.
(c) I-Pdu is data unit at Interaction layer. L-Pdu is data unit of Data-link
layer.
(c) N-Pdu is data unit at Transport layer, which is mandatory for all
AUTOSAR systems.

48
AUTOSAR Layered Architecture
Quiz time
 What are the drawbacks of AUTOSAR?
(a) Standardization by aggregation.
(b) It is huge.
(c) Moving target.
(c) All of above.

49
AUTOSAR Layered Architecture
Quiz time
 What are the drawbacks of AUTOSAR?
(a) Standardization by aggregation.
(b) It is huge.
(c) Moving target.
(c) All of above.

50
 CLASSIC AUTOSAR
USE CASE

Source: AUTOSAR Introduction, AUTOSAR Consortium

 Classic AUTOSAR Use Case
Use Case ‘Front Light Management’: Exchange Type of Front Light
Integrator Supplier B OEM Supplier A
SwitchEvent LightRequest Front-Light Manager Headlight
check_switch () switch event (event) request_light (type, mode) set_light (type, mode)
get_keyposition()
set_light (type, mode) set_current (…)
Switch_event (event) request_light (type, mode)
set_dboard(type, mode)
AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE
Integrator

Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR

Interface Interface Interface Interface Interface
Services Communication ECU Abstraction
Std. Interface Std. Interface Std. Interface
Standardized
Interface

Operating
Silicon Vendor A

Complex
System Drivers
Standardized Interface
DIO PWM CAN Driver
Microcontroller Abstraction
ECU-Hardware

52
of
65
AUTOSAR Introduction 8 July
 Classic AUTOSAR Use Case
Use Case ‘Front Light Management’: Exchange Type of Front Light
Integrator Supplier B OEM Supplier A
SwitchEvent LightRequest Front-Light Manager Xenonlight
Headlight
check_switch () switch event (event) request_light (type, mode) set_light (type, mode)
set_light(type, mode)
get_keyposition()
set_light (type, mode) set_current (…)
set_current(…)
Switch_event (event) request_light (type, mode)
set_dboard(type, mode)
AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE
Integrator

Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR

Interface Interface Interface Interface Interface
Services Communication ECU Abstraction
Std. Interface Std. Interface Std. Interface
Standardized
Interface

Operating
Silicon Vendor A

Complex
System Drivers
Standardized Interface
DIO DIO
PWM CAN Driver
Microcontroller Abstraction
ECU-Hardware

53
of
65
AUTOSAR Introduction 8 July
Classic AUTOSAR Use Case
Distribution ECUs
SwitchEvent LightRequest
LightRequest Front-Light Manager Xenonlight
check_switch () switch_event(event) request_light(type, mode) set_light(type, mode)
switch_event request_light get_keyposition()
set_light(type, mode) set_current (…)
(event) (type, mode)
AUTOSAR Int. AUTOSAR
AUTOSAR Interface
Interface AUTOSAR Interface AUTOSAR Interface

54
of
65
AUTOSAR Introduction 8 July
Classic AUTOSAR Use Case
Distribution on ECUs – ‘Front-Light Management’
SwitchEvent LightRequest Front-Light Manager Xenonlight
check_switch () switch_event(event) request_light(type, mode) set_light(type, mode)
get_keyposition()
switch_event request_light set_light(type, mode) set_current (…)
(event) (type, mode)
AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE AUTOSAR RTE AUTOSAR RTE

Std. AUTOSAR AUTOSAR Standardized Standardized Standardized AUTOSAR
Interface Interface Interface Interface Interface Interface
Services ECU Abstraction Communication Communication Communication ECU Abstraction
Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface
Xenonlight

Std. Interface
set_light(type, mode)

set_current (…)

AUTOSAR Interface

LightRequest
switch_event(event)

request_light
(type, mode)

AUTOSAR Interface

Standardized Interface Standardized Interface Standardized Interface

DIO CAN Driver CAN Driver

Front-Light Manager
request_light(type, mode)
get_keyposition()
CAN Driver PWM
set_light(type, mode)

AUTOSAR Interface

Microcontroller Abstraction Microcontroller Abstraction Microcontroller Abstraction

ECU-Hardware ECU-Hardware
ECU-Hardware

CAN Bus
55
of
65
AUTOSAR Introduction 8 July
CAN
PROTOCOL
Introduction
Vehicle network

57
Introduction
History
Maximum Bitrate Mbit/s

Year

58
Introduction
Characteristics of ‘CAN’
• CAN is a multi-master Bus
• Theoretically No limitation on the number of nodes
• Configuration flexibility - No node addressing
• Prioritization of messages through “Identifiers”
• Multicast reception with the time synchronization
• System wide data consistency
• Guarantee of latency times
• Error detection and error signaling
• Automatic retransmission of corrupted messages
• Temporary errors - permanent failures of nodes and autonomous
switching off defect nodes

59
Introduction
CAN in the OSI model

60
CAN Protocol
Physical Layer
➔ Bit rate: up to 1Mbit/s
➔ Bidirectional Dual-wire bus with 40-50m maximum in length
➔ Multi-Master
CAN bus level
Vehicle

Volt
OBD connector

61
CAN Protocol
Relation between Baud Rate and Bus Length

62
CAN Protocol
Bus Access and Arbitration
• Bus access through CSMA with AMP
NODE Arbitration phase
Remainder
A 0 1 0 0

B 0 1 0 1

C 0 1 1 0 Node B looses
arbitration
Node C looses
BUS 0 1 0 0
arbitration

• Advantages
• No Collision
• Transmission of highest priority message within the latency time

63
CAN Protocol
Message Transfer
Frame Formats
• Standard Frame - 11bit Identifier
• Extended Frame - 29 bit Identifier

Frame Types
• Data Frame
• Remote Frame (not useful)
• Error Frame
• Overload Frame (not useful)
• Inter-frame Spacing

64
CAN Protocol
Data Frame
Standard Data Frame Format
Arbitration Control Field Data Field CRC Field ACK End of Inter
Field Frame mission
Field -

SOF

RTR
IDE
11 Bit Identifier DLC (4) 0 to 64 Bits 15 Bits 7 Bits 3 Bits

r0
Bus Idle CRC Delimiter
Ack Slot Bus Idle
Ack Delimiter

Extended Data Frame Format

SRR Arbitration Field Control Field Data Field
SOF

RTR
IDE
11 Bit Identifier 18 Bit Identifier DLC (4) 0 to 64 Bits

r1
r0
Difference between Standard Frame and Extended Frame
• Differs only in Arbitration field and Control field
65
CAN Protocol
Error Frame
Error Frame Format (Active Error Frame)
Error Condition

Uncompleted Error Frame Inter-

Frame mission

6 Bits 0 -6 Bits 8 Bits 3 Bits

Superposition of Error Delimiter

Error Flag

• Error flag can start within the frame that is currently being transmitted

Types of Error flags

• Active Error flag - consists of 6 consecutive ‘dominant’ bit
• Passive Error flag - consists of 6 consecutive ‘recessive’ bit

66
CAN Protocol
Error Handling
The mode of the controller is controlled by two error
counters - the transmit error counter (tx_count) and the
receive error counter (rx_count).

The following rules apply:

➢ The CAN controller is in error active mode if:
tx_count <= 127 AND rx_count <= 127.
➢ Passive mode is used if :
tx_count > 127 or rx_count>127 AND tx_count <= 255.
➢ Bus off is entered if:
tx_count > 255.

67
CAN Protocol
Interframe Spacing
After the transmission of a frame by an Error Active node

Previous Frame Interframe Spacing Next frame

3 Bits

Inter- Bus idle

mission

After the transmission of a frame by an Error Passive node

Previous Frame Interframe Spacing Next frame

3 Bits 8 Bits

Inter- Suspend Bus idle

mission Transmission

68
CAN Protocol
Message Coding
Non-Return-to-Zero coding
• Keeps the frequency of the signal on the bus to minimum.

“1”
“0”

1 1 0 1 0 0 1 1 ………………..

Bit-Stuffing
• Ensures sufficient Recessive and Dominant edges for Re-Synchronization.
Data Stream
1 1 2 3 4 5 6 7 8 9 101 2 3 1 2 1 2 3 4 5 6 1 2

Bit Stream
1 1 2 3 4 5 S 6 7 8 9 10S 12 3 1 2 1 2 3 4 5 S 6 1 2

69
CAN Protocol
Types of Error Detected in CAN Bus
CRC Error:
• Every node receive the message, Calculate CRC and compare it with Received CRC.

Acknowledge Error:
• Transmitting node send a ACK slot bit as a recessive bit and check for dominant bit to verify reception.

Form Error:
• Generated when any of following bit is detected as a dominant bit where One should not be.
e.g. CRC delimiter, ACK delimiter, End of Frame, Inter Frame Space.

Bit Error:
• Node detect the signal that is opposite of what it send on Bus.

Stuff Error:
• Bit stuffing rule is violated when 6-consecutive bits with the same polarity are detected.
70
Introduction about CAN FD

Main improvement:
• Increase bit rate ( 2,4 … up to 8 Mbit/s)
• Increase payload up to 64 bytes

71
Reference
-CAN Specification 2.0 – Bosch

-ISO 11898-2 – High speed CAN

-ISO 11898-2 2015 – CAN FD

72
DIAGNOSIS
OVERVIEW
Definitions
Diagnosis – What?
“In automotive engineering, Diagnosis is typically used to determine the
causes of symptoms and solutions to issues.”
 symptom(s) – what the user/operator/repairer of the system (vehicle or
whatever) notices;
 fault(s) – the error(s) in the system that result in the symptom(s);
 root cause(s) – the cause(s) of the fault.

Source: Advanced Automotive Fault Diagnosis- Automotive

Technology: Vehicle Maintenance and Repair
TOM DENTON

74
Definitions
Diagnosis – How?[1]
To do Diagnostic, Technician have to know how to use Diagnostic Tools
and Equipment.
Tool and Equipment could be classified into:
 Basic Equipment: such as Multi-meter
 Tracing Tool: like Oscilloscope
 Scanner/Fault Code Readers and Analyzers.

75
Definitions
Diagnosis – How?[2]
 The Equipment shall help technician indicate where is fault occurs in
systems.
 In the other word, In Vehicle, Systems should have ability to provide
information in case request.
 This is the motivation of On-board diagnostics (OBD).

 On-board diagnostics (OBD) is a generic term referring to a vehicle’s

self-diagnostic and reporting system. OBD systems give the vehicle
owner or a technician access to information for various vehicle systems.
 OBD system illuminates a warning lamp known as the malfunction
indicator lamp (MIL) or malfunction indicator (MI) on the instrument
cluster.

76
Definitions
Diagnosis – How?[3]
 When the fault occurs, the system stores a diagnostic trouble code
(DTC), also store important information of the vehicle when the fault was
set.
 A service technician is able to connect a diagnostic scan tool or a code
reader that will communicate with the system and retrieve this
information.
 As vehicles and their systems become more complex, the functionality
of OBD is being extended to cover vehicle systems and components
that do not have anything to do with vehicle emissions control: Vehicle
body, chassis and accessories
 OBD systems use a standardized communications port to provide data
 The Communication between Diagnostic Equipment and ECUs through
Vehicle Special Interface for Diagnosis purpose is called Diagnostic
Communication.
77
Definitions
States and Events
 Everything about the car is either in a "normal" state or an "abnormal"
state.
 Either the car is starting normally or it is not. Either the engine is running
normally or it is not.
 Used in this way, "normal" means acceptable, the way they are
supposed to be, okay. "Abnormal" means not acceptable, not the way
they are supposed to be, not okay.
 The purpose of all automobile repair is to correct abnormal states and
restore the car to its normal state of operation.

78
Definitions
States and Events
 An "event" is when something happens: a spark plug fires, the brakes
are applied, a fuel injector opens, a relay closes.
 An event is a change of state, from one condition to another.
 A "normal event" occurs when something happens just as it is supposed
to happen.
 An "abnormal event" is when something happens that is not supposed
to happen: the engine quits unexpectedly, the car fails to stop when the
brakes are applied.
 All automotive complaints can be described and understood in terms of
abnormal events: some things are happening which are not supposed to
happen, and the driver has noticed them.

79
Diagnosis Uses

 Diagnosis is used to detect the fault in the system.

 Use to read the parameters like WSS signal, SAS signal, YRS signal etc.

 Used for calibration of Steering Angle sensor, Lateral , Longitudinal

sensor etc.

 Use to run EOL(End of Line) routines.

 Used for reprogramming.

80
On board and Off board Diagnosis

Normally, the information is exchanged between an on-board ECU and an off-board

diagnostic tester.

81
Diagnosis Protocols
Unified Diagnostic Services (UDS)

82
Diagnosis Protocols
Emissions-related diagnostics (emissions-related OBD)

83
Diagnosis Protocols
ECU(server) – Tester(client) communication

 Tester sends a request\command to ECU, to perform certain action.

 ECU sends a response message to the corresponding request.

84
Request and response
Overview
Positive response Negative Response

 Tester sends a request to perform  Tester sends a request to perform

software reset. software reset.
 ECU returns a positive response.  ECU returns a negative response
indicating software reset can not
be performed.
85
Request and response
Overview

86
Request and response
Overview

Request Positive Response Description

0x00 .. 0x0F 0x40 .. 0x4F OBD in ISO 15031-5 Emissions-related diagnostic services

0x10 .. 0x3E 0x50 .. 0x7E UDS in ISO 14229

0x83 .. 0x87 0xC3 .. 0xC7 KWP2000 in General vehicle diagnostics
0x81.. 0x82 0xC1 .. 0xC2 KWP2000 over K-line in ISO 14230

0xA0 .. 0xB9 0xE0 .. 0xF9 Reverse for OEM

0xBA .. 0xBE 0xFA ..0xFE Reverse for ECU manufacturers

Others Reverse

87
Request and response
Negative response

88
Diagnosis mode

➔ Normal Mode (Default)

➔ Test Mode / Adjustment mode

➔ Reprogramming mode

89
Addressing

Functional Address:
Physical Address:

90
Definitions
Milestones
 1969: Volkswagen introduces the first on-board computer system with
scanning capability, in their fuel-injected Type 3 models.
 1975: Datsun 280Z On-board computers begin appearing on consumer
vehicles, largely motivated by their need for real-time tuning of fuel
injection systems. Simple OBD implementations appear, though there is
no standardization in what is monitored or how it is reported.
 1980: General Motors implements a proprietary interface and protocol
for testing of the Engine Control Module (ECM) on the vehicle assembly
line. The 'assembly line diagnostic link' (ALDL) protocol communicates
at 160 baud with Pulse-width modulation (PWM) signalling and monitors
very few vehicle systems.

91
Definitions
Milestones
 1986: An upgraded version of the ALDL protocol appears which
communicates at 8192 baud with half-duplex UART signalling. This
protocol is defined in GM XDE-5024B.
 ~1987: The California Air Resources Board (CARB) requires that all
new vehicles sold in California starting in manufacturer's year 1988
(MY1988) have some basic OBD capability. These requirements are
generally referred to as "OBD-I", though this name is not applied until
the introduction of OBD-II. The data link connector and its position are
not standardized, nor is the data protocol.
 1988: The Society of Automotive Engineers (SAE) recommends a
standardized diagnostic connector and set of diagnostic test signals.

92
Definitions
Milestones
 ~1994: Motivated by a desire for a state-wide emissions testing
program, the CARB issues the OBD-II specification and mandates that it
be adopted for all cars sold in California starting in model year 1996.
The DTCs and connector suggested by the SAE are incorporated into
this specification.
 1996: The OBD-II specification is made mandatory for all cars sold in
the United States.
 2001: The European Union makes EOBD mandatory for all gasoline
(petrol) vehicles sold in the European Union, starting in MY2001 (see
European emission standards Directive 98/69/EC)).

93
Thank you!

94