listopad 2020

There was one post published in listopad 2020.

On-Board Diagnostic

      Historia zaczyna się prozaicznie, od stresu związanego z zapaleniem się kontrolki Check engine  po kilku latach eksploatacji Nissana z 2005 roku. Co to oznacza i  gdzie można to naprawić, to pierwsza reakcja na awarie samochodu. Na szczęście wizyta u znajomego mechanika nie była droga, bo  polegała na wymianie jednej świecy żarowej na nową. Lokalizacja awarii polegała na   odczycie kodu błędu silnika, w tym konkretnym przypadku,  błędu  świecy żarowej. Wymiana świecy żarowej trwała 15 minut ale wcześniej podczas odczytu błędu z wykorzystaniem złącza OBDII  pojawił się problem z komunikacja testera z systemem elektroniki samochodu. Ostatecznie po wymianie testera na inny udało się odczytać w/w kod błędu silnika. Po awarii zostały jednak wątpliwości o mój stan wiedzy na temat sposobu diagnostyki za pomocą kodów błędów odczytywanych w systemie OBD (On-Board Diagnostics) – zdolność samo-diagnostyki pojazdów.

Według  https://en.wikipedia.org/wiki/On-board_diagnostics, OBD daje możliwość dostępu do danych dotyczących stanu technicznego poszczególnych układów pojazdu. Pozwala np. na odczytanie kodów błędów (DTC – diagnostic trouble codes) zapisanych w pamięci, dotyczących silnika, immobilisera itp.

1Protokoły transmisji i media wykorzystywane w OBDII
  • J1850 PWM
  • J1850 VPW
  • ISO9141
  • ISO14230 (KWP2000)
  • ISO14229 (UDS)
  • CAN (ISO15765/SAE J2480)

    Obecnie pojazdy silnikowe zawierają różne elektroniczne jednostki sterujące zamontowane w pojeździe mechanicznym. Jednostki sterujące mogą sterować różnymi systemami i / lub podsystemami w pojeździe silnikowym. Na przykład jednostka sterująca może sterować silnikiem, skrzynią biegów, hamulcem lub mechanizmem kierowniczym.  Te jednostki sterujące są zwykle połączone z różnymi czujnikami i / lub siłownikami. W zależności od pojazdu, jednostki sterujące w pojeździe silnikowym mogą realizować różne protokoły komunikacyjne. Ponadto wiele z tych jednostek sterujących może działać przy różnych poziomach napięcia i może nadawać w trybie różnicowym lub pojedynczym. W typowym pojeździe silnikowym jednostka sterująca silnikiem odbiera wiele sygnałów wejściowych. Te sygnały wejściowe mogą obejmować na przykład czujnik temperatury płynu chłodzącego, czujnik tlenu, czujnik ciśnienia w kolektorze dolotowym, przełącznik klimatyzacji, czujnik prędkości pojazdu, przełącznik przyspieszenia, czujnik położenia przepustnicy, przełącznik neutralny i silnik czujnik prędkości. Jednostka sterująca silnika odbiera i przetwarza sygnały wejściowe otrzymane z różnych czujników i przełączników. W odpowiedzi na te sygnały wejściowe jednostka sterująca silnika może wysyłać różne sygnały sterujące. Te sygnały sterujące mogą sterować, na przykład, solenoidem oczyszczania pochłaniacza, siłownikiem układu recyrkulacji gazów wydechowych (EGR), siłownikiem sterującym biegu jałowego, cewką zapłonową i / lub wieloma wtryskiwaczami paliwa. Typowa jednostka sterująca prędkością odbiera sygnały wejściowe z przełącznika ustawiania prędkości i czujnika prędkości pojazdu. W odpowiedzi na te sygnały wejściowe, jednostka sterująca prędkością reguluje siłownik przepustnicy tak, aby napędzał pojazd silnikowy z mniej więcej stałą prędkością. Jednostka sterująca prędkością może również odbierać sygnały wejściowe z przełącznika hamulca, przełącznika przyspieszenia, przełącznika neutralnego, przełącznika zwalniania i / lub przełącznika wznawiania. W odpowiedzi jednostka sterująca prędkością może przerwać sterowanie stałą prędkością lub zresetować stałą prędkość po zmianie prędkości pojazdu silnikowego. Zatem, jak opisano powyżej, typowy pojazd mechaniczny wykorzystuje wiele jednostek sterujących do sterowania działaniem pojazdu mechanicznego.

    Pojazd zgodny z OBD II może zawierać jeden lub więcej z czterech  protokołów komunikacyjnych; SAE J1850 zmienna modulacja szerokości impulsu (VPWM), SAE J1850 modulacja szerokości impulsu (PWM) i ISO 9141  oraz Can BUS J-2284. W typowym pojeździe silnikowym, gdy wystąpi usterka, która jest monitorowana przez jednostkę sterującą, usterka ta jest zapisywana w pamięci. W typowej sytuacji zapala się również lampka kontrolna awarii (MIL-Malfunction Indicator Light ), która informuje kierowcę pojazdu silnikowego o zaistnieniu problemu. Próbując rozwiązać wskazaną usterkę, technik serwisowy zwykle podłącza narzędzie diagnostyczne do złącza diagnostycznego znajdującego się w pojeździe silnikowym. Typowe narzędzie diagnostyczne zawiera mikrokontroler i obwód interfejsu do przekształcania sygnałów elektronicznych dostarczanych przez jednostkę sterującą w pojeździe silnikowym na sygnał, który jest łatwy do wykorzystania przez mikrokontroler narzędzia diagnostycznego.

    PL/EP2302597 Programowalny system diagnostyki pokładowej pojazdu, Texa S.p.A., BRUNO VIANELLO, RONCADE, Data patentu: 20.04.2016.  Wynalazek dotyczy programowalnego systemu diagnostyki pokładowej pojazdu, który, w przeciwieństwie do przenośnych urządzeń diagnostyki pojazdu, jest  skonfigurowany do podłączenia złącza diagnostycznego zamontowanego w pojeździe w taki sposób, aby stanowić integralną część pojazdu, tak aby mogły się z nim poruszać. Oznacza to, że przedmiotem wynalazku jest system, który z jednej strony umożliwi zmniejszenie kosztów i całkowitych wymiarów modułu diagnostyki pokładowej skojarzonych z wykorzystaniem przekaźnika GSM lub GPTS oraz z drugiej strony umożliwi programowanie, za każdym razem, modułu diagnostyki pokładowej pod system diagnostyki pojazdu w którym zostanie zainstalowany.  Obdi1

    Fig.1 jest schematyczną ilustracją programowalnego systemu diagnostyki pojazdu dostarczonego według niniejszego wynalazku; Fig.2 przedstawia diagram blokowy programowalnego systemu diagnostyki pojazdu zilustrowanego na Fig.1; Fig.3 przedstawia moduł diagnostyki pokładowej programowalnego systemu diagnostyki pojazdu podczas podłączenia do złącza diagnostycznego zainstalowanego w pojeździe; Fig.4 przestawia schemat blokowy pracy programowalnego systemu diagnostyki pojazdu zilustrowanego na Fig.1;  Fig.5 przedstawia wariant pracy programowalnego systemu diagnostyki pojazdu zilustrowanego na Fig.1.

    Cały programowalny system diagnostyki pojazdu przedstawiony na Fig.1, zawiera komputer pokładowy, który jest połączony z  urządzeniem interfejsu 2, zainstalowanym na pokładzie pojazdu 3, generującym dane diagnostyczne  pojazdu , przy czym urządzenie 2 jest  dostarczone ze złączem diagnostycznym 4, przez które możliwy jest dostęp do danych pojazdu. Programowalny system diagnostyki pojazdu 1 zawiera również: moduł diagnostyki pokładowej 5, który może być w sposób stabilny, ale gotowy do rozłączenia, połączony ze złączem diagnostycznym 4 , a który   posiada architekturę  sprzętową z  oprogramowaniem  skonfigurowanym  do implementacji diagnostyki oraz uzyskania  czasowego przechowywania danych pojazdu dostarczonych przez urządzenie diagnostyki 2.  Dodatkowo zewnętrzny system oprogramowania 6,  jest skonfigurowany do modyfikacji wewnętrznej architektury sprzętowej/oprogramowania modułu diagnostyki pokładowej 5 w taki sposób, aby spowodować jego kompatybilność z uzyskiwanymi danymi pojazdu generowanymi przez urządzenie diagnostyki 2.

    Odnosząc się do Fig.1, urządzenie diagnostyki pokładowej 2 zawiera systemy pomiarowe 7 i/lub systemy sterujące i przetwarzające  8, które są skonfigurowane do sterowania członami/jednostkami zainstalowanymi na pokładzie pojazdu 3, takimi jak na przykład człony zasilania/wydechu, jednostkę silnika, urządzenia zabezpieczające takie jak ABS, poduszki powietrzne, urządzenia poprawiające jakość i/lub podobne jednostki/człony/urządzenia pojazdu oraz umożliwiają dostęp do danych pojazdu przez złącze diagnostyczne 4. Złącze diagnostyczne 4, może być zainstalowane w różnych miejscach przedniego panelu kierowcy np.: wewnątrz schowka pasażera pojazdu 3  i posiada wiele pinów połączeniowych 10,  które są połączone z urządzeniem diagnostyki pokładowej 2 przez odpowiadające linie lub szyny przesyłania danych 11. Natomiast,  systemy pomiarowe  7  i/lub  systemy sterowania i przetwarzania 8, są  skonfigurowane tak, aby wymieniać dane pojazdu z modułem diagnostyki pokładowej 5, implementując jeden lub więcej zestawionych protokołów komunikacyjnych. W szczególności, protokoły komunikacyjne mogą zawierać korzystnie, ale niekoniecznie, protokół SAEJ1850 (PWM/VPW) i/lub protokół SAEJ2284 (CAN-H/CAN-L) i/lub protokół ISO9141-2 lub protokół ISO14230 lub każdy inny, podobny protokół ujęty w normach  OBD,  E-OBD  lub OBD-II.

    Złącze 12 modułu diagnostyki pokładowej 5 dostarczone jest z wieloma pinami połączeniowymi 13, które są wykonane do podłączenia do odpowiadających pinów 10 złącza diagnostycznego 4, przy czym   moduł diagnostyki pokładowej 5 zawiera również jednostkę  sterującą 14, na  przykład  mikroprocesor, skonfigurowaną do wykonywania programu pobierania/przechowywania danych pojazdu. Jednostka sterująca 14 posiada wiele zacisków komunikacyjnych 15 zaprojektowanych do podłączenia do pinów komunikacyjnych 13 do wdrożenia pobierania danych  pojazdu za pomocą co najmniej jednego zadanego protokołu komunikacyjnego danych. W odróżnieniu od znanych modułów diagnostyki pokładowej, moduł diagnostyki pokładowej 5 zawiera macierz elektronicznych przełączników 16, która zawiera wiele selektywnie połączonych ze sobą urządzeń 17 , z  których każde jest zaprojektowane tak , aby można było zlecić połączenie/rozłączenie każdego z zacisków komunikacyjnych 15 jednostki sterującej 14 z/od  jednego z pinów połączeniowych 13 złącza 12. W praktyce, moduł  diagnostyki pokładowej 5  jest  skonfigurowany   tak , aby był programowany przez zewnętrzny system programistyczny  6  i  łączył/rozłączał, na podstawie wspomnianego programowania, każdy zacisk komunikacyjny 15  jednostki sterującej 14 z/od jednego, i tylko jednego, pinu połączeniowego 13 złącza 12. Bardziej szczegółowo jednostka sterująca 14 jest skonfigurowana do odbierania wejściowego profilu programowania PA do  uzyskiwania danych, który zawiera serię poleceń/operacji dla sprzętu/oprogramowania modułu diagnostyki 5.

     W szczególności, profil programowania PA do uzyskiwania danych zawiera: zestaw informacji określających stan otwarcia/zamknięcia, który ma być nadany każdemu selektywnie połączonemu urządzeniu 17, na podstawie którego jednostka sterująca 14 generuje sygnały sterujące Ci; oraz oprogramowanie zawierające operacje, które jednostka sterująca musi wdrożyć do uzyskania danych pojazdu z urządzenia diagnostyki pokładowej 2. Jednostka sterująca 14  jest skonfigurowana do określenia na podstawie danych zawartych w profilu programowania PA: rodzaju protokołów komunikacyjnych, które mają być użyte do pobierania danych pojazdu; zacisków komunikacyjnych 15, które mają być użyte, podczas pobierania, do prawidłowego połączenia jednostki sterującej 14 z urządzeniem diagnostyki pokładowej 2; oraz operacje, które mają być wdrożone podczas pobierania danych. Dodatkowo zewnętrzny system programistyczny  6  zawiera zdalną  stację  przetwarzania i diagnostyki 21,  która jest skonfigurowana do dostarczania profilu programowania PA oraz przenośne urządzenie komunikacyjne użytkownika 22, które jest skonfigurowane do wykonywania transmisji/odbioru dalekiego zasięgu ze zdalną stacją przetwarzania  i diagnostyki 21 za pomocą systemu komunikacyjnego 50, tak aby odebrać profil programowania PA i wykonać transmisję/odbiór za pomocą urządzenia przekaźnika 19 modułu diagnostyki pokładowej 5, przez system komunikacyjny 20, tak aby dostarczyć do niego profil programowania PA.

    US6526340SPX Multi-vehicle communication interface, SPX Corporation,  Reul et al., Data patent:25.04.2003.  Przedmiotem wynalazku jest narzędzie diagnostyczne do komunikacji z wieloma jednostkami sterującymi pojazdu mechanicznego, które realizują co najmniej dwa różne protokoły komunikacyjne. Narzędzie diagnostyczne zawiera procesor i tablicę bramek programowalną przez użytkownika. Procesor wykonuje procedury diagnostyczne i w ten sposób dostarcza komunikaty do jednej z wielu jednostek sterujących pojazdu silnikowego. Tablica bramek programowalnych przez użytkownika zapewnia wybierany interfejs wielu protokołów, który jest połączony między wieloma jednostkami sterującymi pojazdu silnikowego i procesorem. Wybierany interfejs wielu protokołów konwertuje komunikaty procesora na formaty czytelne dla jednostki sterującej pojazdu silnikowego i konwertuje odebrane informacje z jednostki sterującej na format odczytywalny przez procesor.  Obdi2

     

    FIG.1 jest schematem blokowym narzędzia diagnostycznego, zgodnie z przykładem wykonania niniejszego wynalazku; FIG.2 jest schematem blokowym urządzenia logicznego implementującego różne moduły protokołu komunikacyjnego, zgodnie z przykładem wykonania niniejszego wynalazku;  FIG.3 przedstawia schemat blokowy modułu protokołu komunikacyjnego J1850, zgodnie z przykładem wykonania niniejszego wynalazku;  FIG.4 przedstawia schemat rejestrów sterujących i statusowych dla modułu protokołu komunikacyjnego J1850 z FIG.3.

    Narzędzie diagnostyczne 100 według przykładu wykonania  zawiera procesor 102, tablicę bramek programowalnych przez użytkownika (FPGA) 114, wyświetlacz 106, złożone programowalne urządzenie logiczne (CPLD) 104, klawiaturę 126, podsystem pamięci 108, wewnętrzną  pamięć  nieulotną 118, zewnętrzną pamięć nieulotną 120, sprzętowy port interfejsu 112  i  wybieralny translator 110 sygnałów, połączone, jak pokazano na FIG.1. Wybieralny translator 110 sygnałów jest połączony z interfejsem komunikacyjnym 116 pojazdu mechanicznego za pośrednictwem zewnętrznego kabla, który jest zależny od pojazdu mechanicznego. Translator 110 przekształca sygnały odebrane z jednostki sterującej pojazdu silnikowego na sygnał kompatybilny z narzędziem diagnostycznym 100. Na przykład, norma J1850 VPWM wymaga, aby sygnał wysokiego poziomu był między 4,25V a 20V, a sygnał niskiego poziomu znajdował się między masą a 3,5V. W typowej implementacji 3,3V, narzędzie diagnostyczne 100 wymagałoby sygnału wysokiego poziomu między około 2,64V a 3,3 V oraz sygnału niskiego poziomu między masą a około 0,66V. Zatem w tym przypadku translator 110 przekształca odebrany sygnał na poziom napięcia odpowiedni dla narzędzia diagnostycznego 100.

    Niektóre narzędzia diagnostyczne zawierają wiele obwodów komunikacyjnych połączonych na stałe, co umożliwia narzędziu diagnostycznemu interpretację wielu protokołów z różnych jednostek sterujących. Inne narzędzia diagnostyczne obejmują programowalną macierz bramek (FPGA). Układ FPGA umożliwił technikowi diagnostycznemu załadowanie różnych obrazów do układu FPGA, tak aby  układ FPGA  mógł  obsługiwać różne protokoły komunikacyjne.  W tym przypadku FPGA służył jako interfejs komunikacyjny pomiędzy jedną z jednostek sterujących pojazdu mechanicznego a mikrokontrolerem znajdującym się w narzędziu diagnostycznym.

    Obwód do translacji sygnału  z jednego poziomu napięcia  na  inny  jest dobrze znany  specjalistom  w  tej  dziedzinie.  W korzystnym przykładzie wykonania translator 110 zawiera obwód do translacji wszystkich poziomów napięcia sygnałów aktualnie realizowanych w pojeździe mechanicznym. W związku z tym obwód do tłumaczenia poziomów napięcia określonego protokołu komunikacyjnego jest wybierany przez FPGA 114, np. przez zapewnienie urządzenia kluczującego, które podłącza się do złącza 111, interfejsu komunikacyjnego pojazdu 116.  Translator 110 jest również połączony z FPGA 114  i  sprzętowym portem interfejsu 112 za pośrednictwem magistrali 124. FPGA 114 przesyła do  i odbiera sygnały (tj.Komunikaty) z jednostki sterującej pojazdu silnikowego poprzez translator 110.  FPGA 114 dostarcza odpowiedni sygnał do translatora. 110 tak, że odebrany sygnał (np.Dane) lub przesłany sygnał (np.Polecenie) są tłumaczone, zgodnie z protokołem komunikacyjnym realizowanym przez jednostkę sterującą pojazdu silnikowego.

    FPGA 114 jest sprzężona z procesorem 102 poprzez różne linie adresowe, danych i sterujące przez magistralę systemową 122. FPGA 114 jest również połączona z portem interfejsu sprzętowego 112 przez magistralę 124. Jak omówiono bardziej szczegółowo poniżej, FPGA 114 zapewnia protokół komunikacji wielokrotnej. interfejs między procesorem 102,  a jednostką sterującą pojazdu silnikowego. W korzystnym przykładzie wykonania FPGA 114 to 10K50E wyprodukowane przez Altera Corporation. Interfejs z wieloma protokołami komunikacyjnymi konwertuje komunikaty (np. Dane) z protokołu komunikacyjnego zaimplementowanego przez jednostkę sterującą pojazdu silnikowego na format odczytywalny przez procesor.  W ten  sposób procesor 102 może odczytywać kody błędów z jednostki sterującej pojazdu silnikowego i dostarczać sygnały testowe do jednostki sterującej pojazdu silnikowego tak, że można testować różne siłowniki i / lub czujniki w pojeździe mechanicznym.   Procesor 102 jest również połączony z wyświetlaczem 106  i  CPLD  104 poprzez magistralę systemową 122. Procesor 102 jest zaprogramowany tak, aby dostarczał dane wyjściowe do użytkownika za pośrednictwem wyświetlacza 106 i odbierał dane wejściowe od użytkownika za pośrednictwem klawiatury 126. Procesor 102 uruchamia wybraną procedure komunikacji z wybranymi jednostkami sterującymi pojazdów silnikowych. W  przykładzie wykonania procesor  102  to  MPC823  wyprodukowany przez Motorola Corporation. CPLD 104 jest również połączony z klawiaturą numeryczną 126. CPLD 104 zapewnia układ logiczny do dekodowania różnych danych wejściowych od użytkownika narzędzia diagnostycznego 100 (przez klawiaturę numeryczną 126), a także zapewnia logikę działania dla różnych innych zadań związanych z łączeniem.   Podsystem pamięci 108, wewnętrzna pamięć nieulotna 118 i zewnętrzna pamięć nieulotna 120 są połączone z magistralą systemową 122. Podsystem pamięci 108 zawiera zależną od aplikacji ilość pamięci dynamicznej o dostępie swobodnym (DRAM) oraz pamięć tylko do odczytu (ROM). Wewnętrzna pamięć nieulotna 118 i zewnętrzna pamięć nieulotna 120 mogą być  programowalną pamięcią tylko do odczytu (EEPROM) lub pamięcią flash ROM. Wewnętrzna pamięć nieulotna 118 może zapewnić przechowywanie kodu rozruchowego, autodiagnostyki, różnych sterowników i miejsca na obrazy FPGA, jeśli jest to pożądane. Zewnętrzna pamięć nieulotna 120 może zapewnić przechowywanie zaktualizowanych programów lub danych (np. Diagnostycznych kodów usterek (DTC)).  Schemat blokowy  FPGA 114, przedstawiony na Fig.2 zawiera osiem modułów, gdzie przykładowo piąty moduł 208 zapewnia obsługę kanału J1850 dla komunikacji PWM  i  komunikacji z pojazdem w oparciu o sygnały z  modulacją o zmiennej szerokości impulsu (VPWM). Szósty moduł 210 to moduł kanału szeregowego interfejsu peryferyjnego (SPI) do komunikacji z konwerterem analogowo-cyfrowym (A / D), interfejsem sieci kontrolera (CAN),  według  SPI (Serial Peripheral Interface).

    Siódmy moduł 212 zapewnia wiele timerów do synchronizacji różnych komunikatów pojazdu. Ósmy moduł 214 jest modułem sterującym przerwań i przeprogramowania, który zapewnia włączanie i wyłączanie globalnego przerwania interfejsu i zapewnia możliwość wykonywania operacji ponownego flashowania  pamięci sterowników w pojeździe silnikowym.  Ponadto FPGA 114 zawiera syntezator zegara 216, jak również różne bufory i  układ logiczny do dekodowania adresu 218. Implementacja wielu modułów w jednym urządzeniu logicznym, takim jak FPGA 114, zapewnia wszechstronny interfejs, który może pomieścić wiele protokołów komunikacyjnych występujących w wielu pojazdach silnikowych, przy czym  każdy moduł ma odpowiadający blok szesnastu 8-bitowych lokalizacji adresowych. Te lokalizacje adresowe (rejestry) pozwalają użytkownikowi zaprogramować moduł dla żądanego protokołu komunikacyjnego.

     Zgodnie z konfiguracją moduł 208 obsługuje komunikację J1850 dla protokołów VPWM (GM i Chrysler) oraz PWM (Ford). FIGA.3 to schemat blokowy modułu kanału  J1850.  Informacje są dostarczane do modułu kanału J1850 208 przez magistralę danych 209 (D0-D7), linię odbiorczą 211 VPWM (VPWM RX), linię odbiorczą PWM 213 (PWM RX) i linię 215 transmisji nadprądowej (TX +). Moduł kanału J1850 208 przesyła dane do jednostki sterującej pojazdu silnikowego przez różnicowe linie transmisyjne 217 i 219 (odpowiednio PWM TX + i PWM TX-), gdy jest zaprogramowany na tryb PWM. Po zaprogramowaniu na tryb VPWM,  moduł kanału J1850 208 przesyła informacje przez linię transmisyjną 221 VPWM (VPWM TX).   Mapa adresowania  modułu 208 kanału J1850 przedstawia Fig.4, według której  rejestr wyboru trybu pracy określony jest poprzez przesunięciu adresu 0X00. Pomijając szczegóły implementacji softwarowej do realizacji  obsługi  w/w kanału należy zauważyć  możliwości  moduł kanału 208 J1850, który  został skonfigurowany tak, że może selektywnie implementować wiele protokołów komunikacyjnych. W szczególności moduł kanału J1850 może obsługiwać protokoły komunikacyjne PWM lub VPWM. Podobne protokoły komunikacyjne są zazwyczaj zgrupowane w innych modułach FPGA 114 tak, że obwody konwersji wspólne dla zgrupowanych protokołów komunikacyjnych mogą być współużytkowane. Wykorzystanie wielu modułów, takich jak moduły 200, 202, 204, 206, 208, 210, 212, 214, 216 i 218, wszystkie zawarte w układzie FPGA 114, pozwala użytkownikowi korzystnie diagnozować pojazdy, które realizują wiele protokołów komunikacyjnych w tym samym pojeździe.

    US7248954  INTEGRATED CIRCUIT VEHICLE DIAGNOSTICS INTERFACE ADAPTER APPARATUS AND METHOD, SPX Corp. Chinnadurai et al.,Data patent:24.07.2007.  Wynalazek przedstawia  urządzenie i sposób, które zapewnia adapter interfejsu diagnostycznego pojazdu wbudowany w pojedynczy układ scalony, który przełącza sygnały z różnych styków złącza interfejsu pojazdu do różnych styków wyjściowych skanera diagnostycznego pojazdu. Obdi3

    FIG.1 jest schematem blokowym  ilustrującym interfejs między narzędziem diagnostycznym  pojazdu a komputerem pokładowym pojazdu;  FIG.2 to schemat układu styków złącza SAE J1962; FIG.3 jest schematycznym przedstawieniem ilustrującym adapter interfejsu diagnostyki pojazdu z układem scalonym według przykładu wykonania wynalazku.

    Ponieważ nowoczesne pojazdy zawierają wiele elektronicznych modułów sterujących do sterowania różnymi systemami pojazdu, wymagana jest pokładowa sieć komputerowa, aby umożliwić komunikację między różnymi elektronicznymi modułami sterującymi. Aby ułatwić korzystanie z zewnętrznego sprzętu testującego, w pojazdach zapewniono złącza wiązek przewodów, aby umożliwić podłączenie zewnętrznego testera do w/w sieci w pojeździe.

    Dodatkowo od 1996 roku prawo federalne Stanów Zjednoczonych i prawo stanowe wymagają, aby producenci pojazdów wyposażali pojazdy w szesnastostykowe złącze SAE J1962 oraz aby sieć w pojeździe obsługiwała co najmniej jeden z kilku wspólnych standardów sieciowych. W rezultacie większość produkowanych obecnie samochodów zawiera złącze J1962 jako łącze diagnostyczne między komputerami w pojeździe a sprzętem testowym poza pojazdem, wykorzystując jeden lub więcej standardów protokołu interfejsu sieciowego. Tak więc, chociaż tester diagnostyczny pojazdu ze złączem J1962 może być podłączony do praktycznie wszystkich pojazdów wyprodukowanych od 1996 roku, dane otrzymane na poszczególnych pinach złącza różnią się w zależności od producenta pojazdu.

    Komputery pokładowe 14 w różnych pojazdach 12 mogą korzystać z różnych protokołów lub standardów komunikacji sieciowej do komunikacji z diagnostycznymi narzędziami skanującymi 10.  Złącze 18 interfejsu komputera pokładowego pojazdu w większości pojazdów wyprodukowanych od 1996 r. Jest złączem SAE J1962. FIGA.2 przedstawia układ styków złącza okablowania SAE J1962 22, wymaganego w systemach diagnostyki pokładowej (OBD) od 1996 r. Mimo że złącze J1962 jest instalowane w większości pojazdów od 1996r., pojazdy produkowane przez różnych producentów mogą przesyłać i  odbierać komunikację sieciową w pojeździe na różnych stykach. Na przykład moduł sterujący w pojeździe wyprodukowanym przez jednego producenta może wykorzystywać pin 2,24 do wysyłania i odbierania sygnału „dodatniego” protokołu komunikacyjnego ISO 9141-2, podczas gdy pojazd produkowany przez innego producenta może wykorzystywać pin 6, 26 do wysyłania tego samego sygnał lub styk  2,24, aby wysłać inny sygnał.  W wyniku tego, gdy diagnostyczne narzędzie skanujące 10 podłączone jest  do pojazdu 12, komunikacja wejścia/wyjścia może dotrzeć do złącza we/wy 20 narzędzia diagnostycznego pojazdu na różnych stykach, w zależności od producenta pojazdu. Zatem, gdy narzędzie skanujące 10 do diagnostyki pojazdu jest podłączone do pojazdu 12 za pomocą zespołu przewodów interfejsu 16, dane odebrane ze złącza we/wy 20 narzędzia skanującego muszą być skierowane do prawidłowego obwodu wewnętrznego protokołu komunikacyjnego w diagnostyce pojazdu za pomocą narzędzia skanującego 10.  Przykład wykonania  urządzenia i sposób jego działania  jest zilustrowany na FIG.3, w którym adapter interfejsu diagnostyki pojazdu 30 układu scalonego odbiera dane ze złącza interfejsu pojazdu 18 za pośrednictwem zespołu przewodów interfejsu 16. Dane wejściowe są kierowane do układu scalonego 32 za pośrednictwem  dwukierunkowych styków 34 po stronie pojazdu, z których każdy jest połączony z parą półprzewodnikowych przełączników 36,38  układu 32 za pomocą zintegrowanego przewodu 37.  Przełączniki 36,38 po stronie pojazdu mogą przesyłać sygnały elektryczne o różnych poziomach napięcia, na przykład 12V.  Jeden z każdej pary przełączników 36,38 po stronie pojazdu jest połączony z jednym z dwóch fizycznych przewodów bramkowych 40,42 przez zintegrowany przewód 44 na podłożu półprzewodnikowym 32.   Każdy z dwóch fizycznych przewodników 40,42 bramy jest z kolei sprzężony z jednym przewodem  z każdej pary zestawu sparowanych półprzewodnikowych przełączników po stronie narzędzia 46,48, przez zintegrowany przewód 47,  układu 32. Tutaj ponownie, przełączniki 46,48 po stronie narzędzia diagnostycznego mogą być zdolne do przesyłania sygnałów o poziomach napięcia od zero do 12V.  Zatem adapter interfejsu diagnostyki pojazdu 30 może być  układem scalonym monolitycznym  lub  hybrydowym.  Każda para dwukierunkowych styków 49  połączona z parą przełączników 46,48 narzędzia diagnostycznego. Obwód we/wy 50 narzędzia skanującego są  skonfigurowany do wysyłania i odbierania określonego protokołu komunikacyjnego.

    W ten sposób adapter interfejsu diagnostyki pojazdu 30 może łączyć dowolne dwa styki złącza interfejsu 18 pojazdu z dowolnym z obwodów we/wy 50 protokołu komunikacyjnego.  Jest to realizowane przez połączenie jednego z dwóch dwukierunkowych styków 34 po stronie pojazdu, który jest  skojarzonych  z jednym z dwóch styków złącza interfejsu pojazdu 18 do przewodu bramy 40 lub 42 skojarzonym z odpowiednim sygnałem protokołu komunikacyjnego (wysoki / dodatni lub niski / ujemny).  Drugi dwukierunkowy styk 34 po stronie pojazdu , który jest skojarzony z drugim  wtykiem złącza interfejsu pojazdu 18 podłączony jest do drugiego przewodu bramy 42 lub 40, za pośrednictwem jednego z przełączników 36,38 po stronie pojazdu, a tym samym do dwukierunkowego styku 49 urządzenia diagnostycznego   za  pośrednictwem jednego z przełączników 46, 48.

    W podobny sposób liczba przełączników 46,48 po stronie narzędzia jest co najmniej dwa razy większa niż liczba protokołów komunikacyjnych, do  których  diagnostyczne narzędzie skanujące 10 jest skonfigurowane. Na przykład, jeżeli narzędzie skanujące 10 diagnostyki pojazdu jest skonfigurowane do komunikacji przy użyciu trzech różnych protokołów komunikacyjnych 50,  jak pokazano na FIG.3, adapter interfejsu diagnostyki pojazdu 30  zawiera co najmniej sześć przełączników 40. Adapter interfejsu diagnostyki pojazdu 30 zawiera również moduł sterujący przełączników 52, zintegrowany z układem 32, który jest połączony z przełącznikami 36,38 po stronie pojazdu za pomocą magistrali sterującej 54  i  do  przełączników 46,48 po stronie narzędzia  diagnostycznego przez drugą magistralę sterującą 56. Obwód sterowania przełącznikiem 52 jest również połączony z interfejsem magistrali sterowania przełącznikiem 58, który komunikuje się z różnymi magistralami systemowymi 60, przez które obwód sterowania przełącznikiem 52 odbiera dane dotyczące typu pojazdu lub konfiguracji złącza 18 interfejsu pojazdu. Na przykład, w  przykładzie wykonania, interfejs magistrali 58 komunikuje się z innymi modułami systemu za pośrednictwem magistrali 60 szeregowego interfejsu peryferyjnego (SPI – Serial Peripheral Interface).  Przykład wykonania pokazany na FIG.3 zawiera dwa fizyczne przewody bramkowe 40,42 co zapewnia że urządzenie diagnostyczne  jest kompatybilne z większością protokołów komunikacyjnych w istniejących  pojazdów, ponieważ większość protokołów wymaga jednego lub dwóch przewodów przenoszących sygnał diagnostyczny. Sposób działania testera diagnostycznego 30 polega na tym, że   styki wykorzystywane do komunikacji sieciowej w konkretnej marce pojazdu  i modelu są multipleksowane przez adapter interfejsu diagnostyki pojazdu 30  w  celu dopasowania styków wykorzystywanych w konkretnym diagnostycznym  złączu we / wy pojazdu 20 poprzez konfigurację różnych przełączników po stronie pojazdu 36,38  i   po stronie narzędzia diagnostycznego  46,48. Zatem adapter interfejsu diagnostyki pojazdu 30 może łączyć dowolne dwa wtyki złącza interfejsu 18 pojazdu z dowolnym z obwodów 50 protokołu komunikacyjnego we/wy. Odbywa się to poprzez połączenie jednego z dwóch dwukierunkowych styków 34 po stronie pojazdu, związanych z jednym z dwóch styków złącza 18 interfejsu pojazdu, z przewodem bramki 40 lub 42 skojarzonym z odpowiednim sygnałem protokołu komunikacyjnego (wysoki / dodatni lub niski / ujemny ) i drugi dwukierunkowy styk 34 po stronie pojazdu powiązany z drugim z dwóch styków złącza interfejsu pojazdu 18 do drugiego przewodu bramy  42  lub  40,  za pośrednictwem jednego  z  przełączników 36,  38 po stronie pojazdu.   Podobnie dwukierunkowy styk  boczny  49 połączony z obwodem 50 wybranego protokółu komunikacyjnego, komutowany jest za pośrednictwem jednego z przełączników 46, 48.

    US9418490 DATA DISPLAY WITH CONTINUOUS Bosch Automotive Service Solutions Inc., Gray et al., Data patentu: 16.08.2016. Wynalazek dotyczy ogólnie narzędzia diagnostycznego pojazdu posiadającego koncentrator diagnostyczny i ciągły bufor danych. W szczególności centrum diagnostyczne to graficzny interfejs użytkownika, który umożliwia użytkownikowi nawigację po różnych funkcjach narzędzia diagnostycznego. Bufor danych umożliwia automatyczne zapisywanie danych w buforze pamięci. Narzędzia diagnostyczne pojazdów raportują dane zebrane przez pokładowe komputery sterujące.  Narzędzia diagnostyczne mogą wykrywać usterki na podstawie diagnostycznych kodów usterek lub kodów DTC Diagnostic Trouble Code  ustawionych na pokładowych komputerach sterujących pojazdu. DTC może zostać wywołany i zapisany w przypadku problemu z pojazdem. Następnie technik pobiera kody DTC  za pomocą narzędzia diagnostycznego, naprawia związany problem, a następnie usuwa kody DTC z komputera pojazdu. Zgodnie z  przykładem wykonania niniejszego wynalazku, zapewniono graficzny interfejs użytkownika dla narzędzia diagnostycznego pojazdu posiadającego wiele funkcji diagnostycznych, który może zawierać okno strumienia danych, do wyświetla danych  diagnostycznych odebranych z pojazdu, okno powiększenia, które wyświetla powiększoną część okna strumienia danych, linię czasu z przyrostami czasu i wskaźnik ramki, który przesuwa się wzdłuż linii czasu, aby wskazać przyrosty czasu oglądanego w oknie strumienia danych, przy czym wskaźnik ramki może być przesuwane wzdłuż osi czasu przez użytkownika.

  • Obdi3

  • FIG.1 przedstawia widok z przodu narzędzia diagnostycznego zgodnie z przykładem wykonania wynalazku;  FIG. 2 to widok z góry narzędzia diagnostycznego FIG. 1 pokazując różne złącza; FIG. 3 jest schematem blokowym elementów narzędzia diagnostycznego programu FIG. 1 według przykładu wykonania wynalazku;  FIG. 4 ilustruje hub diagnostyczny według przykładu wykonania  wynalazku;  FIG. 5 ilustruje użytkownika wybierającego przycisk start nowego przycisku zgodnie z przykładem wykonania wynalazku;  FIG. 6 ilustruje użytkownika wybierającego przycisk odczytu DTC według przykładu wykonania wynalazku;  FIG. 7 ilustruje przykładowy ekran wyszukanego kodu DTC według przykładu wykonania wynalazku;  FIG. 8 ilustruje dodatkowe informacje o wybranym DTC według przykładu wykonania wynalazku; FIG. 9 ilustruje okno, które może się pojawić po wybraniu specjalnego przycisku testów zgodnie z przykładem wykonania wynalazku;  FIG. 10 ilustruje ekran zawierający różne parametry danych, które można zmierzyć podczas specjalnego testu według przykładu wykonania wynalazku;  FIG. 11 ilustruje okno strumienia danych według przykładu wykonania wynalazku;  FIG. 12 ilustruje okno strumienia danych mające oś czasu 1200 według przykładu wykonania wynalazku. Wynalazek jest  opisany w odniesieniu do figur rysunku, na których podobne odnośniki liczbowe odnoszą się w całym tekście do podobnych części. Przykład wykonania według niniejszego wynalazku zapewnia narzędzie diagnostyczne, które zawiera wyświetlacz z ekranem dotykowym i centrum diagnostyczne w postaci GUI (Graphical User Interface). Centrum diagnostyczne umożliwia użytkownikowi korzystanie z różnych funkcji narzędzia diagnostycznego, takich jak odczytywanie kodów DTC, przeglądanie i rejestrowanie strumienia danych, uzyskiwanie informacji diagnostycznych, przeprowadzanie specjalnych testów, uruchamianie ogólnych testów OBD, testy emisji, wyszukiwanie w Internecie lub uzyskiwanie dodatkowych informacji diagnostycznych i tym podobne.

     Przykładem narzędzia diagnostycznego jest Genisys® Touch firmy Service Solutions US LLC ), FIG.1. Narzędzie diagnostyczne 100 może zawierać obudowę 102 , wyświetlacz 104 , przycisk funkcyjny 106 , przycisk zasilania 108 , części chwytające 110 mające część 112 do przyjmowania palca (kciuka) i kamerę 114 . Przycisk zasilania 108 może być również użyty do przestawienia narzędzia diagnostycznego 100 w tryb czuwania, aby oszczędzać energię baterii, gdy nie jest używane. Wyświetlacz 104 umożliwia użytkownikowi wprowadzanie wyboru za pośrednictwem ekranu dotykowego w celu interaktywnej nawigacji i wyboru, przy czym technik może wybrać pozycję menu, taką jak centrum diagnostyczne 400 (dalej omówione poniżej), dotykając wyboru na centrum diagnostyczne / ekran. Ponadto ekran dotykowy, po dotknięciu, może również służyć do wybudzania narzędzia diagnostycznego, jeśli jest w trybie uśpienia. Kamera 114 może być ustawiona przodem do użytkownika, tak że użytkownik może prowadzić rozmowę wideo z inną osobą w zdalnej lokalizacji. Kamera może być również umieszczona na dowolnej powierzchni narzędzia diagnostycznego 100, w tym po przeciwnej stronie wyświetlacza 104, tak aby można było wykonać zdjęcia części silnika lub dowolnych komponentów pożądanych przez użytkownika.

    Widok z góry narzędzia diagnostycznego 100 , Fig.2 pokazuje  jego złącza, przykładowo złącze zasilające  A/C 202 . Źródło zasilania A/C zasila narzędzie diagnostyczne 100 i ładuje wewnętrzną baterię narzędzia diagnostycznego., natomiast  złącze wideo VGA 204,  umożliwia wyświetlanie informacji z  narzędzia diagnostycznego 100 na wyświetlaczu zewnętrznym, takim jak wyświetlacz komputera osobistego. Inne typy złączy wyświetlacza mogą obejmować HDMI dla lepszej grafiki i dźwięku oraz gniazda złączy  USB (uniwersalnej magistrali szeregowej) 206 , które  mogą zapewniać  podłączenia dodatkowych urządzeń do narzędzia diagnostycznego 100.   Dodatkowe  złącze Ethernet 212,  umożliwia połączenie sieciowe z narzędziem diagnostycznym 100  w celu przesyłania danych do i z narzędzia diagnostycznego do zdalnego urządzenia, takiego jak serwer lub komputer osobisty.

    Narzędzie diagnostyczne 100 według przykładu wykonania wynalazku FIG.3 może zawierać kamerę 114 , procesor 302 , tablicę programowalną przez użytkownika (FPGA) 314 , pierwszą magistralę systemową 324 , wyświetlacz 104 , złożone programowalne urządzenie logiczne (CPLD) 306 , urządzenie wejściowe 106 lub przycisk funkcyjny, pamięć 308 , wewnętrzna pamięć nieulotna (NVM) 318  z bazą danych 312  i  programem, czytnik kart 210 , drugą magistralę systemową 322 , interfejs złącza 311, wybieralny translator sygnału 310 , antenę GPS 332 , odbiornik GPS 334 , opcjonalny wysokościomierz 336 i obwód 338 komunikacji bezprzewodowej.  Bezprzewodowy obwód komunikacyjny 338 komunikuje się z procesorem 302 za pośrednictwem drugiej szyny systemowej 322.  Bezprzewodowy obwód komunikacyjny 338może być skonfigurowany do komunikacji przez RF (częstotliwość radiowa), satelity, telefony komórkowe (analogowe lub cyfrowe), Bluetooth®, Wi-Fi, podczerwień, sieci lokalne (LAN), WLAN (Wireless Local Area Network), inne bezprzewodowe konfiguracje i standardy komunikacji lub ich kombinacja. Bezprzewodowy obwód komunikacyjny 338 umożliwia narzędziu diagnostycznemu bezprzewodową komunikację z innymi urządzeniami, na przykład ze zdalnym urządzeniem komputerowym  posiadającym zdalne bazy danych. Translator sygnałów 310 może komunikować się na przykład z następującymi protokołami komunikacyjnymi: J1850 (VPM i PWM), sygnał ISO 9141-2, łącza transmisji danych (DCL), interfejsem  komunikacyjnym (SCI), Controller Area Network (CAN), Keyword 2000 (ISO 14230-4), OBD II lub inne protokoły komunikacyjne zaimplementowane w pojeździe. Zespół obwodów do translacji i wysyłania danych  w określonym protokole komunikacyjnym może być wybrany przez FPGA 314, przy czym FPGA 314 może być sprzężony z procesorem 302 poprzez różne linie adresowe, danych i sterowania przez drugiej szyny systemowej  322 . FPGA 314 jest również połączony z czytnikiem kart 210 poprzez pierwszą magistralę systemową  324 . Procesor 302 może być również połączony z wyświetlaczem 104 w celu wysyłania żądanych informacji do użytkownika. Procesor 302 komunikuje się z CPLD 306 poprzez drugą magistralę systemową 322 . Dodatkowo procesor 302 mogą być zaprogramowane do odbierania danych wejściowych od użytkownika za pośrednictwem urządzenia wejściowego 106 za pośrednictwem CPLD 306 lub przez wyświetlacz 104 z ekranem dotykowym.  CPLD 306 może zapewniać logikę do dekodowania różnych danych wejściowych od użytkownika narzędzia diagnostycznego 100, a także zapewnia logikę procedur  dla różnych innych zadań związanych z diagnostyką. Pamięć 308 i wewnętrzna pamięć nieulotna 318 mogą być połączone z drugą magistralą systemową 322 , która umożliwia komunikację z procesorem 302 i FPGA 314. Wewnętrzna pamięć nieulotna 318 może, w razie potrzeby, zapewnić, na przykład, miejsce do przechowywania kodu rozruchowego, autodiagnostyki, różnych sterowników i miejsca na obrazy FPGA. Antena GPS 332 jest elektronicznie sprzężona z odbiornikiem GPS 334 i umożliwia odbiornikowi GPS komunikację (wykrywa i dekoduje sygnały) z różnymi satelitami okrążającymi Ziemię.  Odbiornik GPS 334 i antena GPS 332 mogą elektronicznie połączyć się z procesorem 302 , który może być połączony z pamięcią 308, 318 lub kartę pamięci w czytniku kart 210.

     Pulpit diagnostyczne 400 może być graficznym interfejsem użytkownika wyświetlanym na wyświetlaczu 104 i zawierać różne komponenty, które  można wybrać palcem w celu wybrania komponentu. Alternatywnie, element można wybrać za pomocą rysika lub innych podobnych środków. Elementy składowe pulpitu diagnostycznego  400 mogą obejmować przycisk startu  402 , ogólny przycisk testowy 404 OBD, przycisk odczytu DTC 406 , przycisk strumienia danych 410 , przycisk informacji diagnostycznych 412 , specjalny przycisk testowy 414 , przycisk zakresu 416 , przycisk 418 przeglądarki internetowej i inne. Po wybraniu przez naciśnięcie lub naciśnięcie odpowiedniego przycisku, narzędzie diagnostyczne rozpocznie realizacje funkcji przypisanej do tego przycisku. Różne przyciski mogą zawierać wskaźnik informacji 408. Oznacza to, że dostępne są dodatkowe informacje dotyczące funkcji skojarzonej z tym przyciskiem. Wskaźnik informacji 408 może również wskazywać liczbę dodatkowych informacji, które są dostępne i może aktualizować tę liczbę dynamicznie i automatycznie. Wskaźnik informacji 408 może migać lub zmieniać kolory, aby wskazać, że dostępne są dodatkowe informacje. Liczba wskaźników  informacyjnych może się zwiększać lub zmniejszać, gdy dodatkowe informacje stają się dostępne, podczas korzystania  z narzędzia diagnostycznego 100 .

    Proces diagnostyki pojazdu rozpoczyna po naciśnięcie przycisku 402, FIG.5,które otwiera  okno 504 do dodatkowego wyboru typu pojazdu. Okno 504 zawiera przycisk anulowania 506 i listę ostatnich pojazdów 512. Najnowsza lista 512 pojazdów przedstawia pojazdy, nad którymi ostatnio pracowało narzędzie diagnostyczne  100. Przycisk anulowania 506 naciśnięcie spowoduje powrót ekranu do początkowego ekranu  diagnostycznego 400. Ponadto centrum diagnostyczne może automatycznie wyszukiwać 510 typ testowanego pojazdu na podstawie różnych danych. Jeżeli to automatyczne wyszukiwanie 510 nie zidentyfikuje badanego pojazdu, użytkownik może wybrać przycisk wprowadź nowy pojazd 508 i wybrać pojazd według marki, modelu i roku lub alternatywnie wprowadzając numer identyfikacyjny pojazdu. Po wyborze przyciski odczytu DTC 406, FIG.6 na ekranie wyświetlane są, różne pobrane DTC ,FIG.7,  wraz ze wskaźnikami informacyjnymi 408. Okno 702 wyświetla diagnostyczne kody usterek, a okno 704 pokazuje numer DTC wraz z definicją związaną z numerem DTC. Wskaźnik informacyjny 408 pokazany w rogu okna 704 wskazuje liczbę dodatkowych informacji, które są dostępne dla określonego DTC. Dodatkowe informacje mogą obejmować najważniejsze poprawki, schematy okablowania, komponenty, biuletyny, koszt naprawy, koszt i dostępność komponentów, potrzebne narzędzia, czas naprawy, wymagany poziom umiejętności i inne informacje. Okno 704 pokazuje również informacje aktualnym kodzie błędu  DTC. Dodatkowe informacje 804 o wybranym DTC wyświetla ekran pokazany  na FIG.8, przy czym okno 802 wskazuje użytkownikowi, że przegląda informacje diagnostyczne. Dodatkowe informacje 804 mogą zawierać opis kodu DTC, kryteria kodu, pin PCM, testy skanowania, lokalizację, wspomaganie kodowania i diagram. Te dodatkowe informacje 804 są głównie przechowywane w narzędziu diagnostycznym 100, ale alternatywnie mogą być pobierane ze zdalnej bazy danych. Okienko 902, FIG.9   może się pojawić, gdy zostanie wybrany specjalny przycisk  testowy 414.  Okienko 902 wskazuje, że specjalny test wymagany przez użytkownika dotyczy elektromagnetycznego zaworu sterującego ciśnieniem. Dodatkowo, aby kontynuować, muszą istnieć pewne parametry 904, takie jak włączony zapłon, wyłączony silnik i zakres „P”. W tym momencie użytkownik może anulować za pomocą przycisku anulowania 906 lub wybrać przycisk kontynuowania 910 wirtualną ręką 908 (po zaistnieniu wymaganych parametrów), aby przejść do okna pokazanego na FIG.10. Okno 1002, FIG.10 wskazuje, że narzędzie diagnostyczne 100 przeprowadza specjalny test, a mianowicie kontrolę prędkości silnika. Używając przycisku wybierania 1004 , użytkownik może zmienić typ specjalnego testu, który ma być przeprowadzony przez narzędzie diagnostyczne 100 . Różne mierzone parametry danych można sortować, wybierając przycisk opcji sortowania 1006 w celu sortowania w porządku malejącym lub rosnącym lub podobnym. Można wybrać przycisk Wyczyść dane 1008, aby usunąć wszystkie dane zebrane podczas specjalnego testu. Przycisk ładowania nagrywania 1010  można wybrać, aby załadować poprzednie zapisy danych lub bieżące zapisy danych zapisane w narzędziu diagnostycznym 100 lub zdalnie.

    Okno 1102, FIG.11 ilustruje  strumienia danych według przykładu wykonania wynalazku. Przycisk wybierania  1104 może być wybrany w celu dalszego udoskonalenia typu strumienia danych, który użytkownik chciałby oglądać na narzędziu diagnostycznym 100 . W tym przykładzie wykonania, użytkownikowi można pokazać dane związane z czujnikiem prędkości pojazdu, czujnikiem temperatury powietrza dolotowego, prędkością wału pośredniego, modulowaną szerokością impulsu wtryskiwacza, komórką trymowania, prędkością silnika, ciśnieniem w kolektorze dolotowym i tym podobnymi. Okno danych 1114 wyświetla bieżący odczyt danych, na przykład z czujnika prędkości pojazdu, a okno powiększenia 1116 wyświetla powiększoną część okna danych  1114 w celu łatwego przeglądania okna danych. Okno powiększenia1116 jest generowane i kontrolowany przez procesor. Dane w oknie danych 1114 mogą być przeglądane w różnych formatach po wybraniu przycisku wybierania numeru 1122 przez użytkownika. Po wybraniu użytkownik może przeglądać dane w postaci wykresu słupkowego, przebiegu i tym podobnych. Dodatkowo, użytkownik może wybrać przesunięcie okna danych  1114 do góry, do dołu lub do środka lub do różnych miejsc na ekranie. Użytkownik może również wybrać wyświetlanie tylko tego konkretnego okna danych lub wyświetlanie tego konkretnego okna danych 1114 na pełnym ekranie. Ponadto, jeśli potrzebne są dodatkowe informacje o elemencie, użytkownik może wybrać otrzymywanie większej ilości informacji o elemencie, takich jak koszt, czas wymiany, wymagany poziom umiejętności, dostępność i tym podobne.  Okno 1102 strumienia danych na osi  oś czasu 1200  przedstawia FIG.12. Linia czasu  1200 umożliwia użytkownikowi przeglądanie strumienia danych w różnych punktach czasowych, zgodnie z potrzebami. Okienko ramkowe 1202 jest wyposażone w przyrosty, aby zapewnić punkty odniesienia na linii czasu. Przyrosty mogą być w sek., msek, 2 sekundach, 4 sekundach, 5 sekundach, 8 sekundach, 10 sekundach i tym podobnych. Wskaźnik ramki 1204służy do wskazania użytkownikowi, która część czasu na osi czasu jest wyświetlana. Wskaźnik ramki, w jednym przykładzie wykonania, może wskazywać, kiedy osiąga dane, które są poza z góry określonym zakresem  parametru, aby ostrzec użytkownika oraz aby dokładnie oglądał strumień danych. Wskaźnik ramki może wskazywać miganiem, zmianą kolorów, świeceniem itp. Przycisk nagrywania 1206 umożliwia użytkownikowi nagrywanie strumienia danych zgodnie z wymaganiami.

    Wnioski

    Jak sama nazwa wskazuje, diagnostyka jest głównym celem OBD. Kiedy czujniki samochodu stwierdzą, że coś jest nie tak, wyzwalają komunikat znany jako „kod usterki”, który może objawiać się kontrolką „Check Engine” lub innym ostrzeżeniem na desce rozdzielczej. Skanery OBD mogą sprawdzać te kody usterek, aby dokładnie określić, co jest nie tak, i usuwać je z pamięci komputera, gdy problem zostanie rozwiązany.  Kody problemów to tylko to: Kody cyfrowe. Zamiast diagnozy typu „luźny korek wlewu gazu” zobaczysz ciąg liter i cyfr, które są niezrozumiałe bez odniesienia do danych producenta.  Kody błędów rozpoczynają się od litery i zawierają cztery lub pięć cyfr, które razem wskazują konkretny podsystem i napotkany problem. Sprawa jest prosta , jeżeli zastosowany  skaner OBD ma fabrycznie załadowane definicje tych kodów, w przeciwnym razie będziesz potrzebować listy podobnej do tej, którą można znaleźć na https://www.auto-krak.pl/auto-krak/diagnostyka/kody-bledow-dtc-z-polskim-tlumaczeniem/  . Należy pamiętać, że oprócz kodów ogólnych, które mają zastosowanie do wszystkich samochodów, poszczególni producenci mają własne, specyficzne kody. Znalezienie ich może być nieco trudniejsze, ponieważ nie każdemu producentowi odpowiada pomysł udostępnienia ich opinii publicznej.

    Ciekawym rozwiązaniem taniego testera OBD oferowanego na Allegro  jest   INTERFEJS DIAGNOSTYCZNY VGATE iCAR2 ELM327 BLUETOOTH, którego sercem jest zaprogramowany układ mikroprocesorowy  ELM327 firmy Elm Electronics..  Oryginalny ELM327 jest zaimplementowany na mikrokontrolerze PIC18F2480 firmy Microchip Technology. Protokół poleceń ELM327 jest jednym z najpopularniejszych standardów interfejsu PC-OBD i jest również implementowany przez innych dostawców ELM327, ponieważ zapewnia  uniwersalny konwerter protokołów stosowanych w diagnostyce samochodowej na protokół szeregowy RS-232. Interakcja ECU samochodu z ELM327 odbywa się poprzez transfer poleceń AT, które obsługuje ten mikroukład. Aby to zrobić, konieczne jest zorganizowanie wymiany wiadomości tekstowych za pomocą protokołu RS-232 (a raczej UART, skoro mowa o transmisji danych).  Fizyczne połączenie przez USB, Bluetooth lub Wi-Fi jest łatwe dzięki chipom do konwersji protokołu szeregowego UART.  Technologia została opracowana przez kanadyjską firmę Elm Electronics, która udostępniła kompletna dokumentacje pierwszych wersji interfejsu diagnostycznego-ELM327DShit. 2.

    Reklamowany na Allegro INTERFEJS DIAGNOSTYCZNY VGATE iCAR2 ELM327 BLUETOOTH – Interfejs może działać z darmowym  oprogramowaniem, Car Scanner ELM OBD2   i umożliwia:
    • Odczyt i kasowanie błędów OBD-II
    • Kasowanie lampki CHECK ENGINE
    • Odczyt kodów błędów oczekujących, kiedy lampka MIL jeszcze się nie pali
    • Odczyt kodów błędów zarejestrowanych, które spowodowały zapalenie lampki MIL
    • Odczyt kodów błędów ogólnych i charakterystycznych producenta
    • Podgląd zamrożonych ramek – FREEZE FRAMES
    • Monitorowanie parametrów pracy silnika w czasie rzeczywistym – LIVE DATA
    • Odczyt parametrów rzeczywistych na bieżąco
    • Sprawdzanie znaczenia kodów błędów
    • Pomiar mocy silnika (KM)
    • Pomiar parametrów takich jak czas od 0-100 km/h 3

    Jako ciekawostke polecam materiał filmowy ilustrujacy podobny interfejs OBDII:  Jak skasować błąd CHECK ENGINE w aucie? ELM 327 Interfejs Bluetooth  https://www.youtube.com/watch?v=B7ROyLxRYts