An Insight into UDS - Diagnostics!

23 Nov 2017

I thought I'll get started onto UDS now.. the other important must-know subject with a lot of significance

  • What is UDS?

    • Standing for Unified Diagnostic Services, UDS is a group of services that were put together and developed as a framework. Most cars follow the UDS standard to implement on-board diagnostics.

    So What first is Diagnostics? It is a set of routines that run inside a car internally to check if ECUs are working properly etc. They also have services that make EOL testing easy, giving information needed by a service engineer at a service centre. It is a very very useful tool helpful to diagnose what's going on.

  • How UDS works?

    • UDS is a CAN frame with specific format in the DATA bytes. You generally need to know CAN ID for the node you require Diagnostic information from.(Physical 1:1 addressing).Broadcast/Functional (1:n) is also possible but I have not come across this use-case. Lets go over addressing schemes, frame format and about a few services. Standards related to UDS: ISO 15765, ISO 14229.

  • What is a diagnostics service?
    • A kind of a task for an ECU to execute on command
    • Each service is defined by a request/response message pair
    • Test device sends service request message to ECU
    • ECU sends service response message to test device
  • Addressing Schemes
    • There are 4 addressing schemes. Generally First byte of Data bytes is called Protocol Control information(PCI).
    • Normal Addressing: Address in CAN ID.This has the CAN ID, PCI followed by data( max of 7 bytes), 2CAN IDs used - sending/receiving
    • Normal Fixed Addressing: All addressing information is in CAN ID.Priorty,ID Mask,Target Address,Source Address in the 29 bit identifier. It also uses 2 CAN ids.
    • Extended Addressing: Addressing info in the first data byte. 1 CAN id for all requests
    • Mixed Addressing: Addressing info in Identifier and in first data byte.
  • Transport Frames
    • There are 4 frames involved in UDS. It is based on UUDT- Unacknowledged Unsegmented Data Transfer and USDT- Unacknowledged segmented data transfer. First byte of data contains this information - PCI - Protocol Control information.
    • First Frame

      • If there are more than 8 bytes of data then PCI will begin with a "1" to indicate first frame. This is first part of a segmented message.

    • Flow Control Frame

      • It is an Acknowledgment from the receiver. This follows the first frame begins with "30". Second byte tells how many Consecutive frames will pass before a Flow control is again sent and Third byte specifies delay between 2 consecutive frames. 00 for as soon as possible.

    • Consecutive Frame

      • This follows first flow control frame and begins with "21", goes all the way to "2F" and restarts with "20" if more data is there.

    • Single Frame

      • This is for transfer of Unsegmented messages. PCI - first nibble is zero. Second nibble ranges from 0 to 7.
      Eg: 02 10 01 00 00 00 00 00

    Example for Flow Control

    • FF--10 18 49 53 4f 20 54 44
    • FC--30 02 14 00 00 00 00 00
    • CF--21 3e 4d 5f 61 72 8e 9f
    • CF--22 1f 2e 6f 8e 92 be bf
    • FC--30 02 14 00 00 00 00 00
    Here in First Frame(FF), 018 is the data length. Max is FFF - 4095 bytes length.
    In FC - "3" denotes flow control frame. "0" or "1" denotes clear to send or wait. "02" denotes number of consecutive frames before next Flow control frame-Blocksize. "OO" means this is last flow control frame."14" denotes separation time,"00" means send as fast as possible. Then CF's continue

    An understanding about timing Requirements of flow control can be gained from below:
  • Overview on Servies
    • This image below will give a quick overview. More details follows in the passages below:
    • Service 10 - Diagnostic Session Control
      • There are 4 or 5 diagnostic sessions based on OEMs. They are:
      1. Default Session-01
      2. Programming Session-02
      3. Extended Session-03
      4. Safety Extended Session-04
      5. EOL session-40
      Example: 02 10 03
      06 50 03 00 32 01 FF
      0x0032 is P2 performance timer, (50ms)
      Minimum time before which server has to send a response.
      If it is unable to send response, it has to send NRC-78 - request received response pending
      Then it has to send response within maximum time of 0x01ff - P2 extended performance timer.(5000ms)
      For negative response - 7f precedes the service followed by reason(Negative Response code -NRC)
      (while vehicle speed is given) 02 10 03
      03 7f 10 22
      (22 is conditions not correct NRC) Positive Response can be supressed by setting first bit of subfunction(SUPRESS POSITIVE RESPONSE Bit - SPRMIB). Eg: 02 10 83
    • Service 11 - ECU Reset
      • There are 2 subfunctions here.
      1. Hardreset - Similar to Cold reset. The cluster is powered off and start again similar to a cold start
      2. Softreset - not supported.
      Example: 02 11 01
      02 51 01
    • Service 22- Read data by Identifier
      • Used to read specific DIDs- Diagnostic Data Identifiers for information. No subfunctions. Eg:
      03 22 d1 00
      04 62 d1 00 01
    • Service 23- Read memory by address
      • Used to read ROM Block addresses and return data. No subfunctions. Eg:
      04 23 16 07 1f
      05 63 16 07 1f 01
    • Service 27 - Security Access
      • Used to Request Security Access Unlock in Extended and Programming Modes. This is necessary for few services like IO control by Identifier, Read Memory by address, Etc. For programming mode access, Services like Request Download, Transfer Data, Request Transfer Exit. Has 2 subfunctions - Request seed(odd subfunction) , Send key(even subfunction, odd+1) There are three security unlock accesses - General/Level2 (03,04) , Extended/Level 17 (21,22), OEM specific/Level 18 (23,24) How it works is, once you request seed, a 3 byte seed is sent by ECU. Then you have to generate Key by an algorithm that uses this seed with 5 byte constant and with some hex value EXORs each bit 64 times and arrives at the 3 byte key. If key matches the one ECU calculates internally, security access is provided.
    • Service 2E - Write Data by Identifier
      • Writes data into specific identifiers. Generally not supported
    • Service 2F - I/o Control by Identifier
      • Controls specific portions of ECU. Eg: Test screens for LCD(FE0A), Illumination(7139), Chimes(8022)
    • Service 31 - Routine Control
      • Runs pre-defined tests and returns results. Eg: 0x202- On Demand self test
    • Service 34 - Request Download
      • Start of Download in Flash sequence
    • Service 35 - Request Upload
      • Goes to upload scenario, have not come accross this use case
    • Service 36 - Transfer Data
      • Actual Transfer of data takes place
    • Service 37 - Request Transfer Exit
      • End of Flash sequence has this service.
    • Service 3d - Write Memory by address
      • Supposed to write into address location with data. I have not been able to use this yet.
    • Service 3e - Tester Present
      • Continuously sends tester present so that session is maintained or routine is run. Has one subfunction - 00 the zero subfunction
    • Service 85 - Control DTC Setting
      • Controls whether DTC will be logged or not. Not suported in default session.
      Has two subfunctions - 01 -on and 02 -off
    An Overview on Negative Response Codes:
    I have intentionally not covered Service 14 - Clear DTC, Service 19 - Read DTC here. More on them later!

    NOTE: Images taken from Softing poster, Ford GGDS spec, Vector Diagnostic Seminar Spec, Reproduced here for understanding purposes.