Академический Документы
Профессиональный Документы
Культура Документы
РЕФЕРАТ на тему
«Интерфейс CAN»
Улан-Удэ 2019
CAN (Controller Area Network – сеть контроллеров) – стандарт промышленной сети, ориентированный,
прежде всего, на объединение в единую сеть различных исполнительных устройств и датчиков. Режим передачи
– последовательный, широковещательный, пакетный.
Основные особенности
приоритетность сообщений;
гарантированное время отклика;
гибкость конфигурации;
групповой прием с синхронизацией времени;
система непротиворечивости данных;
multimaster;
обнаружение ошибок и их сигнализация;
автоматическая ретрансляция испорченных сообщений, как только шина снова станет свободной;
различие между нерегулярными ошибками и постоянными отказами узлов и автономное
выключения дефектных узлов.
Впервые идея CAN была предложена в середине 80-х немецкой компанией Robert Bosch, которая
задумывала ее в качестве экономичного средства для объединения контроллеров, расположенных внутри
автомобиля. Традиционный способ связи распределенных по объекту контроллеров жгутами проводов по своей
технической сложности, по ценовым и по весовым параметрам для столь массового изделия, коим является
автомобиль, оказался непригоден. Требовалось альтернативное решение, сокращающее количество проводов,
поэтому был предложен протокол CAN, для которого достаточно любой проводной пары.
Непосредственно стандарт CAN компании Bosch определяет передачу в отрыве от физического уровня –
он может быть каким угодно, например, радиоканалом или оптоволокном. Но на практике под CAN-сетью
обычно подразумевается сеть топологии «шина» с физическим уровнем в виде дифференциальной пары,
определённым в стандарте ISO 11898. Передача ведётся кадрами, которые принимаются всеми узлами сети. Для
доступа к шине выпускаются специализированные микросхемы – драйверы CAN-шины.
Идея заключалась в том, чтобы создать сетевое решение для распределённых систем, работающих в
реальном времени. Первоначально CAN применялся в автомобилях, но затем область его применения
расширилась и на проблемы автоматизации технологических процессов.
CAN обеспечивает высокий уровень защиты данных от повреждения даже при работе в сложных
условиях (сильные помехи), при этом достигается достаточно большая скорость передачи данных (до 1 Mbit/s).
Важным достоинством CAN является также то, что разработчик системы может влиять на приоритет сообщений
с тем чтобы самые важные из них не ожидали в очереди на отправку.
Для достижения прозрачности проекта и гибкости реализации, CAN был подразделен на различные
уровни согласно модели, ISO/OSI:
уровень передачи данных (Data Link Layer);
подуровень логического управления линией (LLC - Logical Link Control);
подуровень управления доступом к среде передачи (MAC Media Access Control);
физический Уровень (Physical Layer).
Область LLC подуровня:
обеспечение сервиса для передачи данных и для удалённого запроса данных;
решение, какие сообщения, полученные LLC подуровнем, должны быть фактически приняты;
обеспечение средствами для управления восстановлением и уведомления о перегрузке.
Область MAC подуровня главным образом – протокол передачи, то есть: арбитраж, проверка на ошибки,
сигнализация и типизация ошибок. Внутри MAC подуровня решается, является ли шина свободной для начала
новой передачи или возможен только приём данных.
В MAC подуровень также включены некоторые элементы битовой синхронизации. Всё это находится
внутри MAC подуровня и не имеет никакой возможности к модификации.
Область физического уровня – фактическая передача битов между различными узлами с соблюдением
всех электрических правил.
Высокая степень и надежности сети благодаря развитым механизмам обнаружения и исправления
ошибок, самоизоляции неисправных узлов, нечувствительность к высокому уровню электромагнитных помех
обеспечивает сети широчайшую сферу применения.
Среди многочисленных факторов, обеспечивших взлет популярности CAN в последние годы, следует
отметить разнообразие элементной базы CAN и ее дешевизну.
Промышленная сеть реального времени CAN представляет собой сеть с общей средой передачи данных.
Это означает, что все узлы сети одновременно принимают сигналы, передаваемые по шине. Невозможно послать
сообщение какому-либо конкретному узлу. Все узлы сети принимают весь трафик, передаваемый по шине.
Однако, CAN-контроллеры предоставляют аппаратную возможность фильтрации CAN-сообщений.
Каждый узел состоит из двух составляющих. Это собственно CAN контроллер, который обеспечивает
взаимодействие с сетью и реализует протокол, и микропроцессор (CPU).
Обработка ошибок встроена в протокол CAN и очень важна для производительности системы CAN.
Обработка ошибок нацелена на обнаружение ошибок в сообщениях, передающихся по шине CAN, чтобы
передатчик мог повторно выслать неверно принятое сообщение. Каждый CAN–контроллер на шине будет
пытаться обнаружить ошибку в сообщении. Если ошибка найдётся, обнаруживший её узел будет передавать флаг
ошибки, таким образом разрушая трафик шины. Другие узлы обнаружат ошибку, вызванную флагом ошибки
(если еще не обнаружили оригинальную ошибку) и предпримут соответствующие действия, т.е. отбракуют
текущее сообщение.
Каждый узел обслуживается двумя счетчиками ошибок: счетчиком ошибок передачи (Transmit Error
Counter) и счетчиком ошибок приёма (Receive Error Counter). Существуют правила, регламентирующие
повышение и/или понижение значения этих счетчиков. По существу, передатчик определяет повышение числа
сбоев в счетчике ошибок передачи быстрее, нежели слушающие узлы увеличат значения своих счетчиков ошибок
передачи. Это потому, что есть немалая вероятность, что сбой именно в передатчике! Когда значение любого
счетчика ошибок превышает определенную величину, узел сначала становится Error Passive – это значит, что он
не будет активно разрушать трафик шины при обнаружении ошибки; а затем Bus Off – это значит, что узел
вообще не будет принимать участия в передаче данных по шине.
При помощи счетчиков ошибок узел CAN может не только обнаруживать сбои, но и ограничивать
ошибки.
Механизмы обнаружения ошибок
Протокол CAN описывает не менее пяти различных способов обнаружения ошибок. Два из них работают
на уровне бита, а остальные три – на уровне сообщения.
1. Мониторинг битов (Bit Monitoring);
2. Вставка битов (Bit Stuffing);
3. Проверка кадра (Frame Check);
4. Проверка распознавания (Acknowledgement Check);
5. Проверка циклической избыточности (Cyclic Redundancy Check).
Мониторинг бита
Каждый передатчик шины CAN осуществляет мониторинг (т.е. повторное прочтение) переданного уровня
сигнала. Если уровень прочитанного бита отличается от уровня переданного, подается сигнал ошибки бита (Bit
Error). (Роста бита ошибок в процессе разрешения конфликтов не происходит.) Вставка битов
После того как узел передаст пять непрерывно следующих друг за другом битов одного уровня, он
добавит к исходящему потоку битов шестой бит, противоположного уровня. Получатели будут удалять этот
дополнительный бит. Это делается для предупреждения появления излишнего количества компонентов DC на
шине, но также дает получателям дополнительную возможность обнаружения ошибок: если по шине передается
более пяти непрерывно следующих друг за другом битов одного уровня, подается сигнал ошибки вставки.
Проверка кадра
Некоторые части сообщения CAN имеют фиксированный формат, т.е. стандарт четко определяет, какие
уровни должны произойти и когда. (Эти части – ограничитель CRC (CRC Delimiter), ограничитель ACK (ACK
Delimiter), конец кадра (End of Frame), а также пауза (Intermission), однако для них существуют дополнительные
специализированные правила проверки на ошибки.) Если контроллер CAN обнаружит неверное значение в одном
из этих полей, он подаст сигнал ошибки формы (Form Error).
Проверка распознавания
Ожидается, что все узлы шины, которые получили сообщение корректно (независимо от того, было ему
это сообщение «интересно» или нет), отправят доминантный уровень в так называемой области распознавания
(Acknowledgement Slot) кадра. Передатчик будет передавать рецессивный уровень. Если передатчик не сможет
обнаружить доминантный уровень в области распознавания, он подаст сигнал ошибки распознавания
(Acknowledgement Error).
Проверка циклической избыточности
Каждое сообщение содержит 15–битную контрольную сумму циклической избыточности (Cyclic
Redundancy Checksum, CRC), и любой узел, обнаруживший что CRC в сообщении отличается от посчитанного
им, подаст сигнал ошибки CRC (CRC Error).
Механизмы ограничения ошибок
Каждый контроллер CAN шины будет пытаться обнаружить описанные выше ошибки в каждом
сообщении. Если ошибка обнаружится, нашедший её узел передаст флаг ошибки, таким образом разрушая
передачу данных по шине. Другие узлы обнаружат ошибку, вызванную флагом ошибки (если они ещё не
обнаружили оригинальную ошибку) и предпримут соответствующее действие, т.е. сбросят текущее сообщение.
Каждый узел обслуживают два счетчика ошибок: счетчик ошибок передачи и счетчик ошибок приема.
Существуют правила, описывающие условия повышения и/или понижения значений этих счетчиков. По
существу, передатчик, обнаруживший сбой, повышает значение своего счетчика ошибок передачи быстрее, чем
слушающие узлы повысят значения своих счетчиков ошибок приема. Это потому, что есть большая вероятность,
что сбоит сам передатчик!
Узел начинает работу в режиме Error Active. Когда значение любого из двух счетчиков ошибок превысит
127, узел перейдет в состояние Error Passive, а когда значение счетчика ошибок передачи превысит 255, узел
перейдёт в состояние Bus Off.
• Узел в режиме Error Active при обнаружении ошибки будет передавать флаги активной ошибки (Active
Error Flags).
• Узел в режиме Error Passive при обнаружении ошибки будет передавать флаги пассивной ошибки
(Passive Error Flags).
• Узел в режиме Bus Off не будет передавать ничего.
Правила повышения и понижения значений счетчиков ошибок довольно сложные, но принцип прост:
ошибка передачи добавляет 8 пунктов, а ошибка прием – 1 пункт. Правильно переданные и/или принятые
сообщения вызывают понижение значения счетчика(ов).
Пример (слегка упрощенный): Представим, что у узла A плохой день. Всякий раз, когда A пытается
передать сообщение, происходит сбой (не важно, по какой причине). При каждом сбое значение счетчика ошибок
передач увеличивается на 8 пунктов и передается флаг активной ошибки. Затем он пытается послать сообщение
ещё раз и всё повторяется.
Когда значение счетчика ошибок передачи превысит 127 пунктов (т.е. после 16 попыток), узел A перейдёт
в режим Error Passive. Разница в том, что теперь он будет передавать флаги пассивной ошибки. Флаг пассивной
ошибки содержит 6 рецессивных битов и не будет нарушать передачу других данных по шине – поэтому другие
узлы не услышат жалобы A на ошибки шины. Однако A продолжит повышать значение счетчика ошибок
передачи. Когда он превысит 255 пунктов, узел A окончательно сдастся и перейдет в режим Bus Off.
Что другие узлы думают об узле A? – После каждого флага активной ошибки, переданного узлом A,
остальные узлы повышают значения своих счетчиков пассивной ошибки на 1 пункт. За всё то время, что
потребуется узлу A для перехода в режим Bus Off, значения счетчиков ошибок получения остальных узлов не
превысят границы Error Passive, т.е. 127. Это значение будет уменьшаться на 1 пункт при каждом корректном
получении сообщения. Однако узел А будет оставаться в режиме Bus Off.
Большинство контроллеров CAN будут предоставлять биты статуса (и соответствующие прерывания) для
двух состояний:
• «Предупреждение об ошибке» (Error Warning) – значение одного или обеих счетчиков ошибок
превысило 96 пунктов
• Bus Off, как описано выше.
Некотрые, но не все (!), контроллеры также предоставляют бит для состояния Error Passive. Немногие
контроллеры также предоставляют прямой доступ к счетчикам ошибок.
Генератор
Для реализации полного диапазона скоростей шины CAN, требуется кварцевый генератор. Микросхемы в
CAN сети с самым высоким требованием по точности генератора определяют точность генератора, которая
требуется от всех других узлов.
CAN контроллеры соответствующие данной CAN спецификации и контроллеры, соответствующие
предыдущим версиям 1.0 и 1.1, используемые в одной и той же сети, должны все иметь кварцевый генератор. Это
означает, что керамические резонаторы могут использоваться только в сети, все узлы которой соответствуют
CAN Спецификации 1.2.
В CAN не существует явной адресации сообщений и узлов. Протокол CAN нигде не указывает что поле
арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким
образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле
арбитража или в поле данных, или присутствовать и там, и там). Точно также протокол не запрещает
использовать поле арбитража для передачи данных. Утилизация поля арбитража и поля данных, и распределение
адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так
называемых протоколов высокого уровня (HLP - Higher Layer Protocols). Название HLP отражает тот факт, что
протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни
описываются протоколами HLP.