CANopen

CANopen - это протокол связи и спецификация профиля устройства для встроенных систем, используемых в автоматизации . Что касается модели OSI , CANopen реализует вышеперечисленные уровни, включая сетевой уровень . Стандарт CANopen состоит из схемы адресации, нескольких небольших протоколов связи и прикладного уровня, определяемого профилем устройства. Коммуникационные протоколы поддерживают управление сетью, мониторинг устройств и связь между узлами, включая простой транспортный уровень для сегментации / десегментации сообщений. Протокол нижнего уровня, реализующий канал передачи данных ифизическим уровнем обычно является сеть контроллеров (CAN), хотя устройства, использующие другие средства связи (например, Ethernet Powerlink , EtherCAT ), также могут реализовать профиль устройства CANopen.

Базовое устройство CANopen и коммуникационные профили приведены в спецификации CiA 301, выпущенной CAN in Automation . ^[1] Профили для более специализированных устройств построены на основе этого базового профиля и указаны во многих других стандартах, выпущенных CAN в автоматизации, таких как CiA 401 ^[2] для модулей ввода / вывода и CiA 402 ^[3] для управления движением.

Модель устройства [ править ]

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

• Блок связи реализует протоколы для обмена сообщениями с другими узлами в сети.
• Запуск и сброс устройства управляется конечным автоматом . Он должен содержать состояния Инициализация, Предварительная эксплуатация, Работа и Остановлено. Переходы между состояниями выполняются путем передачи устройству объекта связи сетевого управления (NMT).
• Объект словаря является массивом переменных с 16-битовым индексом. Кроме того, каждая переменная может иметь 8-битный субиндекс. Переменные могут использоваться для настройки устройства и отражения его окружения, т. Е. Содержать данные измерений.
• Приложение часть устройства фактически выполняет требуемую функцию устройства, после того, как конечный автомат установлен в рабочем состоянии. Приложение настраивается с помощью переменных в словаре объектов, а данные отправляются и принимаются через уровень связи.

Словарь объектов [ править ]

Устройства CANopen должны иметь словарь объектов, который используется для настройки и связи с устройством. Запись в объектном словаре определяется:

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

Основные типы данных для значений словаря объектов , таких как логические значения , целые числа и поплавки определены в стандарте (их размер в битах необязательно хранится в определении соответствующего типа, диапазона индекса 0x0001-0x001F), а также композитные типы данных , такие как строки, массивы и записи (определенные в диапазоне индексов 0x0040–0x025F). Составные типы данных могут быть субиндексированы 8-битным индексом; значение в субиндексе 0 массива или записи указывает количество элементов в структуре данных и имеет тип UNSIGNED8.

Например, параметры связи устройства, стандартизированные в базовом профиле устройства CiA 301 ^[4] , отображаются в диапазоне индексов 0x1000–0x1FFF («область профиля связи»). Первые несколько записей в этой области следующие:

При наличии подходящих инструментов содержимое объектного словаря устройства на основе электронной таблицы данных (EDS) можно настроить в файл конфигурации устройства (DCF) для интеграции устройства в конкретную сеть CANopen. Согласно CiA 306 ^[5] формат файла EDS - это формат файла INI . В ближайшее время появится формат в стиле XML, описанный в CiA 311 ^[6] .

Связь [ править ]

Коммуникационные объекты [ править ]

Шина CAN , канальный уровень CANopen, может передавать только короткие пакеты, состоящие из 11-битного идентификатора, бита запроса удаленной передачи (RTR) и от 0 до 8 байтов данных. Стандарт CANopen делит 11-битный идентификатор кадра CAN на 4-битный код функции и 7-битный идентификатор узла CANopen. Это ограничивает количество устройств в сети CANopen до 127 (0 зарезервировано для широковещательной передачи). Расширение стандарта шины CAN (CAN 2.0 B) позволяет использовать расширенные идентификаторы кадров длиной 29 бит, но на практике сети CANopen, достаточно большие, чтобы требовать расширенного диапазона идентификаторов, встречаются редко.

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

Содержимое CANopen кадра:

Кадр данных с 11-битным идентификатором также называется «форматом основного кадра».

Отображение CAN-ID по умолчанию сортирует кадры, присваивая код функции (NMT, SYNC, EMCY, PDO, SDO ...) первым 4 битам, так что критически важные функции получают приоритет. Однако это сопоставление можно настроить для специальных целей (за исключением NMT и SDO, необходимых для базовой связи).

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

Предопределенный набор подключений ^[7] [ править ]

Для простых сетевых структур CANopen поддерживает заранее заданное распределение идентификаторов сообщений.

Коммуникационные модели [ править ]

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

В отношениях ведущий / ведомый один узел CANopen назначается ведущим, который отправляет или запрашивает данные от ведомых устройств. Протокол NMT является примером модели связи ведущий / ведомый.

Клиент / сервер отношение реализовано в протоколе SDO, где клиент СДО посылает данные (индекс словаря объекта и субиндекс) на сервер SDO, который отвечает один или несколько СДО упаковки , содержащие запрашиваемые данные (содержание словаря объектов по данному индексу).

Модель производитель / потребитель используется в протоколах Heartbeat и Node Guarding. В модели выталкивания производителя / потребителя производитель отправляет данные потребителю без специального запроса, тогда как в модели выталкивания потребитель должен запрашивать данные у производителя.

Протоколы [ править ]

Протоколы управления сетью (NMT) [ править ]

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

Протокол управления модулем используется мастером NMT для изменения состояния устройств. COB-ID CAN-кадра этого протокола всегда равен 0, что означает, что он имеет код функции 0 и идентификатор узла 0, что означает, что каждый узел в сети будет обрабатывать это сообщение. Фактический идентификатор узла, для которого предназначена команда, дается в части данных сообщения (во втором байте). Это также может быть 0, что означает, что все устройства на шине должны перейти в указанное состояние.

Протокол Heartbeat используется для мониторинга узлов в сети и проверки их работоспособности. Производитель пульса (обычно подчиненное устройство) периодически отправляет сообщение с двоичным функциональным кодом 1110 и своим идентификатором узла (COB-ID19 = 0x700 + идентификатор узла). Часть кадра с данными содержит байт, указывающий состояние узла. Потребитель тактового сигнала читает эти сообщения. Если сообщения не приходят в течение определенного периода времени (определенного в объектном словаре устройств), потребитель может предпринять действия, например, сбросить устройство или указать ошибку. Формат кадра:

Устройства CANopen должны автоматически переходить из состояния Initializing в Pre-Operational во время загрузки. Когда этот переход выполняется, на шину отправляется одно контрольное сообщение. Это протокол загрузки .

Протокол типа ответа / ответа (модель вытягивания), называемый охраной узла, существует для ведомого мониторинга.

Протокол объекта служебных данных (SDO) [ править ]

Протокол SDO используется для настройки и чтения значений из объектного словаря удаленного устройства. Устройство, к объектному словарю которого осуществляется доступ, является сервером SDO, а устройство, обращающимся к удаленному устройству, является клиентом SDO. Связь всегда инициируется SDO-клиентом. В терминологии CANopen связь просматривается с сервера SDO, так что чтение из объектного словаря приводит к загрузке SDO, а запись в статью словаря - это загрузка SDO.

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

COB-ID соответствующих сообщений передачи SDO от клиента к серверу и от сервера к клиенту могут быть установлены в словаре объектов. В объектном словаре можно настроить до 128 серверов SDO по адресам 0x1200 - 0x127F. Аналогичным образом, клиентские соединения SDO устройства можно настроить с помощью переменных 0x1280 - 0x12FF. Однако предопределенный набор соединений определяет канал SDO, который можно использовать даже сразу после загрузки (в предоперационном состоянии) для настройки устройства. COB-ID этого канала: 0x600 + идентификатор узла для приема и 0x580 + идентификатор узла для передачи.

Чтобы инициировать загрузку, SDO-клиент отправляет следующие данные в CAN-сообщении с COB-ID «приема» SDO-канала.

• ccs - это спецификатор клиентской команды для передачи SDO, это 0 для загрузки сегмента SDO, 1 для инициирования загрузки, 2 для инициирования загрузки, 3 для загрузки сегмента SDO, 4 для прерывания передачи SDO, 5 для загрузки блока SDO и 6 для SDO блочная загрузка
• n - количество байтов в части данных сообщения, которые не содержат данных, допустимо, только если установлены e и s
• e , если он установлен, указывает на ускоренную передачу, т. е. все данные, которыми обмениваются, содержатся в сообщении. Если этот бит сброшен, сообщение представляет собой сегментированную передачу, в которой данные не помещаются в одно сообщение и используются несколько сообщений.
• s , если установлено, указывает, что размер данных указан в n (если установлен e) или в части данных сообщения
• index - это индекс объектного словаря данных, к которым нужно получить доступ
• субиндекс - это субиндекс переменной объектного словаря
• data содержит данные, которые должны быть загружены в случае ускоренной передачи (e установлено), или размер данных, которые должны быть загружены (s установлен, e не установлен)

Протокол объекта данных процесса (PDO) [ редактировать ]

Протокол объекта данных процесса используется для обработки данных в реальном времени между различными узлами. Вы можете передавать до 8 байтов (64 бита) данных на один PDO с устройства или на устройство. Один PDO может содержать несколько записей словаря объектов, а объекты в одном PDO настраиваются с помощью сопоставления и записей словаря объектов параметров.

Есть два типа PDO: передаваемые и принимающие PDO (TPDO и RPDO). Первый предназначен для данных, поступающих с устройства (устройство является производителем данных), а второй - для данных, поступающих на устройство (устройство является потребителем данных); то есть с помощью RPDO вы можете отправлять данные на устройство, а с помощью TPDO вы можете читать данные с устройства. В предопределенном наборе соединений есть идентификаторы для четырех TPDO и четырех доступных RPDO. В конфигурации возможно 512 PDO.

PDO можно отправлять синхронно или асинхронно. Синхронные PDO отправляются после сообщения SYNC, тогда как асинхронные сообщения отправляются после внутреннего или внешнего триггера. Например, вы можете сделать запрос к устройству на передачу TPDO, который содержит необходимые данные, отправив пустой TPDO с флагом RTR (если устройство настроено для приема запросов TPDO).

С помощью RPDO вы можете, например, запускать два устройства одновременно. Вам нужно только сопоставить один и тот же RPDO на двух или более разных устройствах и убедиться, что эти RPDO сопоставлены с одним и тем же COB-ID.

Протокол объекта синхронизации (SYNC) [ править ]

Sync-Producer предоставляет сигнал синхронизации для Sync-Consumer. Когда Sync-Consumer получает сигнал, он начинает выполнять свои синхронные задачи.

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

Идентификатор объекта синхронизации доступен по индексу 1005h.

Протокол объекта отметки времени (TIME) [ править ]

Обычно объект Time-Stamp представляет время в виде 6-байтового поля: счетчик миллисекунд после полуночи (максимум 27 бит, хранится в 32-битном поле) и 16-битное количество дней без знака с 1 января, 1984. (Это произойдет 7 июня 2163 года.)

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

Отметка времени с высоким разрешением кодируется как unsigned32 с разрешением 1 микросекунда, что означает, что счетчик времени перезапускается каждые 72 минуты. Он настраивается путем отображения метки времени высокого разрешения (объект 1013h) в PDO.

Протокол аварийного объекта (EMCY) [ править ]

Экстренные сообщения инициируются возникновением ситуации внутренней фатальной ошибки устройства и передаются с соответствующего прикладного устройства на другие устройства с высоким приоритетом. Это делает их подходящими для предупреждений об ошибках типа прерывания. Экстренная телеграмма может быть отправлена ​​только один раз на «событие ошибки», т. Е. Экстренные сообщения не должны повторяться. До тех пор, пока на устройстве не возникает новых ошибок, дальнейшее экстренное сообщение не отправляется. С помощью профиля связи CANopen определены коды аварийных ошибок, регистр ошибок и дополнительная информация, относящаяся к устройству, указывается в профилях устройства.

Инициализация [ править ]

Пример трассировки связи между главным устройством и двумя подчиненными датчиками давления, настроенными для идентификатора 1 и идентификатора узла 2.

Электронная таблица данных [ править ]

Электронная таблица данных (EDS) - это формат файла, определенный в CiA306, который описывает поведение связи и записи словаря объектов устройства. Это позволяет таким инструментам, как сервисные инструменты, инструменты конфигурации, инструменты разработки и другие, правильно обращаться с устройствами.

Эти файлы EDS являются обязательными для прохождения теста на соответствие CiA CANopen.

С конца 2007 года в CiA311 определен новый формат на основе XML , называемый XDD. XDD соответствует стандарту ISO 15745.

Глоссарий терминов CANopen [ править ]

• PDO : объект данных процесса - входы и выходы. Значения типа частота вращения, напряжение, частота, электрический ток и т. Д.
• SDO : Service Data Object - Параметры конфигурации, возможно, идентификатор узла, скорость передачи, смещение, усиление и т. Д.
• COB-ID : идентификатор объекта связи.
• CAN ID : идентификатор CAN. Это 11-битный идентификатор сообщения CAN, который находится в начале каждого сообщения CAN на шине.
• EDS : Электронный лист данных. Это файл в формате INI или XML.
• DCF : файл конфигурации устройства. Это модифицированный файл EDS с настройками идентификатора узла и скорости передачи.

См. Также [ править ]

• Контроллерная сеть - это статья о CAN-шине.
• J1939
• DeviceNet
• IEEE 1451
• TransducerML

Ссылки [ править ]

1. ^ CiA 301 Спецификация прикладного уровня CANopen, которую можно бесплатно загрузить сCAN в автоматизации
2. ^ Спецификация CiA 306 CANopen Electronic Data Sheet (EDS)
3. ^ CiA 311 Спецификация CANopen XML-EDS
4. ^ Предопределенный набор соединений из CANopen Basics[8]
5. ^ CiA 401 Спецификация профиля устройства CANopen для универсальных модулей ввода / вывода, которую можно бесплатно загрузить сCAN в автоматизации
6. ^ CiA 402 Профиль устройства CANopen для контроллеров движения и приводов (такой же, как IEC 61800-7-201 / 301)

Внешние ссылки [ править ]

• CANopen Origins - Esprit project ASPIC 1993 (Bosch, Университет Ньюкасла, Университет прикладных наук в Ройтлингене)
• О CANopen (canopensolutions.com)
• Использование идентификатора в сетях CANopen
• CanFestival - многоплатформенная среда CANopen с открытым исходным кодом.
• CanOpenNode - фреймворк CANopen с открытым исходным кодом для микроконтроллеров и Linux
• Lely CANopen - библиотека CANopen с открытым исходным кодом для ведущих и ведомых устройств
• openCANopen - мастер CANopen с открытым исходным кодом
• CANopen Stack Project - гибкий стек CANopen с открытым исходным кодом для микроконтроллера
• CANopen для Python
• Информационный бюллетень CAN - Информация о CAN, CANopen и J1939
• Образовательные страницы CANopen
• Введение в основы CANopen (на сайте www.canopen-solutions.com)
• Вики сообщества CANopen-Lift
• CANeds: бесплатный редактор файлов EDA и XDD
• Информация CAN для промышленности
• Онлайн-портал CAN in Automation
• CANopen - прикладной уровень и общий коммуникационный профиль
• CANopen - простое введение (включая конвертер идентификаторов COB)