implement-uds - CAN11 CAN29

[GuillaumeFegeFullElec]

In order to be compatible with 11bits CAN ids and 29bits CAN ids, UDS an ISOTP Network do not use CAN ids (0x7E0, 0x7DF , ..). for address field. ISOTP Network and UDS use SA (source address) and TA (target adress) as follow :

• 0x00 : ECU#0
• ...
• 0x07 : ECU#7
• 0x33 : Functional (only for target address)
• 0xF7 : Test equipement

And isotp make the correspondance with CAN id as follow, For CAN11 :

• 0x7E0 : SA=0xF7 - TA=0x00
• ...
• 0x7E7 : SA = 0xF7 - TA = 0x07
• 0x7E8 : SA = 0x00 - TA = 0x7F
• ...
• 0x7EF : SA = 0x07 - TA = 0x7F
• 0x7DF : SA = 0x7F - TA = 0x33

For CAN29 :

• 0x18DA00F1 : SA=0xF7 - TA=0x00
• ...
• 0x18DA07F1 : SA=0xF7 - TA=0x07
• 0x18DAF100 : SA = 0x00 - TA = 0x7F
• ...
• 0x18DAF107 : SA = 0x07 - TA = 0x7F
• 0x18DB33F1 : SA = 0x7F - TA = 0x33

Is it possible to add this address abstraction into this API ? Then the user could use TA and SA regardless the CAN 11 / CAN 29 implementation ?

[ericevenchick]

Can you explain how these work? I do not understand how the SA and TA end up forming the addresses.

[GuillaumeFegeFullElec]

Do you have the standart ISO_15765-4 ? Page 11,12,13 there is the explainations. Otherwise i will try to explain it.

With CAN, there is no adresses, just an ID that can represent a function, an adresse or what either you like. There is two types of ID : 11 bits and 29 bits

ISOTP network provide three fields :

• TA (target addresse) : 1 byte ( 0x00 - 0xFF )
• SA (source addresse) : 1 byte ( 0x00 - 0xFF ):
• TA_type (target adresse type) : physical / functional If TA_type is physical , TA is the adresse of one ECU, then only this ECU may responds If TA_type is functional, TA represent a functional service (example 0x33 : OBD system). Then all ECU that implements this service may responds.

There is some TA and SA values reserved :

• 0x00 - 0x07 : physical addresse of ECUs 0 - 7
• 0x33 : functional addresse for ECUs OBD systems
• 0xF1 : physical addresse of external test equipement

Then, if CAN use 29 bits ID, all messages ID are encoded like this : Functional addresse type : 0x18DBXXYY : With XX is TA and YY is SA Phisical addresse type : 0x18DAXXYY : With XX is TA and YY is SA

if CAN use 11 bits ID, all messages ID are encoded like this : 7DF CAN identifier for functionally addressed request messages sent by external test equipment 7E0 Physical request CAN identifier from external test equipment to ECU #1 7E8 Physical response CAN identifier from ECU #1 to external test equipment 7E1 Physical request CAN identifier from external test equipment to ECU #2 7E9 Physical response CAN identifier from ECU #2 to external test equipment 7E2 Physical request CAN identifier from external test equipment to ECU #3 7EA Physical response CAN identifier from ECU #3 to external test equipment 7E3 Physical request CAN identifier from external test equipment to ECU #4 7EB Physical response CAN identifier ECU #4 to the external test equipment 7E4 Physical request CAN identifier from external test equipment to ECU #5 7EC Physical response CAN identifier from ECU #5 to external test equipment 7E5 Physical request CAN identifier from external test equipment to ECU #6 7ED Physical response CAN identifier from ECU #6 to external test equipment 7E6 Physical request CAN identifier from external test equipment to ECU #7 7EE Physical response CAN identifier from ECU #7 to external test equipment 7E7 Physical request CAN identifier from external test equipment to ECU #8 7EF Physical response CAN identifier from ECU #8 to external test equipment

Is it clearer now ?

[brandonros]

In order to be compatible with 11bits CAN ids and 29bits CAN ids, UDS an ISOTP Network do not use CAN ids (0x7E0, 0x7DF , ..). for address field.

So, pyvit is not compatible with UDS/ISOTP?