Содержание

Введение в протокол 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 всегда выставлен в логический ноль (доминантный сигнал).

Рис. 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
SDS
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 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:

скорость передачи	максимальная длина сети
1000 Кбит/сек	40 метров
500 Кбит/сек	100 метров
250 Кбит/сек	200 метров
125 Кбит/сек	500 метров
10 Кбит/сек	6 километров

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

Промышленное оборудование для can сетей

ICP DAS I-7530A-MR в АВЕОН

Стандарт коммуникационной и диагностической сети для различных машин. Изначально был разработан в США для грузовиков. Данный стандарт является коммерческой разработкой, поэтому мало распространён. Протокол основан на CanBUS.

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

Под заказ – 1-2 недели со склада в Тайване (при наличии у производителя).

Обратитесь к специалистам АВЕОН по телефону +7 (343) 381-75-75 или по адресу ipcsales@aveon.ru – и менеджеры отдела продаж помогут подобрать оборудование под ваш проект автоматизации.

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

Приемопередатчики для сетей CAN производства NXP, Texas Instruments и Maxim

Разработанный для автомобильной промышленности, сетевой стандарт CAN в последние годы стал одним из самых распространенных индустриальных интерфейсов. В статье дан обзор производимых приемопередатчиков для CAN-сетей от мировых лидеров электронной промышленности: NXP, Texas Instruments и Maxim.

Интерфейс CAN (Controller Area Network – сеть контроллеров) – стандарт промышленной сети, ориентированный на объединение в единую сеть различных исполнительных устройств и датчиков, был разработан компанией Robert Bosch GmbH для автомобильной автоматики в середине 1980-х. В настоящее время этот стандарт широко применяется в промышленной автоматизации, технологиях «умного дома», автомобильной промышленности, в корабельных бортовых сетях, управлении системами кондиционирования воздуха, лифтами, медицинскими и промышленными установками. В мире уже установлено более 100 млн. узлов сетей CAN, ежегодный прирост составляет более 50%.

Непосредственно стандарт CAN от Bosch определяет передачу без привязки к физическому способу передачи данных, т.е. он может быть каким угодно, например, радиоканалом или оптоволокном. Но на практике под CAN-сетью (рис. 1) обычно подразумевается сеть с физическим уровнем в виде общей и единой дифференциальной пары (ISO 11898). При максимальной скорости передачи, оговоренной стандартом, (1 Мбит/с) длина шины может достигать 30 м. При меньших скоростях ее можно увеличить до нескольких километров (на скорости 10 кБит/с – длина шины до 5 км). Если требуется большая длина, то ставятся мосты или повторители. Теоретически число подсоединяемых к шине устройств не ограничено ничем, а практически не превышает 64. В большинстве применений этой цифры вполне достаточно.

Рис_1

Рис. 1. Физическая топология шины CAN

Шина CAN является мультимастерной, т. е. сразу несколько устройств могут управлять ею. Передача ведется кадрами, которые принимаются абсолютно всеми узлами сети. Шина CAN является синхронной шиной, которая в отличие от сетей типа Ethernet и им подобных (точка-точка) обеспечивает доступ на передачу сообщения детерминировано (т.е. приоритетно), что особо ценно для промышленных сетей управления (fieldbus). Коллизии и ошибки, возникающие на шине CAN, однозначно детектируются всеми узлами сети: узлы с зафиксированной ошибкой попросту отключаются от сети. Описание стандартов и большой объем документации по шине CAN бесплатно доступен на сайте организации CAN in Automation www.can-cia.de.

Каждый узел сети CAN состоит как минимум из трех основных частей: приемопередатчик физического уровня сети (в дальнейшем трансивер), контроллер пакетов сети, процессор или микроконтроллер, определяющий функциональное назначение самого узла. Зачастую сам контроллер CAN входит в состав процессора/микроконтроллера. Однако трансивер в виде отдельной микросхемы является необходимостью. Объясняется это, прежде всего, высокими требованиями к его надежности и рабочим характеристикам, поскольку работает он с цепями, физически выходящими за пределы устройства (в данном случае это сама шина CAN). А условия, в которых находятся эти цепи, зачастую не определены: например, сильные магнитные поля или пролегающие рядом силовые высоковольтные цепи. Более того, при необходимости гальванической развязки ее удобнее всего осуществлять именно между трансивером и контроллером CAN-сети.

Максимальное число узлов, подключенных к шине, фактически определяется нагрузочной способностью примененных трансиверов. Например, при использовании PCA82C250 от компании NXP (данная микросхема была разработана еще Philips Semiconductors) она равна 110.

Значительно возросшие требования к современным микросхемам по надежности, температуре, экономичности и другим параметрам касаются также и трансиверов сетей CAN. Ниже приведен обзор трансиверов трех производителей: NXP, Texas Instruments и Maxim.

CAN-трансиверы NXP

Высокоскоростные CAN-трансиверы компании NXP TJA1040, TJA1041, TJA1050 (табл. 1) основаны на продвинутой технологии SOI – кремний на изоляторе (Silicon-on-Insulator). Благодаря этой технологии новые трансиверы в сравнении с трансиверами предыдущего поколения PCA82C250 и PCA82C251 имеют уменьшенный уровень собственного электромагнитного излучения (20 дБ) и высокую устойчивость к электромагнитному излучению.

Таблица 1. Краткие параметры и характеристики микросхем CAN-трансиверов NXP

Наименование

Диапазон
напряжения
питания, В

Максимально
допустимое
напряжение
на шине CAN,
В

Макси-
мальная
скорость
передачи,
кбит/с

Ток
потреб-
ления в
экономичном
режиме,
мкА

Диапазон
рабочей
температуры,
°С

Промышленное оборудование для can сетей

Не найдено рубрик для подписки.

Новые модули ввода аналоговых данных для промышленных CAN-сетей

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

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

Промышлееные сети построенные на протоколе связи CAN (Controller Area Network) характеризуются высокой скоростью передачи данных, помехоустойчивостью, а также способностью обнаруживать любые возникающие ошибки. Благодаря этому CAN-сети сегодня широко используется в различных областях промышленности для создания различных систем АСУ ТП.

CAN-2018C, CAN-2018D новые модули ввода данных для сетей CAN предназначенны для ввода сигнала с термопары.

Модуль ввода данных CAN-2018С выпускается с поддержкой протокола CANopen и модуль CAN-2018D с протоколом DeviceNet.

Протокол CANopen в модулях ввода данных CAN-2018С соответствует требованиям CiA DS-301 v4.02 и DSP-401 v2.1. Это подтверждается пройденными тестами в CiA CANopen Conformance Test. Модули ввода данных

Модуль ввода CAN-2018D с протоколом DeviceNet соответствуют требованиям спецификаций Volume I/II, Release 2.0. организации ODVA.

Таким образом, данные модули могут быть легко интегрированы в сеть CANopen / DeviceNet, мастером которой является устройство стороннего производителя.

Модули ввода данных CAN-2018С и CAN-2018D имеют 8 каналов дифферинциального аналогового ввода. Каналы могут конфигурироваться для ввода сигнала с термопары.

Используя в качестве мастера сети CANopen / DeviceNet устройства от ICP DAS, пользователь быстро и просто сможет построить гибкую систему сбора данных и управления.

Промышленная автоматизация

Главная
Каталог
Статьи
Контакты
Доставка и оплата

Российские защищенные модули и системы для промышленной автоматизации и ответственных применений

Средства человеко-машинного интерфейса

Защищенные мониторы

Промышленные ЖКИ мониторы
Мониторы для морских применений
Промышленные ЖКИ матрицы

Панельные компьютеры
Рабочие станции

Панельный компьютер на базе процессора Intel Atom с 12,1″ сенсорным экраном
Панельный компьютер с 17″ сенсорным экраном на базе процессора Intel Core 2 Duo
Панельный компьютер с 6,4-дюймовым дисплеем

Промышленная рабочая станция с 15″ ЖК-дисплеем
Промышленная рабочая станция с 6,4″ TFT ЖК-дисплеем и встроенной клавиатурой

Acme Portable
Ariesys
IEI Technology

Крепление в 19″ Rack стойку ( Rack Mounting )
Крепление в панель ( Panel Mounting )
Крепление на DIN рейку ( DIN Mounting )
Настенное крепление ( Wall Mounting )
Настольное крепление ( Stand Mounting )
Подвижный кронштейн ( ARM Mounting )

Промышленный Ethernet

DSL-удлинители Ethernet
SFP модули для коммутаторов
Аксессуары для коммутаторов
Встраиваемые шасси
Кабели и разъемы Ethernet
Коммутаторы с защитой от вибрации, от попадания пыли и влаги
Коммутаторы с функцией Power Over Ethernet (PoE)
Модульные коммутаторы Industrial Ethernet для стойки 19»
Модульные коммутаторы Industrial Ethernet на DIN-рейку
Неуправляемые коммутаторы Industrial Ethernet
Оборудование беспроводного Ethernet
Промышленные Ethernet-конвертеры
Промышленные маршрутизаторы
Управляемые коммутаторы Industrial Ethernet

Встраиваемые бескорпусные преобразователи
Консольные и терминальные серверы
Отладочные платы для MiiNePort и NE
Преобразователи NPort в промышленном исполнении
Преобразователи NPort в стандартном исполнении
Преобразователи NPort со встроенным Ethernet-коммутатором
Преобразователи в беспроводной Ethernet
Преобразователи протоколов (Modbus, Profibus, Profinet, Ethernet/IP, DF1, . )

Защита RS-232/422/485 от импульсных помех
Модульные преобразователи интерфейсов
Повторители и изоляторы RS-232, RS-422/485
Преобразователи RS-232 в RS-422/485
Преобразователи RS-232/422/485 в оптоволокно

Антенны GSM/GPRS/LTE
Сотовые GSM/GPRS-модемы
Сотовые GSM/GPRS-роутеры
Сотовые IP-модемы с интерфейсом RS-232/422/485
Сотовые IP-модемы с интерфейсом RS-232/422/485 и Ethernet
Сотовые LTE-модемы

Аксессуары для видеокамер
Видеорегистраторы
Видеосерверы VPort
Защищенные видеокамеры VPort

1-портовые преобразователи RS-232/422/485 в USB
USB-хабы
Многопортовые преобразователи RS-232 в USB в пластиковом корпусе
Многопортовые преобразователи RS-232/422/485 в USB в металлическом корпусе

Блоки питания
Монтажные комплекты

Аксессуары для 8-портовых плат (кабели и разветвители)
Интеллектуальные мультипортовые платы
Мультипортовые платы для шины ISA
Мультипортовые платы для шины PC/104 и PC/104 Plus
Мультипортовые платы для шины PCI
Мультипортовые платы для шины PCI Express
Мультипортовые платы для шины Universal PCI (с поддержкой PCI и PCI-X)
Платы интерфейса CAN

Коммуникационные платы
Оборудование для полевых шин Fieldbus
Оборудование для промышленных сетей Ethernet
Оборудование с последовательными интерфейсами
Платформы для межсетевых экранов
Промышленные модемы
Беспроводные устройства связи

Коммуникационные платы
Оборудование для полевых шин Fieldbus
Оборудование для промышленных сетей Ethe.
Оборудование с последовательными интерфе.
Платформы для межсетевых экранов
Промышленные модемы
Беспроводные устройства связи

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

Riser карты
Адаптеры
Видеоадаптеры
Звуковые контроллеры ( Audio Kits )
Кабели, планки, переходники, разъемы
Системы охлаждения CPU ( Coolers )

Бескорпусные блоки питания
Блоки питания для модулей сбора данных
Внешние адаптеры питания
Модули питания DC-DC
Промышленные блоки питания для 1U / 2U корпусов
Промышленные блоки питания формата PS/2
Резервируемые блоки питания
Снятые с производства ( Архив )

Аксессуары для корпусов
Корпуса в настольно-настенном исполнении
Корпуса для встраиваемых систем
Корпуса для монтажа в 19″ стойки с дисплеями
Модульные корпуса для монтажа в 19» стойки
Промышленные корпуса для монтажа в 19″ стойки

Серии iKARPC / VTT
Серия ICECARE
Серия ICEFIRE
СЕРИЯ ICEROCK
Серия MODAT

Пассивные платы формата ISA
Пассивные платы формата PCISA
Пассивные платы формата PICMG 1.0
Пассивные платы формата PICMG 1.3
Пассивные платы формата PICO / PICOe

Платы половинного размера ( Half-Size )
Полноразмерные платы формата PICMG 1.0
Полноразмерные платы формата PICMG 1.3
Полноразмерные платы формата PICMG 1.3 Server Grade

Аксессуары для компьютеров
Беспроводные коммуникационные компьютеры
Компьютеры для морских применений
Компьютеры для применения на железной дороге
Компьютеры на базе RISC-процессора
Компьютеры с архитектурой процессора x86
Модули расширения для компьютеров

Серия ARK-1000: Ультратонкие безвентиляторные встраиваемые компьютеры
Серия ARK-2000: Безвентиляторные встраиваемые компьютеры с широким набором интерфейсов ввода/вывода
Серия ARK-3000: Высокопроизводительные безвентиляторные встраиваемые компьютеры
Серия ARK-5000: Безвентиляторные встраиваемые компьютеры со слотами расширения PCI/PCIe
Серия ARK-6300: Безвентиляторные встраиваемые компьютеры форм-фактора mini-ITX
Серия ARK-VH: Встраиваемые безвентиляторные компьютеры для транспорта и видеонаблюдения
Серия eBOX: Универсальные встраиваемые компьютеры
Серия IPC: Barebon системы в безвентиляторном исполнении
Серия rBox: Малогабаритные встраиваемые компьютеры устанавливаемые на DIN-рейку
Серия tBOX: Встраиваемые компьютеры для авто- и жд траспорта
Серии AVL, SBOX: Многофунциональные компьютеры для применения на транспорте
Серия ECN: Компьютеры с возможностью установки PCI-104 плат расширения
Серия ECW: Малогабаритные компьютеры с универсальным креплением и с широким ассортиментом интерфейсов
Серия IBX: Миниатюрные компьютеры с малым электропотреблением
Серия TANK: Безвентиляторные компьютеры с расширенным температурным диапазоном
Серия uIBX: Малогабаритные безвентиляторные компьютеры с VESA креплением
EZ Контроллеры
Высокопроизводительные компьютеры
Компьютеры для железнодорожного транспорта
Компьютеры для траспорта
Компьютеры, работающие в расширенном температурном диапазоне
Энергоэффективные компьютеры
Крепёжные элементы

Процессорные платы

Платы формата 2.5″
Платы формата 3.5″
Платы формата 5.25″
Платы формата EPIC
Платы формата ETX, Q7 и COM Express
Платы формата Mini — ITX
Платы формата PC/104 ( PCI-104 )
Платы формата Pico-ITX
Промышленные материнские платы

Пассивные шины CompactPCI
Периферия CompactPCI
Системы сбора CompactPCI

Защищенные клавиатуры InduKey

Аксессуары
Раздел EX: взрывобезопасные клавиатуры
Раздел IP68: пыле- и влагонепроницаемые клавиатуры
Раздел TKF: компактные мембранные клавиатуры
Раздел TKG: клавиатуры на силиконовой основе
Раздел TKH: защищенные указательные устройства
Раздел TKL: длинноходовые клавиатуры
Раздел TKR: стеклянные емкостные клавиатуры
Раздел TKS: промышленные короткоходовые клавиатуры с износостойким покрытием
Раздел TKV: вандалозащищённые клавиатуры

Измерительные приборы и оборудование

Высокоскоростные АЦП и генераторы сигналов
Цифровые мультиметры

PXI/Compact PCI платформы Adlink

Клеммные и переходные платы
Многофункциональные платы ввода-вывода
Платы для шины ISA
Платы для шины PCI
Платы нормализации сигналов
Платы релейного ввода-вывода
Системы и платы управления перемещением
Платы видеозахвата, видеосистемы

24-канальный модуль дискретного ввода-вывода
48-канальный модуль дискретного ввода-вывода
Многофункциональный модуль ввода-вывода
Многофункциональный модуль ввода-вывода c 16-разрядным разрешением
Модуль дискретного ввода-вывода с гальванической изоляцией
Модуль дискретного ввода-вывода с релейными выходами
Низкопрофильная плата интерфейса GPIB (IEEE 488)

WISE

WISE-4000(D)
WISE-580x
WISE-71xx
WISE-790x(D)

Модули серии ET-7000/PET-7000 с интерфейсом Ethernet
Модули серии I-7000/ M-7000 с интерфейсом RS-485
Нормирующие преобразователи ICP DAS
Релейные модули

Корзины расширения с CAN-интерфейсом
Корзины расширения с Ethernet-интерфейсом
Корзины расширения с PROFIBUS-интерфейсом
Корзины расширения с USB-интерфейсом
Корзины расширения с интерфейсом RS-485

Коммуникационные модули серий I-8100(W) и I-87100(W)
Мезонинные модули серии X000 для компактных контроллеров
Модули I-8000(W) и I-87000(W) ввода-вывода импульсных сигналов
Модули I-8000(W) для сопряжения с сервоприводами
Модули аналогового ввода серий I-8000(W) и I-87000(W) (АЦП)
Модули аналогового вывода серий I-8000(W) и I-87000(W) (ЦАП)
Модули дискретного ввода-вывода серий I-8000(W) и I-87000(W)
Модули памяти I-8000

HMI
MMICON
TouchPAD
Сенсорные мониторы серии TP
Серия cMT — Cloud HMI
Серия eMT3000
Серия MT6000
Серия MT8000i/MT8000iH
Серия MT8000iE
Серия MT8000XE
Серия mTV-100

ISA платы
PCI платы
Дочерние платы
Клеммные и переходные платы
Платы нормализации сигналов
Платы релейного ввода-вывода

I-7188
I-8000
iP-8000
LinPAC
uPAC
ViewPAC
WinPAC
XPAC

Модули серии HART
Преобразователи EtherNet/IP
Преобразователи, повторители, шлюзы
Програмируемые коммуникационные контроллеры (I-752n, I-7188En, PDS-700)

Видеозахват с аналоговых интерфейсов
Распродажа

Внешние модули АЦП/ЦАП и цифрового ввода /вывода
Модульная система сбора данных LTR
Оборудование для измерения качества электроэнергии по ГОСТ
Предусилители и вспомогательное оборудование
Универсальные платы АЦП на шину PCI/PCI Express

Компания СПЕЦ-АСУ продает сетевые платы PCI: GE-100 / FE-124
Плата GE100 может служить заменой платы PWLA8391GT при использовании под Российскими ОС.

CAN-шина

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

Разработка CAN- шины началась в 1983 году в компании Robert Bosch GmbH . [1] Протокол был официально выпущен в 1986 году на конференции Общества автомобильных инженеров (SAE) в Детройте , штат Мичиган . Первые микросхемы контроллеров CAN были представлены Intel в 1987 году, а вскоре после этого — Philips . [1] Выпущенный в 1991 году Mercedes-Benz W140 стал первым серийным автомобилем, оснащенным системой мультиплексной проводки на основе CAN. [2] [3]

Компания Bosch опубликовала несколько версий спецификации CAN, последняя из которых — CAN 2.0, опубликованная в 1991 году. Эта спецификация состоит из двух частей; часть A предназначена для стандартного формата с 11-битным идентификатором, а часть B — для расширенного формата с 29-битным идентификатором. Устройство CAN, использующее 11-разрядные идентификаторы, обычно называется CAN 2.0A, а устройство CAN, использующее 29-разрядные идентификаторы, обычно называется CAN 2.0B. Эти стандарты находятся в свободном доступе от Bosch вместе с другими спецификациями и официальными документами . [4]

В 1993 году Международная организация по стандартизации (ISO) выпустила стандарт CAN ISO 11898, который позже был реструктурирован на две части; ISO 11898-1, который охватывает уровень канала передачи данных , и ISO 11898-2, который охватывает физический уровень CAN для высокоскоростной CAN. Стандарт ISO 11898-3 был выпущен позже и охватывает физический уровень CAN для низкоскоростной отказоустойчивой CAN. Стандарты физического уровня ISO 11898-2 и ISO 11898-3 не являются частью спецификации Bosch CAN 2.0. Эти стандарты можно приобрести в ISO.

Bosch по-прежнему активно расширяет стандарты CAN. В 2012 году Bosch выпустила CAN FD 1.0 или CAN с гибкой скоростью передачи данных. В этой спецификации используется другой формат кадра, который позволяет использовать другую длину данных, а также при необходимости переключаться на более высокую скорость передачи данных после решения арбитража. CAN FD совместим с существующими сетями CAN 2.0, поэтому новые устройства CAN FD могут сосуществовать в одной сети с существующими устройствами CAN. [5]

CAN-шина — это один из пяти протоколов, используемых в стандарте бортовой диагностики (OBD) -II. Стандарт OBD-II является обязательным для всех автомобилей и легких грузовиков, продаваемых в США с 1996 года. Стандарт EOBD является обязательным для всех бензиновых автомобилей, продаваемых в Европейском союзе с 2001 года, и всех дизельных автомобилей с 2004 года. [6]

Легковые автомобили, грузовики, автобусы (бензиновые автомобили и электромобили)
Сельскохозяйственная техника
Электронное оборудование для авиации и навигации
Промышленная автоматизация и механическое управление
Лифты, эскалаторы
Автоматизация зданий
Медицинские инструменты и оборудование / железные дороги
Суда и другие морские приложения
Системы управления освещением

Автомобильная промышленность

Современный автомобиль может иметь до 70 электронных блоков управления (ЭБУ) для различных подсистем. [7] Обычно самым большим процессором является блок управления двигателем . Другие используются для автономного вождения, расширенной системы помощи водителю (ADAS), трансмиссии , подушек безопасности , антиблокировочной системы тормозов / ABS , круиз-контроля , электроусилителя руля , аудиосистем, электрических стеклоподъемников , дверей, регулировки зеркал, аккумуляторной батареи и систем подзарядки для гибридных / электрических автомобилей. автомобили и т. д. Некоторые из них образуют независимые подсистемы, но связь между другими важна. Подсистеме может потребоваться управление исполнительными механизмами или получение обратной связи от датчиков. Стандарт CAN был разработан, чтобы удовлетворить эту потребность. Одним из ключевых преимуществ является то, что взаимосвязь между различными системами транспортного средства может позволить реализовать широкий спектр функций безопасности, экономии и удобства с использованием только программного обеспечения — функциональность, которая увеличила бы стоимость и сложность, если бы такие функции были «жестко подключены» с использованием традиционной автомобильной электрики. Примеры включают:

Системы автоматического ассистента движения по полосе / предотвращения столкновений : входные сигналы от датчиков парковки также используются шиной CAN для передачи данных о внешнем приближении в вспомогательные системы водителя, такие как предупреждение о выезде с полосы движения, а в последнее время эти сигналы проходят через шину CAN для активации тормоза. по проводам в системах активного предотвращения столкновений.
Автоматическая очистка тормозов: сигнал поступает от датчика дождя (используется в основном для автоматических дворников ) через шину CAN на модуль ABS, чтобы инициировать незаметное торможение во время движения для удаления влаги с тормозных роторов. Некоторые высокопроизводительные модели Audi и BMW включают эту функцию.
Датчики могут быть размещены в наиболее подходящем месте, а их данные используются несколькими ЭБУ. Например, датчики наружной температуры (традиционно размещаемые спереди) можно разместить в наружных зеркалах, чтобы избежать нагрева двигателем, и данные, используемые двигателем, климат-контролем и дисплеем водителя.

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

Другой

Протокол шины CAN используется в электронной системе переключения передач Shimano DI2 для дорожных велосипедов с 2009 года, а также используется системами Ansmann и BionX в их двигателях с прямым приводом.
Шина CAN также используется в качестве полевой шины в средах общей автоматизации, в первую очередь из-за низкой стоимости некоторых контроллеров и процессоров CAN.
Производители, в том числе NISMO, стремятся использовать данные шины CAN для воссоздания реальных гоночных кругов в видеоигре Gran Turismo 6 с помощью игровой функции GPS Data Logger, которая затем позволит игрокам участвовать в гонках с реальными кругами. [8] «s Лаборатории прикладной физики » s Модульное Протезирование Лимб (MPL) использует локальную шину CAN для облегчения связи между сервоприводами и микроконтроллеры в протезом.
Команды FIRST Robotics Competition широко используют шину CAN для связи между roboRIO и другими модулями управления роботами.
CueScript Телесуфлер диапазон использует протокол шины CAN по коаксиальному кабелю, для подключения его CSSC — Desktop Scroll управления к основному блоку
Протокол CAN-шины широко применяется из-за его отказоустойчивости в электрически зашумленных средах, таких как системы обратной связи датчиков модели железной дороги от крупных производителей коммерческих систем управления цифровыми командами и различных проектов управления железной дорогой цифровых моделей с открытым исходным кодом.

Физическая организация

CAN — это стандарт последовательной шины с несколькими ведущими устройствами для подключения электронных блоков управления (ЭБУ), также известных как узлы. ( Автомобильная электроника — это основная область применения.) Для связи в сети CAN требуются два или более узла. Узел может взаимодействовать с устройствами от простой цифровой логики, например, PLD , через FPGA до встроенного компьютера, на котором запущено обширное программное обеспечение. Такой компьютер также может быть шлюзом, позволяющим компьютеру общего назначения (например, портативному компьютеру) обмениваться данными через порт USB или Ethernet с устройствами в сети CAN.

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

Эта шина использует дифференциальные сигналы проводного И. Два сигнала, CAN high (CANH) и CAN low (CANL), либо переводятся в «доминирующее» состояние с CANH> CANL, либо не управляются и не переводятся пассивными резисторами в «рецессивное» состояние с CANH ≤ CANL. Бит данных 0 кодирует доминантное состояние, а бит данных 1 кодирует рецессивное состояние, поддерживая соглашение о проводном И, которое дает узлам с более низким приоритетом идентификационных номеров на шине.

ISO 11898-2 , также называемый высокоскоростной CAN (битовая скорость до 1 Мбит / с на CAN, 5 Мбит / с на CAN-FD), использует линейную шину, оконцованную на каждом конце резисторами 120 Ом.

Высокоскоростная сигнализация CAN направляет провод CANH к 3,5 В и провод CANL к 1,5 В, когда какое-либо устройство передает доминантный (0), в то время как, если ни одно устройство не передает доминантный сигнал, согласующие резисторы пассивно возвращают два провода в рецессивный (1) состояние с номинальным дифференциальным напряжением 0 В. (Приемники считают любое дифференциальное напряжение менее 0,5 В рецессивным.) Доминирующим дифференциальным напряжением является номинальное 2 В. Доминирующее синфазное напряжение (CANH + CANL) / 2 должно быть в пределах от 1,5 до 3,5 В от общего, в то время как рецессивное синфазное напряжение должно быть в пределах ± 12 от общего.

ISO 11898-3 , также называемый низкоскоростной или отказоустойчивой CAN (до 125 кбит / с), использует линейную шину, звездообразную шину или несколько звездообразных шин, соединенных линейной шиной, и оканчивается на каждом узле на долю общее оконечное сопротивление. Общее оконечное сопротивление должно быть не менее 100 Ом.

Низкоскоростная отказоустойчивая сигнализация CAN работает аналогично высокоскоростной CAN, но с большими колебаниями напряжения. Доминантное состояние передается путем направления CANH к напряжению источника питания устройства (5 В или 3,3 В) и CANL к 0 В при передаче доминирующего (0), в то время как согласующие резисторы переводят шину в рецессивное состояние с CANH на 0. V и CANL при 5 В. Это позволяет использовать более простой приемник, который просто учитывает знак CANH-CANL. Оба провода должны выдерживать напряжение от −27 до +40 В без повреждений.

Электрические свойства

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

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

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

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

В высокоскоростной CAN используется резистор 120 Ом на каждом конце линейной шины. Низкоскоростной CAN использует резисторы в каждом узле. Могут использоваться другие типы оконечной нагрузки, такие как оконечная цепь смещения, определенная в ISO11783 . [9]

А оконечная цепь смещения обеспечивает питание и заземление в дополнение к сигнализации CAN по четырехпроводному кабелю. Это обеспечивает автоматическое электрическое смещение и согласование на каждом конце каждого сегмента шины . Сеть ISO11783 предназначена для горячего подключения и удаления сегментов шины и ЭБУ.

Каждому узлу требуется

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

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

Прием: он преобразует поток данных с уровней CANbus в уровни, используемые контроллером CAN. Обычно он имеет защитную схему для защиты CAN-контроллера.
Передача: он преобразует поток данных от контроллера CAN на уровни CANbus.

Каждый узел может отправлять и получать сообщения, но не одновременно. Сообщение или фрейм состоит в основном из идентификатора (идентификатора), который представляет приоритет сообщения, и до восьми байтов данных. CRC, слот подтверждения [ACK] и другие служебные данные также являются частью сообщения. Усовершенствованный CAN FD увеличивает длину раздела данных до 64 байтов на кадр. Сообщение последовательно передается на шину с использованием формата без возврата к нулю (NRZ) и может быть получено всеми узлами.

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

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

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

Точные напряжения для логического 0 или 1 зависят от используемого физического уровня, но основной принцип CAN требует, чтобы каждый узел прослушивал данные в сети CAN, включая сам (их) передающий узел (узлы). Если логическая 1 передается всеми передающими узлами одновременно, то логическая 1 видится всем узлам, включая как передающий узел (узлы), так и принимающий узел (узлы). Если логический 0 передается всеми передающими узлами одновременно, то логический 0 видят все узлы. Если логический 0 передается одним или несколькими узлами, а логическая 1 передается одним или несколькими узлами, то логический 0 видят все узлы, включая узел (ы), передающий логическую 1. Когда узел передает логическая 1, но видит логический 0, понимает, что есть конфликт, и прекращает передачу. При использовании этого процесса любой узел, который передает логическую 1, когда другой узел передает логический 0, «выпадает» или теряет арбитраж. Узел, который проиграл арбитраж, повторно ставит свое сообщение в очередь для последующей передачи, и поток битов кадра CAN продолжается без ошибок, пока только один узел не останется в режиме передачи. Это означает, что узел, который передает первую 1, проигрывает арбитраж. Поскольку 11 (или 29 для CAN 2.0B) бит идентификатора передается всеми узлами в начале кадра CAN, узел с наименьшим идентификатором передает больше нулей в начале кадра, и это узел, который выигрывает арбитраж или имеет наивысший приоритет.

Например, рассмотрим сеть CAN с 11-битным идентификатором с двумя узлами с идентификаторами 15 (двоичное представление, 00000001111) и 16 (двоичное представление, 00000010000). Если эти два узла осуществляют передачу одновременно, каждый сначала передаст стартовый бит, а затем передаст первые шесть нулей своего идентификатора без принятия арбитражного решения.

Стартовый бит	Идентификационные биты											Остальная часть кадра
Стартовый бит	10	9	8	7	6	5	4	3	2	1	0	Остальная часть кадра
Узел 15	0	0	0	0	0	0	0	0	1	1	1	1
Узел 16	0	0	0	0	0	0	0	1	Прекращена передача
CAN данные	0	0	0	0	0	0	0	0	1	1	1	1

Когда передается 7-й бит идентификатора, узел с идентификатором 16 передает 1 (рецессивный) для своего идентификатора, а узел с идентификатором 15 передает 0 (доминантный) для своего идентификатора. Когда это происходит, узел с идентификатором 16 знает, что он передал 1, но видит 0 и понимает, что произошла коллизия, и проиграл арбитраж. Узел 16 прекращает передачу, что позволяет узлу с идентификатором 15 продолжить передачу без потери данных. Узел с наименьшим идентификатором всегда выигрывает арбитраж и, следовательно, имеет наивысший приоритет.

Скорость передачи данных до 1 Мбит / с возможна при длине сети менее 40 м. Уменьшение скорости передачи данных позволяет увеличивать сетевые расстояния (например, 500 м при 125 кбит / с). Усовершенствованный стандарт CAN FD позволяет увеличить скорость передачи данных после арбитража и может увеличить скорость раздела данных до десяти или более раз по сравнению со скоростью передачи данных арбитража.

Идентификаторы сообщений должны быть уникальными [10] на одной шине CAN, в противном случае два узла продолжили бы передачу за пределами поля арбитража (ID), вызывая ошибку.

В начале 1990-х годов выбор идентификаторов для сообщений производился просто на основе идентификации типа данных и отправляющего узла; однако, поскольку идентификатор также используется в качестве приоритета сообщения, это привело к снижению производительности в реальном времени. В этих сценариях обычно требовалось низкое использование шины CAN — около 30%, чтобы гарантировать, что все сообщения уложатся в установленные сроки. Однако, если вместо этого идентификаторы определяются на основе крайнего срока сообщения, чем ниже числовой идентификатор и, следовательно, тем выше приоритет сообщения, то обычно можно достичь использования шины от 70 до 80% до того, как какие-либо крайние сроки сообщения будут пропущены. [11]

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

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

Регулировка выполняется путем деления каждого бита на несколько отрезков времени, называемых квантами, и присвоения некоторого количества квантов каждому из четырех сегментов внутри бита: синхронизации, распространения, фазового сегмента 1 и фазового сегмента 2.

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

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

Протокол CAN, как и многие сетевые протоколы, можно разделить на следующие уровни абстракции :

Фильтрация сообщений
Сообщения и обработка статуса

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

Локализация разломов
Обнаружение ошибок
Проверка сообщения
Подтверждение
Арбитраж
Обрамление сообщения
Скорость передачи и время
Маршрутизация информации

CAN-шина ( ISO 11898-1 : 2003) первоначально определяла протокол канального уровня только с абстрактными требованиями для физического уровня, например, утверждая использование среды с множественным доступом на битовом уровне посредством использования доминантного и рецессивного состояний. Электрические аспекты физического уровня (напряжение, ток, количество проводников) были определены в стандарте ISO 11898-2 : 2003, который в настоящее время получил широкое распространение. Однако механические аспекты физического уровня (тип и номер разъема, цвета, метки, расположение выводов) еще не определены. В результате автомобильный блок управления двигателем, как правило, будет иметь особый — часто настраиваемый — разъем с различными типами кабелей, два из которых являются линиями шины CAN. Тем не менее, появилось несколько стандартов де-факто для механической реализации, наиболее распространенным из которых является 9-контактный штекер типа D-sub со следующей схемой расположения выводов:

контакт 2: CAN-Low (CAN−)
контакт 3: GND (Земля)
контакт 7: CAN-High (CAN +)
контакт 9: CAN V + (питание)

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

Отсутствие полной спецификации физического уровня (механического в дополнение к электрическому) освободило спецификацию шины CAN от ограничений и сложности физической реализации. Однако это оставило реализации CAN-шины открытыми для проблем совместимости из-за механической несовместимости. Чтобы улучшить совместимость, многие производители транспортных средств разработали спецификации, описывающие набор разрешенных CAN-трансиверов в сочетании с требованиями к паразитной емкости на линии. Допустимая паразитная емкость включает как конденсаторы, так и защиту от электростатического разряда (ESD [13] согласно ISO 7637-3). Помимо паразитной емкости, системы 12 В и 24 В не имеют одинаковых требований в отношении максимального напряжения линии. Действительно, во время мероприятий по запуску от внешнего источника линии легковых автомобилей могут достигать 24 В, в то время как системы грузовиков могут достигать 36 В. На рынке появляются новые решения, позволяющие использовать один и тот же компонент как для CAN, так и для CAN FD (см. [14] ).

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

ISO 11898-2 обеспечивает некоторую невосприимчивость к синфазному напряжению между передатчиком и приемником за счет того, что шина 0 В проходит вдоль шины для поддержания высокой степени связи напряжения между узлами. Кроме того, в де-факто механической конфигурации, упомянутой выше, имеется шина питания для распределения мощности по каждому из узлов приемопередатчика. В конструкции предусмотрено общее питание для всех трансиверов. Фактическое напряжение, подаваемое на шину, и то, какие узлы применяются к ней, зависят от приложения и формально не указываются. Обычная конструкция узла обеспечивает каждый узел приемопередатчиками, которые оптически изолированы от своего узла узла и получают линейно регулируемое напряжение питания 5 В для приемопередатчиков от универсальной шины питания, обеспечиваемой шиной. Обычно это обеспечивает операционную маржу на шине питания, достаточную для обеспечения взаимодействия между многими типами узлов. Типичные значения напряжения питания в таких сетях составляют от 7 до 30 В. Однако отсутствие официального стандарта означает, что разработчики системы несут ответственность за совместимость с шинами питания.

ISO 11898-2 описывает электрическую реализацию, сформированную из конфигурации многоточечной несимметричной симметричной линии с оконечным резистором на каждом конце шины. В этой конфигурации доминирующее состояние утверждается одним или несколькими передатчиками, переключающими CAN− на подачу 0 В и (одновременно) переключающими CAN + на напряжение шины +5 В, тем самым формируя путь тока через резисторы, замыкающие шину. Таким образом, согласующие резисторы являются важным компонентом системы сигнализации и включены не только для ограничения отражения волн на высокой частоте.

Во время рецессивного состояния сигнальные линии и резистор (-ы) остаются в состоянии высокого импеданса по отношению к обеим рельсам. Напряжения на CAN + и CAN− имеют тенденцию (слабо) к напряжению на полпути между шинами. Рецессивное состояние присутствует на шине только тогда, когда ни один из передатчиков на шине не заявляет о доминантном состоянии.

Во время доминирующего состояния сигнальные линии и резистор (ы) переходят в состояние с низким импедансом по отношению к шинам, так что ток течет через резистор. Напряжение CAN + стремится к +5 В, а CAN− стремится к 0 В.

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

Эта стратегия передачи сигналов значительно отличается от других технологий передачи симметричных линий, таких как RS-422 /3, RS-485 и т. Д., В которых используются драйверы / приемники дифференциальной линии и используется система сигнализации, основанная на напряжении дифференциального режима симметричной линии, пересекающей условное расстояние. 0 В. Множественный доступ в таких системах обычно зависит от среды, поддерживающей три состояния (активный высокий, активный низкий и неактивный трехсостояний), и обрабатывается во временной области. Множественный доступ к шине CAN достигается за счет того, что электрическая логика системы поддерживает только два состояния, которые концептуально аналогичны сети «проводное И».

Сеть CAN может быть настроена для работы с двумя разными форматами сообщений (или «фреймов»): стандартным или базовым форматом фрейма (описанным в CAN 2.0 A и CAN 2.0 B) и расширенным форматом фрейма (описанным только в CAN 2.0 B. ). Единственное различие между двумя форматами состоит в том, что «базовый кадр CAN» поддерживает длину идентификатора 11 бит, а «расширенный кадр CAN» поддерживает длину 29 бит для идентификатора, состоящего из 11-битного идентификатора. («базовый идентификатор») и 18-битное расширение («расширение идентификатора»). Различие между форматом базового кадра CAN и расширенным форматом кадра CAN проводится с помощью бита IDE, который передается как доминирующий в случае 11-битного кадра и передается как рецессивный в случае 29-битного кадра. Контроллеры CAN, поддерживающие сообщения расширенного формата кадра, также могут отправлять и получать сообщения в формате основного кадра CAN. Все кадры начинаются с бита начала кадра (SOF), который обозначает начало передачи кадра.

CAN имеет четыре типа кадров:

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

Фрейм данных

Фрейм данных — единственный фрейм для фактической передачи данных. Есть два формата сообщений:

Формат базового кадра: с 11 битами идентификатора
Расширенный формат кадра: с 29 битами идентификатора

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

Базовый формат кадра

Формат кадра следующий: Битовые значения описаны для сигнала CAN-LO.

Имя поля	Длина (бит)	Цель
Начало кадра	1	Обозначает начало передачи кадра
Идентификатор (зеленый)	11	(Уникальный) идентификатор, который также представляет приоритет сообщения.
Немного материала	1	Немного противоположной полярности для поддержания синхронизации; см. Битовую начинку ниже
Запрос удаленной передачи (RTR) (синий)	1	Должен быть доминирующим (0) для фреймов данных и рецессивным (1) для фреймов удаленного запроса (см. Удаленный фрейм ниже)
Бит расширения идентификатора (IDE)	1	Должен быть доминирующим (0) для формата базового кадра с 11-битными идентификаторами
Зарезервированный бит (r0)	1	Зарезервированный бит. Должен быть доминантным (0), но приниматься либо как доминантный, либо как рецессивный.
Код длины данных (DLC) (желтый)	4	Количество байтов данных (0–8 байтов) [a]
Поле данных (красный)	0–64 (0-8 байтов)	Данные для передачи (длина в байтах определяется полем DLC)
CRC	15	Циклическая проверка избыточности
CRC-разделитель	1	Должен быть рецессивным (1)
Слот ACK	1	Передатчик отправляет рецессивный (1), и любой получатель может утверждать доминантный (0)
ACK-разделитель	1	Должен быть рецессивным (1)
Конец кадра (EOF)	7	Должен быть рецессивным (1)
Межкадровый интервал (IFS)	3	Должен быть рецессивным (1)

^ Физически возможно передать значение от 9 до 15 в 4-битном DLC, хотя размер данных по-прежнему ограничен восемью байтами. Некоторые контроллеры позволяют передавать или принимать DLC больше восьми, но фактическая длина данных всегда ограничена восемью байтами.

Расширенный формат кадра

Формат кадра следующий:

Имя поля	Длина (бит)	Цель
Начало кадра	1	Обозначает начало передачи кадра
Идентификатор A (зеленый)	11	Первая часть (уникального) идентификатора, которая также представляет приоритет сообщения
Заменить удаленный запрос (SRR)	1	Должен быть рецессивным (1)
Бит расширения идентификатора (IDE)	1	Должен быть рецессивным (1) для расширенного формата кадра с 29-битными идентификаторами
Идентификатор B (зеленый)	18	Вторая часть (уникального) идентификатора, которая также представляет приоритет сообщения
Запрос удаленной передачи (RTR) (синий)	1	Должен быть доминирующим (0) для фреймов данных и рецессивным (1) для фреймов удаленного запроса (см. Удаленный фрейм ниже)
Зарезервированные биты (r1, r0)	2	Зарезервированные биты, которые должны быть установлены как доминантные (0), но принимаются как доминантные или рецессивные
Код длины данных (DLC) (желтый)	4	Количество байтов данных (0–8 байтов) [a]
Поле данных (красный)	0–64 (0-8 байтов)	Данные для передачи (длина определяется полем DLC)
CRC	15	Циклическая проверка избыточности
CRC-разделитель	1	Должен быть рецессивным (1)
Слот ACK	1	Передатчик отправляет рецессивный (1), и любой получатель может утверждать доминантный (0)
ACK-разделитель	1	Должен быть рецессивным (1)
Конец кадра (EOF)	7	Должен быть рецессивным (1)

^ Физически возможно передать значение от 9 до 15 в 4-битном DLC, хотя размер данных по-прежнему ограничен восемью байтами. Некоторые контроллеры позволяют передавать или принимать DLC больше восьми, но фактическая длина данных всегда ограничена восемью байтами.

Два поля идентификатора (A и B) вместе образуют 29-битный идентификатор.

Удаленная рамка

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

RTR = 0; ДОМИНАНТ в фрейме данных RTR = 1; РЕЦЕССИВ в удаленном кадре

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

Кадр ошибки

Кадр ошибки состоит из двух разных полей:

Первое поле задается наложением ФЛАГОВ ОШИБОК (6–12 доминирующих / рецессивных битов), поступающих от разных станций.
Следующее второе поле — это РАЗДЕЛИТЕЛЬ ОШИБОК (8 рецессивных битов).

Есть два типа флагов ошибок:

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

В CAN есть два счетчика ошибок:

Когда TEC или REC больше 127 и меньше 255, по шине будет передан кадр пассивной ошибки.
Когда TEC и REC меньше 128, по шине будет передан кадр активной ошибки.
Когда TEC больше 255, узел переходит в состояние отключения шины, в котором кадры не передаются.

Рамка перегрузки

Кадр перегрузки содержит два битовых поля «Флаг перегрузки» и «Ограничитель перегрузки». Есть два типа условий перегрузки, которые могут привести к передаче флага перегрузки:

Внутренние условия приемника, требующие задержки следующего кадра данных или удаленного кадра.
Обнаружение доминирующего бита во время антракта.

Начало кадра перегрузки из-за случая 1 разрешается начинать только в первый битовый момент ожидаемого перерыва, тогда как кадры перегрузки из-за случая 2 начинаются через один бит после обнаружения доминирующего бита. Флаг перегрузки состоит из шести доминирующих битов. Общая форма соответствует форме активного флага ошибки. Форма флага перегрузки разрушает фиксированную форму поля перерыва. Как следствие, все другие станции также обнаруживают состояние перегрузки и со своей стороны начинают передачу флага перегрузки. Ограничитель перегрузки состоит из восьми рецессивных битов. Разделитель перегрузки имеет ту же форму, что и разделитель ошибок.

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

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

Кадры данных и удаленные кадры отделены от предыдущих кадров битовым полем, называемым межкадровым пространством. Межкадровое пространство состоит как минимум из трех последовательных рецессивных (1) битов. После этого, если обнаруживается доминирующий бит, он будет рассматриваться как бит «Начало кадра» следующего кадра. Кадрам перегрузки и кадрам ошибок не предшествует межкадровое пространство, и несколько кадров перегрузки не разделяются межкадровым пространством. Межкадровое пространство содержит битовые поля прерывания и ожидания шины и приостановки передачи для пассивных по ошибке станций, которые были передатчиками предыдущего сообщения. [15]

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

Заполняются все поля кадра, за исключением разделителя CRC, поля ACK и конца кадра, которые имеют фиксированный размер и не заполняются. В полях, где используется вставка битов, шесть последовательных битов одной полярности (111111 или 000000) считаются ошибкой. Флаг активной ошибки может быть передан узлом при обнаружении ошибки. Флаг активной ошибки состоит из шести последовательных доминирующих битов и нарушает правило вставки битов.

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

который набивается как (биты набиты жирным шрифтом):

11111 0 0000 1 1111 0 0000 1 .

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

Размер базовой рамы ограничен

тип кадра	перед начинкой	после фарша	биты набивки	общая длина кадра
опорная рама	8 п + 44 год	8 п + 44 год + ⌊ 34 + 8 п — 1 4 ⌋ < displaystyle 8n + 44 + left lfloor < frac <34 + 8n-1><4>> right rfloor>	≤ 24	≤ 134
расширенная рама	8 п + 64	8 п + 64 + ⌊ 54 + 8 п — 1 4 ⌋ < displaystyle 8n + 64 + left lfloor < frac <54 + 8n-1><4>> right rfloor>	≤ 29	≤ 152

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

Серия ISO 11898 определяет физический уровень и уровень передачи данных (уровни 1 и 2 модели ISO / OSI ) категории последовательной связи, называемой сетью контроллеров, которая поддерживает распределенное управление в реальном времени и мультиплексирование для использования в дорожных транспортных средствах. [16]

Существует несколько физических уровней CAN и других стандартов:

ISO 11898-1: 2015 определяет уровень канала передачи данных (DLL) и физическую сигнализацию сети контроллера (CAN) . [17] Этот документ описывает общую архитектуру CAN с точки зрения иерархических уровней в соответствии с эталонной моделью ISO для взаимодействия открытых систем (OSI), установленной в ISO / IEC 7498-1, и предоставляет характеристики для настройки обмена цифровой информацией между модули, реализующие CAN DLL с подробной спецификацией подуровня управления логическим каналом (LLC) и подуровня управления доступом к среде (MAC) .

ISO 11898-2: 2016 определяет высокоскоростной (скорость передачи до 1 Мбит / с) блок доступа к среде (MAU) и некоторые функции зависимого от среды интерфейса (MDI) (согласно ISO 8802-3), которые включают физический уровень сети контроллера. ISO 11898-2 использует двухпроводную симметричную схему сигнализации. Это наиболее часто используемый физический уровень в приложениях для силовых агрегатов транспортных средств и промышленных сетях управления.

ISO 11898-3: 2006 определяет низкоскоростной, отказоустойчивый, зависимый от среды интерфейс для настройки обмена цифровой информацией между электронными блоками управления дорожных транспортных средств, оборудованных CAN, со скоростью передачи от 40 кбит / с до 125 кбит. / с.

ISO 11898-4: 2004 определяет синхронизируемую по времени связь в CAN (TTCAN). Он применим для настройки синхронизированного по времени обмена цифровой информацией между электронными блоками управления (ЭБУ) дорожных транспортных средств, оснащенных CAN, и определяет объект кадровой синхронизации, который координирует работу как логической связи, так и средств управления доступом к среде в соответствии с ISO. 11898-1, чтобы обеспечить расписание связи по времени.

ISO 11898-5: 2007 определяет физический уровень CAN для скорости передачи до 1 Мбит / с для использования в дорожных транспортных средствах. В нем описаны функции устройства доступа к среде, а также некоторые функции интерфейса, зависящие от среды, в соответствии с ISO 8802-2. Это представляет собой расширение ISO 11898-2, касающееся новых функций для систем, требующих функций с низким энергопотреблением при отсутствии активной связи по шине.

ISO 11898-6: 2013 определяет физический уровень CAN для скорости передачи до 1 Мбит / с для использования в дорожных транспортных средствах. В нем описаны функции устройства доступа к среде, а также некоторые функции интерфейса, зависящие от среды, в соответствии с ISO 8802-2. Это представляет собой расширение ISO 11898-2 и ISO 11898-5, определяющее механизм выборочного пробуждения с использованием настраиваемых кадров CAN.

ISO 16845-1: 2016 предоставляет методологию и набор абстрактных тестов, необходимых для проверки соответствия любой реализации CAN CAN, указанной в ISO 11898-1.

ISO 16845-2: 2018 устанавливает тестовые примеры и требования к тестированию для реализации плана тестирования, проверяющего, соответствует ли трансивер CAN с реализованными функциями выборочного пробуждения указанным функциям. Тип тестирования, определенный в ISO 16845-2: 2018, называется тестированием на соответствие.

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

CAN in Automation (CiA) — это международная организация пользователей и производителей, которая разрабатывает и поддерживает протоколы более высокого уровня на основе CAN и их международную стандартизацию. [18] Среди этих спецификаций:

Стандартизированные подходы

ARINC 812 или ARINC 825 (авиационная промышленность) — CiA 301 / 302-2 и EN 50325-4 (промышленная автоматизация ) (использование CANopen в рельсовых транспортных средствах) (промышленная автоматизация ) — CiA 454 и IEC 61851 -3 (связь между аккумулятором и зарядным устройством)
ISOBUS — ISO 11783 (сельское хозяйство) — ISO 15765-2 (транспортный протокол для автомобильной диагностики) (военные автомобили) — IEC 61162-3 (морская промышленность) (автомобильная сеть для автобусов и грузовиков)
SAE J2284 (автомобильные сети для легковых автомобилей) (UDS) — ISO 14229 (автомобильная диагностика)
LeisureCAN — открытый стандарт для индустрии развлечений и автомобилей

Другие подходы

CAN Kingdom — Kvaser (встроенная система управления)
CCP / XCP (автомобильная калибровка ЭБУ) — General Motors (для General Motors ) — RVIA (используется для транспортных средств для отдыха) — Pilz (используется для промышленной автоматизации ) (аэрокосмическая промышленность и робототехника) (космический протокол CubeSat) (Very Simple Control Protocol) — бесплатный протокол автоматизации, подходящий для всех видов задач автоматизации.

CANopen Special Interest Group (SIG) «Lift Control», основанная в 2001 году, разрабатывает профиль приложения CANopen CiA 417 для систем управления лифтами. Он работает над расширением функций, улучшает техническое содержание и обеспечивает соблюдение действующих правовых стандартов для систем управления лифтами. Первая версия CiA 417 была опубликована (доступна для членов CiA) летом 2003 года, версия 2.0 — в феврале 2010 года, версия 2.1.0 — в июле 2012 года, версия 2.2.0 — в декабре 2015 года и версия 2.3.1 — в феврале 2020 года.

Йорг Хельмих (ELFIN GmbH) является председателем этого SIG и руководит вики-страницей сообщества лифтов CANopen с материалами о лифтах CANopen.

CAN — это протокол низкого уровня, который внутренне не поддерживает никаких функций безопасности. В стандартных реализациях CAN также отсутствует шифрование, что оставляет эти сети открытыми для перехвата кадра «злоумышленник в середине». В большинстве реализаций ожидается, что приложения будут развертывать свои собственные механизмы безопасности; например, для аутентификации входящих команд или наличия определенных устройств в сети. Невыполнение адекватных мер безопасности может привести к разного рода атакам, если противнику удастся вставить сообщения в шину. [19] Хотя существуют пароли для некоторых критически важных для безопасности функций, таких как изменение прошивки, программирование ключей или управление приводами антиблокировочного тормоза, эти системы не применяются повсеместно и имеют ограниченное количество пар начальное значение / ключ.

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

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

Библиотека python-can обеспечивает как пассивный мониторинг , так и активный контроль доступа к CAN-шине на широком спектре платформ.

Компания Bosch владеет патентами на эту технологию, однако срок действия патентов, относящихся к исходному протоколу, истек. Производители CAN-совместимых микропроцессоров платят Bosch лицензионные сборы за использование товарного знака CAN и любых новых патентов, связанных с CAN FD, и они обычно передаются заказчику в цене чипа. Производители продуктов с настраиваемыми ASIC или FPGA, содержащими CAN-совместимые модули, должны вносить плату за лицензию на протокол CAN, если они хотят использовать торговую марку CAN или возможности CAN FD. [20]

Источник http://can.marathon.ru/page/can-protocols/canbus/canintro

Источник https://avtomirkrasnodara.ru/promyshlennoye-oborudovaniye-dlya-can-setey/

Источник https://hmong.ru/wiki/Controller_area_network