CC BY
41
А. Г. Казаров, C. Е. Колос, Ю. Ф. Рябов, И. Б. Соловьёв
ОРГАНИЗАЦИЯ УПРАВЛЯЮЩЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ СБОРА ДАННЫХ ЭКСПЕРИМЕНТА АТЛАС*
Эксперимент ATLAS на ускорителе БАК. Большой адронный коллайдер (БАК, Large Hadron Collider, LHC) — ускоритель заряженных частиц типа протон-антипротон, обеспечивающий (по состоянию на лето 2010 г.) энергию столкновения центра масс частиц до 7 ТэВ при светимости до 1 • 1030 см-2 с-1. Ускоритель, основной частью которого являются сверхпроводящие магниты, расположен в тоннеле протяжённостью 27 км на глубине 100 м.
Эксперимент АТЛАС (ATLAS, A Toroidal LHC Apparatus) — эксперимент общего назначения в области физики высоких энергий, один из четырёх экспериментов (ATLAS, LHCb, CMS, ALICE), проводимых на БАК. Он разрабатывается в рамках международной коллаборации, объединеняющей усилия учёных из 169 институтов 37 стран. Эксперимент рассчитан на решение ряда фундаментальных задач, стоящих перед теоретической физикой, в частности на обнаружение бозона Хиггса. Размеры детектора составляют 40 х 60 х 25 м3. Он состоит из 10 независимых субдетекторов, каждый из которых осуществляет идентификацию частиц определённого типа и энергии с целью решения физических задач, стоящих перед экспериментом. Общий поток первичных данных, регистрируемый всеми субдетекторами ATLAS на максимальной светимости, составляет 160 Гб/с [1] и поступает в общей сложности по 140 миллионам каналов.
Система селекции и сбора данных. Система триггера и сбора данных ATLAS (Trigger and DataAQuisition System) — это масштабная распределённая вычислительная система для сбора, буферизации, построения, передачи и селекции физических данных (событий). События поступают в реальном масштабе времени с первичной электроники субдетекторов ATLAS и проходят через многоуровневый фильтр (триггер событий). Отобранные триггером события записываются в систему постоянного хранения для последующего их анализа.
Основные характеристики и состав системы [2]:
• Аппаратный триггер 1-го уровня, состоящий из специализированных процессоров, обрабатывающих данные с калориметров и мюонной системы, понижает частоту событий до 75 кГц.
• Система считывания детекторов: 150 компьютеров и 1600 оптических каналов передачи данных.
• Триггер 2-го уровня: ферма из 500 компьютеров, выполняющих специализированные быстрые алгоритмы, где время принятия решения составляет 20 мс/событие.
• Event Builder (EB): 100 компьютеров, связанных сетью на основе Gigabyt Ethernet, формируют полное событие размером 1,5 Мб.
• Триггер 3-го уровня (Event Filter (EF)): 2000 компьютеров (до 16 ядер на каждом компьютере) обеспечивают время принятия решения 2 с/событие и запись в систему постоянного хранения данных на скорости до 300 событий/с.
• Общее количество выполняющихся приложений в системе: до 30000.
• По материалам доклада на юбилейном семинаре «Вычислительная физика» 29—30 октября 2009 г., С.-Петербург.
© А. Г. Казаров, C. Е. Колос, Ю. Ф. Рябов, И. Б. Соловьев, 2011
Управляющее программное обеспечение TDAQ. Управляющее прогаммное обеспечение системы TDAQ призвано обеспечивать бесперебойное функционирование всего множества программных и аппаратных компонентов TDAQ, гибкое конфигурирование всей системы, мониторинг состояния системы и качества физических данных. Программные компонены могут быть разделены на три группы, отвечащие соответственно за конфигурацию, оперативное управление (контроль) и мониторинг.
Система оперативного управления TDAQ (TDAQ Run Control System). TDAQ управляется системой управления TDAQ Run Control System, предоставляющей набор разноуровневых программных сервисов для интеграции всех компонентов TDAQ и субдетекторов ATLAS с целью когерентного и бесперебойного выполнения функций, возложенных на всю систему. Состав сервисов и подсистем системы управления и их взаимодействие представлены на схеме (рис. 1). Сервисы нижнего уровня отвечают за управление разделяемыми ресурсами и процессами в распределённой среде, доставку сообщений и контроль доступа. Центральным сервисом системы контроля является оболочка оперативного управления (ООУ). Среди основных задач, стоящих перед ООУ, можно выделить следующие:
• подготовка всей системы к работе и начальная (предпусковая) проверка состояния программной и аппаратной инфраструктуры TDAQ;
• синхронная передача и контроль выполнения команд оператора TDAQ всеми подсистемами;
• отслеживание состояния каждого компонента и всей системы в целом в процессе работы;
• обработка возникающих ошибочных ситуаций;
• проверка состояния компонентов системы, обнаружение и выявление причин неисправностей (диагностика) ;
• выполнение сценариев восстановления работоспособного состояния системы после сбоев.
Тестирование компонентов системы и диагностика ошибок занимают важное место в системе управления. Архитектура системы предусматривает компоненты, отвечающие за конфигурацию и автоматическое выполнение тестов, а также за выполнение интеллектуальных процедур диагностики и восстановления. Эти компоненты призваны облегчить оператору поддержку всей системы в работоспособном состоянии и максимально сократить время простоя системы.
Существенной составляющей частью компонентов системы контроля является экспертная система, реализованная на базе оболочки CLIPS [4]. ООУ организована в виде распределённого дерева «контроллеров», каждый из которых отвечает за определённую подсистему DAQ (рис. 2) и может включать реализацию экспертной системы и набор правил, с помощью которых он анализирует состояние контролируемого поддерева, сообщения об ошибках и принимает решения по автоматическому выполнению процедур восстановления [3].
Отдельным компонентом выделена система «горячего восстановления», которая на верхнем уровне решает проблемы, требующие взаимодействия нескольких подсистем в дереве.
Конфигурационный сервис. Основная задача, стоящая перед конфигурационным сервисом TDAQ, — это обеспечение доступа к описанию подсистем АТЛАС, участвующих в сборе и обработке данных эксперимента: какие части системы (сегменты) задействованы; где, когда и какие процессы должны быть запущены, каковы условия для их выполнения и завершения; способы восстановления при ошибках системы;
Рис. 1. Состав и взаимодействие программных средств системы управления TDAQ
параметры для большинства процессов, включая полное описание систем контроля, передачи физических данных, системы мониторинга и частичное описание параметров триггера, модулей, блоков, каналов детектора и их связей [6]. По окончании сбора данных все конфигурационные данные должны быть надёжно сохранены в архиве.
В основу архитектуры программных средств конфигурационного сервиса были положены следующие принципы:
• объектноориентированная СУБД для реализации: объектная модель дан-
ных — наиболее эффективный способ разделения схемы данных между группами разработчиков;
• генерирование библиотек доступа к данным из объектной схемы: лёгкость освоения и прозрачность пользовательского кода; поддержка языков программирования С++, Java и Python;
• масштабируемость системы: кеширование данных в корневых узлах системы; и на уровне клиентских библиотек доступа к данным;
• архивация в независимой реляционной СУБД.
Рис. 2. Архитектура системы оперативного управления (Run Control):
К — контроллер (Run Controller), КК — корневой контроллер (Root Controller), СВ — система восстановления, П — приложение TDAQ, БЗ — база знаний
Ядро системы OKS (Object Kernel System) — объектноориентированная база данных, реализующая объектную модель данных при хранении схемы и данных в формате XML [7]. Для удалённого доступа к данным в сетевой среде реализован сервис RDB (Remote Database) на основе стандартного протокола CORBA [8]. Пользователям предоставляются графические средства для разработки схемы и модифицирования данных. Архивация всех данных осуществляется в реляционные СУБД (Oracle).
Система мониторинга. Система мониторинга АТЛАС используется для оценки качества данных эксперимента в двух сценариях: на первом этапе непосредственно в ходе сбора данных, что позволяет предотвратить сохраниение «плохих» данных, исправить недостатки и запустить процесс сбора снова, а затем во время полной реконструкции событий, что позволяет отбросить «плохие» данные и сэкономить время на их обработку.
Оценка качества данных (ОКД) в онлайн-системе эксперимента АТЛАС основана на информации, получаемой от системы сбора данных (DAQ), системы контроля (DCS), а также анализа части физических событий, собираемых с детектора. Для осуществления этих задач онлайн-мониторинг реализован как распределённая модульная иерархическая система, состоящая из нескольких подсистем, каждая из которых отвечает за анализ определённого типа данных используемых для мониторига [9]. Отдельно выделена система удалённого мониторинга, которая в целях безопасности изолирована от управляющей сети АТЛАС и предназначена к использованию экспертами из удалённых институтов через сети общего доступа. Полная структура системы мониторинга показана на рис. 3.
Заключение. Управляющее программное обеспечение системы селекции событий и сбора данных ATLAS является центральной программной составляющей всей системы. Система применялось в ходе развёртывания и калибровки детекторов ATLAS [5], а также для сбора физических данных в ходе регистрации первых событий на LHC
Рис. З. Состав системы мониторинга ATLAS TDAQ
в 2009 г. В 2010 г. проводится сбор данных эксперимента c постепенным увеличенни-ем интенсивности столкновений, что даст полномасштабную загрузку всех компонентов и подсистем TDAQ. Дальнейшая эволюция архитектуры системы и программных средств будет определяться требованиями, которые будут сформированы в ходе подготовки к новым этапам развития ускорительного комплекса LHC и детектора ATLAS.
Литература
1. ATLAS Collaboration, Technical Proposal for a General Purpose pp Experiment at the Large Hadron Collider at CERN, CERN/LHCC/93- 43, LHCC/P2, 15 December 1994.
2. ATLAS Collaboration, ATLAS High-Level Trigger, Data Acquisition and Controls, Technical Design Report, ATLAS TDR-0 16, CERN/LHCC/2003-022, 30 June 2003. URL:
http://cern.ch/atlas-proj-hltdaqdcs-tdr (дата обращения: 19.09.2010).
3. Kazarov A., Corso-Radu A., Miotto G. L. et al. A Rule-Based Verification and Control Framework in Atlas Trigger-DAQ, Nuclear Science, IEEE Transactions on 2007. Vol. 54. Iss. 3. Part 2. P. 604-608.
4. CLIPS Expert System Shell, URL: http://www.ghg.net/clips/CLIPS.htm (дата обращения: 19.09.2010).
5. Kazarov A., Kolos S., Soloviev I. et al. Integration of the Trigger and Data Acquisition Systems in ATLAS, Nuclear Science, IEEE Transactions on 2008. Vol. 55. Iss. 1. Part. 1. P. 106-112.
6. Kazarov A., Lehmann-Miotto G., Soloviev I. et al. The Configurations Database Challenge in the ATLAS DAQ System // 2004 conference for Computing in High Energy and Nuclear Physics (CHEP). Interlaken, Swizerland, 2004. P. 101-104.
7. Jones R., Mapelli L., Ryabov Yu., Soloviev I. The OKS Persistent In-memory Object Manager. URL: http://dx.doi.org/10.1109/23.710971 (дата обращения: 19.09.2010).
8. Kazarov A., Kolos S., Soloviev I. et al. Experience with CORBA communication middleware in the ATLAS DAQ // Int. Conference on Computing In High Energy and Nuclear Physics (CHEP 2004), URL: https://edms.cern.ch/document/403799/1.1 (дата обращения: 19.09.2010).
9. Corso-Radu A., Kolos S., Hadavand H. et al. Data Quality Monitoring Framework for the ATLAS experiment at LHC, IEEE Trans. Nucl. Sci., 2008. Vol. 55. Iss. 1. Part 1. P. 417-420.
Статья поступила в редакцию 19 сентября 2010 г.
