Can protocol

1. ISO CAN TP(ISO15765-2),
DCM &
AUTOSAR CAN STACK OVERVIEW
BY RAMYA S

2. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
ISO CAN-TP :
 The ISO15765-2 CAN-TP protocol is an international standard protocol used for sending more than 8-bytes of
data over the CAN consecutive frames.
 The ISO Transport protocol is on the fourth layer(transport)of the OSI model.
 The ISO-TP defined a transmission method that allows to send up to 4095 bytes via CAN bus.
 The messages are segmented and individual CAN frames divided .
 The primary task of transport protocol is to transfer messages which cannot be transmitted as a single
protocol data unit(PDU)due to their length.
 PDU are segmented into multiple and separate PDUs.

3. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
TYPES OF FRAMES IN CAN-TP:
Single frame:
If data payload is 7-bytes or lessthan that,then the single frame will be used for data transmission,where the first
byte of the datafield is used for addressing.
First frame:
It is an initial message of the multi-frame message packet in CAN-TP protocol.It is used when more than 6 or 7
bytes of data segmented must be communicated. It contains the length of the full packet, along with the initial data.

4. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
Consecutive frame:
Consecutive frame containing subsequent data for a multi frame packet.More data that can be transmitted within a
single PDU are segmented by means of the transport protocol and divided into multiple ,separate PDUs.
Flow control frame:
The flow control frame is used to configure the sender to match the properties of receiver(timing ,available receiver
buffer,readiness to receive).

5. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
Single frame transmission multiframe transmission

6. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
EXAMPLE:
For read 20 bytes of data:
Request  03 22 F1 20 00 00 00 00
Response:
First frame  10 0B 62 F1 20 01 02 03
Flow control frame  30 03 F2
Consecutive frame1 21 04 05 06 07 08 09 0A
Consecutive frame2 22 0B 0C 0D 0E 0F 11 12
Consecutive frame3  23 13 14

7. DIAGNOSTIC COMMUNICATION
MANAGER(DCM)

8. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
DIAGNOSTIC COMMUNICATION MANAGER:
 Diagnostic Communication Manager (DCM) is a basic software module which provides the
Functionality to handle diagnostic requests from external diagnostic tool.
 AUTOSAR DCM supports standard diagnostic protocols like UDS – ISO14229-1, OBD – ISO15031-5
over CAN, Flex ray and MOST bus.
 DCM module is responsible for ensuring diagnostic data (messages) flow and managing diagnostic
states, especially diagnostic sessions and security states.
 DCM is above to PDU router (PduR) and it receives diagnostic request message from PduR.

9. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
DCM layers:
Diagnostic Session Layer(DSL):
 DSL communicates with PduR module, accepts incoming diagnostic request from PduR and sends
request to DSD sub module. Receives response from DSD sub module and sends to PduR.
 Handling of different diagnostic protocol and diagnostic services.
 DSL guarantees to achieve timing requirements for perfect communication.
Diagnostic Service Dispatcher(DSD):
 DSD forward received diagnostic requests to Diagnostic Service Processor (DSP) over network.
 DSD checks Security and Session access of incoming request.
 DSD sub-module should check service table for supported services if it is not supported then send NRC
0x11.
 Add diagnostic service identifier and response data returned by application and forwards diagnostic
response message to DSL sub-module.

10. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
Diagnostic Service Processor(DSP):
 DSP sub-module is the main module which processes the received diagnostic request from DSD sub-
module.
 DSP analyses the received request message, checks its format, checks if the requested sub function is
supported, acquire necessary data from DEM, SWCs, or BSW modules, and assemble response.
 DSP check message format and sub-function support.

11. AUTOSAR CAN STACK
OVERVIEW

12. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
AUTOSAR - AUTomotive Open System Architecture
AUTOSAR Architecture was introduced to promote standardization in the software development process
of Automotive Electronic Control Units(ECU).
The basic approach of AUTOSAR is providing a framework for developing application components
independent from the hardware.

13. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
AUTOSAR layers:
Basic Software (BSW) Layer:
This module offers various service necessary to run the functional part of the upper software layer.This
layer consist of ECU specific model along with the generic AUTOSAR modules.
This layer divided into three sub layers :
Microcontroller Abstraction Layer (MCAL)
Electronic Control Unit (ECU) Abstraction Layer
Services Layer
Run-Time Environment (RTE):
It manage the communication between application layer software component and between BSW and
application layer service.
Application Layer(SWC):
This layer consists of the specific software components and many applications, which are a group of
interconnected AUTOSAR Software Components and perform specific tasks as per instructions.
The communication between software components is enabled via specific ports using a virtual Function
Bus.

14. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
AUTOSAR CAN STACK :
When the target Bus type for an AUTOSAR compliant software is CAN, the ComStack implementation is
executed with respect to CAN Bus.
AUTOSAR COM:
 It is Part of the services layer. AUTOSAR COM is a module between the RTE and the PDU Router.
 It is responsible for providing Signal level access to the application layer and PDU level access to the
lower layers independent of the protocol.

15. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
PDU Router:
 PDU Router is a module responsible for routing the PDU to the respective Bus Specific Interface modules.
 Above the PduR module all the PDUs are protocol independent, and below PduR all the PDUs are routed to the
protocol specific modules.
 PduR is also responsible for PDU level gatewaying i.e. transmitting the received PDU from one Bus Specific
Interface module to other Bus Specific Interface module.
CAN TP layer:
 If PDU(message) that needs to be transmitted or received may go beyond the maximum size of supported CAN
message. For solving such problems and limitations of CAN, AUTOSAR implements CanTp block.
 This block provides services to perform the segmentation of I-PDUs whose size is greater than maximum
allowed size for CAN.
 This block also provides services which reassembles the received PDUs which are then further transferred to
application layer by unpacking signals from it.

16. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
CAN INTERFACE LAYER:
 It is Part of the ECU abstraction layer .These modules provide interface between hardware abstraction
layer and service layer.
 CanIf fulfills main control and data flow requirements of the PDU router and upper layer communication
modules of AUTOSAR COM stack
 CanIf is responsible for services like Transmit Request, Transmit Confirmation, Reception Indication,
Controller mode control and PDU mode control.
CAN DRIVER:
 This module is a part of the MCAL layer and provides hardware access to the upper layer services and a
hardware-independent interface to the upper layers.
 CanIf is the only module that can access the CAN driver.

17. Internal | 2021-03-18
© Robert Bosch GmbH 2021. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
Message transfer from upper layer to lower layer: