Распределенная система управления астрономическими ПЗС-камерами

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

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

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

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

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

Традиционным решением здесь является создание монолитного приложения, рассчитанного на работу с камерой одного определенного типа. Однако данный подход не является свободным от ряда ограничений. Во-первых, это увеличенные затраты на разработку и сопровождение отдельных вариантов программы для различных типов камер – при том, что большая часть программного кода (ответственного за графический интерфейс пользователя, операции с FITS-файлами и т. д.) слабо зависит от типа камеры, т. е. должна быть практически одинаковой. Для снижения этих затрат обычно применяют модульное программирование, т. е. построение системы в виде отдельных программных модулей, взаимодействующих друг с другом через строго определенные программные интерфейсы (типичным примером программного модуля в ОС Windows является DLL-библиотека). В системе управления ПЗС-камерами в качестве отдельных модулей должны быть оформлены те части программного кода, которые являются зависимыми от конкретного типа камеры. Для реализации поддержки нового типа камеры потребуется, соответственно, разработка и отладка нового модуля.

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

• •    Возможность развертывания нескольких автоматизированных рабочих мест (АРМ) наблюдателей. Например, большую часть рутинных наблюдений можно выполнять из комнаты управления в по-

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

• •    Обход ограничения на длину интерфейсного кабеля камеры. Многие ПЗС-камеры рассчитаны на управление через USB-интерфейс, при этом максимальная длина кабеля, согласно спецификации на этот интерфейс (версия USB 2.0), составляет всего 5 м, что часто меньше расстояния от места установки камер до теплого помещения внутри башни, где находится АРМ наблюдателя. Использование режима дистанционного управления позволяет решить эту проблему путем использования в качестве сервера камер малогабаритного промышленного компьютера, установленного непосредственно на телескопе.

Рассмотрим некоторые современные подходы к созданию систем дистанционного управления ПЗС-камерами, или, более широко, систем дистанционного выполнения наблюдений. Наиболее простым и часто применяемым решением является метод удаленного рабочего стола, при котором удаленный наблюдатель с помощью специального ПО получает доступ к рабочему столу другого компьютера (в нашем случае сервера камер), как если бы он работал непосредственно за ним. Управление осуществляется путем передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и передачи содержимого экрана в обратном направлении. Существует несколько распространенных протоколов (X11, VNC, RDP) и большое количество программного обеспечения для любой операционной системы, реализующего данную функциональность (RealVNC, TightVNC, Remote Administrator [], TeamViewer [], Microsoft Terminal Services и т. д.). Такой способ удаленного выполнения наблюдений используется в Ликcкой обсерватории [Grigsby et al., 2008], обсерватории Кека [Kibrick et al., 2010] и многих других. Достоинством метода является то, что с помощью стандартного ПО можно дистанционно использовать практически любую готовую систему, изначально не рассчитанную на такой режим. Однако при данном подходе весьма критичным параметром является полоса пропускания линий связи, поскольку она здесь используется не только для передачи полезной информации, но и для отображения вообще любых изменений, происходящих на рабочем столе компьютера. Согласно [Grigsby et al., 2008], пропускная способность должна составлять порядка нескольких мегабит в секунду, что иногда выполнимо только в пределах локальной сети обсерватории.

Альтернативой методу удаленного рабочего стола являются другие подходы, в которых приняты специальные меры к тому, чтобы передавать через компьютерную сеть только действительно необходимую информацию – команды управления камерой, изображения и т. д. Будем называть такие системы распределенными, поскольку разработанное для них ПО состоит как минимум из двух компо- нентов, исполняемых в общем случае на разных компьютерах. Серверный компонент ПО, исполняемый на сервере камер, может обслуживать подключения одной или нескольких клиентских программ, запускаемых удаленными наблюдателями. Поэтому такие системы также можно считать построенными по технологии клиент – сервер. Для организации взаимодействия между компонентами системы могут использоваться самые разные технологии сетевого программирования, причем зачастую в одной системе применяется сразу несколько таких технологий. Наиболее простым вариантом является прямой обмен данными (командами и изображениями) через TCP-соединение, как это сделано, например, в системе управления спектрографом высокого разрешения SARG на 3.6-метровом телескопе TNG (остров Ла-Пальма) [Cosentino et al., 2004]. Прямая передача команд (но не изображений) через TCP-соединение использовалась также в системах дистанционного управления 8.2-метрового телескопа «Субару» (Мауна-Кеа, Гавайи) [Kosugi et al., 2004] и 1-метрового телескопа обсерватории Тонанцинтла (Мексика) [Bernal et al., 2006]. Передача изображений в этих системах была реализована в виде пересылки готовых FITS-файлов по протоколам FTP и SMB.

При разработке распределенных систем возникает ряд стандартных задач программирования сетевого взаимодействия, таких как кодирование сетевых команд (процедур) и их аргументов, проверка типов и допустимых значений аргументов, рассылка сообщений (сигналов), аутентификация, привязка к транспортным протоколам и т. д. Недостатком программирования на уровне TCP-соединений является необходимость самостоятельного решения указанных задач. Современный подход в разработке распределенных систем основан на использовании специального слоя программного обеспечения middleware (в русском языке применяются термины подпрограммное обеспечение – ППО, промежуточное ПО, связующее ПО). Среди функций связующего ПО обычно выделяют следующие:

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

• •    поддержка концепции сетевых сервисов;

• •    обмен сообщениями, в том числе по схеме многие – многим (publish/subscribe);

• •    использование различных транспортных протоколов (TCP, UDP и пр.);

• •    аутентификация и авторизация.

Существует большое количество готовых программных решений класса middleware, наиболее известными из которых являются CORBA [], DCOM [http://www. ], SOAP [], DCE/RPC [], XML-RPC [], ICE [ html], D-BUS.

Связующее ПО в том или ином виде применяется в большинстве современных систем управления телескопами. В качестве примеров можно привести применяющиеся во многих обсерваториях универ- сальные системы управления INDI [http://www. ] и RTS2 [], а также разрабатываемый в ГАО РАН пакет FORTE [Kouprianov, 2011], вторую версию (generation 2) системы управления наблюдениями телескопа «Субару» [Jeschke et al., 2008], перспективные разработки обсерватории Кека [Morrison, Johnson, 2010], систему управления солнечного телескопа ATST и др. На 4.1-метровом телескопе SOAR (Серро-Пачон, Чили) для создания дистанционного графического интерфейса используются возможности коммерческой платформы LabVIEW [; Cecil, Crain, 2004].

Уточненные требования к распределенной системе управления ПЗС-камерами можно сформулировать следующим образом:

• •    построение системы по технологии клиент – сервер: компонент, исполняемый на сервере камер, должен обслуживать подключения одной или нескольких клиентских программ, запускаемых удаленными наблюдателями;

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

• •    сетевое взаимодействие должно быть реализовано с использованием связующего ПО, реализующего функции удаленного вызова процедур (Remote Procedure Call, RPC);

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

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

Общее описание системы

Структура распределенной системы управления камерами приведена на рис. 1. Основными компонентами ПО системы являются: диспетчер камер (ДК), модули сопряжения камер (МСК), связующее ПО (MSRPC), пользовательские программы (camclient, вместе с вспомогательной библиотекой camctl). В терминологии архитектуры клиент – сервер ДК (вместе с МСК) является серверным компонентом, обслуживающим клиентов (в роли которых выступают программы camclient).

Программа ДК является 32-разрядным приложением без интерфейса пользователя, реализованным в виде службы Windows (Windows service) и выполняющимся на сервере камер. Она выполняет следующие основные функции:

• •    ожидание и обработка запросов на подключение к камерам от программ-клиентов – при поступлении запроса проверяется возможность доступа к

камере, выполняется загрузка и инициализация со- ответствующего МСК;

Рис. 1. Структура распределенной системы управления камерами.

• •    получение команд управления камерой от клиентской программы и передача их в МСК;

• •    при каждой экспозиции – выполнение запроса к системе управления телескопом;

• •    по окончании каждой экспозиции – загрузка введенного кадра из МСК, преобразование его в стандартный формат FITS и сохранение в каталоге, доступном программам-клиентам по сети;

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

На рис. 1 в качестве примера изображена ситуация, когда программа ДК обслуживает два сеанса (логических подключения) работы с камерами. Первый экземпляр программы camclient, запущенный на АРМ наблюдателя, подключен к камере FLI. Второй экземпляр camclient, выполняющийся локально на сервере камер, подключен к камере S3C.

Модули сопряжения камер реализуются в виде DLL-библиотек, загружаемых в адресное пространство процесса ДК. Основное назначение МСК заключается в реализации универсального (не зависящего от типа камеры) программного интерфейса управления камерой. Через этот стандартный программный интерфейс происходит взаимодействие между ДК и МСК. Реализация МСК для конкретного типа камер использует базовое программное обеспечение, поставляемое производителем, поскольку при этом необходимо учитывать все особенности управления данным типом камер. Как правило, в состав базового ПО от производителя входят библиотека для работы с камерой (libfli.dll и s3c_pci.dll на рис. 1) и драйвер операционной системы. Разработаны и используются МСК для следующих типов камер:

• •    S3C (НПП «Силар», Россия [ http://www.silar . ru/produce1.html]);

• •    FLI (Finger Lakes Instrumentation, USA);

• •    SBIG (Santa Barbara Instrument Group, USA);

• •    ARC (Astronomical Research Cameras, USA);

• •    VS-CTT-423 (НПК «ВИДЕОСКАН», Россия);

• •    эмулятор камеры (применяется для отладки других компонентов системы).

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

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

Связующее ПО MSRPC (Microsoft RPC) [] является вариантом стандарта DCE/RPC, реализованным фирмой Microsoft для платформы Windows NT. Сетевое взаимодействие здесь основывается на классической концепции удаленного вызова процедуры (Remote Procedure Call, RPC). Это выглядит так, что когда одна программа (RPC-клиент) делает вызов процедуры, то выполнение этой процедуры происходит в другой программе (RPC-сервере) и в общем случае на другом компьютере. Аргументы процедуры пересылаются от RPC-клиента к RPC-серверу в момент ее вызова. После выполнения процедуры результат пересылается обратно к RPC-клиенту (который находится в состоянии ожидания в течение времени выполнения). Функции связующего ПО, таким образом, состоят в пересылке по сети имени процедуры, ее аргументов и результата, преобразовании форматов данных, защите от сбоев при передаче данных и т. д.

Далее перечислены основные причины выбора DCE/RPC (MSRPC) в качестве связующего ПО для системы управления камерами:

• •    Простота использования: технология DCE/RPC разработана для быстрого превращения монолитных приложений в распределенные, скрывает детали сетевого взаимодействия и не требует опыта программирования сетевых приложений; вызов удаленной процедуры по синтаксису не отличается от вызова локальной процедуры; реализация MSRPC встроена в ОС семейства Windows NT.

• •    Независимость от архитектуры: существуют реализации DCE/RPC для всех распространенных платформ и операционных систем; преобразование форматов данных при удаленных вызовах выполняется автоматически.

• •    Поддержка различных транспортных протоколов (TCP, UDP, IPX, SPX, NamedPipes, NetBIOS/NetBEUI, AppleTalk, локальные вызовы через разделяемую память и т. д.).

• •    Эффективность: использование бинарного формата кодирования аргументов и результатов

RPC-вызовов уменьшает объем передаваемых сообщений и повышает скорость клиент-серверного взаимодействия (по сравнению с системами, где используется текстовый формат представления данных, такими как XML-RPC и SOAP).

Использование технологии DCE/RPC при разработке приложений происходит следующим образом. Сначала необходимо создать описание интерфейса RPC-сервера – перечня экспортируемых процедур с указанием типов их аргументов. Описание делается на специальном языке IDL (Interface Definition Language) и помещается в файлы с расширением idl. На основе этого описания с помощью IDL-компилятора генерируется пара файлов с программным кодом на языке C, предназначенных для использования на стороне RPC-сервера и RPC-клиента. Например, описание интерфейса ДК содержится в файле camhost_rpc.idl. Генерируемые c-файлы имеют имена camhost_rpc_s.c и camhost_rpc_c.c и используются соответственно при сборке программы ДК и модуля camctl.

Программное обеспечение системы управления камерами (ДК, МСК, camclient, camctl) разрабатывалось с использованием среды Microsoft Visual Studio версии 6.0.

Диспетчер камер

Запуск службы ДК (camhost.exe) может производиться при старте операционной системы сервера камер. Далее программа регистрирует в операционной системе RPC-интерфейс, который она реализует, и переходит в режим ожидания вызовов экспортированных процедур. Для начала работы с камерой клиентское приложение осуществляет удаленный вызов процедуры camhost_open, при этом ДК выполняет следующие действия:

• •    Если данная камера уже используется другой клиентской программой и новой программой затребован доступ в режиме просмотра (вид доступа определяется одним из аргументов процедуры), то вызов camhost_open завершается успешно, т. е. ДК всегда разрешает доступ в режиме просмотра.

• •    Если данная камера еще не используется другой клиентской программой, то ДК создает новый экземпляр класса Camera. При создании объекта происходит загрузка соответствующего МСК и вызов процедуры инициализации аппаратуры камеры. Все необходимые параметры инициализации считываются из файлов параметров ДК и МСК. Создается также отдельный программный поток (thread), обслуживающий данную камеру. Для учета подключений программа ДК ведет списки объектов типа Camera (активные камеры) и Client (подключенные программы-клиенты).

Если процедура camhost_open одновременно вызывается двумя или более клиентскими приложениями, то такие вызовы ДК обрабатывает последовательно, чтобы исключить ситуацию гонок (race conditions) .

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

• •    получение информации о характеристиках камеры;

• •    установка/чтение параметров кадра;

• •    установка/чтение параметров системы охлаждения;

• •    получение информации о текущем состоянии процесса экспозиции;

• •    проверка очереди событий (ожидание событий);

• •    запуск и отмена выполнения экспозиций;

• •    коррекция положения телескопа (данная команда не выполняется ДК, а транслируется в систему управления телескопом).

В большинстве случаев выполнение некоторой операции по управлению камерой происходит по следующему сценарию (на примере операции запуска экспозиций):

• •    наблюдатель инициирует выполнение команды – нажимает кнопку запуска экспозиций в программе camclient;

• •    программа camclient выполняет вызов удаленной процедуры camhost_startexposure, реализованной в ДК;

• •    ДК анализирует состояние объекта Client и проверяет тип доступа к камере (если данный экземпляр camclient имеет доступ к камере только в режиме просмотра, то вызов удаленной процедуры запуска экспозиции завершается с ошибкой);

• •    ДК производит вызов соответствующей функции МСК данной камеры.

Задачей потока камеры является ожидание асинхронных событий от МСК, таких как готовность кадра и изменение температуры ПЗС-кристалла, и реакция на них. В большинстве случаев реакция на событие завершается помещением информации о нем в очередь событий объекта Client. Программы-клиенты считывают очереди событий с помощью     вызова     удаленной     процедуры camhost waitevent.

_

По событию готовности кадра ДК выполняет следующие действия:

• •    загрузка массива изображения из МСК во внутренний буфер ДК;

• •    преобразование изображения в формат FITS, формирование заголовка FITS-файла (параметры камеры, кадра, телескопа, привязка к WCS (World Coordinate System) и т. д.), запись FITS-файла в каталог на диске, доступный клиентским программам по сети;

• •    помещение в очередь клиентского приложения (объект Client) события готовности кадра вместе с его идентификатором (номером кадра).

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

• •    координаты наведения телескопа (α, δ) в системе ICRS (International Celestial Reference System);

• •    инструментальные координаты и скорости телескопа t, δ, t′, δ′;

• •    имя объекта наблюдения.

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

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

Приложение camclient

При запуске программа camclient считывает файл параметров (ini-файл), передаваемый в качестве аргумента. Файл параметров содержит идентификатор нужной камеры, сетевой адрес сервера камер и параметры подключения к ДК, тип доступа к камере (полный доступ/просмотр кадров), начальные параметры работы камеры и отображения кадров, другую служебную информацию. После этого программа camclient выполняет обращение к серверу камер для вызова удаленной процедуры camhost_open. При успешном выполнении процедуры (в процессе которого ДК загружает соответствующий МСК и производится инициализация аппаратуры камеры) камера считается логически подключенной к программе camclient (находится под управлением программы camclient).

На рис. 2 изображены основное окно программы, диалоговое окно управления камерой (окно с заголовком «Управление…»), диалоговое окно настроек камеры (окно с заголовком «Настройки камеры»).

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

Просмотр информации о ПЗС-камере

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

Настройка параметров работы камеры

Перед началом получения изображений программа camclient позволяет настроить различные параметры работы камеры: требуемую температуру охлаждения ПЗС-кристалла, длительность экспозиции и интервал между кадрами, тип кадра (световой/темновой), бини-рование, частоту оцифровки изображения (если камера поддерживает несколько частот) и т. д.

Запуск/останов экспозиций

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

Отображение получаемых кадров и сопутствующей информации

После того как ПЗС-камера завершает цикл очередн ой экспозиции, полученное изображение преобра-

Рис. 2. Основное окно программы camclient, диалоговые окна управления камерой и настроек камеры.

зуется в ДК в файл формата FITS, снабжается дополнительной информацией (заголовком кадра) и помещается в специальный сетевой каталог, откуда программа camclient загружает его для отображения на экране. При отображении программа позволяет выбирать масштаб кадра, передаточную функцию и диапазон отображения. Программа отображает справочную информацию из заголовка кадра (размер кадра, текущий оптический фильтр и т. д.). При наведении мышью на некоторую точку кадра отображаются координаты ( x , y ) пикселя, значение пикселя в единицах ADU (Analog-to-digital Unit), а также координаты (α, δ) пикселя (при наличии WCS-информации в заголовке кадра).

Отображение параметров звезды, выбранной на кадре

Для изображений звездных полей наблюдатель может выбрать на кадре область анализа параметров звезды, при этом для указанной области будут отображаться профиль интенсивности звезды, значение пикселя с максимальной интенсивностью, инструментальная звездная величина, оценка параметра FWHM (full width at half maximum) профиля звезды.

Сохранение на диск серии кадров либо одиночных кадров

По нажатию кнопки «Сохранить кадр» программа camclient позволяет сохранить на диск кадр, отображаемый в данный момент на экране. При нажатии кнопки «Сохранить серию» будет происходить сохранение всех последовательно получаемых кадров (FITS-файлов) с учетом заданной схемы именования файлов (указывается в ini-файле).

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

Система управления камерами может быть настроена на взаимодействие с системой управления телескопом. В этом случае ДК при формировании очередного кадра будет выполнять RPC-запрос текущих координат наведения телескопа и добавлять эту информацию в заголовок кадра (т. е. делать первичную WCS-привязку кадра). WCS-привязка кадра позволяет программе camclient выводить в строке статуса координаты (α, δ) любого пикселя при наведении мышью, а также выполнять коррекцию положения телескопа. Для этого необходимо выбрать на текущем кадре точку изображения (звезду), которая должна оказаться в центре изображения (на маркере центра кадра), и по щелчку правой кнопкой мыши выбрать в появившемся контекстном меню пункт «Сдвинуть в центр».

Использование

С начала 2008 г. система управления камерами применяется на звездном телескопе АЗТ-33ИК и к настоящему моменту обслуживает следующие ПЗС-камеры (рис. 3):

• •    камера S3C в кассегреновском фокусе телескопа;

• •    камера S3C на вспомогательном 30-сантиметровом объективе (KUA);

• •    камера VS-CTT на вспомогательном 20-сантиметровом объективе ПДНК (прибора дальнего ночного короткофокусного);

• •    камера ST-8 в составе спектрографа SGS фирмы SBIG (в кассегреновском фокусе);

• •    камера ST-9 в системе подсмотра ИК-фотометра (в кассегреновском фокусе).

Обе камеры S3C через волоконно-оптические линии связи подключены к компьютерам azt33-dome и azt33-m2, расположенным в комнате управления башни телескопа (в компьютерах установлены специальные PCI-адаптеры). Камера VS-CTT также подключена через специализированный интерфейс (PCI-адаптер). Камеры ST-8 и ST-9 имеют USB-интерфейс, поэтому для их обслуживания на телескопе установлен портативный компьютер diamond промышленного исполнения (диапазон рабочих температур от –20 до +65 °C). Таким образом, в данной системе существуют три сервера камер (azt33-dome, azt33-m2 и diamond), в совокупности обслуживающие пять камер. Все компьютеры включены в локальную сеть обсерватории.

Доступно два варианта выполнения наблюдений – локальный, из башни телескопа, и удаленный, из здания техкорпуса (компьютер azt33-far). В первом случае компьютеры azt33-dome и azt33-m2 выполняют функцию не только сервера камер, но и терминала наблюдателя (на них выполняются программы camclient для управления камерами). В режиме

Рис. 3 . Схема развертывания распределенной системы управления камерами на телескопе АЗТ-33ИК.

удаленного использования все камеры управляются с компьютера azt33-far. Все компьютеры работают под управлением операционных систем Windows 2000 Professional и Windows XP Professional.

С сентября 2008 г. система управления камерами применяется на звездном телескопе АЗТ-14 (камера FLI Proline PL4301E в первичном фокусе, камера S1C в объективе ПДНК).

С 2010 г. система применяется на Большом вне-затменном коронографе (камеры FLI PL4301E, FLI PL1001E, SBIG STL-11000 в каналах изображений Солнца в линиях Hα, HeII и изображения щели спектрографа в белом свете).

Заключение

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

• •    Разработка инсталлятора для облегчения процесса установки и настройки системы как на сервере камер, так и на АРМ наблюдателя.

• •    Разработка клиентских программ (скриптов) для автоматического управления ПЗС-камерами при решении некоторых рутинных задач (получение калибровочных изображений, выполнение обзоров неба, проведение алертных наблюдений гамма-всплесков и т. д.). В качестве языка программирования здесь предполагается использовать Питон – таким образом, потребуется также разработать библиотеку для доступа к системе управления ПЗС-камерами из программ на Питоне.

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

• •    Обеспечение возможности передачи (отбора) прав доступа к ПЗС-камере между программами-

• клиентами (пример использования – автоматическое прерывание процесса регулярных наблюдений при возникновении некоторого события (алерта), запуск специальной клиентской программы для проведения алертных наблюдений).

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

СПИСОК ЛИТЕРАТУРЫ bernal a., Martínez L., Hernández H., et al. active remote observing system for the 1-m telescope at Tonantzintla Observatory // Proc. SPIE. 2006. V. 6274. 62741R.

Cosentino R., Bruno P., Gonzalez M., et al. Instruments remote control project at TNG: SARG implementation // Proc. SPIE. 2004. V. 5492. Р. 891.

Cecil G.N., Crain J.A. SOAR remote observing: tactics and early results // Proc. SPIE. 2004. V. 5493. Р. 73.

Grigsby B.J., Chloros K., Gates J., et al. Remote observing with the Nickel Telescope at Lick Observatory // Proc. SPIE. 2008. V. 7016: Observatory Operations: Strategies, Processes and Systems / Еds. R.J. Brissenden, D.R. Silva. 701627.

Jeschke E., Bon B., Inagaki T., et al. A lightweight fault-tolerant middleware for a Subaru Telescope second generation observation control system // Proc. SPIE. 2008. V. 7019. 70190U.

Kibrick R.I., Wirth G.D., Gates E.L., et al. A shared approach to supporting remote observing for multiple observatories // Proc. SPIE. 2010. V. 7737: Observatory Operations: Strategies, Processes, and Systems III. 773712.

Kosugi G., Sasaki T. , Yagi M. , et al. Remote observing capability with Subaru Telescope // Proc. SPIE. 2004. V. 5496. Р. 695.

Kouprianov V. Data acquisition software for ISON project // 62nd International Astronautical Congress 2011 (IAC-2011). Space Debris Symposium (A6). IAC-11.A6.1.8. 2011. V. 2. Р. 1855.

Morrison D.A., Johnson J.M. Adapting a publish-subscribe middleware to a RPC response pattern // Proc. SPIE. 2010. V. 7740. 77400E.

Институт солнечно-земной физики СО РАН, Иркутск, Россия