1628502836912_CAN_TP,DCM&AutosarCAN.pptx

Can protocol

1. ISO CAN TP(ISO15765-2), DCM & AUTOSAR CAN STACK OVERVIEW by ramya s

2. 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. 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. 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. Single frame transmission multiframe transmission

6. 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. 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. 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 D ispatcher(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. Diagnostic Service P rocessor(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. 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. AUTOSAR layers: Basic Software (BSW) Layer: This module offers various service necessary t o 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. 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. 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. 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. Message transfer from upper layer to lower layer: