Rozdział 6. Protokoły

Rozdział 5. Interfejsy | OpenDiag - STM32 CAN Tool | Rozdział 7. Testy

Moim zdaniem to będzie drugi najważniejszy rozdział po architekturze. Ale proponuję go trochę zmienić.

Nie opisywałbym tu szczegółowo ELM327 czy UDS. To są setki stron dokumentacji. Zamiast tego opiszmy jakie protokoły przechodzą przez nasze urządzenie i jak są ze sobą powiązane.

Rozdział 6. Protokoły

6.1 Cel

Urządzenie OpenDiag pełni rolę pośrednika pomiędzy aplikacją na komputerze a siecią pojazdu.

Nie implementuje jednego protokołu, lecz tłumaczy i przekazuje dane pomiędzy wieloma warstwami komunikacji.

6.2 Model komunikacji

Linux / Windows
       │
FORScan / OpenDiag GUI
       │
USB CDC / USB Vendor
       │
Parser poleceń
       │
ELM327 / STN / Native
       │
OBD-II / UDS / ISO-TP
       │
     CAN API
       │
HS / MS / I-CAN

Każda warstwa ma jasno określoną odpowiedzialność.

6.3 USB

Pierwszy protokół.

Na początku:

USB CDC

Przeznaczenie:

  • komunikacja z FORScan,
  • terminal diagnostyczny.

W przyszłości:

  • USB Vendor,
  • DFU.

6.4 Parser poleceń

Parser odbiera tekst zakończony CR (\r).

Przykładowe polecenia:

ATI

ATZ

0100

22F190

Parser nie interpretuje znaczenia poleceń.

Jedynie przekazuje je do odpowiedniego modułu.

6.5 ELM327

Pierwszy obsługiwany protokół.

Zakres pierwszej wersji:

  • komendy AT,
  • OBD-II Mode 01,
  • podstawowa konfiguracja adaptera.

Implementujemy wyłącznie funkcjonalność wymaganą przez FORScan.

6.6 STN

Drugi protokół.

Dodaje rozszerzenia do ELM327.

Przykłady:

STI

STMA

STPX

Implementacja planowana w późniejszym etapie.

6.7 Native Protocol

Docelowo urządzenie będzie posiadało własny binarny protokół komunikacyjny.

Cele:

  • większa szybkość,
  • pełny dostęp do wszystkich magistral,
  • jednoczesna obsługa wielu kanałów CAN,
  • przesyłanie ramek bez ograniczeń ELM327.

Będzie wykorzystywany przez aplikację OpenDiag.

6.8 OBD-II

Warstwa diagnostyczna.

Obsługiwane tryby będą dodawane etapami.

Pierwsze:

Mode 01

Mode 03

Mode 04

Później kolejne.

6.9 ISO-TP

Warstwa transportowa.

Obsługuje:

  • segmentację ramek,
  • składanie wiadomości,
  • Flow Control.

Stanowi podstawę komunikacji UDS.

6.10 UDS

Unified Diagnostic Services.

Na początku projekt nie implementuje pełnego UDS.

Obsługa będzie rozszerzana zgodnie z wymaganiami FORScan.

6.11 CAN

Najniższa warstwa komunikacyjna.

Obsługuje:

  • wysyłanie ramek,
  • odbiór ramek,
  • filtry,
  • błędy magistrali.

Warstwa ta nie posiada wiedzy o OBD-II ani UDS.

6.12 Przepływ danych

Przykład 1 – FORScan

FORScan
   │
USB CDC
   │
Parser
   │
ELM327
   │
OBD-II
   │
ISO-TP
   │
CAN

Przykład 2 – OpenDiag GUI

OpenDiag GUI
     │
USB Native
     │
Native Protocol
     │
CAN

Tutaj omijamy ELM327.

6.13 Rozszerzalność

Każdy protokół stanowi niezależny moduł.

Przykładowo można później dodać:

KWP2000

J1939

XCP

DoIP

bez zmian pozostałych warstw.

6.14 Zakres pierwszej wersji

Wersja 0.1 projektu obejmuje:

  • USB CDC,
  • Parser,
  • ELM327 (podstawowe komendy),
  • CAN.

Pozostałe protokoły będą rozwijane iteracyjnie.

Chciałbym jednak zaproponować jedną zmianę w całej koncepcji

Do tej pory zakładaliśmy, że parser będzie kierował polecenia do ELM, STN lub Native. Po zastanowieniu uważam, że lepiej byłoby rozdzielić transport od protokołu aplikacyjnego.

Czyli:

USB CDC
      │
Line Reader
      │
Command Dispatcher
      │
 ┌────┴─────┐
 │          │
ELM      Native
 │          │
OBD      CAN API

Dlaczego?

Bo wtedy:

  • Line Reader odpowiada wyłącznie za odbiór kompletnej linii tekstu,
  • Command Dispatcher decyduje, do którego modułu ją przekazać,
  • ELM327 zajmuje się tylko interpretacją komend ELM,
  • własny protokół może być binarny i nie będzie musiał przechodzić przez parser tekstowy.

To rozdzielenie uprości implementację i sprawi, że dodanie właszego protokołu nie będzie wymagało modyfikowania parsera ELM. W praktyce oznacza to mniej zależności między modułami i czystszą architekturę.