Объявление

Свернуть
Пока нет объявлений.

CAN протоколы высокого уровня

Свернуть
X
Свернуть
  •  

  • CAN протоколы высокого уровня

    Введение

    Нажмите на изображение для увеличения.

Название:	pict1.gif
Просмотров:	16
Размер:	21.9 Кб
ID:	1363 alt="" />
    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). Причем последний реализует некоторые функции транспортного уровня.
    Нажмите на изображение для увеличения.

Название:	pict2_1.gif
Просмотров:	8
Размер:	3.8 Кб
ID:	1364 alt="" />
    Рис. 1

    Нажмите на изображение для увеличения.

Название:	pict2_2.gif
Просмотров:	9
Размер:	16.6 Кб
ID:	1365 alt="" />
    Рис. 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).
    Нажмите на изображение для увеличения.

Название:	pict3_11.gif
Просмотров:	7
Размер:	3.1 Кб
ID:	1366 alt="" />
    Рис. 3

    Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений - до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.
    DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации (рис. 4):
    Нажмите на изображение для увеличения.

Название:	pict3_12.gif
Просмотров:	7
Размер:	9.4 Кб
ID:	1367 alt="" />
    Рис. 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)
    Нажмите на изображение для увеличения.

Название:	pict3_22.gif
Просмотров:	3
Размер:	5.3 Кб
ID:	1368 alt="" />
    Рис. 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).
    Нажмите на изображение для увеличения.

Название:	pict3_31.gif
Просмотров:	5
Размер:	4.8 Кб
ID:	1369 alt="" />
    Рис. 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.
    Нажмите на изображение для увеличения.

Название:	pict3_51.gif
Просмотров:	6
Размер:	3.9 Кб
ID:	1370 alt="" />
    Рис. 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.
    Нажмите на изображение для увеличения.

Название:	pict3_61.gif
Просмотров:	6
Размер:	4.6 Кб
ID:	1371 alt="" />
    Рис. 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.

      Возможность размещать комментарии к сообщениям отключена.

    Метки статей

    Свернуть

    Меток пока нет.

    Новые статьи

    Свернуть

    • Стандартный параллельный интерфейс на PC
      от admin
      Основным назначением интерфейса Centronics (аналог-ИРПР-М) является подключение к компьютеру принтеров различных типов. Поэтому распределение контактов разъема, назначение сигналов, программные средства управления интерфейсом ориентированы именно на это использование. Вто...
      08.02.2017, 22:45
    • Современные микросхемы драйверов RS-485 фирмы MAXIM
      от admin
      Журнал «Схемотехника» №10 2002 г.
      Олег Николайчук
      Целью настоящей статьи является ознакомление читателей с современными микросхемами драйверов сети RS485 фирмы MAXIM, их основными параметрами и особенностями.
      Интерфейс RS485 наиболее часто используется при создании современных локальных сетей различного назначения, как в промышленных изделиях, так и в любительской практике. Основными преимуществами интерфейса являются:
      • Относительно низкая себестоимость
      ...
      08.02.2017, 22:45
    • Системный контроллер ввода-вывода для сопряжения шин PCI и ISA
      от admin
      Журнал «Chip News» №6 2001 г.
      Ракович Н. Н.
      Мы уже беседовали на страницах журнала о продукции компании Winbond [Л.1], выпускающей широкую гамму разнообразных микросхем, начиная с памяти и микроконтроллеров и заканчивая приборами для мобильных средств связи и распознавания речи. Примерно в середине...
      08.02.2017, 22:45
    • Реализация последовательной асинхронной передачи данных в микроконтроллерах PIC
      от admin
      Введение.
      Серия PIC16Cxx от Microchip Technology, Inc. - это второе поколение высокопроизводительных восьмиразрядных микроконтроллеров на базе EPROM. Некоторые микроконтроллеры из этой серии (например PIC16C71 и PIC16C84) не имеют встроенного последовательного асинхронного порта. Эта статья содержит описание последовательного асинхронного интерфейса ( полудуплексное RS-232 соединение ) с программной обработкой прерывания для микроконтроллеров...
      08.02.2017, 22:45
    • Простой конвертер RS-232-TTL
      от admin

      Журнал «Схемотехника» №1 2000 г.
      Александр Нечаев
      При разработке различного рода электронных устройств с использованием микроконтроллеров очень часто оказывается полезной возможность подключения их к персональному компьютеру через последовательный порт. Однако напрямую это сделать...
      08.02.2017, 22:45
    • Программирование портов ввода/вывода LPT и ISA
      от admin
      Данный материал основан на моём (его) личном опыте работы с материнской платой неизвестного (нет, не солдата) производителя. Чипсет - SIS. Если вдруг в Вашем случае дело будет обстоять другим образом, напишите мне. Также хочу сразу предупредить - я не профессиональный программист!!!...
      08.02.2017, 22:45
    Обработка...
    X