CAN Kingdom. 
Автоматизированная система управления очистки городских сточных вод

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

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

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

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

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

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

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

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

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

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

Рисунок 3.12 — Структура CAN-сети.

• а) традиционная;
• б) по протоколы CAN Kingdom.

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

Типы почтовой корреспонденции (информация, передаваемая по сети) и ее соответствие CAN понятиям таковы:

ПИСЬМО — CAN фрейм (данных или удаленного запроса);

КОНВЕРТ — CAN идентификатор;

СТРАНИЦА — поле данных CAN фрейма;

СТРОКА — байт данных;

ЭЛЕМЕНТ СТРОКИ — бит данных.

Для организации и хранения входящей и исходящей «корреспонденции» применяются понятия форм, документов, папок и листов.

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

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

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

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

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

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

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

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

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

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

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

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