CAN (Controller Area Network) в настоящее время является наиболее широко используемой автомобильной бортовой сетью. Однако в связи с постоянным развитием автономных транспортных средств и связанных с ними технологий существует высокий спрос на большую пропускную способность и возможности подключения. Здесь мы кратко опишем CAN и некоторые другие варианты подключения транспортных средств, включая беспроводную CAN, MOST, FlexRay и Automotive Ethernet.
CAN-шина: основные принципы
В широком смысле CAN-шина (Controller Area Network) на самом деле представляет собой набор стандартов, которые позволяют различным устройствам обмениваться данными друг с другом. Это асинхронная (со сдвигом по времени) система последовательной шины, разработанная в 1983 году компанией Robert Bosch GmbH с целью объединения электронных блоков управления (ECU) в транспортных средствах.
CAN был разделен на несколько уровней в соответствии с моделью ISO/OSI для достижения гибкости и прозрачности дизайна. Для практической связи CAN-шина использует два выделенных провода: CAN low и CAN high, с помощью которых контроллер CAN подключается ко всем компонентам сети. CAN позволяет заменить довольно сложную разводку на двухпроводную шину. CAN использует дифференциальный сигнал, что делает его более устойчивым к помехам, с двумя логическими состояниями: рецессивным и доминантным. В настоящее время шина CAN используется практически везде, от кофемашин до управления автопарком и космических приложений. Далее мы кратко опишем принципы работы CAN-шины.
Протокол связи CAN ISO-11898: 2003 объясняет, как информация передается между устройствами в сети, на основе модели взаимодействия открытых систем (OSI), представленной в виде набора уровней на рисунке ниже. Два нижних уровня семиуровневой модели OSI/ISO — это физический уровень и уровень канала передачи данных. Физический уровень определяет связь между устройствами, соединенными физической средой.
Канальный уровень, помимо прочего, также занимается организацией битов в фреймы и включает два протокола: классический CAN (первое использование датировано 1988 годом) и CAN FD (запущено в 2012 году).
Прикладной уровень — это, по сути, уровень конечного пользователя, обеспечивающий доступ к сетевым ресурсам. Существует два типа форматов сообщений/фреймов: стандартные и расширенные. Они отличаются друг от друга только длиной идентификатора — стандартный — 11 бит, расширенный — 29 бит.
Стандартная структура сообщения может быть разделена на 8 частей, как показано на рисунке ниже. Этими частями являются: Start of Frame (SOF — начало передачи фрейма), CAN-ID (идентификатор фрейма, идентификация приоритета сообщения), Remote Transmission Request (RTR, указывает, запрашивает ли узел данные у другого узла или отправляет данные), Control (отображает длину данных в байтах), Data (фактические значения данных, которые необходимо для масштабировать/преобразовывать), Cyclic Redundancy Check (CRC, обеспечение целостности данных), ACK (подтверждение, указывает, правильно ли получены данные) и EOF (конец фрейма), который обозначает конец сообщения/фрейма CAN.
В шине CAN используется инвертированная логика с двумя состояниями: доминантным и рецессивным. На рисунке выше показана упрощенная схема ввода-вывода трансивера CAN: битовый поток, идущий к/от CAN-контроллера и/или микроконтроллера. Когда контроллер отправляет поток битов, они дополняются и помещаются в линию CANH.
Линия CANL всегда является дополнением CANH. CAN должен контролировать как то, что в данный момент находится на шине, так и то, что она отправляет. Для приложений оба конца CAN-шины должны быть ограничены, поскольку любой узел на шине может передавать данные.
На каждом конце линии есть согласующий резистор, равный характеристическому сопротивлению кабеля. Обычно рекомендуемое значение оконечных резисторов составляет 120 Ом (в диапазоне от 100 Ом до 130 Ом). В сети должно быть не более двух согласующих резисторов, поскольку дополнительные ограничительные устройства создают дополнительную нагрузку на драйверы.
На рисунке ниже показана тестовая шина CAN. Узлы на рисунке в принципе могут отправлять сообщения от интеллектуальной сенсорной технологии и контроллера двигателя. Типичным применением может быть, например, датчик температуры.
Если другому узлу необходимо одновременно отправить сообщение, арбитраж гарантирует, что сообщение отправлено. Например, узел A завершает отправку своего сообщения, поскольку узлы B и C подтверждают получение правильного сообщения. Узлы B и C в свою очередь начинают арбитраж, и если узел C выигрывает арбитраж, он отправляет сообщение. Узлы A и B подтверждают сообщение от узла C, и узел B затем продолжает свое сообщение.
Следует помнить о противоположной полярности входа и выхода драйвера на шине. CAN-шина в наши дни широко распространена в автомобилях. Он присутствует практически во всех производимых автомобилях. Автомобили в современном мире по сути являются продуктом глобального рынка, поэтому все автомобили, как правило, имеют шину CAN. Доступ к шине CAN осуществляется через порт OBD, который показан на рисунке ниже вместе с примером оконечного резистора 120 Ом, припаянного к разъему DB9 с проводкой CAN, расположенной в корпусе DB9.
Для подключения порта OBD к устройству CAN DB9 необходим кабель, который можно купить или изготовить. Чтобы получить самодельный, необходимы 9-контактное гнездо D-sub (розетка) и штекер OBD (вилка). Разъем DB9 должен соответствовать вилке устройства CAN.
Пример подключения OBD к DB9 CAN, включая дополнительный оконечный резистор, также показан на схемах ниже.
Существует множество вариантов построения сенсорной сети, интерфейса с шиной CAN и просмотра сигналов CAN от транспортных средств. Различные микроконтроллеры в настоящее время поддерживают протокол CAN и могут быть подключены к CAN через чип приемопередатчика CAN.
Также существуют такие решения, как Raspberry Pi, Texas Instruments Launchpad и Arduino, которые могут взаимодействовать с CAN с помощью некоторых надстроек. Сеть связи CAN в современных транспортных средствах может предоставлять огромный объем данных, которые можно использовать в управлении автопарком для повышения безопасности водителя, сокращения общих расходов, улучшения процессов обслуживания и поддержки экологической ответственности.
Включение данных шины CAN предоставляет владельцам автопарков широкие возможности для доступа к различной информации, включая расход топлива, показания одометра, обороты в минуту, положение дроссельной заслонки, нагрузку/крутящий момент двигателя, температуру двигателя и уровень топлива.
CAN в настоящее время является наиболее широко используемой автомобильной сетью. Однако в связи с постоянным развитием автономных транспортных средств и связанных с ними технологий существует высокий спрос на большую пропускную способность и возможности подключения. Далее мы кратко опишем некоторые другие варианты подключения к автомобилю, включая беспроводную CAN, MOST, FlexRay и Automotive Ethernet.
Wireless CAN
CAN на витой паре медных проводов стал стандартом ISO в 1994 году. Растущий спрос на расширенные возможности подключения приводит к развитию альтернативных и дополнительных технологий. Например, некоторые варианты беспроводной передачи CAN полагаются на стандарты радиосвязи на основе протокола, такие как WLAN или Bluetooth.
В таком случае данные CAN в передатчике должны быть преобразованы в беспроводной протокол и сброшены в приемнике. Таким образом, прозрачная передача в реальном времени по сети CAN невозможна. Таким образом, радиосвязь функционирует как шлюз между двумя сетями CAN.
Беспроводная CAN, основанная на двухрежимном радио, позволяет участникам CAN без проводов интегрироваться в сеть CAN, повышая безопасность и удобство использования. Однако для такой системы требуются специальные антенны, которые требуют места и определенного расположения, ограничивающего всенаправленное излучение.
Кратко о MOST, FlexRay и Automotive Ethernet
Многообещающей альтернативой CAN являетсяAutomotive Ethernet. По некоторым оценкам, рынок автомобильных сетей Ethernet вырастет более чем на 21,6% в прогнозный период 2019-2026 годов.
Ключевые преимущества Ethernet для подключения транспортных средств — высокая пропускная способность и экономическая эффективность. Ethernet использует Carrier Sense Multiple Access и Collision Detection (CSMA/CD). Collision можно игнорировать посредством разделения в автомобильных сетях. Некоторые проблемы автомобильной сети Ethernet — это значительный уровень радиочастотного шума, неспособность обеспечить задержку вплоть до диапазона малых микросекунд и отсутствие способа синхронизации времени между устройствами.
MOST (Media Oriented System Transport) — это система последовательной связи для передачи управляющих данных, видео и аудио по оптоволоконным кабелям. Она обеспечивает двухточечный обмен звуковой и видео информацией со скоростью 24,8 Мбит/с. MOST создается ассоциацией MOST и определяет уровни протокола, программного и аппаратного обеспечения, необходимые для обеспечения эффективной и недорогой транспортировки управляющих данных в реальном времени и пакетных данных с использованием единого промежуточного/физического уровня. Сеть MOST может быть схематично представлена в виде кольца, которое может включать до 64 устройств MOST. Благодаря функции plug & play добавление или удаление устройства MOST должно быть довольно простым.
FlexRay, в свою очередь, является стандартом автомобильной сети, основанным на гибкой, детерминированной, отказоустойчивой и высокоскоростной шине с высокой скоростью передачи данных. Он используется как часть звездообразной или линейной топологии с медным или оптическим волокном. FlexRay с двухканальной конфигурацией обеспечивает повышенную отказоустойчивость и/или увеличенную пропускную способность. Сетевые особенности FlexRay делают его удобным для автомобильной промышленности следующего поколения.
Большинство сетей FlexRay первого поколения обычно используют один канал для сокращения затрат на проводку, но дальнейшее развитие приложений и связанные с этим требования безопасности приведут к увеличению использования двух каналов. Ограничивающими факторами для широкого использования FlexRay являются цена, более низкие уровни рабочего напряжения и асимметрия фронтов, что приводит к проблемам при увеличении длины сети. Некоторые ключевые особенности перечисленных протоколов по сравнению с характеристиками CAN представлены в таблице ниже.
Прямое сравнение перечисленных протоколов связи показывает, что пропускная способность и отказоустойчивость явно уступают средним затратам и сложности системы. В то время как CAN и MOST остаются своего рода фундаментальными протоколами, FlexRay и Ethernet являются более многообещающим решением для удовлетворения растущего рынка и требований приложений с высокой нагрузкой. В современных автомобилях эти протоколы часто используются в качестве дополнительных решений.
Сеть в автомобиле
CAN-шина действительно является хорошо известным и признанным стандартом подключения транспортных средств. Он соединен с силовым агрегатом, шасси, магистральной сетью и системами кузова. Для практической связи CAN-шина использует два выделенных провода: CAN low и CAN high, с помощью которых контроллер CAN подключается к различным компонентам сети. Ethernet, в свою очередь, обычно используется в качестве диагностического протокола для блоков управления электронными соединениями двигателя, шасси и кузова, используемых для сетевых соединений.
FlexRay в настоящее время составляет основу для активной разработки технологий во всем мире, и его многочисленные приложения включают системы X-by-Wire нового поколения и магистральные системы. MOST — это стандарт шины для автомобильных мультимедийных сетей, предназначенный для передачи высококачественного звука, видео и данных. Он позволяет легко соединять различные мультимедийные компоненты автомобиля.
Все вышеупомянутые протоколы и технологии удовлетворяют большинству требований диагностики и мультимедийной связи для современных транспортных средств и связи между транспортными средствами и могут использоваться для продвинутых автономных систем вождения, однако точная интеграция всех этих технологий, при соблюдении все ограничений, по-прежнему остается сложной задачей.
Зачем нужны Can Lin в автосигнализации.
Часто в характеристиках авто сигнализации можно увидеть фразу Can Lin шина. На пальцах разбираем зачем это нам нужно.
CAN и LIN шина- что это такое.

Во – первых? что такое шина.
Шина – в данном случае, это не часть колеса. Назовем её просто автомобильный интернет.
Но интернет для своих устройств.
До 1991 года в автомобилях не было подобной сети. От каждого электрического устройства к кнопке или рычагу управления тянулся свой кабель. А таких устройств было больше сотни.
Каждая лампочка, поворотник, подсветка салона, габариты ближний свет и дальний свет – имели свой кабель. Разнообразные датчики двигателя, температуры, индикация открытых дверей и капота, лючка бензобака. От каждого такого электронного устройства тянулся свой кабель. Всё это привело к тому, что электрика автомобиля стала похожа на паутину гигантского паука, а длина кабелей стала исчисляться Километрами.
Чем больше электронных устройств стало появляться в автомобиле (и не только), тем более очевиден становился вопрос организации всей этой паутины. Для упрощения работы всех систем и возникли CAN Шина, а так же Lin Шина. Последняя используется в- основном на отечественных автомобилях.
Конечно, электрифицированные элементы приобрели цифровой голос, а не аналоговый, как раньше, и стало возможным соединять эти устройства как бы гирляндой (Lin шина). Каждый элемент в эту сеть телеграфировал о своем статусе и принимал команды.
Благодаря этому, стало возможно разместить в автомобиле компьютер, который бы собирал, анализировал данные и с него же происходило бы всё управление. Ну и конечно же автопроизводители сэкономили на количестве кабелей.
Не будем вдаваться в сложные технические детали как работает этот автомобильный интернет.
Поговорим об авто сигнализации.
Если в автомобиле есть Can или Lin Шина, мы можем подключиться к интернету автомобиля и считать, например, такие данные
— какая из дверей открыта
— включены ли фары
— заведен ли двигатель
— повернут ли ключ зажигания
— какое напряжение в аккумуляторе
— подняты ли стекла
— сработал ли датчик удара или крена
И многое другое. В- общем мы можем считать показатели всех устройств и отдать им команду. Например, чтобы замигали фары, включилась сирена, перестал работать двигатель.
То есть наличие такой шины в автомобиле дает нам в первую очередь разнообразные комфортные сервисы и простое дистанционное управление автомобилем. Мы можем посмотреть, закрыты ли двери, получить от автомобиля информацию о том, что кто –то толкает автомобиль, заблокировать работу какого либо агрегата.
В дополнении к этому, мы можем скрыто установить авто сигнализацию, почти в любую точку гирлянды, так что у угонщика уйдет очень много времени на поиск и обезвреживание заветной коробочки, а это самое важное. Ведь угоны должны осуществляться быстро.
Что же делать если в автомобиле нет такой шины? Придется ставить дополнительные датчики, тянуть больше кабелей. Охранная система уже будет сложнее и состоять из бОльшего количества устройств и, как правило, и, скорее всего, не будет иметь самого продвинутого функционала.
Большое количество современных автомобилей оборудовано подобными шинами. Однако каждый производитель часто привносит в систему что-то своё.
Представьте себе. Мы подключились к этому автомобильному интернету. Что дальше?
Теперь у нас есть уши и голос, однако мы находимся на площади европейского города. Да ещё и иностранцы говорят на разных языках, и злыдни, никак не хотят нас учить своему языку, делая из этого строжайший секрет (например, Форд Мерседесу не друг, а конкурент). Вот и приходится по – одному «брать языка», и для каждой марки и каждой модели выпытывать свой язык общения.
У каждого производителя охранных систем есть свой набор марок и моделей, для которых найден общий язык.
Этот список постоянно расширяется и дополняется.
Резюмируя выше сказанное- наличие в Вашем автомобиле такой шины существенно облегчает установку авто сигнализации и как следствие удешевляет стоимость системы и установки.
Подобрать авто сигнализацию исходя из марки и модели Вашего автомобиля.
Смотреть автосигнализации с CAN
Смотреть автосигнализации с LIN
Смотреть автосигнализации с CAN+LIN
Удачи Вам на дорогах и пусть Ваш автомобиль будет под надежной защитой.
Получить бесплатную консультацию
E-mail СообщениеПоделитесь, если статья была полезна
Твитнуть
Поделиться
Поделиться
Отправить
Еще статьи
Сигнализации и защита от угона автомобилей InfinitiСигнализации и защита от угона автомобилей Porsche
Сигнализации и защита от угона автомобилей Mercedes.
Сигнализации и защита от угона автомобилей Citroen.
Сигнализации и защита от угона автомобилей Peugeot.
Car Hacking 101: Практическое руководство по использованию CAN-шины с помощью симулятора комбинации приборов — Часть I: Настройка | by Yogesh Ojha
Автомобильная безопасность действительно интересна и является интересной темой для изучения многими исследователями в области безопасности.

Сегодня, когда вы ведете машину, вы управляете чрезвычайно мощным компьютером, у которого есть колеса и рулевое управление.
Сегодня, когда вы ведете машину, нет ничего, что не было бы опосредовано компьютером. А в основе всего этого лежит Controller Area Network или просто называемая CAN или иногда CAN Bus, центральная нервная система автомобиля, отвечающая за внутриавтомобильную связь. Это руководство станет руководством по максимально безопасному взлому автомобиля с помощью реверс-инжиниринга CAN-пакетов.
Чтобы попрактиковаться в эксплуатации CAN-шины, мы будем использовать пакет ICSim от Крейга Смита. ICSim включает в себя приборную панель со спидометром, индикаторами дверных замков, индикаторами поворотников и панелью управления. Панель управления позволяет пользователю взаимодействовать с смоделированной автомобильной сетью, применяя ускорение, тормоза, управляя дверными замками и сигналами поворота.
« Car Hacking 101: Практическое руководство по эксплуатации CAN-шины с помощью Instrument Cluster Simulator » — это серия статей, где
Часть 1 посвящена настройке виртуальной лаборатории
Часть 2 посвящена использованию шины CAN
Часть 3 посвящена SavvyCAN и выполнению этого на реальном автомобиле [TODO] вы начинаете работу с автомобильной безопасности. Входной барьер для взлома автомобилей намного выше по сравнению с любыми другими областями безопасности. Я надеюсь, что это руководство поможет вам преодолеть входной барьер.В то время как взлом автомобилей и автомобильная безопасность — это гораздо более широкая область, это руководство посвящено только сети контроллеров (CAN) и ограничено прослушиванием трафика CAN, его анализом, обратным проектированием и выполнением повторных атак на автомобили.
Хотя это правда, что мы будем выполнять эту атаку/учебник на симуляторе кластера приборов, его вполне можно перенести на реальный автомобиль с дополнительным оборудованием. Я расскажу о дополнительном оборудовании, необходимом в конце этой статьи.
Цель этой статьи — помочь вам легко приступить к работе в области автомобильной безопасности и/или взлома автомобилей, не тратя много денег на оборудование.
Это НЕ «Взлом от нуля до героя в машине, который сделает вас экспертом в X минут», статья , вместо этого эта статья призвана помочь вам начать взламывать машины в симуляторе.Эта статья поможет вам узнать
- о функционировании CAN
- Получение доступа к CAN через OBD-II
- Анализ трафика CAN
- Анализ и обратное проектирование трафика CAN
- Повторная атака
- Отказ в обслуживании в сети CAN [Часть 3 TODO]
- Игра с пакетами CAN с использованием Python [Часть 3 TODO]😉
Если вы решите попрактиковаться в этом руководстве, вам понадобятся:
Симулятор кластера приборов
- Любые дистрибутивы Linux (я буду использовать Ubuntu)
- can-utils
- ICSim (ICSim — симулятор инструментального кластера с открытым исходным кодом)
Можно загрузить с https ://github.com/zombieCraig/ICSim
Локальная сеть контроллеров, также известная как CAN, представляет собой центральную нервную систему, которая обеспечивает связь между всеми/некоторыми частями автомобиля. До того, как CAN был первоначально разработан BOSCH в 1985 в качестве системы внутриавтомобильной связи производители автомобилей использовали системы проводки «точка-точка». По мере того, как в автомобилях становилось все больше и больше электронных компонентов, они становились громоздкими и слишком дорогими в обслуживании. Затем эта проблема была устранена путем замены его на CAN.
Проще говоря, CAN позволяет различным электронным блокам в автомобилях взаимодействовать и обмениваться данными друг с другом. Основным мотивом предложения CAN было то, что он позволял обмениваться данными с несколькими ECU только с помощью одного провода. В современном автомобиле может быть до 70 ЭБУ. В автомобиле могут быть такие компоненты, как блок управления двигателем, подушки безопасности, трансмиссия, редуктор, антиблокировочная тормозная система или просто АБС, информационно-развлекательные системы, климат-контроль, окна, двери и т.
Компоненты современного автомобиляд. Для того, чтобы все эти блоки могли общаться с друг друга, проводка точка-точка была бы такой громоздкой. Представьте себе, что каждый компонент подключен к любому другому компоненту, это был бы настоящий беспорядок для диагностики для устранения неполадок. Но с CAN это можно заменить одним проводом, и связь между каждым устройством намного проще.
Шина CAN может рассматриваться как шумная, перегруженная и более медленная версия локальной сети Ethernet, за исключением того, что трафик передается по UDP, а не по TCP.
Стоит отметить, что не все системы управления автомобилем используют CAN, а также CAN — это не только протокол связи, используемый в автомобильной системе. Могут быть и другие протоколы, такие как Bluetooth, сотовые сети GSM/LTE, спутниковое радио, LIN и т. д. Вы должны знать, что CAN — не единственная поверхность атаки, их может быть много.
В автомобиле может быть несколько узлов, способных отправлять и/или получать сообщения.
Это сообщение состоит в основном из идентификатора, который является приоритетом сообщения, а также может содержать сообщение CAN, которое может состоять из восьми байтов или меньше за раз.
Если два или более узла начинают отправлять сообщения одновременно, сообщения, отправленные с доминирующим идентификатором, будут перезаписаны идентификатором менее доминирующего. Это называется арбитражем шины на основе приоритета. Сообщения с меньшим числовым значением ID имеют более высокий приоритет и всегда передаются первыми. Таким образом узел обнаруживает, что на шину помещаются сообщения с более высоким приоритетом.
Сообщение от тормозов имеет более высокий приоритет, чем сообщение от аудиоплеера.
Обратите внимание, что самый низкий идентификатор = наивысший приоритет.Если два или более узла начинают отправлять сообщения одновременно, сообщения, отправленные с доминирующим идентификатором, будут перезаписаны идентификатором менее доминирующего.
Шина CAN состоит из двух разных проводов. Поскольку это шина, к этим проводам можно подключить несколько устройств. Фрейм CAN состоит из 3 основных частей:
- Арбитражный идентификатор
- Код длины данных
- Поле данных
Давайте посмотрим на кадр данных CAN: многие другие шины, которые можно легко реализовать, но почему CAN? До того, как была изобретена шина CAN, производители автомобилей использовали системы двухточечной проводки, если у вас есть три компонента в автомобиле, все три компонента были соединены друг с другом с помощью системы двухточечной проводки.
Рассмотрим эти три компонента: система рулевого управления, редуктор и АБС. Теперь, что касается типичной системы двухточечной проводки, вам нужно, чтобы система рулевого управления была напрямую подключена к редуктору и к АБС, а также проводами. Кроме того, ваш редуктор должен быть подключен к АБС и системе рулевого управления кучей проводов. Это совершенно нормально для автомобилей с меньшим количеством компонентов.
Вы можете себе представить такое в современном автомобиле, который имеет целых 100 различных ЭБУ и других компонентов? Это будет грязно и громоздко! Также невозможно выявить неисправности в системе электропроводки (если они есть), диагностика была бы настоящим кошмаром, и очень дорого в обслуживании.
Именно тогда производители автомобилей придумали CAN.
Проблема двухточечной проводки может быть заменена двумя проводами, то есть CANH и CANL, CAN HIGH и CAN LOW соответственно . Теперь этот способ связи намного быстрее, проще и его очень легко диагностировать.
Это потому, что CAN используется практически в каждом автомобиле, это предписано законом, поэтому CAN никуда не денется в ближайшее время. Кроме того, шина CAN не была разработана с учетом современных требований безопасности.
Чтобы получить доступ к шине CAN в автомобиле, вам необходимо иметь доступ к бортовому диагностическому порту, также известному как OBD.
Хотя могут существовать сотни других диагностических стандартов и портов, в настоящее время практически все автомобили используют OBD-II. Это именно то, что ваши автомеханики используют для выявления неисправностей в вашем автомобиле. OBD — это самый прямой доступ к CAN. Найти OBD-II довольно просто. Он расположен где-то рядом с сиденьем пассажира или сиденьем водителя. И это должно быть доступно без использования отвертки.
Так выглядит OBD.
Если вас интересует распиновка OBD, вот распиновка порта OBD.
Если вы посмотрите внимательно, контакты 6 и 14 — это те же CANH и CANL, о которых я упоминал ранее.
Для того, чтобы вы могли взаимодействовать с шиной CAN, поскольку теперь вы уже знаете, что вам нужен порт OBD, вам нужно что-то вроде USB to CAN, потому что ваш компьютер не может напрямую общаться с CAN. Вам нужно что-то, что подключается к порту OBD-II через USB, чтобы вы могли отправлять/получать пакеты CAN. Также в программном обеспечении вам нужно что-то, что может читать и/или записывать пакеты CAN, а также кодировать и/или декодировать пакеты CAN.
Имея немного аппаратного и программного обеспечения, вы определенно сможете подключиться к CAN.
Оборудование
Оборудование, необходимое для подключения к OBD-II, можно легко найти на рынке. Есть как дорогие, так и недорогие аппаратные устройства. Устройства высокого класса включают Kvaser и EMS, которые дороги и излишни.
У вас есть USB2CAN, собственный интерфейс для Linux, который предлагает отличное соотношение цены и качества.
USB2CANКроме того, много раз вы будете сталкиваться с этими устройствами на базе ELM327, Bluetooth, они ужасны для взлома по той причине, что у них более низкая скорость передачи данных, и вы в конечном итоге потеряете так много пакетов.
Интерфейс OBD-II на базе ELM327Macchina M2
Macchina M2 — мой личный фаворит. Macchina M2 — это автомобильный интерфейс с открытым исходным кодом, который позволяет вам обмениваться данными с шиной CAN через OBD-II. Самое приятное в Macchina M2 то, что он модульный, то есть вы можете добавить модули WiFi, GSM, LTE, BLE поверх M2.
Macchina M2M2 имеет 2 канала CAN. У M2 также есть LIN 😉 Подробнее о Macchina M2 можно узнать здесь.
Я использовал USB2CAN и Macchina M2, они предлагают отличное соотношение цены и качества и выполняют свою работу.
CLX000
Еще одним недорогим вариантом является CLX000 от CSS Electronics, который позволяет регистрировать и передавать данные CAN, например, для цели взлома автомобиля. Данные можно визуализировать в бесплатном программном обеспечении Wireshark с открытым исходным кодом, а плагин обеспечивает полезную функциональность обратного проектирования.
CLX000 отлично подходит для визуализации и телематики.
Вы можете найти больше информации о CLX000 здесь, также есть несколько отличных статей о CAN.
Я бы порекомендовал просмотреть их блоги: https://www.csselectronics.com/screen/page/reverse-engineering-can-bus-messages-with-wireshark/language/enПрограммное обеспечение
Что касается программного обеспечения, у вас есть SocketCAN, can-utils, vcan, встроенные в ядро Linux.
Они служат для отправки и получения пакетов CAN, их кодирования и/или декодирования.
У вас также есть Wireshark, который может анализировать пакеты CAN.
Если вы хотите узнать больше об эксплуатации CAN, не беспокоясь о том, чтобы навредить своему автомобилю, ICSim — это то, что вам нужно!
Лучший и недорогой способ попрактиковаться во взломе автомобилей — запустить симулятор приборной панели. Спасибо Крейгу Смиту и его репозиторию с открытым исходным кодом под названием ICSim. Используя ICSim, довольно легко настроить и недорого научиться эксплуатировать CAN-шину.
Для моделирования кластера приборов требуются библиотеки SDL
Выполним настройку.SDL — это кроссплатформенная библиотека для разработки компьютерной графики и звука. Поскольку ISCim рисует и анимирует виртуальную панель инструментов, это необходимо. Это можно установить через apt-get.
sudo apt-get install libsdl2-dev libsdl2-image-dev -yУстановка утилит CAN
Чтобы мы могли отправлять, получать и анализировать пакеты CAN, нам нужны утилиты CAN.
can-utils — это специальный набор утилит для Linux, который позволяет Linux взаимодействовать с сетью CAN в автомобиле. Canutils состоит из 5 основных инструментов, которые мы используем очень часто:
- cansniffer для перехвата пакетов
- cansend для записи пакета
- candump дамп всех полученных пакетов player для воспроизведения пакетов CAN
- cangen для генерации случайных пакетов CAN
can-utils можно установить через apt-get
sudo apt-get install can-utils -yЗагрузить симулятор кластера инструментов
Симулятор кластера инструментов используется для создания имитации трафика CAN.
Его можно загрузить, клонировав проект через репозиторий git.
git clone https://github.com/zombieCraig/ICSimЕсли все пойдет хорошо, вы должны увидеть это
После того, как вы перейдете в каталог ICSim, вы увидите сценарий оболочки с именем setup_vcan.
Содержимое setup_vcan .shsh
Здесь команда modprobe используется для загрузки модулей ядра, таких как модули can и vcan. Последние две строки создадут интерфейс vcan0 для имитации автомобильной сети.
Вы можете запустить следующие команды для настройки интерфейса виртуального банка
./setup_vcan.shЧтобы проверить интерфейс vcan0, ifconfig vcan0 покажет
Теперь пришло время запустить симулятор. Для запуска симулятора ICSim требуется как минимум два компонента. Приборная панель и контроллер для имитации ускорения, тормозов, управления дверями, поворотников и т. д. Для их запуска вам потребуется не менее 3 терминальных окон/вкладок. Нам потребуется, чтобы эти терминалы запускали панель инструментов, контроллер и еще один для запуска can-utils.
Запуск информационной панели
Чтобы запустить информационную панель, вы можете запустить файл с именем icsim с аргументом vcan0, интерфейс, который мы создали ранее.
./icsim vcan0В этот момент приборная панель не будет работать, включая спидометр, поворотники, тормоза или двери. Это потому, что на интерфейсе vcn0 нет трафика. Для имитации трафика на интерфейсе vcan0, нам необходимо запустить контроллер.
Панель управления можно запустить с помощью
./controls vcan0vcan0 — это виртуальный CAN-интерфейс, через который наш ICSim будет отправлять и получать CAN-кадры. Как только вы запускаете панель управления, вы можете наблюдать, как спидометр делает некоторые колебания. Это происходит из-за шума, имитируемого панелью управления.
После запуска панели управления вы можете использовать клавиши клавиатуры для имитации трафика.Используя приведенные ниже комбинации клавиш, вы можете вносить изменения в ICSim Dashboard.
Как только я нажму клавишу со стрелкой вверх и клавишу со стрелкой влево, вы увидите вот что.
На этом все. Если вы следовали за всем, вы должны быть готовы идти.
Во второй части я расскажу о способах использования CAN-трафика.
Далее: Часть 2: Использование шины CAN
Ссылки:
Некоторые иллюстрации взяты из «CSS Electronics» https://www.csselectronics.comЕсли вы считаете, что приведенные здесь иллюстрации принадлежат вам, пожалуйста Не стесняйтесь, пишите мне, я добавлю кредиты к вашим иллюстрациям.
История технологии CAN
Самые первые документы, опубликованные Bosch, описывающие протокол CAN (Спецификация CAN 1.0), модель C Reference CAN и документ SAEВ феврале 1986 года компания Robert Bosch GmbH представила сеть контроллеров (CAN). система последовательной шины на конгрессе Общества автомобильных инженеров (SAE). Это был час рождения одного из самых успешных сетевых протоколов. Сегодня почти каждый новый легковой автомобиль, произведенный в Европе, оснащен хотя бы одной сетью CAN. Используемый также в других типах транспортных средств, от поездов до кораблей, а также в промышленных системах управления, CAN является одним из наиболее распространенных протоколов шины — возможно, даже ведущей системой последовательной шины в мире.
От идеи до первого чипа
В начале 1980-х годов инженеры Bosch оценивали существующие системы последовательных шин на предмет их возможного использования в легковых автомобилях. Поскольку ни один из доступных сетевых протоколов не мог удовлетворить требования автомобильных инженеров, Уве Кинке начал разработку новой системы последовательной шины в 1983 году.
Новый шинный протокол в основном должен был добавить новые функции — сокращение жгутов проводов было лишь побочным продуктом, а не движущей силой развития CAN. Инженеры Mercedes-Benz уже на ранней стадии участвовали в разработке спецификации новой системы последовательной шины, как и Intel как потенциальный основной поставщик полупроводников. Профессор доктор Вольфхард Лоренц из Университета прикладных наук в Брауншвейг-Вольфенбюттеле (сегодня: Остфальский университет прикладных наук), Германия, который был нанят в качестве консультанта, дал новому сетевому протоколу название «Сеть контроллеров». Профессор доктор Хорст Веттштейн из Университета Карлсруэ также оказал академическую помощь.
В феврале 1986 года родилась CAN: на конгрессе SAE в Детройте новая шинная система была представлена как «Автомобильная сеть последовательных контроллеров». Уве Кинке, Зигфрид Дайс и Мартин Литшел представили многоабонентский сетевой протокол. Он был основан на механизме неразрушающего арбитража, который без каких-либо задержек предоставляет шине доступ к кадру с наивысшим приоритетом. Не было центральной инстанции, контролирующей доступ к сети. Кроме того, отцы CAN — упомянутые выше лица, а также сотрудники Bosch Вольфганг Борст, Вольфганг Ботценхард, Отто Карл, Гельмут Шеллинг и Ян Унру — реализовали несколько механизмов обнаружения ошибок. Обработка ошибок также включала автоматическое отключение неисправных узлов шины, чтобы поддерживать связь между оставшимися узлами. Передаваемые кадры идентифицировались не по адресам узлов передатчика кадров или приемников кадров (как почти во всех других шинных системах), а скорее по их содержанию. Идентификатор, представляющий полезную нагрузку кадра, также имел функцию указания приоритета кадра в сегменте сети.
За этим последовало множество презентаций и публикаций, описывающих этот инновационный протокол связи, пока в середине 1987 года — на два месяца раньше запланированного срока — Intel не поставила первый чип контроллера CAN, 82526. Это была самая первая аппаратная реализация протокола CAN. Всего за четыре года идея стала реальностью. Вскоре после этого Philips Semiconductors представила 82C200. Эти два самых ранних предшественника контроллеров CAN сильно отличались в отношении фильтрации приема и обработки кадров. С одной стороны, концепция FullCAN, одобренная Intel, требовала меньшей нагрузки на ЦП (центральный процессор) от подключенного микроконтроллера, чем реализация BasicCAN, выбранная Philips. С другой стороны, устройство FullCAN было ограничено в отношении количества принимаемых кадров. Контроллеру BasicCAN также требовалось меньше кремния. В современных CAN-контроллерах реализовано сочетание концепций приемной фильтрации и обработки кадров. Это сделало вводящие в заблуждение термины BasicCAN и FullCAN устаревшими.
Стандартизация и соответствие
Спецификация Bosch CAN (версия 2.0) была представлена для международной стандартизации в начале 1990-х годов. После нескольких политических споров, особенно связанных с сетью транспортных средств (VAN), разработанной некоторыми крупными французскими производителями автомобилей, в ноябре 1993 года был опубликован стандарт ISO 11898. В дополнение к протоколу CAN он также стандартизировал физический уровень для бит- скорость до 1 Мбит/с. Параллельно в ISO 11519 был стандартизирован маломощный отказоустойчивый способ передачи данных по CAN.-2. Это так и не было реализовано из-за недостатков стандарта. В 1995 году стандарт ISO 11898 был дополнен дополнением, описывающим расширенный формат кадра с использованием 29-битного идентификатора CAN.
К сожалению, все опубликованные спецификации и стандарты CAN содержали ошибки или были неполными. Чтобы избежать несовместимых реализаций CAN, компания Bosch позаботилась о том, чтобы все микросхемы CAN соответствовали эталонной модели Bosch CAN.
Кроме того, Университет прикладных наук в Брауншвейге/Вольфенбюттеле, Германия, уже несколько лет проводит испытания на соответствие CAN под руководством профессора Лоуренца. Используемые шаблоны тестирования основаны на серии стандартов плана тестирования на соответствие ISO 16845. Сегодня несколько испытательных центров предлагают услуги по тестированию на соответствие CAN.
Пересмотренные спецификации CAN стандартизированы. ISO 11898-1 описывает «канальный уровень CAN», ISO 11898-2 стандартизирует «неотказоустойчивый» физический уровень CAN, а ISO 11898-3 определяет «отказоустойчивый физический уровень CAN». Серия ISO 11992 (интерфейс для грузовиков и прицепов) и серия ISO 11783 (сельскохозяйственная и лесохозяйственная техника) определяют профили приложений на основе сетевого подхода SAE J1939. Они несовместимы, потому что спецификации физического уровня отличаются.
Время пионеров CAN
Хотя CAN изначально разрабатывался для использования в легковых автомобилях, первые приложения пришли из разных сегментов рынка.
Особенно в Северной Европе CAN уже был очень популярен в первые дни своего существования. В Финляндии производитель лифтов Kone использовал шину CAN. Шведское инженерное бюро Kvaser предложило CAN в качестве протокола связи внутри машин некоторым производителям текстильных машин (Lindauer Dornier и Sulzer) и их поставщикам. В связи с этим под руководством Ларса-Берно Фредрикссона эти компании основали «Группу пользователей CAN Textile». К 1989, они разработали принципы коммуникации, которые помогли сформировать среду разработки «Королевство CAN» в начале 1990-х годов. Хотя CAN Kingdom не является прикладным уровнем по отношению к эталонной модели OSI, его можно рассматривать как предка протоколов более высокого уровня на основе CAN.
В Нидерландах компания Philips Medical Systems присоединилась к промышленным пользователям CAN, решив использовать CAN для внутренней сети своих рентгеновских аппаратов. «Спецификация сообщений Philips» (PMS), в основном разработанная Томом Сутерсом, представляла собой первый прикладной уровень для сетей CAN.
У профессора доктора Конрада Эчбергера из Университета прикладных наук в Вайнгартене, Германия, были почти идентичные идеи. В Центре передачи Штейнбайса для автоматизации процессов (СТЗП), которым он руководил, он разработал аналогичный протокол.
Несмотря на то, что начали появляться первые стандартизированные протоколы более высокого уровня, большинство пионеров CAN использовали монолитный подход. Коммуникационные функции, управление сетью и прикладной код были одним программным обеспечением. Несмотря на то, что некоторые пользователи предпочли бы более модульный подход, они все равно столкнулись бы с недостатком проприетарного решения. Необходимые усилия для улучшения и поддержки протокола более высокого уровня CAN были недооценены, что отчасти верно и сегодня.
В начале 1990-х пришло время создать группу пользователей для продвижения протокола CAN и его использования во многих приложениях. В январе 1992 года Хольгер Цельтвангер, в то время редактор журнала VMEbus (издатель: Franzis), объединил пользователей и производителей, чтобы создать нейтральную платформу для технического усовершенствования CAN, а также для маркетинга системы последовательной шины.
Два месяца спустя была официально создана международная группа пользователей и производителей «CAN в автоматизации» (CiA). В эти первые дни информационный бюллетень CAN уже был опубликован.Первая техническая публикация, выпущенная всего через несколько недель, касалась физического уровня: CiA рекомендовала использовать только приемопередатчики CAN, соответствующие стандарту ISO 11898. Сегодня приемопередатчики EIA-485, специфичные для производителя, которые довольно часто сети в то время и не всегда были совместимы, должны были полностью исчезнуть.
Одной из первых задач CiA была спецификация прикладного уровня CAN. Используя существующий материал от Philips Medical Systems и STZP, а также с помощью других членов CiA, был разработан «Прикладной уровень CAN» (CAL), также называемый «Зеленой книгой». При разработке спецификаций с использованием CAN одной из основных задач CiA была организация обмена информацией между экспертами CAN и теми, кто хотел получить больше знаний о CAN.
Поэтому с 1994 года проводится международная конференция CAN (iCC). Другой академический подход был реализован в LAV: Немецкая ассоциация сельскохозяйственных транспортных средств. С конца 1980-х годов была разработана шинная система на основе CAN для сельскохозяйственных транспортных средств (LBS). Но прежде чем работа могла быть успешно завершена, международный комитет принял решение в пользу американского решения J1939 (ISO 11783). Этот профиль приложения, который также основан на CAN, был определен комитетами SAE Truck and Bus Association. J1939 — это немодульный подход, который очень прост в использовании, но при этом достаточно негибок.
Также была разработана стандартизация CAN для грузовых автомобилей. Сеть между грузовиком и прицепом стандартизирована как ISO 11992. Этот протокол основан на J1939 и должен использоваться в Европе с 2006 года. . Оба были представлены для международной стандартизации. Однако производители автомобилей до сих пор использовали проприетарные программные решения.
От теории к практике
Конечно, производители полупроводников, внедрившие ядра CAN в свои микроконтроллеры, в основном ориентированы на автомобильную промышленность. С середины 1990-х годов компании Infineon Technologies (ранее Siemens Semiconductors) и Motorola (переданные на аутсорсинг как Freescale и позже приобретенные NXP) поставили большое количество контроллеров CAN европейским производителям легковых автомобилей и их поставщикам. В качестве следующей волны дальневосточные поставщики полупроводников также предлагали CAN-контроллеры с конца 19 века.90-е. NEC выпустила свой легендарный CAN-чип 72005 в 1994 году, но это было слишком рано — компонент не имел коммерческого успеха.
С 1991 года Mercedes-Benz использует CAN в своих легковых автомобилях высшего класса. В качестве первого шага электронные блоки управления, отвечающие за управление двигателем, были подключены через CAN. В 1995 году BMW использовала сеть CAN топологии «дерево / звезда» с пятью ЭБУ (электронными блоками управления) в своих автомобилях серии 7.
На втором этапе последовали блоки управления, необходимые для электроники кузова. Были реализованы две физически отдельные сети CAN, часто соединенные через шлюзы. Другие производители автомобилей последовали примеру своих коллег из Штутгарта и обычно внедряли в свои легковые автомобили две сети CAN. В настоящее время все они внедряют в свои автомобили несколько сетей CAN.
В начале 1990-х годов инженеры американской машиностроительной компании Cincinnati Milacron создали совместное предприятие с Allen-Bradley и Honeywell Microswitch для проекта управления и связи на основе CAN. Однако вскоре важные участники проекта сменили работу, и совместное предприятие распалось. Но Allen-Bradley и Honeywell продолжили работу по отдельности. Это привело к появлению двух протоколов более высокого уровня «Devicenet» и «Smart Distributed System» (SDS), которые очень похожи, по крайней мере, на нижних уровнях связи. В начале 19В 94 году компания Allen-Bradley передала спецификацию Devicenet «Открытой ассоциации производителей устройств для сетей устройств» (ODVA), что повысило популярность устройств Devicenet.
Honeywell не удалось поступить аналогичным образом с SDS, что делает SDS более похожим на внутреннее решение Honeywell Microswitch. Devicenet был разработан специально для автоматизации производства и поэтому представляет собой прямой противник таких протоколов, как Profibus-DP и Interbus. Предлагая готовые функции plug-and-play, Devicenet стала ведущей шинной системой в этом конкретном сегменте рынка в США.
В Европе несколько компаний пытались использовать клиентские лицензии. Хотя подход CAL был правильным с академической точки зрения и его можно было использовать в промышленных приложениях, каждому пользователю необходимо было разработать новый профиль, поскольку CAL представляла собой настоящий прикладной уровень. CAL можно рассматривать как необходимый академический шаг к независимому от приложений решению CAN, но оно так и не получило широкого признания в полевых условиях.
С 1993 года в рамках проекта Esprit Aspic европейский консорциум под руководством Bosch разрабатывал прототип того, что впоследствии станет CANopen.
Это был профиль на основе клиентских лицензий для внутренней сети производственных ячеек. С академической стороны профессор доктор Герхард Грулер из Университета прикладных наук в Ройтлингене (Германия) и доктор Мохаммед Фарси из Университета Ньюкасла (Великобритания) приняли участие в одном из самых успешных мероприятий Esprit за всю историю. После завершения проекта спецификация CANopen была передана CiA для дальнейшего развития и сопровождения. В 1995 был выпущен полностью переработанный коммуникационный профиль CANopen, который всего за пять лет стал самой важной стандартизированной встроенной сетью в Европе.
Первые сети CANopen использовались для внутренней связи машин, особенно для приводов. CANopen предлагает очень высокую гибкость и конфигурируемость. Протокол более высокого уровня, который использовался в нескольких очень разных областях применения (промышленная автоматизация, морская электроника, военные транспортные средства и т. д.), тем временем был стандартизирован на международном уровне как EN 50325-4 (2003).
CANopen используется особенно в Европе. Машины для литья под давлением в Италии, пилы и станки по дереву в Германии, сигаретные машины в Великобритании, краны во Франции, погрузочно-разгрузочные машины в Австрии и машины для изготовления часов в Швейцарии — вот лишь несколько примеров промышленной автоматизации и машиностроения. В Соединенных Штатах CANopen рекомендуется для вилочных погрузчиков и используется в машинах для сортировки писем.
CANopen определяет не только прикладной уровень и коммуникационный профиль, но также структуру для программируемых систем, а также различные профили устройств, интерфейсов и приложений. Это важная причина, по которой целые отрасли промышленности (например, печатные машины, морские приложения, медицинские системы) решили использовать CANopen в конце 1990-х годов.
С помощью Devicenet и CANopen доступны два стандартизированных (IEC 62026-3 или EN 50325-4/5) уровня приложений, предназначенных для различных рынков промышленной автоматизации.
Devicenet оптимизирован для автоматизации производства, а CANopen особенно хорошо подходит для встроенных сетей во всех видах управления машинами. Это сделало проприетарные уровни приложений устаревшими; необходимость определения уровней приложений для конкретных приложений стала историей (за исключением, возможно, некоторых специализированных встраиваемых систем большого объема).
Связь по времени
В начале 2000 года рабочая группа ISO, включающая несколько компаний, определила протокол для передачи кадров CAN по времени. Доктор Бернд Мюллер, Томас Фюрер и другие сотрудники Bosch вместе с экспертами полупроводниковой промышленности и академических исследований определили протокол «Связь по CAN, запускаемая по времени» (TTCAN).
Это расширение CAN сделало возможной равноудаленную во времени передачу кадров и реализацию управления с обратной связью через CAN, а также использование CAN в приложениях x-by-wire. Поскольку протокол CAN не был изменен, можно передавать кадры, запускаемые по времени, а также по событиям, через одну и ту же систему физических шин.
Однако автомобильная промышленность не приняла TTCAN. Кроме того, промышленные пользователи редко используют расширение протокола с запуском по времени. Вместо этого они использовали функции синхронной передачи, указанные в CANopen, так сказать, метод мягкого запуска по времени.
Одобрено властями
В конце 90-х годов было изобретено несколько собственных протоколов безопасности на основе CAN. У Survived есть Safetybus p от Pilz, Германия. В 1999 году CiA приступила к разработке протокола CANopen-Safety, который был одобрен немецким TÜV. После серьезных политических дебатов в органах по стандартизации это расширение CANopen (CiA 304) было стандартизировано на международном уровне в EN 50325-5 (2009).
Devicenet использует расширение протокола безопасности CIP. Germanischer Lloyd, одно из ведущих мировых классификационных обществ, одобрило структуру CANopen для морских приложений (CiA 307). Помимо прочего, эта структура определяет автоматическое переключение с сети CANopen по умолчанию на резервную шинную систему.
Эти функции в настоящее время обобщены и определены в серии CiA 302 дополнительных функций прикладного уровня CANopen.
Разработка CAN FD
В начале 2011 года General Motors и Bosch начали разработку некоторых усовершенствований протокола CAN, касающихся более высокой пропускной способности. Автомобильная промышленность особенно пострадала от загрузки все большего количества пакетов программного обеспечения в электронные блоки управления (ЭБУ). Эта трудоемкая задача должна была быть сокращена за счет более производительной системы связи. Идея увеличить скорость передачи CAN за счет введения второго битрейта не нова. Несколько ученых опубликовали подходы с начала 2000 года. Но ни один из них не был достаточно зрелым, чтобы убедить автопроизводителей. В сотрудничестве с другими экспертами по CAN компания Bosch заранее разработала спецификацию CAN FD, официально представленную в 2012 г.0339-я международная конференция CAN в замке Хамбах, Германия.
В ходе процесса стандартизации в рамках ISO было обнаружено несколько академических недостатков в предлагаемых механизмах обнаружения ошибок.
Это потребовало пересмотра протокола CAN FD и введения дополнительных мер безопасности (например, счетчика заполняющих битов). По этой причине существует протокол CAN FD, отличный от ISO, который несовместим с протоколом ISO CAN FD, стандартизованным в ISO 11898-1.
Доктор Марк Шрайнер из Daimler дал много советов и хитростей при разработке сетей CAN FD. Многие из его идей включены в серию CiA 601 узлов CAN FD и рекомендаций и спецификаций по проектированию системы.
Светлое будущее CAN
Срок службы технологии CAN был продлен с введением протокола CAN FD. Автомобильная промышленность уже начала внедрять протокол CAN FD для автомобильных сетей следующего поколения. Можно ожидать, что все будущие приложения будут использовать протокол CAN FD. Неважно, требуют ли они более высокой пропускной способности или нет. Вы по-прежнему можете использовать CAN FD с одной настройкой битовой синхронизации. Длина полезной нагрузки в любом случае настраивается от 0 байт до 64 байт.
Для тех, кому нужна большая пропускная способность и гибридные топологии, CiA разработала так называемую спецификацию приемопередатчика SIC (схема улучшения сигнала) (CiA 601-4). Первоначальная идея пришла от Denso, японского поставщика Tier-1.
CiA также разработала протокол CANopen FD, основанный на нижних уровнях CAN FD. В частности, для промышленных приложений управления движением очень приветствуются более высокие скорости передачи и более длинные полезные нагрузки (до 64 байт). CiA также участвует в разработке прикладного уровня на основе CAN FD для коммерческих автомобилей с использованием существующих групп параметров, как указано в SAE J19.39 серия.
Третье поколение CAN
В конце 2018 года CiA начала разработку CAN XL, третьего поколения протоколов канального уровня на основе CAN. Он был инициирован по заказу Volkswagen. Карстен Шанце и Александр Мюллер предложили многие из первых идей. Максимальная полезная нагрузка (поле данных) CAN XL составляет 2048 байт.