Протокол высокого уровня CANopen. Часть 1
В наше время насчитывается большое количество интерфейсов последовательной передачи данных. Некоторые из них, например, RS-232, USB, SPI, приобрели огромную популярность благодаря своим характеристикам или простоте использования. Другие же не нашли столь широкого распространения в электронных системах. К ним можно отнести IEEE 1394, RS-449, Х.21. Некоторые стандарты последовательных интерфейсов и вовсе быстро забывались после их разработки, чего нельзя сказать о стандарте CAN (Controller Area Network), разработанном в 1987 году немецкой компанией Robert Bosch GmbH и ставшим, пожалуй, самым популярным интерфейсом последовательной передачи данных в автомобильной отрасли и промышленном оборудовании. Благодаря высокой надежности, довольно высокой скорости передачи данных (до 1 МБ/с) и гибкости настройки и применения, этот интерфейс поддерживается множеством электронных устройств (промышленные контроллеры, микроконтроллеры, специализированные микросхемы, датчики). На сегодняшний день последней версией протокола является CAN 2.0b.
Стандарт CAN описывает поведение сигналов на низком уровне, причем в отрыве от физического уровня, то есть для передачи данных могут использоваться различные среды (медный кабель, оптоволокно и т.п.). Для ускорения проектирования сетей на основе CAN и стандартизации работы таких сетей был разработан протокол высокого уровня CANopen. Он получил широкое распространение в промышленном оборудовании, транспортных средствах, медицинском оборудовании, системах «умный дом». Этот протокол является открытым, и документация по его использованию доступна каждому. DS.301 представляет собой основной документ, в котором описаны основные положения и принципы работы CANopen. В связи с тем, что протокол ориентирован на использование в составе различных классов устройств, в документах CiA DS-4xx регламентируется работа CANopen в каждом из них. Так, например, CiA 412 относится к медицинскому оборудованию, а CiA 417 – к системам управления лифтами.
Топология сети CAN, принципы ее работы и форматы кадров подробно описаны в [1] и [2], поэтому не имеет смысла повторяться, а стоит перейти непосредственно к рассмотрению протокола высокого уровня CANopen на базе данной сети. На Рисунке 1 показана функциональная схема связи двух узлов с помощью шины CAN и протокола CANopen.
| Рисунок 1. | Коммуникационные уровни при соединении двух узлов. |
Основной функциональной единицей протокола является объект. Под объектом может пониматься набор данных, несущих информацию о параметрах (например, показания датчика температуры), конфигурации узла или сети, возникших ошибках и т.п. Поэтому для устройства (узла) необходимым условием работы в сети является наличие словаря, представляющего собой группу доступных в определенном порядке объектов. По своей сути, словарь объектов – это связующее звено между приложением и передаваемой на физическом уровне информацией (Рисунок 2). С каждым устройством, использующим интерфейс CANopen, производитель должен предоставить файл с расширением *.eds (Electronic DataSheet), содержащий словарь объектов и дополнительную информацию.
| Рисунок 2. | Модель устройства с интерфейсом CANopen. |
CANopen-устройство имеет три условных составляющих: программный модуль обработки протокола и пакетов интерфейса, словарь объектов и программное обеспечение на уровне приложения. Модуль обработки протокола непосредственно отвечает за передачу и прием коммуникационных объектов по шине. Словарь объектов описывает все типы данных, коммуникационные объекты и объекты приложения, используемые в данном устройстве. Программное обеспечение на уровне приложения выполняет функции внутреннего управления и обеспечивает связь с другими устройствами, не использующими шину CAN.
Каждый объект в словаре имеет 16-разрядный индекс и 8-разрядный подиндекс. С помощью них можно ссылаться на данный объект. В Таблице 1 показан пример описания идентификационного объекта, содержащего основную информацию об устройстве.