Розділ 6.1 специфікації CAN :
BIT ERROR: Підрозділ, який надсилає трохи в шині, також контролює шину. Помилка BIT повинна бути виявлена в той бітовий час, коли значення біта, яке відстежується, відрізняється від надісланого бітового значення. Виняток - надсилання «рецесивного» біта під час заповненого потоку бітів у полі ARBITRATION FIELD або під час слота ACK.
Отже, вузол, який перший передає '1', коли інший передає '0', відзначає бітову помилку, а потім сигналізує про помилку як звичайне - передаючи прапор помилки (див. Розділ 3.1.3), як це описано формально у розділі 6.2.
Неофіційно, якщо цей вузол є помилковим (що має бути звичайним випадком), він передасть прапор помилки з 6 домінуючих бітів, який усі інші вузли також виявлять (як помилка речовини). Це призводить до повного знищення цього повідомлення:
- ніхто його не отримає
- жоден із передавачів не подумає, що вони щось успішно передали.
Кожен передавач буде намагатися ретрансляцію - залежно від точного часу ретрансляції, один може запустити достатньо перед іншим контролем посилення шини. В іншому випадку така ж послідовність може повторитися. (Або інше повідомлення з вищим пріоритетом може перенести їх обох на деякий час!)
Розширена відповідь, натхненна відповіддю @ clabbacchio нижче.
Ви згадуєте "неприємні вузли", а clabbacchio робить дійсною точкою того, що якщо два вузли передають в різний час, кожному приймачу потрібно вирішити, що робити з його декількома прийомами.
Це продемонстрував хак в минулому році . У статті в розділі "Специфікація PSCM" обговорюється, як зловмисник може синхронізуватися з звичайними повідомленнями в автобусі та відтворювати їхні злісні повідомлення безпосередньо перед тим, яке збирається відправити "добрий" ECU. ECU, що приймає, приймає попереднє повідомлення, оновлює його лічильник повідомлень, а потім відкидає "хороші" повідомлення як помилкові, оскільки його лічильник повідомлень не збільшується.