OBD Car Doctor - історія розробки мобільних додатків

Ідея під’єднати смартфон до бортової системи машини виникла давно, а своєрідним поштовхом послугувала стаття про електронну начинку сучасних авто та CAN-шину, що забезпечує обмін даними між різними пристроями, під’єднаними до цієї шини.

Дослідження можливих способів під’єднання до авто показало, що для під’єднання потрібно використовувати діагностичний роз’єм DLC – Data Link Connector, який слугує для з’єднання бортової мережі авто з діагностичними сканерами та опитування/знімання даних з різних підсистем автомобіля. Проблема великої кількості та різноманітності марок авто, сканерів, конекторів була вирішена завдяки одному з екологічних відомств США – California Air Resources Board – CARB, яке відповідає за контроль викидів автомобілів. Сьогодні актуальним є звід стандартів OBD-II, який описує механічні (форма та розмір роз’єму), електричні (живлення, сигнальні протоколи) та логічні (інформаційні протоколи) рівні сумісності. Тут слід звернути увагу, що відповідність одному з параметрів ще не гарантує відповідності іншим. Тобто наявність правильного механічного роз’єму в автомобілі не гарантує відповідності стандарту сигнальних і логічних протоколів, тобто не обов’язково забезпечує відповідність OBD-II стандарту. Розглянемо вищезгадані рівні сумісності:

Механічно це трапецієподібний роз’єм фіксованого розміру з 16 контактами.
На електричному рівні підтримуються 5 основних сигнальних протоколів:

– SAE J1850 PWM

– SAE J1850 VPW

– ISO 9141-2

– ISO 14230 KWP2000

– ISO 15765 CAN

Логічний рівень передбачає надсилання повідомлень заданої структури і відповідно отримання структурованої відповіді. Пакет складається із заголовка, тіла повідомлення, контрольної суми <header><body><crc>.

Розглянемо структуру тіла запиту

Структура <body> представляється як <mode><pid>.

<mode> (1 байт) визначає функціональну групу параметрів, наприклад 01 – параметри реального часу, 02 – «знімки» параметрів на момент виникнення помилки тощо.
<pid>(1 або 2 байти) — Parameter ID, ідентифікатор запитуваного параметра в контексті групи, наприклад для mode 01 pid 0D відповідає за поточне значення швидкості автомобіля.

Наприклад, 68 6C F1 01 0D A6, где header = 68 6C F1, body = 01 0D, crc = A6.

Структура тіла відповіді містить код повернення:

для позитивної відповіді <mode+0x40>< pid >
для інформації про помилку 7F<pid | mode>
потім, власне, повернуте значення <header><body><crc>.

Наприклад, 48 6B 10 41 0D 00 11, де header = 48 6B 10, body = 41 0D 00, crc = 11, тобто, власне, повернуте значення 00

У результаті, ми отримуємо набір команд, охоплених стандартом, при цьому різні моделі машин підтримують невелику частину цього списку. Окрім того, OBD-II стандарт передбачає наявність користувацьких команд, специфічних для певних виробників і моделей, проте публічна інформація щодо цих команд практично відсутня.

Підбиваємо підсумки. Ми отримали список параметрів, які описані стандартом і які, за умови підтримки з боку автомобіля, можна прочитати. Зазвичай це динамічні параметри, які можна відстежувати в реальному часі (швидкість, оберти, температура, параметри з лямбда-датчиків, параметри, за якими можна обчислити витрату пального, тощо); помилки, які призводять до ввімкнення індикатора CheckEngine; деякі результати самодіагностики бортових систем авто. Також може підтримуватися команда скидання інформації про помилки. Також, гіпотетично можливо дістатися до призначених для користувача параметрів автомобіля, список яких набагато більший за стандартний. Цією статтею ми починаємо цикл нотаток про розробку програм і додатків для автомобілістів.

Детальну статтю, а також її продовження можна прочитати у блозі нашої компанії.