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

Question

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.

Answer 1

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.

Answer 2

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.