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

Рис. 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.

Примечание: код 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 байта данных):

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

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:

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

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

Если 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. Передача PDO может быть инициирована (запущена) разными способами, в соответствии с типом передачи PDO. Один из методов - асинхронная передача. Асинхронный PDO может быть запущен с помощью:

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

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

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

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

Циклически:

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

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

Профиль 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.
2. CiA301: слой приложения и профиль коммуникации CANopen.
3. CiA-401 site:can-cia.org.
4. CiA-404 site:can-cia.org.
5. Обзор протокола CANopen.
6. Basics of CANopen site:ni.com.