Can controller area network шина это

CAN шина в автомобиле: что это такое

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

Что такое CAN шина

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

Аббревиатура CAN расшифровывается как Controller Area Network, то есть сеть контроллеров. Соответственно, CAN-шина – это устройство, принимающее информацию от устройств и передающее между ними. Данный стандарт был разработан и внедрён более 30 лет назад компанией Robert Bosch GmbH. Сейчас его используются в автомобилестроении, промышленной автоматизации и сфере проектирования объектов, обозначаемых «умными», например, домов.

Как работает CAN шина

Фактически, шина представляет собой компактное устройство со множеством входов для подключения кабелей или разъём, к которому подсоединяются кабели. Принцип её действия заключается в передаче сообщений между разными компонентами электронной системы.

Для передачи разной информации в сообщения включаются идентификаторы. Они уникальны и сообщают, например, что в конкретный момент времени автомобиль едет со скоростью 60 км/ч. Серия сообщения отправляется на все устройства, но благодаря индивидуальным идентификаторам они обрабатывают только те, которые предназначаются именно для них. Идентификаторы CAN-шины могут иметь длину от 11 до 29 бит.

В зависимости от назначения КАН шины разделяются на несколько категорий:

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

Для чего CAN шина в автомобиле

Распространение интерфейса КАН в автомобильной сфере связано с тем, что он выполняет ряд важных функций:

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

В современном автомобиле цифровая шина обеспечивает работу следующих компонентов и систем:

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

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

Читайте также: Что такое центральный замок в автомобиле.

Плюсы и минусы CAN шины

Специалисты по автомобильной электронике, высказываясь в пользу использования CAN-интерфейса, отмечают следующие преимущества:

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

Но есть у CAN-шины и функциональные недостатки:

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

Возможные проблемы с CAN шиной

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

индикация вопросительного знака на приборной панели;
одновременное свечение нескольких лампочек, например, CHECK ENGINE и ABS;
исчезновение показателей уровня топлива, оборотов двигателя, скорости на приборной панели.

Такие проблемы возникают по разным причинам, связанным с питанием или нарушением электроцепи. Это может быть замыкание на массу или аккумулятор, обрыв цепи, повреждение перемычек, падение напряжения из-за проблем с генератором или разряд АКБ.

Первая мера для проверки шины – компьютерная диагностика всех систем. Если она показывает шину, необходимо измерить напряжение на выводах H и L (должно быть

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

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

Читайте также: Что такое адаптивный круиз контроль и для чего он нужен.

Использование сети CAN и стека CANopen

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

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

CAN (Controller Area Network) — это стандарт, созданный компанией Bosсh для сетей, используемых в автоматизации и промышленности. Стандарт нашел широкое применение в промышленном производстве, технологиях «умного дома», а так же в автомобилестроении. Очень хорошо подходит для связывания различных датчиков и управляющих устройств в единую сеть.
Как правило, CAN-сеть это сеть типа «шина», в которой все узлы могут передавать и принимать данные.
Она обладает небольшой скоростью, но высокой надежностью.

Далее я хочу поверхностно описать стандарт и рассказать об использовании такой сети на практике.

Стандарт

Стандарт описывает канальный уровень и базовые требования к физическому уровню.
Главное в физическом уровне — это требование возможности передачи бита как «доминантного» и «рецессивного«. Доминантный сигнал считается единицей, а рецессивный — нулем. Основное требование — при передаче доминантного и рецессивного сигнала одновременно, всем узлам должен прийти доминантный сигнал. На этом принципе основан механизм арбитража. Из этого следует, что для передачи могут использоваться разные среды, однако на практике чаще всего используют дифференциальную пару.

Передача в сети происходит кадрами. В стандарте существуют два типа кадров: базовый и расширенный.
Базовый кадр содержит 11 битовый идентификатор, а расширенный — 29 битовый. Кадр так же содержит бит запроса на передачу, информацию о длине передаваемых данных и сами данные. Они могут занимать от 0 до 8 байт в кадре. Так же кадр содержит некоторую служебную информацию, но для программиста она не принципиальна, поскольку её добавление реализовано аппаратно в контроллере сети.
Изначально идентификаторы не привязаны к какому либо узлу и характеризуют именно сообщение, а не отправителя и получателя. Идентификаторы так же показывают приоритетность сообщения. Приоритет определяется доминантными битами в идентификаторе. Так 10000000000 приоритетнее чем 01000000000.

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

Помимо этого используются механизмы обнаружения ошибок, такие как контроль передачи, дополняющие биты, использование контрольной суммы и проверка значений полей. Разработчики оценивают вероятность невыявления ошибки передачи как 4,7×10-11.

Данный стандарт не описывает протоколы верхнего уровня, поэтому было создано несколько реализаций, как коммерческих, так и открытых.
Наиболее известные из них:
— CANopen
— DeviceNet
— CAN Kingdom

Эту и даже более подробную информацию о стандарте легко найти в интернете, поэтому я наконец приступаю к описанию CANopen.

CANopen

Как я уже писал, однажды мне потребовалось создать надежную сеть из микроконтроллеров. После рассмотрения возможных вариантов было решено остановиться на сети CAN. В качестве протокола верхнего уровня был выбран CANopen и его реализация — CANopenNode, поскольку она является открытой и простой в портировании на нужное мне устройство. CANopenNode лицензирован под LGPL.

Основные моменты протокола CANopen:
— протокол работает со стандартными идентификаторами. Сеть может содержать до 127 узлов.
— каждому узлу выдается уникальный номер в сети.
— протокол не требует обязательного наличия мастера сети (однако существуют возможности, которые доступны только одному узлу в сети, который условно можно назвать мастером)
— OD (Object Dictionary ) — словарь объектов. Содержит отсортированный список переменных, доступ к которым можно получить по сети с помощью SDO.
— SDO (Service Data Objects) — механизм доступа к словарю объектов. Для доступа к объектам узла сети на этом узле должен быть запущен так называемый SDO-сервер. В сети может быть только один SDO-клиент, условно называемый мастером, который может получать данные от любого из серверов.
— PDO (Process Data Objects) — объекты для быстрого взаимодействия между узлами. Могут содержать до 8 байт данных и передаются в одном кадре. Для каждого PDO выделяется свой идентификатор (в определенном диапозоне). PDO условно делятся на входящие (RPDO) и исходящие (TPDO). Изначально предполагается, что каждый узел будет иметь по 4 RPDO и 4 TPDO, однако их можно перераспределить между узлами вплоть до того, что один узел будет иметь возможность принимать и передавать до 512 PDO. Однако в этом случае на другие узлы идентификаторов не хватит.
PDO могут посылаться по таймеру, по наступлению определенного события либо по прямому запросу на посылку из управляющей программы.
— NMT (Network Management) — менеджер сети. Сообщения этого типа могут переводить узлы в разные состояния (инициализация, рабочее, предрабочее, остановленное), а так же с их помощью обеспечивается контроль работы сети — механизм heartbeat.
— Heartbeat — переводится как сердцебиение. Суть механизма заключается в том, что каждый узел передает в сеть определенное сообщение, уникальное для каждого узла (ID получается путем прибавления номера узла в сети к определенному числу). Любой узел, который хочет узнать, по прежнему ли ему доступны узлы с определенными id должен просто принимать и обрабатывать эти сообщения. Сообщения от неинтересных для него узлов могут игнорироваться.
— Emergency message — в протоколе предусмотрена посылка сообщений об аварийных ситуациях.
— EDS (Electronic Data Sheets) — специальные текстовые файлы, позволяющие настроить словарь объектов. Существуют программы, помогающие в генерации таких файлов.

CANopenNode

CANopenNode — открытая реализация протокола CANopen, написанная на чистом С для использования в микроконтроллерах.

Теперь я опишу особенности, с которыми мне пришлось столкнуться при работе с CANopenNode.
1. Я использовал 32-битный контроллер, а CANopenNode изначально написан для 8/16 битных. Из-за этого в одном месте таймер сходил с ума, поскольку вместо того, чтобы переполниться и, как следствие, обнулиться, он продолжал расти и в механизме хартбита выдавалась ошибка о том, что поголовно все узлы превысили время ожидания нового хартбита.
2. Моя задача предполагала, что я могу передавать большие объемы данных. При этом несколько контроллеров могли передавать эти данные, а остальные — получать. Пришлось отказаться от механизма SDO (поскольку в нем только один контроллер имел бы возможность посылать данные с размером больше чем 8 байт) и написать свою собтвенную надстройку, которая использовала первые два байта PDO в виде управляющей информации.
3. Решение из пункта два привело к тому, что мне потребовалось однозначно определять участников взаимодействия, что возможно сделать только с помощью идентификаторов.
Это был, пожалуй, самый тонкий момент в работе. Было решено ограничить количество «мастеров» четырьмя штуками. Эти четыре узла получали 127 PDO на вход и на выход. А остальные узлы работали с 4 входящими и исходящими PDO. При чем, идентификаторы PDO были распределены так, что узлы-«ведомые» имели по одному исходящему сообщению, каждое из которых читал только определенный «мастер» и по одному входящему сообщению от каждого «мастера». Мастера же соответственно имели по одному каналу для обращения лично к любому из «ведомых» и точно знали, кто из них обращается к нему.
Эта концепция была сложнее всего, так как даже на форумах, где люди работают с CAN, бытует мнение, будто CANopen нельзя настроить подобным образом.
4. Настройка идентификаторов в данном протоколе происходит в коде. Более того, от неё зависят id узлов, которые будет читать и принимать конкретный узел. Поэтому смена id на ходу представляется сложной для данного протокола и требует дополнительных усилий.

В виде заключения

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

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

Ссылки на некоторые ресурсы, связанные с CAN

www.can-cia.org — (англ.) международная организация CAN in Automation.
sourceforge.net/projects/canopennode — (англ.) проект CANopenNode

UPD:
Забыл добавить еще один интересный момент, который некоторое время вводил меня в заблуждение. Я отлаживал свою сеть на двух контроллерах, которые я соединил напрямую.
1. Когда я перепрошивал один из контроллеров, сеть на втором начинала выдавать ошибки (начинали часто-часто мигать лампочки — поведение, определенное в стеке CANopen). При обычной перезагрузке контроллера такого не происходило. Возможно, это специфика конкретного контроллера, но на всякий случай это стоит иметь в виду.
2. Протокол CANopen спроектирован таким образом, что если сообщение с определенным id не было отправлено до того момента, как оно должно быть отправлено еще раз, то это тоже вызывает ошибку. При том, каждый узел сети каждую секунду посылает хартбит-сообщение. Поэтому даже если вы ничего не отправляете, то всё равно можете получить ошибку сети.

Источник