.. _knowledge-base-docan: Diagnostics over CAN ==================== Diagnostics over CAN (DoCAN) also known as CAN Transport Protocol (CAN-TP, ISO 15765-2), is the transport layer protocol used by UDS and several other diagnostic protocols (e.g., SAE J1979, `KWP2000 `_) for :ref:`message segmentation ` on CAN networks. In other words, DoCAN provides the adaptation that allows UDS to operate on CAN. It is illustrated in the :ref:`UDS OSI Model `. .. _knowledge-base-can-versions: CAN Bus Versions ---------------- `CAN Bus `_ was released in multiple version over the years. Classic CAN ``````````` Classic CAN, also called CAN 2.0. - supports DLC values 0-8 CAN FD `````` CAN version with Flexible Data-Rate. - supports DLC values 0-15 (0-8 linear, 9-15 discrete: 12, 16, 20, 24, 32, 48, 64 bytes) - faster transmission of data field - backward compatible with Classic CAN CAN XL `````` To be released in the near future. - supports up to 2048-bytes payload - backward compatible with Classic CAN and CAN FD .. _knowledge-base-can-frame: CAN Frame --------- DoCAN (and therefore UDS) uses only `CAN data frames `_. A CAN data frame consists of several fields, but for DoCAN communication the most relevant are: - CAN Identifier (CAN ID) CAN ID is a field that informs every receiving CAN node about a sender and a content of frames. CAN nodes shall filter out and ignore CAN frames that are not relevant for them. There are two formats of CAN ID: - Standard - 11-bit long - Extended - 29-bit long - Data Length Code (DLC) DLC is a field that informs about number of data bytes that a CAN frame contains. - CAN Data Field Data Field contains the payload. Its length is determined by the DLC value, as shown in the table: +-----+--------------------------+----------------------------+---------------------+ | DLC | Number of CAN Data bytes | Supported by CLASSICAL CAN | Supported by CAN FD | +=====+==========================+============================+=====================+ | 0x0 | 0 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x1 | 1 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x2 | 2 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x3 | 3 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x4 | 4 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x5 | 5 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x6 | 6 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x7 | 7 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x8 | 8 | YES | YES | +-----+--------------------------+----------------------------+---------------------+ | 0x9 | 12 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ | 0xA | 16 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ | 0xB | 20 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ | 0xC | 24 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ | 0xD | 32 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ | 0xE | 48 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ | 0xF | 64 | NO | YES | +-----+--------------------------+----------------------------+---------------------+ .. note:: To learn more about CAN bus and CAN frame structure, we encourage you to read `CAN bus specification `_ and visit `e-learning portal of Vector Informatik GmbH `_. .. _knowledge-base-can-packet: CAN Packet ---------- CAN Packets are :ref:`CAN Frames ` exchanged during DoCAN communication. .. _knowledge-base-can-data-field: Data Field `````````` In DoCAN, a CAN Packet must use a DLC of 8 (Classical CAN and CAN FD), or greater than 8 (CAN FD only). The only exception is when :ref:`CAN Frame Data Optimization ` is applied. +-----+------------------------------------------------------------------------+ | DLC | Description | +=====+========================================================================+ | <8 | *Valid only for CAN frames using data optimization* | | | | | | Values in this range are only valid for Single Frame, Flow Control and | | | | | | Consecutive Frame that use CAN frame data optimization. | +-----+------------------------------------------------------------------------+ | 8 | *Configured CAN frame maximum payload length of 8 bytes* | | | | | | For the use with CLASSICAL CAN and CAN FD type frames. | +-----+------------------------------------------------------------------------+ | >8 | *Configured CAN frame maximum payload length greater than 8 bytes* | | | | | | For the use with CAN FD type frames only. | +-----+------------------------------------------------------------------------+ where: - DLC - Data Length Code of a :ref:`CAN frame ` .. note:: Number of bytes that carry diagnostic message payload depends on a type and a format of a CAN packet as it is presented in :ref:`the table with CAN packets formats `. .. _knowledge-base-can-frame-data-padding: CAN Frame Data Padding '''''''''''''''''''''' If the payload of a CAN Packet is shorter than the available bytes in the frame’s data field, the sender must pad the unused bytes. Padding applies only to: - :ref:`Single Frame ` - :ref:`Flow Control ` - The last :ref:`Consecutive Frame ` Unless specified otherwise, the padding value shall be 0xCC, which minimizes bit stuffing and signal distortion on the bus. .. note:: CAN frame data padding is mandatory for :ref:`CAN frames ` with DLC>8, optional for frames with DLC=8 and forbidden for frames with DLC<8. .. _knowledge-base-can-data-optimization: CAN Frame Data Optimization ''''''''''''''''''''''''''' CAN frame data optimization is an alternative to `CAN Frame Data Padding`_. If a number of bytes specified in a CAN Packet is shorter than a number of bytes in CAN frame's data field, then the sender might decrease DLC value of the :ref:`CAN frame ` to the smallest DLC that can still accommodate the payload. .. note:: CAN Frame Data Optimization might always be used for CAN Packets with less than 8 bytes of data to send. .. warning:: CAN Frame Data Optimization might not always be able to replace `CAN Frame Data Padding`_ when CAN FD is used. This is a consequence of DLC values from 9 to 15 meaning as these values are mapped into CAN frame data bytes numbers in a non-linear way (e.g. DLC=9 represents 12 data bytes). Example: *When a CAN Packet with 47 bytes of data is planned for a transmission, then DLC=14 can be used instead of DLC=15,* *to choose 48-byte instead of 64-byte long CAN frame. Unfortunately, the last byte of CAN Frame data has to be * *padded as there is no way to send over CAN a frame with exactly 47 bytes of data.* .. _knowledge-base-can-n-pci: CAN Packet Types ```````````````` According to ISO 15765-2, CAN bus supports 4 types of Packets. List of all values of :ref:`Network Protocol Control Information ` supported by CAN bus: - 0x0 - :ref:`Single Frame ` - 0x1 - :ref:`First Frame ` - 0x2 - :ref:`Consecutive Frame ` - 0x3 - :ref:`Flow Control ` - 0x4-0xF - values range reserved for future extension by ISO 15765 The format of all CAN packets is presented in the table below. .. _knowledge-base-can-packets-format: +-------------------+---------------------+---------+---------+---------+---------+---------+-----+ | CAN N_PDU | Byte #1 | Byte #2 | Byte #3 | Byte #4 | Byte #5 | Byte #6 | ... | | +----------+----------+ | | | | | | | | Bits 7-4 | Bits 3-0 | | | | | | | +===================+==========+==========+=========+=========+=========+=========+=========+=====+ | Single Frame | 0x0 | SF_DL | | | | | | | | | | | | | | | | | | *DLC ≤ 8* | | | | | | | | | +-------------------+----------+----------+---------+---------+---------+---------+---------+-----+ | Single Frame | 0x0 | 0x0 | SF_DL | | | | | | | | | | | | | | | | | *DLC > 8* | | | | | | | | | +-------------------+----------+----------+---------+---------+---------+---------+---------+-----+ | First Frame | 0x1 | FF_DL | | | | | | | | | | | | | | | | *FF_DL ≤ 4095* | | | | | | | | +-------------------+----------+----------+---------+---------+---------+---------+---------+-----+ | First Frame | 0x1 | 0x0 | 0x00 | FF_DL | | | | | | | | | | *FF_DL > 4095* | | | | | | +-------------------+----------+----------+---------+---------+---------+---------+---------+-----+ | Consecutive Frame | 0x2 | SN | | | | | | | +-------------------+----------+----------+---------+---------+---------+---------+---------+-----+ | Flow Control | 0x3 | FS | BS | ST_min | N/A | N/A | N/A | N/A | +-------------------+----------+----------+---------+---------+---------+---------+---------+-----+ where: - DLC - Data Length Code of a CAN frame, it is equal to number of data bytes carried by this CAN frame - SF_DL - :ref:`Single Frame Data Length ` - FF_DL - :ref:`First Frame Data Length ` - SN - :ref:`Sequence Number ` - FS - :ref:`Flow Status ` - BS - :ref:`Block Size ` - ST_min - :ref:`Separation Time minimum ` - N/A - Not applicable (the byte does not contain protocol information) .. _knowledge-base-can-single-frame: Single Frame '''''''''''' Single Frame (SF) is used to transmit an entire diagnostic message that fits into one CAN Packet. Payload length is defined by :ref:`SF_DL `. .. _knowledge-base-can-single-frame-data-length: Single Frame Data Length ........................ Single Frame Data Length (SF_DL) is 4-bit (for CAN packets with DLC<=8) or 8-bit (for CAN packets with DLC>8) value carried by every Single Frame as presented in :ref:`the table with CAN packet formats`. SF_DL specifies number of diagnostic message payload bytes transmitted in a Single Frame. .. note:: Maximal value of SF_DL depends on Single Frame :ref:`addressing format ` and :ref:`DLC of a CAN message ` that carries this packet. .. _knowledge-base-can-first-frame: First Frame ''''''''''' First Frame (FF) marks the start of a segmented diagnostic message which could not fit into a :ref:`Single Frame `. Payload length is given by :ref:`FF_DL `. .. _knowledge-base-can-first-frame-data-length: First Frame Data Length ....................... First Frame Data Length (FF_DL) is 12-bit (if FF_DL ≤ 4095) or 4-byte (if FF_DL > 4095) value carried by every First Frame. FF_DL specifies number of diagnostic message payload bytes of a diagnostic message which transmission was initiated by a First Frame. .. note:: Maximal value of FF_DL is 4294967295 (0xFFFFFFFF). It means that CAN bus is capable of transmitting diagnostic messages that contains up to nearly 4,3 GB of payload. .. _knowledge-base-can-consecutive-frame: Consecutive Frame ''''''''''''''''' Consecutive Frame (CF) carries the remaining payload after a :ref:`First Frame `. Order is indicated by :ref:`Sequence Number `. .. _knowledge-base-can-sequence-number: Sequence Number ............... Sequence Number (SN) is 4-bit value used to specify the order of Consecutive Frames. The rules for assigning Sequence Numbers are: - SN value of the first :ref:`Consecutive Frame ` that directly follows a :ref:`First Frame ` shall be set to 1. - SN shall be incremented by 1 for each following :ref:`Consecutive Frame `. - SN value shall not be affected by :ref:`Flow Control ` packets. - When SN reaches 15, the next :ref:`Consecutive Frame ` shall use SN = 0. .. _knowledge-base-can-flow-control: Flow Control '''''''''''' Flow Control (FC) is used by receiving CAN entities to instruct sending entities to stop, start, pause or resume transmission of :ref:`Consecutive Frames `. Flow Control packet contains following parameters: - :ref:`Flow Status ` - :ref:`Block Size ` - :ref:`Separation Time Minimum ` .. _knowledge-base-can-flow-status: Flow Status ........... Flow Status (FS) is 4-bit value that is used to inform a sending network entity whether it can proceed with a Consecutive Frames transmission. Values of Flow Status: - **0x0 - ContinueToSend (CTS)** ContinueToSend value of Flow Status informs a sender of a diagnostic message that receiving entity (that responded with CTS) is ready to receive a maximum of :ref:`Block Size ` number of :ref:`Consecutive Frames `. Reception of a :ref:`Flow Control ` packet with ContinueToSend value shall cause the sender to resume ConsecutiveFrames sending. - **0x1 - wait (WAIT)** Wait value of Flow Status informs a sender of a diagnostic message that receiving entity (that responded with WAIT) is not ready to receive another :ref:`Consecutive Frames `. Reception of a :ref:`Flow Control ` packet with WAIT value shall cause the sender to pause ConsecutiveFrames sending and wait for another :ref:`Flow Control ` packet. Values of :ref:`Block Size ` and :ref:`STmin ` in the :ref:`Flow Control ` packet (that contains WAIT value of Flow Status) are not relevant and shall be ignored. - **0x2 - Overflow (OVFLW)** Overflow value of Flow Status informs a sender of a diagnostic message that receiving entity (that responded with OVFLW) is not able to receive a full diagnostic message as it is too big and reception of the message would result in `Buffer Overflow `_ on receiving side. In other words, the value of :ref:`FF_DL ` exceeds the buffer size of the receiving entity. Reception of a :ref:`Flow Control ` packet with Overflow value shall cause the sender to abort the transmission of a diagnostic message. Overflow value shall only be sent in a :ref:`Flow Control ` packet that directly follows a :ref:`First Frame `. Values of :ref:`Block Size ` and :ref:`STmin ` in the :ref:`Flow Control ` packet (that contains OVFLW value of Flow Status) are not relevant and shall be ignored. - 0x3-0xF - Reserved This range of values is reserved for future extension by ISO 15765. .. _knowledge-base-can-block-size: Block Size .......... Block Size (BS) is a one byte value specified by receiving entity that informs about number of :ref:`Consecutive Frames ` to be sent in a one block of packets. Block Size values: - 0x00 The value 0 of the Block Size parameter informs a sender that no more :ref:`Flow Control ` packets would be sent during the transmission of the segmented message. Reception of Block Size = 0 shall cause the sender to send all remaining :ref:`Consecutive Frames ` without any stop for further :ref:`Flow Control ` packets from the receiving entity. - 0x01-0xFF This range of Block Size values informs a sender the maximum number of :ref:`Consecutive Frames ` that can be transmitted without an intermediate :ref:`Flow Control ` packet from the receiving entity. .. _knowledge-base-can-st-min: Separation Time Minimum ....................... Separation Time minimum (STmin) is a one byte value specified by receiving entity that informs about minimum time gap between the transmission of two following :ref:`Consecutive Frames `. STmin values: - 0x00-0x7F - Separation Time minimum range 0-127 ms The value of STmin in this range represents the value in milliseconds (ms). Meaning of example values: 0x00 -> 0ms 0x20 -> 32ms 0x7F -> 127ms - 0x80-0xF0 - Reserved This range of values is reserved for future extension by ISO 15765. - 0xF1-0xF9 - Separation Time minimum range 100-900μs The value of STmin in this range represents the value in microseconds (μs) according to the formula: .. code-block:: (STmin - 0xF0) * 100μs Meaning of example values: 0xF1 -> 100μs 0xF5 -> 500μs 0xF9 -> 900μs - 0xFA-0xFF - Reserved This range of values is reserved for future extension by ISO 15765. .. _knowledge-base-can-addressing: CAN Addressing Formats ---------------------- CAN addressing formats define how :ref:`Network Address Information ` is encoded within a `CAN Packet`_. ISO 15765 specifies the following three addressing formats: - :ref:`Normal addressing ` - :ref:`Extended addressing ` - :ref:`Mixed addressing ` .. note:: Regardless of addressing format used, to transmit a :ref:`functionally addressed ` message over CAN, a sender is allowed to use :ref:`Single Frame ` packets only. .. seealso:: `ISO 15765-4 `_ contains detailed information about CAN addressing formats. .. _knowledge-base-can-normal-addressing: Normal Addressing ````````````````` Normal CAN Addressing is typically used when a client (Diagnostic Tester) communicates directly with servers (ECUs) in the same CAN network. In this format, the CAN Identifier itself carries the complete :ref:`Network Address Information `. The CAN Identifier alone provides sufficient information to identify the :ref:`addressing type `, as well as the transmitting and receiving nodes. .. note:: With normal addressing, both 11-bit (standard) and 29-bit (extended) CAN Identifiers are allowed. In Normal Addressing Format, the :ref:`Network Address Information ` is contained in the CAN ID, which indicates the addressing type as well as the transmitting and receiving nodes. ISO 15765-4 specifies the following CAN Identifiers as examples for Normal CAN Addressing: - 0x7DF - functionally addressed request message - 0x7E0 - physical request to Engine Control Module - 0x7E8 - physical response from Engine Control Module - 0x7E1 - physical request to Transmission Control Module - 0x7E9 - physical response from Transmission Control Module - 0x7E2 - physical request to ECU#3 - 0x7EA - physical response from ECU#3 - 0x7E3 - physical request to ECU#4 - 0x7EB - physical response from ECU#4 - 0x7E4 - physical request to ECU#5 - 0x7EC - physical response from ECU#5 - 0x7E5 - physical request to ECU#6 - 0x7ED - physical response from ECU#6 - 0x7E6 - physical request to ECU#7 - 0x7EE - physical response from ECU#7 - 0x7E7 - physical request to ECU#8 - 0x7EF - physical response from ECU#8 .. note:: Interpretation of CAN Identifier values is left open for a network designer unless `Normal Fixed Addressing`_ sub-format is used. .. note:: :ref:`Network Protocol Control Information ` is placed in the **first byte** of :ref:`CAN frame data field ` when Normal CAN Addressing format is used. .. _knowledge-base-can-normal-fixed-addressing: Normal Fixed Addressing ''''''''''''''''''''''' Normal Fixed CAN Addressing is a specialized variant of :ref:`Normal Addressing `, where the mapping of :ref:`Network Address Information ` into the 29-bit CAN Identifier is strictly predefined by ISO 15765-4. .. note:: With normal fixed addressing, only 29-bit (extended) CAN Identifiers are allowed. Following parameters contain :ref:`Network Address Information ` for Normal Fixed CAN Addressing Format: - CAN ID (with embedded **Target Address** and **Source Address**) - informs about addressing type, transmitting and receiving nodes - **Source Address** identifies the transmitting node - **Target Address** identifies the receiving node CAN Identifier values used for UDS communication using normal fixed addressing: - For :ref:`physical addressed ` messages, CAN Identifier value is defined as presented below: +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | | Priority | Reserved Bit | Data Page | Protocol data | Target | Source | Data | | | | | | unit format | Address | Address | | +================+==========+==============+===========+===============+=========+=========+===============+ | Bits number | 3 | 1 | 1 | 8 | 8 | 8 | 16-512 | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | Content | 0 - 7 | 0 | 0 | 218 | N_TA | N_SA | N_PCI, N_Data | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | CAN field | CAN Identifier | CAN Data | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | CAN ID bits | 28-26 | 25 | 24 | 23-16 | 15-8 | 7-0 | --- | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | CAN data bytes | --- | --- | --- | --- | --- | --- | 1-64 | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ .. code-block:: # assuming priority parameter equals 0 CAN_ID = 0xDATTSS # assuming priority parameter equals 6 (default value) CAN_ID = 0x18DATTSS # assuming priority parameter equals 7 CAN_ID = 0x1CDATTSS - For :ref:`functional addressed ` messages, CAN Identifier value is defined as presented below: +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | | Priority | Reserved Bit | Data Page | Protocol data | Target | Source | Data | | | | | | unit format | Address | Address | | +================+==========+==============+===========+===============+=========+=========+===============+ | Bits number | 3 | 1 | 1 | 8 | 8 | 8 | 16-512 | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | Content | 0 - 7 | 0 | 0 | 219 | N_TA | N_SA | N_PCI, N_Data | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | CAN field | CAN Identifier | CAN Data | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | CAN ID bits | 28-26 | 25 | 24 | 23-16 | 15-8 | 7-0 | --- | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ | CAN data bytes | --- | --- | --- | --- | --- | --- | 1-64 | +----------------+----------+--------------+-----------+---------------+---------+---------+---------------+ .. code-block:: # assuming priority parameter equals 0 CAN_ID = 0xDBTTSS # assuming priority parameter equals 6 (default value) CAN_ID = 0x18DBTTSS # assuming priority parameter equals 7 CAN_ID = 0x1CDBTTSS where: - CAN_ID - value of **CAN Identifier** - TT - two (hexadecimal) digits of a 8-bit **Target Address** value - SS - two (hexadecimal) digits of a 8-bit **Source Address** value - N_TA - Network **Target Address** parameter - N_SA - Network **Source Address** parameter - :ref:`N_PCI ` - Network Protocol Control Information - :ref:`N_Data ` - Network Data Field ISO 15765-4 recommends to use following parameters for Normal Fixed Addressing: - N_TA = 0xF1 and N_SA = 0xF1 - diagnostic tester parameters - CAN ID = 0x18DB33F1 (N_TA=0x33, N_SA=0xF1) - functionally addressed request message - CAN ID = 0x18DA??F1 (replace ?? with ECU's target address) - physically addressed request messages - CAN ID = 0x18DAF1?? (replace ?? with ECU's source address) - physically addressed response messages .. _knowledge-base-can-extended-addressing: Extended Addressing ``````````````````` The Extended CAN Addressing Format is typically used when direct communication with servers is not possible. In this case, a client (Diagnostic Tester) is not connected to the same CAN network as the server(s), and one or more ECU Gateways forward diagnostic messages. In Extended CAN Addressing, **the first byte of the CAN frame data field contains the Network Target Address (N_TA)**, which identifies the receiving node. The remaining :ref:`Network Address Information ` (the transmitting entity and the :ref:`addressing type `) are derived from the CAN Identifier. .. note:: Extended addressing may be used with both 11-bit (standard) and 29-bit (extended) CAN Identifiers. In Extended CAN Addressing Format, the following parameters define the :ref:`Network Address Information `: - CAN ID – encodes the addressing type and transmitting node - Target Address – contained in the first data byte of the :ref:`CAN Frame `, identifies the receiving node .. note:: In Extended CAN Addressing, the :ref:`Network Protocol Control Information ` is located in the second byte of the :ref:`CAN frame data field `. .. _knowledge-base-can-mixed-addressing: Mixed Addressing ```````````````` Mixed CAN Addressing Format is used in cases where direct communication with servers is not possible. A client (Diagnostic Tester) is not connected to the same CAN network as the server(s), and messages are therefore forwarded by one or more ECU Gateways. When the Mixed CAN Addressing Format is used, **the first byte of the CAN frame data field contains an Address Extension (N_AE)**, which forms part of the :ref:`Network Address Information `. The value of this Address Extension must remain consistent across all packets exchanged between the same sender and receiver for a given :ref:`addressing type `. .. note:: :ref:`Network Protocol Control Information ` is placed in the **second byte** of :ref:`CAN frame data field ` if mixed addressing format is used. Following parameters specify :ref:`Network Address Information ` for Mixed CAN Addressing Format: - CAN ID - informs about addressing type, transmitting and receiving nodes within the network - Addressing Extension (located in the first data byte of a :ref:`CAN Frame `) - provides an additional 8-bit addressing field (N_AE) extending the information in the CAN Identifier Mixed CAN Addressing Format has two sub-types, depending which CAN ID format is used: - `Mixed Addressing with 11-bit CAN Identifier`_ - `Mixed Addressing with 29-bit CAN Identifier`_ .. _knowledge-base-can-mixed-11-bit-addressing: Mixed Addressing with 11-bit CAN Identifier ''''''''''''''''''''''''''''''''''''''''''' It is a subtype `Mixed Addressing`_ when only 11-bit (standard) CAN Identifiers are used. .. _knowledge-base-can-mixed-29-bit-addressing: Mixed Addressing with 29-bit CAN Identifier ''''''''''''''''''''''''''''''''''''''''''' It is a subtype `Mixed Addressing`_ when only 29-bit (extended) CAN Identifiers are used. The mapping of :ref:`Network Address Information ` into the CAN identifier is further specified. CAN Identifier values used for UDS communication using mixed 29-bit addressing: - For :ref:`physical addressed ` messages, CAN Identifier value is defined as presented below: +----------------+----------+--------------+-----------+---------------+---------+---------+----------------------+ | | Priority | Reserved Bit | Data Page | Protocol data | Target | Source | Data | | | | | | unit format | Address | Address | | +================+==========+==============+===========+===============+=========+=========+======+===============+ | Bits number | 3 | 1 | 1 | 8 | 8 | 8 | 8 | 16-504 | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | Content | 0 - 7 | 0 | 0 | 206 | N_TA | N_SA | N_AE | N_PCI, N_Data | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | CAN field | CAN Identifier | CAN Data | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | CAN ID bits | 28-26 | 25 | 24 | 23-16 | 15-8 | 7-0 | --- | --- | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | CAN data bytes | --- | --- | --- | --- | --- | --- | 1 | 2-64 | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ .. code-block:: # assuming priority parameter equals 0 CAN_ID = 0xCETTSS # assuming priority parameter equals 6 (default value) CAN_ID = 0x18CETTSS # assuming priority parameter equals 7 CAN_ID = 0x1CCETTSS - For :ref:`functional addressed ` messages, CAN Identifier value is defined as presented below: +----------------+----------+--------------+-----------+---------------+---------+---------+----------------------+ | | Priority | Reserved Bit | Data Page | Protocol data | Target | Source | Data | | | | | | unit format | Address | Address | | +================+==========+==============+===========+===============+=========+=========+======+===============+ | Bits number | 3 | 1 | 1 | 8 | 8 | 8 | 8 | 16-504 | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | Content | 0 - 7 | 0 | 0 | 205 | N_TA | N_SA | N_AE | N_PCI, N_Data | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | CAN field | CAN Identifier | CAN Data | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | CAN ID bits | 28-26 | 25 | 24 | 23-16 | 15-8 | 7-0 | --- | --- | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ | CAN data bytes | --- | --- | --- | --- | --- | --- | 1 | 2-64 | +----------------+----------+--------------+-----------+---------------+---------+---------+------+---------------+ .. code-block:: # assuming priority parameter equals 0 CAN_ID = 0xCDTTSS # assuming priority parameter equals 6 (default value) CAN_ID = 0x18CDTTSS # assuming priority parameter equals 7 CAN_ID = 0x1CCDTTSS where: - CAN_ID - value of **CAN Identifier** - TT - two (hexadecimal) digits of a 8-bit **Target Address** value - SS - two (hexadecimal) digits of a 8-bit **Source Address** value - N_TA - Network **Target Address** parameter - N_SA - Network **Source Address** parameter - N_AE - Network **Addressing Extension** parameter - :ref:`N_PCI ` - Network Protocol Control Information - :ref:`N_Data ` - Network Data Field .. _knowledge-base-can-segmentation: Segmentation on CAN ------------------- This chapter describes segmentation rules specific to CAN networks and Diagnostic Communication over CAN (DoCAN), as defined in ISO 15765-2. .. _knowledge-base-can-unsegmented-message-transmission: Unsegmented message transmission ```````````````````````````````` An unsegmented message transmission occurs when a complete :ref:`Diagnostic Message ` fits entirely within a single :ref:`CAN Packet `. In this case, the sender shall use a :ref:`Single Frame (CAN Packet) ` to transmit the message. .. figure:: ../../images/CAN_Unsegmented_Message.png :alt: Unsegmented Message on CAN :figclass: align-center :width: 100% Transmission of an unsegmented Diagnostic Message on CAN bus. A sender transmits a :ref:`Single Frame (CAN Packet) ` that contains an entire :ref:`Diagnostic Message `. .. _knowledge-base-can-segmented-message-transmission: Segmented message transmission `````````````````````````````` If the payload of a :ref:`Diagnostic Message ` exceeds the capacity of a :ref:`Single Frame `, the message shall be segmented and transmitted using multiple :ref:`CAN Packets `. The first packet shall be a :ref:`First Frame (CAN Packet) `, followed by a sequence of :ref:`Consecutive Frames (CAN Packets) `. The receiving node manages the transmission flow by sending :ref:`Flow Control (CAN Packets) ` after the :ref:`First Frame ` and after each block of :ref:`Consecutive Frames `. .. note:: The size of :ref:`Consecutive Frames ` block is determined by :ref:`Block Size ` parameter provided in :ref:`Flow Control `. .. note:: The minimum time between two :ref:`Consecutive Frames ` is determined by :ref:`Separation Time Minimum ` parameter provided in :ref:`Flow Control `. .. figure:: ../../images/CAN_Segmented_Message.png :alt: Segmented Message on CAN :figclass: align-center :width: 100% Transmission of a segmented Diagnostic Message on CAN bus. A sender initiates :ref:`Diagnostic Message ` transmission with a :ref:`First Frame (CAN Packet) ` Then, a receiver controls the stream of incoming :ref:`Consecutive Frames (CAN Packets) ` by transmitting :ref:`Flow Controls (CAN Packets) `. .. seealso:: Only the typical use case of :ref:`Flow Control ` was described here. Check :ref:`Flow Status ` parameter and meaning of its values to learn about other use cases. .. _knowledge-base-can-performance-and-error-handling: Performance and Error Handling ------------------------------ ISO 15765-2 defines the following network layer timing parameters for Diagnostics over CAN (DoCAN): - N_As_ - N_Ar_ - N_Bs_ - N_Br_ - N_Cs_ - N_Cr_ .. figure:: ../../images/CAN_Timings.png :alt: Diagnostic on CAN timings :figclass: align-center :width: 100% Network layer time values (N_As, N_Ar, N_Bs, N_Br, N_Cs, N_Cr) present during UDS on CAN communication. .. note:: The example uses :ref:`segmented diagnostic message transmission ` as it enables to present all CAN timing parameters. For :ref:`unsegmented diagnostic message transmission ` though, the only applicable time parameter is N_As_. .. _knowledge-base-can-n-as: N_As ```` N_As is the time parameter of a :ref:`CAN Packet ` transmission on the sender side. It is measured from the start of the CAN frame transmission until the transmission confirmation is received from the data link layer. Timeout value: 1000ms Error handling: If N_As timeout is exceeded, the transmission of the :ref:`diagnostic message ` shall be aborted. Affected :ref:`CAN Packets `: - :ref:`Single Frame ` - :ref:`First Frame ` - :ref:`Consecutive Frame ` .. _knowledge-base-can-n-ar: N_Ar ```` N_Ar is the time parameter of a :ref:`CAN Packet ` transmission on the receiver side. It is measured from the start of the CAN frame transmission until the transmission confirmation is received from the data link layer. Timeout value: 1000ms Error handling: If N_Ar timeout is exceeded, the reception of the :ref:`diagnostic message ` shall be aborted. Affected :ref:`CAN Packets `: - :ref:`Flow Control ` .. _knowledge-base-can-n-bs: N_Bs ```` N_Bs is the time parameter related to :ref:`Flow Control (CAN Packet) ` reception by a sender. It is measured from the end of the last CAN Packet transmission (either transmitted :ref:`First Frame `, :ref:`Consecutive Frame `, or received :ref:`Flow Control `) until the reception of :ref:`Flow Control `. Timeout value: 1000ms Error handling: If N_Bs timeout is exceeded, the reception of the :ref:`diagnostic message ` shall be aborted. Affected :ref:`CAN Packets `: - :ref:`Flow Control ` .. _knowledge-base-can-n-br: N_Br ```` N_Br is the time parameter related to :ref:`Flow Control (CAN Packet) ` transmission by a receiver. It is measured from the end of the last CAN Packet transmission (either received :ref:`First Frame `, :ref:`Consecutive Frame `, or transmitted :ref:`Flow Control `) until the start of :ref:`Flow Control ` transmission. Performance requirement: A receiving entity shall transmit the :ref:`Flow Control ` packet before N_Br reaches its maximal allowed value. .. code-block:: [N_Br] + [N_Ar] < 0.9 * [N_Bs timeout] [N_Br max] = 900ms - [N_Ar] Affected :ref:`CAN Packets `: - :ref:`Flow Control ` .. _knowledge-base-can-n-cs: N_Cs ```` N_Cs is the time parameter related to :ref:`Consecutive Frame ` packet transmission by a sender. It is measured from the end of the last CAN Packet transmission (either received :ref:`Flow Control ` or transmitted :ref:`Consecutive Frame `) until the start of :ref:`Consecutive Frame ` transmission. Performance requirement: A sending entity shall transmit the :ref:`Consecutive Frame ` packet before N_Cs reaches its maximal allowed value. .. code-block:: [N_Cs] + [N_As] < 0.9 * [N_Cr timeout] [N_Cs max] = 900ms - [N_As] Affected :ref:`CAN Packets `: - :ref:`Consecutive Frame ` .. _knowledge-base-can-n-cr: N_Cr ```` N_Cr is the time parameter related to :ref:`Consecutive Frame ` packet reception by a receiver. It is measured from the end of the last CAN Packet transmission (either transmitted :ref:`Flow Control ` or received :ref:`Consecutive Frame `) until the reception of :ref:`Consecutive Frame `. Timeout value: 1000ms Error handling: If the N_Cr timeout is exceeded, the reception of the :ref:`diagnostic message ` shall be aborted. Affected :ref:`CAN Packets `: - :ref:`Consecutive Frame ` .. _knowledge-base-can-unexpected-packet-arrival: Unexpected Packet handling `````````````````````````` According to ISO 15765-2:2016: As a general rule, arrival of an unexpected N_PDU from any node shall be ignored, with the exception of SF N_PDUs and physically addressed FF N_PDUs; functionally addressed FirstFrames shall be ignored. When the specified action is to ignore an unexpected N_PDU, this means that the network layer shall not notify the upper layers of its arrival. Depending on the network layer design decision to support full- or half-duplex communication, the interpretation of “unexpected” differs: a) with half-duplex, point-to-point communication between two nodes is only possible in one direction at a time; b) with full-duplex, point-to-point communication between two nodes is possible in both directions at once. Half-duplex ''''''''''' `Half-duplex `_ allows communication in only one direction at a time. Each node can act either as sender or receiver, but not both simultaneously. Handling of unexpected CAN packets during half-duplex communication: +--------------+--------------------------+-------------------------+-----------------------+--------------+---------+ | Status | Single Frame | First Frame | Consecutive Frame | Flow Control | Unknown | +==============+==========================+=========================+=======================+==============+=========+ | Idle | Process the Single Frame | Process the First Frame | Ignore | Ignore | Ignore | | | | | | | | | | as the start of | as the start of | | | | | | | | | | | | | a new message. | a new message. | | | | +--------------+--------------------------+-------------------------+-----------------------+--------------+---------+ | Segmented | Ignore | Ignore | Ignore | Ignore | Ignore | | | | | | | | | message | | | | | | | | | | | | | | transmission | | | | | | | | | | | | | | in progress | | | | | | +--------------+--------------------------+-------------------------+-----------------------+--------------+---------+ | Segmented | Terminate the current | Terminate the current | If awaited, | Ignore | Ignore | | | | | | | | | message | message reception | message reception and | then process | | | | | | | | | | | reception | and process | process the First Frame | the Consecutive Frame | | | | | | | | | | | in progress | the Single Frame | as the start of | in the on-going | | | | | | | | | | | | as the start of | a new message. | reception and perform | | | | | | | | | | | | a new message. | | required checks | | | | | | | | | | | | | | (e.g. Sequence Number | | | | | | | | | | | | | | in order). | | | | | | | | | | | | | | Otherwise, ignore it. | | | +--------------+--------------------------+-------------------------+-----------------------+--------------+---------+ Full-duplex ''''''''''' `Full-duplex `_ allows simultaneous bidirectional communication. A node may act as sender for one message while simultaneously receiving another. Handling of unexpected CAN packets during full-duplex communication: +--------------+--------------------------+-------------------------+-------------------------+--------------+---------+ | Status | Single Frame | First Frame | Consecutive Frame | Flow Control | Unknown | +==============+==========================+=========================+=========================+==============+=========+ | Idle | Process the Single Frame | Process the First Frame | Ignore | Ignore | Ignore | | | | | | | | | | as the start of | as the start of | | | | | | | | | | | | | a new message. | a new message. | | | | +--------------+--------------------------+-------------------------+-------------------------+--------------+---------+ | Segmented | If a message reception | If a message reception | If a message reception | Ignore | Ignore | | | | | | | | | message | is in progress then see | is in progress then see | is in progress then see | | | | | | | | | | | transmission | the corresponding cell | the corresponding cell | the corresponding cell | | | | | | | | | | | in progress | in the row below. | in the row below. | in the row below. | | | | | | | | | | | | Otherwise, process | Otherwise, process | Otherwise, ignore it. | | | | | | | | | | | | the Single Frame as | the First Frame as | | | | | | | | | | | | | the start of | the start of | | | | | | | | | | | | | a new message. | a new message. | | | | +--------------+--------------------------+-------------------------+-------------------------+--------------+---------+ | Segmented | Terminate the current | Terminate the current | If awaited, then | Ignore | Ignore | | | | | | | | | message | message reception and | message reception and | process the Consecutive | | | | | | | | | | | reception | process the Single | process the First Frame | Frame in the on-going | | | | | | | | | | | in progress | Frame as the start | as the start of | reception and perform | | | | | | | | | | | | of a new message. | a new message. | required checks (e.g. | | | | | | | | | | | | | | Sequence Number in | | | | | | | | | | | | | | order). | | | | | | | | | | | | | | Otherwise, ignore it. | | | +--------------+--------------------------+-------------------------+-------------------------+--------------+---------+