7.1 General information
This part of ISO 15765 makes use of the network layer services defined in ISO 15765- 2 for the transmission and reception of diagnostic messages. This section defines the mapping of the Application layer protocol data units (A PDU) onto the Network layer protocol data units (N PDU).
NOTE:The netwDrk layer services are used to perfom the application layer and diagnostic session management timing (see 6.3)
7.2 FlowControl N_PCI parameter definition
The client shall not use the values of F1 hex - F9 hex for the Strmin parameter. These Stmin parameter values shall be supported by the senver(s) if requested by the vehlcle manufacturer.
7.3 Mapping of A_ PDU onto N_ PDU far message transmission
The parameters of the application layer protocol data unit defined to request the transmission of a diagnostic service request/response aTe mapped in accordance with Table 9 onto the parameters of the network layer protocol data unit for the transmission of a message in the dient/server.
The network layer confirmation of the successful transmission of the message (N USData.con) is forwarded to the application, because it is needed in the application for starting those actions, which shall be executed immediately after the transmission of the request/response message (ECUReset, BaudrateChange, etc).
Table 9 - - Mapping of ServiceName.requestServiceName.response A PDU onto N USData.request N PDU
| A_ PDU parameter (Application Protocol Data Unt]) |
Description | N_ PDU parameter (Network Protacol Data Unit) |
Description |
| A_ SA | Application Source Address | N SA | Network Source Address |
| A_ TA | Application Target Address | N_TA | Network Target Addess |
| A _TAtype | Application Target Address type | N _TAtype | Network Target Address type |
| A_ RA | Application Remote Address | N_AE | Network Address Extension |
| A_ PCI.SI | Application Protocol Control infomnation Service ldenfifer |
N_Data[0] | Network Data |
| A_ Data[0]- A _Data[n] | Application Data | N_ Data(1] N_ Data[n+1] | Network Data |
7.4 Mapping of N_ PDU onto A_ PDU for message reception
The parameters of the network layer protoco! data unit defined for the reception of a message are mapped in accordance with Table 10 onto the parameters of the aplication layer protocol data unit for the confimation/indication of the reception of a diagnostic response/tequest.
The network layer indication for the reception of a FirstFrame N PDU (N USDataFirstFrame.ind) is not forwarded to the apptication, because it is only used within the application layer to perform the application layer timing (see 6.3)_ Therefore,no mapping of the N USDataFirstFrame.ind N_ _PDU onto an A_PDU is defined.
Table 10 - - Mapping of N_ USData.ind N_PDU onto ServiceName.conf/ServiceName.ind A_PDU
| N_ PDU parameter (Network Protacol Data Unit) |
Description | A_ PDU parameter (Application Protocol Data Unt]) |
Description |
| N SA | Network Source Address | A_ SA | Application Source Address |
| N_TA | Network Target Addess | A_ TA | Application Target Address |
| N _TAtype | Network Target Address type | A _TAtype | Application Target Address type |
| N_AE | Network Address Extension | A_ RA | Application Remote Address |
| N_Data[0] | Network Data | A PCI.SI | Application Protocol Control infomnation Service ldenfifer |
| N_ Data(1] N_ Data[n+1] | Network Data | A_ Data[0]- A _Data[n] | Application Data |
8 Standardized diagnostic CAN identifiers
8.1 Leglslated 11 bit OBD CAN identifiers
The 11 bit CAN idenifers for legislated OBD can also be used for enhanced diagnostics (e.g. the funcionat request CAN Id can be used for the functionally addressed TesterPresent (3E hex) request message to keep a non-defaultSession active).
If the 11 bit CAN Identifers as specified in ISO 15765-4 are re used for enhanced diagnostics, then the
following requirements apply.
a) network layer timing parameters according ISO 15765-4 shal} also apply for enhanced diagnostics;
b) the DLC (CAN data length code) shall be set to eight (8) and the CAN frame shall include eight (8) bytes (unused bytes shall be padded).
NOTE:ISO 15765-4 allows for max. a OBD related servers (ECUs) therefore, 11 bit CAN identiers for max 8 sorvers are defined.
8.2 Legislated 29 bit OBD CAN identifiers
The 29 bit CAN identihiers for legislated 0BD comply with the Nommal fixed addressing format specified in ISO 15765-2 and can als0 be used for enhanced diagnostics.
If the 29 bit CAN Identifers as specifed in Iso 15765-4 are e-used for enhanced diagnostics, then the following requirements apply:
a) network layer timing parameters as specifed in ISO 15765 4 shall also apply for enhanced diagnostis;
b) the DLC shall be set to eight (8) and the CAN frame shall include eight (8) bytes (unused bytes shall be padded).
NOTE:The CAN identifer values given in the tables use fthe default value for the priarity information in acordance with ISO 15765-2
8.3 Enhanced diagnostlcs 29 blt CAN Identifiers
8.3.1 General information
This section speifies a standardized addressing and routing concept for CAN using 29 bit identifers. The concept makes use of the well- known and approved mechanisms of the internet protocol (IP). By this means,standardized algorithms for addressing and routing can be used for all nodes in the whole network independent of their positioning in subnetworks.
This addressing and routing concept provides the following features:
- Maximum flexlbility during the design process of network structures,
- full customization of network and node address,
- the possiblility of CAN controller hardware filter feature optimization by the assignment of the appropniate network and node address,
- gateways need to know Orly network addresses of the connected sub-networks instead of all addresses of their sub-network members.
8.3.2 Structure of 29 bit CAN identifier
The 29 bit CAN identifer structure specified in this document is compatible in regard to coexistence with the definitions in IS0 15765-2 ISO 15765-3 and ISO 15765 4 and with SAE J1 939-21. Therefore, the encoding of bit 25 (Reserved/Extended Data Page) and bit 24 (Data Page) in the 29 bit CAN identifer structure defined in SAE J1939-21 shal be used to determine whether a CAN identifer and frame is of SAE J1939 or ISO 15765 format. This enables the vehicle network designer to define non-diagnostic messages and associated CAN identifiers customized according to his needs or to uilize and beneft from the definitions in SAE J1939 in combination with a diagnostc services implementation as defined in ISO 15765-2, ISO 15765-3 and ISO 15765-4.
8.3.2.1
Structure of SAE J1939 29 bit CAN identifier
For infomaticn about the structure of the SAE J1939 29 bit CAN identifier format, see Table 11.
Table 11- - SAE J1939 structure of 29 bit CAN identifiers
| 29 blt CAN identifier | ||||||||||||||||||||||||||||
| 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Prionity | Reserved/ Extended data page |
Data page | PDU Format | PDU-specific (destination or PDU format exlenslon) |
Source address (unique source address) |
|||||||||||||||||||||||
8.3.2.2
Structure of ISO 15765 29 bit CAN identifler
Table 12 shows the structure of ISO 15765 CAN identifier that can be distinguished from the SAE J1939 fomat through the“SAE J1939 Reserved/Extended Data Page and ISO 15765 Extended Data Page" bit 25 and the“SAE J1939 Data Page ISO 15765 Data Page" bit 24.Thus, 1SO 1 5765-fomatted and SAE J1939- formatted 29 bit CAN identifiers can coexist on the same physical CAN bus system without interference.
Table 12一ISO 15765 structure of 29 bit CAN identifiers
| 29 bit CAN identifier | ||||||||||||||||||||||||||||
| 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Priority | Extended data page |
Data page | Type of senvice (TOS) |
Source address | Destination address | |||||||||||||||||||||||
| Encoding see 8.3.2.4 |
Encoding see 8.3.2.5 |
Unique source address. see8.3.3 |
Unique destination address. see8.3.3 |
|||||||||||||||||||||||||
8.3.2.3 Prority field
The priority field is defined as specifed in SAE J1939, to make use of the arbitration mechanism of CAN. Because the CAN identifer can no longer be assigned freely (source and target address are included in CAN identifier), the priority of a CAN message would be assigned by the sender (source address) and the receiver (target address) of that message indirectly. Eight (8) different priority tevels are possible.
Priority level 6 (110b) shal be assigned to diagnostic request messages/trames.
8.3.2.4 Extended Data Page and Data Page field
The Extended Data Page and Data Page bits determine which format of the 29 bit CAN identifer shalil be used. Table 13 specifes the encoding.
Table 13一Definition of Extended Data Page and Data Page field
| Extendcd data page bit 25 | Data page bit 24 | Descrlptlon |
| 0 | 0 | SAE J1939 defined or manufacturer deined "Normal Commumicaion Message" setrategy if SAE M1939 is nof implemenled |
| 0 | 1 | SAE J1939 defned or mantacurer-defined "Normal Communication Message" strategy if SAE J1939 is not implemenled |
| 1 | 0 | SAE J1939-eserved or manufatuer defned "Normnal Cornmunlcation Message" strategy if SAE J1939 is not implemenled |
| 1 | 1 | ISO 15765-3 defned |
8.3.2.5 Type of service (TOS) field
The type of service feld is used to be able to address diterent services of a node without having to assign different addresses to it. Thus, eight (8) different service types of a node can be addressed concurrently using a single destnation address. The dffrent types of services and their usage are defined in Table 14.
Table 14一Definiton of Types of Service (TOS)
| Blt23 | Bit22 | Type Of Servlce (TOS) | Destription |
| 0 | 0 | ISO resenved | This bit cormbinaticn is resenvcd for future use by ISO. |
| 0 | 1 | OEM-defined messages | This bit combinaion indicates that the messages are OEM specific A comblnation of ISO 15765-3 and legacy protocol messages can be used to support a mixture of senvers on the same nelwork with dfferent protocol messages. |
| 1 | 0 | Network control message protocol / network management |
This bit combination indicates that the frame(s) contain data sent and received by gateways to supply information about the cuTent state of subnets leg- network unreachable, nehwork overload) and nodes c.g. host unreachable). |
| 1 | 1 | ISO 15765-3-defined messages | This bit combination indicales an Iso 15765-3 defined diagnostic senvice addressed to a node. The user data bytes of the CAN frame contaln diagnostic requests (ISO 15765-3) using the nelvork layer senvices and transport layer defined in ISO 15765-2. |
8.3.2.6 Source address
The source address contains the address of the sending entity. This information ensures the correct anbitration and can be used by the receiver of a message to address its replies. The structure of the source address is descnbed in 8.3.3.
8.3.2.7 Dcstination address
The destination address contains the address of the receiving entity. This can be a single node, the broadcast address of a network or a genenc broadcast. The destination address is used by gateways to determine whether the CAN frame shall be routed to another CAN bus or not. The structure of the target address is described in 8.3.3.
8.3.3 Structure of address
8.3.3.1 General Infomation
The source and destination addresses are encoded in the 29 bit CAN identifer with a length of 11 bits each. In the following subclauses, the ltters X" and °丫are used to represent a variable parameter.
8.3.3.2 Definltfon of address
An address consists of two parts.
a) Nctwork address
The nelwork address part consists of the first“X° sequential bits of the address and determines a node's network. The same network address shall be assigned to the nodes on one physical bus. The network address part shall not have all bits set to one (1). Thus, the minimum length for the network address part is two (2) bits. The maximum length is nine (9) bits because at least two (2) bits are needed to provide valid node address parts. The maximum number of possible subnets can be calculated as follows:
2X- 1 (where X is the number of bits used for the network address part)
b) Node address
The node address part consists of the remaining "Y”(Y = 11 - X) sequential bits of the address and determines the node within a subnet. It shall be unique within the subnet. All bits set to zero (0) and all bits set to one (1) are not allowed. Thus, the minimum length of the node address part is two (2) bits. The maximum length is nine (9) bits because at least two (2) bits are needed for the network address part. The maximum number of nodes per sub network can be calculated as follows.
2Y- 2 (where Y is the number of bits used for the node address part)
A node is assigned a unique address that shalt be stored in the node's intema! memory. A node shall receive messages with the node's assigned address in the destination address field.
Tabte 15 presents an example for source and destination addresses. The sending and the receiving nodes
| 29 bit CAN identifier | ||||||||||||||||||||||||||||
| 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Priorily 0x6 |
ISO 15765 fomat |
Type of servlce ISO 15765-3 messages |
Source address 0x2ED |
Destination address 0x32F |
||||||||||||||||||||||||
| 1 | 1 | 0 | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 |
