Список используемых источников

1. А.Б. Андросик, С.А. Воробьев, С.Д. Мировицкая. «Основы волноводной фотоники». Москва: Издательство МГОУ, 2009. 246 с.

2. http://www.optiwave.co.kr/pdf/brochures/optifdtd.pdf - описание программы optiwave, англоязычный сайт.

3. Н.В. Никоноров, С.М. Шандаров. «Волноводная фотоника». Учебное пособие, курс лекций. СПб: СПбГУ ИТМО, 2008 г. - 143 стр.

4. B. E. Little, S. T. Chu, H. A. Haus, J. Foresi, and J.-P. Laine. Microring resonator channel dropping _lters. Journal of Lightwave Technology, 15(6):998.1005, 1997.

Разработка и исследование системы обнаружения сигналов сейсмической волны

Воробьёв Д. Ю., Желонкин А. И.

МГОУ имени В.С. Черномырдина

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

Структурная схема системы приведена на рисунке 1. Система состоит из 16 пунктов обнаружения - ПО, располагаемых на расстоянии до 70 км от объекта, комплексов радиоаппаратуры передачи информации, включающих 8 радио трансляционных пунктов - РТП, и двух пунктов регистрации - ПР, располагаемых на объекте. Предусмотрено наращивание количества ПО до 20 и РТП до 10.

Система обеспечивает:

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

- время опережающего оповещения - не менее 10 с;

- вероятность пропуска сигнала - не более 10^-6 в год;

- вероятность ложного срабатывания - не более 10^-4 в год;

- коэффициент неготовности по функции аварийной защиты - не более

10^-5.

Аппаратура ПО предназначена для измерения трех ортогональных составляющих сигнала (X, Y, Z) в полосе частот от 0,3 до 30 Гц. ПО объединены в группы контроля.

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

Система опережающего оповещения о сейсмической волне от удаленных землетрясений (СООС) разработана для повышения безопасности АЭС, проектные сейсмические воздействия которых, определяются максимальными расчетными землетрясениями:

1) местными землетрясениями с магнитудой 4,5 , глубиной очага 5-20 км; частотой от 3 до 20 Гц; время прихода волн составляет 1-10 с.

2) удаленными землетрясениями с магнитудой 7,5 - 8,2 , глубиной 90-150 км, расстоянием до эпицентра 600 - 1600 км, для которых а_max = 0,2 - 0,5 м/с² на частотах 0,3 – 2 Гц , время прихода волн - от 3 до 10 мин.; вероятность землетрясений составляет 10^-4 в год.

Основной целью СООС является формирование опережающего сигнала, по которому возможно полное заглушение реактора до прихода сейсмической волны, превышающей максимальное проектное землетрясение. Время предварительного оповещения при этом составляет t_o £10с. Достигается это путем размещения на определенном расстоянии от объекта сети пунктов обнаружения (ПО), связанных с объектом радиоканалами. Разница в скоростях прохождения сейсмической волны и радиосигнала дает выигрыш во времени t. При этом t ³ т_по + t_р + t_пр + t_о,

где: t_по - время обработки сигнала в ПО,

t_р - время передачи и приема сигнала радиосредствами,

t_пр- время обработки сигнала с формированием управляющего сигнала.

Суммарное время t c учетом заданных значений составляет t = 11c. Наибольшую опасность для сооружений представляют поперечные волны S, несущие большую часть энергии землетрясения. Скорость распространения этих волн зависит от геофизических особенностей местности и лежит в пределах 3-5 км/с. Сейсмическая волна от дальних землетрясений распространяется с кажущейся скоростью Vs, значение которой не превышает тех же величин. Принимая во внимание, что t = R_min/V_s, при разработке схемы расположения ПО принято минимальное удаление 50 км. Для исключения ложных тревог, связанных с промышленными помехами, местными взрывами, грозовыми разрядами и другими факторами, в системе предусмотрена селекция сигналов по скорости распространения. Для этого предусмотрено наружное кольцо размещения ПО с радиусом 70 км от объекта. Типичная схема расположения ПО из 16 ПО представлена на рисунке 2.

Рис. 1. Структурная схема системы измерения сейсмических сигналов

Рис. 2. Схема расположения ПО и РТП сейсмической системы

ОБЪЕКТНО-РЕЛЯЦИОННЫЕ ПРЕОБРАЗОВАТЕЛИ В ЯЗЫКЕ С++

Найденов В. В., Путилин А. Б.

МГОУ имени В.С. Черномырдина

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

Естественной потребностью прикладных программ, разработанных с использованием объектно-ориентированного подхода, является сохранение состояния объектов из оперативной памяти во внешнее постоянное хранилище и обратная операция — восстановление состояний объектов. Эти операции носят название соответственно сериализации и де-сериализации объектов.

Одновременно с этим сложилась практика использования реляционных (табличных) СУБД в качестве универсальных хранилищ самых разнообразных данных. Плюсами реляционных СУБД являются:

• сравнительно простая математическая модель, лежащая в их основе — т. н. реляционная алгебра;

• наличие относительно стандартизированного способа взаимодействия с такими СУБД в виде языка SQL, который используется для выполнения запросов и других манипуляций с данными;

• наличие относительно стандартизированных прикладных программных интерфейсов (Application Programming Interface, API) для всевозможных языков программирования, с помощью которых программа может выполнять запросы к СУБД, используя выше упомянутый язык SQL;

• огромный выбор реализаций реляционных СУБД, удовлетворяющий большинству потребностей хранения данных;

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

В противовес реляционным существуют объектно-ориентированные базы данных, однако, по ряду причин, широкого распространения они до сих пор не получили. В качестве альтернативы объектным БД было предложено совмещение двух самых распространенных практик — объектно-ориентированного подхода и хранения данных в реляционных БД — это решение получило название объектно-реляционного преобразователя (Object-Relational Mapper, ORM). Основная задача инструментария ORM — отобразить классы, объекты и связи между ними на сущности БД — таблицы, строки, ограничения первичных и внешних ключей.

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

Инструментарий ORM создает дополнительный слой абстракции, позволяющий прикладному программисту мыслить больше категориями объектов и классов моделируемой предметной области, нежели категориями реляционной БД. Этот слой берет на себя вопросы сохранения и загрузки объектов, оптимизируя обращения к БД с помощью таких механизмов, как «загрузка по требованию». В то же время данный инструментарий должен предоставлять программисту достаточный контроль над исполняемыми запросами, при необходимости. Потенциально, этот слой абстракции может существенно снизить затраты на обучение программистов, снизить количество ошибок, упростить написание правил бизнес-логики.

Нужно помнить, что между реляционной и объектной моделями существует значительное различие, они решают разные задачи. Поэтому, если в разрабатываемой системе основной упор делается на многокритериальный поиск и массированное извлечение информации (класс информационно-поисковых систем, OLAP, генерация отчетности), то использование объектов для доступа к данным может быть излишне. Никакого различия между табличным представлением информации в базе данных, внутри программы и на экране пользователя или в отчете нет, промежуточная обработка сводится к соединениям таблиц и простым пересчетам значений их полей. Напротив, если система осуществляет транзакционную обработку (OLTP, On-Line Transaction Processing), сложные расчеты, оповещения о событиях, диспетчеризацию, моделирует поведение — здесь преимущества использования инструментария ORM наибольшие.

На данный момент инструментарии ORM в среде программистов на C++ используются не так широко как среде программистов на таких языках, как Java или Python. Причиной может быть как несколько иная сложившаяся область применения языка С++, так и недостаточная развитость средств ORM, доступных программистам на языке C++.

К особенностям данного языка можно отнести сильную типизацию, отсутствие встроенных механизмов интроспекции объектов на этапе выполнения, аналогичных Java Reflection API. В отдельных случаях это может быть проблемой, особенно если требуется анализ схемы БД на стадии выполнения.

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

При разработке должны быть использованы только общедоступные, а еще лучше стандартные компоненты. Однако, стандартная библиотека актуального стандарта ANSI С++ не содержит примитивов для работы с базами данных, данными в формате XML, типами данных для хранения дат и чисел с фиксированной точкой. Отчасти этот пробел восполняется такими библиотеками как Boost, являющимися стандартом де-факто.

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