За десятилетие существования виртуальной обсерватории (ВО) обеспечен удобный доступ к цифровым астрономическим ресурсам. Успех этого международного проекта, деятельность которого координируется Международным альянсом «Виртуальная обсерватория», определяет все большую интеграцию данных обсерваторий в эту информационную инфраструктуру. К последней должна добавиться инфраструктура телескопов, что потребует стандартизации всех этапов наблюдательного цикла, который включает планирование наблюдательного времени, обеспечение наблюдений, архивирование и предварительная обработка данных. В САО РАН разработаны и действуют несколько информационных систем, обеспечивающих поддержку наблюдательного цикла. Архитектура систем многослойная. Они реализованы с использованием веб-технологий и технологий СУБД. Поддержка дистанционных наблюдений требует интеграции этих программных средств в единую систему с учетом тенденций в разработках ВО.
Технический прогресс позволяет сделать качественный скачок в автоматизации наблюдений и повысить эффективность использования дорогостоящих инструментов. Существующий уровень Труды 14-й Всероссийской научной конференции «Электронные библиотеки: перспективные методы и технологии, электронные коллекции» — RCDL-2012, Переславль-Залесский, Россия, 15-18 октября 2012 г.
Впервые система автоматизированного потокового выполнения наблюдений, а точнее управление расписанием наблюдений была разработана для космического телескопа HST. Программный комплекс Spike [1] обеспечивает управление от десяти до тридцати тысяч наблюдений в год. Заявители наблюдательных программ на космическом телескопе определяют большое количество параметров на различные варианты наблюдений, чтобы получить результат. Опыт, накопленный при разработке программного обеспечения, поддерживающего наблюдения на телескопе Хаббла, был использован при проектировании системы потоковых наблюдений на телескопах Европейской южной обсерватории (European Southern Observatory). ESO является межправительственной исследовательской организацией, включающей 11 европейских стран и выполняющей наблюдения на обсерваториях, расположенных в Чили. Эффективное использование времени телескопов и создание архива данных, готовых для научных исследований, привели к разработке в ESO системы потокового получения данных Data Flow System (DFS) [2].
DFS является набором программных средств и процессов для сквозного управления потоком данных, включающем как планирование, так и проведение астрономических наблюдений, а также сохранение наблюдательных данных в научном архиве ESO. На самом нижнем своем уровне DFS в значительной мере опирается на технологию систем управления реляционными базами данных, так как базы данных используются в качестве постоянного хранилища для большинства объектов и информации, проходящих сквозь систему. На верхних своих уровнях система использует комбинацию вебориентированных средств и клиент-серверных приложений на Java и C++. В частности, надежная и быстрая репликация баз данных, располагающихся на трансконтинентальных расстояниях, имеет решающее значение при своевременной реакции на быстроменяющиеся погодные условия для оперативного решения возникающих проблем. Атмосферные условия непредсказуемым образом меняются от часа к часу. Чтобы уменьшить эту проблему, в ESO была разработана концепция сервисных или дистанционных наблюдений. Такой подход применяется в ESO с 1997. При таком подходе астрономы используют программные средства, разработанные таким образом, чтобы подготовка наблюдательных программ могла выполняться астрономами непосредственно со своих рабочих мест в институте. Параметры программы пересылается в ESO, где после проверки они передаются непосредственно к телескопам в Чили, где сохраняются в локальных базах данных. При указанных в программе погодных условиях наблюдения проводятся. Полученные данные передаются в штаб-квартиру ESO. После обработки и контроля качества данные отправляются к заявителю программы, завершая тем самым наблюдательный цикл. В течение года в ESO выполняются более тысячи таких сессий, причем около половины сессий проводятся в дистанционной сервисной моде, при которой заявитель программы проводит наблюдения, находясь не на телескопе . Основным инструментом пользователя для подготовки и управления наблюдательными программами является клиентское приложение на Java, запускаемый с рабочей машины пользователя и обменивающийся информацией с сервером, расположенным в штаб-квартире ESO в Германии.
DFS поддерживает следующие сервисы: (
DFS опирается на три ключевые технологии: основанные на веб-технологиях средства управления информацией, архитектура клиент-сервер и системы управления реляционными базами данных промышленного класса. В этом смысле ESO не отличается от других провайдеров, обеспечивающих круглосуточный сервис на географически распределенной основе.
Следуя опыту ESO, другие наземные обсерватории применяют подобный подход. Так система управления данными (Data Management System) NOAO (National Optical Astronomical Observatory, USA) разрабатывается для обеспечения потока получаемых от телескопов данных к пользователю виртуальной обсерватории [3]. DMS является end-to-end (E2E) системой, которая собирает необработанные данные от разных инструментов, установленных на телескопах в трех географически разнесенных точках, передает эти данные на архивные сайты, автоматически их обрабатывает и передает на ВО-портал. Части этой системы уже используются, обслуживая четыре обсерватории CTIO, KPNO, SOAR и WIYN, входящие в состав NOAO. Особое внимание при разработке системы уделялось возможности настраивать систему для обслуживания других наземных обсерватории в будущем.
Следующим примером разработки E2E-системы
является проект NRAO (National Radio Astronomical
Observatory) OEO (Office of End to End Operations)
[4], направленный на упрощение и повышение
эффективности наблюдательного процесса,
охватывающего все телескопы обсерватории.
Комплекс включает следующие подсистемы: (
Наблюдательный цикл и функциональность отдельных подсистем, обеспечивающих его выполнение, в общих чертах совпадают в приведенных выше проектах, однако нет разработок стандартов на отдельные этапы наблюдательного цикла, которые являлись бы аналогом стандартов IVOA для виртуальной обсерватории. 2 Наблюдательный цикл в САО РАН Инструменты Специальной астрофизической обсерватории РАН вступили в строй в первой половине 70-х годов 20 века, когда уровень развития информационных технологий и автоматизации обеспечивал только управление телескопами. Технологическая структура наблюдательного процесса включала и включает несколько взаимосвязанных этапов: наблюдение (управление телескопом и приемниками излучения, регистрация и сбор наблюдательных данных и сопутствующей информации); архивизация наблюдательных данных; обработка, долговременное хранение и доступ к данным. Подготовка наблюдений имеет свою специфику для разных инструментов. Это определяется конструктивными особенностями телескопов и различными методами наблюдений.
Каждый астрофизический эксперимент, проводимый на инструментах САО РАН, описывается несколькими десятками параметров, которые надо учитывать при наблюдениях и обработке. Для успешной реализации наблюдательного цикла надо определять приоритеты наблюдательных программ, приоритеты наблюдательного времени, связанные с качеством изображения, прозрачностью атмосферы, фазами Луны, и уровни доступа для удаленных наблюдений.
Наблюдения на телескопах САО РАН в общих чертах выполняются так же, как и в других наземных обсерваториях, а именно: планирование и проведение наблюдений, архивизация данных, журналирование наблюдений, потоковая обработка данных и др. [5]. В течение ряда лет в обсерватории ведутся работы, опирающиеся на существующий международный опыт, по созданию информационных систем поддержки отдельных этапов наблюдений, правда, только в самых общих концептуальных и технологических подходах, поскольку нет готовых программных решений применительно к конкретному наблюдательному комплексу.
Разработка систем поддержки наблюдений проводилась в разное время и не в едином контексте E2E-систем. Одна из проблем связана с передачей параметров от разных программных систем, действующих в наблюдательном цикле, к конечному результату – наблюдательному файлу, который помещается для долговременного хранения в архивную систему. Исторически сложилось так, что система управления телескопом и системы управления наблюдательными приборами и системой сбора, которые поставляют основной набор параметров в наблюдательные данные, разрабатывались в разных подразделениях обсерватории. Идеология сквозной передачи параметров через системы не была достаточно продумана для конфигурирования и настройки систем при смене наблюдательных инструментов. В настоящее время для ряда методов наблюдений происходит некорректная передача информации, а в некоторых случаях и потеря ряда параметров. Эти сложности связаны с межплатформенным взаимодействием. Работа по интеграции систем, о которых говорится далее, позволит формализовать этапы потоковой передачи информации к конечному продукту – наблюдательному файлу. Далее мы приводим краткое описание разработок, результаты и проблемы. 3 Планирование наблюдений
Планирование наблюдаемого времени включает в себя подачу конкурсных заявок, их рецензирование и составление расписания наблюдений. Из рассмотренных и принятых КТБТ (Комитет по тематике больших телескопов) заявок составляется календарный план наблюдений на полгода. Для автоматизации планирования наблюдений создана информационная система [6], реализованная на в трехзвенной архитектуре «клиент»-«сервер приложений»-«сервер БД».
Для пользования веб-интерфейсом системы требуется регистрация и авторизация при входе. Определены три ролевые группы, различающиеся по сервисам и правам доступа к данным. Роль «пользователь» дает право на чтение/запись/редактирование только своих заявок, регистрацию и настройку персонального бюджета, просмотр расписания наблюдений, получение краткой информации об инструментах. Выполняется контроль по времени при редактировании подаваемой заявки, поскольку заявочная кампания имеет определенные сроки. Роль «эксперт» включает все привилегии и функции «пользователя» и еще просмотр базы данных заявок, получение статистики и генерацию отчетов о программах, участвующих в наблюдениях, затребованном количестве ночей, программах наблюдений, публикациях. Роль эксперта предоставляется членам КТБТ. Для роли «администратор» разрешены все функции экспертов. В дополнение к ним администратор может редактировать базу данных заявок, управлять бюджетами пользователей, заносить и редактировать заявки, поданные в текстовом виде, составлять расписание наблюдений, управлять бюджетами пользователей, выполнять профилактику базы данных и др.
Названия принятых заявок (наблюдательных программ) и их заявители должны передаваться в качестве параметров в заголовки наблюдательных файлов при накоплении данных, то есть в систему управления сбором. Эта функция не реализована, но на уровне таблиц базы данных расписания и поисковой системы архива реализована связь этих параметров для поддержки запросов по названию программы наблюдений и заявителям. 4 Архивирование данных
Архивная система общего архива наблюдательных данных [7] состоит из хранилища цифровых данных и информационно-поисковой системы (ИПС) на базе СУБД PostgreSQL, которая поддерживает 16 цифровых коллекций. Для обеспечения сохранности данных при возникающих дефектах на носителях или сбоев оборудования имеются несколько копий данных — две копии на CD/DVD-дисках и две копии архива на жестких дисках. Одна реплицирует оптические диски (A0), а другая копия (A1), несколько по структуре каталогов модифицированная, собственно используется ИПС. В настоящее время все цифровые носители и устройства чтения-записи данных нельзя отнести к устройствам длительного хранения, поэтому для обеспечения сохранности цифровых данных на долгий срок необходимо планировать периодическое переписывание информации. Копии архива A0 и A1 поддерживаются также и для такой процедуры переписывания. Вариант архивных данных (A1) повторен на USB-диске с добавлением дампа таблиц ИПС и программ. Он является резервной копией для восстановления информационной системы при аварийных ситуациях на сервере и/или переносе системы на другую платформу.
Информационно-поисковая система общего архива реализована в трехзвенной архитектуре «клиент»-«сервер приложений»-«сервер БД» и обеспечивает открытый веб-доступ к наблюдательным данным в соответствии с резолюцией МАС о доступе к архивам наблюдений [8]. Каждый файл с наблюдениями описывается в таблицах базы данных 60 параметрами. Они используются для динамического формирования веб-интерфейса, установления соответствия параметров FITS-заголовка и атрибутов таблиц ИПС, идентификации файлов, определения типа файла и т.п.
Часть таблиц схемы базы данных являются справочниками (словарями) и содержат информацию, собранную при анализе данных локальных архивов. Она позволяет интегрировать разнородные цифровые коллекции в одной ИПС. Другая часть таблиц содержит параметры, описывающие каждый наблюдательный файл, включенный в архив. Таблицы пополняются по мере поступления оптических дисков с новыми данными. В архиве нет жестких ограничений на формат файлов, поэтому добавление новых локальных архивов не вызывает трудностей при соблюдении достаточно простых правил.
Для проведения модернизации ИПС поддерживаются две схемы базы данных — тестовая и рабочая. Разработки ведутся на тестовой схеме. После ее проверки ИПС переключается на обновленную версию БД. Оригинальная копия A0 и наличие тестовой схемы позволяют выполнять модернизацию ИПС даже на уровне таблиц.
Архивная система включает 16 цифровых коллекций, полученных на разных наблюдательных приборах. Часть коллекций не пополняется из-за того, что некоторые приборы уже не используются на телескопах, но данные, хранящиеся в них, остаются востребованными для научного анализа.
Для подготовки «science-ready» данных требуется коррекция некоторых параметров в заголовках наблюдательных файлов. Это касается, прежде всего, координатной привязки. Частично такая коррекция выполняется сервисом архивной системы, которая по имени объекта обращается в международный центр данных и получает его координаты. Для более точной астрометрической калибровки цифровых изображений разрабатывается система координатной привязки, о которой говорится в следующем разделе. 4.1 Система поддержки электронного журнала наблюдений
Система предназначена для интерактивного заполнения журналов наблюдений на 6-м оптическом телескопе. Электронный журнал наблюдений реализован в трехзвенной архитектуре, где в качестве клиента используется стандартный браузер, сервера приложений – сервер Apache и сервер базы данных под управлением СУБД PostgreSQL.
Заполнение журнала имеет подготовительный этап. После утверждения расписания наблюдений БТА подготавливаются шаблоны журналов с частично внесенной информацией из базы данных расписания наблюдений (дата наблюдения, название программы, заявитель, ответственный наблюдатель), чтобы облегчить работу наблюдателя и уменьшить количество ошибок при внесении информации.
В системе определены следующие роли:
пользователи — регистрация, вход по паролю, просмотр и поиск журналов наблюдений по дате;
ответственные наблюдатели — регистрация, вход по паролю, просмотр и поиск журналов, заполнение журналов, подпись журнала. Это – группа пользователей, ограниченная поименным списком;
администраторы - регистрация, вход по паролю, просмотр и поиск журналов, предварительная подготовка текстовых шаблонов протоколов наблюдений, управление информацией о регистрации пользователей: просмотр данных, удаление пользователей, изменение списка ответственных наблюдателей, напоминание пароля.
Для рабочего инструмента, которым становится виртуальная обсерватория, нужен специальным образом подготовленный контент – данные должны быть готовы для научного анализа, то есть исправлены от инструментальных погрешностей и привязаны к координатной и фотометрической системам. Для этих целей разрабатываются системы потоковой автоматической обработки. 5.1 Координатная привязка прямых снимков Более половины наблюдений на 6-м оптическом телескопе проводятся дистанционно. При удаленных наблюдениях важно оперативно контролировать наведения телескопа, а также отслеживать наблюдательные условия (прозрачность и качество изображений), которые используются при выборе объектов из заявленного программой списка. Для контроля наведения телескопа и уточнения астрометрической калибровки разработана технология автоматизированной координатной привязки прямых изображений. Реализован и внедрен программный комплекс экспресс-обработки изображений с использованием авторского пакета программ по масштабно-инвариантному и корреляционному методам привязки координат в соответствии с требованиями FITS-формата.
Система экспресс-обработки построена на принципах многослойной архитектуры для реализации взаимодействия в распределенной среде между клиентом, сервером приложений и серверомSkyNode, обеспечивающим доступ к базе данных астрономических каталогов. Алгоритм потока задач протестирован на основе наблюдательного материала вспомогательных телескопов и по архивным прямым снимкам БТА. Он показывает устойчивые результаты для разных по качеству и динамическому диапазону данных. Планируется дальнейшее развитие программного комплекса и его применение при подготовке научных данных, коррекции координатных параметров наблюдательных файлов и контроля наведения телескопа. 5.2 Потоковая обработка прямых снимков Проект Youpi [9] - You Pipe - конвейер обработки наблюдений c гибким, ориентированным на астронома веб-интерфейсом приложений обеспечивает развитую функциональность для обработки наблюдательных данных. Он построен на основе открытых программных инструментов. Интерфейс позволяет управлять заданиями обработки в режиме реального времени. На стороне сервера работают скрипты на языке программирования Python вызываемые веб-фреймворком Django. На стороне клиента используется Ajax - технология на основе библиотек Javascript Prototype script.aculo.us. Youpi используется при дистанционной обработке материала обзора неба, проводимого на 4-м телескопе французско-канадской обсерватории.
Мы воспользовались открытыми программными разработками проекта, чтобы приспособить его для наших целей, так появился проект Soupi. Основными, отличительными от Youpi, особенностями Soupi является использование СУБД PostgreSQL с расширением PostGIS, что позволяет повысить масштабируемость процесса обработки данных. Встраиваемые модули и описания наблюдательных инструментов включают новые настройки для приборов, используемых в обсерватории.
Soupi - это универсальный "frontend" для интернет-грида, который подходит как для обработки больших объемов архивного наблюдательного материала, так и персональных данных. Soupi предназначен для запуска заданий и контроля всех этапов и параметров в процессе обработки. Цикл начинается с загрузки FITS-файлов. Виджеты с функцией select позволяют выбирать пользователю один или несколько каналов (фильтров) для FITS-изображений, доступных как локально, так и из сетевых ресурсов, таких как NFS, FTP. При этом Soupi считывает текстовые заголовки и погружает информацию в базу данных, затем сообщает пользователю, в том числе и по E-mail, об окончании загрузки.
Soupi является инструментом, который действует как высокоуровневая оболочка для свободных низкоуровневых программных пакетов обработки астрономических изображений, таких как программные пакеты QualityFITS - оценка качества изображения, SCAMP - астрометрическая и фотометрическая калибровка инструмента, SWarp интерполяция и сложение изображений, а также SExtractor -- инструмент для извлечения точечных источников и каталогизации [10]. Все модули обработки доступны изнутри в качестве плагинов. Некоторые из них могут быть отключены для какойлибо конкретной или фрагментированной последовательности обработки по желанию пользователя. При необходимости можно добавлять собственные плагины и расширить возможности обработки, для чего имеется скелетный шаблон с описанием API. Soupi управляет доступом данных и защиты прав путем реализации Unix-тегов, аналогичных атрибутам файловой системы. Каждый пользователь имеет персональный, защищенный паролем профиль. где наборы данных и результаты могут иметь пользовательские разрешения для владельца, группы и прочих. Разрешения могут быть изменены, чтобы делиться изображениями, результатами обработки и даже файлами конфигурации конвейера.
Загруженные заранее списки изображений выбираются пользователем. Некоторые критерии поиска можно объединять вместе, учитывая идентификаторы фильтров/каналов и типы инструментов. Селекцию можно отредактировать и при необходимости сохранить текущее выделение. Сохраненные выборки могут быть удалены или объединены с другими списками. В целях повышения гибкости настроек селектора добавлена функция загрузки одного текстового файла описания настроек (имена файлов изображений и контрольные MD5-суммы этих файлов) или целого пакета таких файлов, находящихся в каталоге. Это позволяет организовать полуавтоматическую пакетную обработку без необходимости множества ручных операций. Что представляет значительные удобства при обработке наблюдений с очень большим количеством изображений, поскольку всю необходимую выборку можно подготовит заранее.
Перед запуском любой обработки в Soupi все входные данные, параметры конфигурации для плагинов и набор заданий сначала совместно связываются в элемент процессинговой корзины. Процессинговая корзина, по сути, аналогична корзине интернет-магазина, в которую помещают покупки. Это удобный инструмент для обмена между пользователями элементами, описывающими наборы данных и этапы их обработки. Каждый элемент в корзине может быть сохранен для последующего использования или загружен обратно в процесссинговую корзину в любое время. Механизм процессинговой корзины позволяет также менять набор опций обработки в реальном времени перед запуском заданий в кластере.
Soupi для организации кластерных вычислений использует программный пакет Condor. Condor управляет распределением заданий на локальном компьютере, узлах кластера и Интернет-грид. Загрузка заданий на выполнение в среде Condor осуществляется через процессинговую корзину. Soupi собирает все необходимые входные параметры и передает их в Condor через сгенерированный стандартный файл - текстовый скрипт, специфицирующий параметры задания, переменные окружения, командные строки. В зависимости от требований конкретная конфигурация кластера может включать только необходимые узлы кластера с указанными параметрами. В Soupi есть специальная страница для Condor, где специфицируется набор требований в виде настраиваемых политик и селекторов. Пользовательские политики определяют динамические правила, из которых некоторые могут быть описаны регулярными выражениями, причем будут вычислены только перед тем, как задания будут загружены в запуск. В отличие от пользовательских, некий набор доступных узлов кластера может быть выбран статически и отображен на экране. Состояние запланированных заданий Condor можно наблюдать на соответствующей страничке мониторинга. Описание задания на удаленном хосте, время работы, владелец и текущий статус отображается и обновляется в реальном времени без перезагрузки страницы.
Soupi является универсальным средством организации конвейера процедур обработки данных, который может быт построен на персональном компьютере или на крупных вычислительных кластерах и грид. Программа является открытой в соответствии с GPL использует Django 1.2 и выше. Вместо MySQL СУБД-ориентированные вызовы переписаны под использование PostgreSQL с поддержкой полноценных транзакций, а описания геометрических объектов -- точек и вырезок из небесной сферы типа POLYGON в нотации расширения PostGIS. СУБД PostgreSQL теперь разрешает множественность запросов и независимых модификаций базы данных состояния процедур из Django.
Набор инструментальных таблиц расширен параметрами наблюдательного прибора БТА Scorpio. В ближайшей перспективе - расширение набора подключаемых плагинов программами предварительной обработки архивных прямых снимков БТА и их координатной привязки. 6 Интеграция информационных систем поддержки наблюдений
Фокус разработок ВО сдвигается от разработки стандартов и прототипов сервисов, обеспечивающих базовые основы инфраструктуры, к активно используемому «инструменту». Компоненты ВО как полноценного инструмента должны обеспечивать астронома программными средствами для анализа и визуализации, прозрачным доступом к данным и интерфейсами и, конечно же, контентом. ВО не занимается производством контента, но контент, конечно же, должен быть подготовлен так, чтобы соответствовать требованиям ВО.
Успешная деятельность альянса IVOA в создании инфраструктуры виртуальной обсерватории, поддержанная МАС, направлена на объединение всех имеющихся астрономических данных, включая и архивы обсерваторий. Такое «отчуждение» данных предъявляет более жесткие требования, как к организации данных, так и к описанию наблюдений, чем было ранее, когда данные являлись чаще всего собственностью автора программы. Судя по востребованности астрономических ресурсов, доступных в настоящее время пользователю с помощью средств ВО, все больше обсерваторий будет подготавливать свои данные для добавления в контент ВО.
В САО РАН не поддерживалась стратегия наблюдения как единого технологического цикла от постановки задачи до получения научного результата, поскольку инструменты обсерватории были введены в строй в 70-е годы прошлого века. Дистанционные наблюдения требуют все большей автоматизации отдельных частей наблюдательного цикла. В обсерватории активно разрабатывались программные средства, обеспечивающие отдельные этапы наблюдательного цикла. Эти системы приходилось неоднократно менять и модернизировать из-за быстрого развития компьютерных и цифровых технологий.
Еще нет стандартов на отдельные этапы наблюдательного цикла, но они появятся в недалеком будущем стараниями разных рабочих групп IVOA. В настоящее время, когда одна из целей развития ВО состоит в активном наполнении контентом и, следовательно, разработке стандартов для архивов обсерваторий. Это напрямую связано с наблюдательным циклом и стандартизацией его отдельных этапов. Литература
Integration of software systems for support of astrophysical observations
Over the decade of its existence, the Virtual Observatory (VO) has been providing convenient access to digital astronomical resources. Success of this international project which activity is coordinated by the International Alliance Virtual Observatory, defines ever increasing integration of data of the observatories into the VO infrastructure. An infrastructure of telescopes will be added to this process requiring standardization of all steps of an observational cycle which include scheduling of observation time, providing of observations, data archiving and preliminary processing. In SAO RAS there are several information systems supporting of an observational cycle. The systems have multi-tiers architecture. They use web and DBMS technologies. The support of remote observations needs integration this software into a unified system taking into account trends in the VO development.