LIN Description File (LDF) vs. DBC files
As part of your LIN data logger workflow, you may need to decode your raw LIN bus data to physical values. Specifically, this involves extracting LIN signals from the LIN frame payload and decoding these to human-readable form.
This process of LIN bus decoding is similar to CAN bus decoding and requires the same information:
- ID: Which LIN frame ID contains the LIN bus signal
- Name: The LIN signal name should be known
- Start bit: Start position of the LIN signal in the payload
- Length: Length of the LIN bus signal
- Endianness: LIN signals are little endian (Intel byte order)
- Scale: How to multiply the decimal value of the LIN signal bits
- Offset: By what constant should the LIN signal value be offset
- Unit/Min/Max: Additional supporting information (optional)
This information is typically available as part of the LIN Description File (LDF) for a local interconnect network. However, since many software tools do not natively support the LDF format, we explain below how to use DBC files as an alternative.
LIN Description File (LDF) vs. DBC files
As evident from our CAN bus intro and DBC file intro, the above entries are equivalent to the information stored in a CAN DBC file. This means that a simple method for storing LIN bus decoding rules is to use the DBC file format, which
is supported by many software and API tools (incl. the CANedge software tools like asammdf). For example, you can load a LIN DBC file and your raw LIN bus data from the CANedge in asammdf to extract LIN bus signals from the data, which you can then plot, analyze or export.
In many cases, you may not have a LIN DBC file directly available, but instead you may have a LIN description file (LDF). Below we therefore focus on how you can convert the relevant LIN signal information into the DBC format.
Note: The LDF typically contains various other information relevant to the operation of the LIN bus, which we do not focus on here. For a full deep-dive on the LIN protocol and the a detailed description of the LDF specification, see the LIN protocol PDF standard.
How to convert a LIN Description File (LDF) to DBC
Below we provide an example to showcase how you can extract LIN signal information from an LDF and enter it into a DBC file. We use a very simplified LIN description file (with only one signal and excluding some sections).
You can expand the below examples to see the LIN signal, BatteryVoltage, in the LDF format and in the DBC format. You can also download a raw LIN bus log file (MF4) from the CANedge2 with data for this signal, which you can open and DBC decode in asammdf:
Guide to LDF to DBC conversion
In short, to convert an LDF file to DBC, you’ll go through the following steps for each LIN signal:
- Get the LIN signal name and length from the Signals section
- Get the LIN signal message name, ID and length from the Frames section
- Get the LIN signal bit start from the Frames section
- Go to the LDF Signal_encoding_types section and find «Enc_»
- Get remaining info via the syntax: ‘physical_value, , , , , «» ;’
If you’re looking to create your own LIN DBC file, we suggest you review our DBC file introduction for details on the syntax, as well as DBC editor tools like our online DBC editor.
Minor pitfalls
The conversion from LDF to DBC is not entirely 1-to-1. In particular, note how the LIN signal BatteryVoltage has 2 entries for the physical value, one for the decimal range 0 to 32000 and one for 32001 to 65533. In this specific case, only the data in the first range are valid (the unit is «invalid» for the 2nd range). However, in some cases there can be multiple ranges that require separate
scaling factors — something which is not possible to handle in the DBC file format. In this case, you will need to choose one of the ranges and e.g. treat results outside this range as invalid.
This is also the simplest way to handle the LIN signal ‘logical_value’ entries in the Signal_encoding_types section. These typically reflect how specific values of the LIN signal should be treated (e.g. as errors). One way of treating these entries would be to ignore them and possibly exclude them as part of your data post processing — similar to how FF byte values in CAN bus are often
excluded as they represent invalid or N/A data.
FlexRay
Интерфейс FlexRay (aka ISO17458) — пожалуй, можно назвать антиподом LIN в плане стоимости реализации и бесполезности. Поскольку часть обмена по шине осуществляется в режиме TDMA, предьявляются особые требования к точности тактового генератора узлов сети. Сам протокол излишне сложен и надуман (с точки зрения реализации собственного аппаратного контроллера, работающего с FlexRay; однозначно сложнее реализации Ethernet+CAN вместе взятых). На данный момент FlexRay используется на ограниченном количестве моделей автомобилей европейских премиум-брендов (это за >10 лет существования), а дальнейшей экспансией не пахнет. Вероятно, совсем скоро FlexRay загнётся ввиду его замены такими технологиями как CAN FD (сравнимая скорость) и TT-CAN (TDMA работа с шиной).
Характеристики:
- 2006г — дата первой публикации (первые черновики датируются 2000г)
- дублированная неэкранированная дифференциальная пара
- длина шины до ?? метров
- топология — звезда, шина или гибридная
- скорость до 10 Мбит/с
- длина пакета до 254 байт
- совмещенная работа в двух режимах: событийном и TDMA-доступа к шине
- контроль целостности данных с помощью CRC11 (заголовок) и CRC24 (данные)
Slave node position detection (SNPD) or autoaddressing
These methods allow the detection of the position of slave nodes on the LIN bus and allow the assignment of a unique node address (NAD).
Allows similar or the same devices to be connected on the bus without end of line programming or connector pin programming.
Restrictions:
- All auto-addressing slaves must be in one line
SNPD Method | SNPD Method ID | Company |
---|---|---|
Extra wire daisy chain | 0x01 | NXP (formerly Philips) |
Bus shunt method | 0x02 | Elmos Semiconductor |
Reserved | 0x03 | TBD |
Reserved | 0x04 | TBD |
Reserved | 0xFF | TBD |
Extra wire daisy chain (XWDC)
Each slave node has to provide two extra pins, one input, D1, and one output, D2.
- The first SNPD node input D1 is either set to GND or connected to the output of the master.
Each configuration pin Dx (x=1-2) has additional circuitry to aid in the position detection.
- Switchable resistive pull-up to Vbat
- Pull-down to GND
- Comparator referenced to Vbat/2
XWDC auto-addressing procedure
At the start of the procedure no SNPD devices have a NAD assigned
1 First auto-addressing LIN message
- 1.1 All outputs (D2) are set to a high level, all pull-downs are turned off
- 1.2 The first SNPD node is selected. It is identified by having the input D1 low (hardwired).
- 1.3 The selected node takes the address from the LIN configuration message
- 1.4 The detected node turns on the pull-down at the output D2
2 Subsequent auto-addressing LIN messages
- 2.1 The first non addressed SNPD node is selected. It is identified by having the input D1 low (D2 of previous node).
- 2.2 The selected node takes the address from the LIN configuration message
- 2.3 The detected node turns on the pull-down at the output D2
- 2.4 Steps 2.1-2.4 are repeated until all slave nodes are assigned an address
3 All pull-ups and pull-downs are turned off completing the addressing procedure
Bus shunt method (BSM)
Each slave node has two LIN pins
- bus_in
- bus_out
Each slave node needs some additional circuitry compared to the standard LIN circuitry to aid in the position detection.
- The standard pull-up must be switchable
- Switchable 2 mA current source from Vbat
- Shunt resistor
- Differential amplifier
- Analog to digital converter
BSM auto-addressing procedure
At the start of the procedure, none of the SNPD devices have a NAD assigned. The autoaddressing routine is performed during the sync field. The sync field is broken into three phases:
1 Offset current measurement
- 1.1 All outputs pull-ups and current sources are switched off
- 1.2 The bus current is measured, Ioffset
2 Pull-up mode
- 2.1 Pull-ups are turned on and current sources remain off
- 2.2 The bus current is measured, IPU
- 2.3 Nodes with ΔI = IPU—Ioffset < 1 mA are «selected»
3 Current source mode
- 3.1 Selected nodes switch current source on and others switch pull-ups off
- 3.2 Bus current is measured, ICS
- 3.3 Node with ΔI = ICS—Ioffset < 1 mA is detected as the last node
- 3.4 Current sources are switched off and pull-ups are switched on
- 3.5 The last node will accept the address contained in the LIN configuration message
This technique is covered by the patents EP 1490772 B1 and US 7091876.
Определение положения подчиненного узла (SNPD) или автоадресация
Эти методы позволяют определять положение подчиненных узлов на шине LIN и позволяют назначать уникальный адрес узла (NAD).
Позволяет подключать аналогичные или одинаковые устройства к шине без программирования конца линии или программирования контактов разъема.
Ограничения:
Все ведомые устройства с автоадресацией должны быть в одной строке
Метод SNPD | ID метода SNPD | Компания |
---|---|---|
Дополнительная проводная гирляндная цепь | 0x01 | NXP (ранее Philips) |
Метод шинного шунтирования | 0x02 | Элмос Полупроводник |
Зарезервированный | 0x03 | TBD |
Зарезервированный | 0x04 | TBD |
Зарезервированный | 0xFF | TBD |
Дополнительная проводная гирляндная цепь (XWDC)
Каждый подчиненный узел должен иметь два дополнительных контакта, один вход D 1 и один выход D 2 .
Вход D1 первого узла SNPD либо установлен на GND, либо подключен к выходу ведущего устройства.
Каждый вывод конфигурации D x (x = 1-2) имеет дополнительную схему для помощи в обнаружении положения.
- Переключаемое резистивное подтягивание до V bat
- Понижение к GND
- Компаратор ссылается на V bat / 2
Процедура автоадресации XWDC
В начале процедуры ни одному из устройств SNPD не назначен NAD.
1 Первое сообщение LIN с автоматической адресацией
- 1.1 Все выходы (D 2 ) настроены на высокий уровень, все понижения выключены.
- 1.2 Выбирается первый узел SNPD. Он определяется наличием на входе D 1 низкого уровня (проводной).
- 1.3 Выбранный узел берет адрес из сообщения конфигурации LIN.
- 1.4 Обнаруженный узел включает выпадение на выходе D 2
2 Последующие сообщения LIN с автоадресацией
- 2.1 Выбирается первый неадресированный узел SNPD. Он определяется наличием на входе D 1 низкого уровня (D 2 предыдущего узла).
- 2.2 Выбранный узел берет адрес из сообщения конфигурации LIN.
- 2.3 Обнаруженный узел включает выпадение на выходе D 2
- 2.4 Шаги 2.1-2.4 повторяются до тех пор, пока всем подчиненным узлам не будет присвоен адрес.
3 Все подтягивающие и отключаемые отключаются после завершения процедуры адресации.
Метод шинного шунтирования (BSM)
Каждый подчиненный узел имеет два контакта LIN
- bus_in
- bus_out
Каждому подчиненному узлу требуется дополнительная схема по сравнению со стандартной схемой LIN, чтобы помочь в обнаружении положения.
- Стандартное подтягивание должно быть отключаемым.
- Переключаемый источник тока 2 мА от V bat
- Шунтирующий резистор
- Дифференциальный усилитель
- Аналого-цифровой преобразователь
Процедура автоадресации BSM
В начале процедуры ни одному из устройств SNPD не назначен NAD. Процедура автоадресации выполняется в поле синхронизации. Поле синхронизации разбито на три фазы:
1 Измерение тока смещения
- 1.1 Все выходные подтяжки и источники тока отключены
- 1.2 Ток шины измеряется, смещение I
2 Режим подтягивания
- 2.1 Подтягивания включаются, а источники тока остаются выключенными
- 2.2 Измеряется ток шины, I ПУ
- 2.3 Узлы с ΔI = I PU — I смещение <1 мА «выбираются»
3 Режим источника тока
- 3.1 Выбранные узлы включают источник тока, а другие отключают подтягивания.
- 3.2 Ток шины измеряется, I CS
- 3.3 Узел с ΔI = I CS — I смещение <1 мА определяется как последний узел
- 3.4 Источники тока выключены, а подтяжки включены.
- 3.5 Последний узел примет адрес, содержащийся в сообщении конфигурации LIN.
Этот метод защищен патентами EP 1490772 B1 и US 7091876.
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 FRAMESyncLIN (); // Sync Break и Sync FieldDataTX(0b00111100); // IdentifierDataTX(0x80); // AppCMDDataTX(0x81); // CMDDataTX(0b11110000); // slave addressDataTX(0xff); // DATADataTX(0xff); // DATADataTX(0xff); // DATADataTX(0xff); // DATADataTX(0xff); // DATADataTX(0b00001101); // CHK байт контроля ошибок
// READING FRAMESyncLIN (); // Sync Break и Sync FieldDataTX(0B01111101);В ответ драйвер мотора посылает восемь байт своего состояния, после этого можно слать команду установки на нужную позицию — мотор оживает и делает нужное количество шагов:SyncLIN ();// Sync Break и Sync FieldDataTX(0x3c); // IdentifierDataTX(0x80); // AppCMDDataTX(0x8b); // CMDDataTX(0xf0); // AD1 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 основан на мастер-рабочий (master-slave) архитектуре, где одно устройство играет роль мастера, а остальные — роли рабочих устройств.
Соединение между мастером и рабочими устройствами осуществляется посредством единственного физического провода, который называется шиной LIN. Шина LIN может быть прокладывается по всей длине автомобиля и соединять все устройства, которые нуждаются в обмене данными.
Протокол LIN использует уникальный механизм передачи данных, который позволяет снизить стоимость проводов и упростить систему коммуникации. Вся передача данных осуществляется по одному проводу — линии данных (LIN bus). Шина LIN не требует сложных и дорогих аппаратных средств, так как информация передается асинхронно, а не с синхронизацией по тактам, как в случае с мощными шинами CAN или FlexRay.
- Мастер-рабочий принцип
Устройство, которое инициирует передачу данных, называется мастером, а устройства, которые принимают эти данные, называются рабочими устройствами. Мастер-устройство контролирует всю последовательность передачи данных и определяет, когда и какие данные должны быть отправлены.
Фреймы
В протоколе LIN данные передаются в виде фреймов. Фреймы содержат не только непосредственно данные, но и служебную информацию о передаче. Формат фрейма определен спецификацией LIN и включает в себя заголовок, идентификатор, длину данных, сами данные и контрольную сумму.
Синхронизация
Поскольку шина LIN асинхронна, требуется некоторый механизм синхронизации передачи данных. Для этого в протоколе LIN используется специальная команда «синхрофрейм» (Synchronization Frame), которая отправляется мастером и служит для синхронизации всех устройств в системе.
Коллизии и ошибки
В случае, если два или более устройств пытаются передать данные одновременно, возникает коллизия, и данные могут быть потеряны. Для предотвращения коллизий и устранения ошибок в протоколе LIN используются специальные алгоритмы и проверки контрольной суммы.
Реализации CAN на уровне электрических сигналов
CAN шина может быть реализована физически тремя способами:
1 ISO11898-2 или CAN-High Speed.
Классическая витая пара нагруженная с обоих концов резисторами 120 Ом.
В этом случае уровни на шине CAN выглядят так:
Для такой реализации сети используются как правило обычные CAN трансиверы в 8 выводном корпусе, аналоги PCA82C250, TJA1050 и им подобные. Работает такая конфигурация на скоростях 500 кбит\с и выше. (Но могут быть исключения) .
2 ISO11898-3 или CAN-Low Speed или Faut Tolerant CAN
Такой вариант CAN шины способен переключаться в однопроводный режим в случае повреждения одной из линий. Работает на скоростях до 250 кбит\с.Уровни сигнала на шине отличаются от High Speed CAN, при этом не теряется возможность работы с шиной FT-CAN используя трансиверы High-Speed CAN и соблюдая ряд условий. Подробнее в нашей статье о FT-CAN – ссылка.
Fault tolerant CAN обычно используется для низкоскоростного обмена между блоками управления относящимися к сегменту сети Салон\Комфорт\Мультимедиа.
ВАЖНО: При подключении к шине Faul tolerant CAN, подключать терминальный резистор 120 Ом между линиями CAN-High и CAN-Low НЕ НУЖНО !
Шина LIN. Сканирование “молчащих” блоков и датчиков
Как было описано в предыдущей статье, в структуре шины LIN есть Master узел и Slave узлы. Master опрашивает узлы Slave, а те ему отвечают. В большинстве случаев если просто подать питание на Slave и посмотреть что происходит на его выходе шины LIN, то мы ничего не увидим, поскольку Slave ожидает запрос или пакет от Master узла.
Master узлом как правило является какой-либо блок управления: Блок управления двигателем, салоном, креслами и т. д. А Slave узлы это различные цифровые датчики, приводы, блоки кнопок управления или джойстики.
Что же делать если стоит задача “оживить” Slave в отрыве от мастера? Например во время проведения ремонта с целью выяснить исправность Slave узла и вообще шины LIN.
Для решения этой задачи удобно использовать LIN адаптер LIN-K совместно с USB-CAN интерфейсом CAN-Hacker. Программное обеспечение нашего анализатора шины LIN позволяет автоматически искать запросы для Slave узлов сети LIN.
Блок управления стеклоподъемниками автомобиля LADA. Slave узел на шине LIN
В качестве примера рассмотрим работу с блоком управления стеклоподъемниками от автомобиля LADA Granta.
Блок управления стеклоподъемнками является Slave узлом в LIN шине автомобиля LADA, а Master узлом является блок управления комфортом, который отправляет запросы на Slave узлы, а те в свою очередь отвечают ему о своем состоянии. В частности блок управления стеклоподъемниками отвечает статусом нажатия кнопок.
Блок комфорта автомобиля LADA. Master на шине LIN
Если соединить эти блоки в сеть и параллельно подключить LIN анализатор LIN-K на скорости 9600 бод и будем нажимать кнопки на блоке стеклоподъемников, то мы увидим следующий обмен с пакетами имеющими >
Пакеты с данными: 00 00 00 C0 – говорят о том, что кнопки не нажаты, если же нули меняются на другие числа, например 20 02 00 С0 говорят о нажатии кнопок.
Теперь представим, что мастер узла в лице блока комфорта у нас нет, а запустить Slave – блок стеклоподъемников нужно. Для этого подадим питание на исследуемый блок и LIN адаптер и подключимся к выводу LIN.
Выберем в программе LIN-K виртуальный COM порт к которому подключен наш LIN адаптер, нажмем Connect. Затем установим скорость LIN 9600 бод и нажмем Open LIN.
В окне принятых сообщений ничего нет. Это следствие того, что Slave ждет запроса от Master -а.
Настроим LIN-K на передачу запросов в заданном диапазоне – функция Bombing
В такой конфигурации LIN-K будет передавать запросы узлу Slave в диапазоне всех возможных ID на шине LIN от 0 до 0x3C. С каждым ID будет передаваться по 10 запросов.
В случае если Slave прореагирует на отправленный запрос мы увидим этот факт в окне приема:
Как видно из скриншота Slave прореагировал на посылаемый ему запрос с >
Следует обратить внимание на то, что в передаваемых LIN анализатором ID автоматически рассчитываются биты защиты и значение ID отличается от значения в счетчике, например по счетчику а передаваемое значение с битами защиты будет равно =0x42
Далее мы можем убрать флаг Bombing и установить значение ID для Master запроса = 03 и мы будем получать ответы от “ожившего” блока кнопок
Применение шины LIN в автомобильной отрасли
Шина LIN (Local Interconnect Network) широко применяется в автомобильной отрасли для обеспечения связи и взаимодействия различных устройств и компонентов автомобиля. Она представляет собой низкоскоростную и недорогую шину данных, которая используется внутри автомобиля для передачи сигналов между различными устройствами, такими как датчики, актуаторы, панели приборов и системы безопасности.
Применение шины LIN в автомобильной отрасли имеет несколько важных преимуществ. Во-первых, она позволяет сократить количество проводов и разъемов в автомобиле, что снижает стоимость производства и упрощает процесс монтажа. Вместо того чтобы каждое устройство имело собственную проводку до центрального блока управления, все устройства могут быть подключены к шине LIN через общую линию. Таким образом, шина LIN значительно упрощает разводку проводов и сокращает объем работы по сборке автомобиля.
Во-вторых, шина LIN обладает низкой скоростью передачи данных, что является преимуществом в автомобильной отрасли. Многие устройства автомобиля, такие как датчики уровня топлива или датчики давления в шинах, не требуют быстрой передачи данных. Шина LIN обеспечивает достаточную пропускную способность для передачи данных в таких приложениях, при этом сохраняя низкую стоимость и низкое энергопотребление.
Третьим преимуществом применения шины LIN является ее надежность и простота в использовании. Шина LIN имеет простую структуру и минимальное количество компонентов, что обеспечивает надежную работу. Она также поддерживает стандартные протоколы коммуникации, что упрощает интеграцию устройств и обеспечивает совместимость между различными производителями оборудования.
Шина LIN применяется во множестве систем автомобиля, включая системы освещения, информационно-развлекательные системы, системы безопасности и многие другие. Она также широко используется в промышленности для связи и контроля различных устройств, таких как станки, роботы и системы автоматизации.
В заключение, шина LIN является важной составляющей автомобильной электроники и электроники в целом. Ее низкая стоимость, надежность и простота в использовании делают ее отличным выбором для передачи данных в автомобиле, а также в других областях применения
Ее возможности позволяют сократить затраты, упростить процессы и улучшить функциональность систем.
Основные принципы Lin-bus
Основные принципы Lin-bus включают:
- Физический уровень: Lin-bus использует одну общую линию для передачи данных и питания. Это экономичное решение, которое позволяет уменьшить количество проводов и упростить подключение компонентов.
- Адресация: Каждое устройство на Lin-bus имеет свой уникальный адрес, который используется для идентификации. Это позволяет системе точно определить, какой компонент отправляет или получает данные.
- Мастер-слейв архитектура: В системе Lin-bus существуют два типа устройств — мастер и слейв. Мастер инициирует обмен данными, а слейвы отвечают на запросы мастера или отправляют данные по своей инициативе.
- Метод доступа: Lin-bus использует метод доступа «По знаку». Это означает, что каждое устройство должно «спросить» у мастера разрешение на передачу данных по линии перед тем, как начать передачу. Это обеспечивает упорядоченную и жестко контролируемую передачу данных.
- Контроль ошибок: Lin-bus включает в себя механизм контроля ошибок, который позволяет проверять правильность передачи данных и обнаруживать возможные ошибки. Если ошибка обнаруживается, то обмен данными повторяется, чтобы гарантировать правильность информации.
- Низкоскоростная передача данных: Lin-bus разработан для передачи данных с низкой скоростью, обычно в диапазоне от 10 до 20 Кбит/сек. Это достаточно для передачи данных в автомобильных системах, таких как системы сигнализации, блокировки дверей, контроля температуры и т.д.
Все эти основные принципы Lin-bus делают его удобным и эффективным протоколом для использования в автомобильной сигнализации. Он обеспечивает надежную и безопасную передачу данных между компонентами системы, что позволяет эффективно контролировать и управлять автомобилем.
LIN Bus Functionality
In general, LIN Bus is a relatively simple serial protocol. A single master node loops through each of the slave node, sending a request for information; each slave responds with data when polled. However, with each specification update, new features were added, thus increasing the protocol complexity.
The most widely implemented version is LIN 2.2A, but it was also standardized by the SAE as SAE J2602 and CiA (CAN-in-Automation) as ISO 17987:2016.
The following explains the LIN Bus data frames.
LIN Bus Message Frame
The LIN Bus message header consists of a break used to identify the start of the frame and the sync field used by the slave node for clock synchronization. The identifier (ID) consists of a 6-bit message ID and a 2-bit parity field. The ID denotes a specific message address but not the destination. Upon reception and interpretation of the ID, the polled slave begins the message response, which consists of one to eight bytes of data and an 8-bit checksum.
- Break: Every LIN frame begins with the Sync Break Field (SBF), which is at minimum 13+1 bits long but in practice often 18+2 bits. The SBF functions as a «start of frame» indicator to all nodes on the LIN bus.
- Sync: The 8-bit Sync filed is defined as the character 0x55 (binary 01010101), a structure that allows LIN nodes to measure the time between signal edges and consequently determine the master node’s baud rate.
-
Identifier: The ID field contains the actual 6-bit identifier followed by 2 parity bits. This provides identification for each message on the network and ultimately determines which nodes in the network receive or respond to the transmission. All slave tasks continuously listen for ID fields, check the parity, and decide whether they:
- Ignore the received data
- Listen to the data
- Transmit data in response to the header
The 6-bit ID allow for 64 IDs, of which ID 60-61 are used for diagnostics (more below) and 62-63 are reserved.
Typically, since only one slave at a time is polled for data, there is no risk of message collision and hence, no need for arbitration. The master controls the sequencing of message frames, which is defined in a schedule that can be changed as needed.
This is a work in progress and will be amended on a daily basis.
Difference between CAN and LIN bus protocols
Following table highlights difference between CAN bus and LIN bus.
Parameters | CAN | LIN |
---|---|---|
Full form | Controller Area Network | Local Interconnect Network |
Communication type | Broadcast type | Master-slave |
Communication network | Multi master. peer to peer | Single master and multiple slaves |
No. of lines required | 2 wires | 1 wire |
Maximum communication speed | 1 Mbps | 20 kbps |
Triggering technique | Event triggered | Time triggered |
Message length | Longer messages, extensive data payload | Shorter messages, limited data payload |
Message transmission latency | Depends on message priority | Guaranteed latency |
Bus conflicts | Uses arbitration process to resolve bus conflict | No bus conflict |
Implementation cost | Higher | Comparatively lower |
Implementation complexity | Higher | Comparatively lower |
Error handling | Advanced error detection and correction mechanisms | Basic error handling |
Electromagnetic interference (EMI) | Resilient to EMI as it uses differential signaling | Less immune to EMI compared to CAN |
Applications | Safety critical- Airbag, ABS, Engine Management System | Non-safety critical — Entertainment system, wiper control, mirror control |
Conclusion : In summary, from our comparison between CAN vs LIN, we can conclude that
CAN and LIN serve different purposes within the same vehicle or industrial system.
CAN is intended for high-speed and critical communication, where as
LIN is designed for low-speed and non-critical tasks. They are often used in complementary
roles to efficiently handle the diverse communication needs in modern vehicles and industrial systems.
Выводы
Стандарт LIN охватывает спецификацию протокола передачи, среды передачи, взаимодействие инструментальных средств разработки с интерфейсами для передачи параметров из одной программы в другую. LIN гарантирует способность к взаимодействию сетевых узлов с точки зрения аппаратных средств и программного обеспечения, а также электромагнитную совместимость сетевых узлов.
Шина LIN применяется в тех приложениях, где требуется управление оборудованием при низкой стоимости подключения к сети. Это позволяет стандартизировать проектирование и значительно сокращает трудозатраты при подключении к сети таких приборов, как датчики и приводы. В спецификации шины LIN 2.0 появилась поддержка режима Plug and Play.
Фирма NEC Electronics разработала специальные аппаратные дополнения к ядру UART (LIN UART) и предлагает исходные коды драйверов «master» и «slave» для работы в сети LIN.
Стандарт LIN — это не просто «бумажный» документ. Уже сегодня изготовители автомобилей поставляют свою продукцию с магистральными системами LIN.
Широкий диапазон инструментальных средств отладки и контроля, аппаратных и программных компонентов доступен на рынке уже сегодня.
Высокое качество работы и способность к взаимодействию (Plug and Play) достигаются через четко определенную методику разработки проектов и испытаний на соответствие стандартам интерфейса.