1 Энерговыделение (кэВ)

К исх. №
К вх. №
от
от
.04.2006г.
.04.2006г.
Н А У Ч Н О - И С СЛ Е ДО В А Т Е Л ЬС К И Й И Н С Т И ТУ Т Я Д Е Р Н О Й ФИ З И К И
Московского государственного университета им. М.В. Ломоносова
УДК 524.354
Номер государственной регистрации: Ф 40550
Экз.№ 1
инв. №
УТВЕРЖДАЮ
Директор научно-исследовательского
института ядерной физики имени
Д.В.Скобельцына МГУ имени
М.В.Ломоносова.
_____________М.И.Панасюк
«____»________________ 2008 г.
ИТОГОВЫЙ НАУЧНО-ТЕХНИЧЕСКИЙ ОТЧЕТ
«Формирование принципов построения и функционирования основных программных
модулей для решения научных задач в эксперименте с широкоапертурным гаммателескопом. Разработка систем хранения и передачи данных в блоке электроники
прибора. Оптимизация технологии изготовления элементов кодирующей маски
широкоапертурного гамма-телескопа. Проработка методики локализации гаммаквантов в позиционно-чувствительном детекторе широкоапертурного гаммателескопа. Оптимизация теплового режима функционирования широкоапертурного
гамма-телескопа на космическом аппарате.»
НИР «Гаммафон»
(этап 3 календарного плана договора от 29.05.2008 г. № 125-08,
пп. 2.3.2, 2.3.3, 2.3.4, 3.2.2, 3.2.3, 3.2.4 ТЗ на НИР «Гаммафон»)
Научный руководитель НИР,
с.н.с.
_____________С.И.Свертилов
«____»________________2008 г.
Ответственный исполнитель,
заведующий отделом
_____________И.В.Яшин
«____»________________2008 г.
2008
2
СПИСОК ИСПОЛНИТЕЛЕЙ
НИИЯФ МГУ
В.В. Богомолов
к.ф.-м.н., ст.н.с.
В.И. Галкин
д.ф.-м.н., зав. лабораторией
Ю.И. Денисов
к.ф.-м.н., зам. нач. отдела
О.В. Морозов
к.ф.-м.н., м.н.с.
C.И. Свертилов
д.ф.-м.н., ст.н.с., руководитель работ
Имет РАН
Н.Л. Кореновский
к.т.н., вед.н.с.
Н.Е. Клюева
гл. спец-ст
ФГУП КБ “Арсенал”
Г.Б. Виноградова
вед. инженер
М.И. Холодов
вед. инженер
Е.М. Чурбанов
вед. конструктор
3
РЕФЕРАТ
Отчет 142 стр., 13 рис., 7 таблиц, список литературы 2 наименования.
Формирование принципов построения и функционирования
основных программных модулей для решения научных задач в
эксперименте с широкоапертурным гамма-телескопом. Разработка систем
хранения и передачи данных в блоке электроники прибора. Оптимизация
технологии
изготовления
элементов
кодирующей
маски
широкоапертурного гамма-телескопа. Проработка методики локализации
гамма-квантов
в
позиционно-чувствительном
детекторе
широкоапертурного гамма-телескопа. Оптимизация теплового режима
функционирования широкоапертурного гамма-телескопа на космическом
аппарате.
Сформированы принципы построения и функционирования основных
программных модулей для решения научных задач в эксперимете с
широкоапертурным гамма-телескопом. Эти модули включают программу расчет матрицы отклика прибора, обеспечивающую решение обратной задачи –
восстановление изображений по выходным параметрам, программу,
реализующую моделирование взаимодействий гамма-квантов в позиционночувствительном детекторе, программы управления данными в блоке
электроники телескопа.
Разработана система хранения и передачи данных в блоке электроники
прибора, позволяющая. формировать весь объем информации с позиционночувствительных детекторов. Оптимизирована технология изготовления
элементов кодирующей маски широкоапертурного гамма-телескопа на основе
использования тантала в качестве материала маски. Проработана методика
локализации гамма-квантов в позиционно-чувствительном детекторе
широкоапертурного гамма-телескопа.
Оптимизирован тепловой режим функционирования широкоапертурного
гамма-телескопа на космическом аппарате, в том числе проработаны
технические
предложения
по
обеспечению
теплового
режима
функционирования детекторов широкоапертурного гамма-телескопа на борту
серийного космического аппарата нового поколения, проработаны технические
предложения по обеспечению теплового режима функционирования
электроники широкоапертурного гамма-телескопа с бортом космического
аппарата.
4
СОДЕРЖАНИЕ
Введение: цель, задачи и результаты выполнения работ……………………............... 5
Гл. 1. Принципы построения и функционирования основных
программных модулей для решения научных задач в эксперименте с
широкоапертурным гамма-телескопом……………………………...………...…8
§1.1. Основные научные задачи в эксперименте с широкоапертурным
гамма-телескопом и методы их решения……………..…..…………….………… 8
§1.2. Структура и объем выходных данных………………………………………...…... 12
§1.3. Основные программные модули, необходимые для решения научных задач
в эксперименте с широкоапертурным гамма-телескопом………..…………….. 24
Гл. 2. Системы хранения и передачи данных в блоке электроники
широкоапертурного гамма-телескопа…...……..……………………..........…...…….29
§2.1. Системы управления данными ……......……………...............................…………. 29
§2.2. Процессоры баз данных..…………………………..………….....…………..…..…..46
§2.3. Роль баз данных в приложениях реального времени……..….....…………..…..…..62
§2.4. Архитектура баз данных..…………………..……..………….....…………..…..…..66
Гл. 3. Локализация гамма-квантов в широкоапертурном гамма-телескопе
на основе метода кодированной апертуры………………………..………...….…… 96
§3.1. Метод кодированной апертуры в
широкоапертурном гамма-телескопе……….……………………….…….......... 96
§3.2. Оптимизация технологии изготовления элементов
кодирующей маски широкоапертурного гамма-телескопа….…….……………. 100
Гл. 4. Результаты проработки технических предложений по обеспечению
теплового режима функционирования
широкоапертурного гамма-телескопа……..………………………...………...… 111
§4.1. Система обеспечения теплового режима
широкоапертурного гамма-телескопа………………...…..…………….………… 111
§4.2. Результаты проработки технических предложений по обеспечению
теплового режима функционирования
широкоапертурного гамма-телескопа………………………………..…………... 113
§4.3. Оптимизация теплового режима функционирования
широкоапертурного гамма-телескопа……………………………....…………….. 116
Заключение..………...………....................……………………...………………………. 121
Заключение итоговое……………………………………………………………………. 122
Литература………………………………………………………………..…………………..…. 130
Приложение к гл.1…………………………………………………………………………...… 131
Приложение № 1. Выписка из протокола УС ................................................................. 140
Приложение № 2. Сведения о РНТД. ............................................................................... 142
5
Введение: цель, задачи и результаты выполнения работ.
Цель работ.
Основной целью работы является формирование принципов построения и
функционирования основных программных модулей для решения научных
задач в эксперименте с широкоапертурным гамма-телескопом. Разработка
систем хранения и передачи данных в блоке электроники прибора.
Оптимизация
технологии
изготовления
элементов
кодирующей
маски
широкоапертурного гамма-телескопа. Проработка методики локализации
гамма-квантов в позиционно-чувствительном детекторе широкоапертурного
гамма-телескопа.
Оптимизация
теплового
режима
функционирования
широкоапертурного гамма-телескопа на космическом аппарате.
Задачи работ.
Основные задачи работ, выполняемых согласно техническому заданию
(ТЗ) на научно-исследовательскую работу «Проработка предложений по
проведению мониторных наблюдений астрофизических источников и фона в
жестком рентгеновском и гамма-излучении (0.05 – 1.0 МэВ)» на этапе 3 в 2008
г. заключались в:
- формировании принципов построения и функционирования основных
программных модулей для решения научных задач в эксперименте с
широкоапертурным гамма-телескопом;
- разработке системы хранения и передачи данных в блоке электроники
прибора;
- оптимизации технологии изготовления элементов кодирующей маски
широкоапертурного гамма-телескопа;
- проработке методики локализации гамма-квантов в позиционночувствительном детекторе широкоапертурного гамма-телескопа;
оптимизации теплового режима функционирования широкоапертурного
6
гамма-телескопа на космическом аппарате.
(пп. 2.3.2, 2.3.3, 2.3.4, 3.2.2, 3.2.3, 3.2.4 ТЗ)
Результаты выполнения работ.
В результате выполнения работ были получены новые научные знания,
созданы новые программные средства решения поставленных научных задач:
- сформированы принципы построения и функционирования основных
программных модулей для решения научных задач в эксперименте с
широкоапертурным гамма-телескопом; эти модули обеспечивают:
расчет матрицы отклика прибора в рамках решения обратной задачи –
восстановление
изображений
моделирование
взаимодействий
по
выходным
гамма-квантов
в
параметрам,
позиционно-
чувствительном детекторе, управление данными в блоке электроники
прибора.
- разработана система хранения и передачи данных в блоке электроники
прибора, позволяющая. формировать весь объем информации с
позиционно-чувствительных детекторов.
- оптимизирована технология изготовления элементов кодирующей
маски широкоапертурного гамма-телескопа на основе использования
тантала в качестве материала маски.
- проработана методика локализации гамма-квантов в позиционночувствительном детекторе широкоапертурного гамма-телескопа на
основе моделирования физических взаимодействий гамма-квантов в
веществе кодирующей маски и позиционно-чувствительного детектора;
в результате решена обратная задача восстановления изображения
наблюдаемого участка неба по выходным показаниям детектора.
7
- оптимизирован тепловой режим функционирования широкоапертурного
гамма-телескопа на космическом аппарате, в том числе проработаны
технические
предложения
по
обеспечению
теплового
режима
функционирования детекторов широкоапертурного гамма-телескопа на
борту
серийного
космического
аппарата
нового
поколения,
проработаны технические предложения по обеспечению теплового
режима функционирования электроники широкоапертурного гаммателескопа с бортом космического аппарата.
8
Гл. 1. Принципы построения и функционирования основных
программных модулей для решения научных задач в
эксперименте с широкоапертурным гамма-телескопом.
§1.1. Основные научные задачи в эксперименте с широкоапертурным гаммателескопом и методы их решения.
Основная научная задача эксперимента с широкоапертурным гаммателескопом – мониторные наблюдения всего неба в гамма диапазоне
(0.05 – 1.0 МэВ) с целью исследования временных явлений в астрофизике:
космических гамма-всплесков, сверхновых и новых звезд, вспышек в звездных
системах, содержащих нейтронные звезды и черные дыры. Исследование
указанных
явлений
напрямую
связано
с
такими
фундаментальными
проблемами современного естествознания, как происхождение и эволюция
Вселенной, природа темной материи и темной энергии, поведение материи и
структура
пространства-времени
в
сверхсильных
гравитационных
и
электромагнитных полях. В частности, изучение космических гамма-всплесков
на сегодняшний день остается одной из основных задач современной
астрофизики, поскольку это явление является самым мощным из всех
процессов, наблюдаемых в природе, а его природа до конца не понята.
Для решения указанных научных задач предполагается использовать
широкоапертурный
гамма-телескоп,
построенный
на
основе
сочетания
позиционно-чувствительного детектора (ПЧД) и кодирующей маски. Главное
отличие эксперимента от уже проводившихся состоит в квазиполусферической
конфигурации маски и ПЧД, что обеспечивает возможность построения
изображений обширных областей звездного неба в диапазоне жесткого
рентгеновского и гамма-излучения наряду с длительными непрерывными
наблюдениями отдельных источников. При этом за счет, главным образом,
большого
времени
экспозиции
наблюдаемых
объектов
в
обзорном
9
эксперименте
может
быть
обеспечена
чувствительность
на
порядок
превышающая уровень, достигнутый в современных гамма-астрономических
экспериментах.
Рабочий
МэВ).
(0.1-1
энергетический
В
этом
диапазон
диапазоне
энергий
гамма-телескопа
преобладающим
составляет
процессом
взаимодействия гамма-квантов с веществом является комптоновское рассеяние,
определяющее возможную точность локализации места взаимодействия гаммаквантов в ПЧД.
Получение изображения в таких приборах основано на двухступенчатой
процедуре: сначала падающее излучение модулируется так называемой
кодирующей маской, представляющей собой определенную конфигурацию
прозрачных и непрозрачных элементов; затем промодулированное излучение
регистрируется детектором, выходные показания которого обрабатываются с
использованием алгоритма численной реконструкции образов.
Для заданного расстояния между кодирующей маской и позиционночувствительным детектором основным фактором, ограничивающим угловое
разрешение телескопа и точность локализации источника, является конечное
пространственное разрешение позиционно-чувствительного детектора (ПЧД).
Точность, с которой возможно локализовать точечный источник в поле зрения
прибора определяется способностью регистрировать края тени, отбрасываемой
элементами маски на поверхность ПЧД. Таким образом, при заданной
статистической достоверности данных, угловые характеристики телескопа в
значительной мере определяются его конфигурацией. При этом разрешение
непосредственно зависит от угла, под которым элемент маски «виден» с
плоскости детектора и, следовательно, от размеров этого элемента. Однако
размер
элемента
маски
бессмысленно
делать
меньше
величины,
соответствующей позиционному разрешению детектора, поскольку, чем
меньше размер элемента маски, тем большую роль играют случайные ошибки в
10
определении места взаимодействия регистрируемого гамма-кванта в детекторе.
Поэтому максимальное угловое разрешение, а значит и минимальный размер
элемента кодирующей маски, задаются позиционным разрешением детектора.
Можно показать, что ограниченное позиционное разрешение, однородное по
всей плоскости детектора, приводит к дефокусировке изображения, то есть при
одной и той же интенсивности наблюдаемого источника с уменьшением
размера элемента кодирующей маски интенсивность пика функции отклика
относительно фона уменьшается, при этом суммарное число отсчетов под
пиком функции отклика сохраняется, хотя чувствительность прибора падает.
Другими
важными
требованиями
к
ПЧД
являются
необходимость
однородности эффективности и позиционного разрешения по всей плоскости
детектора.
При конструировании изображающих систем необходимо учитывать
ожидаемое количество источников и их распределение в поле зрения прибора.
При относительно небольших энергиях (менее десятков кэВ) решеточные
коллиматоры могут использоваться для ограничения поля зрения каждого
элемента ПЧД и тем самым для снижения уровня аппаратурного фона, который
при этих энергиях в основном определяется рассеянным (диффузным)
излучением в поле зрения детектора. При очень больших энергиях гаммаквантов (свыше десятков МэВ) различные методы определения направления
регистрируемого гамма-квантов (искровые камеры, черенковские детекторы)
позволяют снизить фоновый уровень за счет исключения гамма-квантов,
приходящих вне поля зрения прибора. Однако, в диапазоне мягкого гаммаизлучения ни один из этих методов не работает, поэтому в принципе могут
регистрироваться гамма-кванты от источников за пределами поля зрения
прибора.
Программные модули, разработанные для широкоапертурного гаммателескопа, выполненного в форме додекаэдра, могут быть адаптированы для
11
различных узоров кодирующей маски (геометрический, типа HURA, а также
маски спирального типа с постоянным и с переменным расстоянием между
отверстиями, расположенными вдоль линии спирали). Спиральные маски
можно отнести к маскам псевдослучайного типа. Меняющееся расстояние
между отверстиями, а также направление векторов, соединяющих их центры,
приводит к уникальности формы светотени на поверхности ПЧД для каждого
положения источника. Было показано, что оптимальными в плане качества
изображений
для
выбранной
конфигурации
гамма-телескопа
являются
псевдослучайные спиральные маски.
Для случая, когда скорость счета элементов ПЧД, определяемая
исследуемыми источниками в поле зрения прибора, мала по сравнению с
постоянно присутствующим фоном, определяемым другими причинами
(основная из них – излучение, возникающее в космическом аппарате при
взаимодействии его вещества с частицами) площадь прозрачной части маски
должна составлять около половины ее полной площади. Для более ярких
исследуемых источников эта доля должна быть несколько меньше. С учетом
этого были выбраны узоры маски с отверстиями диаметром 1 см и 1.5 см,
предназначенные для работы с ПЧД, имеющим соответствующий диаметр
кристаллов. В каждом случае сторона пятиугольника маски (или ПЧД)
принималась равной 16.5 см. Расстояние между витками спирали оставалось
постоянным, при этом расстояние между соседними отверстиями вдоль
спирали увеличивалось от минимальной до максимальной величины каждый
раз на одно и то же значение.
Для решения рассмотренных выше научных задач в эксперименте с
широкоапертурным гамма-телескопом были разработаны программные модули,
обеспечивающие решение обратной задачи – восстановление изображений по
выходным параметрам, а также моделирование взаимодействий гамма-квантов
в веществе кодирующей маски и позиционно-чувствительного детектора.
12
§1.2. Cтруктура и объем выходных данных.
При регистрации события (приход гамма-кванта или частицы) на выходе
соответствующего
блока
ПЧД
возникает
импульс
«приход
гамма»
Одновременно с его приходом в выходном регистре блока ПЧД появляется
информация, относящаяся к зарегистрированному событию. Эта информация
хранится в регистре до следующего импульса «приход гамма». Она имеет
следующую структуру:
5 бит – «энергия гамма»»
14 бит – «код кристалла»
3 бита – «тип события»
12 бит – «код АЦПБ»
12 бит – «код АЦПМ»
14-разрядный «код кристалла» в БИ преобразуется в «номер кристалла»,
позволяющий идентифицировать один из 61 кристаллов ПЧД, с которым могло
произойти взаимодействие. Преобразование может быть выполнено согласно
таблице соответствия: каждому из 61 кристаллов соответствует определенный
14-разрядный «код кристалла». При несоответствии «кода кристалла» ни
одному из 61 вариантов событие считается фоновым, ему присваивается
нулевой номер кристалла. Таким образом, для кодирования номера кристалла
требуется 6 бит
Каждому блоку ПЧД присваивается «Номер ПЧД» (от 1 до 5), который
используется при формировании выходных массивов. Номер может быть
закодирован 3 битами.
5-битный код энергии может быть преобразован в 3 бита, которые
кодируют номер одного из 8 энергетических интервалов.
В результате каждому событию, связанному с взаимодействием гаммакванта с одним из детекторов, соответствует 39 бит информации.
13
На основании этой информации бортовой информационный блок
формирует следующие типы информационных кадров:
A) Кадр «Мониторинг» (1 раз в 5 секунд) содержит:
Число событий с определенным кодом «энергия гамма», определенным
«типом события», и определенным «номером ПЧД», произошедших за секунду.
Всего предполагается передавать 22 параметра, указанные в таблице. На
каждый параметр отводится по 2 байта. 7 параметров передаются раздельно для
каждого блока ПЧД, остальные 15 суммируются по всем блокам. Структура
информации идущей с каждого ПЧД, накапливаемой и передаваемой на Землю
представлена в табл. 1.1.
Таблица 1.1.
Энергия гамма
Код события
1
1
1
1
1
1
1
0
1
1
1
1
1
1
1
0
1
1
1
1
1
0
0
0
0
0
0
1
1
1
0
0
0
0
0
1
1
1
0
0
0
1
1
1
0
0
0
0
1
0
1
1
0
0
0
0
1
0
1
1
0
0
1
0
1
1
0
0
1
1
1
1
1
1
0
0
1
1
1
1
1
1
1
1
1
1
1
1
0
1
0
1
1
1
1
1
0
1
0
1
1
1
1
1
0
1
1
1
1
1
Б>М1
Б>М2
М
ENa1
ENa2
ECs1
ECs2
Emax
1




1


0
1
Описание параметра
Энерговыделение
Тип события
(кэВ)
NaI(Tl)
CsI(Tl)
25-50
50-100
100-200
200-400
400-800
800-1500
1500-3000
>3000
25-50
50-100
100-200
200-400
400-800
800-1500
1500-3000
>3000
75-150
150-300
300-600
600-1200
1200-2400
2400-4500
4500-9000
>9000
Все
взаимодействия
NaI
300-600
600-1200
1200-2400
2400-4500
4500-9000
>9000
Нейтроны в CsI
Название
параметра
ALL1
ALL2
ALL3
ALL4
ALL5
ALL6
ALL7
ALL8
NA1
NA2
NA3
NA4
NA5
NA6
NA7
NA8
NU3
NU4
NU5
NU6
NU7
NU8
14
Б) Кадр «спектр» (1 раз в 5 минут):
В кадре «спектр» передаются спектры АЦПБ+АЦПМ (число событий,
пришедших за время кадра, в зависимости от суммы кодов АЦПБ+АЦПМ).
Для
уменьшения
объема
передаваемой
информации
должно
быть
предусмотрено программное суммирование, обеспечивающее сжатие спектра
до 512 каналов следующим образом: Младшие 150 каналов передаются без
изменения. Старшие каналы суммируются таким образом, чтобы размер ячейки
диаграммы был пропорционален энергетическому разрешению детектора (при
общем числе каналов, равном 512 подробность составляет 20% от
энергетического разрешения).
Спектры набираются для следующих типов событий:
спектр АЦПБ+АЦПМ для любых событий.
спектр АЦПБ для кода события Б>М2 = 1 (взаимодействие в NaI)
В) Кадр «карта» (1 раз в 20 секунд):
В кадре «карта» передается число событий с определенным «Номером
кристалла», «Номером ПЧД» и кодом «Энергия гамма» при условии «Кода
события» Б>М2 = 1 (взаимодействие в NaI). Кадр карта содержит число
событий для каждого из 305 кристаллов в трёх энергетических интервалах:25100 кэВ, 100-400 кэВ и 400-1500 кэВ.
Г)
Кадры
«Быстрый
всплеск»
и
«Медленный
всплеск»
(формируются ~1-3 раза в сутки при выполнении определенного критерия,
не регулярно).
Блок БИ должен, анализируя информацию, поступающую с блоков ПЧД
согласно
алгоритму,
который
будет
описан
ниже,
при
выполнении
15
определенных условий генерировать кадры «Быстрый всплеск» и «Медленный
всплеск». Кадры типа «Всплеск» запоминаются в памяти БИ для последующей
передачи этих данных на Землю во время сеанса связи. При значительном
объеме информации (например, несколько всплесков в течение короткого
времени) передача должна происходить в течение нескольких сеансов связи.
В общих чертах алгоритм, вырабатывающий переход на режим записи
всплеска следующий (отличается для «быстрого» и «медленного» всплесков
значениями времени и уровнем значимости):
В кольцевой памяти БИ хранится предыстория показаний каждого блока
ПЧД в виде набора коротких кадров с временным разрешением T, время
хранения равно Tист = 100*T. Каждый раз при наступлении следующего
момента (прошло T секунд) вычисляется число событий в канале NA2
(события в NaI с энерговыделением 50-100кэВ) за 5*T и сравнивается с
ожидаемым значением, вычисленным путем линейной экстраполяции за
предшествующие
50*T. Если измеренное число
событий превышает
ожидаемое более чем на N стандартных отклонений (вычисленных как корень
из ожидаемого числа), то соответствующий блок ПЧД вырабатывает запрос на
режим
всплеска. При средней за время 50*T (перед предполагаемым
всплеском) скорости счета более 5000 имп/с переход на всплесковый режим не
производится.
Кадр «быстрый всплеск» или «Медленный всплеск» формируется при
одновременном поступлении запроса на отработку всплеска от двух и более
блоков ПЧД. Одновременным считается совпадение времени запросов в
пределах 10*T.
Переход на режим «быстрый всплеск» и «медленный всплеск»
осуществляется независимо друг от друга. Таким образом, возможно
формирование кадра «быстрый всплеск» во время «медленного всплеска».
16
В кадрах «Всплеск» содержится подробная информация о временном
ходе показаний прибора, энергетические спектры, карта распределения
излучения по поверхности ПЧД, а также двумерные диаграммы зависимости
числа событий от значений «АЦПБ» и «АЦПМ». В режиме «Всплеск» для
анализа временного хода передаются те же параметры, что и в кадре
«Мониторинг», меняется лишь интервал времени набора событий.
Спектры, передаваемые в режиме «Всплеск» формируются аналогично
спектрам, передаваемым в обычном режиме.
Под
двумерной
диаграммой
понимается
количество
событий
с
определенной комбинацией кодов АЦПБ и АЦПМ за время сбора. Для
уменьшения объема передаваемой информации исходная диаграмма 4096х4096
каналов должна быть сжата до размера 256х256 каналов таким образом, чтобы
размер ячейки диаграммы был пропорционален энергетическому разрешению
детектора. В результате для каждого события формируется двухбайтный код, в
котором один байт содержит сжатый код АЦПБ, другой – сжатый код АЦПМ.
Двумерная диаграмма передается в виде ряда, содержащего
последовательно двухбайтные коды каждого события. Всего записывается
определённое число событий. Для привязки времени через каждые 200 событий
в ряд вставляется маркер времени. Маркер времени добавляется не реже, чем 1
раз в 5 секунд.
Кадр «Быстрый всплеск», T=1 мс, N=7 :
Запись истории показаний прибора за 0.1 секунды до возникновения
всплеска. В эту запись входит число событий «гамма» с определенным кодом
«энергия гамма» и определенным «типом события» (23 канала согласно
таблице), зарегистрированных за каждую 1 миллисекунду. На каждый параметр
отводится по 2 байта.
17
Запись тех же параметров в течение первых 0.5 секунд с той же
подробностью (каждую 1 миллисекунду).
Запись тех же параметров в течение последующего времени с интервалом
в 10 мс в течение 5 секунд.
Запись тех же параметров в течение последующего времени с интервалом
в 100 мс в течение 100 секунд.
Каждые 0.5 секунды, начиная с момента начала всплеска в течение 2
секунд, далее каждые 1 секунду в течение 20 секунд, далее каждые 5 секунд в
течение 100 секунд, должны набираться энергетические спектры (512 каналов):
спектр АЦПБ+АЦПМ для всех событий
спектр АЦПБ при выполнении условия «Б>М2»=1 (взаимодействие в
NaI(Tl) ).
5) При формировании кадра «Быстрый всплеск» должна быть
предусмотрена передача следующих двумерных диаграмм:
Диаграмма, содержащая предысторию всплеска (2000 событий).
Диаграмма, набираемая от момента начала всплеска до тех пор, пока не
будет набрано 2000 событий.
Диаграмма (2000 событий), набор которой начинается спустя 100 секунд
после начала всплеска.
6) При формировании кадра «Быстрый всплеск» предусматривается
передача кадров типа «Карта», набираемых в течение 2 секунд с интервалом в
0.2 секунды, далее в течение 20 секунд с интервалом в 1 секунду, далее в
течение 100 секунд с интервалом в 5 секунд.
Кадр «Медленный всплеск» T=10 мс, N=6:
Запись истории показаний прибора за 1 секунду до возникновения
всплеска. В эту запись входит число событий «гамма» с определенным кодом
«энергия гамма» и определенным «типом события» (23 канала согласно
18
таблице), зарегистрированных за каждые 10 миллисекунд. На каждый параметр
отводится по 2 байта.
Запись тех же параметров в течение первых 5 секунд с той же
подробностью (каждые 10 миллисекунд).
Запись тех же параметров в течение последующего времени с интервалом
в 100 мс в течение 20 секунд.
Запись тех же параметров в течение последующего времени с интервалом
в 500 мс в течение 200 секунд.
Каждые 2 секунды, начиная с момента начала всплеска в течение 20
секунд, далее каждые 10 секунд в течение 200 секунд, далее каждые 25 секунд в
течение 500 секунд, должны набираться энергетические спектры (512 каналов):
спектр АЦПБ+АЦПМ для всех событий
спектр АЦПБ при выполнении условия «Б>М2»=1 (взаимодействие в
NaI(Tl) ).
5) При формировании кадра «медленный всплеск» должна быть
предусмотрена передача следующих двумерных диаграмм:
Диаграмма, содержащая предысторию всплеска (2000 событий).
Диаграмма, набираемая от момента начала всплеска до тех пор, пока не
будет набрано 2000 событий.
Диаграмма (2000 событий), набор которой начинается спустя 500 секунд
после начала всплеска.
6) При формировании кадра «Медленный всплеск» предусматривается
передача кадров типа «Карта», набираемых в течение 20 секунд с интервалом в
2 секунды, далее в течение 200 секунд с интервалом в 5 секунд.
19
Таблица 1.2.
Кадр
часть кадра
Длительность
время
кадра, с
измерений, с
"Мониторинг"
"Спектр"
Служебная
информация
"Карта"
"Быстрый
всплеск"
"медленный
всплеск"
Кадры
5
300
86400
86400
200
86400
20
86400
кадров за
байт в
время
кадре
измерений
17280
100
288
10240
Мбайт в
сутки
1.648
2.813
100
0.041
4320
1830
Итого за сутки
постоянно:
7.539
432
12.041
предыстория
0.001
0.1
100
230
0.022
начало всплеска
середина всплеска
конец всплеска
Двумерная диаграмма
(предыстория)
Двумерная диаграмма
Двумерная диаграмма
(после всплеска)
Энергетический
спектр начало
Энергетический
спектр середина
Энергетический
спектр конец
Карта начало
Карта середина
Карта конец
0.001
0.01
0.1
0.5
5
100
500
500
1000
230
230
230
0.110
0.110
0.219
1
20000
0.019
1
20000
0.019
1
20000
0.019
0.5
2
4
10240
0.039
1
20
20
10240
0.195
5
100
20
10240
0.195
0.2
1
5
2
20
100
10
2440
20
2440
20
2440
Итого за один
всплеск:
0.023
0.047
0.047
1.064
предыстория
0.01
1
100
230
0.022
начало всплеска
середина всплеска
конец всплеска
Двумерная диаграмма
(предыстория)
Двумерная диаграмма
Двумерная диаграмма
(после всплеска)
Энергетический
спектр начало.
Энергетический
спектр середина
Энергетический
спектр конец
Карта начало
Карта конец
0.01
0.1
0.5
5
20
200
500
200
400
230
230
230
0.110
0.044
0.088
1
20000
0.019
1
20000
0.019
1
20000
0.019
«Быстрый
всплеск»
2
20
10
10240
0.098
10
200
20
10240
0.195
25
500
20
10240
0.195
2
5
20
200
10
2440
40
2440
Итого за один
всплеск:
0.023
0.093
и
«Медленный
всплеск»
0.925
должны
накапливаться во внутренней памяти и передаваться на Землю во время
20
ближайших сеансов связи согласно квоте на объем передаваемой информации.
При частой генерации режима «всплеск», приводящей к превышению лимитов
на объем информации, передаваемой за один сеанс связи, кадры «всплеск»
должны запоминаться и передаваться на Землю по очереди. По причине
нерегулярности появления космических всплесков, несущих важную научную
информацию, следует предусмотреть бортовую память, достаточную для
хранения данных не менее чем о 20 всплесках. При переполнении бортовой
памяти всплески передаются на Землю согласно приоритетам, определяемым
логикой работы бортового процессора. В первую очередь на Землю передаются
быстрые всплески, имеющие максимальную степень выполнения критерия.
Оценка суточного объёма информации, поступающеё с гамма-телескопа,
приведена в табл. 1.2.
Для решения научных задач необходимо по показаниям прибора
определять характеристики излучения, падающего на прибор. Эта процедура –
восстановления исходного воздействия по отклику на это воздействия является обратной задачей. Прямая задача – выяснение, каким будет отклик
прибора на то или иное воздействие - решается методами численного
моделирования для различных видов воздействий с последующей проверкой
совпадения результатов моделирования с результатами физических калибровок.
Численное моделирование необходимо, поскольку относительная сложность
аппаратуры, многообразие видов исследуемых излучений и широкий диапазон
измерений делают практически невозможным проведение калибровочных
измерений для всех случаев. Например: для определения функции отклика на
излучение,
приходящее
из
каждого
направления,
разрешаемого
рассматриваемым гамма-телескопом, потребовались бы тысячи измерений с
изотопами.
Обратные задачи, которые предстоит решать в процессе научных
исследований, можно условно разделить на два основных направления.
21
Восстановление изображения в поле зрения прибора
Восстановление энергетического спектра излучения, падающего на
прибор.
Обе эти задачи используют предварительно рассчитанную функцию
отклика. Расчеты функции отклика предполагается проводить методом МонтеКарло с применением пакета GEANT. Ввиду сложности прибора расчеты будут
использовать много входных и выходных параметров. Входными параметрами
падающего излучения являются его энергия, интенсивность и направление
прихода относительно оси прибора. Ограничиваясь расчетами отклика прибора
на излучение единичной интенсивности требуется вычислить отклик прибора
для ряда энергии (~10 значений) для ~20000 направлений прихода, заданных
полярными координатами (,). Выходными параметрами служат скорости
счета каждого из сцинтилляционных кристаллов прибора (305 кристаллов
NaI(Tl) и 5 кристаллов CsI(Tl) ) в энергетических диапазонах прибора. При
расчетах скоростей счета кристаллов NfI(Tl) следует рассмотреть три
возможных режима работы активной защиты: 1)Исключение всех случаев
одновременного выделения энергии в NaI(Tl) и в CsI(Tl), 2) исключение
случаев, когда энерговыделение в CsI(Tl) превышает энерговыделение в
NaI(Tl), 3)Активная защита не используется, то есть рассматриваются все
случаи взаимодействия. Расчеты скорости счета СsI(Tl) следует проводить при
отсутствии энерговыделения в NaI(Tl).
Для дальнейшего использования на основе этих расчетов вычисляются:
Матрицы отклика, необходимые для восстановления изображения по
показаниям
прибора
в
определенном
энергетическом
канале.
Размерность каждой матрицы в одном направлении (ряды) равна числу
кристаллов NaI(Tl), а в другом (столбцы) – числу направлений прихода
излучения (~20000)
22
Матрицы, позволяющие восстановить исходный энергетический спектр по
суммарному
спектру
энерговыделений
в
кристаллах
NaI(Tl).
Параметром служит направление прихода излучения. Учет его
необходим ввиду зависимости поглощения гамма-квантов маской от
энергии.
Матрицы, позволяющие восстановить исходный энергетический спектр по
суммарному
спектру
энерговыделений
в
кристаллах
CsI(Tl).
Параметром также служит направление прихода излучения.
Матрицы, позволяющие восстановить исходный энергетический спектр по
спектру, полученному путем оценки яркости точечного источника в
широких энергетических каналах, используемых для построения
изображения.
Параметром
также
служит
направление
прихода
излучения.
Структура информации, прошедшей предварительную обработку
(типы вторичных информационных массивов).
Вторичные информационные массивы должны регулярно формироваться
на основе информации, поступающей в виде первичных массивов, а также
данных о местоположении и ориентации спутника.
Исходная информация поступает на Землю в виде последовательно
принятых «сеансов», каждый из которых содержит набор кадров различных
типов, описанных выше. Идентификация кадров осуществляется по байтам
признака кадра, записанным в его начале. Для проверки корректности приёма
информации в конце каждого кадра записывается контрольная сумма.
Внутри каждого кадра присутствует информация о времени наблюдений.
На начальном этапе наземной обработки к каждому кадру добавляется
информация об ориентации гамма-телескопа (направление трёх осей),
географические и геомагнитные координаты, а также признак отсутствия или
23
наличия телеметрических сбоев (совпадение контрольной суммы со значением,
записанным в кадре).
После приёма информация сортируется на массивы кадров одинакового
типа:
последовательность кадров «Мониторинг»
последовательность кадров «Спектр»
последовательность кадров «Карта»
наборы кадров «Быстрый всплеск» и «Медленный всплеск»
служебная информация.
Для удобства дальнейшего считывания компьютерными программами
последовательность
кадров
«Мониторинг»
объединяется
в
файлы
длительностью около суток (можно использовать разбиение по сеансам связи).
Аналогично, в отдельные файлы записываются суточные последовательности
кадров «Спектр» и «Карта», а также «служебная информация». На этом же
этапе к каждой строчке соответствующего файла (определенный момент
измерений) добавляется информация о координатах и об ориентации спутника.
Информация во всех файлах хранится в двоичной форме. Перевод файлов
в текстовый вид может быть осуществлен специальной программой. Для
удобства имя соответствующего файла должно содержать информацию о
времени его начала, а также о том, какого типа кадры содержит данный файл.
Кадры «Быстрый всплеск» и «Медленный всплеск» хранятся в виде
отдельных файлов для каждого всплеска. Имя этих файлов должно указывать
на время начала всплеска и его тип.
Для формирования вторичных массивов на основе блока первичной
информации, поступившей во время сеанса связи, может быть использована
одна программа. Эта программа должна запрашивать имя файла, содержащего
принятый блок информации, считывать этот файл и на его основе создавать
файлы, содержащие информационные кадры определенного типа. Эта же
24
программа добавляет внутрь файлов данные об ориентации прибора и о его
координатах, а также осуществляет проверку корректности данных по
контрольным суммам, добавляя в выходные массивы соответствующий
признак. Имена выходных файлов программа формирует автоматически. Эти
имена вместе с интервалами наблюдений, содержащихся в соответствующих
файлах, автоматически заносятся в файл реестра, дополняемый каждый раз при
запуске соответствующей программы.
Файл реестра содержит полный список файлов каждого типа с указанием
интервалов
непрерывных
наблюдений,
которые
в
них
содержатся.
Непрерывными считаются наблюдения, при которых пропущено подряд не
более 3-х кадров соответствующего типа.
Описанная выше программа не анализирует файл реестра с целью его
сортировки по возрастанию времени наблюдений, выявления пересекающихся
интервалов и т.п. Она лишь дописывает в конец свежую информацию. Анализ
файла реестра может быть выполнен пользователем вручную. При большом
объёме принятой информации может потребоваться отдельная программа.
§1.3. Основные программные модули, необходимых для решения научных задач
в эксперименте с широкоапертурным гамма-телескопом.
Вся информация должна просматриваться специалистами сразу после ее
приёма и автоматической сортировки с целью поиска явлений солнечной,
астрофизической или геофизической природы, подлежащих детальному
изучению, а также с целью проверки нормального функционирования
аппаратуры.
25
Для просмотра должны быть написаны и отлажены программы:
осуществляющие
пользователем
визуализацию
параметров
временного
в
хода
выбранных
последовательности
кадров
«Мониторинг». Для удобства анализа программа должна в одном
окне показывать временной ход, а в другом окне – энергетические
спектры, составленные из скоростей
ALL8,
NA1-NA8
и
NU3-NU8.
счета параметров ALL1Показ
спектров
может
производиться в автоматическом режиме (анимация изменений
спектра). Также пользователь может выбрать интересующий его
момент времени (подведя курсор к точке на временном ряду или
введя значение времени с клавиатуры) и увидеть энергетический
спектр в это время.
визуализирующие энергетические спектры, собранные в кадрах
«Спектр». Представление информации может быть сделано в виде
анимации или для момента, выбираемого пользователем. Для
удобства восприятия информации в процессе сопоставления
данных в отдельном окне должен быть представлен временной ход
одного или нескольких параметров. Там же должен находиться
курсор, перемещая который пользователь может выбрать момент
времени, когда ему нужно посмотреть энергетический спектр.
Восстанавливающие изображение в поле зрения прибора для
определенного кадра типа «Карта» с последующей визуализацией.
На данном этапе изображение восстанавливается в поле зрения
прибора (используется полярная система координат). Исходными
данными
значений
для
восстановления
числа
случаев
изображения
взаимодействия
служит
массив
гамма-кванта
соответствующей энергии с каждым из кристаллов (всего 305
значений для каждого энергетического диапазона). Для получения
26
изображения используется матрица отклика, которая должна быть
рассчитана заранее для каждого из диапазонов работы прибора.
Матрица отклика представляет собой таблицу размер которой
равен количеству кристаллов (305) в одном направлении и
количеству точек, на которые разбито поле зрения прибора
(~20000), в другом. В результате процедуры восстановления
вычисляется массив значений потока гамма-квантов, идущего из
соответствующих
Визуализация
точек
поля
предполагает
зрения
(~20000
демонстрацию
значений).
полученного
изображения в виде цветовой карты или в виде трёхмерного
рельефа. Для предварительного просмотра удобна анимация в виде
последовательной смены изображений на экране.
Получение
карты
неба
в
экваториальных
координатах
за
определенный период времени путём наложения изображений в
поле зрения прибора с последующей интерполяцией. Исходными
данными служат массивы скоростей счета кристаллов в каждом
кадре (305 значений для каждого кадра). Программа выбирает
последовательность кадров типа «Карта», восстанавливает для
каждого из них изображение в поле зрения прибора, после чего,
используя информацию об ориентации осей гамма-телескопа в
пространстве, накладывает полученные изображения, проводя
интерполяцию. Одновременно с этим программа определяет для
каждой из точек неба в экваториальных координатах суммарную
экспозицию. По окончании просмотра данных за выбранный
интервал времени программа делит для каждой точки неба
значение числа гамма-квантов, пришедших из этого направления,
на экспозицию, относящуюся к данной точке. В результате
27
получаются значения потока, из которых составляется итоговая
карта неба, изображаемая на экране.
Визуализирующие
временной
ход,
энергетические
спектры,
двумерные диаграммы и карты, содержащиеся в кадрах типа
«Всплеск». Для ускорения предварительного анализа программа
должна быть многооконной. В одних окнах должен изображаться
временной ход основных параметров, в других – энергетические
спектры, собранные на разных фазах всплеска, в третьих –
двумерные диаграммы. В отдельных окнах должны быть
помещены изображение в поле зрения прибора (при разных
энергиях) и положение самого поля зрения прибора на карте неба
в
экваториальных
координатах.
Программа
должна
уметь
находить наиболее яркую точку в поле зрения прибора, сообщать
её координаты и отмечать ее на соответствующих картах по
желанию пользователя. Желательно, чтобы на картах также было
отмечено положение Солнца.
Показывающие служебную информацию. Информация может быть
представлена в виде текста, а также в виде графиков зависимости
от времени температуры, энергопотребления отдельных блоков и
т.п. На этих же графиках удобно показывать положение прибора
на свету или в тени Земли.
Во всех программах должна быть предусмотрена возможность сохранить
вычисленные значения в текстовом файле.
28
Программные модули, позволяющие проводить более детальный
анализ.
Должны быть разработаны программы, позволяющие проводить обработку
данных в следующих направлениях:
Сопоставление карт неба, полученных за определенное время. Сложение и
вычитание изображений.
Восстановление
энергетических
соответствующих
функций
спектров
отклика
(для
с
использованием
подробных
спектров,
содержащихся в кадрах «спектр» и для спектров, сформированных на
основе кадров «мониторинг»)
Разложение энергетических спектров на компоненты. Поиск линий
излучения и поглощения на энергетических спектрах.
Формирование временного ряда потока, идущего из определенной точки
неба путём анализа последовательности восстановленных изображений.
Дальнейший
анализ
может
осуществляться
с
использованием
дополнительных программ, реализующих специальные методы анализа
(например, осуществляющих спектральный анализ временных рядов), а также с
использованием известных пакетов для статистической и др. обработки
результатов эксперимента.
29
Гл. 2. Система хранения и передачи данных в блоке электроники
широкоапертурного гамма-телескопа.
§2.1. Cистемы управления данными.
Выбор средств разработки информационных систем в настоящее время
является очень актуальной задачей. С одной стороны, желательно иметь
средства разработки приложений и взаимодействия с базами данных более
высокого уровня (средства программировании 4GL) - это позволяет сократить
сроки разработки, облегчить поиск ошибок. Для достижения перечисленных
выше
целей
необходимо
пользовательские
в
требования,
максимальной
а
это
-
степени
высокая
удовлетворять
производительность,
компактность, эффективный пользовательский интерфейс и, несомненно,
возможность влиять на механизмы доступа к данным, включая их организацию.
В большинстве случаев средства разработки высокого уровня (4GL) в силу
своих конструктивных особенностей, таких как скрытость механизмов
организации и хранения данных, отработка запросов в едином сервере БД и
других, не отвечают требованиям второй группы.
Традиционно
обеспечение
гибкого
интерфейса
и
эффективных
механизмов доступа к данным выполнялось встраиваемыми в приложения
СУБД, представляющими собой набор статических и динамических библиотек,
работающих совместно с приложениями. Однако большинство подобных
систем по ряду причин морально устарели: предназначены для операционных
систем (ОС), которые уже не поддерживаются (ДОС); их приемлемые
реализации для новых ОС не находят применения или отсутствуют; они
ориентированы на устаревшие модели построения интерфейса и механизмы
доступа
к
данным.
Встроенные
СУБД,
которые
изначально
были
ориентированы только на универсальные и хорошо проработанные механизмы
работы с данными, в которых принципиально отсутствовали процедуры
построения интерфейса, в этом случае приобретают новое значение. Поскольку
30
концепция их построения такова, что они могут подключаться практически к
любым новым современным системам программирования, таким как Builders и
средствам уровня 4GL, эти СУБД занимают свою нишу средств разработки
информационных систем.
Ярким представителем систем подобного класса, является встраиваемая
СУБД RDM предлагаемая и сопровождаемая фирмой Centura. Эта СУБД была
разработана фирмой Raima еще в 1987 году и носила первоначальное название
dbVista, под которым известна многим российским разработчикам и
руководителям проектов. Сейчас, когда Raima влилась в фирму Centura, этот
продукт приобрел особую популярность. Ниже мы рассмотрим особенности,
принципы построения и состав программной системы. Здесь же отметим
ключевые аспекты, которые являются основным критерием выбора продукта
данного класса и в будущем они будут играть важную роль в развитии
информационных технологий (ИТ) для встраиваемых приложений
. Это
следующие свойства СУБД RDM:
В первую очередь это высокое, даже высочайшее быстродействие
встраиваемой СУБД RDM. Оценки и измерения показывают, что даже
по сравнению с очень быстрыми приложениями на CA Clipper, выигрыш
составляет десятки раз (30-50), что достигается за счет хорошо
проработанных и оригинальных методов доступа к данным. Ни в какое
сравнение с RDM не идут временные характеристики, получаемые для
SQL СУБД, даже очень мощных.
Во-вторых, это наличие NON SQL интерфейса навигации по таблицам БД.
Для ряда задач, особенно оперативного ввода и обработки данных, такая
возможность может стать определяющей при выборе СУБД. Наряду с
традиционными методами навигации в RDM предусмотрены методы
доступа к данным, основанные на SQL запросах.
31
В-третьих, для многих информационных систем чисто реляционная модель
данных, лежащая в основе SQL СУБД, не является приемлемой, так как
на дополнительные связи уходит много ресурсов (места в БД, время
формирования выборок и т.п.). Сетевая модель данных, предлагаемая в
RDM, в совокупности с эффективными процедурами доступа в наборах
(Sets), позволяет значительно упростить модель данных, оптимизировать
процедуры их организации и хранения. Это свойство позволяет строить
резервированные комплексы.
В-четвертых, компактность. Новые ИТ, ориентированные на интеграцию
данных и малых (и сверхмалых) вычислительных устройств, таких как
мобильные телефоны портативные
бортовых
систем,
не
и одноплатные компьютеры для
предназначены
для
работы
приложений,
построенных для мощных СУБД. В RDM существует поддержка многих
платформ и конфигураций вычислительных средств, в том числе и таких
как
Windows
CE.
микроминиатюрных
Эти
системы
компьютерах.
способны
работать
Возможность
даже
на
поддержки
распределенных технологий, получивших название технологии "пятого
поколения" или eSNAP- технологии является отличительной чертой
RDM. Здесь СУБД встраивается в приложения клиента, работающего на
микроминиатюрном компьютере.
В-пятых, наличие объектно-ориентированного интерфейса, присущего
всем
современным
средствам
доступа
к
данным.
Объектно-
ориентированный интерфейс в RDM реализован в виде отдельного
пакета программ - ROM (Raima Object Manager). Ранее этот пакет
поставлялся отдельно, а теперь входит в состав продукта RDM.
Отличительной чертой ROM, как системы классов - типов обработки
данных, является направленность на пользователя-программиста. Это
отражается в удобной системе перегруженных операций (процедуры
32
навигации перегружаются, например, операторами ++ - переход к
следующей записи) и первоначальной направленности сохранения
высокой производительности. Для достижения последнего, в ROM в
механизмах доступа к данным использована
прямая адресация
дискового пространства. В дополнение к сказанному отметим, что
интуитивно
понятный
объектно-ориентированный
интерфейс
значительно расширяет возможности сетевых моделей RDM. В RDM
реализованы новые варианты связей между записями в БД, в частности,
реализована связь M к N (M:N).
И, наконец, мобильность. В этом, по-видимому, продукту RDM нет
равных, так как изначально продукт вообще предлагался в виде
исходных текстов программ, настраиваемых для перекомпиляции для
любых платформ и любых систем программирования. Это относилось не
только к главным библиотекам системы, но и ко всем вспомогательным
модулям и утилитам. В настоящее время доступны версии RDM для
любых платформ (от DOS до LINUX) и систем разработки программ: от
СИ++ до VB (кроме того Java, Delphi и др.). За дополнительную плату и
сейчас можно получить все исходные тексты программ, а ROM всегда
поставляется в виде исходных текстов и библиотек. Так как основные
функции представлены в динамической библиотеке стандарта Windows
(Windows DLL), то любые системы программирования обеспечивают
стандартный интерфейс к функциям RDM. Т.е. такой подход отвечает
стандарту открытого программного обеспечения.
Рассмотрим основные составляющие системы управления БД - RDM. В
RDM входят:
Система библиотек (DLL или LIB, в зависимости от платформы) и система
файлов настройки (INCLUDE).
33
ROM - библиотеки и исходные тексты для объектно-ориентированного
интерфейса (Raima Databasebase Runtime Library - RDRL).
Примеры использования RDM и ROM для разных платформ.
Документация в электронном виде (PDF- формат) и печатном виде.
Утилита для преобразования описаний структур данных в физический
формат в виде файлов - DDLP (Databasebase Definition Language
Processor).
Утилита инициализации БД - INITDB.
Средство для обеспечения коллективной работы пользователей с данными
и их защиты - LOCK MANAGER. Эта компонента устанавливается на
одной из машин в сети и обеспечивает совместную работу клиентских
приложений на разных компьютерах.
Утилита DBCLRDL - очистки блокировок в случаях сбоев.
Средства импорта и экспорта данных, снабженных специализированным
языком - DBIMP и DBEXP.
Средства работы с ключами БД - KEYBUILD, KEYPACK и KEYDUMP.
Интерактивные утилиты просмотра и редактирования БД - IDA и WIDA.
Утилиты проверки БД и данных - DBCHECK и DATDUMP.
Утилита распечатки БД - PRDBD.
Средство реорганизации БД - REVISE. Эта утилита основана на
собственном языке и позволяет выполнять все операции реорганизации
БД с сохранением информации. С помощью REVISE можно избежать
необходимости написания и отладки собственных программ для
преобразования базы, а также экспорта и импорта ее содержания.
Целостность базы обеспечивается тем, что REVISE не переписывает
исходную базу данных. REVISE читает базу, сохраняет преобразуемую
информацию в промежуточной рабочей базе и затем записывает
преобразованные данные в выходную базу. Исходная база
не
34
изменяется. В процессе компиляции REVISE сравнивает словарные
файлы
исходной
и
выходной
баз.
Проверяется
корректность
преобразования, отличия в схемах, и отчет может быть распечатан. В
различных режимах реорганизации данных обеспечивается сохранность
данных.
Средство доступа к БД на основе SQL языка, модернизированного для
сетевых структур данных - QUERY. Содержит три составляющие:
библиотеку функций, включаемую в RDRL; базу данных запросов и
интерактивную утилиту WQUERY. QUERY - обеспечивает выполнение
изолированных
и
встроенных
запросов
к
RDM
базе
данных.
Поддерживает подмножество Структурированного Языка Запросов
(SQL) и содержит команды, позволяющие описать и получить
реляционные проекции RDM базы для условной выборки и сортировки
данных.
Рассмотрим некоторые особенности СУБД RDM.
Важными
чертами
RDM
являются
эффективное использование
оперативной и дисковой памяти, компактное хранение данных и встроенные
средства обеспечения ссылочной целостности базы. RDM включает средства
мониторинга
производительности,
эффективную
схему
кэширования
и
предоставляет возможности оптимизации системы для работы практически в
режиме реального времени. Регистрация и восстановление транзакций
обеспечивают целостность базы даже в аварийных ситуациях. Благодаря
средствам повышения устойчивости вероятность появления ошибок в базе из-за
сбоев операционной системы или приложений уменьшена.
Многопользовательский
режим
обеспечивается
специальными
механизмами, реализацию которых поддерживает специальная утилита в сети LOCK MANAGER. Эта утилита строит специальные таблицы, выполняет
контроль за блокировками записей и их отмену, работает как резидентная
35
задача. LOCK MANAGER - управляет пользователями, используя эффективные
и распространенные протоколы NETBIOS, SPX, TCP. Для снятия блокировок в
случае аварийных ситуаций и сбоев предусмотрено специальное средство утилита DBLRDL. Предусматривается защита файлов, страниц и отдельных
записей, ведение журналов и поддержка стандартных механизмов транзакций.
Принцип работы RDM достаточно прост. Эта работа состоит из нескольких
этапов. Рассмотрим их:
Создание БД. БД описывается на специальном языке DDL, при этом
описываются записи, ключи, наборы, а также распределение элементов
данных по файлам. Попутно отметим, что это как раз, в дополнении к
сказанному, позволяет выполнить процедуру оптимизации хранения
данных. Далее с помощью DDLP схема БД компилируется, превращаясь
в набор файлов, некоторые их которых используются в программах для
обеспечения интерфейса с записями.
С использованием средств программирования (СИ, СИ++, VB и др.)
разрабатывается программа, содержащая вызовы функций библиотеки
RDM. Функции эти очень просты в использовании и для запоминания их
названий. Например: открытие БД - d_open, поиск по ключу d_keyfind,
переход к следующей записи - d_recnext, чтение записи - d_recread,
запись в БД - d_recwrite и так далее. Отметим, что можно открыть и
работать одновременно сразу с несколькими БД. В проект программной
системы подключается библиотека RDM или интерфейсная библиотека
для динамических вызовов. После написания и отладки программ
приложение готово к применению.
Для
работы
приложение
запускается
с
обеспечением
доступа
к
динамическим библиотекам по путям поиска программ (path). При
работе в многопользовательском режиме, необходимо на одной из
36
машин в сети запустить - LOCK MANAGER, соответствующий
операционной системе, и настроить протоколы доступа.
Для реорганизации БД, при необходимости, использовать утилиту
REVISE, для импорта и экспорта утилиты DBIMP и DBEXP.
В RDM предусмотрены следующие основные классы функций для работы с
данными и управления данными:
Функции управления базами данных
Функции чтения записей
Функции записи в БД
Функции поиска записей, в том числе и по ключам
Функции работы с наборами
Функции прямого доступа
Функции управления защитой записей
Функции шифровки и дешифровки записей
И многие другие функции.
При работе с RDM, несомненно, доступны все функции и объекты
пользовательского интерфейса, которые имеются в используемой системе
программирования. Подбор названий функций (префиксация) практически
исключают их совпадение. Так как эти функции разработаны и отлажены
довольно давно, то уровень их надежности высок, даже при разработке
приложений в универсальных языках с указателями (С и Pascal).
Составная часть RDM - ROM, объектно-ориентированный интерфейс,
требуют более тщательного внимания и изучения, так как в ROM фактически
определен новый универсальный язык описания и управления данными. Как
любая система взаимосвязанных классов, он не прост в обучении и
осмысливании, но после освоения этого языка.
Несмотря на свою компактность и простоту RDM
представляет собой
программный продукт, с его помощью можно создавать программные
37
информационные системы самого высокого качества и уровня, отвечающие
всем современным требованиям заказчиков и ИТ. Вот некоторые важнейшие
характеристики встраиваемой СУБД RDM:
Число полей в записи ограничено только размерами записи
Максимальное число объектов в файле: 16,777,215
Максимальное число файлов в базе: 256
Максимальное число объектов в базе: 4,294,967,040
Максимальное число одновременно открытых баз данных ограничено
только оперативной памятью
Необходимая оперативная память - всего 110 Kбайт
Поэтому принимая во внимание выше сказанное была выбрана CУБД RDM
для разработки программного обеспечения «гаммафона». Отметим, что СУБД
RDM полностью совместима по функциям и по данным с другим программным
продуктом Centurа - выделенным СУБД Velocis. Это также мощное
профессиональное средство разработки встраиваемых систем. Продукты RDM
и Velocis доступны на российском рынке.
Birdstep Technology - поставщик программного обеспечения для компаний,
работающих на рынке встроенного ПО и мобильных устройств. Компания
предоставляет встраиваемые компоненты приложений, а также СУБД для
беспроводных устройств с возможностью передачи данных через интернет.
Компания производит эффективные и в то же время экономичные СУБД,
позволяющие проводить быстрый и безопасный обмен данными.
Высокопроизводительные технологии управления базами данных упрощают
создание приложений для широкого спектра платформ.
На российском рынке Birdstep представляет семейство продуктов Birdstep
Raima Database Managers, состоящее из 3 разных СУБД. Эти продукты
специально предназначены для работы с серверными, встроенными и
мобильными платформами.
38
RDM Server– это мощный, гибкий и при этом компактный кроссплатформенный сервер баз данных, спроектированный для приложений, к
которым предъявляются высокие требования по производительности. RDM
Server отвечает требованиям современного бизнеса, нуждающегося в такой
платформе встраиваемых баз данных, которая являлась бы масштабируемым и
надежным решением.
RDM Embedded - высокопроизводительная СУБД для профессиональных
разработчиков. Может использоваться в качестве встроенного компонента
приложений, позволяет
создавать приложения с использованием сред
разработки на базе языков C или C++.
RDM Mobile - одно из ведущих решений в области объектно-ориентированных
баз данных. Оно оптимизировано для управления иерархическими данными и
позволяет работать с данными формата XML. RDM Mobile позволяет
осуществлять
передачу
данных
между
беспроводными
устройствами
(мобильные телефоны, PDA, переносные компьютеры и др.)
Технические характеристики СУБД Birdstep
Birdstep RDM Embedded – компактная и встраиваемая СУБД, обладающая
высокой производительностью, разработанная для современных комплексных и
взаимосвязанных
систем
прикладного
назначения.
RDM
Embedded
предоставляет разработчикам доступную и мощную функциональность для
управления данными в безопасном и отказоустойчивом режиме, а также для
взаимодействия с другими системами. Такие компании, как Bloomberg, HP,
Lucent, Intermec, Boeing, Johnson and Johnson, 3Com и Nortel, выбрали Birdstep
RDM Embedded для обработки транзакций и автоматического восстановления
баз данных после сбоев.
Достоинства Birdstep RDM Embedded:
Подтвержденная
В
течение
более
годами
чем
20-летнего
надежность
развития
RDM
Embedded
39
использовалась в нескольких миллионах приложений реального времени
и системах непрерывного доступа для решения задач в области
телекоммуникаций,
систем сбора
различного назначения и др.
Разработчики концентрируются на работе с одним стандартным
продуктом, а не на собственных внутренних разработках.
Использование
стандартных
API
Новинкой в RDM Embedded 7.1 является поддержка интерфейса XML
для облегчения совместимости различных систем и интеграции
приложений. RDM Embedded также включает интерфейсы Java, C/C++ и
SQL с простым администрированием.
RDM
Embedded
разработана
для
встроенных
систем
RDM Embedded является встраиваемой базой данных, обладает высокой
производительностью и требует небольшого объема оперативной и
постоянной памяти. Приложения, разработанные с использованием этой
системы, устойчивы и просты в обслуживании.
Полная
защита
данных
RDM Embedded обеспечивает безопасность, целостность и доступность
данных, применяя зеркальное копирование (data mirroring), а также
обработку транзакций и автоматическое восстановление данных после
сбоев.
Передовые возможности
Сложные приложения требуют быстрого, прозрачного и интегрированного
управления
данными.
Системы
со
встроенными
базами
данных
–
предпочтительное решение по управлению данными для разработчиков и
конечных пользователей. Для современных высокопроизводительных систем
сбора требуется надежное, масштабируемое и гибкое решение по управлению
данными. Разработчики нуждаются в проверенных опытом, простых в
использовании решениях, которые снижают расходы на разработку, ускоряют
40
время разработки продукта и обеспечивают его надежность при минимальном
обслуживании.
Birdstep RDM Embedded – быстрая и устойчивая база данных
Разработчики
выбирают
RDM
Embedded
для
создания
систем,
работающих в режиме реального времени или требующих непрерывного
доступа к данным. С самого начала база данных RDM Embedded была
спроектирована для достижения высокой производительности. Комбинация
сетевой модели данных, эффективного использования памяти и кэширования
позволяет ей работать с беспрецедентной скоростью. Вместе с тем это самая
компактная база данных в отрасли, доступная для множества операционных
систем.
Поддержка сетевой и реляционной моделей баз данных
Архитектура
RDM
высокопроизводительной
и
Embedded
гибкой
построена
сетевой
модели
на
основе
данных,
также
поддерживается традиционная реляционная модель. Уникальность RDM
Embedded заключается в том, что эта система способна комбинировать
использование
сетевой
и
реляционной
модели
данных,
предоставляя
разработчикам преимущества обеих моделей.
Детальное моделирование данных
Встроенные
базы
данных
используются
в
специфических
вычислительных системах, для которых возможность детального определения
структуры данных и взаимосвязи между данными имеет большое значение. В
RDM Embedded в качестве языка определения данных (DDL) используется язык
на основе С, с помощью которого разработчик может моделировать связи
между данными с любой степенью детализации.
Высокая готовность и отказоустойчивость
RDM Embedded имеет уникальные характеристики, с помощью которых
приложения,
в
которых
используется
эта
СУБД,
становятся
41
отказоустойчивыми, способными быстро восстанавливать доступ к данным
после сбоев. Используемые вместе или по отдельности эти достоинства
обеспечивают разработчиков необходимой функциональностью для создания
систем с поддержкой высокой готовности.
Система зеркального копирования, реализованная в RDM Embedded,
представляет собой интегрированное низкоуровневое решение для
зеркального копирования изменений из главной базы данных в
резервную копию. Это мощное средство широко используется в
системах с поддержкой высокой готовности.
Множественный доступ к базе данных позволяет приложениям
выполнять доступ к нескольким файлам базы данных в пределах одной
транзакции.
Автоматическое восстановление данных используется в случае сбоя в
работе системы. Отдельные транзакции могут быть не завершены во
время отказа системы или аппаратных средств. Очень важно вернуть
систему в релевантное состояние. RDM Embedded гарантирует, что
после
перезагрузки
все
изменения,
выполненные
в
пределах
завершенных транзакций, будут применены к базе данных, перед тем
как она станет доступной для других приложений.
Простая интеграция приложений и систем
Интеграция
с
приложениями
значительно
упрощается
благодаря
использованию стандартных интерфейсов, c помощью которых RDM Embedded
может быть встроена в C/C++ , Java и SQL-приложения.
Интеграция приложения в существующую инфраструктуру требует
взаимодействия с другими приложениями, которые могут использовать иные
технологии для управления данными. Благодаря добавлению поддержки XML,
который является промышленным стандартом для реализации совместимости с
42
другими системами, RDM Embedded облегчает интеграцию с такими
приложениями.
Используются следующие интерфейсы:
Native API. RDM Embedded включает свыше 150 функций на языке C, с
помощью которых можно полностью контролировать работу базы
данных.
SQL API. SQL – простой общепринятый язык для работы с базами данных.
В RDM Embedded реализован SQL API для поддержки приложений,
которые общаются с базой данных при помощи команд SQL.
JAVA API. Java API реализован при помощи технологии JNI (Java Native
Interface). С помощью расширенного через JNI интерфейса на языке С
(Native API) разработчики могут удобно и эффективно работать с
данными любого уровня сложности. Такой доступ к функциональности
дает
существенные
преимущества
в
скорости
и
минимизирует
избыточность операций.
XML API. XML является новым передовым стандартом, используемым в
Интернет-приложениях
для
упрощения
обмена
данными
между
различными гетерогенными системами. В RDM Embedded имеется слой
XML Import/Export, который позволяет экспортировать и импортировать
данные в виде правильно сформированных (well-formed) XMLдокументов. Опционально к экспортируемому или импортируемому
XML-документу можно добавлять его DTD или XML-схему.
Многопользовательская поддержка
При одновременной работе разных приложений или нескольких копий
одного и того же приложения, обращающихся к базе данных, стоит задача
обеспечения
целостности
данных.
В
RDM
Embedded
реализована
многопользовательская поддержка, позволяющая обрабатывать запросы от
многопоточных и многозадачных клиентов, или одновременные запросы
43
разных клиентов из локальной сети. Целостность данных поддерживается
благодаря механизмам блокировок и транзакций, реализованных в RDM
Embedded при помощи контроля над операциями в базе данных и ведения
журнала транзакций.
Целостность данных
Двумя ключевыми механизмами обеспечения целостности данных при
работе в многопользовательском режиме и при восстановлении данных
являются обработка транзакций и блокировка файлов.
Обработка транзакций обеспечивает логическую целостность данных,
позволяя группировать последовательные изменения, а затем сохранять
их как единое целое.
Блокировка файлов необходима при изменении совместно используемых
данных. Данные в заблокированных файлах не могут быть изменены
другими клиентами.
Безопасность и высокая готовность
Гарантии безопасности, отказоустойчивости и высокой готовности
данных являлись основным приоритетом при разработке архитектуры Birdstep
RDM
Embedded.
низкоуровневым
Зеркальное
решением
для
копирование
сохранности
является
данных
и
комплексным
может
быть
использовано для разработки отказоустойчивых систем.
Оптимизация производительности приложений
Диспетчер базы данных Birdstep RDM Embedded спроектирован для
высокоэффективного использования системных ресурсов. Как правило, для
работы он требует до 225 Кб памяти в зависимости от операционной системы и
используемых опций. Диспетчер предоставляет универсальную утилиту для
конфигурации размера страниц и кэш-памяти, максимально увеличивая
производительность за счет минимизации операций ввода/вывода с жесткого
диска.
44
Многоплатформенная поддержка
RDM Embedded протестирована на разных операционных системах
общего назначения и на системах работающих в режиме реального времени.
Среди них – Windows, Linux, Solaris, Microsoft WinCE, QNX Neutrino,
MontaVista Embedded Linux и Wind River VxWorks.
RDM Embedded продолжает быть наиболее часто используемой СУБД
для встроенных приложений, начиная от сложных систем реального времени,
до мобильных систем многократного применения.
XML
является
универсальным
форматом
для
структурированных
документов и данных в интернет. Этот язык разметки, являющийся стандартом
консорциума W3C (World Wide Web Consortium), используется для создания
структурированного содержания и сопровождения метаданных о нем. На
практике
это означает, что XML позволяет организациям совместно
использовать,
обмениваться
и
публиковать
данные
универсальным
и
общепринятым образом.
Язык XML повсеместно признан в качестве идеального средства для
создания
информационных
сетей.
В
последнее
время
XML
также
рассматривается в качестве предпочтительного формата для обмена данными
через беспроводные коммуникационные устройства. Язык XML, с его
гибкостью и широким распространением, предлагает обобщенные средства
расширения приложений, позволяя подключить мобильных пользователей как к
потребительским, так и к бизнес-рынкам. Подготовленный к использованию
XML процессор баз дынных Birdstep DataBase Engine, работающий в
приложениях для портативных устройств, также хорошо будет работать и с
периодически подключающимися пользователями.
Абстрактное
определение
языка
XML
называется
множеством
информации (Infoset) XML. Его целью является предоставление согласованного
45
набора определений для ссылки на информацию в правильно построенном
XML-документе.
XML-документы могут иметь два основных представления.
Последовательное представление – это поток знаков, соответствующих
определенным правилам синтаксиса XML. Это представление больше всего
подходит для передачи данных, а также для их просмотра и чтения человеком.
Рис. 2.1. Струкутра сериализации.
Модель Infoset – это иерархия узлов, где каждый узел представляет
информационный элемент, и где каждый элемент может содержать другие
элементы или значения. Это представление больше всего подходит для
навигации в структуре документа, для поиска конкретных элементов или
значений, а также для генерации вторичных документов.
На рис. 2.1. показана структура сериализации, стоящая за иерархическим
преставлением.
46
§2.2. Процессоры баз данных.
Процессор баз данных Birdstep Database Engine.
Перед тем, как XML-документ должен быть представлен в иерархической
структуре на компьютере, он либо размещается в памяти, либо хранится в базе
данных. Если необходимо постоянство, то, очевидно, что поддержка этой
структуры базой данных экономит время и представляет более эффективное
решение, чем многократный анализ документа в памяти. Реляционные базы
данных не очень хорошо подходят для представления XML-документов. Они не
поддерживают упорядоченность, иерархию, регулярные структуры и поля
переменной длины. Реляционные базы данных были спроектированы для таких
структур табличных данных, как базовая модель данных. Они предназначены
для обработки SQL-запросов, но не очень хорошо подходят для обслуживания
запросов, зависящих от содержания, в ориентированных на XML структурах.
Процессор Birdstep Database Engine был спроектирован с акцентом на
эффективное представление XML-документов, на навигацию и поиск в них. В
следующем параграфе описывается ключевой механизм, используемый в
Birdstep Database Engine.
Наполненный данными процессор Birdstep Database Engine можно
представить в виде коллекции объектов. Каждый объект может быть
ассоциирован с типом (классом), который был декларирован в схеме базы
данных. Объекты в Birdstep Database Engine могут быть организованы в
иерархическую структуру. Поэтому этот процессор особенно хорошо подходит
для представления XML-документов в виде иерархии узлов. Birdstep Database
Engine содержит механизм создания структуры, навигации и поиска в ней.
Ниже перечислены возможности доступные в Birdstep Database Engine.
Класс
может
обладать
необязательных атрибутов.
комбинацией
обязательных
и
47
Необязательные атрибуты могут быть добавлены динамически,
что позволяет использовать представления структур данных, которые не
были первоначально определены в схеме базы данных.
Объект может иметь много дочерних объектов, либо ни одного.
Дочерние объекты любого объекта упорядочены. Новые дочерние
объекты вставляются согласованно по отношению к другим дочерним
объектам.
Любой объект имеет не больше одного родительского объекта.
Ребро соединения объекта с родительским объектом обладает
текстовым ярлыком, который описывает роль этого объекта по
отношению к родителю.
Ярлыки могут быть скомбинированы, образуя пути в базе данных.
Пути можно использовать для ограничения множества запросов на
иерархически структурированные данные.
Объекты с одним и тем же родительским объектом могут иметь
одинаковые ярлыки на ребре, соединяющем их с общим родителем. Это
означает, что путь определяет не один, а множество объектов. С другой
стороны, можно представлять ярлык как имя подкаталога. Тогда, на
дочерние объекты, связанные с одним и тем же родительским объектом
через одинаковый ярлык, можно смотреть, как на часть одного и того же
подкаталога. Ярлык представляет подкаталог, а на объекты можно
смотреть, как на файлы, хранимые в данном подкаталоге.
Диаграммы могут быть представлены с помощью комбинации
родительски-дочерних структур и использования атрибутов для ссылки
на другие объекты базы данных.
Индексирование обеспечивает быстрый поиск и навигацию.
Эти возможности Birdstep Database Engine служат средством для
высокоэффективной и надежной реализации интерфейсов XML. XML-
48
документы хранятся в базе данных Birdstep как объекты иерархической
структуры. Для базы данных Birdstep БД-структура XML-документа была
сконструирована максимально похожей на модель Infoset. Это означает, что
существует однозначное соответствие между узлами в структуре Infoset и
узлами в дереве, отвечающем объектам документов базы данных. Для
эффективности, узлы атрибутов в Infoset не представляются как объекты в базе
данных. Это отражается в структурном различии между определением в Infoset
и XML-представлением в базе данных. Также для повышения эффективности,
атрибуты Infoset представляются как атрибуты объектов, для которых атрибуты
уместны. В последовательном (сериализованном) представлении
XML-
документы обычно содержат атрибуты, значения и теги. В базе данных Birdstep
теги хранятся как объекты (теговые объекты). Атрибуты и их значения
хранятся как атрибуты теговых объектов и в самих атрибутах этих объектов.
На рис. 2.2 показано, как Birdstep реализует стандарты SAX, DOM и
XPATH для программистов приложений с помощью множества классов и
методов, определенных в этих стандартах. Реализация SAX, DOM и XPATH
привязана к Birdstep Database Engine с помощью встроенного интерфейса APIобращений к базе данных.
Рис. 2.2. Реализация Birdstep DBE и XML.
49
SAX является простым интерфейсом API для XML, который был
разработан, чтобы обеспечить программистам доступ к нужной информации
без необходимости самим создавать специальные синтаксические анализаторы.
SAX – это набор абстрактных программных интерфейсов, которые проецируют
документ на поток вызовов известных методов. Продукты компании Birdstep
используют внешние синтаксические анализаторы (expat-parser) с открытым
кодом, чтобы анализировать поток и считывать интегрированные теги,
атрибуты, значения, текст и структуру XML-документов. SAX компании
Birdstep содержит методы для преобразования документа в иерархию объектов
и атрибутов, которые будут представлять документ. SAX описывает
управляемый событиями интерфейс для процесса синтаксического разбора
XML-документов. SAX является свободно распространяемым интерфейсом
API, разработанным специалистами из списка рассылки XML-DEV. SAX не
имеет формальных документов спецификации, но он определяется свободно
распространяемой
реализацией,
выполненной
с
помощью
языка
программирования Java™. Синтаксический анализатор языка XML является
совместимым с SAX, если он использует интерфейс, реализованный со
статусом всеобщего достояния (public domain).
Управляемый событиями интерфейс обеспечивает механизм уведомлений
для
кода
приложения
при
распознавании
основным
анализатором
синтаксических XML-конструкций текущего документа.
Использование SAX для импорта XML-документов и данных.
SAX был выбран для того, чтобы обеспечить доступ к информации в
XML-документе не как к дереву узлов, а как к последовательности событий.
Реализация Birdstep SAX отслеживает SAX-события, генерируемые SAXанализатором, когда он читает XML-документ. Birdstep SAX интерпретирует
эти события для создания объектов в базе данных. SAX будет реагировать на
событие для каждого открытого и каждого закрытого тега. Еще он запускается
50
на события для секций #PCDATA и CDATA, инструкций обработки, а также
для шаблонов DTD, комментариев и так далее. На рис. 2.3 показано, как можно
использовать реализацию Birdstep SAX для импорта XML-документа в базу
данных Birdstep.
Рис. 2.3. Реализация Birdstep SAX.
Использование SAX для получения XML-документов и данных из
базы данных Birdstep.
Когда XML-документ сохранен в базе данных Birdstep, его можно
получить целиком или по частям с помощью данной реализации SAX. В этом
случае можно создавать программы приложений, которые используют
интерфейс Birdstep SAX в качестве управляемого событиями механизма подачи
элементов
документа.
Нужно
отметить,
что
элементы
подаются
последовательно и навигация назад и вперед при использовании SAX
невозможна. Конечно, программа приложения может реагировать на события
независимо. Например, она может выполнять сериализацию документа, то есть
перестраивать его. Также программа может осуществлять поиск тегов или сбор
статистики. На рис. 2.4 показано, как реализация Birdstep SAX взаимодействует
с программой приложения и Birdstep Database Engine.
Рис. 2.4. Реализация Birdstep SAX.
51
Так же, как анализатор XML вообще и SAX, в частности, наносит
некоторый слой абстракции на фактическое текстовое представление XMLдокумента, объектная модель документа (DOM) добавляет слой абстракции к
верхнему уровню всего документа. DOM стандартизует объектную модель,
представляющую XML-документ, и определяет интерфейс структуры и стиля
XML-документов, который не зависит от языка программирования и
платформы, К этому интерфейсу некоторые процессы получают динамический
доступ и могут обновлять его. Элементы рассматриваются как узлы дерева
вместо того, чтобы быть составленными из открывающих и закрывающих
тегов. Узлы могут обладать родительскими и дочерними объектами. Также они
могут иметь внутренние свойства, которые можно изменить с помощью
объектов и методов.
DOM предоставляет программам доступ к хранящейся в XML-документе
информации, как к иерархической объектной модели. DOM рассматривает
документ как дерево узлов, основанное на структуре и информации данного
XML-документа. Программисты могут получить доступ к информации,
взаимодействуя
с
этим
деревом
узлов.
DOM
определяет
множество
абстрактных интерфейсов, что моделирует согласование документа со
спецификациями XML-модели Infoset. Реализация DOM компании Birdstep
состоит из множества методов для обеспечения доступа к документу,
хранимому в базе данных в виде иерархии объектов. Данная реализация DOM
поддерживает приложения, написанные на C++.
Объектная модель документа задает древовидное представление XMLдокумента. Самый верхний уровень документа является корнем дерева и имеет
единственный дочерний объект, который представляет собой элемент самого
верхнего уровня. Этот элемент имеет дочерний узел, представляющий
содержание и любые другие подчиненные элементы. Эти элементы могут иметь
свои дочерние элементы на много уровней в глубину. Заданные функции
52
позволяют проходить результирующее дерево любым желаемым образом,
иметь доступ к элементам и значениям атрибутов, вставлять и удалять узлы, а
также конвертировать данное дерево обратно в XML.
Использование
DOM
полезно
для
изменения
XML-документов.
Например, можно создать DOM-дерево, изменить его, добавив новые узлы и
переместив некоторые ветви, а затем на выходе создать новый XML-документ.
Также можно самостоятельно создать DOM-дерево и преобразовать его в XML.
Часто, это более гибкий способ получения XML-кода, чем просто писать
<tag1>...</tag1> в файле.
Для некоторых классов приложений использование SAX или прямое
взаимодействие с анализатором XML может быть идеальным способом
получения XML-документов. Если приложение должно обрабатывать XMLдокументы с минимально возможной задержкой или, если обрабатываемые
документы слишком велики и не помещаются в памяти, тогда необходима
обработка каждого из событий в той последовательности, в которой они
возникают в документе
Проблема использования SAX заключается в том, что приложение
должно установить обработчики событий для всех элементов, с которыми оно
работает, и оперативно создавать свои собственные структуры данных по мере
возникновения событий. Вместо того чтобы реагировать на каждое событие,
было бы проще, если бы все дерево уже было загружено в память, так что при
этом было бы возможно перемещаться по дереву и изменять его сегменты
простым образом.
Модель DBE-хранилища компании Birdstep была спроектирована
максимально приближенной DOM по структуре. Однако, эта модель проще,
настолько, чтобы сделать эффективным последовательный вывод данных, то
есть с помощью SAX. Поскольку в БД компании Birdstep XML-данные
хранятся в структурах, схожих с DOM, DOM-интерфейс (или SAX-обработчик)
53
не обязан загружать в память весь XML-документ прежде, чем пользователь
сможет получить к нему доступ. К методам и объектам DOM можно
обращаться в то время как документ находится в кэш-памяти буфера. Это
основное отличие от подхода, когда XML-документ храниться в виде
последовательной цепочки объектов.
XML-интерфейс процессора Birdstep Database Engine во многих
отношениях подвержен влиянию со стороны DOM-интерфейса компании
Apache, под названием Xerces. Это было сделано с целью помочь персоналу,
знакомому с Xerces, легче перейти к работе с XML-интерфейсом процессора
баз данных Birdstep Database Engine. Кроме того, проекты, использующие
Xerces в качестве основного интерфейса, могут быть легко переведены на
использование XML-интерфейса процессора Birdstep Database Engine. Однако,
лежащая в основе архитектура полностью различна, поскольку DOMинтерфейс компании Birdstep работает с постоянными объектами баз данных,
тогда как Xerces работает только с динамическими представлениями,
находящимися в памяти.
XPATH (язык путей в XML) является языком для выбора в XMLдокументе некоторого множества узлов. Синтаксис этого языка основан на
использовании путей. Продукт XPATH компании Birdstep содержит логику,
которая интерпретирует запрос, преобразует его в серию обращений к APIметодам Birdstep DBE и представляет результирующее множество узлов.
Основной целью XPath является адресация частей XML-документа. В
поддержку этой основной цели данный язык также предоставляет базовые
средства для манипуляций со строками, числами и логическими параметрами.
В XPath реализован компактный, отличный от XML синтаксис для того, чтобы
облегчить использование XPath с идентификаторами URI и значениями
атрибутов в XML. XPath оперирует скорее с абстрактной, логической
структурой XML-документа, чем с его поверхностным синтаксисом. Название
54
XPath возникло из-за использования путевых обозначений, таких как указатель
URL, для навигации по иерархической структуре XML-документов.
Основной синтаксической конструкцией в XPath является выражение.
Выражение после обработки выдает объект одного из следующих четырех
основных типов:
тип
множества
узлов
(неупорядоченная
коллекция
узлов
без
дубликатов);
логический тип (значения: true или false);
число (число с плавающей запятой);
строка (последовательность UCS-символов).
XPath используется для извлечения путей из XML-документов. В базе данных
компании Birdstep XML-документы представлены в виде иерархии объектов
(узлов). Когда XPATH-оператор используется в программе, выражение и
содержание узлов задаются в качестве параметров. Синтаксический анализатор
XPATH оценивает выражение и преобразует его в запрос к процессору Birdstep
Database Engine. Результатом запроса является неупорядоченное множество
узлов, которые могут быть и пустыми. Это множество удовлетворяет
критериям данного выражения.
Запрос обрабатывается с помощью функций LookUp процессора Birdstep
Database Engine. Схема индексации процессора базы данных обеспечивает
высокопроизводительный поиск. Получающееся множество представляется с
помощью ориентированной на указатели коллекции в процессоре баз данных
Birdstep Database Engines.
RDM
предоставляет
мощные
средства
создания
собственного
многопоточного сервера, ориентированного на конкретное приложение. На рис.
2.5, приведенном ниже, иллюстрируется архитектура типичного приложения
клиент-сервер на основе RDM Server. Затененные области представляют
компоненты RDM Server.
55
Рис. 2.5. RDM Server: архитектура типа клиент-сервер.
Пробное приложение состоит из следующих компонентов:
Клиентской
программы,
осуществляющей
доступ
к
серверу
посредством библиотек клиентского интерфейса системы RDM
Server (например, SQL и/или удаленные вызовы процедур).
Запускаемых сервером расширений, ориентированных на конкретное
приложение.
Обмен данными в RDM Server обеспечивается интерфейсом Multiple Network
Control Processor (MNCP).
В классической архитектуре обмен данными с RDM Server ограничен
отдельным системным процессом. Такой процесс использует интерфейс Remote
Procedure Call (RPC)/MNCP. RDM Server продолжает поддерживать эту
архитектуру. Однако теперь имеется мощная альтернатива, обеспечивающая
большую гибкость при использовании RDM Server в качестве встроенной базы
данных. В рамках этой расширенной архитектуры можно напрямую связать
приложение с процессором RDM Server, который позволяет приложению
превратиться в сервер баз данных. Некоторые детали представлены на рис. 2.6.
56
Рис. 2.6. Архитектура сервера приложений.
Для работы сервера баз данных, ориентированного на конкретное
приложение, необходимо выбрать тип протокола удаленного обмена данными,
поддержка которого будет осуществляться в дальнейшем. Обмен данными
может контролироваться приложением совершенно независимо от RDM Server.
Для полного использования преимуществ многопоточной среды RDM Server
приложение может запускать собственные потоки и управлять ими, каждый из
которых контролирует один или несколько сеансов работы с RDM Server.При
обращении приложения к системе RDM Server (с помощью функции s_startup),
она может запустить свои RPC/MNCP-потоки (представленные на рисунке 2
прямоугольниками
со
штрихованными
границами).
Таким
образом
осуществляется доступ к базе данных RDM Server любыми стандартными
клиентскими программами, основанными на этой среде.
Автономные (не типа клиент-сервер) приложения, требующие мощности
и производительности полноценного многопоточного процессора баз данных,
получат преимущества за счет отсутствия проблем с производительностью и
памятью, которые связаны с доступом к отдельному процессу (например, к
57
программе, использующей RDM Server), осуществляемым посредством
протокола сетевого обмена данными (NCP) с совместным использованием
памяти.
Рекомендации по разработке сервера приложений для баз данных
Команды s_startup и s_terminate – административные функции,
контролирующие запуск и завершение работы процессора баз данных RDM
Server.
После запуска RDM Server путем вызова s_startup можно инициировать
любое число сеансов работы с помощью функции s_login. (Примечание:
параметр имени сервера в команде s_login не используется, если эта функция
вызывается сервером приложений). Использование многопоточности увеличит
масштабируемость
и
системную
производительность.
Каждый
поток
осуществляет свой собственный вызов функции s_login. Необходимо отметить,
что обращения к функциям RDM Server реализуются последовательно для
отдельного сеанса работы. Этого можно достигнуть, реализуя все обращения
для данного сеанса работы из одного и того же потока. Хотя можно напрямую
обращаться к функциям управления потоками, предоставляемым операционной
системой, также есть возможность использовать функции диспетчера RDM
Server Resource Manager, обеспечивающие преимущества независимости от
платформ.
После завершения всех сеансов работы (s_logout) вызывается функция
s_terminate для остановки процессора баз данных RDM Server.
Это и в самом деле просто. Кроме обращений к s_startup и s_terminate,
все остальное работает точно так же, как в архитектуре клиент-сервер, за
исключением того, что в целом приложение функционирует подобно модулю
расширения без необходимости быть доступным по RPC-интерфейсу среды
RDM Server. Конечно, сервер приложений также отвечает за управление
обменом с любым клиентским приложением.
58
Краткая сводка и описание этих функций представлены в следующей таблице.
Таблица 2.1. Функции управления средой RDM Server
Функция
s_startup
Описание
Запуск процессора баз данных RDM Server.
Старт RPC/NCP-подсистемы RDM Server и запуск сеансовых
s_startRPCThreads
потоков.
s_endRPCThreads Остановка RPC-подсистемы RDM Server.
s_terminate
Остановка процессора баз данных RDM Server.
Простой код, приведенный ниже, иллюстрирует использование этих функций. В нем описан
запуск основного сервера среды RDM Server.
#include "velocis.h"
static RDSLOGFCN MessageConsole;
static short shutdown_flag;
/* Основной сервер баз данных RDM Server
*/
void main(
int argc,
char *argv[])
{ short stat;
char *catpath = NULL;
char *server = "RDM Server";
if ( argc > 1 ) {
/* первый аргумент – имя сервера, по умолчанию это "RDM Server" */
server = argv[1];
if ( argc > 2 ) {
/* второй аргумент – путь к альтернативному каталогу */
catpath = argv[2];
}
}
stat = s_startup(catpath, MessageConsole, LOG_ALL);
if ( stat != S_OKAY ) {
printf("Unable to start RDM Server engine, status = %d\n", stat);
exit(1);
}
rm_interrupt(&shutdown_flag);
stat = s_startRPCThreads(server, noSessionThreads, &shutdown_flag);
if ( stat != S_OKAY ) {
printf("Unable to start RDM Server RPC server, status = %d\n", stat);
exit(1);
}
while ( ! shutdown_flag )
rm_sleep(5000L);
s_endRPCThreads();
59
s_terminate();
}
Программа получает из командной строки два аргумента. Первый – имя
сервера. Вторым аргументом (если он указан) является путь к системному
каталогу RDM Server.
При вызове функции s_startup ей могут передаваться три параметра.
Первый имеет тип строки и содержит путь к системному каталогу. Если
этот параметр не указан, RDM Server будет использовать переменную
окружения CATPATH или текущую директорию. Если каталог не найден, то
будет выдано сообщение об ошибке.Вторым параметром является адрес
собственной функции журнала регистрации событий RDM Server. Эта функция
вызывается для обработки каждой ошибки или информационного сообщения,
сгенерированного процессором баз данных RDM Server. Если параметр не
задан, то по умолчанию каждое сообщение передается команде stdout и
записывается в файл rds.log.Третий параметр указывает, какой класс сообщений
будет регистрироваться. В приведенном примере задана регистрация любых
сообщений (для получения списка всех типов сообщений следует обратиться к
описанию функции s_startup). Следует заметить, что если команда s_startup
возвращает
ошибку,
то
связанное
с
этим
сообщение
уже
будет
зарегистрировано.Представленной ниже функции журнала регистрации можно
передавать три параметра.
Первый указывает, будет ли функция обрабатывать зарегистрированные
сообщения, только регистрировать их или же закроет журнал регистрации
сообщений. Эти опции задаются константами RDSLOG_OPEN,
RDSLOG_MESSAGE и RDSLOG_CLOSE.
Второй параметр определяет тип сообщений, таких, как сообщение об
ошибке, предупреждающее или информационное сообщение.
60
Третий параметр – строка сообщения. Приведенный ниже пример,
несмотря на тривиальность, иллюстрирует основные конструкции.
/* Log RDM Server console message
*/
void MessageConsole(
RDSLOG_CTRL fcn, /* тип вызова: открыть, закрыть, отправить сообщение */
short type, /* тип сообщения */
char *msg) /* сообщение, которое должно быть зарегистрировано */
{
static FILE *errlog;
switch ( fcn ) {
case RDSLOG_OPEN:
errlog = fopen("RDM Server.log", "w");
break;
case RDSLOG_MESSAGE:
if ( type == LOG_ERROR ) {
/* убедитесь, что это было принято во внимание */
fprintf(errlog, "******* ERROR! ******* ");
printf("******* ERROR! ******* ");
}
fprintf(errlog, "%s\n", msg);
printf("%s\n", msg);
break;
case RDSLOG_CLOSE:
fclose(errlog);
break;
}
}
После успешного запуска процессора RDM Server вызывается функция
rm_interrupt
для
обеспечения
возможности
перехвата
программных
прерываний, инициированных пользователем. Ее единственный параметр
задает адрес переменной типа short (shutdown_flag), которой будет присвоено
значение 1 в случае пользовательского прерывания.
Обращение к функции s_startRPCThreads активизирует RPC/NCPподсистему RDM Server, задавая имя сервера и число запускаемых сеансовых
потоков, которые образуют множество потоков, обеспечивающих выполнение
одного или нескольких сеансов работы пользователей. Система спроектирована
так, чтобы все активные сеансы работы могли обслуживаться фиксированным
числом сеансовых потоков, которое меньше, чем фактическое количество
61
активных сеансов работы. Если число потоков равно нулю, то оно по
умолчанию будет взято из файла rdm server.ini. Третий параметр является
указателем на переменную типа short (опять используется shutdown_flag),
которой будет присвоено значение 1 в случае, если пользователь с правами
администратора
запросил
остановку
системы.Теперь
система
начинает
бесконечную серию пятисекундных циклов, которая заканчивается только
после присваивания флагу shutdown_flag единицы либо в результате
пользовательского прерывания, либо вследствие запроса администратора на
закрытие системы. После фиксации значения флага shutdown_flag программа
обращается к s_endRPCThreads, чтобы закрыть RPC/NCP-подсистему, а затем
вызывает функцию s_terminate, чтобы остановить процессор баз данных RDM
Server.
Этим завершается обсуждение использования среды RDM Server для
создания сервера баз данных, ориентированного на конкретное приложение.
Помимо
поддержки
"спящего"
режима
программа
может
содержать
пользовательский интерфейс, который, например, может выполнять различную
административную работу с помощью утилит admin или dram. Также возможна
поддержка других характерных для конкретных приложений возможностей
администрирования, которые по желанию могут быть ограничены самим
сервером. Описанная технология идеально подходит для любого отдельного
программного приложения, требующего высокопроизводительного процессора
баз данных. Примеры подобного применения включают в себя системы
резервного копирования на внешний носитель, мониторинг событий в режиме
реального времени.
Способность
напрямую
связывать
полнофункциональный,
высокопроизводительный процессор баз данных с конкретным приложением –
одна из уникальных черт продукта RDM Server компании Birdstep, что делает
62
его лучшим выбором среди доступных на текущий момент коммерческих
встраиваемых СУБД.
§2.3. Роль баз данных в приложениях реального времени.
При разработке систем реального времени и встроенных систем обычно
не рассматривают возможность использования в приложениях коммерческих
СУБД. Но разве большинство баз данных не являются медленными и
громоздкими, требуя для доступа к данным интерфейс, подобный SQL?
К сожалению, это общее утверждение проистекает из идеи, что понятие
"база данных" является синонимом больших реляционных баз данных в рамках
всего предприятия (как те, что производятся компанией Oracle) или
неэффективных и медленных персональных баз данных (таких как Microsoft
Access). Многие разработчики полагают, что поскольку такие базы данных не
годятся для встроенных систем и систем реального времени, то им придется
создавать собственные структуры управления данными с нуля.
Однако в данном случае нет необходимости заново "изобретать колесо".
Существует другой тип баз данных, который радикально отличается от хорошо
известных СУРБД. Эти БД является испытанным решением для хранения,
извлечения и манипулирования данными во встроенных приложениях или
приложениях реального времени на многих популярных операционных
системах реального времени (RTOS). RDM – это именно такой процессор баз
данных низкого уровня или встроенная база данных. Эта база данных
встраивается в приложение на самом низком уровне и основана на хорошо себя
зарекомендовавшем и высокоэффективном микроядре компании Birdstep.
Данное микроядро включает в себя библиотеку функций языка C,
которые встроены в приложение и работают с данными напрямую (в отличие от
63
SQL C-API, который создает дополнительные слои между приложением и
данными, хранящимися в базе данных).
Требования, предъявляемые к базе данных.
Ниже перечислены свойства, которые важны для разработчиков приложений
реального времени.
Размер – минимальный объем использования ОЗУ и дискового
пространства.
Производительность
–
характеристика
особенно
важная
для
операционных систем реального времени.
Надежность – это означает, что система должна работать без контроля
со стороны человека.
Предсказуемость
–
необходимость
в
предсказуемости
таких
параметров, как размер и производительность.
Низкоуровневый контроль – способность контролировать количество
операций ввода/вывода и время их совершения.
RDM превосходно подходит для RTOS-приложений, поскольку эта база
данных была разработана с учетом указанных выше свойств. Кроме того,
компания Birdstep более 10 лет занимается конструированием и улучшением
этих свойств. Этот процессор баз данных доступен для 16- и 32-битных
платформ с поддержкой множества операционных систем реального времени
(UNIX и 16- и 32-битные версии Windows также доступны).
Размер.
Сам по себе процессор баз данных RDM является маленьким. Он
включает в себя библиотеку функций языка C, которая компонуется в
приложение. Обычно процессоры баз данных требуют приблизительно 400 Кб
ОЗУ в зависимости от того, сколько C-функций реально используется. При
использовании библиотеки классов C++ вместо C API нужно добавить еще 80
Кб. Сама база данных также может быть целиком загружена в ОЗУ.
64
Эффективная
структура
базы
данных
также
может
минимизировать
использование дискового пространства. Разумное использование модели
сетевой базы данных, основанной на указателях (об этом немного позже),
помогает избегать излишнего использования индексов, которые обычно
расходуют много дискового пространства, и циклов центрального процессора.
Производительность.
Для производительности процессора баз данных исключительно важно
избегать ненужного доступа к диску. Зачастую самой главной причиной
излишнего доступа к диску является недостаток контроля над процессором баз
данных. Возможности контроля в RDM подробно обсуждаются в разделе
настоящей статьи, посвященном низкоуровневому контролю баз данных и
архитектуре данных. RDM, как и многие процессоры баз данных, кэширует
данные в ОЗУ. Он также позволяет задавать размер страниц и кэш-памяти. В
некоторых случаях можно создавать приложения таким образом, чтобы все
записи, к которым доступ всегда осуществляется одновременно, были
расположены непрерывно в файле данных, что ведет к минимальному
использованию дискового пространства.
Надежность.
Ядро RDM, написанное на языке C, а также его версия, основанная на
библиотеке классов C++, более 10 лет пользуется успехом у разработчиков. С
течением времени RDM превратился в испытанный и стабильный процессор
баз данных. А то, что Birdstep предоставляет программный код RDM,
обеспечивает дополнительные гарантии. Целостность данных гарантируется за
счет транзакций RDM и его механизма автоматического восстановления,
который
обеспечивает
завершенность
транзакций
при
нарушении
электроснабжения и системных сбоях. Создание отчетов об ошибках в базе
данных управляются одной функцией (которая при необходимости может быть
65
заменена разработчиком приложений), чтобы обеспечить внесение ошибок в
журнал и их надлежащую обработку.
Предсказуемость.
Возможно, эта характеристика даже более важна для разработчиков
приложений реального времени, чем производительность сама по себе.
Способность в сжатые сроки предсказывать, сколько времени займет та или
иная операция над БД и сколько дискового пространства понадобится для базы
данных, является насущно необходимой. Эти статистические данные должны
оставаться неизменными при росте БД. RDM использует записи фиксированной
длины. На первый взгляд это может показаться недостатком, но следует
вспомнить о том, что любые данные переменной длины могут быть разбиты на
совокупность записей фиксированной длины (использование "множеств" RDM
делает эту процедуру простой в использовании). Значительное преимущество
такой структуры данных заключается в том, что определение местоположения
любой записи становится простой задачей.
Кроме того, в данном случае времена доступа становятся более
предсказуемыми. При удалении записи просто помечаются как удаленные и в
дальнейшем могут быть использованы заново. Поэтому здесь требуется
минимальный контроль.
Аналогично, использование дискового пространства становится легко
предсказуемым. Теперь совершенно просто можно подсчитать точное число
байтов, необходимое для хранения заданного числа записей.
Низкоуровневый контроль.
В случае RDM можно увеличить продуктивность за счет использования
библиотеки классов C++. Но реальным преимуществом является следующее:
если необходим реальный контроль того, что процессор баз данных делает на
самом низком уровне, если нужно избавится от избыточности или добиться
максимальной производительности, требуется использовать низкоуровневый C-
66
API. При необходимости к использованию функций C-API можно обратиться в
любое время.
API, основанный на языке C, включает в себя функции для чтения и
записи отдельных записей или полей, для навигации от одной записи к другой
разными способами (в последовательности ключей, множеств или физическом
порядке), для многопользовательской координации, а также для контроля таких
параметров, как объем кэш-памяти или число дескрипторов файла, доступных
процессору баз данных. C API содержит более 150 функций для полного
контроля и манипулирования базой данных. Библиотека классов C++
предоставляет функции и операторы, позволяющие объединять два или три
вызова C API в единую операцию.
RDM также обеспечивает контроль над физической структурой базы
данных. Все данные хранятся "постранично". Отдельная страница состоит из
нескольких записей или ключевых значений в блоке фиксированного размера.
Запись и чтение данных происходит на одной странице за раз. Поскольку
можно задавать размер страницы, то можно и указывать, сколько записей или
ключевых
значений
могут
быть
прочитаны
одновременно.
За
счет
использования подобных параметров тонкой настройки можно улучшить
производительность приложений, использующих RDM.
Все типы данных, разрешенные в языке C, могут храниться в базе данных
RDM, включая структуры и массивы. Это ускоряет ввод/вывод данных за счет
отказа от транзакций ненужных типов данных.
§2.4. Архитектура баз данных.
Вероятно, самое важное отличие реляционных баз от процессора базы
данных компании Birdstep заключается в лежащей в их основе архитектуре баз
данных. Архитектура баз данных (или модель баз данных) на самом
67
фундаментальном уровне определяет, как будет осуществляться доступ к
данным и их хранение. Дальнейшая производительность и эффективность в
значительной степени определяется в момент выбора лежащей в основе
модели.
Эта модель основана на прямом доступе к записям базы данных в
противоположность
индексному
доступу,
используемому
в
модели
реляционных баз данных. Очень важным моментом в проектировании высокой
производительности приложений со встроенными базами данных является
использование сильных сторон обеих моделей.
Ниже приведены для сравнения различия между моделями реляционных
баз данных и сетевых баз данных, основанных на указателях. Кроме того, ниже
предлагается эталонный тест, демонстрирующий преимущества в скорости и
эффективности сетевой модели. Предлагаемый тест сравнивает сетевое
решение Birdstep Database Manager и реляционные модели в применении к
одним и тем же задачам и демонстрирует 15-кратное превосходство сетевой
модели в скорости перед реляционной версией.
Определение реляционных и сетевых моделей.
В реляционной модели данные хранятся в таблицах, состоящих из
столбцов и строк. При возникновении необходимости в данных более чем из
одной таблицы одна из операций объединения связывает эти данные, используя
копию столбца от каждой таблицы. Несмотря на гибкость реляционной модели,
ее производительность ограничена необходимостью создавать новые таблицы
для хранения результатов реляционных операций, тогда как хранение
избыточных столбцов в связанных таблицах приводит к росту размера базы
данных. Кроме того, обработка операций объединения расходует ценные
системные ресурсы – получение объединенных данных из двух таблиц
приведет к замедлению работы приложения, а запрос на получение данных
более чем из двух таблиц может полностью "подвесить" систему.
68
Рассмотрим, что происходит при переходе от одной таблицы к другой,
используя реляционную связь: найдя ключевое значение в первой таблице,
процессор баз данных ищет это значение в индексном файле, который в свою
очередь содержит некоторый вид ссылок на вторую таблицу. Проблема
заключается в том, что поиск в индексном файле может потребовать две или
три итерации (т.е. два или три обращения к диску) на каждую запись, к которой
осуществляется доступ. Именно здесь сетевая модель и "множества" RDM
могут привести к значительной экономии времени. Фактически такое
множество представляет собой связанный список, представляющий тип
отношений "один-ко-многим". Указатели к следующему и предыдущему
членам связывают каждый элемент данного множества. "Хозяин" множества
(т.е. "один" в отношении "один-ко-многим") указывает на каждый конец
связанного списка. Таким образом, переход от хозяина к первому члену требует
только одну операцию доступа к диску. Подобным образом осуществляется
переход к следующему члену и так далее. Каждый элемент множества обладает
указателем на своего хозяина, т.е. для перехода от него к хозяину также
требуется только одна операция доступа к диску.
Множество указателей относительно невелико – одно такое множество
использует то же или меньшее дисковое пространство, что и дублированные
данные вместе с индексным файлом, ассоциированным с реляционной связью.
Конечно, множества обладают им присущим порядком и поэтому полезны
только тогда, когда доступ к их элементам осуществляется в таком порядке.
Система RDM поддерживает как сетевые, так и реляционные модели,
позволяя разработчикам использовать любой из двух типов по отдельности.
Однако для настоящей производительности разработчики комбинируют
сетевые и реляционные модели при проектировании системы, использующей
RDM.
69
Например,
записи,
требующие
быстрый
беспорядочный
или
сортированный доступ, связаны через индекс, тогда как информация, которая
естественным образом может быть отнесена к таким типам отношений, как
"один-ко-многим",
"многие-к-одному"
и
рекурсивному,
разбивается
на
множества.
Чтобы увидеть преимущества в производительности, достигаемые за счет
прямого доступа к записям при использовании модели сетевых баз данных,
рассмотрим пример, использующий в типичной системе как реляционные, так и
сетевые модели.
Ниже рассматриваются вопросы, связанные с работой менеджера
ресурсов (Resource Manager) базы данных RDM Server.. Содержится
объяснение специальных функций Resource Manager, категорий API (таких как,
функции
управления
потоками
и
функции
организации
очередей)
и
предоставлен подробный пример, иллюстрирующий использование конкретных
функций Resource Manager.
Разработка многопотоковых приложений предполагает использование
функций операционных систем для управления потоками и обеспечения
межпотоковой
синхронизации
и
коммуникации.
Многие
современные
операционные системы поддерживают такие функции, но поскольку доступ к
ним зависит от конкретной платформы, нередко приходится сталкиваться со
значительными
трудностями
при
создании
сложных,
платформенно-
независимых многопотоковых прикладных программ. Если разрабатываемое
вами приложение не является платформенно-независимым, вы можете
свободно применять соответствующие функции вашей операционной системы.
Однако, если вы создаете приложение, масштабируемое для большого числа
различных платформ, вам следует воспользоваться интерфейсом Resource
Manager (RM) базы данных RDM Server. Многопотоковое ядро RDM Server
70
использует все функции интерфейса RM. Это гарантирует их надежность и
доступность для всех платформ, поддерживаемых RDM Server.
Resource Manager предоставляет платформенно-независимый интерфейс с
большим количеством функций, позволяющих решать такие сложные задачи
для операционных систем, как:
управление потоками;
управление параллельным выполнением;
организация очередей сообщений;
динамическое распределение памяти;
управление файлами.
Все функции RM предназначены для работы в однопроцессной среде
многопотоковых приложений.
Полный список функций интерфейса RM приводится в следующей таблице.
Таблица 2.2. – Список функций Resource Manager
Функция
rm_startup
rm_cleanup
rm_sleep
rm_log
rm_getenv
rm_interrupt
rm_threadBegin
rm_threadEnd
rm_syncCreate
rm_syncDelete
Класс
общего
назначения
общего
назначения
общего
назначения
общего
назначения
общего
назначения
общего
назначения
управления
потоками
управления
потоками
синхронизации
синхронизации
Описание
Запуск менеджера ресурсов.
Остановка и очистка менеджера ресурсов.
Приостановка потока на указанное число
миллисекунд.
Запись сообщения в журнал сообщений RDM
Server.
Получение строки описания среды операционной
системы.
Разрешение обработки прерываний работы
пользователей.
Начало выполнения нового потока.
Завершение выполнения потока.
Создание объекта синхронизации.
Удаление объекта синхронизации.
71
rm_syncEnterExcl
синхронизации
rm_syncExitExcl
синхронизации
rm_syncStart
синхронизации
rm_syncResume
синхронизации
rm_syncWait
синхронизации
rm_syncEnableQ
синхронизации
rm_syncDisableQ
синхронизации
rm_syncSendQ
синхронизации
rm_syncReceiveQ
синхронизации
rm_syncWaitQ
синхронизации
организации
очередей
организации
rm_queueDelete
очередей
организации
rm_queuePurge
очередей
организации
rm_queueWrite
очередей
организации
rm_queueRead
очередей
динамической
rm_createTag
памяти
динамической
rm_resetTag
памяти
динамической
rm_freeTagMemory
памяти
динамической
rm_getMemory
памяти
динамической
rm_cGetMemory
памяти
динамической
rm_freeMemory
памяти
динамической
rm_extendMemory
памяти
rm_queueCreate
Вход в участок программы с монопольным
доступом (семафор взаимного исключения).
Выход из участка программы с монопольным
доступом (семафор взаимного исключения).
Запуск события (установка семафора событий в
несигнальное (занятое) состояние).
Возобновление события (семафор событий в
сигнальном состоянии).
Ожидание события, которое должно возобновится
(сигнальное состояние).
Включение семафора взаимного ожидания
(допуск считывателей к общим данным).
Выключение семафора взаимного ожидания
(блокировка считывателей).
Отправка уведомления о завершении считывания
на семафор взаимного ожидания.
Получение уведомления о разрешении
считывания на семафоре взаимного ожидания.
Ожидание на семафоре взаимного ожидания
окончания работы всех считывателей.
Создание очереди сообщений.
Удаление очереди сообщений.
Удаление сообщений из очереди.
Запись сообщений в очередь.
Считывание сообщений из очереди.
Создание тэга динамически выделенной памяти.
Сброс буфера нелокального перехода указанного
тэга.
Освобождение всей памяти, выделенной для тэга.
Выделение блока памяти.
Выделение и очистка блока памяти.
Освобождение выделенного блока памяти.
Расширение (или перераспределение) блока
памяти.
72
динамической
памяти
динамической
rm_allocPool
памяти
динамической
rm_getFromPool
памяти
динамической
rm_putInPool
памяти
динамической
rm_zFreePool
памяти
управления
rm_fileOpen
файлами
управления
rm_fileClose
файлами
управления
rm_filePrintf
файлами
управления
rm_fileSeek
файлами
управления
rm_fileRead
файлами
управления
rm_fileWrite
файлами
управления
rm_fileSeekRead
файлами
управления
rm_fileSeekWrite
файлами
управления
rm_fileLength
файлами
управления
rm_fileSync
файлами
управления
rm_fileRemove
файлами
управления
rm_fileRename
файлами
управления
rm_fileTempName
файлами
rm_growMemory
Увеличение блока памяти (если необходимо).
Выделение пула памяти.
Получение буфера из пула.
Внесение буфера в пул.
Освобождение пула памяти.
Открытие/Создание файла.
Закрытие файла.
Запись в файл форматированного вывода.
Поиск абсолютной позиции в файле.
Считывание из файла.
Запись в файл.
Считывание от заданного места в файле.
Запись до заданного места в файле.
Определение текущей длины файла.
Сброс файла на диск.
Удаление файла (перемещение в другое место).
Переименование файла.
Создание уникального временного имени файла.
Использование функций RM общего назначения.
Для обеспечения платформенной независимости Resource Manager базы
данных RDM Server определяет некоторые встроенные типы данных и
73
константы. Типы данных используются для атрибутов объявления функций и
определений дескрипторов; константы для кодов возврата и управляющих
параметров функций. Определения дескрипторов и управляющих параметров
задаются в описаниях функций. Атрибуты объявления функций приводятся
ниже. Эти атрибуты указываются в объявлении функции между типом данных
и именем функции. Заметим, что объявления функций используются для
платформ, имеющих специальные архитектурные функции, которые не столько
требуют преимущества быстродействия, сколько сами предоставляют такие
преимущества при своем выполнении. Таким образом, мы инкапсулировали эти
платформенно-ориентированные объявления в платформенно-независимые
определения. Для многих платформ эти объявления фактически пусты.
Таблица 2.3. – Атрибуты функций Resource Manager
Атрибут
REXTERNAL
Описание
Задает общедоступную функцию в общей библиотеке (DLL).
Задает частную функцию пользователя, вызываемую из отдельной
RINTERNAL
общей библиотеки (DLL).
REXTVARARG Задает функцию формирования списков переменных аргументов.
Задает функцию управления потоками, которая будет вызвана
RTHREAD
функцией rm_threadBegin.
Список кодов состояния, возвращаемых функциями RM, приводится в
следующей таблице. Они объявлены как тип short. Заметим, что некоторые
функции RM возвращают значение -1 при неудачном выполнении и значение 0
(RM_OKAY) при успешном выполнении.
Таблица 2.4. – Коды возврата Resource Manager
Код возврата
RM_OKAY
Описание
Функция успешно выполнена.
74
Операция не может завершиться до истечения указанного
времени ожидания.
RM_QUEUE_EMPTY Нет сообщений в очереди.
Указан неверный путь к каталогу. Необходимо указать полное
RM_NOCATPATH
имя директории, содержащей каталог RDM Server. Возвращается
при выполнении функции rm_startup.
Недействительный каталог RDM Server. Либо неправильно
указано полное имя файла, либо требуемый файл не найден в
RM_INVCATALOG
указанном каталоге. Возвращается при выполнении функции
rm_startup.
RM_TIMEOUT
Интерфейс RM API предоставляет ряд функций общего назначения.
Функции rm_startup и rm_cleanup являются альтернативами функциям
s_startup и s_terminate. Если вы собираетесь использовать только функции
интерфейса RM API, игнорируя функции базы данных RDM Server (т.е. s_ , d_
или функции SQL), то следует иметь в виду, что вызов функции rm_startup
вместо s_startup требует меньше памяти и выполняется более быстро. Это
объясняется тем, что s_startup запускает управляющие потоки базы данных
RDM Server. В то время как функция rm_startup инициализирует только
подсистему базы данных Resource Manager. Функция rm_getenv извлекает
стандартные строки, описывающие среду операционной системы. Функция
rm_interrupt
предоставляет
доступ
к
обработке
прерываний
работы
пользователей. Функция rm_sleep позволяет приостановить поток на указанное
число миллисекунд.
Функции управления потоками
Поток представляет собой функцию, которая может быть выполнена
независимо из других потоков одного и того же родительского процесса.
Любой поток родительского процесса использует вместе с другими потоками
адресное пространство, глобальные переменные и ресурсы этого процесса.
Каждый процесс порождается одним потоком. Если основной поток
родительского процесса вызывает какую-либо функцию управления потоками,
75
то эта функция выполняется параллельно с основным потоком. Теоретически
может быть запущено любое число потоков, но на практике некоторые
платформы операционных систем ограничивают количество выполняемых
потоков. Слишком большое число потоков может отрицательно сказаться на
быстродействии операционной системы из-за потерь, которые она несет при
управлении и планировании потоков. Впрочем, эти потери могут значительно
различаться как для систем, базирующихся на архитектуре компьютера, так и
для конкретной операционной системы. Потоки дают значительный выигрыш в
быстродействии, если они выполняются в системах с симметричной
мультипроцессорной
архитектурой
(SMP),
использующих
более
двух
центральных процессоров.
С помощью интерфейса RM API базы данных RDM Server вы можете
вызвать функцию rm_threadBegin, которая инициализирует выполнение
потоков. Поток состоит из стандартной функции языка C типа void,
объявленной с атрибутом RTHREAD. Вызывая rm_threadBegin, вы можете
передать параметр указателя в эту функцию. Поток выполняется до тех пор,
пока он не закончит работу или не вызовет функцию rm_threadEnd.
Каждый поток имеет локальную память, которая выделяется из стека
процесса. Назначаемый потоку размер пространства стека задается параметром
функции rm_threadBegin. Используя константу THREAD_STACK, можно
задать системное значение по умолчанию.
Все потоки выполняются на одном из трех приоритетных уровней. Как
правило, потокам сеансов базы данных RDM Server (т.е., потокам,
выполняющим
функцию
s_login
)
должен
назначаться
приоритет
RM_THREAD_HIGH, как и тем потокам, для выполнения которых требуется
приоритет, не меньший чем у системных потоков RDM Server. Частое
использование приоритета RM_THREAD_HIGH может отрицательно сказаться
на системной производительности базы данных RDM Server.
76
Функции синхронизации
Несколько потоков не могут безопасно манипулировать глобальными
переменными одновременно. По крайней мере, один из двух потоков, которые
пытаются одновременно обновить одну и ту же глобальную переменную, не
сможет этого сделать. В худшем случае эта ситуация может привести к
фатальному сбою для некоторых систем. Чтобы обеспечить безопасное
обновление глобальных переменных несколькими потоками, необходимо
запустить один из трех видов синхронизации. Синхронизация взаимного
исключения упорядочивает обновления, выполняемые разными потоками. Это
означает, что эти обновления будут выполняться одно за другим в порядке
поступления
запросов.
Функции
rm_syncEnterExcl
и
rm_syncExitExcl
интерфейса RM обеспечивают выполнение синхронизации этого типа
посредством семафора взаимного исключения (mutex semaphore). Для защиты
глобальных данных можно создавать любое количество семафоров взаимного
исключения. Заметим, что доступ "только для чтения " к любой глобальной
переменной безопасен и не требует упорядочивания.
Два потока, обновляющих одни и те же общие данные, в некоторых
случаях можно синхронизировать с помощью семафоров событий. При
использовании семафора событий один из двух потоков получает доступ к
общим данным, обновляет их и сигнализирует другому потоку, находящемуся в
состоянии ожидания, о том, что он закончил свою работу. Для поддержки
семафора событий используются функции rm_syncStart, rm_syncResume и
rm_syncWait.
Для выполнения синхронизации между несколькими считывателями и
одним редактором, которые обращаются к общим данным, используется
семафор взаимного ожидания. Этот семафор, с одной стороны, не допускает
считывателей к общим данным во время их обновления редактором, а с другой,
77
не позволяет редактору выполнять обновление общих данных до тех пор, пока
все считыватели не прочитают эти данные.
Например, RDM Server использует семафоры взаимного ожидания для
управления процессом контрольных точек. (Функции модификации кэша базы
данных находятся в ожидании во время выполнения контрольной точки, и
наоборот, контрольная точка не выполняется, пока не завершатся все
запущенные функции модификации кэша.) Доступ к семафорам взаимного
ожидания
осуществляется
с
помощью
функций
rm_syncEnableQ,
rm_syncDisableQ, rm_syncSendQ, rm_syncReceiveQ и rm_syncWaitQ.
Вызывая
функцию
rm_syncCreate,
можно
создавать
любые
перечисленные выше семафоры. Семафоры освобождаются при вызове
функции rm_syncDelete.
Функции организации очередей
Часто возникают ситуации, когда требуется отправить в поток
необходимые данные. Функции организации очередей, предусмотренные в
интерфейсе RM API, предоставляют эту возможность. Все потоки могут
отправлять сообщения в другие потоки, независимо от их количества. Каждая
очередь сообщений имеет собственное имя и доступна через дескриптор этой
очереди. Функция rm_queueCreate присваивает очередям соответствующие
дескрипторы.
Вызвав функцию rm_queueWrite, вы можете поставить сообщение в
очередь. Сообщение состоит из указателя, размера блока, на который указывает
этот указатель, и идентификатора сообщения (типа long). Простой механизм
назначения приоритетов позволяет задавать сообщение, которое должно быть
поставлено в начало очереди. Обычно сообщения в очереди обрабатываются в
порядке поступления. Поток может прочитать следующее доступное в очереди
сообщение при вызове функции rm_queueRead. Эта функция позволяет
указать, сколько времени поток должен ожидать сообщения, которое должно
78
быть отправлено, если очередь пуста. По истечении времени ожидания
функция возвратит состояние RM_TIMEOUT. Если вы задали для времени
ожидания значение RM_INDEFINITE_WAIT, поток будет ожидать до тех пор,
пока следующее по времени сообщение не будет поставлено в очередь.
Функции динамической памяти
Resource Manager базы данных RDM Server содержит набор функций
распределения тегированной памяти, которые позволяют распределять память,
связанную
с
тэгами.
Для
создания
тэга
памяти
вызовите
функцию
rm_createTag. При вызове этой функции вы можете предусмотреть буфер
нелокального перехода (jump buffer) для функции setjmp. Если для созданного
тэга окажется недостаточно доступной памяти, управление будет передано в
этот буфер. Обычно в этом случае из функции верхнего уровня вызывается
стандартная функция setjmp языка C (когда вам требуется передать управление
этой функции, сохраняя состояние стека). При использовании буфера
нелокального перехода вам не требуется проверять каждый вызов функций
rm_getMemory, rm_cGetMemory, rm_extendMemory или rm_growMemory на
значение NULL. Вся связанная с тэгом память может быть освобождена
вызовом одной функции rm_freeTagMemory.
Можно также указать адрес функции, к которой будут обращаться
функции распределения памяти интерфейса RM в случае недостатка
выделяемой памяти. Эта функция, написанная вами, должна освобождать
достаточное количество памяти для удовлетворения запроса. Вы можете
использовать эту функцию обратного вызова для выполнения процедуры
"сборки мусора".
Кроме того, существует интерфейс пула памяти, который допускает
многократное использование буферов памяти с целью сокращения потерь,
связанных с большим количеством процедур динамического распределения и
освобождения памяти.
79
Функции управления файлами
Некоторые
операционные
системы
устанавливают
предел
на
максимальное число файлов, которые процесс может одновременно открыть.
Функции
управления
файлами,
предусмотренные
интерфейсом
RM,
отслеживают этот предел, чтобы динамически открывать и закрывать файлы
операционной системы, не выходя за его рамки.
Интерфейс
асинхронный
RM
также
предоставляет
ввод-вывод, позволяя
возможность
нескольким потокам
выполнять
одновременно
считывать или записывать информацию в один и тот же файл. Кроме того,
асинхронная запись в файл позволяет возвращать вызов записи до того, как эта
запись будет завершена.
Ниже приводится пример программы "fastdump", которая иллюстрирует
использование большинства функций Resource Manager. Эта программа
представляет собой утилиту многопоточного шестнадцатеричного дампа, в
которой используются только функции интерфейса Resource Manager API, т.е. в
ней не выполняются обращения к базе данных RDM Server. Программа
запускает до 9 потоков, отвечающих за выполнение дампа. Поток основного
процесса формирует очередь для отправки сообщений, запрашивающих дамп
каждого блока из входного файла в форматированный выходной файл. Каждый
поток считывает следующее по очереди сообщение, затем асинхронно
считывает соответствующий блок из входного файла, форматирует выходной
блок и асинхронно записывает этот отформатированный блок в выходной файл.
После отправки сообщения, которое запрашивает дамп последнего блока, поток
основного процесса посылает каждому потоку сообщение о завершении дампа.
По прочтении этого сообщения поток останавливается и сигнализирует о своем
завершении семафору событий, который информирует об этом поток основного
процесса. После того, как все потоки отправят сигнал о своем завершении,
программа прекращает работу.
80
Программа "fastdump" может быть выполнена с помощью следующей
командной строки:
fastdump [-b размер_блока] [-t число_потоков] входной_файл выходной_файл
-b размер_блока Задает размер блока входного файла, дамп которого выполняется всеми
потоками.
Если размер блока не кратен 512, то он будет усечен до размера кратного 512.
Значение по умолчанию – 4096.
-t число_потоков Задает число потоков, выполняющих дамп. Максимальное число потоков 9,
по умолчанию 3 потока.
Ниже приводится начальный код основной программы "fastdump", который
обрабатывает аргументы командной строки.
void main( int argc, char *argv[] )
{
int argi;
char *inFileName, *outFileName;
short *threadSems, tno, stat;
unsigned long filelen, pos;
jmp_buf noMoreMem;
DUMPMSG *pMsg;
/* process command line options */
for (argi = 1; argi < argc && argv[argi][0] == '-'; ++argi) {
char opt = argv[argi][1];
switch ( opt ) {
ase 'b': /* set size of input file block buffer */
if ( ++argi == argc ) usage();
buffSize = (size_t)atoi(argv[argi]);
if (buffSize % 512) {
/* make sure its a multiple of 512 */
buffSize = (buffSize/512)*512;
}
break;
case 't': /* set # of dump threads (max. of 9) */
if ( ++argi == argc ) usage();
maxThreads = (short)atoi(argv[argi]);
if (maxThreads >= 10)
maxThreads = 9;
break;
default:
usage();
}
}
if ( argi < argc - 1 ) {
81
/* fetch file names */
inFileName = argv[argi++];
outFileName = argv[argi];
}
else
usage();
Функция
usage
позволяет
вывести
на
печать
информацию
об
использовании программы и выйти из программы. Переменные buffSize и
maxThreads являются глобальными целочисленными переменными (типа size_t
и short, соответственно). Следующая часть основной программы запускает
Resource Manager.
/* startup RDM Server resource manager */
stat = rm_startup(NULL, MessageConsole, LOG_ERROR|LOG_WARN|LOG_INFO);
if ( stat != RM_OKAY ) {
printf("Unable to start up resource manager. Status = %d\n", stat);
exit(1);
}
Первый аргумент функции rm_startup указывает полный путь к
директории каталога RDM Server. В данном случае передается значение NULL,
которое позволяет извлечь путь к каталогу из переменной среды CATPATH.
Директория каталога содержит файл velocis.ini, из которого Resource Manager
извлекает информацию о своей конфигурации. Если переменная среды
CATPATH отсутствует, то функция rm_startup возвращает код ошибки
RM_NOCATPATH.
Второй аргумент функции rm_startup указывает адрес пользовательской
функции журнала сообщений RDM Server. Когда он задан, база данных RDM
Server вызывает указанную функцию, чтобы обработать все журнальные
сообщения, которые генерируются самой базой данных RDM Server или при
каждом вызове функции rm_log, исходящем из пользовательского приложения.
Третий аргумент состоит из битовой карты типов журнальных
сообщений. В данном случае в нем указаны только регистрируемые сообщения
типа errors (сообщения об ошибке), warnings (предупреждающие сообщения) и
82
information (информационные сообщения). Можно также включить и другие
типы сообщений, например, сообщения запуска RDM Server (LOG_STARTUP)
и сообщения регистрации пользователя (LOG_LOGIN).
Теперь приведем код функции MessageConsole.
/*
Log console messages
*/
void REXTERNAL MessageConsole(
RDSLOG_CTRL fcn, /* тип вызова: open, close, message */
RDSLOG_CTRL fcn, /* call type: open, close, message */
short type, /* message type */
char *msg) /* message to be logged */
{
if ( fcn == RDSLOG_MESSAGE ) {
switch ( type ) {
case LOG_ERROR: printf("***ERROR: "); break;
case LOG_WARN: printf("***WARINING: "); break;
}
printf("%s\n", msg);
}
}
Функция просто печатает сообщения об ошибке и предупреждающие
сообщения на консоли сервера. Следующий раздел основной программы
открывает входной и выходной файлы.
/* open files */
hInFile = rm_fileOpen(inFileName, O_RDONLY|O_BINARY, RM_SHARE, 0, 0);
hOutFile = rm_fileOpen(outFileName, O_CREAT|O_RDWR|O_BINARY,
RM_SHARE|RM_DIRECTIO, 0, 0);
if ( ! hInFile || !hOutFile ) {
printf("Unable to open files\n");
rm_cleanup();
exit(1);
}
Дескрипторы файлов hInFile и hOutFile являются глобальными
переменными
типа
RM_PFILE.
Они
используются
всеми
потоками,
выполняющими дамп. Оба файла открываются как совместно используемые
(RM_SHARED) двоичные (O_BINARY) файлы (не текстовые). Входной файл
доступен только для чтения (O_RDONLY). Выходной файл доступен для
83
чтения/записи (O_RDWR) (несмотря на то, что запись также применяется).
Если выходного файла нет, то он создается (O_CREAT). Кроме того, выходной
файл имеет флаг RM_DIRECTIO. Этот флаг указывает записи, которые должны
записываться прямо на диск.
Если
файлы
rm_fileOpen
по
какой-либо
возвращает
значение
причине
NULL,
нельзя
открыть,
предварительно
функция
регистрируя
сообщение, указывающее на эту причину. Следующий раздел основной
программы настраивает управление динамической памятью.
/* set up memory management */
if ( setjmp(noMoreMem) ) {
rm_log(LOG_ERROR, "FATAL EXIT: out of memory");
goto shutdown;
}
/* use C malloc function to allocate a reserve threshold amount */
threshold = malloc(2*buffSize);
/* allocate memory tag, RM_USESEM => multithread allocations are serialized */
mTag = rm_createTag("fastdump", 0, noMoreMem, FreeReserve, 0, RM_USESEM);
/* allocate pool for queue messages */
qPool = rm_allocPool(mTag, "qPool");
Заметим, что объявления локальных переменных, которые были ранее
продемонстрированы
для
основной программы, включают переменную
noMoreMem, объявленную как тип jmp_buf (объявление исходит из #include
<jmpbuf.h> под #include rds.h). Вызов стандартной функции setjmp языка С
сохраняет в noMoreMem информацию о месте возвращения, передавая ее в
функцию rm_createTag. Таким образом, если какой-либо вызов функции
распределения памяти, связанный с mTag, не проходит из-за недостатка
памяти, то будет выполняться функция longjmp для указанного jmp_buf. В
результате, функция setjmp возвратит ненулевое значение с вызовом функции
rm_log для сообщения о недостатке памяти, за которым последует остановка
программы. Threshold является глобальным указателем на объект неизвестного
типа
(global
void
pointer),
который
используется
для
получения
зарезервированного фрагмента памяти (в данном случае, равного двум блокам).
84
Функция FreeReserve освобождает этот фрагмент, если при запросе о
выделении памяти для тега mTag не будет найдено достаточного количества
памяти. После освобождения этого буфера любые последующие обращения к
FreeReserve не добавляют свободной памяти, а приводят к передаче
управления к функции setjmp.
Вызов функции rm_createTag содержит флаг RM_USESEM. Он
необходим, поскольку позволяет упорядочить вызовы на выделение памяти для
тега
mTag,
поступающие
сразу
от
нескольких
потоков.
Если
флаг
RM_USESEM не будет указан, то эти вызовы могут привести (и, скорее всего,
приведут) к повреждению структуры данных распределяемой памяти, что
чревато нарушением общей защиты или даже бесконечным циклом. В любом
случае, вам следует заранее определить, какие потоки будут выполнять
извлечение и распределение памяти из каждого тега памяти. Если вы уверены,
что все операции по выделению памяти для данного тега будут выполняться из
одного и того же потока, то для этого флага можно указать значение
RM_NOSEM. Это ускорит распределение памяти.
Если существует вероятность того, что выделение памяти для отдельного
тега будет выполняться из нескольких потоков, следует использовать флаг
RM_USESEM (т.е. указать на необходимость семафора взаимного исключения
для защиты доступа к структурам данных распределяемой памяти для этого
тега).
Большинство операций, связанных с распределением памяти, включают
размещение и освобождение сообщений с запросами на дамп, которые
посылаются из основного потока во все потоки, выполняющие дамп входного
файла. Программа "fastdump" предусматривает использование пула памяти во
избежание
потерь,
связанных
с
большим
количеством
операций
по
распределению и освобождению одинаковых по размеру блоков. Поставленные
в очередь новые сообщения извлекаются из этого пула и распределяются между
85
потоками, которые их обрабатывают. Затем, по завершении обработки, эти
сообщения возвращаются обратно в пул. Вызов функции rm_allocPool
выделяет дескриптор пула qPool. Первый аргумент этого дескриптора
указывает на тег, в котором qPool будет выполнять операции по выделению и
размещению памяти. Второй аргумент указывает имя семафора, созданного
функцией rm_allocPool и используемого для упорядочивания обращений к
пулу. Этот семафор имеет точно такое же назначение, что и другие описанные
выше семафоры, предназначенные для многопотоковых распределений памяти.
Он здесь необходим, поскольку функции пула будут вызываться сразу из
нескольких потоков.
Теперь приведем код функции FreeReserve. Заметим, что аргументы этой
функции включают не только тег памяти, но и запрашиваемый размер памяти.
/*
Insufficient memory reserve function
*/
void REXTERNAL FreeReserve(
RM_MEMTAG tag,
size_t size)
{
if ( threshold && size <= 2*buffSize ) {
/* free reserve if it has sufficient space */
free(threshold);
threshold = NULL; /* печать уведомляющего сообщения */
rm_log(LOG_WARN, "running low on memory");
}
}
После настройки управления динамической памятью основная программа
создает очередь сообщений и глобальный семафор взаимного исключения,
выделяет массив для семафоров завершающего события для каждого потока, и
86
затем запускает эти потоки, чтобы выполнить дампа входного файла. Все эти
операции выполняет следующий сегмент программы.
/* Create message queue for sending dump instructions to threads */
dumpQueue = rm_queueCreate("dumpQueue");
/* A global variable, blockCount, will be updated by the threads.
This mutex semaphore will be used to synchronize access to it.
*/
countSem = rm_syncCreate("countSem", RM_MUTEX_SEM, RM_EXCLUSIVE);
/* allocate array of event semaphores, 1 per thread */
threadSems = rm_getMemory(maxThreads*sizeof(short), mTag);
rm_log(LOG_INFO, "Launching %d dump threads", maxThreads);
for ( tno = 0; tno < maxThreads; ++tno ) {
threadSems[tno] = rm_syncCreate("doneSem", RM_EVENT_SEM, RM_EXCLUSIVE);
rm_syncStart(threadSems[tno]);
rm_threadBegin(DumpThread, THREAD_STACK, &threadSems[tno], RM_THREAD_HIGH);
}
Очередь dumpQueue используется для отправки сообщений из основного
потока в потоки, выполняющие дамп. Семафор взаимного исключения
countSem упорядочивает доступ к глобальной переменной blockCount типа long
для ее обновления. Эта переменная увеличивается после выполнения потоками
каждого
запроса
на
дамп.
Приведенный
выше
сегмент
программы
иллюстрирует способ использования семафоров взаимного исключения для
защиты доступа к глобальным данным.
Массив threadSems содержит для каждого потока один семафор
событий. Эти семафоры создаются циклом for, который и запускает потоки.
Вызов функции rm_syncStart устанавливает семафор событий в несигнальное
состояние, которое приостанавливает все последующие вызовы функции
rm_syncWait для этого семафора, пока какой-либо другой поток или несколько
потоков
не
вызовут
функцию
rm_syncResume.
Вызов
функции
rm_threadBegin инициализирует выполнение указанной функции управления
потоками. Второй аргумент задает размер пространства стека, выделяемого для
этой функции. Константа THREAD_STACK является размером стека RDM
Server по умолчанию. Стек должен вмещать аргументы и локальные
переменные не только указанной функции управления потоками, но и всех
87
функций, которые будут из нее вызываться. Если вы не определили размер
стека, вам лучше всего использовать значение по умолчанию THREAD_STACK
(размер этого значения определяется максимальной глубиной вызовов RDM
Server). Третий аргумент функции rm_threadBegin является переменнойуказателем, который передается как аргумент функции управления потоками.
Вы можете задать его по своему выбору. В данном случае, мы передаем адрес
семафора
завершающего
события.
Последний
аргумент
функции
rm_threadBegin задает приоритет потока. В данном примере мы выбрали
приоритет RM_THREAD_HIGH, поскольку эта программа использует только
функции
Resource
Manager.
(Также
можно
выбрать
значения
RM_THREAD_LOW и RM_THREAD_NORMAL.) Для приложений, которые
будут регистрироваться и обращаться к базе данных RDM Server, этот параметр
должен устанавливать приоритет NORMAL или LOW.
После запуска потоков, отвечающих за выполнение дампа, основная
программа начинает отправлять этим потокам сообщения с запросами на дамп,
используя очередь dumpQueue. Следующий код выполняет разбиение дампа,
создавая и настраивая сообщения с запросами на дамп, и затем вызывает
функцию rm_queueWrite, организуя очередь из этих сообщений.
/* get length of file */
filelen = rm_fileLength(hInFile);
/* send dump messages to threads */
for (pos = 0; filelen > 0; pos += buffSize) {
pMsg = rm_getFromPool(sizeof(DUMPMSG), qPool);
pMsg->startpos = pos;
pMsg->blocklen = filelen >= buffSize ? buffSize : filelen;
rm_queueWrite(dumpQueue, pMsg, sizeof(DUMPMSG), 0, 0);
filelen -= buffSize;
}
Функция rm_fileLength возвращает размер входного файла в байтах,
сохраняя его в локальной переменной filelen типа unsigned long (длинное целое
без знака). Эта переменная используется для управления циклом for, который
разбивает входной файл на сообщения с запросами на дамп, длиной buffSize
88
(возможно, кроме последнего сообщения). Объявление типа DUMPMSG
выполняется следующим образом.
typedef struct dumpmsg {
unsigned long startpos; /* byte offset from start of file */
size_t blocklen; /* length of block (= buffSize, 0 = end) */
} DUMPMSG;
Сначала из пула выделяется буфер сообщения. Затем при вызове
функции rm_queueWrite это сообщение ставится в очередь dumpQueue. Три
первых аргумента этой функции не требуют объяснений. Четвертый аргумент
является значением типа длинное целое, которое может использоваться в
качестве идентификатора сообщения. В данной программе этот аргумент
используется как логический флаг, который имеет значение TRUE (или 1)
после отправки последнего сообщения. Последний аргумент – булевый. Он
указывает, что данное сообщение является приоритетным и, следовательно,
должно быть поставлено в начало очереди. В этом примере, все сообщения
имеют приоритет NORMAL и ставятся в очередь в порядке поступления.
С этого момента мы оставляем основную программу и переходим к
рассмотрению функции управления потоками.
/*
Dump thread - dumps 1 block at a time
*/
static void RTHREAD DumpThread(void *pDoneSem)
{
short doneSem;
char *inBuff;
char *outBuff;
unsigned int len;
DUMPMSG *pMsg = NULL;
long end_of_dump = 0;
/* end-of -dump event semaphore is thread argument */
doneSem = *(short *)pDoneSem;
/* allocate input buffer for 1 dump block */
inBuff = rm_getMemory(buffSize, mTag);
/* allocate output buffer for each formatted dump line */
outBuff = rm_getMemory(77*(buffSize/16)+1, mTag);
while ( ! end_of_dump ) {
rm_queueRead( dumpQueue, &pMsg, NULL, &end_of_dump, RM_INDEFINITE_WAIT );
if ( pMsg ) {
89
/* read block to be dumped */
len = rm_fileSeekRead(hInFile, pMsg->startpos, inBuff, pMsg->blocklen);
if ( len != pMsg->blocklen )
rm_log(LOG_ERROR, "error reading input file");
else
DumpBlock(inBuff, pMsg->startpos, pMsg->blocklen, outBuff);
/* update count of dumped blocks */
rm_syncEnterExcl(countSem);
++blockCount;
rm_syncExitExcl(countSem);
/* free queue message */
rm_putInPool(pMsg, qPool);
}
}
/* signal foreground that we're done */
rm_syncResume(doneSem);
/* terminate thread */
rm_threadEnd();
}
Как говорилось выше, аргумент функции управления потоками является
указателем на семафор завершающего события и извлекается в переменную
doneSem. Каждый поток должен иметь свой входной буфер inBuff. Вызов
функции rm_getMemory выделяет определенное количество байтов buffSize в
этом
буфере.
Для
каждого
входного
блока
форматированный
вывод
записывается в один выходной буфер outBuff, который затем при однократном
вызове записи записывается в выходной файл. Каждая форматированная
выходная строка состоит из 16 байтов дампа входного блока. Все такие строки
имеют длину, равную 77 символам.
Основное
завершается,
тело
когда
потока
флаг
выполняется
end_of_dump,
внутри
цикла
возвращаемый
while.
Цикл
функцией
rm_queueRead, имеет значение TRUE. Аргументы функции rm_queueRead
достаточно просты. Последний аргумент указывает, сколько времени (в
миллисекундах) поток ожидает сообщение, которое будет записано в очередь.
В
данном
случае
поток
(RM_INDEFINITE_WAIT).
ожидает
сообщение
неограниченное
время
90
Если аргумент ожидания имеет значение 0, то функция либо возвратит
значение RM_OKAY и доставит сообщение, либо возвратит значение
RM_QUEUE_EMPTY, которое указывает на отсутствие сообщений в очереди.
озвращаемый указатель сообщения содержится в pMsg. Значение NULL
для pMsg отправляется с последним сообщением (флаг end_of_dump равен 1).
Вызов функции rm_fileSeekRead запускает считывание в inBuff входного
блока, на который указывает последнее сообщение. Функция rm_fileSeekRead
возвращает фактическое число прочитанных байтов. Если это значение (len) не
равно запрошенному числу байтов, значит произошла ошибка (или вы
пытаетесь выполнить считывание за меткой конца файла, что в данном случае
невозможно). После успешно завершенного считывания вызывается функция
DumpBlock для форматирования входного блока в выходной буфер.
Переменная blockCount представляет собой глобальную переменную
типа long, которая используется для подсчета блоков с выполненными
дампами. Процесс обновления этой переменной требует упорядочивания,
поскольку она обновляется сразу несколькими потоками. Когда поток,
обновляющий эту переменную, ждет своей очереди к семафору взаимного
исключения, вызываемая им функция rm_syncEnterExcl приостанавливается.
После того, как он получит управление над семафором взаимного исключения,
функция rm_syncEnterExcl выполняется и поток безопасно обновляет
переменную blockCount. При этом все остальные потоки, обращающиеся к
функции rm_syncEnterExcl для обновления переменной countSem, ставятся в
очередь. Когда управляющий поток, вызывая функцию rm_syncExitExcl,
освобождает
семафор
взаимного
исключения,
управление
передается
следующему потоку, стоящему первым в очереди. Освободив семафор
взаимного исключения, поток вызывает функцию rm_putInPool, чтобы
возвратить буфер сообщения в пул памяти.
91
После получения сообщения о завершении дампа из основного
(высокоприоритетного) потока цикл прерывается, и поток вызывает функцию
rm_syncResume, которая устанавливает семафор завершающего события для
этого потока в сигнальное состояние. Обычно этот семафор остается в
сигнальном состоянии до своего перезапуска, который происходит в результате
вызова функции rm_syncStart. Это означает, что до тех пор пока он находится
в сигнальном состоянии, любые вызовы функции rm_syncWait для этого
семафора будут немедленно возвращаться.
Для завершения потока вызывается функция rm_threadEnd. Заметим,
что при выполнении этой функции поток автоматически завершается. Но
поскольку некоторые новые платформы RDM Server могут потребовать вызова
специальной функции, завершать поток следует этим вызовом.
Теперь возвратимся к основной программе. Приведенный ниже сегмент
программы иллюстрирует, как основная программа посылает потокам
сообщение о завершении дампа. Не имеет значения, какому потоку поступает
то или иное сообщение, поскольку после получения сообщения о завершении
дампа поток не будет обрабатывать никаких дополнительных сообщений.
/* send terminate thread messages */
for (tno = 0; tno < maxThreads; ++tno)
rm_queueWrite(dumpQueue, NULL, 0, 1, 0);
/* wait for each thread to signal they're done */
for (tno = 0; tno < maxThreads; ++tno)
rm_syncWait(threadSems[tno], RM_INDEFINITE_WAIT);
rm_log(LOG_INFO, "Dump complete: %ld %d-byte blocks written to file %s.",
blockCount, buffSize, outFileName);
После отправки сообщений о завершении дампа программа выполняет
цикл по всем элементам массива семафора завершающего события и вызывает
rm_syncWait, ожидая завершения всех потоков. Затем, она вызывает функцию
rm_log, чтобы зарегистрировать завершение дампа и сообщить общее число
записанных
блоков.
Функция
rm_log
аналогична
функции
printf,
за
92
исключением первого аргумента, который указывает тип сообщения. Второй
аргумент – спецификатор формата printf, за которым следует 0 или несколько
переменных, перечисленных в этом спецификаторе. В данном случае это
сообщение будет обрабатывать функция MessageConsole, которая была задана
при вызове функции rm_startup.
Последняя часть программы закрывает файлы и освобождает все
используемые ресурсы Resource Manager.
/* close files */
rm_fileClose(hInFile);
rm_fileClose(hOutFile);
/* delete the queue */
rm_queueDelete(dumpQueue);
/* free the message pool */
rm_zFreePool(&qPool);
/* free semaphores */
rm_syncDelete(countSem);
for (tno = 0; tno < maxThreads; ++tno)
rm_syncDelete(threadSems[tno]);
/* free allocated memory */
rm_freeTagMemory(mTag, 1);
if ( threshold )
free(threshold);
rm_cleanup();
Второй аргумент функции rm_freeTagMemory является флагом, который
указывает на то, будет ли этот тег освобождаться. Поскольку тег можно
многократно использовать, его освобождение не всегда требуется. Тег
многократно используется, когда при однократном выполнении какой-либо
функции выделяется и освобождается вся память. В этом случае, поскольку тег
уже существует, требуется указать способ задания нового буфера нелокального
перехода, который необходим при недостатке памяти. Это можно сделать,
вызвав функцию rm_resetTag.
Этот тестовый пример наглядно показывает, как можно использовать
большинство функции Resource Manager, которые необходимы для создания
93
сложных прикладных программ или дополнительных модулей для сервера базы
данных RDM Server.
Эта тестовая программа позволила проверить основные характеристики и
преимущества использования RDM. Позволила сделать и получить идеи по
проектированию алгоритма работы программного обеспечения «гаммафона».
На стадии разработки алгоритма и структуры программного обеспечения
был проведен анализ и исследованы возможности СУБД RDM c целью
использования в качестве среды разработки программного обеспечения
«гаммафона».
Принципы и архитектура СУБД RDM наилучшим образом подходит для
создания подсистемы архивирования и промежуточного хранения информации
на борту.
Опираясь
на вышеприведенные
возможности СУБД RDM и
полученные результаты при тестировании, можно утверждать что СУБД RDM
наилучшим образом подходит для разработки
программного обеспечения
«гаммафона».
Так же были проработаны основные принципы передачи данных в среду
MATLAB,
для последующей
обработки и представления данных.
Эти
результаты могут быть использованы в дальнейшем для построения “off-line”
системы обработки на Земле
Структуру программного обеспечения можно представить следующей
блок-схемой изображенной на рис. 2.7.
94
СУБД RDM
Драйвер
котроллера
MIL 1553
Многопоточное
приложение передачи
данных на Землю
Драйвер
USB порта
Драйвер
USB порта
Драйвер
USB порта
Драйвер
USB порта
Драйвер
USB порта
Многопоточные
приложения для
формирования
кадров данных
Поток данных с ПЧД1
Поток данных с ПЧД1
Многопоточное
приложение
Обеспечивающее
прием и запись
структуры типа
“event” со всех
детекторов в
многомерный
массив
Многомерный
массив
мгновенных
значений
Драйвер
USB порта
Многопоточные
приложения
оперативного
анализа и
выработки
тригеррных
событий
Многомерный
массив
архивных
данных на
Flesh диске
Драйвер
USB порта
Драйвер
USB порта
Рис. 2.7. Блок-схема структуры программного обеспечения.
При регистрации события (приход гамма - кванта или частицы) мы
имеем структуру «сырых» данных следующего состава:
5 бит – «энергия гамма»»
14 бит – «код кристалла»
3 бита – «тип события»
12 бит – «код АЦПБ»
12 бит – «код АЦПМ».
Надо отметить, что эта структура обозначем ее “event” является исходной
информацией для формирования всех остальных видов и типов информации
для дальнейшей обработки на Земле в режиме «off-line». Данные полученные с
ПЧД и широкоугольных камер непрерывно поступают в буфер ОЗУ
процессора, функционально этот буфер и есть RDM Server. Все остальные
приложения являются клиентами и получают неободимые данные для
формирования необходимых структур данных.
95
Программное обеспечение «гаммафона» должно обеспечивать сбор,
накопление и передачу на Землю следующих видов информации:
Кадр «Мониторинг» (1 раз в секунду);
Кадр «Спектр» (1 раз в минуту);
Кадр «Карта» (1 раз в 12 секунд);
Кадр «Быстрый всплеск»;
Кадр «Медленный всплеск»;
Кадр «Яркий оптический транзиент»;
Кадр «Слабый оптический транзиент».
Программное обеспечение
будет спроектировано и реализовано таким
образом, что бы формировать весь объем информации одновременно в режиме
реального времени, постоянно
анализируя информацию, поступающую с
блоков ПЧД согласно алгоритмам для каждого вида кадров. Детально
алгоритмы
будут разработаны на стадии создания макетного образца и
разработаны виде отдельных задач и приложений для RDM.
В условиях жёсткого ограничения на объём передаваемой информации
должен
быть реализован алгоритм
анализа последовательности кадров с
широкоугольных оптических камер, выделяя информацию, относящуюся
только к неподвижным вспыхивающим источникам. Для этого должен
создаваться архив на
бортовой
памяти, способный хранить покадровую
информацию с каждой из камер в течение >10секунд.
Критерии обнаружения неподвижного вспыхивающего источника (так
называемого оптического транзиента)
так же будут проработаны на этапе
макетирования.
Использование многопоточности и других возможностей RDM, которые
были описаны выше и полученные результаты проведенных тестов, позволяют
сделать вывод, что использование
СУБД RDM наиболее целесообразно в
96
качестве
среды
разработки
архивирования данных на борту.
программного
обеспечения
для
сбора
и
97
Гл.3. Технологические и программные средства, обеспечивающие
локализацию гамма-квантов в широкоапертурном гаммателескопе.
§3.1. Метод кодированной апертуры в широкоапертурном гамма-телескопе.
Как
было
широкоапертурном
отмечено
выше,
гамма-телескопе
для
локализации
использется
гамма-квантов
метод
в
кодированной
апертуры, основанный на сочетании кодирующей маски и позиционночувствительного детектора (ПЧД). При этом используется конфигурация
прибора в виде моноблока, имеющего форму додекаэдра, по верхним граням
которого расположены элементы кодирующей маски, а по нижним – блоки
ПЧД.
Таким образом, сегмент кодирующей маски широкоапертурного гаммателескопа
имеет
форму
правильного
пятиугольника.
Его
размеры
соответствуют размерам грани несущей крепежной фермы моноблока.
Толщина сегмента маски определяется требованием достаточно эффективного
поглощения гамма-излучения в рабочем диапазоне энергий – вплоть до 1.0
МэВ. Эскиз габаритного чертежа сегмента кодирующей маски приведен на рис.
3.1.
Был проведен анализ материалов, обеспечивающих поглощение гаммаизлучения с энергиями квантов в диапазоне 0.05 – 1.0 МэВ. В качестве
возможных материалов рассматривались свинец, вольфрам, тантал, рутений,
осьмий. С точки зрения технологии изготовления поглощающих элементов
кодирующей маски и стоимости материалов в качестве наиболее подходящих
были выбраны свинец, вольфрам и тантал. Их физические характеристики,
определяющие поглощающую способность представлены в табл. 3.1. В плане
поглощения гамма-квантов определяющими параметрами являются плотность
98
материала и его порядковый номер в периодической таблице элементов
Менделеева Z.
Таблица 3.1.
ρ, г/см3
z
μ, см2/г,
50 кэВ
μ, 1
100 кэВ
μ,
200 кэВ
μ,
500 кэВ
μ,
1 МэВ
Pb
11,37
82
>1
>1
0,9
0,14
0,069
W
19,3
74
>1
>1
0.8
0,119
0,066
Tа
16,6
73
>1
>1
0,7
0,107
0,065
Рис. 3.1. Габаритный чертеж сегмента кодирующей маски НА «Гаммаскоп».
99
Рис. 3.2. Эскиз габаритного чертежа сегмента кодирующей маски НА
«Гаммаскоп».
Как следует из таблицы, выбранные материалы обладают приблизительно
одинаковой поглощающей способностью к гамма-излучению. Однако, тантал и
вольфрам характеризуются большей плотностью по сравнению со свинцом, что
позволяет использовать более тонкие слои вещества при обеспечении заданной
эффективности поглощения. Кроме того, следует учитывать более высокую
технологичность тантала и вольфрама, как более твердых веществ. Таким
образом, ввиду более высокой плотности и технологичности в качестве
предпочтительного материала для изготовления поглощающих элементов
кодирующей маски следует выбрать вольфрам или тантал. При этом сегмент
100
кодирующей маски может быть изготовле меньшей толщины и будет обладать
большей жесткостью, что делает его более удобным для крепления.
Поглощение гамма-квантов с более чем 90% эффективностью в указанном
диапазоне энергий обеспечивает слой вольфрама или тантала толщиной 0.5 см.
Эскиз габаритного чертежа сегмента кодирующей маски приведен на рис.
3.2. Как видно из рисунка, сегмент кодирующей маски представляет собой
пятиугольную плиту с крепежными отверстиями диаметром 0.65 см по углам
пятиугольника и отверстиями диаметром Таким образом поглощающие
элементы кодирующей маски должны представлять собой отверстия размером
1.50.5 см по всему полю плиты. Эти отверстия образуют, так называемый
узор кодирующей маски, который собственно и дает проекцию изображения
источника на плоскость ПЧД.
Ранее [1] был рассмотрен вариант кодирующей маски с использованием
вольфрама в качестве поглощающего вещества. Ввиду невозможности
изготовить вольфрамовую пластину требуемых размеров (см. рис.3.2)
рассматривалась, так называемая антимаска, в которой кодирующий узор
формируется не отверстиями, а наоборот поглощающим веществом. В этом
случае сегмент кодирующей маски представлял собой пластину из легкого
вещества, максимально прозрачного для гамма-излучения (рассматривался
алюминиево-скандиевый сплав), в который были вкраплены вольфрамовые
шайбы соответствующих размеров (1.50.5 см). Следует отметить, что такая
компоновка вызвала определенные трудности, связанные, как со сложностью
надежного крепления вольфрамовых шайб, так и с существенным поглощением
в материале пластины гамма-квантов с энергиями менее 50 кэВ, что в случае
использования такой «антимаски» приведет к увеличению энергетического
порога регистрируемых фотонов.
В
результате
проведенного
анализа
результатов
испытаний
и
калибровочных измерений поглощения гамма-квантов с макетом сегмента
101
кодирующей маски на основе вольфрама в качестве поглощающего вещества,
было принято решение оптимизировать технологию изготовления элмента
кодирующей
маски
широкоапертурного
гамма-телескопа,
рассмотрев в
качестве поглощающего материала тантал.
§3.2. Оптимизация технологии изготовления элементов кодирующей маски
широкоапертурного гамма-телескопа.
Среди других элементов тантал занимает 54-е место, что характеризует
его как редкий металл. В природе почти всегда встречается вместе с ниобием.
Тантал (как и ниобий) входит в состав около 100 минералов, основными из
которых являются танталит и колумбит.
Танталит и колумбит почта всегда содержат примеси титана, олова,
вольфрама и ряда других элементов. Плотность минералов сильно зависит от
соотношения содержания в них тантала и ниобия. Плотность танталита 8,200
Мг/м3. Колумбит, не содержащий тантала, имеет плотность 5,000 Мг/м3. По
соотношению этнх величин можно ориентировочно определять содержание в
минерале тантала в ниобия.
Основным способом обогащения руд, содержащих танталит и колумбит,
является гравитационное обогащение (мокрая отсадка, обогащение на столах).
В результате получают обычно коллективный концентрат, содержащий, кроме
танталита и колумбита, касситерит, вольфрамит и некоторые другие минералы.
Дальнейшее обогащение ведут, применяя флотацию и электромагнитное
разделение.
По техническим условиям, принятым в нашей стране, танталитовые
концентраты 1 сорта должны содержать 60-65% Та2О5 и не более 10% Nb2O5, 2
сорта – не менее 40% Та2О5.
102
Кроме рудных концентратов, существенным источником тантала (и
ниобия) служат шлаки оловянных заводов, получаемые при выплавке олова из
касситеритовых концентратов. Шлаки содержат от 3 до 15% (Та, Nb)205.
Переработку концентратов обычно осуществляют в три стадии: 1)
вскрытие или разложение; 2) разделение тантала в ниобия в получение их
чистых химических соединений; 3) восстановление и рафинирование тантала.
Для вскрытия танталового концентрата применяют сплавление со
щелочами (NaOH, КОН) или разложение плавиковой кислотой.
В первом способе в результате плавления концентрата при 750-8000С с
избытком щелочи образуются ортосоль (Na3TaO4) и оксиды железа, марганца.
После обработки сплава водой образуются малорастворимые политанталиты
(Na8Ta6O19.25Н20),
которые
разлагают
соляной
кислотой,
получая
гидратированные оксиды тантала, которые затем перерабатывают на чистые
соединения.
Разложение плавиковой кислотой в настоящее время является основным
способом; в этом случае тонко измельченный танталитовый концентрат при
нагревании разлагают концентрированной плавиковой кислотой.
Лопаритовые концентраты перерабатывают, используя два способа —
хлорирование н сернокислотный. Сущность первого состоит во взаимодействии
рудного концентрата с газообразным хлором при 749-8500С в присутствии
древесного угля или кокса. Различие в летучесть хлоридов позволяет разделить
основные ценные составляющие концентрата. Сернокислотный способ основан
на разложении лопаритового концентрата серной кислотой и разделении
ценных составляющих с использованием различий в растворимости двойных
сульфатов титана, ниобия и тантала, редкоземельных элементов со щелочными
металлами или аммонием.
103
Разделение тантала я ниобия из-за сходства свойств их химических
соединений является сложной задачей:
Известны следующие способы разделения тантала и ниобия: дробная
кристаллизация комплексных фтористых солей, экстракция органическими
растворителями, разделение с помощью ионнообменных смол, ректификация
хлоридов, избирательное восстановление пятихлористого ниобия.
Способ дробной кристаллизации в настоящее время вытеснен более
совершенным — экстракцией. Экстракционное разделение тантала и ниобия с
одновременной их очисткой от примесей других элементов (Si, Ti, Fe, Мn н др.)
большей частью ведут из растворов фтористых соединений тантала и ниобия,
содержащих плавиковую и серную кислоты (растворы получают в результате
разложения рудных концентратов).
Экстракционное разделение тантала и ниобия состоит из трех стадий: 1)
совместной экстракции тантала и ниобия с целью отделения их от
сопутствующих элементов (Fe, Мn, Ti, Sn, Si и др.): 2) избирательной
реэкстракции ниобия из экстракта водой; 3) реэкстракции тантала из
растворителя водой или водными растворами солей, например фтористого
аммония.
Разделение тантала и ниобия ректификацией целесообразно использовать
в том случае, когда рудные концентраты перерабатывают хлорным методом,
получая конденсат хлоридов тантала и ниобия (лопаритовые концентраты).
При разделении смеси хлоридов технологическая схема разделения
состоит из следующих стадий: 1) предварительной ректификации для
отделения хлоридов тантала и ниобия от сопутствующих примесей; 2)
основной ректификации (получения чистого NbCl5 и концентрата ТаСl5; 3)
ректификации танталовой фракции (получение чистого TaCl5.
Метод ректификации отличается высокой производительностью и
эффективностью разделения.
104
Металлический тантал получают восстановлением его соединений
высокой чистоты. Применяют восстановление тантала из Та205 сажей в одну
или две стадии (с предварительным получением ТаС из смеси Та2О5 с сажей в
атмосфере СО или Н2 при 1800 — 20000С) — карботермический способ.
Электрохимическое восстановление из расплава, содержащего фторотанталат
калия K2TaF7 и оксид Та2О5 — электролитической способ. Восстановление
натрием K2TaF7 при нагревании — натриетермический способ. Возможны
такие процессы термической диссоциации хлорида или восстановление из него
тантала водородом. Обычно получают металл в виде танталового порошка
чистотой 98 — 99 %.
Получение металла в компактном виде осуществляют путем спекания
предварительно спрессованных из порошка заготовок прямым пропусканием
тока при 2500 — 27000С или косвенным нагреванием при 2200 — 25000С в
вакууме. При этом чистота металла повышается до 99,9 — 99,95 %. Для
получения
больших
слитков
и
для
рафинированно
применяют
электровакуумную плавку в дуговых печах с расходуемым электродом и в
электронно-лучевых
печах.
В
процессе
вакуумного
переплава
общее
содержание кислорода, азота я углерода снижается от 0,1 — 0,5 до 0.01 —
0,05%.
Особо
чистый
компактный
тантал
(монокристаллы)
получают
бестигельной электронно-лучевой зонной плавкой.
Первичный
танталовый
порошок,
получаемый
в
результате
натриетермического восстановления в применяемый для изготовления твердых
сплавов, должен иметь следующий химический состав, %: ~99.0 Х (Ta+Nb). в
том числе <0.5Nb; <0,08Fe; <0,06Si; <0,03Ti; <0,2С. Порошок комплектуют в
партии массой до 100 кг в упаковывают в пластиковые мешки.
Физические свойства тантала [2].
105
Атомные характеристики. Атомный номер 73, атомная масса 180,948,
атомный объем 10,88*10-6 м3/моль, атомный радиус 0,146нм, ионный радиус
Та5+ 0,066 нм, Та4+ 0,077 нм, Та2+ 0,088 нм. Конфигурация внешних
электронных оболочек 5d36s2. Значения потенциалов ионизации J (эВ): 7,7;
16,2; 22. Электроотрицательность 1,5. Природный тантал состоит из
стабильного изотопа
181
Та (99,9877 %) и радиоактивного
180
Та (0,0123%) с
периодом полураспада 1012 лет. Известны 15 радиоактивных изотопов тантала,
указанные в табл. 3.2.
Таблица 3.2.
Массовое
Период
Массовое
Период
Массовое
Период
число
полураспада
число
полураспада
число
полураспада
172
44 мин
177
56,6 ч
182 m*
16,5 мин
173
3,7 ч
178
9,35 мин
183
5,0 дн
174
1,2 ч
179
600 дн
184
8,7 ч
175
10,5 ч
180 m*
8,15 ч
185
50 мин
176
8ч
182
115 дн
186
10,5 мин
*m — метастабильные состояние ядра
Тантал имеет о.ц.к. решетку с периодом а=0,33074 нм, координационное
число 8. Эффективное поперечное сечение захвата тепловых нейтронов
21,3*10-26м2, работа выхода электронов для поликристалла 4,12 эВ, для
монокристалла 4,352 эВ, положительная ночная эмиссия 10 эВ, энергия
кристаллической решетки 775 мкДж/кмоль.
Плотность при 298 К р=16,500 Мг/м3.
Удельное электрическое сопротивление р и удельная электрическая
проводимость  тантала чистотой 99,9 % в зависимости от температуры
106
меняются от 0.05 мкОмм (100 К) до 0.71 мкОмм (1800 К) и от 20 МСм/м (100
К) до 1.41 МСм/м (1800 К) соответственно [2].
Механические свойства тантала [2].
Механические свойства тантала зависят от его чистоты (содержания
примесей, особенно кислорода) и температуры испытания. Примеси внедрения
способствуют повышению твердости по Бринеллю, временного сопротивления,
предела текучести, но снижают характеристики пластичность и усиливают
хладноломкость.
Химические свойства тантала [2].
Нормальный электродный потенциал реакции Та — 5е ↔ Та5+ Φ=—
1,126В.
В соединениях проявляет степени окисления — 1, +1, +2, +3, +4, +5;
наиболее типична +5. Электрохимический эквивалент 0,3749 мг/Кл.
Тантал — самый коррозионностойкий из всех недрагоценных металлов.
Он стоек в соляной, серной, азотной, фосфорной и органических кислотах всех
концентраций вплоть до 100 — 1500С. В горячих соляной в серной кислотах
тантал отличается более высокой стойкостью, чем ниобий. Тантал растворяется
в плавиковой кислоте и особенно интенсивно в смеси плавиковой в азотной
кислот.
В щелочах тантал менее устойчив. Горячие растворы едких щелочей
заметно разъедают металл; в расплавленных щелочах с соде тантал быстро
окисляется с образованием натриевой соли танталовой кислоты.
При нормальной температуре тантал устойчив против окисления на
воздухе. При нагревании до 200 — 3000С на его поверхности образуется тонкая
прочно сцепляющаяся с основным металлом пленка оксида. Химические
реагенты действуют на металл только в тех случаях, когда они вступают в
реакцию с этой пленкой или проникают сквозь нее. Ценным качеством является
107
и то, что пленка оксида препятствует протеканию электрического тока от
металла к электролиту, если тантал служит анодом. Выше 5000С оксидная
плевка становится пористой, расслаивается и склонна к отделению от
основного металла.
Повышение сопротивления тантала окислению возможно либо путем
модифицированная (изменения структуры образующегося на металле оксида),
осуществляемого легированием соответствующими элементами, либо путем
предотвращения или хотя бы замедления контакта кислорода с металлической
поверхностью. В обоих последних случаях требуется применение защитных
покрытий на основном металле или сплаве.
С кислородом тантал образует твердый раствор и оксид Та2О5 . При
увеличении содержания кислорода в тантале до 15% (ат.)м происходит
пятикратное повышение прочностных свойств при сильном снижение
пластичность и коррозионной стойкости. Растворенный кислород выделяется
при нагреве выше 22000С в вакууме. Оксид тантала (V) Та2О5 существует в
двух модификациях. Температура плавления Та2О5 16200 C (по другим данным,
18720С). Та2О5 имеет кислотный характер.
Тантал слабо реагирует с водородом ниже 3500 С; выше этой
температуры скорость реакции растет примерно до 450 0С; при этой
температуре водород поглощается с максимальной скоростью и, кроме того,
образуется химическое соединение —низкотемпературный гидрид тантала
(ТаН). Поглощенный водород придает металлу хрупкость, однако при
нагревании в вакууме выше 8000 С водород удаляется и механические свойства
восстанавливаются.
Тантал непосредственно реагирует с азотом с образованием трех фаз
твердого раствора азота в тантале и нитридов Та2N и TaN. Реакция начинается
около 3000 С, причем скорость ее возрастает с повышением температуры до тех
108
пор, пока при 11000С не образуется TaN. Поглощенный танталом азот вновь
выделяется в условиях высокого вакуума при температуре 2000 0С. Присутствие
азота, как и кислорода увеличивает твердость в прочность тантала и снижает
его пластичность
Фтор действует на тантал при комнатной температуре. Тантал полностью
инертен к действию влажных и сухих хлора, брома и иода до 150 0С.
Воздействие хлора начинается около 2500, а при 5000С реакция протекает
практически мгновенно. В присутствия паров воды коррозия, вызываемая
хлором, резко замедляется. Бром действует на тантал при 3000С, иод —
примерно при той же температуре; в результате образуются TaBr5 и ТаI5
соответственно.
Углерод и углеродсодержащие газы (например, CH4, CO) при высокой
температуре 1200—14000С взаимодействуют с танталом, образуя твердые и
тугоплавкие карбиды ТаС, которые плавятся при 38800С и весьма устойчивы по
отношению к кислотам.
С бором тантал образует бороды ТаВ2, представляющие собой
тугоплавкие и твердые соединения (tплавления, =30000С), устойчивые против
воздействия соляной и азотной кислот, а также царской водки, но медленно
разлагающиеся под действием горячих серной н фтористой кислот. Бориды
тантала быстро диссоциируют в расплавленных щелочах, карбонатах,
бисульфатах и пероксидных соединениях.
С кремнием тантал образует силициды, основной из них дисилицид ТаSi2.
Этj соединение имеет температуру плавления 24000С, устойчиво против
воздействия минеральных кислот, однако разлагается под действием фтористой
кислоты.
Со многими металлами, имеющими изоморфную кристаллическую
структуру, размер атомов, близкий к размеру атома тантала, а также близко
109
расположенными к нему в ряду электроотрицательности, тантал образует
непрерывные твердые растворы. К этом металлам, в частности, относятся
ниобий, вольфрам, молибден, ванадий, 8-титан н др. Ограниченные твердые
растворы н металлические соединения тантал образует с алюминием,
бериллием, золотом, кремнием, никелем, т.е. металлами, которые значительно
отличаются по размерам атомов и электроотрицательности. С литием, калием,
натрием, магнием н некоторыми другими элементами тантал практически не
образует ни твердых растворов, ни соединений.
Технологические свойства тантала [2].
Тантал является пластичным тугоплавким металлом. Он хорошо
поддается обработке давлением всеми существующими методами. Чистый
тантал медленно нагартовывается в процессе пластической деформация ниже
температуры рекристаллизации, что позволяет подвергать его холодной
деформация с большими (до 95%) обжатиями без промежуточных отжигов.
Слитки тантала, подвергаемые холодной деформации для получения листов,
прутков и проволоки, предварительно обдирают на токарном ставке. В отличие
от тугоплавких металлов Vl группы тантал имеет достаточную пластичность
при низкой температуре вплоть до — 1960С.
110
Рис. 3.3. Макет сегмента кодирующей маски из тантала.
Таким образом, на основании вышеизложенного можно сделать вывод,
что тантал обладает физико-химическими и технологическими свойствами,
позволяющими изготовить из него сегмент кодирующей маски требуемых
размеров. Это позволяет оптимизировать технологию изготовления элементов
кодирующей маски широкоапертурного гамма-телексопа, так как по сравнению
с вариантом «антимаски» из вольфрама снимается вопрос о креплении
поглощающих шайб.
В порядке методической проработки технологии изготовления элемента
кодирующей маски был изготовлен макетный образец центральной части
сегмента кодирующей маски с отверстиями, расположенными согласно
выбранному оптимальному узору (см. рис. 3.3).
111
112
Гл.4. Результаты проработки технических предложений по
обеспечению
теплового
режима
функционирования
широкоапертурного гамма-телескопа.
§4.1. Система обеспечения теплового режима широкоапертурного гаммателескопа.
Для
оптимизации
теплового
режима
функционирования
широкоапертурного гамма-телескопа и с учетом результатов НИР предыдущих
этапов принято разделение системы обеспечения теплового режима (СОТР)
научной аппаратуры (НА) на две подсистемы с различным диапазоном рабочих
температур:
СОТР
-
ОД
с
диапазоном
допустимых
температур
от 0С до 20С;
- общая СОТР ПЧД и БЭ с диапазоном допустимых температур
от 0С до 30 С.
Данное разделение на подсистемы принято в связи с тем, что более
высокая рабочая температура ПЧД и БЭ позволяет использовать радиаторохладитель меньшей площади,
а также позволяет использовать в качестве
отдельного радиатора-охладителя для ОД кодирующую маску.
Исходные данные для оценки системы обеспечения теплового
режима (СОТР).
Тепловой режим МНА "Гаммафон" рассматривался из следующих
допущений относительно аппаратуры:
-
тепловыделения – 150 Вт (постоянно), из них:
-
позиционно-чувствительный детектор – 520 Вт;
-
оптические датчики – 310 Вт;
-
блок электроники – 20 Вт;
113
-
допустимая температура посадочных мест:
-
позиционно-чувствительный детектор – от минус 10 до + 30˚С;
-
оптические датчики – от 0 до 20˚С;
-
блок электроники – от 0 до 40˚С.
СОТР ПЧД и БЭ.
Для отвода тепловыделений ПЧД и БЭ предполагается использование
двух тепловых труб разработки ЦТТ Росавиакосмоса: аксиальной тепловой
трубы (АТТ) марки AGHP-12,5 и контурной тепловой трубы (КТТ).
Коллекторная АТТ собирает тепло от позиционно-чувствительных
детекторов и блока электроники на коллектор с которого, при помощи КТТ
тепло отводится на радиатор.
Предполагается
использование
регулируемой
КТТ.
Регулирование
производится автоматически при помощи клапана, который реагирует на
понижение давления в трубе при снижении температуры теплоносителя ниже
установленной.
В
результате
срабатывания
регулировочного
клапана
теплоноситель перепускается в байпасную магистраль и радиатор "отсекается"
от системы.
Температура, при которой срабатывает клапан, устанавливается равной
плюс 3˚С, определяется, как нижняя граница диапазона допустимых температур
БЭ равная 0˚С плюс запас 3˚С на неточность срабатывания клапана.
Радиатор представляет собой незамкнутый тонкостенный усеченный
конус площадью поверхности 1 м2 с проложенной внутри конденсационной
магистралью КТТ. Радиационной является только внешняя поверхность
радиатора, которая покрываются ТР-со-ЦМ. Радиатор размещен в нижней
части модуля научной аппаратуры и крепится к несущей конструкции для
оптических
датчиков
(см.
рис.
3.1).
Габаритные
размеры
радиатора
114
определялись требуемой площадью радиационной поверхности для сброса
тепла и имеющейся зоной полезного груза под головным обтекателем.
Тепловой расчет показал (см. ниже), что применение покрытия ТР-со-ЦМ
на радиаторе не обеспечивает требуемый диапазон температур для ПЧД и БЭ
из-за недостаточной площади поверхности радиатора (из-за габаритных
ограничений). В связи с этим, в качестве терморегулирующего покрытия
целесообразно
использовать
OS/R
или
аналогичное
с
оптическими
коэффициентами   0,9 и AS  0,1. Кроме того, необходимо расширение
диапазонов допустимых температур ПЧД до +40˚С. Этого можно добиться с
помощью введения в конструкцию ПЧД элементов Пельтье для локального
охлаждения чувствительных элементов (матриц).
§4.2. Результаты проработки технических предложений по обеспечению
теплового режима функционирования широкоапертурного гаммателескопа.
Расчётные случаи
Средняя температура радиатора определялась для двух расчётных
случаев:
-
расчётный случай "Tmax":  (угол между нормалью к плоскости орбиты
и направлением на Солнце, ˚) равен 21,4˚, внутренние тепловыделения
максимальные (120 Вт), альбедо Земли - 0,32, собственное излучение
Земли (на поверхности) – 260 Вт/м2;
-
расчётный случай "Tmin":  = 220˚ (радиатор НА частично закрыт от
Солнца
основным
изделием),
научная
аппаратура
отключена,
собственное излучение Земли (на поверхности) – 220 Вт/м2.
Листинг файла исходных данных для теплового расчета представлен в
Приложении Г.
Тепловой режим ПЧД и БЭ
115
4.3.2.1 Результаты теплового расчёта при применении покрытия
ТР-со-ЦМ на радиаторе.
Результат теплового расчёта для случая максимальной температуры
с применением покрытия ТР-со-ЦМ на радиаторе и КМ приведён на
рисунке 4.1.
В результате теплового расчёта получены следующие данные:
-
максимальная температура посадочных мест ПЧД и БЭ составляет
48С, что превышает допустимую (30˚С для ПЧД и 40С для БЭ);
-
минимальная температура радиатора не опускается ниже минус 55˚С,
что превышает температуру замерзания теплоносителя (аммиак),
равную минус 77˚С.
Рис. 4.1. Результат теплового расчёта для случая максимальной температуры с
применением покрытия ТР-со-ЦМ на радиаторе и КМ.
116
Результаты теплового расчёта при применении улучшенного покрытия на
радиаторе
Результат теплового расчёта для случая максимальной температуры с
применением улучшенного покрытия на радиаторе приведён на рис. 4.2.
В результате теплового расчёта получены следующие данные:
-
максимальная температура посадочных мест ПЧД и БЭ составляет
35С и превышает допустимую для ПЧД (30˚С), что подтверждает
необходимость введения изменений в конструкцию ПЧД;
-
минимальная температура выносного радиатора не опускается ниже
минус 55˚С, что превышает температуру замерзания теплоносителя
(аммиак), равную минус 77˚С.
Рисунок 4.2 - Результат теплового расчёта для случая максимальной
температуры с применением улучшенного покрытия на радиаторе и КМ
117
Результаты теплового расчёта при применении улучшенного покрытия
на КМ
Результат теплового расчёта для случая максимальной температуры
с применением улучшенного покрытия на радиаторе и КМ приведён на
рис. 4.2.
Максимальная температура посадочных мест ОД не превышает значения
13˚С, что ниже допустимой (20˚С).
Анализ тепловых расчетов рассмотренных вариантов СТР показал, что
вариант с применением покрытия ТР-со-ЦМ на радиаторе и КМ не
обеспечивает
поддержание
требуемого
диапазона
температур
научной
аппаратуры. Вариант с применением улучшенного покрытия на радиаторе и
КМ обеспечивает требуемую температуру оптических датчиков, но не
обеспечивает требуемую температуру позиционно-чувствительных детекторов
(превышение допустимой температуры на 5ºС). Решить эту задачу можно
введением в состав ПЧД элементов Пельтье, которые увеличат температуру
посадочных мест ПЧД до 40°, но при этом обеспечат допустимый диапазон
температуры чувствительного элемента (матрицы). Таким образом данный
вариант обеспечивает требуемый тепловой режим научной аппаратуры и может
быть реализован в эксперименте "Гаммафон".
§4.3. Оптимизация теплового режима функционирования широкоапертурного
гамма-телескопа.
Рассмотренный выше вариант СОТР имеет следующие недостатки:
- необходимость использования радиатора большой площади, что
затрудняет размещение НА на изделии 14Ф139 в транспортном положении;
- необходимость
оптического покрытия;
применения
дорогостоящего
и
нетехнологичного
118
- применение регулируемой КТТ усложняет конструкцию СОТР и
снижает надёжность работы СОТР;
- необходимость внедрения в состав ПЧД элементов Пельтье.
В связи с этим рассмотрим альтернативный вариант СОТР.
Вариант СОТР с отводом тепловыделений ПЧД и БЭ в контур СОТР
базового изделия.
СОТР ПЧД и БЭ.
Отличие данного варианта от предыдущего состоит в том, что
коллекторная АТТ1 марки AGHP-12,5 собирает тепло от позиционночувствительных детекторов и блока электроники на коллектор к которому
подводится трубопровод СТР базового изделия. Температура теплоносителя
(ЛЗ-ТК-2) в контуре СТР поддерживается в пределах от 5 до 20 С, что
позволяет надёжно удерживать температуры посадочных мест ПЧД и БЭ в
допустимых пределах.
Тепловой расчет для варианта СОТР с отводом тепловыделений
ПЧД и БЭ в контур СТР базового изделия.
Результат теплового расчёта для случая максимальной температуры
варианта СОТР с отводом тепловыделений ПЧД и БЭ в контур СОТР базового
изделия приведён на рисунке 4.3.
В результате теплового расчёта получены следующие данные:
-
максимальная температура посадочных мест ПЧД и БЭ не превышает
27˚С, что ниже допустимой (30˚С);
-
минимальная температура ПЧД и БЭ не опускается ниже 10˚С;
в случае нештатной работы базового изделия и отключения НА, температура
посадочных мест ПЧД и БЭ – не ниже 2˚С.
119
Рис. 4.3. Результат теплового расчёта для случая максимальной температуры
варианта СОТР с отводом тепловыделений ПЧД и БЭ в контур СТР базового
изделия.
Результаты анализа теплового расчета.
Тепловой расчет показал, что данный вариант СОТР обеспечивает
требуемый диапазон температур научной аппаратуры. При этом он имеет
следующие преимущества по сравнению с предыдущим вариантом:
- потребная площадь радиатора уменьшается до 0,2 м;
-
предусматривает
использование
радиационного покрытия ТР-со-ЦМ;
недорогого
и
практичного
120
- значительное уменьшение габаритов модуля научной аппаратуры, что
позволит рациональнее разместить МНА в транспортном положении в зоне
полезного груза КА;
-
предварительный анализ показал, возможность размещения модуля
научной аппаратуры с уменьшенным радиатором
в рабочем положении в
пределах зоны полезного груза в транспортном положении. При этом
подвижная штанга с ЭМП заменяется жестким неподвижным кронштейном,
что существенно упрощает конструкцию МНА и реализацию эксперимента с
широкапертурным гамма-телескопом.
Тепловой режим научной аппаратуры при ее размещении на малом
космическом аппарате в качестве формообразующей полезной нагрузки.
НА может быть размещена на МКА на базе малой космической
платформы в качестве основной полезной нагрузки.
Схема СОТР при этом аналогична первому варианту СОТР при
размещении НА на изделии 14Ф139. Потребная площадь радиатора составляет
1,1 м2.
Результат теплового расчёта для случая максимальной температуры при
установке МНА на борту МКА приведён на рисунке 4.4.
В результате теплового расчёта получены следующие данные:
-
максимальная температура посадочных мест ПЧД и БЭ не превышает
22˚С, что ниже допустимой (30˚С);
-
минимальная температура радиатора не опускается ниже минус 12˚С,
что превышает температуру замерзания теплоносителя (аммиак), равную минус
77˚С.
121
Рис. 4.4 - Результат теплового расчёта для случая максимальной температуры
при установке НА на борту МКА
Анализ
теплового
расчета
показывает
возможность
реализации
рассмотренной схемы СОТР при размещении научной аппаратуры на малом
космическом аппарате.
122
Заключение
В ходе выполнения работ по договору № 125-08 от 29.05.2008 г. согласно
техническому заданию и календарному плану осуществлялось формирование
принципов построения и функционирования основных программных модулей
для решения научных задач в эксперименте с широкоапертурным гаммателескопом, разработка систем хранения и передачи данных в блоке
электроники прибора, оптимизация технологии изготовления элементов
кодирующей маски широкоапертурного гамма-телескопа, проработка методики
локализации
гамма-квантов
широкоапертурного
в
позиционно-чувствительном
гамма-телескопа,
оптимизация
детекторе
теплового
режима
функционирования широкоапертурного гамма-телескопа на космическом
аппарате. (пп. 2.3.2, 2.3.3, 2.3.4, 3.2.2, 3.2.3, 3.2.4 ТЗ)
В результате выполнения работ были получены следующие основные
результаты:
- сформированы принципы построения и функционирования основных
программных модулей для решения научных задач в эксперименте с
широкоапертурным гамма-телескопом; эти модули обеспечивают:
расчет матрицы отклика прибора в рамках решения обратной задачи –
восстановление
изображений
моделирование
взаимодействий
по
выходным
гамма-квантов
в
параметрам,
позиционно-
чувствительном детекторе, управление данными в блоке электроники
прибора.
- разработана система хранения и передачи данных в блоке электроники
прибора, позволяющая. формировать весь объем информации с
позиционно-чувствительных детекторов.
123
- оптимизирована технология изготовления элементов кодирующей
маски широкоапертурного гамма-телескопа на основе использования
тантала в качестве материала маски.
- проработана методика локализации гамма-квантов в позиционночувствительном детекторе широкоапертурного гамма-телескопа на
основе моделирования физических взаимодействий гамма-квантов в
веществе кодирующей маски и позиционно-чувствительного детектора;
в результате решена обратная задача восстановления изображения
наблюдаемого участка неба по выходным показаниям детектора.
- оптимизирован тепловой режим функционирования широкоапертурного
гамма-телескопа на космическом аппарате, в том числе проработаны
технические
предложения
по
обеспечению
теплового
режима
функционирования детекторов широкоапертурного гамма-телескопа на борту
серийного
технические
космического
аппарата
предложения
по
нового
поколения,
обеспечению
проработаны
теплового
режима
функционирования электроники широкоапертурного гамма-телескопа с
бортом космического аппарата.
124
Заключение итоговое
В соответствии с ТЗ целью НИР «Гаммафон» «Проработка предложений
по проведению мониторных наблюдений астрофизических источников и фона в
жестком рентгеновском и гамма-излучении (0.05 – 1.0 МэВ)» является
проработка предложений по мониторному наблюдению неба в диапазоне
гамма-излучений
0.05-1.0
МэВ
в ходе
космического
эксперимента
с
широкоапертурным гамма-телескопом на серийном КА нового поколения. В
результате
этого
эксперимента
должны
быть
проведены
длительные
мониторные наблюдения, измерен фон и получены изображения обширных
областей звездного неба (вплоть до половины небесной сферы) в диапазоне
энергий регистрируемых фотонов 0.05-1.0 МэВ. При этом должно быть
обеспечено комплексное изучение с высоким временным и спектральным
разрешением известных источников жесткого электромагнитного излучения и
осуществляться
постоянный
патруль
таких
временных
явлений,
как
рентгеновские транзиенты и новые, гамма-всплески.
В соответствии с ТЗ задачами работ, проводившихся в рамках НИР
«Гаммафон» были:
Лабораторное макетирование основных узлов аппаратуры и оптимизация
технологии ее изготовления (лабораторное макетирование системы кодировки
позиционно-разрешаемых элементов позиционно-чувствительного детектора;
лабораторное макетирование системы измерения энергии регистрируемых
гамма-квантов
в
позиционно-чувствительном
детекторе;
определение
позиционного и энергетического разрешения прибора; проработка методики
кодирования изображений; оптимизация технологии изготовления элементов
кодирующей маски; разработка архитектуры процессорного блока).
125
Разработка
программных
средств
обеспечения
эксперимента
с
широкоапертурным гамма-телескопом (разработка принципов построения
программно-вычислительного комплекса для обработки данных; создание
программных средств для расчета матрицы отклика прибора с учетом
реального
позиционного
и
энергетического
разрешения;
адаптация
программно-вычислительного комплекса обработки данных для решения
научных задач эксперимента, формирование принципов построения и
функционирования основных программных модулей).
Проработка реализации и оптимизация размещения широкоапертурного гаммателескопа и аппаратуры передачи научной информации на серийном
космическом аппарате нового поколения (оптимизация конструктивной
реализации размещения научной аппаратуры; оптимизация электрического
сопряжения научной аппаратуры с бортовой аппаратурой космического
аппарата; оптимизация
теплового режима функционирования научной
аппаратуры).
Указанные задачи могут быть разбиты на две группы. Одна группа задач
связана
с
разработкой
концепции
эксперимента,
оптимизацией
НА,
математическим моделированием и лабораторным макетированием основных
узлов НА и проработкой возможности ее изготовления и испытаний. Другая
группа задач связана с необходимостью адаптации НА к условиям
космического эксперимента, проработки возможности размещения НА на борту
серийного КА и ее привязки к бортовым системам. В рамках рассматриваемой
НИР первая группа задач (пп. ТЗ 2.3.1, 2.3.2, 2.3.3, 3.2.1, 3.2.2, 3.2.3)
выполнялась силами НИИЯФ МГУ, а вторая (пп. ТЗ 2.3.4, 3.2.4, 3.3.4) - ФГУП
КБ «Арсенал» им. М.В. Фрунзе.
126
Основные результаты исследований
Проведенные исследования позволили выполнить требования ТЗ в
полном объёме. Работа проводилась в течению трех лет и была разбита на 6
этапов. При этом был выполнен весь комплекс необходимых исследований по
научно-методической
проработке
космического
эксперимента
с
широкоапертурным гамма-телескопом. В результате проведенного анализа
показана возможность осуществления космического эксперимента с размещением
научной аппаратуры на специализированном космическом аппарате разработки
ФГУП КБ «Арсенал» имени М.В. Фрунзе. При этом были получены новые научные
знания, разработаны новые программные средства решения поставленных
научных задач, в том числе:
- дана проработка методов построения изображений в рентгеновских и гаммалучах в приборах с кодированной апертурой и широким полем зрения;
- осуществлено математическое моделирование всех этапов построения
изображений при наблюдениях с широкоапертурным гамма-телескопом,
построена математическая модель прибора;
- проведено лабораторное макетирование основных узлов детекторных блоков
широкоапертурного гамма-телескопа;
- разработаны цифровые методы обработки изображений и принципы
построения программно-вычислительного комплекса для обработки данных в
эксперименте с широкоапертурным гамма-телескопом;
- показана возможность интеграции научной аппаратуры с бортовой
аппаратурой космического аппарата, а также возможность осуществления
передачи полученной научной информации.
В ходе проработки методов построения изображений в рентгеновских и
гамма-лучах в приборах с кодированной апертурой и широким полем зрения
127
был проведен анализ принципов построения изображений в рентгеновских и
гамма-лучах в приборах с кодированной апертурой; дан сравнительный анализ
существующих и разрабатываемых отечественных и зарубежных приборов,
позволяющих получать изображения в рентгеновском и гамма-диапазонах;
проанализированы основные характеристики регистрирующей аппаратуры в
проекте «Гаммафон» в сравнении с существующими зарубежными аналогами.
При
построении
математической
модели
прибора
были
решены
следующие задачи:
 построена математическая модель построения изображения неба с помощью
широкоапертурного гамма-телескопа;
 осуществлено математическое моделирование восстановления изображений
в гамма-лучах по выходным показаниям широкоапертурного гаммателескопа;
 разработан метод построения изображения неба с учетом реальных условий
наблюдений, включая анализ вариаций аппаратурного фона;
 осуществлено математическое моделирование измерений в эксперименте с
широкоапертурным гамма-телескопом на серийном космическом аппарате
нового поколения с учетом данных по астрофизическим источникам и фону
гамма-излучения и реального расположения прибора на спутнике;
 расчитаны апертурная передаточная функция и функция отклика прибора
для реальной конфигурации кодирующей маски и позиционночувствительного детектора;
 созданы программные средства для расчета матрицы отклика
широкоапертурного гамма-телескопа с учетом реального позиционного и
энергетического разрешения;
128
 разработана методика расчета матрицы отклика широкоапертурного гаммателескопа с учетом реального позиционного и энергетического разрешения;
 осуществлено математическое моделирование процессов взаимодействия
гамма-квантов в элементах широкоапертурного гамма-телескопа, включая
кодирующую маску и позиционно-чувствительный детектор;
 для реальной конфигурации широкоапертурного гамма-телескопа
рассчитана засветка позиционно-разрешаемых элементов детектора прибора
при различных положениях на небе точечного источника гамма-квантов.
В ходе лабораторного макетирования основных узлов детекторного блока
гамма-телескопа были выполнены следующие работы:
- проведено лабораторное макетирование электронных узлов блока
позиционно-чувствительного
детектора
широкоапертурного
гамма-
телескопа, в том числе разработана принципиальная схема платы
входных усилителей, разработана принципиальная схема платы трактов
определения энергии и координаты регистрируемого гамма-кванта;
- оптимизирован способ построения кодирующей системы на основе
принципа «антимаски», в том числе выбран материал поглощающих
элементов, разработан оптимальный способ их размещения на сегменте
кодирующей маски, разработан принцип крепления поглощающих
элементов на сегменте кодирующей маски, выбран оптимальный
материал сегмента; оптимизирована технология изготовления элементов
кодирующей маски, разаработана методика локализации гамма-квантов
в приборе.
-
проведено
лабораторное
позиционно-разрешаемых
детектора
макетирование
элементов
широкоапертурного
системы
кодировки
позиционно-чувствительного
гамма-телескопа;
разработаны
принципиальные схемы плат кодировки позиционно-разрешаемых
129
элементов и осуществлено их тестирование от источников стандартных
сигналов;
- разработаны принципиальные схемы плат и проведено лабораторное
макетирование системы измерения энергии регистрируемых гаммаквантов в позиционно-чувствительном детекторе широкоапертурного
гамма-телескопа;
- с помощью лабораторного макета блока позиционно-чувствительного
детектора
(ПЧД)
осуществлены
измерения
позиционного
и
энергетического разрешения ПЧД, на основании которых определены
позиционное и энергетическое разрешение широкоапертурного гаммателескопа.
Разработана система цифровой обработки информации в эксперименте с
широкоаертурным гамма-телескопом:
- сформированы принципов построения и функционирования основных
программных модулей для решения научных задач в эксперименте;
- разработана архитектура процессорного блока широкоапертурного
гамма-телескопа;
- разработана система хранения и передачи данных в блоке электроники
прибора;
- разработан и адаптирован для решения научных задач в эксперименте с
широкоапертурным
гамма-телескопом
программно-вычислительный
комплекс обработки данных;
В результате проработки возможности размещения аппаратуры в качестве
попутной нагрузки на серийном космическом аппарате были получены
следующие результаты:
- оптимизирована конструктивная реализация размещения широкоапертурного
гамма-телескопа на серийном космическом аппарате нового поколения, в том
130
числе проработаны технические требования по доработке служебных систем
базового космического аппарата; проработаны технические требования к
конструктивной реализации аппаратуры с учетом обеспечения максимального
незатенения чувствительных элементов прибора;
- проработаны технические требования по установке элементов научной
аппаратуры на базовом космическом аппарате;
- оптимизировано электрическое сопряжение широкоапертурного гаммателескопа с бортом серийного космического аппарата нового поколения;
- проработаны технические требования по размещению элементов системы
термостатирования,
оптимизирован
тепловой
режим
функционирования
аппаратуры на космичсеком аппарате.
Таким образом, можно сделать вывод о том, что в ходе выполнения НИР
решены научно-методические и технические вопросы проведения космического
эксперимента (КЭ) с широкоапертурным гамма-телескопом, научно обоснована
значимость и актуальность проведения КЭ, проведено предварительное
обоснование технической реализуемости КЭ, проведена предварительная
подготовка привязки научной аппаратуры к конкретному космическому
аппарату. Представляется целесообразным перевести данную работу в стадию
подготовки и выпуска эскизного проекта.
131
Список литературы
1. Научно-технический отчет НИИЯФ МГУ по теме “Магистраль-5” (НИР
“Гаммафон”), этап №3, 2006.
2. Свойства элементов. Справочник. (Под обще редакцией М.Е.Дрица). Москва:
«Металлургия», 1985.
132
ПРИЛОЖЕНИЕ
Пример программы spacemap.c, осуществляющей восстановления карты неба в
экваториальных координатах.
Программа написана на языке С для компилятора “Watcom C – 95”.
Программа выполняет следующие действия:
Считывает
матрицу
отклика,
необходимую
для
получения
изображения в поле зрения прибора.
Последовательного считывает информацию типа «Карта», а также
данных об ориентации осей прибора в каждый момент времени
Восстанавливает изображение в поле зрения прибора
Последовательно перебирая точки на карте неба в экваториальных
координатах (разбиение с интервалом в 1о) вычисляет их
координаты в поле зрения прибора. После этого путём
интерполяции
вычисляется
поток,
который
приписывается
соответствующей точке неба.
Происходит считывание всей заданной последовательности кадров
типа «Карта». Восстановленная карта неба изображается на
экране и может быть сохранена в выходном файле.
#include <stdio.h>
#include <math.h>
#include <conio.h>
#include <dos.h>
#include <graph.h>
#include <graphx.h>
float huge skm[361][181];
float huge tm[21001];
float huge fm[21001];
float huge matr[1001][21001];
float huge kadr[21001];
double cr[1001];
int n1[91],n2[91],nkad=1,ikad=0,needmap=1;
double a3_1,a3_2;
133
double ca1,ca2,sa1,sa2,ca3,sa3,ca,sa,cd,sd,cd1,sd1,cd2,sd2,cd3,sd3;
double tt,tt1,tt2,tga3,tgd3_1,tgd3_2,d3_1,d3_2;
double a,d,a1,d1,a2,d2,a3,d3;
double pi=3.14159265358979,tet,fi,sk,tett,fffi;
int i,j,k,is,yes,crnum,ncr,icr,ntfm=21000,ntf,cp=100,icp,ia,id;
FILE *kadrfile,*inpfile,*matrfile,*tetfile,*datfile,*outfile;
char filekadr[80],fileinp[80],fileout[80];
char filedat[50]="naj_0000.dat",filetet[50]="filetet.dat";
double mid,tet_d,fi_d,potok;
char kuda;
double zmin,zmax,zmini,zmaxi,intens;
int icol,col[15]={0,8,1,9,3,10,14,6,4,12,7,15};
int nk,nastr=1,yesf;
int ig,jg,ncrg;
double srg,v1,v2;
char dtoa();
double tetta();
double ffi();
double interpol();
void find_a3_d3();
void n1n2();
void main(int argc,char *argv[])
{
/*clrscr();*/
if(argc>1)
{ is=0; do{filekadr[is]=*(argv[1]+is); is=is+1;}
while(filekadr[is-1]!='\x0' && is<79);
kadrfile=fopen(filekadr,"r");
if(kadrfile==NULL){printf("не вижу файла с кадрами\n"); goto theend; }
} else {printf("Нужно при запуске указать имя управляющего файла\n");
goto theend;}
printf("предполагается ли выводить результаты в файл?");
scanf("%d",&yesf);
if(yesf==1)
{ printf("введите имя выходного файла:");
scanf("%s",fileout);
}
fscanf(kadrfile,"n=%d",&ncr);
printf("число кристаллов = %d\n",ncr);
ncrg=ncr/6;
printf("на каждой грани по %d штук\n",ncrg);
/* считывание матрицы восстановления изображений */
/* массивы tm[] и fm[] заполняем углами, для которых рассчитана матрица */
tetfile=fopen(filetet,"r");
if(tetfile==NULL){printf("не вижу файла filetet.dat\n"); getch();}
for (k=1;k<=ntfm;k++)
{
fscanf(tetfile,"%lf,%lf",&tett,&fffi);
134
if(feof(tetfile)!=0) { ntf=k-1;
break; }
tm[k]=tett; fm[k]=fffi;
if((icp/cp)*cp==icp)
printf("tetta=%lf , fi=%lf\n",tett,fffi);
icp=icp+1;
}
printf("всего %d значений угла\n",ntf);
/* getch();*/
/* считываем матрицу */
for (j=1;j<=ncr;j++)
{ filedat[4]=dtoa((int)(j/1000));
filedat[5]=dtoa((int)((j-(j/1000)*1000)/100));
filedat[6]=dtoa((int)((j-(j/100)*100)/10));
filedat[7]=dtoa((int)(j-(j/10)*10));
printf("%d, %s\n",j,filedat);
datfile=fopen(filedat,"r");
if(datfile==NULL)
{ printf("не могу открыть %s\n",filedat);
getch(); goto metka; }
for (k=1;k<=ntf;k++)
{ fscanf(datfile,"%lf",&sk);
/*
printf("%d,%lf\n",k,sk); */
matr[j][k]=sk; }
fclose(datfile);
}
/* Матрица считана. Переходим к восстановлению изображений кадр за кадром */
n1n2(tm,ntf);
initialize();
diapazon(0.0,360.0,-100.0,100.0);
setcolor(15);
_rectangle_w(_GBORDER,0.0,-90.0,360.0,90.0);
metka:
while(feof(kadrfile)==0)
{ fscanf(kadrfile,"%lf,%lf,%lf,%lf,%s",
&a1,&d1,&a2,&d2,fileinp);
find_a3_d3();
/* printf("%lf,%lf,%lf,%lf,%lf,%lf,%s\n",a1,d1,a2,d2,a3,d3,fileinp);
printf("-----------------------------------------------------\n");*/
nk=nk+1;
setcolor(0);
_rectangle(_GFILLINTERIOR,20,10,150,25);
setcolor(15);
gprintf(20,10,"frame %d",nk);
inpfile=fopen(fileinp,"r");
if(inpfile==NULL)
{ gprintf(20,30,"не вижу файла %s...\n",fileinp);
getch();
135
continue;
}
mid=0;
for(icr=1;icr<=ncr;icr++)
{ fscanf(inpfile,"%d,%lf",&crnum,&cr[icr]);
/*printf("%3d,%lf\n",icr,cr[icr]);*/
}
fclose(inpfile);
for(jg=1;jg<=6;jg++)
{ srg=0;
for(ig=ncrg*(jg-1)+1;ig<=ncrg*jg;ig++)srg=srg+cr[ig];
srg=srg/(double)ncrg;
for(ig=ncrg*(jg-1)+1;ig<=ncrg*jg;ig++)
cr[ig]=cr[ig]-srg;
}
icp=0;
for(k=1;k<=ntf;k++)
{ kadr[k]=0;
for(icr=1;icr<=ncr;icr++) kadr[k]=kadr[k]+matr[icr][k]*cr[icr];
if((icp/cp)*cp==icp)
/*printf("tet=%f,fi=%f,I=%f\n",tm[k],fm[k],kadr[k]);*/
icp=icp+1;
}
/* массив kadr[k], где k=1,ntf заполнен восстановленным изображением
неба (в системе детектора) */
/* открываются циклы, перебирающие точки неба в экваториальной системе */
for(ia=0;ia<=360;ia++)
{ setcolor(0);
_rectangle(_GFILLINTERIOR,400,10,500,25);
setcolor(15);
gprintf(400,10,"alpha=%d\n",ia);
for(id=0;id<=180;id++)
{ a=(double)ia;
d=(double)id-90.0;
tet_d=tetta(a,d,a1,d1); /*угол tetta в системе детектора */
if(tet_d>=90.0)continue;
fi_d=ffi(a,d,a1,d1,a2,d2,a3,d3);
potok=interpol(tet_d,fi_d,tm,fm,kadr,ntf);
skm[ia][id]=skm[ia][id]+potok;
} } /*закрылись циклы, перебирающие точки неба в экваториальной системе */
/* printf("что нужно? '1'=строить карту,'ESC'=выход,другое=продолжить\n");*/
if(kbhit()!=0)
{ kuda=getch();
if(kuda==27)goto theend;
if(kuda==13)nastr=1;
if(kuda=='f' || kuda=='F')goto tofile;
}
/* Кадр добавлен на общую карту.*/
kud:
kuda='1';
136
/*Печатаем общую карту, если не нажали 'ESC'*/
{
if(nastr==1)
{ closegraph();
zmini=1.0e50;
zmaxi=-1.0e50;
for(ia=0;ia<=360;ia++)
{ for(id=0;id<=180;id++)
{ if (skm[ia][id]>zmaxi) zmaxi=skm[ia][id];
if (skm[ia][id]<zmini) zmini=skm[ia][id]; } }
printf("минимальное значение Imin=%8.4lf\n",zmini);
printf("максимальное значение Imax=%8.4lf\n",zmaxi);
printf("введите диапазон по оси Z : zmin,zmax : ");
scanf("%lf,%lf",&zmin,&zmax);
printf("через сколько кадров обновлять карту на экране?");
scanf("%d",&nkad);
initialize();
diapazon(0.0,360.0,-110.0,110.0);
setcolor(15);
_rectangle_w(_GBORDER,0.0,-90.0,360.0,90.0);
nastr=0;
}
if(needmap==1) {
for(ia=0;ia<=360;ia++)
{ for(id=0;id<=180;id++)
{
intens=(skm[ia][id]-zmin)/(zmax-zmin);
if (intens<0) intens=-0.05;
if (intens>1) intens=1.05;
icol=(int)((intens+0.1)*10);
bigpoint((double)ia,(double)(id-90),col[icol]);
}}
} //нарисовали карту
needmap=0; ikad=ikad+1;
if(ikad>=nkad){ikad=0; needmap=1;}
setcolor(15);
_rectangle_w(_GBORDER,0.0,-90.0,360.0,90.0);
} //закрылся if (если надо печатать карту)
} // закрылся цикл while, читающий кадр за кадром
tofile:
if(yesf==1)
{ outfile=fopen(fileout,"w");
for(ia=0;ia<=360;ia++)
{ for(id=0;id<=180;id++)
{ fprintf(outfile,"%lf,%lf,%lf\n",
(double)ia,(double)(id-90),skm[ia][id]);
}}
fclose(outfile);
if(kuda=='f' || kuda=='F')goto kud;
137
}
getch();
theend:;
closegraph();
}
double ffi( double aa,double dd,double aa1,double dd1,
double aa2,double dd2,double aa3,double dd3)
{ double tt,tt1,tt2,fi1;
tt=tetta(aa,dd,aa1,dd1);
tt1=tetta(aa,dd,aa2,dd2);
tt2=tetta(aa,dd,aa3,dd3);
fi1=cos(tt1/180*pi)/sin(tt/180*pi);
if(fi1>-0.9999999 && fi1<0.9999999)fi1=acos(fi1)/pi*180.0;
else { if(fi1>0)fi1=0; if(fi1<0)fi1=180; }
if(tt2<=90)return fi1;
else return 360.0-fi1;
}
double tetta(double a_,double d_,double a1_,double d1_)
{ double tet_;
tet_=acos(sin(d_/180*pi)*sin(d1_/180*pi)+
cos(d_/180*pi)*cos(d1_/180*pi)*cos(a_/180*pi-a1_/180*pi));
tet_=tet_*180.0/pi;
return tet_;
}
char dtoa(int d)
{ char c;
if (d<0) return('<');
if (d>9) return('>');
c=d+48;
return(c);
}
void n1n2(float huge masx[],int ck)
{ int i,j,j1,j2;
for(j=1;j<=90;j++)
{ j1=1; j2=ck;
for(i=1;i<=ck;i++)
{ if(masx[i]>j+1){j2=i; break;} }
n2[j]=j2;
for(i=ck;i>=1;i--)
{ if(masx[i]<j-1){j1=i; break;} }
n1[j]=j1;
/* printf("%d, %d...%d\n",j,n1[j],n2[j]);
getch();*/
}
}
double interpol(double x,double y,float huge masx[],
float huge masy[],float huge masz[],int ck)
{ double uno,newr;
double z;
138
int iuno=-1,i,j,j1,j2;
uno=1.0e100;
j=(int)x;
j1=n1[j]; j2=n2[j]; if(j1<1)j1=1; if(j2>ck)j2=ck;
for (i=j1;i<=j2;i++)
{ newr=(masx[i]-x)*(masx[i]-x)+(masy[i]-y)*(masy[i]-y);
if (newr<=uno)
{ iuno=i;
uno=newr;}
}
z=masz[iuno];
return(z);
}
void find_a3_d3(void)
{ if(d1==0 && d2==0)
{a3=a1;
if((a2>a1 && (a2-a1)<180.0) ||
(a1<a2 && (a1-a2)>180 )){ d3=90.0; }
else d3=-90.0;
goto finish; }
if((d1-90)*(d1-90)<1e-20)
{ d3=0; a3=a2+90; if(a3>360)a3=a3-360; goto finish; }
if((d1+90)*(d1+90)<1e-20)
{ d3=0; a3=a2-90; if(a3<0)a3=a3+360; goto finish; }
ca1=cos(a1*pi/180.0); sa1=sin(a1*pi/180.0);
cd1=cos(d1*pi/180.0); sd1=sin(d1*pi/180.0);
ca2=cos(a2*pi/180.0); sa2=sin(a2*pi/180.0);
cd2=cos(d2*pi/180.0); sd2=sin(d2*pi/180.0);
v1=(cd2*ca2*sd1-cd1*ca1*sd2);
v2=(cd1*sa1*sd2-cd2*sa2*sd1);
if(v1>1e20*v2 && v2>0) { tga3=1e20; goto tga3gotov; }
if(v1<-1e20*v2 && v2>0) { tga3=-1e20; goto tga3gotov; }
if(v1>-1e20*v2 && v2<0) { tga3=-1e20; goto tga3gotov; }
if(v1<1e20*v2 && v2<0) { tga3=1e20; goto tga3gotov; }
tga3=v1/v2;
tga3gotov:
a3_1=atan(tga3)*180.0/pi;
if(a3_1<0)a3_1=a3_1+360.0;
a3_2=atan(tga3)*180.0/pi+180.0; if(a3_2>360.0)a3_2=a3_2-360.0;
ca3=cos(a3_1*pi/180.0);
sa3=sin(a3_1*pi/180.0);
if(sd1>0.1) tgd3_1=-1.0*cd1*(ca1*ca3+sa1*sa3)/sd1;
else tgd3_1=-1.0*cd2*(ca2*ca3+sa2*sa3)/sd2;
ca3=cos(a3_2*pi/180.0);
sa3=sin(a3_2*pi/180.0);
if(sd1>0.1) tgd3_2=-1.0*cd1*(ca1*ca3+sa1*sa3)/sd1;
else tgd3_2=-1.0*cd2*(ca2*ca3+sa2*sa3)/sd2;
d3_1=atan(tgd3_1)*180.0/pi;
d3_2=atan(tgd3_2)*180.0/pi;
139
if(a1==a2){if(d1<0){a3=a1-90.0; if(a3<0)a3=a3+360; d3=0;}
else { a3=a1+90.0; if(a3>360)a3=a3-360.0; d3=0; }
goto finish;}
if((a2-a1)==180.0 || (a1-a2)==180.0)
{ if(d1>0){a3=a1-90.0; if(a3<0)a3=a3+360; d3=0;}
else { a3=a1+90.0; if(a3>360)a3=a3-360; d3=0;}
goto finish;}
if(a2>a1)
{ if((a2-a1)<180.0)
{ if(d3_1>0){ a3=a3_1; d3=d3_1; }
else { a3=a3_2; d3=d3_2; }
}
else { if(d3_1>0){ a3=a3_2; d3=d3_2; }
else{ a3=a3_1; d3=d3_1; } }
}
if(a2<a1)
{ if((a1-a2)<180.0)
{ if(d3_1>0){ a3=a3_2; d3=d3_2; }
else { a3=a3_1; d3=d3_1; }
}
else { if(d3_1>0){a3=a3_1; d3=d3_1; }
else{ a3=a3_2; d3=d3_2; } }
}
finish:;
}