Архитектура программного обеспечения систем оптической регистрации Текст научной статьи по специальности «Компьютерные и информационные науки»

V ПРОГРАММНЫЕ И АППАРАТНЫЕ СРЕДСТВА

УДК 004.42, 520.8

с1о1:10.15217/1ззп1684-8853.2016.3.51

АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМ ОПТИЧЕСКОЙ РЕГИСТРАЦИИ

И. В. Афанасьева а, б, ведущий инженер, аспирант

Ф. А. Новиковв, доктор техн. наук, профессор

^Специальная астрофизическая обсерватория РАН, Нижний Архыз, РФ

бСанкт-Петербургский национальный исследовательский университет информационных технологий,

механики и оптики, Санкт-Петербург, РФ

вСанкт-Петербургский политехнический университет Петра Великого, Санкт-Петербург, РФ

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

Ключевые слова — система сбора данных, автоматное программирование, ПЗС-камера, наблюдательная астрономия, разработка программного обеспечения.

Введение

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

Типичная астрономическая система регистрации состоит из криостатируемой камеры со встроенным матричным приемником изображения, контроллера, управляющего работой камеры, и интерфейса передачи данных в удаленный компьютер. Формат фотоприемника может существенно варьироваться: однокристальные матрицы имеют размеры от 2048x2048 (2Кх2К) до 10Кх10К пикселей, а мозаичные — до п х (2Кх4К) пикселей. В ходе наблюдений необходимо обеспечить прием, визуализацию, обработку и хранение информации для дальнейшего выявления физических, химических и других свойств астрономических объектов.

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

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

История развития наблюдательных средств оптической астрономии

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

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

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

К 1970-м гг. лидирующее положение среди приемников заняли телевизионные трубки — ви-диконы [2]. Телевизионный метод обладал рядом достоинств: широким спектральным диапазоном, возможностью получать изображения с более короткими экспозициями, а также возможностью вести наблюдения дистанционно из лаборатории. Было разработано множество вариантов таких приборов, отличающихся материалом мишени, наличием встроенного ЭОП, но все они имели ряд серьезных недостатков: большие размеры, низкую квантовую эффективность (на уровне 5-10 %), малый динамический диапазон.

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

с зарядовой связью (ПЗС) [3, 4], которые состоят из большого числа светочувствительных ячеек, называемых пикселями, расположенных в виде одномерной линейки либо двумерной матрицы на кремниевой основе. Самым важным преимуществом ПЗС-матриц является большая квантовая эффективность — световая чувствительность достигает 98 %, т. е. практически все фотоны, достигшие матрицы, генерируют электроны (заряд) в светочувствительном элементе. Накопленные электроны через систему переноса заряда транспортируются в усилитель, затем сигнал оцифровывается аналого-цифровым преобразователем и в цифровом виде передается в компьютер. Недостатками ПЗС являются высокая стоимость приборов научного класса и большой тепловой шум при комнатных температурах. Чтобы снизить тепловой шум, применяют системы охлаждения кристалла матрицы до температур от минус 80 до минус 130 °С.

В 2008 г. альтернативой ПЗС стали КМОП-матрицы [5]. Транзисторный усилитель для считывания, внедренный в каждый пиксель, позволяет трансформировать заряд в напряжение без его переноса, а шины считывания строк и столбцов дают возможность произвольного считывания сигнала с любого из пикселей. Недостатками КМОП-технологии являются наличие структурного шума и высокий тепловой шум, а также плохой коэффициент заполнения, поскольку в каждом пикселе требуется место не только светочувствительному элементу, но и усилителю, и шинам. Однако относительная дешевизна производства и низкое энергопотребление делают этот приемник весьма конкурентоспособным.

Таким образом, наиболее распространенными и перспективными являются приемники на основе ПЗС- или КМОП-технологий.

Структура системы цифровой регистрации изображений

Система цифровой регистрации изображений [6], предназначенная для наземных наблюдений на оптическом телескопе, имеет в своем составе:

— криостатируемую камеру на основе ПЗС-или КМОП-матриц;

— контроллер камеры и стабилизированный источник питания;

— плату связи (интерфейс камера-компьютер);

— программу сбора данных [7].

Основная задача программы сбора — получение астрономических данных (изображений) в заданном режиме считывания. Изображение, т. е. набор пикселей, представлено двумерным массивом беззнаковых 16-битных чисел. Размер кадра и скорость потока данных зависят от характеристик системы регистрации (табл. 1).

■ Таблица 1

Тип приемника Размер кадра, пиксели Скорость считывания/ выход, КБ/с Число выходов Скорость потока, МБ/с Время считывания кадра, с

CCD42-90 8192 х 9224 4000 16 64 2,4

CCD60-01 128х130 16 500 1 16,5 0,002

KAF-4320 2092 х 2092 8000 4 32 0,3

CCD42-90 2048х4612 128/500/2000 2 4 4,8

KAF-16801 4096 х 4096 1000/8000 4 32 1,0

CCD203 4096 х 4096 100/200/400/2000 4 8 4,2

CCD42-40 2048 х 2052 128/500/2000 2 4 2,2

pnCCD 264х264 7000 8 56 0,003

CCD44-82 16 384 х 8192 2000 32 64 4,2

CMOS HAWAII-1 1024 х 1024 2000 4 8 0,25

CCD261-84 2048х 4104 2000 2 4 4,1

CCD230-84 4096х 4112 10 000 4 40 0,8

Начиная с 1998 г., в САО РАН разработано несколько поколений контроллеров семейства DINACON для ПЗС-приемников. В них впервые в мире реализована цифровая оптимальная противошумовая фильтрация видеосигнала, а также цифровая коррекция нестабильности и нелинейности передаточной характеристики «свет/ цифровой сигнал» в реальном времени считывания кадров. Это позволило достичь наилучших из известных результатов по чувствительности и фотометрической стабильности для астрономических ПЗС-систем [6].

Контроллер представляет собой мультипроцессорную систему (на основе DSP или FPGA) и имеет модульное строение на основе плат стандарта Eurocard. Контроллер включает следующие устройства:

— модуль управления (коммуникационный);

— модуль генератора и драйверов управляющих сигналов;

— модуль видеопроцессора;

— блок питания.

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

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

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

— по шине PCI;

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

— через сетевой адаптер оптоволоконной связи.

Таким образом, мы охарактеризовали класс

рассматриваемых аппаратных систем.

Требования к программной системе сбора данных

Исследования в области разработки архитектуры для программ сбора астрономических данных описаны в работах [8-11]. Наша модель и методика проектирования в своих основах не противоречат указанным мировым тенденциям, но за счет детального учета особенностей используемой аппаратуры предлагаемая архитектура позволяет добиться сравнительно лучших показателей работы программного обеспечения.

Перечислим функциональные требования к программному обеспечению.

■ Рис. 1. Варианты использования системы сбора

Программа должна обеспечивать проведение астрономических наблюдений, что включает в себя:

— инициализацию контроллера;

— накопление, считывание и получение данных в различных режимах (кадровом, фрагмент-ном, видео, с бинингом1, пакетном), в том числе обеспечение задания параметров экспозиции и считывания:

— длительность экспозиции;

— кратность бининга по двум координатам;

— скорость считывания элементов изображения;

— номер используемого выходного узла приемника;

— коэффициент усиления видеоканала;

— координаты считываемого фрагмента изображения;

— число кадров в серии;

— сохранение полученных изображений;

— визуализацию и анализ видеоданных;

— настройку системы регистрации, в том числе:

— диагностику, тестирование линии связи и узлов контроллера;

— измерение фотоэлектрических характеристик;

— автоматический мониторинг и постоянный вывод текущих значений следующих параметров:

— температуры приемника;

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

■ Таблица 2

Требование Расшифровка

Быстрая адаптация к новым ПСЗ-системам Универсальная архитектура, позволяющая работать с разными типами контроллеров, чтобы минимизировать число разнородных разработок

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

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

Повторное использование Проектирование системы таким образом, чтобы ее фрагменты можно было повторно использовать в других системах

— уровней напряжений управляющих сигналов приемника;

— уровней напряжений и токов выходных узлов;

— состояния питания камеры.

Зафиксируем данные требования на диаграмме вариантов использования UML [12] (рис. 1).

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

Нефункциональные требования к программе приведены в табл. 2.

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

Архитектура и алгоритмы управления системой сбора

Системы реального времени реализуют цикл управления «стимул-реакция». Такие системы К. Бок [13] называет реагирующими, они взаимодействуют с окружающей средой путем обмена сообщениями в темпе, задаваемом средой. Все системы управления астрономическими инструментами являются реагирующими. Вообще говоря, описывать поведение можно разными спосо-

бами: переходами состояний, потоками управления и данных, последовательностями сообщений [13, 14]. Потоки управления и данных больше подходят для описания последовательных бизнес-процессов, а не реагирующих систем, в то время как последовательности сообщений имеют слишком низкий, приближенный к объектам, уровень. Поэтому для описания реагирующих систем рассматриваются модели поведения, основанные на переходах состояний.

Среди моделей, основанных на диаграммах состояний, в первую очередь необходимо указать автоматное программирование профессора А. Шалыто. В соответствии с парадигмой автоматного программирования [15, 16], программы в целом предлагается строить как системы автоматизированных объектов управления, каждый из которых состоит из объектов управления

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

Перейдем к описанию поведения системы сбора данных. На рис. 2 представлены диаграмма связей и диаграмма состояний «головного» автомата управления приложением. Из схемы связей видно, что автомат принимает команды и события из меню и автоматов А2, А4 и А7 и управляет автоматом А2. В свою очередь автомат А2 (управление клиентами) принимает входные

A4

A2

I

L

A7 г

1

userIn(cmd,p)

getTl(d) endI(er)

Команда

меню Получить

телеметрию Инициализация

dispIm(im)

updTele(d)

завершена Показать

изображение Обновить

brdErr()

телеметрию Ошибка

платы связи

Таймаут (60 с)

cmd==c_init er==0

A1

Application

e1 z11

e21 z1

e22 z2

e71 z3

e41

e42

t0

x0

x1

Автомат

Имя: A1

Название: Application

Выполнить

команду

Визуализировать

apCmd(cmd,p)

A2

изображение Сохранить значения

dispIm1(im)

в массиве телеметрии Выдать значения из

tlm = d

массива телеметрии

d = tlm

tlm Массив телеметрии

cmd Команда меню

p Параметры команды

d Массив данных

im Изображение

er Код ошибки

■ Рис. 2. Диаграмма связей и алгоритм управления приложением

A2 Г

1 1

1 1

1 1

L

A5 г

1 I

1 I

A4 г

1 I

L

aborto

stop()

initO

exp(e)

camResQ

okExpO

errExpO

okInit()

errInitQ

Прервать

экспозицию Остановить

экспозицию Выполнить

инициализацию Выполнить

экспозицию Сброс

камеры Экспозиция

выполнена Экспозиция

не выполнена Инициализация

выполнена Инициализация

не выполнена

Таймаут(60 с)

Таймаут^.^с) Таймер (1 с)

Таймер (15 с)

doTele==0 e.tm<1 n>0 remTm>1 remTm==0 n==1

er Код ошибки

e Параметры экспозиции

n Число экспозиций

tmt Таймаут

A3

Observe

e23 z31

e24 z32

e25 z33

e26 z34

e51 z35

e52 z36

e53 z37

e43

e44 z38

z39

t0

t1 z30

t2

t3 z0

z1

x0 z2

x1 z3

x2 z4

x3 z5

x4 z6

x5 z7 z8 z9 z1 1

Автомат

Имя: A3

Название: Observe

Инициализация

завершена Экспозиция

завершена Записать

endExp(er,tmt)

параметры Прочитать вре-

мя экспозиции Начать

инициализацию Прочитать

телеметрию Запустить

считывание

Запуск обычной

экспозиции Запуск быстрой

экспозиции Серия быстрых экспозиций

endInit(er)

wrPar(e)

rtm = remTm()

doInit()

er = doTele()

rdData(e)

single(e)

fast(e)

multi(e)

er = 0

er = 1

er= 2;

er= 3; tmt = 0

er= 4; tmt = 0

er = 5; tmt = 0

n = n -1

tmt = e.t2

n = 1

tmt = 0

A2

A4

A5

n = e.n

C1 = e26&&x1 C3 = e52 &&-x2 C5 = e52 &&x2 &&-x1 C7 = t3&&-x0 C2 = e26&&-x1 C4 = e52 &&x2 &&x1 C6 = t3 &&x0 C8 = t2 &&-x3 &&-x4

■ Рис. 3. Диаграмма связей и алгоритм управления процессом наблюдений

воздействия из автоматов А1 и А3 и управляет автоматами А1 и А3. Автомат А6 обрабатывает полученные данные и формирует изображение, А7 визуализирует кадр и подготавливает данные для записи, А8 производит запись. Схемы автоматов А2, А6, А7 и А8 мы не приводим, поскольку они тривиальны.

Автомат управления наблюдательным процессом А3 (рис. 3) принимает команды и события из автоматов А2, А4 и А5, а также от таймеров и управляет автоматами А2, А4 и А5. Автомат имеет семь состояний. Симметричность автомата не случайна. На каждую команду есть ответ-

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

Автомат управления последовательным портом A4 (рис. 4) принимает команды и события из автоматов A3 и A5 и управляет автоматами A1, A3 и A5. Каждая команда, поступившая в состоянии Ready, вызывает переход в состояние Read_ write, где происходит ее преобразование в последовательность команд записи и чтения данных в соответствии с протоколом, реализованным в контроллере.

A3

A5

wrPar(e)

remTm() : rtm

doinitO

doTele() : er

startEx(e)

Записать

параметры Прочитать вре -

мя экспозиции Начать

инициализацию Прочитать

телеметрию Запуск

reset 4()

накопления Ошибка

readErr()

камеры Ошибка

isDone()

UART

Выполнение

завершено

success ==true initBrd ==true

e35 && x1/z:2;7

A4

UART

e33 z41

e34 z42

e35 z43

e36 z44

e54 z45

e1 z46

e2 z1

e3 z2 z3

x0 x1 z4 z5 z6 z7

Автомат

Имя: A4

Название : UART

Обновить

телеметрию Ошибка

платы связи Инициализация

выполнена Инициализация

не выполнена Сброс

камеры Инициализация

updTele(d)

brdErr()

okInit()

errInit()

reset()

фрейм-граббера Преобразовать команду

ok = initBrd()

A1

A3

A5

codeC (nc,ad ,w)

Инициализация UART

initUart()

Команда выполнена

ok = success()

Прочитать данные

rDw(ad) : dw

Записать данные

wDw(ad ,dw)

nc = N

nc = 3

e35 && -x1/z:42 ;44

N DO_C OK_C ER_C

1 e33 z45

2 e34 return (rtm ) return (-1)

3 e35 z43 z44

4 e36 z41 ;return (0) return (1)

5 e54 z45

nc Номер команды

e Параметры экспозиции

d Массив данных

rtm Отсчет времени

ad Адрес данных

dw Слово данных

■ Рис. 4. Диаграмма связей и алгоритм управления последовательным портом

A3

A4

multi(e)

rdData(e)

single(e)

fast(e)

reset()

e1/z55

ok = initBrd()

endGrab(im)

doneCmd()

A5

Board

Серия быстрых e30 z51

экспозиций

Запустить e37

считывание z52

Запуск обычной e38

экспозиции z53

Запуск быстрой e39

экспозиции z54

Сброс e45

камеры

Инициализация e46 z55

фрейм-граббера

Изображение e1

принято z1

Прием e2 z2

завершен z3

z4 z5 z6

Таймаут (e.t3 с) t0

alloc ==true x0

e46 && -x0/z5 0. Off

e46 && x0/z6 DO_C/RN_C

1. Ready

Автомат

Имя: A5

Название: Board

Сброс

камеры Экспозиция

camRes()

выполнена Экспозиция

не выполнена Запуск

накопления

Принять

startEx(e)

qIm(im)

изображение

Загрузка платы связи

Прием изображения

Прием серии изображений

Отменить прием

return(false)

return (true)

okExp()

errExp()

A3

A4

A6

ok = alloc()

sGrab(e)

mGrab(e)

abGrab()

im Изображение

e Параметры экспозиции

DO_C RN_C

e37 z2

e39 z2;z54

e30 z3;z54

■ Рис. 5. Диаграмма связей и алгоритм управления фрейм-граббером

Автомат управления фрейм-граббером А5 (рис. 5) отвечает за прием видеоданных. Из схемы связей видно, что автомат принимает команды и события от автоматов А3 и А4 и управляет автоматами А3, А4 и А6.

Еще один способ описания поведения реагирующих программ предложен в работе [18]. В этом подходе источники событий — управляющие автоматы и объекты управления — уравниваются в правах и могут быть описаны одними и теми же средствами. Действительно, если один автомат отправляет другому команду, то для первого автомата — это посылка управляющего воздействия (требуемый интерфейс), а для второго — прием события (предоставляемый интерфейс).

В UML [12] нотация интерфейсов применяется только на диаграммах классов и компонентов, мы же расширяем средство описания диаграмм состояний путем добавления в схему требуемых и предоставляемых интерфейсов.

Для сравнения стилей описания показываем автоматы А3, А4 и А5 в другой нотации (рис. 6-8).

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

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

A2

О

A2

A2

«command» initO

«command» exp(e)

«command» abort()

A2

О

«command» stop()

A2

A2

«command» endInit(er)

«command» endExp(er, tmt)

A3 Observe

n: Integer e: ExpoPar

standby

I

after (60 s)/endInit (2)

V

initO

Л

_L

initialization

entry / doInit()

errInit()/ endInit(1)

/\

init()

okInit()/ endInit(0)

init()

[doTele ==0]

idle

<

exp(e)/n=e.n;

wrPar(e)

after(15 s)

/\ Л

<

after(e.t1)/

<

endEx

[else]/ [i p(3,0)

endExp(2,0) doTele

/|\

= 0]

I

after(e.t1)/

after(15 s)

abortO/ endExp(1,0)

okExp()/ endExp(0,e.t2)

video

ndExp (2,0)

_I

abort()/ endExp(1,0)

[e.tm<1 && n > 1 ] /multi(e)

exposure

entry / single(e)

<::— stop()

[else]

camRes

Л

л

/n=1

after(1 s)

[remTm >1]

[else]/

endExp (5,0)

[remTm ==0] errExp ()/

-'

[e.tm<1 && n=1] /fast(e)

readout

endExp (4,0) entry / n=n-1 ;rdData(e)

Л

[e.tm<1]

[else ]

[n>0] !

okExp() [else ]/

[n>0] endExp(0,e.t2)

«command» single(e)

A5

«command» fast(e)

A5

«command» rdData(e)

A5

«command» multi(e)

A5

«command» okExpO

A5

«command» errExp()

A5

«command» camRes()

A5

«command» okInit()

A4

«command» errInit()

A4

«command» wrPar(e)

A4

«query» doTele():er

A4

«query» remTm():rtm A4

«command» doInit()

A4

error

■ Рис. 6. Диаграмма состояний процесса наблюдений

Компоненты Local Graphical Client и Acquisition Server являются исполняемыми и реализуют автоматы A1 и A2 соответственно. Компонент Observation реализует автомат A3 и обеспечивает процесс наблюдений, Controller Process управляет платой ввода-вывода и реализует протокол управления камерой (автоматы A4 и A5). Компонент Image Building реализует автоматы A6-A8 и отвечает за управление потоком данных, формирование и запись изображений.

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

A1

A1

A5

A5

«command» brdErr()

«command» updTele(d)

«query» initBrd():ok

«command» reset()

A5

О

A4 UART

nc,er: Integer d: Data rtm: Integer e: ExpoPar ad,dw: Integer ok: Boolean

«query» success():ok

«command» codeC(nc,ad ,w)

«command» rDw(ad):dw

«command» startEx(e)

«command» wDw(ad,dw)

[initBrd]/

initUart();nc=3

О

с:

doInit()

1

read write

codeC(nc,ad,w); dw=rDw(ad); wDw(ad,dw)

[else]/

brdErr();

errInit()

( off \

Л Л

«command» initUart()

«command» reset4()

-О

isDone()

DO_C /nc=N

reset4() /reset()

ready

readErr() /reset();

brdErr()

-o

[else]/ ER C

[success]/OK_C

«command» readErr()

-О

«command» isDone()

-О

N DO_C OK_C ER_C

1 wrPar(e) - reset()

2 startEx(e) - reset()

3 doInit() okInit() errInit()

4 doTele():er updTele(d);return(0) return(1)

5 remTm():rtm return(rtm) return(-1)

«command» wrPar(e) -О A3

«query» doTele():er -О A3

«query» remTm():rtm -О A3

«command» doInit()

-О A3

«command» okInit()

-С A3

«command» errInit()

A3

■ Рис. 7. Диаграмма состояний последовательного порта

A4

О

«command» reset()

A4

О

A4

A6

A5 Board

im: Image e: ExpoPar ok: Boolean

«command» endGrab(im)

-О

«command» doneCmd()

-О

«query» alloc():ok

«query» initBrd():ok

«command» startEx(e)

«command» sGrab(e)

«command» mGrab(e)

«command» qIm(im)

«command» abGrab()

1

after(e.t3)/ abGrab();

errExp()

endGrab(im) /qlm(im)

waiting

off

V

initBrd ()

О

doneCmd ()/ okExp()

DO_C /RN C

У

[else]/ return(false)

[alloc]/ return(true)

reset()/ camRes()

>

ready

DO C RN C

rdData(e) sGrab(e)

fast(e) sGrab(e);startEx()

multi(e) mGrab(e);startEx()

single(e) /startEx(e)

«command» single(e) -О A3

«command» fast(e)

-О A3

«command» multi(e) -О A3

«command» rdData(e) -О A3

«command» okExp()

-С A3

«command» errExp()

A3

«command» camRes()

A3

■ Рис. 8. Диаграмма состояний фрейм-граббера

A2 Clients

I12

A1

Application (Graphical Client)

Remote Client

3 I21

I32

4 I43

I45

X

AB

DataComplete

3

IS7

■ Рис. 9. Диаграмма взаимодействия автоматов

<<component>> а Local Graphical Client

IDisplay IApp

J

<<component>> a Remote Client

IServer

1

TCP/IP

<<component>> О Acquisition Server

i

<<component>> Image Building

-9-

IImage

"X

<<component>> Controller Process

X

IUart IBoard

IObserve

<component>> Observation

<< library» G Board Driver

■ Рис. 10. Архитектурная модель системы сбора данных

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

Заключение

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

Литература

1. Зайдель И. Н., Куренков Г. И. Электронно-оптические преобразователи. — М.: Сов. радио, 1970. — 60 с.

2. Абраменко А. Н., Агапов Е. С., Анисимов В. Ф. и

др. Телевизионная астрономия. — М.: Наука, 1983. — 272 с.

3. Howell S. B. Handbook of CCD Astronomy. — Cambridge University Press, 2006. — 223 p. doi:10.1017/CBO9780511807909

4. Janesick J. Scientific Charge-Coupled Devices. — Bellingham: SPIE, 2001. — 920 p.

5. Janesick J., Gunawan F., Dosluoglu T., et al. Scientific CMOS Pixels // Scientific Detectors for Astronomy. 2004. P. 103-114. doi:10.1007/1-4020-2527-0_11

6. Markelov S. V., Murzin V. A., Borisenko A. N., et al. A High-Sensitivity CCD Camera System for Observa-

За счет проведения реорганизации программного обеспечения на указанных принципах повысилась эффективность астрономических наблюдений — отказы во время наблюдений на телескопах по причине программных сбоев сократились в несколько раз. Применение разработанных моделей и алгоритмов позволило сократить сроки кодирования на 30 % за счет повторного использования компонентов и применения каркаса приложения. Экспериментально проверены архитектурные и программные решения, обеспечивающие ввод интенсивного потока цифровых видеоданных от многоканального фотоприемника. Достигнута стабильная работа системы сбора при скорости потока данных 80 МБ/с [7].

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

tions of Early Universe Objects // Astronomical and Astrophysical Transactions. 2000. Vol. 19. P. 579583. doi:10.1080/10556790008238604

7. Afanasieva I. V. Data Acquisition and Control System for High-Performance Large-Area CCD Systems // Astrophysical Bulletin. 2015. Vol. 70. N 2. P. 232237. doi:10.1134/S1990341315020108

8. Cumani C., Balestra A., Stegmeier J. Software for the ESO New General Detector Controller // Scientific Detectors for Astronomy. 2005. P. 585-588. doi:10.1007/1-4020-4330-9_67

9. Moore P., Buchholz N., Hunten M., et al. MONSOON Image Acquisition System: Control Techniques for Application to the Orthogonal Transfer Array Detectors // Proc. of SPIE. 2008. Vol. 7014. doi:10.1117/12.802254

10. Honscheid K., Elliott A., Bonati M., et al. The DECam DAQ System: Lessons Learned after One Year of

Operations // Proc. of SPIE. 2014. Vol. 9152. doi:10.1117/12.2057073

11. Karban R., Andolfato L., Bristow P., et al. Model Based Systems Engineering for Astronomical Projects// Proc. of SPIE. 2014. Vol. 9150. doi:10.1117/12.2055540

12. Новиков Ф. А., Иванов Д. Ю. Моделирование на UML. Теория, практика, видеокурс. — СПб.: Профессиональная литература. Наука и Техника, 2010. — 640 с.

13. Bock C., Odell J. Ontological Behavior Modeling// Journal of Object Technology. 2011. N 10. P. 1-36. doi:10.5381/jot.2011.10.1.a3

14. Bock C. Three Kinds of Behavior Models // Journal of Object-Oriented Programming. 1999. N 12 (4). P. 36-39.

15. Шалыто А. А. Парадигма автоматного программирования // Научно-технический вестник СПбГУ ИТМО. 2008. Вып. 53. С. 3-24.

16. Поликарпова Н. И., Шалыто А. А. Автоматное программирование. — СПб.: Питер, 2011. — 176 с.

17. Канжелев Н. И., Шалыто А. А. Преобразование графов переходов, представленных в формате MS Visio, в исходные коды программ для различных языков программирования. 2005. — 102 с. http:// is.ifmo.ru/projects/metaauto (дата обращения: 10.04.2016).

18. Atiskov A. Y., Novikov F. A., Fedorchenko L. N., et

al. Ontology-Based Analysis of Cryptography Standards and Possibilities of Their Harmonization// Theory and Practice of Cryptography Solutions for Secure Information Systems. — Hershey: IGI Global, 2013. P. 1-33. doi:10.4018/978-1-4666-4030-6.ch001

UDC 004.42, 520.8

doi:10.15217/issn1684-8853.2016.3.51

Software Architecture for Optical Detector Systems

Afanasieva I. V.a> b, Senior Engineer, Post-Graduate Student, [email protected]

Novikov F. A.c, Dr. Sc., Tech., Professor, [email protected]

aSpecial Astrophysical Observatory of RAS, Nizhnii Arkhyz, 369167, Russian Federation

bSaint-Petersburg National Research University of Information Technologies, Mechanics and Optics, 49, Kronverkskii St., 197101, Saint-Petersburg, Russian Federation

cPeter the Great St. Petersburg Polytechnic University, 29, Polytechnicheskaya St., 195251, Saint-Petersburg, Russian Federation

Introduction: Astronomical detector systems are the main tool for observations in the optical and infrared regions. But the requirements for speed, accuracy and reliability of video processing in astronomy are significantly higher than those in the industry and everyday life machine vision systems. Therefore, astronomical detector systems use ad hoc software. The imperfection of the existing software for CCD systems has led to a situation where an attempt to fix some software errors causes other faults; software development for new high-speed detector systems slows down and does not solve all the tasks. One of the effective ways to solve this problem is automata-based programming. Purpose: The goal is to develop a generalized architectural model for highly efficient and reliable video acquisition software taking into account the characteristics of the equipment in use. Results: The paper describes the structure of the digital detector system and shows the characteristics of the existing CCD systems. It is shown that astronomical control software should be classified as reactive systems whose behavior is determined using state-transition models. This approach lies at the basis of automata-based programming. The acquisition software algorithms are described by extended state machine diagrams. The paper shows the control automatons for the observation process and the interface board. The architectural model of the acquisition program was constructed from the interacting state machine diagram. Its main components are discussed in the paper. The implemented program is isomorphic to the architectural model. Practical relevance: The presented architecture was the basis of several acquisition programs designed for optical detector systems. The developed models and algorithms have increased the efficiency of astronomical observations and greatly reduced the software development life for a wide range of digital detector systems. The obtained results can be used for the design of new acquisition systems or for developing experiment automation software along with other types of astronomical devices.

Keywords — Data Acquisition System, Automata-Based Programming, CCD Camera, Observational Astronomy, Software Development.

References

1. Zaidel' I. N., Kurenkov G. I. Elektronno-opticheskie preobra-zovateli [Image Intensifiers]. Moscow, Sovetskoe Radio Publ., 1970. 60 p. (In Russian).

2. Abramenko A. N., Agapov E. S., Anisimov V. F., Galin-skii N. D., Prokof'eva V. V., Sinenok S. M. Televizionnaia astronomiia [Television Astronomy]. Moscow, Nauka Publ., 1983. 272 p. (In Russian).

3. Howell S. B. Handbook of CCD Astronomy. Cambridge University Press, 2006. 223 p. doi:10.1017/CBO9780511807909

4. Janesick J. Scientific Charge-Coupled Devices. Bellingham: SPIE, 2001. 920 p.

5. Janesick J., Gunawan F., Dosluoglu T., Tower J., McCaffrey N. Scientific CMOS Pixels. Scientific Detectors for Astronomy, 2004, pp. 103-114. doi:10.1007/1-4020-2527-0_11

6. Markelov S. V., Murzin V. A., Borisenko A. N., Ivaschen-ko N. G., Afanasieva I. V., Ardilanov V. I. A High-Sensitivity CCD Camera System for Observations of Early Universe Objects. Astronomical and Astrophysical Transactions, 2000, vol. 19, pp. 579-583. doi:10.1080/10556790008238604

7. Afanasieva I. V. Data Acquisition and Control System for High-Performance Large-Area CCD Systems. Astrophysical Bulletin, 2015, vol. 70, no. 2, pp. 232-237. doi:10.1134/ S1990341315020108

8. Cumani C., Balestra A., Stegmeier J. Software for the ESO New General Detector Controller. Scientific Detectors for Astronomy, 2005, pp. 585-588. doi:10.1007/1-4020-4330-9_67

9. Moore P., Buchholz N., Hunten M., et al. MONSOON Image Acquisition System: Control Techniques for Application to

the Orthogonal Transfer Array Detectors. Proc. of SPIE, 2008, vol. 7014. doi:10.1117/12.802254

10. Honscheid K., Elliott A., Bonati M., et al. The DECam DAQ System: Lessons Learned after One Year of Operations. Proc. of SPIE, 2014, vol. 9152. doi:10.1117/12.2057073

11. Karban R., Andolfato L., Bristow P., et al. Model Based Systems Engineering for Astronomical Projects. Proc. of SPIE, 2014, vol. 9150. doi:10.1117/12.2055540

12. Novikov F. A., Ivanov D. Iu. Modelirovanie na UML. Teori-ia,praktika, videokurs [Modeling in UML. Theory, Practice, Video Course]. Saint-Petersburg, Professional'naia literatura Publ., 2010. 640 p. (In Russian).

13. Bock C., Odell J. Ontological Behavior Modeling. Journal of Object Technology, 2011, no. 10, pp. 1-36. doi:10.5381/ jot.2011.10.1.a3

14. Bock C. Three Kinds of Behavior Models. Journal of Object-Oriented Programming, 1999, no. 12 (4), pp. 36-39.

15. Shalyto A. A. Paradigma avtomatnogo programmirovaniia [The Paradigm of Automata-Based Programming]. Scien-

tific and Technical Journal of Information Technologies, Mechanics and Optics, 2008, vol. 53, pp. 3-24 (In Russian).

16. Polikarpova N. I., Shalyto A. A. Avtomatnoe programmiro-vanie [Automata-Based Programming]. Saint-Petersburg, Piter Publ., 2011. 176 p. (In Russian).

17. Kanzhelev N. I., Shalyto A. A. Preobrazovanie grafov perek-hodov, predstavlennykh v formate MS Visio v iskhodnye kody programm dlia razlichnykh iazykov programmirovani-ia [Conversion of Transition Graphs Presented in MS Visio Format in the Source Code for Various Programming Languages]. 2005. 102 p. Available at: http://is.ifmo.ru/pro-jects/metaauto (accessed 10 April 2016).

18. Atiskov A. Y., Novikov F. A., Fedorchenko L. N., Vorobiev V. I., Moldovyan N. A. Ontology-Based Analysis of Cryptography Standards and Possibilities of Their Harmonization. Theory and Practice of Cryptography Solutions for Secure Information Systems, Hershey, IGI Global, 2013, pp. 1-33. doi:10.4018/978-1-4666-4030-6.ch001

УВАЖАЕМЫЕ АВТОРЫ!

Научная электронная библиотека (НЭБ) продолжает работу по реализации проекта SCIENCE INDEX. После того как Вы зарегистрируетесь на сайте НЭБ (http://elibrary.ru/ defaultx.asp), будет создана Ваша личная страничка, содержание которой составят не только Ваши персональные данные, но и перечень всех Ваших печатных трудов, имеющихся в базе данных НЭБ, включая диссертации, патенты и тезисы к конференциям, а также сравнительные индексы цитирования: РИНЦ (Российский индекс научного цитирования), h (индекс Хирша) от Web of Science и h от Scopus. После создания базового варианта Вашей персональной страницы Вы получите код доступа, который позволит Вам редактировать информацию, помогая создавать максимально объективную картину Вашей научной активности и цитирования Ваших трудов.