UDS-Sniff decode
UDS im CAN-Datenstrom erkennen und isolieren
1.) Filtern nach CAN-IDs im Bereich 0x700-x7FF
2.) Filtern der CAN-IDs nach Ziel-Modul (ID-Liste)
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
3.) Nutzdaten auf DL-Länge kürzen
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
4.) SID dekodieren
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
5.) Subfunction der SID dekodieren
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
UDS-Botschaften entschlüsseln
Ein CAN-Frame wird immer auf 8 Bytes mit 0x00
gefüllt (Padding), auch wenn die eigentlichen Nutzdaten (Payload) weniger sind.
Byte 1: "PCI-Byte" (Protocol Control Information) dekodieren
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
Error response code
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
UDS-Fähige Module auf dem CAN-Bus finden (module-scan)
- 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)
CAN ISO-TP
CAN-Kommunikation nach ISO 11898
Segmentierung nach ISO 15756-2
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.
Kommunikation
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