Введение

Компьютерный сетевой протокол CANopen — это стек протоколов и спецификация профиля устройства для встраиваемых систем, используемых в автоматизации. С точки зрения модели OSI, CANopen реализует уровни, начиная с сетевого. Стандарт CANopen включает в себя схему адресации, несколько небольших протоколов связи и прикладной уровень, определяемый профилем устройства. Протоколы связи обеспечивают управление сетью, мониторинг устройств и обмен данными между узлами, включая простой транспортный уровень для сегментации и десегментации сообщений. Протокол более низкого уровня, реализующий канальный и физический уровни, обычно является Controller Area Network (CAN), хотя устройства, использующие другие средства связи (например, Ethernet Powerlink, EtherCAT), также могут реализовывать профиль устройства CANopen. Базовые профили устройства и связи CANopen приведены в спецификации CiA 301, выпущенной CAN in Automation. Профили для более специализированных устройств создаются на основе этого базового профиля и определены в многочисленных других стандартах, выпущенных CAN in Automation, таких как CiA 401 для модулей ввода-вывода и CiA 402 для управления движением.

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

Каждое устройство CANopen должно реализовывать определенные стандартные функции в своем управляющем программном обеспечении. Коммуникационный модуль реализует протоколы для обмена сообщениями с другими узлами в сети. Запуск и сброс устройства контролируются с помощью конечного автомата. Он должен содержать состояния Initialization, Pre-operational, Operational и Stopped. Переходы между состояниями осуществляются путем отправки объекта управления сетью (NMT) устройству. Объектный словарь представляет собой массив переменных с 16-битным индексом. Кроме того, каждая переменная может иметь 8-битный подиндекс. Переменные могут использоваться для конфигурирования устройства и отражения его состояния, то есть содержать данные измерений. Прикладная часть устройства фактически выполняет требуемую функцию устройства после перевода конечного автомата в оперативное состояние. Приложение конфигурируется переменными в объектном словаре, а данные передаются и принимаются через коммуникационный уровень.

Установка подключения

Для простых сетевых структур CANopen поддерживает предопределенное распределение идентификаторов сообщений. Направления передачи и приема указаны с точки зрения устройства. Таким образом, запрос к устройству в сети отправит 0x600+nodeid и получит в ответ 0x580+nodeid.

Объект связи | COB ID (hex) | Ведомые узлы | Спецификация | Управление узлом NMT
------- | -------- | -------- | -------- | --------
000 | Только прием | CiA 301 | Глобальная команда аварийного отключения
001 | ? | CiA 304 | Летящий мастер
071-076 | ? | CiA 302 | Указание активного интерфейса
07F | ? | CiA 302 | Синхронизация
080 | Только прием | CiA 301 | Аварийная ситуация
080 + NodeID | Передача | CiA 301 | Временная метка
100 | Только прием | CiA 301 | Объекты данных, критичные для безопасности
101-180 | ? | CiA 301 | PDO
180 + NodeID | | |
200 + NodeID | | |
280 + NodeID | | |
300 + NodeID | | |
380 + NodeID | | |
400 + NodeID | | |
480 + NodeID | | |
500 + NodeID | | |
1. Передача PDO1
2. Прием PDO2
3. Передача PDO3
4. Прием PDO4
5. Передача PDO5
6. Прием PDO6
CiA 301 | SDO | 580 + NodeID / 600 + NodeID | Передача/Прием | CiA 301
Динамический запрос SDO | 6E0 | ? | CiA 302 | Процедура захвата узла
6E1-6E3 | ? | CiA 416 | Процедура захвата узла
6F0-6FF | ? | CiA 416 | Мониторинг узлов NMT (защита узлов/heartbeat)
700 + NodeID | Передача | CiA 301 | LSS
7E4/7E5 | Передача/Прием | CiA 305 |

Модели коммуникации

Различные модели связи используются при обмене сообщениями между узлами CANopen. В структуре "мастер/ведомый" один узел CANopen назначается мастером, который отправляет данные или запрашивает их у ведомых. Протокол NMT является примером модели связи "мастер/ведомый". Отношения "клиент/сервер" реализованы в протоколе SDO, где клиент SDO отправляет данные (индекс и подиндекс словаря объектов) серверу SDO, который отвечает одним или несколькими пакетами SDO, содержащими запрошенные данные (содержимое словаря объектов по указанному индексу). Модель "производитель/потребитель" используется в протоколах Heartbeat и Node Guarding. В модели "push" (выталкивания) производитель отправляет данные потребителю без конкретного запроса, в то время как в модели "pull" (втягивания) потребитель должен запрашивать данные у производителя.

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

Протокол Process Data Object используется для обработки данных в режиме реального времени между различными узлами. Можно передавать до 8 байт (64 бита) данных в одном ПЗО либо от устройства, либо к нему. Одно ПЗО может содержать несколько записей словаря объектов, а объекты внутри одного ПЗО конфигурируются с помощью записей словаря объектов отображения и параметров. Существуют два типа ПЗО: передающие и принимающие ПЗО (TPDO и RPDO). Первые предназначены для данных, поступающих от устройства (устройство является производителем данных), вторые – для данных, поступающих в устройство (устройство является потребителем данных); то есть с помощью RPDO можно отправлять данные в устройство, а с помощью TPDO – читать данные из устройства. В предварительно определенном наборе соединений доступны идентификаторы для четырех TPDO и четырех RPDO. При настройке возможно использование до 512 ПЗО. ПЗО могут передаваться синхронно или асинхронно. Синхронные ПЗО отправляются после сообщения SYNC, а асинхронные – после внутреннего или внешнего триггера. Например, можно запросить у устройства передачу TPDO, содержащего необходимые данные, отправив пустой TPDO с установленным флагом RTR (если устройство настроено на прием запросов TPDO). С помощью RPDO можно, например, одновременно запустить два устройства. Для этого достаточно отобразить один и тот же RPDO в двух или более различных устройствах и убедиться, что эти RPDO отображены с одним и тем же COB ID.

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

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

Протокол объекта временной метки (TIME)

Обычно объект "Time Stamp" представляет время в виде 6-байтового поля: счётчик миллисекунд после полуночи (максимум 27 бит, хранящийся в 32-битном поле) и неподписанное 16-битное число дней, прошедших с 1 января 1984 года. (Это значение достигнет максимального предела 7 июня 2163 года.) Некоторые приложения, критичные ко времени, особенно в больших сетях с низкой скоростью передачи данных, требуют очень точной синхронизации; может потребоваться синхронизировать локальные часы с точностью до микросекунд. Это достигается с помощью дополнительного протокола синхронизации высокого разрешения, который использует специальный формат сообщения временной метки для корректировки неизбежного расхождения локальных часов. Временная метка высокого разрешения кодируется как беззнаковое 32-битное число с разрешением 1 микросекунды, что означает, что счётчик времени перезапускается каждые 72 минуты. Настройка осуществляется путем сопоставления высокоразрешающей временной метки (объект 1013h) с PDO.

Протокол "Объект экстренной помощи" (EMCY)

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

Электронный лист данных

Электронный лист данных (EDS) — это формат файла, определённый в CiA306, который описывает характеристики обмена данными и записи словаря объектов устройства. Это позволяет таким средствам, как сервисные утилиты, инструменты настройки, средства разработки и другие, корректно работать с устройствами. Наличие этих файлов EDS обязательно для успешного прохождения теста на соответствие стандарту CiA CANopen. С конца 2007 года в CiA311 определён новый формат на основе XML, называемый XDD. XDD соответствует стандарту ISO 15745.