Путешествуя по автомобильным сайтам, я был очень удивлён. Оказывается бывают такие девайсы, и их у нас продают, которые позволяют изменять информацию читаемую с автомобильной 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 Насчёт пробега на щитке понятно. А если запросить пробег (вроде по запросу выдаётся) у того же АБС, то ведь реальный в ответ получишь?

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

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

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

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

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

В АБС пробега не храниться. У АБС и так забот хватает. Подсчетом километража занята приборная панель, иногда моторник.
---------------------------------------------------------------------------

А Вы где-нить на просторах интернета встречали софтверный кан для АВР ? интересно было бы взглянуть.

Не встречал, хотя и не искал. Хотя возможно, сам, в недалёком будущем, займусь. Но ИМХО - то, что с интернета скачано, только для примера использовать можно. А в изделие - только своё, проверенное.

нет... это уже какой-то совсем несерьёзный разговор пошёл.....
мы о современных авто или о механических одометрах на "классике"??

вообще-то, при смене приборной панели на новую в сборе пробег остаётся...

ECU - вот она родословная и обитель километража..

А Вы лично панели меняли, сматывали? на каких авто?

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

ECU = Electronic Control Unit = Электронный Блок Управления = ЭБУ
Большинство электронных блоков в АТС можно так назвать - АБС, ЭСУД... Каждый из них чем-то управляет.
Из не управляющих разве что всякие рекордеры - тахограф, "чёрный ящик"...




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

Могу рассказать, как выглядит система на последних МАЗах с бошевским EDC-7.
Шина там - CAN 2.0 B (29-битный идентификатор) , протокол - SAE J 1939.

С датчиков колёс сигналы получает АБС.
АБС сообщает в CAN скорость в сообщениях EBC2 (Wheel Speed Information, pgn65215), может и HRW (High Resolution Wheel Speed, pgn65134)

С датчика КПП сигнал идёт на тахограф или электронный спидометр, где и должен подсчитываться пробег.
Тахограф должен по запросу выдавать сообщение VD (Vehicle Distance, pgn65248) или HRVD (High Resolution Vehicle Distance, pgn65217).
Электронный же спидометр с CAN вообще дела не имеет, хотя пробег также считает (одометр).
И тахограф, и ЭС сигнал с датчика нормализует (формирует прямоугольник с заданной длительностью и амплитудой импульса), и выдаёт дальше.

Нормализованный сигнал заведен на несколько приемников:
- EDC по этому сигналу также рассчитывает скорость и пробег. Скорость затем выдаётся в CAN в сообщении CCVS (Cruise Control/Vehicle Speed, pgn65265).
Пробег же можно считать из блока через диагностическую шину (KWP 2000).
- Блок БДИ, который кроме управления указателями выполняет функции бортового регистратора, подсчитывает по этому сигналу пробег, который также затем считывается по диагностической шине ISO 9141.
- Контроллер КПП.

Сигнал заведён еще куда-то, о чем я не в курсе - но картина и так вырисовывается.
Пробег "для диагностики" лежит в нескольких местах, и фальсифицировать его именно "цифровым" методом очень сложно.
Уязвимым местом остаётся вход сигнала с датчика. Подмотку "вперёд" можно выполнять генератором импульсов. А вот для уменьшения пробега придётся ездить с отключенным спидометром, оторвав этот провод.

Насчет расшифровки "ECU":
http://en.wikipedia.org/wiki/Electronic_Control_Unit
http://en.wikipedia.org/wiki/Engine_control_unit
Неоднозначность, однако...

А на ПАЗ-иках с камминзом так:
АБС там видимо разные стоят. Все формируют PGN=0xFEBF (65215), но период выдачи этого сообщения различен. Хотя бывает и как положено по стандарту - 100 mS. Но чаще нет. При поворотах возникают корректные отклонения по колёсам - значит датчики во всех стоят.
Спидометр со своим счётчиком сам по себе.
Я интегрирую скорость из PGN=0xFEBF по времени - получаю пробег (интегрирую по времени прихода сообщения, использую Time Trigger Communication). Совпадает с пробегом по GPS с точностью 1%. А у счётчика спидометра примерно на 6% пробег больше. Видимо он не из CAN cкорость берёт, ну или такой выдающийся расчёт там применён...
Сообщения с общим пробегом PGN=0xFEE0 (65248) в сети есть у всех, но в 2-х из 3-х случаев данные там фиктивные. Обычно сплошные 0. Ну или машина ездит, а ничего не прибавляется.

А обмануть можно если к диагностическому разъёму, через который будут читать пробег, ретранслятор приделать. Он все сообщения будет напрямую пропускать, а в сообщении с пробегом данные, ну скажем на 100000 км уменьшать. А спидометр скрутить - это уж само собой. Только крутить нужно так, чтобы разница 6% была. Иначе подозрительно будет...