UDS – podstawy komunikacji diagnostycznej

Cześć!

Mam na imię Wojtek i jestem inżynierem od testowania Systemów Wbudowanych.

Zachęcam do kupienia mojego kursu Wszystko o magistrali CAN

Wstęp

Unified Diagnostic Services (UDS) to standard komunikacyjny stosowany w przemyśle samochodowym, który pozwala na diagnostykę i programowanie układów elektronicznych w pojazdach.

Słowo Unified oznacza nie tylko to, że jest on stosowany przez większość producentów samochodów na całym świecie ale również fakt, że komunikacja za pomocą UDS odbywa się identycznie nieważne od używanego protokołu komunikacyjnego (CAN, LIN, Automotive Ethernet) – treść wiadomości będzie taka sama.

UDS działa na zasadzie REQUEST – RESPONSE. Jedno urządzenie (np. podłączane narzędzie diagnostyczne) nadaje komunikat z żądaniem, a drugie (np. sterownik silnika) na nie odpowiada.

Po pierwsze nie Škodzić

Metaforą, która pomaga zrozumieć działanie UDS, może być rozmowa pomiędzy lekarzem a pacjentem. Lekarz zadaje pytania pacjentowi, aby zbadać jego stan zdrowia, a następnie na podstawie uzyskanych informacji podejmuje decyzję o leczeniu. W przypadku UDS, urządzenie diagnostyczne (lekarz) zadaje zapytania sterownikowi pojazdu (pacjentowi), aby zbadać stan jego systemu i podjąć decyzję dotyczącą konfiguracji lub naprawy.

Lekarz może również wydawać bezpośrednie polecenia: proszę podnieść rękę, proszę otworzyć usta, oddychać głęboko itd., pacjent zaś wykonuje te polecenia niezależnie od tego czy ma na to w tej chwili ochotę.

Diagnostyka samochodowa UDS wizyta u lekarza zapytanie diagnostyczne
Obraz wygenerowany przez Midjourney

Serwisy diagnostyczne

Istnieją różne rodzaje zapytań diagnostycznych nazywanych SERWISAMI. Każdy z nich ma określony numer SID (Service ID). Omówię kilka najważniejszych, w rzeczywistości jest ich dużo więcej:

0x10Ustawianie sesji diagnostycznych (trybów działania urządzenia).
Podstawowe rodzaje sesji to:
0x01 – Default Session. Domyślny, normalny tryb, w którym działa urządzenie po podłączeniu zasilania
0x02 – Programming Session. Mniej popularny tryb używany do modyfikowania oprogramowania. W tym trybie komunikujemy się bezpośrednio z bootloaderem (zob. artykuł o żabie i skorpionie)
0x03 – Extended Session. Sesja rozszerzona, używana do zmian parametrów urządzenia, zapisu do pamięci, i wszystkich działań, do których potrzeba większych uprawnień.
0x22RDBI (Read Data By Identifier) Odczyt parametru z pamięci urządzenia
np. Odczyt numeru seryjnego lub ograniczenia prędkości pojazdu
Do parametru odnosimy się za pomocą identyfikatora (innym serwisem możemy się odwołać wprost do adresu komórki pamięci). Identyfikator ten nazywamy DIDData IDentifier
0x2EWDBI (Write Data By Identifier) Zapis parametrów, analogicznie do powyższego. Również używamy DID do określenia który parametr chcemy zapisać.
0x14Kasowanie błędów (DTC)
0x19Odczyt błędów (DTC)
0x2FInput Output Control – Kontrola Wejść/Wyjść. Służy np. do wymuszania stanu wyjśc cyfrowych urządzenia, niezależnie od stanu SW urządzenia i algorytmu sterującego wyjściami. Przykładowe użycie: sprawdzanie stanu kontrolki LED, która normalnie jest sterowana przez wyjścia cyfrowe urządzenia sterującego, które załączane są tylko w przypadku pojawienia się błędu DTC.
0x31Routine Control. Służy do uruchamiania funkcji w urządzeniu.
System wbudowany może mieć zaimplementowane w swoim kodzie funkcje diagnostyczny, czyli tzw. rutyny. Przykładem rutyny może być inicjalizacja i kalibracja podłączonego czujnika.
Po uruchomieniu rutyny, urządzenie dalej już samodzielnie wykonuje dowolny ciąg instrukcji zdefiniowanych w kodzie.

Pełna lista serwisów, bez dodatkowych komentarzy:

Wiem, ale nie powiem – czyli negatywne odpowiedzi

Zasada działania

Jest jeszcze jeden rodzaj komunikatu, który nazywa się NRC – Negative Response Code. Jest to negatywna odpowiedź na zapytanie UDS (odrzucenie żądania), która idzie w parze z kodem wyjaśniającym powód odrzucenia.

Na powyższym przykładzie widzimy 3 bajty odpowiedzi na żądanie UDS o zmianę wartości danych.

Najpierw wartość 0x7F jako znak, że żądanie jest odrzucone.

Następnie powtórzenie wartości SID z zapytania.

Na koniec kod NRC, czyli rodzaj błędu. W tym przypadku 0x7F oznacza Service not supported in active session. Oznacza to, że aby zapisać parametr musimy się najpierw przełączyć do Extended Session.

Pełna lista kodów NRC

Kod błęduOpis
0x00Nie dotyczy – odpowiedź pozytywna
0x10Odmowa ogólna
0x11Serwis diagnostyczny nieobsługiwany
0x12sub-funkcja nieobsługiwana
0x13Nieprawidłowa długość wiadomości lub format
0x14Odpowiedź zbyt długa
0x21System zajęty (zbyt obciążony by odpowiedzieć)
0x22Warunki niespełnione (np. kluczyk nie jest w pozycji ON)
0x24Nieprawidłowa sekwencja (np. zła kolejność nadanych requestów)
0x31Zapytanie poza zakresem (np. próba przypisania 0xFFF zmiennej 1-bajtowej)
0x33Odmowa dostępu bezpieczeństwa (security access)
0x35Nieprawidłowy klucz (security access)
0x36Przekroczono dozwoloną liczbę prób
0x37Czas odczekania nie minął (np. 2 minuty przerwy po 5 nieudanych próbach)
0x70Odmowa download’u lub upload’u
0x71Transfer danych wstrzymany
0x72Ogólny błąd programowania (flashowania)
0x73Nieprawdłowy licznik bloku (kolejność przesyłania bloków)
0x78Poprawnie otrzymano request – odpowiedź w trakcie przygotowania
UWAGA! To nie jest błąd jako taki, tylko informacja o “pracy w trakcie”
0x7Esub-funkcja nie obsługiwana w bieżącej sesji
0x7Fserwis nie obsługiwany w bieżącej sesji
0x81rpm (obroty silnika) za wysokie
0x82rpm (obroty silnika) za niskie
0x83Silnik pracuje
0x84SIlnik nie pracuje
0x85Silnik pracuje za króko (licząc czas od rozpoczęcia pracy silnika)
0x86Temperatura za wysoka
0x87Temperatura za niska
0x88Prędkość pojazdu za wysoka
0x89Prędkość pojazdu za niska
0x8APedał gazu za wysoko (za mocno)
0x8BPedał gazu za nisko (za słabo)
0x8CSkrzynia biegów nie jest w pozycji “luz”
0x8DSkrzynia biegów nie jest na żadnym biegu (czyli jest na luzie)
0x8FHamulec nie jest wciśnięty lub zaciągnięty
0x90Dźwignia biegów nie jest w pozycji “Park” (dotyczy skrzyni automatycznych)
0x91Sprzęgło konwertera momentu obrotowego zablokowane
0x92Napięcie za wysokie
0x93Napięcie za niskie
Opis błędów. Zzakresy nieużywane lub zarezerwowane “na przyszłość” zostały pominięte.
Więcej szczegółów dotyczących serwisów oraz kodów NRC znajdziesz tutaj: https://automotive.wiki/index.php/ISO_14229

Przykładowe zapytania

Pokażę teraz jak wyglądają przykładowe zapytania UDS oraz odpowiedzi:

Request: proszę wysłać wartość parametru, którego identyfikator to 0x0101

Response: Odpowiadam na request 0x22 (0x22 + 0x40) wartość parametru 0x0101 wynosi 0xF573

Skąd się wzięło 0x62?

W odpowiedzi na każde zapytanie na początku znajduje się potwierdzenie: odpowiadam na SID o takiej wartości. Jednak aby rozróżnić co jest zapytaniem, a co odpowiedzią, do liczby jest zawsze dodawane 0x40.

Dlaczego 0x40?

Nie pytaj mnie, po prostu tak jest 😉

Odpowiedź na zapytanie z SID 0x2E zacznie się od bajtu 0x6E itd.

Przykład z magistrali w CANoe

Popatrzmy teraz na rzeczywisty przykład, który zobserwujemy w oknie Trace środowiska CANoe

Popatrz najpierw sam na powyższy zrzut i spróbuj rozszyfrować co tu się stało. Mając już podstawową wiedzę z UDS i tabelkę powyżej, powinieneś dać radę.

.

.

.

Już? 🙂

To teraz wyjaśnię dokładnie.

  1. Najpierw zostało nadane żądanie 10 01. Dziesiątka oznacza zmianę Sesji (trybu działania urządzenia), 01 to parametr, oznaczający Default Session. W odpowiedzi przychodzi pozytywna odpowiedź (DefaultSession::pos – oznaczone przez CANoe na zielono): 50 01 00.
  2. Następnie zostało nadane żądanie 10 03. Oznacza ono żądanie do przejścia do Sesji rozszerzonej (Extended Session). Żądanie dostało również pozytywną odpowiedź: 50 03 00.
  3. Następnie zostało nadane żądanie odczytu danych: 22 20 21. Oznacza ono: Podaj mi dane (SID 22) znajdujące się w pamięci pod identyfikatorem 0x2021. Na żądanie została nadana pozytywna odpowiedź: 62 20 21 12 34. Pierwszy bajt (62) do SID + 40, bajty 20 21 to tylko powtórzenie (“podaję wartość parametru o ID = 0x2021), kolejne dwa bajty 0x1234 to już wprost wartość parametru odczytana z pamięci urządzenia.

Podsumowanie

To jedynie podstawowe informacje i zaledwie wprowadzenie do tematu standardu diagnostycznego UDS. Mam jednak nadzieję, że po przeczytaniu tego materiału łatwiej zrozumiesz dużo bardziej szczegółowe artykuły i opracowania.


Opublikowano

w

przez

Tagi:

Komentarze

3 odpowiedzi na „UDS – podstawy komunikacji diagnostycznej”

  1. Awatar Slawomir
    Slawomir

    Czyli ten UDS to można sprecyzować ze jest to swego rodzaju “Teleporada” 🙂
    Link: (zob. artykuł o żabie i skorpionie) niestety nie działa -> Brak uprawnień do wyświetlenia wersji roboczych.

    1. Awatar admin

      Dzięki za wyłapanie błędu, link poprawiony

  2. Awatar Slawomir
    Slawomir

    A jak to jest z Candela w Canoe tzn jak się ją implementuje? Robi sie to zapewne w Candela Studio ale czym się mogą różnić te wersje Candeli?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *