Lin bus что это

Lin bus что это

Как следует из этих экранов, системы, в памяти которых отсутствуют коды неисправностей, можно пересчитать по пальцам. А всё остальное «горит» красным цветом, сигнализируя о наличии проблем. Куда «стучаться» в такой ситуации? Опыт подсказывает, что в первую очередь опрашивать надо межсетевой шлюз, т.е. по-нашему Gateway. Ведь именно этот модуль «рулит» всеми шинами данных и именно он фиксирует проблемы, связанные с обменом информацией между блоками.
Прямо из экрана 1, нажав на клавишу с символом « > », входим в блок «Diagnostic Interface For Data-Bus» (это и есть Gateway) и нажимаем на клавишу «Fault Codes» (экран 5).

Экран 5 — Функциональное Меню межсетевого шлюза

Экран 6 — коды неисправностей

В памяти блока имеются три кода (экран 6), и все они, похоже «из одной оперы». Межсетевой шлюз, по сути, жалуется на наличие какой-то электрической проблемы в цепи так называемой локальной шины данных. Общепринятое название этой шины – LIN Bus. Звучит солидно, хотя с физической точки зрения это всего лишь отрезок простого медного провода. Ну а с точки зрения передачи информации, это простецкая 12-ти вольтовая однопроводная шина, с очень низкой скоростью обмена данными (не более 20 кбит в секунду). Тем не менее, данная шина является двунаправленной, т.е. по ней можно как отправлять, так и принимать цифровую информацию.

На автомобиле Audi A5 применяется несколько локальных шин, в частности, их используют блоки климат-контроля, комфорта, бортовой сети и т.п. Но межсетевой шлюз (Gateway) работает только с одной LIN-шиной, и используется она для управления системой зарядки и контроля энергопотребления автомобиля. Другими словами, на этой шине «сидят» только два компонента – генератор с цифровым управлением и блок контроля АКБ, который именуется BDM (Battery Data Module). По сути, данный модуль является встроенным в массовый провод цифровым датчиком тока (фото 2). Модуль BDM по шине LIN передаёт информацию в межсетевой шлюз, а уже тот «рулит» процессом оптимизации зарядки АКБ, причём использует для этого всё ту же локальную шину.

Фото 2 — датчик тока, он же модуль BDM

Вернёмся к кодам неисправностей. Их наличие чрезвычайно сильно упрощает ситуацию и позволяет с большой долей вероятности предположить, что именно неисправность в цепи шины LIN является первопричиной имеющихся проблем с недозарядкой АКБ. Вопрос собственно сводится к следующему: какой именно из двух компонентов (генератор или модуль BDM) «сажает» шину? А если это не делает ни тот и ни другой, то проблема, очевидно, в самой шине, т.е. в проводке.
Надо бы посмотреть что там, на шине происходит. Берём осциллограф и с помощью акупунктурного адаптера подключаем его измерительный кабель к разъёму генератора (фото 3).

Фото 3 — подключение к шине LIN-bus

Собственно, к генератору больше никаких проводов не подходит (кроме силового плюса, естественно). Согласитесь, есть в цифровых шинах свое скромное обаяние. Один провод и всё – больше ничего не нужно. Изящно, ничего не скажешь. Итак, что там у нас на этом проводе? А на этом проводе имеется постоянное напряжение порядка 14 Вольт (экран 7).

Экран 7 — напряжение на шине Lin-bus

А что показывает сканер? Для контроля состояния данной шины входим в режим текущих параметров «Dynamic Requests», и выбираем группу 6. Да, всё верно, статусы коммуникации и с генератором, и с модулем BDM имеют значение 0, а это значит, что коммуникация как таковая, отсутствует (экран 8).

Экран 8 — статусы коммункации по шине LIN-bus

Всё сходится. Похоже, шина просто замкнута на «плюс». Где именно? Либо в генераторе, либо в датчике тока, либо в жгуте. Что в этой ситуации самое простое? Конечно, отключить разъём от генератора (фото 4).

Фото 4 — отсоединяем разъём, но остаёмся на шине

Вот собственно и всё – сразу пошёл обмен данными (экран 9). И сканер это подтверждает (экран 10). Появилась связь с датчиком тока, ну а с генератором, понятное дело коммуникация отсутствует, разъём-то от него отключен.

Экран 9 — обмен данными восстановился
Экран 10 — теперь Gateway «видит» модуль BDM

Яснее ясного, что проблема кроется где-то внутри генератора. Демонтируем его с автомобиля, чтобы отвезти в ремонт (фото 5).

Фото 5 — демонитруем генератор

И при внимательном рассмотрении обнаруживаем, что там уже побывали шаловливые ручонки. На внутренней поверхности разъёма отчётливо видны следы работы паяльником (фото 6).

Фото 6 -следы работы паяльником

Связываемся с хозяйкой автомобиля – оказывается, недавно генератор уже ремонтировали по причине полного отсутствия зарядки. Теперь, какая-никакая зарядка есть, да вот незадача — локальная шина села на «плюс». Не знаю, в какой компании производился ремонт, но что-то там ребята намутили. И в целом, энергетический баланс хотя и положительный, но, очевидно, полного соответствия условиям эксплуатации добиться не удаётся. Поэтому батарея всегда полупустая.
Повторно отремонтированный генератор мои коллеги устанавливали уже без моего участия. Так что никаких дополнительных экранов или осциллограмм привести не могу. Но, надеюсь и так всё понятно. А что же автомобиль? Автомобиль уже почти месяц работает как часы.

AVR308

В данном примере применения описано как реализовать подчиненную LIN (локальная коммутационная сеть) задачу на 8 разрядном AVR RISC микроконтроллере без всяких внешних компонентов.

Протокол LIN — последовательный коммуникационный протокол, который эффективно поддерживает управление механическими узлами распределенных сетей. Это делает его идеальным протоколом для использования в автомобильных системах. LIN сеть состоит из единственного ведущего и множества подчиненных узлов. В данном примере применения описывается как реализовать протокол на физическом уровне и на уровне передачи данных в соответствии с двумя эталонными моделями низкого уровня ISO/OSI. Это фундаментальная основа для реализации передачи сообщений между точками распределенной сети. Физический уровень ISO/OSI моделей обеспечивает только передачу необработанных пакетов между двумя точками распределенной сети. Уровень передачи данных делает физический уровень более надежным за счет реализации обнаружения ошибок и управления. Также этот уровень добавляет средства для активизации, поддержания в активном состоянии и отключения соединения. Высшие уровни эталонных моделей ISO/OSI не относятся к LIN протоколу и поэтому в данном примере применения не рассматриваются.

• Один ведущий, множество подчиненных.
• Низкая стоимость полупроводниковых приборов.
• Для синхронизации подчиненных узлов не требуются кварцевые или керамические резонаторы.
• Гарантия времени ожидания для передачи сигналов.
• Однопроводная линия связи.
• Скорость передачи данных до 20 кбит/с.

Рисунок 1. Топология LIN сети

Концепция протокола LIN

Один ведущий, несколько ведомых

Протокол LIN не использует управление доступом к шине. За передачу всех сообщений отвечает ведущий. Все подчиненные (ведомые) могут реагировать на сообщения ведущего или других узлов сети, но отвечать они могут только будучи адресованными ведущим и получив от него разрешение.

Переменная длина кадров данных

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

После того, как кадр сообщения послан ведущим или ведомым, все подключенные узлы могут его получить. В зависимости от содержимого байта идентификатора, принимающие точки определяют, должны ли они реагировать на данное сообщение или нет. Например, в автомобильной охранной системе одна команда «CLOSE ALL», переданная ведущим, приведет к тому, что все подчиненные выполнят соответствующие действия по закрытию дверей и окон.

Временная синхронизация, не требующая применения в едущих узлах кварцевых или керамических резонаторов

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

Проверка контрольной суммы и детектирование ошибок

Для обнаружения ошибок в данных кадра сообщения используется инвертированная по модулю 256 контрольная сумма с переносом старшего бита в младший разряд. Кроме того, идентификационный байт использует для обнаружения ошибок XOR алгоритм.

Обнаружение поврежденных точек сети

Ведущая задача ответственна за инициализацию передачи кадров сообщения и, таким образом несет ответственность, за информацию и проверяет, все ли узлы сети подключены к питанию и работают правильно.

Минимальная стоимость системы

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

Шина LIN состоит из одного канала, по которому передаются синхросигналы и данные. Физическая среда этого канала — однопроводная линия, подключенная через подтягивающий резистор к шине питания VCC (см. рисунок 1). Высокий или «рецессивный» сигнал на шине показывает, что она свободна, а низкий или «доминантный» — что она занята. Обычно в автомобильных системах VCC является положительным потенциалом.

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

В соответствии с требованиями к уровню паразитных ЭМИ, возникающих при передаче данных по однопроводным линиям связи, скорость передачи данных равняется 20 кбит/с.

• Разрыв синхронизации
• Поле синхронизации
• Идентификационное поле
• Поле данных
• Поле контрольной суммы

Рисунок 2. Кадр сообщения LIN

Кадр сообщения состоит из двух частей: «заголовок», посланный ведущим и «ответ», который может формироваться как ведущей, так и подчиненной задачей.

Формат байтовых полей, показанный на рисунке 3, идентичен формату данных стандарта UART с кодированием 8N1. Это означает, что каждое байтовое поле содержит старт бит, 8 бит данных, стоп бит и не содержит бита проверки на четность. Таким образом, каждое байтовое поле содержит 10 бит (Tbit). Как показано на рисунке 3, старт бит указывает на начало байтового поля и является «доминирующим», в то время как стоп бит является «рецессивным». Восемь информационных битов могут быть как «доминирующими», так и «рецессивными».

Рисунок 3. Байтовое поле LIN

Поле разрыва синхронизации

Поле разрыва синхронизации указывает на начало передачи кадра сообщения. Это поле всегда передается ведущей задачей и указывает на необходимость подчиненным подготовиться к приему поля синхронизации. Поле разрыва синхронизации состоит из двух частей: первая часть имеет доминирующей (низкий) уровень, длительность которого должна быть не менее 13 периодов байтового поля (Tbit), а вторая — рецессивной (высокий) уровень, длительность которого должна быть не менее четырех Tbit. Вторая часть поля необходима для обеспечения возможности обнаружения стартового бита следующего поля синхронизации.

Рисунок 4. Поле разрыва синхронизации

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

Поле синхронизации содержит сигналы, необходимые для синхронизации задающих генераторов подчиненных устройств сети. Поле синхронизации является байтовым полем, имеющем значение «0x55». Временная диаграмма этого поля приведена на рисунке 5.

Рисунок 5. Поле синхронизации

Как видно из рисунка, поле синхронизации содержит пять спадающих фронтов (пять переходов от рецессивного к доминантному состоянию).

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

Идентификационное поле содержит информацию о содержимом и длине сообщения. Как показано на рисунке 6, это поле разделено на три секции: идентификационные биты (4 бита), служебные биты, указывающие на длину сообщения (2 бита) и биты проверки на четность (2 бита). Таким образом происходит деление 64 идентификационных номеров на четыре комплекта, каждый из которых содержит 16 идентификаторов.

Рисунок 6. Идентификационное поле

В соответствии с LIN протоколом количество полей данных в кадре данных определяется по приведенной ниже таблице 1.

Таблица 1. Количество полей данных в кадре данных

ID5	ID4	NDATA (количество полей данных)
0	0	2
0	1	2
1	0	4
1	1	8

Как видно из таблицы 1 есть две группы с двумя полями данных, одна группа с четырьмя полями данных и одна группа с восьмью полями данных. Обратите внимание, что в идентификационном поле не описывается длина сообщения, а только указывается содержание кадра сообщения. Это позволяет приемникам подчиненных задач определить все ли были приняты данные или нет. Последние два бита идентификационного поля являются битами проверки на четность. LIN использует алгоритм смешанного контроля четности, который гарантирует, что идентификационное поле никогда не будет состоять из одних «рецессивных» или «доминантны» символов. Следует заметить, что этот алгоритм позволяет только обнаруживать ошибки, но не исправляет их.

Биты проверки на четность формируются в соответствии с приведенными ниже формулами:

P0 = ID0 xor ID1 xor ID2 xor ID4 P1 = ID1 xor ID3 xor ID4 xor ID5

Кадр данных включает в себя от двух до восьми полей данных, каждое из которых содержит восемь бит. Передача данных осуществляется старшим значащим битом (СЗБ) вперед. Поля данных записываются соответствующими подчиненными задачами. Так как нет никакого управления доступом к шине, то только одна подчиненная задача должна реагировать на идентификатор. Все остальные подчиненные задачи могут только принимать ответное сообщение и выполнять соответствующие действия.

Рисунок 7. Поле данных

Поле контрольной суммы

Последним полем в кадре сообщения является поле контрольной суммы. Этот байт содержит инвертированную сумму по модулю 256 всех байтов данных (кадр данных не включает идентификатор). Эта сумма рассчитывается путем суммирования с переносом всех байтов и инвертирования полученного результата. Свойства инвертированной суммы по модулю 256 таково, что если ее сложить с суммой всех байтов данных, то результат будет равен «0xFF».

Рисунок 8. Поле контрольной суммы

Кадр дежурного режима

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

Рисунок 9. Кадр дежурного режима

Режим сна (дежурный режим) может быть закончен путем посылки любой подчиненной задачей сигнала активизации (пробуждения). Сигнал пробуждения возможно сформировать только в том случае, когда шина находится в режиме сна и внутренние узлы отслеживают его. Сигнал пробуждения — это кодовая комбинация «0x80».

Рисунок 10. Кадр сигнала активизации

В зависимости от того, синхронизирована ли подчиненная задачи с ведущей задачей, скорость ее может быть отличной от скорости приемника ведущего устройства. По этой причине приемник ведущего устройства может идентифицировать переданный сигнал «0x80» как «0xC0», «0x80» или «0x00». Все эти сигналы будут восприняты как правильный сигнал пробуждения, и подчиненные устройства будут ожидать поля разрыва синхронизации от ведущего. Если в течение 128 Tbit не будет обнаружен этот сигнал, то сигнал пробуждения будет игнорирован. Так будет повторяться трижды. Перед посылкой нового запроса на пробуждения ведущее устройство будет ждать не менее 15 000 Tbit. В описываемом примере применения разграничитель пробуждения имеет значение 64 Tbit.

LIN протокол обеспечивает обнаружение ошибок как в идентификационном поле, так и в поле данных. Исправление ошибок не предусмотрено, поэтому единственный путь — автоматический повтор передачи поврежденных данных. Для выяснения правильности приема ведущий опрашивает подчиненных.

LIN протокол не определяет процедуру подтверждения для корректности принятия сообщения. Управляющий модуль ведущего устройства сравнивает переданные данные с полученными от своей собственной подчиненной задачи. Если данные идентичны, то принимается решение о правильности передачи данных. Если же имеется расхождение в этих данных, то ведущий может повторить передачу сообщения.

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

Теоретически максимальное количество узлов в LIN сети не ограничено. Реально же, количество узлов будет ограничено шумами, задержками и электрической нагрузкой шины. Желательно, чтобы количество узлов в сети не превышало 16. В принципе, протокол поддерживает до 63 удаленных точек. Также LIN протокол требует, чтобы общая длина проводов не превышала 40 метров. Импеданс ведущего устройства должен быть порядка 1 кОм, а подчиненных — 20 — 47 кОм.

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

Сообщение считается правильным если в пределах кадра сообщения не было обнаружено ошибок. Если в сообщении имеется ошибка, то принимается решение, что передачу данных не осуществлял ни ведущий, ни ведомый.

• «Ошибочный бит» в данных или контрольной сумме при считывании своего собственного сообщения.
• «Ошибка контроля четности идентификатора» или «Ошибка контрольной суммы» при считывании данных с шины.
• «Ведущий не реагирует на ошибку» при считывании данных с шины.
• «Противоречивая ошибка байта синхронизации» при отсутствии обнаружения в допустимых пределах фронта сигнала синхронизации.

Обычно встроенные RC генераторы имеют большой допустимый диапазон (например, от -50 % до +100 %). LIN протокол требует, чтобы частота подчиненного отличалась от частоты ведущего не более, чем на 15 %. В длительности кадра отклонение частоты не должно превышать +-2 %. Эти требования должны выполняться во всем рабочем температурном диапазоне и при всех допустимых напряжениях питания.

В данном разделе описывается реализация различных частей программы. Управляющая программа состоит из семи различных подпрограмм.

Таблица 2. Реализованные функции

Функция	Описание	Вызывающее событие
main	Основная программа	Сброс
ext_int0	Обработчик внешнего прерывания INT0	Спадающий фронт на выводе PIND2
check_parity	Высчитывает количество доминантных бит в переданной переменной	ext_int0
tim0_ovf	Вызывается при переполнении нулевого таймера/счетчика при расчете длительности бита	аппаратный нулевой таймер/счетчик
putchar	Передача данных по LIN шине	ext_int0
delay	Основная подпрограмма формирования задержки	ext_int0
wakeup	Посылает ведущему сигнал пробуждения	Пользовательская подпрограмма

В описываемом примере применения основная программа не выполняет никаких действий. В нее можно поместить код прикладной программы пользователя. Обратите внимание, что микроконтроллер AT90S1200 не имеет СОЗУ, а использует вместо него трехуровневый аппаратный стек. Если используется более трех уровней, то происходит перезапись первого значения последним. Это ведет к непредсказуемости выполняемой программы. Когда происходит внешнее прерывание, то вызывается подпрограмма обработки прерывания. При приеме данных вызывается подпрограмма check_parity, а при передаче — подпрограмма putchar. Таким образом, два уровня стека используется под внешние прерывания. Поэтому важно, чтобы прикладная программа пользователя не использовала больше одного уровня стека.

Рисунок 11. Байт состояния

При обнаружении ошибки бита или ошибки контрольной суммы устанавливаются соответствующие биты регистра состояния (Status: r20). После считывания эти биты должны быть сброшены. Основная программа должна непрерывно опрашивать флаг дежурного режима. Когда обнаруживается, что этот флаг установлен, то микроконтроллер AT90S1200 может быть введен в режим сна при помощи следующей последовательности команд:

ldi r23, (1 <
При обнаружении активности шины микроконтроллер выходит из дежурного режима и запускает подпрограмму ext_int0. Подпрограмма LIN интерфейса имеет размер 181 слово, поэтому размер пользовательской программы может достигнуть 331 слова (662 байта). В сумме получается 512 слов (1 Кбайт).
Подпрограмма обслуживания нулевого внешнего прерывания: ext_int0

Режим 1: программа ожидает принятие секции разрыва синхронизации.
Режим 2: программа ожидает принятия синхронизирующего байта.
Режим 4: программа ожидает принятия идентификатора.

На рисунке 12 показана блок-схема программы ext_int0.
В режиме 1 подпрограмма отслеживает последующие 11 бит. Длительность бита принимается такой же, как и при последней передаче. После принятии 11 битов устанавливается режим 2.
В режиме 2 по первому срезу сигнала запускается таймер. Программа отслеживает пять спадающих фронтов и после этого останавливает таймер (см. рисунок 5). Содержимое таймера делится на 8 и таким образом вычисляется длительность импульса.
В режиме 4 считывается принятый идентификатор. Сначала проверяется, не является ли принятый идентификатор командой активизации режима сна. Если же принятая секция не является такой командой, то идентификатор сравнивается с внутренним шаблоном. Если переданный идентификатор принадлежит устройству, то выполняется проверка на четность. После этого формируется контрольная сумма и пересылается вместе с данными.
Рисунок 12. Блок-схема подпрограммы обработки прерывания ext_int0
Эта подпрограмма считает количество принятых бит во внутреннюю переменную. Если количество четное, то МЗБ переменной количества битов будет равно 0. Если количество нечетное, то МЗБ переменной будет равняться 1. Этот бит используется для формирования бита контроля на четность.
Подпрограмма обработки переполнения нулевого таймера: tim0_ovf
Нулевой таймер/счетчик, используемый в данном примере применения является восьмибитным. Для обеспечения возможности отслеживания восьми длительностей бита эта подпрограмма, вызываемая при переполнении нулевого таймера, увеличивает значение вспомогательной переменной. Объединение вспомогательной переменной с содержимым первого таймера/счетчика дает 16 битное число, используемое для формирования длительности восьми бит. Деление этого значения на восемь формирует длительность бита. AVR микроконтроллер работает на частоте 1 МГц, и его счетчик увеличивает каждый тактовый цикл. Таким образом, длительность бита формируется непосредственно в микросекундах.
Подпрограмма putchar используется для передачи данных по LIN шине. При передаче нуля в регистре Port Register вывод PIND2 устанавливается на работу в режиме выхода. При передаче единицы линия порта устанавливается на работу в режиме входа, и встроенный подтягивающий резистор подтягивает линию к положительной шине питания. Это эквивалентно закрытому выходу каскада с открытым коллектором. Передаваемые и принимаемые данные накапливаются в регистрах data1 - datan и rx - rx+n. В зависимости от того, какое количество определено в идентификационном поле, подчиненное устройство передает два, четыре или восемь байт. Константа data_addr определяет адрес первого передаваемого регистра.
Эта подпрограмма формирует задержку в циклах, определяемую выражением [temp2] +- 1. Используется она для формирования задержки между выбираемыми битами.
Вызвав эту подпрограмму из основной программы, можно сформировать сигнал пробуждения шины. Программа не используется подпрограммой ext_int0.
Размышления по поводу аппаратной части
Стандарт LIN определяет диапазон уровня доминантного сигнала от 9 В до 18 В (40 В в нерабочем состоянии). Описываемое устройство предназначено для работы на 5 В LIN шине. Так как AVR микроконтроллер, используемый в этом применении, работает от 5 В источника питания, то самым разумным было бы использовать 5 В LIN шину. Если же такая шина не может быть использована, то необходимо обеспечить преобразование уровней LIN шины. Существует два простейших метода обеспечения такого преобразования
В нем используется один полевой транзистор. Схема включения его показана на рисунке 13.
Рисунок 13. Преобразование 5 В интерфейса в 12 В при помощи одного полевого транзистора
На рисунке 14 показано, как можно обеспечить преобразование уровней при помощи двух биполярных транзисторов. Следует заметить, что при этом у микроконтроллера разделяются линии приема и передачи.
Рисунок 14. Преобразование 5 В интерфейса в 12 В при помощи двух биполярных транзисторов

Подпрограмма putchar должна формировать передаваемые данные на выводе Tx, а не на выводе PIND2 (Rx).
Данные на вывод Tx должны поступать без инверсии.
Вывод Tx должен быть установлен на работу в режиме выхода.
Принятые данные должны быть инвертированы.



141 Kb Engl AVR308 Исходный фаил


Пример программы


Мир автомобилей Volkswagen

 Автомобильное зеркало заднего вида Blackview с видеорегистратором и GPS
Ознакомьтесь

Массаж выезд круглосуточно 24 часа массаж для мужчин 24 часа.
Описание полотенцесушитель электрический лесенка на сайте.

Популярные записи

Магнитола RCD 310
Датчик частоты вращения выходного вала G195
Переключатель Tiptronic F189
Магнитола RCD 210
Клапан управления фазами газораспределения N205
Аккамулятор Crafter VW
Бензиновый двигатель модели AQY
Датчики температуры охлаждающей жидкости
Датчик температуры масла G93
Освещение Volkswagen Crafter
Бензиновый двигатель (V6, 3.2 л)
Система отопления и вентиляции VW Crafter
Системы шин данных CAN, применяемые на автомобилях концерна VW
Охлаждение топлива в двигателе 1.9 л TDI Volkswagen
Замена батареи

 Электрооборудование: шина LIN-Bus 

LIN — это сокращение от Local Interconnect Network.
Расширенное применение электроники на автомобиле обусловлено повышением требований к расширению функциональных и эргономических характеристик систем управления.
Применение многочисленных электронных приборов вызвало необходимость поиска новых способов обмена данными между ними.
Эта ситуация оказалась актуальной также для автомобиля Audi A8 модели 2003 года, на котором установлено более 70 электронных блоков управления, нуждающихся в обмене данными между ними.
Помимо известной (двухпроводной) шины данных CAN используются следующие устройства обмена данными:
– однопроводная шина LIN, 
– оптическая шина MOST, 
– беспроводная связь BluetoothTM
Помимо известной (двухпроводной) шины данных CAN используются следующие устройства обмена данными:
– однопроводная шина LIN, 
– оптическая шина MOST, 
– беспроводная связь BluetoothTM
LIN — это сокращение от Local Interconnect Network. Local Interconnect означает, что все связанные между собой блоки управления расположены в пределах определенного ограниченного пространства (например, крыши). Для этого применяется также выражение «lokales Subsystem».
Обмен данными между различными шинами LIN конкретного автомобиля производится посредством специального блока управления через шину CAN.
Шина LIN является однопроводной. Eе провод окрашен в фиолетовый цвет, поверх которого нанесена цветная маркировка. Сечение провода равно 0,35 мм2. Применение экрана для этой шины не обязательно.
Шина обеспечивает обмен данными между ведущим блоком управления LIN-Master и ведомыми блоками управления LIN-Slave, число которых может достигать 16.
Что такое шина LIN

Шина LIN – это простая последовательная однопроводная шина для автомобильных применений и используется в тех случаях когда применение CAN шины – дорого. По шине LIN управляются различные приводы (корректоры фар, заслонки климатической системы, приводы центрального замка), а так же собирается информация с простых датчиков (датчики дождя, света, температуры).
Для изучения шины LIN Вы можете использовать наш адаптер CAN-Hacker 3.0 с дополнительной опцией LIN анализатора. 
А так же интерфейс CAN-Hacker CH-P
Пример системы управления дверью с шиной LIN и без нее:

Еще пример, в автомобиле Porsche Macan 2015 г. все привода и датчики климатической системы подключены к шине LIN а сам блок климат контроля связан с автомобилем при помощи CAN шины.
Дешевизна LIN обусловлена тем что реализация протокола LIN полностью программная и строится на базе обычного UART (родственник RS232, COM порт). Так же LIN не требует применения точных времязадающих цепей – кварцевых резонаторов и генераторов. Поэтому можно применять дешевые микроконтроллеры.
Скорость передачи данных
Скорость передачи данных на шине LIN стандартная для устройств построенных на базе UART: 2400; 9600; 10400; 19200; 20000 Бод. Это немного но достаточно для передачи данных от датчиков и для управления медленными механизмами.
Электрическая реализация LIN
Электрически интерфейс LIN реализован так же просто. В каждом узле линия шины подтянута к шине питания +12V. Передача осуществляется опусканием уровня шины до уровня массы GND. Микроконтроллер подключается к шине LIN при помощи специальной микросхемы Трансивера, например TJA1021

Подключение LIN трансивера к микроконтроллеру

Архитектура сети LIN

Особенностью шины LIN является то, что в сети присутствует два вида узлов: Master и Slave, Master – ведущий, Slave – подчиненный.
Master может опрашивать Slave о его состоянии, будить его, отправлять ему команды. Обмен информации на шине LIN происходит в формате обмена пакетами, и на первый взгляд может показаться что механизм идентичен шине CAN, это не так. Объясняем почему:
Структура LIN пакета выглядит так: 

Frame – Header – заголовок кадра, который отправляется в шину Мастером. Включает в себя ID кадра
Frame – Response – данные которые отправляет Slave в ответ на запрос Master -а.
Уловите разницу – в шине CAN все узлы передают и ID кадра и данные. В шине LIN – заголовок пакета это задача Мастер-узла. 

Поле Frame-Header состоит из полей:
BREAK – Это сигнал шине о том что мастер сейчас будет говорить
Поле синхронизации – это просто байт = 0x55. При его передаче приемники подстраивают свою скорость.
PID – это поле защищенного идентификатора. В дальнейшем будем писать просто – идентификатор.
Идентификатор может принимать значения от 0 до 59 (0x3B в HEX) для пользовательских пакетов. Так же возможно использование специальных служебных пакетов с ID 0x3C, 0x3D, 0x3E и 0x3F. Защищенность идентификатора заключена в следующем:

В структуре байта ID мы видим биты собственно самого идентификатора с ID0 по ID5, а затем идут два контрольных бита P0 и P1, которые рассчитываются так:
P0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4 
P1 = ¬ (ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5)
ID = 0x00 PID =0x80
ID = 0x0C PID = 0x4C
Если в PID контрольные биты рассчитаны неверно то пакет не будет обработан принимающей стороной.
В случае если мы будем эмулировать работу какого либо узла Master, предварительно изучив отправляемые им данные при помощи LIN сниффера, то нам не придется задумываться о расчете контрольных битов ID, поскольку в пакетах которые мы видим сниффером все уже посчитано до нас.
После того как Slave принял Header мастера он отвечает полем Frame Response который состоит из байтов данных в количестве от 1 до 8 и байта контрольной суммы.
Контрольная сумма (CRC) считается как инвертированная сумма всех байтов данных с переносом либо сумма всех байтов данных + значение защищенного ID . В первом случае CRC называется классической, во втором – расширенной. Вариант подсчета контрольной суммы определяется версией стандарта шины LIN. В версиях 1.xx применяется классический алгоритм, в версиях 2.xx применяется расширенный.
Обратите внимание на отсутствие поля DLC отвечающего за количество байтов данных как в CAN шине. В шине LIN количество байтов данных определяется на этапе написания ПО контроллера. Поэтому процесс обмена на шине LIN сложнее анализировать при помощи сниффера – приходится вводить специальный алгоритм разделения пакетов, который угадывает сколько байтов данных было в принятом пакете.

На этой схеме мы видим как один Мастер общается с двумя узлами Slave. Обратите внимание на третий кадр, в нем заголовок Header и тело пакета Response передает Мастер – это важный момент, такие кадры используются для диагностики и конфигурирования Slave узлов.
На осциллограмме обмен одного Master и одного Slave выглядит так:

Здесь мы видим запрос мастера состоящий из полей Break – S – затем следует ответ узла Slave состоящий из четырех байт и контрольной суммы равной 0x3F.
Если мы отключим узел Slave от шины LIN, то увидим уже такую осциллограмму:

Так же в протоколе шины LIN предусмотрены и специальные служебные пакеты служащие для диагностики шины, пробуждения устройств и других функций. В этом случае Master может передавать как Frame Header так и Frame Response последовательно, тогда пакет Master -а может иметь такой вид:
ID=0x3C DATA : FF FF FF FF FF FF FF FF 
Обмен диагностическими сообщениями на шине LIN выглядит так :

При помощи длинных пакетов Master может конфигурировать и программировать узлы Slave. Если для программирования или конфигурирования узла LIN необходимо более 8 байт, то поток данных сегментируется и пересылается частями. Механика передачи данных определяется специальным транспортным протоколом работающим поверх физики шины LIN, о нем мы напишем в следующих статьях.
Видео пример работы с шиной LIN и адаптером CAN-Hacker 3.2


Похожие публикации:

Антифриз стал как кисель в чем причина
Как узнать уровень омывающей жидкости
Какие свечи зажигания лучше иридиевые или платиновые
Когда заливают масло 5w40