МИНИСТЕРСТВО

ОБРАЗОВАНИЯ И НАУКИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное агентство

по образованию
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
НОВОСИБИРСКИЙ
ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
физический факультет

Квалификационная работа на соискание

степени магистра
Кафедра физико-технической информатики


Чеблаков Павел Борисович

Программное обеспечение для системы сопровождающего контроля на ускорительном комплексе ВЭПП-2000


Научный руководитель:



д.ф.м.н., зав. лаб 11 ИЯФ СО РАН Шатунов Юрий Михайлович

н.с. ИЯФ СО РАН Беркаев Дмитрий Евгеньевич


Новосибирск – 2008 год

Оглавление

Введение

В настоящее время в Институте Ядерной Физики СО РАН заканчивается строительство ускорительного комплекса ВЭПП-2000. Новый комплекс является модификацией комплекса ВЭПП-2М (1), который работал в ИЯФ более 20 лет, и рассчитан на энергию 2 ГэВ в СЦМ, имеет два места встречи, а проектная светимость составляет . Кроме того, этот коллайдер позволит проверить концепцию круглых сталкивающихся пучков.

Схема комплекса ВЭПП-2000 представлена на Рис. . Он состоит из нескольких частей и подсистем: Индукционно-Линейный Ускоритель (ИЛУ), синхро-бетатрон (Б-3М), Бустер Электрон-Позитронный (БЭП), коллайдер ВЭПП-2000 (Встречные Электрон-Позитронные Пучки), а также каналы перепуска частиц ИЛУ – Б-3М, Б-3М – БЭП и БЭП – ВЭПП-2000.

Рис. . Схема ускорительного комплекса ВЭПП-2000.

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

В рамках проекта ВЭПП-2000 ведется создание системы управления, отвечающей всем современным требованиям. В связи с этим, электроника контроля и управления, прежде установленная на комплексе ВЭПП-2М в конце 70-х и в начале 80-х годов, была заменена на современную аппаратуру, так как старая в значительной мере устарела, выработала ресурс и практически лишилась поддержки. Это неизбежно вызвало бы простои комплекса и неэффективное управление.

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

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

Целью данной работы является разработка программного обеспечения, выполняющего автоматизацию подсистем сопровождающего контроля на ускорительном комплексе ВЭПП-2000, а именно, анализ требований, проектирование и разработка каркаса программной системы, и последующая реализация на его основе программного продукта.

Постановка задачи

Подсистемы, требующие автоматизации

В рамках задачи сопровождающего контроля ускорительного комплекса ВЭПП-2000 рассматривается автоматизация следующих подсистем:

• 
  вакуумные измерения;
  
• 
  термоконтроль;
  
• 
  криогенная подсистема;
  
• 
  контроль бинарных состояний.
  

Специфика и особенности системы автоматизации

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

С точки зрения автоматизации, ВЭПП-2000 представляет собой систему с более чем тысячей каналов управления и более чем с двумя тысячами каналов измерения и контроля.

В связи с тем, что логика работы комплекса подразумевает независимый контроль и управление подсистемами (ИЛУ, Б-3М, БЭП, ВЭПП, каналы перепуска), программное обеспечение разумно разделить на соответствующие части, ответственные за функционирование той или иной подсистемы комплекса.

Таким образом, появилась концепция простых и независимых управляющих программ, которые в совокупности покрывали бы весь спектр задач по контролю и управлению комплексом. Здесь следует выделить основные преимущества такого подхода.

Во-первых, это простота разработки каждой отдельной программы. При этом нет необходимости учитывать особенности работы других подсистем. Как следствие, это облегчает независимую разработку различных программ разными авторами.

Во-вторых, это простота отладки и поддержки. Это напрямую следует из того, что каждая программа в отдельности достаточно проста. А, следовательно, это облегчает отладку, документирование и поддержку. Ведь зачастую с системой управления за время ее жизни приходится работать различным людям, которые не имели отношения к первоначальной разработке.

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

Требования, накладываемые на программное обеспечение

Каждая из подсистем сопровождающего контроля предъявляет схожие требования к программному обеспечению, а, следовательно, их можно обобщить:

• 
  высокая стабильность работы (24 часа в сутки, 365 дней в году);
  
• 
  легкая перенастройка в соответствии с изменениями в аппаратной конфигурации;
  
• 
  обслуживание порядка нескольких сотен каналов и нескольких десятков устройств;
  
• 
  масштабируемость;
  
• 
  мониторинг интересуемых каналов с периодом ≤ 1 сек;
  
• 
  одновременный доступ нескольких клиентских приложений к одним и тем же каналам;
  
• 
  доступ к каналам по их псевдоименам;
  
• 
  простота разработки клиентских приложений;
  
• 
  независимость от сторонних библиотек и нестандартизованных технологий;
  
• 
  бесплатность используемого инструментария (некоммерческие лицензии);
  
• 
  легкая переносимость.
  

Система сопровождающего контроля ВЭПП-2000

Подсистема измерения вакуума

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

Рис. . Аппаратная часть подсистемы измерения вакуума.

Датчики давления

Датчиками давления являются преобразователи манометрические ПММ-46 (2). Они предназначены для преобразования сигнала давления в токовый электрический сигнал в диапазоне Па ( torr). Преобразователь представляет собой магнитный электро-разрядный датчик с холодным катодом инверсно-магнетронного типа.

Вакуумметры

Датчики давления подключены к вакуумметрам ВМБ-1/8-001. Данные вакуумметры питают датчики давления и снимают с них показания, преобразуя токовый электрический сигнал в напряжение в диапазоне от 0 В до +10 В. Также эти приборы отображают на лицевой панели давление в цифровом виде, что позволяет контролировать правильность всех последующих преобразований сигнала давления.

С выхода вакуумметра сигнал давления в виде напряжения поступает на вход модуля 40-канального АЦП CANADC-40M (3), (4). АЦП, в свою очередь, преобразует аналоговый сигнал в цифровой с заданной точностью и выдает его по запросу от управляющей ЭВМ.

IVA-TINI

Устройство IVA-TINI предназначено для работы с шестнадцатью ДИВ ^{REF _Ref199144539 \h \* MERGEFORMAT} (на рисунке не показаны). Для контроля напряжения и тока каждый источник питания ДИВ имеет сигнальный выход по коаксиальному кабелю, по которому значение напряжения передается в виде частоты импульсами (около 200 нс) положительной полярности, значение тока - в виде частоты импульсами (около 200 нс) отрицательной полярности. IVA-TINI имеет интерфейс CAN-bus для взаимодействия с управляющей ЭВМ.

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

На комплексе ВЭПП-2000 для обслуживания вакуумных насосов используется три устройства IVA-TINI.

Термоконтроль

Во время работы ускорительного комплекса необходимо вести мониторинг температуры токоподводящих шин у поворачивающих магнитов на накопительном кольце БЭП и на коллайдере ВЭПП-2000. С этой целью на каждом токовводе магнита установлен резистивный платиновый термодатчик (HEL-700-0-0-A).

Температура в точке крепления датчика отслеживается по изменению падения напряжения на нем. Напряжение измеряется при помощи многоканального АЦП CANADC-40. Для автоматизации БЭП и ВЭПП-2000 используется по одному такому АЦП, снимающих показания с 26 и 16 датчиков на соответствующих частях комплекса.

Криогенная подсистема

Криогенная подсистема состоит из двух одинаковых частей, одна из которых изображена на Рис. в упрощенном виде. В данную подсистему входят четыре специальных блока Junction Box, разработанных в ИЯФ СО РАН для автоматизации криогенных установок. Помимо этого, для сопряжения с сервером устройств используется четыре устройства CAC208 (8-ми канальный ЦАП + 20-ти канальный АЦП + регистры ввода-вывода) и два устройства CURVV ^{REF _Ref199144539 \h \* MERGEFORMAT} (регистры ввода-вывода).

Рис. Половина аппаратной части криогенной подсистемы.

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

Junction Box

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

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

Заправка криостатов жидким гелием

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

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

Оцифровка сигналов с термодачтиков, с датчиков уровня жидкого гелия и оцифровка различных сигналов блокировок осуществляется при помощи CAC208. А управление нагревателем и вентилями перелива осуществляется при помощи управляемых регистров CURVV.

Бинарный контроль

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

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

Общие элементы аппаратной подсистемы

CANADC-40M

Модуль CANADC-40M (3) предназначен для контроля выходных токов и напряжений в многоканальных управляемых источниках питания. Кроме этого, он может использоваться как многоканальный аналого-цифровой преобразователь широкого применения. Наличие в блоке входного и выходного регистров с оптоизоляцией облегчает создание небольших измерительных стендов.

Модуль состоит из:

• 
  40-канального АЦП с дифференциальными входами;
  
• 
  8-канального выходного регистра с гальванически изолированными выходами;
  
• 
  8-канального входного регистра с гальванически изолированными входами;
  
• 
  CAN-bus интерфейса, по которому осуществляется связь устройства с управляющей ЭВМ;
  
• 
  встроенного микропроцессора.
  

АЦП выполнен на микросхеме сигма-дельта АЦП и аналоговых мультиплексорах. Каждый измерительный канал является дифференциальным. Процессор может организовывать измерения либо нескольких каналов (от 1 до 40), либо обеспечивать быстрые измерения по одному выбранному каналу. Измеренные значения могут выдаваться в CAN-bus, а так же запоминаться во встроенной памяти и выдаваться по специальному запросу. Старт серии измерений может осуществляться адресным, либо широковещательным сообщением по шине CAN-bus. Командой от ЭВМ можно выбирать компромиссное сочетание времени измерения и разрешающей способности. Усилитель с программируемым коэффициентом усиления (1, 10, 100 и 1000) позволяет измерять микровольтовые сигналы (например, от термопар).

Основные параметры устройства CANADC-40M:

• 
  разрядность АЦП 24 бит;
  
• 
  разрешающая способность 24 бит;
  
• 
  абсолютная погрешность не более 0.03%;
  
• 
  входные напряжения: +/-10 В и 1 В, 0.1 В, 10 мВ.\
  

CAC208

Модуль CAC208 (5) предназначен для управления прецизионными (0,03%) управляемыми источниками питания. Модуль включает в себя 20-канальный прецизионный измеритель и 8-канальный цифроаналоговый преобразователь, что позволяет использовать его как преобразователь широкого применения. Наличие в блоке входного и выходного регистров с оптоизоляцией облегчает создание небольших измерительных стендов.

Модуль состоит из:

• 
  8-канального 16-разрядного двухполярного ЦАПа;
  
• 
  20-канального АЦП;
  
• 
  8-канального выходного регистра с гальванически изолированными выходами;
  
• 
  8-канального входного регистра с гальванически изолированными входами;
  
• 
  CANBUS интерфейса, по которому осуществляется связь устройства с управляющей ЭВМ;
  
• 
  встроенного микропроцессора.
  

С точки зрения пользователя, ЦАП может трактоваться либо как прецизионный цифроаналоговый преобразователь, либо как  генератор функций. В процессоре может содержаться до 8 таблиц, по которым устройство формирует изменяющееся напряжение методом кусочно-линейной интерполяции. Все ЦАПы на линии CAN-bus, либо программно определенная группа ЦАПов могут стартоваться одновременно широковещательной посылкой и изменять напряжения/токи соответствующих каналов источников питания ускорительного комплекса с неопределенностью около 1 мс.

В качестве АЦП данное устройство аналогично рассмотренному выше CANADC-40 за тем лишь исключением, что имеет в своем составе только 20 измерительных каналов.

Основные параметры устройства CAC208 (в качестве ЦАП):

• 
  разрядность ЦАП 16 бит;
  
• 
  разрешающая способность ЦАП 16 бит;
  
• 
  абсолютная погрешность ЦАП не более  0.03%;
  
• 
  выходное напряжение ЦАПа   10 В;
  
• 
  каналов выходного регистра  8;
  
• 
  каналов входного регистра   8.
  

CURVV

Универсальный регистр ввода/вывода CURVV (6) предназначен для использования в системах автоматизации ускорительно-накопительных комплексов для ввода/вывода дискретной информации. Устройство содержит два выходных регистра и четыре входных регистра. Все регистры - восьмиразрядные.

CAN адаптер

В управляющей ЭВМ интерфейс CAN-bus реализован с помощью CAN-bus-PCI интерфейсной платы (7).

CAN-bus-PCI интерфейс представляет собой CAN-адаптер, устанавливаемый в PCI слот персонального компьютера. Имеет два CAN-контроллера SJA1000.

Основные характеристики платы:

• 
  совместима со спецификацией PCI 2.1, 4-слойная печатная плата;
  
• 
  два CAN-контроллера Philips SJA1000, соответствующих спецификации CAN 2.0 A/B;
  
• 
  быстрый и эффективный доступ к CAN-контроллерам благодаря отображению внутренних регистров CAN-контроллеров в область памяти центрального процессора;
  
• 
  CAN-bus интерфейс (в соответствии с CiA DS-102) с гальванической развязкой, возможна установка защиты от перенапряжений и импульсных помех по специальному заказу;
  
• 
  напряжение питания 5 В;
  
• 
  потребляемый ток - не более 500 мА, средний 350 мА;
  
• 
  диапазон рабочих температур: 0..+70°С.
  

Управляющие ЭВМ

Управляющие ЭВМ, используемые для автоматизации системы сопровождающего контроля, представляет собой ПК архитектуры x86 под управлением ОС Linux. Одна из машин имеет в своем составе процессор Pentium-4 HT 3 ГГц и объемом оперативной памяти 1 Гб, вторая же машина построена с применением процессора AMD-64 3000 и имеет 512 Мб оперативной памяти. В каждую из них установлено по два CAN-адаптера, описанных выше. Все ЭВМ объединены в сеть Ethernet 100 Mb.
Схема построения программного обеспечения

Рис. . Общая структура программного обеспечения.

Общая структура

При проектировании архитектуры системы автоматизации был использован классический для подобных систем подход. Суть его заключается в выделении трех основных уровней, а именно, уровня аппаратного обеспечения (Hardware Layer), уровня представления аппаратного обеспечения (Hardware Abstraction Layer) и прикладного уровня (Application Layer). В дополнении к трем основным уровням в общую структуру внесен подуровень представления физического канала (Channel Abstraction Layer) измерения/управления.

Рассмотрим назначение каждого из уровней чуть подробнее.

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

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

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

В рассматриваемой архитектуре инициаторами взаимодействий являются приложения прикладного уровня, а само взаимодействие осуществляется посредством компьютерной сети. Таким образом, верхние два уровня образуют клиент-серверную модель взаимодействий ^{REF _Ref199144539 \h \* MERGEFORMAT} .

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

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

Модель представления физической структуры аппаратного обеспечения

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

Для этой цели была разработана система адресации и в ее основу легла физическая структура аппаратного обеспечения.

Рассмотрим модель аппаратного обеспечения, схематично изображенную на Рис. . Как видно из рисунка, модель имеет древовидную структуру с сервером устройств, являющимся корнем этого дерева. Под сервером устройств мы будем понимать часть системы автоматизации, реализующую уровень представления аппаратного обеспечения из описанной в предыдущем разделе схемы (Рис. ). К одному серверу устройств может подключаться несколько контроллеров устройств (Controller 1 … Controller N). На комплексе ВЭПП-2000 в большинстве случаев таковыми являются CAN-bus- и КАМАК-контроллеры. В свою очередь, к каждому контроллеру могут быть подключены различные устройства, работающие по соответствующему протоколу. В то же время, устройство может иметь в своем составе физические (или логические) каналы чтения/записи. Под логическим каналом будем понимать такой канал, который устройство физически не имеет, но способ взаимодействия с данным атрибутом устройства сводится к модели канала, то есть к чтению и/или записи некой величины.

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

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

Таким образом, возвращаясь к Рис. , адрес представляет из себя запись следующего вида: /hardware_server/controller/device/channel. Каждый элемент адреса отделяется от другого при помощи слеша ‘/’, а запись ведется слева направо, следуя от корня в направлении листьев. Каждый элемент адреса содержит исчерпывающую информацию для указания, к какому элементу структуры ведется обращение (на данном уровне иерархии). К примеру, hardware_server – это доменное имя и порт того компьютера, на котором исполняется конкретный сервер устройств. Поле controller может содержать указание протокола и номера канала у контроллера, например, can0 – CAN-линия номер 0. Аналогично, device – это идентификатор устройства.

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

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

Рис. . Серверы устройств и обслуживаемое ими оборудование.
На Error: Reference source not found показан пример такого леса, состоящего из трех серверов устройств и набора контроллеров с устройствами.

Модель функционирования сервера устройств

Сервер устройств состоит из нескольких логических частей, отвечающих за определенные функции. Основные части сервера изображены на Рис. .



Рис. . Структурная схема сервера устройств.
Сетевая подсистема (Network Subsystem) сервера осуществляет установление соединений с клиентами, прием запросов и отправку ответов.

Менеджер подписки (Subscribe Manager) осуществляет работу механизма «издатель-подписчик» ^{REF _Ref199144539 \h \* MERGEFORMAT} , регистрирует подписки клиентов и пересылает им требуемую информацию от устройств.

Ядро сервера (Server Core) объединяет и инициализирует все подсистемы сервера, а также агрегирует модули контроллеров устройств.

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

Выбор был сделан в пользу языка С++, как максимально удовлетворяющего требованиям, предъявляемым к системе автоматизации. Также в пользу этого языка сыграла его высокая эффективность, широкая распространенность, а так же возможность сочетания высоко- и низкоуровневых операций в рамках одного языка. Но основным фактором явилась поддержка им ООП, которая необходима для простой и эффективной реализации многих моделей, в первую очередь модели представления физической структуры аппаратного обеспечения, а так же возможность по простой организации большого объема исходного кода.

Рассмотрим принцип работы сервера в целом. После запуска сервера происходит инициализация сетевой подсистемы с привязкой к порту, на который будет происходить прием входящих соединений от клиентов. При этом также происходит создание пула потоков ^{REF _Ref199144539 \h \* MERGEFORMAT} , обслуживающих клиентов, и создание потока, выполняющего прием запросов на соединение.

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

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

Вслед за запуском контроллеров происходит инициализация устройств и ассоциирование их с контроллерами в соответствии с конфигурацией.

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

Ключевым элементом в построенной архитектуре является понятие команды (command). Команда представляет собой структуру данных, которая содержит в себе набор полей «имя-значение». Имя представляет собой текстовую метку и служит для идентификации конкретного атрибута команды. Значением же является величина одного из предустановленных типов. Как показал анализ, набор, состоящий из int, double, char, string и бинарного массива, полностью удовлетворяет всем запросам к типам, используемым во внутрисерверных и клиент-серверных операциях.

Помимо этого, структура команда содержит в себе адрес получателя команды. При проектировании системы адресации за основу была взята модель физической структуры аппаратного обеспечения ^{REF _Ref199144539 \h \* MERGEFORMAT} .

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

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

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

Модель клиент-серверных взаимодействий

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

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

В классическом понимании термин "клиент-сервер" означает такую архитектуру программного комплекса, в которой его функциональные части взаимодействуют по схеме "запрос-ответ". Но при проектировании данной системы автоматизации данный подход был расширен с целью упрощения механизма взаимодействия и уменьшения накладных расходов. За основу была взята схема издатель-подписчик (publish-subscribe), описанная в (9), которая была модифицирована для применения в архитектуре клиент-сервер. Данная схема применяется для поддержания в согласованном состоянии данных у различных заинтересованных участников системы – подписчиков (наблюдателей) с источником этих данных – издателем (субъектом) ^{REF _Ref199144539 \h \* MERGEFORMAT} .

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

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

Для организации клиент-серверных связей был использован протокол TCP (10) (на транспортном уровне модели OSI/ISO (11)) и его программный интерфейс socket (на сеансовом уровне). Этот выбор был сделан в силу их широкой распространенности в задачах подобного рода и соответствия с предъявляемым требованиям.

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

Рассмотрим требования и ограничения, которые накладывает система в целом на протокол уровня представления:

• 
  поддержка состояния;
  
• 
  стандартизованность;
  
• 
  простота внедрения и поддержки;
  
• 
  гибкость;
  
• 
  эффективность.
  

Поддержка состояния – это способность протокола сохранять промежуточное состояние между запросами и ответами, то есть поддерживать соединение. Поддержка состояния необходима в связи с применением схемы «издатель-подписчик», которая требует постоянного во времени канала связи между клиентом и сервером. Под стандартизованностью будем понимать существование реализаций протокола, соответствующих стандарту, а значит, полностью совместимых на уровне протокола. Также протокол должен быть относительно простым для изучения, внедрения и поддержки, иными словами, его сложность должна быть адекватна поставленной задаче. При этом, безусловно, важным фактором, влияющим на выбор того или иного протокола является существование реализации интерфейса для целевого языка программирования (С++). Протокол должен быть гибким в плане передачи данных произвольных типов, но, в то же время, должен обладать необходимой структуризацией для сохранения целостности этих данных. И, конечно же, должна быть высокой эффективность протокола в плане объема передаваемых данных. Отношение объема полезных данных к общему объему передаваемых данных в идеале должно стремиться к 1.

В связи с этими требованиями были рассмотрены некоторые стандартные протоколы, но в большинстве своем они в какой-то степени не удовлетворяли одному или нескольким требованиям. В результате этого были исключены из рассмотрения такие протоколы как XML-RPC (12) в связи с его использованием в качества транспорта протокола HTTP (13). Протокол HTTP не имеет поддержки состояния, а это полностью не удовлетворяет соответствующему требованию. SOAP - протокол обмена структурированными сообщениями в распределённой вычислительной среде (14) имеет заведомо высокую сложность, а также не имеет простых и активно поддерживаемых реализаций интерфейса для языка С++. Протокол JSON (15), предназначенный для обмена данными, на момент проведения анализа не имел какой-либо устоявшейся реализации для языка С++.

В результате выбор был остановлен на библиотеке boost::serialization (16), которая в большей степени удовлетворяет поставленным требованиям. Данная библиотека находится в составе набора библиотек boost (17), который рассматривается как кандидат на включение в стандарт языка С++. Данная библиотека призвана осуществлять обратимые преобразования произвольной структуры данных языка С++ в последовательность байтов и восстанавливать эквивалентные структуру в другом программном контексте.

При этом библиотека boost::serialization позволяет преобразовывать структуры данных в три различных представления: XML, plain-text и binary. Каждое из представлений одинаково хорошо подходит для передачи по сети, а различия заключаются только в объеме передаваемых данных и удобстве «чтения» человеком.

Программный интерфейс

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

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

Рис. . Схема клиентского приложения.
В составе клиентского приложения присутствуют несколько основных частей.

Сетевая подсистема (Network Subsystem) – осуществляет установление и поддержание соединений с серверами устройств, необходимых данному клиенту. Установление соединения происходит на основании адреса, указанного в команде ^{REF _Ref199140299 \h \* MERGEFORMAT} , которую формирует логика приложения. При этом соединение устанавливается неявным образом при запросе на отправку команды получателю.

Диспетчер (Dispatcher) осуществляет сортировку пришедших от серверов команд на основании адреса (псевдоимени) отправителя. После этого происходит передача команды обработчику, зарегистрированному на данный адрес (псевдоимя) у диспетчера.

Обработчиком команды является произвольный субъект (Subject), который также исполняет роль издателя в модели «издатель-подписчик» (9). Субъект, в зависимости от своего типа, может производить преобразование полученной от сервера (абстрактной) величины. Например, субъект, выполняющий роль датчика давления производит пересчет напряжения, полученного от АЦП, в давление. Таким образом субъект может является программной реализацией какого-либо физического датчика и предоставлять интерфейс к нему.

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

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

Клиентские приложения

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

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

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

Для вакуумных измерений реализованы два клиента, осуществляющие визуализацию показаний давления на ускорительном комплексе. Одно из приложений снимает измерения с ПММ, а второе – с магниторазрядных насосов. Также есть клиентское приложение, ведущее журнал измерений в фоном режиме.

Для нужд термоконтроля написаны два приложения. Они измеряют и визуализируют значения температур на БЭП и ВЭПП-2000 соответственно.

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

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

Внешний вид клиентов показан в приложении на Рис. - Рис. .

Журналирование

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

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

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

Пример записанных в журнале данных показан в приложении на Рис. .

База данных

Все настройки аппаратной конфигурации подсистемы измерения вакуума хранятся в БД и считываются клиентами в процессе работы. На основе этих данных производится управление устройствами и отображение информации, а также ведение журнала. В качестве СУБД используется PostgreSQL (18), хорошо себя зарекомендовавшая в плане функциональности и стабильности работы. Клиент взаимодействует с СУБД при помощи библиотеки libpqxx (19), которая является С++ надстройкой над стандартной библиотекой libpq.

Для подсистемы измерения вакуума была разработана специализированная БД с использованием подхода, общего для всей системы автоматизации комплекса. Структура БД приведена на Рис. .

Эта БД описывает конфигурацию аппаратной части подсистемы измерения вакуума. В ней содержится информация о датчиках, с которых снимаются показания, и способе их подключения к управляющей ЭВМ (номер CAN-линии, адрес АЦП, номер канала). Также в БД ведется запись журнала измерений давления со всех датчиков (ПММ, ДИВ), используемых на комплексе ВЭПП-2000.



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

Заключение

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

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

В дальнейшем планируется реализация приложений для подсистемы бинарного контроля.

Предполагается, что разработанная архитектура будет использована и в других задачах системы автоматизации комплекса ВЭПП-2000.

Список литературы

1. Бару С.Е., Гусев В.А., Захваткин М.Н., Кирпотин А.Н., Кооп И.А., Мишнев С.И., Неханевич Э.Л., Сидоров В.А., Тумайкин Г.М., Шатунов Ю.М. Управление ускорительно-накопительным комплексом ВЭПП-2М со встречными электрон-позитронными пучками. б.м. : препринт 75-86, 1975.

2. Преобразователь манометрический ПММ-46. Техническое описание и инструкция по эксплуатации. 1981.

3. Козак В.Р. Описание устройства CANADC-40M. [В Интернете] 14 03 2003 r. https://www.inp.nsk.su/~kozak/designs/cadc40r.pdf.

4. Козак В. Р., Купер Э.А. Микропроцессорные контроллеры для управления источниками питания. Новосибирск : ИЯФ СО РАН, 2001 r.

5. Козак В.Р. Описание устройства CAС208. [В Интернете] 1 04 2008 r. https://www.inp.nsk.su/~kozak/designs/cac208r.pdf.

6. Козак В.Р., Ромах М.М. Описание устройства CURVV. [В Интернете] 5 03 2004 r. https://www.inp.nsk.su/~kozak/designs/curvvr.pdf.

7. Устройство «CAN-bus-PCI интерфейс». Марафон. CAN технологии. [В Интернете] [Цитировано: 16 05 2008 r.] https://can.marathon.ru/devices/can-bus-pci.html.

8. Многоуровневые системы клиент-сервер. Коржов, Валерий. 6, б.м. : Открытые системы, 6 1997 r., Сети.

9. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Д. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Санкт-Петербург : Питер, 2007. ISBN 5-469-01136-4.

10. TRANSMISSION CONTROL PROTOCOL (RFC 793). [В Интернете] 09 1981 r. https://tools.ietf.org/html/rfc793.

11. ISO/IEC standard 7498-1:1994. iso.org. [В Интернете] 1994 r. https://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip.

12. XML-RPC Home page. xml-rpc.com. [В Интернете] Scripting News, Inc., 2008 r. https://www.xmlrpc.com/.

13. Hypertext Transfer Protocol -- HTTP/1.1. w3.org. [В Интернете] 06 1999 r. https://www.w3.org/Protocols/rfc2616/rfc2616.html.

14. SOAP Version 1.2. W3C. [В Интернете] 27 04 2007 r. https://www.w3.org/TR/soap12/.

15. JSON. JSON. [В Интернете] https://www.json.org/.

16. serialization. boost. [В Интернете] https://www.boost.org/doc/libs/1_35_0/libs/serialization/doc/index.html.

17. boost c++ libraries. [В Интернете] https://www.boost.org.

18. PosrgreSQL. PostgreSQL. [В Интернете] 05 2008 r. https://www.postgresql.org/.

19. libpqxx is the official C++ client API for PostgreSQL. libpqxx. [В Интернете] 2008 r. https://pqxx.org/development/libpqxx/.

20. Qt Cross-Platform Application Framework. Trolltech. [В Интернете] 05 2008 r. https://www.trolltech.com/products/qt.

Приложение



Рис. . Окно визуализации показаний датчиков давления ПММ.

GUI с использование библиотеки Qt 4 (20)


Рис. . Окно визуализации журнала вакуумных измерений.

Видно ухудшение вакуума в кольце ВЭПП-2000, вызванное

инжекциями больших порций (~20 mA) пучка.

GUI с использование библиотеки Qt 4.



Рис. . Внешний вид приложений термоконтроля БЭП и ВЭПП-2000.

GUI с использование библиотеки Qt 4.

Рис. . Внешний вид клиентского приложения для криогенной подсистемы.

GUI с использование библиотеки Qt 4.