CAN Kingdom

Протокол шведской компании KVASER-AB занимает особое место среди CAN HLP не только из-за своего необычного названия (CAN королевство), но и в значительной степени благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе.

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

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

CAN Kingdom скорее набор примитивов метапротокол, с помощью которых можно "собрать" протокол под конкретную сеть модулей. Этим достигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью "закрытости" оригинального протокола.
При разработке спецификации CAN Kingdom авторы отказались от следования правилам взаимосвязи открытых систем OSI/ISO, поскольку семиуровневая модель OSI/ISO создавалась изначально для описания традиционных компьютерных сетей, от которых не требуется работа в реальном масштабе времени. В системах же управления реального времени ситуация прямо противоположная на стадии разработки все коммуникационные потребности модулей должны быть известны.

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

В CAN Kingdom сеть CAN это страна (королевство) со своей столицей (центральный контролирующий узел) и провинциальными городами (остальные узлы).

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

CAN система на базе протокола CAN Kingdom обладает некоторыми особенностями.

· Распределение CAN идентификаторов контролируется разработчиком.

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

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

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

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

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

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

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

· Правила идентификации модулей основаны на использовании международного кода EAN/UPC, включающего код производителя и продукта.

· Гибкость режимов передачи и упаковки данных (включая использование поля арбитража для передачи данных).

· Объединение узлов в группы.

· Поддержка часов реального времени и различных режимов доступа к шине.