CAN Kingdom

За довольно романтичным (CAN-королевство) названием протокола шведской компании KVASER-AB скрывается не менее красивая и оригинальная концепция сетевого взаимодействия устройств, выделяющая его на общем фоне других протоколов высокого уровня. Началу работ над первой версией (текущая — третья) протокола CAN Kingdom в 1990 году предшествовал многолетний опыт компании в области создания систем распределенного управления. Протокол был специально разработан для управления машинами и механизмами: промышленными роботами, текстильными станками, мобильными гидравлическими устройствами — и позволяет удовлетворить такие свойственные подобным приложениям требования, как то:

§ эффективность функционирования в режиме реального времени,

§ жесткие требования безопасности,

§ высокая общая производительность.

CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике, от надувных лодок и систем наведения на цели до сверхзвуковых ракет и истребителей. Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей независимых производителей. CAN Kingdom не является «готовым» протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов — метапротокол, с помощью которых можно «собрать» протокол для конкретной сети модулей, что позволяет достичь уникального сочетания простоты интеграции готовых модулей с высокой степенью «закрытости», защищенности оригинального протокола.

При разработке спецификации CAN Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI. Причина этого проста: семиуровневая модель OSI/ISO создавалась изначально для описания традиционных компьютерных сетей, телекоммуникационных, корпоративных, офисных, которые предназначены не для работы в реальном масштабе времени, а для обслуживания пользователей, требования которых заранее (на этапе построения такой сети) неизвестны и непредсказуемы, и в процессе работы подвержены частым изменениям. (Справедливости ради следует отметить, что большинство протоколов компьютерных сетей также редко в точности следуют этой абстрактной модели, особенно в плане обособления и полной изоляции различных уровней сетевого сервиса.) В системах же управления реального времени ситуация прямо противоположная: на стадии разработки все коммуникационные потребности модулей должны быть известны. И готовая сеть должна функционировать точно так, как задумал системный разработчик. Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип «Модули обслуживают сеть» (MSN — Modules Serves the Network), в отличие от принципа «Сеть обслуживает пользователей» (NSM — Network Serves the Modules), свойственного компьютерным сетям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск по сайту: