Администратор

Необходимость последовательного соединения в автомобилях

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

Многие автомобили уже имеют большое количество электронных систем управления. Рост автомобильной электроники является результатом отчасти стремления потребителя к большей безопасности и комфорту, а также отчасти требований правительства по улучшению контроля за выбросами и снижению расхода топлива. Управляющие устройства, отвечающие этим требованиям уже используются в течение некоторого времени в области управления двигателем, коробкой передач и дроссельной заслонкой, а также в антиблокировочных системах (ABS) и системе управления ускорением (ASC) .

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

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

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

Используя CAN, одноранговые (одноуровневые) станции (контроллеры, датчики и исполнительные механизмы) подключаются через последовательную шину. Сама шина является симметричной или асимметричной двухпроводной цепью, которая может быть экранированной или неэкранированной. Электрические параметры физической передачи также указаны в стандарте ISO 11898. Подходящие чипы драйвера шины доступны от большого ряда производителей

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

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

Использование CAN сети в автомобилях

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

Сетевые контроллеры для синхронизации двигателя, трансмиссии, шасси и тормозов. Скорости передачи данных находятся в диапазоне - типичном для систем реального времени от 200 кбит /с до 1 Мбит /с.
Сетевые компоненты общей электроники и электроники шасси, которые делают автомобиль более комфортным. Примерами таких мультиплексных применений являются управление освещением, кондиционирование воздуха и центральный замок, а также регулировка сиденья и зеркала. Особое значение здесь должно быть уделено стоимости компонентов и требованиям к проводке. Типичная скорость передачи данных составляет около 50 кбит / с.
В ближайшем будущем последовательная связь также будет использоваться в области мобильной связи, чтобы связать такие компоненты, как автомобильные радиоприемники, автомобильные телефоны, навигационные средства и т. д., с центральной более эргономичной панелью управления. Функции, определенные в проекте «Прометей», такие как связь между транспортным средством и транспортным средством, будут в большой степени зависеть от последовательной связи.
В настоящее время CAN используется для первых трех приложений, но для диагностики предпочтительным решением является интерфейс в соответствии со стандартом ISO 9141.

Промышленные применения сети CAN

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

Стандартное использование CAN в «S-классе» Mercedes-Benz и принятие CAN коммерческими автопроизводителями США для быстрой передачи (до 1 Мбит / с) заставляли промышленных пользователей навострить уши. Не только производители мобильных и стационарных сельскохозяйственных и морских машин и оборудования выбрали CAN, но и выбор производителей медицинской аппаратуры, текстильных машин, а также специальной техники и элементов управления лифтами. Система последовательной шины особенно хорошо подходит для сетевых «интеллектуальных» устройств ввода-вывода, а также датчиков и исполнительных механизмов внутри машины или завода.

Промышленность текстильного машиностроения является одним из пионеров CAN. Один производитель оснастил свои ткацкие станки модульными системами управления, сообщающимися в режиме реального времени через сети CAN еще в 1990 году. Тем временем несколько производителей текстильных машин объединились в группу «CAN Textile Users Group», которая, в свою очередь, является членом международной группы пользователей и производителей «CAN in Automation». Аналогичные требования к текстильному оборудованию имеются в упаковочных машинах и машинах для производства и обработки бумаги.

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

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

Как функционируют CAN-сети

Принципы обмена данными

Когда данные передаются по CAN, никакие станции не адресуются, но вместо этого содержание сообщения (например, скорость вращения или температура двигателя) обозначается идентификатором, который является уникальным во всей сети. Идентификатор определяет не только содержимое, но и приоритет сообщения. Это важно для распределения шины, когда несколько станций конкурируют за доступ к шине. Если ЦПУ данной станции желает отправить сообщение одной или нескольким станциям, он передает данные и их идентификаторы в назначенный CAN-чип (стостояние «Готово»). Это все, что должен сделать ЦП, чтобы инициировать обмен данными. Сообщение формируется и передается с помощью CAN-чипа. Как только CAN-чип получает выделение шины (состояние «Send Message»), все остальные станции в сети CAN становятся получателями этого сообщения (состояние «Receive Message»). Каждая станция в сети CAN, правильно приняв сообщение, выполняет приемный тест (тест получения), чтобы определить, относятся ли полученные данные к этой станции (состояние «Выбор»). Если данные имеют значение для соответствующей станции, они обрабатываются (состояние «Принято»), в противном случае они игнорируются. Высокая степень гибкости системы и конфигурации достигается благодаря схеме адресации, ориентированной на содержание. Очень просто добавлять станции в существующую сеть CAN без внесения каких-либо изменений в аппаратные или программные средства для существующих станций при условии, что новые станции являются чисто приемниками. Поскольку протокол передачи данных не требует физических адресов назначения для отдельных компонентов, он поддерживает концепцию модульной электроники, а также допускает множественный прием (широковещательный, многоадресный) и синхронизацию распределенных процессов: могут быть переданы измерения, необходимые в качестве информации несколькими контроллерами через сеть таким образом, что для каждого контроллера не требуется иметь свой собственный датчик.

1. Передача вещания и входная фильтрация узлами CAN на предмет того подходящие ли данные для того или иного узла

Неразрушающая побитовая проверка:

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

2. Принцип неразрушающего побитового проверки(оценки, считывания)

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

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

Эффективность распределения шины:

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

Распределение по фиксированному графику. Распределение производится последовательно каждому участнику для максимальной продолжительности независимо от того, нужена ли этому участнику шина в данный момент или нет (примеры: маркерная ячейка или передача маркера).
Распределение шины на основе необходимости. Шина назначается одному участнику на основании невыполненных запросов на передачу, то есть система распределения учитывает только участников, желающих передать (примеры: CSMA, CSMA / CD, управляющий полет, циклическая или побитовая проверка). Для CAN распределение шины согласовано исключительно между сообщениями, ожидающими передачи. Это означает, что процедура, определенная CAN, классифицируется как распределение на основе необходимости.

Еще одним средством оценки эффективности систем проверки(оценки) шины является метод доступа к шине:

Неразрушающий доступ к шине. С помощью методов этого типа шина назначается одной и только одной станции либо немедленно, либо в течение определенного времени после одного доступа к шине (одной или несколькими станциями). Это гарантирует, что каждый доступ к шине одной или несколькими станциями приводит к однозначному распределению шины (примеры: : маркерная ячейка, передача маркера, циклическая обработка, побитовая проверка.
Разрушающее распределение шины. Одновременный доступ к шине более чем одной станцией приводит к прерыванию всех попыток передачи и, следовательно, успешное распределение шины отсутствует. Для распределения шины может потребоваться более одного доступа к шине, количество попыток до успешного распределения шины является чисто статистической величиной (примеры: CSMA / CD, Ethernet). Чтобы обрабатывать все запросы на передачу сети CAN, соблюдая ограничения времени ожидания при как можно более низкой скорости передачи данных, CAN-протокол должен реализовывать метод распределения шины, который гарантирует, что всегда имеется однозначное распределение шины, даже если есть одновременныё доступ к шине с разных станций.

Метод поразрядной проверки с использованием идентификатора сообщений, которые должны передаваться, однозначно разрешает любое столкновение между несколькими станциями, которые хотят передавать, и он делает это самое позднее в течение 13 (стандартного формата) или 33 (расширенного формата) битовых периодов для любого периода доступа к шине. В отличие от проверки по сообщениям, используемого методом CSMA / CD, этот неразрушающий метод разрешения конфликтов гарантирует, что пропускная способность шины не используется без передачи полезной информации.

Даже в ситуациях, когда шина перегружена, связь приоритета доступа к шине с содержимым сообщения оказывается полезным атрибутом системы по сравнению с существующими протоколами CSMA / CD или токенными(маркерными) протоколами: несмотря на недостаточную пропускную способность шины, все невыполненные запросы на передачу обрабатываются в порядке их важности для всей системы (как определено приоритетом сообщения).

Имеющаяся пропускная способность эффективно используется для передачи полезных данных, так как «пробелы» в распределении шины остаются очень маленькими. Падение всей системы передачи из-за перегрузки, что может произойти с протоколом CSMA / CD, невозможен при CAN. Таким образом, CAN позволяет реализовать быстрый, трафик-определенный доступ к шине, который является неразрушающим из-за побитовой проверке на основе используемого приоритета сообщения.

Неразрушающий доступ к шине можно разделить на:

Централизованное управление доступом к шине и
Децентрализованное управление доступом к шине

В зависимости от того, присутствуют ли механизмы управления в системе только один раз (централизованный) или более одного раза (децентрализованный).

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

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

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

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

3. Кадр сообщения для стандартного формата (CAN Specification 2.0A)

Форматы сообщений.

Протокол CAN поддерживает два формата фреймов (кадров) сообщения, единственное существенное отличие заключается в длине идентификатора (ID). В стандартном формате длина идентификатора равна 11 битам, а в расширенном формате длина равна 29 битам. Кадр сообщения для передачи по шине содержит семь основных полей.

Сообщение в стандартном формате начинается с стартового бита «начало кадра», за ним следует «поле проверки», которое содержит идентификатор и бит «RTR» (запрос удаленной передачи), который указывает, является ли это кадр с данными или кадр запроса без каких-либо байтов данных (кадр удаленного запроса).

«Поле управления» содержит бит расширения IDE (идентификатор расширения), который указывает либо стандартный формат, либо расширенный формат, бит зарезервирован для будущих расширений и - в последних 4 битах - счет байтов данных в поле данных.

«Поле данных» находится в диапазоне от 0 до 8 байтов в длину и сопровождается полем «CRC», которое используется в качестве проверки безопасности кадра для обнаружения битовых ошибок.

Поле «ACK» содержит слот ACK (1 бит) и разделитель ACK (один рецессивный бит). Бит в слоте ACK отправляется как рецессивный бит и перезаписывается в качестве доминантного бита теми приемниками, которые на этот момент времени приема данных приняли их корректно(правильно) (положительное подтверждение). Правильные сообщения подтверждаются приемниками независимо от результата приемочной проверки. Конец сообщения обозначается «конец кадра». «Перерыв» - это минимальное количество периодов битов, разделяющих последовательные сообщения. Если какой-либо станции нет следующего доступа к шине, шина остается бездействующей («bus idle»).

Обнаружение и сигнализация об ошибках.

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

Циклическая проверка избыточности (CRC) CRC защищает информацию в кадре путем добавления избыточных проверочных битов на конце передачи. На конце приемника эти биты повторно вычисляются и проверяются на соответствие принятым битам. Если они не согласны, произошла ошибка CRC. Проверка кадра - этот механизм проверяет структуру передаваемого кадра, проверяя битовые поля на фиксированный формат и размер фрейма. Ошибки, обнаруженные при проверке кадров, обозначаются как «ошибки формата».
Ошибки ACK. Как уже упоминалось выше, полученные кадры подтверждаются всеми получателями посредством «положительного подтверждения». Если не получено подтверждение передатчиком сообщения (ошибка ACK), это может означать, что есть ошибка передачи, которая была обнаружена только получателями, что поле ACK было повреждено или что нет приемников.

Протокол CAN также реализует два механизма обнаружения ошибок на уровне битов.

Мониторинг. Способность передатчика обнаруживать ошибки основана на контроле сигналов шины: каждый узел, который передает, также наблюдает за уровнем шины и, таким образом, обнаруживает различия между отправленным битом и полученным битом. Это обеспечивает надежное обнаружение всех глобальных ошибок и ошибок, локальных для передатчика.
Набивка бит - кодирование отдельных битов проверяется на уровне битов. Битовое представление, используемое CAN, - это кодирование NRZ (non-return-to-zero), которое гарантирует максимальную эффективность в кодировании битов. Края синхронизации генерируются посредством заполнения битов, то есть после пяти последовательных равных битов отправитель вставляет в поток битов бит информации с дополнительным значением, которое удаляется приемниками. Проверка кода ограничивается проверкой соблюдения правила заполнения. Если одна или несколько ошибок обнаруживаются по меньшей мере одной станцией (любой станцией) с использованием указанных выше механизмов, текущая передача прерывается отправкой «флага ошибки». Это предотвращает прием другими станциями сообщений и, таким образом, обеспечивает согласованность данных на протяжении всей сети.

После прекращения передачи ошибочного сообщения отправитель автоматически повторяет попытку передачи (автоматический запрос повторения). Может снова возникнуть конкуренция за распределение шины. Как правило, повторная передача начинается в течение 23-битных периодов после обнаружения ошибки; В особых случаях время восстановления системы составляет 31 бит.

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

Надежность данных протокола CAN:

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

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

4. Вероятность остаточной ошибки как функция вероятности ошибки бита

Вычисление вероятности остаточной ошибки требует классификации ошибок и того, что весь путь передачи описывается моделью. Если мы определим вероятность остаточной ошибки CAN как функцию вероятности ошибки в битах для длин сообщений от 80 до 90 бит, для системных конфигураций, например, пяти или десяти узлов и с частотой ошибок 1/1000 (ошибка в одном сообщении из каждой тысячи), то максимальная вероятность ошибки в битах составляет приблизительно от 0,02 – до порядка 10^-13. Исходя из этого, можно рассчитать максимальное количество необнаруживаемых ошибок для данной сети CAN.

Например, если сеть CAN работает со скоростью передачи данных 1 Мбит/с, при среднем использовании пропускной способности шины 50%, при общем сроке службы 4000 часов и при средней длине сообщения 80 бит, то общее число Передаваемых сообщений составляет 9x10^10. Статистическое число необнаруженных ошибок передачи в течение срока эксплуатации, таким образом, составляет менее чем порядка 10^-2. Или, иначе говоря, с продолжительностью работы восемь часов в день на 365 дней в году и частотой ошибок каждые 0,7 с, одна необнаруженная ошибка происходит раз в тысячу лет (статистическое среднее значение).

Сообщения CAN расширенного формата

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

Чтобы поддержать эти усилия, протокол CAN был расширен за счет введения 29-битного идентификатора. Этот идентификатор состоит из существующего 11-битного идентификатора (базового ID) и 18-битного расширения (ID-расширения). Таким образом, протокол CAN позволяет использовать два формата сообщений: StandardCAN (Версия 2.0A) и ExtendedCAN (Версия 2.0B). Поскольку два формата должны сосуществовать на одной шине, устанавливается, какое сообщение имеет более высокий приоритет на шине в случае коллизий доступа к шине с форматами сглаживания и одним и тем же базовым идентификатором: стандартное сообщение всегда имеет приоритет над сообщением в расширенном формате.

CAN-контроллеры, которые поддерживают сообщения в расширенном формате, могут также отправлять и получать сообщения в стандартном формате. Только сообщения в стандартном формате могут передаваться по всей сети, если в этой сети используются CAN-контроллеры, которые поддерживают только стандартный формат (Версия 2.0A). Сообщения в расширенном формате будут неправильно поняты. Однако есть CAN-контроллеры, которые поддерживают только стандартный формат, но распознают сообщения в расширенном формате и игнорируют их (версия 2.0B пассивная).

Различие между стандартным форматом и расширенным форматом осуществляется с использованием бита IDE (бит расширения идентификатора), который передается как доминирующий в случае кадра в стандартном формате. Для кадров в расширенном формате это рецессивно. Бит RTR передается доминантно или рецессивно в зависимости от того, передаются ли данные или запрашивается конкретное сообщение от станции. Вместо бита RTR в стандартном формате бит SRR (замена удаленного запроса) передается для кадров с расширенным идентификатором. Бит SRR всегда передается как рецессивный, чтобы гарантировать, что в случае проверки стандартный кадр всегда имел приоритетное распределение шины к расширенному кадру, когда оба сообщения имеют одинаковый базовый идентификатор.

В отличие от стандартного формата, в расширенном формате за битом IDE следует 18-битный ID-номер, бит RTR и зарезервированный бит (r1).

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

5. Кадр сообщения для расширенного формата (CAN Specification 2.0A)

Реализации протокола CAN

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

CAN-контроллер с промежуточным буфером

Контроллеры CAN с промежуточным буфером (ранее называемые чипами basicCAN) реализовали в качестве аппаратного обеспечения логику, необходимую для создания и проверки потока битов согласно протоколу. Однако администрирование наборов данных, которые должны быть отправлены и получены, в частности, фильтрация приёма осуществляется только CAN-контроллером.

Как правило, CAN-контроллеры с промежуточным буфером имеют два приема и один буфер передачи. 8-разрядные регистры кода и маски допускают ограниченную фильтрацию принятия (8 MSB идентификатора). Подходящий выбор этих значений регистра позволяет считывать группы идентификаторов или, в пограничных случаях, выбирать все идентификаторы. Если для дифференцирования сообщений требуется более 8 ID-MSB, тогда микроконтроллер, следующий за CAN-контроллером в схеме, должен дополнять фильтрацию принятия программным обеспечением.

Контроллеры CAN с промежуточным буфером могут перенести большую нагрузку на микроконтроллер с фильтрацией приёма, но они требуют только небольшой площади кристалла и поэтому могут быть изготовлены с меньшими затратами. В принципе, они могут принимать все объекты в сети CAN.

CAN-контроллер с хранилищем объектов.

Объекты CAN состоят в основном из трех компонентов: идентификатора, кода длины данных и фактических полезных данных.

CAN-контроллеры с хранилищем объектов (ранее называемые fullCAN) функционируют как CAN-контроллеры с промежуточными буферами, но также управляют определенными объектами. Там, где есть несколько одновременных запросов, они определяют, например, какой объект должен быть передан первым. Они также выполняют фильтрацию принятия для входящих объектов. Интерфейс к следующему микроконтроллеру соответствует ОЗУ. Данные, подлежащие передаче, записываются в соответствующую область ОЗУ, полученные данные считываются из области ОЗУ, соответственно. Микроконтроллер должен управлять только несколькими битами (например, запросом передачи).

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

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

CAN подчиненные контроллеры для функций ввода / вывода.

Также как CAN-контроллеры, которые поддерживают все функции CAN-протокола, есть CAN-чипы, для которых не требуется следующий за ним микроконтроллер. Эти CAN-чипы называются SLIO (последовательное соединение ввода / вывода). CAN-чипы являются подчиненными и должны управляться CAN-мастером(центральный, основной микроконтроллер в сети).

Физическое соединение CAN

Скорости передачи данных (до 1 Мбит / с) требуют достаточно крутого наклона импульса, который может быть реализован только с использованием силовых элементов. В принципе возможно несколько физических соединений. Тем не менее, пользователи и производители группы «CAN in Automation» рекомендуют использовать схемы драйверов в соответствии с ISO 11898.

Встроенные микросхемы драйверов в соответствии с ISO 11898 доступны от нескольких компаний (Bosch, Philips, Siliconix и Texas Instruments). Международная группа пользователей и производителей (CiA) также определяет несколько механических соединений (кабель и разъемы).

6. Physical CAN Connection according to ISO 11898

С уважением, перевод предоставлен коллективом мастерской

Шина CAN – Введение

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

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

Протокол CAN

Протокол CAN описан в стандарте ISO 11898–1 и может быть кратко охарактеризован следующим образом:

Физический уровень использует дифференциальную передачу данных по витой паре;

Для управления доступом к шине используется неразрушающее bit–wise разрешение конфликтов;

Сообщения имеют малые размеры (по большей части 8 байт данных) и защищены контрольной суммой;

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

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

Протоколы более высоких уровней

Сам по себе протокол CAN определяет всего лишь, как малые пакеты данных можно безопасно переместить из точки A в точку B посредством коммуникационной среды. Он, как и следовало ожидать, ничего не говорит о том, как управлять потоком; передавать большое количество данных, нежели помещается в 8–байтное сообщение; ни об адресах узлов; установлении соединения и т.п. Эти пункты определяются протоколом более высокого уровня (Higher Layer Protocol, HLP). Термин HLP происходит из модели OSI и её семи уровней.

Протоколы более высокого уровня используются для:

Стандартизации процедуры запуска, включая выбор скорости передачи данных;

Распределения адресов среди взаимодействующих узлов или типов сообщений;

Определения разметки сообщений;
обеспечения порядка обработки ошибок на уровне системы.

Пользовательские группы и т.п.

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

Продукты CAN

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

Патенты в области CAN

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

Системы распределённого управления

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

Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.

Сообщения CAN

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

Адресация сообщений CAN

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

Типы сообщений

Существует 4 типа сообщений (или кадров), передающихся по шине CAN:

Кадр данных (Data Frame);

Удаленный кадр (Remote Frame);

Кадр ошибки (Error Frame);

Кадр перегрузки (Overload Frame).

Кадр данных

Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):

Поле арбитража (Arbitration Field), которое определяет очередность сообщения в том случае, когда за шину борятся два или более узла. Поле арбитража содержит:

В случае CAN 2.0A, 11–битный идентификатор и один бит, бит RTR который является определяющим для кадров данных.

В случае CAN 2.0B, 29–битный идентификатор (который также содержит два рецессивных бита: SRR и IDE) и бит RTR.

Поле данных (Data Field), которое содержит от 0 до 8 байт данных.

Поле CRC (CRC Field), содержащее 15–битную контрольную сумму, посчитанную для большинства частей сообщения. Эта контрольная сумма используется для обнаружения ошибок.

Слот распознавания (Acknowledgement Slot). Каждый контроллер CAN, способный корректно получить сообщение, посылает бит распознавания (Acknowledgement bit) в конце каждого сообщения. Приемопередатчик проверяет наличие бита распознавания и, если таковой не обнаруживается, высылает сообщение повторно.

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

Примечание 2: Идентификатор в поле арбитража, несмотря на свое название, необязательно идентифицирует содержимое сообщения.

Кадр данных CAN 2.0B («cтандартный CAN»).

Кадр данных CAN 2.0B («расширенный CAN»).

Удаленный кадр

Кратко: «Всем привет, кто–нибудь может произвести данные с маркировкой X?»
Удаленный кадр очень похож на кадр данных, но с двумя важными отличиями:

Он явно помечен как удаленный кадр (бит RTR в поле арбитража является рецессивным), и

Отсутствует поле данных.

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

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

Есть одна уловка, связанная с удаленным кадром: код длины данных (Data Length Code) должен быть установлен длине ожидаемого ответного сообщения. В противном случае разрешение конфликтов работать не будет.

Иногда требуется чтобы узел, отвечающий на удаленный кадр, начинал свою передачу как только распознавал идентификатор, таким образом «заполняя» пустой удаленный кадр. Это другой случай.

Кадр ошибки (Error Frame)

Кратко (все вместе, громко): «О, ДОРОГОЙ, ДАВАЙ ПОПРОБУЕМ ЕЩЁ РАЗОК»
Кадр ошибки (Error Frame) – это специальное сообщение, нарушающее правила формирования кадров сообщения CAN. Он посылается, когда узел обнаруживает сбой и помогает остальным узлам обнаружить сбой – и они тоже будут отправлять кадры ошибок. Передатчик автоматически попробует послать сообщение повторно. Наличествует продуманная схема счетчиков ошибок, гарантирующая, что узел не сможет нарушить передачу данных по шине путём повторяющейся отсылки кадров ошибки.

Кадр ошибки содержит флаг ошибки (Error Flag), который состоит из 6 бит одинакового значения (таким образом нарушая правило вставки битов) и разграничителя ошибки (Error Delimiter), состоящего из 8 рецессивных бит. Разраничитель ошибки предоставляет некоторое пространство, в котором другие узлы шины могут отправлять свои флаги ошибки после того, как сами обнаружат первый флаг ошибки.

Кадр перегрузки (Overload Frame)

Кратко: «Я очень занятой 82526 маленький, не могли бы вы подождать минуточку?»
Кадр перегрузки упоминается здесь лишь для полноты картины. По формату он очень похож на кадр ошибки и передается занятым узлом. Кадр перегрузки используется нечасто, т.к. современные контроллеры CAN достаточно производительны, чтобы его не использовать. Фактически, единственный контроллер, который будет генерировать кадры перегрузки – это ныне устаревший 82526.

Стандартный и расширенный CAN

Изначально стандарт CAN установил длину идентификатора в поле арбитража равной 11 битам. Позже, по требованию покупателей стандарт был расширен. Новый формат часто называют расширенным CAN (Extended CAN), он позволяет использовать не менее 29 бит в идентификаторе. Для различения двух типов кадров используется зарезервированный бит в поле управления Control Field.

Формально стандарты именуются следующим образом –

2.0A – только с 11–битными идентификаторами;
2.0B – расширенная версия с 29–битными или 11–битными идентификаторами (их можно смешивать). Узел 2.0B может быть

2.0B active (активным), т.е. способным передавать и получать расширенные кадры, или

2.0B passive (пассивным), т.е. он будет молча сбрасывать полученные расширенные кадры (но, смотрите ниже).

1.x – относится к оргинальной спецификации и её ревизиям.

В настоящее время новые контроллеры CAN обычно относятся к типу 2.0B. Контроллер типа 1.x или 2.0A прибудет в замешательство, получив сообщения с 29 битами арбитража. Контроллер 2.0B пассивного типа примет их, опознает, если они верны и, затем – сбросит; a контроллер 2.0B активного типа сможет и передавать, и получать такие сообщения.

Контроллеры 2.0B и 2.0A (равно, как и 1.x) совместимы. Можно использовать их все на одной шине до тех пор, пока контроллеры 2.0B будут воздерживаться от рассылки расширенных кадров.

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

Основной CAN (Basic CAN) и полный CAN (Full CAN)

Термины Basic CAN и Full CAN берут начало в «детстве» CAN. Когда–то существовал CAN–контроллер Intel 82526, предоставлявший программисту интерфейс в стиле DPRAM. Потом появился Philips с моделью 82C200, в котором применялась FIFO–ориентированная модель программирования и ограниченные возможности фильтрации. Для обозначения различия между двумя моделями программирования, люди стали называть способ Intel – Full CAN, а способ Philips – Basic CAN. Сегодня большинство контроллеров CAN поддерживают обе модели программирования, поэтому нет смысла в использовании терминов Full CAN и Basic CAN – фактически, эти термины могут вызвать неразбериху и стоит воздержаться от их употребления.

В действительности, контроллер Full CAN может взаимодействовать с контроллером Basic CAN и наоборот. Проблемы с совместимостью отсутствуют.

Разрешение конфликтов на шине и приоритет сообщения

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

Любой контроллер CAN может начать передачу, когда обнаружит, что шина простаивает. Это может привести к тому, что два или более контроллеров начнут передачу сообщения (почти) одновременно. Конфликт решается следующим образом. Передающие узлы осуществляют мониторинг шины в процессе отправки сообщения. Если узел обнаруживает доминантный уровень в то время, как сам он отправляет рецессивный уровень, он незамедлительно устранится от процесса разрешения конфликта и станет приемником. Разрешение конфликтов осуществляется по всему полю арбитража, и после того, как это поле отсылается, на шине остается только один передатчик. Данный узел продолжит передачу, если ничего не случится. Остальные потенциальные передатчики попытаются передать свои сообщения позже, когда шина освободится. В процессе разрешения конфликта время не теряется.

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

Поскольку, CAN–шина является шиной с подсоединением устройств по типу «монтажное И» (wired–AND) и доминантный бит (Dominant bit) является логическим 0, следовательно сообщение с самым низким в численном выражении полем арбитража выиграет в разрешении конфликта.

Вопрос: Что произойдет в случае, если единственный узел шины попытается отослать сообщение?

Ответ: Узел, разумеется, выиграет в разрешении конфликта и успешно проведет передачу сообщения. Но когда наступит время распознавания… ни один узел не отправит доминантный бит области распознавания, поэтому передатчик определит ошибку распознавания, пошлет флаг ошибки, повысит значение своего счетчика ошибок передачи на 8 и начнет повторную передачу. Этот цикл повторится 16 раз, затем передатчик перейдет в статус пассивной ошибки. В соответствии со специальным правилом в алгоритме ограничения ошибок, значение счетчика ошибок передачи не будет более повышаться, если узел имеет статус пассивной ошибки и ошибка является ошибкой распознавания. Поэтому узел будет осуществлять передачу вечно, до тех пор, пока кто–нибудь не распознает сообщение.

Адресация и идентификация сообщения

Повторимся, нет ничего страшного в том, что в сообщениях CAN нет точных адресов. Каждый контроллер CAN будет получать весь траффик шины, и при помощи комбинации аппаратных фильтров и ПО, определять – «интересует» его это сообщение, или нет.

Фактически, в протоколе CAN отсутствует понятие адреса сообщения. Вместо этого содержимое сообщения определяется идентификатором, который находится где–то в сообщении. Сообщения CAN можно назвать «контентно–адрессовнными».

Определённый адрес работает так: «Это сообщение для узла X». Контентно–адресованное сообщение можно описать так: «Это сообщение содержит данные с маркировкой X». Разница между этими двумя концепциями мала, но существенна.

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

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

Примечание о значениях идентификатора

Мы говорили, что идентификатору доступны 11 (CAN 2.0A) или 29 (CAN 2.0B) бит. Это не совсем верно. Для совместимости с определенным старым контроллером CAN (угадайте каким?), идентификаторы не должны иметь 7 старших бит установленных в логическую единицу, поэтому 11–битным идентификаторам доступны значения 0..2031, а пользователи 29–битных идентификаторов могут использовать 532676608 различных значений.

Заметьте, что все остальные контроллеры CAN принимают «неправильные» идентификаторы, поэтому в современных системах CAN идентификаторы 2032..2047 могут использоваться без ограничений.

Физические уровни CAN

Шина CAN

Шина CAN использует код без возвращения к нулю (NRZ) с вставкой битов. Существуют два разных состояния сигнала: доминантное (логический 0) и рецессивное (логическая 1). Они соответствуют определенным электрическим уровням, зависящим от используемого физического уровня (их несколько). Модули подключены к шине по схеме «монтажное И» (wired–AND): если хотя бы один узел переводит шину в доминантное состояние, то вся шина находится в этом состоянии, вне зависмости от того, сколько узлов передают рецессивное состояние.

Различные физические уровни

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

Существует несколько различных версий физических уровней: Наиболее распространенным является вариант, определенный стандартом CAN, часть ISO 11898–2, и представляющий собой двухпроводную сбалансированную сигнальную схему. Он также иногда называется high–speed CAN.

Другая часть того же стандарта ISO 11898–3 описывает другую двухпроводную сбалансированную сигнальную схему – для менее скоростной шины. Она устойчива к сбоям, поэтому передача сигналов может продолжаться даже в том случае, когда один из проводов будет перерезан, замкнут на «землю» или в состоянии Vbat. Иногда такая схема называется low–speed CAN.

SAE J2411 описывает однопроводной (плюс «земля», разумеется) физический уровень. Он используется в основном в автомобилях – например GM–LAN.

Существуют несколько проприетарных физических уровней.

В былые времена, когда драйверов CAN не существовало, использовались модификации RS485.

Различные физические уровни как правило не могут взаимодействовать между собой. Некоторые комбинации могут работать (или будет казаться, что они работают) в хороших условиях. Например, приемопередатчики high–speed и low–speed могут работать на одной шине лишь иногда.

Абсолютное большинство микросхем приемопередатчиков CAN произведено компанией Philips; в число других производителей входят Bosch, Infineon, Siliconix и Unitrode.

Наиболее распространен приемопередатчик 82C250, в котором реализован физический уровень, описываемый стандартом ISO 11898. Усовершенствованная версия – 82C251.

Распространенный приемопередатчик для «low–speed CAN» – Philips TJA1054.

Максимальная скорость передачи данных по шине

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

Low–speed CAN (ISO 11898–3, см. выше) работает на скоростях до 125 кбит/с.

Однопроводная шина CAN в стандартном режиме может передавать данные со скоростью порядка 50 кбит/с, а в специальном высокоскоростном режиме, например для программирования ЭБУ (ECU), около 100 кбит/с.

Минимальная скорость передачи данных по шине

Имейте в виду, что некоторые приемопередатчики не позволят вам выбрать скорость ниже определенного значения. Например, при использовании 82C250 или 82C251 вы можете без проблем установить скорость 10 кбит/с, но если вы используете TJA1050, то не сможете установить скорость ниже 50 кбит/с. Сверяйтесь со спецификацией.

Максимальная длина кабеля

При скорости передачи данных 1 Мбит/с, максимальная длина используемого кабеля может составлять порядка 40 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.

Другие максимальные длины кабеля (значения приблизительные):

100 метров при 500 кбит/с;

200 метров при 250 кбит/с;

500 метров при 125 кбит/с;
6 километров при 10 кбит/с.

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

Оконечное прерывание шины

Шина CAN стандарта ISO 11898 должна заканчиваться терминатором. Это достигается путем установки резистора сопротивлением 120 Ом на каждом конце шины. Терминирование служит двум целям:

1. Убрать отражения сигнала на конце шины.

2. Убедиться, что получает корректные уровни постоянного тока (DC).

Шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Я повторю: шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Для лабораторной работы может хватить и одного терминатора. Если ваша шина CAN работает даже при отсутствии терминаторов – вы просто счастливчик.

Заметьте, что другие физические уровни , такие как low–speed CAN, однопроводная шина CAN и другие, могут требовать, а могут и не требовать наличия оконечного терминатора шины. Но ваша высокоскоростная шина CAN стандарта ISO 11898 всегда будет требовать наличия хотя бы одного терминатора.

Кабель

Стандарт ISO 11898 предписывает, что волновое сопротивление кабеля номинально должно равнятся 120 Ом, однако допускается интервал значений сопротивления Ом.

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

ISO 11898 описывает витую пару, экранированную или неэкранированную. Идёт работа над стандартом однопроводного кабеля SAE J2411.

ENG 192Kb Control Area Network Rus CAN 2.0 A Rus CAN 2.0 В CAN протоколы высокого уровня Шины для бортовых автомобильных систем

CAN (Control Area Network) - последовательная магистраль, обеспечивающая увязку в сеть "интеллектуальных" устройств ввода/вывода, датчиков и исполнительных устройств некоторого механизма или даже предприятия. Характеризуется протоколом, обеспечивающим возможность нахождения на магистрали нескольких ведущих устройств, обеспечивающим передачу данных в реальном масштабе времени и коррекцию ошибок, высокой помехоустойчивостью. Система CAN обеспечена большим количеством микросхем, обеспечивающих работу подключенных к магистрали устройств, разработку которых начинала фирма BOSH для использования в автомобилях, и в настоящее время широко используемых в автоматизации промышленности. Цеколёвка разема приведена на рисунке.

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

Расстояние, м	25	50	100	250	500	1000	2500	5000
Скорость, Кбит/с	1000	800	500	250	125	50	20	10

• Максимальное число абонентов, подключенных к данному интерфейсу фактически определяется нагрузочной способностью примененных приемопередатчиков. Например, при использовании трансивера фирмы PHILIPS PCA82C250 она равна 110.
• Протокол CAN использует оригинальную систему адресации сообщений. Каждое сообщение снабжается идентификатором, который определяет назначение передаваемых данных, но не адрес приемника. Любой приемник может реагировать как на один идентификатор, так и на несколько. На один идентификатор могут реагировать несколько приемников.
• Протокол CAN обладает развитой системой обнаружения и сигнализации ошибок. Для этих целей используется поразрядный контроль, прямое заполнение битового потока, проверка пакета сообщения CRC-полиномом, контроль формы пакета сообщений, подтверждение правильного приема пакета данных. Хемминговый интервал d=6. Общая вероятность необнаруженной ошибки 4.7x10 -11 .
• Система арбитража протокола CAN исключает потерю информации и времени при "столкновениях" на шине.
• Интерфейс с применением протокола CAN легко адаптируется к физической среде передачи информации. Это может быть дифференциальный сигнал, оптоволокно, просто открытый коллектор и т.п. Несложно делается гальваническая развязка.
• Элементная база, поддерживающая CAN, широко выпускается в индустриальном исполнении.

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

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

Рис. 1. Топология сети CAN.

CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии - CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица - в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль - называется доминантным битом, а логическая единица - рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).

Типы сообщений сети CAN.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

• Data Frame
• Remote Frame
• Error Frame
• Overload Frame

Data Frame - это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:

• поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
  • для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
  • для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

  Следует отметить, что поле идентификатора, несмотря на свое название никак не идентифицирует само по себе ни узел в сети, ни содержимое поля данных. Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал).

• поле данных (data field) содержит от 0 до 8 байт данных
• поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
• слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Рис. 2. Data frame стандарта CAN 2.0A.

Remote Frame - это Data Frame без поля данных и с выставленным битом RTR (1 - рецессивные бит). Основное предназначение Remote кадра - это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame - это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

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

Контроль доступа к среде передачи (побитовый арбитраж).

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

Рис. 3. Побитовый арбитраж на шине CAN.

Методы обнаружения ошибок.

CAN протокол определяет пять способов обнаружения ошибок в сети:

• Bit monitoring
• Bit stuffing
• Frame check
• ACKnowledgement Check
• CRC Check

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

Bit stuffing - когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check - некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check - каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check - каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

Механизм ограничения ошибок (Error confinement).

Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.

Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

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

Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP - Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

Рис. 4. Логическая структура протокола CAN.

Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:

• DeviceNet
• CAL/CANopen
• CanKingdom

Физичекий уровень протокола CAN

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).

В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах - CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик - Phillips 82C250, который полностью соответствует стандарту ISO 11898.

Махимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/sec. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.

Валюта магазина рубли у.е.

Поиск

CAN шина. Часть 1.

1. Локальная сеть контроллеров (CAN)

Области применения.

Электронные распределители, Автомобили, Морские суда, Гидравлическое оборудование, Текстильная Промышленность, Перерабатывающая промышленность, Медицинское оборудование, Железная дорога, Строительная автоматизация, Авиационная радиоэлектроника, Бытовые приборы, Вооруженные силы, Обработка материалов, Сельское хозяйство, Телекоммуникация, Грузовики, Строительные Машины и Транспортные средства, Индустриальная автоматизация.

Общие сведения

Локальная сеть контроллеров CAN это стандарт серийной шины, разработанный в 80-х годах Robert Bosch GmbH, для соединения электронных блоков управления. CAN был специально разработан для устойчивой работы в насыщенной помехами окружающей среде с применением разносторонне сбалансированной линии, такой как RS-485. Соединение может быть более устойчивым к помехам при использовании витой пары. Первоначально создавалась для автомобильного назначения, но в настоящее время используется в разнообразных системах управления, в т.ч. индустриальных, работающих в насыщенной помехами окружающей среде.
Скорость обмена данными до 1Mbit/s возможна в сетях протяженностью не более 40м. Снижение скорости обмена позволяет увеличить протяженность сети, например - 250 Kbit/s при 250м.
CAN протокол связи стандартизирован согласно ISO 11898-1 (2003). Этот стандарт главным образом описывает слой обмена данными состоящий из подраздела логического контроля (LLC) и подраздела контроля доступа (MAC), и некоторых аспектов физического слоя ISO/OSI модели. Остальные слои протокола оставлены на усмотрение разработчика сети.

CAN сети и их разновидности

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

Общая характеристика

Интегрированная серийная коммуникационная шина для приложений работающих в режиме реального времени.
. Сеть работоспособна при скорости обмена данными до 1Mbit/s.
. Обладает превосходными возможностями обнаружения и проверки ошибок и неисправностей.
. Изначально CAN шина разработана для применения в автомобилях
. Используется в различных автоматических системах и системах управления.
. Международный стандарт: ISO 11898

Определение CAN

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

Свойства CAN

CAN система на серийной шине с мультифункциональными возможностями, все CAN узлы способны передавать данные и некоторые CAN узлы могут запрашивать шину одновременно. Передатчик передает сообщение всем CAN узлам. Каждый узел, на основании полученного идентификатора, определяет, следует ли ему обрабатывать сообщение или нет. Идентификатор так же определяет приоритет, который имеет сообщение при доступе к шине. Простота определяет стоимость оборудования и затраты на обучение персонала. CAN микросхемы могут быть относительно просто запрограммированы. Вводные курсы, функциональные библиотеки, наборы для начинающих, различные интерфейсы, I/O модули и инструменты в широком разнообразии представлены в открытой продаже по доступным ценам. С 1989 года CAN микросхемы могут быть свободно и просто соединены с микроконтроллерами. В настоящее время в наличии около 50 CAN микросхем для микроконтроллеров более чем 15 производителей.
CAN применяется в большинстве Европейских легковых автомобилях, а так же решение производителей грузовиков и внедорожников в дальнейшем применять CAN, определили развитие более чем на 10 лет. В других областях применения, таких как, бытовая сфера и индустриальный сектор наблюдается рост продаж CAN оборудования, и будет продолжаться в будущем. К весне 1997 года уже насчитывалось более чем 50 миллионов установленных CAN узлов. Одна из выдающихся особенностей CAN протокола высокая надежность обмена данными. CAN контроллер регистрирует ошибки и обрабатывает их статистически для проведения соответствующих измерений, CAN узел, являющийся источником неисправности, в результате будет отстранен от соединения.
Каждое CAN сообщение может содержать от 0 до 8 бит пользовательской информации. Конечно, возможна передача более продолжительных данных с применением фрагментации. Максимальная специфицированная скорость обмена 1 Mbit/s. Это возможно при протяженности сети не более 40м. Для более длинной коммуникации скорость обмена должна быть снижена. Для дистанции до 500 м скорость 125Kbit/s, и для передачи более чем на 1 км допускается скорость 50 Kbit/s.

CAN приложения

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

Лицензия CAN

CAN протокол разработан Robert Bosch GmbH и защищен патентами.

Основные стандарты CAN

Далее перечислены некоторые международные CAN стандарты
. CAN стандарты:
o ISO 11898-1 - CAN протокол
o ISO 11898-2 - CAN высокоскоростная физическая структура
o ISO 11898-3 - CAN низкоскоростная физическая структура совместимая с ошибками
o ISO 11898-4 - CAN запуск
o ISO 11898-5 - Высокоскоростное низковольтное устройство (в разработке).
o ISO 11519-2 - заменен на 11898-3.
. ISO 14230 - "Keyword Protocol 2000" - диагностический протокол использующий серийную линию, не CAN
. ISO 15765 - Диагностический протокол по CAN bus - Keyword 2000 на CAN bus.
. J1939 - Основной CAN протокол для грузовиков и автобусов определенный SAE
. ISO 11783 - J1939 и дополнение для сельхоз машин
. ISO 11992 - определяет интерфейс тягачей и прицепов
. NMEA 2000 - Протокол основанный на J1939 для судов, определен NMEA.

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

Преимущества CAN:

- Доступность для потребителя.
CAN протокол успешно применяется на протяжении более 15 лет, с 1986 года. Существует богатый выбор CAN продуктов и устройств в открытой продаже.

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

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

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

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

2. CAN шина

Введение

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

CAN протокол

CAN определен стандартом ISO 11898-1 и включает следующие основные сведения.
. На физическом уровне, сигнал передается, используя витую пару.
. Для контроля к доступу шины применяются правила арбитража.
. Блоки данных небольшие по размеру (в большинстве случаев 8 байт) и защищены чексуммой.
. Блоки данных не имеют адресации, вместо того каждый блок содержит числовое значение, которое определяет приоритет передачи по шине, так же может нести идентификатор содержания блока данных.
. сложная схема обработки ошибок, которая приводит к повторной передаче данных, которые должным образом не получены.
. Эффективные действия по изоляции неисправностей и отключение источника неисправности от шины.

Протоколы высшего порядка (HLP)

CAN протокол определяет безопасную передачу небольших пакетов данных из пункта А в пункт Б используя общую линию коммуникации. Протокол не содержит средств контроля потока, адресацию, не предоставляет передачу сообщений более чем 8 бит, не осуществляет установку соединения и т.д. Перечисленные свойства определяются HLP(Higher layer protocol) или Протокол Высшего Порядка. Условия HLP получены и состоят из семи порядков OSI модели.

Назначение HLP
. Стандартизация процедур запуска и установка скорости передачи
. Распределение адресации устройств и разновидности сообщений.
. Определение порядка сообщений
. обеспечивает механизм определения неисправностей системного уровня

CAN продукты

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

Патенты в области CAN

Патенты в отношении CAN приложений могут быть различных видов и направлений. Далее несколько видов:
. Синхронизация и реализация частоты передачи
. Передача больших блоков данных (CAN протокол использует фреймы длинной не более 8 бит)
Системы контроля распределения
CAN протокол продуктивная база для создания систем контроля распределения. Метод арбитража обеспечивает возможность каждого CAN устройства взаимодействовать с сообщениями относительно этого устройства.
Система контроля распределения может быть заявлена как система, в которой возможности процессора распределены среди устройств системы, или же наоборот, как система с центральным процессором и локальными I/O устройствами.
При разработке CAN сети могут быть применены различные совместимые аппаратные устройства, обладающие необходимыми свойствами и удовлетворяющие заданным или расчетным параметрам сети такие как, частота процессора, скорость передачи данных и т.д.

Действующие протоколы высшего порядка (HLP)

CAN протокол определяет безопасную передачу небольших пакетов данных из пункта А в пункт Б используя общую линию коммуникации. Протокол не содержит средств контроля потока, адресацию, не предоставляет передачу сообщений более чем 8 бит, не осуществляет установку соединения и т.д. Перечисленные свойства определяются HLP, higher layer protocol (Протоколами Высшего Порядка). Условия HLP получены и состоят из семи порядков

OSI модели (Open Systems Interconnect Model)
CanKingdom
CANopen/CAL
DeviceNet
J1939
OSEK
SDS
HLP обычно определяет
. Параметры запуска
. Распределение идентификатора сообщения среди различных устройств в системе
. Интерпретация содержимого блоков данных
. Статус взаимодействия в системе

Характеристика SDS, DeviceNet and CAN Kingdom.

И различия между CAN Kingdom and CANopen. В настоящее время насчитывается более 50 HLP. Применение HLP обязательно, в противном случае придется изобрести свой, собственный HLP.

CAnKingdom

CanKingdom поддерживается организацией CanKingdom International полная спецификация доступна на сайте организации.
CanKingdom обычно упоминается как CAN (Controller Area Network) протокол высшего порядка. В реальности наиболее упорядоченный протокол. Модули в системе соединены сетью, в которой один из модулей является главным (King). Например: для организации plug & play системы, главный модуль определяет какое устройство и при каких обстоятельствах может быть добавлено, разрешено добавление только специфицированных устройств. CanKingdom обеспечивает простую уникальную идентификацию устройств в системе, для этого используется стандарт идентификации EAN/UPC, индивидуальный идентификатор устройства определяется серийным номером устройства.
CanKingdom предоставляет разработчику все потенциальные возможности CAN.
Дизайнер не ограничен мультимастер протоколом CSMA/AMP и может создавать виртуальные системы управления шинами всевозможных разновидностей и топологии. Предоставляет возможность создания общих модулей без учета обстоятельств таких как, зависимость от HLP и свойств системы. Дизайнер может определить использование только специфических модулей, совмещая тем самым ценности открытой системы с преимуществами системы с ограниченным и безопасным доступом.

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

CAL and CANopen

CAL сокращенно от "CAN Application Layer" Порядок или слой CAN приложений, протокол поддерживается CiA. CAL разделен на несколько составных частей:
. CMS (CAN-based Message Specification) определяет протоколы передачи данных между CAN устройствами
. NMT (Network Management Service) определяет протоколы запуска и выключения, определения неисправностей, и т.д.
. DBT (Distributor Service) определяет протокол распределения идентификаторов различных устройств в системе
- CAL протокол отличный от OSI модели (Open Systems Interconnect (OSI) Model)
- CANopen является подразделом CAL, и скомпонован как набор профилей, которые не завершены окончательно.
- CAL/CANopen один из HLP действующих протоколов, поддерживаемых CiA.
- CAL и CANopen спецификации в полном объеме доступны и поддеживаются CiA

DeviceNet

Протокол развивается “Rockwell Automation nowadays”, определен организацией ODVA (Open DeviceNet Vendor Association). DeviceNet один из четырех протоколов, которые поддерживает CiA.

SAE J1939

J 1939 высокоскоростная сетевая коммуникация класса С разработанная для поддержки функций управления в режиме реальногго времени между контроллерами, которые физически расположены в различных местах автомобиля.
Jl708/Jl587 предыдущий, широко распространенный тип сети класса B с возможность обмена простой информацией, включая диагностические данные, между контроллерами. J1939 обладает всеми свойствами J1708/J1587.
J1939 использует CAN протокол с позволяет любому устройству передавать сообщение по сети в момент когда шина не загружена. Каждое сообщение включат в себя идентификатор, который определяет приоритет сообщения, информацию об отправителе данных, об информации, заключенной в сообщении. Конфликты избегаются благодаря механизму арбитража, который активизируется с передачей идентификатора (используется безопасная схема арбитража). Это позволяет сообщениям с наивысшим приоритетом передаваться с наименьшими задержками, по причине равного доступа к шине любым из устройств сети.
J1939 организован из нескольких частей основанных на (Open Systems Interconnect (OSI) Model). OSI модель определяет семь коммуникационных порядков (слоев), каждый представляет различные функции. В то время как есть документ J1939, ассигнованный каждому слою, не все они явно определены в пределах J1939. Другие слои выполняют вторичные функции, описанные в другом месте. Физический Слой описывает электрический интерфейс коммуникаций (витая экранированная пара проводов, который может также быть упомянут как шина). Слой Канала связи описывает протокол или управляет структурой сообщения, получая доступ к шине, и обнаруживая ошибки передачи. Слой приложения определяет специфические данные, содержащиеся в каждом сообщении, посылаемом по сети.
Полный комплект спецификации можно приобрести в SAE, ниже приведен перечень документов
J1939 дополняется следующими документами:
J1939 Практические рекомендации по Контролю серийной передачи и коммуникационная сеть транспортного средства
J1939/11 Физический порядок (слой) - 250k bits/s, экранированная витая пара
J1939/13 Диагностические разъемы
J1939/21 Данные слоя связи
J1939/31 Слой сети
J1939/71 Слой приложений
J1939/73 Диагностика
J1939/81 Управление сетью

OSEK/VDX

OSEK/VDX является совместным проектом в автомобильной индустрии. Создан как промышленный стандарт открытой оконечной архитектуры для распределенных контроллеров транспортных средств. Операционная система в режиме реального времени, интерфейсы программных средств и задачи управления сетью специфицированы совместно. OSEK" (Open systems and the corresponding interfaces for automotive electronics.) Открытые системы и информационные интерфейсы для автомобильной электроники. VDX “Whicule Distributed eXecutive" Распределенные исполнители транспортного средства.
Компании совместно участвующие в разработке: Opel, BMW, DaimlerChrysler, IIIT - University of Karlsruhe, PSA, Renault, Bosch, Siemens, Volkswagen.
Официальный сайт: www.osek-vdx.org

Smart Distributed System (SDS)

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

Сравнительная характеристика основных HLP протоколов
Общие сведения

DeviceNet, SDS и CAN Kingdom основаны на ISO 11898 CAN коммуникационном протоколе и функционируют согласно требований CAN спецификации. Каждый CAN модуль, следующий определенному протоколу может быть подключен к CAN шине следующей тому же протоколу. В любом случае при подключении модулей, которые действуют по различными протоколам, в большинстве случаев проблемы возникают по причине конфликта интерпретации сообщений на уровне приложений. CAN Kingdom отличается от SDS и DeviceNet основным принципом: CAN Kingdom организуется главным узлом коммуникации (“King”) при запуске, в отличии от SDS и DeviceNet. Такая организация позволяет упростить разработку комплекса систем реального времени и сокращает необходимое количество модулей координирующих спецификации, часто обозначаемые как профили.
SDS эффективен при подключении I/O устройств, различных выключателей и датчиков к PLC , фактически представляет собой соединение между основным модулем и удаленными I/O устройствами.
DeviceNet открытая система, в которой все модули имеют равные права по пользованию шиной, и порядок пользования шиной определяется небольшим набором инструкций. Разработчик модулей системы может передать полномочия по управлению коммуникацией другим модулям, например основному модулю в предопределенном режиме Главный/подчиненный, но DeviceNet не имеет возможности передать полномочия другим модулям. Характеристики SDS с использованием I/O устройств и DeviceNet в режиме Главный/подчиненный сходны.
Can Kingdom протокол ориентированный на системы продуцирования, соединения и контроля и не поддерживает профили для цифровых и аналоговых устройств. Основная особенность протокола заключается в том что модуль, подключенный к системе только ожидает инструкции от главного устройства. Все CAN приоритеты и идентификаторы принадлежат и предоставляются главным устройством. Во время запуска каждый модуль конфигурируется основным устройством, определяются приоритеты и идентификаторы объектов продуцирующих и потребляющих. Основное устройство является главным, но только в период конфигурирования системы. Главное устройство не может быть внедрено в период коммуникационной сессии между работающими приложениями различных модулей. Основное устройство может быть удалено после конфигурирования и проверки комплектности, при том каждый модуль запоминает полученные инструкции в памяти.