ZESZYTY NAUKOWE INSTYTUTU POJAZDÓW 5(96)/2013 Jędrzej Mączak 1, Krzysztof Rokicki 2 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 9- pinowe 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 dr inż. Jędrzej Mączak, adiunkt, Instytut Pojazdów, Politechniki Warszawskiej 2 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