Wurde z.B. IPC gewählt sind das alle Botschaften der Adressen 0x720 (Request) und 0x728 (Answer):

Time   ID     DLC Data                    Comment
17,487 720      8 02 10 01 00 00 00 00 00 
17,497 728      8 06 50 01 00 32 01 F4 00 
17,798 720      8 02 10 03 00 00 00 00 00 
17,806 728      8 06 50 03 00 32 01 F4 00 
19,607 720      8 02 27 01 00 00 00 00 00 
19,621 728      8 05 67 01 16 58 87 00 00 
19,622 720      8 05 27 02 D3 C7 A9 00 00 
19,642 728      8 02 67 02 00 00 00 00 00 
20,198 720      8 06 2E 61 BB 01 D4 0A 00 
20,215 728      8 03 6E 61 BB 00 00 00 00 

Im obigen Snapshot sind also nur Single-Frames enthalten (Bit 7-4 vom PCI-Byte sind immer 0). Das erste Byte enthält also jeweils die Nutzdatenlänge. Gekürzt auf die reinen Nutzdaten (PDU) von UDS siehst das dann so aus:

Time   ID         Data                    Comment
17,487 720   REQ  10 01
17,497 728   ANS  50 01 00 32 01 F4
17,798 720   REQ  10 03
17,806 728   ANS  50 03 00 32 01 F4
19,607 720   REQ  27 01
19,621 728   ANS  67 01 16 58 87
19,622 720   REQ  27 02 D3 C7 A9
19,642 728   ANS  67 02
20,198 720   REQ  2E 61 BB 01 D4 0A
20,215 728   ANS  6E 61 BB

Das erste Byte der PDU Nutzdaten der Anfrage (REQ) enthält den Service-Identifier (SID). Aus obigem Beispiel kommen hier:

• 0x10 ⇒ UDS_SI_DiagnosticSessionControl
• 0x27 ⇒ UDS_SI_SecurityAccess
• 0x2E ⇒ UDS_SI_WriteDataByIdentifier

Positive Antwort ⇒ Konnte die Anforderung vom Modul (Client) verarbeitet werden, enthält das erste Byte der PDU der Antwort die SID + 0x40, konnte die Anfrage verarbeitet werden.
Negative Antwort ⇒ Im Fehlerfall wird als erstes Byte der PDU der feste Wert 0x7F gesendet. Ihm folgt dann die eigentlich angefragte SID

Time   ID         Data                    Comment
17,487 720   REQ  10 01                   UDS_SI_DiagnosticSessionControl
17,497 728   ANS  50 01 00 32 01 F4       => OK
17,798 720   REQ  10 03                   UDS_SI_DiagnosticSessionControl
17,806 728   ANS  50 03 00 32 01 F4       => OK
19,607 720   REQ  27 01                   UDS_SI_SecurityAccess
19,621 728   ANS  67 01 16 58 87          => OK
19,622 720   REQ  27 02 D3 C7 A9          UDS_SI_SecurityAccess
19,642 728   ANS  67 02                   => OK
20,198 720   REQ  2E 61 BB 01 D4 0A       UDS_SI_WriteDataByIdentifier
20,215 728   ANS  6E 61 BB                => OK

Time   ID         Data                    Comment
17,487 720   REQ  10 01                   DiagnosticSessionControl => Default session
17,497 728   ANS  50 01 00 32 01 F4       => OK
17,798 720   REQ  10 03                   DiagnosticSessionControl => Extended Diagnostic Session
17,806 728   ANS  50 03 00 32 01 F4       => OK
19,607 720   REQ  27 01                   SecurityAccess => Request SEED from ECU
19,621 728   ANS  67 01 16 58 87          => OK, SEED is ''0x16 0x58 0x87''
19,622 720   REQ  27 02 D3 C7 A9          SecurityAccess => Send KEY calculated from SEED to ECU ''0xD3 0xC7 0xA9''
19,642 728   ANS  67 02                   => OK, Access Granted
20,198 720   REQ  2E 61 BB 01 D4 0A       WriteDataByIdentifier, DID = 0x61BB, Data = 0x01D40A
20,215 728   ANS  6E 61 BB                => OK, DID 0x61BB set

Ein CAN-Frame wird immer auf 8 Bytes mit 0x00 gefüllt (Padding), auch wenn die eigentlichen Nutzdaten (Payload) weniger sind.

Bit 7 6 5 4 | 3 2 1 0
    [FTYPE] | [ DL  ]

• Bit 7..4 (Type) ⇒ Frame-Type:
  • 0x0* = Single Frame (SF)
  • 0x1* ⇒ First Frame (FF)
  • 0x2* ⇒ Consecutive Frame (CF)
  • 0x3* ⇒ Flow Control Frame (FC)
• Bit 3..0 (DL) ⇒ Anzahl der nun folgenden Datenbytes im CAN-Frame

0x10 General reject
0x11, 0x12, 0x7E, 0x7F Service or Subfunction not supported (in active Session)
0x13 Message length or format incorrect
0x31 Out of range
0x21 Busy – Repeat request
0x78 Busy – Response pending
0x22 Conditions not correct
0x24 Request sequence error
0x33 Security access denied
0x35 Invalid key
0x36 Exceed attempts

• Schleife durch alle möglichen IDs auf dem Bus (bei 11 Bit CAN-ID, Adressbereich 0x700 - 0x7FF scannen) und damit eine Map erstellen von den Modulen die antworten
• Pro ID:
  • Einen leeren Payload senden um eine Antwort zu provozieren
  • Eine „Tester-Present“ Botschaft in der Payload hinterlegen: 02 3E 00 00 00 00 00 00, bzw. 02 3E 80 00 00 00 00 00 (mit Suppress-Bit)

Eine UDS-Übertragung erkennt man an den verwendeten CAN-Adressen. Im CAN-Netzwerk haben die Botschaften Adressen, nicht die Teilnehmer. Das unterscheidet CAN von vielen anderen Bussystemen. Natürlich entstehen diese Botschaften von Teilnehmern und sind für eine oder mehrere andere Teilnehmer gedacht. So kann auch eine Kommunikation entstehen. Im Fall von UDS werden spezielle CAN-IDs dafür verwendet. Das Gerät welches die Kommunikation initiiert und führt wird dabei „Server“ bzw. „Tester“ genannt, das Modul welches eine Botschaft verarbeiten soll ist der „Client“. Im Ford Mondeo MK4 CAN-Netzwerk hat man jedem Modul eine feste UDS-Adresse zugeordnet. Diese Zuordnung gilt auf allen CAN-Bussen (HS-, MS,- und MM-CAN), auch wenn nur jeweils bestimmte Module in den jeweiligen Bussen zu finden sind.

Hier gibt es eine Übersicht aller Module im Mondeo MK4 mit ihren UDS-IDs: CAN-Bus IDs für Module im MK4.

Der Tester wählt sich ein Modul aus mit dem kommuniziert werden soll, z.B. das Kombiinstrument (UDS CAN-ID 0x720) und erzeugt eine CAN-Botschaft mit dieser ID. Das IPC erkennt das diese Botschaft für es bestimmt ist und verarbeitet diese. Als Ergebnis wird es seinerseits eine CAN-Botschaft mit einer Antwort auf den Bus legen, jedoch mit einer um 8 erhöhten CAN-ID.

Ein CAN-Frame hat einen Payload von max. 8 Bytes. Mittels des Transportprotokolls ISO 15765-2 können bis zu 4095 Bytes durch Segmentierung mittels einzelner CAN-Frames übertragen werden.

• 0x720 is Tester to IPC
• 02 10 01 00 00 00 00 00 ⇒
  • Byte 1 'PCI':
    • Bit 7..4: Single-Frame
    • Bit 3..0: DL = 2 Bytes
  • Byte 2..3 'Payload'
    • 10 01
• 0x728 is positive reply IPC to Tester