Skip to main content

Обзор цифровых интерфейсов современного автомобиля

Отказ от ответственности

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

LIN

Интерфейс LIN (aka ISO17987) — пожалуй самый длинный (если сравнивать по длине линий, а не по весу меди в проводах) пучок в современном авто. Как говорится —  модно, доступно, молодёжно. Принцип необходимой достаточности и минимальной цены решения применяемый для некритичных к надёжности и/или безопасности компонент: климатическая установка, кнопки мультируля, стеклоподьемники, замки дверей. Протокол по физике очень похож (берет своё начало) от K-line протокола диагностики, стандартизованного как ISO9141. Во многих микроконтроллерах реализуется на основе аппаратного UART (в том же STM8 имеюттся аппаратные дополнения к UART для поддержки различных реализаций LIN)

Характеристики:

  • 2002г — дата первой публикации (первые черновики датируются 1999г)
  • однопроводная шина с PullUp
  • длина шины до 40 метров
  • коммуникация по принципу ведущий — ведомые (до 16-ти ведомых)
  • скорость до 20 кбит/с
  • длина пакета 2, 4 или 8 байт
  • поддержка широковещательного режима
  • контроль целостности данных с помощью CRC8
  • возможность определения сбойного абонента

CAN

Интерфейс CAN (aka ISO11898) — пожалуй, самый известный интерфейс современного автомобиля, во многом благодаря использования как стандарт де-факто для интерфейса диагностики инжекторного двигателя — аля OBD2. Однако, благодаря своим уникальным качествам, нашёл применение в таких ответственных отраслях как промэлектроника, авиация, космонавтика, ЖД и морской транспорт.

Характеристики:

  • 1986г — дата первой публикации
  • неэкранированная дифференциальная пара
  • длина шины до 40 метров
  • одноранговая сеть с равноправными абонентами (арбитраж по ID абонента)
  • скорость до 1 Мбит/с
  • длина пакета от 0 до 8 байт
  • поддержка широковещательного режима
  • контроль целостности данных с помощью CRC15
  • возможность автовыключения сбойного узла

FlexRay

Интерфейс FlexRay  (aka ISO17458) — пожалуй, можно назвать антиподом LIN в плане стоимости реализации и бесполезности. Поскольку часть обмена по шине осуществляется в режиме TDMA, предьявляются особые требования к точности тактового генератора узлов сети. Сам протокол излишне сложен и надуман (с точки зрения реализации собственного аппаратного контроллера, работающего с FlexRay; однозначно сложнее реализации Ethernet+CAN вместе взятых). На данный момент FlexRay используется на ограниченном количестве моделей автомобилей европейских премиум-брендов (это за >10 лет существования), а дальнейшей экспансией не пахнет. Вероятно, совсем скоро FlexRay загнётся ввиду его замены такими технологиями как CAN FD (сравнимая скорость) и TT-CAN (TDMA работа с шиной).

Характеристики:

  • 2006г — дата первой публикации (первые черновики датируются 2000г)
  • дублированная неэкранированная дифференциальная пара
  • длина шины до ?? метров
  • топология  — звезда, шина или гибридная
  • скорость до 10 Мбит/с
  • длина пакета до 254 байт
  • совмещенная работа в двух режимах: событийном и TDMA-доступа к шине
  • контроль целостности данных с помощью CRC11 (заголовок) и CRC24 (данные)

MOST

Интерфейс MOST  (не стандартизован ISO) — пожалуй, лишь условно можно назвать автомобильным, поскольку основное назначение — изохронная передача мультимедиаданных (аудио/видео). Не особо понятно почему тот же SPDIF по оптике или коаксиалу не использовать — очередная попытка авто-индустрии придумать «свой» стандарт?

Характеристики:

  • 1998г — дата первой публикации
  • оптоволокно, коаксиальный кабель или неэкранированная витая пара
  • топология шины — кольцо
  • скорость до 150 Мбит/с
  • длина пакета до 3072 бит
  • до 64-х абонентов на шине

Ethernet AVB

Протокол Ethernet AVB (Audio Video Bridging) — назначение, аналогичное MOST. Протокол описывается целой когортой стандартов IEEE:

  • IEEE 802.1BA: Audio Video Bridging (AVB) Systems
  • IEEE 802.1AS: Timing and Synchronization for Time-Sensitive Applications (gPTP)
  • IEEE 802.1Qat: Stream Reservation Protocol (SRP)
  • IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams (FQTSS)

Возможно, за счёт многолетних наработок по Ethernet и удешевлению элементной базы, стандарт «взлетит». Предполагаемое использование: передача звука из головного устройства  в цифровой усилитель, трансляция картинки на IVI и пассажирские мониторы, подключение обзорных и парк-камер.

Характеристики:

  • 2013г — дата первой публикации (по факту работы были начаты в 2004г)
  • витая пара, аналогичная для Ethernet 100/1000
  • длина шины, аналогичная для Ethernet 100/1000
  • скорость шины, аналогичная для Ethernet 100/1000
  • поддержка широковещательного режима, аналогичная Ethernet
  • контроль целостности данных, аналогичный Ethernet

SENT

Интерфейс SENT (Single Edge Nibble Transmission, aka SAE J2716) — разработанный для автопрома и быстро ставший популярным интерфейс для датчиков. По аналогии с аналоговыми датчиками, используется три провода: земля, питание 5В и данные с датчика.
Характеристики:

  • 2007г — дата первой публикации
  • однопроводная шина
  • длина шины до ? метров
  • коммуникация точка-точка
  • длина тика от 90 до 3 мкс
  • длина пакета 24 бита
  • контроль целостности данных с помощью CRC4

PSI5

Интерфейс PSI5 (Peripheral Sensor Interface) — второй разработанный специально для нужд автопрома интерфейс для коммуникации с датчиками. Это токовый интерфейс, данные в котором передаются модуляцией по питающей линии. Для кодирования бит используется манчестер-кодирование. Выглядит замечательно: прощайте аналоговые трёхпроводные датчики, чувствительные к наводкам!

Характеристики:

  • 2008г — дата первой публикации (первое упоминание в 2005)
  • медная витая пара
  • длина шины до ? метров
  • поддержка синхронного и асинхронного обмена и двунаправленного обмена
  • топология точка-точка
  • скорость 125/189 кбит/с
  • длина пакета от 8 до 24 бит
  • контроль целостности данных с помощью бита чётности или CRC3

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

Вместо послесловия

Запасаюсь попкорном и жду исходов битвы интерфейсов/появления новых кандидатов за место под солнцем. Как показал опыт FlexRay, недостаточно поддержать интерфейс вендорами в кремнии или консорциумами типа ISO/SAE — он, как фрукт, должен вызреть.

PS: если заметка помогла Вам, поделитесь ей с друзьями или коллегами: