Введение
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:
|
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 |
|
|
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 |
|
|
|
| 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.