article in PDF format - Zeszyty Naukowe Instytutu Pojazdów

article in PDF format - Zeszyty Naukowe Instytutu Pojazdów

ZESZYTY NAUKOWE INSTYTUTU POJAZDÓW
5(96)/2013
Jędrzej Mączak1, Krzysztof Rokicki2
INTERFEJS DIAGNOSTYCZNY SAMOCHODU OSOBOWEGO – PROJEKT
APLIKACJI W ŚRODOWISKU LABVIEW
1. Wstęp
W obecnie produkowanych samochodach wszystkie funkcje związane ze
sterowaniem pracą silnika spalinowego realizowane są poprzez skomplikowane układy
mikroprocesorowe. Analizują one sygnały pochodzące z dziesiątków sensorów i na
podstawie zaawansowanych algorytmów sterowania ustalają parametry zasilania
silnika – m. in. wtrysk paliwa, dostarczanie powietrza, zapłon.
Zaostrzanie norm ograniczających toksyczność spalin wymusza stosowanie coraz
wydajniejszych układów mikroprocesorowych sterujących pracą silnika. Nawet do 90%
ich mocy obliczeniowej jest wykorzystywane do ustalania optymalnych warunków
spalania właśnie pod kątem toksyczności spalin. Wprowadzenie znormalizowanego
systemu diagnostyki pokładowej OBD-II (On Board Diagnostic) umożliwiło stosowanie
tych samych urządzeń i zunifikowanych procedur do diagnozowania stanu jednostki
napędowej pod kątem emisji zanieczyszczeń. Większość obecnie produkowanych
pojazdów wykorzystuje protokoły komunikacji opracowane na potrzeby systemu
OBD-II również do diagnostyki innych układów pojazdu. Diagnostyka pokładowa
samochodów osobowych jest szeroko opisana w literaturze, m. in. w [1].
Niniejsza praca przedstawia projekt aplikacji komunikującej się z diagnostycznym
systemem pokładowym samochodu (OBD-II) i pełniącej funkcje czytnika danych
diagnostycznych. Aplikacja została wykonana w środowisku LabVIEW firmy National
Instruments. O zastosowaniu LabVIEW w zagadnieniach diagnostyki pojazdów
napisano w pracy [2]. Aplikacja została stworzona specjalnie do wykorzystania przy
eksperymentach, podczas których pobierane będą dane z systemu diagnostyki
pokładowej OBD-II.
2. Projekt aplikacji
2.1. Informacje ogólne
Opisywany w niniejszej pracy program do komunikacji z układami w pojeździe
wykorzystuje urządzenia NI-CAN firmy National Instruments (NI). Zawierają one układ
nadawczo – odbiorczy i sterownik mikroprocesorowy współpracujący (poprzez złącze 9pinowe D-Sub) z magistralą CAN oraz złącze USB umożliwiające komunikację z
komputerem. Wykorzystując sterowniki dostarczone przez firmę NI uzyskano
możliwość komunikacji ze urządzeniami podłączonymi do magistrali CAN w pojeździe.
Wszystkie urządzenia NI-CAN wykorzystują do komunikacji z magistralą CAN
znormalizowane 9-pinowe złącze D-Sub (DB9).
1
2
dr inż. Jędrzej Mączak, adiunkt, Instytut Pojazdów, Politechniki Warszawskiej
mgr inż. Krzysztof Rokicki, doktorant, Wydział Samochodów i Maszyn Roboczych Politechniki
Warszawskiej
89
Rys. 1. Urządzenie NI USB-8473s.
Rys. 2. Złącze DB9 w sieci CAN.
Rys. 3. Kabel zakończony z jednej strony
złączem DB9, a z drugiej złączem DLC
Na potrzeby opisywanej aplikacji wykorzystano urządzenie NI USB-8473s (Rys. 1).
Obsługuje ono standard magistrali CAN stosowany zgodnie z normami OBD-II do
komunikacji ze sterownikiem w samochodzie poprzez złącze diagnostyczne DLC w
pojeździe.
Urządzenie NI USB-8473s (CAN) wyposażone jest w złącze typu DB9. W celu
połączenia urządzenia CAN ze złączem DLC w pojeździe, dla potrzeb projektu
wykonano kabel zakończony z jednej strony złączem DB9 (Rys. 2), a z drugiej złączem
DLC (Rys. 3).
2.2. Opis działania programu
Po uruchomieniu aplikacji ukazuje się główne okno – w górnej części pasek
konfiguracji połączenia, a w centralnej 5 zakładek, z których pierwsze 4 związane są z
trybami pracy systemu OBD-II, ostatnia natomiast pozwala na ręczne wysyłanie zapytań
do sterownika.
Aplikacja umożliwia wybór odpowiedniego interfejsu – domyślnie „CAN0”,
protokołu transmisji – ISO, prędkości – 500000 bit/s a także identyfikatorów ID jakie są
przypisane w sieci CAN sterownikowi w samochodzie i zewnętrznemu interfejsowi –
90
zgodnie z normami SAE dla OBD-II domyślnie są to 7D0h i 7D8h (Rys. 4).
Prezentowane zrzuty ekranu wykonano podczas połączenia z samochodem
Opel Zafira B 1.8 - model roku 2005.
Rys. 4. Główne okno programu.
Po uzyskaniu połączenia z pojazdem, odczytane zostają dane: o zastosowanej
odmianie systemu OBD-II – Opel Zafira posiada system EOBD – Europe OBD, numer
identyfikacyjny pojazdu VIN, a także liczba błędów w pamięci sterownika i stan lampki
MIL – zapalona lub zgaszona – reprezentowany przez czerwoną diodę w prawej dolnej
części ekranu.
Program samoczynnie odczytuje także identyfikatory dostępnych w pojeździe w
trybie OBD-II $01 parametrów bieżących pracy silnika. Więcej o trybach pracy systemu
OBD-II napisano w pracy [1]. Parametry dostępne w trybie $01 umieszczone zostają na
liście w głównym oknie programu na podzakładce Tabela w pierwszej zakładce –
Parametry bieżące – wraz z ich chwilowymi wartościami. Opel Zafira udostępnia około
40 parametrów, których wartości są odświeżane w tabeli. Są wśród nich m.in.
temperatura cieczy chłodzącej, prędkość obrotowa silnika, prędkość pojazdu, kąt
wyprzedzenia zapłonu, temperatura powietrza, położenie przepustnicy, napięcie na
czujnikach tlenu itd. Jest to praca systemu OBD-II w trybie $01 (Rys. 5)
91
Rys. 5. Okno programu po nawiązaniu połączenia, w trybie odczytywania parametrów
bieżących.
Częstotliwość aktualizacji danych jest tym mniejsza, im więcej parametrów jest
widocznych w tabeli. Dzieje się tak, ponieważ komunikacja ze sterownikiem w
samochodzie działa na zasadzie „pytanie – odpowiedź”. Program wysyła zapytanie o
chwilową wartość parametru, np. prędkości obrotowej silnika i oczekuje na odpowiedź.
Dopiero gdy ją dostanie może zapytać o wartość następnego parametru. Gdy wybrane są
wszystkie dostępne parametry odświeżenie wartości w tabeli następuje co około 1s. Aby
przyspieszyć odświeżanie, użytkownik może wybrać tylko interesujące go parametry.
Służy do tego druga podzakładka – Wybór parametrów – na pierwszej zakładce
(Parametry bieżące). Znajduje się tam tabela z listą wszystkich dostępnych parametrów i
polami wyboru przy każdym z nich (Rys. 6). Po wybraniu interesujących pozycji i
powrocie na podzakładkę Tabela wyświetlane zostają już tylko wybrane wielkości, a
odświeżanie ich wartości chwilowych odbywa się znacznie szybciej. Przy wybraniu od
1 do 3 parametrów czas odświeżania danych zmniejszyć się może nawet do około 0,02 s.
92
Rys. 6. Podzakładka z tabelą wyboru parametrów bieżących.
Rys. 7. Podzakładka Wykresy.
93
Kolejna podzakładka – Wykresy (Rys. 7) wraz z umieszczonymi na niej układami
współrzędnych umożliwia graficzne śledzenie zmian w czasie maksymalnie dwóch
dowolnie wybranych parametrów z listy dostępnych. Program automatycznie dobiera
skalę osi rzędnych w zależności od wybranej wielkości – np. dla temperatury cieczy
chłodzącej od – 40° C do + 150° C, dla prędkości obrotowej silnika – od 0 obr/min do
8000 obr/min itd. Na Rysunku 7 przedstawiono przykładowe wykresy – pierwszy – kąta
wyprzedzenia zapłonu, a drugi – prędkości obrotowej silnika.
Za kolejne tryby pracy systemu OBD-II – odczytywanie informacji o kodach
usterek – odpowiedzialne są elementy w zakładce „Błędy” (Rys. 8). W górnej części
zakładki znajduje się tabela z listą błędów, które pojawiły się w sterowniku pojazdu.
Aby je odczytać ze sterownika należy kliknąć przycisk OK. Na Rys. 8 widać, że w
badanym pojeździe występuje usterka podgrzewacza czujnika tlenu. Lampka MIL w
prawej części okna programu świeci się na czerwono, a w polu Liczba błędów wskazuje
wartość 1. Stan lampki MIL i liczba błędów są odczytywane w momencie nawiązania
połączenia ze sterownikiem w samochodzie zaraz po uruchomieniu programu – do ich
zadziałania nie jest konieczne wchodzenie na zakładkę Błędy. Za odczyt kodów błędów
w systemie OBD-II odpowiada tryb $03.
W niższej części zakładki znajduje się analogiczna jak dla listy błędów tabela,
wyświetlająca błędy zarejestrowane przez sterownik w bieżącym cyklu jezdnym. W
badanym pojeździe na liście błędów oczekujących znajduje się „Usterka masowego lub
objętościowego przepływomierza powietrza”. Za odczyt kodów błędów oczekujących w
systemie OBD-II odpowiada tryb $07.
Rys. 8. Tryb odczytu i kasowania kodów usterek.
94
W dolnej części zakładki znajduje się przycisk „Kasuj błędy”. System OBD-II nie
przewiduje możliwości selektywnego kasowania błędów, a jedynie wszystkich
informacji diagnostycznych na raz – kody błędów, kody błędów oczekujących oraz
opisane dalej Parametry zamrożone. Po skasowaniu informacji zapali się zielona lampka
w części Kasowania błędów, a także zgaśnie lampka MIL (Rys. 9). Za kasowanie
informacji diagnostycznej w systemie OBD-II odpowiada tryb $04.
Tryb pracy $02 w systemie OBD-II odpowiada za tzw. ramki zamrożone. Jest to
zbiór wartości parametrów zapisanych w pamięci sterownika, jakie panowały w zespole
napędowym pojazdu w chwili wystąpienia usterki. W zależności od pojemności pamięci
sterownik może pamiętać kilka lub więcej ramek. Analizując zapisane w nich informacje
diagnosta może dojść do przyczyny wystąpienia usterki. Zapamiętywane są takie
parametry jak: kod błędu związany z ramką, stan układu zasilającego, wyliczone
obciążenie silnika, temperatura cieczy chłodzącej, krótko i długoterminowe poprawki
dawki, ciśnienie, prędkość obrotowa silnika, kąt wyprzedzenia zapłonu i temperatura
powietrza w kolektorze dolotowym.
Rys. 9: Tryb odczytu i kasowania kodów usterek - po skasowaniu błędów.
95
Rys. 10. Tryb odczytu parametrów zamrożonych.
Program odczytuje z pamięci sterownika ramki po kliknięciu przycisku OK w
górnej części okna. W zależności od liczby ramek czas odczytu może wynieść do kilku
sekund. Po odczytaniu zapala się zielona dioda Odczytano, pojawia się informacja o
liczbie odczytanych ramek, a także – jeśli liczba ramek jest równa co najmniej jednej –
w tabeli pojawiają się dane z pierwszej ramki. W przykładzie na rysunku poniżej w
tabeli znajdują się dane z pierwszej ramki zamrożonej – zapisanej w momencie
wystąpienia błędu układu podgrzewacza czujnika tlenu (Rys. 10).
Zakładka czwarta – Monitory diagnostyczne – zawiera tabelę z wynikami
wykonania monitorów diagnostycznych (Rys. 11). Jeśli nie są one dostępne w pojeździe,
ich wartość jest ustawiana na „brak”, w przeciwnym wypadku w zależności od stanu –
jest to albo „trwa”, albo „zakończono”.
Ostatnia zakładka (Rys. 12) zawiera opcję ręcznego budowania zapytania dla
sterownika OBD-II w pojeździe. Daje możliwość wysłania komendy OBD-II w
wybranym trybie – pole Mode – i jeśli to jest wymagane zawierającego numer parametru
PID. Odpowiedź prezentowana jest heksadecymalnie oraz binarnie i zawiera całe pole
danych ramki otrzymanej siecią CAN na wysłane zapytanie.
96
Rys. 11. Tryb odczytu rezultatów testów monitorów diagnostycznych.
Rys. 12: Zaawansowany tryb odpytywania.
97
3. Podsumowanie
Przedstawiona w niniejszej pracy aplikacja pozwala na diagnozowanie usterek
pojazdu w takim samym zakresie jak standardowe czytniki OBD-II, których funkcje są
znormalizowane przez odpowiednie standardy i normy. Interfejs nie spełnia wymogów
tych norm w zakresie obsługi protokołów komunikacji – obsługuje tylko CAN. Niemniej
jednak protokół CAN od roku modelowego 2008 staje się jedynym protokołem
komunikacji ze sterownikiem, jaki jest stosowany w diagnostyce OBD-II.
Literatura:
[1]
Mazurek S., Merkisz J.: Pokładowe systemy diagnostyczne pojazdów
samochodowych, Warszawa 2006 WKŁ,
[2]
Radkowski S., Rokicki K.: Systemy monitorowania pojazdów – przegląd
istniejących rozwiązań i kierunki ich rozwoju, Studia i Materiały Polskiego
Stowarzyszenia Zarządzania Wiedzą, 2011, nr 47, str. 246-255, ISSN 1732-324X,
2011.
Streszczenie
Niniejsza praca przedstawia projekt aplikacji komunikującej się z diagnostycznym
systemem pokładowym samochodu (OBD-II) i pełniącej funkcje czytnika danych
diagnostycznych. Aplikacja została wykonana w środowisku LabVIEW firmy National
Instruments. Wykorzystuje również interfejs sieci CAN dedykowany do pracy w
środowisku LabVIEW. W pracy przedstawiono wszystkie podstawowe tryby pracy
systemu OBD-II, w których opisywana aplikacja wymienia dane ze sterownikami w
pojeździe.
Słowa kluczowe: Diagnostyka pokładowa, OBD-II, LabVIEW
ON-BOARD DIAGNOSTIC INTERFACE – PROJECT OF APPLICATION IN
LABVIEW ENVIRONMENT
Abstract
This paper presents the application communicating with the vehicle on-board
diagnostic system (OBD-II) and performing the functions of the diagnostic data reader.
The system was developed in LabVIEW from National Instruments. It also uses the
CAN interface dedicated to work in LabVIEW. This paper presents all the basic modes
of the OBD-II, which described the application exchanges data with controllers in the
vehicle.
Keywords: On-board diagnostic, OBD-II, LabVIEW
98