CANopen - Википедия - CANopen

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

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

Модель устройства

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

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

Словарь объектов

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

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

Базовый типы данных для значений словаря объектов, таких как булевы, целые числа и поплавки определены в стандарте (их размер в битах необязательно сохраняется в определении связанного типа, диапазон индексов 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 отправляет данные (индекс словаря объектов и субиндекс) на сервер SDO, который отвечает одним или несколькими пакетами SDO, содержащими запрошенные данные (содержимое словаря объектов по заданному индексу ).

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

Протоколы

Протоколы сетевого управления (NMT)

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

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

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

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

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

Протокол объекта служебных данных (SDO)

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

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

COB-ID соответствующих сообщений передачи SDO от клиента к серверу и от сервера к клиенту могут быть установлены в словаре объектов. В объектном словаре по адресам 0x1200 - 0x127F можно настроить до 128 серверов SDO. Точно так же клиентские соединения 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 заблокировать загрузку
• п - это количество байтов в части данных сообщения, которые не содержат данных, допустимо, только если установлены e и s
• е, если установлено, указывает на ускоренную передачу, т.е. все данные, которыми обмениваются, содержатся в сообщении. Если этот бит сброшен, сообщение представляет собой сегментированную передачу, в которой данные не помещаются в одно сообщение и используются несколько сообщений.
• s, если установлено, указывает, что размер данных указан в n (если установлено e) или в части данных сообщения
• индекс индекс объектного словаря данных, к которым нужно получить доступ
• субиндекс субиндекс переменной объектного словаря
• данные содержит данные, которые должны быть загружены в случае ускоренной передачи (e установлено), или размер данных, которые должны быть загружены (s установлен, e не установлен)

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

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

Есть два типа PDO: передаваемые и принимающие PDO (TPDO и RPDO). Первый предназначен для данных, поступающих с устройства (устройство является производителем данных), а второй - для данных, поступающих на устройство (устройство является потребителем данных); то есть с помощью RPDO вы можете отправлять данные на устройство, а с помощью TPDO вы можете читать данные с устройства. В предопределенном наборе соединений доступны идентификаторы для четырех (4) TPDO и четырех (4) 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 г. новый XML Формат на основе XDD определен в CiA311. XDD соответствует ISO стандарт 15745.

Глоссарий терминов CANopen

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

Смотрите также

• Сеть контроллеров это статья о CAN-шине.
• J1939
• DeviceNet
• IEEE 1451
• ПреобразовательML

Рекомендации

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 ID)