Профильное семейство CANopen определяет стандартизованные приложения для распространяемых систем, основанных на CAN. CANopen был разработан международной группой пользователей и производителей CAN-in-Automation (CiA), и был стандартизован как CENELEC EN 50325-4 в декабре 2002 года. Вскоре после своего первого запуска в 1996 году CANopen встретил широкое признание (особенно в Европе), где можно считать CANopen лидирующим стандартом для системных решений, основанных на CAN.

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

Сейчас CANopen используется для реализации различных задач:

• Управление машинами.
• Заводская, лабораторная автоматизация.
• Транспорт и трафик.
• Автомобильные приложения.
• Автоматизация построек.
• Медицинские системы.

Основные функциональные возможности CANopen. Стандартизованные приложения для распространяемых систем автоматизации на базе (Controller Area Network) предоставляют следующие функции:

• Передача критичных к времени доставки данных в соответствии принципом потребителя.
• Стандартизованное описание устройства (data, parameters, functions, programs) в так называемой форме "словаря объектов" ("object dictionary"). Доступ ко всем "объектам" устройства по стандартизованному протоколу передачи осуществляется по принципу клиент-сервер.
• Стандартизованные службы для мониторинга устройства (node guarding / heartbeat), сигнализация об ошибках (emergency messages) и координация работы сети ("network management").
• Стандартизованные системные службы для синхронных операций (synchronization message), центральное сообщение меток времени (central time stamp message).
• Стандартизованные вспомогательные функции для конфигурирования через шину скорости (baud rate) и идентификационного номера устройства.
• Стандартизованные шаблоны назначения для идентификаторов сообщений, чтобы упростить конфигурации системы в так называемой форме "заранее определенные наборы соединения" ("predefined connection set").

Рис. 1. Иерархическая структура стека протоколов CANopen.

Основные документы стандарта CANopen. Документ CiA 301 "CANopen Application Layer and Communication Profile" [15] является базовым стандартом, доступным через организацию пользователей стандарта "CAN-in-Automation e.V." (CiA), находящейся в Германии (город Эрларген). Расширенные механизмы обмена описаны в CiA 302: "Framework for Programmable Devices", в специальных инструментах PLC, HMI или CANopen. Предложения по спецификации CiA 303, CiA 305 и CiA 306 определяют стандарты и рекомендации для кабелей, цоколевке выводов, SI units, службам установки слоев (layer setting services, LSS) и спецификацию по радиоэлектронным документам (electronic data sheet, EDS). Все стандарты CANopen были разработаны компаниями-участниками CiA, и они свободно доступны без узуфрукта. Обзор устройства CANopen device и профилей приложения дан в разделе "Стандартные профили устройства и приложения".

Специальные объекты коммуникации, так называемые "service data objects" (SDO) используются для прямого доступа к устройствам CANopen. С этими SDO записи словаря объектов OD могут быть считаны и записаны, где обмен всегда осуществляется по принципу логического соединения 1:1 (peer-to-peer) между двумя узлами сети (например, между конфигурирущим узлом и узлом, который получает конфигурацию). Поскольку перемещение данных через такое соединение осуществляется как служба подтверждения, то это означает, что узлу требуется 2 сообщения CAN на соединение: одно сообщение для запроса по сети(SDO request, или "Client SDO"), и второе сообщение для ответа на запрос (SDO response, "Server SDO"). ИМХО, такая терминология вносит некоторую путаницу в терминологию. Эти 2 сетевых узла используются и называются соответственно как SDO client и/или SDO server; здесь сервер идентифицируется как узел, который предоставляет или принимает данные с помощью его словаря OD. Клиентом соответственно считается тот узел, кто запрашивает (читает) или передает (записывает). Здесь имеет место логическое соединение между двумя партнерами, который также называют каналом SDO ("SDO channel"). Инициатива для передачи SDO всегда исходит от клиента. Поскольку передача SDO подтверждается, то на каждый запрос должен поступить ответ, даже если устройство не может предоставить какие-либо значимые данные, или даже если запрос сам по себе был ошибочным. Такой отрицательный ответ называется "abort". В таком ответе в дополнение к 4-байтному коду ошибки (abort code), который указывает причину abort, также передается адрес записи OD, на котором произошла сбойная передача SDO. Как уже упоминалось, передача SDO всегда запускается как последовательность запрос-ответ (request-response) в соответствии с отдельным протоколом, который указан в первом байте данных SDO. Таким образом, идентификатор сообщения указывает сам SDO и первый байт данных SDO задает определенный протокол. По этой причине первый байт данных также называют байтом протокола или байтом команды. Сообщение SDO всегда длиной 8 байт, где биты поля данных, которые не используются, должны быть установлены в 0.

Поля данных любой длины или последовательность байт может быть передана через доступ к объекту словаря. По этой причине длина информации, которая может быть передана через протокол SDO, теоретически не ограничена. Протокол SDO работает в 2 фазы: в фазе инициализации адресуется запись словаря объектов где показана длина передаваемых данных. Вторая фаза предназначена для данных, которые передаются в сегментах (по 8 байт на сегмент).

Соответственно DS-301 [15] разделяет 4 разных службы SDO: Initiate SDO Upload (инициация выгрузки SDO), Upload SDO Segment (выгрузка сегмента SDO), Initiate SDO Download (инициация загрузки SDO) и Download SDO Segment (загрузка сегмента SDO).

Очень часто передается только несколько полезных данных, передача SDO может быть укорочена максимум до 4 байт, с передачей уже на фазе инициализации. Это называют также как "expedited SDO transfer" (ускоренная передача SDO).

Сообщение для службы Initiate SDO Download, в котором доступ на запись в элемент словаря объектов узла происходит одновременно, структурируется следующим образом:

Рис. 8. Initiate SDO Download.

Здесь OD main-index и OD sub-index это соответственно главный индекс и sub-индекс элемента в словаре объекта (OD).

Сервер SDO отвечает байтом протокола 0x60:

Рис. 9. Ответ на Initiate SDO Download.

В байте команд, где его отдельные биты назначены для разных целей, служба кодируется тремя битами (спецификатор команды). Еще один бит задает, какая осуществляется передача - expedited или обычная, non-expedited. Другой бит показывает, задан ли размер передаваемых данных в последних 4 байтах объекта коммуникации; однако этот бит используется только для non-expedited передач.

В expedited transfer, другими словами, данные пользователя передаются непосредственно в последних 4 байтах. Два следующих бита в байте протокола указывают, сколько этих байт назначено в действительности (возможно передавать только 1 байт пользовательских данных). Пользовательские данные должны быть таким образом выравнены влево в поле данных объекта SDO.

Обычно такое выравнивание упоминается так, что данные CANopen передаются по правилу "Little Endian" [11], что соответствует порядку следования байт в памяти процессоров INTEL. Это означает, что младший байт передается первым. Это несколько усложняет анализ данных протокола SDO человеком, хотя это в конце концов вопрос привыкания. При подсчете уже описанных бит протокола их получается 7. Восьмой бит зарезервирован.

Таким образом, SDO download в запись OD [1017], где heartbeat interval для heartbeat producer устанавливается в 4 секунды (в ms, как значение UNSIGNED16, например 0x0F A0), появляется в следующем виде:

Рис. 10. Пример записи в объект [1017].

Узел (SDO server), когда отвечает сообщением успешного завершения:

Рис. 11. Ответ на запись в объект [1017].

Со службой Initiate SDO Upload, с которой считывается элемент словаря объекта узла CANopen, допустимой является то же самое деление поля данных, только здесь до некоторой степени инвертируются телеграммы запроса и ответа. Вот байт команды запроса клиента 0x40:

Рис. 12. Пример запроса чтения обекта словаря.

Сервер SDO отвечает:

Рис. 13. Ответ на запрос чтения объета словаря.

SDO сервер должен всегда отвечать на типичный запрос чтения производителя устройства (vendor ID; он находится в sub-индексе 1 объекта идентификации, identity object [1018]), поскольку этот OD-элемент является обязательным. В качестве примера рассмотрим устройство от IXXAT (номер вендора 00 00 00 04). Таким образом, сообщение ответа SDO будет следующим:

Рис. 14. Пример ответа на запрос чтения.

Если используется не "expedited transfer", то 4 байта данных Initiate SDO services можно использовать для указания длины (в байтах) передаваемых данных. Тогда действительная передача может произойти со службой Download SDO Segment или Upload SDO Segment. Может быть передано 7 байт данных пользователя на сегмент. Байт команды этих служб содержат 3 бита идентификатора службы (service-ID, спецификатор команды), один toggle-бит и 4 не используемых бита, за исключением последнего сегмента. Чтобы также безопасно передать данные пользователя, размер которых не делится нацело на размер сегмента 7, количество не используемых байт (значение между 6 и 0) кодируется 3 битами в последнем сегменте SDO. И наконец, LSB биты байта команд помечают конец передачи. Порядок следования сегментов мониторится по toggle-биту, где переключаются сообщения и SDO request, и SDO response. Закомментироанная последовательность сегментированной non-expedited выгрузки иллюстрируется следующим образом:

   40 08 10 00 00 00 00 00  // Инициация запроса: Read Device Name [1008]
   41 08 10 00 1A 00 00 00  // Инициация ответа: все в порядке, это будет 26 байт.
   60 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 0
   00 54 69 6E 79 20 4E 6F  // Ответ Upload segment, Toggle = 0
   70 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 1
   10 64 65 20 2D 20 4D 65  // Ответ Upload segment, Toggle = 1
   60 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 0
   00 67 61 20 44 6F 6D 61  // Ответ Upload segment, Toggle = 0
   70 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 1
   15 69 6E 73 20 21 00 00  // Последний сегмент, 2 байта свободно, Toggle = 1

В версии 4 CANopen спецификации DS-301 [15], представлен новый, значительно более эффективный, однако более сложный режим SDO, так называемый режим блочной передачи SDO (SDO block transfer). В отличие от передачи сегмента, описанного выше, здесь сегменты больше не запрашиваются индивидуально, вместо этого комбинируются друг с другом в блоки, где все сегменты передаются за 1 раз. Тогда партнер подтверждает только блок. Для пользовательских данных размером от 29 байт блочная передача лучше с точки зрения побочных затрат на протокол. С блочной передачей байт протокола нумерует отдельные сегменты каждого блока так что можно передать в блоке максимум 127 сегментов. Передача окружена фазой инициализации, в которой размеры блока и размеры служебных данных обоих партнеров делаются соответствующими друг другу, и фазой завершения, в которой фиксируется проверка контрольной суммы CRC по всей передаче, при условии, что партнеры обмена подтвердили передачу на этапе инициализации. Однако передача блока SDO в настоящий момент поддерживается только несколькими устройствами.

Доступ на чтение (SDO read access) к элементу словаря объекта [1008], имя устройства, блочная передач выглядит примерно так:

   A4 08 10 00 21 00 00 00  // Инициация запроса: Read [1008], размер блока 33, CRC поддерживается
   C2 08 10 00 1A 00 00 00  // Инициация ответа: длина данных 26 байт, нет CRC
   A3 00 00 00 00 00 00 00  // Инициация запроса блока: начинаем передачу
   01 54 69 6E 79 20 4E 6F  // Ответ Upload block, сегмент 1
   02 64 65 20 2D 20 4D 65  // Ответ Upload block, сегмент 2
   03 67 61 20 44 6F 6D 61  // Ответ Upload block, сегмент 3
   84 69 6E 73 20 21 00 00  // Последний сегмент 4
   A2 04 21 00 00 00 00 00  // Запрос Upload block: принято 4 сегмента, размер блока 33
   C9 00 00 00 00 00 00 00  // Ответ завершения: 2 байта свободно
   A1 00 00 00 00 00 00 00  // Конец запроса: благодарю

Важным сервисом SDO является "Abort SDO Transfer" (байт команды: 0x80). Он состоит полностью из одного сообщения CAN, который может быть передан в любое время любым из двух партнеров вместо обычного сообщения протокола SDO, и приводит к непосредственному завершению передачи SDO. Наиболее общие ситуации для SDO-Abort в качестве ответа на Initiate SDO request, это ситуация, когда в словаре объекта адресуемый объект отсутствует. Структура сообщения Abort SDO:

Рис. 15. Сообщение Abort SDO.

Поле данных этой службы SDO содержит информацию от ошибке (cause of the error, abort code) как двойное слово, dword. Спецификация CANopen перечисляет все определенные коды abort, их всего примерно 30. Использование собственных кодов abort или не определенных кодов не допускается. Наиболее важные коды abort:

   0x05030000  бит Toggle не изменился
   0x05040001  недопустимый идентификатор команды (Invalid SDO Command specifier)
   0x0601000x  не поддерживаемый доступ к объекту
   0x06010002  попытка записи в объект, предназначенный только для чтения
   0x06020000  объект не существует в словаре объекта
   0x0607001x  не соответствует тип данных
   0x06090011  sub-индекс не существует
   0x08000000  общая ошибка

Каждое устройство должно поддерживать как минимум 1 канал SDO. Остальные каналы SDO могут быть настроены через элементы словаря объекта. Записи OD от [1201] до [127F] с предопределены для записи параметра SDO, зарезервированы для определения каналов сервера SDO.

Основная задача системы CANopen конечно же состоит в управлении процессом передачи данными. Для этой цели предоставлено не только большинство идентификатором CAN, но также и большинство записей в словаре объекта. Для обработки передачи данных это происходит без дополнительной нагрузки на протокол, и передача происходит в соответствии с так называемым принципом "генератор-потребитель" ("producer-consumer principle"). Это означает, что сообщение, передаваемое узлом (это генератор) может быть принято всеми другими узлами (потребителями). Этот принцип также называют широковещанием ("broadcasting") и он представляет очень эффективный принцип передачи данных, особенно если сообщение (например сообщение синхронизации) должно быть передано одновременно для всех участников процесса.

Сообщение CAN, которое содержит данные процесса, называется PDO ("Process Data Object"). Как уже было описано, передача сообщений PDO возможно только в состоянии "Operational". Все PDO имеют не фиксированный формат. Поле данных PDO может быть длиной от 1 до 8 байт. Содержимое PDO также не может быть быстро интерпретировано. Основная идея здесь состоит в том, что и передатчик, и приемник знают, как интерпретировать содержимое PDO. По этой причине достаточно в PDO идентифицировать только его COB-ID. Так называемое отображение PDO ("PDO mapping") описывает, какие отдельные переменные процесса в поле данных PDO переданы, как они расположены, и какой тип данных и длину они имеют. Таком образом, содержимое и смысл поля данных каждого определенного PDO описано в форме записи PDO-mapping внутри словаря объекта на обоих сторонах обмена - передатчика и приемника.

PDO producer (передатчик, генератор PDO) составляет поле данных PDO в соответствии со своим отображением TxPDO mapping. Для этого он берет текущие данные передаваемых переменных из своего словаря объекта, и копирует их в поле данных PDO перед отправкой сообщения CAN (PDO). То же самое происходит на стороне потребителя данных (consumer): на базе записи RxPDO mapping, байты данных принятых PDO копируются в записи локального словаря объекта, так что срабатывают зависящие от устройства действия (например, установка цифровых выходов).

Узел сети, которые хотят принять определенные PDO, должны активироваться только соответствующим сообщением CAN. Это осуществляется проверкой "set valid" соответствующей записи COB-ID в OD.

Однако вернемся сейчас к PDO mapping. Принцип расположения (mapping) переменных процесса показан в следующем (переменные доступны в форме записей словаря объекта в профиле приложения). Расположение отдельных переменных процесса в поле данных PDO описано в форме таблицы. Это также предоставлено как запись словаря объекта, а именно для каждого transmit-PDO и receive-PDO в [16xx] или [1Axx]. Эти таблицы, и таким образом расположение переменных процесса в поле данных PDO, могут конфигурироваться с помощью SDO доступа на запись.

Рис. 16. Пример взаимосвязи объектов.

В этом примере имеется точно 2 связи объектов: от объекта (переменная процесса) [2345sub67] продюсера PDO к объекту [5432sub10] потребителя PDO, и от объекта [6000sub01] продюсера до объекта [6200sub02] потребителя. Третий объект передачи [2001sub00] не обрабатывается на стороне приемника, и поэтому считается так называемым пустым, фиктивным объектом (dummy object).

Таблицы отображения имеют тип данных "PDO mapping", которые содержат в sub-индексе 0 (subindex 0) количество отображенных объектов, и в sub-индексах от 1 до 8 сами отображаемые записи словаря объекта в формате DWORD. Здесь содержится 24-битный адрес OD (index, subindex) и закодированная 8 битами длина записи OD. Устройство, которое поддерживает 8 отображенных записей имеет гранулярность 8, и может таким образом выполнить только побайтное отображение (byte-wise mapping). Устройства с гранулярностью 1, с другой стороны, поддерживают отображение каждого отдельного бита PDO ("bit-mapping"). Соответственно здесь должно быть тогда 64 элементов в таблице отображения (mapping table).

Однако PDO описан не только отображением (mapping), но также и его коммуникационными параметрами. Это COB-ID, т. е. идентификатор сообщения CAN, тип передачи ("transmission type"), время запрета ("inhibit time"), и это все может конфигурироваться через соответствующий элемент словаря объекта. Позиция этого дополнительного элемента словаря имеет смещение 0x200 перед соответствующим элементом отображения, например для transmit PDO [18xx] и receive PDOs [14xx]. Таким образом, каждый PDO описан двумя отдельными элементами OD, которые жестко принадлежать друг другу и должны конфигурироваться системным интегратором. Следующая таблица показывает запись "PDO parameter":

Таблица 1. Запись параметра PDO.

Subindex 1 содержит идентификатор CAN PDO выровненный вправо в двойном слове. Самый старший бит значения показывает, активен ли PDO (valid) или не активен (invalid). Набор старших бит показывает недопустимость, например значение 0x80000199, описывает первый TxPDO узла с номером 25.

Тип передачи PDO может быть установлен вторым sub-индексом. Для начала следует отличать друг от друга синхронные и асинхронные PDO:

Таблица 2. Типы PDO.

Асинхронные PDO управляются по событиям (event-controlled), и представляют нормальный тип передачи PDO. Это означает, что когда изменилась как минимум одна из переменных процесса, отображенная на PDO, например изменилось входное значение, то PDO передается немедленно. Для этого значения 255 или 254 вводятся как тип PDO.

Синхронные PDO передаются после предварительного приема сообщения синхронизации (Sync Object). Таким образом, передача PDO осуществляется синхронно во всей сети, более или менее одновременно. Но то, что намного более важно - все входы устройства должны быть опрошены при поступлении sync object, чтобы был сформирован законченный универсальный снимок результатов. Со следующим сообщением sync, записанные данные отправляются в синхронных PDO. Таким образом присутствует задержка, на время цикла синхронизирующего сообщения, поскольку получатели обработали переменные процесса в момент предыдущего синхронизационного сообщения. В направлении вывода синхронные PDO, принятые узлом, становятся действительными только на следующем синхронизационном сообщении.

Чтобы шина CAN не забивалась большим количеством синхронных PDO, которые все посылаются с каждым сообщением SYNC, используются значения 1..240 циклического синхронного типа PDO в качестве делителей интервала передачи. Соответственно [18xxsub02] = 4 означает, что синхронный PDO отправляется только с четвертым сообщением Sync. Независимо от этого устройство конечно должно записать свои входы с каждым сообщением Sync, поскольку может произойти, что синхронно записанные переменные процесса в PDO будут запрошены RTR. В этом случае устройство CANopen должно немедленно передать соответствующий PDO с записанными значениями. В [1006] параметре "Communication Cycle Period" узлы могут быть оповещены интервалом Sync в микросекундах.

И наконец, в sub-индексе 3 для асинхронных PDO можно установить "inhibit time" (время запрета). Это значение дается в единицах 100 микросекунд. Inhibit time полезно, когда происходят частые неконтролируемые изменения входных значений; например, если аналоговый вход никуда не подключен и болтается в воздухе. Если inhibit time сконфигурировано, то узел не может передавать снова соответствующий PDO до истечения времени запрета; это гарантирует, что шина не будет чрезмерно загружена бесполезными сообщениями. Конечно же, время запрета используется только для TxPDO. Оно не имеет смысла для RxPDO.

Асинхронные TxPDO могут быть переданы циклически по таймеру события (event timer), sub-индекс 5. Если значение больше 0, то это становится миллисекундным таймером. Когда этот таймер истек, передается PDO. Таким образом, передача осуществляется, когда изменяется вход внешнего устройства, или когда истек event timer. Этот sub-индекс также имеет значение только для объектов transmit-PDO.

Узел CANopen обычно имеет 4 transmit-PDO и 4 receive-PDO, где один COB-ID зарезервирован для каждого из этих PDO. Так что это займет всего 127*4*2 = 938 идентификаторов COB-ID, что обычно составляет половину всего пространства идентификаторов. Однако из-за так называемой взаимосвязи объектов ("object linking"), например при установлении коммуникационных взаимоотношений между transmit- и receive-PDO, идентификаторы CAN снова освобождаются, поскольку при связи либо продюсера, либо потребителя должны быть адаптированы их COB-ID к партнеру обмена, так что свои собственные зарезервированные COB-ID становятся свободными. Таким образом, на практике для сети с 127 узлами в среднем доступно 8 идентификаторов COB-ID на устройство для TxPDO. Конечно, для сетей с меньшим количеством узлов неиспользуемые COB-ID могут также использоваться. Интегратор системы должен всегда иметь обзор пространства назначения идентификаторов, и иметь представление о реально используемых COB-ID; для более сложных систем для этого рекомендуется использовать программный инструмент, например IXXAT CANopen ConfigStudio. Этот инструментарий, например, автоматически обрабатывает PDO-mapping и PDO-linking.

Это необязательная опция, которая может использоваться в сети. Обычно пакеты SYNC генерирует мастер сети CANopen (генератор пакетов SYNC называют SYNC-producer) с регулярными интервалами, что позволяет синхронизировать обмен данными. В частности, получение пакета SYNC узлом может инициировать ответную передачу сообщения PDO (получателя пакета SYNC называют SYNC-consumer). Таким образом, с помощью пакетов SYNC можно реализовать получение информации от датчиков в регулярные моменты времени.

Поскольку CANopen не является иерархической системой master-slave, и контролируемый узел передает только коммуникационное состояние, а не реальное состояние состояние узла, то каждый узел нуждается в высокоприоритетном идентификаторе CAN, чтобы показывать ситуации ошибки. Этот механизм называется "Emergency Messaging", и он связан с объектом обмена "Emergency Message". Такое аварийное сообщение состоит из 8 байт данных в следующей форме:

Рис. 17. Аварийное сообщение.

Коды ошибок указаны в DS-301 [15]. Старший байт разделяет категории ошибки:

Таблица 3. Коды ошибок аварийного сообщения.

Одновременно с передачей emergency message устройство записывает код ошибки в [1003], где сохраняется история ошибок. Регистр ошибки это содержимое элемента OD [1001] с побитным кодированием случая ошибки:

Таблица 4. Кодирование событий ошибки.

Идентификатор CAN для emergency message сохраняется в OD устройства под ячейкой [1014], но этот элемент OD является опциональным (необязательным), как и само событие аварии (emergency event).

В дополнение к предоставлению служб и протоколов для передачи данных процесса и конфигурации устройств, работа системы, распространяемая по сети, требует функций для командного управления коммуникационным состоянием отдельных узлов сети. Поскольку передача данных устройств CANopen во многих случаях управляется событиями (event-controlled), также требуется отслеживания возможности обмена между узлами сети. CANopen предоставляет так называемые службы управления сетью ("network management", сокращенно NMT) и протоколы для этих задач, а именно управление коммуникационным состоянием узлов сети и мониторинг узла.

[Статус узла сети CANopen и состояние управления через сообщения NMT]

CANopen описывает коммуникационное состояние сетевого узла в диаграмме состояния (state diagram). Путем отправки специальных сообщений CAN (NMT messages), мастер управления сети (network management master) может управлять коммуникационным состоянием других узлов (подчиненные узлы в управлении сетью, network management slaves) сети CANopen. Например мастер может одной командой поменять состояние всех узлов или отдельного конкретного узла.

Сообщения NMT передаются через самый высокоприоритетный идентификатор сообщения (CAN-ID 0). Поле данных этого сообщения состоит только из 2 байт: требуемое целевое состояние закодировано в первом байте данных, второй байт задает номер узла, у которого должно быть изменено коммуникационное состояние. Все узлы сети совместно адресуются через виртуальный идентификатор узла node-ID 0; таким способом одной командой все узлы сети могут быть переведены в рабочее состояние ("Operational"), чтобы работа узлов началась одновременно.

[Какие бывают состояния. Смена состояния]

Ниже на диаграмме показаны возможные состояния устройства и переходы между ними.

Рис. 18. Диаграмма смены состояний узла.

Сброс, включение питания. Чтобы можно было даже частично сбросить определенный узел, это состояние имеет деление на 3 подсостояния: "Reset-Application" (сброс приложения), "Reset-Communication" (сброс обмена) и "Initializing" (инициализация).

После аппаратного сброса (HW-Reset) или включения питания (Power-On) узел попадает в состояние "Initializing". После завершения базовой инициализации узла (например контроллера хоста, контроллера CAN, программы приложения и т. д.) узел передает так называемое сообщение загрузки ("boot-up message") и самостоятельно переходит в состояние в "Pre-operational" (предварительная готовность к работе).

В подсостоянии "Reset-Application" сбрасываются специфические параметры производителя и стандартный профиль устройства к состоянию на момент включения питания (Power-On values, что соответствует последним сохраненным значениям параметров). После этого узел перемещается в подсостояние "Reset-Communication". В этом подсостоянии сбрасываются параметры профиля коммуникации к своим значениям при включении питания (Power-On values). Затем состояние узла меняется на "Initializing".

Pre-Operational. Это состояние главным образом используется для конфигурирования устройств CANopen. Таким образом, процесс обмена данными (через объекты PDO) в этом состоянии невозможен. Элементы словарей объекта устройства могут быть доступны через сервисные объекты данных ("service data objects", SDO). Путем передачи сообщения SDO можно модифицировать словарь объекта определенного устройства, например с помощью инструментария конфигурирования.

В состоянии Pre-operational в дополнение к обмену через сообщения SDO также могут передаваться или приниматься сообщения аварии (emergency), синхронизации (synchronization), метки времени (time stamp) и конечно управляющие сообщения NMT. Путем передачи "Start-Remote-Node" узел переключается в состояние "Operational".

Operational. В этом состоянии возможна передача данных процесса через так называемые объекты обработки данных ("process data objects", PDOs).

Stopped. За исключением сообщений node guarding или heartbeat, в этом состоянии узел не может передавать или принимать какие-либо сообщения.

[Мониторинг устройств CANopen с использованием механизмов node guarding и heartbeat]

Для гарантирования работоспособности узлов сети CANopen предоставляет 2 альтернативные возможности: циклический опрос node guarding и автоматическую передачу сообщений heartbeat, подробнее см. раздел "Мониторинг сети: Guarding и Heartbeat".

Для мониторинга коммуникационного состояния устройства требуется один CAN-ID на узел сети. Для этого зарезервированы низкоприоритетные идентификаторы сообщений со значением 1792 + node-ID.

В настоящее время принцип node guarding больше не используется. Это могло быть данью главным образом более высокой загрузки шины (из-за 2 сообщений CAN на интервал мониторинга), но также и нежелательной централизацией зависимости целостности сети от работоспособности одного узла NMT-master.

Для обеспечения работоспособности узлов сети протокол CANopen предоставляет 2 взаимоисключающие альтернативы:

1. Циклический опрос состояния узла со стороны узла с повышенным приоритетом, так называемого "NMT-Master". Этот принцип называется "node guarding" (буквально переводится "защита узла").
2. Автоматическая передача специального контрольного сообщения узлами сети. Этот принцип называется "heartbeat" (переводится как "сердцебиение").

Node guarding. При работе по принципу node guarding определенный узел сети (это главный узел сети, так называемый NMT-master) опрашивает остальные узлы сети (подчиненные узлы, соответственно называемые NMT-slave) фреймом CAN remote (что такое remote frame, см. [12]). Опрос узлов идет последовательно, друг за другом, с заранее определенным интервалом времени ("guard time", защитный интервал времени). В ответ подчиненные узлы должны передать телеграмму данных, описывающую их текущее коммуникационное состояние (stopped, operational, pre-operational) вместе с так называемым битом toggle. Если узел по какой-то причине не ответил на запрос NMT-master в течение заданного времени ("node life time", время жизни узла), то это регистрируется как ошибка соответствующего узла, и показывается контроллеру хоста NMT-master как "node-guarding event" (событие защиты узла). Другими словами, подчиненные устройства NMT-slave также мониторят сеть на предмет обнаружения запроса от NMT-master в течение своего "времени жизни". Если такой запрос отсутствовал дольше, чем так называемый интервал "времени жизни" узла, то узел NMT-slave также предполагает, что мастер сети NMT-master поломался, и показывает это своему хост-контроллеру через "Life guarding event" (событие защиты жизни сети).

В режиме node guarding, требуется по одному идентификатору CAN на узел сети, чтобы осуществлять опросы коммуникационного состояния. Для этой цели зарезервированы сообщения с идентификаторами низкого приоритета значениями 1792 + node-ID.

Heartbeat. При мониторинге сети по принципу heartbeat узел автоматически передает свое коммуникационное состояние с регулярными интервалами как доказательство своей коммуникационной работоспособности. Интервал между такими ближайшими друг к другу сообщениями (heartbeat messages) конфигурируется через специальную запись директории объектов [1017]. Значение 0 запрещает механизм heartbeat. Так называемое "heartbeat consumer time" (потребительское время сердцебиения) до 127 сетевых узлов дано в записи OD [1016]. Этот интервал времени описывает максимальное время, в течение которого прибытие сообщения подтверждения работоспособности (heartbeat message) ожидается определенным узлом.

В обоих принципах защиты сети сообщения с коммуникационным статусом передается в форме однобайтного значения:

Рис. 19. Кодирование состояния узла.

Определены следующие значения для состояния узла:

0x00 - Bootup
0x04 - Stopped
0x05 - Operational
0x7F - Pre-Operational.

Самый старший бит значения назначен для специальной роли - по принципу защиты node guarding этот бит должен переключаться (toggle), по принципу heartbeat он должен быть всегда в состоянии 0.

Сообщение состояния узла (node status message) имеет специальное приложение, так называемое событие загрузки "bootup event". Это сообщение ("bootup message") автоматически отправляется узлом сети, как только он перейдет из состояния инициализации ("Initialization") в состояние перед началом нормального функционирования ("Pre-Operational"); это оповещает все узлы, уже присутствующие в сети CANopen, о появлении нового узла. Дополнительно конфигурирующий узел (NMT-master) информируется, когда он может начать конфигурировать узел. Байт данных для bootup имеет значение 0x00.

Условием для использования LSS, в дополнение к условию поддержки LSS самим устройством, является установление проводного соединения 1:1 с конфигурируемым узлом. Тогда скорость передачи бит (baudrate) и node-ID устанавливаются в режиме диалога. COB-ID 0x7E5 используется для сообщений CAN в устройство, устройство отвечает на COB-ID 0x7E4. Сообщения LSS всегда имеют полную длину 8 байт. Не используемые байты должны всегда быть инициализированы значением 0.

Чтобы наладить контакт с конфигурируемым устройством, передается команда "Switch Mode Global":

Рис. 20. Начальная фаза установки взаимоствязи с устройством.

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

Затем запрашивается node-ID через службу "Inquire Node-ID":

Рис. 21. Запрос идентификатора устройства.

Если все хорошо, то устройство ответит так:

Рис. 22. Ответ устройства со своим идентификатором.

Если ответ не был получен, то либо устройство не поддерживает службу LSS, либо неправильно установлена скорость. Если не известна именно скорость, то вышеупомянутая последовательность должна быть протестирована со всеми возможными скоростями CANopen, пока устройство не будет обнаружено.

Служба "Configure Node-ID" используется для конфигурирования нового node-ID:

Рис. 23. Запрос на конфигурирование идентификатора узла.

В ответ устройства включен код ошибки:

Рис. 24. Ответ на запрос смены идентификатора.

Об успешной операции сигнализирует только код ошибки 0; код ошибки 1 означает недопустимый node-ID; другие коды ошибки зарезервированы. Расширение кодов ошибки содержит информацию, специфическую для вендора, но это допустимо только для кода ошибки 0xFF.

Скорость по шине (baudrate) конфигурируется службой "Configure Bit Timing Parameters":

Рис. 25. Запрос на изменение скорости.

Стандартные скорости CANopen перечислены в следующей таблице:

Таблица 6. Кодирование скоростей CANopen.

На команду установки скорости устройство ответит:

Рис. 26. Ответ на команду изменения скорости.

И снова код ошибки 0 означает успех операции; код ошибки 1 означает недопустимую скорость; все другие коды ошибки зарезервированы. Расширение кодов ошибки содержит информацию, специфическую для вендора, но это допустимо только для кода ошибки 0xFF.

Теперь сконфигурированы node-ID и baudrate, эти установки должны быть сохранены службой "Store Configuration":

Рис. 27. Команда сохранения конфигурации.

На это устройство выдаст подтверждение:

Рис. 28. Подтверждение сохранения конфигурации.

Код ошибки 0 означает успех; код ошибки 1 означает, что устройство не поддерживает сохранение; код ошибки 2 означает, что есть проблема с доступом с носителю данных, куда сохраняются настройки (storage medium); другие коды ошибок зарезервированы. Расширение кодов ошибки содержит информацию, специфическую для вендора, но это допустимо только для кода ошибки 0xFF.

И наконец, устройство переключается обратно в из режима конфигурации командой "Switch Mode Global":

Рис. 29. Команда выхода из режима конфигурирования.

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

HMS предоставляет под брендом IXXAT различные стеки протоколов, которые позволяют получить функционал CANopen на определенных пользовательских микроконтроллерных платформах. ПО протокола распространяется как независимый от аппаратуры исходный код C, который всегда проверяется на последних тестах совместимости CANopen организации CiA [1]. Подробная документация и примеры программ позволяют быстро разработать нужное прикладное ПО.

HMS предоставляет следующие программные пакеты:

CANopen Protocol Software. Этот пакет включает в себя все необходимые функции для реализации подчиненных устройств (slave) или простых главных устройств (master) CANopen в соответствии со спецификацией CIA 301 (EN 50325-4) [15]. По умолчанию предоставляется поддержка служб LSS в соответствии с CIA 305. Доступны дополнительные модули для интеграции функционала flying master или SDO manager. Подробнее см. CANopen Protocol Software на сайте IXAAT (строка для поиска Software package for the development of CANopen slave or simple CANopen master devices site:ixxat.com).

CANopen Manager Software. Это очень мощный программный пакет для реализации блоков устройств CANopen, которые могут работать как slave, master или сложных устройств менеджеров (CANopen manager). Этот программный пакет базируется на спецификациях CIA 301 [15], CIA 302 и CIA 405. Подробнее см. CANopen Manager Software на сайте IXAAT (строка для поиска Software package for the development of CANopen master devices site:ixxat.com).

CANopenRT (Real-Time) Software. Это ПО является специфической версией протокола CANopen, реализующая расширенные интерфейсы, что позволяет достичь очень эффективной интеграции либо в операционные системы реального времени (RTOS), либо в другие широко распространенные операционные системы. Подробнее см. CANopen RealTime Software на сайте IXAAT (строка для поиска Real-time-capable software package for the development of CANopen slave or simple CANopen master devices site:ixxat.com).

[Пакеты для PC]

HMS также предлагает API для реализации устройств master и slave, обслуживания всех видов приложений и уровней сложности сети. Библиотека распространяется в виде Windows DLL, которая может быть просто интегрирована в ПО пользователя.

CANopen Master API. Это API является программным пакетом, позволяющим упростить разработку таких приложений CANopen slave и master, как сервисные и тестовые программы на платформе Windows. Подробнее см. CANopen Master API на сайте IXAAT (строка для поиска Software package for the development of CANopen service and test applications under Windows site:ixxat.com).

CANopen Manager API. Это API мощное и гибкое решение, которое (в комбинации с CAN-интерфейсом iPC-I XC161/PCI(e)) позволяет реализацию основных управляющих приложений CANopen. Это может быть также интегрировано с совместимым IEC 61131-3 run-time окружением платформ на основе Microsoft Windows. API базируется на CANopen Manager Software, и таким образом полностью поддерживает стандартизованную процедуру CANopen boot-up. CANopen Manager API совместимо со спецификациями CIA 301 [15], CIA 302, и CIA 405. Подробнее см. CANopen Manager API на сайте IXAAT (строка для поиска Software package for the implementation of complex PC-based CANopen control solutions site:ixxat.com).

[Инструменты для обслуживания и диагностики CANopen]

CANopen Device Manager. Это универсальный и обновляемый инструмент, нацеленный на тестирование устройства, диагностику и полевые испытания. Он построен на основе центрального компонента, который управляет сервисами CANopen и предоставляет главную точку входа для определения сети. CANopen Device Manager закрывает функционал наподобие узла NMT и управление ошибками, клиента SDO (включая блочную передачу с CRC), PDO producer и PDO consumer, SYNC producer и time stamp producer. Он также позволяет осуществлять загрузку DCF и загрузку firmware в соответствии со спецификацией CiA 302, LSS master по спецификации CiA 305. Как опциональный аддон предоставляется система скриптов Python, что позволяет реализовать мощные тестовые приложения.

Подробнее см. CANopen Device Manager на сайте IXAAT (строка для поиска Powerful CANopen service and diagnostics tool for service staff and developers site:ixxat.com).

[Онлайн-анализ, симуляция и интерпретация данных]

canAnalyser с модулем CANopen. Программа canAnalyser является мощным и разносторонним инструментом для разработки, тестирования и обслуживания сетей на основе CAN/CANopen.

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

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

Хост скриптов (Scripting Host) комбинирует графический интерфейс пользователя с гибкостью скриптов. С помощью использования Scripting Host canAnalyser можно быстро и просто адаптировать для специфических задач измерений и анализа. Это позволяет пользователю симулировать устройства и протоколы, или тестировать существующие устройства на моделируемых шинах, и помещать их в рабочее состояние. Специальное тестовое окружение может быть просто реализовано на любых интерфейсных компонентах Windows. Scripting Host поддерживает стандартные скриптовые языки C# и Visual Basic .NET. Объединение модулей DLL также позволяет интеграцию в другие модули.

Подробнее см. canAnalyser 3 Suite на сайте IXAAT (строка для поиска canAnalyser 3 Suite site:ixxat.com).

[Интерфейсы]

Платы и модули CAN. HMS предоставляет широкий диапазон плат CANopen, обслуживая широкий диапазон обычных интерфейсов PC для всех требований приложений:

• PCI, PCIe, PCIe Mini, PCIe 104
• PC/104, ISA
• Ethernet
• USB
• Bluetooth

Подробнее см. IXXAT CAN interfaces на сайте IXAAT (строка для поиска IXXAT CAN interfaces site:ixxat.com).

Этот продукт доступен в нескольких основных версиях: Evaluation, Ultimate и Pro Ultimate. Версия Ultimate имеет разные наборы опций отличающиеся друг от друга по стоимости (в комплекте идут разные аппаратные интерфейсы). Ниже приведен список возможностей CANopen Magic Ultimate. The list is not exhaustive by any means, but does give a good overview of the abilities of CANopen Magic Pro Ultimate.

• SDO Upload (чтение из узла сети).

- Отображение прочитанных данных в формате ASCII.
- Отображение прочитанных данных в как десятичных целых чисел со знаком, беззнаковых целых чисел и в формате real.
- Отображение прочитанных данных в шестнадцатеричном формате.
- Отображение прочитанных данных в форматах времени дня (TIME OF DAY) и разницы во времени (TIME DIFFERENCE).
- Сохранение прочитанных данных в файл.
- Автоматический выбор наиболее подходящего типа данных для элемента.
- Ручной выбор элемента.
- Выбор элемента из списка конфигурируемого OD.

• SDO Download (запись в узел сети).

- Ввод данных для записи в формате ASCII.
- Ввод данных для записи в формате десятичного целого со знаком, без знака и в формате real.
- Ввод данных для записи в шестнадцатеричном формате.
- Ввод данных для записи в форматах времени дня (TIME OF DAY) и разницы во времени (TIME DIFFERENCE).
- Данные для записи могут быть прочитаны из файла.
- Автоматический выбор наиболее подходящего типа данных для элемента.
- Ручной выбор элемента.
- Выбор элемента из списка конфигурируемого OD.

• Управление сетью (NMT) для всех узлов или для одного узла.

• Сканирование сети для получения информации о доступных узлах.

• Можно подключить одновременно к сети CAN другие средства разнаботки PEAK.

• Автоматическое запоминание позиций и настроек позиций окон, аппаратных и сетевых конфигураций.

• Передача конфигурируемых сообщений.

- Выбор набора идентификаторов (ID) по умолчанию для сетевого соединения.
- Ручной ввод ID.
- Выбор определяемых пользователем ID сообщений.
- Периодическая передача с настраиваемым периодом.
- Передача нажатий на кнопки.
- Передача при получении сообщения с определенным ID.
- Конфигурируемые содержимое и длина сообщения.
- Есть возможность передачи сообщений RTR (Remote Transmission Request).
- Обзорное отображение всех сконфигурированных сообщений.
- Можно давать сообщениям понятные описательные имена.

• Описание сети (Network Description) и её конфигурирование.

- Указание имен для узлов сети.
- Указание EDS для узлов сети.
- Указание имен для сообщений.

• Сохранение конфигураций узла в файлах описания устройства (Device Configuration Files, DCF).

• Восстановление конфигураций из файлов DCF.

• Сохранение всех конфигураций узлов в файл конфигурации сети (Network Configuration File, NCF).

• Восстановление всех конфигураций узлов из файла NCF.

• Обзорный вид на сеть (Network Overview Display).

- Автоматическое сканирование сети на наличие в ней узлов.
- Предоставляется быстрый обзор доступных узлов и базовой информации о них.
- Постоянно отображается текущее состояние узла и последняя ошибка.
- Установка всех heartbeat-ов для всех узлов за один раз.

• Быстрое конфигурирование PDO.

- Автоматическое сканирование на наличие PDO, определенных на узле.
- Быстрое и простое конфигурирование коммуникационных параметров PDO.
- Быстрое и простое конфигурирование параметров отображения на PDO (PDO mapping).
- Выбор для объектов PDO набора идентификаторов соединения (ID) по умолчанию.
- Ручной ввод идентификаторов ID для объектов PDO.
- Выбор определяемых пользователем идентификаторов для объектов PDO.
- Разрешение и запрет PDO одним кликом.
- Разрешение и запрет одним кликом всех PDO, определенных для узла.

• Конфигурирование отображения трассировки (Configurable Trace Display).

- Запуск и остановка для анализа трассировки.
- Сохраняется до 13000+ сообщений (0.5 секунд на скорости 1 мегабит при 100% загрузке шины).
- Интерпретация сообщений CANopen позволяет просто просматривать активность сети.
- Отображение имен, определенных пользователем.
- Фильтрация отображаемых сообщений.
- Можно открыть до 4 окон трассировки, с индивидуальными настройкой и фильтрацией.
- Непрерывный режим, показывающий каждое сообщение на шине.
- Статический режим, показывающий последнее сообщение для каждого ID на шине.
- Абсолютные метки времени (timestamps) с точностью 1 мкс.
- Относительные метки времени с точностью 1 мкс, показывающие время между следующими друг за другом сообщениями.
- Экспорт трассировки в формате CSV с нарастанием (ascending CSV) и убыванием (descending CSV) с целью последующего анализа в Excel.
- Отображение содержимого сообщения в шестнадцатеричном формате.
- Отображение содержимого сообщения в десятичном знаковом и беззнаковом формате.
- Отображение содержимого сообщения в формате ASCII.
- Отображение сырого содержимого сообщения.
- Опциональное отображение фреймов ошибки.

• Фильтрация отображения трассировки с помощью диапазонов ID или скриптовой системы.

• Конфигурируемое отображение данных процесса (Process Data).

- Может быть показано любого количество элементов данных процесса.
- Обновление при детектировании объектов PDOs в сети.
- Конфигурируемое графическое отображение данных в нескольких форматах.
- Добавление меток и графики для создания интерфейсов продукта.
- Отображение графиков аналоговых данных.

• Файлы проекта.

- Сохранение и загрузка настроек в файлах проекта.
- Запуск приложения с проектом через командную строку.

• Конфигурирование на узлах LSS.

- Автоматическое детектирование одиночных узлов.
- Конфигурирование идентификаторов ID узла.
- Конфигурирование битовых интервалов (bit timings, скорость по шине).

• Работа со всеми CAN-интерфейсами PEAK-System Technik.

• Мониторинг последней аварии (emergency), переданной текущим выбранным узлом.

• Интерфейс командной строки для программирования через BAT-файлы и тестирования линейки конечной продукции.

• Можно запустить одновременно, в той же самой сети, вместе с другими совместимыми инструментами, включая PCANExplorer и PCANView.

• Конфигурируемые таймауты SDO и LSS.

• Система симуляции узла (CANopen Node Simulation System).

- Можно симулировать за 1 раз до 127 узлов CANopen.
- Симулируемые узлы могут обмениваться друг с другом и реальными узлами.
- Реакция на NMT, объекты SDO, PDO, LSS и другие функции, поддерживаемые стеком - CANopen, используемая для постройки симулируемых узлов.
- Симулируемые узлы могут быть доступны из CANopen Magic Ultimate как если бы это были реальные узлы, с использованием всех функций CANopen Magic Ultimate.
- Можно использовать для разработки узлов перед тем, как станет доступной аппаратура.
- Просмотр содержимого образа процесса симулируемого узла.
- Просмотр OD симулируемого узла.
- Создание графического управления вводом и выводом, чтобы управлять и визуализировать I/O симулируемого узла.
- Сохранение всех настроек симуляции в проекте и файлах Sim IO, чтобы можно было обмениваться ими с другими инженерами.
- Моделирование коробочных коммерческих продуктов и тестирование их интеграции в свою пользовательскую сеть.
- После завершения симуляции узлов просто перепишите аппаратный драйвер для переназначения конфигурации узла на аппаратуру.
- Поддержка MicroLSS/LSS Fastscan.
- Поддержка добавляемого профиля устройства CiA 447 (CiA 447 Car Add-On Device Profile).
- Постоянная запись в лог и воспроизведение симуляции с опциями паузы и пошагового выполнения.

Страничка с общим описанием: CANopen Magic site:canopenstore.com.