При разработке спецификации CAN-Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI. Причина этого проста: семиуровневая модель OSI/ISO (рисунок 1) создавалась изначально для описания традиционных компьютерных сетей, телекоммуникационных, корпоративных, офисных, которые предназначены не для работы в реальном масштабе времени, а для обслуживания пользователей, требования которых заранее (на этапе построения такой сети) неизвестны и непредсказуемы и в процессе работы подвержены частым изменениям (следует отметить, что большинство протоколов компьютерных сетей также редко в точности следуют этой абстрактной модели, особенно в плане обособления и полной изоляции различных уровней сетевого сервиса).

Рисунок 2.1 - CAN и модель OSI

В системах же управления реального времени ситуация прямо противоположная: на стадии разработки все коммуникационные потребности модулей должны быть известны. И готовая сеть должна функционировать точно так, как задумал системный разработчик.

CAN-протокол описывает уровень канала данных и часть физического уровня модели взаимодействия открытых систем.

На уровне канала данных протокол описывает два подуровня:

подуровень управления логической связью - Logical Link Control (LLC) - верхний подуровень;

подуровень управления доступом к среде - Medium Access Control (MAC).

Подуровень LLC предоставляет сервисы для передачи данных и удалённых запросов данных, решает, какие сообщения, полученные LLC подуровнем актуальны для данного узла.

Подуровень MAC в основном реализует протокол передачи данных, т.е. формирует и принимает сообщения, реализует арбитраж, квитирование, проверку ошибок передачи, формирование сообщений об ошибках. Именно на MAC-подуровне контролируется состояние шины - свободна/занята. Кроме того, основные параметры битовой синхронизации описываются на MAC-подуровне.

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

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

По требованиям CAN-протокола, среда передачи должна находится в одном

из двух состояний: логический нуль (нижний уровень, CAN_L) - доминирующее состояние, а логическая единица (верхний уровень, CAN_H) - рецессивное состояние. При одновременной передаче доминирующего и рецессивного битов на шине должно присутствовать доминирующее значение. Этот механизм используется при арбитраже сообщений.

В CAN-протоколе используется метод широковещательной передачи сообщений - каждый приёмник сам решает, нужно ли ему обрабатывать очередное передаваемое сообщение. Содержание каждого сообщения определяется идентификатором сообщения. Идентификатор не определяет узел-приёмник, а описывает "смысл" передаваемых данных (можно сказать, что это имя передаваемой переменной), благодаря чему остальные узлы сети могут решить для себя, должны ли они обрабатывать передаваемые данные или нет.

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

Когда шина свободна, любой узел может начать передачу. Если несколько узлов начали передачу одновременно, конфликт разрешается с помощью поля идентификатора сообщений (поля арбитража). Во время передачи сообщения, передатчик сравнивает значение передаваемого им бита со значением, установленным на шине. Если передаваемое и принимаемое значение бита совпадают, то узел может продолжать передачу. Если же при передаче рецессивного бита шина находится в доминирующем состоянии, то передатчик должен прекратить передачу (таблица 2.1). Таким образом, право на передачу по шине получает тот узел, который передаёт сообщение с наивысшим приоритетом. Важно понимать, что приоритетным является не передающий или принимающий узел, а сообщение [3].

Таблица 2.1 - Пример поразрядного арбитража

Краеугольным камнем концепции сетевого воздействия CAN-Kingdom является принцип "Модули обслуживают сеть" (MSN - Modules Serves the Network), в отличие от принципа "Сеть обслуживает пользователей" (NSM - Network Serves the Modules), свойственного компьютерным сетям.

На этапе разработки сеть CAN-Kingdom приспосабливается к нуждам системы, что становится возможным благодаря априорным знаниям о потребностях системы, где детерминизм функционирования модулей является условием обеспечений требований режима реального времени (необходимо, к примеру, знать, как долго сообщение может следовать от одного узла к другому).

Следствием принципа MSN также является и то, что в сети CAN-Kingdom всегда должен существовать один модуль - супервизор, содержащий всю информацию о системе и ответственный за ее инициализацию.

протокол линия коммуникация спецификация

Представление CAN-сети в терминах CAN-Kingdom (в сравнении с традиционным взглядом) дано на рисунке 2.2.

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

Рисунок 2.2 - Два взгляда на структуру CAN-сети: а) традиционный, б) с точки зрения протокола CAN-Kingdom

Для организации и хранения входящей и исходящей "корреспонденции" применяются понятия форм, документов, папок и листов. Типы почтовой корреспонденции (информация, передаваемая по сети) и ее соответствие CAN-понятиям показаны на рисунке 2.3.

Рисунок 2.3 - Типы почтовой корреспонденции

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

Перечислим некоторые особенности CAN-системы на базе протокола CAN-Kingdom.

1. Распределение CAN-идентификаторов находится под полным контролем разработчика. Возможно динамическое распределение идентификаторов. Допускается использование как стандартного, так и расширенного формата CAN-фрейма.

2. Максимальное время прохождения любого сообщения в сети предсказуемо.

3. Во время начальной инициализации системы происходит обязательный этап настройки (setup) протокола, включая построение формата данных, начиная с битового уровня, методов управления шиной, распределение идентификаторов и т.д.

4. В системе всегда должен присутствовать (как минимум до завершения настройки протокола) супервизор, производящий инициализацию системы, контроль подключенных узлов и т.д. Ни один модуль не может принимать участие в сетевом обмене без разрешения супервизора.

5. Перед инициализацией сети каждый модуль должен иметь свой номер (CAN-Kingdom не описывает конкретный способ установки номера модуля - это может быть DIP-переключатель, энергонезависимая память или конфигурация соединителя) и знать идентификатор сообщения инициализации и скорость передачи данных в сети.

6. В сеть CAN-Kingdom возможна интеграция любых CAN-модулей (включая разработанные для других протоколов, например DeviceNet или SDS), удовлетворяющих стандарту ISO 11898.

7. Не существует каких-либо рекомендуемых скоростей передачи данных. Но в первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 Кбит/с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.

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

Правила идентификации модулей основаны на использовании международного кода EAN/UPC, включающего код производителя и продукта. Система распознает только авторизованные системным разработчиком модули. Неавторизованный модуль не получит в свое распоряжение CAN-идентификаторов от супервизора при инициализации сети. Для поддержки режима plug&play модуль-супервизор хранит информацию о том, какие модули и при каких обстоятельствах могут быть добавлены в систему.

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

3. Сравнительная характеристика HLP протоколов