Zdecydowana większość samochodów, które interesują nas w ramach projektu, posiada interfejs diagnostyczny w standardzie OBD. Umożliwia on połączenie z każdym istotnym sterownikiem wchodzącym w skład instalacji elektrycznej, odczyt podstawowych wartości pomiarowych, zarejestrowanych kodów usterek, itp. Komunikacja odbywa się za pomocą protokołu KWP1281 lub KWP2000. Są one charakterystyczne dla pojazdów grupy VAG.
Nie będę w tym miejscu opisywał szczegółów samego protokołu – jest to temat bardzo obszerny i nie sposób zamknąć go w jednym tylko artykule. Zainteresowanych odsyłam do strony, która bardzo przystępnie przedstawia najważniejsze elementy protokołu KWP1281. Postaram się za to bardziej skupić na jego logicznej strukturze i aspektach związanych z jego obsługą po stronie naszego urządzenia, częściowo w oparciu o model OSI.
Przyjrzyjmy się kolejnym warstwom:

Warstwa fizyczna

Szeregowa transmisja odbywa się w sposób asynchroniczny, zbliżony do standardu RS-232. Magistrala składa się z jednego przewodu, służącego do dwustronnej komunikacji – jest to więc interfejs half-duplex. Stan wysoki “1” reprezentuje napięcie około 12V, niski “0” – zbliżone do potencjału masy. Nieco więcej szczegółów można znaleźć w innym moim artykule: Interfejsy OBD i CAN.

Warstwa łącza danych / sieciowa

Od strony topologii, sieć składa się z jednego urządzenia nadrzędnego (master, które inicjuje każde połączenie) oraz wielu urządzeń slave (identyfikowanych adresami z zakresu 1-255). W czasie trwania pojedynczego połączenia tylko jeden slave może być aktywny. Komunikacja między nim, a masterem odbywa się za pomocą kilkubajtowych ramek danych zwanych datagramami.

Warstwa transportowa / sesji

Każdy datagram identyfikowany jest numerem sekwencyjnym oraz identyfikatorem. Określa on jaki rodzaj danych zawiera pakiet. Część z nich może być fragmentowana i podzielona na kilka pakietów.

Warstwa prezentacji

Dane zawarte w pakietach są interpretowane jako: pomiary, kody usterek, informacje o sterowniku, itp.

Warstwa aplikacji

Przechowuje zinterpretowane dane i udostępnia je aplikacjom.

Spróbujmy przełożyć strukturę warstw OSI na szkic architektury podsystemu diagnostyki w projektowanym urządzeniu. Od strony sprzętowej, warstwa fizyczna będzie składać się transceiverów oraz peryferiów procesora (UART, GPIO). Po stronie oprogramowania reprezentować ją będzie driver, zawierający w sobie abstrakcję sprzętu. Zadaniem warstwy fizycznej jest odbieranie i wysyłanie strumieni bajtów – stąd abstrakcyjny interfejs jaki musi zapewnić driver można sprowadzić do dwóch metod: send() oraz receive(). Ze względu na ścisłą współpracę, warstwy łącza danych i sieciowa zostaną umieszczone w jednym bloku, zawierającym właściwą implementację protokołu KWP1281. Interpretowanie danych oraz ich przechowywanie, czyli zadania warstwy prezentacji delegowane są do usługi diagnostyki. Podobnie wszelkie interakcje z zewnętrznymi aplikacjami, obsługa zapytań i udostępnianie danych. Daemon staje się w ten sposób centralnym punktem, przez który przechodzą wszystkie żądania. Dzięki temu można zapewnić dostęp wielu niezależnym klientom do informacji pochodzących z diagnostyki. Z drugiej strony usługa dba o nawiązanie i utrzymanie połączenia, zwalniając z tego obowiązku kod aplikacji.

Jutro zajmiemy się praktyczną implementacją i spróbujemy po raz pierwszy nawiązać połączenie diagnostyczne. Zapraszam 🙂