Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

Controller Area Network ( CAN шина ) является надежной шины автомобиля стандарт , разработанный , чтобы микроконтроллеры и устройства для связи с приложениями друг друга без главного компьютера . Это протокол на основе сообщений , изначально разработанный для мультиплексной электропроводки в автомобилях с целью экономии меди, но он также может использоваться во многих других контекстах. Для каждого устройства данные в кадре передаются последовательно, но таким образом, что если более одного устройства передает одновременно, устройство с наивысшим приоритетом может продолжить, в то время как другие отключаются. Кадры принимают все устройства, в том числе передающее устройство.

История [ править ]

Разработка CAN- шины началась в 1983 году в компании Robert Bosch GmbH . [1] Протокол был официально выпущен в 1986 году на конференции Общества автомобильных инженеров (SAE) в Детройте , штат Мичиган . Первые микросхемы контроллеров CAN были представлены Intel в 1987 году, а вскоре после этого - Philips . [1] Выпущенный в 1991 году Mercedes-Benz W140 стал первым серийным автомобилем, оснащенным системой мультиплексной проводки на основе CAN. [2] [3]

Компания Bosch опубликовала несколько версий спецификации CAN, последняя из которых - CAN 2.0, опубликованная в 1991 году. Эта спецификация состоит из двух частей; часть A предназначена для стандартного формата с 11-битным идентификатором, а часть B - для расширенного формата с 29-битным идентификатором. Устройство CAN, использующее 11-разрядные идентификаторы, обычно называется CAN 2.0A, а устройство CAN, использующее 29-разрядные идентификаторы, обычно называется CAN 2.0B. Эти стандарты находятся в свободном доступе от Bosch вместе с другими спецификациями и официальными документами . [4]

В 1993 году Международная организация по стандартизации (ISO) выпустила стандарт CAN ISO 11898, который позже был реструктурирован на две части; ISO 11898-1, который охватывает уровень канала передачи данных , и ISO 11898-2, который охватывает физический уровень CAN для высокоскоростной CAN. Стандарт ISO 11898-3 был выпущен позже и охватывает физический уровень CAN для низкоскоростной отказоустойчивой CAN. Стандарты физического уровня ISO 11898-2 и ISO 11898-3 не являются частью спецификации Bosch CAN 2.0. Эти стандарты можно приобрести в ISO.

Bosch по-прежнему активно расширяет стандарты CAN. В 2012 году Bosch выпустила CAN FD 1.0 или CAN с гибкой скоростью передачи данных. В этой спецификации используется другой формат кадра, который позволяет использовать другую длину данных, а также при необходимости переключаться на более высокую скорость передачи данных после решения арбитража. CAN FD совместим с существующими сетями CAN 2.0, поэтому новые устройства CAN FD могут сосуществовать в одной сети с существующими устройствами CAN. [5]

CAN-шина - это один из пяти протоколов, используемых в стандарте бортовой диагностики (OBD) -II. Стандарт OBD-II является обязательным для всех автомобилей и легких грузовиков, продаваемых в США с 1996 года. Стандарт EOBD является обязательным для всех бензиновых автомобилей, продаваемых в Европейском союзе с 2001 года, и всех дизельных автомобилей с 2004 года. [6]

Приложения [ править ]

  • Легковые автомобили, грузовики, автобусы (бензиновые автомобили и электромобили)
  • Сельскохозяйственная техника
  • Электронное оборудование для авиации и навигации
  • Промышленная автоматизация и механическое управление
  • Лифты, эскалаторы
  • Автоматизация зданий
  • Медицинские инструменты и оборудование
  • Pedelecs
  • Модельные железные дороги / железные дороги
  • Суда и другие морские приложения
  • Системы управления освещением

Автомобильная промышленность [ править ]

Современный автомобиль может иметь до 70 электронных блоков управления (ЭБУ) для различных подсистем. [7] Обычно самым большим процессором является блок управления двигателем . Остальные используются для трансмиссии , подушек безопасности , антиблокировочной системы тормозов / ABS , круиз-контроля , электроусилителя руля , аудиосистем, электрических стеклоподъемников., двери, регулировка зеркал, аккумуляторные батареи и системы подзарядки для гибридных / электрических автомобилей и т. д. Некоторые из них образуют независимые подсистемы, но связь между прочим важна. Подсистеме может потребоваться управление исполнительными механизмами или получение обратной связи от датчиков. Стандарт CAN был разработан, чтобы удовлетворить эту потребность. Одним из ключевых преимуществ является то, что взаимосвязь между различными системами транспортного средства может позволить реализовать широкий спектр функций безопасности, экономии и удобства с использованием только программного обеспечения - функциональность, которая увеличила бы стоимость и сложность, если бы такие функции были «жестко подключены» с использованием традиционной автомобильной электрики. Примеры включают:

  • Автоматический запуск / остановка : различные входные сигналы датчиков со всего транспортного средства (датчики скорости, угла поворота рулевого колеса, включение / выключение кондиционера, температура двигателя) сопоставляются через шину CAN, чтобы определить, можно ли остановить двигатель в неподвижном состоянии для повышения экономии топлива и выбросы.
  • Электрические стояночные тормоза : функция "удержания на холме" принимает входные данные от датчика наклона автомобиля (также используемого системой охранной сигнализации) и датчиков скорости движения (также используемых системой ABS, системой управления двигателем и контролем тяги) через шину CAN, чтобы определить, автомобиль остановлен на склоне. Точно так же сигналы от датчиков ремня безопасности (часть органов управления подушками безопасности) поступают от шины CAN, чтобы определить, пристегнуты ли ремни безопасности, так что стояночный тормоз автоматически отпускается при трогании с места.
  • Системы помощи при парковке : когда водитель включает передачу заднего хода, блок управления трансмиссией может послать сигнал по шине CAN для активации как системы датчика парковки, так и модуля управления дверью, чтобы зеркало на боковой двери переднего пассажира наклонилось вниз, чтобы показать положение бордюр. Шина CAN также принимает входные сигналы от датчика дождя для включения стеклоочистителя заднего стекла при движении задним ходом.
  • Системы автоматического ассистента движения по полосе / предотвращения столкновений : входные сигналы от датчиков парковки также используются шиной CAN для передачи данных о внешнем приближении в вспомогательные системы водителя, такие как предупреждение о выезде с полосы движения, а в последнее время эти сигналы проходят через шину CAN для активации тормоза. по проводам в системах активного предотвращения столкновений.
  • Автоматическая очистка тормозов: сигнал поступает от датчика дождя (используется в основном для автоматических дворников ) через шину CAN на модуль ABS, чтобы инициировать незаметное торможение во время движения для удаления влаги с тормозных роторов. Некоторые высокопроизводительные модели Audi и BMW включают эту функцию.
  • Датчики могут быть размещены в наиболее подходящем месте, а их данные используются несколькими ЭБУ. Например, датчики наружной температуры (традиционно размещаемые спереди) можно разместить в наружных зеркалах, чтобы избежать нагрева двигателем, и данные, используемые двигателем, климат-контролем и дисплеем водителя.

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

Другое [ править ]

  • Протокол шины CAN используется в электронной системе переключения передач Shimano DI2 для дорожных велосипедов с 2009 года, а также используется системами Ansmann и BionX в их двигателях с прямым приводом.
  • Шина CAN также используется в качестве полевой шины в средах общей автоматизации, в первую очередь из-за низкой стоимости некоторых контроллеров и процессоров CAN.
  • Производители, в том числе NISMO, стремятся использовать данные шины CAN для воссоздания реальных гоночных кругов в видеоигре Gran Turismo 6 с помощью игровой функции GPS Data Logger, которая затем позволит игрокам участвовать в гонках с реальными кругами. [8]
  • Университет Джонса Хопкинса «s Лаборатории прикладной физики » s Модульное Протезирование Лимб (MPL) использует локальную шину CAN для облегчения связи между сервоприводами и микроконтроллеры в протезом.
  • Команды FIRST Robotics Competition широко используют шину CAN для связи между roboRIO и другими модулями управления роботами.
  • CueScript Телесуфлер диапазон использует протокол шины CAN по коаксиальному кабелю, для подключения его CSSC - Desktop Scroll управления к основному блоку
  • Протокол CAN-шины широко применяется из-за его отказоустойчивости в электрически зашумленных средах, таких как системы обратной связи датчиков модели железной дороги от крупных производителей коммерческих систем управления цифровыми командами и различных проектов управления железной дорогой цифровых моделей с открытым исходным кодом.

Архитектура [ править ]

Физическая организация [ править ]

CAN - это стандарт последовательной шины с несколькими ведущими устройствами для подключения электронных блоков управления (ЭБУ), также известных как узлы. ( Автомобильная электроника - это основная область применения.) Для связи в сети CAN требуются два или более узла. Узел может взаимодействовать с устройствами от простой цифровой логики, например, PLD , через FPGA до встроенного компьютера, на котором запущено обширное программное обеспечение. Такой компьютер также может быть шлюзом, позволяющим компьютеру общего назначения (например, портативному компьютеру) обмениваться данными через порт USB или Ethernet с устройствами в сети CAN.

Все узлы соединены друг с другом через физически обычную двухпроводную шину . Провода представляют собой витую пару с характеристическим сопротивлением 120 Ом (номинальное) .

Эта шина использует дифференциальные проводные сигналы И. Два сигнала, CAN high (CANH) и CAN low (CANL), либо переводятся в «доминирующее» состояние с CANH> CANL, либо не управляются и не переводятся пассивными резисторами в «рецессивное» состояние с CANH ≤ CANL. Бит данных 0 кодирует доминантное состояние, а бит данных 1 кодирует рецессивное состояние, поддерживая соглашение о проводном И, которое дает узлам с более низким приоритетом идентификационных номеров на шине.

Высокоскоростная сеть CAN. ISO 11898-2

ISO 11898-2 , также называемый высокоскоростной CAN (битовая скорость до 1 Мбит / с на CAN, 5 Мбит / с на CAN-FD), использует линейную шину, оконцованную на каждом конце резисторами 120 Ом.

Высокоскоростная сигнализация CAN. ISO 11898-2

Высокоскоростная сигнализация CAN направляет провод CANH к 3,5 В, а провод CANL к 1,5 В, когда какое-либо устройство передает доминантный (0), в то время как, если ни одно устройство не передает доминантный сигнал, согласующие резисторы пассивно возвращают два провода в рецессивный (1) состояние с номинальным дифференциальным напряжением 0 В. (Приемники считают любое дифференциальное напряжение менее 0,5 В рецессивным.) Доминирующим дифференциальным напряжением является номинальное 2 В. Доминирующее синфазное напряжение (CANH + CANL) / 2 должно быть в пределах 1,5–3,5 В от общего, а рецессивное синфазное напряжение должно быть в пределах ± 12 от общего.

Низкоскоростная отказоустойчивая сеть CAN. ISO 11898-3

ISO 11898-3 , также называемый низкоскоростной или отказоустойчивой CAN (до 125 кбит / с), использует линейную шину, звездообразную шину или несколько звездообразных шин, соединенных линейной шиной, и оканчивается на каждом узле на долю общее оконечное сопротивление. Общее оконечное сопротивление должно быть не менее 100 Ом.

Низкоскоростная сигнализация CAN. ISO 11898-3

Низкоскоростная отказоустойчивая сигнализация CAN работает аналогично высокоскоростной CAN, но с большими колебаниями напряжения. Доминантное состояние передается путем направления CANH к напряжению источника питания устройства (5 В или 3,3 В) и CANL к 0 В при передаче доминирующего (0), в то время как согласующие резисторы переводят шину в рецессивное состояние с CANH на 0. V и CANL при 5 В. Это позволяет использовать более простой приемник, который просто учитывает знак CANH-CANL. Оба провода должны выдерживать напряжение от −27 до +40 В без повреждений.

Электрические свойства [ править ]

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

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

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

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

В высокоскоростной CAN используется резистор 120 Ом на каждом конце линейной шины. Низкоскоростной CAN использует резисторы в каждом узле. Могут использоваться другие типы оконечной нагрузки, такие как оконечная цепь смещения, определенная в ISO11783 . [9]

Цепь смещения терминатор обеспечивает питание и заземление в дополнение к сигнализации CAN на четыре-жильного кабеля. Это обеспечивает автоматическое электрическое смещение и согласование на каждом конце каждого сегмента шины . Сеть ISO11783 предназначена для горячего подключения и удаления сегментов шины и ЭБУ.

Узлы [ править ]

Узел CANbus

Каждому узлу требуется

  • Центральный процессор , микропроцессор или хост-процессор
    • Главный процессор решает, что означают полученные сообщения и какие сообщения он хочет передать.
    • Датчики, исполнительные механизмы и устройства управления могут быть подключены к главному процессору.
  • CAN-контроллер; часто является неотъемлемой частью микроконтроллера
    • Прием: контроллер CAN сохраняет полученные последовательные биты от шины до тех пор, пока не станет доступным все сообщение, которое затем может быть извлечено хост-процессором (обычно контроллером CAN, инициирующим прерывание).
    • Отправка: главный процессор отправляет сообщение (я) передачи на контроллер CAN, который последовательно передает биты на шину, когда шина свободна.
  • Приемопередатчик определен стандартами ISO 11898-2 / 3 для устройств доступа к среде [MAU].
    • Прием: он преобразует поток данных с уровней CANbus в уровни, используемые контроллером CAN. Обычно он имеет защитную схему для защиты CAN-контроллера.
    • Передача: он преобразует поток данных от контроллера CAN на уровни CANbus.

Каждый узел может отправлять и получать сообщения, но не одновременно. Сообщение или фрейм состоит в основном из идентификатора (идентификатора), который представляет приоритет сообщения, и до восьми байтов данных. CRC, слот подтверждения [ACK] и другие служебные данные также являются частью сообщения. Усовершенствованный CAN FD увеличивает длину раздела данных до 64 байтов на кадр. Сообщение последовательно передается на шину с использованием формата без возврата к нулю (NRZ) и может быть получено всеми узлами.

Устройства, подключенные к сети CAN, обычно представляют собой датчики , исполнительные механизмы и другие устройства управления. Эти устройства подключаются к шине через хост-процессор , контроллер CAN и трансивер CAN.

Передача данных [ править ]

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

В спецификациях CAN используются термины «доминантные» биты и «рецессивные» биты, где доминантный - это логический 0 (активно приводится в напряжение передатчиком), а рецессивный - это логическая 1 (пассивно возвращается к напряжению с помощью резистора). Состояние ожидания представлено рецессивным уровнем (логическая 1). Если один узел передает доминирующий бит, а другой узел передает рецессивный бит, то возникает конфликт, и доминирующий бит «выигрывает». Это означает, что нет задержки для сообщения с более высоким приоритетом, и узел, передающий сообщение с более низким приоритетом, автоматически пытается повторно передать шестибитовые тактовые импульсы после окончания доминирующего сообщения. Это делает CAN очень подходящей в качестве приоритетной системы связи в реальном времени.

Точные напряжения для логического 0 или 1 зависят от используемого физического уровня, но основной принцип CAN требует, чтобы каждый узел прослушивал данные в сети CAN, включая сам (и) передающий узел (узлы). Если логическая 1 передается всеми передающими узлами одновременно, то логическая 1 видится всем узлам, включая как передающий узел (узлы), так и принимающий узел (узлы). Если логический 0 передается всеми передающими узлами одновременно, то логический 0 видят все узлы. Если логический 0 передается одним или несколькими узлами, а логическая 1 передается одним или несколькими узлами, то логический 0 видят все узлы, включая узел (ы), передающий логическую 1. Когда узел передает логическая 1, но видит логический 0, понимает, что есть конфликт, и прекращает передачу.При использовании этого процесса любой узел, который передает логическую 1, когда другой узел передает логический 0, «выпадает» или теряет арбитраж. Узел, который проиграл арбитраж, повторно ставит свое сообщение в очередь для последующей передачи, и поток битов кадра CAN продолжается без ошибок, пока только один узел не останется в режиме передачи. Это означает, что узел, который передает первую 1, проигрывает арбитраж. Поскольку 11 (или 29 для CAN 2.0B) бит идентификатора передается всеми узлами в начале кадра CAN, узел с наименьшим идентификатором передает больше нулей в начале кадра, и это узел, который выигрывает арбитраж или имеет наивысший приоритет.Узел, который проиграл арбитраж, повторно ставит свое сообщение в очередь для последующей передачи, и поток битов кадра CAN продолжается без ошибок, пока только один узел не останется в режиме передачи. Это означает, что узел, который передает первую 1, проигрывает арбитраж. Поскольку 11 (или 29 для CAN 2.0B) бит идентификатора передается всеми узлами в начале кадра CAN, узел с наименьшим идентификатором передает больше нулей в начале кадра, и это узел, который выигрывает арбитраж или имеет наивысший приоритет.Узел, который проиграл арбитраж, повторно ставит свое сообщение в очередь для последующей передачи, и поток битов кадра CAN продолжается без ошибок, пока только один узел не останется в режиме передачи. Это означает, что узел, который передает первую 1, проигрывает арбитраж. Поскольку 11 (или 29 для CAN 2.0B) бит идентификатора передается всеми узлами в начале кадра CAN, узел с наименьшим идентификатором передает больше нулей в начале кадра, и это узел, который выигрывает арбитраж или имеет наивысший приоритет.узел с наименьшим идентификатором передает больше нулей в начале кадра, и это узел, который выигрывает арбитраж или имеет наивысший приоритет.узел с наименьшим идентификатором передает больше нулей в начале кадра, и это узел, который выигрывает арбитраж или имеет наивысший приоритет.

Например, рассмотрим сеть CAN с 11-битным идентификатором с двумя узлами с идентификаторами 15 (двоичное представление, 00000001111) и 16 (двоичное представление, 00000010000). Если эти два узла осуществляют передачу одновременно, каждый сначала передаст стартовый бит, а затем передаст первые шесть нулей своего идентификатора без принятия арбитражного решения.

Когда передается 7-й бит идентификатора, узел с идентификатором 16 передает 1 (рецессивный) для своего идентификатора, а узел с идентификатором 15 передает 0 (доминантный) для своего идентификатора. Когда это происходит, узел с идентификатором 16 знает, что он передал 1, но видит 0 и понимает, что произошла коллизия, и проиграл арбитраж. Узел 16 прекращает передачу, что позволяет узлу с идентификатором 15 продолжить передачу без потери данных. Узел с наименьшим идентификатором всегда выигрывает арбитраж и, следовательно, имеет наивысший приоритет.

Скорость передачи данных до 1 Мбит / с возможна при длине сети менее 40 м. Уменьшение скорости передачи данных позволяет увеличивать сетевые расстояния (например, 500 м при 125 кбит / с). Усовершенствованный стандарт CAN FD позволяет увеличить скорость передачи данных после арбитража и может увеличить скорость раздела данных до десяти или более раз по сравнению со скоростью передачи данных арбитража.

Назначение идентификатора [ править ]

Идентификаторы сообщений должны быть уникальными [10] на одной шине CAN, в противном случае два узла продолжили бы передачу за пределами поля арбитража (ID), вызывая ошибку.

В начале 1990-х годов выбор идентификаторов для сообщений производился просто на основе идентификации типа данных и отправляющего узла; однако, поскольку идентификатор также используется в качестве приоритета сообщения, это привело к снижению производительности в реальном времени. В этих сценариях обычно требовалось низкое использование шины CAN - около 30%, чтобы гарантировать, что все сообщения уложатся в установленные сроки. Однако, если вместо этого идентификаторы определяются на основе крайнего срока сообщения, чем ниже числовой идентификатор и, следовательно, тем выше приоритет сообщения, то обычно можно достичь использования шины от 70 до 80% до того, как какие-либо крайние сроки сообщения будут пропущены. [11]

Битовая синхронизация [ править ]

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

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

Регулировка выполняется путем деления каждого бита на несколько отрезков времени, называемых квантами, и присвоения некоторого количества квантов каждому из четырех сегментов внутри бита: синхронизации, распространения, фазового сегмента 1 и фазового сегмента 2.

Пример битовой синхронизации CAN с 10 квантами времени на бит.

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

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

Слои [ править ]

Протокол CAN, как и многие сетевые протоколы, можно разделить на следующие уровни абстракции :

Уровень приложения
Слой объекта
  • Фильтрация сообщений
  • Сообщения и обработка статуса
Переносной слой

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

  • Локализация разломов
  • Обнаружение ошибок
  • Проверка сообщения
  • Подтверждение
  • Арбитраж
  • Обрамление сообщения
  • Скорость передачи и время
  • Информационная маршрутизация
Физический слой
Топология электрического образца CAN-шины с оконечными резисторами

CAN-шина ( ISO 11898-1 : 2003) первоначально определяла протокол канального уровня только с абстрактными требованиями для физического уровня, например, утверждая использование среды с множественным доступом на битовом уровне посредством использования доминантного и рецессивного состояний. Электрические аспекты физического уровня (напряжение, ток, количество проводников) определены в ISO 11898.-2: 2003, что сейчас широко распространено. Однако механические аспекты физического уровня (тип и номер разъема, цвета, метки, расположение выводов) еще не определены. В результате автомобильный блок управления двигателем, как правило, будет иметь особый - часто настраиваемый - разъем с различными типами кабелей, два из которых являются линиями шины CAN. Тем не менее, появилось несколько стандартов де-факто для механической реализации, наиболее распространенным из которых является 9-контактный штекер типа D-sub со следующей схемой расположения выводов:

  • контакт 2: CAN-Low (CAN−)
  • контакт 3: GND (Земля)
  • контакт 7: CAN-High (CAN +)
  • контакт 9: CAN V + (питание)
Штекерный разъем DE-9 (штекер).

Этот де-факто механический стандарт для CAN может быть реализован с помощью узла, имеющего как вилку, так и розетку 9-контактные разъемы D-sub, электрически подключенные друг к другу параллельно внутри узла. Питание шины подается на штекерный соединитель узла, а шина получает питание от гнездового соединителя узла. Это соответствует принятому в электротехнике соглашению, согласно которому источники питания подключаются к розеткам. Принятие этого стандарта позволяет избежать необходимости изготовления специальных разветвителей для подключения двух наборов шинных проводов к одному D-разъему на каждом узле. Такие нестандартные (нестандартные) жгуты проводов (разветвители), которые соединяют проводники вне узла, снижают надежность шины, исключают взаимозаменяемость кабелей, снижают совместимость жгутов проводов и увеличивают стоимость.

Отсутствие полной спецификации физического уровня (механического в дополнение к электрическому) освободило спецификацию шины CAN от ограничений и сложности физической реализации. Однако это оставило реализации CAN-шины открытыми для проблем совместимости из-за механической несовместимости. Чтобы улучшить совместимость, многие производители транспортных средств создали спецификации, описывающие набор разрешенных CAN-трансиверов в сочетании с требованиями к паразитной емкости на линии. Допустимая паразитная емкость включает как конденсаторы, так и защиту от электростатического разряда (ESD [13]по ISO 7637-3). В дополнение к паразитной емкости системы 12 В и 24 В не имеют одинаковых требований в отношении максимального напряжения линии. Действительно, во время мероприятий по запуску от внешнего источника линии легковых автомобилей могут достигать 24 В, в то время как системы грузовых автомобилей могут достигать 36 В. На рынке появляются новые решения, позволяющие использовать один и тот же компонент как для CAN, так и для CAN FD (см. [14] ).

Помехоустойчивость согласно ISO 11898-2 : 2003 достигается за счет поддержания дифференциального импеданса шины на низком уровне с помощью резисторов низкого сопротивления (120 Ом) на каждом конце шины. Однако в неактивном состоянии шина с низким сопротивлением, такая как CAN, потребляет больше тока (и мощности), чем другие сигнальные шины на основе напряжения. В системах шины CAN, сбалансированная линия работа, где ток в одной сигнальной линии точно сбалансированные по току в направлении , противоположного направлению в другом сигнале обеспечивает независимое, опорное напряжение стабильно 0 для приемников. В соответствии с передовой практикой сигналы симметричной пары шины CAN передаются по витой паре в экранированном кабеле, чтобы минимизировать радиочастотное излучение и снизить восприимчивость к помехам в уже зашумленной радиочастотной среде автомобиля.

ISO 11898-2 обеспечивает некоторую невосприимчивость к синфазному напряжению между передатчиком и приемником благодаря тому, что по шине проходит шина 0 В, чтобы поддерживать высокую степень связи напряжения между узлами. Кроме того, в де-факто механической конфигурации, упомянутой выше, имеется шина питания для распределения мощности по каждому из узлов приемопередатчика. В конструкции предусмотрено общее питание для всех трансиверов. Фактическое напряжение, подаваемое на шину, и то, какие узлы применяются к ней, зависят от приложения и формально не указываются. В стандартной конструкции узла каждый узел снабжен приемопередатчиками, которые оптически изолированы от хоста узла и получают линейно регулируемое напряжение питания 5 В для приемопередатчиков от универсальной шины питания, обеспечиваемой шиной.Обычно это обеспечивает операционную маржу на шине питания, достаточную для обеспечения взаимодействия между многими типами узлов. Типичные значения напряжения питания в таких сетях составляют от 7 до 30 В. Однако отсутствие официального стандарта означает, что разработчики системы несут ответственность за совместимость с шинами питания.

ISO 11898-2 описывает электрическую реализацию, сформированную из конфигурации многоточечной несимметричной симметричной линии с оконечным резистором на каждом конце шины. В этой конфигурации доминирующее состояние утверждается одним или несколькими передатчиками, переключающими CAN− на подачу 0 В и (одновременно) переключающими CAN + на напряжение шины +5 В, тем самым формируя путь тока через резисторы, замыкающие шину. Таким образом, согласующие резисторы являются важным компонентом системы сигнализации и включены не только для ограничения отражения волн на высокой частоте.

Во время рецессивного состояния сигнальные линии и резистор (-ы) остаются в состоянии высокого импеданса по отношению к обеим рельсам. Напряжения на CAN + и CAN− имеют тенденцию (слабо) к напряжению на полпути между шинами. Рецессивное состояние присутствует на шине только тогда, когда ни один из передатчиков на шине не заявляет о доминантном состоянии.

Во время доминирующего состояния сигнальные линии и резистор (ы) переходят в состояние с низким импедансом по отношению к шинам, так что ток течет через резистор. Напряжение CAN + стремится к +5 В, а CAN− стремится к 0 В.

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

Эта стратегия передачи сигналов значительно отличается от других технологий передачи симметричных линий, таких как RS-422 /3, RS-485 и т. Д., В которых используются драйверы / приемники дифференциальной линии и система сигнализации, основанная на напряжении дифференциального режима симметричной линии, пересекающей условную 0 В. Множественный доступ в таких системах обычно зависит от среды, поддерживающей три состояния (активный высокий, активный низкий и неактивный трехсостояний), и обрабатывается во временной области. Множественный доступ к шине CAN достигается за счет того, что электрическая логика системы поддерживает только два состояния, которые концептуально аналогичны сети «проводное И».

Рамки [ править ]

Сеть CAN может быть настроена для работы с двумя разными форматами сообщений (или «фреймов»): стандартным или базовым форматом фрейма (описанным в CAN 2.0 A и CAN 2.0 B) и расширенным форматом фрейма (описанным только в CAN 2.0 B. ). Единственное различие между двумя форматами состоит в том, что «базовый кадр CAN» поддерживает длину идентификатора 11 бит, а «расширенный кадр CAN» поддерживает длину 29 бит для идентификатора, состоящего из 11-битного идентификатора. («базовый идентификатор») и 18-битное расширение («расширение идентификатора»). Различие между форматом базового кадра CAN и расширенным форматом кадра CAN проводится с помощью бита IDE, который передается как доминирующий в случае 11-битного кадра и передается как рецессивный в случае 29-битного кадра.Контроллеры CAN, поддерживающие сообщения расширенного формата кадра, также могут отправлять и получать сообщения в формате основного кадра CAN. Все кадры начинаются с бита начала кадра (SOF), который обозначает начало передачи кадра.

CAN имеет четыре типа кадров:

  • Фрейм данных: фрейм, содержащий данные узла для передачи.
  • Удаленный кадр: кадр, запрашивающий передачу определенного идентификатора.
  • Кадр ошибки: кадр, передаваемый любым узлом, обнаруживающим ошибку.
  • Кадр перегрузки: кадр для вставки задержки между данными или удаленным кадром

Фрейм данных [ править ]

Фрейм данных - единственный фрейм для фактической передачи данных. Есть два формата сообщений:

  • Формат базового кадра: с 11 битами идентификатора
  • Расширенный формат кадра: с 29 битами идентификатора

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

Базовый формат кадра [ править ]

CAN-Frame в базовом формате с электрическими уровнями без вставных битов

Формат кадра следующий: Битовые значения описаны для сигнала CAN-LO.

  1. ^ Физически возможно передать значение от 9 до 15 в 4-битном DLC, хотя размер данных по-прежнему ограничен восемью байтами. Некоторые контроллеры позволяют передавать или принимать DLC больше восьми, но фактическая длина данных всегда ограничена восемью байтами.

Расширенный формат кадра [ править ]

Формат кадра следующий:

  1. ^ Физически возможно передать значение от 9 до 15 в 4-битном DLC, хотя размер данных по-прежнему ограничен восемью байтами. Некоторые контроллеры позволяют передавать или принимать DLC больше восьми, но фактическая длина данных всегда ограничена восемью байтами.

Два поля идентификатора (A и B) вместе образуют 29-битный идентификатор.

Удаленный кадр [ править ]

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

т.е.

RTR = 0; ДОМИНАНТ во фрейме данных
RTR = 1; РЕЦЕССИВ в удаленном кадре

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

Кадр ошибки [ править ]

Кадр ошибки состоит из двух разных полей:

  • Первое поле задается наложением ФЛАГОВ ОШИБОК (6–12 доминирующих / рецессивных битов), поступающих от разных станций.
  • Следующее второе поле - это РАЗДЕЛИТЕЛЬ ОШИБОК (8 рецессивных битов).

Есть два типа флагов ошибок:

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

В CAN есть два счетчика ошибок:

 1. Счетчик ошибок передачи (TEC) 2. Счетчик ошибок приема (REC)
  • Когда TEC или REC больше 127 и меньше 255, по шине будет передан кадр пассивной ошибки.
  • Когда TEC и REC меньше 128, по шине будет передан кадр активной ошибки.
  • Когда TEC больше 255, узел переходит в состояние отключения шины, в котором кадры не передаются.

Кадр перегрузки [ править ]

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

  1. Внутренние условия приемника, требующие задержки следующего кадра данных или удаленного кадра.
  2. Обнаружение доминирующего бита во время антракта.

Начало кадра перегрузки из-за случая 1 разрешается начинать только в первый битовый момент ожидаемого перерыва, тогда как кадры перегрузки из-за случая 2 начинаются через один бит после обнаружения доминирующего бита. Флаг перегрузки состоит из шести доминирующих битов. Общая форма соответствует форме активного флага ошибки. Форма флага перегрузки разрушает фиксированную форму поля перерыва. Как следствие, все другие станции также обнаруживают состояние перегрузки и со своей стороны начинают передачу флага перегрузки. Ограничитель перегрузки состоит из восьми рецессивных битов. Разделитель перегрузки имеет ту же форму, что и разделитель ошибок.

Слот ACK [ править ]

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

Часто режим работы устройства заключается в повторной передаче неподтвержденных кадров снова и снова. Это может в конечном итоге привести к переходу в состояние "пассивной ошибки".

Межкадровый интервал [ править ]

Кадры данных и удаленные кадры отделены от предыдущих кадров битовым полем, называемым межкадровым пространством. Межкадровое пространство состоит как минимум из трех последовательных рецессивных (1) битов. После этого, если обнаруживается доминирующий бит, он будет считаться битом «Начало кадра» следующего кадра. Кадрам перегрузки и кадрам ошибок не предшествует межкадровое пространство, а множественные кадры перегрузки не разделяются межкадровым пространством. Межкадровое пространство содержит битовые поля прерывания и ожидания шины, а также приостановку передачи для пассивных по ошибке станций, которые были передатчиками предыдущего сообщения. [15]

Битовая набивка [ править ]

CAN-Frame до и после добавления битов заполнения (фиолетовый)

Чтобы обеспечить достаточное количество переходов для поддержания синхронизации, бит противоположной полярности вставляется после пяти последовательных битов той же полярности. Эта практика называется вставкой битов и необходима из-за кодирования без возврата к нулю (NRZ), используемого с CAN. Заполненные кадры данных уничтожаются получателем.

Заполняются все поля кадра, за исключением разделителя CRC, поля ACK и конца кадра, которые имеют фиксированный размер и не заполняются. В полях, где используется вставка битов, шесть последовательных битов одной полярности (111111 или 000000) считаются ошибкой. Флаг активной ошибки может быть передан узлом при обнаружении ошибки. Флаг активной ошибки состоит из шести последовательных доминирующих битов и нарушает правило вставки битов.

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

11111000011110000 ...

который набивается как (биты набиты жирным шрифтом):

11111 0 0000 1 1111 0 0000 1 ...

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

Размер базовой рамы ограничен

поскольку это размер кадра перед заполнением, в худшем случае один бит будет добавляться через каждые четыре исходных бита после первого (отсюда -1 в числителе) и, из-за расположения битов заголовка, только 34 из 44 могут быть подвергнуты набивке долота.

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

Стандарты нижнего уровня CAN [ править ]

Серия ISO 11898 определяет физический уровень и уровень передачи данных (уровни 1 и 2 модели ISO / OSI ) категории последовательной связи, называемой сетью контроллеров, которая поддерживает распределенное управление в реальном времени и мультиплексирование для использования в дорожных транспортных средствах. [16]

Существует несколько физических уровней CAN и других стандартов:

ISO 11898-1: 2015 определяет уровень канала передачи данных (DLL) и физическую сигнализацию сети контроллера (CAN) . [17] Этот документ описывает общую архитектуру CAN с точки зрения иерархических уровней в соответствии с эталонной моделью ISO для взаимодействия открытых систем (OSI), установленной в ISO / IEC 7498-1, и предоставляет характеристики для настройки обмена цифровой информацией между модули, реализующие CAN DLL с подробной спецификацией подуровня управления логическим каналом (LLC) и подуровня управления доступом к среде (MAC) .

ISO 11898-2: 2016 определяет высокоскоростной (скорость передачи до 1 Мбит / с) блок доступа к среде (MAU) и некоторые функции зависимого от среды интерфейса (MDI) (согласно ISO 8802-3), которые включают физический уровень сети контроллера. ISO 11898-2 использует двухпроводную симметричную схему сигнализации. Это наиболее часто используемый физический уровень в приложениях для силовых агрегатов транспортных средств и промышленных сетях управления.

ISO 11898-3: 2006 определяет низкоскоростной, отказоустойчивый, зависимый от среды интерфейс для настройки обмена цифровой информацией между электронными блоками управления дорожных транспортных средств, оборудованных CAN, со скоростью передачи от 40 кбит / с до 125 кбит / с. / с.

ISO 11898-4: 2004 определяет синхронизируемую по времени связь в CAN (TTCAN). Он применим для настройки синхронизированного по времени обмена цифровой информацией между электронными блоками управления (ЭБУ) дорожных транспортных средств, оснащенных CAN, и определяет объект кадровой синхронизации, который координирует работу как логической связи, так и средств управления доступом к среде в соответствии с ISO. 11898-1, чтобы обеспечить расписание связи по времени.

ISO 11898-5: 2007 определяет физический уровень CAN для скорости передачи до 1 Мбит / с для использования в дорожных транспортных средствах. В нем описаны функции устройства доступа к среде, а также некоторые функции интерфейса, зависящие от среды, в соответствии с ISO 8802-2. Это представляет собой расширение ISO 11898-2, касающееся новых функций для систем, требующих функций с низким энергопотреблением при отсутствии активной связи по шине.

ISO 11898-6: 2013 определяет физический уровень CAN для скорости передачи до 1 Мбит / с для использования в дорожных транспортных средствах. В нем описаны функции устройства доступа к среде, а также некоторые функции интерфейса, зависящие от среды, в соответствии с ISO 8802-2. Это представляет собой расширение ISO 11898-2 и ISO 11898-5, определяющее механизм выборочного пробуждения с использованием настраиваемых кадров CAN.

ISO 16845-1: 2016 предоставляет методологию и набор абстрактных тестов, необходимых для проверки соответствия любой реализации CAN CAN, указанной в ISO 11898-1.

ISO 16845-2: 2018 устанавливает тестовые примеры и требования к тестированию для реализации плана тестирования, проверяющего, соответствует ли трансивер CAN с реализованными функциями выборочного пробуждения указанным функциям. Тип тестирования, определенный в ISO 16845-2: 2018, называется тестированием на соответствие.

Протоколы более высокого уровня на основе CAN [ править ]

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

CAN in Automation (CiA) - это международная организация пользователей и производителей, которая разрабатывает и поддерживает протоколы более высокого уровня на основе CAN и их международную стандартизацию. [18] Среди этих спецификаций:

Стандартизированные подходы [ править ]

  • ARINC 812 или ARINC 825 (авиационная промышленность)
  • CANopen - CiA 301 / 302-2 и EN 50325-4 (промышленная автоматизация )
  • IEC 61375-3-3 (использование CANopen в рельсовых транспортных средствах)
  • DeviceNet (промышленная автоматизация )
  • EnergyBus - CiA 454 и IEC 61851 -3 (связь между аккумулятором и зарядным устройством)
  • ISOBUS - ISO 11783 (сельское хозяйство)
  • ISO-TP - ISO 15765-2 (транспортный протокол для автомобильной диагностики)
  • MilCAN (военные автомобили)
  • NMEA 2000 - IEC 61162-3 (морская промышленность)
  • SAE J1939 (автомобильная сеть для автобусов и грузовиков)
  • SAE J2284 (автомобильные сети для легковых автомобилей)
  • Единые диагностические услуги (UDS) - ISO 14229 (автомобильная диагностика)
  • LeisureCAN - открытый стандарт для индустрии развлечений и автомобилей

Другие подходы [ править ]

  • CANaerospace - Stock (для авиационной промышленности)
  • CAN Kingdom - Kvaser (встроенная система управления)
  • CCP / XCP (автомобильная калибровка ЭБУ)
  • GMLAN - General Motors (для General Motors )
  • RV-C - RVIA (используется для транспортных средств для отдыха)
  • SafetyBUS p - Pilz (используется для промышленной автоматизации )
  • UAVCAN (аэрокосмическая промышленность и робототехника)
  • CSP (космический протокол CubeSat)
  • VSCP (Very Simple Control Protocol) - бесплатный протокол автоматизации, подходящий для всех видов задач автоматизации.

CANopen Lift [ править ]

CANopen Special Interest Group (SIG) «Lift Control», основанная в 2001 году, разрабатывает профиль приложения CANopen CiA 417 для систем управления лифтами. Он работает над расширением функций, улучшает техническое содержание и обеспечивает соблюдение действующих правовых стандартов для систем управления лифтами. Первая версия CiA 417 была опубликована (доступна для членов CiA) летом 2003 года, версия 2.0 - в феврале 2010 года, версия 2.1.0 - в июле 2012 года, версия 2.2.0 - в декабре 2015 года и версия 2.3.1 - в феврале 2020 года.

Йорг Хельмих (ELFIN GmbH) является председателем этого SIG и руководит вики-страницей сообщества CANopen, посвященной лифтам, с материалами о подъемниках CANopen.

Безопасность [ править ]

CAN - это протокол низкого уровня, который внутренне не поддерживает никаких функций безопасности. В стандартных реализациях CAN также отсутствует шифрование, что оставляет эти сети открытыми для перехвата кадра «злоумышленник в середине». В большинстве реализаций ожидается, что приложения будут развертывать свои собственные механизмы безопасности; например, для аутентификации входящих команд или наличия определенных устройств в сети. Невыполнение адекватных мер безопасности может привести к разного рода атакам, если противнику удастся вставить сообщения в шину. [19] Хотя существуют пароли для некоторых критически важных для безопасности функций, таких как изменение прошивки, программирование ключей или управление приводами антиблокировочной системы тормозов, эти системы не применяются повсеместно и имеют ограниченное количество пар начальное значение / ключ.

Инструменты разработки [ править ]

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

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

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

Библиотека python-can обеспечивает как пассивный мониторинг , так и активный контроль доступа к CAN-шине на широком спектре платформ.

Лицензирование [ править ]

Компания Bosch владеет патентами на эту технологию, однако срок действия патентов, относящихся к исходному протоколу, истек. Производители CAN-совместимых микропроцессоров платят Bosch лицензионные сборы за использование товарного знака CAN и любых новых патентов, связанных с CAN FD, и они обычно передаются заказчику в цене чипа. Производители продуктов с настраиваемыми ASIC или FPGA, содержащими CAN-совместимые модули, должны вносить плату за лицензию на протокол CAN, если они хотят использовать торговую марку CAN или возможности CAN FD. [20]

См. Также [ править ]

  • Byteflight
  • Автозвук
  • Монитор CAN-шины
  • CANopen - протокол связи для встроенных систем
  • CANpie - драйвер устройства с открытым исходным кодом для CAN
  • CAN FD - новая реализация CAN с более быстрой передачей
  • can4linux - Драйвер устройства Linux с открытым исходным кодом для CAN
  • FlexCAN - альтернативная реализация.
  • FlexRay - возможное направление в будущем
  • Список сетевых автобусов
  • Местная межкомпонентная сеть - недорогая альтернатива
  • Modbus
  • MOST автобус
  • OBD-II PID - список идентификаторов параметров
  • ОСЭК
  • SAE J1939 - Протокол связи для грузовиков и автобусов
  • SocketCAN - набор драйверов CAN с открытым исходным кодом и сетевой стек, предоставленный Volkswagen Research для ядра Linux.

Ссылки [ править ]

  1. ^ a b «История CAN» . CAN в автоматизации.
  2. ^ "Mercedes-Benz S-Class W 140" . mercedes-benz.com . 23 февраля 2016 . Проверено 27 октября 2017 года .
  3. ^ «CAN в автоматизации - Mercedes W140: первая машина с CAN» . can-newsletter.org . Проверено 27 октября 2017 года .
  4. ^ "Литература Bosch Semiconductor CAN" . Архивировано из оригинала на 2017-05-23 . Проверено 31 мая 2017 .
  5. ^ де Андраде, Р.; Ходель, KN; Хусто, JF; Laganá, AM; Сантос, ММ; Гу, З. (2018). «Аналитические и экспериментальные оценки производительности шины CAN-FD» . Доступ IEEE . 6 : 21287–21295. DOI : 10,1109 / ACCESS.2018.2826522 .
  6. ^ Строительный адаптер для бортовой диагностики автомобиля. Архивировано 14 мая 2018 г. на Wayback Machine , obddiag.net, доступ 9 сентября 2009 г.
  7. ^ Сравнение концепций, запускаемых по событию и по времени, в отношении распределенных систем управления А. Альберт, Robert Bosch GmbH Embedded World, 2004, Нюрнберг
  8. ^ «NISMO увеличивает функциональность регистратора данных GPS GT6 и количество треков» . www.gtplanet.net .
  9. ^ "ISO11783 Стандартизированный трактор - интерфейс агрегата" (PDF) .
  10. ^ ISO 11898-1: 2015 - Транспорт дорожный - Сеть контроллеров (CAN) - Часть 1: Уровень канала передачи данных и физическая сигнализация.
  11. ^ Дайгморте, Хьюго; Бойер, Марк (2017), "Оценка допустимой нагрузки шины CAN со слабым механизмом синхронизации" , Proc. 24-й Междунар. Конф. по сетям и системам реального времени (RTNS 2017) , Гренобль, Франция: ACM
  12. ^ "Понимание битовой синхронизации модуля CAN Microchip" (PDF) .
  13. ^ "Защита диодов ISO7637-3 для CAN-шины" .
  14. ^ "Защита CAN-шины от электростатического разряда" .
  15. ^ «КАДРЫ СООБЩЕНИЙ CAN BUS - кадр перегрузки, межкадровое пространство» .
  16. ^ «Сеть контроллеров (CAN)» . Векторная группа. Архивировано из оригинального 25 апреля 2016 года . Дата обращения 25 сентября 2013 .
  17. ^ «ISO 11898-1: 2003 - Дорожные транспортные средства - Контроллерная сеть (CAN) - Часть 1: Уровень передачи данных и физическая сигнализация» . ISO.
  18. ^ CiA: Международная стандартизация .
  19. ^ «Мы вели машину, пока ее взламывали» . www.vice.com . Архивировано 8 ноября 2019 года.
  20. ^ «Условия лицензии Протокол CAN и протокол CAN FD» (PDF) . Архивировано из оригинального (PDF) 16 марта 2016 года . Проверено 15 марта 2016 .

Внешние ссылки [ править ]

  • Спецификация Bosch (старый документ - немного двусмысленно / неясно в некоторых пунктах, заменен стандартом [1] )
  • Спецификация Bosch CAN FD версии 1.0
  • Анализ возможности планирования сети контроллеров (CAN): опровергнуто, пересмотрено и пересмотрено
  • Распиновка общих разъемов CAN-шины
  • Веб-страница о CAN в автомобилестроении
  • Анализ возможности планирования сети контроллеров (CAN) с очередями FIFO
  • Руководство по внедрению сети контроллеров (CAN)
  • Бесплатный калькулятор битовой синхронизации для Windows, поддерживает множество микроконтроллеров, например Atmel, STM32, Microchip, Renesas, ... (ZIP-файл)
  • Бесплатный модуль электронного обучения «Знакомство с CAN»
  • Учебное пособие по ARINC-825 (видео) от Excalibur Systems Inc.
  • Сайт CiA
  • Информационный бюллетень CAN онлайн
  • Понимание и использование сети контроллеров от Калифорнийского университета в Беркли
  • Учебное пособие по протоколу CAN
  • Защита от электростатического разряда для CAN-шины и CAN FD