Використання електричних підписів повідомлень шини CAN для зворотного проектування автомобілів

Квіглі, Д. Чарльз, Р. Маклафлін

Warwick Control Technologies

 

 

Анотація

Існує багато програм, у яких вам може знадобитися зворотне проектування мережі контролера (CAN), наприклад:

• Аналіз автомобільних конкурентів;

• Телематичні програми, такі як керування автопарком;

• Відключені програми драйвера.

Типовий процес зворотного проектування пов’язаний із переміщенням датчика та спостереженням за зміною повідомлень на шині CAN. Наприклад, опустіть дверне вікно та подивіться, чи це призведе до змін у даних повідомлення CAN.

Багато шин CAN мають багато повідомлень, що надходять від багатьох електронних блоків керування (ECU). Це означає, що важко переглядати їх усіх одночасно. Було б набагато простіше, якби ви могли просто спостерігати за меншою кількістю повідомлень CAN, щоб спостерігати за змінами, ізолюючи ECU, з яких надходять повідомлення.

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

Метод для визначення того, які ідентифікатори надходять від конкретного ECU, полягає в тому, щоб спочатку отримати графіки електричного підпису відомих діагностичних відповідей і порівняти з графіком електричного підпису повідомлень керування в реальному часі. Ми показуємо, як цього досягти за допомогою інструменту X-Analyser від Warwick Control у поєднанні з комп’ютерним осцилографом PicoScope та USB-інтерфейсом Kvaser CAN.

Цей документ вимагає попередніх базових знань про роботу технології шини CAN.

 

 

Зміст

1. Що таке електричний підпис повідомлення CAN.

2. Створення електричного підпису для кожного кадру CAN.

3. Практичний приклад – Реверсивне проектування автомобілів – Методологія ідентифікації передавального ECU.

4. Висновок.

 

 

Що таке електричний підпис повідомлення CAN

Електричний підпис повідомлення CAN є унікальним у будь-якому повідомленні, яке надсилає ECU. Тому ви очікуєте, що всі повідомлення, що передаються ECU, матимуть однакові електричні характеристики. Наприклад, повідомлення CAN, що складається з напруги CAN High і CAN Low (CAN_H і CAN_L), має показувати щось унікальне для кожного ECU через фізичну структуру шини CAN (наприклад, положення вузла та відстань на шині).

На малюнку 1 показано різні поля, які складають кадр CAN. Через природу методу доступу CAN на основі конкуренції арбітражне поле (CAN ID) не слід розглядати для електричного підпису, оскільки в цьому полі може бути кілька ECU, які спілкуються між собою і, таким чином, впливають на електричний сигнал.

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

Малюнок 1. Конструкція рами CAN

 

Щоб проілюструвати унікальні електричні характеристики кожного ECU в транспортному засобі, на рисунках 2 і 3 нижче показані невеликі відмінності в напрузі CAN_H і CAN_L для двох різних ECU сучасного легкового автомобіля. Вони називаються ECU A та ECU B.

Малюнок 2 ECU A – Електричні характеристики

 

Малюнок 3 ECU B – Електричні характеристики

Можна побачити, що рівні напруги CAN_H і CAN_L для повідомлень цих двох ECU відрізняються.

 

 

Створення електричного підпису для кожного кадру CAN

Методологія, яка розглядається під час збору електричного підпису для кожного повідомлення CAN, що дозволяє нам визначити ECU, з якого воно надходить, полягає в розгляді значень напруги CAN_H і CAN_L для зв’язування повідомлень з ECU.

 

Метод – Аналіз напруги CAN_H проти CAN_L

Процес:

• Зареєструйте один приклад трасування осцилографа кожного повідомлення CAN
• Ізолюйте лише поле даних
• Поділ бітів поля даних на домінантні (логіка 0) і рецесивні (логіка 1)
• Обчислити модальне середнє значення рівнів напруги CAN_H і CAN_L лише для домінуючих бітів

Тепер дані готові для кластерних графіків.

 

Приклад у X-Analyser

На малюнку 4 показано відображення в X-Analyser з використанням інтерфейсу PicoScope. Тут ви можете побачити, що кадри CAN реєструються у верхній половині дисплея. Вибрано (виділено) один із кадрів CAN, і фізична сигналізація цього кадру відображається в нижній частині дисплея. Зверніть увагу, що з цього ми можемо зібрати рівні напруги домінуючих бітів у полі даних (CAN_H, CAN_L).

Малюнок 4 Виділення кадру CAN на дисплеї PicoScope

 

Ці осцилограми можна експортувати як файл Excel, щоб показати показання кадру CAN у точці зразка. Це робиться в X-Analyser за допомогою кнопки «Експортувати кадр», щоб експортувати вибраний кадр, і за допомогою кнопки «Експортувати все», щоб експортувати весь кадр із цієї колекції. Приклад даних, які експортуються, показано на рисунку 5.

Малюнок 5 Приклад даних Excel, експортованих для розширеного кадру CAN

 

Інформація, надана у файлі Excel:

• Ідентифікатор кадру (шістнадцятковий)
• DLC
• Дані (байти в шістнадцятковій системі)
• Кадр помилки (істинне чи хибне) (хибне, якщо кадр CAN справний)
• Зразків за секунду
• Експортовано (дата)
• Час (вибірка для цього кадру, починається з нуля)
• Напруги CAN-H і CAN-L
• Назва регіону (регіон кадру, у якому відображаються дані)
• Додаткова область (показує, де відбувається вставка бітів)

Після експорту цієї інформації в Excel ми можемо обчислити точки кластера за допомогою методу, який бере модальне середнє значення напруг CAN_H і CAN_L з поля даних (лише домінантні біти).

 

Аналіз і кластеризація даних

Дані аналізуються шляхом запису рівнів напруги домінантних бітів CAN_H і CAN_L у полі даних і отримання єдиного модального середнього показника для CAN_H і CAN_L. Потім їх можна помістити на графік кластера, щоб можна було спостерігати кластеризацію повідомлень CAN від конкретного ECU.

У прикладі нижче показано методи збору даних і процес, який використовується для побудови кластерів ідентифікаторів CAN на основі модальних середніх значень Excel. Це дозволяє досліднику/інженеру з'ясувати, з яких блоків керування в реальному часі надходять повідомлення CAN.

 

 

Практичний приклад – Реверсивне проектування автомобілів – Методологія ідентифікації передавального ECU

Основою цієї методології є те, що кожен ECU на шині CAN демонструватиме власні унікальні електронні характеристики, на які впливають такі аспекти, як його електричні компоненти та допуски, трансивер CAN, характеристики роз’єму та розташування в шині CAN. Тому це можна використовувати для зіставлення невідомих кадрів CAN з відомими кадрами CAN. В автомобільній промисловості повідомлення CAN керування в режимі реального часу є запатентованими. Однак діагностичні повідомлення ідентифікаторів, які використовуються для виробничих і сервісних гаражів, стандартизовані в таких специфікаціях, як ISO15765 [1] та/або між виробниками автомобілів.

Добре відомо, що багато транспортних засобів, які використовують стандартні ідентифікатори CAN, роблять діагностичний запит до контролера двигуна з використанням ідентифікатора CAN 0x7E0, і контролер двигуна відповідає на ідентифікатор CAN 0x7E8.

Таким чином, короткий виклад методології описується такими кроками:

• Надсилати діагностичні запити
• Отримайте підписи всіх відповідей і повідомлень у реальному часі
• Проаналізуйте та нанесіть дані на кластерну діаграму

 

 

Налаштування обладнання для зворотного проектування на автомобілі

На рисунку 6 нижче показано приклад налаштування обладнання з використанням X-Analyser, підключеного до шини CAN через інтерфейс Kvaser CAN USB та інтерфейс PicoScope.

Посилаючись на малюнок 6, інтерфейс Kvaser використовується для створення повідомлень діагностичного запиту, а PicoScope використовується для отримання повідомлення діагностичної відповіді для аналізу фізичної сигнатури. Програмне забезпечення X-analyser використовується для створення передавачів ID 0x7E0 (або 0x700-0x7FF для інших ECU) через передавач об’єктів і використовує інтерфейс Kvaser для надсилання цих повідомлень на шину. PicoScope побачить надісланий передавач (0x7E0) і прочитає відповідь на це повідомлення з ID 0x7E8. Потім 0x7E8 можна проаналізувати за допомогою Analogue Network Analyzer у X-analyser.

Рисунок 6 Підключення X-Analyser до автомобіля через інтерфейс Квасер та осцилограф PicoScope PC

 

 

Діагностичні запити

Додаткову інформацію про діагностичний запит можна знайти в ISO 15765-4:2016. Основна необхідна інформація – запит на діагностику має шістнадцяткові ідентифікатори CAN у діапазоні від 0x700 до 0x7FF. Відомо, що стандартне повідомлення діагностичного запиту викидів має ідентифікатор 0x7E0, а очікувана відповідь від ECM (модуля керування двигуном) — ідентифікатор 0x7E8. Посилаючись на ISO 15765-4:2016, сторінка 29, також відомо, що ідентифікатор запиту на діагностику TCM (модуля керування трансмісією) — 7E1, а повідомлення відповіді — 7E9. Багато інших ECU залежать від виробника, але більшість можна перевірити за допомогою інструменту OBD для конкретної моделі автомобіля. Наприклад, відомо, що в багатьох моделях ЕБУ ABS має запит 7E2 і відповідь 7EA.

Значення ідентифікатора діагностичної відповіді збільшиться на 8 і дасть відповідь, тобто;

ID запиту = 0x7E0 ID відповіді = 0x7E8 8 = 7E8 – 7E0

Прикладом CAN-кадру діагностичного запиту 0x7E0 є;

ID = 0x7E0 DLC = 8 Дані = 02 10 01 00 00 00 00 00

Тому ми очікуємо відповіді від ЕБУ системи викидів (двигуна) на CAN ID 7E8.

Якщо на інші запити немає відповіді, це означає, що ця функція діагностики не підтримується в цьому автомобілі. Діаграма на малюнку 7 показує повідомлення діагностичної відповіді в 1- ^му автомобілі кандидата. З цього ми встановили електричні підписи CAN ID 728, 7E8 738 і 768. За специфікацією виробника можна встановити функції цих ECU.

 

 

Збір даних на X-Analyser і PicoScope

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

Кандидати 1 і 2 були електрично хорошими шинами CAN, тобто хорошим заземленням і меншим шумом. Методологія, використана тут, полягала в побудові модальних значень CAN-H і CAN-L із сегмента даних кадру CAN для створення показаних кластерів. Це модальне значення буде взято з регіону поля даних лише для домінантних бітів.

 

 

Використання методу побудови графіка CAN_H проти CAN_L

Кандидат 1

У транспортному засобі 1- ^го кандидата було надіслано повідомлення діагностичного запиту з результатами відповіді, які відображають електричний підпис, показаний на малюнку 7.

Малюнок 7. Кластерний графік повідомлень діагностичної відповіді CAN для транспортного засобу-кандидата 1 – модальна напруга CAN_H проти модальної напруги CAN_L

 

Тут ми малюємо точки кластера за допомогою CAN_H проти CAN_L. Відповідно до специфікації цього транспортного засобу отримані діагностичні відповіді інтерпретуються таким чином:

• 728 – Комбінація приладів
• 7E8 – ЕБУ двигуна
• 738 – ЕБУ рульового управління
• 768 – ЕБУ модуля керування гальмами

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

Рисунок 8. Кластерний графік повідомлень CAN у реальному часі для транспортного засобу-кандидата 1 – модальна напруга CAN_H проти модальної напруги CAN_L

 

Тут ми встановили, що загальні електричні підписи повідомлень CAN у режимі реального часу тісно збігаються з діагностичними відповідями. Таким чином, ми можемо переконатися, що повідомлення надходять від таких ECU:

• ЕБУ приладів – CAN ID 190, 275 430, 433, 460
• ЕБУ двигуна – ідентифікатори CAN 200, 201, 205, 231, 268, 280, 420, 428, 4F0, 4F1, 4F3
• EHPAS ECU – 240
• ECU модуля керування гальмами – 20F, 211, 212, 4B0

Ця інформація дозволить використати методи зворотного проектування, щоб допомогти визначити функції цих повідомлень CAN. У X-Analyser можна виділити ці повідомлення та виконати різні методи дослідження, щоб визначити функції окремих сигналів у цих повідомленнях.

 

Кандидат 2

Для подальшої перевірки валідності цього методу подібний метод було виконано на ^{другому} транспортному засобі, для якого була доступна специфікація CAN. Результат проілюстровано на малюнку 9 нижче, де показано електричні сигнатури даних CAN у реальному часі цього автомобіля.

Малюнок 9. Кластерний графік повідомлень CAN у реальному часі для транспортного засобу-кандидата 2 – модальна напруга CAN_H проти модальної напруги CAN_L

 

Тут ми можемо помітити, що повідомлення надходять від наступних ECU:

• ЕБУ гальмування – CAN ID 091, 1AA, 1A4, 1B0, 1D0,1EA, 255
• Електронний блок керування приладами – ідентифікатори CAN 156, 18E, 1A6, 21E, 221, 294, 295, 309, 372, 374, 377, 378, 386, 405, 428, 42D 510
• ЕБУ двигуна – ідентифікатори CAN 13C, 158, 17C, 1DC, 1ED, 320, 324, 328, 376,3D7, 40C, 454, 465
• ЕБУ подушок безпеки – CAN ID 039, 305, 401

 

 

Висновок

Метод, показаний у цьому документі, можна використовувати як доказ для підтвердження гіпотез під час зворотного проектування. Багато разів під час вправ зворотного проектування ми хочемо ізолювати повідомлення CAN від певного ECU. Цей метод побудови електричних сигнатур шляхом відмітки модального середнього рівня CAN_H проти CAN_L для кожного поля даних повідомлення показав, що він є дуже хорошою допомогою в цьому.

Підхід, показаний у цій статті, не обмежується технологією шини CAN. CAN-FD — очевидний наступний автобус, на який варто звернути увагу. Однак електричні сигнатури можна отримати для багатьох інших шинних і мережевих технологій, наприклад FlexRay, який використовує підхід диференціальної сигналізації. Може бути можливим охарактеризувати сигнали на шині LIN. Однак для отримання електричної сигнатури потрібно буде прийняти дещо змінений підхід, оскільки він не використовує диференціальну передачу сигналів.

 

 

 

Список літератури

ISO 15765-4 (2016) – Дорожні транспортні засоби – Діагностичний зв’язок через мережу контролерів (DoCAN). Частина 4: Вимоги до систем, пов’язаних з викидами . Використання електричних підписів повідомлень шини CAN для зворотного проектування автомобілів С. Квіглі, Д. Чарльз, Р. Маклафлін Уорвік Контроль Технології Анотація Існує багато програм, у яких вам може знадобитися зворотне проектування мережі контролера (CAN), наприклад:

Типовий процес зворотного проектування пов’язаний із переміщенням датчика та спостереженням за зміною повідомлень на шині CAN. Наприклад, опустіть дверне вікно та подивіться, чи це призведе до змін у даних повідомлення CAN.

Багато шин CAN мають багато повідомлень, що надходять від багатьох електронних блоків керування (ECU). Це означає, що важко переглядати їх усіх одночасно. Було б набагато простіше, якби ви могли просто спостерігати за меншою кількістю повідомлень CAN, щоб спостерігати за змінами, ізолюючи ECU, з яких надходять повідомлення.

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

Метод для визначення того, які ідентифікатори надходять від конкретного ECU, полягає в тому, щоб спочатку отримати графіки електричного підпису відомих діагностичних відповідей і порівняти з графіком електричного підпису повідомлень керування в реальному часі. Ми показуємо, як цього досягти за допомогою інструменту X-Analyser від Warwick Control у поєднанні з комп’ютерним осцилографом PicoScope та USB-інтерфейсом Kvaser CAN.

Цей документ вимагає попередніх базових знань про роботу технології шини CAN.

• Аналіз автомобільних конкурентів
• Телематичні програми, такі як керування автопарком
• Відключені програми драйвера

 

 

Оринігал. 

 

Читайте також:

Що таке DoIP