Сеть CANopen в эксперименте ATLAS CERN Печать
Добавил(а) microsin   

Необходим высокоуровневый протокол для того, чтобы определить использование 11 бит идентификатора шины CAN и 8 байт данных пакета среди разных узлов сегмента шины. Существует несколько стандартов, которые используют шину CAN. Организация CERN выбрала стандарт CANopen, поддерживаемый организацией CAN in Automation (CiA). Изначально этот стандарт был разработан из проекта EEC ESPRIT III, и получил свое применение в индустриальных приложениях автоматизации. Здесь приведен перевод статьи [1]. Все незнакомые термины и сокращений см. в разделе "Словарик" статьи [5].

[Модель слоев ISO/OSI и протокол CANopen]

Организация CANopen по отношению к модели взаимодействия ISO Open System Interconnect показана на рис. 1. Она состоит из устройства CANopen, работающего на верхнем уровне протокола, и аппаратных слоев, обслуживающих обмен данными по сети.

CANopen OSI Layers

Рис. 1. Схематический взгляд на стандарты CAN и CANopen в сетевой модели коммуникаций OSI.

Промежуточные слои не нужны, потому что прикладная сеть обычно состоит только из одного сегмента (отпадает необходимость в транспортном слое 3 и сетевом слое 4), нет понятия 'сессий' (слой 5) или нужды в различных внутренних 'представлениях' (слой 6).

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

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

Профили. Слой данных (data link layer), к которому относится контроллер CAN, удовлетворяет стандарту CAN 2.0A и/или 2.0B, в то время как физический слой (physical layer) описан стандартом ISO 11898. Слой данных и физический слой реализован аппаратно, подробности см. в [2].

CANopen использует концепцию профилей устройств (device profiles). Производители могут создавать стандартизованные устройства, соответствующие указаниям, содержащимся в CANopen device profile. Благодаря этому могут быть созданы сети устройств независимо производителей устройств CAN, без необходимости написания специализированного, какого-то особенного программного обеспечения для того, чтобы соединить устройства друг с другом в одну сеть. Базовое функционирование сети гарантируется определением обязательных характеристик устройства - узла сети. Можно реализовать дополнительные функции, чтобы помочь реализовать опциональную и зависящую от производителя часть профилей. Есть некоторое количество стандартных профилей, доступных из CiA, в том числе CiA-401 [3], который описывает модули I/O, и CiA-404 [4] для измерительных устройств и контроллеров обратной связи (closed loop controllers). Профили реализованы в стандартизованной базе данных, которая называется словарем объектов (object dictionary, сокращенно OD). Имеется программное обеспечение для чтения, конфигурирования и изменения записей в словаре устройства. OD не сохраняется в самом узле CANopen (хотя допускается наличие готового словаря в устройстве при включении его питания), он определяется так называемым описанием электронного устройства (Electronic Data Sheet, сокращенно EDS), так что мастер сети (главный узел, обслуживающий основное приложение сети) будет знать тип данных и размер каждого объекта.

Профиль обмена данными (communication profile) определяет, что в сети CANopen должно находится как минимум одно главное устройство, обслуживающее главное приложение сети и как минимум одно подчиненное устройство (подчиненных устройств может быть больше одного), выполняющее вспомогательные функции главного приложения (например, управление реле или оцифровка показаний датчиков). Мастер выполняет процесс загрузки (boot-up process), и проверяет состояние сети, поддерживая её в рабочем состоянии (operational state). Мастер также манипулирует элементами словаря объектов и идентификаторами CAN подключенных подчиненных устройств (эти действия не обязательны, поскольку может существовать заранее определенная конфигурация каждого узла сети). Communication profile определяет несколько методов для передачи и приема сообщений по сети CAN. Синхронные передачи данных позволяют осуществлять скоординированные по все сети операции по выборке данных или управления объектами. Синхронные передачи поддерживаются заранее определенными объектами обмена, например циклически, с определенным интервалом по времени передаются сообщения синхронизации и сообщения метки времени (time stamp messages). Могут быть асинхронно отправлены сообщения в любой момент времени (соответствующие каким-то событиям, event messages), что позволяет одному устройству немедленно оповещать другое устройство без ожидания появления момента синхронной передачи данных. Содержимое обоих типов сообщений - синхронных сообщений и сообщений события (так называемые объекты обрабатываемых данных, Process Data Objects, сокращенно PDO) может быть динамически сконфигурировано в момент запуска сети (network boot up), что осуществляется мастером сети с помощью системы управления сетью (Network Management, NMT). Хотя CAN ограничивает размер передаваемой информации 8 байтами, протокол CANopen поддерживает обмен блоками данных произвольной длины (в том числе больше 8 байт) с помощью протокола Service Data Objects (SDO). Подробное описание CANopen communication содержится в документе CiA DS 301 [2].

Суммарно стандарт коммуникации CANopen определяет 4 типа сообщений (объекта коммуникации):

• Сообщения администрирования сети Network Management (NMT), например для включения в работу и выключения подчиненного узла сети (сообщения с самым высоким приоритетом).
• Заранее определенные сообщения, такие как сообщения синхронизации с меткой времени (synchronisation time stamp) и сообщения об аварии (emergency messages).
• Сообщения для передачи обрабатываемых данных (Process data messages, объекты PDO) с заранее определенным идентификатором и длиной данных от 1 до 8 байт.
• Сервисные сообщения данных (Service Data Messages, объекты SDO), которые обычно передаются между узлами master и slave в виде группы сообщений CAN, с наличием подтверждения получения каждого сообщения (это сообщения с самым низким приоритетом).

[Минимальный набор функционала устройств]

Чтобы добиться упрощения работы с починенными узлами сети, профиль CiA 301 также задает минимально необходимую функциональность, которую должно предоставить устройство CANopen. Усилия по конфигурированию простых сетей могут быть уменьшены с применением обязательных идентификаторов, заданных по умолчанию. Эти идентификаторы доступны непосредственно после инициализации (если не были раньше сохранены какие-либо их модификации), и могут быть модифицированы посредством процедуры динамического распределения. Узлом должен поддерживаться только выбор идентификаторов. В сети CANopen может быть доступно до 127 узлов включительно. Последовательность запуска (boot up sequence) также упрощена, и устройство после своей загрузки попадает непосредственно в так называемое предварительное рабочее состояние (pre-operational state). Единственного сообщения от master достаточно, чтобы перевести slave-устройство в полнофункциональный (operational). Поддерживаемые идентификаторы CAN для устройства могут быть, например, статически выделены и заранее сконфигурированы с помощью DIP-переключателей (есть и другие методы конфигурирования, например протокол LSS). 11 бит стандартного идентификатора распределены с 4 старшими битами под код функции, и 7 остальными битами под идентификатор узла (node ID). Таблица 1 показывает предварительно заданный идентификатор для минимального подчиненного узла (slave node).

Таблица 1. Заранее определенный идентификатор для минимального функционала устройств CANopen.

Сообщение Код функции (bin) Результирующий идентификатор (hex) Коммуникационный индекс OD (hex) Индекс отображения OD (hex) Комментарий
NMT 0000b 0x000 - - Самый высокий приоритет
SYNC 0001b 0x080 (0x1005) -  
TIME STAMP 0010b 0x100 - -  
EMERGENCY 0001b 0x081..0x0FF - - Код DIP-переключателя + 0x080
PDO1 (tx) 0011b 0x181..0x1FF 0x1800 0x1A00 Код DIP-переключателя +0x180
PDO1 (rx) 0100b 0x201..0x27F 0x1400 0x1600 Код DIP-переключателя +0x200
PDO2 (tx) 0101b 0x281..0x2FF 0x1801 0x1601 Код DIP-переключателя +0x280
PDO2 (rx) 0110b 0x301..0x37F 0x1401 0x1601 Код DIP-переключателя +0x300
SDO (tx) сервер 1011b 0x581..0x5FF 0x1200 - Код DIP-переключателя +0x580
SDO (rx) клиент 1100b 0x601..0x67F 0x1280 - Код DIP-переключателя +0x600
Nodeguard 1110b 0x701..0x77F (0x100E) - Код DIP-переключателя +0x700

Примечание: код DIP-переключателя задает значение в диапазоне 0x01 .. 0x7E (127 узлов сети).

[Управление сетью в CANopen - инициализация и функционирование]

Для управления состоянием устройств сети используется так называемый протокол Network Management (NMT). В этом протоколе доступны следующие функции:

1. Динамическое или статическое распределение идентификаторов CAN для обмена SDO/PDO и служб обработки ошибок (error services).
2. Управление рабочими состояниями узла и режимами коммуникации для отдельных узлов или для нескольких узлов.
3. Периодический опрос устройств, чтобы определять узлы, которые больше не работают или функционируют некорректно.

По сконфигурированному идентификатору сначала идентифицируются узлы, подключенные к сети CANopen. Идентификатор узла сети может конфигурироваться установкой движков DIP-переключателей. Когда сеть инициализируется и загружается, мастер сети сначала устанавливает диалог индивидуально с каждым подчиненным устройством сети с помощью служб NMT. Как только этот диалог установлен, для узла выделены идентификаторы CAN для обмена сообщениями. Любая конфигурационная информация может быть загружена в устройство мастером сети с помощью объектов SDO. Это включает любую конфигурационную информацию для содержимого данных любого сообщения данных (PDO), которое может поддерживать устройство.

Чтобы определить, работают ли узлы сети, CANopen использует техники NMT lifeguarding с теми узлами, которые это поддерживают, и для опроса устройств используются CAN remote frame, в ответ на который устройство должно послать пакет с данными, подтверждающими функционирование. Могут быть также реализованы интервалы запрета / таймауты (inhibit time / timeout), чтобы по отсутствию ответа в определенный промежуток времени мастер мог определить, что какой-то узел перестал функционировать. Поддержка времени запрета (inhibit time) означает, что устройство не должно получать lifeguarding remote frame в течение определенного периода времени, что должно быть согласовано в момент загрузки мастером сети.

Службы NMT могут также использоваться для приведения всех устройств сети в определенные рабочие состояния, что может быть сделано в любой момент времени. Например, мастер сети может послать широковещательную команду (broadcast) сообщением входа в режим предварительного рабочего состояния Pre-Operational state (сообщение Enter_Preoperational_State), чтобы все узлы переключились в состояние, в котором конфигурационная информация может быть загружена в устройство с помощью сообщений SDO. Альтернативно один узел может быть помещен в Pre-Operational state (или режим конфигурации) тем же самым сообщением с другой информацией протокола, что оставляет все другие узлы полностью в рабочем состоянии (operational).

Реализация NMT. Каждый подчиненный узел содержит логическую машину из 4 состояний: (1) Initialisation (инициализация), (2) Pre-Operational (состояние предварительно рабочему, или состояние конфигурации), (3) Operational (рабочее состояние) и (4) Prepared (подготовлено). Есть 5 разных сообщений NMT, которые позволяют мастеру CANopen поменять состояние одного подчиненного узла или всех подчиненных узлов одновременно:

Start_Remote_Node
Stop_Remote_Node
Enter_Pre-Operational_State
Reset_Node
Reset_Communication

(1) Initialisation. При включении питания подчиненного устройства CANopen (с минимальной функциональностью boot-up) оно выполняет последовательность инициализации, и автоматически входит в состояние Pre-Operational.

(2) Pre-Operational. В этом состоянии узел выполняет следующие функции:

• Внутренний ввод / вывод (internal I/O function).
• Позволяет осуществлять обмен через канал SDO для конфигурирования, например для отображения объектов (переменных приложения) на PDO, конфигурирования параметров обмена.
• Поддержка протокола проверки работоспособности узла (Node guarding) и ответ на сообщения протокола node-guarding.

Состояние Pre-Operational может поменяться на Operational (Operational_State) командой Start_Remote_Node, Prepared (Prepared_State) командой Stop_Remote_Node, сброс узла (Reset) командами Reset_Node или Reset_Communication.

(3) Operational. Это рабочее состояние, в котором устройство выполняет следующие функции:

• Внутренний ввод / вывод (internal I/O function).
• Поддерживает активность своих каналов PDO (с синхронизацией, если это необходимо).
• Поддерживает активность своих каналов SDO.
• Отправляет сообщения аварии (emergency messages) при возникновении события ошибки (error event).

Состояние Operational может поменяться на Prepared (Prepared_State) командой Stop_Remote_Node, Pre-Operational (Pre-Operational_State) командой Enter_Pre-Operational_State, сброс узла (Reset) командами Reset_Node или Reset_Communication.

(4) Prepared. В этом состоянии узел запрещен (не осуществляет обмен сообщениями SDO/PDO/emergency), но осуществляет свои внутренние функции ввода/вывода.

Состояние Prepared может поменяться на Pre-Operational (Pre-Operational_State) командой Enter_Pre-Operational_State, Operational (Operational_State) командой Start_Remote_Node, сброс узла (Reset) командами Reset_Node или Reset_Communication.

Формат сообщения NMT (заголовок CAN + 2 байта данных):

Заголовок CAN Байт 1 Байт 2
0x000 CS Node_ID

Здесь CS (Command Specifier, спецификатор команды) может получить 5 значений в соответствии с желаемой функцией NMT:

Функция NMT CS
Start_Remote_Node 0x01
Stop_Remote_Node 0x02
Enter_Pre-Operational_State 0x80
Reset_Node 0x81
Reset_Communication 0x82

Node_ID может быть числом от 1 до 127 для выбора одного узла, ли 0 для выбора всех узлов. Аппаратный переключатель подчиненного устройства (или протокол LSS и энергонезависимая память) определяет Node_ID. Подчиненное устройство CANopen не должно в ответ на эти 5 команд отправлять какое-либо сообщение CAN.

CANopen Node Guarding. Эта функция используется для определения ошибок обмена в сети. Мастер (NMT) может проверять свои подчиненные устройства (node guarding), и подчиненные устройства могут проверять работу master (life guarding). Node guarding используется, если подчиненное устройство не может быть опрошено на основе регулярных интервалов времени.

OD содержит конфигурацию Node guarding:

100CH: guard time (время опроса в миллисекундах).
100DH: life time factor (множитель для * guard time, в результате получается life time, время жизни).
100EH: node guarding ID (идентификатор node guarding, по умолчанию 700H + Node_ID).

Life guarding разрешается для подчиненного устройства, когда мастер проверяет состояние slave-устройства через фрейм remote (Remote Transmit Request, RTR) на Node Guarding COB_ID, если guard time и the life time factor не равны 0. Ниже показан формат сообщения MNT от master:

Заголовок CAN
111.0iii.iiii

Slave-устройство NMT ответит своим текущим состоянием:

Заголовок CAN Байт 1
111.0iii.iiii
tsss.ssss

Назначение полей:

Поле Назначение
iiiiiii Node ID (идентификатор узла)
t Переключающийся бит (toggle bit), который меняет свое состояние при каждом запросе Node Guarding.
sssssss Состояние узла:
3 = Pre-Operational
4 = Prepared
5 = Operational

Если node-guarding master не получит ответ с текущем состоянием от узла в течение guard time, то регистрируется ошибка remote error для этого slave-узла приложения.

Если slave-устройство не получит этот запрос в течение life time (= guard time * life time factor), то slave-устройство переключится в состояние Pre-operational.

Если мастер node-guarding перезапускается, то он обнаружит измененное рабочее состояние slave-устройства и отправит сигнал об этой ошибки в приложение.

[Сравнение объектов обмена данными CANopen]

В протоколе CANopen существует 2 разных механизма для передачи данных: SDO и PDO. Service Data Object (SDO) главным образом используется для передачи больших, низкоприоритетных объемов данных между устройствами, и этот процесс передачи осуществляется асинхронно. Обычно SDO используется для конфигурирования устройств сети CANopen. Если все устройства заранее сконфигурированы, то SDO может не использоваться совсем. Отдельные параметры адресуются по 16-битному индексу и 8-битному sub-индексу.

Второй режим передачи задействует Process Data Object (PDO), это обмен сообщениями с обрабатываемыми данными (Process data messages), которые могут быть отправлены синхронно с сообщениями SYNC и асинхронно, в момент возникновения события. PDO в основном используется для обмена данными в реальном времени, и эти сообщения имеют повышенный приоритет по шине CAN по сравнению с сообщениями SDO (приоритеты, как обычно, обеспечиваются распределением адресов CAN). Количество данных в телеграмме PDO ограничено 8 байтами (количество байт данных может быть от 1 до 8 байт). Формат и содержимое данных сообщения PDO может быть фиксированным, или может быть динамически сконфигурировано передачами SDO.

Передачи SDO могут быть сравнены по скорости с передачами PDO как протоколы TCP и UDP соответственно. Другая аналогия - SDO можно поставить в соответствие сильно нагруженный грузовик, а PDO - быстрый спорткар.

Режимы передачи PDO. CANopen поддерживает разные режимы передачи для переноса данных, привязанных к реальному времени (real-time data). Один метод - простая отправка сообщения PDO в момент возникновения события (event). Например, цифровой ввод/вывод передает состояние своих входных линий, когда на них поменялся логический уровень. Модуль аналогового ввода может послать состояние входной линии, когда на ней поменялось значение на заранее сконфигурированную величину. Другой метод подразумевает синхронные передачи данных. В этом режиме каждая высокоприоритетная телеграмма синхронизации (SYNC) отправляется (обычно мастером сети) с определенным интервалом времени. Телеграмма SYNC является широковещательной (broadcast) для всех устройств сети, и те устройства, которые сконфигурированы на отправку данных в ответ на сообщение синхронизации, отправляют свои данные на шину. Данные также отправляются из управляющего устройства на те устройства, которые в этом нуждаются. Данные, переданные от устройства в момент приема SYNC обычно называют актуальными данными, в то время как данные, отправленные в устройство, называют данными команды. Для цифрового модуля I/O актуальными данными может быть информация об состоянии его входов, в то время как данные команды это те данные, которые управляют состоянием выходов. После приема данных команды устройство активируется на прием следующей телеграммы SYNC. Таким образом, если в сети есть несколько устройств вывода, то их выходы могут быть установлены синхронно. Данные команды и актуальные данные могут быть сконфигурированы так, что реакция на команду и/или передача данных будет осуществляться в ответ на каждую N-ную телеграмму SYNC, что помогает снизить нагрузку на шину CAN.

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

Пример PDO. Предположим, что устройство имеет 16-битный аналоговый выход, это значение может быть отображено на первые 2 байта PDO. Таким образом, сообщение CAN для этого устройства будет содержать только 2 байта данных. Из-за того, что передача PDO не требует какого-либо подтверждения, установка этого 16-битного аналогового значения потребует только одного сообщения CAN с 2 байтами данных, что всего составит фрейм из 60 бит, переданных по шине CAN. Та же самая функция, реализованная по методу SDO, потребует 2 сообщения CAN, каждое по 8 байт, что составит суммарно 216 бит, переданных по шине. Чтение аналогового входа может быть реализовано через remote request для PDO, эти 2 сообщения CAN займут 104 бита, переданных по шине. Другой метод передачи PDO может быть осуществлен в ответ на каждое сообщение SYNC. Это могло бы даже инициировать передачу PDO на всех устройствах сети.

Если устройство имеет несколько входов или выходов, они могут быть отображены на один PDO (например, четыре 16-битных аналоговых входа), поскольку длина PDO не должна превышать 8 байт (максимум для одиночного сообщения CAN).

Отображение объекта словаря к PDO осуществляется (через сообщение SDO) с использованием объектов словаря 1600H или 1601H (для объектов PDO приема узлов вывода) и 1A00H или 1A01H (для объектов PDO передачи узлов ввода).

Пример отображения на PDO (аналоговый 16-битный вход и число float):

Информация отображения в OD
Объект sub-индекс Значение   Объект sub-индекс Длина в битах Указывает на:
0x1A01 1 0x64010110 = 0x6401 0x01 0x10 Байты 1, 2 PDO
0x1A01 2 0x64040120 = 0x6404 0x01 0x20 Байты 3, 4, 5, 6 PDO

Результаты придут в следующем сообщении CAN:

PDO1 (tx)
Идентификатор CAN, 11 бит Байт 1 Байт 2 Байт 3  Байт 4 Байт 5 Байт 6 Байт 7 Байт 8
Например, 0x181 LSB 0x6401 MSB 0x6401 LSB 0x6404 2-й 0x6404 3-й 0x6404 MSB 0x6404 не используется

Изменение отображения на PDO возможно, только если узел находится в состоянии Pre-Operational. Если узел имеет на борту энергонезависимую память, то он нуждается только в однократной переконфигурации, если это необходимо. Если изменение отображения на PDO потерпело неудачу (узел не в состоянии Pre-Operational, объект не имеет возможности отображения или из-за другой ошибки), то узел отвечает сообщением 'Abort domain transfer'.

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

• Запросом Remote от другого устройства (RTR).
• Специальным событием устройства (определенным по профилю).

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

Не циклически:

• После получения запроса Remote от другого узла, который делает "предварительный взвод" PDO.
• Специальным событием устройства (определенным по профилю), которое делает "предварительный взвод" PDO.

Циклически:

• Передача PDO срабатывает периодически, в ответ на каждое получение 1, 2 (и т. д., до 240) сообщений SYNC.

Объекты словаря 1400H/1401H/1800H/1801H (параметр обмена PDO), sub-индекс 2 (тип передачи) определяют, как будет срабатывать передача PDO:

Тип передачи Условия для срабатывания PDO:
A = нужны оба
O = одно или оба
Метод передачи PDO
  SYNC RTR Событие  
0 A   A Синхронно, не циклически
1..240 O     Синхронно, циклически
241..251       Зарезервировано
252 A A   Синхронно, после RTR
253   O   Асинхронно, после RTR
254   O O Асинхронно, по событию, специфическому для производителя
255   O O Асинхронно, по событию, специфическому для профиля устройства

Профиль DS401 устройства I/O декларирует тип передачи для каждого PDO в значение 255: передача (входа) PDO асинхронная, управляемая событием (по изменению входа) или п запросу RTR. Прием (для установки выходов) PDO является асинхронным.

PDO inhibit time. Когда PDO срабатывает в ответ на каждое событие I/O (например, изменение уровня цифрового входа или прием символа через RS232), то возможно, что PDO будет срабатывать слишком часто, что вызовет чрезмерный трафик по шине CAN. Для предотвращения этой ситуации введен дополнительный параметр передающих PDO (для узлов со входами), так называемое время запрета (PDO inhibit time). Это счетчик с точностью 100 мс, который запрещает следующую передачу PDO, пока не истечет заданный период времени.

[Ссылки]

1. ATLAS DCS CANopen Software description site:atlas.web.cern.ch.
2CiA301: слой приложения и профиль коммуникации CANopen.
3. CiA-401 site:can-cia.org.
4. CiA-404 site:can-cia.org.
5. Обзор протокола CANopen.
6. Basics of CANopen site:ni.com.