3168

3.5. Протокол CAN

Разработанный в середине 1980-х фирмой «Bosch» для систем управления узлами автомобиля, протокол CAN (Controller Area Network – сеть контроллеров) является последовательным протоколом высокоскоростной и высоконадежной передачи данных в широковещательном (broadcast) режиме в мультимастерной среде. Удачное сочетание низкой стоимости подключения, простоты и надежности с доступностью элементной базы и инструментальных средств разработки – одни из основных достоинств CAN-технологии. Положения стандарта, закрепленные в используемой на сегодня спецификации 2.0А/В фирмы «Bosch» и международном стандарте ISO 11898, соответствуют двум начальным уровням (физическому и канальному) 7-уровневой модели взаимодействия открытых систем ISO/OSI. Ряд оригинальных технических решений, реализованных при разработке протокола, наилучшим образом позволили сориентировать его на решение задач контроля и управления.

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

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

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

Физическая среда передачи данных в CAN может быть самой разной – витая пара, плоский ка-

бель, оптоволокно, а также радио- и ИК-каналы и даже линии электропередач. Основным ограничением протяженности шины является лишь предельно допустимая суммарная задержка распространения сигнала для заданной скорости передачи (в кабеле, трансиверах, входных цепях контроллеров и т. д.). В соответствии с рекомендациями ISO 11898 при использовании стандартных трансиверов и быстродействующих оптопар (для гальванической развязки) максимальная протяженность сети при скорости передачи 1 Мбит/с ограничена девятью метрами. Предельная рекомендуемая протяженность сети в соответствии с тем же стандартом достигается при снижении скорости передачи до 50 кбит/с. А в документах

60

промышленной CAN-группы CiA (CAN in Automation) приведены следующие полученные практическим путем соотношения «скорость – протяженность» для проводной сети без гальванической развязки: 1 Мбит/с – 30 м; 500 кбит/с – 100 м; 125 кбит/с – 500 м; 20 кбит/с

-2500 м; 10 кбит/с – 5000 м.

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

1)Data Frame – фрейм данных;

2)Remote Frame – фрейм запроса данных;

3)Error Frame – фрейм ошибки;

4)Overload Frame – фрейм перегрузки.

Собственно для передачи данных используется Data Frame, в поле данных которого (Data Field) могут находиться от 0 до 8 байтов данных.

Поле арбитража (Arbitration Field) фрейма включает в себя идентификатор (ID), однозначно определяющий содержание и приоритет сообщения. Стандартным форматом сообщений (CAN Specification 2.0A) предусмотрен 11-битный идентификатор, позволяющий различать до 20348 типов сообщений (на практике обычно до 2032), а расширенный (CAN Specification 2.0B) – 29-битный (стандартный 11-битный с 18-битным расширением) с теоретически возможным числом типов сообщений более 536 млн. Фреймы, соответствующие стандартному и расширенному форматам сообщений, приведены на рис. 3.28.

Рис. 3.28. Формат сообщения CAN-протокола

Бит RTR (Remote Transmission Request – запрос передачи данных) для фрейма должен иметь доминантный уровень. В расширенном формате фрейма бит SRR (Substitute Remote Request) с рецессивным уровнем заменяет следующий (в стандартном формате) за 11разрядным идентификатором бит RTR. Бит распознавания формата фрейма IDE (ID Extension) имеет доминантный уровень для стандартного формата фрейма и рецессивный – для расширенного. Биты r0 и r1 – резервные.

В поле управления (Control Field) содержится 4-разрядный код, задающий длину поля данных (0-8 байт) – DLC – Data Length Code. Поле контрольной суммы CRC Field включает

всебя контрольную сумму сообщения (15 бит) и бит-разделитель. В поле подтверждения АСК (Acknowledgement) передающий узел всегда выставляет рецессивный уровень. В случае, если передача прошла успешно, приемный узел сигнализирует об этом установкой

вэтом поле доминантного уровня.

Начинается фрейм доминантным битом SOF (Start of Frame), служащим также для синхронизации битового потока, а заканчивается семью битами рецессивного уровня поля EOF (End of Frame) и 3-битным того же уровня промежутком между фреймами. Для исключения потери синхронизации при передаче длинной последовательности одинаковых битов в пределах полей начала фрейма, арбитража, управления, данных и контрольной суммы используется битстаффинг – вставка дополнительного бита противоположного значения после подряд идущих пяти одинаковых. При приеме производится обратная (дебитстаффинг) операция.

Для запроса данных от удаленного узла служит фрейм запроса данных Remote Frame, также имеющий стандартный и расширенный форматы. Отличия фрейма запроса данных от

61

фрейма данных – в отсутствии поля данных и рецессивном уровне бита RTR. При получении фрейма запроса данных запрашиваемый узел отвечает передачей фрейма данных.

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

Шесть доминантных бит флага ошибки (активный флаг ошибки) перекрывают остаток ошибочно переданного фрейма и создают глобальную ошибку в сети – ошибку битстаффинга, которая воспринимается остальными узлами, если им не удалось обнаружить первоначальную (локальную) ошибку. Далее они выставляют свои флаги ошибки. Ввиду этого обстоятельства последовательность доминантных бит (суперпозиция флагов ошибки) может иметь длину от 6 до 12 бит. Ненадежным или частично поврежденным узлам (см. ниже) при обнаружении ошибки разрешено посылать лишь пассивный флаг ошибки – последовательность шести рецессивных бит.

Для задержки передачи данных или посылки фрейма запроса данных (при неготовности приемника или наличии доминантных бит в промежутке между фреймами) служит фрейм перегрузки Overload Frame. В отличие от фрейма ошибки он не влияет на счетчик ошибок и не вызывает повторную передачу сообщения.

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

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

Подобный режим доступа к шине известен как CSMA/CD+AMP (Carrier Sense Multiple Access with Collision Detection and Arbitration on Message Priority) – множественный доступ с контролем несущей, обнаружением коллизий и арбитражем на основе приоритета сообщений. Этот режим не позволяет «поспорившим» узлам устраивать столкновение на шине, а сразу выявляет победителя. CAN-протокол, изначально разработанный специально для систем управления жизненно важными узлами автомобилей, критичными к уровню безопасности и степени достоверности передаваемых данных, обладает эффективными средствами обнаружения ошибок.

В отличие от других сетевых протоколов, в CAN не используются подтверждающие сообщения, а при обнаружении одной или более ошибок хотя бы одним узлом (в CAN все узлы принимают все сообщения и участвуют в проверке сообщения на наличие ошибок – вычисляют контрольную сумму и т.п.) текущая передача прерывается (при условии, что ошибку обнаружил как минимум один узел со статусом Error Active) генерацией фрейма ошибки с флагом ошибки. Передатчик, сообщение которого было прервано, повторяет передачу.

CAL – CAN-протокол прикладного уровня для индустриальных приложений

В 92/93 годах САN-протокол получил за рубежом большой интерес как дешевый и высокоэффективный протокол связи для промышленных применений. Для того, чтобы синхронизировать и стандартизировать различные мнения и подходы, предлагаемые в САN-системах, в 1992 году была организована ассоциация СiА (CAN in Automation) /23/. Одной из первых выполненных СiА работ была разработка открытой концепции, основанной на CAN-сетевой технологии, и определенной как протокол прикладного уровня

– CAL /24/.

62

Один us основополагающих высокоуровневых CAN-протоколов CAN Application Layer (CAL) предлагает открытую CAN сеть, где в распределенном приложении взаимодействуют модули от различных поставщиков. Для этой цели сервисные элементы CAN Application Layer моделируют свою функциональность через объекты. Приложения могут обращаться к таким идентификационным объектам через имена (name). Эти имена доступны по всей сети. Приложения, которые по сети хотят выполнять дистанционное обслуживание такого объекта, должны знать его имя и это имя должно идентифицировать данный объект.

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

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

Вначале 90-х годов этот вопрос был исследован при выполнении программы Prometheus. Одним из результатов этих исследований является идея VLSA (Virtual Level Systems Architecture) и одно из введенных понятий – канал связи (communication link).

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

CAL-спецификацию, которая была опубликована CiA в 1993 году, можно рассматривать как подмножество VLSA-модели.

Спецификация CAL предлагает независимую от приложений объектноориентированную среду для реализации распределенных систем, основанных на CANсетях. Протокол предлагает объекты и услуги связи, распределения идентификаторов, управления сетью и уровнями. Основные области приложения CAL – распределенные CAN-системы, которые не требуют конфигурируемости и стандартного поведения устройств. Таким образом, CAL спецификация определяет только общие процедуры связи, которые требуются в распределенных системах /24/.

Вотличие от протоколов CANopen и DeviceNet, которые также определяют непосредственную структуру и части приложения через фиксированные методы доступа для представления и обмена данными (переменными), CAL не определяет содержимое данных или специфические объекты связи, которые должно обеспечивать некоторое устройство или которые ожидаются системой. Используя CAL, пользователь имеет возможность адаптировать систему связи точно к требованиям его приложения или системы. Следовательно, CAL протокол идеально подходит для реализации специфических системных решений подобно медицинским или измерительным системам, а также для реализации закрытых систем управления с децентрализованными интеллектуальными модулями.

63

в распределенных управляющих системах реального времени

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

транспортный уровень (Transport Layer) также отсутствует;

в системах управления реального времени не используются связи, ориентированные на сессию. Поэтому уровень сессии (Session Layer) также отсутствует;

CAL жестко определяет форматы данных для приложений через правила кодирования

(«Encoding Rules»). Поэтому представительный уровень (Presentation Layer) отсутству-

ет.

3.6.Стандарт LIN

имикроконтроллеры для его реализации

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

10 Современные модели автомобилей LADA (Granta, Kalina-2, Priora) также оснащены цифровой информационной шиной CAN (Granta, Kalina-2). В Приоре еще в 2009 г. было несколько информационных шин: Lin

– связь блока электропакета и модуля двери водителя, K-line – диагностическая шина всех электронных блоков, W-line – диагностическая шина ЭБУ, связывающая его с блоком электропакета (по сути это та же K-line, только вазовцы почему-то ее назвали W). По W идет обмен о состоянии иммобилайзера (подается запрос в него от ЭБУ и идет ответ обратно о разрешении или запрещении запуска двигателя). В России разработаны и выпускаются с 2007 г. ПКК «Миландр» микроконтроллеры 1886ВЕ5 с интерфейсами CAN и LIN.

64

гарантированное время ожидания для передаваемого сигнала;

дешёвое однопроводное исполнение и скорость до 20 Кбит/с.

Возможен перевод шины в режим микропотребления "Sleep", когда она выключается с целью уменьшения потребляемого тока, но любой узел на шине при необходимости может включить её вновь. Основное отличие протокола LIN от шины CAN заключается в низкой стоимости за счёт пониженной эффективности. Структура шины представляет собой нечто среднее между I2C и RS232. Шина подтягивается вверх к источнику питания через резистор в каждом узле и коммутируется вниз через открытый коллекторный переход приёмопере-

датчика, как в I2C. Но вместо стробирующей линии, каждый передаваемый байт обрамляется стартовым и стоповым битами и передаётся асинхронно, как в RS-232.

На рис. 3.30 /26/ показана типовая конфигурация шины LIN. Для обмена данными используется один сигнальный провод, подтянутый в каждом узле к источнику питания через резистор. В качестве выходного каскада используется транзистор с открытым коллектором. Активным состоянием является низкий уровень на шине данных, в это состояние её может перевести любой узел. В пассивном состоянии напряжение на шине близко к Vbat (9-18 В) – рис. 3.31. Это означает, что все узлы находятся в неактивном состоянии. Диапазон изме-

нений напряжения питания – в пределах 9…18 В, но все узлы должны выдерживать пе-

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

Рис. 3.30

Шина подтягивается к напряжению питания (Vbat) в каждом узле. Для устройствазадатчика (master) значение терминального резистора составляет 1 кОм, для устройствисполнителей (slave) – 20…47 кОм. Максимальная длина шины составляет 40 м.

Рис. 3.31

Формат информационной посылки приведен на рис. 3.32.

66

Аппаратная реализация

Для удобства проектирования встроенных систем управления для автомобильной электроники, Microchip Technology Inc. представила семейство из двух микроконтроллеров PIC16C432 и PIC16C433 с аппаратно-встроенным приёмопередатчиком автомобильного протокола обмена данных LIN. Эти микроконтроллеры содержат на кристалле аппаратный приёмопередатчик, и его не придётся создавать на отдельных элементах.

При классической архитектуре, PIC16C432/433 имеет 2Кх14бит слов однократно программируемой программной памяти и 128 байт оперативной памяти данных. Имея на одном кристалле микроконтроллер и приёмопередатчик LIN в корпусе с 18 и 20 выводами, можно до предела сократить количество внешних навесных деталей, повысив при этом надёжность устройства в целом. А наличие 4-канальных 8-бит АЦП позволяет обрабатывать аналоговые сигналы.

Другими встроенными модулями являются 8-разрядный счётчик/таймер реального времени с 8-разрядным предварительным делителем, выход из "спящего" режима по изменению сигнала на шине и встроенный приёмопередатчик LIN, для работы которого необходимо лишь наличие напряжения питания на шине 12 В. Специальные возможности микроконтроллеров поддерживают внутрисхемное программирование (ICSPTM), power-on reset (POR), power-up timer (PWRT), oscillator start-up timer (OST), режим пониженного энергопо-

требления "Sleep", возможность выбора типа задающего генератора и сторожевой таймер (WDT) с отдельным RC-генератором для повышения надёжности. PIC16C432 также имеет функцию brown-out reset (BOR).

Средства разработки и отладки

Компания Microchip предлагает полный программно-аппаратный комплект для разработки систем на базе микроконтроллеров и протокола LIN, призванный уменьшить время, необходимое для разработки, повысить интенсивность труда и таким образом снизить затраты на разработку в целом и сократить время выхода готового изделия на рынок. Всё программное обеспечение создаётся при помощи бесплатной среды MPLAB, доступной на сайте компании. Предлагается стартовый комплект, содержащий демонстрационную плату с узлами-исполнителями, и устройство-задатчик, которое может обмениваться данными с исполнителями и выдавать принимаемую информацию через последовательный порт RS232 на персональный компьютер. В комплект также входит всё необходимое программное обеспечение, в том числе исходные тексты программ для устройств Master/Slave на ассемблере.

Драйвер повышенной надежности для LIN интерфейса от компании Texas Instruments

Компания Texas Instruments разработала микросхему TPIC1021 для сопряжения логических контроллеров протокола LIN версии 2.0 с физической средой интерфейса.

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

Физическая среда LIN интерфейса представляет собой однопроводную линию для двунаправленного обмена данными. Она имеет два логических уровня: доминантный, с потенциалом, близким к общему проводу, и рецессивный (подавляемый), с потенциалом, близким к напряжению бортовой сети. Рецессивный уровень, формируемый через подтягивающий резистор одним из узлов сети, может быть принудительно инвертирован любым другим узлом в доминантный уровень, формируемый через открытый сток ключевого транзистора на «землю».

Микросхема TPIC1021 представляет собой драйвер повышенной надежности, преобразующий логические уровни ТТЛ 5 В или 3,3 В в логические уровни LIN интерфейса, и об-

68

ратно. TPIC1021 имеет встроенный последовательный диод и подтягивающий резистор, сопротивлением 30 кОм, требуемые по спецификации для сопряжения с шиной LIN.

Микросхема имеет высокую помехозащищенность, удовлетворяющую стандарту ISO7637 для автомобильных применений, она работоспособна при напряжении на контакте LIN до ± 40В и электростатических разрядах, при тестировании по методике IEC, амплитудой до 17 кВ. Рабочая температура окружающей среды драйвера от -40 до +125 С. Микросхема имеет встроенный термодатчик для защиты от перегрева и датчик тока для защиты от коротких замыканий на источник питания или «землю».

TPIC1021 обеспечивает ограничение скоростей нарастания и спада напряжения в шине LIN, согласно протоколу, для снижения электромагнитного излучения. Снижению потребления энергии способствуют низкий собственный ток потребления 1,2 мА, в активном режиме, и снижение тока потребления до 50 мкА, в пассивном режиме, с автоматическим переходом в активный режим при изменении состояния на шине LIN или по команде контроллера.

Микросхема предназначена для работы в широком диапазоне напряжений питания от 7 до 27 В. Поддерживаемая скорость передачи информации интерфейса – до 20 кбит/сек. Микросхема TPIC1021 выпускается в корпусе SO-8.

3.7. Однопроводной интерфейс 1-Wire

Этот интерфейс, разработанный в конце 90-х годов фирмой Dallas Semiconductor (рис. 3.35), регламентирован разработчиками для применения в четырех основных сферахприложениях /27/:

приборы в специальных корпусах MicroCAN для решения проблем идентификации, переноса или преобразования информации (технология iButton),

программирование встроенной памяти интегральных компонентов,

идентификация элементов оборудования и защита доступа к ресурсам электронной аппаратуры,

системы автоматизации (технология 1-Wire-

сетей).

Рис. 3.35

Первое из этих направлений широко известно на мировом рынке и уже давно пользуется заслуженной популярностью. Второе с успехом обеспечивает возможность легкой перестройки функций полупроводниковых компонентов, производимых фирмой Dallas Semiconductor и имеющих малое количество внешних выводов. Третье позволяет обеспечить недорогую, но достаточно эффективную идентификацию и надежную защиту самого разнообразного оборудования. Что касается четвертого применения, то реализация локальных распределенных систем на базе 1-Wire-шины является на сегодня де-факто наиболее оптимальным решением для большинства практических задач автоматизации. В настоящее время Dallas Semiconductor поставляет широкую номенклатуру однопроводных компонентов различных функциональных назначений для реализации самых разнообразных сетевых приложений. Поэтому имеется огромное число конкретных примеров использования 1- Wire-интерфейса для целей автоматизации в самых различных областях, и все больше разработчиков проявляют интерес к этой технологии.

Так в чем же особенность этого сетевого стандарта? Ведь в качестве среды для передачи информации по однопроводной линии чаще всего возможно использование обычного телефонного кабеля и, следовательно, скорость обмена в этом случае не велика. Однако если внимательно проанализировать большинство объектов, требующих автоматизации, то больше чем для 60% из них предельная скорость обслуживания в 16,3 Кбит/с будет более чем удовлетворительной. А другие преимущества 1-Wire-технологии, такие как:

простое и оригинальное решение адресуемости абонентов,

несложный протокол,

69