Содержание к диссертации
Введение
1 Цель и актуальность работы 11
1.1 Инжекционный комплекс ВЭПП-5 11
1.1.1 Общие сведения 11
1.1.2 Подсистемы, требующие автоматизации 12
1.1.3 Требуемые характеристики системы управления 12
1.2 Выбор аппаратной платформы и ОС для системы управления 13
1.3 Выбор системы управления 13
2 Разработка 15
2.1 Трехуровневая клиент-серверная архитектура 15
2.2 Абстракция данных — каналы 16
2.2.1 Каналы 17
2.2.2 Принципы функционирования каналов 20
2.2.3 Большие каналы 21
2.2.4 Циклическая работа сервера 24
2.2.5 Дополнительные атрибуты каналов - возраст значения и флаги . 24
2.3 Принципы представления, преобразования и обработки данных 26
2.4 Обсуждение избранного подхода 27
2.5 О мпогопоточности 28
2.6 Общая архитектура системы управления 29
2.7 Сравнение СХ с другими системами управления физическими установками 31
3 Реализация 35
3.1 СХ-сервер 35
3.1.1 Основной цикл сервера 35
3.1.2 Модель и АРІ драйверов 37
3.2 Драйверы 40
3.2.1 САМАС-драйверы для контроллеров СМ5307 40
3.2.2 CAN-драйверы 44
3.3 Сетевой протокол СХ 50
3.4 Транспортная клиентская библиотека cxlib 51
3.5 Библиотеки работы с данными 53
3.5.1 Доступ к данным с автоматическим восстановлепием соединения cda 53
3.5.2 Формулы 55
3.5.3 Структурирование данных — Cdr 57
3.6 Библиотеки пользовательского интерфейса 59
3.6.1 СЫ 59
3.6.2 Knobs — компоненты управления 60
3.6.3 Xh— упрощенный доступ к функциональности XII 62
3.7 Организация пользовательского интерфейса 63
3.7.1 Цветовое кодирование 63
3.7.2 Выдача информации по мере необходимости 65
3.7.3 Работа полей ввода данных 66
3.7.4 Файловые диалоги 67
3.8 Система запуска и контроля состояния 68
3.9 Средства отладки и диагностики 70
3.9.1 Симуляция аппаратуры 70
3.9.2 Консольные утилиты для доступа к данным 71
3.9.3 Система протоколирования 71
3.9.4 Консольный интерфейс сервера 73
4 Применение 74
4.1 Магнитная система 74
4.2 Система управления субгармоническим группирователем 76
4.3 Система контроля вакуума 78
4.4 Система термостабилизации 80
4.5 Система диагностики пучка 82
4.6 Использование системы СХ в проекте МНТЦ Л"62257 87
4.6.1 Описание проекта 87
4.6.2 Задачи автоматизации 87
4.6.3 Выбор системы управления 89
4.6.4 Программы управления и контроля 89
4.6.5 Драйверы 93
4.6.6 Эволюция 93
4.6.7 Выводы 94
5 Дальнейшее развитие 95
5.1 Порт для Windows 95
5.2 Кросс-сборка 97
5.3 Межплатформное преобразование данпых 98
5.4 БД с конфигурацией аппаратуры 99
5.5 Модульный подход к построению унифицированных программ управления па основе древовидных описателей и plugin-архитектуры 101
5.6 Загружаемые модули сетевого доступа в сервере 105
5.7 Ядро-планировщик cxschcduler 106
5.8 Библиотека структурированного бинарного В/В 106
5.9 Об ограничениях 107
5.10 Кодирование селекторов строками, а не числами 108
Заключение 110
Приложения 112
- Подсистемы, требующие автоматизации
- Принципы представления, преобразования и обработки данных
- Организация пользовательского интерфейса
- Модульный подход к построению унифицированных программ управления па основе древовидных описателей и plugin-архитектуры
Введение к работе
Необходимой частью современных установок для проведения экспериментов по физике высоких энергий является компьютеризированная система управления установкой. Данная работа посвящена созданию системы управления строящимся в ИЯФ СО РАН Инжекционным комплексом ВЭПП-5 [1].
В настоящее время в мире существует и используется па ускорительных установках немалое количество программных систем управления. Однако, в середине 1990-х годов, когда начал создаваться комплекс ВЭПП-5, большинства из этих систем (например, TANGO[2, 3] и TINE[4, 5]) не было, а существовавшие были недоступны либо вследствие закрытости для России (EPICS[6, 7]), либо вследствие дороговизны (Vsystcm[8]). Системы же управления, применяемые на существовавших к тому времени в ИЯФ установках, были слишком привязаны к используемой аппаратуре (как к управляющей электронике, так и к компьютерам), и потому не подходили для ВЭПП-5, поскольку па нем предполагалось использование иной аппаратуры.
Цель проведения работы
Целью работы являлось создание централизованной компьютерной системы управления для Ипжекционного комплекса ВЭПП-5. Это включало в себя:
Разработку архитектуры системы управления на основе трехуровневой модели.
Создание ядра системы управления как самостоятельного программного продукта, работающего под POSIX-совместимыми ОС (в частности, Linux).
Реализацию набора управляющих программ для Инжекционного комплекса ВЭПП-5.
Структура диссертации
Работа состоит из введения, пяти глав, заключения и трех приложений.
Во введении дается общая характеристика работы, обосновывается се актуальность, сформулированы цели работы, научная новизна и практическая значимость, перечислены положения, выносимые на защиту, и приводится краткий обзор содержания диссертации.
Подсистемы, требующие автоматизации
С начала создания ВЭПП-5 планировалась компьютерная автоматизация систем: Контроля вакуума. Магнитной системы. Системы ВЧ-синхронизации. Системы термостабилизации. Системы диагностики пучка. Список систем менялся по мере создания Инжекционного комплекса ВЭПП-5 — например, добавились система управления субгармоническим группироватслем и система фазовых измерений[9] — и продолжает меняться. Очевидно, что для такой большой установки требуется централизованная система управления, поэтому в середине 1990-х годов были сформулированы следующие требования: Управление аппаратурой в стандарте С AM АС (позже добавился CAN-bus). Количество крсйтов — несколько десятков ( 100), а устройств — несколько сотен ( 1000), и ... ...количество точек управления и контроля — несколько тысяч ( 10000). Режим работы основной части аппаратуры — опрос с частотой порядка 1Гц. Возможность одновременного доступа нескольких независимых программ к одной аппаратуре без конфликтов — прозрачно для самих программ1. Максимальное использование стандартных программных и аппаратных средств, .с., программы должны иметь возможность просто работать с аппаратурой, не заботясь о том, что к этой же аппаратуре могут обращаться и другие программы, и от них пе должно требоваться никаких мер для разрешения потенциальных конфликтов. Исходя из последнего пункта требований выбор аппаратной платформы для системы управления был очевиден — в качестве управляющих компьютеров используются стандартные ПК офисного класса. В качестве же операционной системы для этих ПК рассматривались два варианта: ОС семейства Windows (в 1995г. — Windows 95 или Windows NT 3.51) либо Unix-подобная ОС. Достоинством Windows является широкая распространенность. Однако эта система является платной, а ее надежность оставляет желать лучшего, что является неприемлемым для использования в управлении такой сложной установкой, как ВЭПП-5.
Поэтому решено было использовать для управляющих компьютеров Unix-совместимую ОС. Выбор пал на свободно-распространяемую ОС Linux. Опа была на тот момент хотя и не самой продвинутой (по сравнению с разными вариантами BSD-систем), по наиболее динамично развивающейся. В дальнейшем правильность такого выбора подтвердилась: Linux в настоящее время является наиболее развитой и поддерживаемой из Unix-подобных систем (занимая даже некоторую долю «рынка» настольных систем), а также самой универсальной — Linux портирован на большинство современных процессоров, в т.ч. на используемые во встраиваемых устройствах и контроллерах, что позволяет использовать на всех уровнях системы управления единую ОС. Однако, когда в середине 1990-х годов понадобилось выбрать систему управления для ВЭПП-5, оказалось, что готовой доступной системы просто не существует. Система управления ВЭПП-4 [10], исправно работающая десятки лет, жестко привязана к используемой па комплексе ВЭПП-4 аппаратуре, в том числе к ЭВМ «Одре-нок». ВЭПП-5 же изначально проектировался под использование иной аппаратуры. Наиболее распространенный в мировом ускорительном сообществе EPICS[6, 7] был в то время недоступен по нескольким причинам. Во-первых, он был платным, а кроме того, вследствие экспортных ограничений недоступен для использования в России. Во-вторых, он работал только под управлением ОС vxWorks на процессорах Motorola Мб8ххх2, поддержка же Linux появилась лишь в самом конце 1990-х. Кроме того, как показало дальнейшее изучение EPICS, трудозатраты на его поддержку, разработку программ и драйверов для САМАС-аппаратуры настолько высоки, что сравнимы с затратами па создание специализированной системы управления «с нуля». Vsystem[8], идеально, судя по заявлениям ее авторов, подходящая для автоматизации любой установки, является коммерческой, что также исключило ее из рассмотрения: во-первых, собственно по причине платности, а во-вторых, как следствие, из-за ее закрытости и неясности с поддержкой.
Большинства же других систем управления в то время еще просто не существовало. Поэтому оставался единственный путь — создание с нуля собственной системы управления с трехуровневой архитектурой, непосредственно под потребности комплекса ВЭПП-5. Такая система была создала и получила имя СХ ("СХ" — Control system for UNIX). В первоначальном варианте («нулевая версия»)[11, 12], запущенном в 1997г. на ВЧ-стенде накопителя-охладителя, она поддерживала «простую» (ЦАП- и АЦП-подобную) САМАС-аппаратуру под управлением транспьютерных крейт-контроллеров[13]. Затем в версии 1[14] в 1999г. была добавлена более общая инфраструктура драйверов, позволяющая использовать аппаратуру произвольных стандартов, а в современной версии 2[15] — также реализована поддержка «больших каналов» (см.2.2.3) и начат переход к модульному построению прикладных программ (см.5.5 и [16]). Работы по созданию ПО системы управления ВЭПП-5 начались в 1995г. К этому моменту в мире стало общепризнано, что наиболее адекватной архитектурой для подобных крупных систем — с сотнями и тысячами точек управления и контроля — является т.н. трехуровневая, именуемая также стандартной моделъю[17].
Самый верхний уровень представлен прикладными программами (в англоязычной литературе он обычно именуется "human interface layer", "presentation layer" или "supervisory layer"). Нижний уровень — уровень аппаратуры ("device interface layer", "field layer") — состоит из устройств и их драйверов1. В реальности провести четкую границу между устройствами и их драйверами довольно сложно: в случае интеллектуальных устройств, таких, как PLC, современные CAN-устройства, либо САМАС с интеллектуальными контроллерами, содержимое "field layer" располагается непосредственно в аппара И, наконец, средний уровень ("control layer") является связующим, обеспечивая передачу данных между прикладными программами и аппаратурой, решая также большое количество служебных задач — таких, как мультиплексирование данных, разрешение конфликтов, управление доступом, и т.д. Фактически, средігий уровень — это как бы «программная шина данных». Основными достоинствами трехуровневой архитектуры являются: разграничение функций — каждый уровень решает четко определенную задачу; распределенность — подобные системы всегда реализуются по модели клиент-сервер (прикладные программы являются клиентами, а средний уровень — сервером); так что к одному серверу (т.е. — к одной и той же аппаратуре) может доступаться несколько клиентов одновременно, и один клиент может общаться сразу с несколькими серверами (в том числе на разных ЭВМ и даже в разных частях света); разрешение конфликтов — при одновременном обращении к аппаратуре нескольких клиентов запрос будет исполнен аппаратурой один раз, и результат его исполнения будет отправлен всем клиентам. Следствием этих достоинств является масштабируемость — одно из основных требований, предъявляемых к крупным системам управления. Типичная схема системы управления с трехуровневой архитектурой представлена на рис.2.2. Такой архитектуры придерживаются все современные системы управления физическими установками - EPICS[6, 7], коммерческая Vsystem[8], TANGO[2, 3], TINE[4, 5], СОАСК[18], и другие. Аналогичную структуру имеет и система управления работающего в ИЯФ комплекса ВЭПП-З/ВЭПП-4 [10].
Принципы представления, преобразования и обработки данных
Система управления в конечном итоге представляет операторам вещественные значения — напряжения, температуры, энергии и т.д. с каким-то количеством знаков после десятичной точки. Хотя: Контрольно-измерительная аппаратура принципиально работает в целых числах. Не существует хоть сколько-нибудь стандартного способа представления вещественных чисел, который был бы совместим со всеми процессорами. При этом система должна поддерживать разные платформы. Поэтому — Весь обмен между драйверами, сервером и клиентами ведется в целых 32-битовых числах, преобразование же в вещественпые производится в клиентах. Специфичный для конкретных устройств пересчет из кодов в инженерные величины производится непосредственно в драйверах. Значения ЦАП и АЦП указываются в микровольтах. Подавляющее большинство используемых устройств имеют разрядность не выше 24 бит (чаще — 16 или 20) и точность (цену деления) десятки, а то и сотни микровольт, поэтому (в рамках 32 бит) перевод в микровольты не приводит к потере точности. С другой стороны — микровольты более чем адекватны для подавляющего большинства приложений, давая даже некоторый избыток точности, что обеспечивает повышенную гибкость и надежность. Такой подход обеспечивает независимость уровней, расположенных выше драйверов, от специфики конкретных устройств. И позволяет прозрачно производить замепу одпих устройств на другие (даже со сменой стандарта электроники, например, САМАС па CAN-bus). Потребность в этом возникала в системе управления ВЭПП-5 несколько раз, и избранное представление данных полностью себя оправдало. Для устройств же, оперирующих с некоторыми «абстрактными» единицами (например, ПКС), либо когда собственные единицы прибора являются достаточно натуральными (например, АЦПТ возвращает температуру сразу в градусах), эти единицы и используются.
В других системах управления, используемых в ИЯФ — существующей на ВЭПП-4 и разрабатываемой для ВЭПП-2000 — устройства типа цифровых осциллографов не поддерживаются общей инфраструктурой вовсе, и работа с ними производится отдельно, в обход общей системы управления. То, что СХ содержит полноценную поддержку подобных устройств, уже является несомненным достоинством. С другой стороны, во многих системах управления работа с подобными сущностями сделана полностью унифицирований с «обычными» каналами. Например, в EPICS любой канал именуется рекордом (от англ. "record" — запись), работа с ним всегда выглядит как чтение/запись полей этого рекорда. Подобная унификация выглядит привлекательно, и при дальнейшем развитии СХ будут делаться шаги в этом направлении. Однако, функционирование обычных (особенно с учетом обработки большого их количества «оптом») и больших каналов слишком отличается, поэтому попытка полной унификации интерфейса во-первых, приведет спижению эффективности, а во-вторых, потребует неоправданных трудозатрат. Кроме того, используемая в том же EPICS парадигма «чтения и записи полей рекорда» также имеет недостатки. Например, чтобы получить осциллограмму с заданными параметрами, надо вначале уставить эти параметры в соответствующих полях, а затем запросить чтение поля «осциллограмма». Таким образом, операция получается неатомарной (составной) — в последовательность действий может вмешаться другая программа, изменив часть параметров, что приведет к порче результата. В СХ же измерение осциллограммы с некими параметрами является единой операцией. В свете приведенных аргументов принятая в СХ модель представляется адекватной. Другим отличием мпогих систем управления является поддержка в качестве адресуемых единиц (полей рекордов) более сложных типов данных - строк переменной длины, массивов, вещественных чисел. Хотя из общих соображений это также выглядит весьма привлекательно, но практического применения па ВЭПП-5 пока не имеет13, и добавление этой функциональности в СХ было бы неоправданной тратой времени разработчиков. 13А то, где должно производиться преобразование из инженерных единиц и целых чисел в физические величины и вещественные числа, (а также где должны храниться промежуточные результаты вычислений), как было[22], так и до сих пор продолжает оставаться[23] предметом дискуссий в международном сообществе разработчиков систем управления. В последнее десятилетие получила широкую популярность технология многопоточности (multithreading). При этом в рамках одного процесса создается несколько потоков исполнения (нитей, threads), имеющих одно адресное пространство, но раздельные контексты исполнения (стек и набор регистров). Тем самым получается как бы «легкий» вариант мпогозадачпости, позволяющий многопроцессные по сути задачи разделять на составные подзадачи, выполняемые параллельно. Если в компьютере несколько процессоров, то задача сможет использовать их все и будет исполняться реально параллельно. На первый взгляд, мпогопоточность выглядит очень привлекательной для систем управления, и часто в них используется.
К примеру, драйвер каждого устройства может исполняться отдельной нитью; также отдельной питью может запускаться связь с каждым из серверов. По мнению же автора использование многопоточности в системах управления не оправдывает себя (по крайпей мере, в физике высоких энергий). Обоснование: 1. Если процессор реально всего один, то многопоточность будет лишь тратить лишнее время на переключения контекста. 2. Многопоточность требует множества накладных расходов, и для программиста это огромная головная боль: доступ ко всем ресурсам приходится окружать блокировками (locks, mutexes). В результате — (a) Много дополнительной, лишней работы. (b) Повышается вероятность ошибок. (c) Блокировки опять же сказываются на производительности. 3. Многопоточпость, к сожалению, весьма далека от портабельности: существуют значительные различия между POSIX и Win32, плюс даже в Linux внутренняя реализация многопоточности менялась несколько раз. 4. Многопоточпость реально нужна, когда программа выполняет параллельно несколько разных продолжительных действий. В системе управления же собственно действия выполняются аппаратурой, а программа лишь реагирует на впешние события да ждет. Это вполпе можно сделать и в рамках единого потока. К тому же, доступ к САМАС и CAN-bus принципиально последователен. Таким образом, вся многозадачность в системе управления обычно заключается в ожидании некоторого количества внешних событий и истечения нескольких временных интервалов. Следовательно, программы управления по своей сути — однопоточны, и применение в них многопоточпости неадекватно задаче. А ведь POSIX позволяет довольно легко делать однопоточпые программы с мультиплексированием ввода/вывода и таймаутами — на основе select () (близкий аналог в Win32 - "completion ports"[24]), что и было использовано еще много лет назад при создании библиотеки Xt. Программы при этом становятся 1) простыми в создании (однопроцессные программы всегда проще «переплетающихся» многопроцесспых); 2) легкочитаемыми и отлаживаемыми. Как следствие — более высокая надежность однопроцесспых программ. Поэтому в СХ было принято решение как прикладные программы, так и сервер сделать одиопоточиыми, что полностью себя оправдало.
В результате на основе трехуровневой модели была разработана архитектура системы управления, представленная на рис.2.5. СХ содержит компоненты, поддерживающие все три уровня и связи между ними. Нижний уровень представлеп готовой инфраструктурой для драйверов САМАС и CAN-bus и набором драйверов для устройств, применяемых па ВЭПП-5. Сервер содержит следующие компоненты: менеджер драйверов, реализующий также и API драйверов; менеджер каналов, реализующий функционирование каналов в соответствии с правилами, описанными в 2.2; ядро-планировщик (scheduler), реализующий основной цикл сервера и реакцию на внепшие события; модуль удаленного администрирования сервера (supervisor); интерфейс с клиентами ("client frontend") — серверная реализация СХ-протокола.
Организация пользовательского интерфейса
Человеческий глаз распознает цвета намного быстрее, чем буквы и цифры, поэтому хорошо подобранные цвета способны значительно повысить эффективность пользовательского интерфейса. Однако при большом количестве цветов их выбор становится нетривиальной задачей: с одной стороны, они должны достаточно отличаться, чтобы быть легко узнаваемыми, а с другой — гармонировать, чтобы интерфейс не выглядел аляповато. В СХ эта задача была успешно решена, и цветовая сигнализация является одним из ключевых элементов пользовательского интерфейса. Цветовое кодирование в СХ используется для нескольких целей: 1. Для визуальпого разделения данных (значения разной «важности» и разные линии на графиках). 2. Для цветовой сигнализации о нештатных ситуациях. 3. Для отображения предыдущих значений — т.н. теней одновременно с текущими данными — это дает возможность лучше оцепить динамику ситуации. Все цвета определяются централизованно — через библиотеку Xh, программы же оперируют логическими цветами. В качестве основного фонового цвета был выбран светло-серый #dbdbdb. Он и не вызывает утомляемости глаз, и контрастен для максимального количества цветов. Основным во многих аспектах может рассматриваться как reference-реализация Motif-программы с современным пользовательским интерфейсом. цветом переднего плана является черный. Тем самым, основная часть информации представляется привычным человеку образом, практически «черным по белому».18
Для повышения разборчивости внешнего вида программ и приближения его к внешнему виду «настоящих» приборов управляющие каналы сделаны несколько отличающимися от остальных: они более «объемные» и чуть других цветов — текстовые поля имеют белый фон и как бы утоплены, а «выступающие» элементы (кнопки, селекторы, выключатели, бегунки) — более темные (см. рис.3.96). В качестве фонового цвета графиков и гистограмм был выбран «почти белый» — #fffff0. Для отображения графиков используются голубой, красный, темно-зеленый, темно-золотистый и бледно-бирюзовый (пример см. на рис.4.16). Гистограммы рисуются голубым, красным и зеленым (пример см. на рис.4.10) — более трех гистограмм на одном поле рисовать нет смысла. Для отрисовки тени — предыдущего значения — все 18Поскольку экран монитора, в отличие от бумаги, светится, то чисто-белый (#ffffff) фон будет слитком ярким и утомляющим. На экране примерным аналогом бумажного белого с точки зрения эргономики является именно светло-серый. гда используется бледно-серый #С0С0С0. Все служебные элементы (оси, подписи, реперы, сетка) рисуются цветами, близкими к черному. Цветовая сигнализация Сигнализация о нештатных ситуациях производится сменой цвета фона (см. рис.З.Оа), так что подобный канал заметен издалека. Выбор конкретного цвета производился так, чтобы он соответствовал символизируемой проблеме. Часть цветов не являются контрастными с черным цветом символов (к примеру, бордовый при аппаратных ошибках), но в этих случаях конкретное значение в канале становится неважным (как, например, последнее прочитапное значение из отключенного устройства), а важен лишь сам сигнал о нештатной ситуации. Объем информации, которую должна предоставлять оператору система управления, весьма велик — так, в магнитной системе линейного ускорителя больше двух сотен только «настоящих» каналов. Несмотря на использование 4 мониторов на каждом из пультовых ПК[46], зачастую на экране просто не хватает места даже для полных названий каналов — приходится прибегать к сокращениям. С другой стороны, оператор все равно не может воспринимать все сразу, поэтому СХ даст возможность отображать часть информации по мере необходимости: К любому каналу, а также к заголовкам строк и столбцов можно добавить тул-тип19 — информацию о местоположении, комментарии, и т.д. Двойной щелчок па заголовке элемента сворачивает этот элемент в топкую полоску с названием. Так же можно сворачивать и отдельные колонки.
Щелчок правой кнопкой мыши (Btn3Down) на любом канале вызывает окно с детальной информацией о нем — имя, метка, «сырое» значепие, возраст, исходный аппаратный канал, текущий набор флагов (расшифровки которых также выводятся в виде тултипов), и т.д. — см. рис.3.7а. 19 Тултип (иногда используется термип всплывающая подсказка) — небольшое окно с комментарием, появляющееся при наведении курсора мыши на объект; см. Приложение 1.3.3. Сам термип является калькой с английского "tooltip". Щелчок правой кпопкой мыши при нажатой кпопке Ctrl вызывает окно, отображающее значение канала шрифтом большого размера (рис.3.7б). Это используется при работе «в полевых условиях», когда требуется выполнять некие действия непосредственно с аппаратурой (проверка контактов и т.п.) — при этом значение, изображенное большими цифрами, видно издалека. Одни и те же элементы используются и для отображения значений управляющих каналов, и для модификации их пользователем.
При этом возникает проблема: если значение капала изменится в момент редактирования (например, другим оператором), то ручка будет словно «вырываться из рук». Для ручек типа бегунков, селекторов и т.п. этой проблемы не существует — момент выбора значения дискретен: когда пользователь отпускает кнопку мыши, тогда и происходит отправка значения в сервер. С текстовыми же полями (которыми, кроме собственно ручки «текстовое поле», могут быть снабжены бегунки и крутилки) ситуация несколько сложнее: пользователь вначале удаляет старое значение, вводит новое, и заканчивает ввод клавишей Enter . Поэтому для текстовых полей был реализован следующий алгоритм работы. Есть два режима: режим автоматического обновления и режим редактирования, когда программное обновление текстового поля отключено. Переход в режим редактирования производится, когда пользователь начинает модификацию поля (удаление, ввод, перемещение текстового курсора). Когда пользователь закончит ввод и нажмет Enter , значепие будет отправлено в сервер и автоматическое обновление включается вновь. Клавишей Esc можно отменить редактирование — при этом возвращается предыдущее значепие и происходит возврат в режим автоматического обновленияг Поскольку первое значение, приходящее от сервера после завершения ввода числа, относится к предыдущему циклу, т.е., является «старым», то оно просто пропускается и реально автоматическое обновление включается на цикл позже. Такая отсрочка на один цикл делается не только текстовыми полями, а всеми ручками. Модификация значения стрелками вверх/вниз эквивалентна ручному вводу с завершающим нажатием Enter .
Модульный подход к построению унифицированных программ управления па основе древовидных описателей и plugin-архитектуры
Прикладные программы в системе управления ВЭПП-5 делятся на два класса: простые (chlclients), состоящие просто из набора каналов управления и контроля, отображаемых на экране, и интеллектуальные, включающие также программный код, реализующий логику работы, специфичную для конкретной задачи. Первый класс программ поддерживается библиотеками Chi и Cdr, причем собственно «программы» состоят всего лишь из «описания» — информации о списке каналов и об их группировке на экране (в ближайшем будущем эта информация будет содержаться непосредственно в БД). Реальной же программой является единый chlclient, считывающий описание и создающий его экранное отображение. У такого подхода есть масса достоинств: 1. То, что собственно «программа» состоит лить из описания каналов, сводит к минимуму возможность ошибок в ней, поскольку ббльшая часть работы выполняется стандартными, отлаженными библиотеками. 2. Описания могут считыватьея системой контроля состояния (cx-starter, см. 3.8), которая при этом способна мониторировать состояние подсистемы и в отсутствие самой программы. 3. Описания могут использоваться другими унифицированными утилитами — такими, как архивное сохранение режимов, выдача в HTML-формате для web-доступа, и т.д. С другой стороны, интеллектуальные программы, помимо своей основной деятельности, вынуждены содержать код для достаточно стандартных операций — создание окна и поддержание графического интерфейса, соединение с сервером и обмен данными с ним, и т.д. Хотя этот код зачастую очень похож (обычно он практически копируется из программы в программу), но все же слишком отличается, а главное — слишком переплетен с кодом программы, чтобы быть выделенным в отдельную библиотеку. При этом людей, одновременно и разбирающихся в физике, и умеющих писать качественные программы (в т.ч. с полноценным графическим интерфейсом), чрезвычайно мало. Т.е., налицо дефицит человеческих ресурсов и явная потребность в упрощении процесса создания интеллектуальных программ. Причем идеальным вариантом было бы решение, позволяющее унифицировать интеллектуальные программы с простыми.
Современное устройство простых программ В обоих классах программ доступ к серверу обеспечивается библиотекой cda, а для стандартизации пользовательского интерфейса используется Xh. Простые программы поддерживаются библиотеками полностью: Cdr отвечает за организацию структуры дерева и получение данных, а также сохранение и загрузку режимов; Knobs предоставляет компоненты, отображающие каналы; Chi обеспечивает остальное. Собственно иерархия организации данных трехуровневая: самые «мелкие» компоненты — одиночные каналы; каналы собираются в т.н. элементы; набор элементов называется группировкой, которая и представляет из себя «экран программы» (см. рис.5.1 и 3.5.3). Смысл такого деления заключается в том, что элементы являются регулярными таблицами каналов — одна или несколько колонок однородных данных8. Сами же элементы, составляющие «экран», могут значительно различаться как по содержимому, так и по размерам, поэтому они раскладываются в виде «строк» по вертикали либо горизонтали, с «переносами строк» в обозначенных местах. Каждый канал может быть либо управляющим (read/write) либо контрольным Например, каждая строка соответствует одному источнику питания; в первой колонке собраны уставки тока, во второй — контрольные значения, в третьей — отображается стабильность, и т.д. (readonly), и отображаться одним из стандартных компонентов, предоставляемых библиотекой Knobs — «текстовое поле», «селектор», «лампочка», и т.д. Элементы, как указывалось выше, могут быть одно- либо многоколоночпыми. Гибкость же группировки ограничивается выбором «базового направления» — горизонтального либо вертикального. В 2004г. эта стройная схема была расширена введением понятия вложенного элемента-, вместо обычного канала любая клетка в элементе может быть занята вложенным элементом, содержащим каналы. Этот элемент, в свою очередь также может содержать вложенные элементы, и так далее — что позволяет создавать па экране структуры любой сложности. Решение состоит из нескольких аспектов, которые вместе складываются в цельную картину. Во-первых, в свете вложенных элементов современное деление по уровням «группиров-ка/элемепт/капал» представляется малоудобным и требует замены на простую древесную иерархию, в которой контейнер содержит либо другие контейнеры, либо собственно каналы.
Причем внутренний формат контейнеров и оконечных компонентов также стоит унифицировать — имя, метка, комментарий, и т.д.; различаться же они будут именно тем, что у оконечных компонентов будут свойства «ссылка па капал», пределы, и т.д., а у контейнеров — список содержимого и некоторые указания о расположении. Естественно, «корневой» компонент обязан быть контейнером. И, собственно, группировка отличается от элемента лишь паличием нескольких дополнительных полей. Такая замена существенно упростит код библиотек и программ, напрямую работающих с описаниями: например, сейчас чтение режима из файла реализуется функцией в две сотни строк (и это не считая собственно разбора текста (парсинга)), трудночи-тасмой, с большим количеством похожих фрагментов, и с разными исключениями — именно из-за избыточной сложности архитектуры. (Предлагаемая схема очень похожа на устройство файловой системы в Unix, где есть директории (в т.ч. корневая директория, почти не отличающаяся от остальных), и есть т.н. иподы ("inodes"), могущие быть либо объектами нескольких разных типов — обычными файлами, FIFO, и т.д., либо также директориями. И директории содержат просто список именованных ссылок на иноды.) Во-вторых, в настоящее время к интеллектуальным программам вынужденно относятся любые, имеющие дело с большими каналами. Дело в том, что сейчас пет возможности поместить большой канал в элемент наравне с обычными каналами. Главная проблема в том, что создать (например, в Knobs) хоть сколько-нибудь стандартные компоненты отображения больших каналов затруднительно — требования почти всегда разные, и именно отображение больших каналов зачастую и является сутью соответствующих программ. Отсюда вытекает идея: компоненты отображения больших каналов должны предоставляться программой. Т.е., быть plug-іп ами ("plug-ins")9. В остальном же — cda и сейчас поддерживает большие каналы, да и в Cdr добавить их несложно. В-третьих, следует дать программе возможность предоставлять plugin-компопснты пе только для больших каналов, по и для обычных. А также — для элементов. И даже — для группировок. Это открывает интересные возможности: например, компонент-группировка для управления накопителем-охладителем мог бы расставлять свои элементы, имитируя геометрию самого кольца; элементы же, в свою очередь, в компактной форме отображали бы данные и позволяли бы управлять «почти визуально». Т.е., такая «всеуровневая» plugin-архитектура позволит создавать довольно сложные программы, просто сделав соответствующие компоненты отображения. В-четвертых, для остальных случаев, когда задача не сводится к простой работе с обычными либо большими каналами (например, специализированная обработка дан-пых), требуется отдельный класс компонентов — пользовательские, поведение которых целиком определяется самим компонентом, а фиксированная привязка 9 Словарь Lingvo (LingvoComputer) дает следующее определения слова "plug-in": «дополнительный программный модуль (к существующей системе программного обеспечения)».
