CAN протоколы высокого уровня
Введение
CAN протокол получил всемирное признание как весьма универсальная, эффективная, надежная и экономически приемлемая платформа для почти любого типа связи данных в передвижных системах, машинах, техническом оборудовании и индустриальной автоматизации. Основанная на базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных систем автоматизации. Под терминами CAN стандарт или CAN протокол понимаются функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в соответствии с 7-ми уровневой OSI моделью. CAN стандарт соответствует уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация даже весьма простых распределенных систем на базе CAN демонстрирует, что помимо предоставляемых сервисов уровня канала данных требуются более широкие функциональные возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти дополнительные функциональные возможности непосредственно используются прикладным циклом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня. Обычно их и называют термином CAN протоколы.
OSI модель протоколов высокого уровня на базе CAN,протоколов TCP/IP
Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми уровневой модели OSI( 1). Это связано с тем, что типичная CAN система имеет в своей основе единственный канал данных для обмена сообщениями между устройствами, все устройства ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень приложений( 2). Причем последний реализует некоторые функции транспортного уровня.
1
2
Из-за широко использования CAN сетей с различными целями и требованиями существуют несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP.
Основные возможности протоколов высокого уровня на базе CAN
Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня:
- система назначения идентификатора для сообщения
- метод обмена данных цикла
- прямая(peer-to-peer) связь
- метод установления связей для обмена данных цикла
- сетевое управление
- модели и профайлы устройств
Идентификаторы сообщений
Метод назначения идентификатора сообщения является главным архитектурным элементом CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет сообщения и следовательно время обработки сообщения (latency time). Это также влияет на возможность применимости фильтрования сообщения,на использование возможных коммуникационных структур и эффективность использования идентификатора. Что касается назначения идентификаторов сообщений, существуют различные подходы для систем на базе CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур системы, DeviceNet и SDS делают это.
Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в одной из 3-х групп в зависимости от приоритета сообщения ( 3).
3
Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений - до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.
DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации ( 4):
4
Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit) сообщениями между Master и Slave устройствами из предопределенного множества связей:
- явный канал сообщений
- изменение Master статуса канала (Master Poll Change of State/Cyclic channel)
- изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel )
- Bit Strobe канал
Явный канал сообщений главным образом служит для конфигурации устройства. С изменением Master статуса канала Master может запрашивать данные ввода - вывода от устройства и посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может запросить данные у любого из 64 Slave устройств посредством одного сообщения.
Oбмен данных цикла
Передача данных цикла между устройствами распределенной системы - цель системы на основе CAN протокола. Поэтому передача прикладных данных (данные цикла, данные ввода - вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet обеспечивают весьма схожие механизмы связи для передачи данных обслуживания / конфигурации цикла. У CANopen передача данных цикла происходит посредством так называемых Объектов Данных цикла (PDOs), у DeviceNet посредством I/O-сообщений .
В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS. Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также поддерживаются 3 различных протокола ( 4) по отношению к подтверждению приема данных (Transport Classes) . Например, классы 2 и 3 могут быть использованы для эффективного опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты (connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2 или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных.
Таблица 1. Exchange of Process Data in CANopen, DeviceNet and SDS (Multicasting)
| CANopen | DeviceNet | SDS (V2.0) | | Name of Communication Object | Process Data Object | I/O-Message | Multicast Channel APDU | | Maximal Number of Communication Objects per Device | 512 Transmit PDOs 512 Receive PDOs | 27 I/O- Transmit Messages 1701 I/O Receive Messages per device 32 Multicast Channels for each of up to | 32 Embedded Objects per device | | Maximal length of Data Field | 8 bytes | 8 bytes fragmented: Arbitrary length | 6 bytes fragmented: 64 * 4 bytes | | Protocol | Unfragmented: No overhead, Notify/Read Stored-Event-protocol (CAL/CMS) Unacknowledged | Unfragmented: No overhead, three Transport Classes supported: - Unacknowledged,
- Acknowledged by Server Connection Object,
- Acknowledged by Application
| Unfragmented: 2 byte protocol overhead, Unacknowledged | | Fragmented: Unacknowledged fragmented protocol 1 byte protocol overhead per frame | Fragmented: Acknowledged fragmented protocol with Acknowledge after reception of complete block 4 bytes protocol overhead per fragment | | Message Production Triggering Modes | - On Request of local or remote application
- Cyclic/acyclic synchron
| - Cyclic
- Change-of-State
- Application specific
| Specified by object model | | Mapping of Application Objects | Maximum number of mappable application objects/PDO dependent on data size of objects (1-bit objects: 64 application objects mappable) Definition of Application objects by means of Mapping Parameter Record (configurable) Dynamic mapping supported | Arbitrary number of Application objects mappable with fragmented protocol. Definition of Application objects by means of Assembly Object (several Assembly Objects possible) Dynamic mapping supported | Network Data Descriptor defines size, granularity and data type of I/O data of Embedded Object (V1.8) |
5. Device Net Transport Classes
Вызов (triggering) сообщений
Все рассматриваемые протоколы поддерживают различные способы вызова сообщений. DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный (Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера и опять начинается передача сообщения. Передача по состоянию опять начинается, когда статус определенного объекта изменяется. В этом случае сообщение также передается, когда истекает определенный интервал времени, в котором не осуществлялась передача сообщения. Программным способом сам объект решает, когда начать передачу сообщения. В этом случае сообщение также передается, когда истекает определенный интервал времени без передачи сообщения.
Установление соответствий (mapping) для программных объектов
Сетевые устройства обычно содержат более одного программного объекта и передача I/O сообщения более чем одному программному объекту внутри одного PDO является необходимым требованием. В DeviceNet объединение прикладных данных осуществляется посредством трансляционных (assembly) объектов, которые определяют формат передаваемых данных. Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего (consumed/ produced_connection_path) может быть настраиваемой опцией устройства.
Прямые (peer-to-peer) коммуникационные каналы
Для конфигурации устройств посредством конфигурационных средств требуются специальные функции у устройств или программы, обеспечивающие многоцелевые каналы связи. Это не критичные по времени каналы связи. Передача данных в них осуществляется посредством протокола с подтверждениями и фрагментацией. Любой из протоколов высокого уровня, которые поддерживают некоторую конфигурацию устройств, должны обеспечивать этот вид связи.
DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.), сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit) сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific arguments).
6. DeviceNet Fragemented Explicit Message Data Field Format (Request/Response)
Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы, которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit соединение в предопределенном множестве соединений. Запрос к устройству группы 2 передается как Explicit запрос без предварительного установления соединения (Unconnected Explicit Request ) с зарезервированным идентификатором сообщения.
Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых (peer-to-peer) коммуникационных каналов представлены в таблице 2.
Таблица 2. Main Characteristics of Peer-to-Peer Communication Channels
| CANopen | DeviceNet | SDS (V2.0) | | Name | Service Data Channel | Explicit Message | Peer-to-peer Channel | | Maximum number of channels | 128 Client SDOs, 128 Server SDOs per device | 27 Explicit Transmit Messages 1701 Explicit Receive messages per device | 4 channels per Embedded Object. 32 Embedded Objects per Logical Device | | Protocol | < 5 byte: Acknowledged unfragmented 4 byte: Fragmented transmission (7 bytes per fragment) Each frame acknowledged Any length (CAL Multiplexed Domain protocol) | < 7 byte: Acknowledged unfragmented 6 byte: Fragmented transmission. (6 bytes per fragment) Each frame acknowledged Any length | < 6 bytes Acknowledged unfragmented 5 byte Fragmented transmission (3 bytes per fragment) Acknowledgement of complete data block. Max. 255 byte | | Establishing of Connections | - Dynamic establishment by means of Unconnected Message Manager
- Group 2 Only devices: Allocation of Explicit Message from Predefined Connection Set
| - Dynamic establishing by means of Connection Manager
- Master/Slave Set of Connections Set
| - Dynamic establishment by means of SDO Manager
- Default predefined connections
| | Connection Services and Arguments | Initiate, Abort Upload/Download Segment/Domain | Open/Close Creation, Configuration, Start, Stop, Reset etc. of Objects | Open/Close Read, Write, Event, Action | | Index and Subindex of addressed | Object Directory Entry Object attribute access path, Service arguments | Channel Number, Attribute/Action/Event Identifier | Установление связей для обмена данных цикла
Распределение идентификаторов для передаваемых сообщений и , соответственно, получаемых сообщений устанавливает коммуникационные пути в CAN сети. Установление взаимодействия возможно через использование предопределенного множества сообщений с уже размещенными идентификаторами сообщений или через переменное распределение идентификаторов для сообщений.
В системе с предопределенным множеством сообщений функции и идентификаторы сообщений уже определены. DeviceNet также использует предопределенное множество сообщений для системы со структурой 1:n. Master устройство, предварительно разместив у себя множество связей со Slave устройствами, знает ID сообщений для передачи запроса и ID сообщений для получения ответа, который включает Slave MAC-ID в соответствии с предопределенным множеством связей. Также возможно не предопределять идентификаторы сообщений.
Сетевое управление
Так как в CAN-сети мы имеем дело с распределенными приложениями, должны отслеживаться определенные события(отказы различных частей приложения или отказ устройств). Поэтому главными задачами сетевого управления становятся обнаружение и вывод ошибок в сети и предоставление сервисов, позволяющих контролировать статусы устройств и вести координацию устройств. В зависимости от системных решений сетевое управление может вестись явным или косвенным путем.
В DeviceNet каждое соединение контролируется. Поэтому каждая ожидающая сообщение конечная точка имеет Inactivity/Watchdog таймер, чтобы контролировать прибытие сообщения согласно предопределенному времени ожидания. Если время истекает, соединение выполняет действие Timeout. На 7 показана диаграмма изменения состояний у объекта I/O.
7. Device Net I/O Connection Object State Transition Diagram
После получения вызова CREAT ( Explicit сообщение) соединение настраивается при помощи подходящей последовательности вызовов явных сообщений и после этого устанавливается. Перед получением доступа к сети каждое устройство должно совершить проверку на дубликат своего MAC-ID. Определенные алгоритмы выбора гарантируют уникальность MAC-ID.
Контроль может осуществляться также посредством Heartbeat сообщения, которое может посылаться устройствам посредством UCMM в форме сообщения. В поле данных этого сообщения передается состояние устройства. Heartbeat сообщение вызывается объектом Idendity.
Профайлы устройств
Для открытых автоматических систем помимо обеспечения связи от входящих в их состав устройств требуется также обеспечение возможности взаимодействия и взаимозаменяемости. Поэтому протоколы высокого уровня (такие как DeviceNet) описывают функциональные возможности устройств в виде модели устройства (Device Model).
Помимо описания функциональности устройств модель устройства должна также содержать ряд важных параметров (статус, диагностическую информацию, коммуникационные возможности, конфигурационные параметры и т.д.). На 8 показана модель устройства DeviceNet.
8. DeviceNet Object Model
DeviceNet профайл должен содержать следующую информацию:
- модель объекта для устройства
- формат данных I/O для устройства
- конфигурационные данные и внешние интерфейсы для этих данных
В таблице 3 показаны главные функции объектов в DeviceNet.
Таблица 3. Objects of a DeviceNet node
| Object | Function | | Connection | Instantiates connections (I/O or Explicit Messaging) | | DeviceNet | Maintains configuration and status of physical attachments to DeviceNet. | | Message Router | Routes received Explicit Messages to appropriate target objects | | Assembly | Groups attributes of multiple objects into a single block of data, which can be sent and received over a single connection | | Parameter | Provides a standard means for device configuration and attribute access | | Identity | Provides general information about the identity of a device | | Application | Supplies application-specific behaviour and data | Заключение
Протокол CAN применяется в real-time системах для решения различных задач. В настоящий момент развиваются несколько видов CAN протоколов высокого уровня, таких как CAL ,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в основе которых лежит канальный протокол CAN2.0 (Bosch) , и на основе этих протоколов можно решать проблемы, возникающие в real-time системах, которые невозможно разрешить при помощи других известных протоколов, скажем, TCP/IP.
Источник: http://gaw.ruЧитайте далее: Колесо и палка. Размышления., ЧТО ТАКОЕ 'ТЕПЛОВОЕ ЗЕРКАЛО'?, Микросхемы - усилители низкой частоты (4), Я вам пишу… без опасений. О криптографии..., Предельные значения величин, Техника, Числа, Громкоговоритель Карфидова, Частицы и вещества, СОЗДАН НОВЫЙ СВЕТОДИОДНЫЙ СВЕТОФОР СПЕЦИАЛЬНО ДЛЯ РОССИЙСКИХ ЖЕЛЕЗНЫХ ДОРОГ, Уран в стеклянной клетке, Компьютеры и средства связи, Ураган из улитки, Микросхемы - усилители низкой частоты (6), Удивительное в физике - рядом., НОВЫЙ ПРИНЦИП ПРЕОБРАЗОВАНИЯ СОЛНЕЧНОЙ ЭНЕРГИИ, РАДИОИМПУЛЬС ЗАСТАВЛЯЕТ ВЕЩЕСТВО ФОНТАНИРОВАТЬ, IrDA, TMP05, TMP06 - Температурные датчики с точностью измерения температуры ±1 C, ШИМ,
|
