Standard OBD II (wcześniej OBD) jest powszechnie używany do diagnozowania układów samochodów osobowych, dostawczych, ciężarowych i autobusów. Możliwość przekazywania do urządzeń diagnostycznych i pomiędzy podzespołami komunikatów o stanie technicznym pojazdu zmieniła zasady projektowania i serwisowania poszczególnych układów.

Wykorzystanie interfejsu OBD II do programowania podzespołów stwarza dogodne warunki do bardzo szybkiej aktualizacji oprogramowania wbudowanego, korekcji parametrów pracy silnika itp. Dzisiaj nie wyobrażamy sobie, że nowoczesny samochód mógłby nie mieć tego interfejsu i wymagać odczytywania danych osobno z każdego układu wyposażonego w sterownik z mikrokontrolerem lub mikroprocesorem.

Historia standardu OBD jest długa. Pierwsza wersja została zaimplementowana w roku 1980 przez General Motors. OBD II jest obowiązkowy w USA od roku 1986. W Europie obowiązek udostępniania interfejsu EOBD w samochodach z silnikiem benzynowym powstał w roku 2001, a w 2004 objął także pojazdy z silnikami wysokoprężnymi. Standard OBD II składa się z kilku wzajemnie uzupełniających się elementów. Przygodę z tym narzędziem najlepiej zacząć od… wtyczki. Jeśli przyjrzymy się typowej wtyczce OBD II, zobaczymy zestaw 16 styków, z których część jest wykorzystywana zawsze, a część ma zmienne przeznaczenie – w zależności od producenta.

Połączenia

Zawsze możemy być pewni, że na styku nr 4 jest wyprowadzona masa nadwozia, na styku 5 masa sygnału, a na styku 16 napięcie akumulatora. Styki 6 i 14 to magistrala CAN, 7 i 15 to linie dla transmisji danych w standardzie ISO 9141-2 oraz ISO 14230-4 (jeśli samochód nie jest wyposażony w podzespoły komunikujące się przy pomocy tych protokołów, wówczas te linie pozostaną niewykorzystane). Styki o numerach: 1, 3, 8, 9, 11, 12, 13 mogą być wykorzystywane przez producentów w sposób zgodny z ich potrzebami, np. do wykonywania pomiarów, testów albo programowania kontrolerów – samodzielnie lub w połączeniu z magistralami wyprowadzonymi na pinach 6 i 4 oraz 7 i 15. Jak widać, standard standardem, ale jest tu także sporo miejsca na rozwiązania będące własnymi pomysłami producentów, które czasami utrudniają obsługę pojazdu przy pomocy narzędzi pochodzących od niezależnych producentów.

Protokoły transmisji danych

Najczęściej spotykamy protokół CAN (ang. controller area network), stosowane są jednak również: PWM (ang. pulse width modulation) – zgodny z normą SAE J1850 w pojazdach Forda, VPW (ang. variable pulse width) w pojazdach General Motors, ISO 9141-2 i ISO14230-4 (Keyword Protocol 2000) w pojazdach europejskich.

Kody błędów

Kody błędów to temat rzeka. Zdarzenia i awarie, które zostały przewidziane przez producenta, otrzymują indywidualne kody. Wystąpienie zdarzenia powoduje zapisanie w pamięci sterownika odpowiadającego mu komunikatu. Po nawiązaniu sesji z urządzeniem diagnostycznym odczytuje ono wszystkie komunikaty oraz dodatkowe informacje (o ile zostały zapisane). W tym miejscu pojawia się pierwszy poważny problem. Numer błędu może być dobrze zdefiniowany przez powszechnie uznaną normę, ale może też być rozszerzeniem normy wprowadzonym przez producenta pojazdu. Dlatego prawdopodobnie najbardziej pożądaną cechą urządzenia diagnostycznego jest dostęp do ciągle aktualizowanego słownika komunikatów o błędach i spisu procedur serwisowych. W znacznej mierze decyduje to o renomie i cenie urządzeń diagnostycznych i oprogramowania. Nieustanne zmiany wprowadzane przez producentów pojazdów sprawiają, że oprogramowanie stosunkowo szybko się dezaktualizuje, ponieważ pojawiają się nowe kody błędów, a to znaczy, że producenci narzędzi mogą liczyć na ciągłe zapotrzebowanie klientów i przedłużanie abonamentu na aktualizacje o kolejne lata.

Znaczenie kodów diagnostycznych wspólnych dla wszystkich producentów można znaleźć w dwóch dokumentach: „Diagnostic Trouble Code Definitions SAE International J2012_201612” oraz ISO 15031-6:2010. Są one w zasadzie identyczne. Dostęp online do dokumentu SAE kosztuje 85 USD. Kody dodatkowe opisują poszczególni producenci pojazdów.

Podstawowe ustalenia są następujące: kod błędu ma pięć znaków, pierwszy znak jest literą i wskazuje, jakiego układu dotyczy komunikat o błędzie:

• P – układ napędowy,
• B – karoseria,
• C – układ jezdny,
• U – transmisja danych.

Drugi znak określa, czy kod należy do grupy znormalizowanych (wtedy wartość wynosi 0), czy też jest kodem dodanym przez producenta pojazdu.

Trzeci znak dokładniej wskazuje system pojazdu, którego dotyczy usterka:

• 0 – usterka układu elektrycznego,
• 1, 2 – usterka układu zasilania paliwem lub powietrzem,
• 3 – usterka związana z ustawieniem zapłonu,
• 4 – usterka związana z emisją spalin,
• 5 – usterka dotycząca sterowania prędkością obrotową biegu jałowego,
• 6 – usterka związana z układami wyjścia i wejścia ECU,
• 7 – usterka związana z przekazywaniem napędu,
• 8 – usterki dotyczące elementów pojazdu niesterowanych elektrycznie.

Dwa pozostałe znaki wskazują na konkretną usterkę.

Tzw. freeze frame (w dosłownym tłumaczeniu z jęz. angielskiego: „zamrożona ramka”) to bardzo pożyteczna właściwość OBD II. Działa ona w ten sposób, że w chwili wystąpienia awarii w pamięci sterownika są zapisywane wartości odczytane z czujników. Dzięki temu, analizując dane, można wyciągnąć wnioski na temat możliwych przyczyn uszkodzenia albo zlokalizować problem, który wprawdzie nie doprowadził do zgłoszenia komunikatu o osobnym błędzie, ale w niedalekiej przyszłości może się skończyć awarią.

Nie tylko odczyt

Złącze OBD II można wykorzystywać na wiele sposobów. Odczytanie komunikatu błędu albo „zamrożonej” wartości parametrów to zaledwie dwa z nich. Podłączając się do magistrali danych, uzyskujemy możliwość dwukierunkowej wymiany danych między pojazdem a przyrządem diagnostycznym, którą możemy wykorzystać do rejestrowania wartości mierzonych przez wszystkie czujniki w czasie rzeczywistym. Jest to bardzo przydatne, np. jeśli poszukujemy awarii, która ujawnia się tylko w określonych warunkach podczas pracy silnika albo w czasie jazdy. Zarejestrowane dane można analizować na dowolnym komputerze wyposażonym w odpowiednie oprogramowanie.

Interfejsy diagnostyczne

Te urządzenia pośredniczą pomiędzy programem diagnostycznym a urządzeniami wymieniającymi dane przy pomocy magistrali pojazdu. Od ich konstrukcji zależą takie właściwości jak: odporność na uszkodzenie przez skoki napięcia czy zwarcia, możliwość odczytywania danych w warunkach dużych zakłóceń elektromagnetycznych, wykorzystanie pinów gniazda OBD II pozostawionych do użytku producenta pojazdu w sposób właściwy dla konkretnej marki/modelu, możliwość transmisji danych z urządzenia diagnostycznego do pojazdu w celu programowania poszczególnych urządzeń (kasowanie błędów, korekcja ustawień, rejestrowanie nowych podzespołów po naprawie itp.). Niektóre interfejsy mają wbudowane moduły multimetru i oscyloskopu, co dodatkowo ułatwia poszukiwanie usterki.

Zazwyczaj kolejne wersje interfejsów diagnostycznych pojawiają się na rynku stosunkowo rzadko, np. co kilka lat. Jeśli producent decyduje się zaimplementować nowe funkcje odpowiadające na zapotrzebowanie rynku, może to zrobić, udostępniając aktualizację wbudowanego oprogramowania. W zależności od modelu biznesowego producenta urządzenia aktualizacja może być dostępna dla wszystkich posiadaczy, dla tych, którzy za nią zapłacą, albo dla tych, którzy mają aktualny abonament na oprogramowanie diagnostyczne.

Programy diagnostyczne

Od jakości programów diagnostycznych zależą faktyczne możliwości diagnozowania i programowania. Pozornie są to dość proste aplikacje odczytujące kody błędów i kojarzące z nimi opis problemu. W rzeczywistości na sukces programu diagnostycznego składa się wiele czynników: potężna wiedza programistów o jak największej liczbie wariantów kodów i procedur diagnostycznych zaimplementowanych przez poszczególnych producentów, dostęp do schematów, opisów procedur serwisowych, umiejętność zaprojektowania „poręcznego” interfejsu użytkownika ułatwiającego obsługę programu. Ważna jest gwarancja stałej, wieloletniej współpracy i dostępu do danych nowych modeli samochodów.

Trzeba zwrócić uwagę na jeszcze jeden fakt. Niektóre funkcje zestawów diagnostycznych są dostępne wyłącznie dla mechaników, którzy zostali przeszkoleni przez producenta. Dotyczy to obsługi podzespołów, które mają bezpośredni wpływ na bezpieczeństwo, np. układu hamulcowego. Dostęp do tych funkcji jest możliwy po wprowadzeniu numeru autoryzacji.

Online czy offline?

Producenci, którzy udostępniają rozbudowaną bazę wiedzy o układach pojazdu, częściach zamiennych i procedurach serwisowych, konstruują swoje systemy w taki sposób, że wykorzystanie pełnych możliwości zakupionego programu wymaga stałego dostępu do Internetu, najlepiej za pośrednictwem łącza o dużej przepustowości. Trzeba o tym pamiętać, planując infrastrukturę informatyczną warsztatu albo przygotowując się do pracy w terenie.

Takie postępowanie jest może uciążliwe, ale ma swoje praktyczne uzasadnienie. Dokumentacja techniczna pojazdów jest tak obszerna i tak często modyfikowana, że dostarczanie przy każdej instalacji kompletu danych byłoby uciążliwe i obciążałoby komputer diagnostyczny. Jeśli natomiast przesyłane są wyłącznie dane diagnozowanego pojazdu, wówczas nie ma potrzeby lokalnego przechowywania dużych ilości plików. Niewątpliwie z punktu widzenia producenta oprogramowania ważne jest również to, że w takim modelu trudniej jest zapisać lokalnie kompletną bazę wiedzy, np. tuż przed zakończeniem okresu abonamentu.

Co po abonamencie?

Tutaj możliwości jest kilka. Niektórzy producenci blokują możliwość pobierania aktualizacji dokumentów i oprogramowania, ale użytkownik może swobodnie i bezterminowo korzystać z dotychczas opłaconych informacji. Inni blokują dostęp do całej bazy wiedzy, co sprawia, że kosztowny sprzęt diagnostyczny staje się w zasadzie bezużyteczny, a wybór właściwych narzędzi i ocena faktycznych kosztów ich użytkowania stają się coraz trudniejsze.

Przyszłość diagnostyki

Podobnie jak w innych dziedzinach, także i w diagnostyce samochodowej można zauważyć tendencję do zmiany modelu udostępniania oprogramowania diagnostycznego i serwisowego na SaaS (ang. software as a service), co oznacza, że oprogramowanie staje się usługą dostępną wtedy, kiedy zostanie opłacony abonament. W niedalekiej przyszłości może się zatem okazać, że podstawowe narzędzia diagnostyczne będą dostępne tylko przy regularnym opłacaniu abonamentu. Taki sposób rozliczeń z klientami wprowadzają duże firmy ze świata IT, m.in. Microsoft, Adobe i inni. Wiele wskazuje na to, że ten model biznesowy jest atrakcyjny dla producentów oprogramowania i że w przyszłości będzie się on upowszechniał.

Piotr Kołaczek