Comments 42
Да. Я лично видел как интерфейс CAN используют в автомобилях, в RFID считывателях для шахтёров, в грузовозах, в автобусах, в нано спутниках CubeSat(ах) и даже космических зондах!
Каждая часть - просто транслирует в шину свой стейт, а дальше, прослушивая "эфир" шины, ты знаешь обо всём, что происходит в системе.
В связи с этим мне всегда было непонятно как такие системы проектировать: у нас есть N устройств, которые должны в гарантированные промежутки времени (реалтайм же!) "высказаться". Но если их много то как определить успеют ли они это сделать?
Или просто загруженность шины не должна быть выше единиц процентов чтобы эта гарантия соблюдалась?
Просто выбираете такую шину передачи данных, которая на физическом уровне реализует приоритетность передачи сообщений и та же шина CAN это обеспечивает. Правда в этой статье написано "Устройство с меньшим ID выигрывает арбитраж. Соответственно, чем меньше ID, тем выше приоритет у устройства", но ничего подробно не объясняется, так что гуглите про арбитраж сообщений CAN отдельно.
Именно про CAN-шину и вопрос! Где гарантия что все устройства (разложенные по приоритетам и всё такое прочее) успеют высказаться? "Математически" это доказать можно?
Что значит "математически" в реальном аналоговом мире физических линий связи?
https://ru.wikipedia.org/wiki/Controller_Area_Network#Арбитраж_доступа
Если никто не будет подтверждать пакеты с ID=000 то контроллер при определённой настройке будет спаммить ими без временного интервала. Шина ляжет с этим пакетом на ней. Я проводил такие эксперименты, когда игрался с CANом у STM32.
Если никто не будет подтверждать пакеты с ID=000 то контроллер при определённой настройке будет спаммить ими без временного интервала. Шина ляжет с этим пакетом на ней. Я проводил такие эксперименты, когда игрался с CANом у STM32.
Если никто не будет подтверждать прием пакета с любым CAN ID, то контроллер будет спаммить до переполнения счетчика ошибок передачи (зависит от его настроек).
А если замкнуть или оборвать оба провода в линии связи, то пакеты вообще ходить не будут, однако при обрыве только одного провода, CAN пакеты еще могут передаваться.
Выход из этих ситуаций только один - корректно настраивать параметры работы устройств, а в алгоритме их работы учитывать возможные проблемы при обмене пакетами, включая потерю связи, дублирование CAN ID и прочие неприятности реального мира (в отличии от абстрактного "математического").
Если никто не будет подтверждать прием пакета с любым CAN ID, то контроллер будет спаммить до переполнения счетчика ошибок передачи
Это называется CAN BUS-OFF
Если никто не будет подтверждать прием пакета с любым CAN ID, то контроллер будет спаммить до переполнения счетчика ошибок передачи (зависит от его настроек).
Верно, но более высокий ID теоретически может перебить арбитраж, а 000 никто не перебьёт.
Контроллеры кан-шины не имеют возможности выборочно подтверждать пакеты, как в I2C, например. Любой корректно сформированый пакет аппаратно подтверждается всеми, кто его слышыт.
Не знаю, зачем так сделано. Это ведь не даёт гарантии доставки. Но если на шине несколько исправных устройств, очень сложно получить ситуацию, когда не слышит никто, и подтверждения нет.
Если устройство одно, то, как правило оно и продолжает долбить шину своим единственным пакетом. Ну и пофиг, всё равно этот пакет никому не нужен в таком случае. С программной стороны это приходится анализировать, ставить какие-то таймауты и всё такое.
"Арбитраж доступа" - это про недопущение одновременного говорения и про вытеснение менее приоритетных более приоритетными
А я говорю о том что в конечном счёте ведь все должны "высказаться" за определённое время, а значит должна быть методика расчёта гарантий того что самое низкоприоритетное устройство всей шины успеет сделать все свои дела за отведённое время
Доказать можно. Например:
Берём интервал, за который устройство должно успеть "высказать" пакет с данным ID. Считаем, какую часть этого интервала может занять передача всех пакетов с бОльшим приоритетом в худшем случае. Если эта часть меньше выбранного интервала (есть запас по скорости), то устройство высказаться успеет. И так для каждого ID.
Если, как в телекоме принято, учитывать вероятность ошибки, то и результат такого расчёта, как ни крути, даст вероятность, а не гарантию. В зависимости от запаса по скорости, видимо.
Как определить сколько time quantum (Tq) следует выделить пред делителем для одного CAN бита? 10? 20? 40?
Проще говоря, какое разрешение нужно для одного CAN бита?
Это можно как-то математически рассчитать?
CAN-шину вполне можно загружать по-полной. За счёт аппаратной системы приоритетов обмен по шине достаточно детерминированный, а не случайный, как в Ethernet и многих радио-каналах.
Меньший ID даёт больший приоритет при передаче. Поэтому более частым сообщениям присваивают меньший ID. На картинке Period - в миллисекундах.
Это понятно. Вопрос в том, как измерить процент загрузки CAN шины? Каким оборудованием?
На глазок - осциллографом)
А если точно надо - также, как и во всех остальных протоколах: взять секундный траффик, хоть в электронную таблицу сохранить. Посчитать, сколько битовых интервалов занято под данные, служебную информацию, необходимые паузы, битстаффинг. Разделить на скорость.
На приведённом скриншоте, например, уже есть все исходные данные для расчёта загрузки.
А оборудование - кому что нравится. Я пользуюсь простыми устройствами с али, с открытой прошивкой типа CANable, CANtact и софтом can-utils. Кому-то адаптеры OBD2 ближе, или кан-хакер жаба не душит купить. CAN-FD я пока не пробовал, но тоже какие-то решения для сливания траффика есть.
Можно метафорично сказать, что CAN - это нервная система автомобиля.
Вот не нужно так говорить.
CAN - это стандарт передачи данных, который применяется много где (в том числе и в автомобилях) и физическая среда передачи данных у CAN может быть не только витая пара, но и любая другая, например оптика или даже радиоканал.
В пакете самое важное это 8 байт (64 бит) полезных данных. Мы это называем сообщением.
Кстати, CAN сообщение может быть и без данных, но от этого оно не перестанет быть CAN сообщеним.
GD32C103CB два канала CAN-FD. Цена - копейки.
Запускаем портированный CANact и больше ничего не надо (кроме компьютера/телефона/планшета конечно)
--Каким переходником с USB на CAN-FD можно отлаживать интерфейс CAN-FD? Какое для этоно нужно ПО?
Peak Can FD
Как взламывать CAN трафик в иномарках? Какой пакет CAN шины отвечает за скорость автомобиля?
Захватываем трафик анализируем долго думаем. Тем более обычно есть два способа, из порта ODB, и напрямую с шины которая может её в RAW передавать. Надо только знать что она может передаваться и в оборотах колеса в минуту.
Как найти в CAN трафике легкового автомобиля пакет, который показывает количество пассажиров в автомобиле?
Также как и скорость хватаем травик, садимся встаем, повторяем много раз ищём где. Ну или расковыриваем какой нибудь ODIS и смотрим откуда он вычитывает.
Как измерить процент загрузки CAN шины трафиком в реальном времени?
Peak Can FD показывает и график рисует.
Peak Can FD
Спасибо, не знал про такой. Так уж вышло, что почти весь рынок переходников USB-CAN-FD поделили две компании: Kvaser и Vector.
https://docs.google.com/spreadsheets/d/1RlZYbiAvPGSZC7jcodfeU_IjBmKSKv0fi38Q513mCRs/edit?gid=0#gid=0
Захватываем трафик анализируем долго думаем.
Проблема в том, что в UDS захватывать нечего. Без запроса ECU не ответит. Надо знать, что спрашивать.
Если нет команд UDS, то ничего кулибину и не узнать будет.
Если нет команд UDS, то ничего кулибину и не узнать будет.
Всё так и не так. Там обычно шин то несколько они сходятся в "свич" на котором сидит ODB. Думаю вам об этом известно и так. Так вот до ODB там может быть всё что угодно и оно совсем может быть и не UDS. Это вопервых.
Во вторых если ECU знает скорость, то видимо он ей с кемто делится, ну например с дисплеем на котором спидометр рисуется(InstrumentCluster вроде бы зовется). Ну вот они между собой должны общаться что в логе можно и выловить.
Также как и скорость хватаем травик, садимся встаем, повторяем много раз ищём где. Ну или расковыриваем какой нибудь ODIS и смотрим откуда он вычитывает.
Это был вопрос шутка. Нет в автомобилях датчиков количества пассажиров. Правильный ответ: никак.
Если бы Вас попросили найти в CAN трафике Renault Logan данные о цвете глаз водителя Вы бы тоже всех своих знакомых стали в автомобиль по очереди сажать и как медвежатник взламывать CAN шину?
Это был вопрос шутка. Нет в автомобилях датчиков количества пассажиров. Привильный ответ никак.
Мне если честно абсолютно не интересно есть оно там или нет. А датчики наличия пассажиров на сиденьях вполне могут стоять. Да я понимаю, что сейчас услышу мол а вдруг на одно сиденье два человека сели итд. Но сама суть не меняется.
Если бы Вас попросили найти в CAN трафике Renault Logan данные о цвете глаз водителя вы бы тоже всех своих знакомых стали в автомобиль по очереди сажать и как медвежатник взламывать CAN шину?
Если бы там был датчик которые регистрирует цвет глаз водителя и шлёт на CAN, и это где то отображается, что можно убедится что это работает, да я бы так и сделал.
А что собственно удивляет?
В сиденьях есть датчики которые «видят» сидит кто то или нет, например для индикации непристегнутого ремня безопасности
И для того, чтобы подушки безопасности не взрывались, когда там никого нет
Подушки так же не взорвутся, если увидят непристёгнутый ремень безопасности. Привет адептам заглушек "чтоб не пищало", которым эта подушка гарантированно свернёт шею, ибо она работает именно в паре с ремнём (ремень удерживает тело, подушка голову и все расстояния просчитаны очень точно).
У меня при дтп водительская и пассажирская сработали, хотя на пассажирском кресле ни кто не сидел, а я (водитель) был не пристегнут
Я использую кан хакер, очень удобный девайс. Там у них не очень очевидно, что, как и откуда надо установить. Но в остальном он очень удобный. И цена приемлемая. До этого использовал буржуйский пик кан, больше не пользуюсь этой хренью.
Спасибо автору за труд - занавес слегка приоткрыт. Но до ликбеза конечно тут ещё далеко. Вот например, чем отличается can classic и can2.0, да ещё А и В? Про стандарты ничего не сказано. А ещё есть стандартные идентификатор пакетов - для автодиагностики полезно знать. Есть онлайн калькуляторы пакетов. А ещё и шнайдер пошалили и can open "подарили миру".
Прокомментируйте этот адаптер USB-CAN_FD:
На Али стоит в 2 раза дороже.
Рассказывать про CAN и ни разу не привести как это расшифровывается. Только в конце маленькая табличка акронимов... Это фиаско, братан.
CAN это Controller Area Network, и вот уже не надо придумывать метафоры про нервную систему автомобиля, правда?
PS Забавный факт: can в английском может переводиться как жестяная банка (консерва). Применение в автомобилях символично.
А что скажете про Canable v2? https://canable.io/ . Первая версия успешно работала с PCAN-View и триальной CANopen Magic https://www.canopenmagic.com/index.php/en/
Благодарю за наводку.
Пока ничего не могу сказать. Надо пробовать. Заказал себе
https://www.ozon.ru/product/canable-2-0-can-analizator-usbcan-1763713998/?utm_medium=organic&utm_source=yandex_serp_products
проверю поддерживает ли CAN-FD.
ЛикБез по CAN-FD