Розвиток і можливості бортової діагностики OBD для автомобілів

Коли справа доходить до діагностики та усунення несправностей сучасних автомобілів, навряд чи можна обійтися без бортової діагностики (OBD). Але що може зробити OBD і на що слід звернути увагу фахівцю з автомобілів?

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

Електромеханічні системи запалювання («розподільники») і карбюратори не можуть достатньою мірою враховувати ці фактори і не працюють так точно, як повинні, у всіх умовах експлуатації – також внаслідок виробничих допусків. Можливості машинобудування в цій галузі були практично вичерпані до кінця 1970-х років. Однак потім в автомобілі почали впроваджувати все більше електроніки, що дозволило підвищити точність багатьох процесів.

Наприкінці 1960-х років вже з’явилися перші електронні системи впорскування бензину – наприклад, у малопопулярному VW 411 E, – ці авто були оснащені аналоговою технологією та дискретними компонентами, такими як транзистори, діоди, конденсатори та резистори. Вони були «таємницею за сімома печатками» для автомайстерень, оскільки тодішнім механікам не вистачало знань з електроніки та відповідного діагностичного обладнання. Під час пошуку несправностей за допомогою стандартної тодішньої контрольної лампи можна було легко вивести з ладу дорогий блок управління.

Самодіагностика, реалізована в блоці управління, і тестове з’єднання в той час ще не існували.

Навіть перші цифрові блоки управління з інтегральними схемами (IC) або мікроконтролерами (MCU) наприкінці 1970-х років, які визначали час запалювання або кількість впорскування палива на основі попередньо запрограмованих карт, зазвичай не дозволяли автомеханікам або електрикам заглядати в свої «карти». У разі виникнення несправностей, датчики та виконавчі механізми перевірялися традиційним способом, і якщо несправність не виявлялася, відповідний блок управління зрештою замінювався.

Перші кроки до створення блоків управління з можливістю діагностики були зроблені приблизно на початку 1980-х років з впровадженням цифрової електроніки двигуна (DME), тобто комбінованих систем запалювання і впорскування. Практично кожен виробник автомобілів мав спеціальний сервісний роз’єм, «захований» десь в автомобілі, для зчитування даних з блоку управління. Виведення помилки завжди базувалося на фірмовому мигаючому коді, який виводився, наприклад, після замикання двох контактів сервісного роз’єму. Це був практично початок бортової діагностики (OBD), хоча і дуже простий.

Наступним етапом розвитку блоків керування – приблизно з 1986 року – стала передача даних на спеціальні пристрої зчитування та програмування, такі як VAG 1551 і 1552 від Volkswagen або Tech 1 від Opel/GM. За допомогою таких сервісних пристроїв зчитані коди несправностей перетворювалися на зрозумілі текстові повідомлення за допомогою електроніки та дисплеїв. Вони також дозволяли видаляти будь-які коди несправностей і кодувати блоки управління – про це пізніше. У той час кожен виробник мав власні неопубліковані стандарти для інтерфейсів, діагностичних роз’ємів, кодів несправностей і протоколів передачі даних. Volkswagen, наприклад, використовував власний протокол Key Word Protocol (KWP) 1281, а GM/Opel – протокол передачі даних з конвеєра (ALDL). Хоча такий протекціонізм захищав майстерні виробників, він ускладнював або навіть унеможливлював усунення несправностей і технічне обслуговування для незалежних майстерень. Ці бар’єри для конкуренції вдалося обійти лише завдяки законодавчому визначенню OBD як частини подальшого законодавства Європейського Союзу щодо викидів.

OBD, OBD-1, OBD-2 та EOBD

Забезпечення низького рівня викидів вихлопних газів є метою законодавства, що також призвело до появи бортової діагностики. Ще на початку 1970-х років Каліфорнійська рада з повітряних ресурсів (CARB) інтенсивно працювала над законодавчими вимогами щодо скорочення викидів забруднюючих речовин. Передумови: вихлопні гази автомобілів, такі як незгорілі вуглеводні (HC), чадний газ (CO) та оксиди азоту (NOX), спричиняли видимий і відчутний смог у великих містах Каліфорнії та інших регіонах, який був пов’язаний зі значними проблемами зі здоров’ям. CARB послідовно обмежував ці викиди з вихлопної системи, вентиляції картера і вентиляції бензобака в нових моделях автомобілів. В результаті в Каліфорнії також дебютували особливо чисті автомобілі з каталітичним нейтралізатором і лямбда-контролем сумішоутворення.

У Сполучених Штатах не було або практично не існувало періодичних перевірок транспортних засобів випробувальними організаціями, які могли б виявити проблеми з безпекою або системами, пов’язаними з викидами шкідливих речовин. Однак система нейтралізації вихлопних газів може ефективно працювати лише тоді, коли окремі вузли перебувають в оптимальному робочому стані. Саме тому з 1988 року CARB вимагає від виробників транспортних засобів надання спеціально визначеної бортової діагностики (OBD-1). Таким чином, специфічна для виробника OBD була розширена і стандартизована щодо моніторингу компонентів і систем, пов’язаних з викидами. OBD-1 вимагає:

► Простий моніторинг електричних компонентів, що впливають на викиди, та зберігання інформації про будь-які несправності в блоці керування.

► Індикатор на приладовій панелі (Malfunction Indicator Light = MIL), який вказує водієві – або поліції в разі більш-менш випадкової перевірки – на несправність системи.

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

Пізніше CARB визнала, що виробники транспортних засобів почали встановлювати власні роз’єми або діагностичні інтерфейси для свого тестового обладнання, що дозволило проводити більш ретельний аналіз несправностей, ніж за допомогою простого блимаючого коду. З цієї причини в 1994 році з’явився стандарт OBD-2, який передбачає більш широкі законодавчі вимоги. Його особливістю є стандартизований діагностичний роз’єм (так званий роз’єм CARB; далі в тексті для спрощення називається роз’ємом OBD) з 16 контактами.

Окрім призначення контактів, електричні параметри, протоколи передачі, дані та коди помилок також стандартизовані. Крім того, діагностичний роз’єм повинен бути безпосередньо доступний в радіусі одного метра навколо водія і без інструментів.

Основними додатковими вимогами OBD-2 у порівнянні з OBD-1 є

► Безперервне тестування сигналів і компонентів систем, пов’язаних з відпрацьованими газами, на достовірність. Це стосується, наприклад, систем мінімізації викидів випаровування з бака, автоматичної трансмісії та будь-яких систем рециркуляції відпрацьованих газів.

► Кілька автоматичних діагностичних процедур (кодів готовності), які показують, чи всі тести, пов’язані з викидами, були успішно завершені системою управління двигуном за допомогою достатньої кількості перевірок.

Каліфорнійські правила OBD були також введені в 1994 році в інших штатах США федеральним органом EPA (Агентство з охорони навколишнього середовища) як так звані EPA-OBD і по суті відповідають законам CARB. OBD-2 або EPA-OBD стали обов’язковими для нових моделей автомобілів з дизельними двигунами з 1996 року.

У 1998 році Європейський Союз прийняв Директиву ЄС 98/69/ЄС, яка передбачає запровадження європейських БДР (EOBD). EOBD базується на OBD-2, але був адаптований до європейських умов. З січня 2000 року він є обов’язковим для всіх нових моделей транспортних засобів категорії М1 (легкові та вантажні автомобілі до 3,5 т) з бензиновими двигунами. Нові моделі транспортних засобів класу М1 з дизельними двигунами повинні були відповідати вимогам EOBD з січня 2003 року. До речі, введення EOBD не пов’язане безпосередньо з жодними стандартами ЄС щодо викидів.

Для чого потрібен OBD?

Для того, щоб автомобіль відповідав раннім каліфорнійським вимогам OBD-1, в найпростішому випадку йому потрібен був блок управління двигуном з програмним забезпеченням OBD і лампочка попередження про несправності. Починаючи з OBD-2 і EOBD, було додано принаймні одне діагностичне гніздо відповідно до стандарту ISO 15031-3 і додатковий лямбда-датчик.

У той час як зусилля, пов’язані з апаратним забезпеченням, здаються цілком керованими, існує значний обсяг роботи з розробки програмного забезпечення. Наприклад, у сучасних автомобілях частина, пов’язана з OBD-2 або EOBD, становить близько 50 відсотків програмного забезпечення блоку керування двигуном. Діагностична частина тісно пов’язана з програмним забезпеченням двигуна і безперервно контролює всі сигнали датчиків і роботу виконавчих механізмів.

Функції тестування та діагностики активуються тільки тоді, коли виконуються певні умови ввімкнення, наприклад, порогові значення температури двигуна, швидкості та крутного моменту. Також допускається тимчасове вимкнення діагностичних функцій для запобігання помилкових діагнозів, наприклад, у разі низького заряду акумулятора, великої висоти над рівнем моря або дуже низької температури навколишнього середовища під час запуску двигуна.

Система EOBD повинна постійно перевіряти мінімум наступні компоненти:

• Ефективність каталітичного нейтралізатора.
• Ефективність сажового фільтра.
• Лямбда-датчики та будь-який підігрів.
• Система рециркуляції відпрацьованих газів та інші системи зниження викидів при холодному старті.
• Системи зменшення викидів при випаровуванні з бака.
• Згоряння та осічки.
• Функціонування системи SCR для зниження викидів оксидів азоту разом з системою подачі необхідного розчину сечовини (AdBlue).
• Перевірка інших датчиків і виконавчих механізмів, які можуть впливати на поведінку вихлопних газів або на тести OBD.

Приклади функціонування окремих OBD-тестів:

Діагностика каталітичного нейтралізатора

Каталітичний нейтралізатор призначений для перетворення шкідливих вихлопних газів у нешкідливі шляхом окислення та відновлення. Правильне співвідношення повітря-паливо, яке регулюється первинним лямбда-зондом, відіграє центральну роль у хімічних реакціях в каталітичному нейтралізаторі.

Кисень з оксидів азоту (NOX) для окислення вуглеводнів (HC до H2O і CO2) і оксиду вуглецю (CO до CO2) зберігається і вивільняється в матеріалі каталітичного нейтралізатора (покриття між носієм каталізатора і металами каталізатора). Ця накопичувальна здатність є робочою характеристикою каталітичного нейтралізатора і може бути оцінена шляхом порівняння кривих напруги первинного і вторинного лямбда-зондів. Старий або зіпсований каталітичний нейтралізатор має низьку здатність накопичувати кисень і, отже, погано перетворює шкідливі вихлопні гази.

Діагностика сажового фільтра

Значення датчика диференціального тиску аналізуються в залежності від об’ємного потоку вихлопних газів. Якщо сажовий фільтр несправний, засмічений або знятий, різниця тиску відхиляється від очікуваних значень і виводиться як помилка.

Діагностика лямбда-зондів

Значення напруги на датчиках порівнюються з очікуваними значеннями блоку керування (перевірка достовірності). Також здійснюється електричний контроль на наявність короткого замикання на землю та обриву. Нагрівання датчиків також перевіряється електричним способом за споживаним струмом.

Діагностика системи рециркуляції відпрацьованих газів (EGR)

Функціонування клапана EGR зазвичай визначається можливим відхиленням регулювання регулятора положення і повітряної маси. За наявності охолоджувача рециркуляції відпрацьованих газів вимірюється температура за охолоджувачем і порівнюється з заданими значеннями.

Діагностика системи впорскування вторинного повітря

Впорскування вторинного повітря можна перевірити за допомогою електричних параметрів, таких як споживання струму, коротке замикання на землю та обрив ланцюга.

Діагностика системи вентиляції бака Відкриття електричного клапана для промивання бака з активованим вугіллям системи вентиляції бака у впускному колекторі двигуна впливає на значення лямбда-зонда сумішоутворення. Цей ефект може бути інтерпретований блоком керування двигуном для перевірки його функціонування.

Простіші тести визначають електричні параметри, такі як споживання струму, коротке замикання на землю та обрив ланцюга. Більш складні тести працюють за допомогою датчика тиску в баку і, отже, також дозволяють виявляти витоки. Такі системи є обов’язковими, наприклад, у США (OBD-2 або EPA-OBD).

Діагностика системи вторинного повітропостачання

Функціонування системи вторинного повітропостачання можна перевірити за допомогою електричних параметрів, таких як споживання струму, коротке замикання на масу та обрив ланцюга.

Діагностика системи вентиляції бака

Відкриття електричного клапана для промивання ємності з активованим вугіллям системи вентиляції бака у впускному колекторі двигуна впливає на значення лямбда-зонда сумішоутворення. Цей ефект може бути інтерпретований блоком керування двигуном для перевірки його функціонування.

Простіші тести визначають електричні параметри, такі як споживання струму, коротке замикання на землю та обрив ланцюга. Більш складні тести працюють за допомогою датчика тиску в баку і, отже, також дозволяють виявляти витоки. Такі системи є обов’язковими, наприклад, у США (OBD-2 або EPA-OBD).

Діагностика згоряння і пропусків запалювання

Несправність циліндра супроводжується погіршенням рівномірності обертання колінчастого валу, двигун працює «не рівно». Різне кутове прискорення розпізнається блоком керування за допомогою датчика швидкості і співвідноситься з відповідним циліндром. Починаючи з певної кількості осічок, впорскування деактивується циліндрово-селективно, щоб захистити каталітичний нейтралізатор від перегріву.

Діагностика системи SCR

Датчик NOX використовується для визначення ефективності роботи відновлювального каталітичного нейтралізатора з метою контролю роботи системи SCR в рамках діагностики EOBD. Значення, виміряне датчиком, порівнюється з моделлю розрахунку оксидів азоту в блоці керування двигуном, і в разі необхідності видається повідомлення про помилки.

Для систем SCR з реагентом AdBlue, законодавство вимагає моніторингу рівня заповнення AdBlue та його якості. Якість реагенту визначається за допомогою датчика шляхом визначення діелектричних властивостей.

Діагностика інших датчиків і виконавчих механізмів

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

Приводи також зазвичай тестуються шляхом аналізу споживання струму та очікуваного ефекту по відношенню до виміряних значень датчиків в розрахунковій моделі блоку управління двигуном. Крім того, процесори, а також програмна і розрахункова пам’ять блоку керування тестуються за допомогою тестових розрахунків і контрольних сум. Також перевіряється зв’язок за допомогою з’єднання для передачі даних (наприклад, CAN-шини) між декількома блоками керування.

Зберігання та видалення помилок

Неправдоподібні сигнали датчиків класифікуються як недійсні або як помилки лише через певний проміжок часу. До закінчення цього часу система використовує останнє вірогідне значення. Після класифікації дефектів система виконує розрахунки з постійно збереженими запасними значеннями, наприклад, з температурою охолоджувальної рідини 95 градусів за Цельсієм для несправного датчика температури. Якщо ймовірно несправний датчик знову подає правдоподібні сигнали, система може переключитися із значення-замінника на поточне значення датчика через певний час.

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

На додаток до зберігання даних про несправності, індикатор несправності (MIL) активується в залежності від актуальності та частоти несправності, щоб водій міг негайно звернутися на станцію технічного обслуговування. Для транспортних засобів, що відповідають специфікаціям EOBD, індикатор несправності MIL повинен вмикатися не пізніше третього циклу руху, в якому було виявлено несправність. Якщо несправність знову зникає, MIL знову вимикається після трьох циклів руху, але запис про несправність залишається в пам’яті блоку керування ще протягом 40 поїздок (цикли прогріву). У разі особливо серйозних несправностей, таких як пропуски або неправильне спрацьовування, які можуть призвести до незворотного пошкодження каталітичного нейтралізатора, індикатор MIL починає блимати. Водій також може відчути «деактивацію циліндрів» через втрату потужності двигуна.

Водій також стикається з втратою потужності, коли блок керування двигуном активує функцію аварійного режиму роботи. Наприклад, якщо система контролю детонації виходить з ладу і кут запалювання знижується до нешкідливих запасних значень. Аварійна робота призначена для запобігання впливу несправності на безпеку руху, викиди вихлопних газів або подальші пошкодження.

Видалення збережених несправностей з блоку керування можливе за допомогою практично будь-якого інструменту для сканування OBD або тестового пристрою для майстерні. Щоб уникнути обману перед перевіркою викидів або основною перевіркою, коди готовності контрольованих компонентів у блоці керування скидаються. Коди готовності вводяться в блок керування тільки після завершення всіх функцій самодіагностики в досить тривалих поїздках.

16 контактів стандартизованого роз’єму OBD

Більшість автомобілів на дорогах по всьому світу, ймовірно, обладнані роз’ємом OBD відповідно до стандартів OBD-2 або ISO 15031-3.

Цей стандарт ISO також визначає призначення контактів для передачі даних на PIN #2 і PIN #10, заземлення на PIN #4 і 12 вольт на PIN #16, протокол зв’язку відповідно до стандарту ISO 15031-1 і стандартизацію інформації, що зчитується з пам’яті несправностей відповідно до стандарту ISO 15031-5, а також кодування несправностей відповідно до стандарту ISO 15031-6. Технічні характеристики сканерів можна знайти в стандарті ISO 15031-4. Деякі виробники мотоциклів використовують три-, чотири- або шестиконтактні OBD-кабелі, які можна підключити до 16-контактного стандартного роз’єму тестового пристрою за допомогою адаптера.

Деякі старі моделі автомобілів у цій країні також здатні підтримувати цей зв’язок ISO, оскільки виробники транспортних засобів рідко випускають додаткові варіанти блоків управління для різних країн з міркувань вартості.

У Європі при визначенні EOBD законодавство базувалося на американських специфікаціях. Деякі вимоги були пом’якшені, інші – посилені. Протокол зв’язку був визначений у стандарті DIN ISO 9141-2. Призначення контактів для передачі даних було визначено тут як PIN #7 і PIN #15. Це пряме з’єднання з блоком управління також відоме як K-Line і L-Line, яке Volkswagen, наприклад, також використовує для свого фірмового протоколу ключових слів (KWP) 1281 для діагностики автомобіля (тобто не для OBD-2 або EOBD). KWP2000 був визначений в стандарті ISO 14230 як загальний, незалежний від виробника діагностичний протокол (знову ж таки, не для OBD-2 або EOBD) для цієї двонаправленої шини.

Шина CAN

Технічний розвиток автомобілів призвів до появи більшої кількості блоків керування (таких як ABS, ESP, подушки безпеки, управління трансмісією, системи допомоги водієві), які, природно, також залежать від живого, надійного та швидкого обміну даними між собою. З цією метою Bosch розробив мережу Controller Area Network (CAN), яка в 1990-х роках все частіше з’являлася в нових моделях автомобілів.

Як логічний наслідок, гніздо OBD з PIN-кодом №6 (CAN High) і PIN-кодом №14 (CAN Low) також було підключено до цієї мережі через діагностичний шлюз. Стандарт ISO 15765 визначає діагностичні сервіси та елементи транспортного протоколу (Diagnostic communication over Controller Area Network = DoCAN). З 2007 року нові моделі в США повинні були надавати дані OBD-2 через CAN.

В 2006 році для потужного транспортного протоколу CAN стандартом ISO 14229 було визначено стандартизацію різних діагностичних протоколів виробників транспортних засобів в Єдину діагностичну службу (UDS), не в останню чергу для того, щоб гармонізувати зусилля з програмування та випробувального обладнання для розробки та обслуговування транспортних засобів. Але навіть в UDS виробники транспортних засобів все ще знаходять достатньо місця для власних рішень, так що оригінальне діагностичне обладнання виробника транспортного засобу від виробника X не завжди працює з виробником Y.

Легальна OBD також зазнала подальшого розвитку і стандартизації протягом багатьох років завдяки ISO 27145 і відома серед експертів як «Всесвітня гармонізована бортова діагностика» (World Wide Harmonised On-Board Diagnostics, WWH-OBD). У той же час, аспекти бездротових технологій і об’єднання компонентів транспортного засобу в мережу через Ethernet також були включені в цей стандарт.

Приблизно з 2016 року з’явилися перші моделі автомобілів з новою, знову ж таки більш потужною мережею Ethernet. Це особливий подальший розвиток мережевої технології LAN, знайомої в компаніях і домогосподарствах. Для транспортних засобів мережева технологія визначена в стандарті ISO 13400 і має назву «Діагностичний зв’язок через Інтернет-протокол» (DoIP). Ця технологія вимагає наявності чотирьох полюсів на гнізді OBD: PIN #3, PIN #11, PIN #12 і PIN #13. PIN #8, PIN #9, PIN #12 і PIN #13 використовуються дещо рідше.

При підключенні IP-мережі через діагностичний роз’єм або бездротові мережі (5G, WLAN) необхідно вживати заходів безпеки, щоб запобігти зловмисним атакам. Особливо у випадку з автономними транспортними засобами, не повинно бути ніяких зовнішніх втручань.

Захист і безпека даних

Кібербезпека стала дуже важливою темою у всіх сферах нашого підключеного світу. Навіть без бездротового підключення до мережі бортова електроніка автомобіля вже давно стала об’єктом злочинних посягань. У багатьох випадках діагностичний роз’єм OBD використовувався, наприклад, для деактивації іммобілайзерів або маніпуляцій з показаннями пробігу.

Довгий час виробники транспортних засобів і законодавці більш-менш ігнорували цю діяльність. Можливо, лише дослідження 2015 року, в якому двом хакерам вдалося дистанційно керувати автомобілем Jeep Cherokee через Wi-Fi з’єднання, змусило відповідальних осіб прокинутися. Виробник автомобіля, тоді Fiat Chrysler Group (FCA), зміг відносно швидко закрити прогалину в системі безпеки, оновивши програмне забезпечення. FCA (Stellantis з січня 2021 року) також стала першим виробником, який оснастив свої нові моделі шлюзом безпеки приблизно з 2018 року. Нові моделі Mercedes-Benz, Volkswagen Group, Kia, Hyundai, Nissan і Renault тепер також захищені таким чином. Це також пов’язано з новими законами, які вимагають, щоб транспортні засоби були захищені. Для повноти картини слід згадати Рекомендацію ЄЕК ООН R 155, яка вимагає від виробників транспортних засобів мати систему управління кібербезпекою (CSMS).

Таким чином, доступ до блоків керування через діагностичний роз’єм OBD був різко обмежений. Доступними залишаються тільки передбачені законом системи OBD-2 або EOBD і доступ для читання некритичних даних фірмової діагностики виробника через KWP2000 або UDS. Для будь-якого доступу на запис, наприклад, видалення кодів несправностей виробника або сервісних скидань, діагностичний пристрій повинен бути авторизований за допомогою цифрового ключа (захищений доступ). Зазвичай для цього використовується процедура seed-and-key: діагностичний прилад запитує так званий seed від блоку керування – так би мовити, випадкове число. Потім блок керування очікує від діагностичного тестера ключ, який обчислюється за допомогою секретного алгоритму. Блок управління дозволяє доступ, якщо ключ збігається з ключем, обчисленим блоком управління за тим самим алгоритмом. Інші ключові запити можуть бути додані для встановлення оновлень програмного забезпечення або аналізу даних на більш глибоких рівнях блоку управління.

З міркувань безпеки алгоритм обчислення ключа не знаходиться безпосередньо в тестері майстерні – на випадок, якщо він потрапить до рук сторонніх осіб, – а завжди надається центром обробки даних виробника через онлайн-з’єднання. Погана новина для незалежних майстерень: практично кожен виробник транспортних засобів має свій власний стандарт безпеки, що добре охороняється, наприклад, сертифікати та токени, які працюють подібно до процедури seed-and-key, і вимагають широкої персональної акредитації від кожної майстерні, яка бажає взяти в ній участь.

Зараз існують альтернативні процедури доступу для незалежних майстерень: наприклад, Hella Gutmann розробила систему управління кібербезпекою (CSM), яка діє як інтерфейс до серверів різних виробників транспортних засобів.

Основна перевага CSM: замість того, щоб реєструватися окремо у кожного виробника транспортних засобів і підтверджувати різні вимоги для отримання дозволів на діагностику, клієнтам Hella-Gutmann достатньо однієї аутентифікації в CSM.

Pass Thru 

Іншим способом доступу до блоків керування є «Pass Thru». Цей термін базується на законодавчих вимогах і стандартах (ISO 22920 і SAE J2534), які передбачають і описують недискримінаційний доступ для незалежних майстерень. Для цього незалежній майстерні потрібні чотири речі: адаптер Pass-Thru (від 500 до 1000 євро), наявний у продажу стандартний ПК/ноутбук, платний дозвіл на доступ або акредитація (близько 100 євро/рік) на відповідному порталі виробника транспортного засобу, а також потужний і надійно стабільний доступ до Інтернету.

Це працює так: користувач завантажує власне програмне забезпечення від одного або декількох виробників транспортних засобів та встановлює його на свій ПК/ноутбук. Адаптер Pass-Thru підключається до ПК/ноутбука за допомогою USB, Bluetooth або USB-кабелю, встановлюються драйвери, які забезпечують стандартизований програмний інтерфейс (Application Program Interface = API), до якого може отримати доступ програмне забезпечення виробника транспортного засобу. Нарешті, адаптер Pass-Thru підключається до роз’єму OBD автомобіля. Залежно від специфікацій виробника та дозволу безпеки, програмне забезпечення можна використовувати для зчитування та видалення записів пам’яті несправностей, кодування та оновлення програмного забезпечення блоків керування.

Однак Pass Thru не є ідеальним рішенням для незалежних майстерень: крім відносно високих витрат, може виникнути несумісність між програмними системами різних виробників, якщо вони встановлені на ПК/ноутбуці одночасно. Саме тому за підтримки компаній ZDK, ZKF та ADIS-Technology було розроблено спеціальне мультибрендове рішення «EuroDFT» на спеціально сконфігурованому ноутбуці для незалежних майстерень.

Це дозволяє проводити діагностичні та програмні роботи на різних моделях близько 16 марок автомобілів.

ADIS-технологія пропонує ще одне цікаве мультибрендове рішення під назвою «DFT Direct», яке базується на віддаленому інтернет-з’єднанні між автомобілем клієнта, OBD або VCI адаптером, стандартним ноутбуком і сервером провайдера. Для DFT Direct не потрібно встановлювати на ноутбук спеціальне діагностичне програмне забезпечення. Технік з сервісного центру постачальника послуг під’єднується до ноутбука майстерні за допомогою дистанційного з’єднання, а потім підключає до автомобіля відповідне діагностичне програмне забезпечення виробника. Крім діагностики, DFT Direct також можна використовувати для кодування та програмування електронних блоків управління.

Інструменти для сканування OBD

Асортимент простих портативних інструментів для діагностики OBD, доступних у відповідних інтернет-магазинах, магазинах «зроби сам» і супермаркетах, орієнтований не стільки на професіоналів в області автотранспорту, скільки на механіків-любителів. Такі пристрої коштують від трохи менше 30 до близько 100 євро і зазвичай можуть зчитувати лише законодавчо визначені несправності OBD 2 і EOBD та видаляти будь-які збережені несправності. Якщо вам пощастить або ви вивчите ринок, ви можете придбати пристрій, який не тільки відображає загадкові коди OBD, такі як «P0420», але надає описовий текст , наприклад, «Ефективність роботи каталізатора».

У дешевих далекосхідних продуктах набір даних OBD-2 або EODB, такі як поточні робочі дані (наприклад, температура охолоджуючої рідини, частота обертання двигуна), дані стоп-кадру (діагностичні дані на момент несправності) і тестові значення лямбда-зонда (значення напруги, що подається зондом), часто залишаються прихованими від користувача. Для інструментів OBD-діагностики з відповідною глибиною діагностики користувачеві зазвичай доводиться трохи глибше заглядати в кишеню.

Для того, щоб мати змогу використовувати практично всі можливості OBD-2 або EODB, програмне забезпечення, придатне для ПК/ноутбуків, доступне від різних постачальників, наприклад, «moDiag» від Sortima. Разом з USB-адаптером для гнізда OBD це коштує від 100 до 300 євро, залежно від обсягу функцій.

Повернемося до професійних додатків: Програмне забезпечення «VCDS» і адаптер від виробника Ross-Tech є важливою віхою в області діагностики на рівні виробника.

Це означає, що практично всі функції технічного обслуговування, діагностики та кодування майже всіх моделей VW Group можливі, як і за допомогою оригінального обладнання для майстерні. Однак тільки в тому випадку, якщо автомобіль не захищений «Шлюзом безпеки». Аналогічні спеціальні рішення також доступні для різних інших виробників і марок.

Тим часом, незалежні майстерні або амбітні механіки-любителі не повинні відмовлятися від моделей Tesla. Професіоналів може зацікавити «LOKI» від PCI Diagnosetechnik.

Для механіків-любителів варто згадати «Scan My Tesla» та «TM-Spy», щоб картина була цілісною. Основні постачальники діагностичних систем (Hella Gutmann та ін.) зараз також пропонують підтримку моделей Tesla, хоча вона все ще обмежена. Для автомобілів Tesla без роз’єму OBD готові комплекти для модернізації доступні у відповідних постачальників в Інтернеті.

Аксесуари для OBD

Додатки для смартфонів, такі як «Carly», які встановлюють бездротове з’єднання через Bluetooth-ключ для роз’єму OBD, знаходяться в дещо іншій лізі. Окрім досить обмеженої підтримки протоколів OBD-2 та EODB, основна увага приділяється функціям технічного обслуговування, кодування та діагностики, а також графічному аналізу даних, що залежать від виробника транспортного засобу.

У цьому контексті варто також згадати технічно схоже рішення «DataPlug» від VW. За близько 40 євро водій VW отримує інформацію про пробіг, напругу акумулятора, рівень палива і останнє місцезнаходження автомобіля в поєднанні з додатком для смартфона, але без OBD, кодування і діагностичних функцій для пошуку і усунення несправностей.

WLAN-ключі для гнізда OBD пропонуються різними мобільними операторами, але вони видаються сумнівними. Вони в основному функціонують як точка доступу до бездротової мережі, але, як і VW DataPlug, вони також призначені для надання користувачеві даних та аналітики через додаток. Звісно, умови прийому мобільного зв’язку в просторі для ніг досить несприятливі, а WLAN-ключі досить громіздкі, що може спричинити проблеми. Застереження щодо безпеки слід враховувати для всіх рішень з адаптерами та ключами з функцією радіозв’язку, таких як Bluetooth, WLAN і мобільний зв’язок стандарту GSM. Зовнішні атаки на мережу транспортного засобу, такі як злом Jeep Cherokee, повинні бути надійно виключені. Крім того, дані про транспортний засіб та його рух у хмарі (сховище даних у зовнішній комп’ютерній мережі) завжди повинні розглядатися критично з міркувань захисту даних.

Згідно з розслідуванням комп’ютерного журналу c’t, донгли для роз’єму OBD, які мають зменшити споживання палива або підвищити потужність двигуна, є нісенітницею. Аналіз не виявив жодного зв’язку між досліджуваними ключами та лініями передачі даних роз’єму OBD.

Люди з кримінальною енергією також використовують широкі можливості доступу до майже всіх блоків керування автомобілем через роз’єм OBD. Пристрої для деактивації іммобілайзера, маніпуляцій з пробігом або скидання блоків управління подушок безпеки, що спрацювали, доступні вже багато років. Корисним є так званий «OBD Saver», який може перешкодити викрадачам автомобілів запрограмувати іммобілайзер, механічно запечатавши роз’єм OBD загартованою захисною пластиною.

Гніздо OBD для основної перевірки згідно з § 29 StVZO

Приблизно з 2012 року випробувальні організації переслідують добрі наміри, використовуючи гніздо OBD як частину основного техогляду відповідно до § 29 StVZO. За допомогою «адаптера HU» інспектор може спочатку зчитати номер шасі і за допомогою програмного забезпечення та бази даних Fahrzeugsystemdaten GmbH (FSD = державний уповноважений орган відповідно до Закону про дорожній рух) з’ясувати тип транспортного засобу, стан технічного обладнання (так званий список оснащення) та важливу інформацію про перевірку.

Адаптер HU можна використовувати для перевірки встановлених на заводі або передбачених систем безпеки і зниження викидів на наявність і будь-які коди несправностей в пам’яті подій. Крім того, інспектор може активувати світло систем освітлення, наприклад, за допомогою пульта дистанційного керування, що може полегшити роботу.

Адаптер HU також може бути корисним для електромобілів у майбутньому, наприклад, для виявлення дефектів безпеки в системі рекуперативного гальмування або ізоляції високовольтної системи.

З 20 травня 2023 року випробувальні організації також візьмуть на себе нове завдання в рамках ТО: дані бортового моніторингу споживання палива (OBFCM) повинні будуть зчитуватися з представлених транспортних засобів за допомогою адаптера HU через роз’єм OBD. Відповідно до Регламенту ЄС 2017/1151, з 1 січня 2021 року транспортні засоби повинні визначати та постійно зберігати дані про споживання енергії. Європейське агентство з навколишнього середовища (EEA) зацікавлене в цих даних, щоб перевірити достовірність значень споживання вуглекислого газу, палива та електроенергії, визначених і опублікованих для затвердження типу.

OBD для розробки та обслуговування

Як і в повсякденному житті майстерні, багатство даних з різних блоків управління також стало незамінним для розробки та післяпродажного обслуговування автовиробником. Сучасні автомобілі вже давно перестали бути «рухомими комп’ютерами», а скоріше рухомим центром обробки даних з декількома комп’ютерами, об’єднаними в мережу. Над розробкою автомобільної електроніки зараз працюють багато сотень співробітників, які співпрацюють не лише з виробником автомобіля, але й з різними постачальниками. Навіть якщо зв’язок між блоками управління детально описаний, помилки зв’язку «запрограмовані».

Тому під час тестування нових автомобілів дуже важливо витягувати, зберігати та аналізувати дані шини даних і пам’яті несправностей. Для цього використовуються спеціальні інструменти, які підключаються до автомобіля через роз’єм OBD. Як і для загальної діагностики автомобіля, це протокол Key Word Protocol 2000 (KWP2000) і все частіше Unified Diagnostic Services (UDS) як стандартизовані протоколи зв’язку.

Сучасні системи розробки базуються на стандартах ISO ODX (Open Diagnostic Data Exchange, ISO 22901) та мові програмування OTX (Open Test Sequence Exchange, ISO 13209). ODX можна використовувати для визначення та опису всієї мережі автомобіля під час розробки. OTX – це формат опису виконуваних і автоматизованих тестових послідовностей, таких як системні тести або керований пошук несправностей. Таким чином, він доповнює формат ODX, який описує релевантні для діагностики сервіси і дані ECU, а також використовує для цієї мети формат даних XML.

Передача даних по повітрю

Розвиток безпечних і високопродуктивних з’єднань для передачі даних вже давно став необхідним. 

Це стосується не лише сучасних автомобілів, але особливо безпілотних автомобілів, зв’язку між автомобілями та хмарних технологій. Автомобілі стають частиною інтернету, надсилаючи і отримуючи дані та оновлення програмного забезпечення через бездротовий інтерфейс, такий як мобільна мережа 4G/LTE, а незабаром і 5G. Бездротове оновлення по повітрю (OTA = on the air) може запропонувати клієнту більшу безпеку завдяки швидшому виправленню помилок програмного забезпечення, більшу зручність і кращу інформаційно-розважальну систему завдяки додатковим функціям. А для оновлення програмного забезпечення за допомогою OTA клієнту не потрібно додатково їхати до майстерні. За допомогою правила R 156 Європейська економічна комісія (ЄЕК ООН) запровадила всеосяжний набір правил для оновлення програмного забезпечення блоків керування, щоб забезпечити безпеку транспортних засобів.

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

Однак майстерні та діагностичні тестери продовжуватимуть існувати, як і роз’єм OBD, щоб забезпечити недискримінаційний доступ для незалежних майстерень, тестерів та організацій, що надають допомогу на дорогах. До речі, нові моделі Tesla тепер також поставляються з роз’ємом OBD.

В продовження теми: