Путешествуя по автомобильным сайтам, я был очень удивлён. Оказывается бывают такие девайсы, и их у нас продают, которые позволяют изменять информацию читаемую с автомобильной CAN шины. Чаще всего, как я понял, они используются водителями для "коррекции" пробега, чтобы списать побольше топлива. Но наверное можно и перед продажей установить, чтобы скрутить пробег. Ну и для того, чтобы информацию о машине изменить, тоже использовать можно.

Я предполагаю, что дело происходит примерно так:
1. В CAN сеть подключается специальный девайс.
2. Этот девайс портит посылки, содержащие информацию о пробеге. Но нужно перед этим прочесть имеющуюся посылку, чтобы из неё вынуть данные о реальном пробеге.
3. Этот девайс выдаёт в сеть свою посылку, содержащую скорректированную информацию.

Испортить посылку по п.2, на мой взгляд, лучше всего установив доминанту во время передачи CRC. Тогда и реальный пробег можно прочесть (мы ведь знаем, что ошибка CRC - это наших рук дело). Понятно, что для этого придётся влезть в CAN протокол програмно, т.к. CAN контроллеры на такое не рассчитаны. Но проблем там быть не должно, т.к. скорость 250 или 500 кбод. ATmega48 вполне справится. При тактовой 16 мГц будет 64 или 32 такта на бит. Вполне достаточно чтобы CRC на лету подсчитать. Лучше всего вход захвата таймера для приёма данных использовать.

Ну и противодействовать этому легко. Просто смотреть испорченные посылки.

Хотя м.б. я не прав, а там ребята просто знают команду для изменения пробега...

А сейчас подумал, что м.б. ребята так не заморачиваются. Просто забивают всю шину своими левыми сообщениями. А когда происходит реальная передача, то у неё ID такой же. Арбитража из-за этого нет. Появляется ошибка в данных и CRC. А счётчик ошибок у ребят постоянно сбрасывается. А у настоящего - Bus Off.

Вы будете удивлены, может быть, но есть еще и такие штучки, которые позволяют смотреть видео на встроенной навигационке, когда машина двигается(например в Volkswagen это запрещено по умолчанию). Девайс имеет 2 CAN интерфейса и ставится между дисплеем навигашки и шиной (там CAN). Сообщения о скорости движения просто блокируются.
Известно, что в CAN сообщения с одинаковым ID не должны генерироваться в двух разных местах. Иначе может быть коллизия при передаче. Поэтому просто достаточно вычислить, кто шлет посылку с пробегом (может быть спидометр или датчик скорости). И включить ваш девайс между этим устройством и шиной. Для всех остальных посылок данный девайс будет полностью прозрачным, а для посылочки с пробегом - нет. Спидометр пошлет свое значение - девайс его примет, обработает и в сеть уйдет скорректированное значение.
...И Вы никогда не увидите ни коллизий ни испорченных посылок.

1. Так именно на коллизии (ошибка бита у передатчика, ошибка CRC у всех остальных), и последующем переходе в Bus Off "нежелательного" передатчика там всё и построено.
2. Такую штуку вполне можно и без двух CAN интерфейсов сделать. На той же ATmega48 за $0.5. Только CAN-овских драйверов (за $1) таки придётся 2 штуки поставить. Но в итоге даже лучше получится. Т.к. задержки, размером в посылку, вносится не будет. Будет только совсем небольшая в 4 такта (1/8 бита при 500 кбод и 16 мГц тактовой). Это для того, чтобы узнать из какой части сейчас доминанта идёт. Можно и примитивную логику для этого поставить конечно.
Когда будет принято интересующее нас ID - рвём соединение и остаток посылки сами в ''защищённую" часть шлём, а "нежелательную" посылку в это время принимаем (если данные, в ней содержащиеся, нужны). Тут как раз удачно бит RTR стоит. В J1939 он всегда =0 (RTR не используется). В это время переключится вполне можно успеть. Только всё равно нужно продолжение, с вычисленным CRC и битстаффингом, к этому моменту в памяти уже иметь и передавать дальше в "защищённую" часть (с помощью SPI). Тогда без проблем для приёма времени хватит. Тем более, что в такой конфигурации CRC на лету можно и не считать (хотя на лету лучше).

Но вообще, это прикол конечно. Причём, что-то такое родное, чисто русское. Поэтому меня и заинтересовало...

galjoen

да.. вот мне тоже думается это реализуется всёже подключкой вразрыв между щитком приборов и набортной сетью CAN

по поводу вашей идеи с копеечной мега:
её можно усовершенствовать, заведя доп.сигнал с датчика скорости (который используется также для подсчёта пройденного пути)
ведь смысл прибора в том чтобы отображать показания на щитке с некоторой "дельтой":
так получается введя эту дельту и текущий (реальный) пробег, и инкрементируя пробег с импульсов датчика скорости, атмега может рассчитывать новое значение с битстаффингом и CRC в промежутках между приходом на неё оригинальных CAN-сообщений.

ЗЫЖ не корысти ради, а исключительно тренируя инженерную смекалку)

1. Не совсем понял. К самому датчику что ли подключиться? Может не получится - там ещё всякие колёсные датчики противобуксовочные и ABS стоят. Вообще машина ехать может перестать. У меня как-то на задние колёса, при езде по мокрому полю, столько травы намоталось, что они вращатся перестали. Так какая то сумасшедшая ошибка вылезла...
Да и CAN посылка с реального дачкика скорости чем плоха? И все те же данные есть, и лишних проводов тянуть не надо. В чём преимущество то?

2. Полностью согласен. Обманув хитрож-ю технику, получаешь большое удовольствие.

думаю в разных авто - по-разному.
у меня кореянка 2006м.г. (сee'd) - так там помимо сигналов с АБС с каждого колеса есть старый-добрый сигнал датчика скорости с АКПП - и вот он как раз много куда заводится, несмотря на обилие потребителей CAN-сети
в т.ч. на щиток приборов и маршрутный компьютер
думаю врядли схемотехника других современных авто в этом плане претерпела какие-либо существенные изменения..
(логично что в ЭБУ хранится только само значение счётчика одометра, как особо охраняемое, а мгновенный расчёт скорости можно отдать на откуп другим блокам)

По последним, не проверенным, сведениям КАН моталка всего лишь шлёт в CAN посылку со скоростью (PG=FEBF). И всё! Т.е. машина стоит, а спидометр едет. А в самом блоке ЭБУ правильная информация о пробеге. Только она сама не выдаётся - её запрашивать нужно...
А мы, особенно я, уж тут намудрили...
Хотя это тоже полезно может быть. Подключил что-то такое миниатюрное к OBD разъёму, и поехал к официальному диллеру. Ну и посмотрел все пароли. Как он там прохождение ТО отмечает? Обычным логгером такое намного сложнее сделать т.к. нет информации о том, кто какую посылку отправил. Ну и различную информацию насчёт общего пробега, например, (по запросу из OBD) таким образом можно подкорректировать...

Так в том то и вопрос - мотать в какую сторону вам нужно? Вперед, чтобы пробег увеличить и топливо списать? Если первое, то это делалось еще в докановские времена с помощью любого сервис тула. Там всегда есть опция калибровки спидометра. То есть задаешь скорость и смотришь на стрелку - туда ли она встала. Естественно счетчик тоже считал что машина едет. Делалось все просто симуляцией генерации импульсов от датчика скорости. Ну и КАН посылкой это тоже делается легко в настоящее время.
А вот как смотать назад, например для продажи, да чтобы никто не заметил (например коллизии или ошибки CRC обнаруживаются легко) это интересней.
В любом случае передатчик не обязательно "давить", а просто достаточно сделать так чтобы он думал, что его сообщение приняли. А в сеть совсем другое сообщение отсылать. Синхронность сдесь не нужна, но 2 CAN-контроллера желательно.

Так в том и идея, чтобы ATmega48 за $0.5 с софтовым CAN-ом использовать. Все другие варианты (в т.ч. MCP2515) значительно дороже. А к MCP2515 всё равно процессор нужен. А LPC с двумя CAN-ами вроде от $7 начинаются... Ну и по размерам/потреблению мега тоже вне конкуренции. Можно и 2 ATmega48 поставить, в случае не синхронного повторителя, но тогда связь между ними проблемой будет. Да и вообще, зачем не синхронно делать, если можно (и проще) синхронно?

Я посмотрел, ATmega48 до 20 мГц работает. Т.е. при 500 кбод 40 тактов на бит у неё будет. Вроде должна успевать и CRC и битстаффинг на лету считать. Хотя простейшую логику таки придётся добавить. Но можно, наверное, и диодами/резисторами обойтись...

Ну Вы мужики и намудрили=) Делать софтверный кан для моталки, када проц с каном от 7 баксов....цена моталки все равно во много раз больше стоимости проца и сбивать эти цены никому не надо....

а по существу есть что сказать, господин продавец мк с CAN по 7баксов ?

Извиняюсь, заснул вчера когда писал.Хочу сказать что коллизии при параллельной ABS отправке своих пакетов хоть и возникают но ЭБУ, АБС и панель приборов особого внимания на это не обращают.

Кстати в большинстве авто за угол отклонения стрелки спидометра и увеличение пробега на 0.1км отвечают разные байты в пакете а иногда и разные пакеты

Сообщение отредактировал Punk - Nov 23 2009, 05:23

Punk Насчёт пробега на щитке понятно. А если запросить пробег (вроде по запросу выдаётся) у того же АБС, то ведь реальный в ответ получишь?

Кстати мне недавно на пару часов Сканматик в руки попался. Это такое автомобильное диагностическое оборудование + программа. Подключается ко многим типам автомобильных интерфейсов, в т.ч. к CAN. К машине его подключить, к сожалению, возможности не было. Но платку я рассмотрел. Там стоит ATtiny2313 (хотя надпись затёрта) с кварцем 20 мГц. Причём RxCAN у них на INT0 заведён, а не на вход захвата (как сделал бы я). И TxCAN они обычным портом формируют, а не SPI. И ничего, с CAN до 500 кбод (автомобильные выше не бывают) работает. Так вот, не стали они мк с CAN, пусть даже за $5, ставить. Хотя вся эта штука в комплекте 9200 руб. стоит.

Реальный не получишь из АБС и вообще когда эмулируешь по кан скорость у тебя впринципе во все нужные места пробег меняется, так что ровно тут все. Другое дело когда наоборот сматываешь.

Не спорю, решение очень интересное с инженерной точки зрения, я бы даже за такое решение денег выложил, но с практической, ИМХО, все же лучше железный CAN применять, тем более в автомобиле, не игрушки все-таки.

Сообщение отредактировал Punk - Nov 23 2009, 17:48

Что-то теория с практикой расходятся... Если АБС внутри у себя пробег по датчикам с колёс считает (а там не CAN, а просто импульсы, иначе это уже будет не CAN моталка), то испортив его CAN посылки, мы не затронем тот пробег, который в самом АБС хранится (если он там хранится конечно). Другое дело если мы подменяем посылки, с колёсами связанные. CAN посылки с датчика установленного в КПП, например.

1. Железный CAN не имеет преимущества перед программным по надёжности т.к. программый глюк в МК с железным CAN-ом может привести к тем-же последствиям, что и с софтовым.
2. Простой МК (а софтовый CAN имеет смысл делать только на простом) менее подвержен зависанию, чем сложный из-за меньших размеров (меньше ловит помеху), лучшего охлаждения и, собственно, простоты. Не случайно у младших/мелких AVR тактовая частота выше, чем у старших/больших.
3. В простом МК с небольшой программой есть возможность в ватчдоге использовать малую задержку. Из-за этого время восстановления после сбоя будет меньше, чем у сложного МК.
4. В любом случае от подвешивания всей сети доминантой спасёт аппаратная защита в CAN приёмопередатчике. Именно такой приёмопередатчик нужно использовать в любом случае. MCP2551 например.