|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://rtm-cs.sinp.msu.ru/new/can/cs/cs.html
Дата изменения: Tue Dec 22 12:22:48 1998 Дата индексирования: Mon Oct 1 21:20:39 2012 Кодировка: koi8-r |
D.V. Komissarov, A.S. Chepurnov, F.N. Nedeoglo, V.V. Garbuzov, A.S. Lisutin Institute of Nuclear Physics, Moscow State University. 119899, Moscow, Russia, (095) 939-5659
Комиссаров Д.В., Чепурнов А.С., Недеогло Ф.Н., Гарбузов В.В., Лисютин А.С.
Принципы построения системы управления
This paper discusses the architecture of new small control system of LINAC. In discussed control system number of high cost components reduced as much as possible without lose of any functionality and ability operate in hard real time. This is possible because new control system small enough and we able to use for communication between various components of this system high speed and efficient CAN bus. Calculation power of personal computer and front-end micro controllers in this system enough for provide stable small latency time of control actions.
The brief overview of CAN standard and CAN - based higher layer protocols is given.
Сегодня технология Controller Area Network (CAN) находит все более широкое применение при построении систем управления ускорителями. В связи со своей спецификой ( сравнительно небольшая протяженность сети , ограниченное число подключаемых устройств) CAN более всего подходит для компактных систем управления. Таковыми являются системы управления (СУ) малых и средних ускорителей ,а также отдельные подсистемы CУ больших ускорителей.
Традиционная СУ ускорителем представляет из себя трёхуровневую систему (рис. 1).
Верхний уровень в такой системе составляют консоль оператора и сервер базы данных. Этот уровень образован персональными компьютерами , работающими под управлением какой-нибудь операционной системы (ОС), не обязательно поддерживающей алгоритмы реального времени, зато обладающей мощными средствами разработки ПО и поддержки человекомашинного интерфейса.
Средний уровень представляет из себя магистрально-модульную систему , например на основе 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.
Идея создания Controller Area Network ( CAN ) появилась в конце 80-х у Роберта Боша ( Robert Bosch ). Идея заключалась в том, чтобы создать сетевое решение для распределённых систем, работающих в реальном времени. Первоначально CAN применялся в автомобилях , но затем область его применения расширилась и на проблемы автоматизации технологических процессов. CAN обеспечивает высокий уровень защиты данных от повреждения даже при работе в сложных условиях ( сильные помехи ), при этом достигается достаточно большая скорость передачи данных ( до 1 Mbit/s ). Важным достоинством CAN является также то, что разработчик системы может влиять на приоритет сообщений с тем чтобы самые важные из них не ожидали в очереди на отправку. Это свойство CAN позволяет строить сети, поддерживающие реальное время.
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 определяет следующие методы обнаружения ошибок:
Благодаря этим механизмам вероятность приёма испорченного сообщения не превышает (частота появления ошибок) * 4.7 * 10-11. Подсчёты (Mike Schofield) показывают что при средней загрузке шины (на 50%), при её работе 8 часов в день, 365 дней в году со скоростью 1 Mbit/s, одна не зарегистрированная ошибка возникает каждые 1000 лет! Т.о. CAN является технологичной, надёжной и достаточно скоростной системой, к тому же стандартизированной (стандарт ISO 11898).
Стандарт CAN не регламентирует каким образом конкретные приложения будут передавать специфичные для себя данные по сети 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 байт
с использованием фрагментации: не ограничена.
Для новой системы управления малым ускорителем в качестве коммуникационной технологии была выбрана CAN технология. Протоколом верхнего уровня будет служить Device Net. На момент написания этой статьи оконечные микроконтроллерные устройства находились на стадии тестирования и отладки. Параллельно велась разработка программного обеспечения для новых устройств, в том числе написание собственного драйвера для карты PC-I 03 под ОС Linux, а так же реализация основных алгоритмов протокола Device Net.
CAN Specification , Version 2.0 , Robert Bosch GmbH , 1991 Device Net Specification , Release 2.0 , 1997 , Vol.1: Communication Model and Protocol, Vol.2: Device Profiles and Object Library CAN-based Higher Layer Protocols and Profiles , K. Etschberger
This site is optimized for Netscape 3.0
Last modified 21 Nov 1998