ЖУРНАЛ СТА №3/1999

ных, которые предназначены не для работы в реальном масштабе време- ни, а для обслуживания пользовате- лей, требования которых заранее (на этапе построения такой сети) неиз- вестны и непредсказуемы, и в процес- се работы подвержены частым изме- нениям. (Справедливости ради следу- ет отметить, что большинство прото- колов компьютерных сетей также редко в точности следуют этой абст- рактной модели, особенно в плане обособления и полной изоляции раз- личных уровней сетевого сервиса.) В системах же управления реального времени ситуация прямо противопо- ложная: на стадии разработки все коммуникационные потребности мо- дулей должны быть известны. И гото- вая сеть должна функционировать точно так, как задумал системный раз- работчик. Краеугольным камнем кон- цепции сетевого взаимодействия 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-идентификатор СТРАНИЦА Поле данных 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 король хранит информацию о том, ка- кие модули и при каких обстоятельст- вах могут быть добавлены в систему. ОБЗОР ПРОМЫШЛЕННЫЕ СЕТИ 11 3/99 Семейство IBM PC совместимых контроллеров (CIF — Communication InterFace) фирмы Hilscher для построения сетей CANopen, DeviceNet и SDS