Что такое лин шина в автомобиле?

Что такое лин шина в автомобиле?

Диагностика и ремонт: Шина системы Lin

В середине 90-х годов для обеспечения безопасности и комфорта на автомобиле «представительского» класса могло быть от 10 до 15 блоков управления.
В настоящее время такого количества блоков управления уже недостаточно, оно увеличилось, возможно, в два раза (или больше).

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

И в настоящий момент уже существуют следующие технологии передачи данных:
– шина LIN (однопроводная шина)
– шина MOST (оптоволоконная шина)
– беспроводная шина Bluetoot h

В данной статье мы рассмотрим шину LIN .

Шина под названием » LIN » — это сокращение от полного названия: » Local Interconnect Network «, то есть, «локальная коммутируемая сеть».
Это означает. что все коммутируемые блоки управлению подключены и располагаются в пределах одного ограниченного пространства, например, крыши автомобиля, двери автомобиля и так далее.
Обмен данными между коммутируемыми блоками системы LIN происходят по шине данных CAN .
У шины LIN есть особенность: она однопроводная.

Цвет изоляции провода — фиолетовый (на нем может быть цветная маркировка).
Толщина провода (площадь поперечного сечения) составляет около 0.35 мм2.
Провода шины LIN экранировать не обязательно.

Однако, как уже говорилось, скорости передачи данных по шине CAN и шине LIN различные.
Различными также являются и сигналы.

Для этого был придуман так называемый «Блок управления LIN-Master «, который является своеобразным «переводчиком» между шиной LIN и шиной CAN :

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

Итак, что такое LIN Master мы разобрались.
Но есть еще такое понятие, как LIN Slave .

Это не что иное, как исполнительные механизмы, электронные или электронномеханические узлы или блоки, получающие команды от блока LIN Master .
Но не только команды.

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

Как видно из фото 1, для нескольких исполнительных механизмов требуется только один контакт () в блоке pin LIN Master .

Скорость передачи данных в шине LIN невысокая и составляет приблизительно от 5 до 25 кбитсек.

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

Доминантный уровень

Для передачи доминирующего бита по шине данных LIN в передающем блоке управления шина данных замыкается на массу через приемопередатчик (трансивер) — см. фото 2 :

Надежность и стабильность передачи данных обеспечивается установлением определенных допусков в сигналах на рецессивном и доминантном уровнях.

Между блоками Slave и Master постоянно «курсируют» телеграммы определенной формы.

Блок управления LIN Master периодически посылает телеграммы, которые строго разделены на четыре составляющие:

1 — пауза в синхронизации
2 — ограничение синхронизации
3 — поле синхронизации
4 — поле идентификатора

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

Поле синхронизации требуется для того, что бы все исполнительные блоки могли настроиться или проверить свои настройки перед приемом телеграммы — оно состоит из строго определенной последовательности битов 0101010101.

LIN — цифровая шина в автомобиле

LIN -шина, это однопроводная цифровая шина для управления по одному проводу группой разнообразных исполнительных устройств, широко применяемая в современных автомобилях. Например двигателями заслонок климата, корректорами фар, замками и стеклоподъемниками дверей и т.п. Конкретно у меня сейчас стоит задача заставить управлять шаговыми двигателями корректора фар. Шаговые двигатели управляются драйвером-контроллером AMIS-30621 Моя задача сделать контроллер, который бы умел контролировать и управлять шаговыми моторчиками корректора фар. А чтоб сделать контроллер, необходимо изучить сам протокол данных LIN и конкретно сам даташит драйвера.
Протокол LIN достаточно не сложный, не быстрый, но при этом надежный и в общем мне очень понравился. В даташитах все подробно описано, я лишь пробегусь вкратце. Если кратко, то цифровая посылка LIN контроллера состоит из этого:

Sync Break — передача данных всегда начинается с притягиванию к нулю шины не менее чем на 13 тактов. Увидев эту притяжку, все устройства на шине оживают, и понимают, что сейчас пойдет что то интересное и начинают ждать. А далее следует:
Sync Field — сигнал синхронизации. Все устройства на шине обязаны подстроится под этот сигнал и подстроить свои тактовые сигналы.
PID Field — служебный байт, который содержит адрес конкретного устройства на шине, последующую длину данных байт и два бита контроля ошибок
Data — передаваемые данные, до восьми байт
Checksum — контрольная сумма

Общее описание стало понятно, пора было собрать макетную плату контроллера шины.
За основу взят микроконтроллер ATTiny13 и транслятор-приемник шины LIN TJA1020 Регулятор положения сделан на обычном энкодере. Вот получилась такая схема:

Далее пошло изучение даташита контроллера шагового мотора. AMIS-30621 это контроллер последнего поколения, который включает в себя все, что можно. Он имеет ЦАП, контроль тока, контроль температуры, напряжения, режим разгона-торможения, настройку силы тока и еще кучу настраиваемых параметров. Достаточно ему подать команду, насколько нужно нашагать, остальное полностью он делает сам. Очень умный драйвер короче. Даташит немного замудреный, много неясностей было при прочтении, но в итоге удалось оживить этого монстра, читать с него данные и управлять им. Вот пример из анализатора:

А вот пример из кода:
Сначала нужно считать данные состояния, это обязательное условие из даташита:
void GetFullStatus (void)
<
// PREPARING FRAME
SyncLIN (); // Sync Break и Sync Field
DataTX(0b00111100); // Identifier
DataTX(0x80); // AppCMD
DataTX(0x81); // CMD
DataTX(0b11110000); // slave address
DataTX(0xff); // DATA
DataTX(0xff); // DATA
DataTX(0xff); // DATA
DataTX(0xff); // DATA
DataTX(0xff); // DATA
DataTX(0b00001101); // CHK байт контроля ошибок

// READING FRAME
SyncLIN (); // Sync Break и Sync Field
DataTX(0B01111101);

В ответ драйвер мотора посылает восемь байт своего состояния, после этого можно слать команду установки на нужную позицию — мотор оживает и делает нужное количество шагов:
SyncLIN ();// Sync Break и Sync Field
DataTX(0x3c); // Identifier
DataTX(0x80); // AppCMD
DataTX(0x8b); // CMD
DataTX(0xf0); // AD1[6:0] slave address 1 шагового мотора
DataTX(0x55); // DATA нужная позиция 1 мотора (16 бит, поэтому в два захода)
DataTX(0xff); // DATA нужная позиция 1 мотора
DataTX(0xNN); // DATA slave address 2-го шагового мотора
DataTX(0xNN); // DATA нужная позиция 2 мотора (16 бит, поэтому в два захода)
DataTX(0xNN); // DATA нужная позиция 2 мотора
DataTX(0xNN); // CHK контрольная сумма

Это минимальный код, заставляющий двигаться шаговый мотор. В железе это вышло так:

Внизу: плата контроллера
Слева: программатор
Вверху: шаговый мотор и драйвер

Плата драйвера крупнее:

В итоге можно организовать корректор вертикального положения фар, управляемый при помощи энкодера (управлять шаговым мотором при помощи шагового энкодера — что может быть лучше?) с отдельным управлением левой и правой фарой (для сервисной настройки фар) с возможностью оперативного изменения угла энкодером и все это от одного управляющего проводка.

Что такое шина 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

Автомобильный справочник

для настоящих любителей техники

LIN шина

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

Первая спецификация стандарта под брендом LIN была издана в 1999 году по инициативе консорциума европейских автопроизводителей и других известных компаний, включая Audi AG, BMW AG, Daimler Chrysler AG, Motorola Inc., Volcano Communications Technologies AB, Volkswagen AG и VolvoCar Corporation. Последняя спецификация, LIN 2.2, издана в 2010 году. В настоящее время документы стандарта переданы под контроль Международной организации по стандартизации (ISO), где стандарту был присвоено новое наименование ISO 17987. В связи с политикой ISO копия стандарта стала платной.

Шина LIN

LIN шина (локальная сеть воздействия) была разработана для удовлетворения потребно­стей в связи для систем класса А (см. табл. «Классификация шинных систем» ) с использованием самого экономичного обо­рудования. Типичные области применения:

• Дверной модуль с дверным замком;
• Приводы стеклоподъемников;
• Регулировка боковых зеркал заднего вида;
• Система кондиционирования (передача сигналов от элемента управления, актива­ция вентилятора свежего воздуха).

Текущую спецификацию LIN можно найти на сайте консорциума LIN.

Важные особенности шины LIN:

• Концепции с одним ведущим и несколь­кими ведомыми устройствами;
• Небольшая стоимость оборудования за счет передачи данных по неэкранированному однопроводному кабелю;
• Самосинхронизация ведомых устройств без кварцевого генератора;
• Связь в виде очень коротких сообщений;
• Скорость передачи данных до 20 кбит/с;
• Длина шины до 40 м, до 16 узлов.

Система передачи в шине LIN

Шина LIN представляет собой неэкранированный однопроводный кабель. Уровень шины может принимать два логических состояния. Доминантный уровень соответствует напря­жению приблизительно 0 В (масса) и пред­ставляет собой логический 0. Рецессивный Уровень соответствует напряжению батареи U_batt и представляет собой логическую 1.

Из-за наличия разных вариантов электри­ческих цепей уровни могут быть разными. Определение допусков на передачу и прием в области рецессивных и доминантных уровней обеспечивает стабильную передачу данных. Диапазоны допусков шире на приемном конце (рис. «Уровень напряжения на линии данных шины LIN» ), чтобы действительные сигналы тоже можно было получать, несмотря па излучаемые помехи.

Скорость передачи по шине LIN ограничена величиной 20 кбит/с. Это компромисс между большой крутизной фронта импульсов, не­обходимой для синхронизации ведомых устройств, с одной стороны, и небольшой его крутизной, необходимой для улучшения ЕМС — с другой. Рекомендуемая скорость передачи составляют 2400, 9600 и 19200 бит/с. Минимально допустимая скорость составляет 1 кбит/с.

Максимальное количество узлов не регла­ментируется в спецификации LIN. Теоретиче­ски оно ограничено количеством доступных идентификаторов сообщений. Возможности линии и узла и крутизна фронта импульсов ограничивают сочетание длины и количества узлов сети LIN. Рекомендуется не более 16 узлов.

Пользователи шины обычно располага­ются в линейной топологии; однако эта топо­логия не является обязательной.

Доступ к шине LIN

Доступ к шине LIN обеспечивается на основе доступа «ведущий-ведомый». В сети имеется ведущее устройство, инициирующее каждое сообщение. Ведомое устройство имеет воз­можность ответить. Обмен сообщениями происходит между ведущим и одним, не­сколькими либо всеми ведомыми устрой­ствами.

Во время обмена сообщениями между ве­дущим и ведомым устройством возможны следующие взаимосвязи:

• Сообщение с ответом ведомого: ведущее устройство передает сообщение одному или нескольким ведомым устройствам и запрашивает данные (например, состояния измеренных значений);
• Сообщение с инструкцией ведущего: веду­щее устройство передает инструкции ве­домому устройству (например, включение сервопривода);
• Сообщение для использования: ведущее устройство инициирует связь между двумя ведомыми устройствами.

Протокол LIN

Фрейм данных LIN

Информация на шине LIN встраивается в определенный фрейм данных, фрейм LIN (рис. «Фрейм LIN» ). Инициированное ведущим устрой­ством сообщение начинается с заголовка. В поле сообщения (ответ) содержится раз­личная информация, зависящая от типа со­общения. Если ведущее устройство передает инструкции ведомому устройству, то оно опи­сывает поле сообщения данными, которые должно использовать ведомое устройство. В случае запроса данных адресуемое ведомое устройство описывает поле сообщения дан­ными, запрошенными ведущим устройством.

Заголовок

Заголовок состоит из разрыва синхронизации, поля синхронизации и поля идентификации.

Синхронизация LIN

Синхронизация происходит в начале каж­дого фрейма для обеспечения последова­тельной передачи данных между ведущим и ведомыми устройствами. Сначала разрывом синхронизации четко определяется начало фрейма. Он состоит из не менее 13 после­довательных доминантных уровней и одного рецессивного уровня.

После разрыва синхронизации ведущее устройство передает поле синхронизации, состоящее из последовательности битов 01010101. Это дает ведомым устройствам возможность адаптироваться к временной оси ведущего. Тактовый импульс ведущего устройства не должен отличаться от номи­нального значения более чем на ±0,5%. Так­товый импульс ведомых устройств перед син­хронизацией может иметь разброс ±15 %, если синхронизация к концу сообщения достигает уровня ±2 %. Таким образом, ведомым устрой­ствам не нужен дорогой кварцевый генера­тор — они могут быть выполнены, например, с экономичной резистивно-емкостной цепью.

Идентификатор LIN

Третий байт в заголовке служит иденти­фикатором LIN. По аналогии с шиной CAN здесь используется адресация по содержа­нию — идентификатор дает информацию о содержании сообщения. Все подключенные к шине узлы на основании этой информации решают, намерены ли они получить и обрабо­тать сообщение или же проигнорировать его (фильтрация при приемке).

Шесть или восемь битов в поле идентифи­катора определяют сам идентификатор; из них получается 64 возможных идентифика­тора (ID). Имеются следующие значения:

• ID = 0 — 59: передача сигналов;
• ID = 60: запрос команд и диагностики от ведущего устройства;
• ID = 61: отклик ведомого устройства на ID 60;
• ID = 62: зарезервирован для связи с изго­товителем;
• ID = 63: зарезервирован для будущих рас­ширений протокола.

Из 64 возможных сообщений 32 могут содер­жать только два байта данных, 16 — четыре байта данных, и остальные 16 — восемь бай­тов данных.

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

Поле данных

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

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

Данные в ответе ведомого устройства за­щищаются контрольной суммой (CS).

Описательный файл LIN

Конфигурация шины LIN, т.е. спецификация пользователей сети, сигналов и фреймов, выполняется в описательном файле LIN. Спецификация LIN для этой цели имеет под­ходящий язык конфигурации.

Из описательного файла LIN автоматиче­ски генерируется набор кодов на С и файлов заголовков; эти коды и файлы используются для реализации функций ведущего и ведо­мых устройств в ЭБУ, расположенных на шине. Таким образом, описательный файл LIN служит для конфигурации всей сети LIN. Это общий интерфейс между автопроизво­дителем и поставщиками ведущих и ведомых устройств.

Составление графика отправки сообщений

Таблица-график в описательном файле LIN определяет порядок и время отправки со­общений. Часто запрашиваемая информа­ция отправляется время от времени. Когда таблица проработана, ведущее устройство снова начинает с первого сообщения. После­довательность обработки можно изменить в зависимости от режима работы (например, активна/неактивна диагностика, включено/ выключено зажигание).

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

Управление сетью LIN

Для минимизации тока замкнутой цепи узлы сети LIN можно переводить в спящий режим. Это можно сделать двумя способами. Веду­щее устройство передает команду «перейти в спящий режим» зарезервированным иден­тификатором 60, либо ведомые устройства переходят в спящий режим автоматически, если в течение относительно длительного времени (4 секунды) не было передачи данных по шине. И ведущее, и ведомые устройства могут снова активировать сеть. Для этого необходимо передать сигнал ак­тивации. Он состоит из байта данных с номе­ром 128, обозначающим содержание. После перерыва времени бита 4-64 (разграничитель активации) все узлы должны быть инициа­лизированы и способны ответить ведущему устройству.

Протокол LIN. Полный обзор, описание, формат кадра.

Совсем недавно мы разбирали протокол CAN, и вот сегодня продолжаем двигаться по автомобильным стандартам! На очереди LIN, который также свое основное применение нашел в автомобильной промышленности, да и, в общем-то, для этого и был изначально создан.

Чуть забегу вперед – этому протоколу будет посвящено целых три статьи. Сегодня будет исключительно теория, максимально подробно и наглядно. Во второй части мы будем работать с LIN на практике при помощи STM32 с использованием аппаратных средств микроконтроллера. А вот в третьей части мы с нуля напишем свой собственный драйвер для LIN на базе UART.

А пока к теории!

Итак, протокол LIN был создан в конце 90-х годов (первая версия спецификации относится к 1999 году) группой известных компаний, в основном, автопроизводителей. Среди них:

• Audi
• Volkswagen
• BMW
• Volvo
• Motorola

В целом архитектура шины выглядит следующим образом:

В чем же смысл, спросите вы, ведь есть же CAN? Так вот, использование LIN не исключает использование CAN, а скорее дополняет. LIN является однопроводной шиной, более дешевой, чем CAN, и используется для связи менее критичных для безопасности и для работы автомобиля узлов между собой. То есть основная связь по-прежнему обеспечивается протоколом CAN, а менее важные блоки и датчики уже подключаются по LIN:

Низкая стоимость обеспечивается в том числе тем, что для реализации протокола обычно используется обычный UART микроконтроллера. Все остальное, необходимое для работы шины, реализуется исключительно в ПО. Но это с программной точки зрения. Физически же все-таки требуется использование дополнительной микросхемы трансивера. И самый популярный кандидат бесспорно – TJA1021:

Скорость передачи данных также вполне стандартная для UART’а: от 1 – до 20 кБод, длина линии может достигать 40 м. Давайте теперь перейдем к самому интересному, к структуре пакета в LIN!

Структура пакета протокола LIN.

Каждый пакет состоит из заголовка (header) и непосредственно данных (data):

Причем важной особенностью является то, что на шине присутствуют два типа устройств – LIN Master (ведущий) и LIN Slave (подчиненный). При этом инициировать передачу данных может только Master. То есть Slave-устройство не может само по себе выслать в сеть данные, оно должно ожидать запроса от ведущего и никак иначе

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

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

Как видите, иерархия очень строгая!

С организацией обмена данными разобрались, теперь можно углубиться непосредственно в структуру уже упомянутых частей LIN-фреймов. Заголовок пакета состоит из нескольких байт:

• Поле Break – это поле представляет из себя 13 нулевых битов подряд.
• Поле Sync – поле синхронизации. Этот байт имеет определенное значение – 0x55. Именно это число выбрано по той причине, что в двоичном виде оно представляет из себя чередующиеся нули и единицы – 0b01010101. При помощи этого поля устройства могут настроить свою скорость передачи данных.
• Поле PID – поле идентификатора. В нем зашифровано следующее:

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

Из битов ID0…ID5 складывается непосредственно значение идентификатора. А поскольку под это выделено только 6 битов, то значит диапазон значений идентификатора составляет от 0 до 0x3F (0b111111). При этом значения от 0x3C до 0x3F являются служебными. Кроме того, в значении идентификатора содержится информация о количестве передаваемых в Frame Data байт:

Идентификатор	Кол-во байт
0x00-0x1F	2
0x20-0x2F	4
0x30-0x3F	8

Итак, тут у нас остаются еще два бита четности, для них формула выглядит следующим образом:

И на этом все! Заголовок пакета сформирован.

Поле данных в свою очередь состоит из непосредственно байт данных (от 1-го до 8-ми байт) и контрольной суммы (1 байт):

Для расчета контрольной суммы есть два варианта:

• Классическая контрольная сумма (версия LIN1.x) – сумма всех байт данных из поля Frame Data с переносом. После суммирования полученный байт инвертируется.
• Расширенная контрольная сумма (версия LIN2.x) – используется такой же алгоритм, только в суммировании участвует еще и байт PID. Сообщения с заголовками 0x3C и 0x3D должны использовать классическую контрольную сумму.

Давайте рассмотрим пример расчета классической контрольной суммы. Пусть байты данных равны: 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37. Суммируем:

Вычитаем из полученного значения 0xFF:

И инвертируем, в итоге получаем:

Для выбранных нами байт данных контрольная сумма равна 0x62.

В практической статье по протоколу LIN мы обязательно посмотрим, как все это будет выглядеть на деле, а пока на этом заканчиваем, до скорой встречи!

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

• Главная
• Рубрикация
• Указатель А — Я
• Порталы
• Произвольно
• Журнал
• Редакторам
• 
  • Ссылки сюда
  • Связанные правки
  • Загрузить файл
  • Спецстраницы
  • Версия для печати
  • Постоянная ссылка
  • Сведения о странице
  • Цитировать страницу
• 
  • Читать
  • Просмотр
  • История

LIN (Local Interconnect Network)

LIN (англ. Local Interconnect Network ) — стандарт промышленной сети, ориентированный на управление автомобильными системами низкой ответственности, разработанный специально для организации связи между простыми электронными блоками в автомобилях консорциумом европейских автопроизводителей и других известных компаний, включая Audi AG, BMW AG, Daimler Chrysler AG, Motorola Inc., Volcano Communications Technologies AB, Volkswagen AG и VolvoCar Corporation.

Содержание

• 1 История
• 2 Позиционирование
• 3 Сетевая топология
• 4 Аппаратное обеспечение LIN
• 5 Обзор
  • 5.1 Функции протокола
  • 5.2 Применение
• 6 LIN блок сообщений
• 7 Принципы построения LIN-сети
• 8 Принцип работы LIN-интерфейса
  • 8.1 Типы передаваемых данных в LIN-интерфейсе
• 9 Спецификации
  • 9.1 LIN 1.3
  • 9.2 LIN 2.0
  • 9.3 Сравнение спецификаций
• 10 ИМС, реализующие протокол
• 11 Ссылки
• 12 Источники

История

В конце 1990-х годов консорциум LIN был основан пятью автопроизводителями (BMW, Volkswagen Group, Audi Group, Volvo Cars, Mercedes-Benz) с использованием технологий (опыт работы в области сетей и аппаратного обеспечения) от Volcano Automotive Group и Motorola.

В 1996 г. концерн Volvo и Volcano Communication (VCT) совместно разработали интерфейс на основе UART/SCI-технологии для применения его в новой серии автомобилей Volvo S80. В дальнейшем этот интерфейс получил название Volcano Lite. Данный интерфейс стал неотъемлемой частью автомобильных средств коммуникации. В 1997 г. Motorola совместно с Volvo и VCT с целью удовлетворения новых технических требований (например, реализовав концепцию самосинхронизации ведомого узла без применения кварцевого резонатора) улучшила Volcano Lite и сформировала новый открытый стандарт, позволяющий поддерживать широкий ряд автомобильных систем. В декабре 1998 г. Audi, BMW, DaimlerChrysler и VW основали LIN-консорциум/

Первая полностью реализованная версия новой спецификации LIN (LIN версия 1.3) была опубликована в ноябре 2002 года. В сентябре 2003 года была введена версия 2.0 для расширения возможностей и обеспечения дополнительных функций диагностики. LIN также может использоваться по линии электропитания аккумулятора автомобиля с помощью специального трансивера LIN-DC Powerline (DC-LIN).

Линия электропередачи LIN через DC (DC-LIN) стандартизирована как ISO / AWI 17987-8. CAN in Automation (CIA) был назначен Советом по техническому управлению ISO (TMB) в качестве регистрирующего органа для идентификатора поставщика LIN, стандартизированного в серии ISO 17987. [Источник 1]

Позиционирование

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

К основным задачам, которые возлагает на LIN консорциумом европейских автомобильных производителей, относится в первую очередь объединение автомобильных подсистем и узлов (таких как дверные замки, стеклоочистители, стеклоподъёмники, управление магнитолой и климат-контролем, электролюк и так далее) в единую электронную систему. LIN протокол утверждён Европейским Автомобильным Консорциумом как дешёвое дополнение к сверхнадёжному протоколу CAN.

LIN и CAN являются дополнениями друг к другу и позволяют объединить все электронные автомобильные приборы в единую многофункциональную бортовую сеть. Следуут учитывать, что область применения CAN — участки, где требуется сверхнадёжность и скорость; область же применения LIN — объединение дешёвых узлов, работающих с малыми скоростями передачи информации на коротких дистанциях и сохраняющих при этом универсальность, многофункциональность, а также простоту разработки и отладки. Стандарт LIN включает технические требования на протокол и на среду передачи данных. Как последовательный протокол связи, LIN эффективно поддерживает управление электронными узлами в автомобильных системах с шиной класса «А» (двунаправленный полудуплексный), что подразумевает наличие в системе одного главного (англ. master ) и нескольких подчинённых (англ. slave ) узлов.

Сетевая топология

LIN — широковещательная последовательная сеть в составе которой 16 узлов (один мастер и, как правило, до 15 подчиненных). Все сообщения инициируются мастером с не более чем одним ответом на данный идентификатор сообщения от подчиненного узла. Главный узел может также выступать в качестве подчинённого (англ. slave ), отвечая на свои собственные сообщения. Поскольку все коммуникации инициируются мастером, то не нужно осуществлять обнаружение противоречий. Главный и подчиненные узлы, как правило, микроконтроллеры, но в целях экономии стоимости, места, или потребления, так же могут быть реализованы в специализированных аппаратных средствах или ASIC.

Аппаратное обеспечение LIN

Спецификация LIN была разработана для того, чтобы в сети могли использоваться очень дешевые аппаратные узлы. Это недорогая однопроводная сеть, основанная на стандарте ISO 9141. В современных автомобильных топологиях используются микроконтроллеры с возможностью UART или выделенным оборудованием LIN. Микроконтроллер генерирует все необходимые данные LIN с помощью программного обеспечения и подключается к сети LIN через приемопередатчик LIN (преобразователь уровня с некоторыми надстройками). Работа в качестве узла LIN является лишь частью возможной функциональности. Аппаратное обеспечение LIN может включать этот трансивер и работать как чистый узел LIN без дополнительных функций.

Поскольку подчиненные узлы LIN должны быть как можно более дешевыми, они могут генерировать свои внутренние часы, используя RC-генераторы вместо кристаллических (кварцевых или керамических). Для обеспечения стабильности скорости передачи в одном блоке данных LIN используется поле SYNC в заголовке.

Обзор

Шина LIN представляет собой недорогой последовательный коммуникационный протокол, который эффективно поддерживает удаленное приложение в сети автомобиля. В частности предназначен для мехатронных узлов, но в равной степени подходит для промышленного применения. Она предназначена как дополнение к существующей сети CAN. [Источник 2]

Первая версия LIN 1.0 под влиянием некоторых автомобильных компаний была реализована в июле 1999 г. благодаря переделке стандарта VLITE. В дальнейшем LIN-стандарт был переделан дважды в течение 2000 г., в результате чего появилась следующая версия LIN 1.2. В ноябре 2002 г. LIN-консорциум выпустил новый стандарт LIN 1.3. Изменения в нем в основном коснулись только физического уровня, благодаря чему была достигнута лучшая совместимость между узлами сети. Последняя версия стандарта, названная LIN 2.0, была принята в сентябре 2003 г., обновление позволило расширить возможности конфигурации и дополнительной диагностики.

Функции протокола

Основные функции протокола перечислены ниже:

• В основу LIN положена концепция «single-master/multi-slave»
• Один ведущий, до 16 подчиненных. Это значение, рекомендованное Консорциумом LIN для достижения детерминированного отклика времени.
  • Обнаружение положения подчиненного узла (ОППД) позволяет назначать адреса узла после включения питания.
• Топология «общая шина»
• Реализуется с помощью асинхронного последовательного интерфейса (UART).
• Переменная длина блока данных (2, 4 и 8 байт).
• Передача данных по одному проводу
• Обнаружение дефектных узлов.
• Скорость до 20 Кбит/с
• Длина шины до 40 м
• Напряжение на шине в пассивном состоянии 9. 18 В (подключенные к шине узлы должны выдерживать повышение напряжения до 40 В)

Данные передаются по шине в фиксированной форме сообщений выбираемых длин. Мастер задача передает заголовок, который состоит из сигнала разрыва и идентификаторов полей. Подчинённые узлы присылают блок данных, который состоит из от 2, 4 и 8 байт данных плюс 3 байта информации управления.

Применение

Примеры применения протокола в различных компонентах автомобиля:

Сегмент	Пример применения
Крыша	Датчик освещенности, управление освещением, солнечная крыша
Руль	Круиз-контроль, стеклоочиститель, поворотник, климат-контроль, автомагнитола, блокировка руля
Сиденье	Моторы положения сиденья, датчики пассажира, панель управления
Двигатель	Датчики, малые моторы, моторы вентиляторов охлаждения
Решетка	Решетка жалюзи
Климат	Малые моторы, панель управления
Дверь	Зеркало, центральный ЭБУ, выключатель зеркала, стеклоподъемник, выключатель сиденья, замок двери
Освещение	Улучшение отделки салона автомобиля, накладки на пороги освещены светодиодом RGB

LIN блок сообщений

Сообщения содержат следующие поля:

• Разрыв синхронизации
• Байты синхронизации
• Байты дентификатора
• Байты данных
• Контрольная сумма

1. Безусловный блок. Они всегда несут сигналы, и их идентификаторы находятся в диапазоне от 0 до 59 (от 0x00 до 0x3b). Все подписчики безусловного блока должны получить блок и сделать его доступным для приложения (при условии, что ошибок не обнаружено).
2. Блок, инициированный событием. Его целью является повышение скорости отклика кластера LIN без выделения слишком большой полосы пропускания шины для опроса множества подчиненных узлов с редко возникающими событиями. Первый байт данных переносимого безусловного блока должен быть равен защищенному идентификатору, назначенному блоку, инициированному событием. Подчиненное устройство должно ответить связанным безусловным блоком, только если его значение данных изменилось. Если ни одна из подчиненных задач не отвечает на заголовок, оставшаяся часть слота блока молчит, а заголовок игнорируется. Если более чем одна подчиненная задача отвечает на заголовок в одном и том же временном интервале блока, произойдет конфликт, и мастер должен разрешить конфликт, запросив все связанные безусловные блоки, прежде чем запросить блок, инициированный событием.
3. Спорадический блок. Этот блок передается ведущим по мере необходимости, поэтому столкновение не может произойти. Заголовок спорадического блока должен отправляться только в соответствующий ему интервал блока, когда главная задача знает, что сигнал, переносимый в блоке данных, обновлен. Издатель спорадического блока всегда должен предоставлять ответ на заголовок.
4. Диагностический блок. Они всегда содержат диагностические данные или данные конфигурации, и они всегда содержат восемь байтов данных. Идентификатор: 60 (0x3C), называемый основным блоком запроса, или 61 (0x3D), называемый ведомым ответным блоком. Прежде чем генерировать заголовок диагностического блока, мастер задач спрашивает свой диагностический модуль, должен ли он быть отправлен или шина должна молчать. Подчиненные задачи публикуют и подписываются на ответ в соответствии с их диагностическим модулем.
5. Пользовательский блок. Они могут нести любую информацию. Их идентификатор — 62 (0x3E). Заголовок пользовательского блока всегда передается, когда обрабатывается интервал блока, выделенный для блока данных.
6. Зарезервированный блок. Они не должны использоваться в кластере LIN 2.0. Их идентификатор — 63 (0x3F).

Принципы построения LIN-сети

LIN-сеть состоит из одного ведущего узла (master node) и нескольких ведомых (slave nodes). Пример построения LIN-сети с одним ведущим узлом и двумя ведомыми показан на (рис.1). Обычный ведущий узел выполняет как «задачу ведущего» (Master Task), так и «задачу ведомого» (Slave Task). Все остальные узлы (ведомые) выполняют только Slave Task. В задачу ведущего узла входит: принятие решения, а также когда и какие данные должны быть переданы, в то время как ведомый узел отвечает только за обеспечение данных на запросы ведущего [Источник 3] .