Наиболее популярный сетевой протокол CAN верхнего уровня CANopen используется в промышленной автоматике, судовой электронике, на транспорте и в системах автоматизации зданий. Для CANopen существует мощная поддержка инструментальными средствами PCANopen Magic и ProCANopen для программирования CANopen и CANopen Software для разработки устройств CANopen. Интерфейсы CAN-PC и готовые контроллерные модули CANopen Nodes также являются необходимым атрибутом разработки.

    * Протоколы CAN верхнего уровня
    * CAL (CAN Application Layer)
    * Протокол CANopen

Протоколы CAN верхнего уровня

Распределенные сетевые решения характеризуются высоким уровнем сложности. При отсутствии стандартов разработчик вынужден опускаться на регистрово-битовый уровень, что влечет риск ошибок, закрытость программного обеспечения и высокую стоимость разработки. Поэтому были созданы протоколы верхнего уровня для CAN-сетей, где оговариваются адресация узлов, назначение идентификаторов, значения полей кадра данных, передача данных длиной более 8 байт и т.д.  Стандартные прикладные протоколы предоставляют также разработчику готовые механизмы передачи данных, возможность быстрой конфигурации параметров входящих в сеть устройств и процедуры начальной инициализации.

CAN соответствует спецификации CAN V2.0A/B и международному стандарту ISO 11898, описывает форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок, физические параметры среды передачи данных. Протоколы CAN верхнего уровня описывают метод обмена информацией между устройствами и определены в терминах уровней, т.е. каждый уровень одного устройства общается с тем же уровнем другого устройства. Протоколы CAN верхнего уровня имеют трехуровневую архитектуру, включающую два базовых уровня CAN (физический и канальный) и прикладной уровень. Трехуровневая архитектура позволяет обеспечить предсказуемость задержек прохождения сообщений в сети и повысить ее производительность в режиме реального времени. Наибольшее распространение, получили следующие протоколы, поддерживаемые ассоциацией CiA (CAN in Automation): CAL/CANopen и J1939. Информация по протоколам верхнего уровня может быть получена по ссылкам: http://www.embedded.com и http://www.can-cia.de.
CAL (CAN Application Layer)

Протокол CAL (CAN Application Layer) определяет способ связи и базируется на канальном уровне CAN. CAL лишь определяет абстрактные сервисные элементы прикладного уровня, но не конкретизирует содержимое данных или значения определенных сообщений:

    * CMS (CAN Message Specification) - спецификация CAN сообщений CMS определяет объекты взаимодействия в модели клиент-сервер, правила и механизмы передачи данных разных типов посредством CAN фреймов, включая передачу пакетов длиной более 8 байт. При этом сервером является узел, управляющий исполнительным механизмом, а клиентом - узел, дающий сигнал на его включение/отключение.
    * NMT (Network Management) - управление сетью, построено на взаимодействии типа мастер-слуга и назначает каждому узлу свой адрес и идентификатор. Один узел сети выполняет функции NMT-Master, все остальные - NMT-Slave. NMT-мастер инициализирует, управляет NMT-слугами, которые желают принять участие во взаимодействии, и позволяет им общаться между собой посредством CMS-объектов. Также в задачи сетевого управления входят контроль ошибок и конфигурирование устройств.
    * DBT (DistriBuTor) - динамическое распределение идентификаторов среди модулей DBT-Slave происходит под контролем DBT-Master. С помощью DBT-сервиса назначается тип специальных сообщений, а также осуществляется проверка корректности такого назначения. Для этого на узле DBT Master размещается база данных с именами всех CMS объектов.
    * LMT (Layer Management) - управление канальными уровнями осуществляет изменение NMT-адреса, скорости передачи и битового квантования в узлах CAN-сети. В данном случае также задействована модель Master/Slave.

CAL определяет также механизм реализации перечисленных сервисных элементов через примитивы: запрос от приложения на уровень CAL (request), оповещение приложения о событии на уровне CAL (indication), отклик приложения на оповещение (response), подтверждение от CAL о поступлении ответа (confirm).
Протокол CANopen

Протокол CANopen регламентирует управление сетью, проектирование и диагностику и является для CAL приложением прикладного уровня. С помощью CANopen могут быть просто объединены в сеть модули и блоки различных производителей. В CANopen определяются профили устройств, интерфейсов и приложений. Например, профиль соединения CiA DS 301 определяет базовые правила обмена данными и структуру словаря объектов. Механизмы сетевого взаимодействия для PC и PLC контроллеров и инструментальных средств описаны в CiA DS 302. В дополнение к спецификации ISO 11898 (среда передачи данных двухпроводная дифференциальная линия), CANopen содержит собственные правила битового квантования, а также определяет рекомендуемые типы соединителей:

    * 9-контактный D-Sub (DIN 41652);
    * 5-контактный круглый Mini (ANSI/B93.55M-1981);
    * 5-контактное клеммное соединение.

Разводка контактов всех типов соединителей предусматривает возможность подачи питания на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определены восемь скоростей передачи данных: 1000, 800, 500, 250, 125, 50, 20 и 10 Кбит/с. Скорость 20 Кбит/с обязательно должна поддерживаться всеми узлами. Количество узлов для CANopen для витой экранированной пары ограничено величиной 256. Число сообщений в секунду при скорости передачи 125 Кбит/с колеблется от 1000 до 2500 в зависимости от количества байт в каждом сообщении.

В сети CANopen на прикладном уровне сообщение передается внутри объекта COB (Communication Object), включающего один или более кадров CAN. Каждый COB содержат до 8-ми байт данных и характеризуется уникальным идентификатором. Коммуникационный профиль CANopen определяет интерфейс в виде стандартной структуры словаря объектов OD (Object Dictionary). Object Dictionary един для всех прикладных программ, могут изменяться только элементы внутри этой структуры. Для обмена данными определены два механизма:

    * PDO (Process Data Objects) - объекты данных процесса, предназначенные для быстрого обмена данными до 8 байт. PDO передаются в синхронном режиме (циклический или не циклический) или асинхронном режиме, инициируемом внешними прерываниями, и имеют по сравнению с SDO более высокий приоритет.
    * SDO (Service Data Objects) - объекты данных сервиса, предназначенные для связи типа точка в точку (peer-to-peer) и обмена данными объемом более 8 байт с помощью нескольких кадров CAN в не циклическом низкоприоритетном режиме. Этот тип обмена используется для конфигурирования устройств или настройки формата PDO объектов.

Существует также два системных механизма:

    * Special Function Objects
    * - специальных функций для ряда специальных задач: синхронизированный обмен данными, извещения о событиях и ошибках и общесистемная служба времени. Network Management Objects
      - сетевого управления с помощью сообщений NMT, LMT и DBT сервисов.

Администрированием сети занимается NMT-мастер, который инициализирует устройства, обеспечивает контроль ошибок, а также производит их перекличку для выявления нерабочих узлов (Life Guarding) с помощью PDO сообщений (Node Guarding Object).

CANopen прекрасно подходит для систем автоматизации, построенных на основе PLC. CANopen базируется на доступе к каждому устройству, едином методе связи (PDO и SDO) и едином интерфейсе прикладной программы (Object Dictionary), при которых интеграция различных устройств или их замена не представляют особой сложности.