Где взять описания CAN-протоколов для разных марок?..
 

Собственно, вопрос - в заголовке. Есть большой опыт программирования под CAN-шины (CANopen в том числе, но, насколько я понимаю, в автодиагностике достаточно уровня "чистого" CAN). Есть различные приборы для работы с CAN. Ну, и есть большое желание применить это все в благородном деле автодиагностики...:smile:

///
 

Странно.. Типа, никто ничего не знает? Сам уже нарыл стандарт SAE J/1979. Однако, это только рекомендуемые стандартные сообщения. Их-то я сделаю "влет", что называется. Интересуют именно нестандартные, применяемые производителями. И не только диагностические, но и описания фреймов управления и обратной связи. Было бы неплохо.. :rolleyes:

Вопрос не совсем понятен. Какие именно протоколы нужны? Какая, собственно, цель? К примеру в ВАГ группе имеется Моторный КАН и Комфортный КАН, мало того не всё, что есть во внутреннем моторном идёт на диагностический разъём... Да и размеры пакетов с данными отличаются по годам.

ЗЫ. КанХаккер поможет.

///
 

Да понятно, что есть несколько КАН-овских разделенных физически шин. На диагностику идет малая толика. Хотелось бы полных описаний. Понятно, что дайте мне любую машинку на недельку и процентов на 90 я "расколю" все её протоколы. Однако, это долго и довольно нудно. А цель - посмотреть доп. возможности по диагностике и тюнингу ТОЛЬКО с помощью КАН-управления. Так, навскидку, зная какие кадры шлет тот или иной блок, при подозрениях на неправильную работу, можно просто физически откинуть его от шины, взамен же слать сообщения "от его имени" - то есть, с его идентификаторами и с данными эмулирующими заведомо правильную работу.. Это так - лишь малая часть дополнительных возможностей..

КАН-хакер никакой не нужен, я могу перехватывать все сообщения на любых скоростях обмена и тоже самое с отправкой сообщений..

А зачем? Как ты собираешся исключить какой либо пакет из обшего потока? Это нужно ставить в разрыв свой контроллер и фильтровать... Ты собрался на кажый блок это ставить? Года 3 назад меня посещали подобные мысли, но это всё можно решить совсем другими путями. В каждой прошивке описаны данные КАНа, вот там это гораздо легче поменять.

Так это и есть канхаккер.

...
 

У вас, простите, некоторая "каша" в голове по технологии CAN. Ничего "фильтровать" не надо, да в этой технологии это абсолютно бессмысленно.
Я же написал, - блок физически откидывается от CAN-шины. Вместо него шлются заведомо корректные сообщения (или наоборот - зависит от того, что нужно в итоге). А по поводу "Зачем?" - это вопрос риторический.. КАН-технологии позволяют выйти на совсем другой диагностический уровень.

Да нет у меня каши. Это вопрос поставлен не корректно. Только с этого сообщения догадался что же именно преследуется этой целью. Вам охота сделать эмулятор того или иного блока для ремонта на столе? Или как?

...
 

Да, так.. Но повторюсь - это только малая часть возможностей. Программный эмулятор (всех перефирийных блоков, датчиков и прочее) того или иного авто по части КАН возможно сделать дня за 3, только нужны описания протоколов.
Представьте, - подключили комп к кан-шинам, продиагностировали все сразу, построили временные диаграммы всех процессов, если что-то не работает (особенно, когда длинная разветвленная цепь неисправностей), эмуляторами БЫСТРО вычислили такую цепь любой длины и разветвленности. И не надо клиента гонять несколько раз в магазины ("а что если нам теперь заменить вот это?.:smile:")

Но и это ещё далеко не все...

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

Молодчина !!!!!
 

КЛАСНУЮ ТЕМУ ПАДНЯЛ!!!!!!!
НИ ВСЕ ВОЛОКУТ- В ЧЕМ ПРИКОЛ!!!!!!
А КТО ВОЛОКЁТ ПОМАЛКИВАЕТ!!!
ЕСЛИ ЭТУ ТЕМУ РАСКАЧАТЬ-- ПРОДАВЦАМ АВТОДИАГНОСТИКИ НЕ СЛАДКО БУДЕТ,,,,,,,,

USB-CAN адаптер 150 у.е
USB-K Line адаптер 50 у.е
USB-Lin адаптер 100 у.е

ВОТ и вся диагностика!!!!!! ВЕСЬ МИР ЗАКРЫВАЕТ!!!
ну и до кучи RS485.....
USB-CAN транслирует данные в реальном времени ВСЁ что происходит в автомобиле видишь в реальном времени(АБСОЛЮТНО!!!)
ХОЧЕШЬ БОЛЬШЕГО-ПОЖАЛУЙСТА.... отправляешь команду через USB-KLine, и по кану возвратом ещё больше параметров!!!!

Если переферию посмотреть--USB-Lin тебе в помощь!!!!!!

тоже самое при програмировании, ....
есть, правда, мелкие нюансы - но они решаемы.

МЫ ХОТИМ УЧИТСЯ!!! но нас никто не учит.........
 

КАКИМ АДАПТЕРОМ ПОЛЬЗУЕШСЯ РАСКАЖИ.....
КАКОИ ПРОГОЙ ИНТЕРПРЕТИРУЕШЬ СООБЩЕНИЯ?...
ПОПОДРОБНЕЕ ПОЖАЛУЙСТА..... ТЕМА ООООООЧЕНЬ ИНТЕРЕСНАЯ.
ЕСЛИ самому залазить с нуля, при отсутствии информации-это капец!!!
ЛИЧНО Я РАД ,что появился такой ЧЕЛОВЕК !!!

Alexo НАДО развивать эту тему!!!!!
(Эту ветку,в частности)
так что . всё с нуля- и поподробнее....(читателей будет- ОКЕАН)

Да, полностью согласен..
Я использую MARATHON и IXXAT - CAN-USB адаптеры. Самое главное, что программирование под них отработано (у одного - юзаешь библиотеку CHAI, у другого - API расписаны). Кроме того, есть и стандартные программы, идущие с ними..
А по поводу CAN - да, возможностей масса - мы действительно, помимо диагностических, видим ВСЕ сигналы (и управления, и от периферии) В РЕАЛЬНОМ времени, помимо этого, можем вмешаться в любой процесс управления (понятно, что ОООчень аккуратно и четко осознавая, что делаешь, - для этого и нужны точные протоколы обмена, в частности)... Тут, как говорится, ещё то "поле деятельности"...
На меня уже, правда, вышли, обещали прислать для Форда (2006 -...) протоколы.

надо идти дальше.
 

например
начать показывать -как с ними работать.
1.видео работы интерпретатора.
2.команды
3.прописывание (интерпретаций и отправляемых команд)
4. графические оболочки и работа с ними.

дело за тобой...
что касается кан-сообщений(протокольных) -они все стандартизированны по SAE (95%) и лишь 5% это для OEM.
но их тоже найти можно. некоторые выложены.
SAE их продаёт -2000уе но и выложенных тоже есть....

Один из приборов
 

Это ешо одно устойство
 

SAE 1939
 

Протокол SAE J1939 определен SAE и предназначен для коммерческих транспортных средств, а также для морских судов, железнодорожных транспортных средств, сельскохозяйственного оборудования и больших генераторов. SAE J1939 является базой для международных стандартов NMEA 2000 (морские) и ISO 11783 (ISO шина для сельскохозяйственного оборудования), поэтому протокол SAE J1939 можно использовать и для этих приложений.

Последовательные протоколы для коммерческих транспортных средств, стандартизированные SAE, применяются уже давно. Они предназначены для установления связи между отдельными электронными блоками управления и компонентами приводных механизмов. J1708/J1587 протокол основаный на последовательном порте, обычно доступным в микроконтроллерах, может рассматриваться как предшественник J1939.

Для того, чтобы обеспечить требования совместимости с J1708/J1587 протоколом, необходимо расширение идентификатора CAN сообщения (с 11 бит до 29 бит – расширенный формат), а также разработка CAN модулей или реализация протоколов, поддерживающих формат такого сообщения.

Расширенный CAN идентификатор позволяет установить соответствие между принципами связи CAN и J1708. Для этого, часть идентификатора используется для определения 8-ми разрядного исходного адреса и 8-ми разрядного целевого адреса (номер узла). С помощью SAE J1939 возможно как передавать значения измерений и управлять данными, так и конфигурировать компоненты. Также возможно считывать или удалять диагностические данные отдельных компонентов, а также выполнять калибровку отдельных единиц управления.

Чтобы это стало возможным в SAE J1939 определяются всек переменные, относящиеся к коммерческим транспортным средствам, вместе с их диапазоном значений, дискретностью, идентификационным номером и т.д. Это реализуется на основе уже имеющейся в J1587 спецификации.

Таким образом в протоколе J1939 специфицируются не только типы передач, структура сообщений и их сегментация, контроль потока и т.п., но также точно определяется и само содержание сообщений.

SAE J1939 и ISO/OSI уровневая модель


SAE J1939 имеет несколько уровней, соответствующих OSI уровневой модели. Каждый уровень определен соответствующим документом. Аналогично практически всем протоколам полевой шины, в SAE J1939 уровень 5 и уровень 6 не используются, поэтому они не определены для данного протокола.



Функциональность SAE J1939 разделяется в соответствие с уровнями:

SAE J1939-1X. A Physical Layer (физический уровень) – определяет электрический интерфейс и физическую среду
SAE J1939-21. Data Link Layer (канальный уровень) – определяет обмен данными по CAN согласно спецификации CAN 2.0B
SAE J1939-31. Network Layer (сетевой уровень) – в основном, описывает функциональность моста для обмена сообщениями между двумя сегментами сети. Он является значимым только для реализации J1939 моста
SAE J1939-4X. Transport Layer (транспортный уровень) – описывает сетевые сервисы для режима запроса сообщений, передачи уведомлений и фрагментированной передачи больших блоков данных
SAE J1939-71. Vehicle Application Layer (прикладной уровень) – описывает фактические данные (параметры или переменные сети с диапазоном значений, разрешением, физическим модулем и типом передачи). Каждое сообщение имеет однозначную ссылку по номеру (номер группы параметров)
Так как управление сетью может рассматриваться как отдельный элемент (распространяется от 7 до 1 уровня), то этот блок в уровневой модели представлен как независимый функциональный блок, изображенный на рисунке справа. Обычно управление сетью состоит из автоматического назначения или определения адреса узла (принцип plug & play). В SAE J1939 не определен мониторинг узла, он реализуется с помощью циклических сообщений на прикладном уровне.

НА ТЕБЯ ВСЯ СТРАНА СМОТРИТ!!!
 

ALEXO примерно в таком духе продолжи,пожалуйста.
И несколько практических примерчиков, очень помогут пониманию глубоких уровней диагностики- а это приведёт к широкому интересу к этой теме.
адаптеры то стоят копейки.

на самом деле- нужно только расширить базу данных по сообщениям(КАН) .РАЗОБРАТЬСЯ с интерпретацией(расшифровка) их.
как только народ это увидит........

Тут, для меня проблем работы с МАРАФОНОМ вплоть до создания своих программулин, например, нет. Дело больше в самом CAN – для самого начала неплохо бы изучить структуру КАН-кадра (или «сообщения», или «фрейма» – в разной документации возможно различное название). Для этого, опять же, надо представлять для чего вообще была создана эта технология и, если хотите, её «философия» - то есть, чем принципиально она отличается от других (того же, например RS485). Тут важно понимать, что за «простоту» принципа обмена информацией «расплачиваются» повышением общих накладных за счет обязательности у каждого прибора в сети наличия КАН-контроллера. Далее, - естесственно, это все стандартизировано, и ещё на аппаратном уровне имеются и проверки целостности, и защита от ошибок, и аппаратные фильтры и ещё много чего нужного, но делаемого автоматически и, таким образом, освобождающего программиста от заботы об этом всем.. Для программера остается только сам формат кадра – идентификатор сообщения и восемь байт с данными. И ВСЕ – больше он ни о чем может не волноваться. Протокол обмена устроен так: например, там написано, что некий датчик общается с основными «мозгами» авто в следующем порядке: на скорости 500 кБит/с, форма – «запрос – ответ», формат данных – «в первом байте – каждый бит (из 8-ми) говорит о его состоянии, - 1-ый, допустим, исправен-неисправен (да-нет – булева переменная, 2-ой – есть связь-нет связи, третий - ещё какие-то булевы параметры.)» То есть первый байт, по протоколу ответственен за булевы переменные (да-нет). Второй байт может быть уже какой-то аналоговой величиной (допустим, напряжение). Тогда весь байт отдан под него (может быть под аналоговые переменные отдано и больше – один байт максимум обеспечивает 255 – и то, если беззнаковая переменная, если знаковая – то до 127). Ну, и так далее – все зависит от того, как заранее ДОГОВОРИЛИСЬ это все дело передавать. Если для передачи данных не хватает восьми байт, то в протоколе прописывают ещё один кадр со своим идентификатором и восемью байтами данных. И т.д. Далее – контроллер датчика постоянно слушает сеть (как, впрочем, и все остальные контроллеры остальных приборов). «Слышит» он все сообщения, которые в ней «гуляют». Как только он услышал в сети кадр с идентификатором, который прописан у него программно (или в фильтре), только на него он реагирует – шлет свой пакет из предписанных ему по протоколу сообщений (о своем состоянии, величинах которые он контролирует и проч.) Кстати, очень часто, в одном из байт, как правило, передается так называемый «счетчик» - в каждом новом сообщении величина счетчика увеличивается на 1 и так до 255, потом – по-новой. Для «принимающей» стороны это, хоть и косвенно, говорит о том, что прибор исправен. Да и при необходимости, можно точно восстановить последовательность кадров. Формат общения не обязательно может быть «запрос-ответ», зачастую такие приборы, как датчики сами с некоторой «договоренной» периодичностью шлют свои сообщения. Или наоборот, - шлют только по запросу, если же превышен некоторый критичный порог, - начинают слать постоянно с некоторой периодичностью.. И т.д. – все это и есть описание протокола информационного обмена… Ну, как, нужен такой «ликбез»?... :smile:

Да IXXAT такой же, как на фото..

Если не говорить о программировании - то возможности обычных стандартных КАН-адаптеров тоже достаточно велики - в их стандартных программах мы перехватываем и видим все сообщения. Зная протокол, - можем судить обо всем, что там происходит.. Вот, как-то так.. Кстати, в ихатовских и марафоновских программах (стандартных, - те, что идут вместе с приборами) также можно и отсылать в сеть любые кан-кадры с заданной периодичностью.. Об эмуляции я писал уже раньше..

Вот скрин со стандартной программы Марафона (CANwise) одного из 4-рех каналов некой системы управления, по сложности которая на порядок больше автомобильной. В этом канале порядка сотни сообщений и около сорока периферийных приборов.
То есть, я, зная только скорость обмена (500 К) подключился к шине (в любом месте, где это удобнее - всего-то делов - два провода подсоединить), "слышу" все, что там происходит. В данном случае - на рис. закладка CANtracer - если сообщение хотя бы раз проходило, то оно здесь появится под своим идетификатором и будет "стоять" неподвижно, меняться будут только данные (если им "положено" меняться в силу логики работы). Столбец NUM -сколько всего данных с идентификатором ID прошло на данный момент. Все представлено в 16-ричной системе счисления. Вот, например, сообщение с идентификатором 0х206 (так обозначают в 16-ричной системе), байт "0" (все подсчеты, как правило, начинаются не с 1-го а с0-го, также как и биты) - значение 0хD2 (в десятичной системе - 210). Я по протоколу знаю, что в этом байте передается значение скорости в км/час (так договорились, когда разрабатывали) протокол обмена, так как максимально возможная скорость - 230 км/час, то все "умещается" в один байт, который, как известно, позволяет передавать от 0 до 255. А, например, сообщения с ID 0х184, 0х186 - передают засветку клавиш от блока управления. То есть, в данном случае, буквально: "Клавиши такие-то такие-то подсвечивать желтым цветом".. Все эти сообщения проходят со средней периодичностью около 30 мс (то есть, порядка 30-ти раз в секунду).. Продолжение следует...

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

Продолжим..
 

Вот выдержка из штатного протокола обмена некоего управляющего блока с управляемым. Управляющий шлет запрос 0х200, управляемый - отвечает. На самом деле там 10 ответных сообщений. Я выбрал 2 - разных, первое из них шлет аналоговые параметры, второе - в основном дискретные, но есть и аналоговые. Скорость обмена в данном случае - 250 КБит/сек...

КЛАСС!!!!!!!
 

ВЕЛИКОЕ ДЕЛО ДЕЛАЕШЬ!!!!!!
ЛИЧНО я с ИНТЕРЕСОМ ЧИТАЮ. СВЕЖИЕ МЫСЛИ!!!

ВАЖНО ПОНЯТЬ ОБЩИЕ ПРИНЦИПЫ . А ПОТОМ ДОСКОНАЛЬНО ПО ПУНКТАМ УГЛУБЛЯТЬСЯ

по поводу кадра интересно очень....

Ладно, я сегодня на работе, вообще-то:biggrin1:. Перерывчик надо сделать и поработать.. Но потом - продолжим.. У меня тоже вопросы есть к опытным диагностам.

ДЛЯ РАЗВИТИЯ....
 

ALEXO, про библиотеки.....(кто за что отвечает, что даёт,Зачем надо)

Библиотеки имеется ввиду программные. в случае с МАРАФОНОМ имеется ввиду CHAI.dll. То есть, производитель прибора поставляет и библиотеку - там на низком уровне описано общение с контроллером. Но, чтобы мне не заморачиваться при написании своих программ, я знаю только МЕТОДЫ работы с ней - то есть, например, чтобы программно установить скорость обмена, я вызываю саму библиотеку и метод SetBaud(500) - и абсолютно не парюсь, что там в ней происходит (несколько страниц на Ассемблере):wave:

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

Да, согласен, информация в основном закрытая. Понятно, что и на этой закрытости делаются немалые деньги. Однако, на самом деле, - это пресловутый "секрет полишинеля". Вы же видели - все данные - как "на ладони" - надо только суметь их интерпретировать. Типа, нажимаешь на педаль газа - и смотришь, какие байты меняются (это упрощенно, конечно, но принцип таков)В конце-концов, те же китайцы "грохают" протоколы. А остальное - дело техники.. Да, надо постараться, надо иметь "подопытное" авто на определенный срок.. А в случае заявленной мультимарочности - и далеко не одно. Но, как говорится, "не боги горшки обжигают":smile:

Может быть имеет смысл покопать от обнародованных прошивок и заиметь себе на стол не слишком нужный ЭБУ от какой-нибудь популярной марки?

Да, мысль "уловлена" правильно - собственно, имея основные мозги и подав на них питание, в итоге получим, то что программно эти "мозги" должны начать постоянно слать сигналы по своим шинам.. Отлавливаем их, кое-что нам известно (в открытом доступе, в принципе есть стандарты кое-какие, как я понимаю?). В идеале же для ЭБУ можем сэмулировать ситуацию, что он будет "думать", что реально работает в авто:smile: - то есть, получает все сигналы от периферийных устройств. Сымитировать их работу - проще простого, зная протокол обмена..

Или же последить за блоками, подключив парочку к интерфейсу. На любой разборке этого добра можно набрать на целую машину. Где-то мне эти эксперименты по эмуляции датчиков и тд уже попадались на глаза.
Буду следить за темой.

Тут "замечательность" технологии CAN именно в том, что кроме диагностического, и весь "рабочий" обмен идет также по этой технологии. То есть все управление и обратная связь также ведется по CAN-шинам. "Быстрым" или "Медленным" не играет никакой роли для самой диагностики. В программе (стандартной или своей) установили необходимую скорость, - и все - вот они данные..

Да я в общих чертах в курсе этой технологии. Хотя бы для общего развития. Диагностику же мы не рассматриваем сейчас, не наладив систему и не научившись с ней адекватно обмениваться данными, за рабочие устройства и всякие второстепенные модули. Занятно на прицепах например этот обмен реализован. Второй CAN-сервер в тягаче и прицеп общается исключительно с ним не входя в общую цепь. Даже индикация неисправности выведена отдельным проводом. Все закрыто перезакрыто.

Закрыто, но данные мы же увидим? Не спрятали же они провода в недоступные места? Кстати, есть КАН-крокодилы, которые позволяют мониторить КАН-шину, не подключаясь физически к самим проводам (то есть, не нужно гальванического контакта - прямо поверх изоляции такие "прищепки цепляются"...)

Закрыто, но "тройник" спаять и подключить все это удовольствие к китайскому прибору-копии европейского, в котором присутствуют ворованные расшифровки оригинального протокола - не проблема. Кто-то посидел и разобрался же.

Вот и я о том же.. Не люблю, когда делают "великую тайну" и деньги на совсем простых вобщем-то вещах.. Ничего супер-пупер сложного в КАН нету. Наоборот - все упрощено "до безобразия"..