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
Agenda

No Part Duration Trainer Training date

Automotive Software
1 2.5 Pham Vo Tuan Anh
Architecture Intro

2 CAN Protocol 6 Mr. Quan (UIT)

Automotive
3 1.5 Nguyen Kien
Diagnostic Overview

5
Trainer Introduction

Pham Vo Tuan Anh

Senior Specialist
AUTOSAR Expert
◾ Master of Science on Elec., Telecom. & Com. Technology ◾ VNU-HCMUS ◾
◾ Bachelor of Science on Electronics and Telecom. ◾ VNU-HCMUS ◾

6
WHAT IS
SOFTWARE
ARCHITECTURE?
What is Software Architecture

How could we be so wrong?

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

9
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)

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

11
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
Dynamic runtime
(+interfaces)
Static (hierarchical) composition of view
the SW system consisting of Description of run time behavior of
architectural building blocks, existing SW elements and their
subsystems, SW components and concurrence. Dynamical structures.
their interfaces.

12
What is Software Architecture
What is an architecture
Definition of Architecture (IEEE, 2011-12-01): According to this definition architectures
architecture <system> fundamental describe:
concepts or properties of a system in its  fundamental concepts on which
environment embodied in its elements, corresponding systems are built,
relationships, and in the principles of its  the environment where the system under
design and evolution design 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

14
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

15
SOFTWARE
ARCHITECTURAL
PATTERN
Software Architectural Pattern
Layered Architecture
Overall agility Low Performance Low
Ease of deployment Low Scalability Low
Testability High Ease of development High
The rating for each characteristic is based on the natural tendency for that characteristic as a capability
based on a typical implementation of the pattern, as well as what the pattern is generally known for.

Key concept:
• Horizontal layers
• Separation of concerns
• Layers are “closed”
• “Monolith” nature
Software Architectural Pattern
Microkernel Architecture
Overall agility High Performance High
Ease of deployment High Scalability Low
Testability High Ease of development Low
The rating for each characteristic is based on the natural tendency for that characteristic as a capability
based on a typical implementation of the pattern, as well as what the pattern is generally known for.

Key concept:
• A core system and plug-in modules
• Plug-in registry
• Minimal interface between plug-in modules
• Toward evolutionary design and incremental development
• “Product” nature
Software Architectural Pattern
Event-Driven Architecture
Overall agility High Performance High
Ease of deployment High Scalability High
Testability Low Ease of development Low
The rating for each characteristic is based on the natural tendency for that characteristic as a capability
based on a typical implementation of the pattern, as well as what the pattern is generally known for.

Key concept:
• Highly decoupled, single-purpose event processing
components
• Mediator or Broker topology
• “Asynchronous” nature
Software Architectural Pattern
Microservices Architecture
Overall agility High Performance Low
Ease of deployment High Scalability High
Testability High Ease of development High
The rating for each characteristic is based on the natural tendency for that characteristic as a capability
based on a typical implementation of the pattern, as well as what the pattern is generally known for.

Key concept:
• Separately deployable units i.e., service components
• Granularity of service component
• Dependencies and orchestration
• “Distributed” nature
Software Architectural Pattern
OSI – Open Systems Interconnection
High-level protocols such as for resource sharing or remote file
Application access, e.g. HTTP.

Translation of data between a networking service and an application;

Presentation including character encoding, data compression and
Host encryption/decryption.
layers Managing communication sessions, i.e., continuous exchange of
Session information in the form of multiple back-and-forth transmissions
between two nodes.

Reliable transmission of data segments between points on a

Transport network, including segmentation, acknowledgement and
multiplexing.

Structuring and managing a multi-node network, including

Network addressing, routing and traffic control.

Media Transmission of data frames between two nodes connected by a

Data Link physical layer.
layers

Transmission and reception of raw bit streams over a physical

Physical medium.

ISO/IEC 7498

21
WHAT IS
AUTOSAR?
What is AUTOSAR
Aims and benefits of using AUTOSAR

• Hardware and software – widely independent of each other.

• Development can be de-coupled (through abstraction) by horizontal layers, reducing
development time and costs.
24 • Reuse of software, enhances quality and efficiency
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

26
What is AUTOSAR
AUTOSAR Deliverables Most common type of deliverables
• ATS: Acceptance Test Specification
• CONC: Concept document
Acceptance Application Sensor • EXP: Explanation document
• MMOD: Meta-model files (M2)
Test Interfaces Interfaces • MOD: Model files (M1)
• PRS: Protocol Specification
• RS/SRS: Requirement Specification
• SWS: Software Specification
• TPS: Template Specification
Classic Platform Adaptive Platform • TR: Technical Report
Legend
Released as an own standard

Released as part of the standard it is extending

Common documents and
specifications for all standards Foundation A B A extends B

A B A planned to extend B

AUTOSAR SVN copy @Bosch: AUTOSAR Docupedia @Bosch:

file://///si8256.de.bosch.com/AUTOSAR$/SVN3- https://inside-
COPY/26_Standards/02_Releases/ docupedia.bosch.com/confluence/display/AUT
27
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
Compl
ex
ECU Abstraction Layer Driver
s
Microcontroller Abstraction Layer

Microcontroller
30
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 Communicatio I/O Hardware Complex
Services Communicatio n Services Abstraction Drivers
n Services

Onboard Memory Crypto Wireless Communicatio

Device Hardware Hardware Communicatio n Hardware
Abstraction Abstraction Abstraction n HW Abstraction
Abstraction
Microcontroller Memory Drivers Crypto Drivers Wireless Communicatio I/O Drivers
Drivers Communicatio n Drivers
n Drivers

Microcontroller

31
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

32
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

33
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

34
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

35
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

36
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
37 MCAL = Microcontroller Abstraction Layer
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
38 MCAL = Microcontroller Abstraction Layer
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).
(d) Non-repudiability.

39
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).
(d) Non-repudiability.

40
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
provide the base or starting point from computer does; computer programs
[cambridge.org]
which something can develop
[cambridge.org]

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

ECU Function C
BSW

Schedule Communication
Memory

…
I/O

43
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

44
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

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

47
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.) RTE

Layers Communication
Signals Service

Layer Communication Services

is a group of modules for vehicle network communication with the communication system CAN.
Task:
- Provide a uniform interface to the CAN network AUTOSAR
- Hide protocol and message properties from the application. COM

I-PDU

Layer Communication Hardware Abstraction PDU Router

is a group of modules which abstracts from the location of communication controllers and the ECU
hardware layout. I-PDU1
I-PDU
- Provide equal mechanisms to access CAN bus channel regardless of it‘s location (on-chip / on-board)
CAN Tp
- µC independent, ECU hardware dependent and external device dependent

N-PDU

Communication
HW

Layer Microcontroller Abstraction CAN Interface2 Abstraction

contains internal drivers, which are software modules with direct access to the µC internal peripherals and L-PDU

memory mapped µC external devices. Communication Drivers

- Make higher software layers independent of µC CAN Driver2

48
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.) RTE

Components Communication
Signals Service

Com
- 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 different I-PDUs AUTOSAR
COM

I-PDU
PduR
- Provides routing of PDUs between different abstract communication controllers and upper layers PDU Router
- Provides TP routing on-the-fly. Transfer of TP data is started before full TP data is buffered
I-PDU1
I-PDU

CAN Tp

<BusType>Tp N-PDU

- The main purpose of the TP module is to segment and reassemble (CAN) I-PDUs longer than 8 bytes
Communication
HW
CAN Interface2 Abstraction

<BusType>If L-PDU

- Provides a unique interface to manage different hardware device types e.g., CAN controllers and CAN Communication Drivers

transceivers used by the defined ECU hardware layout CAN Driver2

49
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.) RTE

AUTOSAR model Communication
Service
RX
Signals

AUTOSAR
COM

I-PDU

PDU Router

I-PDU1
I-PDU

CAN Tp

N-PDU

Communication
HW
CAN Interface2 Abstraction

L-PDU

Communication Drivers

CAN Driver2

50
TX
AUTOSAR Basic Software REF

Communication Stack – Runtime: transmission and reception

OSI Layer Layer AUTOSAR PDU Name
Prefix Modules

7: Application Not in scope of BSW Generic interface at VFB.

SystemSignal_A SystemSignal_B
Data exchanged as System Signals.
Rte
Generic interface.
ISignal_A ISignal_B
Data exchanged as I-Signals.
6: Presentation I COM, DCM I-PDU
(Interaction) Com
Generic interface. IPdu_B
IPdu_A
Data exchanged as I-PDUs.
I PDU router, I-PDU
PduR
PDU Bus Type dependent interface. IPdu_A IPdu_B
multiplexer Data exchanged as I-PDUs.
3: Network N TP Layer N-PDU
CanTp
Can Transport Protocol dependent interface. Npdu_B
Data exchanged as N-PDUs.
2: Data Link L Driver, Interface L-PDU
Can Driver Instance dependent interface e.g.
CanIf
rba_Can_MCan_Write. HwObject_A LPdu_B
Data exchanged as L-PDU and HW Object handler.
Can 1 Can 2
1: Physical Microcontroller, Transceiver, Bus medium
Can Frames on physical network CanFrame_A CanFrame_B

51
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.)

Transmission
RTE
Communication
Service

AUTOSAR
COM

PDU Router

Communication
HW
FlexRay Interface CAN Interface Abstraction

Communication Drivers
FlexRay Driver CAN Driver

52
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.)

Transmission (fan-out)
RTE
Communication
Service

AUTOSAR
COM

PDU Router

Communication
HW
FlexRay Interface CAN Interface Abstraction

Communication Drivers
FlexRay Driver CAN Driver

53
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.)

Reception
RTE
Communication
Service

AUTOSAR
COM

PDU Router

Communication
HW
FlexRay Interface CAN Interface Abstraction

Communication Drivers
FlexRay Driver CAN Driver

54
AUTOSAR Basic Software REF

Communication Stack – Building Blocks (cont.)

Reception + Gateway
RTE
Communication
Service

AUTOSAR
COM

PDU Router

Communication
HW
FlexRay Interface CAN Interface Abstraction

Communication Drivers
FlexRay Driver CAN Driver

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

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

58
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.
(d) Rte.

59
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.
(d) Rte.

60
AUTOSAR Layered Architecture
Quiz time
Which statement below is correct when talking about inter-
ECU data exchange in AUTOSAR?
(a) Com Pdu Transmission can happen in two fashion: top-down or
bottom-up.
(b) Com knows the bus-type of the Pdu it transmit.
(c) Com knows the bus-type of the Pdu it receives.
(d) Transmission is top-down. Reception is bottom-up.

61
AUTOSAR Layered Architecture
Quiz time
Which statement below is correct when talking about inter-
ECU data exchange in AUTOSAR?
(a) Com Pdu Transmission can happen in two fashion: top-down or
bottom-up.
(b) Com knows the bus-type of the Pdu it transmit.
(c) Com knows the bus-type of the Pdu it receives.
(d) Transmission is top-down. Reception is bottom-up.

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

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

64
 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

66
of
65
AUTOSAR Introduction 10 April
 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

67
of
65
AUTOSAR Introduction 10 April
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

68
of
65
AUTOSAR Introduction 10 April
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
69
of
65
AUTOSAR Introduction 10 April
CAN
PROTOCOL
Introduction
Vehicle network

71
Introduction
History
Maximum Bitrate Mbit/s

Year

72
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

73
Introduction
CAN in the OSI model

74
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

75
CAN Protocol
Relation between Baud Rate and Bus Length

76
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

77
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)

78
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
79
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

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

81
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

82
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

83
A complete CAN bus frame

Source: Wikipedia

84
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.
85
Introduction about CAN FD

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

86
Reference
- CAN Specification 2.0 – Bosch

- ISO 11898-2 – High speed CAN

- ISO 11898-2 2015 – CAN FD

- Bit timing calculation: http://www.bittiming.can-wiki.info/

- Return to zero: https://en.wikipedia.org/wiki/Return-to-zero

- None return to zero : https://en.wikipedia.org/wiki/Non-return-to-zero

- CSMA/CD : https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection

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

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

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

92
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.
93
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.

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

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

96
On board and Off board Diagnosis

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

diagnostic tester.

97
Diagnosis Protocols
Unified Diagnostic Services (UDS)

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

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

100
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.
101
Request and response
Overview

102
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

103
Request and response
Negative response

104
Diagnosis mode

➔ Normal Mode (Default)

➔ Test Mode / Adjustment mode

➔ Reprogramming mode

105
Addressing

Functional Address:
Physical Address:

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

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

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

109
UNIFIED
DIAGNOSTIC
SERVICES
Agenda

1. Overview
1. UDS
2. Diagnostic Communication Protocol
3. Related ISO Standards
2. UDS In General
1. Application Layer
2. Session Layer
3. UDS In CAN Implementation

111
Overview
UDS
 (U)nified (D)iagnostic (S)ervices is a diagnostic communication protocol

 UDS is a non-OBD protocol

 Standardized across manufacturers and standards

 Use cases:
 Detect faults in the system
 Read vehicle parameters
 Configuration/Calibration ECUs
 End Of Line Routine
 Reprogramming

112
Overview
Protocol

Protocol: server  client

Positive response Negative response

113
Overview
Related ISO Standards
 Derived and distributed based on OSI model

 UDS specification covers layer 5~7

 Service ID and associated parameters are

contained in the payload of message frame

 Communication protocol covers layer 1~2

114
UDS in General
Application Layer – Services
 Also referred to as Diagnostic Services
 At client side: used to request certain diagnostic functions
 At server side: used to send response data back to client
 6 service primitives are specified
 Service request primitive
 Service request-confirmation primitive
 Service indication primitive
 Service response primitive
 Service response-confirmation primitive
 Service confirmation primitive

115
UDS in General
Application Layer – Request Format
Application Layer Protocol Data Unit (A_PDU)

Protocol Control Service Data Unit (A_SDU)

Information (A_PCI)

Request with only Service ID (SID)

SID Opt. Data

Request with Service ID (SID) and Sub-function (SF)

SID SF Opt. Data

Request with Service ID (SID) and Data ID (DID)

SID DID DID Opt. Data
Request with Service ID (SID), Sub-function (SF) and
Data ID (DID) SID SF DID DID Opt. Data

116
UDS in General
Application Layer – Response Format
Application Layer Protocol Data Unit (A_PDU)

Protocol Control Service Data Unit (A_SDU)

Information (A_PCI)

Positive Response with only Service ID (SID) SID +

0x40 Opt. Data
Positive Response with Service ID (SID) and Sub- SID +
function (SF) 0x40 SF Opt. Data
Positive Response with Service ID (SID) and Data ID SID +
(DID) 0x40 DID DID Opt. Data
Positive Response with Service ID (SID), Sub-function SID +
(SF) and Data ID (DID) 0x40 SF DID DID Opt. Data
Negative Response 0x7F SID NRC

117
UDS in General
Application Layer – Service ID List

118
UDS in General
Application Layer – Common NRC List
Value Response Code Value Response Code
0x00 positiveResponse 0x10 generalReject
0x11 serviceNotSupported 0x12 subFunctionNotSupported
0x13 incorrectMessageLengthOrInvalidFormat 0x21 busyRepeatRequest
0x22 conditionNotCorrect 0x24 requestSequenceError
0x31 requestOutOfRange 0x33 securityAccessDenied
0x35 invalidKey 0x36 exceedNumberOfAttempts
0x37 requiredTimeDelayNotExpired 0x72 generalProgrammingFailure
0x78 responsePending 0x7E subFunctionNotSupportedInActiveSession
0x7F serviceNotSupportedInActiveSession 0x83 engineIsRunning
0x88 vehicleSpeedTooHight 0x93 voltageTooLow

119
UDS in General
Application Layer –
Server Response
Implementation Rules
 General server response behavior upon
receiving a request from client

 Services with sub-function and without sub-

function are handled differently in next steps

 Service 0x31 (only service with both sub-

function and data ID) are also handled
differently

120
UDS in General
Application Layer –
Server Response
Implementation Rules
 General server response behavior upon receiving a
request with sub-function is given in the picture

 There is no general server response behavior for

requests without sub-function

 Server response behavior also depends on

addressing mode (physical/functional) and on
whether “suppress-positive-response” is requested

121
UDS in General
Application Layer – List Of Standardized Services
SID Service Name SID Service Name
Diagnostic & Communication Management
0x10 Diagnostic Session Control 0x11 ECU Reset
0x27 Security Access 0x28 Communication Control
0x3E Tester Present 0x83 Access Timing Parameter
0x84 Secured Data Transmission 0x85 DTC Control Setting
0x86 Response On Event 0x87 Link Control
Data Transmission
0x22 Read Data By Identifier 0x2E Write Data By Identifier
0x23 Read Memory By Address 0x3D Write Memory By Address
0x23 Read Scaling Data By Identifier 0x2C Dynamically Defined Data Identifier
0x2A Read Data By Periodic Identifier
122
UDS in General
Application Layer – List Of Standardized Services
SID Service Name SID Service Name
Stored Data Transmission
0x14 Clear Diagnostic Information 0x19 Read DTC Information
Input Output Control
0x2F Input Output Control By Identifier
Routine
0x31 Routine Control
Upload Download
0x34 Request Download 0x35 Request Upload
0x36 Transfer Data 0x37 Exit Transfer

123
UDS in General
Application Layer – Service $10 – Overview
 Service $10 – Diagnostic Session Control

 A diagnostic session enables a set of services/functions

 Only 1 active diagnostic session at a time

 System starts with default session at power up. Other sessions must be
requested with service $10 to start

124
UDS in General
Application Layer – Service $10 – Request Format

Diagnostic Session Type:

 0x00: reserved  0x05-0x3F: reserved
 0x01: default session  0x40-0x5F: vehicle manufacture specific
 0x02: programming session  0x60-0x7E: supplier specific
 0x03: extended session  0x7F: reserved
 0x04: safety system diagnostic session

125
UDS in General
Application Layer – Service $10 – Positive Response Format

 Diagnostic Session Type  Session Parameter Record

(same as in request format)

126
UDS in General
Application Layer – Service $27 - Overview
Client Server
 Service $27 – Security Access

 Provide a mean to access data/services

 Implement using seed/key relationship

 Formula to calculate key from seed is pre-

determined and known by both client and server

 Access is granted when key calculated by client

matches with that by server

127
UDS in General
Application Layer – Service $27 - Overview
 Security Level
Security Level 1 2 3 … n …
Seed-related sub-function 1 3 5 … 2n-1 …
Key-related sub-function 2 4 6 … 2n …

 Security levels are independent and non-arbitration from each other

 At any moment, only 1 security level can be in unlock state

 Data/services can be assigned to more than 1 security level. Access is

granted when any of those is in unlock state

128
UDS in General
Application Layer – Service $27 – Request Format
 Security Access
Data Record
(optional):
information about
the seed

129
UDS in General
Application Layer – Service $27 – Response Format

 Security Access Type in the response is echoed from the request

 Seed length and algorithm is defined by user (usually a random generation algorithm)
 Key length and algorithm is defined by user.
 Seed length and key length are not necessarily be same

130
UDS in General
Application Layer – Service $22/$2E – Overview
 Service $22 – Read Data by Identifier
 Service $2E – Write Data by Identifier

 Data Identifier (DID): 2 byte – mark for an internal location of a data

record

 DID along with referred data length and format are pre-defined by user

 Service $2E might involve NVM-related services to store data

 Service $2E might involve certain security check methods

131
UDS in General
Application Layer – Service $22/$2E – Request Format

 Data from multiple DIDs

can be read in 1 single
request
 Maximum number of
DIDs must be pre-
determined

132
UDS in General
Application Layer – Service $22/$2E – Response Format
 For multiple DIDs read request, data
is provided in the response along with
the respective DID

133
UDS in General
Session Layer - Services
 E.g.: transmission/reception of data, setting of protocol parameters
 Primitives: request, indication, confirm

134
UDS in General
Session Layer – Timing
Parameter – P2, P2*, P4

 P2: from receiving of request to start of 1st

response (can be NRC 0x78)
 P2*: from receiving NRC 0x78 to start of
next response (can also be NRC 0x78)
 P4: from receiving of request to start of final
response (cannot be 0x78)
 Note: delay between layers and transmission
medium should be accounted for
 Note: from server side, a max threshold is
also defined for each parameter

135
UDS in CAN Implementation
Application Layer
SID Service Name SID Service Name
Diagnostic & Communication Management
0x10 Diagnostic Session Control 0x11 ECU Reset
0x27 Security Access 0x28 Communication Control
0x3E Tester Present 0x83 Access Timing Parameter
0x84 Secured Data Transmission 0x85 DTC Control Setting
0x86 Response On Event 0x87 Link Control
Data Transmission
0x22 Read Data By Identifier 0x2E Write Data By Identifier
0x23 Read Memory By Address 0x3D Write Memory By Address
0x23 Read Scaling Data By Identifier 0x2C Dynamically Defined Data Identifier
0x2A Read Data By Periodic Identifier
136
UDS in CAN Implementation
Application Layer
SID Service Name SID Service Name
Stored Data Transmission
0x14 Clear Diagnostic Information 0x19 Read DTC Information
Input Output Control
0x2F Input Output Control By Identifier
Routine
0x31 Routine Control
Upload Download
0x34 Request Download 0x35 Request Upload
0x36 Transfer Data 0x37 Exit Transfer

137
138
DIAGNOSTIC
COMMUNICATION
OVER CAN
Agenda

1. Overview
1. Diagnostic over any protocol
2. OSI encapsulation model
2. Diagnostic over CAN
1. Problem
2. Single-frame transmission
3. Multi-frame transmission
4. N_PDU definition
5. Timing parameters

140
Overview
Diagnostic Over Any Protocol
 Diagnostic communication protocols (like UDS) cover the
upper layers (5, 6, 7)

 Communication protocols (like CAN) cover the lower

layers (1, 2)

 Diagnostic over <protocol> covers Network layer (3) and

Transport layer (4)

 Diagnostic over <protocol> ensure diagnostic data from

upper layers can be transmitted/received using <protocol>
communication

141
Overview
OSI Encapsulation Model
 Layer header is included in the data before
passing to the adjacent lower layer

 Content of the header is related to the

protocol/format used at that level

 Data and header of Nth-layer will become

data of N-1th-layer

 Header included in the N-layer at sender

side will later be used by same N-layer at
receiver side to process the data

142
Overview
OSI Encapsulation Model
 Terminology:
 SDU – Service Data Unit (payload)
 PCI – Protocol Control Information (header)
 PDU – Protocol Data Unit

 Note:
 Nth-PCU is added by Nth-layer of sender, then removed by Nth-layer of receiver
 Not always all 7 layers are present, processing data or adding header
 For the rest of this document, PDU provided by network layer are denoted as N_PDU, similarly for N_PCI and
N_SDU

143
Diagnostic Over CAN
Problem - Overview
 Requirement: ECU must be able to provide Vehicle Identification
Number (VIN) via a diagnostic read service
Example
Tester: 22 F1 90
ECU: 62 F1 90 31 48 47 42 48 34 31 58 4A 4D 4E 31 30 39 31 38 36
(ASCII translation: 1HGBH41XJMN109186)

 Problem:
 VIN according to automotive standard are 17-byte long
 UDS protocol requires 3 more bytes to specify for the service
 CAN protocol only allows 8 bytes in the data field at max

144
Diagnostic Over CAN
Problem – VIN Format

145
Diagnostic Over CAN
Problem – CAN Frame Format

CRC ACK
Arbitration Field Control Field Data Field
Field Field
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0

CANNOT FIT IN???

UDS Protocol VIN Data

Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte
#1 #2 #3 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17
7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
62 F1 90 31 48 47 42 48 34 31 58 4A 4D 4E 31 30 39 31 38 36

146
Diagnostic Over CAN
Single-frame Transmission
 Data can be fitted in single CAN
frame

 No segmentation is needed

 Network layer data packet for this

case is call SingleFrame (SF)

147
Diagnostic Over CAN
Multi-frame Transmission
 Data doesn’t fit a single CAN frame

 Network layer segments the data into multiple CAN

frames (FF and CF)
 FirstFrame (FF) contains the total length
 ConsecutiveFrame (CF) contains respective sequence
number

 FlowControl is provided by receiver, to adjust the

sender to the network layer capacities of receiver

148
Diagnostic Over CAN Tester ECU
N_PDU Definition – Single Frame
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0
7-0 7-0 7-0 7-0 7-0 7-0 7-0
FT DL
0 3 22 F1 90 x x x x

 FT: Frame Type: 0x0 for Single Frame

 DL: Data Length, maximum 7 for Single Frame

149
Diagnostic Over CAN Tester ECU
N_PDU Definition – First Frame
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0
FF: 10 14 62 F1 90 31 48 47

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte
Byte #1 Byte #2 #3 #4 #5 #6 #7 #8
7-4 3-0 7-4 3-0
7-0 7-0 7-0 7-0 7-0 7-0
FT DL
1 0 1 4 62 F1 90 31 48 47

 FT: Frame Type: 0x1 for First Frame

 DL: total Data Length, maximum 4096 for First Frame
 First Frame contains 1st 6 bytes of total payload

150
Diagnostic Over CAN  FT: Frame Type: 0x3 for Flow Control
N_PDU Definition – Flow Control
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
 FS: Flow State
SOF

EOF
Identifier RTR Res DLC
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Deli Ack Deli  0x0: CTS – continue to send
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0  0x1: WT – wait
 0x2: OVFLW – overflow
N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte
 BS: Block Size
Byte #1
#2 #3 #4 #5 #6 #7 #8  0x00: no more FC needed
7-4 3-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
 0x01..0xFF: max number of CFs can be
ST
FT FS BS
min
N/A N/A N/A N/A N/A sent until the next FC
3 0 00 00 x x x x x

 Note: no data for FC  STmin: Separation Time Minimum

 0x00..0x7F: 0..127 ms
 0xF1..0xF9: 100..900 us

151
Diagnostic Over CAN Tester ECU
N_PDU Definition – Flow Control
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0
FF: 10 14 62 F1 90 31 48 47

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte FC: 30 00 00
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
ST
FT FS BS N/A N/A N/A N/A N/A
min
3 0 00 00 x x x x x

152
Diagnostic Over CAN Tester ECU
N_PDU Definition – Consecutive Frame
Arbitration Field Control Field Data Field
CRC
Field
ACK
Field
SF: 03 22 F1 90
SOF

EOF
Byte Byte Byte Byte Byte Byte Byte Byte Byte
Identifier RTR Res DLC Deli Ack Deli
#1 #2 #3 #4 #5 #6 #7 #8 #1
0 10 9 8 7 6 5 4 3 2 1 0 0 5 4 3 2 1 0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0 0 1 0 6 54 3 2 1 0
FF: 10 14 62 F1 90 31 48 47

N_PDU
N_PCI N_SDU
Byte Byte Byte Byte Byte Byte Byte FC: 30 00 00
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0
7-0 7-0 7-0 7-0 7-0 7-0 7-0
FT SN CF: 21 42 48 34 31 58 4A 4D
2 1 42 48 34 31 58 4A 4D
2 2 4E 31 30 39 31 38 36

STmin CF: 22 4E 31 30 39 31 38 36
 FT: Frame Type: 0x2 for Consecutive Frame
 SN: Sequence Number, initial 0x1, range 0x0..0xF

153
Diagnostic Over CAN
N_PDU Definition - Summary

N_PDU
Byte Byte Byte Byte Byte Byte Byte
Byte #1
#2 #3 #4 #5 #6 #7 #8
7-4 3-0 7-0 7-0 7-0 7-0 7-0 7-0 7-0
Single Frame 0 DL Data
First Frame 1 DL Data
Consecutive Frame 2 SN Data
Flow Control 3 FS BS Stmin N/A

N_PCI
N_SDU

154
Diagnostic Over CAN Receiver Sender
Timing Parameters
Timing SF
Timeou Performance
Paramet Description
t (ms) (ms)
N_Ar
er
Time for transmission of the
N_As CAN frame (any N_PDU) on 1000 N/A FF
the sender side N_As
Time for transmission of the
N_Ar CAN frame (any N_PDU) on 1000 N/A N_Br
the receiver side FC N_Bs
Time until reception of the
N_Ar
N_Bs 1000 N/A
next FC N_PDU N_Cs
N_Br
Time until transmission of the
N/A
(N_Br + N_Ar) N_Cr CF
next FC N_PDU < (0.9 * N_Cr) N_As
Time until transmission of the (N_Br + N_Ar)
N_Cs N/A < (0.9 * N_Cr) N_Cs
next CF N_PDU
N_Cr CF
Time until reception of the
N_Cr
next CF N_PDU
1000 N/A N_As

155
Thank you!

15
6