Что такое sdo и pdo

Введение в CANopen

Общая схема связи устройств в CANopen

Протокол CANopen определяет несколько методов передачи сообщений по сети CAN. Эти сообщения называются объектами связи (communication objects). CANopen поддерживает синхронизованную передачу сообщений, которая обеспечивается объектами Sync и Time Stamp. Асинхронные сообщения (или события) могут пересылаться в любой момент времени. В целом CANopen определяет четыре типа сообщений (communication objects):

Инициализация и управление сетью

Сервис управления сетью используется для контроля состояния устройств в сети CANopen. В рамках сервиса управления сетью доступны следущие функции:

Механизм передачи данных

CANopen определяет два совершенно разных механизма передачи данных.

Service Data Object (SDO) механизм обычно используется для конфигурирования устройств низкой приоритетности. Отдельные параметры устройства адресуются при помощи 16 битного адреса и 8 битного подадреса. С помощью SDO можно передавать данные длиной больше восьми байт используя механизм фрагментации. Функциональность SDO:

Все параметры устройства объеденены в object dictionary (словрь объектов), и все объекты в object dictionary могут быть прочитаны или изменены удаленно при помощи SDO.

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

События

CANopen поддерживает несколько способов передачи данных реального времени.

При возникновении какого-либо события можно послать PDO сообщение. Например, устройство дискретного ввода-вывода может отсылать состояние своих выводов в сеть при их изменении. Такой способ позволяет минимизировать загрузку сети и увеличить ее пропускную способность.

Возможен синхронный режим передачи данных. В этом режиме устройства синхронизируют передачу данных в сеть с часами Master устройства. Этот режим особенно полезен когда контуры управления замыкаются через сеть (так называемые сетевые системы управления).

Кроме перечисленных выше способов передачи данных, можно использовать передачу по запросу (polling). В любой момент можно использовать PDO сообщение для инициации передачи данных устройством. Эта схема использует RTR бит CAN кадра.

Источник

Использование сети CAN и стека CANopen

Однажды передо мной встала задача разработать встраиваемую систему, в которой бы данные могли передаваться между узлами c максимальной надежностью. Тогда то я впервые и узнал о CAN.

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

CAN (Controller Area Network) — это стандарт, созданный компанией Bosсh для сетей, используемых в автоматизации и промышленности. Стандарт нашел широкое применение в промышленном производстве, технологиях «умного дома», а так же в автомобилестроении. Очень хорошо подходит для связывания различных датчиков и управляющих устройств в единую сеть.
Как правило, CAN-сеть это сеть типа «шина», в которой все узлы могут передавать и принимать данные.
Она обладает небольшой скоростью, но высокой надежностью.

Далее я хочу поверхностно описать стандарт и рассказать об использовании такой сети на практике.

Стандарт

Стандарт описывает канальный уровень и базовые требования к физическому уровню.
Главное в физическом уровне — это требование возможности передачи бита как «доминантного» и «рецессивного«. Доминантный сигнал считается единицей, а рецессивный — нулем. Основное требование — при передаче доминантного и рецессивного сигнала одновременно, всем узлам должен прийти доминантный сигнал. На этом принципе основан механизм арбитража. Из этого следует, что для передачи могут использоваться разные среды, однако на практике чаще всего используют дифференциальную пару.

Передача в сети происходит кадрами. В стандарте существуют два типа кадров: базовый и расширенный.
Базовый кадр содержит 11 битовый идентификатор, а расширенный — 29 битовый. Кадр так же содержит бит запроса на передачу, информацию о длине передаваемых данных и сами данные. Они могут занимать от 0 до 8 байт в кадре. Так же кадр содержит некоторую служебную информацию, но для программиста она не принципиальна, поскольку её добавление реализовано аппаратно в контроллере сети.
Изначально идентификаторы не привязаны к какому либо узлу и характеризуют именно сообщение, а не отправителя и получателя. Идентификаторы так же показывают приоритетность сообщения. Приоритет определяется доминантными битами в идентификаторе. Так 10000000000 приоритетнее чем 01000000000.

Главным достоинством CAN является его надежность. В нём используется механизм разрешения коллизий (в отличие от механизма обнаружения коллизий в Ethernet), что позволяет не терять пропускную способность из-за коллизий.
Его суть заключается в том, что каждый узел слушает сеть и, если она свободна, может начать передачу. При этом, он продолжает слушать сеть. Если при посылке рецессивного бита принимается доминантный, значит одновременно с этим узлом начал передачу другой узел с более высоким приоритетом. В этом случае передача прекращается.

Помимо этого используются механизмы обнаружения ошибок, такие как контроль передачи, дополняющие биты, использование контрольной суммы и проверка значений полей. Разработчики оценивают вероятность невыявления ошибки передачи как 4,7×10-11.

Данный стандарт не описывает протоколы верхнего уровня, поэтому было создано несколько реализаций, как коммерческих, так и открытых.
Наиболее известные из них:
— CANopen
— DeviceNet
— CAN Kingdom

Эту и даже более подробную информацию о стандарте легко найти в интернете, поэтому я наконец приступаю к описанию CANopen.

CANopen

Как я уже писал, однажды мне потребовалось создать надежную сеть из микроконтроллеров. После рассмотрения возможных вариантов было решено остановиться на сети CAN. В качестве протокола верхнего уровня был выбран CANopen и его реализация — CANopenNode, поскольку она является открытой и простой в портировании на нужное мне устройство. CANopenNode лицензирован под LGPL.

Основные моменты протокола CANopen:
— протокол работает со стандартными идентификаторами. Сеть может содержать до 127 узлов.
— каждому узлу выдается уникальный номер в сети.
— протокол не требует обязательного наличия мастера сети (однако существуют возможности, которые доступны только одному узлу в сети, который условно можно назвать мастером)
— OD (Object Dictionary ) — словарь объектов. Содержит отсортированный список переменных, доступ к которым можно получить по сети с помощью SDO.
— SDO (Service Data Objects) — механизм доступа к словарю объектов. Для доступа к объектам узла сети на этом узле должен быть запущен так называемый SDO-сервер. В сети может быть только один SDO-клиент, условно называемый мастером, который может получать данные от любого из серверов.
— PDO (Process Data Objects) — объекты для быстрого взаимодействия между узлами. Могут содержать до 8 байт данных и передаются в одном кадре. Для каждого PDO выделяется свой идентификатор (в определенном диапозоне). PDO условно делятся на входящие (RPDO) и исходящие (TPDO). Изначально предполагается, что каждый узел будет иметь по 4 RPDO и 4 TPDO, однако их можно перераспределить между узлами вплоть до того, что один узел будет иметь возможность принимать и передавать до 512 PDO. Однако в этом случае на другие узлы идентификаторов не хватит.
PDO могут посылаться по таймеру, по наступлению определенного события либо по прямому запросу на посылку из управляющей программы.
— NMT (Network Management) — менеджер сети. Сообщения этого типа могут переводить узлы в разные состояния (инициализация, рабочее, предрабочее, остановленное), а так же с их помощью обеспечивается контроль работы сети — механизм heartbeat.
— Heartbeat — переводится как сердцебиение. Суть механизма заключается в том, что каждый узел передает в сеть определенное сообщение, уникальное для каждого узла (ID получается путем прибавления номера узла в сети к определенному числу). Любой узел, который хочет узнать, по прежнему ли ему доступны узлы с определенными id должен просто принимать и обрабатывать эти сообщения. Сообщения от неинтересных для него узлов могут игнорироваться.
— Emergency message — в протоколе предусмотрена посылка сообщений об аварийных ситуациях.
— EDS (Electronic Data Sheets) — специальные текстовые файлы, позволяющие настроить словарь объектов. Существуют программы, помогающие в генерации таких файлов.

CANopenNode

CANopenNode — открытая реализация протокола CANopen, написанная на чистом С для использования в микроконтроллерах.

Теперь я опишу особенности, с которыми мне пришлось столкнуться при работе с CANopenNode.
1. Я использовал 32-битный контроллер, а CANopenNode изначально написан для 8/16 битных. Из-за этого в одном месте таймер сходил с ума, поскольку вместо того, чтобы переполниться и, как следствие, обнулиться, он продолжал расти и в механизме хартбита выдавалась ошибка о том, что поголовно все узлы превысили время ожидания нового хартбита.
2. Моя задача предполагала, что я могу передавать большие объемы данных. При этом несколько контроллеров могли передавать эти данные, а остальные — получать. Пришлось отказаться от механизма SDO (поскольку в нем только один контроллер имел бы возможность посылать данные с размером больше чем 8 байт) и написать свою собтвенную надстройку, которая использовала первые два байта PDO в виде управляющей информации.
3. Решение из пункта два привело к тому, что мне потребовалось однозначно определять участников взаимодействия, что возможно сделать только с помощью идентификаторов.
Это был, пожалуй, самый тонкий момент в работе. Было решено ограничить количество «мастеров» четырьмя штуками. Эти четыре узла получали 127 PDO на вход и на выход. А остальные узлы работали с 4 входящими и исходящими PDO. При чем, идентификаторы PDO были распределены так, что узлы-«ведомые» имели по одному исходящему сообщению, каждое из которых читал только определенный «мастер» и по одному входящему сообщению от каждого «мастера». Мастера же соответственно имели по одному каналу для обращения лично к любому из «ведомых» и точно знали, кто из них обращается к нему.
Эта концепция была сложнее всего, так как даже на форумах, где люди работают с CAN, бытует мнение, будто CANopen нельзя настроить подобным образом.
4. Настройка идентификаторов в данном протоколе происходит в коде. Более того, от неё зависят id узлов, которые будет читать и принимать конкретный узел. Поэтому смена id на ходу представляется сложной для данного протокола и требует дополнительных усилий.

В виде заключения

В конце концов, я пришел к выводу, что данный протокол не совсем хорошо ложится на мою задачу и что мне придется написать свою реализацию. Однако, за время, которое я провел, разбираясь с этим протоколом, я намного лучше понял принципы работы с сетью CAN. Если Вам нужно быстро получить работающее приложение, использующее все преимущества надежной доставки, если Вы хотите, чтобы Ваше приложение было совместимо со многими уже существующими системами, если Вам нужны готовые средства отладки CAN-сети, то CANopen — это очень хороший выбор.

Я с удовольствием отвечу на любые вопросы, принимаю критику и дополнения, а так же могу подробнее остановиться на каких-либо моментах, если кому-нибудь это будет интересно.
Спасибо Вам за внимание!

Ссылки на некоторые ресурсы, связанные с CAN

www.can-cia.org — (англ.) международная организация CAN in Automation.
sourceforge.net/projects/canopennode — (англ.) проект CANopenNode

UPD:
Забыл добавить еще один интересный момент, который некоторое время вводил меня в заблуждение. Я отлаживал свою сеть на двух контроллерах, которые я соединил напрямую.
1. Когда я перепрошивал один из контроллеров, сеть на втором начинала выдавать ошибки (начинали часто-часто мигать лампочки — поведение, определенное в стеке CANopen). При обычной перезагрузке контроллера такого не происходило. Возможно, это специфика конкретного контроллера, но на всякий случай это стоит иметь в виду.
2. Протокол CANopen спроектирован таким образом, что если сообщение с определенным id не было отправлено до того момента, как оно должно быть отправлено еще раз, то это тоже вызывает ошибку. При том, каждый узел сети каждую секунду посылает хартбит-сообщение. Поэтому даже если вы ничего не отправляете, то всё равно можете получить ошибку сети.

Источник

Протокол высокого уровня CANopen. Часть 1

Приводятся основные положения и правила работы протокола CANopen, описываются основные элементы и коммуникационные объекты протокола, поясняются правила организации связи на основе этих объектов.

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

Протокол CANopen предполагает существование следующих типов объектов:

SDO обеспечивают доступ к элементам словаря объектов, то есть, с помощью SDO можно читать и записывать информацию в словарь объектов. При связи посредством SDO между двумя устройствами устанавливается соединение типа «точка-точка», причем будет реализована клиент-серверная модель коммуникации, где устройство-клиент передает необходимое сообщение, а устройство-сервер выдает соответствующий этому сообщению ответ, в соответствии со схемой, изображенной на Рисунке 3.

Рисунок 3.	Клиент-серверная модель.

При организации SDO-связи клиент с помощью мультиплексора, содержащего индекс и подиндекс объектного словаря, может предоставлять серверу определенный набор данных, которые будут передаваться. В основном передача SDO реализуется как сегмент-трансферт (segment transfer), при котором передается последовательность сегментов в количестве до 127. Непосредственно до передачи осуществляется стадия подготовки, когда клиент и сервер готовятся к обмену. Если необходимо передать объект размером до 4 байт, такой обмен может быть реализован на стадии инициализации, он также называется ускоренный трансферт (expedited transfer). Существует еще один тип передачи – блок-трансферт (block transfer). При этом передается набор блоков, каждый из которых состоит из 127 сегментов. Один сегмент содержит данные и свой порядковый номер в блоке. SDO описывается параметром связи, определяющим коммуникационные настройки SDO. Эти параметры связи расположены по специально отведенным адресам, и их индексы для SDO-сервера (SSDO) и SDO-клиента (CSDO) вычисляются по следующим правилам:

Для непосредственной передачи полезных данных технологического процесса (температура, скорость, ток, напряжение и т.п.) в реальном времени используются PDO. Передача PDO осуществляется широковещательно, при этом применяется модель производитель-потребитель (producer-consumer), изображенная на Рисунке 4.

Рисунок 4.	Модель производитель-потребитель.

В объектном словаре различаются два типа PDO – для передачи данных (TPDO) и для приема (RPDO). Устройства, в конкретный момент времени выдающие PDO на шину, называются производителями, а принимающие эти PDO – потребителями. PDO также описываются в объектном словаре устройства. Типы данных и отображение объектов в PDO описываются структурой, называемой PDO-отображение (PDO-mapping). С помощью SDO на стадии инициализации можно изменить количество PDO и отображение объектов внутри них. Все PDO описываются структурным параметром (или параметром отображения) и параметром связи, характеризующим коммуникационные возможности PDO. Индексы этих параметров определяются в соответствии со следующими правилами:

С помощью одного PDO можно передать от 1 до 8 байт данных. В одной сети CANopen может присутствовать до 512 TPDO и до 512 RPDO.

PDO могут передаваться как синхронно, так и асинхронно относительно объекта синхронизации SYNC, выдающегося на шину с определенной периодичностью. Это проиллюстрировано Рисунком 5. Синхронные PDO передаются в рамках установленного интервала времени после появления на шине SYNC-объекта.

Рисунок 5.	Принцип передачи синхронных и асинхронных PDO.

Асинхронные PDO передаются без какой-либо связи с объектом синхронизации. Различают также три режима вызова PDO (Рисунок 6):

Передача синхронных PDO может выполняться как в цикличном режиме, так и ацикличном. При выборе цикличного режима PDO передаются с определенной периодичностью, устанавливаемой числом от 1 до 240, т. е. 5 будет означать передачу PDO после каждого пятого появления SYNC-объекта на шине. В ацикличном режиме момент выдачи PDO на шину определяется внутренним событием устройства, но она обязательно должна выполняться в окне SYNC-объекта.

На Рисунке 7 показан принцип отображения PDO, основная идея которого заключается в том, что как производитель, так и потребитель PDO-сообщения должны знать, каким образом им необходимо интерпретировать содержимое этого сообщения. При этом PDO определяются по их идентификационным номерам (COB-ID). PDO-отображение описывает, какие переменные технологического процесса из поля данных PDO должны передаваться, каким образом они должны быть упорядочены, а также какой тип данных и какую длину они имеют. Таким образом, содержание и значение поля данных каждого определенного PDO определяется в виде записи PDO-отображения внутри словаря объектов на стороне производителя и на стороне потребителя.

Рисунок 7.	Принцип отображения PDO.

Производитель составляет поле данных передаваемого PDO в соответствии со своими записями отображения TPDO. В связи с этим, текущие значения отсылаемых данных должны быть взяты из словаря объектов и записаны в поле передаваемых данных до того, как сообщение будет отправлено на шину. Подобные операции выполняются на стороне потребителя. В соответствии с записями отображения RPDO, принятые данные записываются в словарь объектов данного устройства.

Другими объектами, без которых немыслимо существование CANopen-сети, являются NMT-объекты, позволяющие управлять работой этой сети. Вначале стоит отметить, что в конкретный момент времени устройство должно находиться в одном из четырех состояний: инициализация (Initialization), готовность (Pre-operational), работа (Operational) или остановка (Stopped). При включении устройство проходит этап внутренней инициализации, и после ее успешного завершения переходит в состояние готовности. В этом состоянии уже возможно осуществить настройку CANopen-узла с помощью SDO. Затем узел может перейти в рабочее состояние. Для этого необходимо, чтобы Master сети (передача NMT сообщений происходит в соответствии с моделью Master-Slave) передал широковещательное сообщение Start_remote_node. ID NMT-сообщений равен 0, поскольку они должны иметь самый высокий приоритет в сети. В Таблице 2 представлено описание NMT-сообщений.

Источник