Передача різних повідомлень з ідентичним ідентифікатором на шині CAN


12

CAN арбітраж проводиться з ідентифікаторами, і будь-який вузол на шині може передавати з будь-яким ідентифікатором (в ідеалі він не повинен, але неприємний вузол може).

Що робити, якщо два різних вузли, підключені на одній шині CAN, передають повідомлення з однаковими ідентифікаторами, але різними байтами даних?

Моє мислення: Це створить сміття в автобусі. Той, хто має домінуючі біти, лише ті, хто буде переданий.


1
Я не впевнений, чому вони зробили це так. Я б подумав, що арбітраж має більше сенсу застосовувати до всього повідомлення.
Rocketmagnet

Відповіді:


12

Розділ 6.1 специфікації CAN :

BIT ERROR: Підрозділ, який надсилає трохи в шині, також контролює шину. Помилка BIT повинна бути виявлена ​​в той бітовий час, коли значення біта, яке відстежується, відрізняється від надісланого бітового значення. Виняток - надсилання «рецесивного» біта під час заповненого потоку бітів у полі ARBITRATION FIELD або під час слота ACK.

Отже, вузол, який перший передає '1', коли інший передає '0', відзначає бітову помилку, а потім сигналізує про помилку як звичайне - передаючи прапор помилки (див. Розділ 3.1.3), як це описано формально у розділі 6.2.

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

  • ніхто його не отримає
  • жоден із передавачів не подумає, що вони щось успішно передали.

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


Розширена відповідь, натхненна відповіддю @ clabbacchio нижче.

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

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


1

У своєму запитанні ви висуваєте цю гіпотезу:

Той, хто має домінуючі біти, лише ті, хто буде переданий.

Що передбачає, що два повідомлення передаються точно в один і той же час, що є конкретним випадком більш загального питання. Дійсна відповідь Мартіна стосується цього конкретного питання, але ігнорує (більш загальний) випадок, коли два вузли передають у різний час.

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

Скажімо, що одне повідомлення містить показання датчика температури, інше містить цільове положення виконавчого механізму на тому ж байті (ДОБРЕ НЕ БУДЕ ВІДПОВІДНО В РЕАЛЬНОМУ ЖИТТІ), можливо, привід може отримати це як своє цілі, навіть не знаючи про це.


Так, слід розробити логіку, щоб розрізняти два повідомлення. Але моє запитання було, якщо арбітраж проводиться на основі ідентифікатора, то що буде, якщо ідентифікатор повідомлення однаковий, а дані інші.
Swanand

@Swanand лише на гіпотезі одночасної передачі?
Зауважте

0

Якщо поле даних повідомлень відрізняється, ви (сподіваємось!) Отримаєте кадр помилок на шині через неправильну CRC.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.