CODEWITHSUNDEEP
can-busiot-for-automotive
Semant1ka
Semant1ka

Reputation: 687

Automotive: How does ECU tell a CAN frame is a part of UDS protocol?

Read a lot of specifications and still can't get a simple thing.

All UDS requests encapsulated in ISO-TP packets, which are encapsulated in simple CAN frames, so ECU constantly receives a stream of frames from CAN bus.

How does ECU decide that this CAN frame is a part of any high-level protocol?

For example, I've sent Security request to ECU, CAN frame data will look like this

02 27 01

How does ECU determine that this is not just a chunk of data but a part of the protocol?

I wasn't able to find any relation to ISO/OSI stack when high-level protocols "talk to each other" using headers, so we know how to decode data packets.

Upvotes: 1

Views: 6890

Answers (3)

Maciek
Maciek

Reputation: 612

What information you need

If we are talking about Diagnostic on CAN, then to be able to say whether this communication is using UDS protocol you need to know:

  • CAN Addressing format
  • Addressing Information parameters
    • if Normal Addressing format is used:
    • if Normal Fixed Addressing format is used, it would be simpler as CAN ID scheme is known, so it is enough to get:
      • priority parameter for physical addressing
      • priority parameter for functional addressing
      • (Source for request, Target for response messages) Address of diagnostic tester
      • (Target for request, Source for response messages) Address for each ECU in the vehicle
    • if Extended Addressing format is used, it is the hardest as we need:
      • pair of (for request and response) CAN Identifiers and Target Address (1 byte) parameters for functional addressing
      • pair of (for request and response) CAN Identifiers and Target Address (1 byte) parameters for each ECU that can be physically addressed
    • if Mixed Addressing format with 11-bit CAN Identifier is used then we need:
      • pair of (for request and response) CAN Identifiers and Addressing Extension (1 byte, the same value for request and response messages) parameter for functional addressing channel
      • pair of (for request and response) CAN Identifiers and Addressing Extension (1 byte, the same value for request and response messages) parameter for each ECU that can be addressed physically
    • if Mixed Addressing format with 29-bit CAN Identifier is used then we need:
      • priority parameter for physical addressing
      • priority parameter for functional addressing
      • (Source for request, Target for response messages) Address of diagnostic tester
      • (Target for request, Source for response messages) Address for each ECU in the vehicle
      • Addressing Extension (1 byte, the same for request and response message) for each communication channel (usually the value is unique for each vehicle's network)

How to get them

Certain ways

The only way to be sure that the communication you are observing is diagnostic communication is basing on OEM (e.g. Toyota, FIAT) requirements. So basically, you need to get some piece of documentation or get an access to their standards about diagnostic communication. Those information are either public or have leaked for older car models.

Probable ways

If you have an option to observe diagnostic (UDS) communication, then you would be able to figure out most of the previously mentioned variables/parameters.

In every diagnostic communication you will see Tester Present and Diagnostic Session Control services being used. So you can look for:

  • Tester Present requests will have following data

    might be one byte here 02 3E 00 might be data padding here

    might be one byte here 02 3E 80 might be data padding here

  • Tester Present response will have following data

    might be one byte here 02 7E 00 might be data padding here

  • Diagnostic Session Control request will have following data

    might be one byte here 02 10 XX might be data padding here

    • XX would usually be equal 01, 02, 03 or 04, but might be any value

  • Diagnostic Session Control response will have following data

    might be one byte here 02 50 XX or 06 50 XX YY ZZ WW VV might be data padding here

    • XX be repreated value from request
    • YY, ZZ, WW, VV might be various values

Guessing

Just sending blindly requests (e.g. Tester Present) and hoping for a response. If we assume Normal Fixed Addressing format (which is most likely to be used), this is relatively possible to figure out.

Upvotes: 0

Martin
Martin

Reputation: 11

UDS via CAN is specified in the DoCAN ISO-15765-2 part and describe the network and transport layer for a functional (broadcast) and physical (p2p) communication between ECUs or better control functions.

Normal CAN id's don't implement any network functionalities like a addressing. For that purpose the SAE J1939 network layer is used. In a J1939 network each CAN client has a address and each functionality a parameter group (PGN). All of this is encoded in a 29bit CAN ID. For example the CAN ID 0x18EF8081. This will transport a message from the CAN client 0x81 to 0x80 via the PGN 0xEF, 0x18 is the priority.

In UDS over CAN the PGNs 0xDA (physical) and 0xDB (functional) are used for all communications. With that information's you can implement a CAN ID filter which match only the PGN part of the CAN ID.

Upvotes: 1

MByD
MByD

Reputation: 137442

The CAN message IDs that are used for specific protocols are defined per system.

In most cases the OBD-II will be sent over CAN ID 7DFh for the query and higher IDs for responses from different modules, but even that might be different on specific car models.

One way of figuring out the CAN IDs that are used for UDS-based communication is to send simple tester-present (SID 3Eh) messages and watching for CAN IDs which seems to have an appropriate response.

Upvotes: 2

Related Questions