|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://rtm-cs.sinp.msu.ru/publications/acs1998/acs98_2.html
Дата изменения: Mon Nov 30 21:42:19 1998 Дата индексирования: Mon Oct 1 21:12:10 2012 Кодировка: koi8-r |
Принципы построения системы управления
The brief overview of CAN standard and CAN - based higher layer protocols
is given.
Верхний уровень в такой системе составляют консоль оператора и сервер базы данных. Этот уровень образован персональными компьютерами , работающими под управлением какой-нибудь операционной системы (ОС), не обязательно поддерживающей алгоритмы реального времени, зато обладающей мощными средствами разработки ПО и поддержки человекомашинного интерфейса.
Средний уровень представляет из себя магистрально-модульную систему , например на основе VME компьютеров. На VME может работать одна из ОС реального времени. В качестве такой ОС можно использовать , например, VxWorks. Магистрально-модульная система соединяется с компьютерами верхнего уровня посредством какой-нибудь сети офисного типа , например Ethernet.
Нижний уровень составляют микроконтроллерные устройства, обеспечивающие доступ к объектам управления . Микроконтроллерные устройства объединены между собой с помощью одной из Fieldbus сетей. С помощью этой же сети осуществляется связь между устройствами нижнего и среднего уровней СУ ускорителем.
Средний уровень содержит в своём составе дорогостоящие быстродействующие устройства , например MVME микропроцессорные платы или быстрые ЦАП / АЦП. Таким образом существенную часть стоимости всей системы управления составляет стоимость её среднего уровня.
В связи с ограниченностью ресурсов нашей лаборатории подход к построению
СУ малым ускорителем был пересмотрен. Предлагается не использовать магистрально-модульную
систему вообще. СУ малого или среднего ускорителя может быть построена
по двухуровневой схеме. При этом нормальное её функционирование гарантируется
сохранением интегральной производительности системы в целом. Т.е. вычислительные
мощности СУ ,построенной по двухуровневой схеме, должны быть примерно такими
же как и у СУ , выполненной по трехуровневой схеме. Сохранить интегральную
производительность помогут возросшие вычислительные мощности персональных
компьютеров. Таким образом новая система управления ускорителем (рис. 2)
существенно упрощается и удешевляется.
Верхний уровень в новой СУ состоит из мощного персонального компьютера , который выполняет функции как консоли оператора так и сервера базы данных. Использование на этом компьютере ОС Linux предоставляет широкие возможности сетевого обмена с другими компьютерами по офисной сети типа Ethernet. Таким образом становится возможным включение в рассматриваемую СУ дополнительных консолей оператора , например в виде X - терминалов.
Нижний уровень новой СУ состоит из микроконтроллерных устройств. Все критичные ко времени алгоритмы предполагается разместить именно на нижнем уровне СУ.
Для соединения микроконтроллерных устройств предлагается использовать стандарт CAN bus. Консоль оператора соединяется с нижним уровнем так же с помощью CAN bus. Для этого используется специальная карта расширения для персонального компьютера , оборудованная CAN контроллером. Сейчас используется карта PC-I 03 фирмы STZP с СAN контроллером PCA82c200 фирмы Philips.
В качестве CAN контроллера для оконечных микроконтроллерных устройств
был выбран SJA 1000. Этот контроллер отображает свои регистры управления
и регистры данных в определенную область памяти микропроцессора , который
так же входит в состав оконечного устройства. Такой механизм доступа к
CAN контроллеру позволяет создавать простые и эффективные программы для
работы с ним. В качестве протокола верхнего уровня для CAN bus был выбран
протокол Device Net.
CAN контроллеры соединяются с помощью шины, которая имеет как минимум два провода can- high и can-low. CAN сеть предназначена для коммуникации так называемых <узлов>. Каждый узел должен состоять как минимум из двух составляющих. Это собственно CAN контроллер, который обеспечивает взаимодействие с сетью, и CPU (рис.3). CAN не нуждается в особой физической среде передачи сигналов. То есть для соединения CAN контроллеров можно использовать и витую пару и оптоволоконный кабель. Сигнал передается по двум линиям can_high и can_low.Логический ноль регистрируется когда на can_high сигнал выше чем на can_low. Логическая единица в обратном случае. Такая схема передачи делает возможным работу CAN сети в очень сложных внешних условиях. С точки зрения помехозащищённости CAN подходящий вариант длясистем управления ускорителями.
Быстродействие CAN сети (до 1 Mbit/s) достигается благодаря механизму
не деструктивного арбитража шины посредством сравнения бит конкурирующих
сообщений. Т.е. если случится так что одновременно начнут передачу несколько
контроллеров, то каждый из них сравнивает бит, который собирается передать
на шину с битом, который пытается передать на шину конкурирующий контроллер.
Если значения этих битов равны оба контроллера пытаются передать следующий
бит. И так происходит до тех пор пока значения передаваемых битов не окажутся
различными. Теперь контроллер, который передавал логический ноль (более
приоритетный сигнал) будет продолжать передачу, а другой(другие) контроллер
прервёт свою передачу до того времени пока шина вновь не освободится (рис.
4). Конечно ,если шина в данный момент занята ,то контроллер не начнет
передачу до момента её освобождения.
Многие механизмы спецификации CAN работают благодаря тому, что все CAN контроллеры принимают сигналы с шины одновременно. Т.е. в одно и то же время один и тот же бит принимается всеми контроллерами в сети. С одной стороны такое положение вещей делает возможным побитовый арбитраж, а с другой стороны ограничивает длину CAN bus. Сигнал распространяется по CAN bus со скоростью света и для правильной работы CAN нужно , чтобы все контроллеры <услышали> его почти одновременно. Почти, потому что каждый контроллер принимает бит в течении определённого промежутка времени, отсчитываемого системным часам. Т.о. чем быстрее тикают системные часы (чем выше скорость передачи данных), тем меньшая длинна CAN bus возможна.
Данные по CAN сети пересылаются в виде отдельных кадров стандартного
формата (рис.5). Наиболее важными полями являются поле идентификатора (identifier)
и собственно данные (data). Приоритетность сообщения, таким образом определяется
значением идентификатора. Приоритет тем больше чем идентификатор меньше.
Как правило контроллер позволяет задавать лишь эти два поля. Остальные
поля используются для передачи специфических данных, необходимых для функционирования
CAN.
Надежность CAN сети определяется также механизмами обнаружения ошибок. Стандарт CAN определяет следующие методы обнаружения ошибок:
Рассмотрим эти протоколы более детально. Сравним каким образом в
этих системах используется 11-ти битное поле Identifier Field стандартного
кадра CAN. Использование этого поля определяет функциональные возможности
того или иного протокола, а также количество подключаемых узлов.
CAL не предусматривают какой-либо интерпретации поля идентификатора
( только некоторые идентификаторы зарезервированы для использования самой
системой)(рис. 6а). Т.е. разработчик сам решает как использовать идентификатор.
Всего доступных идентификаторов в системе получается 1760 (из 2048 возможных
при использовании 11-ти битного идентификатора. CAL система может адресовать
до 256 узлов.
СANopen в основном поступает так же, с тем отличием что адресовать может
128 узлов. Хотя у этой системы имеется и другая схема адресации, которая
работает в том случае, если в системе 127 узлов - клиентов(slave) и один
узел - сервер (master) (рис. 6б). В этом случае первые (0-6) бит идентификатора
используются для задания номера узла - клиента, а оставшиеся 4 бита для
указания номера функции, которую клиент поручает выполнить серверу.
SDS полностью определяет то , как нужно использовать поле идентификатора. Это поле делится на DIR bit, Логический Адрес и Тип Функции (рис. 6в). DIR bit определяет то, какой адрес указан в поле Логический Адрес. Это может быть как адрес отправителя(source) так и адрес получателя(destination). Тип Функции задает действие, которое должна выполнить получающая сторона.
Device Net обладает, пожалуй самой развитой схемой адресации. Система
поддерживает до 64-х узлов. Все идентификаторы поделены на группы (рис.
6г). В первой группе находятся наиболее приоритетные идентификаторы. Всего
в первой группе 1024 идентификатора, т.е. по 16 на каждый узел. Вторая
группа отличается внутренним использованием битов. Она введена для поддержки
CAN контроллеров, которые фильтруют поступающие сообщения только по первым
8-ми битам. Это так называемые Basic-CAN контроллеры. Некоторые идентификаторы
2-ой группы используются системой в спец. целях. Группа 3 предоставляет
для каждого узла по 7 низкоприоритетных идентификаторов. Группа 4 используется
для обработки внештатных ситуаций, как например восстановление работоспособности
узла, в котором случился сбой.
Другой, и пожалуй самой важной, характеристикой высокоуровневого протокола является эффективность использования поля данных кадра CAN, т.е. способ передачи данных. Как правило все протоколы верхнего уровня имеют в своём составе средства, позволяющие передавать данные по схеме производитель - потребитель, но работают эти механизмы в разных системах по-разному. СAL осуществляет передачу данных посредством "объектов коммуникации" (communication objects), работа которых построена на передаче так называемых "переменных" и "событий". Переменные делятся на простые и мультиплексированные. События и простые переменные имеют размер не более 8 байт и передаются с помощью одного кадра CAN. В протоколе CAL используется подтверждение передачи данных типа переменная. CAL поддерживает так же передачу длинных сообщений (длиннее 8 байт), однако при использовании фрагментации в каждом кадре CAN передаётся не более 4 - х байт.
Device Net организует передачу данных посредством cообщений ввода/вывода (I/O Message). Этот механизм резервирует один байт в поле данных для передачи спец. информации. Остальные 7 байт доступны для данных приложения. Device Net поддерживает фрагментацию данных и передачу сообщений неограниченной длинны. При этом, однако, в поле данных резервируется 2 бита для спец. информации. Поддерживаются так же различные модели подтверждения приёма.
SDS создавалась как оптимальное решение для распределённых систем с <бинарными> устройствами, например с сенсорами и переключателями. Т.о. эта система ориентирована на короткие сообщения. Фрагментация в SDS пердусмотрена, но даже с её помощью можно передать не более 256 байт данных.
Для удобства разработки собственного программного обеспечения большое
значение имеет способ описания частей самой системы, а так же устройств,
которые объединяются данной сетью. Способ описания устройств рассматриваемыми
системами схож в том что везде широко применяется абстрактная объектная
модель. Для примера рассмотрим как должно выглядеть стройство с точки зрения
модели описания, принятой в Device Net (рис. 7).
Поясним назначение отдельных объектов в схеме на рис. 7. Сonnection - Обеспечивает взаимодействие данного узла с другими узлами по сети Device Net Device Net - Определяет конфигурацию и статус физического соединения с сетью Device Net Message Router - Направляет приходящие сообщения определённым объектам, которым эти сообщения были адресованы Аssembly - Группирует данные от разных объектов данного узла в один блок данных для последующей передачи как целого Parameter - Содержит основные данные о конфигурации устройства Identity - Идентифицирует данное устройство Application - Задает специфику поведения данного устройства
Основные параметры протокола Device Net таковы: Количество устройств в сети (max): 64; Длина сети при скорости обмена 125 Kbit/s : 500 метров 250 Kbit/s : 250 метров 500 Kbit/s : 100 метров Длина сообщения без использования фрагментации (max): 7 байт с использованием фрагментации: не ограничена.